From ras at e-gerbil.net  Sun Mar  1 13:03:53 2009
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Sun, 1 Mar 2009 12:03:53 -0600
Subject: [c-nsp] bootvar desync between RP and SP
In-Reply-To: <9149d2410902272125n189f4fc0sf678a50621538b0a@mail.gmail.com>
References: <20090228025216.GC51443@gerbil.cluepon.net>
	<9e246b4d0902271924x133a1b9g1ca5cda9204621e4@mail.gmail.com>
	<20090228051314.GD51443@gerbil.cluepon.net>
	<9149d2410902272125n189f4fc0sf678a50621538b0a@mail.gmail.com>
Message-ID: <20090301180353.GM51443@gerbil.cluepon.net>

On Sat, Feb 28, 2009 at 10:25:20AM +0500, M Usman Ashraf wrote:
> Hi,
> 
> What is the "boot system" command in this box configuration.

router#sh run | inc boot
boot-start-marker
boot system flash disk0:s72033-advipservicesk9-mz.122-33.SRC3.bin
boot system flash disk0:s72033-advipservicesk9-mz.122-33.SRC2.bin
boot-end-marker

I tried removing and readding these in IOS, but it doesn't change the
SP's bootvar at all.

On Sat, Feb 28, 2009 at 02:46:04PM -0500, Tim Durack wrote:
> What does "show run" look like on the sp? Mine all have:
>
> !
> boot-start-marker
> boot-end-marker
> !
>
> Wonder if that ever gets out of sync.

Empty on all routers, both working and non-working. Seems like this is 
completely ignored, and the bootvar is what is passed to the SP.

-- 
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 musmanashraf at gmail.com  Sun Mar  1 13:23:55 2009
From: musmanashraf at gmail.com (M Usman Ashraf)
Date: Sun, 1 Mar 2009 23:23:55 +0500
Subject: [c-nsp] bootvar desync between RP and SP
In-Reply-To: <20090301180353.GM51443@gerbil.cluepon.net>
References: <20090228025216.GC51443@gerbil.cluepon.net>
	<9e246b4d0902271924x133a1b9g1ca5cda9204621e4@mail.gmail.com>
	<20090228051314.GD51443@gerbil.cluepon.net>
	<9149d2410902272125n189f4fc0sf678a50621538b0a@mail.gmail.com>
	<20090301180353.GM51443@gerbil.cluepon.net>
Message-ID: <9149d2410903011023u251c5a2aje52d9c210d65afb4@mail.gmail.com>

Hi,

In our case the difference between boot variable on SP and RP was due to
"boot system" command. When it was boot system
disk0:c7600s72033-advipservicesk9-mz.122-33.SRC.bin", router used to boot
from sup-bootflash image, and like you, we had to break the boot sequence
and then had to type new image name. When we changed "boot system" command
to,

boot-start-marker
boot system flash disk0:c7600s72033-advipservicesk9-mz.122-33.SRC.bin
boot-end-marker

and then had to retype config register value to 0x2102, save and reload.
Since then everything is fine. However in you case everthing seems to be ok.



On Sun, Mar 1, 2009 at 11:03 PM, Richard A Steenbergen <ras at e-gerbil.net>wrote:

> On Sat, Feb 28, 2009 at 10:25:20AM +0500, M Usman Ashraf wrote:
> > Hi,
> >
> > What is the "boot system" command in this box configuration.
>
> router#sh run | inc boot
> boot-start-marker
> boot system flash disk0:s72033-advipservicesk9-mz.122-33.SRC3.bin
> boot system flash disk0:s72033-advipservicesk9-mz.122-33.SRC2.bin
> boot-end-marker
>
> I tried removing and readding these in IOS, but it doesn't change the
> SP's bootvar at all.
>
> On Sat, Feb 28, 2009 at 02:46:04PM -0500, Tim Durack wrote:
> > What does "show run" look like on the sp? Mine all have:
> >
> > !
> > boot-start-marker
> > boot-end-marker
> > !
> >
> > Wonder if that ever gets out of sync.
>
> Empty on all routers, both working and non-working. Seems like this is
> completely ignored, and the bootvar is what is passed to the SP.
>
> --
> 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)
>



-- 
Regards,

M Usman Ashraf

From asadh at comcast.net  Sun Mar  1 17:27:18 2009
From: asadh at comcast.net (asadh at comcast.net)
Date: Sun, 1 Mar 2009 22:27:18 +0000 (UTC)
Subject: [c-nsp] Which OID provides SP Memory stats on Sup720-3B
In-Reply-To: <240914582.865311235946144653.JavaMail.root@sz0032a.westchester.pa.mail.comcast.net>
Message-ID: <1668770281.866501235946438793.JavaMail.root@sz0032a.westchester.pa.mail.comcast.net>



I am trying use SNMP to get MemoryUsed and MemoryFree from SUP720-3B SP. Is there a particular OID that can be used to get this information? 



I've OIDs which work for RP but the OIDs for SP seem to be different for each 6509-E chassis. 



For example, I walked three 6509-Es with Sup720-3B, installed in slot 5 and resulting OID is different on each chassis. 



Sup720-3B in slot 5, running 12.2(33)SXI 

snmpwalk -v1 -c irishspring test -dist-01 1.3.6.1.4.1.9.9.221.1.1.1.1.7 
CISCO-ENHANCED-MEMPOOL-MIB::cempMemPoolUsed.5001.1 = Gauge32: 127996892 (SP Processor Mem) 
CISCO-ENHANCED-MEMPOOL-MIB::cempMemPoolUsed.5001.2 = Gauge32: 2082350 4 (SP IO Mem) 
CISCO-ENHANCED-MEMPOOL-MIB::cempMemPoolUsed.5017.1 = Gauge32: 121830752 (RP Processor Mem) 
CISCO-ENHANCED-MEMPOOL-MIB::cempMemPoolUsed.5017.2 = Gauge32: 21605592 (R P IO Mem) 




Sup720-3B in slot 5, running 12.2(18)SXF10 
snmpwalk -v1 -c irishspring test -dist-02 1.3.6.1.4.1.9.9.221.1.1.1.1.7 
CISCO-ENHANCED-MEMPOOL-MIB::cempMemPoolUsed.2001.1 = Gauge32: 70445456 (SP Processor Mem) 
CISCO-ENHANCED-MEMPOOL-MIB::cempMemPoolUsed.2001.2 = Gauge32: 15705552 (SP IO Mem) 
CISCO-ENHANCED-MEMPOOL-MIB::cempMemPoolUsed.2017.1 = Gauge32: 82511200 (RP Processor Mem) 
CISCO-ENHANCED-MEMPOOL-MIB::cempMemPoolUsed.2017.2 = Gauge32: 16487640 (RP IO Mem) 



Sup720-3B in slot 5, running 12.2(33)SXI 
snmpwalk -v1 -c irishspring test -dist-03 1.3.6.1.4.1.9.9.221.1.1.1.1.7 
CISCO-ENHANCED-MEMPOOL-MIB::cempMemPoolUsed.6001.1 = Gauge32: 128474820 (SP Processor Mem) 
CISCO-ENHANCED-MEMPOOL-MIB::cempMemPoolUsed.6001.2 = Gauge32: 20823504 (SP IO Mem) 
CISCO-ENHANCED-MEMPOOL-MIB::cempMemPoolUsed.6017.1 = Gauge32: 141062428 (RP Processor Mem) 
CISCO-ENHANCED-MEMPOOL-MIB::cempMemPoolUsed.6017.2 = Gauge32: 21605592 (RP IO Mem) 



Above OIDs also change upon reboot. Is there an easier?method or different OID to get memory information on SP? 



Thanks in advance. 



-Asad 



From David at hughes.com.au  Sun Mar  1 17:13:59 2009
From: David at hughes.com.au (David Hughes)
Date: Mon, 2 Mar 2009 08:13:59 +1000
Subject: [c-nsp] Odd request to anyone who has a switch capable of EoMPLS
In-Reply-To: <C5290E36-F64A-4EB4-8F43-60D2A0B609A8@lixfeld.ca>
References: <C5290E36-F64A-4EB4-8F43-60D2A0B609A8@lixfeld.ca>
Message-ID: <E34B6244-78B7-4A84-B4CE-4CB70B31325A@Hughes.com.au>



On 28/02/2009, at 12:15 AM, Jason Lixfeld wrote:

> I need to know whether or not a switch port from a 6500/7600 or  
> ME6500 (or any other switch series that does EoMPLS) that is  
> configured for EoMPLS (xconnect <vc> <IP>) still transmits STP BPDUs  
> while the EoMPLS tunnel is up (or down for that matter).

On Cat6k you can only configure EoMPLS xconnects on a layer 3  
interface, not a switch port..  Any BPDUs you get are from the other  
end of the VC.


Thanks

David
...

From sam+cisco-nsp at australiaonline.net.au  Sun Mar  1 19:45:22 2009
From: sam+cisco-nsp at australiaonline.net.au (Sam Tilders)
Date: Mon, 02 Mar 2009 11:45:22 +1100
Subject: [c-nsp] packet loss between adjacent ciscos
In-Reply-To: <200902272248.30103.mtinka@globaltransit.net>
References: <20090227162830.xbtdn6m8jyss40sg@webmail2.australiaonline.net.au>
	<200902272248.30103.mtinka@globaltransit.net>
Message-ID: <20090302114522.h7m2au9v8kwk4c88@webmail2.australiaonline.net.au>

Quoting Mark Tinka <mtinka at globaltransit.net>:

> On Friday 27 February 2009 01:28:30 pm Sam Tilders wrote:
>
>> So, I was wondering if this sounds familiar to anyone or
>> if there is anything someone might be able to suggest to
>> further investigate or resolve this issue.
>
> Does this affect all other traffic running across this
> switch, or just the VoIP customer?

Mark,

It appears to affect all traffic. For example an SSH session to a host  
that has to pass across the link between the router and switch will  
pause at the same moment that the ping misses a packet and the voip is  
silent.

- Sam



From md at bts.sk  Mon Mar  2 03:29:22 2009
From: md at bts.sk (Marian =?utf-8?B?xI51cmtvdmnEjQ==?=)
Date: Mon, 2 Mar 2009 09:29:22 +0100
Subject: [c-nsp] Cat3560E - insufficient buffers for microbursts?
Message-ID: <20090302082922.GA35030@bts.sk>

Hi all,

  recently we replaced some of our access switches by Cat3560E models.
After the change, we noticed a significant rise of dropped packets on
outgoing interfaces.

  Closer investigation showed, that for some reason, Cat3560E is doing
significantly less output buffering than all other Cisco access switches.
While Cat2960G, Cat3550, Cat3560G and Cat3750G happily buffer any
microburst upto 100 full size (1500 byte) packets, Cat3560E only buffers
upto 64 full size packets and starts dropping beginning with 65-th packet.
This was rather bad surprise, since the Cat3560E is supposed to have
10GE uplinks - and with 10:1 or 100:1 speed downshift from uplink into
access ports decent buffering is vital for proper operation.

  Does anyone have an idea what's the reason for this behaviour - i.e.
were the ASIC buffers significantly reduced on Cat3560E models or is this
just wrong IOS defaults? Are there any CLI knobs to tune output buffering
in FIFO mode of operation (no mls qos)?


     Thanks & kind regards,

            M.


P.S. This behaviour could be reproduced by e.g. sending 1500 byte packets
     at gigabit ethernet wire rate through the switch to another device,
     which is connected at lower speed (10 or 100 Mbps).

From ian.mackinnon at lumison.net  Mon Mar  2 04:01:15 2009
From: ian.mackinnon at lumison.net (Ian MacKinnon)
Date: Mon, 02 Mar 2009 09:01:15 +0000
Subject: [c-nsp] mls qos vlan-based issues
In-Reply-To: <EAF4FF4AB2142D499F2F5A3B9D8515290440F6CC@exch-bo.MGVFS.McLeanNet>
References: <EAF4FF4AB2142D499F2F5A3B9D8515290440F6CC@exch-bo.MGVFS.McLeanNet>
Message-ID: <49ABA05B.40703@lumison.net>

Hi Leslie,

I am seeing something similar, but I am not seeing policing in either 
direction :-)

12.2(33)SXH

when I check with sh policy-map interface, I do not see the exceed 
counters incrementing.



On 27/02/2009 20:14, Leslie Meade wrote:
> I have an issue that I cannot work out.
>
>   I had all my policing statements working, when I had my asa's plugged
> into an old 6509 via a fiber port that was trunked on both ends and the
> ports that the asa's were plugged into were normal switch ports.
>
> I have now plugged them directly into the new 6509 and now I am only
> getting policing on downloads only.
>
>
>
> policy-map 8_Mb_Internet
>
>    class class-default
>
>     police cir 8388500 bc 265625 be 265625 conform-action transmit
> exceed-action drop violate-action drop
>
>
>
> interface GigabitEthernet5/8
>
> switchport
>
>   switchport trunk encapsulation dot1q
>
>   switchport mode trunk
>
>   no ip address
>
>   mls qos vlan-based
>
>
>
> interface Vlan16
>
>    ip address 10.1.16.2 255.255.255.0
>
>   ip access-group Productions in
>
>   ip helper-address 10.1.6.10
>
>   no ip redirects
>
>   no ip unreachables
>
>   ip flow ingress
>
>   ip route-cache flow
>
>   no ip mroute-cache
>
>   mls netflow sampling
>
>   standby 15 ip 10.1.16.1
>
>   standby 15 priority 250
>
>   standby 15 preempt
>
>   service-policy input 8_Mb_Internet
>
>   service-policy output 8_Mb_Internet
>
>
>
> Any ideas what could be causing the qos to police only downloads and not
> up loads ?
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>    


-- 
Ian MacKinnon
Lumison
t: 0845 1199 900
d: 0131 514 4055
P.S. Do you love Lumison?

p.s. Looking for remote access?
Chat to our team about our award winning broadband and VoIP solutions
for remote and home working, or visit www.lumison.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 and nPlusOne.
Finally, the recipient should check this email and any attachments for the
presence of viruses.  Lumison and nPlusOne accept no liability for any
damage caused by any virus transmitted by this email.


From manafo at hotmail.com  Mon Mar  2 04:27:27 2009
From: manafo at hotmail.com (Manaf Al Oqlah)
Date: Mon, 2 Mar 2009 11:27:27 +0200
Subject: [c-nsp] DHCP Binding Expiration
In-Reply-To: <D0D0330CBD07114D85B70B784E80C2F2022FCFB6@exch-mail2.win.slac.stanford.edu>
References: <49906CFE.7040407@justinshore.com><200902092022.14601.lowen@pari.edu>
	<D0D0330CBD07114D85B70B784E80C2F2022FCFB6@exch-mail2.win.slac.stanford.edu>
Message-ID: <BLU130-DS740D6D8F977DFFE7BAC20C5A90@phx.gbl>

Yes, I've noticed that all affected clients are BOOTP clients!

--------------------------------------------------
From: "Buhrmaster, Gary" <gtb at slac.stanford.edu>
Sent: Sunday, February 15, 2009 7:51 AM
To: <cisco-nsp at puck.nether.net>
Subject: Re: [c-nsp] DHCP Binding Expiration

> 
> 
>> 
>> BOOTP.
>> 
> 
> Have not used the IOS dhcp server in a long
> time (the ISC dhcp server is far more capable),
> but when I did, I vaguely recall adding these
> commands which eliminated the infinite lease
> times in my specific environment (which were
> all traced down to bootp requests):
> 
>  no ip bootp server
>  ip dhcp bootp ignore
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 

From sthaug at nethelp.no  Mon Mar  2 04:41:26 2009
From: sthaug at nethelp.no (sthaug at nethelp.no)
Date: Mon, 02 Mar 2009 10:41:26 +0100 (CET)
Subject: [c-nsp] Cat3560E - insufficient buffers for microbursts?
In-Reply-To: <20090302082922.GA35030@bts.sk>
References: <20090302082922.GA35030@bts.sk>
Message-ID: <20090302.104126.74722994.sthaug@nethelp.no>

>   Closer investigation showed, that for some reason, Cat3560E is doing
> significantly less output buffering than all other Cisco access switches.
> While Cat2960G, Cat3550, Cat3560G and Cat3750G happily buffer any
> microburst upto 100 full size (1500 byte) packets, Cat3560E only buffers
> upto 64 full size packets and starts dropping beginning with 65-th packet.
> This was rather bad surprise, since the Cat3560E is supposed to have
> 10GE uplinks - and with 10:1 or 100:1 speed downshift from uplink into
> access ports decent buffering is vital for proper operation.

We experienced the same problem with ME3400 switches. It has extremely
small buffers by default - the queue size is in units of 256 byte, and
default queue size is only 48 of these. We got around this by configuring
shaping (which is possible on the ME3400) and setting queue-limit 256 in
the policy-map. The problem seems to be resolved in 12.2(46), note the
following point from the release notes:

> CSCsm80634 
>
> The default queue limit for QoS has been changed from 48 to 160
> (256-byte) packets.

I wouldn't be surprised if 3560E has similar behavior (but I haven't
checked).

Steinar Haug, Nethelp consulting, sthaug at nethelp.no

From ibrahim.abozaid at gmail.com  Mon Mar  2 05:01:10 2009
From: ibrahim.abozaid at gmail.com (Ibrahim Abo Zaid)
Date: Mon, 2 Mar 2009 12:01:10 +0200
Subject: [c-nsp] CCIE Lab tools
Message-ID: <a48927f70903020201n12d1c679gce60ba8c2d707249@mail.gmail.com>

Hi All

I have a question about CCIE Lab exam , we heard many stories about some
exam trick and IOS bugs which causes technologies to fail and losing point
so is there any tool available in the exam to identify if there is IOS bug
cause this problem ? i know there is documentation tool but that states
technologies configuration task list not technologies interworking problems
?

best regards
--Ibrahim

From zhqasmi at cyber.net.pk  Mon Mar  2 05:03:54 2009
From: zhqasmi at cyber.net.pk (Amjad Ul Hasnain Qasmi)
Date: Mon, 02 Mar 2009 15:03:54 +0500
Subject: [c-nsp] No. of VRF supported
Message-ID: <006c01c99b1e$32a3ce90$97eb6bb0$@net.pk>

Hi All,

 

I would like to know the max. number of VRF supported on Cisco 7206VXR
(NPE-G2) and Cisco 10K.

 

Regards,

AHQ

 


From mihai.todor at datanets.ro  Mon Mar  2 05:18:34 2009
From: mihai.todor at datanets.ro (Mihai Todor)
Date: Mon, 2 Mar 2009 12:18:34 +0200
Subject: [c-nsp] high cpu load not by processes
In-Reply-To: <499D912E.3020301@umn.edu>
References: <006001c992af$f5648ef0$e02dacd0$@todor@datanets.ro>
	<499D912E.3020301@umn.edu>
Message-ID: <004b01c99b20$3e787430$bb695c90$@todor@datanets.ro>

Thanks for the tip! In my case though there were no single processes loading
the cpu:

#sh proc cpu | e 0.00
CPU utilization for five seconds: 48%/35%; one minute: 32%; five minutes:
32%
 PID Runtime(ms)   Invoked      uSecs   5Sec   1Min   5Min TTY Process 
 196    21322228 427846338         49  0.31%  0.16%  0.17%   0 IP Input

 460     5474156    285374      19182  0.55%  0.07%  0.03%   0 BGP Scanner

 466        2868      6596        434 11.59%  0.96%  0.23%   1 Virtual Exec


A nice command to check how much traffic goes to the cpu:

#show ibc
Interface information:
	Interface IBC0/0(idb 0x13764774)
	5 minute rx rate 285758000 bits/sec, 23046 packets/sec
	5 minute tx rate 594270000 bits/sec, 91869 packets/sec
	110219721075 packets input, 170099314990812 bytes
	109544766443 broadcasts received
	218978746093 packets output, 173382310588137 bytes
	283552367 broadcasts sent
	0 Bridge Packet loopback drops
	109343818646 Packets CEF Switched, 8 Packets Fast Switched
	0 Packets SLB Switched, 0 Packets CWAN Switched
	Label switched pkts dropped: 0
	0 total martian ip v4 packets dropped
	Xconnect pkts processed: 0, dropped: 0
	Total paks copied for process level 0
	Total throttle drops 612719    Input queue drops 2662
	IBC resets   = 1; last at 09:35:51.771 UTC Mon Aug 11 2008
 Dev_Instance=0x1377F774


In our case the load was caused by packet fragmentation performed by the CPU
in interrupt mode I suppose.

Cheers,
Mihai



-----Original Message-----
From: Ge Moua [mailto:moua0100 at umn.edu] 
Sent: Thursday, February 19, 2009 7:05 PM
To: Mihai Todor
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] high cpu load not by processes

sh proc cpu | ex 0.00

sh proc cpu detailed [pid] | ex 0.00


Regards,
Ge Moua | Email: moua0100 at umn.edu

Network Design Engineer
University of Minnesota | Networking & Telecommunications Services




Mihai Todor wrote:
> Hello,
>
> Do you have any ideea on how to see what interrups are loading a router's
> CPU?
>
> We're experiencing a high cpu load (60%) on a router, yet resources are
not
> consumed by processes. Some background info - the machine is a 7609-S
router
> with redundant SUP720-3BXL supervizors having a PE role.
>
> Thanks!
>
> Mihai
>
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>   


From oboehmer at cisco.com  Mon Mar  2 07:04:27 2009
From: oboehmer at cisco.com (Oliver Boehmer (oboehmer))
Date: Mon, 2 Mar 2009 13:04:27 +0100
Subject: [c-nsp] No. of VRF supported
In-Reply-To: <006c01c99b1e$32a3ce90$97eb6bb0$@net.pk>
References: <006c01c99b1e$32a3ce90$97eb6bb0$@net.pk>
Message-ID: <70B7A1CCBFA5C649BD562B6D9F7ED78406F46F64@xmb-ams-333.emea.cisco.com>

Amjad Ul Hasnain Qasmi <> wrote on Monday, March 02, 2009 11:04:

> I would like to know the max. number of VRF supported on Cisco 7206VXR
> (NPE-G2) and Cisco 10K.

"it depends".. Don't think there is a hard/fixed limit on the 7200, we
used to recommend not more than 1000 (NPE-G2 can push more, possibly),
but it depends on the control-plane features being used (i.e. routing
protocols) and also the number of routes/vrf..
I think the 10k PRE2/PRE3 supports 4k VRFs, but with the same caveat..

	oli

From blahu77 at gmail.com  Mon Mar  2 08:24:00 2009
From: blahu77 at gmail.com (Mateusz Blaszczyk)
Date: Mon, 2 Mar 2009 13:24:00 +0000 (IST)
Subject: [c-nsp] Cat3560E - insufficient buffers for microbursts?
In-Reply-To: <20090302.104126.74722994.sthaug@nethelp.no>
Message-ID: <frt6mpnfvou929hchpUYAxe124vaj_firegpg@mail.gmail.com>


We are seeing similar problem not to be able to achieve good thorughput speeds even with 12.2(46).

2009/3/2  <sthaug at nethelp.no>:
> We got around this by configuring
> shaping (which is possible on the ME3400) and setting queue-limit 256 in
> the policy-map. The problem seems to be resolved in 12.2(46), note the
> following point from the release notes:
>
>> CSCsm80634
>>
>> The default queue limit for QoS has been changed from 48 to 160
>> (256-byte) packets.

27x 1500B packets is still low.. so I guess the shaping/policy-map is still needed.


-- 
pgp-key 0x1C655CAB

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 270 bytes
Desc: OpenPGP digital signature
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090302/696bb6d0/attachment.bin>

From bennetb at gmail.com  Mon Mar  2 11:23:49 2009
From: bennetb at gmail.com (Brandon Bennett)
Date: Mon, 2 Mar 2009 09:23:49 -0700
Subject: [c-nsp] CCIE Lab tools
In-Reply-To: <a48927f70903020201n12d1c679gce60ba8c2d707249@mail.gmail.com>
References: <a48927f70903020201n12d1c679gce60ba8c2d707249@mail.gmail.com>
Message-ID: <d81b6b610903020823y109c9794tb731e312a04fd74b@mail.gmail.com>

On Mon, Mar 2, 2009 at 3:01 AM, Ibrahim Abo Zaid
<ibrahim.abozaid at gmail.com>wrote:

> Hi All
>
> I have a question about CCIE Lab exam , we heard many stories about some
> exam trick and IOS bugs which causes technologies to fail and losing point
> so is there any tool available in the exam to identify if there is IOS bug
> cause this problem ? i know there is documentation tool but that states
> technologies configuration task list not technologies interworking problems
> ?
>
>
Those people are just trying to justify why they failed and blame external
issues instead of "incompetence".  You will not run into a bug during the
exam.  If  you think you have you can call over the proctor,  he will let
you know if it is a bug or not but 99.9% of the time it won't be.

Don't get hung up on the stories of people failing and the reasons why.  The
reason always boils down to not enough studying.

-Brandon
CCIE #19406

From nrauhauser at gmail.com  Mon Mar  2 12:24:38 2009
From: nrauhauser at gmail.com (neal rauhauser)
Date: Mon, 2 Mar 2009 11:24:38 -0600
Subject: [c-nsp] finding bad actors on Cat 2924 ports
Message-ID: <9515c62d0903020924y38c48f08i92c8420d265f8952@mail.gmail.com>

  I have a Cat 2924 with a port facing an old Waverider radio. I've got
about 80 MACs live on the interface, it's got a steady 5% error rate, and
the net effect is that it's behaving like WRED with a nearly full cue -
traffic for all slows to a crawl.

  I've been fiddling with it a bit trying to come up with a way to sort out
which remote MAC is the source of the mangled frames and I'm having no luck.
Let's keep in mind that it's 18F here today with a nice, stiff breeze and
the machine in question is 120' up in the top of an old grain elevator.
Something in an snmpwalk that would find this would be lovely ...




-- 
mailto:Neal at layer3arts.com //
GoogleTalk: nrauhauser at gmail.com
IM: nealrauhauser

From isplists at duracom.net  Mon Mar  2 15:04:04 2009
From: isplists at duracom.net (Rhino Lists)
Date: Mon, 2 Mar 2009 14:04:04 -0600
Subject: [c-nsp] 7206 Gig Ethernet Options
In-Reply-To: <037901c995ec$4ba3db60$e2eb9220$@net>
References: <389E7FA0-2001-4038-B225-D4B6C003B593@Princeton.EDU>
	<037901c995ec$4ba3db60$e2eb9220$@net>
Message-ID: <01c301c99b72$09866730$1c933590$@net>

We are in the process of migrating from ATM Circuits at our locations to
point to point fiber.  I have a Cisco 7206vxr with NPE-G2 so currently I
have 3 GigE ports over Copper and have the option to add SFP's if need be to
go to fiber.  If I need more GigE ports in this Chassis are the only options
to add a PA-GE?  I read where a PA-GE will not support the copper gigabit?  


Joe



From abalashov at evaristesys.com  Mon Mar  2 15:07:29 2009
From: abalashov at evaristesys.com (Alex Balashov)
Date: Mon, 02 Mar 2009 15:07:29 -0500
Subject: [c-nsp] Voice translation-rules on FXS voice-port don't work.
Message-ID: <49AC3C81.4030508@evaristesys.com>

Sorry for crossposting this from cisco-voip - figured maybe someone here 
might know.

-------- Original Message --------
Subject: Re: [cisco-voip] Voice translation-rules on FXS voice-port 
don't work.
Date: Mon, 02 Mar 2009 15:03:45 -0500
From: Alex Balashov <abalashov at evaristesys.com>
To: cisco-voip at puck.nether.net
References: <49AC3722.9040900 at evaristesys.com>

Applying the translation rule straight without a profile - e.g.

voice-port 5/0/0
   translate called 10

Doesn't work either.

Alex Balashov wrote:

> Does anybody have any idea why voice translation-rules designed to 
> prepend a prefix to the dialed number would not work when applied to an 
> FXS voice-port?
> 
> e.g.
> 
> voice translation-rule 10
>  rule 1 /^1/ /35#1/
>  rule 2 /^2/ /35#2/
>  rule 3 /^3/ /35#3/
>  rule 4 /^4/ /35#4/
>  rule 5 /^5/ /35#5/
>  rule 6 /^6/ /35#6/
>  rule 7 /^7/ /35#7/
>  rule 8 /^8/ /35#8/
>  rule 9 /^9/ /35#9/
> !
> !
> !
> voice translation-profile TRANSPROF
>  translate called 10
> 
> ...
> 
> voice-port 5/0/0
>  translation-profile incoming TRANSPROF
>  station-id number 4049611103
> 
> The goal here is to prepend a 35# prefix to any number that is dialed 
> from an analog phone connected to this device before the call is sent 
> out as VoIP.
> 
> I've never run into this before because the only ports I've ever needed 
> to apply these types of translations to have been PRI.  In any case, the 
> above does not cause a 35# prefix to be prepended.  The call just passes 
> through as normal with no translations.
> 


-- 
Alex Balashov
Evariste Systems
Web    : http://www.evaristesys.com/
Tel    : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (678) 237-1775
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

-- 
Alex Balashov
Evariste Systems
Web    : http://www.evaristesys.com/
Tel    : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (678) 237-1775

From billw at waveform.net  Mon Mar  2 15:26:31 2009
From: billw at waveform.net (billw at waveform.net)
Date: Mon, 2 Mar 2009 15:26:31 -0500 (EST)
Subject: [c-nsp] 7206 Gig Ethernet Options
In-Reply-To: <01c301c99b72$09866730$1c933590$@net>
References: <389E7FA0-2001-4038-B225-D4B6C003B593@Princeton.EDU>
	<037901c995ec$4ba3db60$e2eb9220$@net>
	<01c301c99b72$09866730$1c933590$@net>
Message-ID: <6caa2aaf3999544c0ef807111b85a0c8.squirrel@webmail.waveform.net>

AFAIK, the PA-GE is only available supporting a GBIC, so there is no
native copper interface. I've never tried using a 1000b-T GBIC in a PA-GE
before, but I wouldn't count on it working -- Cisco only lists the PA-GE
as supporting optical GBICs.

Depending on your application, you might be able to use a switch as a
"media converter" to convert from something like gig-SX from the PA-GE to
a gigabit copper port. If you don't need the router to see multiple VLANs
it's easy to just put a copper port and an optical port on the same VLAN
in a switch and use the two ports like a media converter. While not an
elegant solution, it does work.

  -Bill

> We are in the process of migrating from ATM Circuits at our locations to
> point to point fiber.  I have a Cisco 7206vxr with NPE-G2 so currently I
> have 3 GigE ports over Copper and have the option to add SFP's if need be
> to
> go to fiber.  If I need more GigE ports in this Chassis are the only
> options
> to add a PA-GE?  I read where a PA-GE will not support the copper gigabit?
>
>
> Joe
>
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>



From kapsi1911 at hotmail.com  Mon Mar  2 15:45:12 2009
From: kapsi1911 at hotmail.com (D W)
Date: Mon, 2 Mar 2009 15:45:12 -0500
Subject: [c-nsp] Verizon's PIP service
Message-ID: <BLU105-W204299E47DC1F7EA2F3F0A7A90@phx.gbl>


Anyone happen to know if Verizon relies on any 3rd party service providers (using inter-AS MP-BGP, ATOM, etc.) for their PIP (MPLS based private IP) service? I'm trying to figure out which service providers have a national reach and fully contain/control their own MPLS clouds without relying on one another for transport.

 

Thanks,

Dave

_________________________________________________________________
Windows Live?: Life without walls.
http://windowslive.com/explore?ocid=TXT_TAGLM_WL_allup_1a_explore_032009

From Gregori.Parker at theplatform.com  Mon Mar  2 15:52:53 2009
From: Gregori.Parker at theplatform.com (Gregori Parker)
Date: Mon, 2 Mar 2009 12:52:53 -0800
Subject: [c-nsp] 7206 Gig Ethernet Options
In-Reply-To: <6caa2aaf3999544c0ef807111b85a0c8.squirrel@webmail.waveform.net>
References: <389E7FA0-2001-4038-B225-D4B6C003B593@Princeton.EDU><037901c995ec$4ba3db60$e2eb9220$@net><01c301c99b72$09866730$1c933590$@net>
	<6caa2aaf3999544c0ef807111b85a0c8.squirrel@webmail.waveform.net>
Message-ID: <1A9866F953006D45AEE0166066114E0915D78791@TPMAIL02.corp.theplatform.com>

PA-GE is the only available option for more GE ports on the
7206vxr...and it's one interface per module and 1000b-TX GBICs work just
fine in the slot.

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of
billw at waveform.net
Sent: Monday, March 02, 2009 12:27 PM
To: Rhino Lists
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] 7206 Gig Ethernet Options

AFAIK, the PA-GE is only available supporting a GBIC, so there is no
native copper interface. I've never tried using a 1000b-T GBIC in a
PA-GE
before, but I wouldn't count on it working -- Cisco only lists the PA-GE
as supporting optical GBICs.

Depending on your application, you might be able to use a switch as a
"media converter" to convert from something like gig-SX from the PA-GE
to
a gigabit copper port. If you don't need the router to see multiple
VLANs
it's easy to just put a copper port and an optical port on the same VLAN
in a switch and use the two ports like a media converter. While not an
elegant solution, it does work.

  -Bill

> We are in the process of migrating from ATM Circuits at our locations
to
> point to point fiber.  I have a Cisco 7206vxr with NPE-G2 so currently
I
> have 3 GigE ports over Copper and have the option to add SFP's if need
be
> to
> go to fiber.  If I need more GigE ports in this Chassis are the only
> options
> to add a PA-GE?  I read where a PA-GE will not support the copper
gigabit?
>
>
> Joe
>
>
> _______________________________________________
> cisco-nsp mailing 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 lowen at pari.edu  Mon Mar  2 16:13:14 2009
From: lowen at pari.edu (Lamar Owen)
Date: Mon, 2 Mar 2009 16:13:14 -0500
Subject: [c-nsp] 7206 Gig Ethernet Options
In-Reply-To: <6caa2aaf3999544c0ef807111b85a0c8.squirrel@webmail.waveform.net>
References: <389E7FA0-2001-4038-B225-D4B6C003B593@Princeton.EDU>
Message-ID: <200903021613.14546.lowen@pari.edu>

I have used a copper GBIC (WS-G5483) with a 7500 and a GEIP+ before.  But not 
with a GEIP (VIP2-50+PA-GE).  It may work, though.

The 'official' answer is in 
http://www.cisco.com/en/US/docs/interfaces_modules/transceiver_modules/compatibility/matrix/OL_6981.html

But, that document doesn't show the WS-G5483 being supported by the GEIP+ 
(which I know works, because I've used it).  

Likewise, Catalyst 5500 Gigabit EtherChannel module (WS-X5410) works with the 
5483, but it's the only Catalyst 5000 series interface to do so (see below:
pari-5505-colo-1> (enable) sh mod
Mod Slot Ports Module-Type               Model               Sub Status
--- ---- ----- ------------------------- ------------------- --- --------
1   1    2     1000BaseX Supervisor IIIG WS-X5550            no  ok
15  1    1     Route Switch Feature Card WS-F5541            no  ok
2   2    2     1000BaseX Supervisor IIIG WS-X5550            no  standby
16  2    1     Route Switch Feature Card WS-F5541            no  ok
3   3          Gigabit Ethernet Ext      WS-X5410
4   4    9     Gigabit Ethernet          WS-X5410            no  ok
5   5    24    10/100BaseTX Ethernet     WS-X5225R           no  ok
......
ari-5505-colo-1> (enable) sh port
Port  Name               Status     Vlan       Level  Duplex Speed Type
----- ------------------ ---------- ---------- ------ ------ ----- 
------------
 1/1                     notconnect 1          normal   full  1000 No 
Connector
 1/2                     connected  trunk      normal   full  1000 1000-LX/LH
[snip]
 4/9                     connected  trunk      normal   full  1000 1000BaseT
 
The X5410 ports will work with 1000base-T, but the SupIIIG's ports will not, 
nor will a X5403's (three-port gigabit ethernet).

So, grab a surplus 5483 on ebay and try it.  It may work.


On Monday 02 March 2009 15:26:31 billw at waveform.net wrote:
> AFAIK, the PA-GE is only available supporting a GBIC, so there is no
> native copper interface. I've never tried using a 1000b-T GBIC in a PA-GE
> before, but I wouldn't count on it working -- Cisco only lists the PA-GE
> as supporting optical GBICs.
>
> Depending on your application, you might be able to use a switch as a
> "media converter" to convert from something like gig-SX from the PA-GE to
> a gigabit copper port. If you don't need the router to see multiple VLANs
> it's easy to just put a copper port and an optical port on the same VLAN
> in a switch and use the two ports like a media converter. While not an
> elegant solution, it does work.
>
>   -Bill
>
> > We are in the process of migrating from ATM Circuits at our locations to
> > point to point fiber.  I have a Cisco 7206vxr with NPE-G2 so currently I
> > have 3 GigE ports over Copper and have the option to add SFP's if need be
> > to
> > go to fiber.  If I need more GigE ports in this Chassis are the only
> > options
> > to add a PA-GE?  I read where a PA-GE will not support the copper
> > gigabit?
> >
> >
> > Joe
> >
> >
> > _______________________________________________
> > cisco-nsp mailing 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/


-- 
Lamar Owen
Chief Information Officer
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
http://www.pari.edu

From sml at lordsargon.com  Mon Mar  2 16:30:36 2009
From: sml at lordsargon.com (SML)
Date: Mon, 2 Mar 2009 15:30:36 -0600
Subject: [c-nsp] Verizon's PIP service
In-Reply-To: <BLU105-W204299E47DC1F7EA2F3F0A7A90@phx.gbl>
References: <BLU105-W204299E47DC1F7EA2F3F0A7A90@phx.gbl>
Message-ID: <13B240E3-7052-4F46-B88D-9FCE692AAC08@lordsargon.com>


On 2-Mar-09, at 14:45:12, D W wrote:

>
> Anyone happen to know if Verizon relies on any 3rd party service  
> providers (using inter-AS MP-BGP, ATOM, etc.) for their PIP (MPLS  
> based private IP) service? I'm trying to figure out which service  
> providers have a national reach and fully contain/control their own  
> MPLS clouds without relying on one another for transport.


VZ told us that they use their network. We user them in multiple  
locations around the world. We do see the occasional issue in which  
the PE circuit (Ethernet hand-off) is up and the BGP peering is up,  
but we see no routes. Sometimes this lasts for a couple of hours  
(especially in Asia).

We have never received a satisfactory explanation for what they are  
doing to our routes internally in their network.


From chris at chrisserafin.com  Mon Mar  2 16:44:43 2009
From: chris at chrisserafin.com (ChrisSerafin)
Date: Mon, 02 Mar 2009 15:44:43 -0600
Subject: [c-nsp] Verizon's PIP service
In-Reply-To: <BLU105-W204299E47DC1F7EA2F3F0A7A90@phx.gbl>
References: <BLU105-W204299E47DC1F7EA2F3F0A7A90@phx.gbl>
Message-ID: <49AC534B.8010809@chrisserafin.com>

I know for a fact that Verizon doesn't control everything end to end. I 
have a decent sized client with circuits all over EMEA, and I always 
hear, 'ooh that's referred out to AT&T/xxxx for testing'

This may be only the last mile of the circuit though.

just my 2 cents

--chris

D W wrote:
> Anyone happen to know if Verizon relies on any 3rd party service providers (using inter-AS MP-BGP, ATOM, etc.) for their PIP (MPLS based private IP) service? I'm trying to figure out which service providers have a national reach and fully contain/control their own MPLS clouds without relying on one another for transport.
>
>  
>
> Thanks,
>
> Dave
>
> _________________________________________________________________
> Windows Live?: Life without walls.
> http://windowslive.com/explore?ocid=TXT_TAGLM_WL_allup_1a_explore_032009
> _______________________________________________
> cisco-nsp mailing 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.0.237 / Virus Database: 270.11.5/1979 - Release Date: 03/01/09 17:46:00
>
>   


From brandon at sterling.net  Mon Mar  2 18:27:03 2009
From: brandon at sterling.net (Brandon Price)
Date: Mon, 02 Mar 2009 15:27:03 -0800
Subject: [c-nsp] 7206 Gig Ethernet Options
In-Reply-To: <1A9866F953006D45AEE0166066114E0915D78791@TPMAIL02.corp.theplatform.com>
References: <389E7FA0-2001-4038-B225-D4B6C003B593@Princeton.EDU><037901c995ec$4ba3db60$e2eb9220$@net><01c301c99b72$09866730$1c933590$@net>	<6caa2aaf3999544c0ef807111b85a0c8.squirrel@webmail.waveform.net>
	<1A9866F953006D45AEE0166066114E0915D78791@TPMAIL02.corp.theplatform.com>
Message-ID: <49AC6B47.9040805@sterling.net>

Actually, you can install a C7200-I/O-GE+E and save yourself a PA slot 
and the associated bandwidth point hit.

http://www.gossamer-threads.com/lists/cisco/bba/101247

Brandon



Gregori Parker wrote:
> PA-GE is the only available option for more GE ports on the
> 7206vxr...and it's one interface per module and 1000b-TX GBICs work just
> fine in the slot.
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of
> billw at waveform.net
> Sent: Monday, March 02, 2009 12:27 PM
> To: Rhino Lists
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] 7206 Gig Ethernet Options
>
> AFAIK, the PA-GE is only available supporting a GBIC, so there is no
> native copper interface. I've never tried using a 1000b-T GBIC in a
> PA-GE
> before, but I wouldn't count on it working -- Cisco only lists the PA-GE
> as supporting optical GBICs.
>
> Depending on your application, you might be able to use a switch as a
> "media converter" to convert from something like gig-SX from the PA-GE
> to
> a gigabit copper port. If you don't need the router to see multiple
> VLANs
> it's easy to just put a copper port and an optical port on the same VLAN
> in a switch and use the two ports like a media converter. While not an
> elegant solution, it does work.
>
>   -Bill
>
>   
>> We are in the process of migrating from ATM Circuits at our locations
>>     
> to
>   
>> point to point fiber.  I have a Cisco 7206vxr with NPE-G2 so currently
>>     
> I
>   
>> have 3 GigE ports over Copper and have the option to add SFP's if need
>>     
> be
>   
>> to
>> go to fiber.  If I need more GigE ports in this Chassis are the only
>> options
>> to add a PA-GE?  I read where a PA-GE will not support the copper
>>     
> gigabit?
>   
>> Joe
>>
>>
>> _______________________________________________
>> cisco-nsp mailing 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 brian at bluecoat93.org  Mon Mar  2 19:30:47 2009
From: brian at bluecoat93.org (Brian Landers)
Date: Mon, 2 Mar 2009 19:30:47 -0500
Subject: [c-nsp] SNMP MIB for IP SLA on Pix/ASA 7.x?
Message-ID: <689ea7e40903021630x12b916c7s35b16928b0519046@mail.gmail.com>

Does anyone know if the Pix/ASA has support for polling IP SLA monitor
status in the 7.x (or even 8.x) OS?  It don't seem to support the standard
RTTMON-MIB like IOS does.

Thanks,
Brian


-- 
Brian C Landers
http://www.packetslave.com/
CCIE #23115

From leonardo.souza at nec.com.br  Mon Mar  2 20:08:57 2009
From: leonardo.souza at nec.com.br (Leonardo Gama Souza)
Date: Mon, 2 Mar 2009 22:08:57 -0300
Subject: [c-nsp] Export routes from VRF to the global routing table
Message-ID: <9E07F8717FE8BC4FBAE6860F61EA6C1D02124E6C@spsrvmail03.nec.br>

Hi list,

I am almost confident this is not possible, but would like to confirm
whether exporting routes from some VRF to the global routing table is
possible or not.
This would be a solution to overcome the constraints of using PBR+GRE
setup.

Thanks in advance.

From gustavo at nexthop.com.br  Mon Mar  2 20:30:20 2009
From: gustavo at nexthop.com.br (Gustavo Rodrigues Ramos)
Date: Mon, 2 Mar 2009 22:30:20 -0300
Subject: [c-nsp] Export routes from VRF to the global routing table
In-Reply-To: <9E07F8717FE8BC4FBAE6860F61EA6C1D02124E6C@spsrvmail03.nec.br>
References: <9E07F8717FE8BC4FBAE6860F61EA6C1D02124E6C@spsrvmail03.nec.br>
Message-ID: <73d1f88a0903021730j267a1cc5q1d71df107bc2b050@mail.gmail.com>

Hello Leonardo, I guess you'll use route leaking to accomplish what you want.

http://www.cisco.com/en/US/tech/tk436/tk832/technologies_configuration_example09186a0080231a3e.shtml

Gustavo.



On Mon, Mar 2, 2009 at 10:08 PM, Leonardo Gama Souza
<leonardo.souza at nec.com.br> wrote:
> Hi list,
>
> I am almost confident this is not possible, but would like to confirm
> whether exporting routes from some VRF to the global routing table is
> possible or not.
> This would be a solution to overcome the constraints of using PBR+GRE
> setup.
>
> 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 David at Hughes.com.au  Mon Mar  2 20:33:35 2009
From: David at Hughes.com.au (David Hughes)
Date: Tue, 3 Mar 2009 11:33:35 +1000
Subject: [c-nsp] 7206 Gig Ethernet Options
In-Reply-To: <01c301c99b72$09866730$1c933590$@net>
References: <389E7FA0-2001-4038-B225-D4B6C003B593@Princeton.EDU>
	<037901c995ec$4ba3db60$e2eb9220$@net>
	<01c301c99b72$09866730$1c933590$@net>
Message-ID: <C13A6DD2-417F-499F-9985-C0D94220C655@Hughes.com.au>



On 03/03/2009, at 6:04 AM, Rhino Lists wrote:

> If I need more GigE ports in this Chassis are the only options
> to add a PA-GE?  I read where a PA-GE will not support the copper  
> gigabit?

Hi

Nope, that's not correct.  We've run copper gbics in a pa-ge on 7206- 
VXR / NPE-G1 before.



David
...

From ccie6961 at yahoo.com  Tue Mar  3 00:12:53 2009
From: ccie6961 at yahoo.com (Yinglam Cheung)
Date: Mon, 2 Mar 2009 21:12:53 -0800 (PST)
Subject: [c-nsp] ipsec support on 7600
References: <a89d89ac0902271002x3ca63607y9c1575e843609e26@mail.gmail.com>
Message-ID: <405404.85822.qm@web52706.mail.re2.yahoo.com>


The answer is no. I just got into this recently. The software crypto feature is in SXF but no longer in SR releases.

You need to get the IPSec module for hardware crypto.



----- Original Message ----
From: Marlon Duksa <mduksa at gmail.com>
To: "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>
Sent: Saturday, February 28, 2009 2:02:57 AM
Subject: [c-nsp] ipsec support on 7600

Hi - does anyone know if Cisco 7600 can support IPSec only with RSPs and
ES20 cards? No additional hardware service modules such as IPSec VPN
modules. If so, I presume the processing of IPSec would take place in MSFC?I
understand that performance would be severely impacted without the HW
acceleration module, I just need to know if this is supported? And also
maybe what would be the performance in this case?
Thanks,
Marlon
_______________________________________________
cisco-nsp mailing list  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  Tue Mar  3 02:09:59 2009
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Tue, 3 Mar 2009 08:09:59 +0100 (CET)
Subject: [c-nsp] 7206 Gig Ethernet Options
In-Reply-To: <C13A6DD2-417F-499F-9985-C0D94220C655@Hughes.com.au>
References: <389E7FA0-2001-4038-B225-D4B6C003B593@Princeton.EDU>
	<037901c995ec$4ba3db60$e2eb9220$@net>
	<01c301c99b72$09866730$1c933590$@net>
	<C13A6DD2-417F-499F-9985-C0D94220C655@Hughes.com.au>
Message-ID: <alpine.DEB.1.10.0903030808510.30683@uplift.swm.pp.se>

On Tue, 3 Mar 2009, David Hughes wrote:

> Nope, that's not correct.  We've run copper gbics in a pa-ge on 7206-VXR 
> / NPE-G1 before.

There is a difference between "it works" and "it's supported". Cisco do 
not support copper GBICs in the PA-GE, but there are lots of success 
stories that it still works (plenty of old threads regarding this).

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

From vdv at co.ru  Tue Mar  3 02:08:15 2009
From: vdv at co.ru (Dmitry V. Volkov)
Date: Tue, 3 Mar 2009 10:08:15 +0300
Subject: [c-nsp] TE FRR via CSC
Message-ID: <1de701c99bce$d2acad70$1e3843c2@sovintel.net>

Hi All,

Does anyone have experience organizing TE FRR via CSC? Customer network is VOIP operator and they would like organize fast
convergence via CSC connection.

Dmitry


From perc69 at gmail.com  Tue Mar  3 03:25:46 2009
From: perc69 at gmail.com (Pelle)
Date: Tue, 3 Mar 2009 09:25:46 +0100
Subject: [c-nsp] 7206 Gig Ethernet Options
In-Reply-To: <01c301c99b72$09866730$1c933590$@net>
References: <389E7FA0-2001-4038-B225-D4B6C003B593@Princeton.EDU>
	<037901c995ec$4ba3db60$e2eb9220$@net>
	<01c301c99b72$09866730$1c933590$@net>
Message-ID: <746ca6da0903030025v5eca9fefp37234e2024763bcc@mail.gmail.com>

Hi.

> If I need more GigE ports in this Chassis are the only options
> to add a PA-GE? ?I read where a PA-GE will not support the copper gigabit?

You also have the option to use an external switch to aggregate
several GE links into the 7200. Of course do that limit the bandwidth
to the locations, but a 7200 will probably not do 3 x GE on full speed
any way... IMHO that's a better/safer solution than fiddeling with
unsupported combinations on PA-GE/GBICs.

--
Pelle

From md at bts.sk  Tue Mar  3 04:13:28 2009
From: md at bts.sk (Marian =?utf-8?B?xI51cmtvdmnEjQ==?=)
Date: Tue, 3 Mar 2009 10:13:28 +0100
Subject: [c-nsp] Cat3560E - insufficient buffers for microbursts?
In-Reply-To: <20090302.104126.74722994.sthaug@nethelp.no>
References: <20090302082922.GA35030@bts.sk>
	<20090302.104126.74722994.sthaug@nethelp.no>
Message-ID: <20090303091328.GA81897@bts.sk>

On Mon, Mar 02, 2009 at 10:41:26AM +0100, sthaug at nethelp.no wrote:
> >   Closer investigation showed, that for some reason, Cat3560E is doing
> > significantly less output buffering than all other Cisco access switches.
> > While Cat2960G, Cat3550, Cat3560G and Cat3750G happily buffer any
> > microburst upto 100 full size (1500 byte) packets, Cat3560E only buffers
> > upto 64 full size packets and starts dropping beginning with 65-th packet.
> > This was rather bad surprise, since the Cat3560E is supposed to have
> > 10GE uplinks - and with 10:1 or 100:1 speed downshift from uplink into
> > access ports decent buffering is vital for proper operation.
> 
> We experienced the same problem with ME3400 switches. It has extremely
> small buffers by default - the queue size is in units of 256 byte, and
> default queue size is only 48 of these. We got around this by configuring
> shaping (which is possible on the ME3400) and setting queue-limit 256 in
> the policy-map. The problem seems to be resolved in 12.2(46), note the
> following point from the release notes:
> 
> > CSCsm80634 
> >
> > The default queue limit for QoS has been changed from 48 to 160
> > (256-byte) packets.
> 
> I wouldn't be surprised if 3560E has similar behavior (but I haven't
> checked).

Yes, looks like it's indeed wrong IOS defaults. More buffering could be
achieved on 3560-E by enabling qos, and increasing the thresholds:

mls qos
mls qos queue-set output 1 threshold 2 1400 1400 100 1400

This restores the ability to buffer 100 full-size packets on 3560-E.

Anyway, there doesn't seem to be any CLI knob to tune this when qos is 
disabled and the default buffer size (64 full-size packets) is too small.
We do not want to enable qos, as it most probably reserves some packet
memory for unused queues and lowers total available buffer space.


    With kind regards,

        M.

From jcovini at free.fr  Tue Mar  3 05:39:06 2009
From: jcovini at free.fr (jcovini at free.fr)
Date: Tue, 03 Mar 2009 11:39:06 +0100
Subject: [c-nsp] 3560 vrf unwanted leaking when using tracked static
	route
Message-ID: <1236076746.49ad08ca07b54@imp.free.fr>

Fixed in 12.2.46 :)

>>> The problem you noticed is documented under the following bug ID:
>>> CSCsl31925
>>> Externally found moderate defect: Duplicate (D)
>>> Static routes using VRF object tracking not working . .
>>> It eventually was found to be due to bug:
>>> CSCsf25288

From deric.kwok2000 at gmail.com  Tue Mar  3 08:01:42 2009
From: deric.kwok2000 at gmail.com (Deric Kwok)
Date: Tue, 3 Mar 2009 08:01:42 -0500
Subject: [c-nsp] Can I post the network question here?
Message-ID: <40d8a95a0903030501r5b306c53x1b2e3c127012de32@mail.gmail.com>

Hi all

I have network question and hope you can help

main router- 3 static routes
ip route 192.168.0.0/24   10.0.0.1 (routerA) ----
ip route 192.168.1.0/24   10.0.0.2 (routerB) ----same switch ---telecom
company---client request
ip route 192.168.2.0/24   10.0.0.3 (routerC) ----

Diagram
=======
                              ---routerA---
main router ---switch ---routerB--- switch ---telecom company
                              ---routerC---
dyname ip clients ip 192.168.0.0/24 and 192.168.1.0/24
static ip clients ip 192.168.2.0/24
This setting is fine when any dynamic ip clients sent from telcom company.
But When telecom company sent request from static ip client
(any ip in 192.168.2.0/24) but this client is sent to in routerA,
how this work out?
I really don't want to have 192.168.2.0 in routerC to routerB then routerA
in loop
as there will have big admin work if there is more than 3 routers and have
increase
new static ip client for the future
Thank you for your help

From leonardo.souza at nec.com.br  Tue Mar  3 08:11:38 2009
From: leonardo.souza at nec.com.br (Leonardo Gama Souza)
Date: Tue, 3 Mar 2009 10:11:38 -0300
Subject: [c-nsp] Export routes from VRF to the global routing table
References: <9E07F8717FE8BC4FBAE6860F61EA6C1D02124E6C@spsrvmail03.nec.br>
	<73d1f88a0903021730j267a1cc5q1d71df107bc2b050@mail.gmail.com>
Message-ID: <9E07F8717FE8BC4FBAE6860F61EA6C1D7E0E9C@spsrvmail03.nec.br>

Hi Gustavo,
 
Thanks for the feedback, but I would like to dynamically export the routes, not using static routing. 
 
Regards.

 
________________________________

From: Gustavo Rodrigues Ramos [mailto:gustavo at nexthop.com.br]
Sent: Mon 3/2/2009 22:30
To: Leonardo Gama Souza
Cc: cisco-nsp
Subject: Re: [c-nsp] Export routes from VRF to the global routing table



Hello Leonardo, I guess you'll use route leaking to accomplish what you want.

http://www.cisco.com/en/US/tech/tk436/tk832/technologies_configuration_example09186a0080231a3e.shtml

Gustavo.



On Mon, Mar 2, 2009 at 10:08 PM, Leonardo Gama Souza
<leonardo.souza at nec.com.br> wrote:
> Hi list,
>
> I am almost confident this is not possible, but would like to confirm
> whether exporting routes from some VRF to the global routing table is
> possible or not.
> This would be a solution to overcome the constraints of using PBR+GRE
> setup.
>
> 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 deric.kwok2000 at gmail.com  Tue Mar  3 08:21:41 2009
From: deric.kwok2000 at gmail.com (Deric Kwok)
Date: Tue, 3 Mar 2009 08:21:41 -0500
Subject: [c-nsp] how can I know which process takes over CPU and memory?
In-Reply-To: <002a01c999df$97fa2680$0a00000a@nil.si>
References: <40d8a95a0902280959q7c5abfb4j8b5def5adfe4a097@mail.gmail.com>
	<002a01c999df$97fa2680$0a00000a@nil.si>
Message-ID: <40d8a95a0903030521s670b04e2x8f8e139339a0dd2f@mail.gmail.com>

Hi Ivan

Thank you. I try to do it in my switch but it won't work

What wrong I did?

Thank you

switch#dir
Directory of flash:/
  4  drwx         704   Feb 28 1993 19:08:20  html
 18  -rwx        1142   Mar 03 2009 08:14:33  top.tcl
3612672 bytes total (357888 bytes free)
switch#config terminal
Enter configuration commands, one per line.  End with CNTL/Z.
switch(config)#alias exec top tclsh flash:top.tcl
switch(config)#exit
switch#top
tclsh flash:top.tcl
 ^
% Invalid input detected at '^' marker.
switch#




On Sat, Feb 28, 2009 at 3:03 PM, Ivan Pepelnjak <ip at ioshints.info> wrote:

> To get the top CPU consumers, use the "show proc cpu sorted" command.
> You're
> probably experiencing increase in "interrupt CPU usage" (packet
> forwarding),
> which is the second number in the "CPU utilization for five seconds" field
> in the top line.
>
> To get continuous CPU utilization display (similar to the Unix "top"
> command), use this Tclsh script:
>
> http://wiki.nil.com/Continuous_display_of_top_CPU_processes
>
> Ivan
>
> http://www.ioshints.info/about
> http://blog.ioshints.info/
>
>
> > -----Original Message-----
> > From: Deric Kwok [mailto:deric.kwok2000 at gmail.com]
> > Sent: Saturday, February 28, 2009 6:59 PM
> > To: cisco-nsp at puck.nether.net
> > Subject: [c-nsp] how can I know which process takes over CPU
> > and memory?
> >
> > Hi All
> >
> > I am trying to add access rule to prevent outside accessing
> > to one host.
> >
> > I realize the router CPU (R700 CPU at 240MHz) graph rising
> > from 70% to 80%
> >
> > How can I know which process used up how many CPU and memory?
> >
> > I use show memory but don't understand the listing
> >
> > Thank you for your help
> >
> >
>
>

From drew.weaver at thenap.com  Tue Mar  3 08:37:21 2009
From: drew.weaver at thenap.com (Drew Weaver)
Date: Tue, 3 Mar 2009 05:37:21 -0800
Subject: [c-nsp] SNMP fun
Message-ID: <F3318834F1F89D46857972DD4B411D7005155503@EXCHANGE.thenap.com>

Does anyone know if it is possible even roundaboutly to figure out what physical port a MAC address is connected to even if that port is in a VLAN? I can find the mac -> IP pair and I can find out what ports are assigned to the VLAN, but it would be super swell if I could also figure out what port => what IP/Mac address.

I believe you can do this in the CAM table on the switches but I'm not really sure how to do it in SNMP

Thanks,
-Drew


From schilling2006 at gmail.com  Tue Mar  3 08:41:57 2009
From: schilling2006 at gmail.com (schilling)
Date: Tue, 3 Mar 2009 08:41:57 -0500
Subject: [c-nsp] Export routes from VRF to the global routing table
In-Reply-To: <9E07F8717FE8BC4FBAE6860F61EA6C1D02124E6C@spsrvmail03.nec.br>
References: <9E07F8717FE8BC4FBAE6860F61EA6C1D02124E6C@spsrvmail03.nec.br>
Message-ID: <bd3771a60903030541x7e09760ahdb9d520cbb8dedda@mail.gmail.com>

If you have loopback cable on the same router, or vlan between two different
routers, you could potentially run a IGP routing protocol for example ospf
on the same network while using different context/process on each end to
exchange routes.


Schilling








On Mon, Mar 2, 2009 at 8:08 PM, Leonardo Gama Souza <
leonardo.souza at nec.com.br> wrote:

> Hi list,
>
> I am almost confident this is not possible, but would like to confirm
> whether exporting routes from some VRF to the global routing table is
> possible or not.
> This would be a solution to overcome the constraints of using PBR+GRE
> setup.
>
> 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 blahu77 at gmail.com  Tue Mar  3 08:43:42 2009
From: blahu77 at gmail.com (Mateusz Blaszczyk)
Date: Tue, 3 Mar 2009 13:43:42 +0000
Subject: [c-nsp] SNMP fun
In-Reply-To: <F3318834F1F89D46857972DD4B411D7005155503@EXCHANGE.thenap.com>
References: <F3318834F1F89D46857972DD4B411D7005155503@EXCHANGE.thenap.com>
Message-ID: <383357750903030543o788adc64t88579177e83fb554@mail.gmail.com>

2009/3/3 Drew Weaver <drew.weaver at thenap.com>:
> Does anyone know if it is possible even roundaboutly to figure out what physical port a MAC address is connected to even if that port is in a VLAN? I can find the mac -> IP pair and I can find out what ports are assigned to the VLAN, but it would be super swell if I could also figure out what port => what IP/Mac address.
>
> I believe you can do this in the CAM table on the switches but I'm not really sure how to do it in SNMP
>

try that

http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a00801c9199.shtml

-mat
-- 
pgp-key 0x1C655CAB

From jcovini at free.fr  Tue Mar  3 09:30:24 2009
From: jcovini at free.fr (jcovini at free.fr)
Date: Tue, 03 Mar 2009 15:30:24 +0100
Subject: [c-nsp] Can I post the network question here?
In-Reply-To: <40d8a95a0903030501r5b306c53x1b2e3c127012de32@mail.gmail.com>
References: <40d8a95a0903030501r5b306c53x1b2e3c127012de32@mail.gmail.com>
Message-ID: <1236090624.49ad3f00c160f@imp.free.fr>

Why not running a dynamic routing protocol between Main, A, B, and C. ?
Static routes = manual maintenance.


Selon Deric Kwok <deric.kwok2000 at gmail.com>:

> Hi all
>
> I have network question and hope you can help
>
> main router- 3 static routes
> ip route 192.168.0.0/24   10.0.0.1 (routerA) ----
> ip route 192.168.1.0/24   10.0.0.2 (routerB) ----same switch ---telecom
> company---client request
> ip route 192.168.2.0/24   10.0.0.3 (routerC) ----
>
> Diagram
> =======
>                               ---routerA---
> main router ---switch ---routerB--- switch ---telecom company
>                               ---routerC---
> dyname ip clients ip 192.168.0.0/24 and 192.168.1.0/24
> static ip clients ip 192.168.2.0/24
> This setting is fine when any dynamic ip clients sent from telcom company.
> But When telecom company sent request from static ip client
> (any ip in 192.168.2.0/24) but this client is sent to in routerA,
> how this work out?
> I really don't want to have 192.168.2.0 in routerC to routerB then routerA
> in loop
> as there will have big admin work if there is more than 3 routers and have
> increase
> new static ip client for the future
> Thank you for your help
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>



From oboehmer at cisco.com  Tue Mar  3 10:53:34 2009
From: oboehmer at cisco.com (Oliver Boehmer (oboehmer))
Date: Tue, 3 Mar 2009 16:53:34 +0100
Subject: [c-nsp] TE FRR via CSC
In-Reply-To: <1de701c99bce$d2acad70$1e3843c2@sovintel.net>
References: <1de701c99bce$d2acad70$1e3843c2@sovintel.net>
Message-ID: <70B7A1CCBFA5C649BD562B6D9F7ED78406FA51A3@xmb-ams-333.emea.cisco.com>

Dmitry V. Volkov <> wrote on Tuesday, March 03, 2009 08:08:

> Hi All,
> 
> Does anyone have experience organizing TE FRR via CSC? Customer
> network is VOIP operator and they would like organize fast
> convergence via CSC connection. 

Don't see how this can be done at the moment. You can investigate
Inter-AS MPLS-TE (and moving to PCE in the future), but this generally
requires an Inter-AS setup, rather than CSC. 

General note: TE-FRR is generally not required for Voice, fast
convergence (sub-second) is generally sufficient.. 

Your challenge could be L3VPN convergence (CSC is using regular L3VPN
mechanisms within the carrier's AS), so your convergence will depend on
what the customer is providing. A L2VPN setup (where you could run
BFD-triggered FRR over the L2VPN circuit) might be better if you strive
for reliable sub-500msec convergence or so..

	oli

From jason at pins.net  Tue Mar  3 10:52:25 2009
From: jason at pins.net (Jason Berenson)
Date: Tue, 03 Mar 2009 10:52:25 -0500
Subject: [c-nsp] OSPF flaps
Message-ID: <49AD5239.9010906@pins.net>

Greetings,

I'm seeing a weird OSPF flap issue between a bunch of 7206's and a 
6513.  We're running fast OSPF between them all.  Here's some sample config:

7206:

router ospf 1
 router-id 0.0.1.10
 log-adjacency-changes
 area 0 authentication
 redistribute connected metric-type 1 subnets
 redistribute static metric-type 1 subnets
 redistribute bgp 65010 metric-type 1 subnets route-map global
 network 10.11.1.0 0.0.0.255 area 0
 network 10.12.1.0 0.0.0.255 area 0
!
interface GigabitEthernet0/2
des primary net
 ip address 10.11.1.10 255.255.255.0
 no ip redirects
 ip route-cache flow
 ip ospf authentication-key 7
 ip ospf cost 1
 ip ospf dead-interval minimal hello-multiplier 4
 duplex auto
 speed auto
 media-type rj45
 no negotiation auto


6513:

router ospf 1
 router-id 0.0.1.24
 log-adjacency-changes
 no capability lls
 area 0 authentication
 passive-interface default
 network 10.11.1.0 0.0.0.255 area 0
 network 10.12.1.0 0.0.0.255 area 0
!
interface GigabitEthernet9/1
 no ip address
 speed 1000
 duplex full
 switchport
 switchport access vlan 11
 switchport mode access
!
interface Vlan11
 description << PRIMARY NET >>
 ip address 10.11.1.24 255.255.255.0
 no ip redirects
 no ip mroute-cache
 ip ospf authentication-key 7
 ip ospf cost 1
 ip ospf dead-interval minimal hello-multiplier 4
!


There is IP connectivity between the two routers of course.  We leave 
all ints as passive by default and turn on each int as we need them to 
speak OSPF.  When I turn on vlan 11 as non passive, things come up then 
start flapping very rapidly at which point the 6513 becomes completely 
unresponsive.  Here's some output from the 7206's logs:

Mar  2 19:07:07 pri.core.router1 37224: Mar  2 19:07:04: %OSPF-5-ADJCHG: 
Process 1, Nbr 0.0.1.24 on GigabitEthernet0/2 from 2WAY to DOWN, 
Neighbor Down: Dead timer expired
Mar  2 19:07:07 pri.core.router2 2556211: Mar  2 19:07:04: 
%OSPF-5-ADJCHG: Process 1, Nbr 0.0.1.24 on GigabitEthernet0/2 from 2WAY 
to DOWN, Neighbor Down: Dead timer expired

The timers are matched up on all the routers, and there's of course no 
packet loss.  I don't see why the dead timers are expiring causing this 
to keep flapping.  Any input would be greatly appreciated.

Thanks,
Jason

From asturluismi at gmail.com  Tue Mar  3 12:01:32 2009
From: asturluismi at gmail.com (luismi)
Date: Tue, 03 Mar 2009 18:01:32 +0100
Subject: [c-nsp] strange message at boot "Can't insert config node for
	vrf=default"
Message-ID: <1236099692.10233.1.camel@dsba-ipso>

Hi all,

I have here a 2960 switch with 12.2(46) lan base.
After the switche has booted correctly I can see..

[...]
% Can't insert config node for vrf=default


Press RETURN to get started!

What is the reason for the message "Can't insert config node for
vrf=default"?

Any idea?

Thanks


From jared at puck.nether.net  Tue Mar  3 12:13:45 2009
From: jared at puck.nether.net (Jared Mauch)
Date: Tue, 3 Mar 2009 12:13:45 -0500
Subject: [c-nsp] strange message at boot "Can't insert config node
	for	vrf=default"
In-Reply-To: <1236099692.10233.1.camel@dsba-ipso>
References: <1236099692.10233.1.camel@dsba-ipso>
Message-ID: <20090303171345.GB11502@puck.nether.net>

On Tue, Mar 03, 2009 at 06:01:32PM +0100, luismi wrote:
> Hi all,
> 
> I have here a 2960 switch with 12.2(46) lan base.
> After the switche has booted correctly I can see..
> 
> [...]
> % Can't insert config node for vrf=default
> 
> 
> Press RETURN to get started!
> 
> What is the reason for the message "Can't insert config node for
> vrf=default"?

	cisco doesn't do effective testing of the boot-up mode of the device so
does not notice these types of things, and when they are noticed they are logged
as sev5 or sev6 defects since they are not seen as critical.

	there is also the problem that the parser operates in two modes, one
for processing the config at boot-time, and another for processing the config
at runtime.  This is why it will translate some older-style configuration bits
but you can no longer enter them.

	Without knowing your full config, it's hard to say what caused the above,
but if everything is working fine, or you are not using VRFs it's likely cosmetic.
I do encourage you to ask cisco to fix the defect, but don't expect it to be
quickly resolved.

-- 
Jared Mauch  | pgp key available via finger from jared at puck.nether.net
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.

From asturluismi at gmail.com  Tue Mar  3 12:28:55 2009
From: asturluismi at gmail.com (luismi)
Date: Tue, 03 Mar 2009 18:28:55 +0100
Subject: [c-nsp] strange message at boot "Can't insert config node
	for	vrf=default"
In-Reply-To: <20090303171345.GB11502@puck.nether.net>
References: <1236099692.10233.1.camel@dsba-ipso>
	<20090303171345.GB11502@puck.nether.net>
Message-ID: <1236101335.10233.4.camel@dsba-ipso>

So if I understand everything correctly, it is a cosmetic bug during the
boot.
I will notify it to Cisco.
It shouldn't be related with my previous config since I don't have any
command related with "node", "vrf" or similar words related with the
message -I think-.


El mar, 03-03-2009 a las 12:13 -0500, Jared Mauch escribi?:
> On Tue, Mar 03, 2009 at 06:01:32PM +0100, luismi wrote:
> > Hi all,
> > 
> > I have here a 2960 switch with 12.2(46) lan base.
> > After the switche has booted correctly I can see..
> > 
> > [...]
> > % Can't insert config node for vrf=default
> > 
> > 
> > Press RETURN to get started!
> > 
> > What is the reason for the message "Can't insert config node for
> > vrf=default"?
> 
> 	cisco doesn't do effective testing of the boot-up mode of the device so
> does not notice these types of things, and when they are noticed they are logged
> as sev5 or sev6 defects since they are not seen as critical.
> 
> 	there is also the problem that the parser operates in two modes, one
> for processing the config at boot-time, and another for processing the config
> at runtime.  This is why it will translate some older-style configuration bits
> but you can no longer enter them.
> 
> 	Without knowing your full config, it's hard to say what caused the above,
> but if everything is working fine, or you are not using VRFs it's likely cosmetic.
> I do encourage you to ask cisco to fix the defect, but don't expect it to be
> quickly resolved.
> 


From jp at saucer.midcoast.com  Tue Mar  3 12:50:04 2009
From: jp at saucer.midcoast.com (jp)
Date: Tue, 3 Mar 2009 12:50:04 -0500
Subject: [c-nsp] Verizon's PIP service
In-Reply-To: <49AC534B.8010809@chrisserafin.com>
References: <BLU105-W204299E47DC1F7EA2F3F0A7A90@phx.gbl>
	<49AC534B.8010809@chrisserafin.com>
Message-ID: <20090303175004.GA10877@saucer.midcoast.com>

No company owns all the infrastructure to get around the world.

For example the undersea cables are commonly investor owned, installed 
by one company, maintained by another, and used by a variety of 
carriers. Things like the FLAG or SEA-* cables. Surely not the case 
here, but AT&T either did or does a lot of the ship-based 
repair/construction work on undersea cables, and has a fleet of ships 
around the world waiting for a problem to respond to. Probably differnet 
companies are incharge of things on land too.

On Mon, Mar 02, 2009 at 03:44:43PM -0600, ChrisSerafin wrote:
> I know for a fact that Verizon doesn't control everything end to end. I 
> have a decent sized client with circuits all over EMEA, and I always hear, 
> 'ooh that's referred out to AT&T/xxxx for testing'
>
> This may be only the last mile of the circuit though.
>
> just my 2 cents
>
> --chris
>
> D W wrote:
>> Anyone happen to know if Verizon relies on any 3rd party service providers (using inter-AS MP-BGP, ATOM, etc.) for their PIP (MPLS based private IP) service? I'm trying to figure out which service providers have a national reach and fully contain/control their own MPLS clouds without relying on one another for transport.
>>
>>  
>> Thanks,
>>
>> Dave
>>
>> _________________________________________________________________
>> Windows Live?: Life without walls.
>> http://windowslive.com/explore?ocid=TXT_TAGLM_WL_allup_1a_explore_032009
>> _______________________________________________
>> cisco-nsp mailing 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.0.237 / Virus Database: 
>> 270.11.5/1979 - Release Date: 03/01/09 17:46:00
>>
>>   
>
> _______________________________________________
> cisco-nsp mailing 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 ip at ioshints.info  Tue Mar  3 14:03:02 2009
From: ip at ioshints.info (Ivan Pepelnjak)
Date: Tue, 3 Mar 2009 20:03:02 +0100
Subject: [c-nsp] how can I know which process takes over CPU and memory?
In-Reply-To: <40d8a95a0903030521s670b04e2x8f8e139339a0dd2f@mail.gmail.com>
References: <40d8a95a0902280959q7c5abfb4j8b5def5adfe4a097@mail.gmail.com>
	<002a01c999df$97fa2680$0a00000a@nil.si>
	<40d8a95a0903030521s670b04e2x8f8e139339a0dd2f@mail.gmail.com>
Message-ID: <002501c99c32$ade84cb0$0a00000a@nil.si>

Your original message indicated you had a router. Based on Cisco's
documentation tclsh doesn't work on most Catalyst switches.
 
Best regards
Ivan


  _____  

From: Deric Kwok [mailto:deric.kwok2000 at gmail.com] 
Sent: Tuesday, March 03, 2009 2:22 PM
To: Ivan Pepelnjak
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] how can I know which process takes over CPU and memory?


Hi Ivan
 
Thank you. I try to do it in my switch but it won't work
 
What wrong I did?
 
Thank you

switch#dir
Directory of flash:/
  4  drwx         704   Feb 28 1993 19:08:20  html
 18  -rwx        1142   Mar 03 2009 08:14:33  top.tcl
3612672 bytes total (357888 bytes free)
switch#config terminal
Enter configuration commands, one per line.  End with CNTL/Z.
switch(config)#alias exec top tclsh flash:top.tcl
switch(config)#exit
switch#top
tclsh flash:top.tcl
 ^
% Invalid input detected at '^' marker.
switch#


From jeff-kell at utc.edu  Tue Mar  3 14:09:14 2009
From: jeff-kell at utc.edu (Jeff Kell)
Date: Tue, 03 Mar 2009 14:09:14 -0500
Subject: [c-nsp] how can I know which process takes over CPU and memory?
In-Reply-To: <002501c99c32$ade84cb0$0a00000a@nil.si>
References: <40d8a95a0902280959q7c5abfb4j8b5def5adfe4a097@mail.gmail.com>	<002a01c999df$97fa2680$0a00000a@nil.si>	<40d8a95a0903030521s670b04e2x8f8e139339a0dd2f@mail.gmail.com>
	<002501c99c32$ade84cb0$0a00000a@nil.si>
Message-ID: <49AD805A.8010608@utc.edu>

Ivan Pepelnjak wrote:
> Your original message indicated you had a router. Based on Cisco's
> documentation tclsh doesn't work on most Catalyst switches.

They do have their pride, after all :-)

Jeff

From kevin at gannons.net  Tue Mar  3 15:25:27 2009
From: kevin at gannons.net (kevin gannon)
Date: Tue, 3 Mar 2009 20:25:27 +0000
Subject: [c-nsp] mpls bgp forwarding ?
Message-ID: <17eef0950903031225m561003d3j302e7b6f4694ca3a@mail.gmail.com>

Having a strange problem with IPv4 and send-label. The topology is the
below. I originate 100.100.100.16
from AS16 and it reaches AS19.

R16-------eBGP+send-label----------R17-------IGP
BGP+send-label-----R18---------eBGP send-label--------R19
AS16
AS17
AS17                                              AS19
100.100.100.16



On R18 I see the label installed for 100.100.100.16

R18#show mpls for
Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop
Label  Label or VC   or Tunnel Id      Switched      interface
16     Pop Label     189.189.189.9/32  0             Fa1/1
189.189.189.9
17     Pop Label     100.100.100.17/32 0             Fa1/0
178.178.178.7
18     20            100.100.100.16/32 0             Fa1/0
178.178.178.7
19     Pop Label     100.100.100.19/32 0             Fa1/1
189.189.189.9


show ip bgp 100.100.100.16
BGP routing table entry for 100.100.100.16/32, version 2
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Advertised to update-groups:
     2
  16
    100.100.100.17 (metric 2) from 100.100.100.17 (100.100.100.17)
      Origin IGP, metric 0, localpref 100, valid, internal, best,
      mpls labels in/out 18/20
R18(config)#


However on R19 I receive the label via eBGP. However I do not install into
the
MPLS forwarding table but I do not know why ??

R19#show ip bgp 100.100.100.16
BGP routing table entry for 100.100.100.16/32, version 7
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Not advertised to any peer
  17 16
    189.189.189.8 from 189.189.189.8 (100.100.100.18)
      Origin IGP, localpref 100, valid, external, best,
      mpls labels in/out nolabel/18


R19#
R19#show mpls for
Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop
Label  Label or VC   or Tunnel Id      Switched      interface
16     Pop Label     189.189.189.8/32  0             Fa1/0
189.189.189.8

From deric.kwok2000 at gmail.com  Tue Mar  3 15:26:16 2009
From: deric.kwok2000 at gmail.com (Deric Kwok)
Date: Tue, 3 Mar 2009 15:26:16 -0500
Subject: [c-nsp] how can I know which process takes over CPU and memory?
In-Reply-To: <002501c99c32$ade84cb0$0a00000a@nil.si>
References: <40d8a95a0902280959q7c5abfb4j8b5def5adfe4a097@mail.gmail.com>
	<002a01c999df$97fa2680$0a00000a@nil.si>
	<40d8a95a0903030521s670b04e2x8f8e139339a0dd2f@mail.gmail.com>
	<002501c99c32$ade84cb0$0a00000a@nil.si>
Message-ID: <40d8a95a0903031226o3d7a0592xdec2edfcdf1ee88a@mail.gmail.com>

Hi Ivan

Now I am trying on the router but it won't work also

What wrong I did?

Thank you


router#dir
Directory of flash:/
    1  -rw-     8624196   Mar 5 1993 00:05:02 +00:00  c3725-i-mz.123-6e.bin
    2  -rw-        1142   Mar 3 2009 15:05:26 +00:00  top.tcl
31936512 bytes total (23306240 bytes free)

router#config t
Enter configuration commands, one per line.  End with CNTL/Z.
router(config)#alias exec top tclsh flash:top.tcl
router(config)#exit
router#top
Translating "top"...domain server (202.64.2.36) (202.64.3.5)
Translating "top"...domain server (202.64.2.36) (202.64.3.5)
 (202.64.2.36) (202.64.3.5)% Unknown command or computer name, or unable to
find computer address


On Tue, Mar 3, 2009 at 2:03 PM, Ivan Pepelnjak <ip at ioshints.info> wrote:

>  Your original message indicated you had a router. Based on Cisco's
> documentation tclsh doesn't work on most Catalyst switches.
>
> Best regards
> Ivan
>
>  ------------------------------
>  *From:* Deric Kwok [mailto:deric.kwok2000 at gmail.com]
> *Sent:* Tuesday, March 03, 2009 2:22 PM
> *To:* Ivan Pepelnjak
> *Cc:* cisco-nsp at puck.nether.net
> *Subject:* Re: [c-nsp] how can I know which process takes over CPU and
> memory?
>
>  Hi Ivan
>
> Thank you. I try to do it in my switch but it won't work
>
> What wrong I did?
>
> Thank you
>
> switch#dir
> Directory of flash:/
>   4  drwx         704   Feb 28 1993 19:08:20  html
>  18  -rwx        1142   Mar 03 2009 08:14:33  top.tcl
> 3612672 bytes total (357888 bytes free)
> switch#config terminal
> Enter configuration commands, one per line.  End with CNTL/Z.
> switch(config)#alias exec top tclsh flash:top.tcl
> switch(config)#exit
> switch#top
> tclsh flash:top.tcl
>  ^
> % Invalid input detected at '^' marker.
> switch#
>
>

From ip at ioshints.info  Tue Mar  3 15:32:39 2009
From: ip at ioshints.info (Ivan Pepelnjak)
Date: Tue, 3 Mar 2009 21:32:39 +0100
Subject: [c-nsp] how can I know which process takes over CPU and memory?
In-Reply-To: <40d8a95a0903031226o3d7a0592xdec2edfcdf1ee88a@mail.gmail.com>
References: <40d8a95a0902280959q7c5abfb4j8b5def5adfe4a097@mail.gmail.com>
	<002a01c999df$97fa2680$0a00000a@nil.si>
	<40d8a95a0903030521s670b04e2x8f8e139339a0dd2f@mail.gmail.com>
	<002501c99c32$ade84cb0$0a00000a@nil.si>
	<40d8a95a0903031226o3d7a0592xdec2edfcdf1ee88a@mail.gmail.com>
Message-ID: <003001c99c3f$32e79400$0a00000a@nil.si>

Your IOS is too old, tclsh was introduced in 12.3(2)T. Cisco recommends
using at least 12.3(14)T; 12.4 might be even better.
 
http://www.cisco.com/en/US/docs/ios/12_3t/12_3t2/feature/guide/gt_tcl.html
 
If you want to know when a particular command (for example, tclsh) was
introduced in Cisco IOS, the Command Lookup Tool is a great place to start;
you can even install it in your browser's toolbar.
 
Best regards
Ivan


  _____  

From: Deric Kwok [mailto:deric.kwok2000 at gmail.com] 
Sent: Tuesday, March 03, 2009 9:26 PM
To: Ivan Pepelnjak
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] how can I know which process takes over CPU and memory?


Hi Ivan
 
Now I am trying on the router but it won't work also
 
What wrong I did?
 
Thank you
 

router#dir 
Directory of flash:/
    1  -rw-     8624196   Mar 5 1993 00:05:02 +00:00  c3725-i-mz.123-6e.bin
    2  -rw-        1142   Mar 3 2009 15:05:26 +00:00  top.tcl
31936512 bytes total (23306240 bytes free)

router#config t
Enter configuration commands, one per line.  End with CNTL/Z.
router(config)#alias exec top tclsh flash:top.tcl
router(config)#exit
router#top
Translating "top"...domain server (202.64.2.36) (202.64.3.5)
Translating "top"...domain server (202.64.2.36) (202.64.3.5)
 (202.64.2.36) (202.64.3.5)% Unknown command or computer name, or unable to
find computer address


From justin at justinshore.com  Tue Mar  3 16:38:20 2009
From: justin at justinshore.com (Justin Shore)
Date: Tue, 03 Mar 2009 15:38:20 -0600
Subject: [c-nsp] 7206 Gig Ethernet Options
In-Reply-To: <49AC6B47.9040805@sterling.net>
References: <389E7FA0-2001-4038-B225-D4B6C003B593@Princeton.EDU><037901c995ec$4ba3db60$e2eb9220$@net><01c301c99b72$09866730$1c933590$@net>	<6caa2aaf3999544c0ef807111b85a0c8.squirrel@webmail.waveform.net>	<1A9866F953006D45AEE0166066114E0915D78791@TPMAIL02.corp.theplatform.com>
	<49AC6B47.9040805@sterling.net>
Message-ID: <49ADA34C.7060309@justinshore.com>

Brandon Price wrote:
> Actually, you can install a C7200-I/O-GE+E and save yourself a PA slot 
> and the associated bandwidth point hit.
> 
> http://www.gossamer-threads.com/lists/cisco/bba/101247

Now that's something that I did not know.  Any word on if this is 
actually supported or not?

Justin

From Stig.Johansen at atea.no  Tue Mar  3 17:29:22 2009
From: Stig.Johansen at atea.no (Stig Johansen)
Date: Tue, 3 Mar 2009 23:29:22 +0100
Subject: [c-nsp] mpls bgp forwarding ?
In-Reply-To: <17eef0950903031225m561003d3j302e7b6f4694ca3a@mail.gmail.com>
References: <17eef0950903031225m561003d3j302e7b6f4694ca3a@mail.gmail.com>
Message-ID: <5EB9799F396A304686962AFFF740ED0CE96C400F@NOOSLEXCH001.adno.local>

 
Hi there,

>However on R19 I receive the label via eBGP. However I do not install into
>The MPLS forwarding table but I do not know why ??

You send the labels via BGP, but have you enabled LDP/TDP between R18 and R19? If not, it won't use any labels and consequently not install anything into the LFIB.

Regards,
Stig Meireles Johansen

From ddunkin at netos.net  Tue Mar  3 18:09:09 2009
From: ddunkin at netos.net (Darryl Dunkin)
Date: Tue, 3 Mar 2009 15:09:09 -0800
Subject: [c-nsp] mpls bgp forwarding ?
References: <17eef0950903031225m561003d3j302e7b6f4694ca3a@mail.gmail.com>
Message-ID: <56F5BC5F404CF84896C447397A1AAF20D499CC@MAIL.nosi.netos.com>

Do you have the VRF configured in your eBGP router?

If not, add this to your BGP configuration to keep it from filtering
those out:
no bgp default route-target filter

The prefixes will be filtered out if there is no local VRF to import to.

Some more details on this setup:
http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_e
xample09186a0080094472.shtml

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of kevin gannon
Sent: Tuesday, March 03, 2009 12:25
To: cisco-nsp
Subject: [c-nsp] mpls bgp forwarding ?

Having a strange problem with IPv4 and send-label. The topology is the
below. I originate 100.100.100.16
from AS16 and it reaches AS19.

R16-------eBGP+send-label----------R17-------IGP
BGP+send-label-----R18---------eBGP send-label--------R19
AS16
AS17
AS17                                              AS19
100.100.100.16



On R18 I see the label installed for 100.100.100.16

R18#show mpls for
Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop
Label  Label or VC   or Tunnel Id      Switched      interface
16     Pop Label     189.189.189.9/32  0             Fa1/1
189.189.189.9
17     Pop Label     100.100.100.17/32 0             Fa1/0
178.178.178.7
18     20            100.100.100.16/32 0             Fa1/0
178.178.178.7
19     Pop Label     100.100.100.19/32 0             Fa1/1
189.189.189.9


show ip bgp 100.100.100.16
BGP routing table entry for 100.100.100.16/32, version 2
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Advertised to update-groups:
     2
  16
    100.100.100.17 (metric 2) from 100.100.100.17 (100.100.100.17)
      Origin IGP, metric 0, localpref 100, valid, internal, best,
      mpls labels in/out 18/20
R18(config)#


However on R19 I receive the label via eBGP. However I do not install
into
the
MPLS forwarding table but I do not know why ??

R19#show ip bgp 100.100.100.16
BGP routing table entry for 100.100.100.16/32, version 7
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Not advertised to any peer
  17 16
    189.189.189.8 from 189.189.189.8 (100.100.100.18)
      Origin IGP, localpref 100, valid, external, best,
      mpls labels in/out nolabel/18


R19#
R19#show mpls for
Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop
Label  Label or VC   or Tunnel Id      Switched      interface
16     Pop Label     189.189.189.8/32  0             Fa1/0
189.189.189.8
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From lsawyer at gci.com  Tue Mar  3 20:19:58 2009
From: lsawyer at gci.com (Leif Sawyer)
Date: Tue, 3 Mar 2009 16:19:58 -0900
Subject: [c-nsp] FWSM and mixed IPv4/IPv6 access-list
In-Reply-To: <49A88BB5.8050901@bromirski.net>
Message-ID: <38D04BF3A4B7B2499D19EB1DB54285EA09E90498@FNB1EX01.gci.com>

Is anybody working with FWSM's and mixed-mode IPv4+IPv6 ACL's?

I'm having trouble with traceroute6 not succeeding, but ping6 working
fine:

access-list From_Internet extended permit udp any range 32768 65535
object-group NMS-HOSTS range 33434 33523 log
access-list From_Internet extended permit icmp any object-group
NMS-HOSTS log
!
access-list PERMIT_ANY extended permit ip any any log
!
ipv6 access-list V6_From_Internet permit udp any range 32768 65535
object-group V6-NMS-HOSTS range 33434 33523 log
ipv6 access-list V6_From_Internet permit icmp6 any object-group
V6-NMS-HOSTS log
!
ipv6 access-list V6_PERMIT_ANY permit ip any any log
!
! for testing, allow anything outbound...
!
access-group PERMIT_ANY in interface inside
access-group V6_PERMIT_ANY in interface inside
!
!
access-group From_Internet in interface outside
access-group V6_From_Internet in interface outside
!
ipv6 icmp permit any inside
ipv6 icmp permit any outside
icmp permit any inside
icmp permit any outside


object-group NMS-HOSTS :== V6-NMS-HOSTS   for the appropriate protocol.


I'm running FWSM  4.0(4)   on top of  12.2.33(SXI) on my 6509.


The above is cut verbatim, but slightly re-arranged.  telnet/ssh work
from
the inside-> outside as well.


here's the output from the FWSM.  First, the successful IPv4, then the
failed IPv6.
The source hosts and destination hosts are equivalent.

Mar  3 16:16:55 fwsm : %FWSM-6-106100: access-list PERMIT_ANY permitted
udp inside/192.168.1.127(60219) -> outside/192.168.3.1(33434) hit-cnt 1
(first hit) [0xd136324, 0x0]
Mar  3 16:16:55 fwsm : %FWSM-6-106100: access-list PERMIT_ANY permitted
udp inside/192.168.1.127(38690) -> outside/192.168.3.1(33435) hit-cnt 1
(first hit) [0xd136324, 0x0]
Mar  3 16:16:55 fwsm : %FWSM-6-106100: access-list PERMIT_ANY permitted
udp inside/192.168.1.127(60005) -> outside/192.168.3.1(33436) hit-cnt 1
(first hit) [0xd136324, 0x0]
Mar  3 16:16:55 fwsm : %FWSM-6-106100: access-list PERMIT_ANY permitted
udp inside/192.168.1.127(53862) -> outside/192.168.3.1(33437) hit-cnt 1
(first hit) [0xd136324, 0x0]
Mar  3 16:16:55 fwsm : %FWSM-6-106100: access-list PERMIT_ANY permitted
udp inside/192.168.1.127(35579) -> outside/192.168.3.1(33438) hit-cnt 1
(first hit) [0xd136324, 0x0]
Mar  3 16:16:55 fwsm : %FWSM-6-106100: access-list PERMIT_ANY permitted
udp inside/192.168.1.127(57635) -> outside/192.168.3.1(33439) hit-cnt 1
(first hit) [0xd136324, 0x0]
Mar  3 16:16:55 fwsm : %FWSM-6-106100: access-list PERMIT_ANY permitted
udp inside/192.168.1.127(59543) -> outside/192.168.3.1(33440) hit-cnt 1
(first hit) [0xd136324, 0x0]
Mar  3 16:16:55 fwsm : %FWSM-6-106100: access-list PERMIT_ANY permitted
udp inside/192.168.1.127(42568) -> outside/192.168.3.1(33441) hit-cnt 1
(first hit) [0xd136324, 0x0]
Mar  3 16:16:55 fwsm : %FWSM-6-106100: access-list PERMIT_ANY permitted
udp inside/192.168.1.127(45739) -> outside/192.168.3.1(33442) hit-cnt 1
(first hit) [0xd136324, 0x0]
Mar  3 16:16:55 fwsm : %FWSM-6-106100: access-list PERMIT_ANY permitted
udp inside/192.168.1.127(38052) -> outside/192.168.3.1(33443) hit-cnt 1
(first hit) [0xd136324, 0x0]
Mar  3 16:16:55 fwsm : %FWSM-6-106100: access-list From_Internet
permitted icmp outside/192.168.3.1(0) -> inside/192.168.1.127(3) hit-cnt
1 (first hit) [0x64d8ffc5, 0x5a3e207a]
Mar  3 16:16:55 fwsm : %FWSM-6-106100: access-list PERMIT_ANY permitted
udp inside/192.168.1.127(50556) -> outside/192.168.3.1(33444) hit-cnt 1
(first hit) [0xd136324, 0x0]



Mar  3 16:09:11 fwsm : %FWSM-6-106100: access-list V6_PERMIT_ANY
permitted udp inside/2001:dead:beef:3:204:23ff:deaf:bead(50928) ->
outside/2001:dead:beef:cafe::1(33434) hit-cnt 1 first hit
Mar  3 16:09:11 fwsm : %FWSM-6-106100: access-list V6_PERMIT_ANY
permitted udp inside/2001:dead:beef:3:204:23ff:deaf:bead(40298) ->
outside/2001:dead:beef:cafe::1(33435) hit-cnt 1 first hit
Mar  3 16:09:11 fwsm : %FWSM-6-106100: access-list V6_PERMIT_ANY
permitted udp inside/2001:dead:beef:3:204:23ff:deaf:bead(59693) ->
outside/2001:dead:beef:cafe::1(33436) hit-cnt 1 first hit
Mar  3 16:09:11 fwsm : %FWSM-6-106100: access-list V6_PERMIT_ANY
permitted udp inside/2001:dead:beef:3:204:23ff:deaf:bead(53347) ->
outside/2001:dead:beef:cafe::1(33437) hit-cnt 1 first hit
Mar  3 16:09:11 fwsm : %FWSM-6-106100: access-list V6_PERMIT_ANY
permitted udp inside/2001:dead:beef:3:204:23ff:deaf:bead(40017) ->
outside/2001:dead:beef:cafe::1(33438) hit-cnt 1 first hit
Mar  3 16:09:11 fwsm : %FWSM-6-106100: access-list V6_PERMIT_ANY
permitted udp inside/2001:dead:beef:3:204:23ff:deaf:bead(35667) ->
outside/2001:dead:beef:cafe::1(33439) hit-cnt 1 first hit
Mar  3 16:09:11 fwsm : %FWSM-6-106100: access-list V6_PERMIT_ANY
permitted udp inside/2001:dead:beef:3:204:23ff:deaf:bead(36459) ->
outside/2001:dead:beef:cafe::1(33440) hit-cnt 1 first hit
Mar  3 16:09:11 fwsm : %FWSM-6-106100: access-list V6_PERMIT_ANY
permitted udp inside/2001:dead:beef:3:204:23ff:deaf:bead(45750) ->
outside/2001:dead:beef:cafe::1(33441) hit-cnt 1 first hit
Mar  3 16:09:11 fwsm : %FWSM-6-106100: access-list V6_PERMIT_ANY
permitted udp inside/2001:dead:beef:3:204:23ff:deaf:bead(59125) ->
outside/2001:dead:beef:cafe::1(33442) hit-cnt 1 first hit
Mar  3 16:09:11 fwsm : %FWSM-6-106100: access-list V6_PERMIT_ANY
permitted udp inside/2001:dead:beef:3:204:23ff:deaf:bead(34934) ->
outside/2001:dead:beef:cafe::1(33443) hit-cnt 1 first hit
Mar  3 16:09:11 fwsm : %FWSM-6-106100: access-list V6_PERMIT_ANY
permitted udp inside/2001:dead:beef:3:204:23ff:deaf:bead(48452) ->
outside/2001:dead:beef:cafe::1(33444) hit-cnt 1 first hit
Mar  3 16:09:11 fwsm : %FWSM-6-106100: access-list V6_PERMIT_ANY
permitted udp inside/2001:dead:beef:3:204:23ff:deaf:bead(44628) ->
outside/2001:dead:beef:cafe::1(33445) hit-cnt 1 first hit
Mar  3 16:09:11 fwsm : %FWSM-6-106100: access-list V6_PERMIT_ANY
permitted udp inside/2001:dead:beef:3:204:23ff:deaf:bead(33027) ->
outside/2001:dead:beef:cafe::1(33446) hit-cnt 1 first hit
Mar  3 16:09:11 fwsm : %FWSM-6-106100: access-list V6_PERMIT_ANY
permitted udp inside/2001:dead:beef:3:204:23ff:deaf:bead(45131) ->
outside/2001:dead:beef:cafe::1(33447) hit-cnt 1 first hit
Mar  3 16:09:11 fwsm : %FWSM-6-106100: access-list V6_PERMIT_ANY
permitted udp inside/2001:dead:beef:3:204:23ff:deaf:bead(52958) ->
outside/2001:dead:beef:cafe::1(33448) hit-cnt 1 first hit
Mar  3 16:09:11 fwsm : %FWSM-6-106100: access-list V6_PERMIT_ANY
permitted udp inside/2001:dead:beef:3:204:23ff:deaf:bead(33004) ->
outside/2001:dead:beef:cafe::1(33449) hit-cnt 1 first hit
Mar  3 16:09:11 fwsm : %FWSM-4-106023: Deny icmp src
outside:2001:dead:beef:cafe::1 dst
inside:2001:dead:beef:3:204:23ff:deaf:bead (type 1, code 4) by
access-group "V6_From_Internet"
Mar  3 16:09:11 fwsm : %FWSM-4-106023: Deny icmp src
outside:2001:dead:beef:cafe::1 dst
inside:2001:dead:beef:3:204:23ff:deaf:bead (type 1, code 4) by
access-group "V6_From_Internet"
Mar  3 16:09:11 fwsm : %FWSM-4-106023: Deny icmp src
outside:2001:dead:beef:cafe::1 dst
inside:2001:dead:beef:3:204:23ff:deaf:bead (type 1, code 4) by
access-group "V6_From_Internet"
Mar  3 16:09:11 fwsm : %FWSM-4-106023: Deny icmp src
outside:2001:dead:beef:cafe::1 dst
inside:2001:dead:beef:3:204:23ff:deaf:bead (type 1, code 4) by
access-group "V6_From_Internet"
Mar  3 16:09:11 fwsm : %FWSM-4-106023: Deny icmp src
outside:2001:dead:beef:cafe::1 dst
inside:2001:dead:beef:3:204:23ff:deaf:bead (type 1, code 4) by
access-group "V6_From_Internet"
Mar  3 16:09:11 fwsm : %FWSM-4-106023: Deny icmp src
outside:2001:dead:beef:cafe::1 dst
inside:2001:dead:beef:3:204:23ff:deaf:bead (type 1, code 4) by
access-group "V6_From_Internet"
Mar  3 16:09:11 fwsm : %FWSM-4-106023: Deny icmp src
outside:2001:dead:beef:cafe::1 dst
inside:2001:dead:beef:3:204:23ff:deaf:bead (type 1, code 4) by
access-group "V6_From_Internet"
Mar  3 16:09:11 fwsm : %FWSM-4-106023: Deny icmp src
outside:2001:dead:beef:cafe::1 dst
inside:2001:dead:beef:3:204:23ff:deaf:bead (type 1, code 4) by
access-group "V6_From_Internet"
Mar  3 16:09:11 fwsm : %FWSM-4-106023: Deny icmp src
outside:2001:dead:beef:cafe::1 dst
inside:2001:dead:beef:3:204:23ff:deaf:bead (type 1, code 4) by
access-group "V6_From_Internet"
Mar  3 16:09:11 fwsm : %FWSM-4-106023: Deny icmp src
outside:2001:dead:beef:cafe::1 dst
inside:2001:dead:beef:3:204:23ff:deaf:bead (type 1, code 4) by
access-group "V6_From_Internet"

From streiner at cluebyfour.org  Tue Mar  3 20:30:06 2009
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Tue, 3 Mar 2009 20:30:06 -0500 (EST)
Subject: [c-nsp] FWSM and mixed IPv4/IPv6 access-list
In-Reply-To: <38D04BF3A4B7B2499D19EB1DB54285EA09E90498@FNB1EX01.gci.com>
References: <38D04BF3A4B7B2499D19EB1DB54285EA09E90498@FNB1EX01.gci.com>
Message-ID: <Pine.LNX.4.64.0903032025140.10827@whammy.cluebyfour.org>

On Tue, 3 Mar 2009, Leif Sawyer wrote:

> Is anybody working with FWSM's and mixed-mode IPv4+IPv6 ACL's?
> 
> I'm having trouble with traceroute6 not succeeding, but ping6 working
> fine:

You might be getting caught by flawed behavior of the FWSM.  I've run into 
something similar with straight v4 firewall zones where certain flavors of 
traceroute will be dropped by the blade.  When it was first reported to 
us, we thought is was a broken fixup, but the behavior persisted after 
the fixup was disabled.  No word on a fix from Cisco.

On a somewhat unrelated note, how has the v6 performance been on the FWSMs 
for you?  Everything I've heard from Cisco and other sources suggests that 
the v6 packets are much more expensive for the FWSM to forward, so 
performance would suffer greatly.

jms

From lsawyer at gci.com  Tue Mar  3 20:56:29 2009
From: lsawyer at gci.com (Leif Sawyer)
Date: Tue, 3 Mar 2009 16:56:29 -0900
Subject: [c-nsp] FWSM and mixed IPv4/IPv6 access-list
In-Reply-To: <Pine.LNX.4.64.0903032025140.10827@whammy.cluebyfour.org>
Message-ID: <38D04BF3A4B7B2499D19EB1DB54285EA09E904C5@FNB1EX01.gci.com>

Justin M. Streiner writes in reply to:
> On Tue, 3 Mar 2009, Leif Sawyer wrote:
> 
>> Is anybody working with FWSM's and mixed-mode IPv4+IPv6 ACL's?
>> 
>> I'm having trouble with traceroute6 not succeeding, but 
>> ping6 working fine:
> 
> You might be getting caught by flawed behavior of the FWSM.  
> I've run into something similar with straight v4 firewall 
> zones where certain flavors of traceroute will be dropped by 
> the blade.  When it was first reported to us, we thought is 
> was a broken fixup, but the behavior persisted after the 
> fixup was disabled.  No word on a fix from Cisco.

Hrm.  I guess it's time to open a ticket, then.  
Damn. I hate dealing with TAC on complex issues.

And it's not like CiscoPress is up-to-date.  what, 6 pages on Ipv6
in the FWSM manual? friggin joke.

 
> On a somewhat unrelated note, how has the v6 performance been 
> on the FWSMs for you?  Everything I've heard from Cisco and 
> other sources suggests that the v6 packets are much more 
> expensive for the FWSM to forward, so performance would 
> suffer greatly.

Just starting to roll this out, so no load to speak of.

Can't wait to see what next issue creeps up!

From ajadav at gmail.com  Tue Mar  3 23:28:57 2009
From: ajadav at gmail.com (Asheesh Jadav)
Date: Tue, 3 Mar 2009 20:28:57 -0800
Subject: [c-nsp] VPLS on 7600
Message-ID: <b247bbf20903032028sc32c39cib101b6fafe7c18b7@mail.gmail.com>

Hi,

 I'm trying to get answers to a few questions regarding VPLS configuration
on a 7600. Can someone please help me out here. Below is my running config.

* I'm not seeing the traffic coming in on the VC get switched towards the
attachment circuit. The traffic i'm using is Unicast, IP. Is there something
i'm missing in my config?
* The 'Output Interface' and 'Preferred path' parameters for the VC are
default, why is it so? And how can I set a preferred path if I can?

Thanks.

Router#
Router#show run
Building configuration...

Current configuration : 2641 bytes
!
upgrade fpd auto
version 12.2
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
service counters max age 10
!
hostname Router
!
boot-start-marker
boot system flash
sup-bootdisk:c7600s72033-advipservicesk9-mz.122-33.SRB5.bin
boot-end-marker
!
!
no aaa new-model
ip subnet-zero
!
!
!
!
ipv6 mfib hardware-switching replication-mode ingress
mls ip slb purge global
mls ip multicast flow-stat-timer 9
mls flow ip interface-full
no mls flow ipv6
no mls acl tcam share-global
mls cef error action reset
mpls traffic-eng tunnels
mpls ldp neighbor 7.7.7.7 targeted ldp
mpls ldp discovery targeted-hello accept
mpls label range 2048 524287
mpls label protocol ldp
!
!
spanning-tree mode pvst
spanning-tree extend system-id
diagnostic cns publish cisco.cns.device.diag_results
diagnostic cns subscribe cisco.cns.device.diag_commands
!
!
redundancy
 mode sso
 main-cpu
  auto-sync running-config
!
vlan internal allocation policy ascending
vlan access-log ratelimit 2000
l2 vfi vpls manual
 vpn id 100
 neighbor 7.7.7.7 encapsulation mpls
!
!
!
!
!
!
!
interface Tunnel1
 ip unnumbered Loopback0
 mpls traffic-eng tunnels
 mpls ip
 tunnel source GigabitEthernet4/1
 tunnel destination 7.7.7.7
 tunnel mode mpls traffic-eng
 tunnel mpls traffic-eng autoroute announce
 tunnel mpls traffic-eng path-option 1 dynamic
!
interface Loopback0
 ip address 9.9.9.9 255.255.255.255
!
interface GigabitEthernet4/1
 ip address 20.20.20.9 255.255.255.0
 ip ospf network broadcast
 ip ospf priority 2
 mpls traffic-eng tunnels
 mpls label protocol ldp
 ip rsvp bandwidth
!
interface GigabitEthernet4/2
 switchport
 switchport access vlan 100
 switchport mode access
!
interface GigabitEthernet4/3
 no ip address
!
interface GigabitEthernet4/4
 no ip address
 shutdown
!
interface GigabitEthernet4/5
 no ip address
 shutdown
!
interface GigabitEthernet4/6
 no ip address
 shutdown
!
interface GigabitEthernet4/7
 no ip address
 shutdown
!
interface GigabitEthernet4/8
 no ip address
 shutdown
!
interface GigabitEthernet5/1
 no ip address
 shutdown
!
interface GigabitEthernet5/2
 no ip address
 shutdown
!
interface Vlan1
 no ip address
 shutdown
!
interface Vlan100
 no ip address
 xconnect vfi vpls
!
router ospf 1
 router-id 9.9.9.9
 log-adjacency-changes
 network 9.9.9.9 0.0.0.0 area 0
 network 20.20.20.0 0.0.0.255 area 0
 mpls traffic-eng router-id Loopback0
 mpls traffic-eng area 0
 mpls traffic-eng interface GigabitEthernet4/1 area 0
!
ip classless
!
!
no ip http server
no ip http secure-server
!
!
!
mpls ldp router-id Loopback0 force
!
control-plane
!
!
line con 0
line vty 0 4
 login
!
!
end

Router#show ip cef
Prefix               Next Hop             Interface
0.0.0.0/0            no route
0.0.0.0/32           receive
7.7.7.7/32           7.7.7.7              Tunnel1
9.9.9.9/32           receive              Loopback0
20.20.20.0/24        attached             GigabitEthernet4/1
20.20.20.0/32        receive              GigabitEthernet4/1
20.20.20.7/32        attached             GigabitEthernet4/1
20.20.20.9/32        receive              GigabitEthernet4/1
20.20.20.255/32      receive              GigabitEthernet4/1
127.0.0.0/8          attached             EOBC0/0
127.0.0.0/32         receive              EOBC0/0
127.0.0.51/32        receive              EOBC0/0
127.255.255.255/32   receive              EOBC0/0
224.0.0.0/4          drop
224.0.0.0/24         receive
240.0.0.0/4          drop
255.255.255.255/32   receive
Router#
Router#show mpls l2transport vc 100 detail
Local interface: VFI vpls VFI up
  MPLS VC type is VFI, interworking type is Ethernet
  Destination address: 7.7.7.7, VC ID: 100, VC status: up
    Output interface: none, imposed label stack {2048}
    Preferred path: not configured
    Default path: active
    Next hop: Invalid ADDR
  Create time: 09:16:24, last status change time: 00:07:30
  Signaling protocol: LDP, peer 7.7.7.7:0 up
    Targeted Hello: 9.9.9.9(LDP Id) -> 7.7.7.7
    MPLS VC labels: local 2050, remote 2048
    Group ID: local 0, remote 100
    MTU: local 1500, remote 1500
    Remote interface description:
  Sequencing: receive disabled, send disabled
  VC statistics:
    packet totals: receive 111393, send 0
    byte totals:   receive 6683580, send 0
    packet drops:  receive 0, send 0

Router#

From brhedlun at cisco.com  Wed Mar  4 00:26:24 2009
From: brhedlun at cisco.com (Brad Hedlund)
Date: Tue, 03 Mar 2009 23:26:24 -0600
Subject: [c-nsp] VPLS on 7600
In-Reply-To: <b247bbf20903032028sc32c39cib101b6fafe7c18b7@mail.gmail.com>
Message-ID: <C5D36D20.2EC29%brhedlun@cisco.com>

Hi,
VPLS is not supported over GRE on 7600.


Brad Hedlund
bhedlund at cisco.com
http://www.internetworkexpert.org



On 3/3/09 10:28 PM, "Asheesh Jadav" <ajadav at gmail.com> wrote:

> Hi,
> 
>  I'm trying to get answers to a few questions regarding VPLS configuration
> on a 7600. Can someone please help me out here. Below is my running config.
> 
> * I'm not seeing the traffic coming in on the VC get switched towards the
> attachment circuit. The traffic i'm using is Unicast, IP. Is there something
> i'm missing in my config?
> * The 'Output Interface' and 'Preferred path' parameters for the VC are
> default, why is it so? And how can I set a preferred path if I can?
> 
> Thanks.
> 
> Router#
> Router#show run
> Building configuration...
> 
> Current configuration : 2641 bytes
> !
> upgrade fpd auto
> version 12.2
> service timestamps debug datetime msec
> service timestamps log datetime msec
> no service password-encryption
> service counters max age 10
> !
> hostname Router
> !
> boot-start-marker
> boot system flash
> sup-bootdisk:c7600s72033-advipservicesk9-mz.122-33.SRB5.bin
> boot-end-marker
> !
> !
> no aaa new-model
> ip subnet-zero
> !
> !
> !
> !
> ipv6 mfib hardware-switching replication-mode ingress
> mls ip slb purge global
> mls ip multicast flow-stat-timer 9
> mls flow ip interface-full
> no mls flow ipv6
> no mls acl tcam share-global
> mls cef error action reset
> mpls traffic-eng tunnels
> mpls ldp neighbor 7.7.7.7 targeted ldp
> mpls ldp discovery targeted-hello accept
> mpls label range 2048 524287
> mpls label protocol ldp
> !
> !
> spanning-tree mode pvst
> spanning-tree extend system-id
> diagnostic cns publish cisco.cns.device.diag_results
> diagnostic cns subscribe cisco.cns.device.diag_commands
> !
> !
> redundancy
>  mode sso
>  main-cpu
>   auto-sync running-config
> !
> vlan internal allocation policy ascending
> vlan access-log ratelimit 2000
> l2 vfi vpls manual
>  vpn id 100
>  neighbor 7.7.7.7 encapsulation mpls
> !
> !
> !
> !
> !
> !
> !
> interface Tunnel1
>  ip unnumbered Loopback0
>  mpls traffic-eng tunnels
>  mpls ip
>  tunnel source GigabitEthernet4/1
>  tunnel destination 7.7.7.7
>  tunnel mode mpls traffic-eng
>  tunnel mpls traffic-eng autoroute announce
>  tunnel mpls traffic-eng path-option 1 dynamic
> !
> interface Loopback0
>  ip address 9.9.9.9 255.255.255.255
> !
> interface GigabitEthernet4/1
>  ip address 20.20.20.9 255.255.255.0
>  ip ospf network broadcast
>  ip ospf priority 2
>  mpls traffic-eng tunnels
>  mpls label protocol ldp
>  ip rsvp bandwidth
> !
> interface GigabitEthernet4/2
>  switchport
>  switchport access vlan 100
>  switchport mode access
> !
> interface GigabitEthernet4/3
>  no ip address
> !
> interface GigabitEthernet4/4
>  no ip address
>  shutdown
> !
> interface GigabitEthernet4/5
>  no ip address
>  shutdown
> !
> interface GigabitEthernet4/6
>  no ip address
>  shutdown
> !
> interface GigabitEthernet4/7
>  no ip address
>  shutdown
> !
> interface GigabitEthernet4/8
>  no ip address
>  shutdown
> !
> interface GigabitEthernet5/1
>  no ip address
>  shutdown
> !
> interface GigabitEthernet5/2
>  no ip address
>  shutdown
> !
> interface Vlan1
>  no ip address
>  shutdown
> !
> interface Vlan100
>  no ip address
>  xconnect vfi vpls
> !
> router ospf 1
>  router-id 9.9.9.9
>  log-adjacency-changes
>  network 9.9.9.9 0.0.0.0 area 0
>  network 20.20.20.0 0.0.0.255 area 0
>  mpls traffic-eng router-id Loopback0
>  mpls traffic-eng area 0
>  mpls traffic-eng interface GigabitEthernet4/1 area 0
> !
> ip classless
> !
> !
> no ip http server
> no ip http secure-server
> !
> !
> !
> mpls ldp router-id Loopback0 force
> !
> control-plane
> !
> !
> line con 0
> line vty 0 4
>  login
> !
> !
> end
> 
> Router#show ip cef
> Prefix               Next Hop             Interface
> 0.0.0.0/0            no route
> 0.0.0.0/32           receive
> 7.7.7.7/32           7.7.7.7              Tunnel1
> 9.9.9.9/32           receive              Loopback0
> 20.20.20.0/24        attached             GigabitEthernet4/1
> 20.20.20.0/32        receive              GigabitEthernet4/1
> 20.20.20.7/32        attached             GigabitEthernet4/1
> 20.20.20.9/32        receive              GigabitEthernet4/1
> 20.20.20.255/32      receive              GigabitEthernet4/1
> 127.0.0.0/8          attached             EOBC0/0
> 127.0.0.0/32         receive              EOBC0/0
> 127.0.0.51/32        receive              EOBC0/0
> 127.255.255.255/32   receive              EOBC0/0
> 224.0.0.0/4          drop
> 224.0.0.0/24         receive
> 240.0.0.0/4          drop
> 255.255.255.255/32   receive
> Router#
> Router#show mpls l2transport vc 100 detail
> Local interface: VFI vpls VFI up
>   MPLS VC type is VFI, interworking type is Ethernet
>   Destination address: 7.7.7.7, VC ID: 100, VC status: up
>     Output interface: none, imposed label stack {2048}
>     Preferred path: not configured
>     Default path: active
>     Next hop: Invalid ADDR
>   Create time: 09:16:24, last status change time: 00:07:30
>   Signaling protocol: LDP, peer 7.7.7.7:0 up
>     Targeted Hello: 9.9.9.9(LDP Id) -> 7.7.7.7
>     MPLS VC labels: local 2050, remote 2048
>     Group ID: local 0, remote 100
>     MTU: local 1500, remote 1500
>     Remote interface description:
>   Sequencing: receive disabled, send disabled
>   VC statistics:
>     packet totals: receive 111393, send 0
>     byte totals:   receive 6683580, send 0
>     packet drops:  receive 0, send 0
> 
> Router#
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/




From thilak.t at gmail.com  Wed Mar  4 00:37:10 2009
From: thilak.t at gmail.com (Thilak T)
Date: Tue, 3 Mar 2009 21:37:10 -0800
Subject: [c-nsp] How to track SSL cert expiry on Cisco ACS
Message-ID: <1d11fbf80903032137i49899c54nac5fb1513d011274@mail.gmail.com>

Hello

Can anyone advice what is the best method to keep track of SSL cert expiry
on ACS 4.2  servers.  I have 15  ACS across the globe , which I have to
manually keep track on cert validity.

From ajadav at gmail.com  Wed Mar  4 01:19:36 2009
From: ajadav at gmail.com (Asheesh Jadav)
Date: Tue, 3 Mar 2009 22:19:36 -0800
Subject: [c-nsp] VPLS on 7600
In-Reply-To: <b247bbf20903032028sc32c39cib101b6fafe7c18b7@mail.gmail.com>
References: <b247bbf20903032028sc32c39cib101b6fafe7c18b7@mail.gmail.com>
Message-ID: <b247bbf20903032219p3fc880e6k46f3b133f8ad94cf@mail.gmail.com>

The Line card I have is a WS-X6408A-GBIC. I'm using different ports on the
same line card for my attachment circuit as well as VC. Is VPLS supported on
this hardware?

On Tue, Mar 3, 2009 at 8:28 PM, Asheesh Jadav <ajadav at gmail.com> wrote:

> Hi,
>
>  I'm trying to get answers to a few questions regarding VPLS configuration
> on a 7600. Can someone please help me out here. Below is my running config.
>
> * I'm not seeing the traffic coming in on the VC get switched towards the
> attachment circuit. The traffic i'm using is Unicast, IP. Is there something
> i'm missing in my config?
> * The 'Output Interface' and 'Preferred path' parameters for the VC are
> default, why is it so? And how can I set a preferred path if I can?
>
> Thanks.
>
> Router#
> Router#show run
> Building configuration...
>
> Current configuration : 2641 bytes
> !
> upgrade fpd auto
> version 12.2
> service timestamps debug datetime msec
> service timestamps log datetime msec
> no service password-encryption
> service counters max age 10
> !
> hostname Router
> !
> boot-start-marker
> boot system flash
> sup-bootdisk:c7600s72033-advipservicesk9-mz.122-33.SRB5.bin
> boot-end-marker
> !
> !
> no aaa new-model
> ip subnet-zero
> !
> !
> !
> !
> ipv6 mfib hardware-switching replication-mode ingress
> mls ip slb purge global
> mls ip multicast flow-stat-timer 9
> mls flow ip interface-full
> no mls flow ipv6
> no mls acl tcam share-global
> mls cef error action reset
> mpls traffic-eng tunnels
> mpls ldp neighbor 7.7.7.7 targeted ldp
> mpls ldp discovery targeted-hello accept
> mpls label range 2048 524287
> mpls label protocol ldp
> !
> !
> spanning-tree mode pvst
> spanning-tree extend system-id
> diagnostic cns publish cisco.cns.device.diag_results
> diagnostic cns subscribe cisco.cns.device.diag_commands
> !
> !
> redundancy
>  mode sso
>  main-cpu
>   auto-sync running-config
> !
> vlan internal allocation policy ascending
> vlan access-log ratelimit 2000
> l2 vfi vpls manual
>  vpn id 100
>  neighbor 7.7.7.7 encapsulation mpls
> !
> !
> !
> !
> !
> !
> !
> interface Tunnel1
>  ip unnumbered Loopback0
>  mpls traffic-eng tunnels
>  mpls ip
>  tunnel source GigabitEthernet4/1
>  tunnel destination 7.7.7.7
>  tunnel mode mpls traffic-eng
>  tunnel mpls traffic-eng autoroute announce
>  tunnel mpls traffic-eng path-option 1 dynamic
> !
> interface Loopback0
>  ip address 9.9.9.9 255.255.255.255
> !
> interface GigabitEthernet4/1
>  ip address 20.20.20.9 255.255.255.0
>  ip ospf network broadcast
>  ip ospf priority 2
>  mpls traffic-eng tunnels
>  mpls label protocol ldp
>  ip rsvp bandwidth
> !
> interface GigabitEthernet4/2
>  switchport
>  switchport access vlan 100
>  switchport mode access
> !
> interface GigabitEthernet4/3
>  no ip address
> !
> interface GigabitEthernet4/4
>  no ip address
>  shutdown
> !
> interface GigabitEthernet4/5
>  no ip address
>  shutdown
> !
> interface GigabitEthernet4/6
>  no ip address
>  shutdown
> !
> interface GigabitEthernet4/7
>  no ip address
>  shutdown
> !
> interface GigabitEthernet4/8
>  no ip address
>  shutdown
> !
> interface GigabitEthernet5/1
>  no ip address
>  shutdown
> !
> interface GigabitEthernet5/2
>  no ip address
>  shutdown
> !
> interface Vlan1
>  no ip address
>  shutdown
> !
> interface Vlan100
>  no ip address
>  xconnect vfi vpls
> !
> router ospf 1
>  router-id 9.9.9.9
>  log-adjacency-changes
>  network 9.9.9.9 0.0.0.0 area 0
>  network 20.20.20.0 0.0.0.255 area 0
>  mpls traffic-eng router-id Loopback0
>  mpls traffic-eng area 0
>  mpls traffic-eng interface GigabitEthernet4/1 area 0
> !
> ip classless
> !
> !
> no ip http server
> no ip http secure-server
> !
> !
> !
> mpls ldp router-id Loopback0 force
> !
> control-plane
> !
> !
> line con 0
> line vty 0 4
>  login
> !
> !
> end
>
> Router#show ip cef
> Prefix               Next Hop             Interface
> 0.0.0.0/0            no route
> 0.0.0.0/32           receive
> 7.7.7.7/32           7.7.7.7              Tunnel1
> 9.9.9.9/32           receive              Loopback0
> 20.20.20.0/24        attached             GigabitEthernet4/1
> 20.20.20.0/32        receive              GigabitEthernet4/1
> 20.20.20.7/32        attached             GigabitEthernet4/1
> 20.20.20.9/32        receive              GigabitEthernet4/1
> 20.20.20.255/32      receive              GigabitEthernet4/1
> 127.0.0.0/8          attached             EOBC0/0
> 127.0.0.0/32         receive              EOBC0/0
> 127.0.0.51/32        receive              EOBC0/0
> 127.255.255.255/32   receive              EOBC0/0
> 224.0.0.0/4          drop
> 224.0.0.0/24         receive
> 240.0.0.0/4          drop
> 255.255.255.255/32   receive
> Router#
> Router#show mpls l2transport vc 100 detail
> Local interface: VFI vpls VFI up
>   MPLS VC type is VFI, interworking type is Ethernet
>   Destination address: 7.7.7.7, VC ID: 100, VC status: up
>     Output interface: none, imposed label stack {2048}
>     Preferred path: not configured
>     Default path: active
>     Next hop: Invalid ADDR
>   Create time: 09:16:24, last status change time: 00:07:30
>   Signaling protocol: LDP, peer 7.7.7.7:0 up
>     Targeted Hello: 9.9.9.9(LDP Id) -> 7.7.7.7
>     MPLS VC labels: local 2050, remote 2048
>     Group ID: local 0, remote 100
>     MTU: local 1500, remote 1500
>     Remote interface description:
>   Sequencing: receive disabled, send disabled
>   VC statistics:
>     packet totals: receive 111393, send 0
>     byte totals:   receive 6683580, send 0
>     packet drops:  receive 0, send 0
>
> Router#
>

From r.engehausen at gmail.com  Wed Mar  4 01:49:12 2009
From: r.engehausen at gmail.com (Roy)
Date: Tue, 03 Mar 2009 22:49:12 -0800
Subject: [c-nsp] SSH from router to linux
Message-ID: <49AE2468.40001@gmail.com>

I am trying to ssh from a 2811 to linux box.  I telnet to the Cisco and
issue

ssh -l root xx.xx.xx.xx

and I get the password prompt.  I enter that and then logon goes through
and I get the shell prompt.  The problem is that nothing I type seems to
get through to linux. 

Is there some magic I am missing?

From serhat.candan at probil.com.tr  Wed Mar  4 04:14:43 2009
From: serhat.candan at probil.com.tr (=?iso-8859-9?Q?Serhat_Candan_=28Probil_-_=DDstanbul=29?=)
Date: Wed, 4 Mar 2009 11:14:43 +0200
Subject: [c-nsp] Cisco 7600 Router's Default IPSec Throughput Rate
In-Reply-To: <3fc686ad0903040112p6760a191r9cb16eb7969d8960@mail.gmail.com>
References: <3fc686ad0903040112p6760a191r9cb16eb7969d8960@mail.gmail.com>
Message-ID: <2ED8C866F019B840AD21E8E29AD091CD0CB9E77410@proexc.probil.intl>

Hello All,

I m trying to find a reference guide which has IPSec VPN throughput rates of Cisco 7600 router. I m not sure to use VPN SPA or not because of that. For example if you have 50 IPSec Sites with low speed such as 128 Kbps, do we need to use VPN SPA or just upgrade the IOS of the router by using Security Feature enabled IOS?

It would be great to have such a document to determine that need.

Thanks in advance,

Serhat

From blahu77 at gmail.com  Wed Mar  4 05:00:06 2009
From: blahu77 at gmail.com (Mateusz Blaszczyk)
Date: Wed, 4 Mar 2009 10:00:06 +0000
Subject: [c-nsp] VPLS on 7600
In-Reply-To: <b247bbf20903032219p3fc880e6k46f3b133f8ad94cf@mail.gmail.com>
References: <b247bbf20903032028sc32c39cib101b6fafe7c18b7@mail.gmail.com>
	<b247bbf20903032219p3fc880e6k46f3b133f8ad94cf@mail.gmail.com>
Message-ID: <383357750903040200s5cb711ceg94e872948507041e@mail.gmail.com>

2009/3/4 Asheesh Jadav <ajadav at gmail.com>:
> The Line card I have is a WS-X6408A-GBIC. I'm using different ports on the
> same line card for my attachment circuit as well as VC. Is VPLS supported on
> this hardware?

VPLS is supported only on ES, SPA and OSM line cards

[...]

>> interface Tunnel1
>> ?ip unnumbered Loopback0
>> ?mpls traffic-eng tunnels
>> ?mpls ip
>> ?tunnel source GigabitEthernet4/1

I think you need to source the tunnel from Lo0

>> ?tunnel destination 7.7.7.7
>> ?tunnel mode mpls traffic-eng
>> ?tunnel mpls traffic-eng autoroute announce
>> ?tunnel mpls traffic-eng path-option 1 dynamic

[...]

>> interface Vlan100
>> ?no ip address
>> ?xconnect vfi vpls

This configuration is not supported on your line card.

Best Regards,

-mat
-- 
pgp-key 0x1C655CAB

From hegedus.gabor at euroway.hu  Wed Mar  4 04:27:25 2009
From: hegedus.gabor at euroway.hu (Hegedus Gabor)
Date: Wed, 04 Mar 2009 10:27:25 +0100
Subject: [c-nsp] ip helper and dhcp on the same device
Message-ID: <49AE497D.20503@euroway.hu>

Hi all!

I have a question.

Is it possible to use ip dhcp pool XY for one host( use mac address) and 
ip helper-address  for the others (all pc is in the same subnet).

the scenario is here:

                                           ________onePcWithKnownMAC
                                          |
[ROUTER]_____________[SW]_______otherPCs
|
|__________________[DHCP SERVER for the others]


- one dhcp server on the router for just one pc and
- one dhcp server for the others

Is it possible?

another question:

I set the ip helper address, and the ip on 2 interface, and my C 2611 
dosen't send the  request packet from in interface to the out interface. 
(checked by in acc list log and out acc list log)
Why? What is the problem?

Thank you for help me!
Best regards
Gabor
 






From Steven.Glogger at swisscom.com  Wed Mar  4 05:42:06 2009
From: Steven.Glogger at swisscom.com (Steven.Glogger at swisscom.com)
Date: Wed, 4 Mar 2009 11:42:06 +0100
Subject: [c-nsp] ip helper and dhcp on the same device
In-Reply-To: <49AE497D.20503@euroway.hu>
References: <49AE497D.20503@euroway.hu>
Message-ID: <1FC8A0BAFBBD9749BB1F06010D23C8A55EE6565D@sg000035.corproot.net>

probably you could solve it by placing one pool for your local stuff, and doing some nasty dhcp proxying / agent stuff for your other requirement

-steven 

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Hegedus Gabor
Sent: Wednesday, March 04, 2009 10:27 AM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] ip helper and dhcp on the same device

Hi all!

I have a question.

Is it possible to use ip dhcp pool XY for one host( use mac address) and 
ip helper-address  for the others (all pc is in the same subnet).

the scenario is here:

                                           ________onePcWithKnownMAC
                                          |
[ROUTER]_____________[SW]_______otherPCs
|
|__________________[DHCP SERVER for the others]


- one dhcp server on the router for just one pc and
- one dhcp server for the others

Is it possible?

another question:

I set the ip helper address, and the ip on 2 interface, and my C 2611 
dosen't send the  request packet from in interface to the out interface. 
(checked by in acc list log and out acc list log)
Why? What is the problem?

Thank you for help me!
Best regards
Gabor
 





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

From Craig at smilernet.com  Wed Mar  4 07:25:51 2009
From: Craig at smilernet.com (Craig Allen)
Date: Wed, 4 Mar 2009 12:25:51 -0000
Subject: [c-nsp] Cisco 6509-E QoS Policy Confusion
Message-ID: <468184E71AE00E4B803885E21B5CD81408A828@bender.smilernet.local>

Hello,
 
I have recently taken over a network and have a question about a current QoS policy and am trying to understand why it would have been configured this way.
 
An excerpt of the questionable config is as follows:
 
policy-map apply_1000_qos_for_att_dscp_to_nextlevel
  class EF_QOS_PORTS
   police cir 4000000000 bc 3125000 be 31250000 conform-action set-dscp-transmit ef exceed-action policed-dscp-transmit violate-action policed-dscp-transmit
  class af31_QOS_PORTS
   police cir 4000000000 bc 31250000 be 31250000 conform-action set-dscp-transmit af31 exceed-action policed-dscp-transmit violate-action policed-dscp-transmit
  class af21_QOS_PORTS
   police cir 1000000000 bc 31250000 be 31250000 conform-action set-dscp-transmit af21 exceed-action policed-dscp-transmit violate-action policed-dscp-transmit
!
 
The above policy has been applied to all Gig interfaces on the 6509 blades.
 
What I'm trying to understand is the CIR / BC / BE settings and exactly what they will achieve.
 
My first initial thought is that the CIR/BC/BE settings will achieve nothing?
 
Thanks!
 
Craig

From Michael.Robson at manchester.ac.uk  Wed Mar  4 08:00:59 2009
From: Michael.Robson at manchester.ac.uk (Michael Robson)
Date: Wed, 4 Mar 2009 13:00:59 +0000
Subject: [c-nsp] UDP-helper problem
Message-ID: <2CE904AA-FF23-4480-8D58-1322E1521FBD@manchester.ac.uk>

I have recently moved the routing of a subnet from an old sup2/msfc2  
6500 (Version 12.1(26)E8, RELEASE SOFTWARE (fc1)) to a newer sup3/ 
msfc3 6500 (Version 12.2(18)SXF13, RELEASE SOFTWARE (fc1)). On the old  
router the udp-helper command worked fine, but on the new router I can  
see the DHCP address coming in but not the reply coming back and the  
DHCP server isn't seeing the request arriving. Can anyone suggest why  
this might have stopped working (it isn't an ACL or firewall issue as  
there aren't any in the way) and I haven't turned _off_ any component  
of udp-helper (i.e. using the ip forward-protocol command).

interface Vlan937
  description XXXYYYZZZ
  ip address w.x.y.z 255.255.255.192
  ip helper-address a.b.c.d


Thanks,

Michael
-- 


From avayner at cisco.com  Wed Mar  4 08:16:39 2009
From: avayner at cisco.com (Arie Vayner (avayner))
Date: Wed, 4 Mar 2009 14:16:39 +0100
Subject: [c-nsp] Cisco 6509-E QoS Policy Confusion
In-Reply-To: <468184E71AE00E4B803885E21B5CD81408A828@bender.smilernet.local>
References: <468184E71AE00E4B803885E21B5CD81408A828@bender.smilernet.local>
Message-ID: <78C984F8939D424697B15E4B1C1BB3D74D4B7B@xmb-ams-331.emea.cisco.com>

Craig,

Basically you are making sure the customer is not abusing the different
classes.
For example any packet that goes beyond the policer in class
EF_QOS_PORTS would be remarked (this is the " exceed-action
policed-dscp-transmit violate-action policed-dscp-transmit" part) to a
lower value.

To see the value of the remark, you should use this command:
router#show mls qos maps policed-dscp
   Normal Burst Policed-dscp map:
(dscp= d1d2)
     d1 :  d2 0  1  2  3  4  5  6  7  8  9
     -------------------------------------
      0 :    00 01 02 03 04 05 06 07 08 09
      1 :    10 11 12 13 14 15 16 17 18 19
      2 :    20 21 22 23 24 25 26 27 28 29
      3 :    30 31 32 33 34 35 36 37 38 39
      4 :    40 41 42 43 44 45 46 47 48 49
      5 :    50 51 52 53 54 55 56 57 58 59
      6 :    60 61 62 63

   Maximum Burst Policed-dscp map:
(dscp= d1d2)
     d1 :  d2 0  1  2  3  4  5  6  7  8  9
     -------------------------------------
      0 :    00 01 02 03 04 05 06 07 08 09
      1 :    10 11 12 13 14 15 16 17 18 19
      2 :    20 21 22 23 24 25 26 27 28 29
      3 :    30 31 32 33 34 35 36 37 38 39
      4 :    40 41 42 43 44 45 46 47 48 49
      5 :    50 51 52 53 54 55 56 57 58 59
      6 :    60 61 62 63

For reference, search for "policed-dscp-transmit" on this page:
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/con
figuration/guide/qos.html


Usually this kind of policy is deployed on the ingress of the network
(where a customer is connected) and the remark makes sure that any
excess traffic from each class is marked down either to BE or a lower
class (depends on policy)


Arie

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Craig Allen
Sent: Wednesday, March 04, 2009 14:26
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Cisco 6509-E QoS Policy Confusion

Hello,
 
I have recently taken over a network and have a question about a current
QoS policy and am trying to understand why it would have been configured
this way.
 
An excerpt of the questionable config is as follows:
 
policy-map apply_1000_qos_for_att_dscp_to_nextlevel
  class EF_QOS_PORTS
   police cir 4000000000 bc 3125000 be 31250000 conform-action
set-dscp-transmit ef exceed-action policed-dscp-transmit violate-action
policed-dscp-transmit
  class af31_QOS_PORTS
   police cir 4000000000 bc 31250000 be 31250000 conform-action
set-dscp-transmit af31 exceed-action policed-dscp-transmit
violate-action policed-dscp-transmit
  class af21_QOS_PORTS
   police cir 1000000000 bc 31250000 be 31250000 conform-action
set-dscp-transmit af21 exceed-action policed-dscp-transmit
violate-action policed-dscp-transmit
!
 
The above policy has been applied to all Gig interfaces on the 6509
blades.
 
What I'm trying to understand is the CIR / BC / BE settings and exactly
what they will achieve.
 
My first initial thought is that the CIR/BC/BE settings will achieve
nothing?
 
Thanks!
 
Craig
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From Craig at smilernet.com  Wed Mar  4 08:50:02 2009
From: Craig at smilernet.com (Craig Allen)
Date: Wed, 4 Mar 2009 13:50:02 -0000
Subject: [c-nsp] Cisco 6509-E QoS Policy Confusion
References: <468184E71AE00E4B803885E21B5CD81408A828@bender.smilernet.local>
	<78C984F8939D424697B15E4B1C1BB3D74D4B7B@xmb-ams-331.emea.cisco.com>
Message-ID: <468184E71AE00E4B803885E21B5CD81408A82A@bender.smilernet.local>

Arie,
 
I understand the policed-dscp-transmit part of the policy however it's the CIR/BC/BE values that I'm questioning as based on the figures the CIR is set to 4Gbps so effectively the policed-dscp-transmit will never kick in and BC/BE are set to 32Megabytes.
 
Basically this policy is applied to user access ports (1Gb) and also to 2 x 1Gb EtherChannel Trunk ports.
 
What values should be applied for CIR/BC/BE on the edge if any?
 
Craig

________________________________

From: Arie Vayner (avayner) [mailto:avayner at cisco.com]
Sent: Wed 04/03/2009 13:16
To: Craig Allen; cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] Cisco 6509-E QoS Policy Confusion



Craig,

Basically you are making sure the customer is not abusing the different
classes.
For example any packet that goes beyond the policer in class
EF_QOS_PORTS would be remarked (this is the " exceed-action
policed-dscp-transmit violate-action policed-dscp-transmit" part) to a
lower value.

To see the value of the remark, you should use this command:
router#show mls qos maps policed-dscp
   Normal Burst Policed-dscp map:
(dscp= d1d2)
     d1 :  d2 0  1  2  3  4  5  6  7  8  9
     -------------------------------------
      0 :    00 01 02 03 04 05 06 07 08 09
      1 :    10 11 12 13 14 15 16 17 18 19
      2 :    20 21 22 23 24 25 26 27 28 29
      3 :    30 31 32 33 34 35 36 37 38 39
      4 :    40 41 42 43 44 45 46 47 48 49
      5 :    50 51 52 53 54 55 56 57 58 59
      6 :    60 61 62 63

   Maximum Burst Policed-dscp map:
(dscp= d1d2)
     d1 :  d2 0  1  2  3  4  5  6  7  8  9
     -------------------------------------
      0 :    00 01 02 03 04 05 06 07 08 09
      1 :    10 11 12 13 14 15 16 17 18 19
      2 :    20 21 22 23 24 25 26 27 28 29
      3 :    30 31 32 33 34 35 36 37 38 39
      4 :    40 41 42 43 44 45 46 47 48 49
      5 :    50 51 52 53 54 55 56 57 58 59
      6 :    60 61 62 63

For reference, search for "policed-dscp-transmit" on this page:
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/con
figuration/guide/qos.html


Usually this kind of policy is deployed on the ingress of the network
(where a customer is connected) and the remark makes sure that any
excess traffic from each class is marked down either to BE or a lower
class (depends on policy)


Arie

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Craig Allen
Sent: Wednesday, March 04, 2009 14:26
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Cisco 6509-E QoS Policy Confusion

Hello,

I have recently taken over a network and have a question about a current
QoS policy and am trying to understand why it would have been configured
this way.

An excerpt of the questionable config is as follows:

policy-map apply_1000_qos_for_att_dscp_to_nextlevel
  class EF_QOS_PORTS
   police cir 4000000000 bc 3125000 be 31250000 conform-action
set-dscp-transmit ef exceed-action policed-dscp-transmit violate-action
policed-dscp-transmit
  class af31_QOS_PORTS
   police cir 4000000000 bc 31250000 be 31250000 conform-action
set-dscp-transmit af31 exceed-action policed-dscp-transmit
violate-action policed-dscp-transmit
  class af21_QOS_PORTS
   police cir 1000000000 bc 31250000 be 31250000 conform-action
set-dscp-transmit af21 exceed-action policed-dscp-transmit
violate-action policed-dscp-transmit
!

The above policy has been applied to all Gig interfaces on the 6509
blades.

What I'm trying to understand is the CIR / BC / BE settings and exactly
what they will achieve.

My first initial thought is that the CIR/BC/BE settings will achieve
nothing?

Thanks!

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



From rens at autempspourmoi.be  Wed Mar  4 09:10:46 2009
From: rens at autempspourmoi.be (Rens)
Date: Wed, 4 Mar 2009 15:10:46 +0100
Subject: [c-nsp] Deliver a L2 MTU circuit of 1530
Message-ID: <259B663485FD4F5A8F803F333F048F8D@EU.corp.clearwire.com>

Hi all,

 

I would want to know of my logic makes sense.

 

Customer side A <=> SWITCH L2 <=> ROUTER <=> L2TPv3 cloud <=> ROUTER <=>
SWITCH L2 <=> Customer side B

 

So I would configure QinQ on my switch and this would arrive on my router
via dot1q subinterface and with an xconnect to the other router and out
again with dot1q subinterface and QinQ towards the customer.

If my customer demands a L2 MTU of 1530 which IP should I need between my 2
routers towards the L2TPv3 cloud.

 

I calculate like this:

 

Customer 1530 + 8 bytes for my QinQ + 42 bytes for my L2TPv3

So my minimum MTU between my 2 routers should be minimum 1580 so they
wouldn't fragment?

 

Any feedback is welcome.

 

Regards,

 

Rens

 

 

 

 


From justin at justinshore.com  Wed Mar  4 09:14:27 2009
From: justin at justinshore.com (Justin Shore)
Date: Wed, 04 Mar 2009 08:14:27 -0600
Subject: [c-nsp] SSH from router to linux
In-Reply-To: <49AE2468.40001@gmail.com>
References: <49AE2468.40001@gmail.com>
Message-ID: <49AE8CC3.5060802@justinshore.com>

My best guess is that your Linux box isn't correcting determining what 
term type to use or some other core shell variable along those lines. 
SSH in normally and issue echo $TERM to see what it is.  Add "env" to 
one your shell's startup file (.bash_login for example if you use bash). 
  Compare env output from the normal SSH connection to the one through 
the router.  Try switching your default shell on the Linux box to 
something else.  I use bash.

You'll probably get better responses on a list specific to your Linux 
distribution's SSH daemon.  I think that's where the problem most likely is.

Justin

Roy wrote:
> I am trying to ssh from a 2811 to linux box.  I telnet to the Cisco and
> issue
> 
> ssh -l root xx.xx.xx.xx
> 
> and I get the password prompt.  I enter that and then logon goes through
> and I get the shell prompt.  The problem is that nothing I type seems to
> get through to linux. 
> 
> Is there some magic I am missing?
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

From charles.regan at gmail.com  Wed Mar  4 09:46:10 2009
From: charles.regan at gmail.com (Charles Regan)
Date: Wed, 4 Mar 2009 10:46:10 -0400
Subject: [c-nsp] VLAN and switch and ?
Message-ID: <e353d880903040646t7afaa334yec3ad26b84d1fd7@mail.gmail.com>

Good Morning,

I'll try to explain what I want to do... We are LOCAL NETWORK in this graphic.
The ISP wants to use our fiber link to connect to his wireless customer.
We also want internet access from his Wireless Backhaul1.
ISP also use VLAN on his customer subscriber modules.

How would you configure 2924 Switch and 2960 Switch, so that
everything is transparent from my side and his side ?
I don't want him to call me to add a new VLAN on our switch.


ISP ---Wireless BackHaul1 -- 2924 Switch ---- FIBER ---- 2960 Switch
---- Wireless Backhaul2 ---- Access Point ---- Wireless subscriber
modules
                                            |
             |
                                            |
             |
                                            |
             |
                                            |
             |
                                            |
             |
                             LOCAL NETWORK            LOCAL NETWORK


Will something like this work ?
switchport access vlan 500
switchport trunk encapsulation dot1q
switchport mode trunk

From rodunn at cisco.com  Wed Mar  4 10:11:39 2009
From: rodunn at cisco.com (Rodney Dunn)
Date: Wed, 4 Mar 2009 10:11:39 -0500
Subject: [c-nsp] packet loss between adjacent ciscos
In-Reply-To: <20090227162830.xbtdn6m8jyss40sg@webmail2.australiaonline.net.au>
References: <20090227162830.xbtdn6m8jyss40sg@webmail2.australiaonline.net.au>
Message-ID: <20090304151139.GG4100@rtp-cse-489.cisco.com>

Upgrade the 72xx's to 12.4(20)T latest on Cisco.com to get the
packet capture feature and prove where the packets are getting
lost via a capture:

http://supportwiki.cisco.com/ViewWiki/index.php/Tech_Insights:Utilizing_the_New_Packet_Capture_Feature

We could go in to the long discussion about how to make sure all the
packets are being CEF switched, performance with features, etc...

But it's easier to just prove via a trace where the packets are not being
delivered via a trace and focus there.

Rodney

On Fri, Feb 27, 2009 at 04:28:30PM +1100, Sam Tilders wrote:
> Hi,
> 
> We have been experiencing some packet loss between a switch and a
> router directly connected to each other and are having some difficulty
> finding the problem.
> 
> The problem showed up when a customer complained that there were
> moments of silence on their voip calls. They did some pings and found
> that there was packet loss at the same time as the silence on the calls.
> 
> With some further help from the customer, I was able to narrow the
> problem down to loss between two ciscos in our rack.
> 
> The network layout is like this:
> 
> carrier peer port
>       |
>       |
>       | 100% ping success.
>       |
>       | iofe
> border router (7200vxr w/npe-400 12.2(18)S4)
>       | pa-fe-tx
>       |
>       | 99.994 - 99.999% ping success
>       |
>       |
> switch (2924 xl en)
>       |
>       |
>       | 100% ping success
>       |
>       | iofe
> l2tp termination router (7200vxr w/npe-300 12.4(4)T1)
>       | gige
>       |
>       |
> downstream to customers
> 
> The ping percentages are from repeated 100000 ping samples.
> 
> The interfaces are all forced duplex full, the switch interfaces are
> forced speed 100.
> 
> When the link between the router and the switch has loss it can be
> seen in the ping as a slow down then a single timeout.
> 
> The ping output goes something like:
> 
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> !!!! !  !   !    !     !      !         .!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> 
> where I've used spacing to indicate the time between markers.
> 
> So it appears that the ping and reply begins to slow, then it slows
> enough that a single 2 second timeout occurs and then it picks up
> again at full speed.
> 
> A 100000 ping takes a few minutes to run and during this time it may
> lose one or half a dozen pings, each lost ping spaced apart,
> apparently with no regular period.
> 
> The router and switch are typically running around 30% cpu.
> 
> When I run these ping tests the switch gets to 80% cpu, however it can
> be shown with cases like a customer's voip call that the problem
> occurs even when the util is lower.
> 
> I have correlated the ping loss with the customer's voip silence,
> having them on a call while running the ping and they experience a
> couple of seconds of silence at the same time as the router misses a
> ping.
> 
> I've been on site and replaced the pa-fe-tx in the 7200 to no
> improvement. I moved the PA to a different port on the router, no
> improvement. I've replaced the switch with no improvement.
> 
> (We had previously tried different switch ports and replacing the cabling.)
> 
> All the while, none of the interface statistics report any errors
> other than the occasional ignored packet - however, these don't occur  
> at the same time as
> the problem and much less frequently.
> 
> I've had various debug options turned on - both on the switch and the
> router - there has been no clear correlation between any events and
> the occurence of packet loss.
> 
> So, I was wondering if this sounds familiar to anyone or if there is
> anything someone might be able to suggest to further investigate or
> resolve this issue.
> 
> I'd appreciate any advice that can be given.
> 
> Regards,
> 
> - Sam
> 
> 
> 
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

From jfitz at Princeton.EDU  Wed Mar  4 10:14:15 2009
From: jfitz at Princeton.EDU (Jeff Fitzwater)
Date: Wed, 4 Mar 2009 10:14:15 -0500
Subject: [c-nsp] VLAN and switch and ?
In-Reply-To: <e353d880903040646t7afaa334yec3ad26b84d1fd7@mail.gmail.com>
References: <e353d880903040646t7afaa334yec3ad26b84d1fd7@mail.gmail.com>
Message-ID: <A1666B81-2A80-47DF-B802-3EEE770FF602@princeton.edu>

Look at layer 2 tunneling for your switches.  You would assign tunnel  
vlan ID and ISP would send tagged traffic into tunnel (Q in Q) and  
traffic would exit tunnel where ever needed.   When you assign a port  
as a tunnel port, it becomes a tunnel-input and tunnel-output.   You  
can have as many tunnel ports as you need.  The ISP can now send what  
ever VLANs they want and you do not need to change anything.
Read the doc and be aware of oversized packet handling within tunnel  
switches.


Jeff Fitzwater
OIT Network Systems
Princeton University

On Mar 4, 2009, at 9:46 AM, Charles Regan wrote:

> Good Morning,
>
> I'll try to explain what I want to do... We are LOCAL NETWORK in  
> this graphic.
> The ISP wants to use our fiber link to connect to his wireless  
> customer.
> We also want internet access from his Wireless Backhaul1.
> ISP also use VLAN on his customer subscriber modules.
>
> How would you configure 2924 Switch and 2960 Switch, so that
> everything is transparent from my side and his side ?
> I don't want him to call me to add a new VLAN on our switch.
>
>
> ISP ---Wireless BackHaul1 -- 2924 Switch ---- FIBER ---- 2960 Switch
> ---- Wireless Backhaul2 ---- Access Point ---- Wireless subscriber
> modules
>                                            |
>             |
>                                            |
>             |
>                                            |
>             |
>                                            |
>             |
>                                            |
>             |
>                             LOCAL NETWORK            LOCAL NETWORK
>
>
> Will something like this work ?
> switchport access vlan 500
> switchport trunk encapsulation dot1q
> switchport mode trunk
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


From mduksa at gmail.com  Wed Mar  4 10:57:17 2009
From: mduksa at gmail.com (Marlon Duksa)
Date: Wed, 4 Mar 2009 07:57:17 -0800
Subject: [c-nsp] Cisco 7600 Router's Default IPSec Throughput Rate
In-Reply-To: <2ED8C866F019B840AD21E8E29AD091CD0CB9E77410@proexc.probil.intl>
References: <3fc686ad0903040112p6760a191r9cb16eb7969d8960@mail.gmail.com>
	<2ED8C866F019B840AD21E8E29AD091CD0CB9E77410@proexc.probil.intl>
Message-ID: <a89d89ac0903040757rf5dbef9s2727e76e91baa8e1@mail.gmail.com>

Serhat - look for "ipsec support on 7600" posting on this list. A similar
question was submitted a several days ago..

On Wed, Mar 4, 2009 at 1:14 AM, Serhat Candan (Probil - ?stanbul) <
serhat.candan at probil.com.tr> wrote:

> Hello All,
>
> I m trying to find a reference guide which has IPSec VPN throughput rates
> of Cisco 7600 router. I m not sure to use VPN SPA or not because of that.
> For example if you have 50 IPSec Sites with low speed such as 128 Kbps, do
> we need to use VPN SPA or just upgrade the IOS of the router by using
> Security Feature enabled IOS?
>
> It would be great to have such a document to determine that need.
>
> Thanks in advance,
>
> Serhat
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From psirt at cisco.com  Wed Mar  4 11:30:00 2009
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Wed, 04 Mar 2009 17:30:00 +0100
Subject: [c-nsp] Cisco Security Advisory: Cisco 7600 Series Router Session
	Border Controller Denial of Service Vulnerability
Message-ID: <200903041732.sbc@psirt.cisco.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cisco Security Advisory: Cisco 7600 Series Router Session Border
                         Controller Denial of Service Vulnerability

Document ID: 109483

Advisory ID: cisco-sa-20090304-sbc

http://www.cisco.com/warp/public/707/cisco-sa-20090304-sbc.shtml

Revision 1.0

For Public Release 2009 March 4 1600 UTC (GMT)

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

Summary
=======

A denial of service (DoS) vulnerability exists in the Cisco Session
Border Controller (SBC) for the Cisco 7600 series routers. Cisco has
released free software updates that address this vulnerability.
Workarounds that mitigate this vulnerability are available.

This advisory is posted at 
http://www.cisco.com/warp/public/707/cisco-sa-20090304-sbc.shtml

Affected Products
=================

Vulnerable Products
+------------------

All Cisco ACE-based SBC modules running software versions prior to
3.0(2) are affected.

To determine the version of the Cisco SBC software running on a
system, log in to the device and issue the show version command to
display the system banner.

    card_A/Admin# show version
      system image file: [LCP] disk0:c76-sbck9-mzg.3.0.1_AS3_0_00.bin
    <output truncated>


Cisco SBC software version 3.0.1 is running in the device used in
this example.

Products Confirmed Not Vulnerable
+--------------------------------

The Cisco XR 12000 Series SBC is not vulnerable. Additionally, the
Cisco ACE Module, Cisco ACE 4710 Application Control Engine, Cisco
ACE XML Gateway, Cisco ACE Web Application Firewall, and the Cisco
ACE GSS (Global Site Selector) 4400 Series are not affected by this
vulnerability. No other Cisco products are currently known to be
affected by this vulnerability.

Details
=======

The Session Border Controller (SBC) enables direct IP-to-IP
interconnect between multiple administrative domains for
session-based services providing protocol interworking, security, and
admission control and management. The SBC is a multimedia device that
sits on the border of a network and controls call admission to that
network. A vulnerability exists in the Cisco SBC where an
unauthenticated attacker may cause the Cisco SBC card to reload by
sending crafted TCP packets over port 2000. Repeated exploitation
could result in a sustained DoS condition.

Note: Only the Cisco SBC module reloads after successful
exploitation. The Cisco 7600 series router does not reload and it is
not affected by this vulnerability.

Note: TCP port 2000 is typically used by Skinny Call Control Protocol
(SCCP) applications. However, the Cisco SBC module uses TCP port 2000
for high availability (redundancy) communication, but does not use
the SCCP for this purpose.

This vulnerability is documented in Cisco Bug IDs CSCsq18958 (
registered customers only) ; and has been assigned the Common
Vulnerability and Exposures (CVE) IDs CVE-2009-0619.

Vulnerability Scoring Details
=============================

Cisco has provided scores for the vulnerability in this advisory
based on the Common Vulnerability Scoring System (CVSS). The CVSS
scoring in this Security Advisory is done in accordance with CVSS
version 2.0.

CVSS is a standards-based scoring method that conveys vulnerability
severity and helps determine urgency and priority of response.

Cisco has provided a base and temporal score. Customers can then
compute environmental scores to assist in determining the impact of
the vulnerability in individual networks.

Cisco has provided an FAQ to answer additional questions regarding
CVSS at

http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html

Cisco has also provided a CVSS calculator to help compute the
environmental impact for individual networks at

http://intellishield.cisco.com/security/alertmanager/cvss

CVSS Base Score - 7.8

Access Vector           - Network
Access Complexity       - Low
Authentication          - None
Confidentiality Impact  - None
Integrity Impact        - None
Availability Impact     - Complete

CVSS Temporal Score - 6.4

Exploitability          - Functional
Remediation Level       - Official-Fix
Report Confidence       - Confirmed

Impact
======

Successful exploitation of the vulnerability may cause a reload of
the affected device. Repeated exploitation could result in a
sustained DoS condition.

Software Versions and Fixes
===========================

This vulnerability has been corrected in Cisco SBC software release
3.0(2).

Cisco SBC software can be downloaded from:

http://www.cisco.com/pcgi-bin/tablebuild.pl/sbc-7600-crypto

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.

Workarounds
===========

As a workaround, configure an access control list (ACL) in the
signaling / media VLAN on the Route Processor (RP). The following
examples show how VLAN 140 is configured as the signaling / media
VLAN. A separate VLAN (VLAN 77) is configured as Fault Tolerance
(FT). An ACL is added to the signaling/media VLAN on the RP filtering
all TCP port 2000 packets to the alias IP address.

Cisco SBC configuration

    interface vlan 140
      ip address 10.140.1.90 255.255.255.0
      alias 10.140.1.100 255.255.255.0
      peer ip address 10.140.1.8 255.255.255.0
    !
    ft interface vlan 77
      ip address 192.168.1.1 255.255.255.0
      peer ip address 192.168.1. 255.255.255.0


RP Configuration

    !- ACL blocking all TCP port 2000 traffic to the 10.140.1.0 internal network
    !
    access-list 100 deny   tcp any host 10.140.1.100 eq 2000
    access-list 100 permit ip any any
    !
    interface Vlan140
     ip address 10.140.1.1 255.255.255.0
    !- ACL is applied to the VLAN interface to egress traffic
      ip access-group 100 out
    !

The alias command under VLAN 140 is configured with an IP address
that floats between active and standby modules when using high
availability. Only TCP port 2000 traffic destined to this IP address
may trigger this vulnerability. An access control list (ACL) is
configured to deny TCP port 2000 destined to the alias IP address
(10.140.1.100). The ACL is applied egress in the RP.

Note: TCP port 2000 is used by Skinny Call Control Protocol (SCCP)
applications; however, in this case it is used by the SBC for
internal communications. The previous ACL only blocks TCP port 2000
traffic to the alias IP address. TCP port 2000 is not used by the
alias IP address. This ACL should not cause any collateral damage.

Additional mitigations that can be deployed on Cisco devices within
the network are available in the Cisco Applied Intelligence companion
document for this Advisory:

http://www.cisco.com/warp/public/707/cisco-amb-20090304-sbc.shtml

Obtaining Fixed Software
========================

Cisco has released free software updates that address this
vulnerability. 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/products/prod_warranties_item09186a008088e31f.html
or as otherwise set forth at Cisco.com Downloads at 
http://www.cisco.com/public/sw-center/sw-usingswc.shtml

Do not contact psirt at cisco.com or security-alert at cisco.com for
software upgrades.

Customers with Service Contracts
+-------------------------------

Customers with contracts should obtain upgraded software through
their regular update channels. For most customers, this means that
upgrades should be obtained through the Software Center on Cisco's
worldwide website at http://www.cisco.com.

Customers using Third Party Support Organizations
+------------------------------------------------

Customers whose Cisco products are provided or maintained through
prior or existing agreements with third-party support organizations,
such as Cisco Partners, authorized resellers, or service providers
should contact that support organization for guidance and assistance
with the appropriate course of action in regards to this advisory.

The effectiveness of any workaround or fix is dependent on specific
customer situations, such as product mix, network topology, traffic
behavior, and organizational mission. Due to the variety of affected
products and releases, customers should consult with their service
provider or support organization to ensure any applied workaround or
fix is the most appropriate for use in the intended network before it
is deployed.

Customers without Service Contracts
+----------------------------------

Customers who purchase direct from Cisco but do not hold a Cisco
service contract, and customers who purchase through third-party
vendors but are unsuccessful in obtaining fixed software through
their point of sale should acquire upgrades by contacting the Cisco
Technical Assistance Center (TAC). TAC contacts are as follows.

  * +1 800 553 2447 (toll free from within North America)
  * +1 408 526 7209 (toll call from anywhere in the world)
  * e-mail: tac at cisco.com

Customers should have their product serial number available and be
prepared to give the URL of this notice as evidence of entitlement to
a free upgrade. Free upgrades for non-contract customers must be
requested through the TAC.

Refer to http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html 
for additional TAC contact information, including localized telephone
numbers, and instructions and e-mail addresses for use in various 
languages.

Exploitation and Public Announcements
=====================================

The Cisco PSIRT is not aware of any public announcements or malicious
use of the vulnerability described in this advisory.

This vulnerability was found during internal testing.

Status of this Notice: FINAL
============================

THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY
KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE
INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS
AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS
DOCUMENT AT ANY TIME.

A stand-alone copy or Paraphrase of the text of this document that
omits the distribution URL in the following section is an
uncontrolled copy, and may lack important information or contain
factual errors.

Distribution
============
 
This advisory is posted on Cisco's worldwide website at :

http://www.cisco.com/warp/public/707/cisco-sa-20090304-sbc.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-March-04 | 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-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkmurgEACgkQ86n/Gc8U/uBrwwCfbQxCcSz4S4X3UpH4Mccg0Df1
KMoAn11BqKmRhw5mUuJOl3D/RrVxVrc7
=m2di
-----END PGP SIGNATURE-----

From ploopster at gmail.com  Wed Mar  4 11:44:16 2009
From: ploopster at gmail.com (Sridhar Ayengar)
Date: Wed, 04 Mar 2009 11:44:16 -0500
Subject: [c-nsp] SSH from router to linux
In-Reply-To: <49AE2468.40001@gmail.com>
References: <49AE2468.40001@gmail.com>
Message-ID: <49AEAFE0.5030306@gmail.com>

Roy wrote:
> I am trying to ssh from a 2811 to linux box.  I telnet to the Cisco and
> issue
> 
> ssh -l root xx.xx.xx.xx
> 
> and I get the password prompt.  I enter that and then logon goes through
> and I get the shell prompt.  The problem is that nothing I type seems to
> get through to linux. 
> 
> Is there some magic I am missing?

Does the TERM environment variable make sense?  Are there any stty lines 
anywhere in your login configuration?

Peace...  Sridhar

From brandon at sterling.net  Wed Mar  4 12:16:29 2009
From: brandon at sterling.net (Brandon Price)
Date: Wed, 04 Mar 2009 09:16:29 -0800
Subject: [c-nsp] 7206 Gig Ethernet Options
In-Reply-To: <49ADA34C.7060309@justinshore.com>
References: <389E7FA0-2001-4038-B225-D4B6C003B593@Princeton.EDU><037901c995ec$4ba3db60$e2eb9220$@net><01c301c99b72$09866730$1c933590$@net>	<6caa2aaf3999544c0ef807111b85a0c8.squirrel@webmail.waveform.net>	<1A9866F953006D45AEE0166066114E0915D78791@TPMAIL02.corp.theplatform.com>
	<49AC6B47.9040805@sterling.net> <49ADA34C.7060309@justinshore.com>
Message-ID: <49AEB76D.6010303@sterling.net>

Justin Shore wrote:
> Brandon Price wrote:
>> Actually, you can install a C7200-I/O-GE+E and save yourself a PA 
>> slot and the associated bandwidth point hit.
>>
>> http://www.gossamer-threads.com/lists/cisco/bba/101247
>
> Now that's something that I did not know.  Any word on if this is 
> actually supported or not?
>
> Justin



* From the NPE G1 datasheet:  http://tinyurl.com/2hlzhg*


"Although a Cisco 7200VXR chassis with an NPE-G1 does not require the 
use of an I/O controller, an I/O controller can still be used. The 
NPE-G1 is supported with the following Cisco 7200 Series I/O controller 
part numbers: C7200-I/O, C7200-I/O-2FE/E, C7200-I/O-GE+E."


Brandon

From csirek at cooler.hu  Wed Mar  4 11:41:05 2009
From: csirek at cooler.hu (Nemeth Laszlo)
Date: Wed, 04 Mar 2009 17:41:05 +0100
Subject: [c-nsp] 6500/Sup720 3BXL and ACK/RST
Message-ID: <49AEAF21.7020606@cooler.hu>

Hi list,

I would like to set a limit in my 6500/Sup720 3BXL RP card to how many 
ACK/RST packets send back to source if this RP get lot of SYN packets 
(flood) to random ports. I think to a magic mls rate-limit command :)

The CoPP not a good idea, because if i use it the CPU make a 100% load 
every 4th minutes (may be it is an IOS bug, i tried it whit 12.2(18)SXF6 ).

Thanks
Laszlo

From lmeade at signal.ca  Wed Mar  4 13:21:39 2009
From: lmeade at signal.ca (Leslie Meade)
Date: Wed, 4 Mar 2009 10:21:39 -0800
Subject: [c-nsp] (no subject)
In-Reply-To: <A1666B81-2A80-47DF-B802-3EEE770FF602@princeton.edu>
References: <e353d880903040646t7afaa334yec3ad26b84d1fd7@mail.gmail.com> 
	<A1666B81-2A80-47DF-B802-3EEE770FF602@princeton.edu>
Message-ID: <EAF4FF4AB2142D499F2F5A3B9D8515290440FC0F@exch-bo.MGVFS.McLeanNet>

I am trying to bridge my 2821 to one ip to give me redundancy.
I am using this config to bridge the two ints and I see gig0/1 up and the bvi up but I am not able to ping it

The original config  gig0/1 had the ip of 10.1.1.6 and I could ping everything and get to everything
Ios C2800NM-IPVOICEK9-M

Any ideas ?


bridge irb 
! 
interface gig0/0.100 
encapsulation dot1Q 100 
bridge-group 100 
! 
interface gig0/1.100 
encapsulation dot1Q 100 
bridge-group 100 
! 
interface BVI100 
ip address 10.1.1.6 255.255.255.0 
no shutdown 
! 
bridge 100 protocol ieee 
bridge 100 route ip

From chris at lavin-llc.com  Wed Mar  4 13:28:07 2009
From: chris at lavin-llc.com (chris at lavin-llc.com)
Date: Wed, 04 Mar 2009 13:28:07 -0500
Subject: [c-nsp] (no subject)
Message-ID: <53311.1236191287@lavin-llc.com>

On Wed Mar  4 13:21 , "Leslie Meade"  sent:

>I am trying to bridge my 2821 to one ip to give me redundancy.
>I am using this config to bridge the two ints and I see gig0/1 up and the bvi up but I am not able to ping it
>
>The original config  gig0/1 had the ip of 10.1.1.6 and I could ping everything and get to everything
>Ios C2800NM-IPVOICEK9-M
>
>Any ideas ?
>
>
>bridge irb 
>! 
>interface gig0/0.100 
>encapsulation dot1Q 100 
>bridge-group 100 
>! 
>interface gig0/1.100 
>encapsulation dot1Q 100 
>bridge-group 100 
>! 
>interface BVI100 
>ip address 10.1.1.6 255.255.255.0 
>no shutdown 
>! 
>bridge 100 protocol ieee 
>bridge 100 route ip


Do you have a default route configured? If you are pinging from a remote subnet you'll need a default route.

-chris


From lmeade at signal.ca  Wed Mar  4 13:33:10 2009
From: lmeade at signal.ca (Leslie Meade)
Date: Wed, 4 Mar 2009 10:33:10 -0800
Subject: [c-nsp] (no subject)
In-Reply-To: <53311.1236191287@lavin-llc.com>
References: <53311.1236191287@lavin-llc.com>
Message-ID: <EAF4FF4AB2142D499F2F5A3B9D8515290440FC1D@exch-bo.MGVFS.McLeanNet>

Yep 
ip route 0.0.0.0 0.0.0.0 10.1.1.220


-----Original Message-----
From: chris at lavin-llc.com [mailto:chris at lavin-llc.com] 
Sent: Wednesday, March 04, 2009 10:28 AM
To: cisco-nsp at puck.nether.net; Leslie Meade
Subject: Re: [c-nsp] (no subject)

On Wed Mar  4 13:21 , "Leslie Meade"  sent:

>I am trying to bridge my 2821 to one ip to give me redundancy.
>I am using this config to bridge the two ints and I see gig0/1 up and the bvi up but I am not able to ping it
>
>The original config  gig0/1 had the ip of 10.1.1.6 and I could ping everything and get to everything
>Ios C2800NM-IPVOICEK9-M
>
>Any ideas ?
>
>
>bridge irb 
>! 
>interface gig0/0.100 
>encapsulation dot1Q 100 
>bridge-group 100 
>! 
>interface gig0/1.100 
>encapsulation dot1Q 100 
>bridge-group 100 
>! 
>interface BVI100 
>ip address 10.1.1.6 255.255.255.0 
>no shutdown 
>! 
>bridge 100 protocol ieee 
>bridge 100 route ip


Do you have a default route configured? If you are pinging from a remote subnet you'll need a default route.

-chris


From MatlockK at exempla.org  Wed Mar  4 13:41:22 2009
From: MatlockK at exempla.org (Matlock, Kenneth L)
Date: Wed, 4 Mar 2009 11:41:22 -0700
Subject: [c-nsp] (no subject)
In-Reply-To: <53311.1236191287@lavin-llc.com>
References: <53311.1236191287@lavin-llc.com>
Message-ID: <4288131ED5E3024C9CD4782CECCAD2C7065D32AC@LMC-MAIL2.exempla.org>

A couple of other things to look for.


1) Where are you trying to ping the 10.1.1.6 IP from? I assume something
on Gi0/1? 
2) Make sure the devices plugged into Gi0/0 and Gi0/1 are either set up
as trunk ports allowing VLAN100, or access ports in VLAN100. (since
you're giving it a dot1q encapsulation on the subints)
3) Make sure that you have a route in the route table for 10.1.1.0/24
going towards this chassis.
4) Make sure you have a valid route back to the destination from this
chassis.
 

Ken Matlock
Network Analyst
Exempla Healthcare
(303) 467-4671
matlockk at exempla.org
-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of
chris at lavin-llc.com
Sent: Wednesday, March 04, 2009 11:28 AM
To: cisco-nsp at puck.nether.net; Leslie Meade
Subject: Re: [c-nsp] (no subject)

On Wed Mar  4 13:21 , "Leslie Meade"  sent:

>I am trying to bridge my 2821 to one ip to give me redundancy.
>I am using this config to bridge the two ints and I see gig0/1 up and
the bvi up but I am not able to ping it
>
>The original config  gig0/1 had the ip of 10.1.1.6 and I could ping
everything and get to everything
>Ios C2800NM-IPVOICEK9-M
>
>Any ideas ?
>
>
>bridge irb 
>! 
>interface gig0/0.100 
>encapsulation dot1Q 100 
>bridge-group 100 
>! 
>interface gig0/1.100 
>encapsulation dot1Q 100 
>bridge-group 100 
>! 
>interface BVI100 
>ip address 10.1.1.6 255.255.255.0 
>no shutdown 
>! 
>bridge 100 protocol ieee 
>bridge 100 route ip


Do you have a default route configured? If you are pinging from a remote
subnet you'll need a default route.

-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 at lavin-llc.com  Wed Mar  4 13:54:17 2009
From: chris at lavin-llc.com (chris at lavin-llc.com)
Date: Wed, 04 Mar 2009 13:54:17 -0500
Subject: [c-nsp] UDP-helper problem
Message-ID: <35870.1236192857@lavin-llc.com>

On Wed Mar  4  8:00 , Michael Robson  sent:

>I have recently moved the routing of a subnet from an old sup2/msfc2  
>6500 (Version 12.1(26)E8, RELEASE SOFTWARE (fc1)) to a newer sup3/ 
>msfc3 6500 (Version 12.2(18)SXF13, RELEASE SOFTWARE (fc1)). On the old  
>router the udp-helper command worked fine, but on the new router I can  
>see the DHCP address coming in but not the reply coming back and the  
>DHCP server isn't seeing the request arriving. Can anyone suggest why  
>this might have stopped working (it isn't an ACL or firewall issue as  
>there aren't any in the way) and I haven't turned _off_ any component  
>of udp-helper (i.e. using the ip forward-protocol command).
>
>interface Vlan937
>  description XXXYYYZZZ
>  ip address w.x.y.z 255.255.255.192
>  ip helper-address a.b.c.d
>

>From this new sup, do you have a route to a.b.c.d? Can you ping the DHCP server from this new sup?


-chris


From kevin at gannons.net  Wed Mar  4 14:08:02 2009
From: kevin at gannons.net (kevin gannon)
Date: Wed, 4 Mar 2009 19:08:02 +0000
Subject: [c-nsp] mpls bgp forwarding ?
In-Reply-To: <5EB9799F396A304686962AFFF740ED0CE96C400F@NOOSLEXCH001.adno.local>
References: <17eef0950903031225m561003d3j302e7b6f4694ca3a@mail.gmail.com>
	<5EB9799F396A304686962AFFF740ED0CE96C400F@NOOSLEXCH001.adno.local>
Message-ID: <17eef0950903041108g4c743fccva00546f37f1c9afa@mail.gmail.com>

I have and it still doesnt show up in a "show mpls forw" however when
I dug deeper
"show ip cef" and "show ip bgp labels" was showing them.

No idea why. It does for eBGP learned routes with a label but not iBGP
learned labels.

Its ipv4 only routes no vpnv4.

Regards
Kevin

On Tue, Mar 3, 2009 at 10:29 PM, Stig Johansen <Stig.Johansen at atea.no> wrote:
>
> Hi there,
>
>>However on R19 I receive the label via eBGP. However I do not install into
>>The MPLS forwarding table but I do not know why ??
>
> You send the labels via BGP, but have you enabled LDP/TDP between R18 and R19? If not, it won't use any labels and consequently not install anything into the LFIB.
>
> Regards,
> Stig Meireles Johansen

From Michael.Robson at manchester.ac.uk  Wed Mar  4 16:27:44 2009
From: Michael.Robson at manchester.ac.uk (Michael Robson)
Date: Wed, 4 Mar 2009 21:27:44 +0000
Subject: [c-nsp] UDP-helper problem
In-Reply-To: <35870.1236192857@lavin-llc.com>
References: <35870.1236192857@lavin-llc.com>
Message-ID: <2B8F519A-BE98-44BA-841D-4C304E19CD11@manchester.ac.uk>

Yes there is a route to a.b.c.d and yes we can ping the DHCP server  
from everywhere, including the new sup.

On 4 Mar 2009, at 18:54, <chris at lavin-llc.com> wrote:

> On Wed Mar  4  8:00 , Michael Robson  sent:
>
>> I have recently moved the routing of a subnet from an old sup2/msfc2
>> 6500 (Version 12.1(26)E8, RELEASE SOFTWARE (fc1)) to a newer sup3/
>> msfc3 6500 (Version 12.2(18)SXF13, RELEASE SOFTWARE (fc1)). On the  
>> old
>> router the udp-helper command worked fine, but on the new router I  
>> can
>> see the DHCP address coming in but not the reply coming back and the
>> DHCP server isn't seeing the request arriving. Can anyone suggest why
>> this might have stopped working (it isn't an ACL or firewall issue as
>> there aren't any in the way) and I haven't turned _off_ any component
>> of udp-helper (i.e. using the ip forward-protocol command).
>>
>> interface Vlan937
>> description XXXYYYZZZ
>> ip address w.x.y.z 255.255.255.192
>> ip helper-address a.b.c.d
>>
>
> From this new sup, do you have a route to a.b.c.d? Can you ping the  
> DHCP server from this new sup?
>
>
> -chris
>


Michael
-- 

Michael Robson           | Tel: +44 (0) 161 275 6113
Senior Network Engineer  | Fax: +44 (0) 161 275 6120
Net North West           | Email: Michael.Robson at manchester.ac.uk


From MatlockK at exempla.org  Wed Mar  4 16:30:08 2009
From: MatlockK at exempla.org (Matlock, Kenneth L)
Date: Wed, 4 Mar 2009 14:30:08 -0700
Subject: [c-nsp] UDP-helper problem
In-Reply-To: <2B8F519A-BE98-44BA-841D-4C304E19CD11@manchester.ac.uk>
References: <35870.1236192857@lavin-llc.com>
	<2B8F519A-BE98-44BA-841D-4C304E19CD11@manchester.ac.uk>
Message-ID: <4288131ED5E3024C9CD4782CECCAD2C7065D32B2@LMC-MAIL2.exempla.org>

Extended ping using the source interface of Vlan937 as well works?

Ken Matlock
Network Analyst
Exempla Healthcare
(303) 467-4671
matlockk at exempla.org
-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Michael Robson
Sent: Wednesday, March 04, 2009 2:28 PM
To: chris at lavin-llc.com
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] UDP-helper problem

Yes there is a route to a.b.c.d and yes we can ping the DHCP server  
from everywhere, including the new sup.

On 4 Mar 2009, at 18:54, <chris at lavin-llc.com> wrote:

> On Wed Mar  4  8:00 , Michael Robson  sent:
>
>> I have recently moved the routing of a subnet from an old sup2/msfc2
>> 6500 (Version 12.1(26)E8, RELEASE SOFTWARE (fc1)) to a newer sup3/
>> msfc3 6500 (Version 12.2(18)SXF13, RELEASE SOFTWARE (fc1)). On the  
>> old
>> router the udp-helper command worked fine, but on the new router I  
>> can
>> see the DHCP address coming in but not the reply coming back and the
>> DHCP server isn't seeing the request arriving. Can anyone suggest why
>> this might have stopped working (it isn't an ACL or firewall issue as
>> there aren't any in the way) and I haven't turned _off_ any component
>> of udp-helper (i.e. using the ip forward-protocol command).
>>
>> interface Vlan937
>> description XXXYYYZZZ
>> ip address w.x.y.z 255.255.255.192
>> ip helper-address a.b.c.d
>>
>
> From this new sup, do you have a route to a.b.c.d? Can you ping the  
> DHCP server from this new sup?
>
>
> -chris
>


Michael
-- 

Michael Robson           | Tel: +44 (0) 161 275 6113
Senior Network Engineer  | Fax: +44 (0) 161 275 6120
Net North West           | Email: Michael.Robson at manchester.ac.uk

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

From deric.kwok2000 at gmail.com  Wed Mar  4 16:44:09 2009
From: deric.kwok2000 at gmail.com (Deric Kwok)
Date: Wed, 4 Mar 2009 16:44:09 -0500
Subject: [c-nsp] VLAN and switch and ?
In-Reply-To: <A1666B81-2A80-47DF-B802-3EEE770FF602@princeton.edu>
References: <e353d880903040646t7afaa334yec3ad26b84d1fd7@mail.gmail.com>
	<A1666B81-2A80-47DF-B802-3EEE770FF602@princeton.edu>
Message-ID: <40d8a95a0903041344v5ebf64ffk1288300312ed7371@mail.gmail.com>

look like L2TP.

Can I know why use it intead of typically vlan?

Thank you

On Wed, Mar 4, 2009 at 10:14 AM, Jeff Fitzwater <jfitz at princeton.edu> wrote:

> Look at layer 2 tunneling for your switches.  You would assign tunnel vlan
> ID and ISP would send tagged traffic into tunnel (Q in Q) and traffic would
> exit tunnel where ever needed.   When you assign a port as a tunnel port, it
> becomes a tunnel-input and tunnel-output.   You can have as many tunnel
> ports as you need.  The ISP can now send what ever VLANs they want and you
> do not need to change anything.
> Read the doc and be aware of oversized packet handling within tunnel
> switches.
>
>
> Jeff Fitzwater
> OIT Network Systems
> Princeton University
>
>
> On Mar 4, 2009, at 9:46 AM, Charles Regan wrote:
>
> Good Morning,
>>
>> I'll try to explain what I want to do... We are LOCAL NETWORK in this
>> graphic.
>> The ISP wants to use our fiber link to connect to his wireless customer.
>> We also want internet access from his Wireless Backhaul1.
>> ISP also use VLAN on his customer subscriber modules.
>>
>> How would you configure 2924 Switch and 2960 Switch, so that
>> everything is transparent from my side and his side ?
>> I don't want him to call me to add a new VLAN on our switch.
>>
>>
>> ISP ---Wireless BackHaul1 -- 2924 Switch ---- FIBER ---- 2960 Switch
>> ---- Wireless Backhaul2 ---- Access Point ---- Wireless subscriber
>> modules
>>                                           |
>>            |
>>                                           |
>>            |
>>                                           |
>>            |
>>                                           |
>>            |
>>                                           |
>>            |
>>                            LOCAL NETWORK            LOCAL NETWORK
>>
>>
>> Will something like this work ?
>> switchport access vlan 500
>> switchport trunk encapsulation dot1q
>> switchport mode trunk
>> _______________________________________________
>> cisco-nsp mailing 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 charles.regan at gmail.com  Wed Mar  4 16:48:02 2009
From: charles.regan at gmail.com (Charles Regan)
Date: Wed, 4 Mar 2009 17:48:02 -0400
Subject: [c-nsp] VLAN and switch and ?
In-Reply-To: <e353d880903041347t77ee09b9n86781038f4724c34@mail.gmail.com>
References: <e353d880903040646t7afaa334yec3ad26b84d1fd7@mail.gmail.com>
	<A1666B81-2A80-47DF-B802-3EEE770FF602@princeton.edu>
	<40d8a95a0903041344v5ebf64ffk1288300312ed7371@mail.gmail.com>
	<e353d880903041347t77ee09b9n86781038f4724c34@mail.gmail.com>
Message-ID: <e353d880903041348h49f2b96awc1009767bcb029e9@mail.gmail.com>

On Wed, Mar 4, 2009 at 5:47 PM, Charles Regan <charles.regan at gmail.com> wrote:
> There's now way my switch will support L2TP.
>
> How would you setup VLAN in this setup.
>
> ISP needs to pass all his vlan (switchport mode trunk)
> I don't want ISP to have access to my network ... (swictchport access
> vlan 500, on both end ?)
> I want Internet acces from this ISP from his BackHaul1. ?(switchport
> access vlan 500, on my gateway router ?)
>
>
>
> On Wed, Mar 4, 2009 at 5:44 PM, Deric Kwok <deric.kwok2000 at gmail.com> wrote:
>> look like L2TP.
>>
>> Can I know why use it intead of typically vlan?
>>
>> Thank you
>>
>> On Wed, Mar 4, 2009 at 10:14 AM, Jeff Fitzwater <jfitz at princeton.edu> wrote:
>>>
>>> Look at layer 2 tunneling for your switches. ?You would assign tunnel vlan
>>> ID and ISP would send tagged traffic into tunnel (Q in Q) and traffic would
>>> exit tunnel where ever needed. ? When you assign a port as a tunnel port, it
>>> becomes a tunnel-input and tunnel-output. ? You can have as many tunnel
>>> ports as you need. ?The ISP can now send what ever VLANs they want and you
>>> do not need to change anything.
>>> Read the doc and be aware of oversized packet handling within tunnel
>>> switches.
>>>
>>>
>>> Jeff Fitzwater
>>> OIT Network Systems
>>> Princeton University
>>>
>>> On Mar 4, 2009, at 9:46 AM, Charles Regan wrote:
>>>
>>>> Good Morning,
>>>>
>>>> I'll try to explain what I want to do... We are LOCAL NETWORK in this
>>>> graphic.
>>>> The ISP wants to use our fiber link to connect to his wireless customer.
>>>> We also want internet access from his Wireless Backhaul1.
>>>> ISP also use VLAN on his customer subscriber modules.
>>>>
>>>> How would you configure 2924 Switch and 2960 Switch, so that
>>>> everything is transparent from my side and his side ?
>>>> I don't want him to call me to add a new VLAN on our switch.
>>>>
>>>>
>>>> ISP ---Wireless BackHaul1 -- 2924 Switch ---- FIBER ---- 2960 Switch
>>>> ---- Wireless Backhaul2 ---- Access Point ---- Wireless subscriber
>>>> modules
>>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
>>>> ? ? ? ? ? ?|
>>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
>>>> ? ? ? ? ? ?|
>>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
>>>> ? ? ? ? ? ?|
>>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
>>>> ? ? ? ? ? ?|
>>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
>>>> ? ? ? ? ? ?|
>>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ?LOCAL NETWORK ? ? ? ? ? ?LOCAL NETWORK
>>>>
>>>>
>>>> Will something like this work ?
>>>> switchport access vlan 500
>>>> switchport trunk encapsulation dot1q
>>>> switchport mode trunk
>>>> _______________________________________________
>>>> cisco-nsp mailing 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 charles.regan at gmail.com  Wed Mar  4 16:48:25 2009
From: charles.regan at gmail.com (Charles Regan)
Date: Wed, 4 Mar 2009 17:48:25 -0400
Subject: [c-nsp] VLAN and switch and ?
In-Reply-To: <e353d880903041348h49f2b96awc1009767bcb029e9@mail.gmail.com>
References: <e353d880903040646t7afaa334yec3ad26b84d1fd7@mail.gmail.com>
	<A1666B81-2A80-47DF-B802-3EEE770FF602@princeton.edu>
	<40d8a95a0903041344v5ebf64ffk1288300312ed7371@mail.gmail.com>
	<e353d880903041347t77ee09b9n86781038f4724c34@mail.gmail.com>
	<e353d880903041348h49f2b96awc1009767bcb029e9@mail.gmail.com>
Message-ID: <e353d880903041348h192919f9x32a68347dd29f24a@mail.gmail.com>

There's now way my switch will support L2TP.

How would you setup VLAN in this setup.

ISP needs to pass all his vlan (switchport mode trunk)
I don't want ISP to have access to my network ... (swictchport access
vlan 500, on both end ?)
I want Internet acces from this ISP from his BackHaul1.  (switchport
access vlan 500, on my gateway router ?)



On Wed, Mar 4, 2009 at 5:48 PM, Charles Regan <charles.regan at gmail.com> wrote:
> On Wed, Mar 4, 2009 at 5:47 PM, Charles Regan <charles.regan at gmail.com> wrote:
>> There's now way my switch will support L2TP.
>>
>> How would you setup VLAN in this setup.
>>
>> ISP needs to pass all his vlan (switchport mode trunk)
>> I don't want ISP to have access to my network ... (swictchport access
>> vlan 500, on both end ?)
>> I want Internet acces from this ISP from his BackHaul1. ?(switchport
>> access vlan 500, on my gateway router ?)
>>
>>
>>
>> On Wed, Mar 4, 2009 at 5:44 PM, Deric Kwok <deric.kwok2000 at gmail.com> wrote:
>>> look like L2TP.
>>>
>>> Can I know why use it intead of typically vlan?
>>>
>>> Thank you
>>>
>>> On Wed, Mar 4, 2009 at 10:14 AM, Jeff Fitzwater <jfitz at princeton.edu> wrote:
>>>>
>>>> Look at layer 2 tunneling for your switches. ?You would assign tunnel vlan
>>>> ID and ISP would send tagged traffic into tunnel (Q in Q) and traffic would
>>>> exit tunnel where ever needed. ? When you assign a port as a tunnel port, it
>>>> becomes a tunnel-input and tunnel-output. ? You can have as many tunnel
>>>> ports as you need. ?The ISP can now send what ever VLANs they want and you
>>>> do not need to change anything.
>>>> Read the doc and be aware of oversized packet handling within tunnel
>>>> switches.
>>>>
>>>>
>>>> Jeff Fitzwater
>>>> OIT Network Systems
>>>> Princeton University
>>>>
>>>> On Mar 4, 2009, at 9:46 AM, Charles Regan wrote:
>>>>
>>>>> Good Morning,
>>>>>
>>>>> I'll try to explain what I want to do... We are LOCAL NETWORK in this
>>>>> graphic.
>>>>> The ISP wants to use our fiber link to connect to his wireless customer.
>>>>> We also want internet access from his Wireless Backhaul1.
>>>>> ISP also use VLAN on his customer subscriber modules.
>>>>>
>>>>> How would you configure 2924 Switch and 2960 Switch, so that
>>>>> everything is transparent from my side and his side ?
>>>>> I don't want him to call me to add a new VLAN on our switch.
>>>>>
>>>>>
>>>>> ISP ---Wireless BackHaul1 -- 2924 Switch ---- FIBER ---- 2960 Switch
>>>>> ---- Wireless Backhaul2 ---- Access Point ---- Wireless subscriber
>>>>> modules
>>>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
>>>>> ? ? ? ? ? ?|
>>>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
>>>>> ? ? ? ? ? ?|
>>>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
>>>>> ? ? ? ? ? ?|
>>>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
>>>>> ? ? ? ? ? ?|
>>>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
>>>>> ? ? ? ? ? ?|
>>>>> ? ? ? ? ? ? ? ? ? ? ? ? ? ?LOCAL NETWORK ? ? ? ? ? ?LOCAL NETWORK
>>>>>
>>>>>
>>>>> Will something like this work ?
>>>>> switchport access vlan 500
>>>>> switchport trunk encapsulation dot1q
>>>>> switchport mode trunk
>>>>> _______________________________________________
>>>>> cisco-nsp mailing 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 Jonathan.Brashear at hq.speakeasy.net  Wed Mar  4 16:55:29 2009
From: Jonathan.Brashear at hq.speakeasy.net (Jonathan Brashear)
Date: Wed, 4 Mar 2009 13:55:29 -0800
Subject: [c-nsp] ASA 5505 multiple netblock functionality
Message-ID: <725755F5E728EE4086DAAF1A54DACF4F0B53DB2B@sea5exbe1.speakeasy.hq>

Apologies if this has been addressed previously, I looked through the last 12 months of c-nsp threads and didn't see this mentioned.

There is some debate going on in my department over a particular implementation and the 5505's capability to handle multiple netblocks. A quick primer on the situation:

Firewall IP: 1.2.3.4(publicly routable, but changing for cust privacy)
Customer netblock: 5.6.7.0/26(it's publicly routable as well, I'm changing for sake of cust privacy)
Customer NAT: 192.168.0.0/24


The /26 is statically routed to 1.2.3.4 from the router level, and the customer wants to run NAT for their internal devices(db servers, etc.). Our implementations guy states that the 5505 can't handle assigning 3+ netblocks because they can't run multiple contexts. My experience with the ASA firewalls is limited so I very well may be wrong, but I believe the 5505s should be able to handle multiple netblocks on the internal side of the firewall using something such as sub-interfaces or similar. Can anyone help explain why this is or isn't feasible?

They don't need to be on the same physical interface necessarily, we can run them to separate physical interfaces because this customer is hairpinned behind a switch(and the servers are connected to said switch instead of the firewall directly) so port density isn't a big issue(to a point).

We can assign a netblock to each internal port on the firewall if need be - which seems to be the best solution from what I'm uncovering - and that works as a reasonable alternative. It doesn't scale very well obviously, but I don't think this customer is going to chew through netblocks at a rate where this will be an issue.

Network Engineer, JNCIS-M
> 214-981-1954 (office) 
> 214-642-4075 (cell)
> jbrashear at hq.speakeasy.net 
http://www.speakeasy.net

From samuel-petreski at uiowa.edu  Wed Mar  4 17:35:14 2009
From: samuel-petreski at uiowa.edu (Petreski, Samuel)
Date: Wed, 4 Mar 2009 16:35:14 -0600
Subject: [c-nsp] FWSM and mixed IPv4/IPv6 access-list
In-Reply-To: <38D04BF3A4B7B2499D19EB1DB54285EA09E904C5@FNB1EX01.gci.com>
References: <Pine.LNX.4.64.0903032025140.10827@whammy.cluebyfour.org>
	<38D04BF3A4B7B2499D19EB1DB54285EA09E904C5@FNB1EX01.gci.com>
Message-ID: <0AF2BA9F8063B34AA9A2201D34DFC7B45FF8B1F25D@IOWAEVS07.iowa.uiowa.edu>

One thing that I have had problems with is sourcing a high number of IPv6
pings (~10K) from the FWSM in routed mode; it makes the FWSM freeze. Don't
do this if you don't have console access. I was running FWSM 4.0.3.

Good luck IPv6ing!

--Samuel


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Leif Sawyer
Sent: Tuesday, March 03, 2009 7:56 PM
To: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] FWSM and mixed IPv4/IPv6 access-list

Justin M. Streiner writes in reply to:
> On Tue, 3 Mar 2009, Leif Sawyer wrote:
> 
>> Is anybody working with FWSM's and mixed-mode IPv4+IPv6 ACL's?
>> 
>> I'm having trouble with traceroute6 not succeeding, but 
>> ping6 working fine:
> 
> You might be getting caught by flawed behavior of the FWSM.  
> I've run into something similar with straight v4 firewall 
> zones where certain flavors of traceroute will be dropped by 
> the blade.  When it was first reported to us, we thought is 
> was a broken fixup, but the behavior persisted after the 
> fixup was disabled.  No word on a fix from Cisco.

Hrm.  I guess it's time to open a ticket, then.  
Damn. I hate dealing with TAC on complex issues.

And it's not like CiscoPress is up-to-date.  what, 6 pages on Ipv6
in the FWSM manual? friggin joke.

 
> On a somewhat unrelated note, how has the v6 performance been 
> on the FWSMs for you?  Everything I've heard from Cisco and 
> other sources suggests that the v6 packets are much more 
> expensive for the FWSM to forward, so performance would 
> suffer greatly.

Just starting to roll this out, so no load to speak of.

Can't wait to see what next issue creeps up!
_______________________________________________
cisco-nsp mailing 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: smime.p7s
Type: application/x-pkcs7-signature
Size: 3175 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090304/6ca781f0/attachment-0001.bin>

From deric.kwok2000 at gmail.com  Wed Mar  4 17:35:33 2009
From: deric.kwok2000 at gmail.com (Deric Kwok)
Date: Wed, 4 Mar 2009 17:35:33 -0500
Subject: [c-nsp] VLAN and switch and ?
In-Reply-To: <e353d880903041348h192919f9x32a68347dd29f24a@mail.gmail.com>
References: <e353d880903040646t7afaa334yec3ad26b84d1fd7@mail.gmail.com>
	<A1666B81-2A80-47DF-B802-3EEE770FF602@princeton.edu>
	<40d8a95a0903041344v5ebf64ffk1288300312ed7371@mail.gmail.com>
	<e353d880903041347t77ee09b9n86781038f4724c34@mail.gmail.com>
	<e353d880903041348h49f2b96awc1009767bcb029e9@mail.gmail.com>
	<e353d880903041348h192919f9x32a68347dd29f24a@mail.gmail.com>
Message-ID: <40d8a95a0903041435n51afa718qe90074f2f957ca1c@mail.gmail.com>

Hi

I only have l2tp configuration in linux router. Here is below.

Pls note that i don't know Jeff suggestion how L2tp works out in your
network
it looks like his suggestion is same as L2tp so that I post to ask him

I only know this l2tp worked in my setting before when doing in DSL

HTH

!
interface Ethernet0
 no ip address
 speed 1000
 duplex full
!
interface Ethernet0.120
 description vlan120
 ip address 10.0.0.6 255.255.255.252
!
interface Ethernet0.130
 description vlan130
 ip address 10.0.0.74 255.255.255.252
!
interface Ethernet0.140
 description vlan140
 ip address 10.0.0.54 255.255.255.252
!
!
interface Tunnel1
 description vlan120
 tunnel mode l2tp
 tunnel peer name xxxx
 tunnel local name deric
 tunnel key kwok
 tunnel virtual-template 1
!
interface Tunnel2
 description vlan130
 tunnel mode l2tp
 tunnel peer name xxxx
 tunnel local name deric
 tunnel key kwok
 tunnel virtual-template 1
!
interface Tunnel3
 description vlan140
 tunnel mode l2tp
 tunnel peer name xxxx
 tunnel local name deric
 tunnel key kwok
 tunnel virtual-template 1
!



On Wed, Mar 4, 2009 at 4:48 PM, Charles Regan <charles.regan at gmail.com>wrote:

> There's now way my switch will support L2TP.
>
> How would you setup VLAN in this setup.
>
> ISP needs to pass all his vlan (switchport mode trunk)
> I don't want ISP to have access to my network ... (swictchport access
> vlan 500, on both end ?)
> I want Internet acces from this ISP from his BackHaul1.  (switchport
> access vlan 500, on my gateway router ?)
>
>
>
>  On Wed, Mar 4, 2009 at 5:48 PM, Charles Regan <charles.regan at gmail.com>
> wrote:
> > On Wed, Mar 4, 2009 at 5:47 PM, Charles Regan <charles.regan at gmail.com>
> wrote:
> >> There's now way my switch will support L2TP.
> >>
> >> How would you setup VLAN in this setup.
> >>
> >> ISP needs to pass all his vlan (switchport mode trunk)
> >> I don't want ISP to have access to my network ... (swictchport access
> >> vlan 500, on both end ?)
> >> I want Internet acces from this ISP from his BackHaul1.  (switchport
> >> access vlan 500, on my gateway router ?)
> >>
> >>
> >>
> >> On Wed, Mar 4, 2009 at 5:44 PM, Deric Kwok <deric.kwok2000 at gmail.com>
> wrote:
> >>> look like L2TP.
> >>>
> >>> Can I know why use it intead of typically vlan?
> >>>
> >>> Thank you
> >>>
> >>> On Wed, Mar 4, 2009 at 10:14 AM, Jeff Fitzwater <jfitz at princeton.edu>
> wrote:
> >>>>
> >>>> Look at layer 2 tunneling for your switches.  You would assign tunnel
> vlan
> >>>> ID and ISP would send tagged traffic into tunnel (Q in Q) and traffic
> would
> >>>> exit tunnel where ever needed.   When you assign a port as a tunnel
> port, it
> >>>> becomes a tunnel-input and tunnel-output.   You can have as many
> tunnel
> >>>> ports as you need.  The ISP can now send what ever VLANs they want and
> you
> >>>> do not need to change anything.
> >>>> Read the doc and be aware of oversized packet handling within tunnel
> >>>> switches.
> >>>>
> >>>>
> >>>> Jeff Fitzwater
> >>>> OIT Network Systems
> >>>> Princeton University
> >>>>
> >>>> On Mar 4, 2009, at 9:46 AM, Charles Regan wrote:
> >>>>
> >>>>> Good Morning,
> >>>>>
> >>>>> I'll try to explain what I want to do... We are LOCAL NETWORK in this
> >>>>> graphic.
> >>>>> The ISP wants to use our fiber link to connect to his wireless
> customer.
> >>>>> We also want internet access from his Wireless Backhaul1.
> >>>>> ISP also use VLAN on his customer subscriber modules.
> >>>>>
> >>>>> How would you configure 2924 Switch and 2960 Switch, so that
> >>>>> everything is transparent from my side and his side ?
> >>>>> I don't want him to call me to add a new VLAN on our switch.
> >>>>>
> >>>>>
> >>>>> ISP ---Wireless BackHaul1 -- 2924 Switch ---- FIBER ---- 2960 Switch
> >>>>> ---- Wireless Backhaul2 ---- Access Point ---- Wireless subscriber
> >>>>> modules
> >>>>>                                           |
> >>>>>            |
> >>>>>                                           |
> >>>>>            |
> >>>>>                                           |
> >>>>>            |
> >>>>>                                           |
> >>>>>            |
> >>>>>                                           |
> >>>>>            |
> >>>>>                            LOCAL NETWORK            LOCAL NETWORK
> >>>>>
> >>>>>
> >>>>> Will something like this work ?
> >>>>> switchport access vlan 500
> >>>>> switchport trunk encapsulation dot1q
> >>>>> switchport mode trunk
> >>>>> _______________________________________________
> >>>>> cisco-nsp mailing 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 lmeade at signal.ca  Wed Mar  4 17:49:57 2009
From: lmeade at signal.ca (Leslie Meade)
Date: Wed, 4 Mar 2009 14:49:57 -0800
Subject: [c-nsp] BVI issues
In-Reply-To: <3e4b8fe10903041407i4e984498lf0dbbc2e7d819d16@mail.gmail.com>
References: <e353d880903040646t7afaa334yec3ad26b84d1fd7@mail.gmail.com>	 
	<A1666B81-2A80-47DF-B802-3EEE770FF602@princeton.edu>	 
	<EAF4FF4AB2142D499F2F5A3B9D8515290440FC0F@exch-bo.MGVFS.McLeanNet> 
	<3e4b8fe10903041407i4e984498lf0dbbc2e7d819d16@mail.gmail.com>
Message-ID: <EAF4FF4AB2142D499F2F5A3B9D8515290450322B@exch-bo.MGVFS.McLeanNet>

Thanks guys I have worked it out.

I left this command out...

 

bridge 100 route ip

 

Thanks for your help

 

From: Rich Davies [mailto:rich.davies at gmail.com] 
Sent: Wednesday, March 04, 2009 2:08 PM
To: Leslie Meade
Subject: Re: [c-nsp] (no subject)

 

Leslie,

A handy command I used to use when troubleshooting BVI's was:

show bridge verbose

This was able to show me the L2 info (MAC) of members of the BVI.
Hopefully you can do a "show arp" and see the MAC addy of 10.1.1.6 and
then also check the "show bridge verbose" to also see the MAC within the
BVI.   Hope this helps.   Your config does look good.


-Rich



On Wed, Mar 4, 2009 at 1:21 PM, Leslie Meade <lmeade at signal.ca> wrote:

I am trying to bridge my 2821 to one ip to give me redundancy.
I am using this config to bridge the two ints and I see gig0/1 up and
the bvi up but I am not able to ping it

The original config  gig0/1 had the ip of 10.1.1.6 and I could ping
everything and get to everything
Ios C2800NM-IPVOICEK9-M

Any ideas ?


bridge irb
!
interface gig0/0.100
encapsulation dot1Q 100
bridge-group 100
!
interface gig0/1.100
encapsulation dot1Q 100
bridge-group 100
!
interface BVI100
ip address 10.1.1.6 255.255.255.0
no shutdown
!
bridge 100 protocol ieee
bridge 100 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 vincent.aniello at pipelinefinancial.com  Wed Mar  4 18:23:49 2009
From: vincent.aniello at pipelinefinancial.com (Vincent Aniello)
Date: Wed, 4 Mar 2009 18:23:49 -0500
Subject: [c-nsp] CPU utilization on a Cisco 3560E switch
Message-ID: <9DF561416307E245950A6E212A55367A04BFCB61@EMAILSRV1.exad.net>

We have two Cisco 3560E switches that during the day when the network
traffic load is high run at about 40% CPU utilization.   This is much
higher than on our other 3650E switches that sit at about 10% CPU
utilization even when the network traffic load is high.

 

What I have noticed is that when I log into the switch with the 40% CPU
utilization, either via SSH or through the console, the CPU utilization
drops to 10% and stays there as long as I remain logged into the switch.
Once I log out the CPU utilization goes back up to 40%.  

 

Unfortunately, it is difficult to see what process is causing the high
CPU utilization since it drops down when we are logged into the switch.

 

Has anyone else experienced this behavior?  The switch is running IOS
version 12.2(46)SE.

 

We are tracking the CPU utilization through MRTG.

 

Thanks.

 

--Vincent

 

 

 

 

 



Disclaimer: Any references to Pipeline performance contained herein are based on internal testing and / or historic performance levels which Pipeline expects to maintain or exceed but nevertheless does not guarantee.  Congested networks, price volatility, or other extraordinary events may impede future trading activities and degrade performance statistics. Pipeline is a member of FINRA and SIPC.

From mksmith at adhost.com  Wed Mar  4 18:49:38 2009
From: mksmith at adhost.com (Michael K. Smith - Adhost)
Date: Wed, 4 Mar 2009 15:49:38 -0800
Subject: [c-nsp] ASA 5505 multiple netblock functionality
In-Reply-To: <725755F5E728EE4086DAAF1A54DACF4F0B53DB2B@sea5exbe1.speakeasy.hq>
References: <725755F5E728EE4086DAAF1A54DACF4F0B53DB2B@sea5exbe1.speakeasy.hq>
Message-ID: <17838240D9A5544AAA5FF95F8D520316059759E4@ad-exh01.adhost.lan>

Hello Jonathan:

You can have multiple subnets defined on the statics from the outside with no problem, routed as you described.  Such as:

static (inside,outside) 5.1.1.1 192.168.0.1
static (inside,outside) 6.2.2.2 192.168.0.2

If you have multiple inside subnets they would have to be on their own VLAN's, provided you have a license that allows that configuration.  I think you need Security Plus for more than two VLAN's (i.e. inside and outside).  With that configuration you would have something like:

interface vlan 1
ip address 192.168.0.1 255.255.255.0
nameif inside

interface vlan 2
ip address 1.2.3.4 255.255.255.0
nameif outside

interface vlan 3
ip address 192.168.1.1 255.255.255.0
nameif dmz

Then you can add statics for the 192.168.1.0/24 subnet as well.  You *can't* have two different attached subnets on the same VLAN interface, such as:

interface vlan 1
ip address 192.168.0.1 255.255.255.0
ip address 192.168.1.1 255.255.255.0 secondary
nameif inside

Regards,

Mike

> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> bounces at puck.nether.net] On Behalf Of Jonathan Brashear
> Sent: Wednesday, March 04, 2009 1:55 PM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] ASA 5505 multiple netblock functionality
> 
> Apologies if this has been addressed previously, I looked through the last 12
> months of c-nsp threads and didn't see this mentioned.
> 
> There is some debate going on in my department over a particular
> implementation and the 5505's capability to handle multiple netblocks. A quick
> primer on the situation:
> 
> Firewall IP: 1.2.3.4(publicly routable, but changing for cust privacy)
> Customer netblock: 5.6.7.0/26(it's publicly routable as well, I'm changing for
> sake of cust privacy)
> Customer NAT: 192.168.0.0/24
> 
> 
> The /26 is statically routed to 1.2.3.4 from the router level, and the
> customer wants to run NAT for their internal devices(db servers, etc.). Our
> implementations guy states that the 5505 can't handle assigning 3+ netblocks
> because they can't run multiple contexts. My experience with the ASA firewalls
> is limited so I very well may be wrong, but I believe the 5505s should be able
> to handle multiple netblocks on the internal side of the firewall using
> something such as sub-interfaces or similar. Can anyone help explain why this
> is or isn't feasible?
> 
> They don't need to be on the same physical interface necessarily, we can run
> them to separate physical interfaces because this customer is hairpinned
> behind a switch(and the servers are connected to said switch instead of the
> firewall directly) so port density isn't a big issue(to a point).
> 
> We can assign a netblock to each internal port on the firewall if need be -
> which seems to be the best solution from what I'm uncovering - and that works
> as a reasonable alternative. It doesn't scale very well obviously, but I don't
> think this customer is going to chew through netblocks at a rate where this
> will be an issue.
> 
> Network Engineer, JNCIS-M
> > 214-981-1954 (office)
> > 214-642-4075 (cell)
> > jbrashear at hq.speakeasy.net
> http://www.speakeasy.net
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 474 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090304/e3054e5d/attachment.bin>

From Carlos.Bulleri at matsci.com  Wed Mar  4 20:57:09 2009
From: Carlos.Bulleri at matsci.com (Bulleri, Carlos)
Date: Wed, 4 Mar 2009 19:57:09 -0600
Subject: [c-nsp]  6500 not exporting layer 2 netflow data
Message-ID: <EE3BD7EE588FFD4B9B0B6B5CDA91CFAC02BECDCFE6@msc-egv-exch.matsci.com>

Have you found a solution to this problem? I have the exact same problem except that our 6500 router has a Sup2 with a MSCFC2 and we are running 12.2(18) SFX11, I can see the Bridge captured data but nothing is being exported to the Netflow server, only the routed information.

I'm considering upgrading to the SFX15 version but I would like your input first.

Thanks



Carlos Bulleri
Network Engineer
(847) 439-2210 ext. 8225
Carlos.Bulleri at matsci.com<mailto:Carlos.Bulleri at matsci.com>




From jeff-kell at utc.edu  Wed Mar  4 21:49:22 2009
From: jeff-kell at utc.edu (Jeff Kell)
Date: Wed, 04 Mar 2009 21:49:22 -0500
Subject: [c-nsp] 100Mb fiber aggregation/conversion/etc
Message-ID: <49AF3DB2.9080207@utc.edu>

We have a couple of areas with a need to aggregate some legacy 100FX/MM 
fiber runs.  There are three different housing clusters that are 
currently all 100FX uplinks, and 100FX back to campus.  In two areas we 
have small IDFs with 100FX back to a common plant back to campus over 
100FX, one of them aggregates on some old 2912MF-XLs, another has a set 
of 2924XLs with the fiber "daisy-chained" with loops at the MDF to 
create one long (way too many hops) chain through the IDFs.  It's old, 
but sparsely populated, and we're not looking at upgrading the IDFs just 
yet.

I'd like to use some new SM runs to the complexes to get a gigabit back 
to campus, and aggregate the 100FX "somehow".  Having the option to 
later upgrade to gig from the IDFs is a plus, but not a requirement.  I 
see the Cisco-ish options as:

* pick up some used 2912MF-XLs for spares, and try to locate a couple of 
the gigabit uplink modules for the uplinks, but that freezes the 100FX,
* pick up some used 4912s, 3508XLs, or 3550-12s and try to locate some 
cheap 100FX GBIC modules for the IDFs,
* forklift the IDFs too and just do gig (really out of our budget)

Otherwise, we could just pick up some media converters (100FX to TX) and 
aggregate the buildings with any 100Mb switch with a 1G fiber uplink.  
We have one of these rack-mounts (12 or 16 slots for converter modules) 
in the data center from another consolidation project, but it was 
"provided" for us and I don't have the original bids / specs.

Anyone have any suggestions, particularly for the media converter 
modules?  Don't need high-density, the worst-case would be 22 lines (if 
we consolidated both 2912MFs in the modular apartments), but need "more 
than 6" each place.

Jeff

From justin at justinshore.com  Thu Mar  5 01:27:22 2009
From: justin at justinshore.com (Justin Shore)
Date: Thu, 05 Mar 2009 00:27:22 -0600
Subject: [c-nsp] Conflicting OSPF router-ids in separate VRFs
Message-ID: <49AF70CA.6070007@justinshore.com>

I'm trying to get multiple OSPF instances to work in separate VRFs with 
all OSPF instances using the same router-id.  We're offering a VPN 
tunnel service to access offsite bit-for-bit data copy services in our 
Data Center.  The tunnel of choice is a GRE tunnel with IPSec 
protection.  The GRE tunnel interface is inside a unique VRF per 
customer.  The IP subnet used in each VRF for this product offering is 
identical, as is the interface IPs on the tunnel interfaces.  This makes 
the config templates as simple as possible since all sites are 
essentially identical from our perspective.

I have OSPF configured inside the VRF in question.  This is the first of 
the production GRE tunnels we've turned up for this product offering. 
Tunnel2999 is my beta tunnel and Tunnel3013 is the production tunnel:

Neighbor ID     Pri   State           Dead Time   Address         Interface
%OSPF: Router process 3013 is not running, please configure a router-id
192.168.100.1     0   FULL/  -        00:00:38    10.125.124.2    Tunnel2999


The problem I'm running into is that OSPF will not run on the production 
tunnel because it's IP conflicts with the IP in my beta tunnel in a 
separate VRF.  When I try to configure OSPF in the production VRF with 
the interface IP of the tunnel I get an error:

7613-1(config-router)#router-id 10.125.124.1
OSPF: router-id 10.125.124.1 in use by ospf process 2999

router ospf 2999 vrf dc-gre-test
  ignore lsa mospf
  ispf
  log-adjacency-changes
  redistribute bgp 65001 subnets
  passive-interface default
  no passive-interface Tunnel2999
  network 10.125.124.0 0.0.0.3 area 0
  network 10.125.125.0 0.0.0.255 area 0


router ospf 3013 vrf dc-customer-vrf
  ignore lsa mospf
  ispf
  log-adjacency-changes
  redistribute bgp 65001 subnets
  passive-interface default
  no passive-interface Tunnel3013
  network 10.125.124.0 0.0.0.3 area 0
  network 10.125.125.0 0.0.0.255 area 0


Is there some magic trick to making OSPF on a 7600 running SRB1 be truly 
  VRF-aware?  OSPF instances in separate VRFs shouldn't IP conflict with 
router-ids in other VRFs.  If they did then what's the point of VRF 
separation?  Any thoughts before I call TAC?

Thanks
  Justin

From justin at justinshore.com  Thu Mar  5 01:34:25 2009
From: justin at justinshore.com (Justin Shore)
Date: Thu, 05 Mar 2009 00:34:25 -0600
Subject: [c-nsp] MPLS LDP and BGP Neighbor flapping constantly
Message-ID: <49AF7271.40507@justinshore.com>

This afternoon I stumbled across a problem with a LDP session between a 
7613 and a 7201.  Actually both LDP and iBGP were flapping every 10 
seconds or so.  I had both interfaces configured for MPLS, LDP, IS-IS 
(with AUTH and BFD though BFD isn't enabled on the interface itself yet) 
with an interface MTU of 9000 and CLNS MTU of 1496.  Nothing too fancy. 
  The systems as a whole are configured with MPLS graceful-restart, LDP, 
no mpls ip propagate-ttl, and LDP router-ID on a loopback:

# 7201
mpls label protocol ldp
no mpls ip propagate-ttl
mpls ldp graceful-restart
mpls ldp router-id Loopback0 force

# 7613
mls mpls tunnel-recir
mpls traffic-eng tunnels
mpls ldp graceful-restart
no mpls ip propagate-ttl
mpls label protocol ldp
mpls ldp router-id Loopback0 force

This morning at 7:05 the router stopped responding to SNMP queries for 
about 15m.  The load was about 13 before.  Cacti shows the load doubling 
in the 10m prior to the 15m of nothing.  When it came back the load was 
just shy of 50 and stayed there for about 30m.  After that it stayed at 
around 30-35 for the next 7.5hrs before I noticed the BGP flapping issue 
and shutdown the peer for troubleshooting.  The load dropped back to 
around 16, higher than it was before the hiccup this morning.  I'm at a 
loss to adequately explain why the load has been so jacked.  I think the 
30-35 load was because BGP flapping and the slightly higher load now is 
due to the LDP flapping issue.  That's my best guess.

Anyone know how to troubleshoot a LDP neighbor flapping issue?  The 7613 
is logging this:

730278: Mar  4 20:43:48.696 CST: LDP GR: Received FT Sess TLV from 
10.64.0.34:0  (fl 0x1, rs 0x0, rconn 0, rcov 120000)
730279: Mar  4 20:43:48.696 CST: LDP GR: MFI cutover wait delay = 
600000, Forwarding State Hold Timer = 600000
730280: Mar  4 20:43:48.696 CST: LDP GR: searching for down nbr record 
(10.64.0.34:0, 10.64.0.178)
730281: Mar  4 20:43:48.696 CST: LDP GR: Added FT Sess TLV (Rconn 
120000, Rcov 0) to INIT msg to 10.64.0.34:0

The 7201 is logging this:

054705: Mar  5 00:28:19.599 CST: LDP GR: GR session 10.64.0.20:0:: lost
054706: Mar  5 00:28:19.599 CST: LDP GR: down nbr 10.64.0.20:0:: created 
[1 total]
054707: Mar  5 00:28:19 CST: %LDP-5-GR: GR session 10.64.0.20:0 (inst. 
3): interrupted--recovery pending
054708: Mar  5 00:28:19.599 CST: LDP GR: GR session 10.64.0.20:0:: 
bindings retained
054709: Mar  5 00:28:19.599 CST: LDP GR: down nbr 10.64.0.20:0:: state 
change (None -> Reconnect-Wait)
054710: Mar  5 00:28:19.599 CST: LDP GR: down nbr 10.64.0.20:0:: 
reconnect timer started [120000 msecs]
054711: Mar  5 00:28:19.599 CST: LDP GR: down nbr 10.64.0.20:0:: added 
to bindings task queue [1 entries]
054712: Mar  5 00:28:19 CST: %LDP-5-NBRCHG: LDP Neighbor 10.64.0.20:0 
(0) is DOWN (Received error notification from peer: Shut down)

054713: Mar  5 00:28:25.923 CST: LDP GR: searching for down nbr record 
(10.64.0.20:0, 10.64.0.179)
054714: Mar  5 00:28:25.923 CST: LDP GR: search for down nbr record 
(10.64.0.20:0, 10.64.0.179) returned 10.64.0.20:0
054715: Mar  5 00:28:25.923 CST: LDP GR: Added FT Sess TLV (Rconn 0, 
Rcov 120000) to INIT msg to 10.64.0.20:0
054716: Mar  5 00:28:25.947 CST: LDP GR: Received FT Sess TLV from 
10.64.0.20:0  (fl 0x1, rs 0x0, rconn 120000, rcov 0)
054717: Mar  5 00:28:25.947 CST: LDP GR: GR session 10.64.0.20:0:: 
established
054718: Mar  5 00:28:25.947 CST: LDP GR: GR session 10.64.0.20:0:: found 
down nbr 10.64.0.20:0
054719: Mar  5 00:28:25.947 CST: LDP GR: down nbr 10.64.0.20:0:: 
reconnect timer stopped
054720: Mar  5 00:28:25.947 CST: LDP GR: down nbr 10.64.0.20:0:: state 
change (Reconnect-Wait -> Recovering)
054721: Mar  5 00:28:25.947 CST: LDP GR: down nbr 10.64.0.20:0:: 
recovery timer started [1 msecs]
054722: Mar  5 00:28:25 CST: %LDP-5-GR: GR session 10.64.0.20:0 (inst. 
4): starting graceful recovery
054723: Mar  5 00:28:25 CST: %LDP-5-NBRCHG: LDP Neighbor 10.64.0.20:0 
(4) is UP
054724: Mar  5 00:28:25.951 CST: LDP GR: down nbr 10.64.0.20:0:: 
recovery timer expired
054725: Mar  5 00:28:25 CST: %LDP-5-GR: GR session 10.64.0.20:0 (inst. 
4): completed graceful recovery
054726: Mar  5 00:28:25.951 CST: LDP GR: down nbr 10.64.0.20:0:: 
destroying record [0 left]
054727: Mar  5 00:28:25.951 CST: LDP GR: down nbr 10.64.0.20:0:: state 
change (Recovering -> Delete-Wait)

054728: Mar  5 00:28:28.091 CST: LDP GR: Tagcon querying for up to 12 
bindings update tasks [table 0]
054729: Mar  5 00:28:28.091 CST: LDP GR: down nbr 10.64.0.20:0:: 
requesting bindings DEL for {10.64.0.20:0, 3}
054730: Mar  5 00:28:28.091 CST: LDP GR: down nbr 10.64.0.20:0:: removed 
from bindings task queue [0 entries]
054731: Mar  5 00:28:28.091 CST: LDP GR: Requesting 1 bindings update 
tasks [0 left in queue]

10.64.0.20 is a loopback on the 7613 and 10.64.0.34 is a loopback on the 
7201.

I do have some interface errors which I also can't explain.  They do not 
appear to be incrementing though.  7613:

GigabitEthernet9/1 is up, line protocol is up (connected)
   Hardware is C6k 1000Mb 802.3, address is 001a.3063.0a80 (bia 
001a.3063.0a80)
   Description: TO 2821-2.dc Gi0/0
   Internet address is 10.64.0.179/31
   MTU 9000 bytes, BW 1000000 Kbit, DLY 10 usec,
      reliability 255/255, txload 1/255, rxload 1/255
   Encapsulation ARPA, loopback not set
   Keepalive set (10 sec)
   Full-duplex, 1000Mb/s
   input flow-control is off, output flow-control is off
   Clock mode is auto
   ARP type: ARPA, ARP Timeout 04:00:00
   Last input 00:00:02, output 00:00:00, output hang never
   Last clearing of "show interface" counters never
   Input queue: 0/75/1936665/7581 (size/max/drops/flushes); Total output 
drops: 4
   Queueing strategy: fifo
   Output queue: 0/40 (size/max)
   5 minute input rate 49000 bits/sec, 17 packets/sec
   5 minute output rate 56000 bits/sec, 24 packets/sec
   L2 Switched: ucast: 52903876 pkt, 3771470311 bytes - mcast: 15056043 
pkt, 1653756471 bytes
   L3 in Switched: ucast: 80170438 pkt, 12709078926 bytes - mcast: 0 
pkt, 0 bytes mcast
   L3 out Switched: ucast: 185161821 pkt, 36022953056 bytes mcast: 0 
pkt, 0 bytes
      150040994 packets input, 30087625055 bytes, 0 no buffer
      Received 15660647 broadcasts (0 IP multicasts)
      30 runts, 4247159 giants, 0 throttles
      1929071 input errors, 68 CRC, 0 frame, 13 overrun, 0 ignored
      0 watchdog, 0 multicast, 0 pause input
      0 input packets with dribble condition detected
      257650143 packets output, 64726258058 bytes, 0 underruns
      2 output errors, 0 collisions, 2 interface resets
      0 babbles, 0 late collision, 0 deferred
      0 lost carrier, 0 no carrier, 0 PAUSE output
      0 output buffer failures, 0 output buffers swapped out

7201:
GigabitEthernet0/0 is up, line protocol is up
   Hardware is MV64460 Internal MAC, address is 0023.5ee9.ac1b (bia 
0023.5ee9.ac1b)
   Description: TO 7613-2.clr Gi9/1
   Internet address is 10.64.0.178/31
   MTU 9000 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
      reliability 255/255, txload 1/255, rxload 1/255
   Encapsulation ARPA, loopback not set
   Keepalive set (10 sec)
   Full-duplex, 1000Mb/s, media type is RJ45
   output flow-control is XON, input flow-control is unsupported
   ARP type: ARPA, ARP Timeout 04:00:00
   Last input 00:00:00, output 00:00:00, output hang never
   Last clearing of "show interface" counters never
   Input queue: 0/75/3951/0 (size/max/drops/flushes); Total output drops: 6
   Queueing strategy: fifo
   Output queue: 0/40 (size/max)
   5 minute input rate 45000 bits/sec, 19 packets/sec
   5 minute output rate 64000 bits/sec, 13 packets/sec
      51466122 packets input, 1916487584 bytes, 0 no buffer
      Received 1891956 broadcasts, 0 runts, 0 giants, 0 throttles
      5 input errors, 0 CRC, 0 frame, 0 overrun, 5 ignored
      0 watchdog, 2247902 multicast, 0 pause input
      0 input packets with dribble condition detected
      32927369 packets output, 1549013167 bytes, 0 underruns
      8 output errors, 0 collisions, 1 interface resets
      23 unknown protocol drops
      23 unknown protocol drops
      0 babbles, 0 late collision, 0 deferred
      8 lost carrier, 0 no carrier, 0 pause output
      0 output buffer failures, 0 output buffers swapped out


Any thoughts as to what's going on here?  I can't tell for certain which 
of the 2 routers is causing LDP and BGP to drop.  Knowing that would 
help me narrow my troubleshooting focus.  The 7600 is running SRB1 and 
the 7201 is running 12.4(15)T7.

Thanks
  Justin


From blahu77 at gmail.com  Thu Mar  5 03:23:48 2009
From: blahu77 at gmail.com (Mateusz Blaszczyk)
Date: Thu, 5 Mar 2009 08:23:48 +0000
Subject: [c-nsp] Conflicting OSPF router-ids in separate VRFs
In-Reply-To: <49AF70CA.6070007@justinshore.com>
References: <49AF70CA.6070007@justinshore.com>
Message-ID: <383357750903050023o665dc660uc037b8811d4fc448@mail.gmail.com>

2009/3/5 Justin Shore <justin at justinshore.com>:
> I'm trying to get multiple OSPF instances to work in separate VRFs with all
> OSPF instances using the same router-id.

As you noticed it won't work

[...]

> I have OSPF configured inside the VRF in question. ?This is the first of the
> production GRE tunnels we've turned up for this product offering. Tunnel2999
> is my beta tunnel and Tunnel3013 is the production tunnel:
>
> Neighbor ID ? ? Pri ? State ? ? ? ? ? Dead Time ? Address ? ? ? ? Interface
> %OSPF: Router process 3013 is not running, please configure a router-id
> 192.168.100.1 ? ? 0 ? FULL/ ?- ? ? ? ?00:00:38 ? ?10.125.124.2 ? ?Tunnel2999

[...]

> 7613-1(config-router)#router-id 10.125.124.1
> OSPF: router-id 10.125.124.1 in use by ospf process 2999

Since router-id doesn't have to be any configured IP on the box you
could do something like below and still have a "good" template.

router ospf 2999 vrf bla1
  router-id 2.9.9.9

router ospf 3013 vrf bla2
 router-id 3.0.1.3

and everything should be just fine.
You can "encode" these 32bits whatever you like.


Best Regards,

-mat
-- 
pgp-key 0x1C655CAB

From serhat.candan at probil.com.tr  Thu Mar  5 03:25:31 2009
From: serhat.candan at probil.com.tr (=?iso-8859-9?Q?Serhat_Candan_=28Probil_-_=DDstanbul=29?=)
Date: Thu, 5 Mar 2009 10:25:31 +0200
Subject: [c-nsp] Cisco 7600 Router's Default IPSec Throughput Rate
In-Reply-To: <a89d89ac0903040757rf5dbef9s2727e76e91baa8e1@mail.gmail.com>
References: <3fc686ad0903040112p6760a191r9cb16eb7969d8960@mail.gmail.com>
	<2ED8C866F019B840AD21E8E29AD091CD0CB9E77410@proexc.probil.intl>
	<a89d89ac0903040757rf5dbef9s2727e76e91baa8e1@mail.gmail.com>
Message-ID: <2ED8C866F019B840AD21E8E29AD091CD0CB9E7755B@proexc.probil.intl>

Hello Marlon,

Thanks for reply. I checked the topic it is about IOS support, i need some charts about IPSec throughput, pps etc.

Regards,

Serhat

From: Marlon Duksa [mailto:mduksa at gmail.com]
Sent: 04 Mart 2009 ?ar?amba 17:57
To: Serhat Candan (Probil - ?stanbul)
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Cisco 7600 Router's Default IPSec Throughput Rate

Serhat - look for "ipsec support on 7600" posting on this list. A similar question was submitted a several days ago..
On Wed, Mar 4, 2009 at 1:14 AM, Serhat Candan (Probil - ?stanbul) <serhat.candan at probil.com.tr<mailto:serhat.candan at probil.com.tr>> wrote:
Hello All,

I m trying to find a reference guide which has IPSec VPN throughput rates of Cisco 7600 router. I m not sure to use VPN SPA or not because of that. For example if you have 50 IPSec Sites with low speed such as 128 Kbps, do we need to use VPN SPA or just upgrade the IOS of the router by using Security Feature enabled IOS?

It would be great to have such a document to determine that need.

Thanks in advance,

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


From sbr at infonet.ee  Thu Mar  5 04:33:26 2009
From: sbr at infonet.ee (Konstantin Barinov)
Date: Thu, 5 Mar 2009 11:33:26 +0200
Subject: [c-nsp] Redundant SUP32-10G
Message-ID: <139174052.20090305113326@infonet.ee>


Hello All!

Please help me to understand, if there are redundant SUP32-10GE's
in chassis, is it possible to use all 4 10G ports at wire speed
simultaneously? What type of interconnection do supervisors use
between them?

Thank you!


br
--
Konstantin Barinov
INFONET AS, Tallinn, Estonia


From perc69 at gmail.com  Thu Mar  5 04:56:55 2009
From: perc69 at gmail.com (Pelle)
Date: Thu, 5 Mar 2009 10:56:55 +0100
Subject: [c-nsp] ip helper and dhcp on the same device
In-Reply-To: <49AE497D.20503@euroway.hu>
References: <49AE497D.20503@euroway.hu>
Message-ID: <746ca6da0903050156u159d187fyc224b8fa61c96f70@mail.gmail.com>

Hi.

> Is it possible to use ip dhcp pool XY for one host( use mac address) and ip
> helper-address ?for the others (all pc is in the same subnet).

If the propose is to give the PC with the known MAC-address a fixed
IP-address, this is easier[1] to do on the DHCP-server.

[1] At least a no-brainer on the ISC dhcp-server

-- 
Pelle

From peter at rathlev.dk  Thu Mar  5 05:24:40 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Thu, 05 Mar 2009 11:24:40 +0100
Subject: [c-nsp] UDP-helper problem
In-Reply-To: <2CE904AA-FF23-4480-8D58-1322E1521FBD@manchester.ac.uk>
References: <2CE904AA-FF23-4480-8D58-1322E1521FBD@manchester.ac.uk>
Message-ID: <1236248680.5801.134.camel@localhost.localdomain>

On Wed, 2009-03-04 at 13:00 +0000, Michael Robson wrote:
> I have recently moved the routing of a subnet from an old sup2/msfc2  
> 6500 (Version 12.1(26)E8, RELEASE SOFTWARE (fc1)) to a newer sup3/ 
> msfc3 6500 (Version 12.2(18)SXF13, RELEASE SOFTWARE (fc1)). On the old  
> router the udp-helper command worked fine, but on the new router I can  
> see the DHCP address coming in but not the reply coming back and the  
> DHCP server isn't seeing the request arriving. Can anyone suggest why  
> this might have stopped working (it isn't an ACL or firewall issue as  
> there aren't any in the way) and I haven't turned _off_ any component  
> of udp-helper (i.e. using the ip forward-protocol command).
> 
> interface Vlan937
>   description XXXYYYZZZ
>   ip address w.x.y.z 255.255.255.192
>   ip helper-address a.b.c.d

AFAIK this forwarding requires the device to have "service dhcp", which
is default. Do you have "no service dhcp" defined maybe?

(I might have misunderstood this requirement though.)

We use this in many places for Sup720 SXF13 boxes, so it should work.

Another thing could be the DHCP server. If you know "by sniff" that the
packet doesn't arrive at the DHCP this is not relevant, but the DHCP
server would of course only reply if e.g. netmasks are the same.

Regards,
Peter



From peter at rathlev.dk  Thu Mar  5 05:57:10 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Thu, 05 Mar 2009 11:57:10 +0100
Subject: [c-nsp] Cisco 7600 Router's Default IPSec Throughput Rate
In-Reply-To: <2ED8C866F019B840AD21E8E29AD091CD0CB9E7755B@proexc.probil.intl>
References: <3fc686ad0903040112p6760a191r9cb16eb7969d8960@mail.gmail.com>
	<2ED8C866F019B840AD21E8E29AD091CD0CB9E77410@proexc.probil.intl>
	<a89d89ac0903040757rf5dbef9s2727e76e91baa8e1@mail.gmail.com>
	<2ED8C866F019B840AD21E8E29AD091CD0CB9E7755B@proexc.probil.intl>
Message-ID: <1236250630.5801.138.camel@localhost.localdomain>

On Thu, 2009-03-05 at 10:25 +0200, Serhat Candan wrote:
> Thanks for reply. I checked the topic it is about IOS support, i need
> some charts about IPSec throughput, pps etc.

Then read the thread once more. :-)

If it is not supported the throughput you can rely on is exactly 0. If
you need IPSec for other than management purposes (or on SR) you need an
IPSec SPA.

Regards,
Peter


From peter at rathlev.dk  Thu Mar  5 06:02:52 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Thu, 05 Mar 2009 12:02:52 +0100
Subject: [c-nsp] Redundant SUP32-10G
In-Reply-To: <139174052.20090305113326@infonet.ee>
References: <139174052.20090305113326@infonet.ee>
Message-ID: <1236250972.5801.144.camel@localhost.localdomain>

On Thu, 2009-03-05 at 11:33 +0200, Konstantin Barinov wrote:
> Please help me to understand, if there are redundant SUP32-10GE's
> in chassis, is it possible to use all 4 10G ports at wire speed
> simultaneously?

Assuming the Sup32 can do wire speed on these ports at all, then yes,
each port should be able to deliver 10G connectivity, and both
supervisor's ports are at your disposal in a redundant setup.

This doesn't mean that you can have the box take 10G in one port and
send all 10G out another port though, not even on the same supervisor.

> What type of interconnection do supervisors use between them?

Regular bus, so inter-sup capacity is limited by this "32 Gbps"
bottleneck shared with all other traffic in the box.

Regards,
Peter



From serhat.candan at probil.com.tr  Thu Mar  5 06:34:49 2009
From: serhat.candan at probil.com.tr (=?iso-8859-9?Q?Serhat_Candan_=28Probil_-_=DDstanbul=29?=)
Date: Thu, 5 Mar 2009 13:34:49 +0200
Subject: [c-nsp] Cisco 7600 Router's Default IPSec Throughput Rate
In-Reply-To: <1236250630.5801.138.camel@localhost.localdomain>
References: <3fc686ad0903040112p6760a191r9cb16eb7969d8960@mail.gmail.com>
	<2ED8C866F019B840AD21E8E29AD091CD0CB9E77410@proexc.probil.intl>
	<a89d89ac0903040757rf5dbef9s2727e76e91baa8e1@mail.gmail.com>
	<2ED8C866F019B840AD21E8E29AD091CD0CB9E7755B@proexc.probil.intl>
	<1236250630.5801.138.camel@localhost.localdomain>
Message-ID: <2ED8C866F019B840AD21E8E29AD091CD0CB9E775EA@proexc.probil.intl>

Thank you so much :)

Regards,

Serhat

-----Original Message-----
From: Peter Rathlev [mailto:peter at rathlev.dk] 
Sent: 05 Mart 2009 Per?embe 12:57
To: Serhat Candan (Probil - ?stanbul)
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Cisco 7600 Router's Default IPSec Throughput Rate

On Thu, 2009-03-05 at 10:25 +0200, Serhat Candan wrote:
> Thanks for reply. I checked the topic it is about IOS support, i need
> some charts about IPSec throughput, pps etc.

Then read the thread once more. :-)

If it is not supported the throughput you can rely on is exactly 0. If
you need IPSec for other than management purposes (or on SR) you need an
IPSec SPA.

Regards,
Peter




From saku+cisco-nsp at ytti.fi  Thu Mar  5 07:13:03 2009
From: saku+cisco-nsp at ytti.fi (Saku Ytti)
Date: Thu, 5 Mar 2009 14:13:03 +0200
Subject: [c-nsp] ftp.cisco.com unusable?
In-Reply-To: <78C984F8939D424697B15E4B1C1BB3D746DEBF@xmb-ams-331.emea.cisco.com>
References: <20090228170533.GJ27070@ronin.4ever.de>
	<78C984F8939D424697B15E4B1C1BB3D746DEBF@xmb-ams-331.emea.cisco.com>
Message-ID: <20090305121303.GA10395@mx.ytti.net>

On (2009-02-28 18:26 +0100), Arie Vayner (avayner) wrote:
> Guys,
> 
> I can recreate it from my PC as well.
> It seems that:
>  - download-sj-1 and download-sj-2 work
>  - download-sj-3 and download-sj-4 are broken
> 
> I will file a case for this with Cisco IT.

Any news?

> 
> Arie
> 
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Elmar K. Bins
> Sent: Saturday, February 28, 2009 19:06
> To: Saku Ytti
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] ftp.cisco.com unusable?
> 
> saku+cisco-nsp at ytti.fi (Saku Ytti) wrote:
> 
> > > ftp> ls
> > > 500 EPSV: Command not recognized
> > > 227 Entering Passive Mode (198,133,219,241,46,108)
> > > 
> > > Well, doing FTP with an Apache...
> > > (that's like teaching a cowboy to shoot arrows, right?
> > 
> > Right :). Thank you for the update. Hopefully someone
> > from @cisco.com picks up gets it fixed.
> 
> I guess they will have to kick their sysadmins.
> This happening or not depends on which Server DNS
> gives you for "ftp.cisco.com".
> 
> Broken:		download-sj-4.cisco.com
> Working:	download-sj-2.cisco.com
> 
> (Examples)
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

-- 
  ++ytti

From kajtzu at basen.net  Thu Mar  5 06:46:58 2009
From: kajtzu at basen.net (Kaj Niemi)
Date: Thu, 5 Mar 2009 14:46:58 +0300
Subject: [c-nsp] ASA 5505 multiple netblock functionality
In-Reply-To: <725755F5E728EE4086DAAF1A54DACF4F0B53DB2B@sea5exbe1.speakeasy.hq>
References: <725755F5E728EE4086DAAF1A54DACF4F0B53DB2B@sea5exbe1.speakeasy.hq>
Message-ID: <2ED4B530-2094-4548-9384-AC357B8BFF9E@basen.net>

Hi,


The default license allows for 2 unrestricted vlans + 1 restricted  
('dmz'). The restricted one cannot initiate traffic towards one of the  
other vlans.

# sh ver

Cisco Adaptive Security Appliance Software Version 8.0(4)16

...
Hardware:   ASA5505, 256 MB RAM, CPU Geode 500 MHz
...
Licensed features for this platform:
Maximum Physical Interfaces  : 8
VLANs                        : 3, DMZ Restricted
Inside Hosts                 : 10

To get around this restriction you would need to buy another license  
(Security Plus). As for 'multiple contexts' - the 5505 does not  
support any.

Refer to http://www.cisco.com/en/US/prod/collateral/vpndevc/ps6032/ps6094/ps6120/product_data_sheet0900aecd802930c5.html 
  for more info.



Kaj

On Mar 5, 2009, at 00:55, Jonathan Brashear wrote:

> Apologies if this has been addressed previously, I looked through  
> the last 12 months of c-nsp threads and didn't see this mentioned.
>
> There is some debate going on in my department over a particular  
> implementation and the 5505's capability to handle multiple  
> netblocks. A quick primer on the situation:
>
> Firewall IP: 1.2.3.4(publicly routable, but changing for cust privacy)
> Customer netblock: 5.6.7.0/26(it's publicly routable as well, I'm  
> changing for sake of cust privacy)
> Customer NAT: 192.168.0.0/24
>
>
> The /26 is statically routed to 1.2.3.4 from the router level, and  
> the customer wants to run NAT for their internal devices(db servers,  
> etc.). Our implementations guy states that the 5505 can't handle  
> assigning 3+ netblocks because they can't run multiple contexts. My  
> experience with the ASA firewalls is limited so I very well may be  
> wrong, but I believe the 5505s should be able to handle multiple  
> netblocks on the internal side of the firewall using something such  
> as sub-interfaces or similar. Can anyone help explain why this is or  
> isn't feasible?
>
> They don't need to be on the same physical interface necessarily, we  
> can run them to separate physical interfaces because this customer  
> is hairpinned behind a switch(and the servers are connected to said  
> switch instead of the firewall directly) so port density isn't a big  
> issue(to a point).
>
> We can assign a netblock to each internal port on the firewall if  
> need be - which seems to be the best solution from what I'm  
> uncovering - and that works as a reasonable alternative. It doesn't  
> scale very well obviously, but I don't think this customer is going  
> to chew through netblocks at a rate where this will be an issue.
>
> Network Engineer, JNCIS-M
>> 214-981-1954 (office)
>> 214-642-4075 (cell)
>> jbrashear at hq.speakeasy.net
> http://www.speakeasy.net
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/





Kaj
-- 
Kaj J. Niemi
<kajtzu at basen.net>
FI +358 45 63 12000
KSA +966 54 52 43277





From ibrahim.abozaid at gmail.com  Thu Mar  5 07:52:50 2009
From: ibrahim.abozaid at gmail.com (Ibrahim Abo Zaid)
Date: Thu, 5 Mar 2009 14:52:50 +0200
Subject: [c-nsp] rotary-like dynamic NAT pool
Message-ID: <a48927f70903050452u6c6c957eh9a7ab116f11a1949@mail.gmail.com>

Dear All


i was searching for dynamic NAT technology that utilize the NAT pool in
rotary fashion for inside source addresses like rotary NAT technology does
for destination addresses


best regards
--Ibrahim

From hnyhus at gmail.com  Thu Mar  5 09:00:25 2009
From: hnyhus at gmail.com (=?UTF-8?Q?H=C3=A5vard_Nyhus?=)
Date: Thu, 5 Mar 2009 15:00:25 +0100
Subject: [c-nsp] Redundant SUP32-10G
In-Reply-To: <139174052.20090305113326@infonet.ee>
References: <139174052.20090305113326@infonet.ee>
Message-ID: <6bc4a240903050600q2740fd0er8fbc303ad2478277@mail.gmail.com>

> Please help me to understand, if there are redundant SUP32-10GE's
> in chassis, is it possible to use all 4 10G ports at wire speed
> simultaneously? What type of interconnection do supervisors use
> between them?


All four ports can be used at the same time - however, they will be
oversubscribed 2:1 on each supervisor. There is also a limit at 15mpps
ipv4 traffic (64-byte packets).

The SUP32 connects to the classic bus - that is the shared 32gbps bus,
which is also used between the two supervisors. This means that a
SUP32-system cannot forward more than 32gbps in total, no matter which
linecards you use.


-- 
H?vard Staub Nyhus

From sbr at infonet.ee  Thu Mar  5 09:17:16 2009
From: sbr at infonet.ee (Konstantin Barinov)
Date: Thu, 05 Mar 2009 16:17:16 +0200
Subject: [c-nsp] Redundant SUP32-10G
In-Reply-To: <6bc4a240903050600q2740fd0er8fbc303ad2478277@mail.gmail.com>
References: <139174052.20090305113326@infonet.ee>
	<6bc4a240903050600q2740fd0er8fbc303ad2478277@mail.gmail.com>
Message-ID: <49AFDEEC.4050109@infonet.ee>


Thank you for answers! Subject is now clear.

--
Konstantin Barinov



On 05-Mar-09 16:00, H?vard Nyhus wrote:
>> Please help me to understand, if there are redundant SUP32-10GE's
>> in chassis, is it possible to use all 4 10G ports at wire speed
>> simultaneously? What type of interconnection do supervisors use
>> between them?
>
>
> All four ports can be used at the same time - however, they will be
> oversubscribed 2:1 on each supervisor. There is also a limit at 15mpps
> ipv4 traffic (64-byte packets).
>
> The SUP32 connects to the classic bus - that is the shared 32gbps bus,
> which is also used between the two supervisors. This means that a
> SUP32-system cannot forward more than 32gbps in total, no matter which
> linecards you use.
>
>

From ayourtch at cisco.com  Thu Mar  5 11:22:44 2009
From: ayourtch at cisco.com (Andrew Yourtchenko)
Date: Thu, 5 Mar 2009 17:22:44 +0100 (CET)
Subject: [c-nsp] FWSM and mixed IPv4/IPv6 access-list
In-Reply-To: <Pine.LNX.4.64.0903032025140.10827@whammy.cluebyfour.org>
References: <38D04BF3A4B7B2499D19EB1DB54285EA09E90498@FNB1EX01.gci.com>
	<Pine.LNX.4.64.0903032025140.10827@whammy.cluebyfour.org>
Message-ID: <Pine.LNX.4.64.0903051702330.6781@zippy.stdio.be>



On Tue, 3 Mar 2009, Justin M. Streiner wrote:

> On Tue, 3 Mar 2009, Leif Sawyer wrote:
>
>>  Is anybody working with FWSM's and mixed-mode IPv4+IPv6 ACL's?
>>
>>  I'm having trouble with traceroute6 not succeeding, but ping6 working
>>  fine:
>
> You might be getting caught by flawed behavior of the FWSM.  I've run into 
> something similar with straight v4 firewall zones where certain flavors of 
> traceroute will be dropped by the blade.  When it was first reported to us, 
> we thought is was a broken fixup, but the behavior persisted after the fixup 
> was disabled.  No word on a fix from Cisco.

traceroute relies on the party that is doing the traceroute being able to 
receive the ICMP TTL expired from all the nodes along the path back to 
the originator. In the presence of nat(ipv4)/ACLs you would need the icmp 
inspection to have it working.

"Classic" traceroute uses UDP as probe packets, but windows boxes use
ICMP for that purpose. If you had issues with the latter but not with the 
former, CSCsj53485 might be what you were encountering. If it does not 
match what you were experiencing and you have a case#, unicast it to me 
please.

>
> On a somewhat unrelated note, how has the v6 performance been on the FWSMs 
> for you?  Everything I've heard from Cisco and other sources suggests that 
> the v6 packets are much more expensive for the FWSM to forward, so 
> performance would suffer greatly.

Correct.

thanks,
andrew

From hritter at cisco.com  Thu Mar  5 12:06:31 2009
From: hritter at cisco.com (Harold Ritter (hritter))
Date: Thu, 5 Mar 2009 12:06:31 -0500
Subject: [c-nsp] Conflicting OSPF router-ids in separate VRFs
In-Reply-To: <49AF70CA.6070007@justinshore.com>
References: <49AF70CA.6070007@justinshore.com>
Message-ID: <F4469404D9886545AD22355D96D8620F07091660@xmb-rtp-20a.amer.cisco.com>

Justin,

The OSPF RID needs to be globally unique on the box. There is no way
around it.

Regards 

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Justin Shore
Sent: Thursday, March 05, 2009 1:27 AM
To: 'Cisco-nsp'
Subject: [c-nsp] Conflicting OSPF router-ids in separate VRFs

I'm trying to get multiple OSPF instances to work in separate VRFs with
all OSPF instances using the same router-id.  We're offering a VPN
tunnel service to access offsite bit-for-bit data copy services in our
Data Center.  The tunnel of choice is a GRE tunnel with IPSec
protection.  The GRE tunnel interface is inside a unique VRF per
customer.  The IP subnet used in each VRF for this product offering is
identical, as is the interface IPs on the tunnel interfaces.  This makes
the config templates as simple as possible since all sites are
essentially identical from our perspective.

I have OSPF configured inside the VRF in question.  This is the first of
the production GRE tunnels we've turned up for this product offering. 
Tunnel2999 is my beta tunnel and Tunnel3013 is the production tunnel:

Neighbor ID     Pri   State           Dead Time   Address
Interface
%OSPF: Router process 3013 is not running, please configure a router-id
192.168.100.1     0   FULL/  -        00:00:38    10.125.124.2
Tunnel2999


The problem I'm running into is that OSPF will not run on the production
tunnel because it's IP conflicts with the IP in my beta tunnel in a
separate VRF.  When I try to configure OSPF in the production VRF with
the interface IP of the tunnel I get an error:

7613-1(config-router)#router-id 10.125.124.1
OSPF: router-id 10.125.124.1 in use by ospf process 2999

router ospf 2999 vrf dc-gre-test
  ignore lsa mospf
  ispf
  log-adjacency-changes
  redistribute bgp 65001 subnets
  passive-interface default
  no passive-interface Tunnel2999
  network 10.125.124.0 0.0.0.3 area 0
  network 10.125.125.0 0.0.0.255 area 0


router ospf 3013 vrf dc-customer-vrf
  ignore lsa mospf
  ispf
  log-adjacency-changes
  redistribute bgp 65001 subnets
  passive-interface default
  no passive-interface Tunnel3013
  network 10.125.124.0 0.0.0.3 area 0
  network 10.125.125.0 0.0.0.255 area 0


Is there some magic trick to making OSPF on a 7600 running SRB1 be truly
  VRF-aware?  OSPF instances in separate VRFs shouldn't IP conflict with
router-ids in other VRFs.  If they did then what's the point of VRF
separation?  Any thoughts before I call TAC?

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 justin at justinshore.com  Thu Mar  5 12:16:18 2009
From: justin at justinshore.com (Justin Shore)
Date: Thu, 05 Mar 2009 11:16:18 -0600
Subject: [c-nsp] Conflicting OSPF router-ids in separate VRFs
In-Reply-To: <F4469404D9886545AD22355D96D8620F07091660@xmb-rtp-20a.amer.cisco.com>
References: <49AF70CA.6070007@justinshore.com>
	<F4469404D9886545AD22355D96D8620F07091660@xmb-rtp-20a.amer.cisco.com>
Message-ID: <49B008E2.7070703@justinshore.com>

Harold,

Thanks for the reply.  This sounds odd to me.  Why wouldn't IOS be able 
to handle conflicting OSPF router-ids for OSPF processes in different 
VRFs?  I could certainly see the problem if these were separate OSPF 
processes that were in the global VRF but I would think that VRF 
separation would take care of any conflicts in OSPF processes.  Odd.  Is 
this something that may be addressed in a future release?

Thanks again for the reply
  Justin


Harold Ritter (hritter) wrote:
> Justin,
> 
> The OSPF RID needs to be globally unique on the box. There is no way
> around it.
> 
> Regards 
> 
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Justin Shore
> Sent: Thursday, March 05, 2009 1:27 AM
> To: 'Cisco-nsp'
> Subject: [c-nsp] Conflicting OSPF router-ids in separate VRFs
> 
> Is there some magic trick to making OSPF on a 7600 running SRB1 be truly
>   VRF-aware?  OSPF instances in separate VRFs shouldn't IP conflict with
> router-ids in other VRFs.  If they did then what's the point of VRF
> separation?  Any thoughts before I call TAC?


From lmeade at signal.ca  Thu Mar  5 12:50:41 2009
From: lmeade at signal.ca (Leslie Meade)
Date: Thu, 5 Mar 2009 09:50:41 -0800
Subject: [c-nsp] eigrp questions
Message-ID: <EAF4FF4AB2142D499F2F5A3B9D85152904503306@exch-bo.MGVFS.McLeanNet>

I have two 6509's with sup 32 running HRSP and ether channel links
between them.

On Vlan2 I have two routers, one that handles T1 and the other DMVPN.

All devices have eigrp running. Vlan 2 is my routed network to these
devices. The HRSP ip on the 6509 is 10.1.2.1

 

On my both of my routers that are only connected to one 6509, when I do
a sh ip route eigrp 100 I get the following.

 

 D       10.1.32.0/24 [90/3072] via 10.1.2.3, 1w5d, GigabitEthernet0/0

                                     [90/3072] via 10.1.2.2, 1w5d,
GigabitEthernet0/0

D EX    10.1.204.0/24 [170/3072] via 10.1.2.3, 1w5d, GigabitEthernet0/0

                                         [170/3072] via 10.1.2.2, 1w5d,
GigabitEthernet0/0

D EX 192.168.0.0/16 [170/3072] via 10.1.2.3, 1w5d, GigabitEthernet0/0

                                        [170/3072] via 10.1.2.2, 1w5d,
GigabitEthernet0/0 

 

vfs-core-r1#sh ip route 10.1.1.6

Routing entry for 10.1.1.0/24

  Known via "eigrp 100", distance 90, metric 3072, type internal

  Redistributing via eigrp 100

  Last update from 10.1.2.2 on GigabitEthernet0/0, 1w5d ago

  Routing Descriptor Blocks:

  * 10.1.2.3, from 10.1.2.3, 1w5d ago, via GigabitEthernet0/0

      Route metric is 3072, traffic share count is 1

      Total delay is 20 microseconds, minimum bandwidth is 1000000 Kbit

      Reliability 255/255, minimum MTU 1500 bytes

      Loading 1/255, Hops 1

    10.1.2.2, from 10.1.2.2, 1w5d ago, via GigabitEthernet0/0

      Route metric is 3072, traffic share count is 1

      Total delay is 20 microseconds, minimum bandwidth is 1000000 Kbit

      Reliability 255/255, minimum MTU 1500 bytes

      Loading 11/255, Hops 1

 

My question is how do I change the weighting on the eigrp so that
10.1.2.1 is the preferred, then .2 then .3.

The easy answer is to remove the eigrp from the 2nd 6509, but there is a
move to plug them into the other 6509 for redundancy.

 

 

Leslie 


From david.freedman at uk.clara.net  Thu Mar  5 13:05:52 2009
From: david.freedman at uk.clara.net (David Freedman)
Date: Thu, 05 Mar 2009 18:05:52 +0000
Subject: [c-nsp] MPLS LDP and BGP Neighbor flapping constantly
In-Reply-To: <49AF7271.40507@justinshore.com>
References: <49AF7271.40507@justinshore.com>
Message-ID: <49B01480.5020003@uk.clara.net>

You appear to have a high number of input queue drops and input errors,
granted the counters have never been cleared, do you haver any PPS
graphs of the link between these two boxes? I would suspect a traffic
spike or link fault causing control messages to be dropped being the
cause here.

Dave.

Justin Shore wrote:
> This afternoon I stumbled across a problem with a LDP session between a
> 7613 and a 7201.  Actually both LDP and iBGP were flapping every 10
> seconds or so.  I had both interfaces configured for MPLS, LDP, IS-IS
> (with AUTH and BFD though BFD isn't enabled on the interface itself yet)
> with an interface MTU of 9000 and CLNS MTU of 1496.  Nothing too fancy.
>  The systems as a whole are configured with MPLS graceful-restart, LDP,
> no mpls ip propagate-ttl, and LDP router-ID on a loopback:
> 
> # 7201
> mpls label protocol ldp
> no mpls ip propagate-ttl
> mpls ldp graceful-restart
> mpls ldp router-id Loopback0 force
> 
> # 7613
> mls mpls tunnel-recir
> mpls traffic-eng tunnels
> mpls ldp graceful-restart
> no mpls ip propagate-ttl
> mpls label protocol ldp
> mpls ldp router-id Loopback0 force
> 
> This morning at 7:05 the router stopped responding to SNMP queries for
> about 15m.  The load was about 13 before.  Cacti shows the load doubling
> in the 10m prior to the 15m of nothing.  When it came back the load was
> just shy of 50 and stayed there for about 30m.  After that it stayed at
> around 30-35 for the next 7.5hrs before I noticed the BGP flapping issue
> and shutdown the peer for troubleshooting.  The load dropped back to
> around 16, higher than it was before the hiccup this morning.  I'm at a
> loss to adequately explain why the load has been so jacked.  I think the
> 30-35 load was because BGP flapping and the slightly higher load now is
> due to the LDP flapping issue.  That's my best guess.
> 
> Anyone know how to troubleshoot a LDP neighbor flapping issue?  The 7613
> is logging this:
> 
> 730278: Mar  4 20:43:48.696 CST: LDP GR: Received FT Sess TLV from
> 10.64.0.34:0  (fl 0x1, rs 0x0, rconn 0, rcov 120000)
> 730279: Mar  4 20:43:48.696 CST: LDP GR: MFI cutover wait delay =
> 600000, Forwarding State Hold Timer = 600000
> 730280: Mar  4 20:43:48.696 CST: LDP GR: searching for down nbr record
> (10.64.0.34:0, 10.64.0.178)
> 730281: Mar  4 20:43:48.696 CST: LDP GR: Added FT Sess TLV (Rconn
> 120000, Rcov 0) to INIT msg to 10.64.0.34:0
> 
> The 7201 is logging this:
> 
> 054705: Mar  5 00:28:19.599 CST: LDP GR: GR session 10.64.0.20:0:: lost
> 054706: Mar  5 00:28:19.599 CST: LDP GR: down nbr 10.64.0.20:0:: created
> [1 total]
> 054707: Mar  5 00:28:19 CST: %LDP-5-GR: GR session 10.64.0.20:0 (inst.
> 3): interrupted--recovery pending
> 054708: Mar  5 00:28:19.599 CST: LDP GR: GR session 10.64.0.20:0::
> bindings retained
> 054709: Mar  5 00:28:19.599 CST: LDP GR: down nbr 10.64.0.20:0:: state
> change (None -> Reconnect-Wait)
> 054710: Mar  5 00:28:19.599 CST: LDP GR: down nbr 10.64.0.20:0::
> reconnect timer started [120000 msecs]
> 054711: Mar  5 00:28:19.599 CST: LDP GR: down nbr 10.64.0.20:0:: added
> to bindings task queue [1 entries]
> 054712: Mar  5 00:28:19 CST: %LDP-5-NBRCHG: LDP Neighbor 10.64.0.20:0
> (0) is DOWN (Received error notification from peer: Shut down)
> 
> 054713: Mar  5 00:28:25.923 CST: LDP GR: searching for down nbr record
> (10.64.0.20:0, 10.64.0.179)
> 054714: Mar  5 00:28:25.923 CST: LDP GR: search for down nbr record
> (10.64.0.20:0, 10.64.0.179) returned 10.64.0.20:0
> 054715: Mar  5 00:28:25.923 CST: LDP GR: Added FT Sess TLV (Rconn 0,
> Rcov 120000) to INIT msg to 10.64.0.20:0
> 054716: Mar  5 00:28:25.947 CST: LDP GR: Received FT Sess TLV from
> 10.64.0.20:0  (fl 0x1, rs 0x0, rconn 120000, rcov 0)
> 054717: Mar  5 00:28:25.947 CST: LDP GR: GR session 10.64.0.20:0::
> established
> 054718: Mar  5 00:28:25.947 CST: LDP GR: GR session 10.64.0.20:0:: found
> down nbr 10.64.0.20:0
> 054719: Mar  5 00:28:25.947 CST: LDP GR: down nbr 10.64.0.20:0::
> reconnect timer stopped
> 054720: Mar  5 00:28:25.947 CST: LDP GR: down nbr 10.64.0.20:0:: state
> change (Reconnect-Wait -> Recovering)
> 054721: Mar  5 00:28:25.947 CST: LDP GR: down nbr 10.64.0.20:0::
> recovery timer started [1 msecs]
> 054722: Mar  5 00:28:25 CST: %LDP-5-GR: GR session 10.64.0.20:0 (inst.
> 4): starting graceful recovery
> 054723: Mar  5 00:28:25 CST: %LDP-5-NBRCHG: LDP Neighbor 10.64.0.20:0
> (4) is UP
> 054724: Mar  5 00:28:25.951 CST: LDP GR: down nbr 10.64.0.20:0::
> recovery timer expired
> 054725: Mar  5 00:28:25 CST: %LDP-5-GR: GR session 10.64.0.20:0 (inst.
> 4): completed graceful recovery
> 054726: Mar  5 00:28:25.951 CST: LDP GR: down nbr 10.64.0.20:0::
> destroying record [0 left]
> 054727: Mar  5 00:28:25.951 CST: LDP GR: down nbr 10.64.0.20:0:: state
> change (Recovering -> Delete-Wait)
> 
> 054728: Mar  5 00:28:28.091 CST: LDP GR: Tagcon querying for up to 12
> bindings update tasks [table 0]
> 054729: Mar  5 00:28:28.091 CST: LDP GR: down nbr 10.64.0.20:0::
> requesting bindings DEL for {10.64.0.20:0, 3}
> 054730: Mar  5 00:28:28.091 CST: LDP GR: down nbr 10.64.0.20:0:: removed
> from bindings task queue [0 entries]
> 054731: Mar  5 00:28:28.091 CST: LDP GR: Requesting 1 bindings update
> tasks [0 left in queue]
> 
> 10.64.0.20 is a loopback on the 7613 and 10.64.0.34 is a loopback on the
> 7201.
> 
> I do have some interface errors which I also can't explain.  They do not
> appear to be incrementing though.  7613:
> 
> GigabitEthernet9/1 is up, line protocol is up (connected)
>   Hardware is C6k 1000Mb 802.3, address is 001a.3063.0a80 (bia
> 001a.3063.0a80)
>   Description: TO 2821-2.dc Gi0/0
>   Internet address is 10.64.0.179/31
>   MTU 9000 bytes, BW 1000000 Kbit, DLY 10 usec,
>      reliability 255/255, txload 1/255, rxload 1/255
>   Encapsulation ARPA, loopback not set
>   Keepalive set (10 sec)
>   Full-duplex, 1000Mb/s
>   input flow-control is off, output flow-control is off
>   Clock mode is auto
>   ARP type: ARPA, ARP Timeout 04:00:00
>   Last input 00:00:02, output 00:00:00, output hang never
>   Last clearing of "show interface" counters never
>   Input queue: 0/75/1936665/7581 (size/max/drops/flushes); Total output
> drops: 4
>   Queueing strategy: fifo
>   Output queue: 0/40 (size/max)
>   5 minute input rate 49000 bits/sec, 17 packets/sec
>   5 minute output rate 56000 bits/sec, 24 packets/sec
>   L2 Switched: ucast: 52903876 pkt, 3771470311 bytes - mcast: 15056043
> pkt, 1653756471 bytes
>   L3 in Switched: ucast: 80170438 pkt, 12709078926 bytes - mcast: 0 pkt,
> 0 bytes mcast
>   L3 out Switched: ucast: 185161821 pkt, 36022953056 bytes mcast: 0 pkt,
> 0 bytes
>      150040994 packets input, 30087625055 bytes, 0 no buffer
>      Received 15660647 broadcasts (0 IP multicasts)
>      30 runts, 4247159 giants, 0 throttles
>      1929071 input errors, 68 CRC, 0 frame, 13 overrun, 0 ignored
>      0 watchdog, 0 multicast, 0 pause input
>      0 input packets with dribble condition detected
>      257650143 packets output, 64726258058 bytes, 0 underruns
>      2 output errors, 0 collisions, 2 interface resets
>      0 babbles, 0 late collision, 0 deferred
>      0 lost carrier, 0 no carrier, 0 PAUSE output
>      0 output buffer failures, 0 output buffers swapped out
> 
> 7201:
> GigabitEthernet0/0 is up, line protocol is up
>   Hardware is MV64460 Internal MAC, address is 0023.5ee9.ac1b (bia
> 0023.5ee9.ac1b)
>   Description: TO 7613-2.clr Gi9/1
>   Internet address is 10.64.0.178/31
>   MTU 9000 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
>      reliability 255/255, txload 1/255, rxload 1/255
>   Encapsulation ARPA, loopback not set
>   Keepalive set (10 sec)
>   Full-duplex, 1000Mb/s, media type is RJ45
>   output flow-control is XON, input flow-control is unsupported
>   ARP type: ARPA, ARP Timeout 04:00:00
>   Last input 00:00:00, output 00:00:00, output hang never
>   Last clearing of "show interface" counters never
>   Input queue: 0/75/3951/0 (size/max/drops/flushes); Total output drops: 6
>   Queueing strategy: fifo
>   Output queue: 0/40 (size/max)
>   5 minute input rate 45000 bits/sec, 19 packets/sec
>   5 minute output rate 64000 bits/sec, 13 packets/sec
>      51466122 packets input, 1916487584 bytes, 0 no buffer
>      Received 1891956 broadcasts, 0 runts, 0 giants, 0 throttles
>      5 input errors, 0 CRC, 0 frame, 0 overrun, 5 ignored
>      0 watchdog, 2247902 multicast, 0 pause input
>      0 input packets with dribble condition detected
>      32927369 packets output, 1549013167 bytes, 0 underruns
>      8 output errors, 0 collisions, 1 interface resets
>      23 unknown protocol drops
>      23 unknown protocol drops
>      0 babbles, 0 late collision, 0 deferred
>      8 lost carrier, 0 no carrier, 0 pause output
>      0 output buffer failures, 0 output buffers swapped out
> 
> 
> Any thoughts as to what's going on here?  I can't tell for certain which
> of the 2 routers is causing LDP and BGP to drop.  Knowing that would
> help me narrow my troubleshooting focus.  The 7600 is running SRB1 and
> the 7201 is running 12.4(15)T7.
> 
> 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 david.freedman at uk.clara.net  Thu Mar  5 13:05:52 2009
From: david.freedman at uk.clara.net (David Freedman)
Date: Thu, 05 Mar 2009 18:05:52 +0000
Subject: [c-nsp] MPLS LDP and BGP Neighbor flapping constantly
In-Reply-To: <49AF7271.40507@justinshore.com>
References: <49AF7271.40507@justinshore.com>
Message-ID: <49B01480.5020003@uk.clara.net>

You appear to have a high number of input queue drops and input errors,
granted the counters have never been cleared, do you haver any PPS
graphs of the link between these two boxes? I would suspect a traffic
spike or link fault causing control messages to be dropped being the
cause here.

Dave.

Justin Shore wrote:
> This afternoon I stumbled across a problem with a LDP session between a
> 7613 and a 7201.  Actually both LDP and iBGP were flapping every 10
> seconds or so.  I had both interfaces configured for MPLS, LDP, IS-IS
> (with AUTH and BFD though BFD isn't enabled on the interface itself yet)
> with an interface MTU of 9000 and CLNS MTU of 1496.  Nothing too fancy.
>  The systems as a whole are configured with MPLS graceful-restart, LDP,
> no mpls ip propagate-ttl, and LDP router-ID on a loopback:
> 
> # 7201
> mpls label protocol ldp
> no mpls ip propagate-ttl
> mpls ldp graceful-restart
> mpls ldp router-id Loopback0 force
> 
> # 7613
> mls mpls tunnel-recir
> mpls traffic-eng tunnels
> mpls ldp graceful-restart
> no mpls ip propagate-ttl
> mpls label protocol ldp
> mpls ldp router-id Loopback0 force
> 
> This morning at 7:05 the router stopped responding to SNMP queries for
> about 15m.  The load was about 13 before.  Cacti shows the load doubling
> in the 10m prior to the 15m of nothing.  When it came back the load was
> just shy of 50 and stayed there for about 30m.  After that it stayed at
> around 30-35 for the next 7.5hrs before I noticed the BGP flapping issue
> and shutdown the peer for troubleshooting.  The load dropped back to
> around 16, higher than it was before the hiccup this morning.  I'm at a
> loss to adequately explain why the load has been so jacked.  I think the
> 30-35 load was because BGP flapping and the slightly higher load now is
> due to the LDP flapping issue.  That's my best guess.
> 
> Anyone know how to troubleshoot a LDP neighbor flapping issue?  The 7613
> is logging this:
> 
> 730278: Mar  4 20:43:48.696 CST: LDP GR: Received FT Sess TLV from
> 10.64.0.34:0  (fl 0x1, rs 0x0, rconn 0, rcov 120000)
> 730279: Mar  4 20:43:48.696 CST: LDP GR: MFI cutover wait delay =
> 600000, Forwarding State Hold Timer = 600000
> 730280: Mar  4 20:43:48.696 CST: LDP GR: searching for down nbr record
> (10.64.0.34:0, 10.64.0.178)
> 730281: Mar  4 20:43:48.696 CST: LDP GR: Added FT Sess TLV (Rconn
> 120000, Rcov 0) to INIT msg to 10.64.0.34:0
> 
> The 7201 is logging this:
> 
> 054705: Mar  5 00:28:19.599 CST: LDP GR: GR session 10.64.0.20:0:: lost
> 054706: Mar  5 00:28:19.599 CST: LDP GR: down nbr 10.64.0.20:0:: created
> [1 total]
> 054707: Mar  5 00:28:19 CST: %LDP-5-GR: GR session 10.64.0.20:0 (inst.
> 3): interrupted--recovery pending
> 054708: Mar  5 00:28:19.599 CST: LDP GR: GR session 10.64.0.20:0::
> bindings retained
> 054709: Mar  5 00:28:19.599 CST: LDP GR: down nbr 10.64.0.20:0:: state
> change (None -> Reconnect-Wait)
> 054710: Mar  5 00:28:19.599 CST: LDP GR: down nbr 10.64.0.20:0::
> reconnect timer started [120000 msecs]
> 054711: Mar  5 00:28:19.599 CST: LDP GR: down nbr 10.64.0.20:0:: added
> to bindings task queue [1 entries]
> 054712: Mar  5 00:28:19 CST: %LDP-5-NBRCHG: LDP Neighbor 10.64.0.20:0
> (0) is DOWN (Received error notification from peer: Shut down)
> 
> 054713: Mar  5 00:28:25.923 CST: LDP GR: searching for down nbr record
> (10.64.0.20:0, 10.64.0.179)
> 054714: Mar  5 00:28:25.923 CST: LDP GR: search for down nbr record
> (10.64.0.20:0, 10.64.0.179) returned 10.64.0.20:0
> 054715: Mar  5 00:28:25.923 CST: LDP GR: Added FT Sess TLV (Rconn 0,
> Rcov 120000) to INIT msg to 10.64.0.20:0
> 054716: Mar  5 00:28:25.947 CST: LDP GR: Received FT Sess TLV from
> 10.64.0.20:0  (fl 0x1, rs 0x0, rconn 120000, rcov 0)
> 054717: Mar  5 00:28:25.947 CST: LDP GR: GR session 10.64.0.20:0::
> established
> 054718: Mar  5 00:28:25.947 CST: LDP GR: GR session 10.64.0.20:0:: found
> down nbr 10.64.0.20:0
> 054719: Mar  5 00:28:25.947 CST: LDP GR: down nbr 10.64.0.20:0::
> reconnect timer stopped
> 054720: Mar  5 00:28:25.947 CST: LDP GR: down nbr 10.64.0.20:0:: state
> change (Reconnect-Wait -> Recovering)
> 054721: Mar  5 00:28:25.947 CST: LDP GR: down nbr 10.64.0.20:0::
> recovery timer started [1 msecs]
> 054722: Mar  5 00:28:25 CST: %LDP-5-GR: GR session 10.64.0.20:0 (inst.
> 4): starting graceful recovery
> 054723: Mar  5 00:28:25 CST: %LDP-5-NBRCHG: LDP Neighbor 10.64.0.20:0
> (4) is UP
> 054724: Mar  5 00:28:25.951 CST: LDP GR: down nbr 10.64.0.20:0::
> recovery timer expired
> 054725: Mar  5 00:28:25 CST: %LDP-5-GR: GR session 10.64.0.20:0 (inst.
> 4): completed graceful recovery
> 054726: Mar  5 00:28:25.951 CST: LDP GR: down nbr 10.64.0.20:0::
> destroying record [0 left]
> 054727: Mar  5 00:28:25.951 CST: LDP GR: down nbr 10.64.0.20:0:: state
> change (Recovering -> Delete-Wait)
> 
> 054728: Mar  5 00:28:28.091 CST: LDP GR: Tagcon querying for up to 12
> bindings update tasks [table 0]
> 054729: Mar  5 00:28:28.091 CST: LDP GR: down nbr 10.64.0.20:0::
> requesting bindings DEL for {10.64.0.20:0, 3}
> 054730: Mar  5 00:28:28.091 CST: LDP GR: down nbr 10.64.0.20:0:: removed
> from bindings task queue [0 entries]
> 054731: Mar  5 00:28:28.091 CST: LDP GR: Requesting 1 bindings update
> tasks [0 left in queue]
> 
> 10.64.0.20 is a loopback on the 7613 and 10.64.0.34 is a loopback on the
> 7201.
> 
> I do have some interface errors which I also can't explain.  They do not
> appear to be incrementing though.  7613:
> 
> GigabitEthernet9/1 is up, line protocol is up (connected)
>   Hardware is C6k 1000Mb 802.3, address is 001a.3063.0a80 (bia
> 001a.3063.0a80)
>   Description: TO 2821-2.dc Gi0/0
>   Internet address is 10.64.0.179/31
>   MTU 9000 bytes, BW 1000000 Kbit, DLY 10 usec,
>      reliability 255/255, txload 1/255, rxload 1/255
>   Encapsulation ARPA, loopback not set
>   Keepalive set (10 sec)
>   Full-duplex, 1000Mb/s
>   input flow-control is off, output flow-control is off
>   Clock mode is auto
>   ARP type: ARPA, ARP Timeout 04:00:00
>   Last input 00:00:02, output 00:00:00, output hang never
>   Last clearing of "show interface" counters never
>   Input queue: 0/75/1936665/7581 (size/max/drops/flushes); Total output
> drops: 4
>   Queueing strategy: fifo
>   Output queue: 0/40 (size/max)
>   5 minute input rate 49000 bits/sec, 17 packets/sec
>   5 minute output rate 56000 bits/sec, 24 packets/sec
>   L2 Switched: ucast: 52903876 pkt, 3771470311 bytes - mcast: 15056043
> pkt, 1653756471 bytes
>   L3 in Switched: ucast: 80170438 pkt, 12709078926 bytes - mcast: 0 pkt,
> 0 bytes mcast
>   L3 out Switched: ucast: 185161821 pkt, 36022953056 bytes mcast: 0 pkt,
> 0 bytes
>      150040994 packets input, 30087625055 bytes, 0 no buffer
>      Received 15660647 broadcasts (0 IP multicasts)
>      30 runts, 4247159 giants, 0 throttles
>      1929071 input errors, 68 CRC, 0 frame, 13 overrun, 0 ignored
>      0 watchdog, 0 multicast, 0 pause input
>      0 input packets with dribble condition detected
>      257650143 packets output, 64726258058 bytes, 0 underruns
>      2 output errors, 0 collisions, 2 interface resets
>      0 babbles, 0 late collision, 0 deferred
>      0 lost carrier, 0 no carrier, 0 PAUSE output
>      0 output buffer failures, 0 output buffers swapped out
> 
> 7201:
> GigabitEthernet0/0 is up, line protocol is up
>   Hardware is MV64460 Internal MAC, address is 0023.5ee9.ac1b (bia
> 0023.5ee9.ac1b)
>   Description: TO 7613-2.clr Gi9/1
>   Internet address is 10.64.0.178/31
>   MTU 9000 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
>      reliability 255/255, txload 1/255, rxload 1/255
>   Encapsulation ARPA, loopback not set
>   Keepalive set (10 sec)
>   Full-duplex, 1000Mb/s, media type is RJ45
>   output flow-control is XON, input flow-control is unsupported
>   ARP type: ARPA, ARP Timeout 04:00:00
>   Last input 00:00:00, output 00:00:00, output hang never
>   Last clearing of "show interface" counters never
>   Input queue: 0/75/3951/0 (size/max/drops/flushes); Total output drops: 6
>   Queueing strategy: fifo
>   Output queue: 0/40 (size/max)
>   5 minute input rate 45000 bits/sec, 19 packets/sec
>   5 minute output rate 64000 bits/sec, 13 packets/sec
>      51466122 packets input, 1916487584 bytes, 0 no buffer
>      Received 1891956 broadcasts, 0 runts, 0 giants, 0 throttles
>      5 input errors, 0 CRC, 0 frame, 0 overrun, 5 ignored
>      0 watchdog, 2247902 multicast, 0 pause input
>      0 input packets with dribble condition detected
>      32927369 packets output, 1549013167 bytes, 0 underruns
>      8 output errors, 0 collisions, 1 interface resets
>      23 unknown protocol drops
>      23 unknown protocol drops
>      0 babbles, 0 late collision, 0 deferred
>      8 lost carrier, 0 no carrier, 0 pause output
>      0 output buffer failures, 0 output buffers swapped out
> 
> 
> Any thoughts as to what's going on here?  I can't tell for certain which
> of the 2 routers is causing LDP and BGP to drop.  Knowing that would
> help me narrow my troubleshooting focus.  The 7600 is running SRB1 and
> the 7201 is running 12.4(15)T7.
> 
> 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 geoff at pendery.net  Thu Mar  5 13:11:26 2009
From: geoff at pendery.net (Geoffrey Pendery)
Date: Thu, 5 Mar 2009 12:11:26 -0600
Subject: [c-nsp] eigrp questions
In-Reply-To: <EAF4FF4AB2142D499F2F5A3B9D85152904503306@exch-bo.MGVFS.McLeanNet>
References: <EAF4FF4AB2142D499F2F5A3B9D85152904503306@exch-bo.MGVFS.McLeanNet>
Message-ID: <d6966e4b0903051011n23ab9424pbb4a8d2f61e8b38@mail.gmail.com>

The HSRP address is only virtual, but the 6509 should also have an
actual address on VLAN 2, different from the HSRP address.  It is
probably the .2 or .3 you're seeing in the routing tables.  Issue a
"show int VLAN2" on the 6500 to see its actual address.

HSRP is generally used to provide redundant gateway for host machines
which can't peer with the routing protocol - that .1 address is for
static routes or default gateway settings on servers and workstations,
not for EIGRP.

If you connect the router to both 6509s and run EIGRP, the default
behavior will probably be what you see now - two equal cost routes,
both 6509s.
If you want to force it to use only the first one, then switch to the
second in the event of a failure, you can modify the delay value on
the interfaces, causing EIGRP to prefer one over the other.  This
could have implications in the rest of your EIGRP domain though, as
this delay information will be advertised to others.  If you want to
establish the preference only for this router, or only for particular
routes, you could use floating statics, or even a single static route
to the HSRP address.  Which approach is better depends on more details
in your network.


-Geoff


On Thu, Mar 5, 2009 at 11:50 AM, Leslie Meade <lmeade at signal.ca> wrote:
> I have two 6509's with sup 32 running HRSP and ether channel links
> between them.
>
> On Vlan2 I have two routers, one that handles T1 and the other DMVPN.
>
> All devices have eigrp running. Vlan 2 is my routed network to these
> devices. The HRSP ip on the 6509 is 10.1.2.1
>
>
>
> On my both of my routers that are only connected to one 6509, when I do
> a sh ip route eigrp 100 I get the following.
>
>
>
> ?D ? ? ? 10.1.32.0/24 [90/3072] via 10.1.2.3, 1w5d, GigabitEthernet0/0
>
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? [90/3072] via 10.1.2.2, 1w5d,
> GigabitEthernet0/0
>
> D EX ? ?10.1.204.0/24 [170/3072] via 10.1.2.3, 1w5d, GigabitEthernet0/0
>
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? [170/3072] via 10.1.2.2, 1w5d,
> GigabitEthernet0/0
>
> D EX 192.168.0.0/16 [170/3072] via 10.1.2.3, 1w5d, GigabitEthernet0/0
>
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?[170/3072] via 10.1.2.2, 1w5d,
> GigabitEthernet0/0
>
>
>
> vfs-core-r1#sh ip route 10.1.1.6
>
> Routing entry for 10.1.1.0/24
>
> ?Known via "eigrp 100", distance 90, metric 3072, type internal
>
> ?Redistributing via eigrp 100
>
> ?Last update from 10.1.2.2 on GigabitEthernet0/0, 1w5d ago
>
> ?Routing Descriptor Blocks:
>
> ?* 10.1.2.3, from 10.1.2.3, 1w5d ago, via GigabitEthernet0/0
>
> ? ? ?Route metric is 3072, traffic share count is 1
>
> ? ? ?Total delay is 20 microseconds, minimum bandwidth is 1000000 Kbit
>
> ? ? ?Reliability 255/255, minimum MTU 1500 bytes
>
> ? ? ?Loading 1/255, Hops 1
>
> ? ?10.1.2.2, from 10.1.2.2, 1w5d ago, via GigabitEthernet0/0
>
> ? ? ?Route metric is 3072, traffic share count is 1
>
> ? ? ?Total delay is 20 microseconds, minimum bandwidth is 1000000 Kbit
>
> ? ? ?Reliability 255/255, minimum MTU 1500 bytes
>
> ? ? ?Loading 11/255, Hops 1
>
>
>
> My question is how do I change the weighting on the eigrp so that
> 10.1.2.1 is the preferred, then .2 then .3.
>
> The easy answer is to remove the eigrp from the 2nd 6509, but there is a
> move to plug them into the other 6509 for redundancy.
>
>
>
>
>
> Leslie
>
> _______________________________________________
> cisco-nsp mailing list ?cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From damin at nacs.net  Thu Mar  5 16:53:07 2009
From: damin at nacs.net (Gregory Boehnlein)
Date: Thu, 5 Mar 2009 16:53:07 -0500
Subject: [c-nsp] Cisco Dial-Plan Assistance
Message-ID: <141f01c99ddc$c4d96fc0$4e8c4f40$@net>

Hello,
	I have a few Cisco 2600s configured as PRI gateways. Most of them
have very simple dial-plans, but I'm struggling w/ a more complex plan for a
Dual-PRI configuration and I think I'm missing something simple.

Here is a run-down of the configuration

Carrier PRI <-> Serial 1/0:23
Customer PBX <-> Serial 1/1:23


The routing challenge that I am having is fairly simple, but I'm not finding
a solution in the documentation that I'm looking at.

Here is run-down of the configuration (Stripped of extra crap)

interface Serial1/0:23
 description Two-Way PRI to Carrier for 800 Origination/Termination
!
interface Serial1/1:23
 description Two-Way PRI to Customer

dial-peer voice 2000 voip
 preference 1
 destination-pattern 8885551212
 session protocol sipv2
 session target sip-server

dial-peer voice 2001 voip
 preference 2
 huntstop
 destination-pattern .T
 session protocol sipv2
 session target sip-server

dial-peer voice 1000 pots
 preference 1	
 destination-pattern 8885551212
 direct-inward-dial
 port 1/1:23

dial-peer voice 1002 pots
 preference 2
 huntstop
 destination-pattern .T
 direct-inward-dial
 port 1/0:23

Currently, this works, but not in the way that I need it to. As it is
configured, calls coming in from the Carrier that match the dest
"8885551212" are sent directly to the customer's PBX. I need those calls to
be sent to the VoIP server first, where we need to record the RTP streams.
The Asterisk server, will then deliver the call back to the gateway and
hopefully over S1/1:23 to the customer's PBX.

So the call flow that I'm looking for is:

Carrier PRI -> Cisco -> Asterisk Server -> Cisco -> Customer PBX

I feel like I'm missing something really simple.. I don't do a lot of
Dial-Plan work on IOS...


From kwoody at citytel.net  Thu Mar  5 18:22:05 2009
From: kwoody at citytel.net (Keith)
Date: Thu, 5 Mar 2009 15:22:05 -0800 (PST)
Subject: [c-nsp] 7206vxr cpu usage.
Message-ID: <20090305150921.P69720@pop.citytel.net>


Have a 7206vxr w/NPE-G1 and a couple of PA gig adapters, one with
an SFP one with a GBIC.

We have a fiber connection that was 100Meg, plugged into GE0/1.

We added another fiber connection that is GigE and connected to the GBIC.
This morning I cut over from the old 100meg fiber to the fiber in the
GBIC. It was just a matter of moving the IP address of GE0/1 to GE1/0 and
we were away and running.

Since then, the router CPU has gone up by about 10%. Normally at this time
of day its about 22-23%, it is now about 32%. Normally at peak times the
CPU barely broke 25%. I'm guessing but it looks like it might break 40% at
peak times now.

Is the router working harder because of the GBIC and using gig ethernet
rather than faste? We were using a gig port on the NPE at 100 meg.

sh proc cpu shows that IP input is the top process and ip cef is enabled.

Thanks for any input.
Keith


From stevend at uidaho.edu  Thu Mar  5 19:50:12 2009
From: stevend at uidaho.edu (Dodd, Steven)
Date: Thu, 5 Mar 2009 16:50:12 -0800
Subject: [c-nsp] 7206vxr cpu usage.
In-Reply-To: <20090305150921.P69720@pop.citytel.net>
References: <20090305150921.P69720@pop.citytel.net>
Message-ID: <4C0A1E4AB1B97642AFB097A8CDA0B223CD8E77@EXVS1.its.uidaho.edu>

Are you pushing more traffic through using the new GigE interface? The
7200 uses CPU for everything.

-Steve

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Keith
Sent: Thursday, March 05, 2009 3:22 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] 7206vxr cpu usage.


Have a 7206vxr w/NPE-G1 and a couple of PA gig adapters, one with
an SFP one with a GBIC.

We have a fiber connection that was 100Meg, plugged into GE0/1.

We added another fiber connection that is GigE and connected to the
GBIC.
This morning I cut over from the old 100meg fiber to the fiber in the
GBIC. It was just a matter of moving the IP address of GE0/1 to GE1/0
and
we were away and running.

Since then, the router CPU has gone up by about 10%. Normally at this
time
of day its about 22-23%, it is now about 32%. Normally at peak times the
CPU barely broke 25%. I'm guessing but it looks like it might break 40%
at
peak times now.

Is the router working harder because of the GBIC and using gig ethernet
rather than faste? We were using a gig port on the NPE at 100 meg.

sh proc cpu shows that IP input is the top process and ip cef is
enabled.

Thanks for any input.
Keith

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

From kwoody at citytel.net  Thu Mar  5 19:57:15 2009
From: kwoody at citytel.net (Keith)
Date: Thu, 5 Mar 2009 16:57:15 -0800 (PST)
Subject: [c-nsp] 7206vxr cpu usage.
In-Reply-To: <4C0A1E4AB1B97642AFB097A8CDA0B223CD8E77@EXVS1.its.uidaho.edu>
References: <20090305150921.P69720@pop.citytel.net>
	<4C0A1E4AB1B97642AFB097A8CDA0B223CD8E77@EXVS1.its.uidaho.edu>
Message-ID: <20090305165559.R69720@pop.citytel.net>

On Thu, 5 Mar 2009, Dodd, Steven wrote:

|->Are you pushing more traffic through using the new GigE interface? The
|->7200 uses CPU for everything.

No, traffic levels are the same right now. We were maxing out the 100 meg
link sometimes at peak times. During the day the link does avg about 70-80
megs.



From brad.henshaw at qcn.com.au  Thu Mar  5 20:04:23 2009
From: brad.henshaw at qcn.com.au (Brad Henshaw)
Date: Fri, 6 Mar 2009 11:04:23 +1000
Subject: [c-nsp] Cisco Dial-Plan Assistance
Message-ID: <8B25B862BC09784B9B74FB950D4F64D40F81B1@qcnapp01.corp.qcn>

Gregory Boehnlein wrote: 

> I have a few Cisco 2600s configured as PRI gateways...
> So the call flow that I'm looking for is:
> Carrier PRI -> Cisco -> Asterisk Server -> Cisco -> Customer PBX

You need to give the VOIP dial-peer a lower preference:

dial-peer voice 2000 voip
 preference 1
dial-peer voice 1000 pots
 preference 2

Alternatively you might be able to use trunkgroups and the associated
preference parameter but I'm not sure that will work with VoIP/SIP
peers.

Regards,
Brad

From justin at justinshore.com  Thu Mar  5 20:07:27 2009
From: justin at justinshore.com (Justin Shore)
Date: Thu, 05 Mar 2009 19:07:27 -0600
Subject: [c-nsp] 7206vxr cpu usage.
In-Reply-To: <20090305150921.P69720@pop.citytel.net>
References: <20090305150921.P69720@pop.citytel.net>
Message-ID: <49B0774F.2030803@justinshore.com>

Keith wrote:
> Have a 7206vxr w/NPE-G1 and a couple of PA gig adapters, one with
> an SFP one with a GBIC.
> 
> We have a fiber connection that was 100Meg, plugged into GE0/1.
> 
> We added another fiber connection that is GigE and connected to the GBIC.
> This morning I cut over from the old 100meg fiber to the fiber in the
> GBIC. It was just a matter of moving the IP address of GE0/1 to GE1/0 and
> we were away and running.
> 
> Since then, the router CPU has gone up by about 10%. Normally at this time
> of day its about 22-23%, it is now about 32%. Normally at peak times the
> CPU barely broke 25%. I'm guessing but it looks like it might break 40% at
> peak times now.
> 
> Is the router working harder because of the GBIC and using gig ethernet
> rather than faste? We were using a gig port on the NPE at 100 meg.
> 
> sh proc cpu shows that IP input is the top process and ip cef is enabled.

So before you had data coming in Gi0/1.  Where was it going to?  My 
thought here is that the data is now coming in Gi1/0 on a PA which has 
to cross one of the PCI buses.  Were you to say that track used to come 
in Gi0/1 and exit Gi0/2 then I wouldn't expect the load to go up because 
of the PCI bus.  Of course if it's now coming in Gi1/0 on a PA, dropping 
onto the PCI bus and then exiting on onboard GigE int (or for that 
matter another PA) then I would expect the PCI bus to be loaded more and 
the load on the router to increase accordingly.  Maybe someone from 
Cisco.com could give us more insight.  I'm curious about this too 
because one day I may find myself in a similar situation.

Justin

From sf at lists.esoteric.ca  Thu Mar  5 20:54:57 2009
From: sf at lists.esoteric.ca (Stephen Fulton)
Date: Thu, 05 Mar 2009 20:54:57 -0500
Subject: [c-nsp] 12.2 SXI, 12.2 SRC route-map question.
Message-ID: <49B08271.7030509@lists.esoteric.ca>

Hi all,

I am banging my head against the wall with a particular route-map, and I'm 
seriously wondering if I drank the stupidity kool-aid today.  I'm testing a 
route-map between two BGP speakers, a 7600 running 12.2(33)SRC1 and an ME6524 
running 12.2(33)SXI, and for the life of me I cannot get either to match based 
on a defined community.  The matching is done for inbound prefixes.  Outbound 
prefixes from the peer are not filtered, and are visible as (received) when 
soft-reconfiguration is configured.  The specific community below is one of 
several that may accompany a route.

Here is a sample, stripping out the identifying details:

(two sample routes, 1.1.1.0/24 and 2.2.2.0/24)

- snip -

ip community-list TEST-COMMUNITY 65000:1234

ip prefix-list TEST-PREFIX-LIST permit 1.1.1.1/24

route-map TEST-IN permit 100
  match ip address prefix-list TEST-PREFIX-LIST

route-map TEST-IN permit 200
  match community TEST-COMMUNITY
  set local-pref 90

route-map TEST-IN deny 999
  desc The End.

- snip -

The first route, 1.1.1.1/24 is received and entered into the RIB successfully. 
The second, which should be matched based on community, is not.  It is listed as 
received, but that's all.

What the heck am I missing?

-- Stephen

From sf at lists.esoteric.ca  Thu Mar  5 21:02:17 2009
From: sf at lists.esoteric.ca (Stephen Fulton)
Date: Thu, 05 Mar 2009 21:02:17 -0500
Subject: [c-nsp] 12.2 SXI, 12.2 SRC route-map question.
In-Reply-To: <49B08271.7030509@lists.esoteric.ca>
References: <49B08271.7030509@lists.esoteric.ca>
Message-ID: <49B08429.2080304@lists.esoteric.ca>

Scratch that, I fell off the stupid tree today.

-- Stephen

Stephen Fulton wrote:
> Hi all,
> 
> I am banging my head against the wall with a particular route-map, and 
> I'm seriously wondering if I drank the stupidity kool-aid today.  I'm 
> testing a route-map between two BGP speakers, a 7600 running 
> 12.2(33)SRC1 and an ME6524 running 12.2(33)SXI, and for the life of me I 
> cannot get either to match based on a defined community.  The matching 
> is done for inbound prefixes.  Outbound prefixes from the peer are not 
> filtered, and are visible as (received) when soft-reconfiguration is 
> configured.  The specific community below is one of several that may 
> accompany a route.
> 
> Here is a sample, stripping out the identifying details:
> 
> (two sample routes, 1.1.1.0/24 and 2.2.2.0/24)
> 
> - snip -
> 
> ip community-list TEST-COMMUNITY 65000:1234
> 
> ip prefix-list TEST-PREFIX-LIST permit 1.1.1.1/24
> 
> route-map TEST-IN permit 100
>  match ip address prefix-list TEST-PREFIX-LIST
> 
> route-map TEST-IN permit 200
>  match community TEST-COMMUNITY
>  set local-pref 90
> 
> route-map TEST-IN deny 999
>  desc The End.
> 
> - snip -
> 
> The first route, 1.1.1.1/24 is received and entered into the RIB 
> successfully. The second, which should be matched based on community, is 
> not.  It is listed as received, but that's all.
> 
> What the heck am I missing?
> 
> -- Stephen
> 

From gert at greenie.muc.de  Fri Mar  6 01:41:40 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Fri, 6 Mar 2009 07:41:40 +0100
Subject: [c-nsp] ftp.cisco.com unusable?
In-Reply-To: <gobv83$s5v$1@ger.gmane.org>
References: <49A88BB5.8050901@bromirski.net>
	<20090228085447.GA4503@mx.ytti.net> <gobv83$s5v$1@ger.gmane.org>
Message-ID: <20090306064140.GY290@greenie.muc.de>

Hi,

On Sat, Feb 28, 2009 at 06:19:47PM +0000, Bernhard Schmidt wrote:
> I've sent an email to my SE and all DNS contacts at cisco.com I could
> find a week ago, but no answer so far. I'll kick my SE on Monday if it
> hasn't improved until then.

Any news?

(The ftp.cisco.com brokenness has plagued me as well, but I've completely
given up complaining about issues with www or ftp.cisco.com)

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/20090306/91fc0c52/attachment.bin>

From Stig.Johansen at atea.no  Fri Mar  6 02:01:02 2009
From: Stig.Johansen at atea.no (Stig Johansen)
Date: Fri, 6 Mar 2009 08:01:02 +0100
Subject: [c-nsp] ftp.cisco.com unusable?
In-Reply-To: <20090306064140.GY290@greenie.muc.de>
References: <49A88BB5.8050901@bromirski.net>
	<20090228085447.GA4503@mx.ytti.net> <gobv83$s5v$1@ger.gmane.org>
	<20090306064140.GY290@greenie.muc.de>
Message-ID: <5EB9799F396A304686962AFFF740ED0CE96C436F@NOOSLEXCH001.adno.local>

>(The ftp.cisco.com brokenness has plagued me as well, but I've completely given up complaining about issues with www or ftp.cisco.com)

Because of the borked ftp.cisco.com, I have generally used ftp-sj.cisco.com instead, and it works just fine "all the time".

/Stig

From euang+cisco-nsp at lists.eusahues.co.uk  Fri Mar  6 05:31:41 2009
From: euang+cisco-nsp at lists.eusahues.co.uk (Euan Galloway)
Date: Fri, 6 Mar 2009 10:31:41 +0000
Subject: [c-nsp] 7206vxr cpu usage.
In-Reply-To: <20090305150921.P69720@pop.citytel.net>
References: <20090305150921.P69720@pop.citytel.net>
Message-ID: <20090306103141.GA5094@hyperion.eusahues.co.uk>

On Thu, Mar 05, 2009 at 03:22:05PM -0800, Keith wrote:

> Since then, the router CPU has gone up by about 10%. Normally at this time
> of day its about 22-23%, it is now about 32%. Normally at peak times the
> CPU barely broke 25%. I'm guessing but it looks like it might break 40% at
> peak times now.
> 
> Is the router working harder because of the GBIC and using gig ethernet
> rather than faste? We were using a gig port on the NPE at 100 meg.

The main BCM1250 processor on the NPE-G1 is what provides the gig ports on 
the NPE. It shouldn't be too surprising to find that it's easier to just pass 
bits around inside the CPU rather than out through the processor's seperate 
PCI I/O capability to reach the PCI backplanes in the VXR chassis in order to 
chat with the PA-GEs.

The performance figures for an NPE-G1 are always onboard to onboard.
Using a PA really takes the edge off of the NPE-G1. 

I've not yet had a play with the 7201 which is similar but different, in that 
none of the onboard are on the main CPU, but 3 are "directly" on one supporting 
chip, and the fourth is hung of that chip's PCI-X bus. 

I wonder what interesting brokenness awaits there.

-- 
Euan Galloway

From Michael.Robson at manchester.ac.uk  Fri Mar  6 06:30:00 2009
From: Michael.Robson at manchester.ac.uk (Michael Robson)
Date: Fri, 6 Mar 2009 11:30:00 +0000
Subject: [c-nsp] UDP-helper problem
In-Reply-To: <4288131ED5E3024C9CD4782CECCAD2C7065D32B2@LMC-MAIL2.exempla.org>
References: <35870.1236192857@lavin-llc.com>
	<2B8F519A-BE98-44BA-841D-4C304E19CD11@manchester.ac.uk>
	<4288131ED5E3024C9CD4782CECCAD2C7065D32B2@LMC-MAIL2.exempla.org>
Message-ID: <134CA3C2-4B00-4D44-835A-2FA2EF2BF285@manchester.ac.uk>

Yup.

On 4 Mar 2009, at 21:30, Matlock, Kenneth L wrote:

> Extended ping using the source interface of Vlan937 as well works?
>
> Ken Matlock
> Network Analyst
> Exempla Healthcare
> (303) 467-4671
> matlockk at exempla.org
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Michael Robson
> Sent: Wednesday, March 04, 2009 2:28 PM
> To: chris at lavin-llc.com
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] UDP-helper problem
>
> Yes there is a route to a.b.c.d and yes we can ping the DHCP server
> from everywhere, including the new sup.
>
> On 4 Mar 2009, at 18:54, <chris at lavin-llc.com> wrote:
>
>> On Wed Mar  4  8:00 , Michael Robson  sent:
>>
>>> I have recently moved the routing of a subnet from an old sup2/msfc2
>>> 6500 (Version 12.1(26)E8, RELEASE SOFTWARE (fc1)) to a newer sup3/
>>> msfc3 6500 (Version 12.2(18)SXF13, RELEASE SOFTWARE (fc1)). On the
>>> old
>>> router the udp-helper command worked fine, but on the new router I
>>> can
>>> see the DHCP address coming in but not the reply coming back and the
>>> DHCP server isn't seeing the request arriving. Can anyone suggest  
>>> why
>>> this might have stopped working (it isn't an ACL or firewall issue  
>>> as
>>> there aren't any in the way) and I haven't turned _off_ any  
>>> component
>>> of udp-helper (i.e. using the ip forward-protocol command).
>>>
>>> interface Vlan937
>>> description XXXYYYZZZ
>>> ip address w.x.y.z 255.255.255.192
>>> ip helper-address a.b.c.d
>>>
>>
>> From this new sup, do you have a route to a.b.c.d? Can you ping the
>> DHCP server from this new sup?
>>
>>
>> -chris
>>
>
>
> Michael
> -- 
>
> Michael Robson           | Tel: +44 (0) 161 275 6113
> Senior Network Engineer  | Fax: +44 (0) 161 275 6120
> Net North West           | Email: Michael.Robson at manchester.ac.uk
>
> _______________________________________________
> cisco-nsp mailing 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
-- 

Michael Robson           | Tel: +44 (0) 161 275 6113
Senior Network Engineer  | Fax: +44 (0) 161 275 6120
Net North West           | Email: Michael.Robson at manchester.ac.uk


From networkstuff.training at gmail.com  Fri Mar  6 09:23:11 2009
From: networkstuff.training at gmail.com (Swati Sharma)
Date: Fri, 6 Mar 2009 19:53:11 +0530
Subject: [c-nsp] sup redundancy - hot vs warm
Message-ID: <8a93d4b30903060623m5ce48252kc6259b5424fe2241@mail.gmail.com>

Hi,

 On 6500 i can see below information... once it says hot standby and
anotherside it says warm... any idea !!!!

Peer Processor Information :
----------------------------
              Standby Location = slot 6
        Current Software state = STANDBY HOT
       Uptime in current state = 3 minutes
                 Image Version = Cisco Internetwork Operating System
Software
IOS (tm) s72033_rp Software (s72033_rp-ADVENTERPRISEK9_WAN-M), Version
12.2(18)SXF12a, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2008 by cisco Systems, Inc.
Compiled Thu 10-Jan-08 23:52 by kellythw
                          BOOT =
disk0:s72033-adventerprisek9_wan-mz.122-18.SXF12a.bin,12
                   CONFIG_FILE =
                       BOOTLDR =
        Configuration register = 0x2102


Router#sh mod
Mod Ports Card Type                              Model              Serial
No.
--- ----- -------------------------------------- ------------------
-----------
  1   24  CEF720 24 port 1000mb SFP              WS-X6724-SFP       SAL26K
  5    2  Supervisor Engine 720 (Active)         WS-SUP720-3BXL     SAL112
  6    2  Supervisor Engine 720 (Warm)           WS-SUP720-3BXL     SAL122
Mod MAC addresses                       Hw    Fw


Regards,

From James.Pender at PAETEC.com  Fri Mar  6 09:34:01 2009
From: James.Pender at PAETEC.com (Pender, James)
Date: Fri, 6 Mar 2009 09:34:01 -0500
Subject: [c-nsp] sup redundancy - hot vs warm
In-Reply-To: <8a93d4b30903060623m5ce48252kc6259b5424fe2241@mail.gmail.com>
References: <8a93d4b30903060623m5ce48252kc6259b5424fe2241@mail.gmail.com>
Message-ID: <B1FBCC0EF362994491030771D94D15E63714914FED@NYMAILCLUSTER1.corp.paetec.com>

Are you running SSO? Have you given the processors a change to sync after what looks like a reboot? 

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Swati Sharma
Sent: Friday, March 06, 2009 9:23 AM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] sup redundancy - hot vs warm

Hi,

 On 6500 i can see below information... once it says hot standby and
anotherside it says warm... any idea !!!!

Peer Processor Information :
----------------------------
              Standby Location = slot 6
        Current Software state = STANDBY HOT
       Uptime in current state = 3 minutes
                 Image Version = Cisco Internetwork Operating System
Software
IOS (tm) s72033_rp Software (s72033_rp-ADVENTERPRISEK9_WAN-M), Version
12.2(18)SXF12a, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2008 by cisco Systems, Inc.
Compiled Thu 10-Jan-08 23:52 by kellythw
                          BOOT =
disk0:s72033-adventerprisek9_wan-mz.122-18.SXF12a.bin,12
                   CONFIG_FILE =
                       BOOTLDR =
        Configuration register = 0x2102


Router#sh mod
Mod Ports Card Type                              Model              Serial
No.
--- ----- -------------------------------------- ------------------
-----------
  1   24  CEF720 24 port 1000mb SFP              WS-X6724-SFP       SAL26K
  5    2  Supervisor Engine 720 (Active)         WS-SUP720-3BXL     SAL112
  6    2  Supervisor Engine 720 (Warm)           WS-SUP720-3BXL     SAL122
Mod MAC addresses                       Hw    Fw


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/

From saku+cisco-nsp at ytti.fi  Fri Mar  6 10:13:25 2009
From: saku+cisco-nsp at ytti.fi (Saku Ytti)
Date: Fri, 6 Mar 2009 17:13:25 +0200
Subject: [c-nsp] ftp.cisco.com unusable?
In-Reply-To: <5EB9799F396A304686962AFFF740ED0CE96C436F@NOOSLEXCH001.adno.local>
References: <49A88BB5.8050901@bromirski.net>
	<20090228085447.GA4503@mx.ytti.net> <gobv83$s5v$1@ger.gmane.org>
	<20090306064140.GY290@greenie.muc.de>
	<5EB9799F396A304686962AFFF740ED0CE96C436F@NOOSLEXCH001.adno.local>
Message-ID: <20090306151325.GA17796@mx.ytti.net>

On (2009-03-06 08:01 +0100), Stig Johansen wrote:

> >(The ftp.cisco.com brokenness has plagued me as well, but I've completely given up complaining about issues with www or ftp.cisco.com)
> 
> Because of the borked ftp.cisco.com, I have generally used ftp-sj.cisco.com instead, and it works just fine "all the time".

I noticed this same years ago, this is why I use ftp-sj. However somewhere
between beginning of time and now it seems to have lost relevance:

[ytti at ytti.fi ~]% dig ftp.cisco.com +short
198.133.219.241
[ytti at ytti.fi ~]% dig ftp-sj.cisco.com +short
download-sj.cisco.com.
198.133.219.241

-- 
  ++ytti

From justin at justinshore.com  Fri Mar  6 10:29:13 2009
From: justin at justinshore.com (Justin Shore)
Date: Fri, 06 Mar 2009 09:29:13 -0600
Subject: [c-nsp] OT:  TCL Book recommendation for Cisco EEM
Message-ID: <49B14149.7050702@justinshore.com>

Does anyone have any suggestions on a good book on TCL scripting for 
Cisco's EEM?  As a complete TCL novice, a good TCL intro would be good. 
  I can probably use existing EEM examples to learn the intricacies of 
using TCL for Cisco I think, unless someone knows of a book that covers 
that too.

http://www.cisco.com/en/US/docs/ios/netmgmt/configuration/guide/nm_eem_overview.html

Thanks
  Justin


From blahu77 at gmail.com  Fri Mar  6 10:31:26 2009
From: blahu77 at gmail.com (Mateusz Blaszczyk)
Date: Fri, 6 Mar 2009 15:31:26 +0000
Subject: [c-nsp] ftp.cisco.com unusable?
In-Reply-To: <20090306151325.GA17796@mx.ytti.net>
References: <49A88BB5.8050901@bromirski.net>
	<20090228085447.GA4503@mx.ytti.net> <gobv83$s5v$1@ger.gmane.org>
	<20090306064140.GY290@greenie.muc.de>
	<5EB9799F396A304686962AFFF740ED0CE96C436F@NOOSLEXCH001.adno.local>
	<20090306151325.GA17796@mx.ytti.net>
Message-ID: <383357750903060731q1e43cdccxd9d28d2df921d259@mail.gmail.com>

> I noticed this same years ago, this is why I use ftp-sj. However somewhere
> between beginning of time and now it seems to have lost relevance:
>
> [ytti at ytti.fi ~]% dig ftp.cisco.com +short
> 198.133.219.241
> [ytti at ytti.fi ~]% dig ftp-sj.cisco.com +short
> download-sj.cisco.com.
> 198.133.219.241

1 IP does not mean same machine these days


-- 
pgp-key 0x1C655CAB

From Michael.Robson at manchester.ac.uk  Fri Mar  6 10:59:46 2009
From: Michael.Robson at manchester.ac.uk (Michael Robson)
Date: Fri, 6 Mar 2009 15:59:46 +0000
Subject: [c-nsp] UDP-helper problem
In-Reply-To: <1236248680.5801.134.camel@localhost.localdomain>
References: <2CE904AA-FF23-4480-8D58-1322E1521FBD@manchester.ac.uk>
	<1236248680.5801.134.camel@localhost.localdomain>
Message-ID: <C84ED921-988C-4E30-90EA-87CDDB560AF3@manchester.ac.uk>


On 5 Mar 2009, at 10:24, Peter Rathlev wrote:

> On Wed, 2009-03-04 at 13:00 +0000, Michael Robson wrote:
>> I have recently moved the routing of a subnet from an old sup2/msfc2
>> 6500 (Version 12.1(26)E8, RELEASE SOFTWARE (fc1)) to a newer sup3/
>> msfc3 6500 (Version 12.2(18)SXF13, RELEASE SOFTWARE (fc1)). On the  
>> old
>> router the udp-helper command worked fine, but on the new router I  
>> can
>> see the DHCP address coming in but not the reply coming back and the
>> DHCP server isn't seeing the request arriving. Can anyone suggest why
>> this might have stopped working (it isn't an ACL or firewall issue as
>> there aren't any in the way) and I haven't turned _off_ any component
>> of udp-helper (i.e. using the ip forward-protocol command).
>>
>> interface Vlan937
>>  description XXXYYYZZZ
>>  ip address w.x.y.z 255.255.255.192
>>  ip helper-address a.b.c.d
>
> AFAIK this forwarding requires the device to have "service dhcp",  
> which
> is default. Do you have "no service dhcp" defined maybe?
>
> (I might have misunderstood this requirement though.)
>
The DHCP is no on a router, but a linux server several hops away.



> We use this in many places for Sup720 SXF13 boxes, so it should work.
>
> Another thing could be the DHCP server. If you know "by sniff" that  
> the
> packet doesn't arrive at the DHCP this is not relevant, but the DHCP
> server would of course only reply if e.g. netmasks are the same.


The traffic doesn't arrive at the DHCP server.

  Thanks,


Michael
-- 



From moua0100 at umn.edu  Fri Mar  6 11:02:42 2009
From: moua0100 at umn.edu (Ge Moua)
Date: Fri, 06 Mar 2009 10:02:42 -0600
Subject: [c-nsp] OT:  TCL Book recommendation for Cisco EEM
In-Reply-To: <49B14149.7050702@justinshore.com>
References: <49B14149.7050702@justinshore.com>
Message-ID: <49B14922.2030803@umn.edu>

The "monkey book" was what I started with.  Very detailed with pretty 
good intro.


http://oreilly.com/catalog/expect/chapter/ch03.html


Regards,
Ge Moua | Email: moua0100 at umn.edu

Network Design Engineer
University of Minnesota | Networking & Telecommunications Services



Justin Shore wrote:
> Does anyone have any suggestions on a good book on TCL scripting for 
> Cisco's EEM?  As a complete TCL novice, a good TCL intro would be 
> good.  I can probably use existing EEM examples to learn the 
> intricacies of using TCL for Cisco I think, unless someone knows of a 
> book that covers that too.
>
> http://www.cisco.com/en/US/docs/ios/netmgmt/configuration/guide/nm_eem_overview.html 
>
>
> 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 elparis at cisco.com  Fri Mar  6 11:36:22 2009
From: elparis at cisco.com (Eloy Paris)
Date: Fri, 6 Mar 2009 11:36:22 -0500
Subject: [c-nsp] OT:  TCL Book recommendation for Cisco EEM
In-Reply-To: <49B14922.2030803@umn.edu>
References: <49B14149.7050702@justinshore.com> <49B14922.2030803@umn.edu>
Message-ID: <20090306163622.GG7620@cisco.com>

On Fri, Mar 06, 2009 at 10:02:42AM -0600, Ge Moua wrote:

> The "monkey book" was what I started with.  Very detailed with pretty  
> good intro.
>
> http://oreilly.com/catalog/expect/chapter/ch03.html

Agreed - the Expect book has a great Tcl introduction. Just one chapter
but it goes over the most important Tcl aspects.

I also reference this short tutorial a lot:

http://www.tcl.tk/man/tcl8.5/tutorial/tcltutorial.html

Keep in mind that none of these have any information about Cisco EEM -
it's basic Tcl, and for Cisco EEM you'll need to read the Cisco EEM
documentation.

Cheers,

-- 

Eloy Paris
Cisco PSIRT
Ph: +1 919 392-9118

From saku+cisco-nsp at ytti.fi  Fri Mar  6 11:37:16 2009
From: saku+cisco-nsp at ytti.fi (Saku Ytti)
Date: Fri, 6 Mar 2009 18:37:16 +0200
Subject: [c-nsp] ftp.cisco.com unusable?
In-Reply-To: <383357750903060731q1e43cdccxd9d28d2df921d259@mail.gmail.com>
References: <49A88BB5.8050901@bromirski.net>
	<20090228085447.GA4503@mx.ytti.net> <gobv83$s5v$1@ger.gmane.org>
	<20090306064140.GY290@greenie.muc.de>
	<5EB9799F396A304686962AFFF740ED0CE96C436F@NOOSLEXCH001.adno.local>
	<20090306151325.GA17796@mx.ytti.net>
	<383357750903060731q1e43cdccxd9d28d2df921d259@mail.gmail.com>
Message-ID: <20090306163716.GB18235@mx.ytti.net>

On (2009-03-06 15:31 +0000), Mateusz Blaszczyk wrote:

> > I noticed this same years ago, this is why I use ftp-sj. However somewhere
> > between beginning of time and now it seems to have lost relevance:
> >
> > [ytti at ytti.fi ~]% dig ftp.cisco.com +short
> > 198.133.219.241
> > [ytti at ytti.fi ~]% dig ftp-sj.cisco.com +short
> > download-sj.cisco.com.
> > 198.133.219.241
> 
> 1 IP does not mean same machine these days

Unlike HTTP/1.1 FTP does not tell which was the DNS name attempted, as
that information is lost SLB can not use that information to steer
traffic. Connecting with ftp to ftp.cisco.com, ftp-sj.cisco.com or
198.133.219.241 in above case would be equal.
Of course we can't determine where 198.133.219.241 will end up,
but where ever it will be, ftp-sj or ftp does not make difference.

Thanks,
-- 
  ++ytti

From Michael.Robson at manchester.ac.uk  Fri Mar  6 12:09:11 2009
From: Michael.Robson at manchester.ac.uk (Michael Robson)
Date: Fri, 6 Mar 2009 17:09:11 +0000
Subject: [c-nsp] UDP-helper problem
In-Reply-To: <200903061010200.SM05152@Inbox>
References: <200903061010200.SM05152@Inbox>
Message-ID: <27EE268A-8634-497B-97E1-E34C807995DB@manchester.ac.uk>



> Make sure u dont have no service dhcp in your config.
>
>>> ...
>>
>> AFAIK this forwarding requires the device to have "service dhcp",
>> which
>> is default. Do you have "no service dhcp" defined maybe?
>>
>> ...

Ahh the penny finally drops, thanks. Yes the router had "no service  
DHCP" set. I had wrongly thought that this command was for the DHCP  
server feature on the router, I didn't realise it was for the relaying  
side too.

Thanks all,


Michael
-- 


From justin at justinshore.com  Fri Mar  6 12:12:00 2009
From: justin at justinshore.com (Justin Shore)
Date: Fri, 06 Mar 2009 11:12:00 -0600
Subject: [c-nsp] OT:  TCL Book recommendation for Cisco EEM
In-Reply-To: <20090306163622.GG7620@cisco.com>
References: <49B14149.7050702@justinshore.com> <49B14922.2030803@umn.edu>
	<20090306163622.GG7620@cisco.com>
Message-ID: <49B15960.8040507@justinshore.com>

Eloy Paris wrote:
> On Fri, Mar 06, 2009 at 10:02:42AM -0600, Ge Moua wrote:
> 
>> The "monkey book" was what I started with.  Very detailed with pretty  
>> good intro.
>>
>> http://oreilly.com/catalog/expect/chapter/ch03.html
> 
> Agreed - the Expect book has a great Tcl introduction. Just one chapter
> but it goes over the most important Tcl aspects.
> 
> I also reference this short tutorial a lot:
> 
> http://www.tcl.tk/man/tcl8.5/tutorial/tcltutorial.html
> 
> Keep in mind that none of these have any information about Cisco EEM -
> it's basic Tcl, and for Cisco EEM you'll need to read the Cisco EEM
> documentation.

Thanks for the replies, guys.  I believe I may already have that book. 
I'll have to look when I get home.  The tutorial looks very useful too.

Thanks for the info!
  Justin


From blahu77 at gmail.com  Fri Mar  6 12:18:56 2009
From: blahu77 at gmail.com (Mateusz Blaszczyk)
Date: Fri, 6 Mar 2009 17:18:56 +0000
Subject: [c-nsp] ftp.cisco.com unusable?
In-Reply-To: <20090306163716.GB18235@mx.ytti.net>
References: <49A88BB5.8050901@bromirski.net>
	<20090228085447.GA4503@mx.ytti.net> <gobv83$s5v$1@ger.gmane.org>
	<20090306064140.GY290@greenie.muc.de>
	<5EB9799F396A304686962AFFF740ED0CE96C436F@NOOSLEXCH001.adno.local>
	<20090306151325.GA17796@mx.ytti.net>
	<383357750903060731q1e43cdccxd9d28d2df921d259@mail.gmail.com>
	<20090306163716.GB18235@mx.ytti.net>
Message-ID: <383357750903060918k5b0b7b1er7022bedaf9fee9de@mail.gmail.com>

2009/3/6 Saku Ytti <saku+cisco-nsp at ytti.fi>:
> On (2009-03-06 15:31 +0000), Mateusz Blaszczyk wrote:
>> 1 IP does not mean same machine these days
>
> Unlike HTTP/1.1 FTP does not tell which was the DNS name attempted, as
> that information is lost SLB can not use that information to steer
> traffic.


Another day, another thing I learnt, I thank You.

> Connecting with ftp to ftp.cisco.com, ftp-sj.cisco.com or
> 198.133.219.241 in above case would be equal.
> Of course we can't determine where 198.133.219.241 will end up,
> but where ever it will be, ftp-sj or ftp does not make difference.

I agree

-- 
pgp-key 0x1C655CAB

From mailinglists at unix-scripts.com  Fri Mar  6 13:12:09 2009
From: mailinglists at unix-scripts.com (Shaun R.)
Date: Fri, 6 Mar 2009 10:12:09 -0800
Subject: [c-nsp] Input Errors
Message-ID: <gorp2j$s96$1@ger.gmane.org>

I seam to be having a few customer complain about latency and I'm not sure 
what's going on.  There traceroutes always show the latency on my layer2 
side of the connect from my upstream.  It always seams to be the same 
upstream but my other two don't really move too much traffic.  One thing I 
did notice is that I'm seeing input errors on some interested.  I'm seeing 
input errors on the interface that connects to the upstream, as well as 
input errors on interfaces that are connecting my borders to my core/access 
switch.  I try to trace from my gear out to the customers ip and the trace 
goes out the same upstream but latency looks normal and is half what they 
see when coming in.  I'm been trying to figure out what might be going on 
but it's proving difficult.

So what's causing these input errors?  I have them on every interface on 
both my borders.  Whats weird is that on my core/access switches that 
connect to the borders i dont see any errors on those interfaces.

My network design is simple.

* two border routers, 7206VXR-NPE-G2
* 3750 stack as core/access
* gigE connection between borders and core/access
* gigE connection between borders
* gigE connection to all 3 upstreams.
* full BGP between borders
* OSPF between borders and core/access
* full BGP to upstreams
* Primary upstream pushes about 200mbit
* secondary upstream pushes around 40mbit
* third upstream pushes around 10mbit.

Any help would be appreciated, thanks in advance!

border1#sh int | inc input errors
     16 input errors, 0 CRC, 0 frame, 0 overrun, 16 ignored  [ GigE 0/1 ]
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored [ FE/02 Shutdown]
     6 input errors, 0 CRC, 0 frame, 0 overrun, 6 ignored [GigE 0/2]
     6464 input errors, 0 CRC, 0 frame, 0 overrun, 6464 ignored [ GigE 0/3 ]
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored [FE1/0 Shutdown]
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 
[Loopback0]

border2#sh int | inc input errors
     6712 input errors, 0 CRC, 0 frame, 0 overrun, 6712 ignored [ GigE 0/1 ]
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored [ FE 0/2 
Shutdown ]
     23 input errors, 0 CRC, 0 frame, 0 overrun, 23 ignored [ GigE 0/2 ]
     14805 input errors, 0 CRC, 0 frame, 0 overrun, 14805 ignored [ GigE 
0/3 ]
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored [ FE 1/0 
Shutdown ]
     257 input errors, 0 CRC, 0 frame, 66 overrun, 191 ignored [ GigE 2/0 ]
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 
[Loopback0]


~Shaun



From rodunn at cisco.com  Fri Mar  6 13:31:28 2009
From: rodunn at cisco.com (Rodney Dunn)
Date: Fri, 6 Mar 2009 13:31:28 -0500
Subject: [c-nsp] Input Errors
In-Reply-To: <gorp2j$s96$1@ger.gmane.org>
References: <gorp2j$s96$1@ger.gmane.org>
Message-ID: <20090306183128.GV23482@rtp-cse-489.cisco.com>

Very unlikely the ignores are causing latency that would be
noticed for transit packets going through a 72xx due to it's architecture.

It will introduce a very small amount because it signals the rx ring
filled up with packets coming in. But given the transit packet forwarding
speed to drain that rx ring it would be very very minimal.

These ignores ususally come from microburst on the wire where the upstream
sent a gige linerate type burst that the 72xx couldn't pull off the wire
fast enough. It's the most common issue seen on 72xx's (or any sw forwarding
gige box) that connects to a device that can do linerate gige on transmit.

There have been some other improvements to prevent things like 'sh ver'
from blocking interrupts for a very small amount of time so make sure
you are on something pretty recents such ast 12.4(20) or later mainline
or 12.4(20)T or later.

Rodney

 
On Fri, Mar 06, 2009 at 10:12:09AM -0800, Shaun R. wrote:
> I seam to be having a few customer complain about latency and I'm not sure 
> what's going on.  There traceroutes always show the latency on my layer2 
> side of the connect from my upstream.  It always seams to be the same 
> upstream but my other two don't really move too much traffic.  One thing I 
> did notice is that I'm seeing input errors on some interested.  I'm seeing 
> input errors on the interface that connects to the upstream, as well as 
> input errors on interfaces that are connecting my borders to my core/access 
> switch.  I try to trace from my gear out to the customers ip and the trace 
> goes out the same upstream but latency looks normal and is half what they 
> see when coming in.  I'm been trying to figure out what might be going on 
> but it's proving difficult.
> 
> So what's causing these input errors?  I have them on every interface on 
> both my borders.  Whats weird is that on my core/access switches that 
> connect to the borders i dont see any errors on those interfaces.
> 
> My network design is simple.
> 
> * two border routers, 7206VXR-NPE-G2
> * 3750 stack as core/access
> * gigE connection between borders and core/access
> * gigE connection between borders
> * gigE connection to all 3 upstreams.
> * full BGP between borders
> * OSPF between borders and core/access
> * full BGP to upstreams
> * Primary upstream pushes about 200mbit
> * secondary upstream pushes around 40mbit
> * third upstream pushes around 10mbit.
> 
> Any help would be appreciated, thanks in advance!
> 
> border1#sh int | inc input errors
>     16 input errors, 0 CRC, 0 frame, 0 overrun, 16 ignored  [ GigE 0/1 ]
>     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored [ FE/02 Shutdown]
>     6 input errors, 0 CRC, 0 frame, 0 overrun, 6 ignored [GigE 0/2]
>     6464 input errors, 0 CRC, 0 frame, 0 overrun, 6464 ignored [ GigE 0/3 ]
>     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored [FE1/0 Shutdown]
>     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 
> [Loopback0]
> 
> border2#sh int | inc input errors
>     6712 input errors, 0 CRC, 0 frame, 0 overrun, 6712 ignored [ GigE 0/1 ]
>     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored [ FE 0/2 
> Shutdown ]
>     23 input errors, 0 CRC, 0 frame, 0 overrun, 23 ignored [ GigE 0/2 ]
>     14805 input errors, 0 CRC, 0 frame, 0 overrun, 14805 ignored [ GigE 
> 0/3 ]
>     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored [ FE 1/0 
> Shutdown ]
>     257 input errors, 0 CRC, 0 frame, 66 overrun, 191 ignored [ GigE 2/0 ]
>     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 
> [Loopback0]
> 
> 
> ~Shaun
> 
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

From behrnetworks at gmail.com  Fri Mar  6 13:42:28 2009
From: behrnetworks at gmail.com (Chris)
Date: Fri, 6 Mar 2009 13:42:28 -0500
Subject: [c-nsp] Forward protocol 41 on PIX 501?
Message-ID: <64aa03030903061042p6d5782te95edc9f16738202@mail.gmail.com>

Is it possible to forward protocol 41 (or any protocol # for that matter) on
a PIX 501 running 6.3(5) or is that
a 7.x thing only? I'm poking at ACL syntax but maybe I'm just missing
something.

Thanks!

From mailinglists at unix-scripts.com  Fri Mar  6 13:43:55 2009
From: mailinglists at unix-scripts.com (Shaun R.)
Date: Fri, 6 Mar 2009 10:43:55 -0800
Subject: [c-nsp] Input Errors
In-Reply-To: <20090306183128.GV23482@rtp-cse-489.cisco.com>
References: <gorp2j$s96$1@ger.gmane.org>
	<20090306183128.GV23482@rtp-cse-489.cisco.com>
Message-ID: <gorqu8$2rm$1@ger.gmane.org>

I'm running 12.4(15)T7 right now.  Looks like cisco changed there site a bit 
and the latest release of mainline is 12.4.23(MD), anybody see any problems 
upgrading to this?

~Shaun 



From zeusdadog at gmail.com  Fri Mar  6 14:25:57 2009
From: zeusdadog at gmail.com (Jay Nakamura)
Date: Fri, 6 Mar 2009 14:25:57 -0500
Subject: [c-nsp] IOS content filtering with Trend Micro
Message-ID: <9418aca70903061125p5fda1f3cw3d76681437624ddc@mail.gmail.com>

I was looking into doing web content filtering on ISRs with the trend
micro/IOS content filtering for some rudimentary blocking of bad
sites.  Wanted to see if anyone has used it, and any thought/opinions
on it.

Does it tax the router much?
How effective is it?

Thanks!

From gert at greenie.muc.de  Fri Mar  6 17:45:16 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Fri, 6 Mar 2009 23:45:16 +0100
Subject: [c-nsp] ftp.cisco.com unusable?
In-Reply-To: <5EB9799F396A304686962AFFF740ED0CE96C436F@NOOSLEXCH001.adno.local>
References: <49A88BB5.8050901@bromirski.net>
	<20090228085447.GA4503@mx.ytti.net> <gobv83$s5v$1@ger.gmane.org>
	<20090306064140.GY290@greenie.muc.de>
	<5EB9799F396A304686962AFFF740ED0CE96C436F@NOOSLEXCH001.adno.local>
Message-ID: <20090306224516.GV290@greenie.muc.de>

Hi,

On Fri, Mar 06, 2009 at 08:01:02AM +0100, Stig Johansen wrote:
> Because of the borked ftp.cisco.com, I have generally used 
> ftp-sj.cisco.com instead, and it works just fine "all the time".

Unfortunately, it doesn't.  ftp-sj is also balanced to 4 different
servers, half of them choking on EPSV commands.

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/20090306/a613b3e0/attachment-0001.bin>

From lukasz at bromirski.net  Fri Mar  6 17:48:16 2009
From: lukasz at bromirski.net (=?ISO-8859-2?Q?=A3ukasz_Bromirski?=)
Date: Fri, 06 Mar 2009 23:48:16 +0100
Subject: [c-nsp] Input Errors
In-Reply-To: <gorqu8$2rm$1@ger.gmane.org>
References: <gorp2j$s96$1@ger.gmane.org>	<20090306183128.GV23482@rtp-cse-489.cisco.com>
	<gorqu8$2rm$1@ger.gmane.org>
Message-ID: <49B1A830.1090207@bromirski.net>

On 2009-03-06 19:43, Shaun R. wrote:
> I'm running 12.4(15)T7 right now.  Looks like cisco changed there
> site a bit and the latest release of mainline is 12.4.23(MD), anybody
> see any problems upgrading to this?

That won't be an 'upgrade' - 12.4(15)T7 you're running is a technical
(read: more features, possibly some new bugs) train for 12.4.

12.4(23) you're choosing is actually 'older' version of IOS, the one
12.4T was branched some time ago. But 12.4 "mainline" got only
bug fixes in meantime, and Rodney pointed You to some new fixes
in the IOS code focused around CEF to better service traffic under
load.

I believe they were commited only to "T" code, so You better bet would
be something like newest rebuild of 12.4(20)T or 12.4(22)T.

-- 
"Don't expect me to cry for all the     |               ?ukasz Bromirski
  reasons you had to die" -- Kurt Cobain |    http://lukasz.bromirski.net

From asturluismi at gmail.com  Fri Mar  6 18:42:53 2009
From: asturluismi at gmail.com (luismi)
Date: Sat, 07 Mar 2009 00:42:53 +0100
Subject: [c-nsp] Disabling "enable" command for users at privilege 0
Message-ID: <1236382973.7344.0.camel@dsba-ipso>

Is possible to disable "enable" command for users at privilege 0?


From amsoares at netcabo.pt  Fri Mar  6 21:27:20 2009
From: amsoares at netcabo.pt (Antonio Soares)
Date: Sat, 7 Mar 2009 02:27:20 -0000
Subject: [c-nsp] Disabling "enable" command for users at privilege 0
In-Reply-To: <1236382973.7344.0.camel@dsba-ipso>
References: <1236382973.7344.0.camel@dsba-ipso>
Message-ID: <0640DEEAA56B4A428B55F6FAAB1326AF@int.convex.pt>


privilege exec level 1 enable 


Regards,

Antonio Soares, CCIE #18473 (R&S)
amsoares at netcabo.pt

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of luismi
Sent: sexta-feira, 6 de Mar?o de 2009 23:43
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Disabling "enable" command for users at privilege 0

Is possible to disable "enable" command for users at privilege 0?

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


From bitkraft at gmail.com  Fri Mar  6 21:35:40 2009
From: bitkraft at gmail.com (Brian Spade)
Date: Fri, 6 Mar 2009 18:35:40 -0800
Subject: [c-nsp] Issue with 16MB flash card in ls1010
Message-ID: <505b616c0903061835v46a1ebd3yf22f3dff85c1ff6e@mail.gmail.com>

Hey all,

I'm trying to install a 16mb flash card into an LS1010 running 12.0(10).
The LS1010 recognizes the card from a 'sh ver' but pauses and spits out a
traceback when viewing:

Cisco Internetwork Operating System Software
IOS (tm) LS1010 WA4-5 Software (LS1010-WP-M), Version 12.0(10), RELEASE
SOFTWARE (fc1)
Copyright (c) 1986-2000 by cisco Systems, Inc.
Compiled Wed 22-Mar-00 08:39 by phanguye
Image text-base: 0x60010930, data-base: 0x60696000

ROM: System Bootstrap, Version 11.2(1.4.WA3.0) [integ 1.4.WA3.0], RELEASE
SOFTWARE

RegIV_1010 uptime is 14 minutes
System restarted by reload
Running default software

cisco LS1010 (R4600) processor with 65536K bytes of memory.
R4700 processor, Implementation 33, Revision 1.0
Last reset from power-on
1 Ethernet/IEEE 802.3 interface(s)
10 ATM network interface(s)
123K bytes of non-volatile configuration memory.

16384K bytes of Flash PCMCIA card at slot 0 (Sector size 128K).
8192K bytes of Flash internal SIMM (Sector size 256K).
 --More--
*Mar  6 18:49:26.159: %SYS-3-CPUHOG: Task ran for 4804 msec (50/0), process
= Exec, PC = 600A8E90.
-Traceback= 600A8E98 60038260 6003895C 60038374 60038118 6003895C 60038374
60057794 6004BAFC 600569F4 6009701Configuration register is 0x2102


I try to format the card and get the same error:

IV_1010#format slot0:
Format operation may take a while. Continue? [confirm]
Format operation will destroy all data in "slot0:".  Continue? [confirm]

%Error formatting slot0: (Error reading for erase check)
RegIV_1010#
*Mar  6 18:52:31.111: %SYS-3-CPUHOG: Task ran for 4844 msec (43/0), process
= Exec, PC = 600A8E90.
-Traceback= 600A8E98 60038260 6003895C 60038374 600CAEF4 6004BAFC 600569F4
6009701C 60097008

Any ideas on what's going on?

Thanks,
/bs

From kgraham at industrial-marshmallow.com  Fri Mar  6 20:50:10 2009
From: kgraham at industrial-marshmallow.com (Kevin Graham)
Date: Fri, 6 Mar 2009 17:50:10 -0800 (PST)
Subject: [c-nsp] Disabling "enable" command for users at privilege 0
References: <1236382973.7344.0.camel@dsba-ipso>
Message-ID: <171978.68228.qm@web902.biz.mail.mud.yahoo.com>






> Is possible to disable "enable" command for users at privilege 0?

With a "parser view" you can exclude-command enable; then just assign
those users that view (ie. "username noc view LIMITED passsword 0 test").

This works under 12.4T, there is a (still undetermined) bug that prevents
it from working properly in earlier releases.

From bitkraft at gmail.com  Fri Mar  6 22:16:50 2009
From: bitkraft at gmail.com (Brian Spade)
Date: Fri, 6 Mar 2009 19:16:50 -0800
Subject: [c-nsp] Issue with 16mb flash card on an LS1010
Message-ID: <505b616c0903061916v59a55553sf3add4dca50674e7@mail.gmail.com>

Hi all,

I have installed a 16 mb flash card into an LS1010.  From the 'sh ver', the
card is shown/recognized, but I get a trackback error:

Cisco Internetwork Operating System Software
IOS (tm) LS1010 WA4-5 Software (LS1010-WP-M), Version 12.0(10), RELEASE
SOFTWARE (fc1)
Copyright (c) 1986-2000 by cisco Systems, Inc.
Compiled Wed 22-Mar-00 08:39 by phanguye
Image text-base: 0x60010930, data-base: 0x60696000

ROM: System Bootstrap, Version 11.2(1.4.WA3.0) [integ 1.4.WA3.0], RELEASE
SOFTWARE

RegIV_1010 uptime is 14 minutes
System restarted by reload
Running default software

cisco LS1010 (R4600) processor with 65536K bytes of memory.
R4700 processor, Implementation 33, Revision 1.0
Last reset from power-on
1 Ethernet/IEEE 802.3 interface(s)
10 ATM network interface(s)
123K bytes of non-volatile configuration memory.

16384K bytes of Flash PCMCIA card at slot 0 (Sector size 128K).
8192K bytes of Flash internal SIMM (Sector size 256K).
 --More--
*Mar  6 18:49:26.159: %SYS-3-CPUHOG: Task ran for 4804 msec (50/0), process
= Exec, PC = 600A8E90.
-Traceback= 600A8E98 60038260 6003895C 60038374 60038118 6003895C 60038374
60057794 6004BAFC 600569F4 6009701Configuration register is 0x2102

I can't format the card either:

IV_1010#format slot0:
Format operation may take a while. Continue? [confirm]
Format operation will destroy all data in "slot0:".  Continue? [confirm]

%Error formatting slot0: (Error reading for erase check)
RegIV_1010#
*Mar  6 18:52:31.111: %SYS-3-CPUHOG: Task ran for 4844 msec (43/0), process
= Exec, PC = 600A8E90.
-Traceback= 600A8E98 60038260 6003895C 60038374 600CAEF4 6004BAFC 600569F4
6009701C 60097008

Any idea on what's going on?

Thanks....
/bs

From charles at thewybles.com  Fri Mar  6 22:23:17 2009
From: charles at thewybles.com (Charles Wyble)
Date: Fri, 06 Mar 2009 19:23:17 -0800
Subject: [c-nsp] Resetting an RSM password/config
Message-ID: <49B1E8A5.8070807@thewybles.com>

All,

I recently purchased some cisco gear for my lab. One of the things I am 
doing is configuring a Catalyst 5505 with a Route Switch Module (RSM).

Any idea how to reset the config to factory defaults? I bought it second 
hand and need to clear the configs as I don't know the password.

I googled a bit and didn't find anything.

Thanks.


-- 
Charles N Wyble charles at thewybles.com
(818)280-7059 http://charlesnw.blogspot.com
CTO SocalWiFI.net

From mksmith at adhost.com  Fri Mar  6 22:48:25 2009
From: mksmith at adhost.com (Michael K. Smith)
Date: Fri, 06 Mar 2009 19:48:25 -0800
Subject: [c-nsp] Horrible MPPP Performance
Message-ID: <C5D72E89.5218B%mksmith@adhost.com>

Hello Everyone:

I have two 2800 series routers with 4, clear-channel T-1's between.  I'm
running MPPP with the 4 T1's in the bundle.  Performance is *awful*.  100
byte packets, 40 ms with 98% delivered.  1500 byte packets, 900 ms latency
with 25% packet loss.

Here are my config snippets from the two routers.  I've done everything I
can think of and nothing seems to change the performance.  Any help would be
greatly appreciated.

I've tried moving clock from one side to another, tried running with
network-clock-participate on the line-clocked side, set both sides to line,
set both sides to internal.  The configuration below is the only one that
shows no slips, but the performance is still terrible.

I've also tried changing the load-balancing from per-packet to
per-destination to FIFO to Fair queue.  Nothing changes.

Note, I only included one of each of the T-1 controllers and Serial
interfaces because the others are exactly the same.

----- Side A ----------
    WIC Slot 0 and 1:
    T1 (2 port) Multi-Flex Trunk WAN daughter card
    Hardware revision 1.0             Board revision B0
    Serial number     34720142      Part number    800-04477-04
    FRU Part Number   VWIC-2MFT-T1=


no network-clock-participate wic 0
no network-clock-participate wic 1
ip cef
!
controller T1 0/0/0
 framing esf
 clock source internal
 linecode b8zs
 channel-group 0 timeslots 24
!
!
interface Multilink1
 description Uplink to Market Range via 4 Bonded T-1's
 ip address 172.16.1.5 255.255.255.252
 no cdp enable
 ppp multilink
 ppp multilink links maximum 4
 ppp multilink group 1
!
interface Serial0/0/0:0
 no ip address
 ip load-sharing per-packet
 encapsulation ppp
 no keepalive
 no fair-queue
 ppp multilink
 ppp multilink group 1
!
ip route 10.2.0.0 255.255.0.0 Multilink1
!
-------- Side B --------

    WIC Slot 0 and 1:
    T1 (2 port) Multi-Flex Trunk WAN daughter card
    Hardware revision 1.0             Board revision B0
    Serial number     34720142      Part number    800-04477-04
    FRU Part Number   VWIC-2MFT-T1=

no network-clock-participate wic 0
no network-clock-participate wic 1
!
ip cef
!
controller T1 0/0/0
 framing esf
 linecode b8zs
 channel-group 0 timeslots 24
!
interface Multilink1
 description Uplink to Adhost via 4 Bonded T-1's
 ip address 172.16.1.6 255.255.255.252
 no cdp enable
 ppp multilink
 ppp multilink links maximum 4
 ppp multilink group 1
!
interface Serial0/0/0:0
 no ip address
 ip load-sharing per-packet
 encapsulation ppp
 no keepalive
 no fair-queue
 ppp multilink
 ppp multilink group 1
!
ip route 0.0.0.0 0.0.0.0 Multilink1

Regards,

Mike


From sethm at rollernet.us  Fri Mar  6 23:12:54 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Fri, 06 Mar 2009 20:12:54 -0800
Subject: [c-nsp] Horrible MPPP Performance
In-Reply-To: <C5D72E89.5218B%mksmith@adhost.com>
References: <C5D72E89.5218B%mksmith@adhost.com>
Message-ID: <49B1F446.2050704@rollernet.us>

Michael K. Smith wrote:
> Hello Everyone:
> 
> I have two 2800 series routers with 4, clear-channel T-1's between.  I'm
> running MPPP with the 4 T1's in the bundle.  Performance is *awful*.  100
> byte packets, 40 ms with 98% delivered.  1500 byte packets, 900 ms latency
> with 25% packet loss.
> 
> Here are my config snippets from the two routers.  I've done everything I
> can think of and nothing seems to change the performance.  Any help would be
> greatly appreciated.
> 
> I've tried moving clock from one side to another, tried running with
> network-clock-participate on the line-clocked side, set both sides to line,
> set both sides to internal.  The configuration below is the only one that
> shows no slips, but the performance is still terrible.
> 
> I've also tried changing the load-balancing from per-packet to
> per-destination to FIFO to Fair queue.  Nothing changes.
> 


Why do you have load-sharing with MLPPP?

~Seth

From mksmith at adhost.com  Sat Mar  7 00:29:41 2009
From: mksmith at adhost.com (Michael K. Smith)
Date: Fri, 06 Mar 2009 21:29:41 -0800
Subject: [c-nsp] Horrible MPPP Performance
In-Reply-To: <49B1F446.2050704@rollernet.us>
Message-ID: <C5D74645.521A3%mksmith@adhost.com>

Hello Seth:


On 3/6/09 8:12 PM, "Seth Mattinen" <sethm at rollernet.us> wrote:

> Michael K. Smith wrote:
>> Hello Everyone:
>> 
>> I have two 2800 series routers with 4, clear-channel T-1's between.  I'm
>> running MPPP with the 4 T1's in the bundle.  Performance is *awful*.  100
>> byte packets, 40 ms with 98% delivered.  1500 byte packets, 900 ms latency
>> with 25% packet loss.
>> 
>> Here are my config snippets from the two routers.  I've done everything I
>> can think of and nothing seems to change the performance.  Any help would be
>> greatly appreciated.
>> 
>> I've tried moving clock from one side to another, tried running with
>> network-clock-participate on the line-clocked side, set both sides to line,
>> set both sides to internal.  The configuration below is the only one that
>> shows no slips, but the performance is still terrible.
>> 
>> I've also tried changing the load-balancing from per-packet to
>> per-destination to FIFO to Fair queue.  Nothing changes.
>> 
> 
> 
> Why do you have load-sharing with MLPPP?
> 

As far as I can tell, with CEF enabled, it's either per-packet or
per-destination, with per-destination being the default (not printed to the
config).  I tried doing the "no" on the per-packet with no change.

Regards,

Mike


From mksmith at adhost.com  Sat Mar  7 00:36:12 2009
From: mksmith at adhost.com (Michael K. Smith)
Date: Fri, 06 Mar 2009 21:36:12 -0800
Subject: [c-nsp] Horrible MPPP Performance SOLVED
In-Reply-To: <C5D72E89.5218B%mksmith@adhost.com>
Message-ID: <C5D747CC.521AA%mksmith@adhost.com>

Hello Everyone:

Sorry for the post-to-my-own-post.  Jeremy Gaddis <jeremy at evilrouters.net>
was kind enough not to out me on the list, but what the hey.

I only had one 64k channel enabled on each T-1.

>  channel-group 0 timeslots 24

I used to know T-1's, I swear.

Thanks Jeremy!

Regards,

Mike

On 3/6/09 7:48 PM, "Michael Smith" <mksmith at adhost.com> wrote:

> Hello Everyone:
> 
> I have two 2800 series routers with 4, clear-channel T-1's between.  I'm
> running MPPP with the 4 T1's in the bundle.  Performance is *awful*.  100
> byte packets, 40 ms with 98% delivered.  1500 byte packets, 900 ms latency
> with 25% packet loss.
> 
> Here are my config snippets from the two routers.  I've done everything I
> can think of and nothing seems to change the performance.  Any help would be
> greatly appreciated.
> 
> I've tried moving clock from one side to another, tried running with
> network-clock-participate on the line-clocked side, set both sides to line,
> set both sides to internal.  The configuration below is the only one that
> shows no slips, but the performance is still terrible.
> 
> I've also tried changing the load-balancing from per-packet to
> per-destination to FIFO to Fair queue.  Nothing changes.
> 
> Note, I only included one of each of the T-1 controllers and Serial
> interfaces because the others are exactly the same.
> 
> ----- Side A ----------
>     WIC Slot 0 and 1:
>     T1 (2 port) Multi-Flex Trunk WAN daughter card
>     Hardware revision 1.0             Board revision B0
>     Serial number     34720142      Part number    800-04477-04
>     FRU Part Number   VWIC-2MFT-T1=
> 
> 
> no network-clock-participate wic 0
> no network-clock-participate wic 1
> ip cef
> !
> controller T1 0/0/0
>  framing esf
>  clock source internal
>  linecode b8zs
>  channel-group 0 timeslots 24
> !
> !
> interface Multilink1
>  description Uplink to Market Range via 4 Bonded T-1's
>  ip address 172.16.1.5 255.255.255.252
>  no cdp enable
>  ppp multilink
>  ppp multilink links maximum 4
>  ppp multilink group 1
> !
> interface Serial0/0/0:0
>  no ip address
>  ip load-sharing per-packet
>  encapsulation ppp
>  no keepalive
>  no fair-queue
>  ppp multilink
>  ppp multilink group 1
> !
> ip route 10.2.0.0 255.255.0.0 Multilink1
> !
> -------- Side B --------
> 
>     WIC Slot 0 and 1:
>     T1 (2 port) Multi-Flex Trunk WAN daughter card
>     Hardware revision 1.0             Board revision B0
>     Serial number     34720142      Part number    800-04477-04
>     FRU Part Number   VWIC-2MFT-T1=
> 
> no network-clock-participate wic 0
> no network-clock-participate wic 1
> !
> ip cef
> !
> controller T1 0/0/0
>  framing esf
>  linecode b8zs
>  channel-group 0 timeslots 24
> !
> interface Multilink1
>  description Uplink to Adhost via 4 Bonded T-1's
>  ip address 172.16.1.6 255.255.255.252
>  no cdp enable
>  ppp multilink
>  ppp multilink links maximum 4
>  ppp multilink group 1
> !
> interface Serial0/0/0:0
>  no ip address
>  ip load-sharing per-packet
>  encapsulation ppp
>  no keepalive
>  no fair-queue
>  ppp multilink
>  ppp multilink group 1
> !
> ip route 0.0.0.0 0.0.0.0 Multilink1
> 
> Regards,
> 
> Mike
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


From ip at ioshints.info  Sat Mar  7 03:17:35 2009
From: ip at ioshints.info (Ivan Pepelnjak)
Date: Sat, 7 Mar 2009 09:17:35 +0100
Subject: [c-nsp] OT:  TCL Book recommendation for Cisco EEM
In-Reply-To: <49B14149.7050702@justinshore.com>
References: <49B14149.7050702@justinshore.com>
Message-ID: <004501c99efd$2d1e8860$0a00000a@nil.si>

Tcl/TK: A developer's guide
http://www.msen.com/~clif/DevGuide.html

A bit more advanced book when you want to go slightly beyond the basics. I
wasn't too happy with it, but it did the job.

Ivan

> -----Original Message-----
> From: Justin Shore [mailto:justin at justinshore.com] 
> Sent: Friday, March 06, 2009 4:29 PM
> To: 'Cisco-nsp'
> Subject: [c-nsp] OT: TCL Book recommendation for Cisco EEM
> 
> Does anyone have any suggestions on a good book on TCL 
> scripting for Cisco's EEM?  As a complete TCL novice, a good 
> TCL intro would be good. 
>   I can probably use existing EEM examples to learn the 
> intricacies of using TCL for Cisco I think, unless someone 
> knows of a book that covers that too.
> 
> http://www.cisco.com/en/US/docs/ios/netmgmt/configuration/guid
> e/nm_eem_overview.html
> 
> Thanks
>   Justin


From gert at greenie.muc.de  Sat Mar  7 04:39:22 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Sat, 7 Mar 2009 10:39:22 +0100
Subject: [c-nsp] Resetting an RSM password/config
In-Reply-To: <49B1E8A5.8070807@thewybles.com>
References: <49B1E8A5.8070807@thewybles.com>
Message-ID: <20090307093922.GX290@greenie.muc.de>

Hi,

On Fri, Mar 06, 2009 at 07:23:17PM -0800, Charles Wyble wrote:
> I recently purchased some cisco gear for my lab. One of the things I am 
> doing is configuring a Catalyst 5505 with a Route Switch Module (RSM).
> 
> Any idea how to reset the config to factory defaults? I bought it second 
> hand and need to clear the configs as I don't know the password.
> 
> I googled a bit and didn't find anything.

The RSM has a console port - and from there, you should be able to follow
the standard password recovery procedure documented on CCO.

Search www.cisco.com for "password recovery".  If the RSM is not documented
anymore (being end-of-life), follow the procedure for a router from that 
time - a RSP* or 3640 should be similar.  Don't follow the procedures for 
*switches*, though - the RSM is a bog-standard IOS router in a switch blade, 
not a switch in itself.

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/20090307/c160c15f/attachment.bin>

From manafo at hotmail.com  Sat Mar  7 09:49:47 2009
From: manafo at hotmail.com (Manaf Al Oqlah)
Date: Sat, 7 Mar 2009 16:49:47 +0200
Subject: [c-nsp] 3750ME CPU Utilization
Message-ID: <BLU130-DS41CD1ACBDF52B43539BECC5A20@phx.gbl>

Hi all,

what does the "HULC DAI Process" stands for when executing the command "show process cpu" in 3750ME switch. I found an abnormal behavior on this process ID and it is frequently goes high.

Regards,
Manaf

From ibrahim.abozaid at gmail.com  Sat Mar  7 10:10:27 2009
From: ibrahim.abozaid at gmail.com (Ibrahim Abo Zaid)
Date: Sat, 7 Mar 2009 17:10:27 +0200
Subject: [c-nsp] Multicast RPF check and unicast default route
Message-ID: <a48927f70903070710m24c98973s161d4b28634f52f3@mail.gmail.com>

Hi All

i have a question about multicast RPF check that checks routing table for
source address and ensure traffic incoming interface is the same as route
next hop

does this check supports default routes ? is there a feature like
allow-default used in uRPF ?


best regards
--Ibrahim

From tdurack at gmail.com  Sat Mar  7 10:41:51 2009
From: tdurack at gmail.com (Tim Durack)
Date: Sat, 7 Mar 2009 10:41:51 -0500
Subject: [c-nsp] BGP community and MP-BGP route-target
Message-ID: <9e246b4d0903070741w45312990o6bf36ea5a9a07569@mail.gmail.com>

If I use AS:100 as a BGP community, is this the same as vrf route-target AS:100?

I guess what I'm asking is: Do AS:nn BGP communities and AS:nn MP-BGP
route-targets share the same "community-space"?

Tim:>

From peter at rathlev.dk  Sat Mar  7 10:57:08 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Sat, 07 Mar 2009 16:57:08 +0100
Subject: [c-nsp] BGP community and MP-BGP route-target
In-Reply-To: <9e246b4d0903070741w45312990o6bf36ea5a9a07569@mail.gmail.com>
References: <9e246b4d0903070741w45312990o6bf36ea5a9a07569@mail.gmail.com>
Message-ID: <1236441428.2073.2.camel@localhost.localdomain>

On Sat, 2009-03-07 at 10:41 -0500, Tim Durack wrote:
> If I use AS:100 as a BGP community, is this the same as vrf route-target AS:100?
> 
> I guess what I'm asking is: Do AS:nn BGP communities and AS:nn MP-BGP
> route-targets share the same "community-space"?

They don't, the RT is an extended community. There is no overlapping and
no conflicts. You can set it with "set extcommunity rt ...".

Regards,
Peter



From berni at birkenwald.de  Sat Mar  7 10:24:41 2009
From: berni at birkenwald.de (Bernhard Schmidt)
Date: Sat, 07 Mar 2009 16:24:41 +0100
Subject: [c-nsp] ftp.cisco.com unusable?
In-Reply-To: <20090306224516.GV290@greenie.muc.de>
References: <49A88BB5.8050901@bromirski.net>
	<20090228085447.GA4503@mx.ytti.net> <gobv83$s5v$1@ger.gmane.org>
	<20090306064140.GY290@greenie.muc.de>
	<5EB9799F396A304686962AFFF740ED0CE96C436F@NOOSLEXCH001.adno.local>
	<20090306224516.GV290@greenie.muc.de>
Message-ID: <49B291B9.2040000@birkenwald.de>

On 06.03.2009 23:45, Gert Doering wrote:

> On Fri, Mar 06, 2009 at 08:01:02AM +0100, Stig Johansen wrote:
>> Because of the borked ftp.cisco.com, I have generally used
>> ftp-sj.cisco.com instead, and it works just fine "all the time".
> Unfortunately, it doesn't.  ftp-sj is also balanced to 4 different
> servers, half of them choking on EPSV commands.

But it isn't affected by broken DNS for AAAA records, so it works better 
than ftp.cisco.com :-\

*sigh*
Bernhard

From ibrahim.abozaid at gmail.com  Sat Mar  7 12:08:22 2009
From: ibrahim.abozaid at gmail.com (Ibrahim Abo Zaid)
Date: Sat, 7 Mar 2009 19:08:22 +0200
Subject: [c-nsp] Multicast RPF check and unicast default route [7:134602]
In-Reply-To: <7F338D54E95EF14BAE0631DBEF9A2C8201D421@INK.backbone.dpsciences.com>
References: <200903071510.n27FAxwo029911@groupstudy.com>
	<7F338D54E95EF14BAE0631DBEF9A2C8201D421@INK.backbone.dpsciences.com>
Message-ID: <a48927f70903070908q39c96e3eoe0108bedfba19a6d@mail.gmail.com>

yes Rohynas that what i mean but my question is that work with multicast RPF
check or works for unicast only ?


best regards
--Ibrahim

On Sat, Mar 7, 2009 at 6:30 PM, Rohyans, Aaron <arohyans at dpsciences.com>wrote:

> I believe you're referring to:
>
> interface fastEthernet 0/0
>  ip verify unicast source reachable-via any
>
> ...this allows the router to use the default route for Reverse Path check.
>
> Hope this helps,
>
> Aaron T. Rohyans
> Senior Network Engineer
> CCIE #21945, CCSP, CCNA, CQS-Firewall, CQS-IDS, CQS-VPN, ISSP, CISP,
> JNCIA-ER
> DPSciences Corporation
> 7400 N. Shadeland Ave., Suite 245
> Indianapolis, IN 46250
> Office:  (317) 348-0099
> Fax:   (317) 849-7134
> arohyans at dpsciences.com
> http://www.dpsciences.com/
>
>
> -----Original Message-----
> From: nobody at groupstudy.com [mailto:nobody at groupstudy.com] On Behalf Of
> Ibrahim Abo Zaid
> Sent: Saturday, March 07, 2009 10:11 AM
> To: cisco at groupstudy.com
> Subject: Multicast RPF check and unicast default route [7:134602]
>
> Hi All
>
> i have a question about multicast RPF check that checks routing table for
> source address and ensure traffic incoming interface is the same as route
> next hop
>
> does this check supports default routes ? is there a feature like
> allow-default used in uRPF ?
>
>
> best regards
> --Ibrahim
>
>
>
>
> Message Posted at:
> http://www.groupstudy.com/form/read.php?f=7&i=134602&t=134602
> --------------------------------------------------
> FAQ, list archives, and subscription info:
> http://www.groupstudy.com/list/cisco.html
>
>

From mtinka at globaltransit.net  Sat Mar  7 11:39:34 2009
From: mtinka at globaltransit.net (Mark Tinka)
Date: Sun, 8 Mar 2009 00:39:34 +0800
Subject: [c-nsp] BGP community and MP-BGP route-target
In-Reply-To: <9e246b4d0903070741w45312990o6bf36ea5a9a07569@mail.gmail.com>
References: <9e246b4d0903070741w45312990o6bf36ea5a9a07569@mail.gmail.com>
Message-ID: <200903080039.44983.mtinka@globaltransit.net>

On Saturday 07 March 2009 11:41:51 pm Tim Durack wrote:

> I guess what I'm asking is: Do AS:nn BGP communities and
> AS:nn MP-BGP route-targets share the same
> "community-space"?

No they don't.

VRF RT's are part of the extended communities definition 
which support a 64-bit value, and would appear only on the 
routes associated with that particular VRF or per your 
configuration.

Assuming your garden-variety IP network, standard 
communities support 32-bit values and would generally apply 
to routes in your global routing table.

Having said that, it is possible to attach both standard and 
extended communities to a route. In such a case, the router 
would handle each type of community per their individual RFC 
specifications.

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/20090308/c8d029a6/attachment.bin>

From blahu77 at gmail.com  Sat Mar  7 12:44:07 2009
From: blahu77 at gmail.com (Mateusz Błaszczyk)
Date: Sat, 7 Mar 2009 17:44:07 +0000 (IST)
Subject: [c-nsp] 3750ME CPU Utilization
In-Reply-To: <BLU130-DS41CD1ACBDF52B43539BECC5A20@phx.gbl>
Message-ID: <fs0l4gxy3z8irg2ekhUYAxe124vaj_firegpg@mail.gmail.com>

Dynamic Arp Inspection is what comes to my mind?

2009/3/7 Manaf Al Oqlah <manafo at hotmail.com>:
> Hi all,
>
> what does the "HULC DAI Process" stands for when executing the command "show process cpu" in 3750ME switch. I found an abnormal behavior on this process ID and it is frequently goes high.
>
> Regards,
> Manaf
> _______________________________________________
> cisco-nsp mailing list ?cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>



-- 
pgp-key 0x1C655CAB

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090307/5d6ed4d4/attachment.bin>

From asturluismi at gmail.com  Sat Mar  7 12:54:59 2009
From: asturluismi at gmail.com (luismi)
Date: Sat, 07 Mar 2009 18:54:59 +0100
Subject: [c-nsp] Disabling "enable" command for users at privilege 0
In-Reply-To: <0640DEEAA56B4A428B55F6FAAB1326AF@int.convex.pt>
References: <1236382973.7344.0.camel@dsba-ipso>
	<0640DEEAA56B4A428B55F6FAAB1326AF@int.convex.pt>
Message-ID: <1236448499.8327.4.camel@dsba-ipso>

Thanks it works perfectly for me :D

El s?b, 07-03-2009 a las 02:27 +0000, Antonio Soares escribi?:
> privilege exec level 1 enable 


From tdurack at gmail.com  Sat Mar  7 13:02:43 2009
From: tdurack at gmail.com (Tim Durack)
Date: Sat, 7 Mar 2009 13:02:43 -0500
Subject: [c-nsp] BGP community and MP-BGP route-target
In-Reply-To: <200903080039.44983.mtinka@globaltransit.net>
References: <9e246b4d0903070741w45312990o6bf36ea5a9a07569@mail.gmail.com>
	<200903080039.44983.mtinka@globaltransit.net>
Message-ID: <9e246b4d0903071002m7c458a8t38558f54a1173499@mail.gmail.com>

On Sat, Mar 7, 2009 at 11:39 AM, Mark Tinka <mtinka at globaltransit.net> wrote:
> On Saturday 07 March 2009 11:41:51 pm Tim Durack wrote:
>
>> I guess what I'm asking is: Do AS:nn BGP communities and
>> AS:nn MP-BGP route-targets share the same
>> "community-space"?
>
> No they don't.
>

That's what I needed to know - thanks!

Tim:>

From asturluismi at gmail.com  Sat Mar  7 13:04:52 2009
From: asturluismi at gmail.com (luismi)
Date: Sat, 07 Mar 2009 19:04:52 +0100
Subject: [c-nsp] Open Source solution to deploy a radius server against
	Cisco	devices?
Message-ID: <1236449092.8327.12.camel@dsba-ipso>

Hi all,

I am looking for an open source solution to deploy some radius in our
network.
The primary goal is to connect to those radius to provide auth services:
- The VPN Concentrators and vpn accounts (we would move all the vpn
accounts info to the radius)
- Validate ip http auth-proxy users

Radius service should be able to be managed using a web interface.
I don't really mind if there is a proper web interface of if we need to
install webadmin.
It also must support accounting.
And it would be great if it is possible to have the back-end into MySQL.

I was checking FreeRadius and Radiator.
Any other options?
All comments are welcome.

Thanks



From lowen at pari.edu  Sat Mar  7 13:06:01 2009
From: lowen at pari.edu (Lamar Owen)
Date: Sat, 7 Mar 2009 13:06:01 -0500
Subject: [c-nsp] Resetting an RSM password/config
In-Reply-To: <49B1E8A5.8070807@thewybles.com>
References: <49B1E8A5.8070807@thewybles.com>
Message-ID: <200903071306.01589.lowen@pari.edu>

On Friday 06 March 2009 22:23:17 Charles Wyble wrote:
> I recently purchased some cisco gear for my lab. One of the things I am
> doing is configuring a Catalyst 5505 with a Route Switch Module (RSM).
>
> Any idea how to reset the config to factory defaults? I bought it second
> hand and need to clear the configs as I don't know the password.

http://www.cisco.com/en/US/products/hw/switches/ps686/products_password_recovery09186a00801d1248.shtml

Connect to the female DB-25 on the RSM itself and send the BREAK sequence 
(with Minicom under Linux, for instance, this is CTRL-A F or ALT-F, depending 
on version and console) right after you see the ROMMON banner.
-- 
Lamar Owen
Chief Information Officer
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
http://www.pari.edu

From p.mayers at imperial.ac.uk  Sat Mar  7 13:15:15 2009
From: p.mayers at imperial.ac.uk (Phil Mayers)
Date: Sat, 7 Mar 2009 18:15:15 +0000
Subject: [c-nsp] Multicast RPF check and unicast default route
In-Reply-To: <a48927f70903070710m24c98973s161d4b28634f52f3@mail.gmail.com>
References: <a48927f70903070710m24c98973s161d4b28634f52f3@mail.gmail.com>
Message-ID: <20090307181514.GB19698@wildfire.net.ic.ac.uk>

On Sat, Mar 07, 2009 at 03:10:27PM +0000, Ibrahim Abo Zaid wrote:
>Hi All
>
>i have a question about multicast RPF check that checks routing table for
>source address and ensure traffic incoming interface is the same as route
>next hop
>
>does this check supports default routes ? is there a feature like

Yes

>allow-default used in uRPF ?

What does that mean? Can you describe what you are trying to achieve?

From p.mayers at imperial.ac.uk  Sat Mar  7 13:17:49 2009
From: p.mayers at imperial.ac.uk (Phil Mayers)
Date: Sat, 7 Mar 2009 18:17:49 +0000
Subject: [c-nsp] Multicast RPF check and unicast default route [7:134602]
In-Reply-To: <a48927f70903070908q39c96e3eoe0108bedfba19a6d@mail.gmail.com>
References: <200903071510.n27FAxwo029911@groupstudy.com>
	<7F338D54E95EF14BAE0631DBEF9A2C8201D421@INK.backbone.dpsciences.com>
	<a48927f70903070908q39c96e3eoe0108bedfba19a6d@mail.gmail.com>
Message-ID: <20090307181749.GC19698@wildfire.net.ic.ac.uk>

On Sat, Mar 07, 2009 at 05:08:22PM +0000, Ibrahim Abo Zaid wrote:
>yes Rohynas that what i mean but my question is that work with multicast RPF
>check or works for unicast only ?

I don't believe this works for multicast, and find it hard to conceive 
of a circumstance where it would be useful. What are you trying to 
achieve?

You can use a separate set of routes to do the multicast RPF check - for 
example, a set of network statements under the "ipv4 multicast" BGP 
family, or static "ip mroute" commands, but whether that's useful will 
depend.

From Charles at thewybles.com  Sat Mar  7 13:52:50 2009
From: Charles at thewybles.com (Charles at thewybles.com)
Date: Sat, 7 Mar 2009 18:52:50 +0000
Subject: [c-nsp] Open Source solution to deploy a radius server
	againstCisco	devices?
Message-ID: <2044551257-1236451993-cardhu_decombobulator_blackberry.rim.net-2132750851-@bxe1216.bisx.prod.on.blackberry>

Those seem to be the category killers. 


------Original Message------
From: luismi
Sender: cisco-nsp-bounces at puck.nether.net
To: Cisco Network Service Providers
Subject: [c-nsp] Open Source solution to deploy a radius server againstCisco	devices?
Sent: Mar 7, 2009 10:04 AM

Hi all,

I am looking for an open source solution to deploy some radius in our
network.
The primary goal is to connect to those radius to provide auth services:
- The VPN Concentrators and vpn accounts (we would move all the vpn
accounts info to the radius)
- Validate ip http auth-proxy users

Radius service should be able to be managed using a web interface.
I don't really mind if there is a proper web interface of if we need to
install webadmin.
It also must support accounting.
And it would be great if it is possible to have the back-end into MySQL.

I was checking FreeRadius and Radiator.
Any other options?
All comments are welcome.

Thanks


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



Sent via BlackBerry from T-Mobile

From Charles at thewybles.com  Sat Mar  7 14:01:16 2009
From: Charles at thewybles.com (Charles at thewybles.com)
Date: Sat, 7 Mar 2009 19:01:16 +0000
Subject: [c-nsp] Resetting an RSM password/config
Message-ID: <2137577677-1236452498-cardhu_decombobulator_blackberry.rim.net-598636238-@bxe1216.bisx.prod.on.blackberry>

Thanks to all. Standard ios reset procedure it is. :)

------Original Message------
From: Lamar Owen
Sender: 
To: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Resetting an RSM password/config
Sent: Mar 7, 2009 10:06 AM

On Friday 06 March 2009 22:23:17 Charles Wyble wrote:
> I recently purchased some cisco gear for my lab. One of the things I am
> doing is configuring a Catalyst 5505 with a Route Switch Module (RSM).
>
> Any idea how to reset the config to factory defaults? I bought it second
> hand and need to clear the configs as I don't know the password.

http://www.cisco.com/en/US/products/hw/switches/ps686/products_password_recovery09186a00801d1248.shtml

Connect to the female DB-25 on the RSM itself and send the BREAK sequence 
(with Minicom under Linux, for instance, this is CTRL-A F or ALT-F, depending 
on version and console) right after you see the ROMMON banner.
-- 
Lamar Owen
Chief Information Officer
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
http://www.pari.edu
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/



Sent via BlackBerry from T-Mobile

From lists at quux.de  Sat Mar  7 13:49:09 2009
From: lists at quux.de (Jens Link)
Date: Sat, 07 Mar 2009 19:49:09 +0100
Subject: [c-nsp] Open Source solution to deploy a radius server against
	Cisco	devices?
In-Reply-To: <1236449092.8327.12.camel@dsba-ipso> (luismi's message of "Sat\,
	07 Mar 2009 19\:04\:52 +0100")
References: <1236449092.8327.12.camel@dsba-ipso>
Message-ID: <87tz655ftm.fsf@laphroiag.quux.de>

luismi <asturluismi at gmail.com> writes:

> Radius service should be able to be managed using a web interface.  I
> don't really mind if there is a proper web interface of if we need to
> install webadmin.  It also must support accounting.  And it would be
> great if it is possible to have the back-end into MySQL.
>
> I was checking FreeRadius and Radiator.  Any other options?  All
> comments are welcome.

FreeRADIUS is used in several big installations.  It can use MySQL as
database backend. It ships withs DialUp-Admin, a web based interface for
the *user* administration which also can use MySQL. 

cheers 

Jens
-- 
-------------------------------------------------------------------------
| Foelderichstr. 40  | 13595 Berlin, Germany | +49-151-18721264         |
| http://www.quux.de | http://blog.quux.de   | jabber: jenslink at guug.de |
-------------------------------------------------------------------------

From mustafa.golam at gmail.com  Sat Mar  7 15:02:25 2009
From: mustafa.golam at gmail.com (Mustafa Golam -)
Date: Sat, 7 Mar 2009 23:02:25 +0300
Subject: [c-nsp] 3750ME CPU Utilization
In-Reply-To: <BLU130-DS49BC8D21F4064FB79F05CC5A20@phx.gbl>
References: <BLU130-DS41CD1ACBDF52B43539BECC5A20@phx.gbl>
	<fs0l4gxy3z8irg2ekhUYAxe124vaj_firegpg@mail.gmail.com>
	<c72973e60903070948kaee4b68iff3531c6fab96052@mail.gmail.com>
	<BLU130-DS49BC8D21F4064FB79F05CC5A20@phx.gbl>
Message-ID: <c72973e60903071202od0517f8xd313844301dcb1ff@mail.gmail.com>

Ref to:
http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_40_se/configuration/guide/swdynarp.html

*no ip arp inspection vlan vlan-range *should solve the problem than.

//Mustafa
**
On Sat, Mar 7, 2009 at 10:40 PM, Manaf Al Oqlah <manafo at hotmail.com> wrote:

>  Yes it is Dynamic ARP Inspection. it is frequently goes 100%.
>
>  *From:* Mustafa Golam - <mustafa.golam at gmail.com>
> *Sent:* Saturday, March 07, 2009 7:48 PM
> *To:* Mateusz B??aszczyk <blahu77 at gmail.com>
> *Cc:* Manaf Al Oqlah <manafo at hotmail.com>
> *Subject:* Re: [c-nsp] 3750ME CPU Utilization
>
>
>
> On Sat, Mar 7, 2009 at 8:44 PM, Mateusz B??aszczyk <blahu77 at gmail.com>wrote:
>
>> Dynamic Arp Inspection is what comes to my mind?
>>
> True!!!
>
>
>>
>> 2009/3/7 Manaf Al Oqlah <manafo at hotmail.com>:
>
>
> --
> --
> *??)
> ?.???.?*??) ?.?*?)
> (?.?? (?.?` *Mustafa Golam,CCIE(..)'.'`,.
> -.*.-JNCIS,RHCE,CC{D,I,N,S,V}P`et. al.'.'`,.
> GPRS/MPBN Soultion Integrator, Madagascar.
>    LM Ericsson SA Ltd. www.ericsson.com.
>     Email  : mustafa.golam at gmail.com
>       Mobile : +(261)034-111-77-28
>      http://journey2ccie.wordpress.com/
>



-- 
--
*??)
?.???.?*??) ?.?*?)
(?.?? (?.?` *Mustafa Golam,CCIE(..)'.'`,.
-.*.-JNCIS,RHCE,CC{D,I,N,S,V}P`et. al.'.'`,.
GPRS/MPBN Soultion Integrator, Madagascar.
   LM Ericsson SA Ltd. www.ericsson.com.
    Email  : mustafa.golam at gmail.com
      Mobile : +(261)034-111-77-28
     http://journey2ccie.wordpress.com/

From manafo at hotmail.com  Sat Mar  7 18:25:30 2009
From: manafo at hotmail.com (Manaf Al Oqlah)
Date: Sun, 8 Mar 2009 01:25:30 +0200
Subject: [c-nsp] 3750ME CPU Utilization
In-Reply-To: <c72973e60903071202od0517f8xd313844301dcb1ff@mail.gmail.com>
References: <BLU130-DS41CD1ACBDF52B43539BECC5A20@phx.gbl>
	<fs0l4gxy3z8irg2ekhUYAxe124vaj_firegpg@mail.gmail.com>
	<c72973e60903070948kaee4b68iff3531c6fab96052@mail.gmail.com>
	<BLU130-DS49BC8D21F4064FB79F05CC5A20@phx.gbl>
	<c72973e60903071202od0517f8xd313844301dcb1ff@mail.gmail.com>
Message-ID: <BLU130-DS463B38B044C1591F3955EC5A20@phx.gbl>

but I can't live without this option! it is mandatory to prevent users ARP and DHCP spoofing


From: Mustafa Golam - 
Sent: Saturday, March 07, 2009 10:02 PM
To: Manaf Al Oqlah 
Cc: cisco-nsp at puck.nether.net 
Subject: Re: [c-nsp] 3750ME CPU Utilization


Ref to:
http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_40_se/configuration/guide/swdynarp.html

no ip arp inspection vlan vlan-range should solve the problem than.

//Mustafa


On Sat, Mar 7, 2009 at 10:40 PM, Manaf Al Oqlah <manafo at hotmail.com> wrote:

  Yes it is Dynamic ARP Inspection. it is frequently goes 100%.


  From: Mustafa Golam - 
  Sent: Saturday, March 07, 2009 7:48 PM
  To: Mateusz B??aszczyk 
  Cc: Manaf Al Oqlah 
  Subject: Re: [c-nsp] 3750ME CPU Utilization





  On Sat, Mar 7, 2009 at 8:44 PM, Mateusz B??aszczyk <blahu77 at gmail.com> wrote:

    Dynamic Arp Inspection is what comes to my mind?

  True!!!
   


    2009/3/7 Manaf Al Oqlah <manafo at hotmail.com>:

  -- 
  --
  *??)
  ?.???.?*??) ?.?*?)
  (?.?? (?.?` *Mustafa Golam,CCIE(..)'.'`,.
  -.*.-JNCIS,RHCE,CC{D,I,N,S,V}P`et. al.'.'`,.
  GPRS/MPBN Soultion Integrator, Madagascar.
     LM Ericsson SA Ltd. www.ericsson.com.
      Email  : mustafa.golam at gmail.com
        Mobile : +(261)034-111-77-28
       http://journey2ccie.wordpress.com/




-- 
--
*??)
?.???.?*??) ?.?*?)
(?.?? (?.?` *Mustafa Golam,CCIE(..)'.'`,.
-.*.-JNCIS,RHCE,CC{D,I,N,S,V}P`et. al.'.'`,.
GPRS/MPBN Soultion Integrator, Madagascar.
   LM Ericsson SA Ltd. www.ericsson.com.
    Email  : mustafa.golam at gmail.com
      Mobile : +(261)034-111-77-28
     http://journey2ccie.wordpress.com/

From moua0100 at umn.edu  Sat Mar  7 22:09:02 2009
From: moua0100 at umn.edu (Ge Moua)
Date: Sat, 07 Mar 2009 21:09:02 -0600
Subject: [c-nsp] Open Source solution to deploy a radius server against
 Cisco	devices?
In-Reply-To: <1236449092.8327.12.camel@dsba-ipso>
References: <1236449092.8327.12.camel@dsba-ipso>
Message-ID: <49B336CE.3090608@umn.edu>

We use Radiator over here to manage over 6,000 cisco devices; works 
pretty good on server class hardware.

Regards,
Ge Moua | Email: moua0100 at umn.edu

Network Design Engineer
University of Minnesota | Networking & Telecommunications Services



luismi wrote:
> Hi all,
>
> I am looking for an open source solution to deploy some radius in our
> network.
> The primary goal is to connect to those radius to provide auth services:
> - The VPN Concentrators and vpn accounts (we would move all the vpn
> accounts info to the radius)
> - Validate ip http auth-proxy users
>
> Radius service should be able to be managed using a web interface.
> I don't really mind if there is a proper web interface of if we need to
> install webadmin.
> It also must support accounting.
> And it would be great if it is possible to have the back-end into MySQL.
>
> I was checking FreeRadius and Radiator.
> Any other options?
> All comments are welcome.
>
> Thanks
>
>
> _______________________________________________
> cisco-nsp mailing list  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  Sat Mar  7 23:26:46 2009
From: abalashov at evaristesys.com (Alex Balashov)
Date: Sat, 7 Mar 2009 23:26:46 -0500
Subject: [c-nsp] Open Source solution to deploy a radius server against
	Cisco	devices?
In-Reply-To: <49B336CE.3090608@umn.edu>
References: <1236449092.8327.12.camel@dsba-ipso> <49B336CE.3090608@umn.edu>
Message-ID: <A38D9215-AFCF-48A5-B3F8-58DE4E09C4F8@evaristesys.com>

FreeRADIUS has not been a problem for us.

--
Sent from mobile device

On Mar 7, 2009, at 10:09 PM, Ge Moua <moua0100 at umn.edu> wrote:

> We use Radiator over here to manage over 6,000 cisco devices; works  
> pretty good on server class hardware.
>
> Regards,
> Ge Moua | Email: moua0100 at umn.edu
>
> Network Design Engineer
> University of Minnesota | Networking & Telecommunications Services
>
>
>
> luismi wrote:
>> Hi all,
>>
>> I am looking for an open source solution to deploy some radius in our
>> network.
>> The primary goal is to connect to those radius to provide auth  
>> services:
>> - The VPN Concentrators and vpn accounts (we would move all the vpn
>> accounts info to the radius)
>> - Validate ip http auth-proxy users
>>
>> Radius service should be able to be managed using a web interface.
>> I don't really mind if there is a proper web interface of if we  
>> need to
>> install webadmin.
>> It also must support accounting.
>> And it would be great if it is possible to have the back-end into  
>> MySQL.
>>
>> I was checking FreeRadius and Radiator.
>> Any other options?
>> All comments are welcome.
>>
>> Thanks
>>
>>
>> _______________________________________________
>> cisco-nsp mailing 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 mustafa.golam at gmail.com  Sun Mar  8 01:53:29 2009
From: mustafa.golam at gmail.com (Mustafa Golam -)
Date: Sun, 8 Mar 2009 09:53:29 +0300
Subject: [c-nsp] 3750ME CPU Utilization
In-Reply-To: <BLU130-DS463B38B044C1591F3955EC5A20@phx.gbl>
References: <BLU130-DS41CD1ACBDF52B43539BECC5A20@phx.gbl>
	<fs0l4gxy3z8irg2ekhUYAxe124vaj_firegpg@mail.gmail.com>
	<c72973e60903070948kaee4b68iff3531c6fab96052@mail.gmail.com>
	<BLU130-DS49BC8D21F4064FB79F05CC5A20@phx.gbl>
	<c72973e60903071202od0517f8xd313844301dcb1ff@mail.gmail.com>
	<BLU130-DS463B38B044C1591F3955EC5A20@phx.gbl>
Message-ID: <c72973e60903072253l70175472obceaca6d10475328@mail.gmail.com>

Issue a TAC ticket than. You must be missing something else.
Please show us your running config.
WR,
Mustafa

On Sun, Mar 8, 2009 at 2:25 AM, Manaf Al Oqlah <manafo at hotmail.com> wrote:

>  but I can't live without this option! it is mandatory to prevent users
> ARP and DHCP spoofing
>

From deric.kwok2000 at gmail.com  Sun Mar  8 18:34:12 2009
From: deric.kwok2000 at gmail.com (Deric Kwok)
Date: Sun, 8 Mar 2009 18:34:12 -0400
Subject: [c-nsp] Open Source solution to deploy a radius server against
	Cisco devices?
In-Reply-To: <A38D9215-AFCF-48A5-B3F8-58DE4E09C4F8@evaristesys.com>
References: <1236449092.8327.12.camel@dsba-ipso> <49B336CE.3090608@umn.edu>
	<A38D9215-AFCF-48A5-B3F8-58DE4E09C4F8@evaristesys.com>
Message-ID: <40d8a95a0903081534u2da8e6b7qa7ed69ae3d07c5e@mail.gmail.com>

freeradius is good. I used it in debian (woody and ethic)  before. At that
time, it can support 12,000 DSL users
The database was around 2G. 2G memory and Pentium 4 CPU



On Sun, Mar 8, 2009 at 12:26 AM, Alex Balashov <abalashov at evaristesys.com>wrote:

> FreeRADIUS has not been a problem for us.
>
> --
> Sent from mobile device
>
>
> On Mar 7, 2009, at 10:09 PM, Ge Moua <moua0100 at umn.edu> wrote:
>
> We use Radiator over here to manage over 6,000 cisco devices; works pretty
>> good on server class hardware.
>>
>> Regards,
>> Ge Moua | Email: moua0100 at umn.edu
>>
>> Network Design Engineer
>> University of Minnesota | Networking & Telecommunications Services
>>
>>
>>
>> luismi wrote:
>>
>>> Hi all,
>>>
>>> I am looking for an open source solution to deploy some radius in our
>>> network.
>>> The primary goal is to connect to those radius to provide auth services:
>>> - The VPN Concentrators and vpn accounts (we would move all the vpn
>>> accounts info to the radius)
>>> - Validate ip http auth-proxy users
>>>
>>> Radius service should be able to be managed using a web interface.
>>> I don't really mind if there is a proper web interface of if we need to
>>> install webadmin.
>>> It also must support accounting.
>>> And it would be great if it is possible to have the back-end into MySQL.
>>>
>>> I was checking FreeRadius and Radiator.
>>> Any other options?
>>> All comments are welcome.
>>>
>>> Thanks
>>>
>>>
>>> _______________________________________________
>>> cisco-nsp mailing 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 David at hughes.com.au  Sun Mar  8 18:07:53 2009
From: David at hughes.com.au (David Hughes)
Date: Mon, 9 Mar 2009 08:07:53 +1000
Subject: [c-nsp] Open Source solution to deploy a radius server against
	Cisco	devices?
In-Reply-To: <49B336CE.3090608@umn.edu>
References: <1236449092.8327.12.camel@dsba-ipso> <49B336CE.3090608@umn.edu>
Message-ID: <60C56285-9584-478B-A7CD-C402CBF2ED82@Hughes.com.au>


On 08/03/2009, at 1:09 PM, Ge Moua wrote:

> We use Radiator over here to manage over 6,000 cisco devices; works  
> pretty good on server class hardware.


+1 for Radiator.  It's not opensource as the original poster  
requested, but it's certainly a solid and flexible radius server.


David
...

From Kris.Amy at EIP.net.au  Sun Mar  8 20:32:20 2009
From: Kris.Amy at EIP.net.au (Kris Amy)
Date: Mon, 9 Mar 2009 10:32:20 +1000
Subject: [c-nsp] Open Source solution to deploy a radius server against
 Cisco devices?
In-Reply-To: <60C56285-9584-478B-A7CD-C402CBF2ED82@Hughes.com.au>
Message-ID: <C5DAA0B4.3A88A%kris.amy@eip.net.au>

Another +1 for radiator


On 9/03/09 8:07 AM, "David Hughes" <David at hughes.com.au> wrote:



On 08/03/2009, at 1:09 PM, Ge Moua wrote:

> We use Radiator over here to manage over 6,000 cisco devices; works
> pretty good on server class hardware.


+1 for Radiator.  It's not opensource as the original poster
requested, but it's certainly a solid and flexible radius server.


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


From chaz at chaz6.com  Sun Mar  8 23:29:54 2009
From: chaz at chaz6.com (Chris Hills)
Date: Mon, 09 Mar 2009 04:29:54 +0100
Subject: [c-nsp] Open Source solution to deploy a radius server against
 Cisco devices?
In-Reply-To: <60C56285-9584-478B-A7CD-C402CBF2ED82@Hughes.com.au>
References: <1236449092.8327.12.camel@dsba-ipso> <49B336CE.3090608@umn.edu>
	<60C56285-9584-478B-A7CD-C402CBF2ED82@Hughes.com.au>
Message-ID: <gp22fi$58c$1@ger.gmane.org>

David Hughes wrote:
> +1 for Radiator.  It's not opensource as the original poster requested,
> but it's certainly a solid and flexible radius server.

Radiator /is/ open-source, but it is not free.


From musmanashraf at gmail.com  Mon Mar  9 04:47:29 2009
From: musmanashraf at gmail.com (M Usman Ashraf)
Date: Mon, 9 Mar 2009 13:47:29 +0500
Subject: [c-nsp] How to assign same virtual interface to a PPPoE customer
Message-ID: <9149d2410903090147n39b96601t836e01ea7132be89@mail.gmail.com>

Hi list,

Is there any way by which we can assign same virtual access interface to a
PPPoE customer? We are terminating PPPoE customers on 7301 with 12.2(31)SB14
using BBA groups with virtual-templates and want that a customer X should
always get virtual-interface A. Any idea?

-- 
Regards,

M Usman Ashraf

From benny+usenet at amorsen.dk  Mon Mar  9 04:56:04 2009
From: benny+usenet at amorsen.dk (Benny Amorsen)
Date: Mon, 09 Mar 2009 09:56:04 +0100
Subject: [c-nsp] Open Source solution to deploy a radius server against
	Cisco devices?
In-Reply-To: <gp22fi$58c$1@ger.gmane.org> (Chris Hills's message of "Mon\,
	09 Mar 2009 04\:29\:54 +0100")
References: <1236449092.8327.12.camel@dsba-ipso> <49B336CE.3090608@umn.edu>
	<60C56285-9584-478B-A7CD-C402CBF2ED82@Hughes.com.au>
	<gp22fi$58c$1@ger.gmane.org>
Message-ID: <m3r617xefv.fsf@ursa.amorsen.dk>

Chris Hills <chaz at chaz6.com> writes:

> Radiator /is/ open-source, but it is not free.

The fact that you get the source code doesn't by itself make the
software open-source.

The license may be this one: http://www.open.com.au/license.html but
it says that any click-through license overrides what is written there,
so don't put too much faith in that.


/Benny


From oboehmer at cisco.com  Mon Mar  9 05:01:46 2009
From: oboehmer at cisco.com (Oliver Boehmer (oboehmer))
Date: Mon, 9 Mar 2009 10:01:46 +0100
Subject: [c-nsp] How to assign same virtual interface to a PPPoE customer
In-Reply-To: <9149d2410903090147n39b96601t836e01ea7132be89@mail.gmail.com>
References: <9149d2410903090147n39b96601t836e01ea7132be89@mail.gmail.com>
Message-ID: <70B7A1CCBFA5C649BD562B6D9F7ED78406FF3150@xmb-ams-333.emea.cisco.com>

M Usman Ashraf <> wrote on Monday, March 09, 2009 09:47:

> Hi list,
> 
> Is there any way by which we can assign same virtual access interface
> to a PPPoE customer? We are terminating PPPoE customers on 7301 with
> 12.2(31)SB14 using BBA groups with virtual-templates and want that a
> customer X should always get virtual-interface A. Any idea?

no idea, don't think this is possible. What are you trying to achieve?
If you want to apply user-specific attributes, take a look at AAA
per-user config..

	oli

From A.L.M.Buxey at lboro.ac.uk  Mon Mar  9 05:09:32 2009
From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk)
Date: Mon, 9 Mar 2009 09:09:32 +0000
Subject: [c-nsp] Open Source solution to deploy a radius server
	against	Cisco devices?
In-Reply-To: <60C56285-9584-478B-A7CD-C402CBF2ED82@Hughes.com.au>
References: <1236449092.8327.12.camel@dsba-ipso> <49B336CE.3090608@umn.edu>
	<60C56285-9584-478B-A7CD-C402CBF2ED82@Hughes.com.au>
Message-ID: <20090309090932.GB14149@lboro.ac.uk>

Hi,

> +1 for Radiator.  It's not opensource as the original poster requested, 
> but it's certainly a solid and flexible radius server.

it is Open Source, its just not free.  you, as a user are free to
look at the source code...

please dont confuse 'open source' with 'free software', GPL , BSD, etc

that said, their licence is onorous and feels like its a verbatim
shrink-wrap EULA rather than dealing with what you get.  does reading
their PERL mean I am disassembling it? 

for this last reaosn alone, I'm +1 for FreeRADIUS

alan

From musmanashraf at gmail.com  Mon Mar  9 06:16:02 2009
From: musmanashraf at gmail.com (M Usman Ashraf)
Date: Mon, 9 Mar 2009 15:16:02 +0500
Subject: [c-nsp] How to assign same virtual interface to a PPPoE customer
In-Reply-To: <70B7A1CCBFA5C649BD562B6D9F7ED78406FF3150@xmb-ams-333.emea.cisco.com>
References: <9149d2410903090147n39b96601t836e01ea7132be89@mail.gmail.com>
	<70B7A1CCBFA5C649BD562B6D9F7ED78406FF3150@xmb-ams-333.emea.cisco.com>
Message-ID: <9149d2410903090316g446afbefo1f0a6762532e5a98@mail.gmail.com>

Hi Oliver,

Just wanted to plot MRTG for customers whose CPE has no SNMP support or who
does not want to enable SNMP. Is there any MIB that lists PPPoE username
against the assigned virtual-interface.

On Mon, Mar 9, 2009 at 2:01 PM, Oliver Boehmer (oboehmer) <
oboehmer at cisco.com> wrote:

> M Usman Ashraf <> wrote on Monday, March 09, 2009 09:47:
>
> > Hi list,
> >
> > Is there any way by which we can assign same virtual access interface
> > to a PPPoE customer? We are terminating PPPoE customers on 7301 with
> > 12.2(31)SB14 using BBA groups with virtual-templates and want that a
> > customer X should always get virtual-interface A. Any idea?
>
> no idea, don't think this is possible. What are you trying to achieve?
> If you want to apply user-specific attributes, take a look at AAA
> per-user config..
>
>        oli
>



-- 
Regards,

M Usman Ashraf

From asturluismi at gmail.com  Mon Mar  9 06:34:08 2009
From: asturluismi at gmail.com (luismi)
Date: Mon, 09 Mar 2009 11:34:08 +0100
Subject: [c-nsp] Open Source solution to deploy a radius
	server	against	Cisco devices?
In-Reply-To: <20090309090932.GB14149@lboro.ac.uk>
References: <1236449092.8327.12.camel@dsba-ipso> <49B336CE.3090608@umn.edu>
	<60C56285-9584-478B-A7CD-C402CBF2ED82@Hughes.com.au>
	<20090309090932.GB14149@lboro.ac.uk>
Message-ID: <1236594848.10690.1.camel@dsba-ipso>

Hi all,

As I can see there is just two options over the table: Freeradius and
Radiator.

Is there anyone here with any of them working against VPN Concentrators?
I ask that because it would be the primary goal of the radius.

El lun, 09-03-2009 a las 09:09 +0000, A.L.M.Buxey at lboro.ac.uk escribi?:
> Hi,
> 
> > +1 for Radiator.  It's not opensource as the original poster requested, 
> > but it's certainly a solid and flexible radius server.
> 
> it is Open Source, its just not free.  you, as a user are free to
> look at the source code...
> 
> please dont confuse 'open source' with 'free software', GPL , BSD, etc
> 
> that said, their licence is onorous and feels like its a verbatim
> shrink-wrap EULA rather than dealing with what you get.  does reading
> their PERL mean I am disassembling it? 
> 
> for this last reaosn alone, I'm +1 for FreeRADIUS
> 
> 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 musmanashraf at gmail.com  Mon Mar  9 07:02:39 2009
From: musmanashraf at gmail.com (M Usman Ashraf)
Date: Mon, 9 Mar 2009 16:02:39 +0500
Subject: [c-nsp] How to assign same virtual interface to a PPPoE customer
In-Reply-To: <9149d2410903090401p30239bd2j61c7638819f52103@mail.gmail.com>
References: <9149d2410903090147n39b96601t836e01ea7132be89@mail.gmail.com>
	<70B7A1CCBFA5C649BD562B6D9F7ED78406FF3150@xmb-ams-333.emea.cisco.com>
	<9149d2410903090316g446afbefo1f0a6762532e5a98@mail.gmail.com>
	<c10d10920903090332n3cf7e567vcb051f9f330b6365@mail.gmail.com>
	<9149d2410903090401p30239bd2j61c7638819f52103@mail.gmail.com>
Message-ID: <9149d2410903090402x7249162fi250ec71e2b951101@mail.gmail.com>

>
> Hi Junaid,
>
> Customers have Ethernet based connectivity on Alcatel ONTs that does not
> have SNMP support. Their PPPoE session are terminated on 7301. So we can
> only look for customers stats from this 7301.
>
>
> On Mon, Mar 9, 2009 at 3:32 PM, Junaid <junaid.x86 at gmail.com> wrote:
>
>> Hi,
>>
>> Why don't you try poll (via SNMP) the customer's port on the access
>> device (DSLAM). In this case, you will not have to deal with the
>> dynamic allocation of the interface as the port will be fixed for a
>> customer.
>>
>> Regards,
>> Junaid
>>
>>
>> On Mon, Mar 9, 2009 at 3:16 PM, M Usman Ashraf <musmanashraf at gmail.com>
>> wrote:
>> > Hi Oliver,
>> >
>> > Just wanted to plot MRTG for customers whose CPE has no SNMP support or
>> who
>> > does not want to enable SNMP. Is there any MIB that lists PPPoE username
>> > against the assigned virtual-interface.
>> >
>> > On Mon, Mar 9, 2009 at 2:01 PM, Oliver Boehmer (oboehmer) <
>> > oboehmer at cisco.com> wrote:
>> >
>> >> M Usman Ashraf <> wrote on Monday, March 09, 2009 09:47:
>> >>
>> >> > Hi list,
>> >> >
>> >> > Is there any way by which we can assign same virtual access interface
>> >> > to a PPPoE customer? We are terminating PPPoE customers on 7301 with
>> >> > 12.2(31)SB14 using BBA groups with virtual-templates and want that a
>> >> > customer X should always get virtual-interface A. Any idea?
>> >>
>> >> no idea, don't think this is possible. What are you trying to achieve?
>> >> If you want to apply user-specific attributes, take a look at AAA
>> >> per-user config..
>> >>
>> >>        oli
>> >>
>> >
>> >
>> >
>> > --
>> > Regards,
>> >
>> > M Usman Ashraf
>> > _______________________________________________
>> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> > https://puck.nether.net/mailman/listinfo/cisco-nsp
>> > archive at http://puck.nether.net/pipermail/cisco-nsp/
>> >
>>
>
>
>
>

-- 
Regards,

M Usman Ashraf

From rmikisa at gmail.com  Mon Mar  9 07:09:12 2009
From: rmikisa at gmail.com (Mikisa Richard)
Date: Mon, 9 Mar 2009 14:09:12 +0300
Subject: [c-nsp] Static mapping behind 2 ASA firewall
In-Reply-To: <20090309090932.GB14149@lboro.ac.uk>
References: <1236449092.8327.12.camel@dsba-ipso>
	<49B336CE.3090608@umn.edu>	<60C56285-9584-478B-A7CD-C402CBF2ED82@Hughes.com.au>
	<20090309090932.GB14149@lboro.ac.uk>
Message-ID: <49B4F8D8.1070201@gmail.com>

Hi all,

Scenario below. I have two ASA5520 in my network. Static mapping for 
nodes in LAN A work fine however mappings in LAN B don't. I am making 
the mapping on ASA1. Any ideas as to get mappings for LAN B accessible.

Internet
    |
    |
    |
    ASA1---- LAN A - (192.168.0.0/16)
    |
    |
    |
    ASA2---- LAN B - (10.101.0.0/16)

Richard
   

From david.freedman at uk.clara.net  Mon Mar  9 08:27:27 2009
From: david.freedman at uk.clara.net (David Freedman)
Date: Mon, 09 Mar 2009 12:27:27 +0000
Subject: [c-nsp] How to assign same virtual interface to a PPPoE customer
In-Reply-To: <9149d2410903090316g446afbefo1f0a6762532e5a98@mail.gmail.com>
References: <9149d2410903090147n39b96601t836e01ea7132be89@mail.gmail.com>	<70B7A1CCBFA5C649BD562B6D9F7ED78406FF3150@xmb-ams-333.emea.cisco.com>
	<9149d2410903090316g446afbefo1f0a6762532e5a98@mail.gmail.com>
Message-ID: <gp31vf$jl1$1@ger.gmane.org>

I would strongly advise against this, take a look at RADIUS interim
accounting and then storing that in RRD databases.

Dave.

M Usman Ashraf wrote:
> Hi Oliver,
> 
> Just wanted to plot MRTG for customers whose CPE has no SNMP support or who
> does not want to enable SNMP. Is there any MIB that lists PPPoE username
> against the assigned virtual-interface.
> 
> On Mon, Mar 9, 2009 at 2:01 PM, Oliver Boehmer (oboehmer) <
> oboehmer at cisco.com> wrote:
> 
>> M Usman Ashraf <> wrote on Monday, March 09, 2009 09:47:
>>
>>> Hi list,
>>>
>>> Is there any way by which we can assign same virtual access interface
>>> to a PPPoE customer? We are terminating PPPoE customers on 7301 with
>>> 12.2(31)SB14 using BBA groups with virtual-templates and want that a
>>> customer X should always get virtual-interface A. Any idea?
>> no idea, don't think this is possible. What are you trying to achieve?
>> If you want to apply user-specific attributes, take a look at AAA
>> per-user config..
>>
>>        oli
>>
> 
> 
> 


From tim at muppetz.com  Mon Mar  9 08:01:47 2009
From: tim at muppetz.com (TiM)
Date: Mon, 9 Mar 2009 12:01:47 -0000 (GMT)
Subject: [c-nsp] GLBP Groups Question
Message-ID: <c6e3274349e11d5674dc7952fd7c656e.squirrel@muppetz.com>

Hi,

Short version of question: Does putting multiple SVI's in the same GLBP
group save resources? i.e. is it more efficent to have 10 SVI's in 5 GLBP
groups, or is there no difference in resource usage?

Long version of question:

I'm looking to have ~10 3750 stacks connected to a couple of Cisco 7609s. 
To avoid any spanning tree hassles, a vlan on one stack will not appear on
any other stack.  A decision has been made to keep the management of the
3750's in a seperate VLAN, therefore I'll need ~10 extra vlans to manage
all 3750 stacks.

Therefore, assume that each stack has a Data, Voice and Management VLAN.

I'm going to be running GLBP on the 7609's, so that traffic is spread over
the 7609s and there is redundancy in th event of 7609 failure.

In order to ensure that I can always manage a 3750 Stack, I'm going to be
adding the Management VLAN into GLBP as well.  Will the extra 10 GLBP
sessions add extra CPU overhead/load to the 7609s?  Using the group
feature, if I have a group 10 for Stack 1, group 20 for stack 2 etc, does
adding the Management VLAN to that group save on CPU/keepalive traffic?

Really my question boils down to:

Is this configuration:

interface Vlan10
 description Data Stack 1
 ip address x.x.x.x 255.255.255.0
 glbp 10 ip x.x.x.x
!
interface Vlan11
 description Management Stack 1
 ip address y.y.y.y 255.255.255.0
 glbp 10 ip y.y.y.y

anymore efficent than this configuration:

interface Vlan10
 description Data Stack 1
 ip address x.x.x.x 255.255.255.0
 glbp 10 ip x.x.x.x
!
interface Vlan11
 description Management Stack 1
 ip address y.y.y.y 255.255.255.0
 glbp 11 ip y.y.y.y

Many Thanks,
Tim



From cmadams at hiwaay.net  Mon Mar  9 09:02:21 2009
From: cmadams at hiwaay.net (Chris Adams)
Date: Mon, 9 Mar 2009 08:02:21 -0500
Subject: [c-nsp] Open Source solution to deploy a radius server
	against	Cisco devices?
In-Reply-To: <20090309090932.GB14149@lboro.ac.uk>
References: <1236449092.8327.12.camel@dsba-ipso> <49B336CE.3090608@umn.edu>
	<60C56285-9584-478B-A7CD-C402CBF2ED82@Hughes.com.au>
	<20090309090932.GB14149@lboro.ac.uk>
Message-ID: <20090309130221.GA1282392@hiwaay.net>

Once upon a time, A.L.M.Buxey at lboro.ac.uk <A.L.M.Buxey at lboro.ac.uk> said:
> it is Open Source, its just not free.  you, as a user are free to
> look at the source code...
> 
> please dont confuse 'open source' with 'free software', GPL , BSD, etc

"Open Source" is a trademarked term that has specific requirements.
Freedom to modify and redistribute the source code is a major part of
that (e.g. GPL, BSD license, etc.).  Don't confuse "you can look but not
touch" with "Open Source".

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

From oboehmer at cisco.com  Mon Mar  9 09:04:00 2009
From: oboehmer at cisco.com (Oliver Boehmer (oboehmer))
Date: Mon, 9 Mar 2009 14:04:00 +0100
Subject: [c-nsp] How to assign same virtual interface to a PPPoE customer
In-Reply-To: <gp31vf$jl1$1@ger.gmane.org>
References: <9149d2410903090147n39b96601t836e01ea7132be89@mail.gmail.com>	<70B7A1CCBFA5C649BD562B6D9F7ED78406FF3150@xmb-ams-333.emea.cisco.com><9149d2410903090316g446afbefo1f0a6762532e5a98@mail.gmail.com>
	<gp31vf$jl1$1@ger.gmane.org>
Message-ID: <70B7A1CCBFA5C649BD562B6D9F7ED78406FF33B7@xmb-ams-333.emea.cisco.com>

Agreed, this is much better as you don't have to periodically poll and
watch for session re-connects..

If you still want to go down the SNMP path: You can poll the
AAA-SESSION-MIB, and use casnVaiIfIndex OID which references the ifIndex
for this particular user.. 

	oli

David Freedman <> wrote on Monday, March 09, 2009 13:27:

> I would strongly advise against this, take a look at RADIUS interim
> accounting and then storing that in RRD databases.
> 
> Dave.
> 
> M Usman Ashraf wrote:
>> Hi Oliver,
>> 
>> Just wanted to plot MRTG for customers whose CPE has no SNMP support
>> or who does not want to enable SNMP. Is there any MIB that lists
>> PPPoE username against the assigned virtual-interface.
>> 
>> On Mon, Mar 9, 2009 at 2:01 PM, Oliver Boehmer (oboehmer) <
>> oboehmer at cisco.com> wrote: 
>> 
>>> M Usman Ashraf <> wrote on Monday, March 09, 2009 09:47:
>>> 
>>>> Hi list,
>>>> 
>>>> Is there any way by which we can assign same virtual access
>>>> interface to a PPPoE customer? We are terminating PPPoE customers
>>>> on 7301 with 
>>>> 12.2(31)SB14 using BBA groups with virtual-templates and want that
>>>> a customer X should always get virtual-interface A. Any idea?
>>> no idea, don't think this is possible. What are you trying to
>>> achieve? If you want to apply user-specific attributes, take a look
>>> at AAA per-user config.. 
>>> 
>>>        oli
>>> 
>> 
>> 
>> 
> 
> _______________________________________________
> cisco-nsp mailing list  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  Mon Mar  9 09:48:26 2009
From: p.mayers at imperial.ac.uk (Phil Mayers)
Date: Mon, 09 Mar 2009 13:48:26 +0000
Subject: [c-nsp] GLBP Groups Question
In-Reply-To: <c6e3274349e11d5674dc7952fd7c656e.squirrel@muppetz.com>
References: <c6e3274349e11d5674dc7952fd7c656e.squirrel@muppetz.com>
Message-ID: <49B51E2A.7010305@imperial.ac.uk>

> 
> Really my question boils down to:
> 
> Is this configuration:
> 
> interface Vlan10
>  description Data Stack 1
>  ip address x.x.x.x 255.255.255.0
>  glbp 10 ip x.x.x.x
> !
> interface Vlan11
>  description Management Stack 1
>  ip address y.y.y.y 255.255.255.0
>  glbp 10 ip y.y.y.y
> 
> anymore efficent than this configuration:
> 
> interface Vlan10
>  description Data Stack 1
>  ip address x.x.x.x 255.255.255.0
>  glbp 10 ip x.x.x.x
> !
> interface Vlan11
>  description Management Stack 1
>  ip address y.y.y.y 255.255.255.0
>  glbp 11 ip y.y.y.y

I don't think so. The GLBP groups are local to an SVI.

HOWEVER - each GLBP group uses a different GLBP virtual MAC address, and 
the sup has a limit as to the size of it's MAC receive filter - 64 on 
older hardware, and 1024 on newer hardware - so using the same group is 
still valuable

HSRP has a feature called "hsrp multiple group optimisation" that will 
do what you want, but it doesn't work on SVIs - only subints (bah).

From jmaimon at ttec.com  Mon Mar  9 11:33:08 2009
From: jmaimon at ttec.com (Joe Maimon)
Date: Mon, 09 Mar 2009 11:33:08 -0400
Subject: [c-nsp] How to assign same virtual interface to a PPPoE customer
In-Reply-To: <9149d2410903090316g446afbefo1f0a6762532e5a98@mail.gmail.com>
References: <9149d2410903090147n39b96601t836e01ea7132be89@mail.gmail.com>	<70B7A1CCBFA5C649BD562B6D9F7ED78406FF3150@xmb-ams-333.emea.cisco.com>
	<9149d2410903090316g446afbefo1f0a6762532e5a98@mail.gmail.com>
Message-ID: <49B536B4.6020105@ttec.com>

Assuming you use a radius server that can place its accounting data in a 
sql server, this should work fairly well for you

http://www.jmaimon.com/freeradius/mrtg-radsql/mrtg-radsql.tar.gz



M Usman Ashraf wrote:
> Hi Oliver,
> 
> Just wanted to plot MRTG for customers whose CPE has no SNMP support or who
> does not want to enable SNMP. Is there any MIB that lists PPPoE username
> against the assigned virtual-interface.
> 
> On Mon, Mar 9, 2009 at 2:01 PM, Oliver Boehmer (oboehmer) <
> oboehmer at cisco.com> wrote:
> 
>> M Usman Ashraf <> wrote on Monday, March 09, 2009 09:47:
>>
>>> Hi list,
>>>
>>> Is there any way by which we can assign same virtual access interface
>>> to a PPPoE customer? We are terminating PPPoE customers on 7301 with
>>> 12.2(31)SB14 using BBA groups with virtual-templates and want that a
>>> customer X should always get virtual-interface A. Any idea?
>> no idea, don't think this is possible. What are you trying to achieve?
>> If you want to apply user-specific attributes, take a look at AAA
>> per-user config..
>>
>>        oli
>>
> 
> 
> 

From deric.kwok2000 at gmail.com  Mon Mar  9 11:59:56 2009
From: deric.kwok2000 at gmail.com (Deric Kwok)
Date: Mon, 9 Mar 2009 11:59:56 -0400
Subject: [c-nsp] Open Source solution to deploy a radius server against
	Cisco devices?
In-Reply-To: <1236594848.10690.1.camel@dsba-ipso>
References: <1236449092.8327.12.camel@dsba-ipso> <49B336CE.3090608@umn.edu>
	<60C56285-9584-478B-A7CD-C402CBF2ED82@Hughes.com.au>
	<20090309090932.GB14149@lboro.ac.uk>
	<1236594848.10690.1.camel@dsba-ipso>
Message-ID: <40d8a95a0903090859u31b633d3u2eb5db04d5160581@mail.gmail.com>

To me, I haven't used freeradius for VPN Concentrator. and haven't used
Radiator

But I think you can try it

Just use computer to install any distribution of linux (debian is better) +
freeradius.
(if you have installation quesiton, i try to help)

or

Post this in freeradius newsgroup http://freeradius.org/list/index.html
"Anyone to use freeradius in VPN Concentrator"

I think you can get immediately response

HTH




On Mon, Mar 9, 2009 at 6:34 AM, luismi <asturluismi at gmail.com> wrote:

> Hi all,
>
> As I can see there is just two options over the table: Freeradius and
> Radiator.
>
> Is there anyone here with any of them working against VPN Concentrators?
> I ask that because it would be the primary goal of the radius.
>
> El lun, 09-03-2009 a las 09:09 +0000, A.L.M.Buxey at lboro.ac.uk escribi?:
>  > Hi,
> >
> > > +1 for Radiator.  It's not opensource as the original poster requested,
> > > but it's certainly a solid and flexible radius server.
> >
> > it is Open Source, its just not free.  you, as a user are free to
> > look at the source code...
> >
> > please dont confuse 'open source' with 'free software', GPL , BSD, etc
> >
> > that said, their licence is onorous and feels like its a verbatim
> > shrink-wrap EULA rather than dealing with what you get.  does reading
> > their PERL mean I am disassembling it?
> >
> > for this last reaosn alone, I'm +1 for FreeRADIUS
> >
> > 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 A.L.M.Buxey at lboro.ac.uk  Mon Mar  9 12:21:23 2009
From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk)
Date: Mon, 9 Mar 2009 16:21:23 +0000
Subject: [c-nsp] Open Source solution to deploy a radius server
	against	Cisco devices?
In-Reply-To: <40d8a95a0903090859u31b633d3u2eb5db04d5160581@mail.gmail.com>
References: <1236449092.8327.12.camel@dsba-ipso> <49B336CE.3090608@umn.edu>
	<60C56285-9584-478B-A7CD-C402CBF2ED82@Hughes.com.au>
	<20090309090932.GB14149@lboro.ac.uk>
	<1236594848.10690.1.camel@dsba-ipso>
	<40d8a95a0903090859u31b633d3u2eb5db04d5160581@mail.gmail.com>
Message-ID: <20090309162123.GB15892@lboro.ac.uk>

Hi,

> Post this in freeradius newsgroup http://freeradius.org/list/index.html
> "Anyone to use freeradius in VPN Concentrator"

alternatively use google.  do most sites now ban access to google? :-)

"freeradius cisco vpn concentrator"

eg 
http://1000milesnetwork.blogspot.com/2005/12/freeradius-iii.html

alan

From mradulovic at comutel.co.rs  Mon Mar  9 11:01:19 2009
From: mradulovic at comutel.co.rs (Miodrag Radulovic)
Date: Mon, 9 Mar 2009 16:01:19 +0100
Subject: [c-nsp] AUTO: Miodrag Radulovic is out of the office (returning
	16-03-2009)
Message-ID: <OF4F67EB74.8FB92E2A-ONC1257574.005284FC-C1257574.005284FC@nil.si>



I am out of the office until 16-03-2009.

Privremeno nedostupan - Out-of-Office Message.

Poruka koju ste poslali je prispela i bice sacuvana, napominjem da je za
vreme mog puta
pristup elektronskoj posti veoma ogranicen.

The message that you have sent will be saved in my inbox, but please
note that I will be out of the country and my access to my email will be
very limited.

Miodrag Radulovic
General Manager
COMUTEL



Note: This is an automated response to your message  "cisco-nsp Digest, Vol
76, Issue 26" sent on 9.3.2009 11:34:21.

This is the only notification you will receive while this person is away.

From justin at justinshore.com  Mon Mar  9 12:30:33 2009
From: justin at justinshore.com (Justin Shore)
Date: Mon, 09 Mar 2009 11:30:33 -0500
Subject: [c-nsp] MPLS LDP and BGP Neighbor flapping constantly
In-Reply-To: <49B01480.5020003@uk.clara.net>
References: <49AF7271.40507@justinshore.com> <49B01480.5020003@uk.clara.net>
Message-ID: <49B54429.2080505@justinshore.com>

This message slipped through the cracks.  It leads me to giving an 
update on the problem though.

I worked with TAC to troubleshoot the issue last week.  The TAC engineer 
also noticed the giants on the 7600's side.  He tried sending large 
ICMPs through to the 7600 from the 7201.  Nothing over 1508 would pass 
even though the interface MTU was 9000 on both sides (and the IP MTU 
followed).  Even sending ICMPs WITHOUT df set still resulted in a 
failure.  We dropped the MTU to 1500 and suddenly we could send large 
ICMPs that needed to be fragged.  Very weird.  It gets weirder though.

Prior to calling TAC I upgraded the code on another 7201 that's 
dual-homed to both 7613s in the core.  As soon as I reloaded that 7201 
LDP on it also started flapping to BOTH 7600s (the original 7201 was 
only single-homed to one 7600).  BGP appears to be unaffected on this 
7201.  So now I have 2 7201s with constantly flapping LDP neighbors. 
The 2nd 7201 also can't ping either 7600 with large ICMPs.  However, and 
this is weird, BOTH 7600s can ping the loopback on the 7201 with 9000 
byte ICMPs.

When I wrote that last sentence it got me thinking.  I was pinging from 
the 7201s to Lo0 on the 7600s.  Large ICMPs weren't getting there and 
giants were logged on the incoming L3 interface on the 7600s.  I can 
ping from the 2nd 7201 to the directly-connected interface on either 
7600 with large ICMPs and they are not dropped and no giants are logged. 
  Even though it can send large frames to the directly-connected 
interface it can't to the loopback.  I don't believe that's normal. 
 From the 7600 I can turn around and ping the loopback on the 2nd 7201 
with jumbo frames without any problems.  It's like MTU is only being 
honored in one direction.

This is a confusing one to me that smells like a bug.  I'm running SRB1 
on both 7600s and was running different 12.4(15)Tn releases on the 
7201s.  They are both now running 12.2(24)T.  I'll drop one of them back 
to an early 12.4(15)Tn tonight to troubleshoot if I have to.  The 
problem occured on the 1st 7201 without a code change and didn't occur 
on the 2nd until after the code change and reboot.

Any thoughts?
  Justin


David Freedman wrote:
> You appear to have a high number of input queue drops and input errors,
> granted the counters have never been cleared, do you haver any PPS
> graphs of the link between these two boxes? I would suspect a traffic
> spike or link fault causing control messages to be dropped being the
> cause here.


From jmaimon at ttec.com  Mon Mar  9 12:52:38 2009
From: jmaimon at ttec.com (Joe Maimon)
Date: Mon, 09 Mar 2009 12:52:38 -0400
Subject: [c-nsp] Open Source solution to deploy a radius server	against
 Cisco devices?
In-Reply-To: <20090309090932.GB14149@lboro.ac.uk>
References: <1236449092.8327.12.camel@dsba-ipso>
	<49B336CE.3090608@umn.edu>	<60C56285-9584-478B-A7CD-C402CBF2ED82@Hughes.com.au>
	<20090309090932.GB14149@lboro.ac.uk>
Message-ID: <49B54956.6080107@ttec.com>



A.L.M.Buxey at lboro.ac.uk wrote:
> Hi,
> 
>> +1 for Radiator.  It's not opensource as the original poster requested, 
>> but it's certainly a solid and flexible radius server.
> 
> it is Open Source, its just not free.  you, as a user are free to
> look at the source code...
> 
> please dont confuse 'open source' with 'free software', GPL , BSD, etc

This really isnt the time and place, but to prevent any confusion:

Open Source has an official meaning and definition, which I believe the 
thread is referring to, as opposed to any other informal or incorrect 
meaning of the phrase.

http://www.opensource.org/docs/osd

Source Available does not mean Open Source.



> that said, their licence is onorous and feels like its a verbatim
> shrink-wrap EULA rather than dealing with what you get.  does reading
> their PERL mean I am disassembling it? 

Doesnt sound like it is Open Source by any definition.

> 
> for this last reaosn alone, I'm +1 for FreeRADIUS
> 
> 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 frnkblk at iname.com  Mon Mar  9 14:32:33 2009
From: frnkblk at iname.com (Frank Bulk - iName.com)
Date: Mon, 9 Mar 2009 13:32:33 -0500
Subject: [c-nsp] Egress shaping/policing for bandwidth control on a 3750-ME
Message-ID: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAB8J+z/vkTlTa26LBvnRFWxAQAAAAA=@iname.com>

I have two Cisco 3750-ME (Metro) where we are trying to apply an 8 Mbps
bandwidth limit to it.  

We tried HQM shaping but got a lovely message that "Hierarchical
service-policies are only supported on ES interfaces".  

When we tried policing, we can't seem to apply the "mls qos bridged" command
to it:
	router(config)#interface vlan 260
	router(config-if)#mls ?
	% Unrecognized command
	router(config-if)#mls

This is the relevant configuration to our policing attempt:
	ip access-list extended customer-policer_inbound
	 permit ip any any
	ip access-list extended customer-policer_outbound
	 permit ip any any
	
	class-map match-any customer-networks
	  match access-group name customer-policer_inbound
	  match access-group name customer-policer_outbound
	!
	
	policy-map customer-policer
	  class customer-networks
	   police 8000000 1000000 exceed-action drop
	!

	interface Vlan260
	 mls qos bridged
	 service-policy input customer-policer
	 service-policy output customer-policer
	!

	interface Gi1/0/1
	  mls qos vlan-based
	!

To get shaping work we should have had the uplink interface use non-ES ports
and the interface facing our core use the ES ports. 

Any other ideas in terms or policing/shaping?

Regards,

Frank


From peter at rathlev.dk  Mon Mar  9 17:15:44 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Mon, 09 Mar 2009 22:15:44 +0100
Subject: [c-nsp] FWSM HA secondary reload & long downtime
Message-ID: <1236633344.3572.13.camel@localhost.localdomain>

Hi,

We've had some problems with an old pair of FWSMs lately running 2.3(4).
We're testing and collecting information to maybe open a ticket, but
during this I found something I hadn't expected.

Currently we have experienced ~10 secs failover from active to standby
in a HA pair when using 3 sec hello and 10 sec downtime. This is fine
for us.

On a running system we can switch around with "no failover active" /
"failover active" with no problems either.

BUT: When we reload the standby unit, we experience very long downtime.
It seems to happen when the standby unit resurfaces and seems to be for
as long as they're replicating configurations.

This time around it was the configured secondary that was active. When
the primary was brought up the secondary's logs said:

Mar 09 2009 16:39:56: %FWSM-1-709003: (Secondary) Beginning configuration replication: Send to mate.
Mar 09 2009 16:41:26: %FWSM-1-709004: (Secondary) End Configuration Replication (ACT)

Are we supposed to have this much downtime for an _up_ convergence? This
pair is configured with 19 contexts, so replication of course must take
some time. I just don't see why the running active has to stop
forwarding traffic.

I can't seem to find any information on this on cisco.com, still looking
though. I can't test it very much because we only have one spare
FWSM. :-(

Failover configuration from sys context:

failover
failover lan unit secondary
failover lan interface failover vlan 553
failover polltime unit 3 holdtime 10
failover polltime interface 3
failover interface-policy 1
failover replication http
failover link statefullfailover vlan 554
failover interface ip failover 10.220.254.1 255.255.255.0 standby 10.220.254.2
failover interface ip statefullfailover 10.220.253.1 255.255.255.0 standby 10.220.253.2

The primary (standby) is of course configured similarly.

Any comments/pointers very much appreciated. :-)

Regards,
Peter



From david at hughes.com.au  Mon Mar  9 19:02:42 2009
From: david at hughes.com.au (David Hughes)
Date: Tue, 10 Mar 2009 09:02:42 +1000
Subject: [c-nsp] Open Source solution to deploy a radius server against
	Cisco devices?
In-Reply-To: <gp22fi$58c$1@ger.gmane.org>
References: <1236449092.8327.12.camel@dsba-ipso> <49B336CE.3090608@umn.edu>
	<60C56285-9584-478B-A7CD-C402CBF2ED82@Hughes.com.au>
	<gp22fi$58c$1@ger.gmane.org>
Message-ID: <EBB17C82-1EC3-44C7-9FFC-DDB62EA1C7CA@hughes.com.au>


On 09/03/2009, at 1:29 PM, Chris Hills wrote:

> David Hughes wrote:
>> +1 for Radiator.  It's not opensource as the original poster  
>> requested,
>> but it's certainly a solid and flexible radius server.
>
> Radiator /is/ open-source, but it is not free.

Nope.  Commercial licensed product.  Which isn't a bad thing - it  
helps the guys writing the code feed themselves.



David
...



From jay at west.net  Mon Mar  9 19:14:33 2009
From: jay at west.net (Jay Hennigan)
Date: Mon, 09 Mar 2009 16:14:33 -0700
Subject: [c-nsp] snmp-server ifindex persist - store data on flash/disk?
Message-ID: <49B5A2D9.5000106@west.net>

We have a number of 7206VXR boxes terminating ATM ADSL aggregation 
circuits.  With a large number of interfaces, the persistent index table 
is too large for NVRAM and the interface IDs change on reboot just as if 
the command weren't specified.

Is there a workaround or command to store the persistent data on the 
flash disk which has plenty of room?

--
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 jlewis at lewis.org  Mon Mar  9 19:16:49 2009
From: jlewis at lewis.org (Jon Lewis)
Date: Mon, 9 Mar 2009 19:16:49 -0400 (EDT)
Subject: [c-nsp] Open Source solution to deploy a radius server against
 Cisco devices?
In-Reply-To: <1236594848.10690.1.camel@dsba-ipso>
References: <1236449092.8327.12.camel@dsba-ipso> <49B336CE.3090608@umn.edu>
	<60C56285-9584-478B-A7CD-C402CBF2ED82@Hughes.com.au>
	<20090309090932.GB14149@lboro.ac.uk>
	<1236594848.10690.1.camel@dsba-ipso>
Message-ID: <Pine.LNX.4.61.0903091911190.6312@soloth.lewis.org>

On Mon, 9 Mar 2009, luismi wrote:

> Hi all,
>
> As I can see there is just two options over the table: Freeradius and
> Radiator.

Another option is Cistron Radius http://www.radius.cistron.nl/ which is 
probably going to be pretty similar to Freeradius, since the latter is 
apparently a fork of the former.

Radiator is perl, so you get the 'source code', but it's not open source 
and you do need to buy a license to use it.

----------------------------------------------------------------------
  Jon Lewis                   |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

From deric.kwok2000 at gmail.com  Mon Mar  9 19:20:12 2009
From: deric.kwok2000 at gmail.com (Deric Kwok)
Date: Mon, 9 Mar 2009 19:20:12 -0400
Subject: [c-nsp] Open Source solution to deploy a radius server against
	Cisco devices?
In-Reply-To: <EBB17C82-1EC3-44C7-9FFC-DDB62EA1C7CA@hughes.com.au>
References: <1236449092.8327.12.camel@dsba-ipso> <49B336CE.3090608@umn.edu>
	<60C56285-9584-478B-A7CD-C402CBF2ED82@Hughes.com.au>
	<gp22fi$58c$1@ger.gmane.org>
	<EBB17C82-1EC3-44C7-9FFC-DDB62EA1C7CA@hughes.com.au>
Message-ID: <40d8a95a0903091620j1c707e14k4e6a65f1f1564b9d@mail.gmail.com>

Yes. isn't bad

It depends on the budget

You can spend hundred thousand dollars to buy 10G router
or buy $1,500 a  (4 cores) computer running quagga to have $6,000 a 10G card
on it.







On Mon, Mar 9, 2009 at 7:02 PM, David Hughes <david at hughes.com.au> wrote:

>
> On 09/03/2009, at 1:29 PM, Chris Hills wrote:
>
> David Hughes wrote:
>>
>>> +1 for Radiator.  It's not opensource as the original poster requested,
>>> but it's certainly a solid and flexible radius server.
>>>
>>
>> Radiator /is/ open-source, but it is not free.
>>
>
> Nope.  Commercial licensed product.  Which isn't a bad thing - it helps the
> guys writing the code feed themselves.
>
>
>
> David
> ...
>
>
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From cmadams at hiwaay.net  Mon Mar  9 19:50:53 2009
From: cmadams at hiwaay.net (Chris Adams)
Date: Mon, 9 Mar 2009 18:50:53 -0500
Subject: [c-nsp] Open Source solution to deploy a radius server against
	Cisco devices?
In-Reply-To: <Pine.LNX.4.61.0903091911190.6312@soloth.lewis.org>
References: <1236449092.8327.12.camel@dsba-ipso> <49B336CE.3090608@umn.edu>
	<60C56285-9584-478B-A7CD-C402CBF2ED82@Hughes.com.au>
	<20090309090932.GB14149@lboro.ac.uk>
	<1236594848.10690.1.camel@dsba-ipso>
	<Pine.LNX.4.61.0903091911190.6312@soloth.lewis.org>
Message-ID: <20090309235053.GA604180@hiwaay.net>

Once upon a time, Jon Lewis <jlewis at lewis.org> said:
> Another option is Cistron Radius http://www.radius.cistron.nl/ which is 
> probably going to be pretty similar to Freeradius, since the latter is 
> apparently a fork of the former.

Cistron RADIUS (which was based on the original Livingston RADIUS
server) development has pretty much stopped in favor of FreeRADIUS.
There is also a fork of FreeRADIUS called OpenRADIUS; I don't remember
the reasons for the fork.

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

From brad.henshaw at qcn.com.au  Mon Mar  9 19:59:19 2009
From: brad.henshaw at qcn.com.au (Brad Henshaw)
Date: Tue, 10 Mar 2009 09:59:19 +1000
Subject: [c-nsp] Egress shaping/policing for bandwidth control on a
	3750-ME
Message-ID: <8B25B862BC09784B9B74FB950D4F64D40F81CF@qcnapp01.corp.qcn>

Frank Bulk - iName.com wrote:
 
> I have two Cisco 3750-ME (Metro) where we are trying to apply
> an 8 Mbps bandwidth limit to it.  
> We tried HQM shaping but got a lovely message that "Hierarchical
> service-policies are only supported on ES interfaces".

Frank,

The 3750ME can only do per-VLAN shaping on the ES ports.

You can shape standard ports (but not per-VLAN) in increments of 10% of
the port speed using the 'srr-queue bandwidth limit' command. To achieve
8Mbps with this you'd need to lock the [FastEthernet] port to 10Mbps and
set the limit to 80%. Buffering of packets is less than ideal.

The 3750ME supports hierarchical dual-level *ingress* policies on SVIs.
To use these you need to set 'mls qos vlan-based' on the port and may
or may not need to use a 'match input-interface' statement in the class
of a subpolicy. (I've never used these so can't comment with authority)

I'd provide an example but I'd just be ripping it from page 35-71 of
the 3750 Metro 12.2(46)SE Software Configuration Guide ;-)

I'm pretty sure neither SVIs nor standard ports support output policies
so you'd best do as much as you can on the ES ports on ingress from your
core.

Note that ingress service policies on 12.2(44)SE1 seem to be broken - 
This may also affect other versions. We never logged a bug because it's
fixed in 12.2(46)SE.

Overall I think the quality control on IOS releases for the 3750ME
leaves a BLOODY LOT to be desired.

Regards,
Brad

From andy.saykao at staff.netspace.net.au  Mon Mar  9 21:19:27 2009
From: andy.saykao at staff.netspace.net.au (Andy Saykao)
Date: Tue, 10 Mar 2009 12:19:27 +1100
Subject: [c-nsp] L3 MPLS VPN Question - Redundant Internet Access
Message-ID: <56F211C5E3F24F47B103EA1B253822BE03654C4E@vic-cr-ex1.staff.netspace.net.au>

Hi All,
 
I'm trying to build some redundancy for our L3 MPLS VPN customers for
Internet access. 
 
At the moment, customers gain Internet access via their Central Site. We
configure a default route on the PE connecting the Central Site and use
BGP to redistribute the default route to all other PE's with the
"default-information originate" command like so: 
 
ip route vrf NSTEST 0.0.0.0 0.0.0.0 GigabitEthernet0/1.902 10.15.99.2
!
interface GigabitEthernet0/1.902
 description NSTEST VPN Link
 encapsulation dot1Q 902
 ip vrf forwarding NSTEST
 ip address 10.15.99.1 255.255.255.252
!
address-family ipv4 vrf NSTEST
  redistribute connected
  redistribute static
  default-information originate
  no auto-summary
  no synchronization
 exit-address-family

In the event that the VPN link to the Central Site goes down and branch
sites can no longer gain Internet access via the Central Site, I've set
up a NAT-PE for Internet traffic as a form of redundancy. 
 
[WWW] <-- [NAT-PE] <-- [Branch Site] --> [Central Site] --> [WWW]
 
To accomplish this, I configured a default route on the NAT-PE and can
"manuallly" trigger the default route to be redistributed to the PE's
when the Central Site is down - just wondering if there a way to do this
automatically so that when the Central Site is down, Internet traffic
goes via the NAT-PE and when the Central Site is back up, Internet
traffic once again goes via the Central Site??? The NAT-PE is a
dedicated router and has no CE's attached to it.
 
I've tried a few different things, but couldn't get it to work. I'm not
sure if you can alter the way iBGP behaves and maybe give the default
route learnt from the NAT-PE via iBGP a higher admistrative distance of
say 250 (rather than the default 200) so that when the Central Site is
down, the default route from the NAT-PE gets installed.
 
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 oboehmer at cisco.com  Tue Mar 10 03:01:28 2009
From: oboehmer at cisco.com (Oliver Boehmer (oboehmer))
Date: Tue, 10 Mar 2009 08:01:28 +0100
Subject: [c-nsp] L3 MPLS VPN Question - Redundant Internet Access
In-Reply-To: <56F211C5E3F24F47B103EA1B253822BE03654C4E@vic-cr-ex1.staff.netspace.net.au>
References: <56F211C5E3F24F47B103EA1B253822BE03654C4E@vic-cr-ex1.staff.netspace.net.au>
Message-ID: <70B7A1CCBFA5C649BD562B6D9F7ED7840704CE8C@xmb-ams-333.emea.cisco.com>

Andy Saykao <> wrote on Tuesday, March 10, 2009 02:19:

[...]
> In the event that the VPN link to the Central Site goes down and
> branch sites can no longer gain Internet access via the Central Site,
> I've set 
> up a NAT-PE for Internet traffic as a form of redundancy.
> 
> [WWW] <-- [NAT-PE] <-- [Branch Site] --> [Central Site] --> [WWW]
> 
> To accomplish this, I configured a default route on the NAT-PE and can
> "manuallly" trigger the default route to be redistributed to the PE's
> when the Central Site is down - just wondering if there a way to do
> this automatically so that when the Central Site is down, Internet
> traffic goes via the NAT-PE and when the Central Site is back up,
Internet
> traffic once again goes via the Central Site??? The NAT-PE is a
> dedicated router and has no CE's attached to it.

sure:

on the NAT-PE, you can have the default-route up all the time (as there
is no CE attached to it), so just advertise it with a lower local-pref:

address-family ipv4 vrf ..
 default-information originate
 redistribute static route-map foo
!
ip route vrf <foo> 0.0.0.0 0.0.0.0 oif next-hop
!
route-map foo
 set local-preference 80

if you don't want the NAT-PE to always have the static default up, you
need to use a floating static and manipulate the weight so the central
site's default route will overwrite it:

ip route vrf <foo> 0.0.0.0 0.0.0.0 oif next-hop 210
route-map foo
 set local-preference 80
 set weight 0


HTH,

	oli

From manafo at hotmail.com  Tue Mar 10 03:41:59 2009
From: manafo at hotmail.com (Manaf Al Oqlah)
Date: Tue, 10 Mar 2009 09:41:59 +0200
Subject: [c-nsp] OSPF Default Route
Message-ID: <BLU130-DS74B6D429DD464F8402CA0C5A10@phx.gbl>

Hi,

Is there any way to advertise default route in OSPF with a specific metric to an interface and another metric to another interface. For example, I want to advertise default route (default-information originate) for neighbor connected to gigabit 1/0 with metric 10 and for neighbor connected to gigabit 1/1 with metric 20.

Thank you

From b.turnbow at twt.it  Tue Mar 10 04:22:41 2009
From: b.turnbow at twt.it (Brian Turnbow)
Date: Tue, 10 Mar 2009 09:22:41 +0100
Subject: [c-nsp] snmp-server ifindex persist - store data on flash/disk?
In-Reply-To: <49B5A2D9.5000106@west.net>
References: <49B5A2D9.5000106@west.net>
Message-ID: <F2207DB22012F94E92D7030F81A2629401DBEB5A@twt-exch.milano.twt>

I'm guessing you want the fixed ifindex for snmp polling purposes.
If that is the case try the aal5 cisco mib where you can poll based on vc data. 
Note that it seems to not work well if you have persistent indexes in use , at least on 12.2SB. 

Brian



-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Jay Hennigan
Sent: marted? 10 marzo 2009 0.15
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] snmp-server ifindex persist - store data on flash/disk?

We have a number of 7206VXR boxes terminating ATM ADSL aggregation 
circuits.  With a large number of interfaces, the persistent index table 
is too large for NVRAM and the interface IDs change on reboot just as if 
the command weren't specified.

Is there a workaround or command to store the persistent data on the 
flash disk which has plenty of room?

--
Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net
Impulse Internet Service  -  http://www.impulse.net/
Your local telephone and internet company - 805 884-6323 - WB6RDV
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From oboehmer at cisco.com  Tue Mar 10 05:40:42 2009
From: oboehmer at cisco.com (Oliver Boehmer (oboehmer))
Date: Tue, 10 Mar 2009 10:40:42 +0100
Subject: [c-nsp] OSPF Default Route
In-Reply-To: <BLU130-DS74B6D429DD464F8402CA0C5A10@phx.gbl>
References: <BLU130-DS74B6D429DD464F8402CA0C5A10@phx.gbl>
Message-ID: <70B7A1CCBFA5C649BD562B6D9F7ED7840704CFBA@xmb-ams-333.emea.cisco.com>

Manaf Al Oqlah <> wrote on Tuesday, March 10, 2009 08:42:

> Hi,
> 
> Is there any way to advertise default route in OSPF with a specific
> metric to an interface and another metric to another interface. For
> example, I want to advertise default route (default-information
> originate) for neighbor connected to gigabit 1/0 with metric 10 and
> for neighbor connected to gigabit 1/1 with metric 20.    

generally no, OSPF is a link-state protocol, so all routers in the area
have the same visibility..  
I guess you need to play with interface costs on the neighbors to
achieve what you want..

	oli

From manafo at hotmail.com  Tue Mar 10 03:41:59 2009
From: manafo at hotmail.com (Manaf Al Oqlah)
Date: Tue, 10 Mar 2009 09:41:59 +0200
Subject: [c-nsp] OSPF Default Route
Message-ID: <BLU130-DS28A0F2E8449BA242F9176C5A10@phx.gbl>

Hi,

Is there any way to advertise default route in OSPF with a specific metric to an interface and another metric to another interface. For example, I want to advertise default route (default-information originate) for neighbor connected to gigabit 1/0 with metric 10 and for neighbor connected to gigabit 1/1 with metric 20.

Thank you

From howie at thingy.com  Tue Mar 10 06:00:53 2009
From: howie at thingy.com (Howard Jones)
Date: Tue, 10 Mar 2009 10:00:53 +0000
Subject: [c-nsp] L2TPv3 sizing?
Message-ID: <49B63A55.4020401@thingy.com>

Can anyone point me to any documentation/whitepaper regarding router
sizing for L2TPv3 throughput? We're trying to understand what the
startup cost would be for a couple of ~100Mbit/sec L2TPv3
ethernet-to-ethernet tunnels as an alternative to a full MPLS solution.

Is there any Cisco (or 3rd party) information on what size routers would
be needed for given link sizes? My google-fu is weak on this.

Thanks in advance for any pointers,

Howie

From sam_mailinglists at spacething.org  Tue Mar 10 06:23:10 2009
From: sam_mailinglists at spacething.org (Sam Stickland)
Date: Tue, 10 Mar 2009 10:23:10 +0000
Subject: [c-nsp] Buggy interface counters in12.2(33)SB2 ?
Message-ID: <49B63F8E.8070008@spacething.org>

Hey guys,

It looks like we are seeing bogus interface counters (SNMP and CLI) in 
12.2(33)SB2 on a 7304 NSE150.

I'm just trying good ol' bog standard MRTG to rule out our monitoring 
systems, but I'm curious if anyone else has seen this?

Sam

From A.L.M.Buxey at lboro.ac.uk  Tue Mar 10 07:23:06 2009
From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk)
Date: Tue, 10 Mar 2009 11:23:06 +0000
Subject: [c-nsp] OSPF Default Route
In-Reply-To: <BLU130-DS74B6D429DD464F8402CA0C5A10@phx.gbl>
References: <BLU130-DS74B6D429DD464F8402CA0C5A10@phx.gbl>
Message-ID: <20090310112306.GF18951@lboro.ac.uk>

Hi,
> Hi,
> 
> Is there any way to advertise default route in OSPF with a specific metric to an interface and another metric to another interface. For example, I want to advertise default route (default-information originate) for neighbor connected to gigabit 1/0 with metric 10 and for neighbor connected to gigabit 1/1 with metric 20.

yes. 

I'll dig through my bookmarks to see if i can.....ah yes, here:

http://www.nil.si/ipcorner/OSPFDefaultMysteries/

(PS thanks Ivan!)

alan

From hiromasa.sekiguchi at ctc-g.co.jp  Tue Mar 10 07:25:31 2009
From: hiromasa.sekiguchi at ctc-g.co.jp (Hiromasa Sekiguchi)
Date: Tue, 10 Mar 2009 20:25:31 +0900
Subject: [c-nsp] 802.3z document
Message-ID: <49B64E2B.7090004@ctc-g.co.jp>

Hi all,

I would like to know signaling procedure on gigamit ethernet(802.3z).

Does anyonw have 802.3z standard document?

Regards,
Hiromasa

From hiromasa.sekiguchi at ctc-g.co.jp  Tue Mar 10 07:34:00 2009
From: hiromasa.sekiguchi at ctc-g.co.jp (Hiromasa Sekiguchi)
Date: Tue, 10 Mar 2009 20:34:00 +0900
Subject: [c-nsp] 802.3z document
In-Reply-To: <49B64E2B.7090004@ctc-g.co.jp>
References: <49B64E2B.7090004@ctc-g.co.jp>
Message-ID: <49B65028.3040407@ctc-g.co.jp>

Hi all,

I have an additional questions.

We have two line cards.
- WS-X4506-GB-T
- WS-X4448-GB-SFP

Do they work fine 802.3z?

We have some interoperability issue...

So, we would like to know two line cards support 802.3z or not.
Is there any document?

Regards,
Hiromasa


On 2009/03/10 20:25, Hiromasa Sekiguchi wrote:
> Hi all,
> 
> I would like to know signaling procedure on gigamit ethernet(802.3z).
> 
> Does anyonw have 802.3z standard document?
> 
> Regards,
> Hiromasa

From sam_mailinglists at spacething.org  Tue Mar 10 07:35:37 2009
From: sam_mailinglists at spacething.org (Sam Stickland)
Date: Tue, 10 Mar 2009 11:35:37 +0000
Subject: [c-nsp] Buggy interface counters in12.2(33)SB2 ?
In-Reply-To: <49B63F8E.8070008@spacething.org>
References: <49B63F8E.8070008@spacething.org>
Message-ID: <49B65089.1010602@spacething.org>

Sam Stickland wrote:
> Hey guys,
>
> It looks like we are seeing bogus interface counters (SNMP and CLI) in 
> 12.2(33)SB2 on a 7304 NSE150.
>
> I'm just trying good ol' bog standard MRTG to rule out our monitoring 
> systems, but I'm curious if anyone else has seen this?
MRTG just started graphing the same nonsense values (and yes I am using 
SNMP v2c ;) ), so it definately looks like a bug. Time for a TAC case.

Sam

From topperm9 at gmail.com  Tue Mar 10 07:41:59 2009
From: topperm9 at gmail.com (Matthew Topper)
Date: Tue, 10 Mar 2009 07:41:59 -0400
Subject: [c-nsp] Buggy interface counters in12.2(33)SB2 ?
In-Reply-To: <49B63F8E.8070008@spacething.org>
References: <49B63F8E.8070008@spacething.org>
Message-ID: <20090310074159.595d21bd@gmail.com>

We had the exact same problem here.  Specifically, while we were
polling ifInBroadcastPkts, the value appeared to be going down!

After some investigation, it turned out that the 32 bit counter was
wrapping so we tried the ifHCInBroadcastPkts counter.  Well, it wasn't
wrapping but it was going up by almost exactly 2^32 whenever it
went up at all.

Upgrading to SB3 fixed the issue for us.

-Matt

On Tue, 10 Mar 2009 10:23:10 +0000
Sam Stickland <sam_mailinglists at spacething.org> wrote:

> Hey guys,
> 
> It looks like we are seeing bogus interface counters (SNMP and CLI)
> in 12.2(33)SB2 on a 7304 NSE150.
> 
> I'm just trying good ol' bog standard MRTG to rule out our monitoring 
> systems, but I'm curious if anyone else has seen this?
> 
> Sam
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

From alexmoya at bellsouth.net  Tue Mar 10 07:45:53 2009
From: alexmoya at bellsouth.net (Alex Moya)
Date: Tue, 10 Mar 2009 07:45:53 -0400
Subject: [c-nsp] Egress shaping/policing for bandwidth control on a
	3750-ME
In-Reply-To: <8B25B862BC09784B9B74FB950D4F64D40F81CF@qcnapp01.corp.qcn>
References: <8B25B862BC09784B9B74FB950D4F64D40F81CF@qcnapp01.corp.qcn>
Message-ID: <8110A8DE-9DDE-4463-ADBE-39A00541603D@bellsouth.net>

Try policing the port

Sent from my iPhone

On Mar 9, 2009, at 7:59 PM, "Brad Henshaw" <brad.henshaw at qcn.com.au>  
wrote:

> Frank Bulk - iName.com wrote:
>
>> I have two Cisco 3750-ME (Metro) where we are trying to apply
>> an 8 Mbps bandwidth limit to it.
>> We tried HQM shaping but got a lovely message that "Hierarchical
>> service-policies are only supported on ES interfaces".
>
> Frank,
>
> The 3750ME can only do per-VLAN shaping on the ES ports.
>
> You can shape standard ports (but not per-VLAN) in increments of 10%  
> of
> the port speed using the 'srr-queue bandwidth limit' command. To  
> achieve
> 8Mbps with this you'd need to lock the [FastEthernet] port to 10Mbps  
> and
> set the limit to 80%. Buffering of packets is less than ideal.
>
> The 3750ME supports hierarchical dual-level *ingress* policies on  
> SVIs.
> To use these you need to set 'mls qos vlan-based' on the port and may
> or may not need to use a 'match input-interface' statement in the  
> class
> of a subpolicy. (I've never used these so can't comment with  
> authority)
>
> I'd provide an example but I'd just be ripping it from page 35-71 of
> the 3750 Metro 12.2(46)SE Software Configuration Guide ;-)
>
> I'm pretty sure neither SVIs nor standard ports support output  
> policies
> so you'd best do as much as you can on the ES ports on ingress from  
> your
> core.
>
> Note that ingress service policies on 12.2(44)SE1 seem to be broken -
> This may also affect other versions. We never logged a bug because  
> it's
> fixed in 12.2(46)SE.
>
> Overall I think the quality control on IOS releases for the 3750ME
> leaves a BLOODY LOT to be desired.
>
> Regards,
> Brad
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

From howie at thingy.com  Tue Mar 10 08:23:27 2009
From: howie at thingy.com (Howard Jones)
Date: Tue, 10 Mar 2009 12:23:27 +0000
Subject: [c-nsp] Open Source solution to deploy a radius server against
 Cisco devices?
In-Reply-To: <Pine.LNX.4.61.0903091911190.6312@soloth.lewis.org>
References: <1236449092.8327.12.camel@dsba-ipso>
	<49B336CE.3090608@umn.edu>	<60C56285-9584-478B-A7CD-C402CBF2ED82@Hughes.com.au>	<20090309090932.GB14149@lboro.ac.uk>	<1236594848.10690.1.camel@dsba-ipso>
	<Pine.LNX.4.61.0903091911190.6312@soloth.lewis.org>
Message-ID: <49B65BBF.5000204@thingy.com>

Jon Lewis wrote:
> Another option is Cistron Radius http://www.radius.cistron.nl/ which
> is probably going to be pretty similar to Freeradius, since the latter
> is apparently a fork of the former.
>
> Radiator is perl, so you get the 'source code', but it's not open
> source and you do need to buy a license to use it.
The perl aspect also makes it pretty easy to add new functionality or
backends too (assuming you have some perl experience!) - we added some
stuff to restrict what IP addresses could appear in a Framed-IP-Address
entry in about an hour or so, for example.

The Radiator guys also have excellent support, the few times we've
needed to use it. Definitely would recommend it.

Howie

From skeeve at skeeve.org  Tue Mar 10 08:26:42 2009
From: skeeve at skeeve.org (Skeeve Stevens)
Date: Tue, 10 Mar 2009 23:26:42 +1100
Subject: [c-nsp] Supress STP on a port?
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAAN5U5OuspydJheQZRk7Gfl7CgAAAEAAAAK/bl9g9cthJu/bPX/RPm1kBAAAAAA==@skeeve.org>

Is it possible to suppress STP on a specific port?

.Skeeve

--
Skeeve Stevens, RHCE
skeeve at skeeve.org / www.skeeve.org
Cell +61 (0)414 753 383 / skype://skeeve

eintellego - skeeve at eintellego.net - www.eintellego.net 
--
I'm a groove licked love child king of the verse 
Si vis pacem, para bellum



From brad.henshaw at qcn.com.au  Tue Mar 10 08:31:55 2009
From: brad.henshaw at qcn.com.au (Brad Henshaw)
Date: Tue, 10 Mar 2009 22:31:55 +1000
Subject: [c-nsp] Supress STP on a port?
References: <!&!AAAAAAAAAAAYAAAAAAAAAN5U5OuspydJheQZRk7Gfl7CgAAAEAAAAK/bl9g9cthJu/bPX/RPm1kBAAAAAA==@skeeve.org>
Message-ID: <8B25B862BC09784B9B74FB950D4F64D401F8FA@qcnapp01.corp.qcn>

Skeeve Stevens wrote:
 
> Is it possible to suppress STP on a specific port?

spanning-tree bpdufilter enable

Regards,
Brad

From csirek at cooler.hu  Tue Mar 10 08:39:45 2009
From: csirek at cooler.hu (Nemeth Laszlo)
Date: Tue, 10 Mar 2009 13:39:45 +0100
Subject: [c-nsp] Etherchannel guard vs. mstp
Message-ID: <49B65F91.8000807@cooler.hu>

Dear List,

I have 6500/SUP720-3BXL with ipservicesk9-mz.122-18.SXF13.bin (this is 
Router A) , a 7600/RSP720-3CXL with advipservicesk9-mz.122-33.SRC3.bin 
(this is Router B), and a Router C 6500/3BXL with 
ipservicesk9-mz.122-18.SXF6.bin.

The topology is:

Router A  == 4x10G (lacp) ==  Router B  == 2x10G (pagp) ==  Router C


All routers run Rapid-PVSTP.

I needed to change the STP from RSTP to MSTP on all devices.

The first router was the Router A. It changed without problem.
But when i sent the "spanning-tree mode mstp" to Router B it put down 
the 4x10G Etherchannel link with Router A and logged it:

Mar  9 16:04:57.669 MET: %PM-SP-STDBY-4-ERR_DISABLE: channel-misconfig 
error detected on Te1/3, putting Te1/3 in err-disable state
Mar  9 16:04:57.677 MET: %PM-SP-STDBY-4-ERR_DISABLE: channel-misconfig 
error detected on Te1/4, putting Te1/4 in err-disable state
Mar  9 16:04:57.685 MET: %PM-SP-STDBY-4-ERR_DISABLE: channel-misconfig 
error detected on Te2/3, putting Te2/3 in err-disable state
Mar  9 16:04:57.701 MET: %PM-SP-STDBY-4-ERR_DISABLE: channel-misconfig 
error detected on Te2/4, putting Te2/4 in err-disable state

Mar  9 16:04:57.641 MET: %PM-SP-4-ERR_DISABLE: channel-misconfig error 
detected on Po3, putting Te1/3 in err-disable state
Mar  9 16:04:57.653 MET: %PM-SP-4-ERR_DISABLE: channel-misconfig error 
detected on Po3, putting Te1/4 in err-disable state
Mar  9 16:04:57.665 MET: %PM-SP-4-ERR_DISABLE: channel-misconfig error 
detected on Po3, putting Te2/3 in err-disable state
Mar  9 16:04:57.673 MET: %PM-SP-4-ERR_DISABLE: channel-misconfig error 
detected on Po3, putting Te2/4 in err-disable state
Mar  9 16:04:57.685 MET: %PM-SP-4-ERR_DISABLE: channel-misconfig error 
detected on Po3, putting Po3 in err-disable state


The Etherchannel with Router C stilled UP only the Router A went down.

If i deleted and recreated the port channel with LACP or PAGP or other 
etherchannel number, the result always it: put down the links.

If i changed back to RSTP on the Router B, all links went UP with router 
A and it's working without problem.

So the topology now is: Router A runs MSTP, router B runs RSTP and 
router C runs  RSTP too.

I think the STP's etherchannel guard put down the link, but i don't 
found any bug that made this problem in the BugTool at Cisco.com.

Any idea?

Thanks

Laszlo


From ibrahim.abozaid at gmail.com  Tue Mar 10 08:45:37 2009
From: ibrahim.abozaid at gmail.com (Ibrahim Abo Zaid)
Date: Tue, 10 Mar 2009 14:45:37 +0200
Subject: [c-nsp] default route and PBR set ip next-hop
Message-ID: <a48927f70903100545q1e97dc31w1546be3f96e3d63a@mail.gmail.com>

Hi All


I was checking when routers PBR traffic to certain NH , it checks if NH
route exit in routing table or not , if exist , traffic is PBR and if not
traffic is normally routed


so my question is , if there is a default route , will it considered a valid
route to reach the specified NH or this check depends on specific routes ?



best regards
--Ibrahim

From csirek at cooler.hu  Tue Mar 10 08:51:26 2009
From: csirek at cooler.hu (Nemeth Laszlo)
Date: Tue, 10 Mar 2009 13:51:26 +0100
Subject: [c-nsp] Etherchannel guard vs. mstp]
Message-ID: <49B6624E.90108@cooler.hu>

Hi

I make a mistake in the Routers name.

This is the good version:

I have a 7600/RSP720-3CXL with advipservicesk9-mz.122-33.SRC3.bin
(this is Router A), 6500/SUP720-3BXL with 
ipservicesk9-mz.122-18.SXF13.bin (this is Router B) and a C 6500/3BXL 
with ipservicesk9-mz.122-18.SXF6.bin (Router C)

The topology is:

Router A  == 4x10G (lacp) ==  Router B  == 2x10G (pagp) ==  Router C


All routers run Rapid-PVSTP.

I needed to change the STP from RSTP to MSTP on all devices.

The first router was the Router A. It changed without problem.
But when i sent the "spanning-tree mode mstp" to Router B it put down
the 4x10G Etherchannel link with Router A and logged it:

Mar  9 16:04:57.669 MET: %PM-SP-STDBY-4-ERR_DISABLE: channel-misconfig
error detected on Te1/3, putting Te1/3 in err-disable state
Mar  9 16:04:57.677 MET: %PM-SP-STDBY-4-ERR_DISABLE: channel-misconfig
error detected on Te1/4, putting Te1/4 in err-disable state
Mar  9 16:04:57.685 MET: %PM-SP-STDBY-4-ERR_DISABLE: channel-misconfig
error detected on Te2/3, putting Te2/3 in err-disable state
Mar  9 16:04:57.701 MET: %PM-SP-STDBY-4-ERR_DISABLE: channel-misconfig
error detected on Te2/4, putting Te2/4 in err-disable state

Mar  9 16:04:57.641 MET: %PM-SP-4-ERR_DISABLE: channel-misconfig error
detected on Po3, putting Te1/3 in err-disable state
Mar  9 16:04:57.653 MET: %PM-SP-4-ERR_DISABLE: channel-misconfig error
detected on Po3, putting Te1/4 in err-disable state
Mar  9 16:04:57.665 MET: %PM-SP-4-ERR_DISABLE: channel-misconfig error
detected on Po3, putting Te2/3 in err-disable state
Mar  9 16:04:57.673 MET: %PM-SP-4-ERR_DISABLE: channel-misconfig error
detected on Po3, putting Te2/4 in err-disable state
Mar  9 16:04:57.685 MET: %PM-SP-4-ERR_DISABLE: channel-misconfig error
detected on Po3, putting Po3 in err-disable state


The Etherchannel with Router C stilled UP only the Router A went down.

If i deleted and recreated the port channel with LACP or PAGP or other
etherchannel number, the result always it: put down the links.

If i changed back to RSTP on the Router B, all links went UP with router
A and it's working without problem.

So the topology now is: Router A runs MSTP, router B runs RSTP and
router C runs  RSTP too.

I think the STP's etherchannel guard put down the link, but i don't
found any bug that made this problem in the BugTool at Cisco.com.

Any idea?

Thanks

Laszlo

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

From skeeve at skeeve.org  Tue Mar 10 08:53:57 2009
From: skeeve at skeeve.org (Skeeve Stevens)
Date: Tue, 10 Mar 2009 23:53:57 +1100
Subject: [c-nsp] Supress STP on a port?
In-Reply-To: <8B25B862BC09784B9B74FB950D4F64D401F8FA@qcnapp01.corp.qcn>
References: <!&!AAAAAAAAAAAYAAAAAAAAAN5U5OuspydJheQZRk7Gfl7CgAAAEAAAAK/bl9g9cthJu/bPX/RPm1kBAAAAAA==@skeeve.org>
	<8B25B862BC09784B9B74FB950D4F64D401F8FA@qcnapp01.corp.qcn>
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAAN5U5OuspydJheQZRk7Gfl7CgAAAEAAAABOYIHS9foVLsdEeXv5qzZgBAAAAAA==@skeeve.org>

Thanks Brad and Glovanni

-----Original Message-----
From: Brad Henshaw [mailto:brad.henshaw at qcn.com.au] 
Sent: Tuesday, 10 March 2009 11:32 PM
To: skeeve at skeeve.org; cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] Supress STP on a port?

Skeeve Stevens wrote:
 
> Is it possible to suppress STP on a specific port?

spanning-tree bpdufilter enable

Regards,
Brad


From blahu77 at gmail.com  Tue Mar 10 09:07:27 2009
From: blahu77 at gmail.com (Mateusz Blaszczyk)
Date: Tue, 10 Mar 2009 13:07:27 +0000
Subject: [c-nsp] Etherchannel guard vs. mstp]
In-Reply-To: <49B6624E.90108@cooler.hu>
References: <49B6624E.90108@cooler.hu>
Message-ID: <383357750903100607n255c4dadw8b7a8549977175d1@mail.gmail.com>

I would suggest a reload after changing the spanning tree mode

2009/3/10 Nemeth Laszlo <csirek at cooler.hu>:
> Hi
>
> I make a mistake in the Routers name.
>
> This is the good version:
>
> I have a 7600/RSP720-3CXL with advipservicesk9-mz.122-33.SRC3.bin
> (this is Router A), 6500/SUP720-3BXL with ipservicesk9-mz.122-18.SXF13.bin
> (this is Router B) and a C 6500/3BXL with ipservicesk9-mz.122-18.SXF6.bin
> (Router C)
>
> The topology is:
>
> Router A ?== 4x10G (lacp) == ?Router B ?== 2x10G (pagp) == ?Router C
>
>
> All routers run Rapid-PVSTP.
>
> I needed to change the STP from RSTP to MSTP on all devices.
>
> The first router was the Router A. It changed without problem.
> But when i sent the "spanning-tree mode mstp" to Router B it put down
> the 4x10G Etherchannel link with Router A and logged it:
>
> Mar ?9 16:04:57.669 MET: %PM-SP-STDBY-4-ERR_DISABLE: channel-misconfig
> error detected on Te1/3, putting Te1/3 in err-disable state
> Mar ?9 16:04:57.677 MET: %PM-SP-STDBY-4-ERR_DISABLE: channel-misconfig
> error detected on Te1/4, putting Te1/4 in err-disable state
> Mar ?9 16:04:57.685 MET: %PM-SP-STDBY-4-ERR_DISABLE: channel-misconfig
> error detected on Te2/3, putting Te2/3 in err-disable state
> Mar ?9 16:04:57.701 MET: %PM-SP-STDBY-4-ERR_DISABLE: channel-misconfig
> error detected on Te2/4, putting Te2/4 in err-disable state
>
> Mar ?9 16:04:57.641 MET: %PM-SP-4-ERR_DISABLE: channel-misconfig error
> detected on Po3, putting Te1/3 in err-disable state
> Mar ?9 16:04:57.653 MET: %PM-SP-4-ERR_DISABLE: channel-misconfig error
> detected on Po3, putting Te1/4 in err-disable state
> Mar ?9 16:04:57.665 MET: %PM-SP-4-ERR_DISABLE: channel-misconfig error
> detected on Po3, putting Te2/3 in err-disable state
> Mar ?9 16:04:57.673 MET: %PM-SP-4-ERR_DISABLE: channel-misconfig error
> detected on Po3, putting Te2/4 in err-disable state
> Mar ?9 16:04:57.685 MET: %PM-SP-4-ERR_DISABLE: channel-misconfig error
> detected on Po3, putting Po3 in err-disable state
>
>
> The Etherchannel with Router C stilled UP only the Router A went down.
>
> If i deleted and recreated the port channel with LACP or PAGP or other
> etherchannel number, the result always it: put down the links.
>
> If i changed back to RSTP on the Router B, all links went UP with router
> A and it's working without problem.
>
> So the topology now is: Router A runs MSTP, router B runs RSTP and
> router C runs ?RSTP too.
>
> I think the STP's etherchannel guard put down the link, but i don't
> found any bug that made this problem in the BugTool at Cisco.com.
>
> Any idea?
>
> Thanks
>
> Laszlo
>
> _______________________________________________
> cisco-nsp mailing 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/
>



-- 
pgp-key 0x1C655CAB

From rens at autempspourmoi.be  Tue Mar 10 09:11:56 2009
From: rens at autempspourmoi.be (Rens)
Date: Tue, 10 Mar 2009 14:11:56 +0100
Subject: [c-nsp] L2TPv3 sizing?
In-Reply-To: <49B63A55.4020401@thingy.com>
References: <49B63A55.4020401@thingy.com>
Message-ID: <AF7B568F82704022A5A215234CA9CD70@EU.corp.clearwire.com>

Have a look at Cisco Routing Performance sheet.

This already gives you an indication of the speed with 64 byte packet sizes
without L2TPv3.

The second think you need to make sure is that the router does not fragment
any of the big packets. I have only been able to test this with 7206VXR
platform, not sure how well other routers handle fragmentation.

I have already seen speeds of 300Mbps+ with L2TPv3 tunnel with 2x 7206VXR
NPE-400 (with 1024-1522 frame sizes)

I guess if you want also that speed with 64 byte you will have to need
NPE-G1.


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Howard Jones
Sent: mardi 10 mars 2009 11:01
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] L2TPv3 sizing?

Can anyone point me to any documentation/whitepaper regarding router
sizing for L2TPv3 throughput? We're trying to understand what the
startup cost would be for a couple of ~100Mbit/sec L2TPv3
ethernet-to-ethernet tunnels as an alternative to a full MPLS solution.

Is there any Cisco (or 3rd party) information on what size routers would
be needed for given link sizes? My google-fu is weak on this.

Thanks in advance for any pointers,

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


From cchurc05 at harris.com  Tue Mar 10 09:44:51 2009
From: cchurc05 at harris.com (Church, Charles)
Date: Tue, 10 Mar 2009 08:44:51 -0500
Subject: [c-nsp] 100FX duplex
Message-ID: <FA1BA229357DB640B944218F3585FECA0200E16B@mspe2k1.cs.myharris.net>

Hey all,

 

                Sorry about the really basic question.  Can't find a
definitive answer anywhere else.  Does 100FX do auto-negotiation of
duplex?  If not, do they default to half or full?  We're seeing odd
things on our stuff, some are Cisco to Cisco links, some are Cisco to
various brands of media converters on into a 10/100 port.  Odd things
such as collisions on ports set to full, huge amounts of FCS errors at
places, etc.  The semi-dumb media converters have dip switches that
mention duplex, but the directions seem to indication that it affects
the copper side of it only.  Any good advice?

 

Thanks,

 

Chuck


From ross at kallisti.us  Tue Mar 10 10:07:56 2009
From: ross at kallisti.us (Ross Vandegrift)
Date: Tue, 10 Mar 2009 10:07:56 -0400
Subject: [c-nsp] 802.3z document
In-Reply-To: <49B64E2B.7090004@ctc-g.co.jp>
References: <49B64E2B.7090004@ctc-g.co.jp>
Message-ID: <20090310140756.GA22881@kallisti.us>

On Tue, Mar 10, 2009 at 08:25:31PM +0900, Hiromasa Sekiguchi wrote:
> Hi all,
> 
> I would like to know signaling procedure on gigamit ethernet(802.3z).
> 
> Does anyonw have 802.3z standard document?

You can get all of IEEE 802 for free directly from IEEE.  Check out:

http://standards.ieee.org/getieee802/

for PDF downlods.

-- 
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 ross at kallisti.us  Tue Mar 10 10:16:55 2009
From: ross at kallisti.us (Ross Vandegrift)
Date: Tue, 10 Mar 2009 10:16:55 -0400
Subject: [c-nsp] Etherchannel guard vs. mstp
In-Reply-To: <49B65F91.8000807@cooler.hu>
References: <49B65F91.8000807@cooler.hu>
Message-ID: <20090310141655.GB22881@kallisti.us>

On Tue, Mar 10, 2009 at 01:39:45PM +0100, Nemeth Laszlo wrote:
> The first router was the Router A. It changed without problem.
> But when i sent the "spanning-tree mode mstp" to Router B it put down 
> the 4x10G Etherchannel link with Router A and logged it:
> 
> Mar  9 16:04:57.669 MET: %PM-SP-STDBY-4-ERR_DISABLE: channel-misconfig 
> error detected on Te1/3, putting Te1/3 in err-disable state
> Mar  9 16:04:57.677 MET: %PM-SP-STDBY-4-ERR_DISABLE: channel-misconfig 
> error detected on Te1/4, putting Te1/4 in err-disable state
> Mar  9 16:04:57.685 MET: %PM-SP-STDBY-4-ERR_DISABLE: channel-misconfig 
> error detected on Te2/3, putting Te2/3 in err-disable state
> Mar  9 16:04:57.701 MET: %PM-SP-STDBY-4-ERR_DISABLE: channel-misconfig 
> error detected on Te2/4, putting Te2/4 in err-disable state

I'm running ethernetchannel with MSTP and don't have any problems.  Do
you have STP config on the associated member interfaces?  If changing
the STP mode causes problems, I'm guessing you have config left on the
individual interfaces and this causes the STP state machine to change
the state of the member interfaces.

On some platforms (6500, for example), the port bundler freaks out if
you change anything on the member interfaces.  On other platforms
(2960, for example), IOS will simply refuse to apply any changes.

Ross

-- 
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 hiromasa.sekiguchi at ctc-g.co.jp  Tue Mar 10 10:26:01 2009
From: hiromasa.sekiguchi at ctc-g.co.jp (Hiromasa Sekiguchi)
Date: Tue, 10 Mar 2009 23:26:01 +0900
Subject: [c-nsp] 802.3z document
In-Reply-To: <49B65028.3040407@ctc-g.co.jp>
References: <49B64E2B.7090004@ctc-g.co.jp> <49B65028.3040407@ctc-g.co.jp>
Message-ID: <49B67879.90003@ctc-g.co.jp>

Hi all,

Do they support clause 36, 37 on 802.3z?

Regards,
Hiromasa

On 2009/03/10 20:34, Hiromasa Sekiguchi wrote:
> Hi all,
> 
> I have an additional questions.
> 
> We have two line cards.
> - WS-X4506-GB-T
> - WS-X4448-GB-SFP
> 
> Do they work fine 802.3z?
> 
> We have some interoperability issue...
> 
> So, we would like to know two line cards support 802.3z or not.
> Is there any document?
> 
> Regards,
> Hiromasa
> 
> 
> On 2009/03/10 20:25, Hiromasa Sekiguchi wrote:
>> Hi all,
>>
>> I would like to know signaling procedure on gigamit ethernet(802.3z).
>>
>> Does anyonw have 802.3z standard document?
>>
>> Regards,
>> Hiromasa
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/

From will at harg.net  Tue Mar 10 13:39:38 2009
From: will at harg.net (Will Hargrave)
Date: Tue, 10 Mar 2009 17:39:38 +0000
Subject: [c-nsp] 100FX duplex
In-Reply-To: <FA1BA229357DB640B944218F3585FECA0200E16B@mspe2k1.cs.myharris.net>
References: <FA1BA229357DB640B944218F3585FECA0200E16B@mspe2k1.cs.myharris.net>
Message-ID: <49B6A5DA.2070607@harg.net>

Church, Charles wrote:

>                 Sorry about the really basic question.  Can't find a
> definitive answer anywhere else.  Does 100FX do auto-negotiation of
> duplex?  If not, do they default to half or full?  We're seeing odd
> things on our stuff, some are Cisco to Cisco links, some are Cisco to
> various brands of media converters on into a 10/100 port.  Odd things
> such as collisions on ports set to full, huge amounts of FCS errors at
> places, etc.  The semi-dumb media converters have dip switches that
> mention duplex, but the directions seem to indication that it affects
> the copper side of it only.  Any good advice?

100FX doesn't support any form of autoneg so you need to configure all of the
devices involved. I imagine the media converters (if they are just media
converters rather than bridges) will have DIP switches which set duplex on both
sides.


Will


From achatz at forthnet.gr  Tue Mar 10 14:52:02 2009
From: achatz at forthnet.gr (Tassos Chatzithomaoglou)
Date: Tue, 10 Mar 2009 20:52:02 +0200
Subject: [c-nsp] power down of standby sup is not possible
Message-ID: <49B6B6D2.4000308@forthnet.gr>

Anyone care to explain why such a limitation?

7609(config)#no power enable module 5
%Error: no power control on supervisor cards

7609#sh mod
Mod Ports Card Type                              Model              Serial No.
--- ----- -------------------------------------- ------------------ -----------
   5    2  Supervisor Engine 720 (Hot)            WS-SUP720-3BXL
   6    2  Supervisor Engine 720 (Active)         WS-SUP720-3BXL


I'm trying to power down the standby sup and i though cisco's green agenda would have though of that.


-- 
Tassos

From frnkblk at iname.com  Tue Mar 10 14:52:08 2009
From: frnkblk at iname.com (Frank Bulk - iName.com)
Date: Tue, 10 Mar 2009 13:52:08 -0500
Subject: [c-nsp] Egress shaping/policing for bandwidth control on a
	3750-ME
In-Reply-To: <8110A8DE-9DDE-4463-ADBE-39A00541603D@bellsouth.net>
References: <8B25B862BC09784B9B74FB950D4F64D40F81CF@qcnapp01.corp.qcn>
	<8110A8DE-9DDE-4463-ADBE-39A00541603D@bellsouth.net>
Message-ID: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAABLNQUnH7aoQ7z2j8cfqhkwAQAAAAA=@iname.com>

Thanks for the idea, but the port carries multiple VLANs.  Only one of them
needs to be rate-limited.

Frank

-----Original Message-----
From: Alex Moya [mailto:alexmoya at bellsouth.net] 
Sent: Tuesday, March 10, 2009 6:46 AM
To: Brad Henshaw
Cc: <frnkblk at iname.com>; <cisco-nsp at puck.nether.net>
Subject: Re: [c-nsp] Egress shaping/policing for bandwidth control on a
3750-ME

Try policing the port

Sent from my iPhone

On Mar 9, 2009, at 7:59 PM, "Brad Henshaw" <brad.henshaw at qcn.com.au>
wrote:

> Frank Bulk - iName.com wrote:
>
>> I have two Cisco 3750-ME (Metro) where we are trying to apply
>> an 8 Mbps bandwidth limit to it.
>> We tried HQM shaping but got a lovely message that "Hierarchical
>> service-policies are only supported on ES interfaces".
>
> Frank,
>
> The 3750ME can only do per-VLAN shaping on the ES ports.
>
> You can shape standard ports (but not per-VLAN) in increments of 10%
> of
> the port speed using the 'srr-queue bandwidth limit' command. To
> achieve
> 8Mbps with this you'd need to lock the [FastEthernet] port to 10Mbps
> and
> set the limit to 80%. Buffering of packets is less than ideal.
>
> The 3750ME supports hierarchical dual-level *ingress* policies on
> SVIs.
> To use these you need to set 'mls qos vlan-based' on the port and may
> or may not need to use a 'match input-interface' statement in the
> class
> of a subpolicy. (I've never used these so can't comment with
> authority)
>
> I'd provide an example but I'd just be ripping it from page 35-71 of
> the 3750 Metro 12.2(46)SE Software Configuration Guide ;-)
>
> I'm pretty sure neither SVIs nor standard ports support output
> policies
> so you'd best do as much as you can on the ES ports on ingress from
> your
> core.
>
> Note that ingress service policies on 12.2(44)SE1 seem to be broken -
> This may also affect other versions. We never logged a bug because
> it's
> fixed in 12.2(46)SE.
>
> Overall I think the quality control on IOS releases for the 3750ME
> leaves a BLOODY LOT to be desired.
>
> Regards,
> Brad
> _______________________________________________
> cisco-nsp mailing list  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  Tue Mar 10 15:53:16 2009
From: justin at justinshore.com (Justin Shore)
Date: Tue, 10 Mar 2009 14:53:16 -0500
Subject: [c-nsp] L3VPN Voice VRF
Message-ID: <49B6C52C.10305@justinshore.com>

I'm trying to figure out the best, safest, most secure and of course 
least expensive (in my time, hair, sleep at night, etc) way to implement 
a voice MPLS/VPN across our network.  I'm sure people on c-nsp have done 
it before so I'm hoping for a few pointers.

What we have today are a pair of MetaSwitches, one in each main POP.  In 
front of them at each POP are a pair of HA PIXs.  Customer RTP and 
signaling from our CATV MTAs, IP DSLAMs, FTTH, etc enter through the 
PIXs.  Communication between the 2 MetaSwitches and MS management 
servers is across an IPSec tunnel on the PIXs.

That works well enough but I need to do a few things to make it better. 
  First off the IPSec tunnel needs to go.  It's a real PITA because it 
randomly fails, forcing me to literally power cycle one of the sets of 
PIXs (taking down the remote POP's voice service entirely).  I can't 
clear anything crypto on these PIXs so I can't bring up the tunnel 
remotely.  I also can't see into the IPSec tunnel to identify traffic 
needing QoS preference or not.  My plan was to put the protected MS 
equipment along with the backside of the PIXs in a VRF which can span 
both POPs.  Traffic from the unprotected side to the protected side 
would hair-pin from the core routers through the PIXs back into the core 
router(s) at that site and into the VRF.  That's not too hard to do, 
it's just getting the time to plan and do it.

The second problem is that this does not allow for roving remote users 
with IP phones.  My ACLs on the MS PIXs are tight and I want to keep it 
that way.  We bought a pair of Ditech SBCs to address the roving user 
problem (horrible pieces of junk; I only recommend them to competitors). 
  They will straddle the unprotected and protected network boundary, 
just like the PIXs more or less.  That's not too hard either.  I only 
plan on pointing remote roving users at the SBCs; not VoIP users that 
are using fixed phones on our own SP network.

My current problem is that we're entering into the realm of managed 
voice service.  We're CLECing a remote city and offering managed VoIP 
with SIP for businesses over DS1s and LRE (G.SHDSL).  The CE for voice 
customers is managed by us to ensure QoS is properly configured.  The 
VoIP phones are Linksys currently and will be connected either directly 
to the router (ISR) or a managed PoE switch (Cisco again).  Voice will 
be on a voice VLAN configured as such on the switchports (so it's only 
reachable by devices that speak CDP and look like a phone).  One problem 
with this offering is with remote access to the phones in the voice VLAN 
on the managed-CE.  We could configure IPSec client VPNs on each of the 
managed CEs but that gets exponentially ugly as the number of users 
grows.  My favorite thought is to extend MPLS all the way down to the 
managed-CE (which dictates a minimum of a 2800 ISR, 2811 or bigger for 
our needs, running Adv IP).  Then we could extend a common voice VRF to 
that managed-CE.  The voice VLAN would be put into that voice VRF.  This 
would give us the ability to access the GUI config of the customer's 
phone to configure it, command it to resync, reboot it, etc.  Otherwise 
we're forced to either have the user power cycle the phone by unplugging 
it from the network or figure out which switchport it is and cut the 
power to it.  We could also generate a truck roll to do something as 
trivial as adding a speed dial; not a cost-effective idea.

I favor the voice VRF idea but I struggle to figure out how to fully 
implement it.  On the managed-CE side it's not very hard.  MPLS, LDP, 
mBGP, IGP (IS-IS), address the phones uniquely for each site in the 
common VRF, etc.  Back in the main POPs is where I'm having the most 
difficulties with this concept.  Do I consider a phone hung off of a 
managed switchport trustworthy enough to bring it in BEHIND my firewalls 
and SBCs and allow it direct access to the secured MetaSwitch network? 
If so then this really isn't that hard.  I'll use the same VRF at all 
VoIP sites that I'm going to use behind the MS PIXs.  If I don't 
consider it trustworthy then I have to run the voice traffic through the 
PIXs or SBCs to get the filtered traffic to the MSs, either through the 
outside int of the PIXs or through a DMZ int.  The DMZ interface thought 
opens up some possibilities at least; I can somewhat envision that int 
being tied to a VLAN that's part of the voice customer VRF.  That gives 
me a device to bridge the gap between the a customer voice VRF and the 
MS VRF.  If I didn't use the DMZ then I wouldn't know how to pop 
customers out of the voice VRF to gain access to the public side of the 
PIXs which are in our default VRF.  BTW, all public traffic on our 
network is in the default VRF.

This is a rather complicated problem, or at least I'm mentally making it 
complicated.  I think I could continue using the PIXs and SBCs to bridge 
the gap between the protected MetaSwitch VRF and the unprotected public 
Internet.  It's what to do with the Voice VRF that perplexes me the 
most.  The Voice VRF concept is a popular example in Cisco Press books 
like the MPLS Architectures books.  Unfortunately those books don't 
really tell you how to implement it end to end which is what I need.  It 
also doesn't help you decide when the traffic is secure and when it's not.

Does anyone have any suggestions, pointers to example scenarios, guides, 
howtos, etc?  I'm sure this can be done but I'm missing some critical 
pieces at this point.

Thanks
  Justin

From rskjels at pogostick.net  Tue Mar 10 16:11:55 2009
From: rskjels at pogostick.net (Rikard Stemland Skjelsvik)
Date: Tue, 10 Mar 2009 21:11:55 +0100 (MET)
Subject: [c-nsp] Error upgrading CSS: error in script playbackA
Message-ID: <Pine.GSO.4.64.0903102110250.21168@pogostick.net>



Dear all,

We are having trouble upgrading Cisco CSS that runs sg0750004 to sg0810503
We have tried upgrading according to both the manual procedyre and the 
automatic.
Both of them fails when we try to do the "set primary boot-file sg0810503" 
command.


We also tried upgrading from sg0750004 to sg0750103 with the same error

The error we get is:

     Error in script playback line:949
     >>>             primary boot-file ${new_version}


We would be grateful if anyone could provide us with some help.

Regards,
Rikard

From A.L.M.Buxey at lboro.ac.uk  Tue Mar 10 16:48:05 2009
From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk)
Date: Tue, 10 Mar 2009 20:48:05 +0000
Subject: [c-nsp] power down of standby sup is not possible
In-Reply-To: <49B6B6D2.4000308@forthnet.gr>
References: <49B6B6D2.4000308@forthnet.gr>
Message-ID: <20090310204805.GC20682@lboro.ac.uk>

Hi,
> Anyone care to explain why such a limitation?
>
> 7609(config)#no power enable module 5
> %Error: no power control on supervisor cards
>
> 7609#sh mod
> Mod Ports Card Type                              Model              Serial No.
> --- ----- -------------------------------------- ------------------ -----------
>   5    2  Supervisor Engine 720 (Hot)            WS-SUP720-3BXL
>   6    2  Supervisor Engine 720 (Active)         WS-SUP720-3BXL
>
>
> I'm trying to power down the standby sup and i though cisco's green agenda would have though of that.

supervisors are the 'brain' of the box, as it were - and therefore
when people buy 2 of them, they'd rather have them both running..eg
in SSO mode.  i found this 'situation' out as you possibly did - 
attempting to do a remote reload by just doing a 'power enable'-cycle? :-)

alan

From achatz at forthnet.gr  Tue Mar 10 17:08:26 2009
From: achatz at forthnet.gr (Tassos Chatzithomaoglou)
Date: Tue, 10 Mar 2009 23:08:26 +0200
Subject: [c-nsp] power down of standby sup is not possible
In-Reply-To: <20090310204805.GC20682@lboro.ac.uk>
References: <49B6B6D2.4000308@forthnet.gr> <20090310204805.GC20682@lboro.ac.uk>
Message-ID: <49B6D6CA.4090100@forthnet.gr>


A.L.M.Buxey at lboro.ac.uk wrote on 10/03/2009 22:48:
> Hi,
>> Anyone care to explain why such a limitation?
>>
>> 7609(config)#no power enable module 5
>> %Error: no power control on supervisor cards
>>
>> 7609#sh mod
>> Mod Ports Card Type                              Model              Serial No.
>> --- ----- -------------------------------------- ------------------ -----------
>>   5    2  Supervisor Engine 720 (Hot)            WS-SUP720-3BXL
>>   6    2  Supervisor Engine 720 (Active)         WS-SUP720-3BXL
>>
>>
>> I'm trying to power down the standby sup and i though cisco's green agenda would have though of that.
> 
> supervisors are the 'brain' of the box, as it were - and therefore
> when people buy 2 of them, they'd rather have them both running..eg
> in SSO mode.  i found this 'situation' out as you possibly did - 
> attempting to do a remote reload by just doing a 'power enable'-cycle? :-)
> 
> alan
> 

Well, i don't like the idea of strictly following Cisco's concept of redundancy.
In my case, i don't want to enable redundancy on this box, but i want to have 2 sups 
inside (with the 2nd one being powered-off). I guess that's not possible :(

Alan, you can do "hw-module module x reset" in order to reset a module (sup included).
I was just trying to have a 2nd sup disabled. I don't need any syncing between the sups 
and power saving would be a welcome addition.

Talking about power-saving, i haven't found any way to disable power reservation of a sup 
slot, when that one is not being used. You can always put another module there, but i 
can't consider this as a solution.


-- 
Tassos

From peter at rathlev.dk  Tue Mar 10 17:10:08 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Tue, 10 Mar 2009 22:10:08 +0100
Subject: [c-nsp] FWSM HA secondary reload & long downtime
In-Reply-To: <Pine.LNX.4.64.0903101125050.6781@zippy.stdio.be>
References: <1236633344.3572.13.camel@localhost.localdomain>
	<Pine.LNX.4.64.0903101125050.6781@zippy.stdio.be>
Message-ID: <1236719408.4513.51.camel@localhost.localdomain>

On Tue, 2009-03-10 at 11:32 +0100, Andrew Yourtchenko wrote:
> if it is merely a new standby that is coming up, the active should not
> stop forwarding the traffic.

That's what I would've assumed too. :-) I do seem to remember that we've
seen this before though, when we had random reboots (CSCse15099 if I
remember correctly) of secondary units resulting in downtime.

> I'd watch out for "logging standby" - I vaguely remember there were
> some issues where the newly coming up box would try to send the
> traffic with the wrong IP/MAC and/or send the gratuitous arp with the
> wrong info in there.
> 
> Especially may be true if you are bringing up primary as standby - at
> this moment the secondary/active is forwarding the traffic using the
> primary's mac addresses.

Standby logging is disabled on all contexts, so this shouldn't be the
issue. Of course if the module coming up sends out gratuitous ARPs this
could break things with the way PIX/FWSM/ASA does HA, using the same
MAC-address.

I had thought that the unit coming up would start by looking at the
failover interface(s) to see if there is already an active unit, and
then start acting as active/standby depending of what it hears.

Otherwise a crashing/rebooting primary unit would always introduce
downtime when coming up again.

> Of course, interesting would be to check if indeed this is on all the 
> contexts or only some of them, etc.

The log buffer (logging errors) on the contexts on the standby unit
(which is the configured primary) didn't say "'

>From the sys context on the standby:

Mar 09 2009 16:41:04: %FWSM-4-411003: Interface statefullfailover, changed state to administratively up
Mar 09 2009 16:41:05: %FWSM-5-504001: Security context admin was added to the system
...
Mar 09 2009 16:41:07: %FWSM-5-504001: Security context sample was added to the system
Mar 09 2009 16:41:26: %FWSM-1-709006: (Primary) End Configuration Replication (STB)
Mar 09 2009 16:42:02: %FWSM-6-210022: LU missed 4837568 updates

>From one of the contexts, still the standby unit:

Mar 09 2009 16:41:35: %FWSM-1-105006: (Primary) Link status 'Up' on interface internet
Mar 09 2009 16:41:35: %FWSM-1-105003: (Primary) Monitoring on interface internet waiting
Mar 09 2009 16:41:35: %FWSM-1-105006: (Primary) Link status 'Up' on interface aars_pro
Mar 09 2009 16:41:35: %FWSM-1-105003: (Primary) Monitoring on interface aars_pro waiting
Mar 09 2009 16:41:35: %FWSM-1-105006: (Primary) Link status 'Up' on interface inside
Mar 09 2009 16:41:35: %FWSM-1-105003: (Primary) Monitoring on interface inside waiting
Mar 09 2009 16:41:35: %FWSM-1-105006: (Primary) Link status 'Up' on interface aars_interfw
Mar 09 2009 16:41:35: %FWSM-1-105003: (Primary) Monitoring on interface aars_interfw waiting
Mar 09 2009 16:41:44: %FWSM-1-105004: (Primary) Monitoring on interface internet normal
Mar 09 2009 16:41:44: %FWSM-1-105004: (Primary) Monitoring on interface aars_pro normal
Mar 09 2009 16:41:44: %FWSM-1-105004: (Primary) Monitoring on interface inside normal
Mar 09 2009 16:41:44: %FWSM-1-105004: (Primary) Monitoring on interface aars_interfw normal

So the contexts weren't really activated (with "Up" interfaces) during
all the downtime, just at the end. To me that seems to suggest that it's
not just simply that it "steals" the traffic for the interfaces.

It seems we have to try and replicate it in the lab to find out what
actually happened. :-)

Thank you for the input.

Regards,
Peter



From sethm at rollernet.us  Tue Mar 10 18:50:50 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Tue, 10 Mar 2009 15:50:50 -0700
Subject: [c-nsp] power down of standby sup is not possible
In-Reply-To: <49B6B6D2.4000308@forthnet.gr>
References: <49B6B6D2.4000308@forthnet.gr>
Message-ID: <49B6EECA.4090602@rollernet.us>

Tassos Chatzithomaoglou wrote:
> Anyone care to explain why such a limitation?
> 
> 7609(config)#no power enable module 5
> %Error: no power control on supervisor cards
> 
> 7609#sh mod
> Mod Ports Card Type                              Model             
> Serial No.
> --- ----- -------------------------------------- ------------------
> -----------
>   5    2  Supervisor Engine 720 (Hot)            WS-SUP720-3BXL
>   6    2  Supervisor Engine 720 (Active)         WS-SUP720-3BXL
> 
> 
> I'm trying to power down the standby sup and i though cisco's green
> agenda would have though of that.
> 
> 

It's not a "green" thing, but a "redundant" thing. A second supervisor
is for redundancy, and if it's off and unconfigured, you might as well
just store it on a shelf and swap it in when needed because you won't be
able to power it up anyway if the active sup fails. They're doing more
than just synchronizing config changes when in standby mode.

~Seth

From todd at newfrontierssolutions.com  Tue Mar 10 19:49:44 2009
From: todd at newfrontierssolutions.com (Todd Shipway)
Date: Tue, 10 Mar 2009 19:49:44 -0400
Subject: [c-nsp] 7500 Channelized DS3 Issues
Message-ID: <1236728984.8428.8.camel@booger>

We are experiencing weird issues on a channelized DS3 card with
interfaces dying at random.

DS3 card is divided into multiple T1 interfaces.  All interfaces have
been running without problems for weeks.  Last week 1 interface went
down, and when it came back up, no traffic will go across the interface.
The int shows as up/up, manually setting a route doesn't help anything.
Copying the int config to a different channel on the same card fixes the
issue and traffic is back to normal.

Today, we had 2 interfaces that were part of a multilink ppp interface
go down and right back up.  All interfaces were up/up including the
MLPPP interface.  Moving them to different channels resulted in the same
issue.  Moving 1 T1 to a Multi-channel T1 card and keeping the other T1
on the channelized DS3 allowed the multilink interface to come up and
traffic went back to normal. 

No errors or alarms on any cards.  Cards aren't over provisioned, and I
can't pinpoint why this issue is occurring.  It seems like it's slowly
spreading from interface to interface.  

Has anyone experienced something similar or have any clues as to what I
could possibly look for?

Thanks,
Todd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090310/6e24530d/attachment.bin>

From achatz at forthnet.gr  Tue Mar 10 20:12:37 2009
From: achatz at forthnet.gr (Tassos Chatzithomaoglou)
Date: Wed, 11 Mar 2009 02:12:37 +0200
Subject: [c-nsp] power down of standby sup is not possible
In-Reply-To: <49B6EECA.4090602@rollernet.us>
References: <49B6B6D2.4000308@forthnet.gr> <49B6EECA.4090602@rollernet.us>
Message-ID: <49B701F5.1000206@forthnet.gr>



Seth Mattinen wrote on 11/03/2009 00:50:
> Tassos Chatzithomaoglou wrote:
>> Anyone care to explain why such a limitation?
>>
>> 7609(config)#no power enable module 5
>> %Error: no power control on supervisor cards
>>
>> 7609#sh mod
>> Mod Ports Card Type                              Model             
>> Serial No.
>> --- ----- -------------------------------------- ------------------
>> -----------
>>   5    2  Supervisor Engine 720 (Hot)            WS-SUP720-3BXL
>>   6    2  Supervisor Engine 720 (Active)         WS-SUP720-3BXL
>>
>>
>> I'm trying to power down the standby sup and i though cisco's green
>> agenda would have though of that.
>>
>>
> 
> It's not a "green" thing, but a "redundant" thing. A second supervisor
> is for redundancy, and if it's off and unconfigured, you might as well
> just store it on a shelf and swap it in when needed because you won't be
> able to power it up anyway if the active sup fails. They're doing more
> than just synchronizing config changes when in standby mode.
> 
> ~Seth

Seth,

There are remote locations (with more than one box installed) that i don't have a shelf 
and i prefer to have one sup "online" (but not as standby) serving all boxes. That way i 
can watch it through my inventory management system. In case of an emergency, someone 
staying nearby can go there and just plug it in, replacing the active sup in any box.


-- 
Tassos

From sethm at rollernet.us  Tue Mar 10 20:25:03 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Tue, 10 Mar 2009 17:25:03 -0700
Subject: [c-nsp] power down of standby sup is not possible
In-Reply-To: <49B701F5.1000206@forthnet.gr>
References: <49B6B6D2.4000308@forthnet.gr> <49B6EECA.4090602@rollernet.us>
	<49B701F5.1000206@forthnet.gr>
Message-ID: <49B704DF.4050206@rollernet.us>

Tassos Chatzithomaoglou wrote:
> 
> 
> Seth Mattinen wrote on 11/03/2009 00:50:
>> Tassos Chatzithomaoglou wrote:
>>> Anyone care to explain why such a limitation?
>>>
>>> 7609(config)#no power enable module 5
>>> %Error: no power control on supervisor cards
>>>
>>> 7609#sh mod
>>> Mod Ports Card Type                              Model            
>>> Serial No.
>>> --- ----- -------------------------------------- ------------------
>>> -----------
>>>   5    2  Supervisor Engine 720 (Hot)            WS-SUP720-3BXL
>>>   6    2  Supervisor Engine 720 (Active)         WS-SUP720-3BXL
>>>
>>>
>>> I'm trying to power down the standby sup and i though cisco's green
>>> agenda would have though of that.
>>>
>>>
>>
>> It's not a "green" thing, but a "redundant" thing. A second supervisor
>> is for redundancy, and if it's off and unconfigured, you might as well
>> just store it on a shelf and swap it in when needed because you won't be
>> able to power it up anyway if the active sup fails. They're doing more
>> than just synchronizing config changes when in standby mode.
>>
>> ~Seth
> 
> Seth,
> 
> There are remote locations (with more than one box installed) that i
> don't have a shelf and i prefer to have one sup "online" (but not as
> standby) serving all boxes. That way i can watch it through my inventory
> management system. In case of an emergency, someone staying nearby can
> go there and just plug it in, replacing the active sup in any box.
> 


Basically your storage space is a supervisor slot. Someone from Cisco
should know if this is just a config thing or actually in the hardware
design.

~Seth

From andy.saykao at staff.netspace.net.au  Tue Mar 10 23:30:17 2009
From: andy.saykao at staff.netspace.net.au (Andy Saykao)
Date: Wed, 11 Mar 2009 14:30:17 +1100
Subject: [c-nsp] BGP Route Selection
Message-ID: <56F211C5E3F24F47B103EA1B253822BE03654C54@vic-cr-ex1.staff.netspace.net.au>

Hi All,
 
Just trying to get my head around why BGP prefers a certain route over
others in my example below. I've read up on how BGP makes it's path
selection decision but I can't follow why it hasn't chosen a route with
a higher local preferences.
 
Here's my example...

Edge-Router#sh ip bgp 202.134.39.34

BGP routing table entry for 202.134.39.0/24, version 1469850
Paths: (6 available, best #2, table Default-IP-Routing-Table)
  Advertised to update-groups:
     7          8          9

  7606 9837 9837 9837 18250, (Received from a RR-client), (received &
used)
    198.32.212.61 (metric 20) from 203.17.96.105 (203.17.101.40)
      Origin IGP, metric 0, localpref 90, valid, internal
      Community: 4854:6002
      Originator: 203.17.101.24, Cluster list: 203.17.101.40,
203.17.101.22

  7606 9837 9837 9837 18250, (Received from a RR-client), (received &
used)
    198.32.212.61 (metric 20) from 203.17.96.101 (203.17.101.40)
      Origin IGP, metric 0, localpref 90, valid, internal, best
      Community: 4854:6002
      Originator: 203.17.101.24, Cluster list: 203.17.101.40,
203.17.101.22

  1221 2764 9837 18250, (received-only)
    203.62.252.39 from 203.62.252.39 (203.62.252.39)
      Origin IGP, localpref 100, valid, external

  1221 2764 9837 18250
    203.62.252.241 from 203.62.252.241 (203.62.252.241)
      Origin IGP, metric 120, localpref 50, valid, external
      Community: 4854:2001

  1221 2764 9837 18250, (received-only)
    203.62.252.241 from 203.62.252.241 (203.62.252.241)
      Origin IGP, localpref 100, valid, external

  1221 2764 9837 18250, (received-only)
    203.62.252.240 from 203.62.252.240 (203.62.252.240)
      Origin IGP, localpref 100, valid, external

 
Edge-Router#sh ip route 202.134.39.34
Routing entry for 202.134.39.0/24
  Known via "bgp 4854", distance 200, metric 0
  Tag 7606, type internal
  Redistributing via ospf 200
  Last update from 198.32.212.61 6d11h ago
  Routing Descriptor Blocks:
  * 198.32.212.61, from 203.17.96.101, 6d11h ago
      Route metric is 0, traffic share count is 1
      AS Hops 5
      Route tag 7606

 
I can only imagine it has something to do with the output below which
gives me a better indication of which prefixes have been received by
this router and their local preference. After looking at that, it would
make sense why it chose #2 from above.
 
Edge-Router#sh ip bgp 202.134.39.0 255.255.255.0 longer-prefixes
BGP table version is 1511449, local router ID is 203.17.101.35
Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal,
              S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
 
   Network          Next Hop            Metric LocPrf Weight Path
* i202.134.39.0     198.32.212.61            0     90      0 7606 9837
9837 9837 18250 i
*>i                 198.32.212.61            0     90      0 7606 9837
9837 9837 18250 i
*                   203.62.252.241         120     50      0 1221 2764
9837 18250 i

What's the relationship between the "sh ip bgp A.B.C.D" and "sh ip bgp
longer-prefixes" command? Why are there "(received-only)" routes and
what does that mean? The "(received-only)" routes have a higher local
preferences but why aren't they shown with the "sh ip bgp
longer-prefixes" command?
 
Thanks for everyone's help...
 
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 oboehmer at cisco.com  Tue Mar 10 23:46:25 2009
From: oboehmer at cisco.com (Oliver Boehmer (oboehmer))
Date: Wed, 11 Mar 2009 04:46:25 +0100
Subject: [c-nsp] BGP Route Selection
In-Reply-To: <56F211C5E3F24F47B103EA1B253822BE03654C54@vic-cr-ex1.staff.netspace.net.au>
References: <56F211C5E3F24F47B103EA1B253822BE03654C54@vic-cr-ex1.staff.netspace.net.au>
Message-ID: <70B7A1CCBFA5C649BD562B6D9F7ED7840704D4DC@xmb-ams-333.emea.cisco.com>

Andy Saykao <> wrote on Wednesday, March 11, 2009 04:30:

> Hi All,
> 
> Just trying to get my head around why BGP prefers a certain route over
> others in my example below. I've read up on how BGP makes it's path
> selection decision but I can't follow why it hasn't chosen a route
> with a higher local preferences.

because all the paths with a higher local-pref are ignored as they are
"received-only", i.e. stored in the table due to "soft-recoconfiguration
inbound" config on your neighbors..  
 
[..]
> 
> What's the relationship between the "sh ip bgp A.B.C.D" and "sh ip bgp
> longer-prefixes" command?

the latter only shows the non-received-only paths..

> Why are there "(received-only)" routes and
> what does that mean? The "(received-only)" routes have a higher local
> preferences but why aren't they shown with the "sh ip bgp
> longer-prefixes" command?

see above: because they are ignored.. this is also described in
http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a008009
4431.shtml..

	oli

From samantha at cairns.net.au  Wed Mar 11 03:15:58 2009
From: samantha at cairns.net.au (Regional Connect (Samantha))
Date: Wed, 11 Mar 2009 17:15:58 +1000
Subject: [c-nsp] Access Servers (LNS)
Message-ID: <FD9777F55745476D82D6B77920083263@SamanthaPC>

Hi List

I am doing some enquiries so I can remove our l2tpns machines.
I have bought some cheap npe-225 ciscos off ebay, orginally as source of spares for our 7206G1 (Power Supplies)

After reading I found out I may be better off deplying the current l2tpns servers elsewhere

If I do this I am trying to get some questions answerwed but been unable to find the answers (as they differ so much)

What is the max number of sessions I could expect from 2 of these machines?

And if I choose to use npe-400 what would it be

How much ram would I need in both scenerios to be "workable"

Thanks in advance


Samantha
Regional Internet Connect
samantha at regionalconnect.com.au



---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 090310-0, 10/03/2009
Tested on: 11/03/2009 5:15:59 PM
avast! - copyright (c) 1988-2009 ALWIL Software.
http://www.avast.com



From asad747 at cyber.net.pk  Wed Mar 11 04:12:30 2009
From: asad747 at cyber.net.pk (Asad Ul-Islam)
Date: Wed, 11 Mar 2009 13:12:30 +0500
Subject: [c-nsp] CPU Usage for standby SUP720?
Message-ID: <003c01c9a221$1f6bf8c0$5e43ea40$@net.pk>

Dear friends

 

I am trying to poll for CPU usage of Standby SUP7203b in 6500 Chassis.

 

I have tried polling PROCESS MIB but its returning only two Values for
cpmCPUTotalPhysicalIndex , which are of ACTIVE SUP. (SUP in Slot 8 is in
Standby state)

 

SNMPv2-SMI::enterprises.9.9.109.1.1.1.1.2.1 = INTEGER: 4017 

SNMPv2-SMI::enterprises.9.9.109.1.1.1.1.2.2 = INTEGER: 4001

 

However walking on ENTITY MIB for entPhysicalIndex shows the CPU index for
both SUPs

 

SNMPv2-SMI::mib-2.47.1.1.1.1.2.4001 = STRING: "CPU of Switching Processor 7"

SNMPv2-SMI::mib-2.47.1.1.1.1.2.4017 = STRING: "CPU of Routing Processor 7"

SNMPv2-SMI::mib-2.47.1.1.1.1.2.5001 = STRING: "CPU of Switching Processor 8"

SNMPv2-SMI::mib-2.47.1.1.1.1.2.5017 = STRING: "CPU of Routing Processor 8"

 

I wonder why PROCESS MIB is not returning values for Standby SUP.. Is it
some limitation that Standby SUP cannot be polled?  Or I am making some
mistake here??

 

Regards,


Asad


From soonkian.wong at gmail.com  Wed Mar 11 04:38:43 2009
From: soonkian.wong at gmail.com (Soon Kian)
Date: Wed, 11 Mar 2009 16:38:43 +0800
Subject: [c-nsp] PVDM resources required for VIC3-2FXS WIC ?
Message-ID: <371cac6a0903110138k78d78841nafb4191157c57c0d@mail.gmail.com>

Hi all,

Wondering if PVDM is required for VIC3-2FXS WIC ?

I'm using the following

- Cisco2811
- IP Voice feature set
- Version: 124-24.T

Thanks in advance

From skoal at skoal.name  Wed Mar 11 04:49:34 2009
From: skoal at skoal.name (Gergely Antal)
Date: Wed, 11 Mar 2009 09:49:34 +0100
Subject: [c-nsp] CPU Usage for standby SUP720?
In-Reply-To: <003c01c9a221$1f6bf8c0$5e43ea40$@net.pk>
References: <003c01c9a221$1f6bf8c0$5e43ea40$@net.pk>
Message-ID: <49B77B1E.1010707@skoal.name>

If i'm not mistaken you can only poll the active sup
,and if a switchover occures then you can poll the new active sup based
on the indexes by the entity-mib

Asad Ul-Islam wrote:
> Dear friends
> 
>  
> 
> I am trying to poll for CPU usage of Standby SUP7203b in 6500 Chassis.
> 
>  
> 
> I have tried polling PROCESS MIB but its returning only two Values for
> cpmCPUTotalPhysicalIndex , which are of ACTIVE SUP. (SUP in Slot 8 is in
> Standby state)
> 
>  
> 
> SNMPv2-SMI::enterprises.9.9.109.1.1.1.1.2.1 = INTEGER: 4017 
> 
> SNMPv2-SMI::enterprises.9.9.109.1.1.1.1.2.2 = INTEGER: 4001
> 
>  
> 
> However walking on ENTITY MIB for entPhysicalIndex shows the CPU index for
> both SUPs
> 
>  
> 
> SNMPv2-SMI::mib-2.47.1.1.1.1.2.4001 = STRING: "CPU of Switching Processor 7"
> 
> SNMPv2-SMI::mib-2.47.1.1.1.1.2.4017 = STRING: "CPU of Routing Processor 7"
> 
> SNMPv2-SMI::mib-2.47.1.1.1.1.2.5001 = STRING: "CPU of Switching Processor 8"
> 
> SNMPv2-SMI::mib-2.47.1.1.1.1.2.5017 = STRING: "CPU of Routing Processor 8"
> 
>  
> 
> I wonder why PROCESS MIB is not returning values for Standby SUP.. Is it
> some limitation that Standby SUP cannot be polled?  Or I am making some
> mistake here??
> 
>  
> 
> Regards,
> 
> 
> Asad
> 
> _______________________________________________
> cisco-nsp mailing 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: 260 bytes
Desc: OpenPGP digital signature
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090311/7b5fede7/attachment.bin>

From skoal at skoal.name  Wed Mar 11 05:01:55 2009
From: skoal at skoal.name (Gergely Antal)
Date: Wed, 11 Mar 2009 10:01:55 +0100
Subject: [c-nsp] CPU Usage for standby SUP720?
In-Reply-To: <49B77B1E.1010707@skoal.name>
References: <003c01c9a221$1f6bf8c0$5e43ea40$@net.pk>
	<49B77B1E.1010707@skoal.name>
Message-ID: <49B77E03.8050008@skoal.name>

If you use cacti then here is a good template for your problem
http://forums.cacti.net/about27623.html

Gergely Antal wrote:
> If i'm not mistaken you can only poll the active sup
> ,and if a switchover occures then you can poll the new active sup based
> on the indexes by the entity-mib
> 
> Asad Ul-Islam wrote:
>> Dear friends
>>
>>  
>>
>> I am trying to poll for CPU usage of Standby SUP7203b in 6500 Chassis.
>>
>>  
>>
>> I have tried polling PROCESS MIB but its returning only two Values for
>> cpmCPUTotalPhysicalIndex , which are of ACTIVE SUP. (SUP in Slot 8 is in
>> Standby state)
>>
>>  
>>
>> SNMPv2-SMI::enterprises.9.9.109.1.1.1.1.2.1 = INTEGER: 4017 
>>
>> SNMPv2-SMI::enterprises.9.9.109.1.1.1.1.2.2 = INTEGER: 4001
>>
>>  
>>
>> However walking on ENTITY MIB for entPhysicalIndex shows the CPU index for
>> both SUPs
>>
>>  
>>
>> SNMPv2-SMI::mib-2.47.1.1.1.1.2.4001 = STRING: "CPU of Switching Processor 7"
>>
>> SNMPv2-SMI::mib-2.47.1.1.1.1.2.4017 = STRING: "CPU of Routing Processor 7"
>>
>> SNMPv2-SMI::mib-2.47.1.1.1.1.2.5001 = STRING: "CPU of Switching Processor 8"
>>
>> SNMPv2-SMI::mib-2.47.1.1.1.1.2.5017 = STRING: "CPU of Routing Processor 8"
>>
>>  
>>
>> I wonder why PROCESS MIB is not returning values for Standby SUP.. Is it
>> some limitation that Standby SUP cannot be polled?  Or I am making some
>> mistake here??
>>
>>  
>>
>> Regards,
>>
>>
>> Asad
>>
>> _______________________________________________
>> cisco-nsp mailing 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/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090311/5fa27b2d/attachment.bin>

From gert at greenie.muc.de  Wed Mar 11 05:10:59 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Wed, 11 Mar 2009 10:10:59 +0100
Subject: [c-nsp] CPU Usage for standby SUP720?
In-Reply-To: <003c01c9a221$1f6bf8c0$5e43ea40$@net.pk>
References: <003c01c9a221$1f6bf8c0$5e43ea40$@net.pk>
Message-ID: <20090311091059.GZ290@greenie.muc.de>

Hi,

On Wed, Mar 11, 2009 at 01:12:30PM +0500, Asad Ul-Islam wrote:
> I am trying to poll for CPU usage of Standby SUP7203b in 6500 Chassis.

Should the standby SUP show more than neglible CPU usage?  If yes, why?

(I'm genuinely curious what it might do that causes CPU load)
 
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/20090311/21b2a325/attachment.bin>

From A.L.M.Buxey at lboro.ac.uk  Wed Mar 11 05:23:59 2009
From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk)
Date: Wed, 11 Mar 2009 09:23:59 +0000
Subject: [c-nsp] CPU Usage for standby SUP720?
In-Reply-To: <20090311091059.GZ290@greenie.muc.de>
References: <003c01c9a221$1f6bf8c0$5e43ea40$@net.pk>
	<20090311091059.GZ290@greenie.muc.de>
Message-ID: <20090311092359.GA22892@lboro.ac.uk>

Hi,

> Should the standby SUP show more than neglible CPU usage?  If yes, why?
> 
> (I'm genuinely curious what it might do that causes CPU load)

in an active standby mode, the primary and standby are constantly
sharing stuff and storing details...that said, you cant do much
with the one that isnt active... 'Standby console disabled' etc

alan

From anderson.levi at gmail.com  Wed Mar 11 05:29:09 2009
From: anderson.levi at gmail.com (Anderson Levi)
Date: Wed, 11 Mar 2009 12:29:09 +0300
Subject: [c-nsp] ME3400
Message-ID: <e22d607d0903110229p2cdbad27ue7ab34963df664fa@mail.gmail.com>

Hi,

I need to find out how many routes a Cisco ME3400 can hold. Anyone with an
idea or pointer as to where I can find out? Any help would be appreciated.
Thanks.

From A.L.M.Buxey at lboro.ac.uk  Wed Mar 11 05:33:36 2009
From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk)
Date: Wed, 11 Mar 2009 09:33:36 +0000
Subject: [c-nsp] power down of standby sup is not possible
In-Reply-To: <49B6D6CA.4090100@forthnet.gr>
References: <49B6B6D2.4000308@forthnet.gr> <20090310204805.GC20682@lboro.ac.uk>
	<49B6D6CA.4090100@forthnet.gr>
Message-ID: <20090311093336.GB22892@lboro.ac.uk>

Hi,

> Alan, you can do "hw-module module x reset" in order to reset a module (sup included).

i know - in fact, i think it was this particular issue that made
me find the hw-module command  :-)

> I was just trying to have a 2nd sup disabled. I don't need any syncing 
> between the sups and power saving would be a welcome addition.

no sync'ing?  so how do you ensure your spare sup has the right config when it is needed? what process or procedure is followed?

> Talking about power-saving, i haven't found any way to disable power 
> reservation of a sup slot, when that one is not being used. You can 
> always put another module there, but i can't consider this as a solution.

power reserved != power used.  the system just ensures that the
right amount is reserved so it can be used, rather than not being
able to provide the juice.

alan

From achatz at forthnet.gr  Wed Mar 11 05:39:52 2009
From: achatz at forthnet.gr (Tassos Chatzithomaoglou)
Date: Wed, 11 Mar 2009 11:39:52 +0200
Subject: [c-nsp] CPU Usage for standby SUP720?
In-Reply-To: <20090311092359.GA22892@lboro.ac.uk>
References: <003c01c9a221$1f6bf8c0$5e43ea40$@net.pk>	<20090311091059.GZ290@greenie.muc.de>
	<20090311092359.GA22892@lboro.ac.uk>
Message-ID: <49B786E8.6060001@forthnet.gr>



A.L.M.Buxey at lboro.ac.uk wrote on 11/03/2009 11:23:
> Hi,
> 
>> Should the standby SUP show more than neglible CPU usage?  If yes, why?
>>
>> (I'm genuinely curious what it might do that causes CPU load)
> 
> in an active standby mode, the primary and standby are constantly
> sharing stuff and storing details...that said, you cant do much
> with the one that isnt active... 'Standby console disabled' etc
> 
> alan

7609(config)#redundancy
7609(config-red)#main-cpu
7609(config-r-mc)#standby console ?
   enable  Enable


At least in SRD1 (quite strangely it's not the default, but it's also not shown in the 
config when configured).

-- 
Tassos

From ayourtch at cisco.com  Wed Mar 11 06:16:36 2009
From: ayourtch at cisco.com (Andrew Yourtchenko)
Date: Wed, 11 Mar 2009 11:16:36 +0100 (CET)
Subject: [c-nsp] FWSM HA secondary reload & long downtime
In-Reply-To: <1236719408.4513.51.camel@localhost.localdomain>
References: <1236633344.3572.13.camel@localhost.localdomain> 
	<Pine.LNX.4.64.0903101125050.6781@zippy.stdio.be>
	<1236719408.4513.51.camel@localhost.localdomain>
Message-ID: <Pine.LNX.4.64.0903111101340.21155@zippy.stdio.be>



On Tue, 10 Mar 2009, Peter Rathlev wrote:

> On Tue, 2009-03-10 at 11:32 +0100, Andrew Yourtchenko wrote:
>> if it is merely a new standby that is coming up, the active should not
>> stop forwarding the traffic.
>
> That's what I would've assumed too. :-) I do seem to remember that we've
> seen this before though, when we had random reboots (CSCse15099 if I
> remember correctly) of secondary units resulting in downtime.

ahha. interesting - so there's probably also something specific to the 
setup that might be contributing to seeing this.

>
>> I'd watch out for "logging standby" - I vaguely remember there were
>> some issues where the newly coming up box would try to send the
>> traffic with the wrong IP/MAC and/or send the gratuitous arp with the
>> wrong info in there.
>>
>> Especially may be true if you are bringing up primary as standby - at
>> this moment the secondary/active is forwarding the traffic using the
>> primary's mac addresses.
>
> Standby logging is disabled on all contexts, so this shouldn't be the
> issue. Of course if the module coming up sends out gratuitous ARPs this
> could break things with the way PIX/FWSM/ASA does HA, using the same
> MAC-address.
>
> I had thought that the unit coming up would start by looking at the
> failover interface(s) to see if there is already an active unit, and
> then start acting as active/standby depending of what it hears.
>

That's precisely how it is supposed to work :-)

> Otherwise a crashing/rebooting primary unit would always introduce
> downtime when coming up again.
>
>> Of course, interesting would be to check if indeed this is on all the
>> contexts or only some of them, etc.
>
> The log buffer (logging errors) on the contexts on the standby unit
> (which is the configured primary) didn't say "'
>
>> From the sys context on the standby:
>
> Mar 09 2009 16:41:04: %FWSM-4-411003: Interface statefullfailover, changed state to administratively up
> Mar 09 2009 16:41:05: %FWSM-5-504001: Security context admin was added to the system
> ...
> Mar 09 2009 16:41:07: %FWSM-5-504001: Security context sample was added to the system
> Mar 09 2009 16:41:26: %FWSM-1-709006: (Primary) End Configuration Replication (STB)
> Mar 09 2009 16:42:02: %FWSM-6-210022: LU missed 4837568 updates
>
>> From one of the contexts, still the standby unit:
>
> Mar 09 2009 16:41:35: %FWSM-1-105006: (Primary) Link status 'Up' on interface internet
> Mar 09 2009 16:41:35: %FWSM-1-105003: (Primary) Monitoring on interface internet waiting
> Mar 09 2009 16:41:35: %FWSM-1-105006: (Primary) Link status 'Up' on interface aars_pro
> Mar 09 2009 16:41:35: %FWSM-1-105003: (Primary) Monitoring on interface aars_pro waiting
> Mar 09 2009 16:41:35: %FWSM-1-105006: (Primary) Link status 'Up' on interface inside
> Mar 09 2009 16:41:35: %FWSM-1-105003: (Primary) Monitoring on interface inside waiting
> Mar 09 2009 16:41:35: %FWSM-1-105006: (Primary) Link status 'Up' on interface aars_interfw
> Mar 09 2009 16:41:35: %FWSM-1-105003: (Primary) Monitoring on interface aars_interfw waiting
> Mar 09 2009 16:41:44: %FWSM-1-105004: (Primary) Monitoring on interface internet normal
> Mar 09 2009 16:41:44: %FWSM-1-105004: (Primary) Monitoring on interface aars_pro normal
> Mar 09 2009 16:41:44: %FWSM-1-105004: (Primary) Monitoring on interface inside normal
> Mar 09 2009 16:41:44: %FWSM-1-105004: (Primary) Monitoring on interface aars_interfw normal
>
> So the contexts weren't really activated (with "Up" interfaces) during
> all the downtime, just at the end. To me that seems to suggest that it's
> not just simply that it "steals" the traffic for the interfaces.

Right. That was why I was wondering whether indeed "all" (as in 
"absolutely all, i swear" :) the traffic was affected, or only some part 
of it, and with what timing. Also interesting thing to check if the 
existing TCP connections continue to run ok (so then the problem area 
could be isolated to session path and up). Of course, in the real-world 
scenario there's frequently simply not enough time to look at those 
details, but they might be definitely helpful.

>
> It seems we have to try and replicate it in the lab to find out what
> actually happened. :-)

Yes, that would be most ideal - if this issue is reproducible 
in the lab, then a case to further nail it down would be the way to go.

cheers,
andrew

From marco at linuxgoeroe.dhs.org  Wed Mar 11 05:34:30 2009
From: marco at linuxgoeroe.dhs.org (marco at linuxgoeroe.dhs.org)
Date: Wed, 11 Mar 2009 10:34:30 +0100 (CET)
Subject: [c-nsp] ME3400
In-Reply-To: <e22d607d0903110229p2cdbad27ue7ab34963df664fa@mail.gmail.com>
References: <e22d607d0903110229p2cdbad27ue7ab34963df664fa@mail.gmail.com>
Message-ID: <31371.212.142.33.197.1236764070.squirrel@www.vive-id.nl>


> I need to find out how many routes a Cisco ME3400 can hold. Anyone with an
> idea or pointer as to where I can find out? Any help would be appreciated.

Datasheet says 5000:
http://www.cisco.com/en/US/prod/collateral/switches/ps6568/ps6580/product_data_sheet0900aecd8034fef3.html

             Regards,

                    Marco.

From asad747 at cyber.net.pk  Wed Mar 11 06:41:51 2009
From: asad747 at cyber.net.pk (Asad Ul-Islam)
Date: Wed, 11 Mar 2009 15:41:51 +0500
Subject: [c-nsp] CPU Usage for standby SUP720?
In-Reply-To: <20090311092359.GA22892@lboro.ac.uk>
References: <003c01c9a221$1f6bf8c0$5e43ea40$@net.pk>
	<20090311091059.GZ290@greenie.muc.de>
	<20090311092359.GA22892@lboro.ac.uk>
Message-ID: <005f01c9a235$fd13f600$f73be200$@net.pk>

Hello!

My initial question was to poll CPU of Standby SUP via SNMP

I don't think enabling or disabling Console of Standby will have anything to
do with SNMP?? 

I just want to confirm if it's possible to Poll CPU of Standby SUP. Or it's
not possible Logically, or is it some bug? Bcos we are doing same for
Junipers with redundant REs.


Regards,


Asad.

-----Original Message-----
From: A.L.M.Buxey at lboro.ac.uk [mailto:A.L.M.Buxey at lboro.ac.uk] 
Sent: Wednesday, March 11, 2009 2:24 PM
To: Gert Doering
Cc: Asad Ul-Islam; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] CPU Usage for standby SUP720?

Hi,

> Should the standby SUP show more than neglible CPU usage?  If yes, why?
> 
> (I'm genuinely curious what it might do that causes CPU load)

in an active standby mode, the primary and standby are constantly
sharing stuff and storing details...that said, you cant do much
with the one that isnt active... 'Standby console disabled' etc

alan


From dv at dv.ru  Wed Mar 11 06:44:21 2009
From: dv at dv.ru (Dmitry Valdov)
Date: Wed, 11 Mar 2009 13:44:21 +0300 (MSK)
Subject: [c-nsp] ME3400
In-Reply-To: <31371.212.142.33.197.1236764070.squirrel@www.vive-id.nl>
References: <e22d607d0903110229p2cdbad27ue7ab34963df664fa@mail.gmail.com>
	<31371.212.142.33.197.1236764070.squirrel@www.vive-id.nl>
Message-ID: <20090311134228.T56136@xkis.kis.ru>

Hi!

The device says 9K total (5K directly connected and  4K indirect)..
===

#sh sdm pref
  The current template is "default" template.
  The selected template optimizes the resources in
  the switch to support this level of features for
  8 routed interfaces and 1024 VLANs.

   number of unicast mac addresses:                  5K
   number of IPv4 IGMP groups + multicast routes:    1K
   number of IPv4 unicast routes:                    9K
     number of directly-connected IPv4 hosts:        5K
     number of indirect IPv4 routes:                 4K
   number of IPv4 policy based routing aces:         0.5K
   number of IPv4/MAC qos aces:                      0.5K
   number of IPv4/MAC security aces:                 1K



On Wed, 11 Mar 2009, marco at linuxgoeroe.dhs.org wrote:

>
>> I need to find out how many routes a Cisco ME3400 can hold. Anyone with an
>> idea or pointer as to where I can find out? Any help would be appreciated.
>
> Datasheet says 5000:
> http://www.cisco.com/en/US/prod/collateral/switches/ps6568/ps6580/product_data_sheet0900aecd8034fef3.html
>
>             Regards,
>
>                    Marco.
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

-- 
Dmitry Valdov
CCIE #15379 (R&S and SP)

From Marcus.Gerdon at versatel.de  Wed Mar 11 06:45:40 2009
From: Marcus.Gerdon at versatel.de (Marcus.Gerdon)
Date: Wed, 11 Mar 2009 11:45:40 +0100
Subject: [c-nsp] Sup720 crashing at RP boot - HW revision dependent ?
Message-ID: <227142482560EF458FF1F7E784E26AB84727E8@FLBVEXCH01.versatel.local>

Hi @all,

yesterday I've been hit by a somewhat strange - and possibly worrying -
effect with Sup720 in 6500.

I've got 3 Sup720-3BXL, one with an older HW revision (Sup: 4.4 / PFC:
1.6 / MSFC: 2.5) and 2 with newer (Sup: 5.2 / PFC: 1.8 / MSFC: 2.5). All
three have been tested in a 6509 successfully by the supplier. According
the test sheets they've used a Rev. 3.0 chassis.

For offline testing and preparation I've an 6509 and 6506 spare chassis
at hands, both of them being Rev. 2.0.

When trying to boot those Sup in my 6509 the older one boots fine and
everything is ok. The newer ones both start to boot and after switching
to boot the RP it stalls (download doesn't even start, hangs after
memory is displayed). After a minute or two a 'software forced crash'
occurs and I'm thrown do SP rommon.

Up to this point no updates, config changes or anything other than
plugging them in the chassis and turning the power on has been done.

It doesn't matter if they're put in slot 5 or 6, if the working one is
already active in slot 5 or if I'm manually booting from rommon instead
of autoboot. Also the IOS used doesn't change anything (18SXF, 18SXI,
17SXd)

Interestingly in the Rev. 2.0 6506 all three are booting fine. I've done
both rom updates in the 6506 and tried again in the 6509 - without any
change.

To me this looks like there's some dependancy between HW revisions of
the Sup or PFC (MSFC rev. is the same on all threee) and the 6509
chassis (6506 wasn't effected). 

I've searched cisco.com for quite some time but without any hint to this
issue. The only thing I found was that there're a few 6509-NEB eeprom
updates to be applied to the chassis itself. So in fact there is some
active rom part with the chassis that supposedly will differ between
revisions.


Does someone stumbled upon this, had similar issues or maybe even know
or did see any document (comp. matrix, workaround or alike) about this ?



regards,

Marcus

From p.mayers at imperial.ac.uk  Wed Mar 11 07:14:30 2009
From: p.mayers at imperial.ac.uk (Phil Mayers)
Date: Wed, 11 Mar 2009 11:14:30 +0000
Subject: [c-nsp] Sup720 crashing at RP boot - HW revision dependent ?
In-Reply-To: <227142482560EF458FF1F7E784E26AB84727E8@FLBVEXCH01.versatel.local>
References: <227142482560EF458FF1F7E784E26AB84727E8@FLBVEXCH01.versatel.local>
Message-ID: <49B79D16.3040809@imperial.ac.uk>

Marcus.Gerdon wrote:
> Hi @all,
> 
> yesterday I've been hit by a somewhat strange - and possibly worrying -
> effect with Sup720 in 6500.
> 
> I've got 3 Sup720-3BXL, one with an older HW revision (Sup: 4.4 / PFC:
> 1.6 / MSFC: 2.5) and 2 with newer (Sup: 5.2 / PFC: 1.8 / MSFC: 2.5). All
> three have been tested in a 6509 successfully by the supplier. According
> the test sheets they've used a Rev. 3.0 chassis.
> 
> For offline testing and preparation I've an 6509 and 6506 spare chassis
> at hands, both of them being Rev. 2.0.
> 
> When trying to boot those Sup in my 6509 the older one boots fine and
> everything is ok. The newer ones both start to boot and after switching
> to boot the RP it stalls (download doesn't even start, hangs after
> memory is displayed). After a minute or two a 'software forced crash'
> occurs and I'm thrown do SP rommon.

I've seen this exact symptom a couple of times with new supervisors. It 
generally "goes away" after a bit of ill-specified fiddling (I know, 
that's not very helpful)

The last time it happened, I ended up booting from a really old IOS off 
the bootflash, re-formatting the CF card, loading a new IOS on then 
re-loading again.

If you pin this down definitively I'd love to know the cause; there was 
another post on the list recently with similar symptoms, so you're not 
alone.

From achatz at forthnet.gr  Wed Mar 11 07:25:25 2009
From: achatz at forthnet.gr (Tassos Chatzithomaoglou)
Date: Wed, 11 Mar 2009 13:25:25 +0200
Subject: [c-nsp] Sup720 crashing at RP boot - HW revision dependent ?
In-Reply-To: <227142482560EF458FF1F7E784E26AB84727E8@FLBVEXCH01.versatel.local>
References: <227142482560EF458FF1F7E784E26AB84727E8@FLBVEXCH01.versatel.local>
Message-ID: <49B79FA5.6010800@forthnet.gr>

Marcus, are you using the latest rommon in the SP (8.5(3)) and RP (12.2(17r)SX5)?

6500#remote command switch sh ver | i ROM:
ROM: System Bootstrap, Version 8.5(3)

6500#sh ver | i ROM:
ROM: System Bootstrap, Version 12.2(17r)SX5, RELEASE SOFTWARE (fc1)


-- 
Tassos


Marcus.Gerdon wrote on 11/03/2009 12:45:
> Hi @all,
> 
> yesterday I've been hit by a somewhat strange - and possibly worrying -
> effect with Sup720 in 6500.
> 
> I've got 3 Sup720-3BXL, one with an older HW revision (Sup: 4.4 / PFC:
> 1.6 / MSFC: 2.5) and 2 with newer (Sup: 5.2 / PFC: 1.8 / MSFC: 2.5). All
> three have been tested in a 6509 successfully by the supplier. According
> the test sheets they've used a Rev. 3.0 chassis.
> 
> For offline testing and preparation I've an 6509 and 6506 spare chassis
> at hands, both of them being Rev. 2.0.
> 
> When trying to boot those Sup in my 6509 the older one boots fine and
> everything is ok. The newer ones both start to boot and after switching
> to boot the RP it stalls (download doesn't even start, hangs after
> memory is displayed). After a minute or two a 'software forced crash'
> occurs and I'm thrown do SP rommon.
> 
> Up to this point no updates, config changes or anything other than
> plugging them in the chassis and turning the power on has been done.
> 
> It doesn't matter if they're put in slot 5 or 6, if the working one is
> already active in slot 5 or if I'm manually booting from rommon instead
> of autoboot. Also the IOS used doesn't change anything (18SXF, 18SXI,
> 17SXd)
> 
> Interestingly in the Rev. 2.0 6506 all three are booting fine. I've done
> both rom updates in the 6506 and tried again in the 6509 - without any
> change.
> 
> To me this looks like there's some dependancy between HW revisions of
> the Sup or PFC (MSFC rev. is the same on all threee) and the 6509
> chassis (6506 wasn't effected). 
> 
> I've searched cisco.com for quite some time but without any hint to this
> issue. The only thing I found was that there're a few 6509-NEB eeprom
> updates to be applied to the chassis itself. So in fact there is some
> active rom part with the chassis that supposedly will differ between
> revisions.
> 
> 
> Does someone stumbled upon this, had similar issues or maybe even know
> or did see any document (comp. matrix, workaround or alike) about this ?
> 
> 
> 
> regards,
> 
> Marcus
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 

From hegedus.gabor at euroway.hu  Wed Mar 11 07:59:59 2009
From: hegedus.gabor at euroway.hu (Hegedus Gabor)
Date: Wed, 11 Mar 2009 12:59:59 +0100
Subject: [c-nsp] vlan trunking problem
Message-ID: <49B7A7BF.3000700@euroway.hu>

Hi all!

I have a problem:

I have c2960 with vlan 200, 300, and 1 for management,
and it connected to 861w router, but the 861w has just 2 vlan 
allowed(vlan 1 -management, vlan 300 for second vlan).

how can I "switch" the vlan200(c2960) traffic  to the vlan1(861w).

I tried the native vlan but didn't work:

c2960:
interface FastEthernet0/30
 switchport trunk native vlan 200
 switchport trunk allowed vlan 200,300
 switchport mode trunk
 spanning-tree portfast

861:
vlan 300
interface FastEthernet0
  switchport mode trunk

interface Vlan1
  ip address 192.168.1.1 255.255.255.0
  ip tcp adjust-mss 1452

interface Vlan300
  ip address 192.168.2.1 255.255.255.0


Any idea how can i resolve this problem?

thank you!
Gabor



From Marcus.Gerdon at versatel.de  Wed Mar 11 08:05:20 2009
From: Marcus.Gerdon at versatel.de (Marcus.Gerdon)
Date: Wed, 11 Mar 2009 13:05:20 +0100
Subject: [c-nsp] Sup720 crashing at RP boot - HW revision dependent ?
Message-ID: <227142482560EF458FF1F7E784E26AB84728AE@FLBVEXCH01.versatel.local>

Tassos,

they've been delivered and supplier-tested with 8.4(2) and 12.2(17r)S4 and bootet with those smoothly in the 6506.

I'm running 8.5(1) and 12.2(17r)SX5 everywhere and updated those Sup's accordingly. But it didn't make difference.



regards,

Marcus
 

> -----Urspr?ngliche Nachricht-----
> Von: cisco-nsp-bounces at puck.nether.net 
> [mailto:cisco-nsp-bounces at puck.nether.net] Im Auftrag von 
> Tassos Chatzithomaoglou
> Gesendet: Mittwoch, 11. M?rz 2009 12:25
> An: cisco-nsp at puck.nether.net
> Betreff: Re: [c-nsp] Sup720 crashing at RP boot - HW revision 
> dependent ?
> 
> Marcus, are you using the latest rommon in the SP (8.5(3)) 
> and RP (12.2(17r)SX5)?
> 
> 6500#remote command switch sh ver | i ROM:
> ROM: System Bootstrap, Version 8.5(3)
> 
> 6500#sh ver | i ROM:
> ROM: System Bootstrap, Version 12.2(17r)SX5, RELEASE SOFTWARE (fc1)
> 
> 
> -- 
> Tassos
> 
> 
> Marcus.Gerdon wrote on 11/03/2009 12:45:
> > Hi @all,
> > 
> > yesterday I've been hit by a somewhat strange - and 
> possibly worrying -
> > effect with Sup720 in 6500.
> > 
> > I've got 3 Sup720-3BXL, one with an older HW revision (Sup: 
> 4.4 / PFC:
> > 1.6 / MSFC: 2.5) and 2 with newer (Sup: 5.2 / PFC: 1.8 / 
> MSFC: 2.5). All
> > three have been tested in a 6509 successfully by the 
> supplier. According
> > the test sheets they've used a Rev. 3.0 chassis.
> > 
> > For offline testing and preparation I've an 6509 and 6506 
> spare chassis
> > at hands, both of them being Rev. 2.0.
> > 
> > When trying to boot those Sup in my 6509 the older one 
> boots fine and
> > everything is ok. The newer ones both start to boot and 
> after switching
> > to boot the RP it stalls (download doesn't even start, hangs after
> > memory is displayed). After a minute or two a 'software 
> forced crash'
> > occurs and I'm thrown do SP rommon.
> > 
> > Up to this point no updates, config changes or anything other than
> > plugging them in the chassis and turning the power on has been done.
> > 
> > It doesn't matter if they're put in slot 5 or 6, if the 
> working one is
> > already active in slot 5 or if I'm manually booting from 
> rommon instead
> > of autoboot. Also the IOS used doesn't change anything 
> (18SXF, 18SXI,
> > 17SXd)
> > 
> > Interestingly in the Rev. 2.0 6506 all three are booting 
> fine. I've done
> > both rom updates in the 6506 and tried again in the 6509 - 
> without any
> > change.
> > 
> > To me this looks like there's some dependancy between HW 
> revisions of
> > the Sup or PFC (MSFC rev. is the same on all threee) and the 6509
> > chassis (6506 wasn't effected). 
> > 
> > I've searched cisco.com for quite some time but without any 
> hint to this
> > issue. The only thing I found was that there're a few 
> 6509-NEB eeprom
> > updates to be applied to the chassis itself. So in fact 
> there is some
> > active rom part with the chassis that supposedly will differ between
> > revisions.
> > 
> > 
> > Does someone stumbled upon this, had similar issues or 
> maybe even know
> > or did see any document (comp. matrix, workaround or alike) 
> about this ?
> > 
> > 
> > 
> > regards,
> > 
> > Marcus
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> > 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 

From achatz at forthnet.gr  Wed Mar 11 09:17:13 2009
From: achatz at forthnet.gr (Tassos Chatzithomaoglou)
Date: Wed, 11 Mar 2009 15:17:13 +0200
Subject: [c-nsp] Sup720 crashing at RP boot - HW revision dependent ?
In-Reply-To: <227142482560EF458FF1F7E784E26AB84728AE@FLBVEXCH01.versatel.local>
References: <227142482560EF458FF1F7E784E26AB84728AE@FLBVEXCH01.versatel.local>
Message-ID: <49B7B9D9.9060707@forthnet.gr>

Marcus, since you're experiencing a software force crash, maybe you should open a tac case.

In a similar case of mine (booting seemed stuck for mins, but there wasn't any crash), i upgraded the flash monlib 
("upgrade filesystem monlib") and it worked fine afterwards.


--
Tassos

Marcus.Gerdon wrote on 11/03/2009 14:05:
> Tassos,
> 
> they've been delivered and supplier-tested with 8.4(2) and 12.2(17r)S4 and bootet with those smoothly in the 6506.
> 
> I'm running 8.5(1) and 12.2(17r)SX5 everywhere and updated those Sup's accordingly. But it didn't make difference.
> 
> 
> 
> regards,
> 
> Marcus
>  
> 
>> -----Urspru"ngliche Nachricht-----
>> Von: cisco-nsp-bounces at puck.nether.net 
>> [mailto:cisco-nsp-bounces at puck.nether.net] Im Auftrag von 
>> Tassos Chatzithomaoglou
>> Gesendet: Mittwoch, 11. Ma"rz 2009 12:25
>> An: cisco-nsp at puck.nether.net
>> Betreff: Re: [c-nsp] Sup720 crashing at RP boot - HW revision 
>> dependent ?
>>
>> Marcus, are you using the latest rommon in the SP (8.5(3)) 
>> and RP (12.2(17r)SX5)?
>>
>> 6500#remote command switch sh ver | i ROM:
>> ROM: System Bootstrap, Version 8.5(3)
>>
>> 6500#sh ver | i ROM:
>> ROM: System Bootstrap, Version 12.2(17r)SX5, RELEASE SOFTWARE (fc1)
>>
>>
>> -- 
>> Tassos
>>
>>
>> Marcus.Gerdon wrote on 11/03/2009 12:45:
>>> Hi @all,
>>>
>>> yesterday I've been hit by a somewhat strange - and 
>> possibly worrying -
>>> effect with Sup720 in 6500.
>>>
>>> I've got 3 Sup720-3BXL, one with an older HW revision (Sup: 
>> 4.4 / PFC:
>>> 1.6 / MSFC: 2.5) and 2 with newer (Sup: 5.2 / PFC: 1.8 / 
>> MSFC: 2.5). All
>>> three have been tested in a 6509 successfully by the 
>> supplier. According
>>> the test sheets they've used a Rev. 3.0 chassis.
>>>
>>> For offline testing and preparation I've an 6509 and 6506 
>> spare chassis
>>> at hands, both of them being Rev. 2.0.
>>>
>>> When trying to boot those Sup in my 6509 the older one 
>> boots fine and
>>> everything is ok. The newer ones both start to boot and 
>> after switching
>>> to boot the RP it stalls (download doesn't even start, hangs after
>>> memory is displayed). After a minute or two a 'software 
>> forced crash'
>>> occurs and I'm thrown do SP rommon.
>>>
>>> Up to this point no updates, config changes or anything other than
>>> plugging them in the chassis and turning the power on has been done.
>>>
>>> It doesn't matter if they're put in slot 5 or 6, if the 
>> working one is
>>> already active in slot 5 or if I'm manually booting from 
>> rommon instead
>>> of autoboot. Also the IOS used doesn't change anything 
>> (18SXF, 18SXI,
>>> 17SXd)
>>>
>>> Interestingly in the Rev. 2.0 6506 all three are booting 
>> fine. I've done
>>> both rom updates in the 6506 and tried again in the 6509 - 
>> without any
>>> change.
>>>
>>> To me this looks like there's some dependancy between HW 
>> revisions of
>>> the Sup or PFC (MSFC rev. is the same on all threee) and the 6509
>>> chassis (6506 wasn't effected). 
>>>
>>> I've searched cisco.com for quite some time but without any 
>> hint to this
>>> issue. The only thing I found was that there're a few 
>> 6509-NEB eeprom
>>> updates to be applied to the chassis itself. So in fact 
>> there is some
>>> active rom part with the chassis that supposedly will differ between
>>> revisions.
>>>
>>>
>>> Does someone stumbled upon this, had similar issues or 
>> maybe even know
>>> or did see any document (comp. matrix, workaround or alike) 
>> about this ?
>>>
>>>
>>> regards,
>>>
>>> Marcus
>>> _______________________________________________
>>> cisco-nsp mailing 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 link at pobox.com  Wed Mar 11 09:26:34 2009
From: link at pobox.com (Terje Bless)
Date: Wed, 11 Mar 2009 14:26:34 +0100
Subject: [c-nsp] Sup720 crashing at RP boot - HW revision dependent ?
In-Reply-To: <227142482560EF458FF1F7E784E26AB84727E8@FLBVEXCH01.versatel.local>
References: <227142482560EF458FF1F7E784E26AB84727E8@FLBVEXCH01.versatel.local>
Message-ID: <47ac005a0903110626r7fc65ea3h8e92c4e3b86869e@mail.gmail.com>

On Wed, Mar 11, 2009 at 11:45 AM, Marcus.Gerdon
<Marcus.Gerdon at versatel.de> wrote:
> When trying to boot those Sup in my 6509 the older one boots fine and
> everything is ok. The newer ones both start to boot and after switching
> to boot the RP it stalls (download doesn't even start, hangs after
> memory is displayed). After a minute or two a 'software forced crash'
> occurs and I'm thrown do SP rommon.

We saw symptoms like these in a 6509 with SupII's when we'd upgraded
the DRAM on the RP but forgotten to upgrade the DRAM on the SP
(D'oh!). The box booted the SP fine and then stalled at the point
where it would usually download the image, and then crashed. Once both
SP and RP had enough DRAM to run the IOS image the box suddenly booted
fine.

Not an identical scenario, but it might be worth checking.

-link

From jfitz at Princeton.EDU  Wed Mar 11 09:32:30 2009
From: jfitz at Princeton.EDU (Jeff Fitzwater)
Date: Wed, 11 Mar 2009 09:32:30 -0400
Subject: [c-nsp] vlan trunking problem
In-Reply-To: <49B7A7BF.3000700@euroway.hu>
References: <49B7A7BF.3000700@euroway.hu>
Message-ID: <C1727615-C70A-4FB3-8008-C188AF52842F@princeton.edu>

The mismatch in natives should work as long as you have CDP disabled  
on those ports and maybe even STP disabled for vlan 1 and 200 on both  
boxes.

What error message do you get when you have mismatched natives?

Jeff Fitzwater
OIT Network Systems
Princeton University

On Mar 11, 2009, at 7:59 AM, Hegedus Gabor wrote:

> Hi all!
>
> I have a problem:
>
> I have c2960 with vlan 200, 300, and 1 for management,
> and it connected to 861w router, but the 861w has just 2 vlan  
> allowed(vlan 1 -management, vlan 300 for second vlan).
>
> how can I "switch" the vlan200(c2960) traffic  to the vlan1(861w).
>
> I tried the native vlan but didn't work:
>
> c2960:
> interface FastEthernet0/30
> switchport trunk native vlan 200
> switchport trunk allowed vlan 200,300
> switchport mode trunk
> spanning-tree portfast
>
> 861:
> vlan 300
> interface FastEthernet0
> switchport mode trunk
>
> interface Vlan1
> ip address 192.168.1.1 255.255.255.0
> ip tcp adjust-mss 1452
>
> interface Vlan300
> ip address 192.168.2.1 255.255.255.0
>
>
> Any idea how can i resolve this problem?
>
> thank you!
> Gabor
>
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


From anderson.levi at gmail.com  Wed Mar 11 09:40:44 2009
From: anderson.levi at gmail.com (Anderson Levi)
Date: Wed, 11 Mar 2009 16:40:44 +0300
Subject: [c-nsp] ME3400
In-Reply-To: <458B3EC21E4A3044998E917199AACB2F01A6459A@GNBEX02.gnb.ca>
References: <e22d607d0903110229p2cdbad27ue7ab34963df664fa@mail.gmail.com>
	<458B3EC21E4A3044998E917199AACB2F01A6459A@GNBEX02.gnb.ca>
Message-ID: <e22d607d0903110640o6291c293nbc159ede83385971@mail.gmail.com>

Thanks, for the info everyone!


On Wed, Mar 11, 2009 at 4:17 PM, Munroe, James (DSS/MAS) <
James.Munroe at gnb.ca> wrote:

> An output from the "show sdm pref" command.
>
> The current template is "default" template.
>  The selected template optimizes the resources in
>  the switch to support this level of features for
>  8 routed interfaces and 1024 VLANs.
>
>  number of unicast mac addresses:                  5K
>  number of IPv4 IGMP groups + multicast routes:    1K
>  number of IPv4 unicast routes:                    9K
>    number of directly-connected IPv4 hosts:        5K
>    number of indirect IPv4 routes:                 4K
>  number of IPv4 policy based routing aces:         0.5K
>  number of IPv4/MAC qos aces:                      0.5K
>  number of IPv4/MAC security aces:                 1K
>
> Hope this helps...
>
> Jim
>
> -----Original Message-----
> From: Anderson Levi [mailto:anderson.levi at gmail.com]
> Sent: Wednesday, March 11, 2009 6:29 AM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] ME3400
>
> Hi,
>
> I need to find out how many routes a Cisco ME3400 can hold. Anyone with
> an idea or pointer as to where I can find out? Any help would be
> appreciated.
> Thanks.
>
>

From skeeve at skeeve.org  Wed Mar 11 09:48:00 2009
From: skeeve at skeeve.org (Skeeve Stevens)
Date: Thu, 12 Mar 2009 00:48:00 +1100
Subject: [c-nsp] Stopping VTP on a specific port
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAAN5U5OuspydJheQZRk7Gfl7CgAAAEAAAAHvKVuctX0xJmEvm9PKC6jkBAAAAAA==@skeeve.org>

Hey all,

I might have asked this ages ago... but you never know, might be worth
asking again.

We manage multiple networks which are all Ethernet connected to each other
in a Datacenter.

We don't manage some of the end networks though... and while on the middle
transiting networks I can set vtp transparent and put a password...

I would actually like to be using it.  But MetroE customers are becoming a
problem.

I can't stop two end networks using our middle network as a middleman for
VTP issues...

I would like to block any VTP traffic on a specific port.

If this doesn't make sense... let me know.



--
Skeeve Stevens, RHCE
skeeve at skeeve.org / www.skeeve.org
Cell +61 (0)414 753 383 / skype://skeeve

eintellego - skeeve at eintellego.net - www.eintellego.net 
--
I'm a groove licked love child king of the verse 
Si vis pacem, para bellum



From nicotine at warningg.com  Wed Mar 11 09:49:21 2009
From: nicotine at warningg.com (Brandon Ewing)
Date: Wed, 11 Mar 2009 08:49:21 -0500
Subject: [c-nsp] ME3400
In-Reply-To: <20090311134228.T56136@xkis.kis.ru>
References: <e22d607d0903110229p2cdbad27ue7ab34963df664fa@mail.gmail.com>
	<31371.212.142.33.197.1236764070.squirrel@www.vive-id.nl>
	<20090311134228.T56136@xkis.kis.ru>
Message-ID: <20090311134921.GL24628@biological.warningg.com>

On Wed, Mar 11, 2009 at 01:44:21PM +0300, Dmitry Valdov wrote:
> Hi!
>
> The device says 9K total (5K directly connected and  4K indirect)..
> ===
>
> #sh sdm pref
>  The current template is "default" template.
>  The selected template optimizes the resources in
>  the switch to support this level of features for
>  8 routed interfaces and 1024 VLANs.
>
>   number of unicast mac addresses:                  5K
>   number of IPv4 IGMP groups + multicast routes:    1K
>   number of IPv4 unicast routes:                    9K
>     number of directly-connected IPv4 hosts:        5K
>     number of indirect IPv4 routes:                 4K
>   number of IPv4 policy based routing aces:         0.5K
>   number of IPv4/MAC qos aces:                      0.5K
>   number of IPv4/MAC security aces:                 1K

If it's like a 3560's SDM, be careful:  A connected subnet is 4
"indirect IPv4 routes" -- it stores a CEF receive entry for the network
address, broadcast address, assigned IP, and then the CEF attach for the 
actual netblock.

And even though "directly-connected IPv4 hosts" is listed under the "unicast
routes" prefix, it isn't counting connected networks.  Each connected subnet is
a glean in the "directly-attached" section, and each IP -> ARP address is an
adjacency in the "directly-attached" section, so it's really more a
limitation on the amount of ARP entries the switch can store.

-- 
Brandon Ewing                                        (nicotine at warningg.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090311/202b9957/attachment.bin>

From jlewis at lewis.org  Wed Mar 11 10:16:49 2009
From: jlewis at lewis.org (Jon Lewis)
Date: Wed, 11 Mar 2009 10:16:49 -0400 (EDT)
Subject: [c-nsp] Stopping VTP on a specific port
In-Reply-To: <!&!AAAAAAAAAAAYAAAAAAAAAN5U5OuspydJheQZRk7Gfl7CgAAAEAAAAHvKVuctX0xJmEvm9PKC6jkBAAAAAA==@skeeve.org>
References: <!&!AAAAAAAAAAAYAAAAAAAAAN5U5OuspydJheQZRk7Gfl7CgAAAEAAAAHvKVuctX0xJmEvm9PKC6jkBAAAAAA==@skeeve.org>
Message-ID: <Pine.LNX.4.61.0903111016200.6312@soloth.lewis.org>

On Thu, 12 Mar 2009, Skeeve Stevens wrote:

> Hey all,
>
> I might have asked this ages ago... but you never know, might be worth
> asking again.

You asked about a year ago.  Did you try any of the suggestions?

http://www.gossamer-threads.com/lists/cisco/nsp/85833

----------------------------------------------------------------------
  Jon Lewis                   |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

From A.L.M.Buxey at lboro.ac.uk  Wed Mar 11 10:33:14 2009
From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk)
Date: Wed, 11 Mar 2009 14:33:14 +0000
Subject: [c-nsp] Stopping VTP on a specific port
In-Reply-To: <!&!AAAAAAAAAAAYAAAAAAAAAN5U5OuspydJheQZRk7Gfl7CgAAAEAAAAHvKVuctX0xJmEvm9PKC6jkBAAAAAA==@skeeve.org>
References: <!&!AAAAAAAAAAAYAAAAAAAAAN5U5OuspydJheQZRk7Gfl7CgAAAEAAAAHvKVuctX0xJmEvm9PKC6jkBAAAAAA==@skeeve.org>
Message-ID: <20090311143314.GA23978@lboro.ac.uk>

Hi,

> I might have asked this ages ago... but you never know, might be worth
> asking again.

not sure why you'd think that - the asnwers given back then are all valid

many options, though these 2 are trivial:

1) block the MAC address used for such packets - multicast MAC 01-00-0c-cc-cc-cc

2) set the links to switchport mode access (vtp only works over trunks)

alan

From petelists at templin.org  Wed Mar 11 10:38:12 2009
From: petelists at templin.org (Pete Templin)
Date: Wed, 11 Mar 2009 09:38:12 -0500
Subject: [c-nsp] BGP Route Selection
In-Reply-To: <56F211C5E3F24F47B103EA1B253822BE03654C54@vic-cr-ex1.staff.netspace.net.au>
References: <56F211C5E3F24F47B103EA1B253822BE03654C54@vic-cr-ex1.staff.netspace.net.au>
Message-ID: <49B7CCD4.1000702@templin.org>

Andy Saykao wrote:
> Hi All,
>  
> Just trying to get my head around why BGP prefers a certain route over
> others in my example below. I've read up on how BGP makes it's path
> selection decision but I can't follow why it hasn't chosen a route with
> a higher local preferences.

To rehash what Oliver said, you and the router ignore the 
(received-only) routes when choosing a best path.  The (received-only) 
shows you the routes received from (soft-reconfig-enabled) neighbors in 
the exact form received, in other words before your inbound route-map is 
applied to those routes.

pt


From dan at beanfield.com  Wed Mar 11 09:41:39 2009
From: dan at beanfield.com (Dan Armstrong)
Date: Wed, 11 Mar 2009 09:41:39 -0400
Subject: [c-nsp] ME3400
In-Reply-To: <e22d607d0903110229p2cdbad27ue7ab34963df664fa@mail.gmail.com>
References: <e22d607d0903110229p2cdbad27ue7ab34963df664fa@mail.gmail.com>
Message-ID: <6C016A4A-CA92-40A1-84C0-CCC9D2BFE4F8@beanfield.com>

Nowhere near a full table. :-)

Our busiest ME3400 has about 10,000 OSPF routes in it, and doesn't  
break a sweat.  Without doing any math, I wouldn't put any more than  
that in there though.




On 11-Mar-09, at 5:29 AM, Anderson Levi wrote:

> Hi,
>
> I need to find out how many routes a Cisco ME3400 can hold. Anyone  
> with an
> idea or pointer as to where I can find out? Any help would be  
> appreciated.
> Thanks.
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


From petelists at templin.org  Wed Mar 11 10:43:58 2009
From: petelists at templin.org (Pete Templin)
Date: Wed, 11 Mar 2009 09:43:58 -0500
Subject: [c-nsp] 7500 Channelized DS3 Issues
In-Reply-To: <1236728984.8428.8.camel@booger>
References: <1236728984.8428.8.camel@booger>
Message-ID: <49B7CE2E.7060005@templin.org>

Todd Shipway wrote:

> DS3 card is divided into multiple T1 interfaces.  All interfaces have
> been running without problems for weeks.  Last week 1 interface went
> down, and when it came back up, no traffic will go across the interface.
> The int shows as up/up, manually setting a route doesn't help anything.
> Copying the int config to a different channel on the same card fixes the
> issue and traffic is back to normal.
> 
> Today, we had 2 interfaces that were part of a multilink ppp interface
> go down and right back up.  All interfaces were up/up including the
> MLPPP interface.  Moving them to different channels resulted in the same
> issue.  Moving 1 T1 to a Multi-channel T1 card and keeping the other T1
> on the channelized DS3 allowed the multilink interface to come up and
> traffic went back to normal. 

Usual questions first: what chassis, what RSP, what IPs/VIPs/PAs, 
particularly for the DS3 work, what IOS, and why have you selected that IOS?

I had odd problems with 7507/RSP4+RSP4/VIP2-50+PA-FE-TX/VIP2-50+PA-FE-TX 
VIP2-50+PA-MC-2T3+ boxes on IOS 12.0(27)S1 back in the day.  "Something" 
would happen, and one T3 port would stop passing traffic.  RMA on the 
PA-MC-2T3 helped, but 12.0(27)S3 made all the difference (and 12.0(27)S5 
has been even better).  We chose 12.0(27)S back then as it was perhaps 
the newest 12.0S at the time and seemed to have the general following 
for CT3 work.  We've tried 12.0(31)S (for various rebuilds of that S) 
with very poor success on Ethernet work, and have left 12.0(27)S5 in 
place for CT3s ever since.  It's as close to "set and let" as we've ever 
seen with 7507s.

Pete

From skeeve at skeeve.org  Wed Mar 11 11:07:28 2009
From: skeeve at skeeve.org (Skeeve Stevens)
Date: Thu, 12 Mar 2009 02:07:28 +1100
Subject: [c-nsp] Stopping VTP on a specific port
In-Reply-To: <Pine.LNX.4.61.0903111016200.6312@soloth.lewis.org>
References: <!&!AAAAAAAAAAAYAAAAAAAAAN5U5OuspydJheQZRk7Gfl7CgAAAEAAAAHvKVuctX0xJmEvm9PKC6jkBAAAAAA==@skeeve.org>
	<Pine.LNX.4.61.0903111016200.6312@soloth.lewis.org>
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAAN5U5OuspydJheQZRk7Gfl7CgAAAEAAAAM3QUoN4LV9Kt1bQ42F5XDoBAAAAAA==@skeeve.org>

Hey Jon,

1) They are trunk ports and must be trunk ports
2) I actually like CDP... very useful in diagnosing issues with customers
3) Doesn't stop being used as an bridge between two networks
4) hmmmm does just changing the native vlan on a trunk stop VTP by any
chance?

...Skeeve

-----Original Message-----
From: Jon Lewis [mailto:jlewis at lewis.org] 
Sent: Thursday, 12 March 2009 1:17 AM
To: Skeeve Stevens
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Stopping VTP on a specific port

On Thu, 12 Mar 2009, Skeeve Stevens wrote:

> Hey all,
>
> I might have asked this ages ago... but you never know, might be worth
> asking again.

You asked about a year ago.  Did you try any of the suggestions?

http://www.gossamer-threads.com/lists/cisco/nsp/85833

----------------------------------------------------------------------
  Jon Lewis                   |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________


From skeeve at skeeve.org  Wed Mar 11 11:08:38 2009
From: skeeve at skeeve.org (Skeeve Stevens)
Date: Thu, 12 Mar 2009 02:08:38 +1100
Subject: [c-nsp] Stopping VTP on a specific port
In-Reply-To: <20090311143314.GA23978@lboro.ac.uk>
References: <!&!AAAAAAAAAAAYAAAAAAAAAN5U5OuspydJheQZRk7Gfl7CgAAAEAAAAHvKVuctX0xJmEvm9PKC6jkBAAAAAA==@skeeve.org>
	<20090311143314.GA23978@lboro.ac.uk>
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAAN5U5OuspydJheQZRk7Gfl7CgAAAEAAAANoJ8wLuxZ9Jr7e0a69IM3kBAAAAAA==@skeeve.org>

Needs to be trunk... How do I block the MAC on a trunk? Is that possible?

-----Original Message-----
From: A.L.M.Buxey at lboro.ac.uk [mailto:A.L.M.Buxey at lboro.ac.uk] 
Sent: Thursday, 12 March 2009 1:33 AM
To: Skeeve Stevens
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Stopping VTP on a specific port

Hi,

> I might have asked this ages ago... but you never know, might be worth
> asking again.

not sure why you'd think that - the asnwers given back then are all valid

many options, though these 2 are trivial:

1) block the MAC address used for such packets - multicast MAC
01-00-0c-cc-cc-cc

2) set the links to switchport mode access (vtp only works over trunks)

alan


From psirt at cisco.com  Wed Mar 11 11:40:00 2009
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Wednesday, 11 March 2009 10:40:00 -0500 
Subject: [c-nsp] Cisco Security Advisory: Cisco Unified Communications
	Manager IP Phone Personal Address Book Synchronizer Privilege
	Escalation Vulnerability
Message-ID: <200903111040.cucmpab@psirt.cisco.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cisco Security Advisory: Cisco Unified Communications Manager IP
Phone Personal Address Book Synchronizer Privilege Escalation
Vulnerability

Advisory ID: cisco-sa-20090311-cucmpab

Revision 1.0

For Public Release 2009 March 11 1600 UTC (GMT)

+---------------------------------------------------------------------

Summary
=======

Cisco Unified Communications Manager, formerly CallManager, contains
a privilege escalation vulnerability in the IP Phone Personal Address
Book (PAB) Synchronizer feature that may allow an attacker to gain
complete administrative access to a vulnerable Cisco Unified
Communications Manager system. If Cisco Unified Communications
Manager is integrated with an external directory service, it may be
possible for an attacker to leverage the privilege escalation
vulnerability to gain access to additional systems configured to use
the directory service for authentication.

Cisco has released free software updates that address this
vulnerability. Workarounds that mitigate this vulnerability are
available.

This advisory is posted at:

http://www.cisco.com/warp/public/707/cisco-sa-20090311-cucmpab.shtml

Affected Products
=================

Vulnerable Products
+------------------

The following products are vulnerable:

  * Cisco Unified CallManager 4.1 versions
  * Cisco Unified Communications Manager 4.2 versions prior to 4.2(3)SR4b
  * Cisco Unified Communications Manager 4.3 versions prior to 4.3(2)SR1b
  * Cisco Unified Communications Manager 5.x versions prior to 5.1(3e)
  * Cisco Unified Communications Manager 6.x versions prior to 6.1(3)
  * Cisco Unified Communications Manager 7.0 versions prior to 7.0(2)

Administrators of systems that are running Cisco Unified
Communications Manager software version 4.x can determine the
software version by navigating to Help > About Cisco Unified
CallManager and selecting the Details button via the Cisco Unified
Communications Manager administration interface.

Administrators of systems that are running Cisco Unified
Communications Manager software versions 5.x, 6.x, and 7.x can
determine the software version by viewing the main page of the Cisco
Unified Communications Manager administration interface. The software
version can also be determined by running the command show version
active via the command line interface (CLI).

Products Confirmed Not Vulnerable
+--------------------------------

Cisco Unified Communications Manager Express is not affected by this
vulnerability. No other Cisco products are currently known to be
affected by this vulnerability.

Details
=======

The Cisco IP Phone Personal Address Book (PAB) Synchronizer feature
of Cisco Unified Communications Manager allows users to keep their
Cisco Unified Communications Manager address book synchronized with
their Microsoft Windows address book. The IP Phone PAB Synchronizer
feature contains a privilege escalation vulnerability that may allow
an attacker to obtain complete administrative access to a vulnerable
Cisco Unified Communications Manager system. After an IP Phone PAB
Synchronizer client successfully authenticates to a Cisco Unified
Communications Manager device over a HTTPS connection, the Cisco
Unified Communications Manager returns credentials for a user account
that is used to manage the Cisco Unified Communications Manager
directory service. If an attacker is able to intercept the
credentials, they can perform unauthorized modifications to the Cisco
Unified Communications Manager configuration and extend their
privileges. The IP Phone PAB Synchronizer client has been redesigned
to allow address book synchronization without requiring the directory
service credentials. This vulnerability does not allow an attacker to
gain access to the underlying platform operating system of any Cisco
Unified Communications Manager system.

Cisco Unified Communications Manager 4.x
+---------------------------------------

Cisco Unified Communications Manager software version 4.x by default
stores user information using an internal Lightweight Directory
Access Protocol (LDAP) server called DC Directory. After an IP Phone
PAB Synchronizer client successfully authenticates, the Cisco Unified
Communications Manager returns credentials for the DC Directory user
that will be used by the client to synchronize a user's address book.
Depending on how a Cisco Unified Communications Manager is
configured, an attacker may obtain different privilege levels using
the intercepted credentials.

By default, Cisco Unified Communications Manager software version 4.x
administrator accounts are created as part of an underlying Microsoft
Windows operating system. Cisco Unified Communications Manager is
commonly deployed using the Multi-Level Administration (MLA) feature
to ease the integration of Cisco Unified Communications Manager into
enterprise environments. If MLA is enabled, Cisco Unified
Communications Manager stores administrator accounts in the Cisco
Unified Communications Manager DC Directory service. If an attacker
obtains the DC Directory credentials and MLA is enabled, the attacker
can add an existing account to the Cisco Unified Communications
Manager super-user group. The attacker can then access the Cisco
Unified Communications Manager management interface with complete
administrative access. If MLA is not enabled, the attacker cannot
escalate their privileges; however, they can modify any user settings
in the directory.

The Cisco Unified Communications Manager 4.x IP Phone PAB
Synchronizer client uses an unencrypted LDAP connection to perform
address book synchronization. The DC Directory credentials are passed
in the clear over the network and are vulnerable to being sniffed by
an attacker. If using the DC Directory internal LDAP server, the IP
Phone PAB Synchronizer client communicates to Cisco Unified
Communications Manager on TCP ports 8404 and 8405.

Cisco Unified Communications Manager 5.x, 6.x, 7.x
+-------------------------------------------------

Cisco Unified Communications Manager software versions 5.x, 6.x, and
7.x store user information as a part of the internal Cisco Unified
Communications Manager configuration database. The IP Phone PAB
Synchronizer client uses the AXL application programming interface
(API) to perform address book synchronization. After a client
successfully authenticates, the Cisco Unified Communications Manager
returns credentials for a database user account named TabSyncSysUser
that will be used by the client to synchronize an user's address
book. The TabSyncSysUser account has full read and write privileges
to the Cisco Unified Communications Manager configuration database.
Using the TabSyncSysUser credentials via the AXL API, an attacker can
modify any parameter in the database including creating new
administrator accounts.

Directory Service Integration
+----------------------------

Cisco Unified Communications Manager software versions 4.x, 5.x, 6.x,
and 7.x can be integrated with Microsoft Active Directory and several
non-Microsoft LDAP servers to perform user authentication. In order
to function properly, the integration process requires that
appropriate user credentials for the directory service are provided
to Cisco Unified Communications Manager. If an attacker intercepts or
sniffs the directory service credentials returned by a Cisco Unified
Communications Manager responding to an IP Phone PAB Synchronizer
client, the attacker may be able to leverage the credentials to gain
access to additional systems configured to use the directory service
for authentication.

Administrators should ensure that any directory service credentials
used for the Cisco Unified Communications Manager integration process
are configured to follow the principle of least privilege. The
credentials should be configured with only the privileges necessary
to access the directory service data needed for the integration
process to function properly. The use of overly privileged
administrator accounts is discouraged. Please see the Workarounds
section for more information on performing the integration of Cisco
Unified Communications Manager with AD using the least privilege
concept.

This vulnerability is documented in Cisco Bug IDs CSCso76587 and
CSCso78528 and has been assigned Common Vulnerabilities and Exposures
(CVE) identifier CVE-2009-0632.

Vulnerability Scoring Details
=============================

Cisco has provided scores for the vulnerability in this advisory
based on the Common Vulnerability Scoring System (CVSS). The CVSS
scoring in this Security Advisory is done in accordance with CVSS
version 2.0.

CVSS is a standards-based scoring method that conveys vulnerability
severity and helps determine urgency and priority of response.

Cisco has provided a base and temporal score. Customers can then
compute environmental scores to assist in determining the impact of
the vulnerability in individual networks.

Cisco has provided an FAQ to answer additional questions regarding
CVSS at:

http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html

Cisco has also provided a CVSS calculator to help compute the
environmental impact for individual networks at:

http://intellishield.cisco.com/security/alertmanager/cvss

CSCso76587 - Directory Manager password sent in clear from client

CVSS Base Score - 9

Access Vector           - Network
Access Complexity       - Low
Authentication          - Single
Confidentiality Impact  - Complete
Integrity Impact        - Complete
Availability Impact     - Complete

CVSS Temporal Score - 7.4

Exploitability          - Functional
Remediation Level       - Official-Fix
Report Confidence       - Confirmed

CSCso78528 - TabSyncSysUser (axl user) password sent in clear from client

CVSS Base Score - 9

Access Vector           - Network
Access Complexity       - Low
Authentication          - Single
Confidentiality Impact  - Complete
Integrity Impact        - Complete
Availability Impact     - Complete

CVSS Temporal Score - 7.4

Exploitability          - Functional
Remediation Level       - Official-Fix
Report Confidence       - Confirmed

Impact
======

Successful exploitation of this vulnerability may allow an attacker
to intercept user credentials that allow the attacker to escalate
their privilege level and obtain complete administrative access to a
vulnerable Cisco Unified Communications Manager system. If integrated
with an external directory service, the intercepted user credentials
may allow an attacker to gain access to additional systems configured
to use the directory service for authentication.

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 Unified Communications Manager software version 4.2(3)SR4b
contains the fix for this vulnerability. Administrators of Cisco
Unified CallManager software version 4.1 systems are encouraged to
upgrade to Cisco Unified Communications Manager software version 4.2
(3)SR4b in order to obtain fixed software. Version 4.2(3)SR4b can be
downloaded at the following link:

http://tools.cisco.com/support/downloads/go/PlatformList.x?sftType=Unified%20Communications%20Manager%20Updates&mdfid=280264388&treeName=Voice%20and%20Unified%20Communications&mdfLevel=Software%20Version/Option&url=null&modelName=Cisco%20Unified%20CallManager%20Version%204.2&isPlatform=N&treeMdfId=278875240&modifmdfid=null&imname=null&hybrid=Y&imst=N

Cisco Unified Communications Manager software version 4.3(2)SR1b
contains the fix for this vulnerability. Version 4.3(2)SR1b can be
downloaded at the following link:

http://tools.cisco.com/support/downloads/go/PlatformList.x?sftType=Unified%20Communications%20Manager%20Updates&mdfid=280771554&treeName=Voice%20and%20Unified%20Communications&mdfLevel=Software%20Version/Option&url=null&modelName=Cisco%20Unified%20Communications%20Manager%20Version%204.3&isPlatform=N&treeMdfId=278875240&modifmdfid=null&imname=null&hybrid=Y&imst=N

Cisco Unified Communications Manager software version 5.1(3e)
contains the fix for this vulnerability. Version 5.1(3e) can be
downloaded at the following link:

http://tools.cisco.com/support/downloads/go/ReleaseType.x?optPlat=null&isPlatform=Y&mdfid=280735907&sftType=Unified%20Communications%20Manager%20Updates&treeName=Voice%20and%20Unified%20Communications&modelName=Cisco%20Unified%20Communications%20Manager%20Version%205.1&mdfLevel=Software%20Version/Option&treeMdfId=278875240&modifmdfid=null&imname=null&hybrid=Y&imst=N

Cisco Unified Communications Manager software version 6.1(3) contains
the fix for this vulnerability. Version 6.1(3) can be downloaded at
the following link:

http://tools.cisco.com/support/downloads/go/PlatformList.x?sftType=Unified%20Communications%20Manager%20Updates&mdfid=281023410&treeName=Voice%20and%20Unified%20Communications&mdfLevel=Software%20Version/Option&url=null&modelName=Cisco%20Unified%20Communications%20Manager%20Version%206.1&isPlatform=N&treeMdfId=278875240&modifmdfid=null&imname=null&hybrid=Y&imst=N

Cisco Unified Communications Manager software version 7.0(2) contains
the fix for this vulnerability. Version 7.0(2) can be downloaded at
the following link:

http://tools.cisco.com/support/downloads/go/ReleaseType.x?optPlat=&isPlatform=Y&mdfid=281941895&sftType=Unified+Communications+Manager+Updates&treeName=Voice+and+Unified+Communications&modelName=Cisco+Unified+Communications+Manager+Version+7.0&mdfLevel=Software%20Version/Option&treeMdfId=278875240&modifmdfid=null&imname=&hybrid=Y&imst=N

Workarounds
===========

It is possible to mitigate against this vulnerability using the
following workarounds.

Cisco Unified Communications Manager 4.x
+---------------------------------------

It is possible to mitigate this vulnerability by moving the ASP
script that IP Phone Personal Address Book (PAB) Scynchronizer
clients interact with to a directory location that is not accessible
to the Cisco Unified Communications Manager web server. The system
drive where the ASP script resides depends on how Cisco Unified
Communications Manager was installed. Employing this workaround will
prevent address book synchronization; however, the PAB application
will continue to function. The ASP script can be moved using the
following command:

    C:\> move c:\CiscoWebs\User\LDAPDetails.asp c:\temp

It is also possible to mitigate this vulnerability by implementing
filtering on screening devices or using the Windows firewall.
Administrators are advised to permit access to TCP ports 8404 and
8405 only from trusted networks.

Cisco Unified Communications Manager 5.x, 6.x, 7.x
+-------------------------------------------------

It is possible to mitigate this vulnerability by restricting the
permissions of the TabSyncSysUser database user account. In the Cisco
Unified Communications Manager Administration interface, navigate to 
User Management > Application User and search for the TabSyncSysUser
account. Remove all groups from the account and change the password.
Employing this workaround will prevent address book synchronization;
however, the PAB application will continue to function.

Active Directory Integration
+---------------------------

To improve the security of Cisco Unified Communications Manager
integration with Active Directory (AD), Cisco has produced a
whitepaper that provides a detailed explanation of how to perform
Cisco Unified Communications Manager integration with AD using the
least-privileged principle. The whitepaper can be downloaded here:

http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_tech_note09186a0080a83435.shtml

Additional mitigation techniques that can be deployed on Cisco
devices within the network are available in the Cisco Applied
Mitigation Bulletin companion document for this advisory:

http://www.cisco.com/warp/public/707/cisco-amb-20090311-cucmpab.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/products/prod_warranties_item09186a008088e31f.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 vulnerability in Cisco Unified Communications Manager 4.x
software versions was reported to Cisco by Olivier Grosjeanne of
Dimension Data France. The vulnerability in Cisco Unified
Communications Manager 5.x, 6.x and 7.x software versions was
reported by Oliver Dewdney of LBI.

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-20090311-cucmpab.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-March-11 | 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-----
Version: GnuPG v1.4.5 (SunOS)

iD8DBQFJt9DF86n/Gc8U/uARAtjqAJ9eE9ETbc4lyUJV8GrCEmiaJeS1NACdExbB
dLmiSiaPCdGHpVKTKvZj78k=
=C3h7
-----END PGP SIGNATURE-----

From A.L.M.Buxey at lboro.ac.uk  Wed Mar 11 12:25:31 2009
From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk)
Date: Wed, 11 Mar 2009 16:25:31 +0000
Subject: [c-nsp] Stopping VTP on a specific port
In-Reply-To: <!&!AAAAAAAAAAAYAAAAAAAAAN5U5OuspydJheQZRk7Gfl7CgAAAEAAAANoJ8wLuxZ9Jr7e0a69IM3kBAAAAAA==@skeeve.org>
References: <!&!AAAAAAAAAAAYAAAAAAAAAN5U5OuspydJheQZRk7Gfl7CgAAAEAAAAHvKVuctX0xJmEvm9PKC6jkBAAAAAA==@skeeve.org>
	<20090311143314.GA23978@lboro.ac.uk>
	<!&!AAAAAAAAAAAYAAAAAAAAAN5U5OuspydJheQZRk7Gfl7CgAAAEAAAANoJ8wLuxZ9Jr7e0a69IM3kBAAAAAA==@skeeve.org>
Message-ID: <20090311162531.GB24260@lboro.ac.uk>

Hi,
> Needs to be trunk... How do I block the MAC on a trunk? Is that possible?

regarding port ACLs (of which MAC ACLs are one of:

to quote cisco press "When applied to a trunk port, the ACL filters traffic on all VLANs present on the trunk port. When applied to a port with voice VLAN, the ACL filters traffic on both data and voice VLANs"

http://www.ciscopress.com/articles/article.asp?p=1181682&seqNum=4

alan

From justin at justinshore.com  Wed Mar 11 12:25:48 2009
From: justin at justinshore.com (Justin Shore)
Date: Wed, 11 Mar 2009 11:25:48 -0500
Subject: [c-nsp] Stopping VTP on a specific port
In-Reply-To: <!&!AAAAAAAAAAAYAAAAAAAAAN5U5OuspydJheQZRk7Gfl7CgAAAEAAAAHvKVuctX0xJmEvm9PKC6jkBAAAAAA==@skeeve.org>
References: <!&!AAAAAAAAAAAYAAAAAAAAAN5U5OuspydJheQZRk7Gfl7CgAAAEAAAAHvKVuctX0xJmEvm9PKC6jkBAAAAAA==@skeeve.org>
Message-ID: <49B7E60C.2090409@justinshore.com>

Skeeve Stevens wrote:
> We don't manage some of the end networks though... and while on the middle
> transiting networks I can set vtp transparent and put a password...
> 
> I would actually like to be using it.  But MetroE customers are becoming a
> problem.
> 
> I can't stop two end networks using our middle network as a middleman for
> VTP issues...
> 
> I would like to block any VTP traffic on a specific port.

Would a L2TP tunnel be appropriate here?  If the customers want to use 
VTP and you want to use VTP (why is anyone's guess!) but not mix them 
then the only way I know of doing this would be a L2TP tunnel so that 
you ignore their VTP messages and tunnel them to the far side.

http://www.cisco.com/warp/public/cc/pd/si/casi/ca6000/prodlit/65met_wp.htm#wp40056

Justin


From ardabalkanay at gmail.com  Wed Mar 11 12:33:19 2009
From: ardabalkanay at gmail.com (Arda Balkanay)
Date: Wed, 11 Mar 2009 18:33:19 +0200
Subject: [c-nsp] Stopping VTP on a specific port
In-Reply-To: <20090311162531.GB24260@lboro.ac.uk>
References: <!&!AAAAAAAAAAAYAAAAAAAAAN5U5OuspydJheQZRk7Gfl7CgAAAEAAAAHvKVuctX0xJmEvm9PKC6jkBAAAAAA==@skeeve.org>
	<20090311143314.GA23978@lboro.ac.uk>
	<!&!AAAAAAAAAAAYAAAAAAAAAN5U5OuspydJheQZRk7Gfl7CgAAAEAAAANoJ8wLuxZ9Jr7e0a69IM3kBAAAAAA==@skeeve.org>
	<20090311162531.GB24260@lboro.ac.uk>
Message-ID: <9af987420903110933y74e22e7bs746308861a084028@mail.gmail.com>

hi ,
does QinQ make sense ?
make switchport mode dot1q tunnel and assign a vlan (access vlan X as outer
vlan) and disable l2protocol tunnelling (to not carry cdp, stp like
information at customer vlans, you may also partially block l2 protocols)
if you are at the middle of a L2 point to point service QinQ can make sense
this way.
If you are terminating vlans which comes via trunk of customer you will need
special hardware (like 7600 and ES20 or SIP400) to terminate QinQ at ip
interface.


On Wed, Mar 11, 2009 at 6:25 PM, <A.L.M.Buxey at lboro.ac.uk> wrote:

> Hi,
> > Needs to be trunk... How do I block the MAC on a trunk? Is that possible?
>
> regarding port ACLs (of which MAC ACLs are one of:
>
> to quote cisco press "When applied to a trunk port, the ACL filters traffic
> on all VLANs present on the trunk port. When applied to a port with voice
> VLAN, the ACL filters traffic on both data and voice VLANs"
>
> http://www.ciscopress.com/articles/article.asp?p=1181682&seqNum=4
>
> 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 Mar 11 13:47:06 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Wed, 11 Mar 2009 18:47:06 +0100
Subject: [c-nsp] FWSM HA secondary reload & long downtime
In-Reply-To: <Pine.LNX.4.64.0903111101340.21155@zippy.stdio.be>
References: <1236633344.3572.13.camel@localhost.localdomain>
	<Pine.LNX.4.64.0903101125050.6781@zippy.stdio.be>
	<1236719408.4513.51.camel@localhost.localdomain>
	<Pine.LNX.4.64.0903111101340.21155@zippy.stdio.be>
Message-ID: <1236793626.3563.339.camel@localhost.localdomain>

On Wed, 2009-03-11 at 11:16 +0100, Andrew Yourtchenko wrote:
> > So the contexts weren't really activated (with "Up" interfaces)
> > during all the downtime, just at the end. To me that seems to
> > suggest that it's not just simply that it "steals" the traffic for
> > the interfaces.
> 
> Right. That was why I was wondering whether indeed "all" (as in 
> "absolutely all, i swear" :) the traffic was affected, or only some part 
> of it, and with what timing. Also interesting thing to check if the 
> existing TCP connections continue to run ok (so then the problem area 
> could be isolated to session path and up). Of course, in the real-world 
> scenario there's frequently simply not enough time to look at those 
> details, but they might be definitely helpful.

Hmm... I have discovered that my original analysis was flawed. I knew
TCP sessions without activity survived this, among others a couple of
SSH sessions I had going through two of the contexts to test exactly
this. I had setup a ping job (200 ms interval) between two hosts for
traffic crossing two contexts. This job lost 509 packets during the
downtime, and I assumed this meant that the total time-to-recover for
the system was ~100 seconds.

This conclusion was not right though; assumption bit me again. :-D

I have looked at the log-files in a more thorough and systematic
fashion, and actually it was only traffic through one context that was
impacted. All the contexts, including the impacted one, have logged
continuously with no problems. When I saw SYN Timeouts on the others
contexts too it was always for connections coming from the one with
problems.

This of course points to something else being the problem, not the FWSM.
Or at least that it is something concerning the context, not the
hardware or system configuration.

The switch housing the FWSM logged some things during the bootup, but
only the usual stuff and only before the break:

Mar  9 16:37:00.303: %C6KPWR-SP-4-DISABLED: power to module in slot 2 set off (Reset)
Mar  9 16:39:01.552: %PM_SCP-SP-4-UNK_OPCODE: Received unknown unsolicited message from module 2, opcode 0x330
Mar  9 16:39:02.572: %DIAG-SP-6-RUN_MINIMUM: Module 2: Running Minimum Online Diagnostics...
Mar  9 16:39:04.624: %DIAG-SP-6-DIAG_OK: Module 2: Passed Online Diagnostics
Mar  9 16:39:05.076: %OIR-SP-6-INSCARD: Card inserted in slot 2, interfaces are now online
Mar  9 16:39:12.079: %PM_SCP-SP-4-UNK_OPCODE: Received unknown unsolicited message from module 2, opcode 0x330
Mar  9 16:39:22.579: %PM_SCP-SP-4-UNK_OPCODE: Received unknown unsolicited message from module 2, opcode 0x330

The break was just around 16:40:10. Nothing in those messages make me
concerned.

I think we'll let it rest here. It was a much lower impact than we
thought, so no biggie.

And Andrew: Thank you very much for your input. :-)

Regards,
Peter





From ayourtch at cisco.com  Wed Mar 11 14:14:10 2009
From: ayourtch at cisco.com (Andrew Yourtchenko)
Date: Wed, 11 Mar 2009 19:14:10 +0100 (CET)
Subject: [c-nsp] FWSM HA secondary reload & long downtime
In-Reply-To: <1236793626.3563.339.camel@localhost.localdomain>
References: <1236633344.3572.13.camel@localhost.localdomain> 
	<Pine.LNX.4.64.0903101125050.6781@zippy.stdio.be> 
	<1236719408.4513.51.camel@localhost.localdomain> 
	<Pine.LNX.4.64.0903111101340.21155@zippy.stdio.be>
	<1236793626.3563.339.camel@localhost.localdomain>
Message-ID: <Pine.LNX.4.64.0903111901550.21155@zippy.stdio.be>



On Wed, 11 Mar 2009, Peter Rathlev wrote:

> Hmm... I have discovered that my original analysis was flawed. I knew
> TCP sessions without activity survived this, among others a couple of

hmm, so "no traffic during the problem" = "survival"... for those sessions 
that died in the process, would be interesting to see the reason in the 
syslog. If it's "reset-I" or "reset-O" at the time of sync, then the next 
step would be to look in more detail where and how the reset comes from. 
Iterative PCAP.

> SSH sessions I had going through two of the contexts to test exactly
> this. I had setup a ping job (200 ms interval) between two hosts for
> traffic crossing two contexts. This job lost 509 packets during the
> downtime, and I assumed this meant that the total time-to-recover for
> the system was ~100 seconds.
>
> This conclusion was not right though; assumption bit me again. :-D
>
> I have looked at the log-files in a more thorough and systematic
> fashion, and actually it was only traffic through one context that was
> impacted. All the contexts, including the impacted one, have logged
> continuously with no problems. When I saw SYN Timeouts on the others
> contexts too it was always for connections coming from the one with
> problems.

ahha. "Never assume anything unless you have hard proof" is a good rule 
of thumb that helps a lot. Though of course the reality dictates the 
probabilistic shortcuts at times.

>
> This of course points to something else being the problem, not the FWSM.

*bling* too strong of an assumption :).

I'd not discard it right away, but from the practical standpoint the fact 
that some contexts survive the replication just fine and it is only one 
that has an issue, gives a very good jumpstart to look for differences 
between the problematic context and the others - configuration, topology, 
traffic volumes, anything. The good point is that this is a non-intrusive 
(although a bit time-consuming) exercise.

> Or at least that it is something concerning the context, not the
> hardware or system configuration.

yup, with this I totally agree.

>
> The switch housing the FWSM logged some things during the bootup, but
> only the usual stuff and only before the break:
>
> Mar  9 16:37:00.303: %C6KPWR-SP-4-DISABLED: power to module in slot 2 set off (Reset)
> Mar  9 16:39:01.552: %PM_SCP-SP-4-UNK_OPCODE: Received unknown unsolicited message from module 2, opcode 0x330
> Mar  9 16:39:02.572: %DIAG-SP-6-RUN_MINIMUM: Module 2: Running Minimum Online Diagnostics...
> Mar  9 16:39:04.624: %DIAG-SP-6-DIAG_OK: Module 2: Passed Online Diagnostics
> Mar  9 16:39:05.076: %OIR-SP-6-INSCARD: Card inserted in slot 2, interfaces are now online
> Mar  9 16:39:12.079: %PM_SCP-SP-4-UNK_OPCODE: Received unknown unsolicited message from module 2, opcode 0x330
> Mar  9 16:39:22.579: %PM_SCP-SP-4-UNK_OPCODE: Received unknown unsolicited message from module 2, opcode 0x330
>
> The break was just around 16:40:10. Nothing in those messages make me
> concerned.

+1

>
> I think we'll let it rest here. It was a much lower impact than we
> thought, so no biggie.
>

Indeed - though still would be good to nail it down. The latent problems 
are worse in a sense that they usually pop up at the worst possible times 
in combination with something else, and complicate the life a lot. It's 
like walking on the rails is practically not a huge issue, and a 
high-speed train passing by is not of an issue, but combined the two 
events are highly undesirable :)

> And Andrew: Thank you very much for your input. :-)

My pleasure :)

cheers,
andrew

From lowen at pari.edu  Wed Mar 11 17:20:47 2009
From: lowen at pari.edu (Lamar Owen)
Date: Wed, 11 Mar 2009 17:20:47 -0400
Subject: [c-nsp] Tracking connection resets on a 7500 trunking GEIP+
Message-ID: <200903111720.47935.lowen@pari.edu>

Ok, I'm having an odd difficulty, and am trying to determine how to go about 
troubleshooting it.

I have two routers at my border, a 7401ASR and a 7507/RSP8, both running 12.4 
mainline.  The two routers are both running iBGP to each other and eBGP to my 
provider.  The two routers are providing HSRP to a server subnet, an APS-
protected OC3 POS WAN link, and Stateful NAT with several static entries and a 
dynamic pool.  CBAC is in use, and the ACL isn't terribly long.

The two routers connect to both the server farm and the ISP through two Gige 
trunks to a Catalyst 5505 switch, using two SupIIIG's for the GigE-LX trunks 
and a WS-X5225R 24 port 10/100 blade to connect to the ISP through a pair of 
ports on two VLANs, and to the server farm through other VLANs.

While the 7401 (the APS protect) is active on the OC3 and set as active for 
HSRP, everything works as it should.  When the 7507 is doing this duty, some 
websites become deathly slow, to the point of showing 'connection reset by 
peer' errors.

I'm looking for just a pointer or two as to how to trace this issue and narrow 
down to the port on the Cat5505 SupIIIG, the two GBIC's, the fiber path, the 
GEIP+ on the 7507, or maybe even the RSP8 on the 7507.  I do see a very few 
framing errors on the GigE between the GEIP+ and the SupIIIG, but they are 
very few and far between.

So any pointer (except 'upgrade your hardware') is desired.  I would love to 
upgrade, but, in this economy?

The best idea I've had yet is to remove the 7401, replace with another known 
good 7507 that I have, drop to 12.0S, and do my NAT and firewalling on this end 
of the OC3 with a single or dual 7401ASR setup (using hardware I have at my 
disposal).  Then I'll use GRE tunnels to the RSFC's on the two SupIIIG's to 
get to the server farm at that end.

From david at hughes.com.au  Wed Mar 11 18:59:17 2009
From: david at hughes.com.au (David Hughes)
Date: Thu, 12 Mar 2009 08:59:17 +1000
Subject: [c-nsp] Etherchannel guard vs. mstp
In-Reply-To: <49B65F91.8000807@cooler.hu>
References: <49B65F91.8000807@cooler.hu>
Message-ID: <624DA659-C8A9-4503-A1B2-E7497037ECF0@hughes.com.au>


We are running etherchannel on 6500s with MST all over the place.   
Shouldn't be a problem.  Also swapping from RPVST+ to MST without a  
reload should not be a problem (did it many times when we migrated to  
MST).

Please post your physical interface and portchannel interface configs  
from both ends of the bundle that isn't working.


Thanks

David
...

On 10/03/2009, at 10:39 PM, Nemeth Laszlo wrote:

> \The first router was the Router A. It changed without problem.
> But when i sent the "spanning-tree mode mstp" to Router B it put  
> down the 4x10G Etherchannel link with Router A and logged it:
>
> Mar  9 16:04:57.669 MET: %PM-SP-STDBY-4-ERR_DISABLE: channel- 
> misconfig error detected on Te1/3, putting Te1/3 in err-disable state
> Mar  9 16:04:57.677 MET: %PM-SP-STDBY-4-ERR_DISABLE: channel- 
> misconfig error detected on Te1/4, putting Te1/4 in err-disable state
> Mar  9 16:04:57.685 MET: %PM-SP-STDBY-4-ERR_DISABLE: channel- 
> misconfig error detected on Te2/3, putting Te2/3 in err-disable state
> Mar  9 16:04:57.701 MET: %PM-SP-STDBY-4-ERR_DISABLE: channel- 
> misconfig error detected on Te2/4, putting Te2/4 in err-disable state
>
> Mar  9 16:04:57.641 MET: %PM-SP-4-ERR_DISABLE: channel-misconfig  
> error detected on Po3, putting Te1/3 in err-disable state
> Mar  9 16:04:57.653 MET: %PM-SP-4-ERR_DISABLE: channel-misconfig  
> error detected on Po3, putting Te1/4 in err-disable state
> Mar  9 16:04:57.665 MET: %PM-SP-4-ERR_DISABLE: channel-misconfig  
> error detected on Po3, putting Te2/3 in err-disable state
> Mar  9 16:04:57.673 MET: %PM-SP-4-ERR_DISABLE: channel-misconfig  
> error detected on Po3, putting Te2/4 in err-disable state
> Mar  9 16:04:57.685 MET: %PM-SP-4-ERR_DISABLE: channel-misconfig  
> error detected on Po3, putting Po3 in err-disable state


From andy.saykao at staff.netspace.net.au  Wed Mar 11 20:51:27 2009
From: andy.saykao at staff.netspace.net.au (Andy Saykao)
Date: Thu, 12 Mar 2009 11:51:27 +1100
Subject: [c-nsp] NBAR support for 7600-SIP-400 ?
Message-ID: <56F211C5E3F24F47B103EA1B253822BE03654C57@vic-cr-ex1.staff.netspace.net.au>

Does anyone know if NBAR is supported on the 7600-SIP-400 (4-subslot SPA
Interface Processor-400)? I've applied "ip nbar protocol-discovery" on
Gig4/0/2 but do not see any matches. This is a 7606 SUP32 running
12.2(33)SRB3.
 
interface GigabitEthernet4/0/2
 bandwidth 200000
 ip address 203.x.x.x 255.255.255.252
 ip nbar protocol-discovery
 load-interval 30
 negotiation auto
 mpls ip

#sh ip nbar protocol-discovery interface g4/0/2 top-n 1
 
 GigabitEthernet4/0/2
                            Input                    Output
                            -----                    ------
   Protocol                 Packet Count             Packet Count
                            Byte Count               Byte Count
                            30sec Bit Rate (bps)     30sec Bit Rate
(bps)
                            30sec Max Bit Rate (bps) 30sec Max Bit Rate
(bps)
   ------------------------ ------------------------
------------------------
   bgp                      0                        0
                            0                        0
                            0                        0
                            0                        0
   unknown                  0                        0
                            0                        0
                            0                        0
                            0                        0
   Total                    0                        0
                            0                        0
                            0                        0
                            0                        0

 
Googling around, I found a previous nsp post that said NBAR was only
available on the 7600-SIP-200 but this post is 3 years old.
 
"NBAR with Sup720 is only supported on FlexWAN, Enhanced FlexWAN, and
the 7600-SIP-200 modules"
 
Also read the data sheet on the 7600-SIP-400 and no mention of NBAR
support on there?
 
http://www.cisco.com/en/US/prod/collateral/routers/ps368/product_data_sh
eet0900aecd8027c9e6.html
 
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 justin at justinshore.com  Wed Mar 11 20:59:15 2009
From: justin at justinshore.com (Justin Shore)
Date: Wed, 11 Mar 2009 19:59:15 -0500
Subject: [c-nsp] MTU nightmare
Message-ID: <49B85E63.3080000@justinshore.com>

My recent post about LDP and BGP flapping turns out to be caused by MTU 
errors.  The problem just happened early one morning.  No config changes 
were made; it just broke.  RANCID confirms that no changes were made for 
12hrs before and almost as many after the problem first happened.

I've been working with TAC on the issue but I they seem to be stuck on 
the fiber media converters I'm using (I'm forced to use due to a lack of 
single-strand optics from Cisco that go farther than 10k).  I have 
several dozen of these same MCs spread out across my network and almost 
all of them carry links with MTUs of 9000 or 9216.  The link in question 
worked find for several weeks, nearly 2 months, before it suddenly broke 
last week.  We've gone through more debugging than I can recall.  We've 
looked for frames with elam on my 7600s and dove into the DFC to look at 
the registers on the rohini.  We haven't found anything at this point.

My layout is fairly simple.  I have a pair of 7613s in the core with 
6748s (and DFCs).  One of the 6748s connects to a Versitron MC, crosses 
several miles of our fiber, out another MC and into a 7201 (Gi0/0, 
non-PCI bus interface).  Interface MTUs are set to 9000 on both sides. 
IP and MPLS MTUs were default originally when it was working (both 
follow interface MTUs).  CLNS MTU was 1496 to keep IS-IS from getting 
pissy with me.

Up until tonight neither the 7201 or 7613 can ping the remote IP on the 
directly-connected subnet with packets larger than 1500 bytes.  1501 
fails.  This is without df set so it should frag it.  Dropping the MTU 
back down to 1500 fixed pings including fragging packets but of course 
that hurts other MPLS things.  Neither box can hit the other's loopback 
either.  This evening I came out to this CO to disconnect from the MC 
and connect directly to the 7201.  I'm using a 2821 so I can up the MTU 
on the onboard ports.  I did that and ICMPs passed fine all the way up 
to 9000.  I reconnected to the MC and I can again ping the 7613 but not 
constantly.  If I start pinging at 9000 it works about half the time. 
If I use 1600 it works maybe 95% of the time.  That holds true all the 
way down to 1501.  The first packet or 2 are usually dropped for some 
reason.  Currently IP MTU on the 7613 is set to 1500 with interface set 
to 9000 and MPLS MTU set to 1524.  This was part of the testing 
left-over from several hours hours on the phone today with TAC.  At this 
point I would say that I think the problem is the media converters BUT 
when I remove the IP MTU from the 7613 all ICMPs greater than 1500 fail. 
  Clearly this MTU problem is not just the MCs but has to also be the 
7613.  Doesn't it?

This has been a huge mind-bender for me.  I can't for the life of me 
figure out what's going on here.  The worst part is that it's not 100% 
consistent.  Yesterday with a slightly more intelligent pair of MCs I 
could send 1508 but not 1509.  I swapped them last night with a known 
good pair of completely dumb MCs (no settings, switches, etc at all). 
These MCs are purely FIFO compared to the ones that are 2-port switches. 
  I have several of these dumb ones in my network.  I have 8 of them 
back to back spanning about 120mi carrying frames of 9000 bytes without 
any problems.  They just work.

Does anyone have any ideas?  WAGs would even be welcomed at this point. 
  I don't know if the problem is the 7201 or 7613 or the 7613's code 
(SRB1).  I'm ready to bump the case to P1 but I'm afraid the finger will 
still be pointed at the MCs and I can't prove it's not them.

Confused,
  Justin

From ltd at cisco.com  Wed Mar 11 22:42:22 2009
From: ltd at cisco.com (Lincoln Dale)
Date: Thu, 12 Mar 2009 13:42:22 +1100
Subject: [c-nsp] MTU nightmare
In-Reply-To: <49B85E63.3080000@justinshore.com>
References: <49B85E63.3080000@justinshore.com>
Message-ID: <49B8768E.4020207@cisco.com>

Justin Shore wrote:
> (I'm forced to use due to a lack of single-strand optics from Cisco 
> that go farther than 10k)
you can most certainly use CWDM SFPs to achieve what you want.  you can 
use CWDM SFPs "back to back" without a MUX in the middle, transmit on 
one wavelength, receive on a different one.  single strand.  it "works" 
because of wideband receivers.


cheers,

lincoln.


From mylists at battleop.com  Wed Mar 11 23:23:43 2009
From: mylists at battleop.com (Richey)
Date: Wed, 11 Mar 2009 23:23:43 -0400
Subject: [c-nsp] T3 fixed when cables are reseated..
Message-ID: <005e01c9a2c1$f2d62c80$d8828580$@com>

I had this happen a year or two ago on another router on a different card.
I have a 7206 with a PA-MC-T3 with about 25 T1s go down tonight.   I
couldn't fix it remotely so I drove to the office to see what was going on.
I unplugged the TX cable and plugged it in and then the same with the RX
cable.   I went back checked the T3 and all of the T1s were backup.    Has
anyone had this happen before?   I can't find any clues as to what happened.
My only guess is that the far end is looped when I unplug the cables and it
may reset the far end.  

 

Richey


From jay at west.net  Thu Mar 12 01:19:39 2009
From: jay at west.net (Jay Hennigan)
Date: Wed, 11 Mar 2009 22:19:39 -0700
Subject: [c-nsp] T3 fixed when cables are reseated..
In-Reply-To: <005e01c9a2c1$f2d62c80$d8828580$@com>
References: <005e01c9a2c1$f2d62c80$d8828580$@com>
Message-ID: <49B89B6B.6070709@west.net>

Richey wrote:
> I had this happen a year or two ago on another router on a different card.
> I have a 7206 with a PA-MC-T3 with about 25 T1s go down tonight.   I
> couldn't fix it remotely so I drove to the office to see what was going on.
> I unplugged the TX cable and plugged it in and then the same with the RX
> cable.   I went back checked the T3 and all of the T1s were backup.    Has
> anyone had this happen before?   I can't find any clues as to what happened.
> My only guess is that the far end is looped when I unplug the cables and it
> may reset the far end.  

If the T3 cable run is fairly short I've seen issues with Cisco PAs 
getting screwy because the signal level in to the PA is too high, 
regardless of the cable length setting (which just affects the 
transmitted level).  Usually this just manifests itself as a constant 
low-level stream of errors.

The fix is an attenuator inline with the receive jack on the port 
adapter.  10dB seems to do the trick.

http://www.pasternack.com/product-75-OHM-BNC-ATTENUATOR-DC-TO-1-GHz-1-WATT-PE7009-10-71538.html

Where size matters:

http://tinyurl.com/csb7rt

If the far end were looped, you would see the loop on "show interface" 
and unplug-replug wouldn't fix it.

Also verify clocking is provisioned correctly, that there is exactly one 
clock source on the T3.

--
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 bbc at misn.com  Thu Mar 12 01:20:45 2009
From: bbc at misn.com (Bryan Campbell)
Date: Thu, 12 Mar 2009 00:20:45 -0500
Subject: [c-nsp] MTU nightmare
In-Reply-To: <49B85E63.3080000@justinshore.com>
References: <49B85E63.3080000@justinshore.com>
Message-ID: <1236835245.5856.26.camel@home-desktop>

O.K. WAG-ing away . . .

If you are willing to defend the MC hardware, so be it.  But, the first
thing you should do is look for a microbend in a fiber jumper.  Replace
all the jumpers with known good and clean jumpers.  Second, replace all
the copper cables with known good cables.  Make sure that you have
certification data for all the cables/jumpers.  You have to be able to
trust your cabling and jumpers.

Second, throw a switch in that can handle the traffic from the MC to the
router.  Mirror out the data to a workstation running wireshark or
something of the like.  Capture your BGP data.  Do the same on the other
end of the link.  You should be able to isolate the problem this way.

If Cisco can't find anything wrong with the configs, it has to be a
physical part.  Interfaces, media converters, cables/jumpers are the
first place to look.  It is not very common for Cisco parts to just up
and fail with no warning.  If Cisco stuff fails, it usually goes down in
a blaze of glory with a pile of data left behind to inspect.   

FWIW, every time we have had a failure of this nature it has been a
media converter failure, or a microbend in a fiber jumper.  

bbc at misn.com


On Wed, 2009-03-11 at 19:59 -0500, Justin Shore wrote:
> My recent post about LDP and BGP flapping turns out to be caused by MTU 
> errors.  The problem just happened early one morning.  No config changes 
> were made; it just broke.  RANCID confirms that no changes were made for 
> 12hrs before and almost as many after the problem first happened.
> 
> I've been working with TAC on the issue but I they seem to be stuck on 
> the fiber media converters I'm using (I'm forced to use due to a lack of 
> single-strand optics from Cisco that go farther than 10k).  I have 
> several dozen of these same MCs spread out across my network and almost 
> all of them carry links with MTUs of 9000 or 9216.  The link in question 
> worked find for several weeks, nearly 2 months, before it suddenly broke 
> last week.  We've gone through more debugging than I can recall.  We've 
> looked for frames with elam on my 7600s and dove into the DFC to look at 
> the registers on the rohini.  We haven't found anything at this point.
> 
> My layout is fairly simple.  I have a pair of 7613s in the core with 
> 6748s (and DFCs).  One of the 6748s connects to a Versitron MC, crosses 
> several miles of our fiber, out another MC and into a 7201 (Gi0/0, 
> non-PCI bus interface).  Interface MTUs are set to 9000 on both sides. 
> IP and MPLS MTUs were default originally when it was working (both 
> follow interface MTUs).  CLNS MTU was 1496 to keep IS-IS from getting 
> pissy with me.
> 
> Up until tonight neither the 7201 or 7613 can ping the remote IP on the 
> directly-connected subnet with packets larger than 1500 bytes.  1501 
> fails.  This is without df set so it should frag it.  Dropping the MTU 
> back down to 1500 fixed pings including fragging packets but of course 
> that hurts other MPLS things.  Neither box can hit the other's loopback 
> either.  This evening I came out to this CO to disconnect from the MC 
> and connect directly to the 7201.  I'm using a 2821 so I can up the MTU 
> on the onboard ports.  I did that and ICMPs passed fine all the way up 
> to 9000.  I reconnected to the MC and I can again ping the 7613 but not 
> constantly.  If I start pinging at 9000 it works about half the time. 
> If I use 1600 it works maybe 95% of the time.  That holds true all the 
> way down to 1501.  The first packet or 2 are usually dropped for some 
> reason.  Currently IP MTU on the 7613 is set to 1500 with interface set 
> to 9000 and MPLS MTU set to 1524.  This was part of the testing 
> left-over from several hours hours on the phone today with TAC.  At this 
> point I would say that I think the problem is the media converters BUT 
> when I remove the IP MTU from the 7613 all ICMPs greater than 1500 fail. 
>   Clearly this MTU problem is not just the MCs but has to also be the 
> 7613.  Doesn't it?
> 
> This has been a huge mind-bender for me.  I can't for the life of me 
> figure out what's going on here.  The worst part is that it's not 100% 
> consistent.  Yesterday with a slightly more intelligent pair of MCs I 
> could send 1508 but not 1509.  I swapped them last night with a known 
> good pair of completely dumb MCs (no settings, switches, etc at all). 
> These MCs are purely FIFO compared to the ones that are 2-port switches. 
>   I have several of these dumb ones in my network.  I have 8 of them 
> back to back spanning about 120mi carrying frames of 9000 bytes without 
> any problems.  They just work.
> 
> Does anyone have any ideas?  WAGs would even be welcomed at this point. 
>   I don't know if the problem is the 7201 or 7613 or the 7613's code 
> (SRB1).  I'm ready to bump the case to P1 but I'm afraid the finger will 
> still be pointed at the MCs and I can't prove it's not them.
> 
> Confused,
>   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 skeeve at skeeve.org  Thu Mar 12 02:37:37 2009
From: skeeve at skeeve.org (Skeeve Stevens)
Date: Thu, 12 Mar 2009 17:37:37 +1100
Subject: [c-nsp] Supress STP on a port?
In-Reply-To: <49B65E75.4010702@ninds.nih.gov>
References: <!&!AAAAAAAAAAAYAAAAAAAAAN5U5OuspydJheQZRk7Gfl7CgAAAEAAAAK/bl9g9cthJu/bPX/RPm1kBAAAAAA==@skeeve.org>
	<49B65E75.4010702@ninds.nih.gov>
Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAAN5U5OuspydJheQZRk7Gfl7CgAAAEAAAAM3UE3LLhslPndrxEN0pwysBAAAAAA==@skeeve.org>

What about if it is a trunk port... which isn't portfasted.... and  you can
only do that command on a portfast port yes?

...Skeeve

-----Original Message-----
From: Giovanni Torres [mailto:torresgi at ninds.nih.gov] 
Sent: Tuesday, 10 March 2009 11:35 PM
To: skeeve at skeeve.org
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Supress STP on a port?

Switch(config-if)# spanning-tree bpdufilter enable

Skeeve Stevens wrote:
> Is it possible to suppress STP on a specific port?
> 
> .Skeeve
> 
> --
> Skeeve Stevens, RHCE
> skeeve at skeeve.org / www.skeeve.org
> Cell +61 (0)414 753 383 / skype://skeeve
> 
> eintellego - skeeve at eintellego.net - www.eintellego.net
> --
> I'm a groove licked love child king of the verse
> Si vis pacem, para bellum
> 
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 


From ltd at cisco.com  Thu Mar 12 02:42:32 2009
From: ltd at cisco.com (Lincoln Dale)
Date: Thu, 12 Mar 2009 17:42:32 +1100
Subject: [c-nsp] Supress STP on a port?
In-Reply-To: <!&!AAAAAAAAAAAYAAAAAAAAAN5U5OuspydJheQZRk7Gfl7CgAAAEAAAAM3UE3LLhslPndrxEN0pwysBAAAAAA==@skeeve.org>
References: <!&!AAAAAAAAAAAYAAAAAAAAAN5U5OuspydJheQZRk7Gfl7CgAAAEAAAAK/bl9g9cthJu/bPX/RPm1kBAAAAAA==@skeeve.org>	<49B65E75.4010702@ninds.nih.gov>
	<!&!AAAAAAAAAAAYAAAAAAAAAN5U5OuspydJheQZRk7Gfl7CgAAAEAAAAM3UE3LLhslPndrxEN0pwysBAAAAAA==@skeeve.org>
Message-ID: <49B8AED8.8070900@cisco.com>

its a matter of SHOULD you.  enabling eating BPDUs is never a wise thing 
IMHO.

not sure what you're looking for exactly - are you looking to have 
multiple VLANs on a port, but not have that port as a 'network' port?

if so, why not enable it as 'edge trunk' port?  best of both worlds & 
keep your STP protective measures in place (loop guard et al) ?



cheers,

lincoln.

Skeeve Stevens wrote:
> What about if it is a trunk port... which isn't portfasted.... and  you can
> only do that command on a portfast port yes?
>
> ...Skeeve
>
> -----Original Message-----
> From: Giovanni Torres [mailto:torresgi at ninds.nih.gov] 
> Sent: Tuesday, 10 March 2009 11:35 PM
> To: skeeve at skeeve.org
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] Supress STP on a port?
>
> Switch(config-if)# spanning-tree bpdufilter enable
>
> Skeeve Stevens wrote:
>   
>> Is it possible to suppress STP on a specific port?
>>
>> .Skeeve
>>
>> --
>> Skeeve Stevens, RHCE
>> skeeve at skeeve.org / www.skeeve.org
>> Cell +61 (0)414 753 383 / skype://skeeve
>>
>> eintellego - skeeve at eintellego.net - www.eintellego.net
>> --
>> I'm a groove licked love child king of the verse
>> Si vis pacem, para bellum
>>
>>
>> _______________________________________________
>> cisco-nsp mailing 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 brad.henshaw at qcn.com.au  Thu Mar 12 02:48:22 2009
From: brad.henshaw at qcn.com.au (Brad Henshaw)
Date: Thu, 12 Mar 2009 16:48:22 +1000
Subject: [c-nsp] Supress STP on a port?
Message-ID: <8B25B862BC09784B9B74FB950D4F64D40F81F7@qcnapp01.corp.qcn>

Skeeve Stevens wrote:

>What about if it is a trunk port... which isn't portfasted....
>and  you can only do that command on a portfast port yes?

To the best of my knowledge 'spanning-tree bpdufilter enable'
will filter all STP BPDUs on a port regardless of whether it's
a trunk port or whether portfast is enabled.

Regards,
Brad

From mksmith at adhost.com  Thu Mar 12 02:57:02 2009
From: mksmith at adhost.com (Michael K. Smith - Adhost)
Date: Wed, 11 Mar 2009 23:57:02 -0700
Subject: [c-nsp] Supress STP on a port?
In-Reply-To: <49B8AED8.8070900@cisco.com>
References: <!&!AAAAAAAAAAAYAAAAAAAAAN5U5OuspydJheQZRk7Gfl7CgAAAEAAAAK/bl9g9cthJu/bPX/RPm1kBAAAAAA==@skeeve.org>	<49B65E75.4010702@ninds.nih.gov><!&!AAAAAAAAAAAYAAAAAAAAAN5U5OuspydJheQZRk7Gfl7CgAAAEAAAAM3UE3LLhslPndrxEN0pwysBAAAAAA==@skeeve.org>
	<49B8AED8.8070900@cisco.com>
Message-ID: <17838240D9A5544AAA5FF95F8D52031605B41D84@ad-exh01.adhost.lan>

I echo what Lincoln said as loudly as I can without typing in all caps.  If you enable filtering and you get a second path somehow or somewhere (customers can be very helpful by doing "stuff" when you're not looking), you will loop up your entire network.  This will happen at 3 am 2 years from now on a Sunday when you're out of town and your front line tech is asleep in a hut somewhere.  Trust me.  BPDU-filter bad.  Really.

Mike

> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> bounces at puck.nether.net] On Behalf Of Lincoln Dale
> Sent: Wednesday, March 11, 2009 11:43 PM
> To: skeeve at skeeve.org
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] Supress STP on a port?
> 
> its a matter of SHOULD you.  enabling eating BPDUs is never a wise thing
> IMHO.
> 
> not sure what you're looking for exactly - are you looking to have
> multiple VLANs on a port, but not have that port as a 'network' port?
> 
> if so, why not enable it as 'edge trunk' port?  best of both worlds &
> keep your STP protective measures in place (loop guard et al) ?
> 
> 
> 
> cheers,
> 
> lincoln.
> 
> Skeeve Stevens wrote:
> > What about if it is a trunk port... which isn't portfasted.... and  you can
> > only do that command on a portfast port yes?
> >
> > ...Skeeve
> >
> > -----Original Message-----
> > From: Giovanni Torres [mailto:torresgi at ninds.nih.gov]
> > Sent: Tuesday, 10 March 2009 11:35 PM
> > To: skeeve at skeeve.org
> > Cc: cisco-nsp at puck.nether.net
> > Subject: Re: [c-nsp] Supress STP on a port?
> >
> > Switch(config-if)# spanning-tree bpdufilter enable
> >
> > Skeeve Stevens wrote:
> >
> >> Is it possible to suppress STP on a specific port?
> >>
> >> .Skeeve
> >>
> >> --
> >> Skeeve Stevens, RHCE
> >> skeeve at skeeve.org / www.skeeve.org
> >> Cell +61 (0)414 753 383 / skype://skeeve
> >>
> >> eintellego - skeeve at eintellego.net - www.eintellego.net
> >> --
> >> I'm a groove licked love child king of the verse
> >> Si vis pacem, para bellum
> >>
> >>
> >> _______________________________________________
> >> cisco-nsp mailing 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/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 474 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090311/85db5d8e/attachment.bin>

From gert at greenie.muc.de  Thu Mar 12 04:19:28 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Thu, 12 Mar 2009 09:19:28 +0100
Subject: [c-nsp] T3 fixed when cables are reseated..
In-Reply-To: <005e01c9a2c1$f2d62c80$d8828580$@com>
References: <005e01c9a2c1$f2d62c80$d8828580$@com>
Message-ID: <20090312081928.GP290@greenie.muc.de>

Hi,

On Wed, Mar 11, 2009 at 11:23:43PM -0400, Richey wrote:
> I unplugged the TX cable and plugged it in and then the same with the RX
> cable.   I went back checked the T3 and all of the T1s were backup.    Has

We've seen this on E3s and T3s every now and then.

No idea why, though.

My theory is that "a good old loss-of-signal" will reset all framers etc
involved, and enable re-synchronization.

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/20090312/381826a0/attachment.bin>

From Marcus.Gerdon at versatel.de  Thu Mar 12 05:23:19 2009
From: Marcus.Gerdon at versatel.de (Marcus.Gerdon)
Date: Thu, 12 Mar 2009 10:23:19 +0100
Subject: [c-nsp] Sup720 crashing at RP boot - HW revision dependent ?
Message-ID: <227142482560EF458FF1F7E784E26AB84AD1EB@FLBVEXCH01.versatel.local>

Hello,

I got another pair of Sup720, Rev 5.2 and 5.7 and we've done a bunch of additional tests yesterday and there're some new results on this.

As before the 5.2 crashes in the 6509, but the 5.7 boots fine. This 5.2 gave me 'EOBC Jam's in addtion.

So at least there seems to be no >=5.2 or somewhat general issue.

Our supplier did some additional tests based on the revisions and came out with Sup720 Rev 5.2 booting fine in a 6509 Rev 2.0.

Although now all 3 Rev 5.2 engines aren't booting in my 6509 whilst 4.4 and 5.7 are working fine I begin to think whether my chassis might simply be defect. It's been productive for years and up to now everything worked smoothly as expected except those 3 Sup720's. But the only other cause in case the chassis is ok I can think of would mean a revision-based issue Sup 5.2/chassis 2.0 only occuring randomly (3 out of 3 is still random?) or with a subset of Sup's manufactured in Rev 5.2. This sounds too unlikely to me.

It can't be this one http://www.cisco.com/en/US/ts/fn/620/fn62606.html, but the note especially on Rev 5.2 makes me somewhat suspicious.




regards,

Marcus
 

> -----Urspr?ngliche Nachricht-----
> Von: cisco-nsp-bounces at puck.nether.net 
> [mailto:cisco-nsp-bounces at puck.nether.net] Im Auftrag von 
> Marcus.Gerdon
> Gesendet: Mittwoch, 11. M?rz 2009 11:46
> An: cisco-nsp at puck.nether.net
> Betreff: [c-nsp] Sup720 crashing at RP boot - HW revision dependent ?
> 
> Hi @all,
> 
> yesterday I've been hit by a somewhat strange - and possibly 
> worrying -
> effect with Sup720 in 6500.
> 
> I've got 3 Sup720-3BXL, one with an older HW revision (Sup: 4.4 / PFC:
> 1.6 / MSFC: 2.5) and 2 with newer (Sup: 5.2 / PFC: 1.8 / 
> MSFC: 2.5). All
> three have been tested in a 6509 successfully by the 
> supplier. According
> the test sheets they've used a Rev. 3.0 chassis.
> 
> For offline testing and preparation I've an 6509 and 6506 
> spare chassis
> at hands, both of them being Rev. 2.0.
> 
> When trying to boot those Sup in my 6509 the older one boots fine and
> everything is ok. The newer ones both start to boot and after 
> switching
> to boot the RP it stalls (download doesn't even start, hangs after
> memory is displayed). After a minute or two a 'software forced crash'
> occurs and I'm thrown do SP rommon.
> 
> Up to this point no updates, config changes or anything other than
> plugging them in the chassis and turning the power on has been done.
> 
> It doesn't matter if they're put in slot 5 or 6, if the working one is
> already active in slot 5 or if I'm manually booting from 
> rommon instead
> of autoboot. Also the IOS used doesn't change anything (18SXF, 18SXI,
> 17SXd)
> 
> Interestingly in the Rev. 2.0 6506 all three are booting 
> fine. I've done
> both rom updates in the 6506 and tried again in the 6509 - without any
> change.
> 
> To me this looks like there's some dependancy between HW revisions of
> the Sup or PFC (MSFC rev. is the same on all threee) and the 6509
> chassis (6506 wasn't effected). 
> 
> I've searched cisco.com for quite some time but without any 
> hint to this
> issue. The only thing I found was that there're a few 6509-NEB eeprom
> updates to be applied to the chassis itself. So in fact there is some
> active rom part with the chassis that supposedly will differ between
> revisions.
> 
> 
> Does someone stumbled upon this, had similar issues or maybe even know
> or did see any document (comp. matrix, workaround or alike) 
> about this ?
> 
> 
> 
> regards,
> 
> Marcus
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 

From pl+list at pmacct.net  Thu Mar 12 05:38:43 2009
From: pl+list at pmacct.net (Paolo Lucente)
Date: Thu, 12 Mar 2009 09:38:43 +0000
Subject: [c-nsp] NBAR support for 7600-SIP-400 ?
In-Reply-To: <56F211C5E3F24F47B103EA1B253822BE03654C57@vic-cr-ex1.staff.netspace.net.au>
References: <56F211C5E3F24F47B103EA1B253822BE03654C57@vic-cr-ex1.staff.netspace.net.au>
Message-ID: <20090312093842.GA18487@london.pmacct.net>

Hi Andy,

Generally you would need a SUP32-PISA supervisor in order to get NBAR
on a 6500 platform. Don't know about the SIP-400, but i see too there
is no mention around about it supporting the feature.

http://www.cisco.com/en/US/prod/collateral/routers/ps368/product_data_sheet0900aecd8027c9e6.html

Cheers,
Paolo


On Thu, Mar 12, 2009 at 11:51:27AM +1100, Andy Saykao wrote:
> Does anyone know if NBAR is supported on the 7600-SIP-400 (4-subslot SPA
> Interface Processor-400)? I've applied "ip nbar protocol-discovery" on
> Gig4/0/2 but do not see any matches. This is a 7606 SUP32 running
> 12.2(33)SRB3.
>  
> interface GigabitEthernet4/0/2
>  bandwidth 200000
>  ip address 203.x.x.x 255.255.255.252
>  ip nbar protocol-discovery
>  load-interval 30
>  negotiation auto
>  mpls ip
> 
> #sh ip nbar protocol-discovery interface g4/0/2 top-n 1
>  
>  GigabitEthernet4/0/2
>                             Input                    Output
>                             -----                    ------
>    Protocol                 Packet Count             Packet Count
>                             Byte Count               Byte Count
>                             30sec Bit Rate (bps)     30sec Bit Rate
> (bps)
>                             30sec Max Bit Rate (bps) 30sec Max Bit Rate
> (bps)
>    ------------------------ ------------------------
> ------------------------
>    bgp                      0                        0
>                             0                        0
>                             0                        0
>                             0                        0
>    unknown                  0                        0
>                             0                        0
>                             0                        0
>                             0                        0
>    Total                    0                        0
>                             0                        0
>                             0                        0
>                             0                        0
> 
>  
> Googling around, I found a previous nsp post that said NBAR was only
> available on the 7600-SIP-200 but this post is 3 years old.
>  
> "NBAR with Sup720 is only supported on FlexWAN, Enhanced FlexWAN, and
> the 7600-SIP-200 modules"
>  
> Also read the data sheet on the 7600-SIP-400 and no mention of NBAR
> support on there?
>  
> http://www.cisco.com/en/US/prod/collateral/routers/ps368/product_data_sh
> eet0900aecd8027c9e6.html
>  
> Thanks.
>  
> Andy


From rodunn at cisco.com  Thu Mar 12 10:14:55 2009
From: rodunn at cisco.com (Rodney Dunn)
Date: Thu, 12 Mar 2009 10:14:55 -0400
Subject: [c-nsp] NBAR support for 7600-SIP-400 ?
In-Reply-To: <20090312093842.GA18487@london.pmacct.net>
References: <56F211C5E3F24F47B103EA1B253822BE03654C57@vic-cr-ex1.staff.netspace.net.au>
	<20090312093842.GA18487@london.pmacct.net>
Message-ID: <20090312141455.GE15487@rtp-cse-489.cisco.com>

I don't think it is on any other card other than SIP200, Flexwan and then
sup32 PISA.
.

The Flexwan and SIP-200 had some limited support since they were software
forwarding based on some of the VIP code that had NBAR support.

The PISA was the other option for NBAR as you mentioned.

Rodney

On Thu, Mar 12, 2009 at 09:38:43AM +0000, Paolo Lucente wrote:
> Hi Andy,
> 
> Generally you would need a SUP32-PISA supervisor in order to get NBAR
> on a 6500 platform. Don't know about the SIP-400, but i see too there
> is no mention around about it supporting the feature.
> 
> http://www.cisco.com/en/US/prod/collateral/routers/ps368/product_data_sheet0900aecd8027c9e6.html
> 
> Cheers,
> Paolo
> 
> 
> On Thu, Mar 12, 2009 at 11:51:27AM +1100, Andy Saykao wrote:
> > Does anyone know if NBAR is supported on the 7600-SIP-400 (4-subslot SPA
> > Interface Processor-400)? I've applied "ip nbar protocol-discovery" on
> > Gig4/0/2 but do not see any matches. This is a 7606 SUP32 running
> > 12.2(33)SRB3.
> >  
> > interface GigabitEthernet4/0/2
> >  bandwidth 200000
> >  ip address 203.x.x.x 255.255.255.252
> >  ip nbar protocol-discovery
> >  load-interval 30
> >  negotiation auto
> >  mpls ip
> > 
> > #sh ip nbar protocol-discovery interface g4/0/2 top-n 1
> >  
> >  GigabitEthernet4/0/2
> >                             Input                    Output
> >                             -----                    ------
> >    Protocol                 Packet Count             Packet Count
> >                             Byte Count               Byte Count
> >                             30sec Bit Rate (bps)     30sec Bit Rate
> > (bps)
> >                             30sec Max Bit Rate (bps) 30sec Max Bit Rate
> > (bps)
> >    ------------------------ ------------------------
> > ------------------------
> >    bgp                      0                        0
> >                             0                        0
> >                             0                        0
> >                             0                        0
> >    unknown                  0                        0
> >                             0                        0
> >                             0                        0
> >                             0                        0
> >    Total                    0                        0
> >                             0                        0
> >                             0                        0
> >                             0                        0
> > 
> >  
> > Googling around, I found a previous nsp post that said NBAR was only
> > available on the 7600-SIP-200 but this post is 3 years old.
> >  
> > "NBAR with Sup720 is only supported on FlexWAN, Enhanced FlexWAN, and
> > the 7600-SIP-200 modules"
> >  
> > Also read the data sheet on the 7600-SIP-400 and no mention of NBAR
> > support on there?
> >  
> > http://www.cisco.com/en/US/prod/collateral/routers/ps368/product_data_sh
> > eet0900aecd8027c9e6.html
> >  
> > Thanks.
> >  
> > Andy
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

From billw at waveform.net  Thu Mar 12 11:38:52 2009
From: billw at waveform.net (billw at waveform.net)
Date: Thu, 12 Mar 2009 11:38:52 -0400 (EDT)
Subject: [c-nsp] T3 fixed when cables are reseated..
In-Reply-To: <005e01c9a2c1$f2d62c80$d8828580$@com>
References: <005e01c9a2c1$f2d62c80$d8828580$@com>
Message-ID: <10eafa5eb339095b72fa03def0f1fb2d.squirrel@webmail.waveform.net>

I've seen this a few times in the past with loose connectors. The cause
has generally been either a loose connection on the center pin (usually in
the connector on the card, but sometimes the crimp on the center pin of
the connector isn't tight enough onto the center conductor of the cable).
Occasionally it's a loose ferrule on the connector but that's rare. I have
seen connectors that have a strand or two of the shield that make
intermittent contact to the center pin to cause a short.

Many of these loose connector problems magically disappear when the
connector is either unplugged/replugged or is just "wiggled a little". The
problem is that over time the loose connector will fail again so the real
solution has been to either replace the problem cable or cut off the bad
connector and put on a new one.

  -Bill

> I had this happen a year or two ago on another router on a different card.
> I have a 7206 with a PA-MC-T3 with about 25 T1s go down tonight.   I
> couldn't fix it remotely so I drove to the office to see what was going
> on.
> I unplugged the TX cable and plugged it in and then the same with the RX
> cable.   I went back checked the T3 and all of the T1s were backup.    Has
> anyone had this happen before?   I can't find any clues as to what
> happened.
> My only guess is that the far end is looped when I unplug the cables and
> it
> may reset the far end.
>
>
>
> Richey



From clinton at scripty.com  Thu Mar 12 12:07:16 2009
From: clinton at scripty.com (Clinton Work)
Date: Thu, 12 Mar 2009 10:07:16 -0600
Subject: [c-nsp] VRF aware syslog - feature enhancement CSCsu22476
Message-ID: <49B93334.9060100@scripty.com>


I created a feature enhancement for VRF-aware syslog support in IOS 
12.4T so you can actually set the source interface.  If you interested 
in the feature, please go ahead and let your account team know or open a 
case against the enhancement ID.   The feature probably won't be 
implemented until 12.5T or later.   Support for managing a CE router via 
a separate management VRF is almost complete. 

CSCsu22476 - Set source interface for VRF-aware syslog messages


Clinton. 

From ATolstykh at integrysgroup.com  Thu Mar 12 11:37:07 2009
From: ATolstykh at integrysgroup.com (Tolstykh, Andrew)
Date: Thu, 12 Mar 2009 10:37:07 -0500
Subject: [c-nsp] NBAR support for 7600-SIP-400 ?
In-Reply-To: <56F211C5E3F24F47B103EA1B253822BE03654C57@vic-cr-ex1.staff.netspace.net.au>
References: <56F211C5E3F24F47B103EA1B253822BE03654C57@vic-cr-ex1.staff.netspace.net.au>
Message-ID: <BC9398A687968242BE5F841438B09AD501663137@DOB-BXVS3.integrysgroup.net>

Do you have "ip flow ingress/egress" or "ip route-cache flow" enabled on
this interface? Also is this a P/PE MPLS router?

SUP-32 supports NetFlow just fine.

Thanks,
Andrew

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Andy Saykao
Sent: Wednesday, March 11, 2009 7:51 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] NBAR support for 7600-SIP-400 ?

Does anyone know if NBAR is supported on the 7600-SIP-400 (4-subslot SPA
Interface Processor-400)? I've applied "ip nbar protocol-discovery" on
Gig4/0/2 but do not see any matches. This is a 7606 SUP32 running
12.2(33)SRB3.
 
interface GigabitEthernet4/0/2
 bandwidth 200000
 ip address 203.x.x.x 255.255.255.252
 ip nbar protocol-discovery
 load-interval 30
 negotiation auto
 mpls ip

#sh ip nbar protocol-discovery interface g4/0/2 top-n 1
 
 GigabitEthernet4/0/2
                            Input                    Output
                            -----                    ------
   Protocol                 Packet Count             Packet Count
                            Byte Count               Byte Count
                            30sec Bit Rate (bps)     30sec Bit Rate
(bps)
                            30sec Max Bit Rate (bps) 30sec Max Bit Rate
(bps)
   ------------------------ ------------------------
------------------------
   bgp                      0                        0
                            0                        0
                            0                        0
                            0                        0
   unknown                  0                        0
                            0                        0
                            0                        0
                            0                        0
   Total                    0                        0
                            0                        0
                            0                        0
                            0                        0

 
Googling around, I found a previous nsp post that said NBAR was only
available on the 7600-SIP-200 but this post is 3 years old.
 
"NBAR with Sup720 is only supported on FlexWAN, Enhanced FlexWAN, and
the 7600-SIP-200 modules"
 
Also read the data sheet on the 7600-SIP-400 and no mention of NBAR
support on there?
 
http://www.cisco.com/en/US/prod/collateral/routers/ps368/product_data_sh
eet0900aecd8027c9e6.html
 
Thanks.
 
Andy

This email and any files transmitted with it are confidential and
intended
 solely for the use of the individual or entity to whom they are
addressed. 
Please notify the sender immediately by email if you have received this 
email by mistake and delete this email from your system. Please note
that
 any views or opinions presented in this email are solely those of the
 author and do not necessarily represent those of the organisation. 
Finally, the recipient should check this email and any attachments for 
the presence of viruses. The organisation accepts no liability for any 
damage caused by any virus transmitted by this email.

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

From ASikkema at office.unet.nl  Thu Mar 12 12:20:47 2009
From: ASikkema at office.unet.nl (Andreas Sikkema)
Date: Thu, 12 Mar 2009 17:20:47 +0100
Subject: [c-nsp] Sending connected number from AS5350
Message-ID: <OFC129ADB2.21329615-ONC1257577.0057C5A2-C1257577.0059CC14@office.unet.nl>

Hi,

I've got a Cisco AS5350XM connected to a couple of ISDN30s from one of the 
local telcos. The 5350 converts ISDN to SIP and vice versa. Some of our 
customers on the SIP side have complained that every now and then when 
they are called from the PSTN side the calling party sees the "main 
number" of our ISDN lines appear instead of the called number when the 
call has been answered. 

The telco apparently has the policy that they will send out the line 
number when we don't provide the connected number or overwrite it when we 
send an "illegal" number. The only thing the telco so far has offered us 
is to set presentation to not allowed for all outgoing connected numbers 
which will solve the presentation of the line number but might give some 
calling parties the wrong impression.

The problem is that I haven't been able to find a way make our 5350 send a 
"connected number" IE on the ISDN side. (isdn outgoing ie connected-number 
hasn't yet solved the problem as far as I can see). 

Is there a way to force the 5350 to send a connected number IE for 
instance when receiving an UPDATE message or on receipt of a 200 OK 
message? The only logging a debug isdn q931 will give on a CONNECT message 
being sent is this:
Mar 12 16:28:10.935: ISDN Se3/5:15 Q931: TX -> CONNECT pd = 8  callref = 
0xF001


Or am I way off track and should be looking at something else?

-- 
Andreas Sikkema

From techconfig at yahoo.com  Thu Mar 12 13:06:36 2009
From: techconfig at yahoo.com (Mark Tech)
Date: Thu, 12 Mar 2009 10:06:36 -0700 (PDT)
Subject: [c-nsp] 95th percentile billing software
Message-ID: <677003.85629.qm@web44807.mail.sp1.yahoo.com>


Hi
I am the lookout for 95th billing software and I'm not sure where to start.?I am open to either commercial or open souce software; just wondering what other people are using/have thoughts on?

Currently we use Cisco 7600s and GSRs for our ISP platform

Your input is appreciated

Regards

Mark


      


From chris at nmedia.net  Thu Mar 12 13:45:08 2009
From: chris at nmedia.net (Chris Cappuccio)
Date: Thu, 12 Mar 2009 10:45:08 -0700
Subject: [c-nsp] 95th percentile billing software
In-Reply-To: <677003.85629.qm@web44807.mail.sp1.yahoo.com>
References: <677003.85629.qm@web44807.mail.sp1.yahoo.com>
Message-ID: <20090312174508.GN10872@ref.nmedia.net>

RTG http://rtg.sourceforge.net/ is popular because it stores real 95th data, without averaging it, into a database for accurate billing.  Unfortunately the software itself is poorly written so if it doesn't work properly on your platform or your number of targets, then it sucks.  The latest release is from 2003 but the mailing list is active.  The CVS code is newer.  People in the mailing list seem to have work arounds for the poller bugs, by using other pollers. http://lists.grdata.com/pipermail/rtg/

RTG-Report http://search.cpan.org/~msimerson/RTG-Report-1.16/ can be used to pull RTG data out of your RTG database into Perl scripts.

JRTG http://jrtg.sourceforge.net/ is less popular, but maintained.  Oddly, it is migrating to JRRD, which is exactly what RTG was trying to avoid (a database that would average data into larger timeslots as it ages.)

CACTI http://www.cacti.net/ has a 95th percentile mode for its graphs, but is considered less accurate as it averages samples together (because it uses RRD) thus lowering the overall 95th percentile rating for customers with less constant usage.  The monthly graph uses a 30 minute average, and the yearly graph uses a 1 day average.  Many customers will have a significantly lower 1 day average, due to low night time usage, for instance...

Plenty of other network monitoring tools have a 95th percentile mode too, but most of them use an averaging data store, which doesn't provide you with any sort of long term way to maintain the data!  The data you use to bill one month gets averaged into larger chunks the next month with RRD stores.

Mark Tech [techconfig at yahoo.com] wrote:
> 
> Hi
> I am the lookout for 95th billing software and I'm not sure where to start.?I am open to either commercial or open souce software; just wondering what other people are using/have thoughts on?
> 
> Currently we use Cisco 7600s and GSRs for our ISP platform
> 
> Your input is appreciated
> 
> Regards
> 
> 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/

-- 
Only failure makes us experts

From cmadams at hiwaay.net  Thu Mar 12 13:59:54 2009
From: cmadams at hiwaay.net (Chris Adams)
Date: Thu, 12 Mar 2009 12:59:54 -0500
Subject: [c-nsp] 95th percentile billing software
In-Reply-To: <20090312174508.GN10872@ref.nmedia.net>
References: <677003.85629.qm@web44807.mail.sp1.yahoo.com>
	<20090312174508.GN10872@ref.nmedia.net>
Message-ID: <20090312175954.GD536710@hiwaay.net>

Once upon a time, Chris Cappuccio <chris at nmedia.net> said:
> CACTI http://www.cacti.net/ has a 95th percentile mode for its graphs, but is considered less accurate as it averages samples together (because it uses RRD) thus lowering the overall 95th percentile rating for customers with less constant usage.  The monthly graph uses a 30 minute average, and the yearly graph uses a 1 day average.  Many customers will have a significantly lower 1 day average, due to low night time usage, for instance...

That's not a function of RRD, that's a function of how RRD is
configured.  For example, Cricket uses default RRDs that only keep 5
minute snapshots for a couple of days, but it is easy to configure it to
keep them longer (which of course makes them larger).  This can be done
on a per-targetType basis (so you could build a 95th percentile target
type and set it to keep 5 minute data for 30 or 60 days).

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

From dwcarder at wisc.edu  Thu Mar 12 14:23:14 2009
From: dwcarder at wisc.edu (Dale W. Carder)
Date: Thu, 12 Mar 2009 13:23:14 -0500
Subject: [c-nsp] 95th percentile billing software
In-Reply-To: <20090312175954.GD536710@hiwaay.net>
References: <677003.85629.qm@web44807.mail.sp1.yahoo.com>
	<20090312174508.GN10872@ref.nmedia.net>
	<20090312175954.GD536710@hiwaay.net>
Message-ID: <0FA7CF79-9E52-49EB-B340-E2FBDC64B018@wisc.edu>


On Mar 12, 2009, at 12:59 PM, Chris Adams wrote:
> That's not a function of RRD, that's a function of how RRD is
> configured.  For example, Cricket uses default RRDs that only keep 5
> minute snapshots for a couple of days, but it is easy to configure  
> it to
> keep them longer (which of course makes them larger).  This can be  
> done
> on a per-targetType basis (so you could build a 95th percentile target
> type and set it to keep 5 minute data for 30 or 60 days).

MRTG can too.  Here's a cfg example for keeping approx a
year's worth of data: RRDRowCount[$target]: 105408

Cheers,
Dale

From chris at nmedia.net  Thu Mar 12 15:44:52 2009
From: chris at nmedia.net (Chris Cappuccio)
Date: Thu, 12 Mar 2009 12:44:52 -0700
Subject: [c-nsp] 95th percentile billing software
In-Reply-To: <20090312175954.GD536710@hiwaay.net>
References: <677003.85629.qm@web44807.mail.sp1.yahoo.com>
	<20090312174508.GN10872@ref.nmedia.net>
	<20090312175954.GD536710@hiwaay.net>
Message-ID: <20090312194452.GR10872@ref.nmedia.net>

Chris Adams [cmadams at hiwaay.net] wrote:
> That's not a function of RRD, that's a function of how RRD is
> configured.  For example, Cricket uses default RRDs that only keep 5
> minute snapshots for a couple of days, but it is easy to configure it to
> keep them longer (which of course makes them larger).  This can be done
> on a per-targetType basis (so you could build a 95th percentile target
> type and set it to keep 5 minute data for 30 or 60 days).
> 

Yes, but what's the point of using an RRD based grapher if you aren't going to take advantage of RRD?  You have to work around RRD just to keep the data in a form that you can use for legal purposes.  This was the primary design consideration of RTG, anyways.  


From cmadams at hiwaay.net  Thu Mar 12 15:49:20 2009
From: cmadams at hiwaay.net (Chris Adams)
Date: Thu, 12 Mar 2009 14:49:20 -0500
Subject: [c-nsp] 95th percentile billing software
In-Reply-To: <20090312194452.GR10872@ref.nmedia.net>
References: <677003.85629.qm@web44807.mail.sp1.yahoo.com>
	<20090312174508.GN10872@ref.nmedia.net>
	<20090312175954.GD536710@hiwaay.net>
	<20090312194452.GR10872@ref.nmedia.net>
Message-ID: <20090312194919.GA1143421@hiwaay.net>

Once upon a time, Chris Cappuccio <chris at nmedia.net> said:
> Yes, but what's the point of using an RRD based grapher if you aren't going to take advantage of RRD?  You have to work around RRD just to keep the data in a form that you can use for legal purposes.  This was the primary design consideration of RTG, anyways.  

It isn't a "work-around", it is just a configuration option.  When you
create an RRD file, you tell rrdtool how many of each data point to
keep.  If you tell it to keep 576 5 minute interval data points, you get
2 days.  If you tell it 17280, you get 60 days.  You still get all the
advantages of RRD (round-robin databases, quick-and-easy graphs, etc.).

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

From peter at rathlev.dk  Thu Mar 12 16:22:28 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Thu, 12 Mar 2009 21:22:28 +0100
Subject: [c-nsp] FWSM HA secondary reload & long downtime
In-Reply-To: <Pine.LNX.4.64.0903111901550.21155@zippy.stdio.be>
References: <1236633344.3572.13.camel@localhost.localdomain>
	<Pine.LNX.4.64.0903101125050.6781@zippy.stdio.be>
	<1236719408.4513.51.camel@localhost.localdomain>
	<Pine.LNX.4.64.0903111101340.21155@zippy.stdio.be>
	<1236793626.3563.339.camel@localhost.localdomain>
	<Pine.LNX.4.64.0903111901550.21155@zippy.stdio.be>
Message-ID: <1236889348.4133.15.camel@localhost.localdomain>

On Wed, 2009-03-11 at 19:14 +0100, Andrew Yourtchenko wrote:
> On Wed, 11 Mar 2009, Peter Rathlev wrote:
> > This of course points to something else being the problem, not the
> > FWSM.
> 
> *bling* too strong of an assumption :).

Ironically that was a very precise observation. ;-) I've looked much
more thoroughly at the logs now, and finally I discovered what would've
taken only few moments to see had I just opened my eyes.

It turns out that more than one context had problems. I think I was
tired when I looked at the configuration differences. Specifically all
contexts with no "monitor-interface"-configuration were affected. Every
context with at least one "monitor-interface" had no problems.

I seem to remember that we stopped using "monitor-interface" in the
individual contexts a year or so back, thinking that when failover is
always system wide anyway, and since all the relevant VLANs share the
same underlying (redundant) path, we could just as well only monitor one
interface in the admin context. By chance a couple of other contexts had
some monitors that weren't removed back then.

It is of course a joy to have figured this out, but I can't seem to find
anything much on what "monitor-interface" in a multiple context setup
actually does or doesn't do.

Should every context have one monitor-interface? Should all interfaces
be monitored or just one per context?

Regards,
Peter



From cphillips at wbsconnect.com  Thu Mar 12 17:28:35 2009
From: cphillips at wbsconnect.com (Chris Phillips)
Date: Thu, 12 Mar 2009 14:28:35 -0700
Subject: [c-nsp] Interworking on 6500s
Message-ID: <49B97E83.2010708@wbsconnect.com>

Looking at interworking on 6500s with SUP720-3BXLs running SXI on 
non-PA, non-OSM and non-SIP/SPA cards.  The command takes going Ethernet 
to Ethernet.

connect TEST1 FastEthernet 9/25 FastEthernet 9/26

sh connect

ID   Name            Segment 1              Segment 2 
State
================================================================================
6    TEST1           Fa9/25                 Fa9/26 
ADMIN UP

or...

connect TEST2 FastEthernet 9/26 GigabitEthernet 7/16.4080 interworking 
ethernet

sh connect

ID   Name            Segment 1              Segment 2 
State
================================================================================
5    TEST2           Fa9/26                 Gi7/16.4080 
ADMIN UP

However, traffic does not seem to want to pass.

Looked over a few documents online.  They seem to suggest that 
interworking is only supported on SIP/SPA, OSM and PA cards.

#######
Cisco 7600 and 6500 Series Router Restrictions

?Layer 2 Local Switching supports the following port adapters and 
interface processors on the Cisco 7600-SUP720/MSFC3 router:

?All port adapters on the Enhanced FlexWAN module

?All SPAs on the SIP-200 line cards

?On the Cisco 6500 series and 7600 series routers, only like-to-like 
local switching is supported (ATM to ATM and Frame Relay to Frame Relay).

?Same-port switching is not supported on the Cisco 6500 series and 7600 
series routers.
#######

Has anyone have any experience to the contrary?

-- 
Chris Phillips

From andy.saykao at staff.netspace.net.au  Thu Mar 12 17:33:25 2009
From: andy.saykao at staff.netspace.net.au (Andy Saykao)
Date: Fri, 13 Mar 2009 08:33:25 +1100
Subject: [c-nsp] NBAR support for 7600-SIP-400 ?
Message-ID: <56F211C5E3F24F47B103EA1B253822BE03654C5C@vic-cr-ex1.staff.netspace.net.au>

Hi Andrew,

I tried applying "ip flow ingress" on the interface but still no go.
This is a P MPLS router in our network.

interface GigabitEthernet4/0/2
 bandwidth 200000
 ip address 203.x.x.x 255.255.255.252
 ip nbar protocol-discovery
 ip flow ingress
 load-interval 30
 negotiation auto
 mpls ip 

On other platforms I tested (eg: 7301), even without the "ip flow
ingress", NBAR was still functioning fine.

Thanks for your reply.

Cheers.

Andy


-----Original Message-----
From: Tolstykh, Andrew [mailto:ATolstykh at integrysgroup.com] 
Sent: Friday, 13 March 2009 2:37 AM
To: Andy Saykao; cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] NBAR support for 7600-SIP-400 ?

Do you have "ip flow ingress/egress" or "ip route-cache flow" enabled on
this interface? Also is this a P/PE MPLS router?

SUP-32 supports NetFlow just fine.

Thanks,
Andrew

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 vijay.ramcharan at verizonbusiness.com  Thu Mar 12 17:25:25 2009
From: vijay.ramcharan at verizonbusiness.com (Ramcharan, Vijay A)
Date: Thu, 12 Mar 2009 21:25:25 +0000
Subject: [c-nsp] FWSM HA secondary reload & long downtime
In-Reply-To: <1236889348.4133.15.camel@localhost.localdomain>
Message-ID: <8171C8272CE8FE4A8F5BFF8A97CE6AB33BEED1@ASHEVS006.mcilink.com>

Not that I'm helping any... 

We've always enabled monitoring on every interface whether the FWSM was
running single or multi mode and I've always taken it for granted that
it was configured that way. 

The FWSM 3.2 config guide says "In multiple context mode, you must
configure interface monitoring from within each context." 
Also that if an interface is shared between contexts you can monitor
that interface in just one context. That doesn't say a whole lot
obviously as you already know. 

Normally if you configure interface monitoring the unit runs a series of
tests (link, activity, arp, broadcast) to determine whether an interface
has failed and what should be done according to the failover policy. 

If all interfaces within a context are not monitored then I wonder, what
is the behavior of a unit booting up? Does that newly booted up context
with no monitored interface go active for some time and mess with
traffic coming/going to/from it for some period of time? Obviously the
"correct" behavior would be to "see" the peer as active and go into
standby. 

I know that for active/standby all contexts on a unit are either active
or standby but obviously something else is going on. 

What does "show monitor" on a context with no monitored interfaces look
like? 
 
Vijay Ramcharan 
  
-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Peter Rathlev
Sent: March 12, 2009 16:22
To: ayourtch at cisco.com
Cc: cisco-nsp
Subject: Re: [c-nsp] FWSM HA secondary reload & long downtime

On Wed, 2009-03-11 at 19:14 +0100, Andrew Yourtchenko wrote:
> On Wed, 11 Mar 2009, Peter Rathlev wrote:
> > This of course points to something else being the problem, not the
> > FWSM.
> 
> *bling* too strong of an assumption :).

Ironically that was a very precise observation. ;-) I've looked much
more thoroughly at the logs now, and finally I discovered what would've
taken only few moments to see had I just opened my eyes.

It turns out that more than one context had problems. I think I was
tired when I looked at the configuration differences. Specifically all
contexts with no "monitor-interface"-configuration were affected. Every
context with at least one "monitor-interface" had no problems.

I seem to remember that we stopped using "monitor-interface" in the
individual contexts a year or so back, thinking that when failover is
always system wide anyway, and since all the relevant VLANs share the
same underlying (redundant) path, we could just as well only monitor one
interface in the admin context. By chance a couple of other contexts had
some monitors that weren't removed back then.

It is of course a joy to have figured this out, but I can't seem to find
anything much on what "monitor-interface" in a multiple context setup
actually does or doesn't do.

Should every context have one monitor-interface? Should all interfaces
be monitored or just one per context?

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/

______________________________________________________________________
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 jeff-kell at utc.edu  Thu Mar 12 22:20:38 2009
From: jeff-kell at utc.edu (Jeff Kell)
Date: Thu, 12 Mar 2009 22:20:38 -0400
Subject: [c-nsp] PBR/VRF sanity check...
Message-ID: <49B9C2F6.9000903@utc.edu>

Aren't PBR and VRF mutually exclusive on all Catalysts, or are they 
possible concurrently on a 4500 or 6500?

Jeff

From td_miles at yahoo.com  Thu Mar 12 22:45:55 2009
From: td_miles at yahoo.com (Tony)
Date: Thu, 12 Mar 2009 19:45:55 -0700 (PDT)
Subject: [c-nsp] PBR/VRF sanity check...
Message-ID: <186062.14699.qm@web110109.mail.gq1.yahoo.com>


Hi Jeff,

I've tested both PBR & VRF on a 3550 with extended match routing SDM. It works, but adding VRF's when using PBR forced it to use software/CPU instead of hardware/ASIC forwarding.

This caused max PBR + VRF throughput to be just over 30Mbps with 100% CPU.

Don't know about the higher end platforms you've mentioned.


regards,
Tony.

--- On Fri, 13/3/09, Jeff Kell <jeff-kell at utc.edu> wrote:

> From: Jeff Kell <jeff-kell at utc.edu>
> Subject: [c-nsp] PBR/VRF sanity check...
> To: "'NSP List'" <cisco-nsp at puck.nether.net>
> Date: Friday, 13 March, 2009, 1:20 PM
>
> Aren't PBR and VRF mutually exclusive
> on all Catalysts, or are they possible concurrently on a
> 4500 or 6500?
> 
> Jeff
>


      


From ltd at cisco.com  Fri Mar 13 01:42:26 2009
From: ltd at cisco.com (Lincoln Dale)
Date: Fri, 13 Mar 2009 16:42:26 +1100
Subject: [c-nsp] PBR/VRF sanity check...
In-Reply-To: <49B9C2F6.9000903@utc.edu>
References: <49B9C2F6.9000903@utc.edu>
Message-ID: <49B9F242.3090305@cisco.com>

Jeff Kell wrote:
> Aren't PBR and VRF mutually exclusive on all Catalysts, or are they 
> possible concurrently on a 4500 or 6500?
Catalyst 6500:  see 
http://www.cisco.com/en/US/docs/ios/mpls/configuration/guide/mp_mltvrf_slct_pbr.html
Nexus 7000: you can certainly do 'set vrf' on PBR with it remaining in 
hardware switching path.


cheers,

lincoln.


From david.freedman at uk.clara.net  Fri Mar 13 05:04:17 2009
From: david.freedman at uk.clara.net (David Freedman)
Date: Fri, 13 Mar 2009 09:04:17 +0000
Subject: [c-nsp] Interworking on 6500s
In-Reply-To: <49B97E83.2010708@wbsconnect.com>
References: <49B97E83.2010708@wbsconnect.com>
Message-ID: <49BA2191.8060801@uk.clara.net>

I believe that layer 2 local switching is not supported on LAN cards
such as yours on your platform,


Can I just ask why you would want to do such a thing ?

Connecting two ports can be achieved by bridging them together (vlan),
you can preserve 802.1q tags with dot1qtunnelling and allow many BPDUs
to pass transparently without the device intervening using
l2protocoltunnel (l2pt)

If you wish to interwork from tagged to untagged, you could use use the
"native" vlan on a bridged pair (as above) to achieve this.

Dave.



Chris Phillips wrote:
> Looking at interworking on 6500s with SUP720-3BXLs running SXI on
> non-PA, non-OSM and non-SIP/SPA cards.  The command takes going Ethernet
> to Ethernet.
> 
> connect TEST1 FastEthernet 9/25 FastEthernet 9/26
> 
> sh connect
> 
> ID   Name            Segment 1              Segment 2 State
> ================================================================================
> 
> 6    TEST1           Fa9/25                 Fa9/26 ADMIN UP
> 
> or...
> 
> connect TEST2 FastEthernet 9/26 GigabitEthernet 7/16.4080 interworking
> ethernet
> 
> sh connect
> 
> ID   Name            Segment 1              Segment 2 State
> ================================================================================
> 
> 5    TEST2           Fa9/26                 Gi7/16.4080 ADMIN UP
> 
> However, traffic does not seem to want to pass.
> 
> Looked over a few documents online.  They seem to suggest that
> interworking is only supported on SIP/SPA, OSM and PA cards.
> 
> #######
> Cisco 7600 and 6500 Series Router Restrictions
> 
> ?Layer 2 Local Switching supports the following port adapters and
> interface processors on the Cisco 7600-SUP720/MSFC3 router:
> 
> ?All port adapters on the Enhanced FlexWAN module
> 
> ?All SPAs on the SIP-200 line cards
> 
> ?On the Cisco 6500 series and 7600 series routers, only like-to-like
> local switching is supported (ATM to ATM and Frame Relay to Frame Relay).
> 
> ?Same-port switching is not supported on the Cisco 6500 series and 7600
> series routers.
> #######
> 
> Has anyone have any experience to the contrary?
> 


From david.freedman at uk.clara.net  Fri Mar 13 05:04:17 2009
From: david.freedman at uk.clara.net (David Freedman)
Date: Fri, 13 Mar 2009 09:04:17 +0000
Subject: [c-nsp] Interworking on 6500s
In-Reply-To: <49B97E83.2010708@wbsconnect.com>
References: <49B97E83.2010708@wbsconnect.com>
Message-ID: <49BA2191.8060801@uk.clara.net>

I believe that layer 2 local switching is not supported on LAN cards
such as yours on your platform,


Can I just ask why you would want to do such a thing ?

Connecting two ports can be achieved by bridging them together (vlan),
you can preserve 802.1q tags with dot1qtunnelling and allow many BPDUs
to pass transparently without the device intervening using
l2protocoltunnel (l2pt)

If you wish to interwork from tagged to untagged, you could use use the
"native" vlan on a bridged pair (as above) to achieve this.

Dave.



Chris Phillips wrote:
> Looking at interworking on 6500s with SUP720-3BXLs running SXI on
> non-PA, non-OSM and non-SIP/SPA cards.  The command takes going Ethernet
> to Ethernet.
> 
> connect TEST1 FastEthernet 9/25 FastEthernet 9/26
> 
> sh connect
> 
> ID   Name            Segment 1              Segment 2 State
> ================================================================================
> 
> 6    TEST1           Fa9/25                 Fa9/26 ADMIN UP
> 
> or...
> 
> connect TEST2 FastEthernet 9/26 GigabitEthernet 7/16.4080 interworking
> ethernet
> 
> sh connect
> 
> ID   Name            Segment 1              Segment 2 State
> ================================================================================
> 
> 5    TEST2           Fa9/26                 Gi7/16.4080 ADMIN UP
> 
> However, traffic does not seem to want to pass.
> 
> Looked over a few documents online.  They seem to suggest that
> interworking is only supported on SIP/SPA, OSM and PA cards.
> 
> #######
> Cisco 7600 and 6500 Series Router Restrictions
> 
> ?Layer 2 Local Switching supports the following port adapters and
> interface processors on the Cisco 7600-SUP720/MSFC3 router:
> 
> ?All port adapters on the Enhanced FlexWAN module
> 
> ?All SPAs on the SIP-200 line cards
> 
> ?On the Cisco 6500 series and 7600 series routers, only like-to-like
> local switching is supported (ATM to ATM and Frame Relay to Frame Relay).
> 
> ?Same-port switching is not supported on the Cisco 6500 series and 7600
> series routers.
> #######
> 
> Has anyone have any experience to the contrary?
> 


From Steven.Glogger at swisscom.com  Fri Mar 13 05:31:00 2009
From: Steven.Glogger at swisscom.com (Steven.Glogger at swisscom.com)
Date: Fri, 13 Mar 2009 10:31:00 +0100
Subject: [c-nsp] OSPF Default Route
In-Reply-To: <BLU130-DS28A0F2E8449BA242F9176C5A10@phx.gbl>
References: <BLU130-DS28A0F2E8449BA242F9176C5A10@phx.gbl>
Message-ID: <1FC8A0BAFBBD9749BB1F06010D23C8A55F20EA7F@sg000035.corproot.net>

hi manaf

one quick "hack" would be: run 2 different ospf processes and do redistribute between them. unfortunately you're then seeing all the routes as ospf external..

-steven

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Manaf Al Oqlah
Sent: Tuesday, March 10, 2009 8:42 AM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] OSPF Default Route

Hi,

Is there any way to advertise default route in OSPF with a specific metric to an interface and another metric to another interface. For example, I want to advertise default route (default-information originate) for neighbor connected to gigabit 1/0 with metric 10 and for neighbor connected to gigabit 1/1 with metric 20.

Thank you
_______________________________________________
cisco-nsp mailing list  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  Fri Mar 13 08:34:58 2009
From: drew.weaver at thenap.com (Drew Weaver)
Date: Fri, 13 Mar 2009 05:34:58 -0700
Subject: [c-nsp] Quick question regarding trunking and routing.
Message-ID: <F3318834F1F89D46857972DD4B411D700651DA22@EXCHANGE.thenap.com>

We have a 3550 which connects to two 6500s.

The 3550 has some L3 vlans on it, but we also need to trunk a few of the ports up to the 6500s.

I've been banging my head because I cannot figure out how to make the two uplink ports on the 3550 both trunk and route.

What I mean is, currently the ports have ip addresses assigned directly to them (/30s).

I have to remove the IP to enable trunking, but then the L3 VLANs that originate directly on the 3550 no longer function.

I'm thinking there has to be some way to use uplink ports for both trunking and routing but I just can't seem to figure it out.

I realize that the "normal" network topology would be to just create all the vlans on the 6500s and just trunk everything from the 3550 to the 6500s but for legacy purposes that isn't really an option.

Any advice would be great.

thanks,
-Drew


From jfitz at Princeton.EDU  Fri Mar 13 08:49:44 2009
From: jfitz at Princeton.EDU (Jeff Fitzwater)
Date: Fri, 13 Mar 2009 08:49:44 -0400
Subject: [c-nsp] PBR/VRF sanity check...
In-Reply-To: <49B9C2F6.9000903@utc.edu>
References: <49B9C2F6.9000903@utc.edu>
Message-ID: <5C9C2326-B5CB-45B9-BB64-AAA000923FFF@princeton.edu>

Hello Jeff.
  I just implemented VRF and PBR on a 6500 720-CXL running SXI code,  
and have pushed 600Mb so far with switch CPU and Router CPU showing no  
increase.

Jeff Fitzwater
OIT Network Systems
Princeton University
On Mar 12, 2009, at 10:20 PM, Jeff Kell wrote:

> Aren't PBR and VRF mutually exclusive on all Catalysts, or are they  
> possible concurrently on a 4500 or 6500?
>
> Jeff
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


From jfitz at Princeton.EDU  Fri Mar 13 08:51:46 2009
From: jfitz at Princeton.EDU (Jeff Fitzwater)
Date: Fri, 13 Mar 2009 08:51:46 -0400
Subject: [c-nsp] PBR/VRF sanity check...
In-Reply-To: <49B9F242.3090305@cisco.com>
References: <49B9C2F6.9000903@utc.edu> <49B9F242.3090305@cisco.com>
Message-ID: <70F571C5-CAD1-4D8F-B401-D78DF9606CFE@princeton.edu>

I might mention that the "set vrf" is also in the SXI code and works  
on 6500 with 720-CXL.


Jeff Fitzwater
OIT Network Systems
Princeton University


On Mar 13, 2009, at 1:42 AM, Lincoln Dale wrote:

> Jeff Kell wrote:
>> Aren't PBR and VRF mutually exclusive on all Catalysts, or are they  
>> possible concurrently on a 4500 or 6500?
> Catalyst 6500:  see http://www.cisco.com/en/US/docs/ios/mpls/configuration/guide/mp_mltvrf_slct_pbr.html
> Nexus 7000: you can certainly do 'set vrf' on PBR with it remaining  
> in hardware switching path.
>
>
> cheers,
>
> lincoln.
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


From jfitz at Princeton.EDU  Fri Mar 13 09:02:12 2009
From: jfitz at Princeton.EDU (Jeff Fitzwater)
Date: Fri, 13 Mar 2009 09:02:12 -0400
Subject: [c-nsp] Quick question regarding trunking and routing.
In-Reply-To: <F3318834F1F89D46857972DD4B411D700651DA22@EXCHANGE.thenap.com>
References: <F3318834F1F89D46857972DD4B411D700651DA22@EXCHANGE.thenap.com>
Message-ID: <FC00F101-33C2-4ADB-ACD5-B6D4312F6372@princeton.edu>

Use an SVI for the routing and the L2 port for the trunking.

! SVI
interface vlan 100
ip address 10.10.10.10 255.255.255.0


interface gi1/0/1
switchport
switchport mode trunk
! Use the following if you need to use a native vlan.
! switchport trunk native vlan nnnn
!Use the following to restrict what vlans you want on the trunk
!  swithcport trunk allowed vlans 100,200,300,400,500
switchport nonegotiate



Jeff
On Mar 13, 2009, at 8:34 AM, Drew Weaver wrote:

> We have a 3550 which connects to two 6500s.
>
> The 3550 has some L3 vlans on it, but we also need to trunk a few of  
> the ports up to the 6500s.
>
> I've been banging my head because I cannot figure out how to make  
> the two uplink ports on the 3550 both trunk and route.
>
> What I mean is, currently the ports have ip addresses assigned  
> directly to them (/30s).
>
> I have to remove the IP to enable trunking, but then the L3 VLANs  
> that originate directly on the 3550 no longer function.
>
> I'm thinking there has to be some way to use uplink ports for both  
> trunking and routing but I just can't seem to figure it out.
>
> I realize that the "normal" network topology would be to just create  
> all the vlans on the 6500s and just trunk everything from the 3550  
> to the 6500s but for legacy purposes that isn't really an option.
>
> Any advice would be great.
>
> thanks,
> -Drew
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


From Stig.Johansen at atea.no  Fri Mar 13 09:11:10 2009
From: Stig.Johansen at atea.no (Stig Johansen)
Date: Fri, 13 Mar 2009 14:11:10 +0100
Subject: [c-nsp] Quick question regarding trunking and routing.
In-Reply-To: <F3318834F1F89D46857972DD4B411D700651DA22@EXCHANGE.thenap.com>
References: <F3318834F1F89D46857972DD4B411D700651DA22@EXCHANGE.thenap.com>
Message-ID: <5EB9799F396A304686962AFFF740ED0CE9C50312@NOOSLEXCH001.adno.local>


>We have a 3550 which connects to two 6500s.
>The 3550 has some L3 vlans on it, but we also need to trunk a few of the ports up to the 6500s.
>I've been banging my head because I cannot figure out how to make the two uplink ports on the 3550 both trunk and route.
>What I mean is, currently the ports have ip addresses assigned directly to them (/30s).
>I have to remove the IP to enable trunking, but then the L3 VLANs that originate directly on the 3550 no longer function.
>I'm thinking there has to be some way to use uplink ports for both trunking and routing but I just can't seem to figure it out.
>I realize that the "normal" network topology would be to just create all the vlans on the 6500s and just trunk everything from the 3550 to the 6500s but for legacy purposes that isn't really an option.
>Any advice would be great.

You'll have to establish one or two VLAN's between the 3550 and the 6500'es and let this VLAN over the trunk.

As in:

Old config:
interface FastEthernet0/1
 description to 6500-1
 ip address 1.2.3.2 255.255.255.252
!
interface FastEthernet0/2
 description to 6500-2
 ip address 2.3.4.2 255.255.255.252

New config:
vlan 100
 name 3550-to-6500-1
!
vlan 200
 name 3550-to-6500-2
!
interface FastEthernet0/1
 description L2 to 6500-1
 switchport
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 100   ! And all of the other VLAN's you want to trunk up to 6500-1.
 switchport mode trunk
!
interface FastEthernet0/2
 description L2 to 6500-2
 switchport
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 200   ! And all of the other VLAN's you want to trunk up to 6500-2.
 switchport mode trunk
!
interface Vlan100
 description L3 to 6500-1
 ip address 1.2.3.2 255.255.255.252
!
interface Vlan200
 description L3 to 6500-2
 ip address 2.3.4.2 255.255.255.252
!

Best regards,
Stig Meireles Johansen

From jeff-kell at utc.edu  Fri Mar 13 09:27:26 2009
From: jeff-kell at utc.edu (Jeff Kell)
Date: Fri, 13 Mar 2009 09:27:26 -0400
Subject: [c-nsp] Quick question regarding trunking and routing.
In-Reply-To: <F3318834F1F89D46857972DD4B411D700651DA22@EXCHANGE.thenap.com>
References: <F3318834F1F89D46857972DD4B411D700651DA22@EXCHANGE.thenap.com>
Message-ID: <49BA5F3E.10006@utc.edu>

Drew Weaver wrote:
> We have a 3550 which connects to two 6500s.
> The 3550 has some L3 vlans on it, but we also need to trunk a few of the ports up to the 6500s.
> I've been banging my head because I cannot figure out how to make the two uplink ports on the 3550 both trunk and route.
> What I mean is, currently the ports have ip addresses assigned directly to them (/30s).

Take your /30 endpoints and make them SVIs on an unused vlan, and add
that vlan to the trunk allowed vlans.  If you slap 'ip address' on an
interface, it's going to be an L3 endpoint.  But keeping an SVI should
let you do what you want, provided that you properly "prune" the trunk
on both ends (switchport trunk allowed vlan ...) to avoid unintended
leakage over the trunk.

Jeff



From denyipanyany at gmail.com  Fri Mar 13 09:41:21 2009
From: denyipanyany at gmail.com (Deny IP Any Any)
Date: Fri, 13 Mar 2009 09:41:21 -0400
Subject: [c-nsp] determining cause of CPU spike in ASA after-the-fact?
Message-ID: <c979a8a40903130641gbcb09c0yb2a9f96750fe7a58@mail.gmail.com>

Hello. I've got a pair of Cisco ASA 5540s running the latest 8.0.4 in
an active/standby cluster; early this morning the CPU on the active
box went from 3% to 100% (as reported by SNMP), and sat there for
about 20 minutes. The only thing in the logs during this time is the
Active unit started testing one of the interfaces about 4 times a
minute (not sure if this was the cause or a symptom); by the time I
was woken up to look at it, the CPU usage was back to normal. It does
strike me as slightly odd that the Secondary ASA didn't report losing
comm with the Primary during this same period.

Is there any way to, after-the-fact, figure out the cause of this? A
'show processes cpu-hog' doesn't show any thing during the time frame.

Mar 13 2009 01:47:22: %ASA-1-105005: (Primary) Lost Failover
communications with mate on interface webdmz
Mar 13 2009 01:47:22: %ASA-1-105008: (Primary) Testing Interface webdmz
Mar 13 2009 01:47:23: %ASA-1-105009: (Primary) Testing on interface
webdmz Passed
Mar 13 2009 01:47:37: %ASA-1-105005: (Primary) Lost Failover
communications with mate on interface webdmz
Mar 13 2009 01:47:37: %ASA-1-105008: (Primary) Testing Interface webdmz
Mar 13 2009 01:47:38: %ASA-1-105009: (Primary) Testing on interface
webdmz Passed
Mar 13 2009 01:48:02: %ASA-1-105005: (Primary) Lost Failover
communications with mate on interface webdmz
Mar 13 2009 01:48:02: %ASA-1-105008: (Primary) Testing Interface webdmz
Mar 13 2009 01:48:03: %ASA-1-105009: (Primary) Testing on interface
webdmz Passed
Mar 13 2009 01:48:17: %ASA-1-105005: (Primary) Lost Failover
communications with mate on interface webdmz
Mar 13 2009 01:48:17: %ASA-1-105008: (Primary) Testing Interface webdmz
Mar 13 2009 01:48:18: %ASA-1-105009: (Primary) Testing on interface
webdmz Passed
Mar 13 2009 01:48:32: %ASA-1-105005: (Primary) Lost Failover
communications with mate on interface webdmz
Mar 13 2009 01:48:32: %ASA-1-105008: (Primary) Testing Interface webdmz
Mar 13 2009 01:48:33: %ASA-1-105009: (Primary) Testing on interface
webdmz Passed
Mar 13 2009 01:48:52: %ASA-1-105005: (Primary) Lost Failover
communications with mate on interface webdmz
Mar 13 2009 01:48:52: %ASA-1-105008: (Primary) Testing Interface webdmz
Mar 13 2009 01:48:53: %ASA-1-105009: (Primary) Testing on interface
webdmz Passed

-- 
deny ip any any (4393649193 matches)

From schilling2006 at gmail.com  Fri Mar 13 10:48:28 2009
From: schilling2006 at gmail.com (schilling)
Date: Fri, 13 Mar 2009 10:48:28 -0400
Subject: [c-nsp] Cisco ACL Manager 1.6 Broke after enable MPLS
Message-ID: <bd3771a60903130748t13112063wab48ad2df6aa4019@mail.gmail.com>

Hi All,

We had ACL manager 1.6 managing ACLs on our Catalyst 6500. We recently
enabled MPLS on some of our core switches, ACL manger now will not open the
device. The error is "Exception while getting device attributes: IDL
AclmModule/AclmException:1.0".

We only did the following in terms of MPLS.

int loopback10
 description MPLS-LDP-ID
 ip address 192.168.253.5 255.255.255.255

ip access-list standard mpls-loopbacks-only
 permit 192.168.253.0 0.0.0.63
 permit any
exit
mpls label protocol ldp
mpls ldp router-id loopback10 force
no mpls ldp advertise-labels
mpls ldp advertise-labels for mpls-loopbacks-only

Then enabled mpls ip on backbone vlans.

I sniffed the traffic of working one, ACL manager is using snmp and tftp to
change the router configuration in our environment.

Could somebody give some insight on this?

Thanks.

Schilling

From ray at oneunified.net  Fri Mar 13 11:48:15 2009
From: ray at oneunified.net (Ray Burkholder)
Date: Fri, 13 Mar 2009 12:48:15 -0300
Subject: [c-nsp] 15km optics
In-Reply-To: <Pine.LNX.4.64.0903111901550.21155@zippy.stdio.be>
References: <1236633344.3572.13.camel@localhost.localdomain>
	<Pine.LNX.4.64.0903101125050.6781@zippy.stdio.be>
	<1236719408.4513.51.camel@localhost.localdomain>
	<Pine.LNX.4.64.0903111101340.21155@zippy.stdio.be>	<1236793626.3563.339.camel@localhost.localdomain>
	<Pine.LNX.4.64.0903111901550.21155@zippy.stdio.be>
Message-ID: <33f001c9a3f3$3de0c190$b9a244b0$@net>

I have a carrier which has about 13km to 15km of fibre to their CO.  They
run 1310 nm alcatel equipment on their end.  I was wanting to use a Cisco
GLC-LH-SM on my end but that is rated for 10km.  The GLC-ZX-SM is 1550 nm
70km device which is incompatible.  

Does anyone have suggestions on how to complete this link?  inexpensive
optical regenerator?  small intermediate alcaltel box?   a cisco SFP running
1310 nm and has longer range?

Ray


-- 
Scanned for viruses and dangerous content at 
http://www.oneunified.net and is believed to be clean.


From paul at paulstewart.org  Fri Mar 13 12:07:50 2009
From: paul at paulstewart.org (Paul Stewart)
Date: Fri, 13 Mar 2009 12:07:50 -0400
Subject: [c-nsp] 15km optics
In-Reply-To: <33f001c9a3f3$3de0c190$b9a244b0$@net>
References: <1236633344.3572.13.camel@localhost.localdomain>	<Pine.LNX.4.64.0903101125050.6781@zippy.stdio.be>	<1236719408.4513.51.camel@localhost.localdomain>	<Pine.LNX.4.64.0903111101340.21155@zippy.stdio.be>	<1236793626.3563.339.camel@localhost.localdomain>	<Pine.LNX.4.64.0903111901550.21155@zippy.stdio.be>
	<33f001c9a3f3$3de0c190$b9a244b0$@net>
Message-ID: <000301c9a3f5$e8f057b0$bad10710$@org>

Hi Ray..

Use the ZX SFP and check the levels - if needed, put attenuators inline to
drop the signal back down.... we have some runs with ZX in place at 12-15km
and no attenuation with no issues - they have been in place for several
years now...

I don't have the specs but the receiver sensitivity I believe is the key
(what highs and lows it can tolerate).... someone may have a more technical
explanation for you ;)

Take care,

Paul


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Ray Burkholder
Sent: Friday, March 13, 2009 11:48 AM
To: 'cisco-nsp'
Subject: [c-nsp] 15km optics

I have a carrier which has about 13km to 15km of fibre to their CO.  They
run 1310 nm alcatel equipment on their end.  I was wanting to use a Cisco
GLC-LH-SM on my end but that is rated for 10km.  The GLC-ZX-SM is 1550 nm
70km device which is incompatible.  

Does anyone have suggestions on how to complete this link?  inexpensive
optical regenerator?  small intermediate alcaltel box?   a cisco SFP running
1310 nm and has longer range?

Ray


-- 
Scanned for viruses and dangerous content at 
http://www.oneunified.net and is believed to be clean.

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



From greg at ip-man.net  Fri Mar 13 12:15:31 2009
From: greg at ip-man.net (Gregoire Huet)
Date: Fri, 13 Mar 2009 17:15:31 +0100
Subject: [c-nsp] 15km optics
In-Reply-To: <33f001c9a3f3$3de0c190$b9a244b0$@net>
References: <1236633344.3572.13.camel@localhost.localdomain>	<Pine.LNX.4.64.0903101125050.6781@zippy.stdio.be>	<1236719408.4513.51.camel@localhost.localdomain>	<Pine.LNX.4.64.0903111101340.21155@zippy.stdio.be>	<1236793626.3563.339.camel@localhost.localdomain>	<Pine.LNX.4.64.0903111901550.21155@zippy.stdio.be>
	<33f001c9a3f3$3de0c190$b9a244b0$@net>
Message-ID: <49BA86A3.6020102@ip-man.net>

Ray Burkholder a ?crit :
> I have a carrier which has about 13km to 15km of fibre to their CO.  They
> run 1310 nm alcatel equipment on their end.  I was wanting to use a Cisco
> GLC-LH-SM on my end but that is rated for 10km.  The GLC-ZX-SM is 1550 nm
> 70km device which is incompatible.  

Hello

We have a 16km link on 1310 fiber with LH, it works perfectly, so it might
be worth giving it a try.

Greg


From Marcus.Gerdon at versatel.de  Fri Mar 13 12:23:36 2009
From: Marcus.Gerdon at versatel.de (Marcus.Gerdon)
Date: Fri, 13 Mar 2009 17:23:36 +0100
Subject: [c-nsp] 15km optics
Message-ID: <227142482560EF458FF1F7E784E26AB84ADBB3@FLBVEXCH01.versatel.local>

Ray,

best check the transmission power and sensibility of the SFP (just look it up at Cisco's site) against the attenuation of the fibers (both directions).

Longest link I had working were 14.6 km according OTDR with a LX GBIC and up to 12 km occur quite some time, so there's the possibility this will still work with LH-SM. Of course nearly fully utilizing the power budget raises the risk of fiber caused connection outage as a bend in a patch can become the .5 dB to much attenuation.

Attenuated ZX is the saver one, so maybe converting 1310 to 1550 in the CO might be an option.


regards,

Marcus


> -----Urspr?ngliche Nachricht-----
> Von: cisco-nsp-bounces at puck.nether.net 
> [mailto:cisco-nsp-bounces at puck.nether.net] Im Auftrag von Ray 
> Burkholder
> Gesendet: Freitag, 13. M?rz 2009 16:48
> An: 'cisco-nsp'
> Betreff: [c-nsp] 15km optics
> 
> I have a carrier which has about 13km to 15km of fibre to 
> their CO.  They
> run 1310 nm alcatel equipment on their end.  I was wanting to 
> use a Cisco
> GLC-LH-SM on my end but that is rated for 10km.  The 
> GLC-ZX-SM is 1550 nm
> 70km device which is incompatible.  
> 
> Does anyone have suggestions on how to complete this link?  
> inexpensive
> optical regenerator?  small intermediate alcaltel box?   a 
> cisco SFP running
> 1310 nm and has longer range?
> 
> Ray
> 
> 
> -- 
> Scanned for viruses and dangerous content at 
> http://www.oneunified.net and is believed to be clean.
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 

From gert at greenie.muc.de  Fri Mar 13 12:57:13 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Fri, 13 Mar 2009 17:57:13 +0100
Subject: [c-nsp] 15km optics
In-Reply-To: <33f001c9a3f3$3de0c190$b9a244b0$@net>
References: <1236633344.3572.13.camel@localhost.localdomain>
	<Pine.LNX.4.64.0903101125050.6781@zippy.stdio.be>
	<1236719408.4513.51.camel@localhost.localdomain>
	<Pine.LNX.4.64.0903111101340.21155@zippy.stdio.be>
	<1236793626.3563.339.camel@localhost.localdomain>
	<Pine.LNX.4.64.0903111901550.21155@zippy.stdio.be>
	<33f001c9a3f3$3de0c190$b9a244b0$@net>
Message-ID: <20090313165713.GC290@greenie.muc.de>

Hi,

On Fri, Mar 13, 2009 at 12:48:15PM -0300, Ray Burkholder wrote:
> I have a carrier which has about 13km to 15km of fibre to their CO.  They
> run 1310 nm alcatel equipment on their end.  I was wanting to use a Cisco
> GLC-LH-SM on my end but that is rated for 10km.  The GLC-ZX-SM is 1550 nm
> 70km device which is incompatible.  
> 
> Does anyone have suggestions on how to complete this link?  inexpensive
> optical regenerator?  small intermediate alcaltel box?   a cisco SFP running
> 1310 nm and has longer range?

There's 3rd-party "LX40" modules that are 1310 and can go up to 40km,
available as GBIC or SFP.

We use a few of those and are quite happy.  Of course IOS complains 
"bah, bah, don't do that".

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/20090313/ba0d523d/attachment.bin>

From md at bts.sk  Fri Mar 13 13:00:06 2009
From: md at bts.sk (=?UTF-8?Q?Marian_=C4=8Eurkovi=C4=8D?=)
Date: Fri, 13 Mar 2009 18:00:06 +0100
Subject: [c-nsp] 15km optics
In-Reply-To: <33f001c9a3f3$3de0c190$b9a244b0$@net>
References: <1236633344.3572.13.camel@localhost.localdomain>
	<Pine.LNX.4.64.0903101125050.6781@zippy.stdio.be>
	<1236719408.4513.51.camel@localhost.localdomain>
	<Pine.LNX.4.64.0903111101340.21155@zippy.stdio.be>	<1236793626.3563.339.camel@localhost.localdomain>
	<Pine.LNX.4.64.0903111901550.21155@zippy.stdio.be>
	<33f001c9a3f3$3de0c190$b9a244b0$@net>
Message-ID: <20090313165221.M33041@bts.sk>

On Fri, 13 Mar 2009 12:48:15 -0300, Ray Burkholder wrote
> I have a carrier which has about 13km to 15km of fibre to their CO.  They
> run 1310 nm alcatel equipment on their end.  I was wanting to use a Cisco
> GLC-LH-SM on my end but that is rated for 10km.  The GLC-ZX-SM is 1550 
> nm 70km device which is incompatible.
> 
> Does anyone have suggestions on how to complete this link?  inexpensive
> optical regenerator?  small intermediate alcaltel box?   a cisco SFP running
> 1310 nm and has longer range?

SFPs for 20 km, 40 km or even 55 km reach running at 1310 nm are commonly
available on the market, but not from Cisco. Power budget upto 22 dB could
be supported at 1310 nm.

   With kind regards,

          M.

From swmike at swm.pp.se  Fri Mar 13 14:21:15 2009
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Fri, 13 Mar 2009 19:21:15 +0100 (CET)
Subject: [c-nsp] 15km optics
In-Reply-To: <33f001c9a3f3$3de0c190$b9a244b0$@net>
References: <1236633344.3572.13.camel@localhost.localdomain>
	<Pine.LNX.4.64.0903101125050.6781@zippy.stdio.be>
	<1236719408.4513.51.camel@localhost.localdomain>
	<Pine.LNX.4.64.0903111101340.21155@zippy.stdio.be>
	<1236793626.3563.339.camel@localhost.localdomain>
	<Pine.LNX.4.64.0903111901550.21155@zippy.stdio.be>
	<33f001c9a3f3$3de0c190$b9a244b0$@net>
Message-ID: <alpine.DEB.1.10.0903131919001.25843@uplift.swm.pp.se>

On Fri, 13 Mar 2009, Ray Burkholder wrote:

> I have a carrier which has about 13km to 15km of fibre to their CO.  They
> run 1310 nm alcatel equipment on their end.  I was wanting to use a Cisco
> GLC-LH-SM on my end but that is rated for 10km.  The GLC-ZX-SM is 1550 nm
> 70km device which is incompatible.

Why is the ZX incompatible?

"All" 1310nm optics have wideband receivers so getting the ZX into the LX 
at the other end is not a problem (apart from that you might want to 
attenuate it 5-10dB at the ZX launch end), and the ZX has -24dB receiver 
sensitivity meaning you gain there as well.

This works. Been there done, that plenty of times.

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

From skoal at skoal.name  Fri Mar 13 15:18:35 2009
From: skoal at skoal.name (Gergely Antal)
Date: Fri, 13 Mar 2009 20:18:35 +0100
Subject: [c-nsp] 15km optics
In-Reply-To: <20090313165713.GC290@greenie.muc.de>
References: <1236633344.3572.13.camel@localhost.localdomain>	<Pine.LNX.4.64.0903101125050.6781@zippy.stdio.be>	<1236719408.4513.51.camel@localhost.localdomain>	<Pine.LNX.4.64.0903111101340.21155@zippy.stdio.be>	<1236793626.3563.339.camel@localhost.localdomain>	<Pine.LNX.4.64.0903111901550.21155@zippy.stdio.be>	<33f001c9a3f3$3de0c190$b9a244b0$@net>
	<20090313165713.GC290@greenie.muc.de>
Message-ID: <49BAB18B.3040007@skoal.name>

Is there similar options also in the 10G market...
I have the same problem like Ray but on 10G
with cisco LR modules i have -16.5 RX receive power,and the telco says
that thay dont support ER or ZR.


Gert Doering wrote:
> Hi,
> 
> On Fri, Mar 13, 2009 at 12:48:15PM -0300, Ray Burkholder wrote:
>> I have a carrier which has about 13km to 15km of fibre to their CO.  They
>> run 1310 nm alcatel equipment on their end.  I was wanting to use a Cisco
>> GLC-LH-SM on my end but that is rated for 10km.  The GLC-ZX-SM is 1550 nm
>> 70km device which is incompatible.  
>>
>> Does anyone have suggestions on how to complete this link?  inexpensive
>> optical regenerator?  small intermediate alcaltel box?   a cisco SFP running
>> 1310 nm and has longer range?
> 
> There's 3rd-party "LX40" modules that are 1310 and can go up to 40km,
> available as GBIC or SFP.
> 
> We use a few of those and are quite happy.  Of course IOS complains 
> "bah, bah, don't do that".
> 
> gert

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090313/c6248db0/attachment.bin>

From ayourtch at cisco.com  Fri Mar 13 15:37:45 2009
From: ayourtch at cisco.com (Andrew Yourtchenko)
Date: Fri, 13 Mar 2009 20:37:45 +0100 (CET)
Subject: [c-nsp] FWSM HA secondary reload & long downtime
In-Reply-To: <1236889348.4133.15.camel@localhost.localdomain>
References: <1236633344.3572.13.camel@localhost.localdomain> 
	<Pine.LNX.4.64.0903101125050.6781@zippy.stdio.be> 
	<1236719408.4513.51.camel@localhost.localdomain> 
	<Pine.LNX.4.64.0903111101340.21155@zippy.stdio.be> 
	<1236793626.3563.339.camel@localhost.localdomain> 
	<Pine.LNX.4.64.0903111901550.21155@zippy.stdio.be>
	<1236889348.4133.15.camel@localhost.localdomain>
Message-ID: <Pine.LNX.4.64.0903132033250.17437@zippy.stdio.be>



On Thu, 12 Mar 2009, Peter Rathlev wrote:

> On Wed, 2009-03-11 at 19:14 +0100, Andrew Yourtchenko wrote:
>> On Wed, 11 Mar 2009, Peter Rathlev wrote:
>>> This of course points to something else being the problem, not the
>>> FWSM.
>>
>> *bling* too strong of an assumption :).
>
> Ironically that was a very precise observation. ;-) I've looked much
> more thoroughly at the logs now, and finally I discovered what would've
> taken only few moments to see had I just opened my eyes.
>
> It turns out that more than one context had problems. I think I was
> tired when I looked at the configuration differences. Specifically all
> contexts with no "monitor-interface"-configuration were affected. Every
> context with at least one "monitor-interface" had no problems.
>
> I seem to remember that we stopped using "monitor-interface" in the
> individual contexts a year or so back, thinking that when failover is
> always system wide anyway, and since all the relevant VLANs share the
> same underlying (redundant) path, we could just as well only monitor one
> interface in the admin context. By chance a couple of other contexts had
> some monitors that weren't removed back then.
>
> It is of course a joy to have figured this out, but I can't seem to find
> anything much on what "monitor-interface" in a multiple context setup
> actually does or doesn't do.

if all the interfaces go over the exact same path, there is probably not 
an entirely huge benefit of it.

>
> Should every context have one monitor-interface? Should all interfaces
> be monitored or just one per context?


>From the practical perspective, if the "magic trick" of having at least 
one monitored interface per context solves it - business needs first, 
let's put it in. But otherwise it should not be needed. Would be very cool 
if you have some cycles to try this in the lab - if this is reproducible, 
I think we should treat it as a bug if not already. I'm on PTO the next 
two weeks, after that open the SR# and shoot me unicast.

cheers,
andrew

From ajadav at gmail.com  Fri Mar 13 16:25:52 2009
From: ajadav at gmail.com (Asheesh Jadav)
Date: Fri, 13 Mar 2009 13:25:52 -0700
Subject: [c-nsp] Fast Reroute - Detour Object support ?
Message-ID: <b247bbf20903131325s3802b8a4v9ed1f8c670aa6ffb@mail.gmail.com>

Hi,

   Is the DETOUR Object as specified in RFC 4090 supported on Cisco IOS? I'm
trying to set up a detour through a Cisco 7600 but the system doesn't seem
to like the PATH message. I'm using the  Version 12.2(33)SRB5 on a 7600
chassis.

Router#
Router#
*Sep  5 07:21:10.999: RSVP: Found unknown object (63) when parsing message
*Sep  5 07:21:10.999: RSVP: 7.7.7.7_1->8.8.8.8_1[7.7.7.7]: Found unknown
object (63) when parsing Path message
*Sep  5 07:21:10.999: RSVP: 7.7.7.7_1->8.8.8.8_1[7.7.7.7]: Sending PathError
message to 20.20.20.7
*Sep  5 07:21:11.007: RSVP-MSG: 7.7.7.7_1->8.8.8.8_1[7.7.7.7]: Received
PathTear message from 7.7.7.7 (on GigabitEthernet4/1)
Router#
Router#show mod
Mod Ports Card Type                              Model              Serial
No.
--- ----- -------------------------------------- ------------------
-----------
  4    8  8 port 1000mb GBIC Enhanced QoS        WS-X6408A-GBIC
SAL0735KZKL
  5    2  Supervisor Engine 720 (Active)         WS-SUP720-3B
SAL1208GKQA

Mod MAC addresses                       Hw    Fw           Sw
Status
--- ---------------------------------- ------ ------------ ------------
-------
  4  000d.bdf5.2bbc to 000d.bdf5.2bc3   3.0   5.4(2)       8.6(0.434)BA Ok
  5  0017.9444.2688 to 0017.9444.268b   5.3   8.5(2)       12.2(33)SRB5 Ok

Mod  Sub-Module                  Model              Serial       Hw
Status
---- --------------------------- ------------------ ----------- -------
-------
  5  Policy Feature Card 3       WS-F6K-PFC3B       SAL1126W66V  2.2    Ok
  5  MSFC3 Daughterboard         WS-SUP720          SAL1126W66E  2.3    Ok

Mod  Online Diag Status
---- -------------------
  4  Pass
  5  Pass
Router#


Thanks.

Asheesh

From tdurack at gmail.com  Fri Mar 13 16:30:50 2009
From: tdurack at gmail.com (Tim Durack)
Date: Fri, 13 Mar 2009 16:30:50 -0400
Subject: [c-nsp] 12.2(33)SXI vpnv6
Message-ID: <9e246b4d0903131330v72e9d04dgce7d78273faeac89@mail.gmail.com>

I'm running 12.2(33)SXI on some boxes in a PE-PE setup. I'm trying to enable
vpnv6. BGP side of things is working:

rtr-1#sh ipv6 route vrf v101
IPv6 Routing Table - v101 - 4 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
       B - BGP, R - RIP, I1 - ISIS L1, I2 - ISIS L2
       IA - ISIS interarea, IS - ISIS summary, D - EIGRP, EX - EIGRP
external
       O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
       ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
B   1:0:1:1::1/128 [200/0]
     via 1:0:1970::1%Default, indirectly connected
B   1:0:1:1::2/128 [200/0]
     via 1:0:1970::2%Default, indirectly connected
LC  1:0:1970:1::3/128 [0/0]
     via Loopback101, receive
L   FF00::/8 [0/0]
     via Null0, receive

But cef/labels aren't being programmed:

rtr-1#sh mls cef ipv6 vrf v101

Codes: + - Push label
Index  Prefix                              Adjacency
196640 1:0:1970:1::3/128                receive
196672 ::/127                              drop
196704 FE80::/10                           receive
196736 FF00::/8                            glean
197152 ::/0                                drop

vpnv4 is working fine, IPv6 in the global table is working, but not vpnv6.

Any ideas?

Tim:>

From ras at e-gerbil.net  Fri Mar 13 16:48:17 2009
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Fri, 13 Mar 2009 15:48:17 -0500
Subject: [c-nsp] 15km optics
In-Reply-To: <33f001c9a3f3$3de0c190$b9a244b0$@net>
References: <1236633344.3572.13.camel@localhost.localdomain>
	<Pine.LNX.4.64.0903101125050.6781@zippy.stdio.be>
	<1236719408.4513.51.camel@localhost.localdomain>
	<Pine.LNX.4.64.0903111101340.21155@zippy.stdio.be>
	<1236793626.3563.339.camel@localhost.localdomain>
	<Pine.LNX.4.64.0903111901550.21155@zippy.stdio.be>
	<33f001c9a3f3$3de0c190$b9a244b0$@net>
Message-ID: <20090313204817.GE51443@gerbil.cluepon.net>

On Fri, Mar 13, 2009 at 12:48:15PM -0300, Ray Burkholder wrote:
> I have a carrier which has about 13km to 15km of fibre to their CO.  They
> run 1310 nm alcatel equipment on their end.  I was wanting to use a Cisco
> GLC-LH-SM on my end but that is rated for 10km.  The GLC-ZX-SM is 1550 nm
> 70km device which is incompatible.  

I think this has already been answered to death by everyone else on the 
list, but I'd like to try and summarize a few points into something 
which can be pointed to on the list archives the next time someone asks 
this question.

1. All SMF optics have wideband receivers and will happily accept any
signal from any other source (typically 1270-1610nm), with absolutely no
requirement that it match what the other side is sending. Don't think of
a fiber circuit as a single link, think of it as two completely distinct
links running in opposite directions which just happen to be parallel to
each other for TX and RX.

2. Distances specified on optics mean absolutely nothing, they are there 
to give you a rough estimation of what you could expect under the worst 
possible conditions. Optical budget (and at higher speeds, things like 
dispersion penalties) are pretty much all you care about (ignoring goofy 
things like reflections which aren't relevent to this discussion).

3. Not all optics perform the same. Think of it like how processors are
made, they make a batch and some of them perform better than others. A
certain number perform completely outside of spec and have to be thrown
away, but even within the "good" batch there will be varying levels of
performance and quality.

For example, Cisco LX/LH optics have a TX power spec of between -3 to
-9.5 dBm, and a RX power spec of between -3 to -20 dBm. The max TX of -3
is so that incase you have two LX optics side by side, the signal isn't
so strong that it blinds the other side. The distance spec is calculated
assuming the worst possible conditions, a TX over -9.5 dBm, running over
old crappy SMF28 fiber. In reality, you're likely to find that most of 
your LX/LH optics operate much closer to the -3 side than the -9.5 side, 
and infact you may find some that are hotter than spec. Fixing something 
thats too hot is easy, you just add an attenuator. You'll find that you 
can almost always go at least 2dB below your RX budget too, before you 
actually start taking errors. Think of it like the max capacity sign on 
an elevator, they actually make the steel cables to hold many times more 
than that max capacity, "just incase".

Also optics tend to cool over time, so what shipped as a +1 might end up 
as a -1 after a few years, and they don't want your link randomly going 
out and you complaining. :)

4. Often times, links can be extended simply by changing out one side of 
the pair with a longer reach optic. When you upgrade one side, not only 
do you increase the transmitted signal strength (and often switch the 
signal from 1310 to 1550, which has a lower rate of loss per unit of 
distance), you're also increasing the receiver sensitivity. The far side 
can hear you because you're transmitting a stronger signal in a band 
that has less loss over distance, and you can hear the far side because 
you have a more sensitive receiver.

At the end of the day, almost all your questions (well at least all the 
simple ones :P) can be answered by a light meter or integrated optical 
monitoring on newer optics. Anyone who doesn't have a light meter would 
do well to get themselves over to ebay and spend a couple hundred bucks. 

<rant>
Also, please for the love of god read the instruction manual and learn 
the difference between "absolute power mode" (i.e. how much signal am I 
receiving?) and "relative loss mode" (i.e. how much loss does this cable 
have assuming that there is a known fixed-strength signal generator on 
the other side?). I'm seriously sick and tired of 95% of supposedly 
trained remote hands techs telling me I'm transmitting +65dBm. :)
</rant>

-- 
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 tdurack at gmail.com  Fri Mar 13 17:00:53 2009
From: tdurack at gmail.com (Tim Durack)
Date: Fri, 13 Mar 2009 17:00:53 -0400
Subject: [c-nsp] 12.2(33)SXI vpnv6
In-Reply-To: <49BAC823.6080901@whack.org>
References: <9e246b4d0903131330v72e9d04dgce7d78273faeac89@mail.gmail.com>
	<49BAC823.6080901@whack.org>
Message-ID: <9e246b4d0903131400v527bf7e2s483b284155e3e416@mail.gmail.com>

On Fri, Mar 13, 2009 at 4:54 PM, Bruce Pinsky <bep at whack.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Tim Durack wrote:
> > I'm running 12.2(33)SXI on some boxes in a PE-PE setup. I'm trying to
> enable
> > vpnv6. BGP side of things is working:
> >
> > rtr-1#sh ipv6 route vrf v101
> > IPv6 Routing Table - v101 - 4 entries
> > Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
> >        B - BGP, R - RIP, I1 - ISIS L1, I2 - ISIS L2
> >        IA - ISIS interarea, IS - ISIS summary, D - EIGRP, EX - EIGRP
> > external
> >        O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext
> 2
> >        ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
> > B   1:0:1:1::1/128 [200/0]
> >      via 1:0:1970::1%Default, indirectly connected
> > B   1:0:1:1::2/128 [200/0]
> >      via 1:0:1970::2%Default, indirectly connected
> > LC  1:0:1970:1::3/128 [0/0]
> >      via Loopback101, receive
> > L   FF00::/8 [0/0]
> >      via Null0, receive
> >
> > But cef/labels aren't being programmed:
> >
> > rtr-1#sh mls cef ipv6 vrf v101
> >
> > Codes: + - Push label
> > Index  Prefix                              Adjacency
> > 196640 1:0:1970:1::3/128                receive
> > 196672 ::/127                              drop
> > 196704 FE80::/10                           receive
> > 196736 FF00::/8                            glean
> > 197152 ::/0                                drop
> >
> > vpnv4 is working fine, IPv6 in the global table is working, but not
> vpnv6.
> >
> > Any ideas?
> >
>
> Got a config?
>
> Assume you did enable "mls ipv6 vrf"...
>

Yup:

rtr-1#sh run | i mls ipv6 vrf
mls ipv6 vrf

(same on all PE)

From rinse.kloek at isp.solcon.nl  Fri Mar 13 16:13:32 2009
From: rinse.kloek at isp.solcon.nl (Rinse Kloek)
Date: Fri, 13 Mar 2009 21:13:32 +0100
Subject: [c-nsp] PPPoEoQinQ works but PPPoE o VLAN doesn't on 7600
Message-ID: <49BABE6C.4040805@isp.solcon.nl>

Hello,

I try to do PPPoE terminating of sessions on a 7600-RSP7203C with 
WS-X6724-SFP Lan cards (12.2(33)SRC).  I have a trunk that carries VLAN 
710 and is connected to Gi1/1:
The following config with pppoe enabled on the physical interface, 
doesn't work. The CPU doesn't process the PPPoE packets.

interface GigabitEthernet1/1
description "Trunk with VLAN 710 for PPPoE"
no ip address
vlan-id dot1q 710
 pppoe enable group global
 exit-vlan-config
!
!

However, when I do dot1q tunneling, PPPoE packets get processed:

interface GigabitEthernet1/1
description "Trunk with VLAN 710 for PPPoE"
switchport
switchport access vlan 720
switchport mode dot1q-tunnel
!

interface vlan 720
no ip address
vlan-id dot1q 710
 pppoe enable group global
 exit-vlan-config
!
!

What do I miss. Do the Cisco WS-X67xx LAN cards discard PPPoE packets 
and only process them when doing dot1q tunneling ?

Rinse Kloek

From bep at whack.org  Fri Mar 13 16:54:59 2009
From: bep at whack.org (Bruce Pinsky)
Date: Fri, 13 Mar 2009 13:54:59 -0700
Subject: [c-nsp] 12.2(33)SXI vpnv6
In-Reply-To: <9e246b4d0903131330v72e9d04dgce7d78273faeac89@mail.gmail.com>
References: <9e246b4d0903131330v72e9d04dgce7d78273faeac89@mail.gmail.com>
Message-ID: <49BAC823.6080901@whack.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tim Durack wrote:
> I'm running 12.2(33)SXI on some boxes in a PE-PE setup. I'm trying to enable
> vpnv6. BGP side of things is working:
> 
> rtr-1#sh ipv6 route vrf v101
> IPv6 Routing Table - v101 - 4 entries
> Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
>        B - BGP, R - RIP, I1 - ISIS L1, I2 - ISIS L2
>        IA - ISIS interarea, IS - ISIS summary, D - EIGRP, EX - EIGRP
> external
>        O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
>        ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
> B   1:0:1:1::1/128 [200/0]
>      via 1:0:1970::1%Default, indirectly connected
> B   1:0:1:1::2/128 [200/0]
>      via 1:0:1970::2%Default, indirectly connected
> LC  1:0:1970:1::3/128 [0/0]
>      via Loopback101, receive
> L   FF00::/8 [0/0]
>      via Null0, receive
> 
> But cef/labels aren't being programmed:
> 
> rtr-1#sh mls cef ipv6 vrf v101
> 
> Codes: + - Push label
> Index  Prefix                              Adjacency
> 196640 1:0:1970:1::3/128                receive
> 196672 ::/127                              drop
> 196704 FE80::/10                           receive
> 196736 FF00::/8                            glean
> 197152 ::/0                                drop
> 
> vpnv4 is working fine, IPv6 in the global table is working, but not vpnv6.
> 
> Any ideas?
> 

Got a config?

Assume you did enable "mls ipv6 vrf"...

- --
=========
bep

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkm6yCMACgkQE1XcgMgrtyboiwCgyBTo9Cf9MZjOh089Zc7UgxSM
TwMAn0b70Quqei+R/+S7ldKtePLDII6d
=184z
-----END PGP SIGNATURE-----

From sethm at rollernet.us  Fri Mar 13 18:35:26 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Fri, 13 Mar 2009 15:35:26 -0700
Subject: [c-nsp] HWIC-4T1/E1 Platform Support
Message-ID: <49BADFAE.9030900@rollernet.us>

I'm looking at the HWIC-4T1/E1 and according to its data sheet, it's
only supported in the 2821, 2851 and 3800's. On the 2800 data sheet, the
big table says it's OK for all 2800's. Which one is correct?

~Seth

From todd at newfrontierssolutions.com  Fri Mar 13 19:38:01 2009
From: todd at newfrontierssolutions.com (Todd Shipway)
Date: Fri, 13 Mar 2009 19:38:01 -0400
Subject: [c-nsp] Virtual Access int down after IOS upgrade
Message-ID: <1236987481.10690.12.camel@booger>

We just upgraded a 7500 to 12.4(23) and everything works great except
DSL connections over atm card.  ATM interfaces are up, all configuration
is in place,  pvc interfaces are up, virtual templates are in place.
But the virtual-access interface refuses to come up.  Anyone have any
clues as to what we shoudl be looking at?  Everything I see seems like
it shoudl be working good.


summit#sh interfaces atm 10/0/0
ATM10/0/0 is up, line protocol is up 
  Hardware is cyBus ATM
  MTU 4470 bytes, sub MTU 4470, BW 155520 Kbit/sec, DLY 80 usec, 
     reliability 129/255, txload 1/255, rxload 1/255
  Encapsulation ATM, loopback not set
  Encapsulation(s): AAL5 , PVC mode
  2047 maximum active VCs, 1024 VCs per VP, 88 current VCCs
  VC Auto Creation Disabled.
  VC idle disconnect time: 300 seconds
  Last input 00:02:08, output 00:02:08, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 30000 bits/sec, 56 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     37010 packets input, 2527473 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
     37305 input errors, 0 CRC, 0 frame, 63 overrun, 0 ignored, 1 abort
     1 packets output, 56 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 unknown protocol drops
     0 output buffer failures, 0 output buffers swapped out
summit#sh interfaces atm 10/0/0.1
ATM10/0/0.1 is up, line protocol is up 
  Hardware is cyBus ATM
  MTU 4470 bytes, BW 155520 Kbit/sec, DLY 80 usec, 
     reliability 128/255, txload 1/255, rxload 1/255
  Encapsulation ATM
     35184 packets input, 2260236 bytes
     0 packets output, 0 bytes 
     1 OAM cells input, 1 OAM cells output
  AAL5 Oversized SDUs : 0
  Last clearing of "show interface" counters never
summit#sh interfaces virtual-access 1
Virtual-Access1 is down, line protocol is down 
  Hardware is Virtual Access interface
  MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100000 usec, 
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation PPP, LCP Closed
  Base VtMgr vaccess
  Vaccess status 0x0, loopback not set
  DTR is pulsed for 5 seconds on reset
  Last input never, output never, output hang never
  Last clearing of "show interface" counters 00:11:07
  Input queue: 0/4096/0/0 (size/max/drops/flushes); Total output drops:
0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     0 packets input, 0 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     0 packets output, 0 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 unknown protocol drops
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090313/53b55f7e/attachment.bin>

From mcdonald.richards at gmail.com  Fri Mar 13 20:42:47 2009
From: mcdonald.richards at gmail.com (McDonald Richards)
Date: Sat, 14 Mar 2009 11:42:47 +1100
Subject: [c-nsp] Sending connected number from AS5350
In-Reply-To: <OFC129ADB2.21329615-ONC1257577.0057C5A2-C1257577.0059CC14@office.unet.nl>
References: <OFC129ADB2.21329615-ONC1257577.0057C5A2-C1257577.0059CC14@office.unet.nl>
Message-ID: <8bde567b0903131742r36510054rd578c3826c1cdff4@mail.gmail.com>

This is fairly common policy for a telco and I think you are probably
heading in the wrong direction with your analysis. The calling party IE is
sent in the ISDN setup message. You should use translation profiles on the
SIP leg of the call to normalise the calling party number as the call hits
the gateway and present the expected format to your provider.

Here's a sample configuration on how to overstamp incoming calls from a
customer assuming you use a digit prepend or similar to identify them on
your gateway (in this case the digit prepend being 00022):

voice translation-profile OVERSTAMP-CUSTOMER-A
 translate calling 100
!

voice translation-rule 100
 rule 1 /^.*/ /$customer_number/
!

dial-peer 100
 description incoming calls from customer-a
 translation-profile incoming OVERSTAMP-CUSTOMER-A
 incoming called-number 00022.T

The above config snippets will take any number coming in that matches
dial-peer 100 and set the calling-party to whatever you have entered in
$customer_number. Using this you can present your provider the correct
numbers and preserve CLI integrity.



On Fri, Mar 13, 2009 at 3:20 AM, Andreas Sikkema <ASikkema at office.unet.nl>wrote:

> Hi,
>
> I've got a Cisco AS5350XM connected to a couple of ISDN30s from one of the
> local telcos. The 5350 converts ISDN to SIP and vice versa. Some of our
> customers on the SIP side have complained that every now and then when
> they are called from the PSTN side the calling party sees the "main
> number" of our ISDN lines appear instead of the called number when the
> call has been answered.
>
> The telco apparently has the policy that they will send out the line
> number when we don't provide the connected number or overwrite it when we
> send an "illegal" number. The only thing the telco so far has offered us
> is to set presentation to not allowed for all outgoing connected numbers
> which will solve the presentation of the line number but might give some
> calling parties the wrong impression.
>
> The problem is that I haven't been able to find a way make our 5350 send a
> "connected number" IE on the ISDN side. (isdn outgoing ie connected-number
> hasn't yet solved the problem as far as I can see).
>
> Is there a way to force the 5350 to send a connected number IE for
> instance when receiving an UPDATE message or on receipt of a 200 OK
> message? The only logging a debug isdn q931 will give on a CONNECT message
> being sent is this:
> Mar 12 16:28:10.935: ISDN Se3/5:15 Q931: TX -> CONNECT pd = 8  callref =
> 0xF001
>
>
> Or am I way off track and should be looking at something else?
>
> --
> Andreas Sikkema
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From oboehmer at cisco.com  Sat Mar 14 02:59:17 2009
From: oboehmer at cisco.com (Oliver Boehmer (oboehmer))
Date: Sat, 14 Mar 2009 07:59:17 +0100
Subject: [c-nsp] Fast Reroute - Detour Object support ?
In-Reply-To: <b247bbf20903131325s3802b8a4v9ed1f8c670aa6ffb@mail.gmail.com>
References: <b247bbf20903131325s3802b8a4v9ed1f8c670aa6ffb@mail.gmail.com>
Message-ID: <70B7A1CCBFA5C649BD562B6D9F7ED7840709C44A@xmb-ams-333.emea.cisco.com>

Asheesh Jadav <> wrote on Friday, March 13, 2009 21:26:

> Hi,
> 
>    Is the DETOUR Object as specified in RFC 4090 supported on Cisco
> IOS? I'm trying to set up a detour through a Cisco 7600 but the
> system doesn't seem to like the PATH message. I'm using the  Version
> 12.2(33)SRB5 on a 7600 chassis.

no, we do not support detour, we support facility..

	oli

From mtinka at globaltransit.net  Fri Mar 13 23:56:20 2009
From: mtinka at globaltransit.net (Mark Tinka)
Date: Sat, 14 Mar 2009 11:56:20 +0800
Subject: [c-nsp] Supress STP on a port?
In-Reply-To: <17838240D9A5544AAA5FF95F8D52031605B41D84@ad-exh01.adhost.lan>
References: <!&!AAAAAAAAAAAYAAAAAAAAAN5U5OuspydJheQZRk7Gfl7CgAAAEAAAAK/bl9g9cthJu/bPX/RPm1kBAAAAAA==@skeeve.org>
	<49B8AED8.8070900@cisco.com>
	<17838240D9A5544AAA5FF95F8D52031605B41D84@ad-exh01.adhost.lan>
Message-ID: <200903141157.00430.mtinka@globaltransit.net>

On Thursday 12 March 2009 02:57:02 pm Michael K. Smith - 
Adhost wrote:

> I echo what Lincoln said as loudly as I can without
> typing in all caps.  If you enable filtering and you get
> a second path somehow or somewhere (customers can be very
> helpful by doing "stuff" when you're not looking), you
> will loop up your entire network.  This will happen at 3
> am 2 years from now on a Sunday when you're out of town
> and your front line tech is asleep in a hut somewhere. 
> Trust me.  BPDU-filter bad.  Really.

As one poster subtly mentioned, limit BPDU filtering to Edge 
ports (Portfast-enabled ports in Cisco speak).

Trunk ports would still process BPDU's, as they are 
typically not configured as Edge ports.

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/20090314/7a611792/attachment.bin>

From p.mayers at imperial.ac.uk  Sat Mar 14 09:43:44 2009
From: p.mayers at imperial.ac.uk (Phil Mayers)
Date: Sat, 14 Mar 2009 13:43:44 +0000
Subject: [c-nsp] 12.2(33)SXI vpnv6
In-Reply-To: <9e246b4d0903131330v72e9d04dgce7d78273faeac89@mail.gmail.com>
References: <9e246b4d0903131330v72e9d04dgce7d78273faeac89@mail.gmail.com>
Message-ID: <49BBB490.8080303@imperial.ac.uk>

Tim Durack wrote:
> I'm running 12.2(33)SXI on some boxes in a PE-PE setup. I'm trying to enable
> vpnv6. BGP side of things is working:
> 
> rtr-1#sh ipv6 route vrf v101
> IPv6 Routing Table - v101 - 4 entries
> Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
>        B - BGP, R - RIP, I1 - ISIS L1, I2 - ISIS L2
>        IA - ISIS interarea, IS - ISIS summary, D - EIGRP, EX - EIGRP
> external
>        O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
>        ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
> B   1:0:1:1::1/128 [200/0]
>      via 1:0:1970::1%Default, indirectly connected
> B   1:0:1:1::2/128 [200/0]
>      via 1:0:1970::2%Default, indirectly connected
> LC  1:0:1970:1::3/128 [0/0]
>      via Loopback101, receive
> L   FF00::/8 [0/0]
>      via Null0, receive
> 
> But cef/labels aren't being programmed:
> 
> rtr-1#sh mls cef ipv6 vrf v101
> 
> Codes: + - Push label
> Index  Prefix                              Adjacency
> 196640 1:0:1970:1::3/128                receive
> 196672 ::/127                              drop
> 196704 FE80::/10                           receive
> 196736 FF00::/8                            glean
> 197152 ::/0                                drop
> 
> vpnv4 is working fine, IPv6 in the global table is working, but not vpnv6.
> 
> Any ideas?

I've definitely had this working; what's your config?

From paul at paulstewart.org  Sat Mar 14 09:52:07 2009
From: paul at paulstewart.org (Paul Stewart)
Date: Sat, 14 Mar 2009 09:52:07 -0400
Subject: [c-nsp] Sup720-3BXL Stable IOS
Message-ID: <00d001c9a4ac$10871c30$31955490$@org>

Hi there.

 

We're seeing issues occasionally with BGP sessions on Sup720-3BXL getting
"stuck".  When adding a new session in particular it won't come up and
sometimes after removing and adding back into the config it works.. Other
strange unexplained stuff once in a while..

 

Anyways, talked to a few peers and they tell me "wow, you're on the bleeding
edge" because we're running 12.2.33SRD and 12.2.33SRC releases.

 

I am thinking of moving to 12.2.33SRA7 release as it's listed as LD vs ED
and is very current still - am I playing with fire?  Any feedback?

 

Box is running IPv4/IPv6, OSPF and BGP

 

Many thanks,

 

Paul

 

 

 



This message was delivered by MDaemon - http://www.altn.com/MDaemon/

From todd at newfrontierssolutions.com  Sat Mar 14 14:22:34 2009
From: todd at newfrontierssolutions.com (Todd Shipway)
Date: Sat, 14 Mar 2009 14:22:34 -0400
Subject: [c-nsp] Virtual Access int down after IOS upgrade
In-Reply-To: <1236987481.10690.12.camel@booger>
References: <1236987481.10690.12.camel@booger>
Message-ID: <1237054954.7369.6.camel@booger>

I had to go back to 12.4(3) to get the virtual-access interface working
again.  But below is the config I'm using for the dsl's on the atm card.
Is there something I'm missing that has changed since 12.4(3) and (23)?
I'm sure there is, but it's becoming a huge pain to track it down.  Just
looking for possible suggestions, I'm digging through release notes now
to see if I can find more info.

The problem is that after upgrading to 12.4(23), the Virtual-Access
interface stays in a down/down state.  atm and pvc interfaces are up/up.
Since the Virtual-Access int is down, no traffic passes from DSL
connections. 

This is on a 7513 with 12.0(10r)S1 bootstrap.

ATM Card:
NAME: "Card Slot 10, Bay 0", DESCR: "ATM Lite Port Adaptor (SM)"
PID: PA-ATM-LITE-SM    , VID: Hardware Version : 1.1 Board Revision :
D0, SN: 16743213 


Current 12.4(3) config:

interface ATM10/0/0
 no ip address
 no atm ilmi-keepalive
 no clns route-cache
!
interface ATM10/0/0.1 multipoint
 pvc 1/6 
  encapsulation aal5snap
  protocol ppp Virtual-Template16
 !
 pvc 1/9 
  encapsulation aal5snap
  protocol ppp Virtual-Template13



interface Virtual-Template13 
 ip unnumbered FastEthernet4/0
 peer default ip address pool dsl13
!
interface Virtual-Template14 
 ip unnumbered FastEthernet4/0
 peer default ip address pool dsl14
!
interface Virtual-Template15 
 ip unnumbered FastEthernet4/0
 peer default ip address pool dsl15
!
interface Virtual-Template16 
 ip unnumbered FastEthernet4/0
 peer default ip address pool dsl16
!




ip local pool dsl13 63.168.160.164
ip local pool dsl14 63.168.160.165
ip local pool dsl15 63.168.160.166
ip local pool dsl16 198.70.13.130 198.70.13.142



On Fri, 2009-03-13 at 19:38 -0400, Todd Shipway wrote:
> We just upgraded a 7500 to 12.4(23) and everything works great except
> DSL connections over atm card.  ATM interfaces are up, all configuration
> is in place,  pvc interfaces are up, virtual templates are in place.
> But the virtual-access interface refuses to come up.  Anyone have any
> clues as to what we shoudl be looking at?  Everything I see seems like
> it shoudl be working good.
> 
> 
> summit#sh interfaces atm 10/0/0
> ATM10/0/0 is up, line protocol is up 
>   Hardware is cyBus ATM
>   MTU 4470 bytes, sub MTU 4470, BW 155520 Kbit/sec, DLY 80 usec, 
>      reliability 129/255, txload 1/255, rxload 1/255
>   Encapsulation ATM, loopback not set
>   Encapsulation(s): AAL5 , PVC mode
>   2047 maximum active VCs, 1024 VCs per VP, 88 current VCCs
>   VC Auto Creation Disabled.
>   VC idle disconnect time: 300 seconds
>   Last input 00:02:08, output 00:02:08, output hang never
>   Last clearing of "show interface" counters never
>   Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
>   Queueing strategy: fifo
>   Output queue: 0/40 (size/max)
>   5 minute input rate 30000 bits/sec, 56 packets/sec
>   5 minute output rate 0 bits/sec, 0 packets/sec
>      37010 packets input, 2527473 bytes, 0 no buffer
>      Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
>      37305 input errors, 0 CRC, 0 frame, 63 overrun, 0 ignored, 1 abort
>      1 packets output, 56 bytes, 0 underruns
>      0 output errors, 0 collisions, 0 interface resets
>      0 unknown protocol drops
>      0 output buffer failures, 0 output buffers swapped out
> summit#sh interfaces atm 10/0/0.1
> ATM10/0/0.1 is up, line protocol is up 
>   Hardware is cyBus ATM
>   MTU 4470 bytes, BW 155520 Kbit/sec, DLY 80 usec, 
>      reliability 128/255, txload 1/255, rxload 1/255
>   Encapsulation ATM
>      35184 packets input, 2260236 bytes
>      0 packets output, 0 bytes 
>      1 OAM cells input, 1 OAM cells output
>   AAL5 Oversized SDUs : 0
>   Last clearing of "show interface" counters never
> summit#sh interfaces virtual-access 1
> Virtual-Access1 is down, line protocol is down 
>   Hardware is Virtual Access interface
>   MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100000 usec, 
>      reliability 255/255, txload 1/255, rxload 1/255
>   Encapsulation PPP, LCP Closed
>   Base VtMgr vaccess
>   Vaccess status 0x0, loopback not set
>   DTR is pulsed for 5 seconds on reset
>   Last input never, output never, output hang never
>   Last clearing of "show interface" counters 00:11:07
>   Input queue: 0/4096/0/0 (size/max/drops/flushes); Total output drops:
> 0
>   Queueing strategy: fifo
>   Output queue: 0/40 (size/max)
>   5 minute input rate 0 bits/sec, 0 packets/sec
>   5 minute output rate 0 bits/sec, 0 packets/sec
>      0 packets input, 0 bytes, 0 no buffer
>      Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
>      0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
>      0 packets output, 0 bytes, 0 underruns
>      0 output errors, 0 collisions, 0 interface resets
>      0 unknown protocol drops
>      0 output buffer failures, 0 output buffers swapped out
>      0 carrier transitions
> 
> _______________________________________________
> cisco-nsp mailing 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: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090314/a476423b/attachment.bin>

From tdurack at gmail.com  Sat Mar 14 15:21:24 2009
From: tdurack at gmail.com (Tim Durack)
Date: Sat, 14 Mar 2009 15:21:24 -0400
Subject: [c-nsp] 12.2(33)SXI vpnv6
In-Reply-To: <49BBB490.8080303@imperial.ac.uk>
References: <9e246b4d0903131330v72e9d04dgce7d78273faeac89@mail.gmail.com>
	<49BBB490.8080303@imperial.ac.uk>
Message-ID: <9e246b4d0903141221p6e6674cckeb9de7fbe9ca6fc8@mail.gmail.com>

>
> I've definitely had this working; what's your config?
>

vrf definition v101
 rd 10.1.0.3:101
 route-target export xxx:101
 route-target import xxx:101
 !
 address-family ipv4
 exit-address-family
 !
 address-family ipv6
 exit-address-family
!
!
interface Loopback101
 vrf forwarding v101
 ip address 10.1.0.3 255.255.255.255
 ipv6 address 1:0:1970:1::3/128
!
router bgp 65001
!
address-family ipv4 vrf v101
 redistribute connected
 no synchronization
 exit-address-family
!
!
address-family ipv6 vrf v101
 redistribute connected
 no synchronization
 exit-address-family
!
!
end

Can't see anything missing. MP-BGP is working, VPN routes are being
exchanged, but IPv6 isn't getting label switched. Feels like I'm
missing something stupid.

Tim:>

From tdurack at gmail.com  Sat Mar 14 15:55:50 2009
From: tdurack at gmail.com (Tim Durack)
Date: Sat, 14 Mar 2009 15:55:50 -0400
Subject: [c-nsp] 12.2(33)SXI vpnv6
In-Reply-To: <9e246b4d0903141221p6e6674cckeb9de7fbe9ca6fc8@mail.gmail.com>
References: <9e246b4d0903131330v72e9d04dgce7d78273faeac89@mail.gmail.com>
	<49BBB490.8080303@imperial.ac.uk>
	<9e246b4d0903141221p6e6674cckeb9de7fbe9ca6fc8@mail.gmail.com>
Message-ID: <9e246b4d0903141255r3091a2e5m6e451616bbed7ab8@mail.gmail.com>

On Sat, Mar 14, 2009 at 3:21 PM, Tim Durack <tdurack at gmail.com> wrote:
>>
>> I've definitely had this working; what's your config?
>>
>
> vrf definition v101
> ?rd 10.1.0.3:101
> ?route-target export xxx:101
> ?route-target import xxx:101
> ?!
> ?address-family ipv4
> ?exit-address-family
> ?!
> ?address-family ipv6
> ?exit-address-family
> !
> !
> interface Loopback101
> ?vrf forwarding v101
> ?ip address 10.1.0.3 255.255.255.255
> ?ipv6 address 1:0:1970:1::3/128
> !
> router bgp 65001
> !
> address-family ipv4 vrf v101
> ?redistribute connected
> ?no synchronization
> ?exit-address-family
> !
> !
> address-family ipv6 vrf v101
> ?redistribute connected
> ?no synchronization
> ?exit-address-family
> !
> !
> end
>
> Can't see anything missing. MP-BGP is working, VPN routes are being
> exchanged, but IPv6 isn't getting label switched. Feels like I'm
> missing something stupid.
>
> Tim:>
>

Maybe vpnv6 should be activated on my IPv4 peering sessions, not IPv6
sessions. Let me try that.

Tim:>

From tdurack at gmail.com  Sat Mar 14 16:40:27 2009
From: tdurack at gmail.com (Tim Durack)
Date: Sat, 14 Mar 2009 16:40:27 -0400
Subject: [c-nsp] 12.2(33)SXI vpnv6
In-Reply-To: <9e246b4d0903141255r3091a2e5m6e451616bbed7ab8@mail.gmail.com>
References: <9e246b4d0903131330v72e9d04dgce7d78273faeac89@mail.gmail.com>
	<49BBB490.8080303@imperial.ac.uk>
	<9e246b4d0903141221p6e6674cckeb9de7fbe9ca6fc8@mail.gmail.com>
	<9e246b4d0903141255r3091a2e5m6e451616bbed7ab8@mail.gmail.com>
Message-ID: <9e246b4d0903141340y48769f00v56f9bc49b938e569@mail.gmail.com>

>
> Maybe vpnv6 should be activated on my IPv4 peering sessions, not IPv6
> sessions. Let me try that.
>
> Tim:>
>

That was it. I guess this is why Cisco docs say stuff like:

Restrictions for Implementing IPv6 VPN over MPLS
6VPE supports an MPLS IPv4-signaled core. An MPLS IPv6-signaled core
is not supported.

I'm not really trying to run 6VPE, just IPv6 VPNs, over a dual-stack
infrastructure. Somewhat counter-intuitive to *not* enable IPv6 peers
for VPNv6. Even more confusing that VPNv6 will exchange routes over
IPv6 sessions, but then not work due to the missing label path.

Guess this is due to the lack of IPv6 LDP. Hopefully this will get
fixed sooner rather than later.

Tim:>

From damin at nacs.net  Sat Mar 14 17:50:20 2009
From: damin at nacs.net (Gregory Boehnlein)
Date: Sat, 14 Mar 2009 17:50:20 -0400
Subject: [c-nsp] AS5200 / 5300 Modem Cards
Message-ID: <036001c9a4ee$defc7af0$9cf570d0$@net>

I'm having a tough time locating this information on CCO. I have an AS5200
sitting in the back, and am wondering if I can move the two Mica carrier
cards into an AS5300? Are they interchangeable?


From bdikici at gmail.com  Sat Mar 14 19:13:17 2009
From: bdikici at gmail.com (Burak Dikici)
Date: Sun, 15 Mar 2009 01:13:17 +0200
Subject: [c-nsp] BGP - Multihoming
Message-ID: <d9281f5c0903141613v1c165fd7y18077b5ec1609bdf@mail.gmail.com>

Hello ,

I would like consult some subject about BGP to the experienced BGP users. We
are making a BGP connection to a two different ISPs via central site router.
We are announcing our subnet via ISP-1 normally , but for ISP2 we are
announcing the subnet with AS path prepending configuration. As a result ,
we still see inbound traffic from internet to our subnet via ISP-2. Is that
possible to adjust more tuning for
inbound traffic ? We would like to achieve that there will be no inbound
traffic via ISP-2.
By the way , in the next step of the configuration we would like to
configure our multihomed BGP router with PBR & NBAR. What we are going to
try with this is that for example p2p traffic from our subnet to the
internet
will be detected with NBAR and it will be forwarded to the ISP-2 connection
with PBR and the return traffic of this
connection will be come through the ISP-2 connection. (Symmetric traffic
flow) How can be achive that ?
Kind Regards...

Burak Dikici


Note: I am writing the configuration of our multihomed BGP router below.
(the real configuration's ip addresses
and BGP AS numbers has beed changed in the text which is writing below.)



router bgp 100
bgp log-neighbor-changes
neighbor 2.2.2.2 remote-as 222
neighbor 2.2.2.2 description ISP_2
neighbor 1.1.1.1 remote-as 111
neighbor 1.1.1.1 description ISP_1
!
address-family ipv4
no synchronization
network X.Y.0.0 mask 255.255.0.0
neighbor 2.2.2.2 activate
neighbor 2.2.2.2 route-map AS_path_prepend_for_ISP2 out
neighbor 2.2.2.2 filter-list 10 out
neighbor 1.1.1.1 activate
neighbor 1.1.1.1 route-map UPDATES_FOR_ISP1 in
neighbor 1.1.1.1 filter-list 10 out
no auto-summary
exit-address-family


ip as-path access-list 10 permit ^$

access-list 10 permit any

access-list 20 permit X.Y.0.0 0.0.255.255



route-map UPDATES_FOR_ISP1 permit 10
match ip address 10
set weight 100

route-map AS_path_prepend_for_ISP2 permit 10
match ip address 20
set as-path prepend 100 100 100 100 100

route-map AS_path_prepend_for_ISP2 permit 20

From Stig.Johansen at atea.no  Sat Mar 14 20:07:09 2009
From: Stig.Johansen at atea.no (Stig Johansen)
Date: Sun, 15 Mar 2009 01:07:09 +0100
Subject: [c-nsp] BGP - Multihoming
In-Reply-To: <d9281f5c0903141613v1c165fd7y18077b5ec1609bdf@mail.gmail.com>
References: <d9281f5c0903141613v1c165fd7y18077b5ec1609bdf@mail.gmail.com>
Message-ID: <5EB9799F396A304686962AFFF740ED0CE9C50383@NOOSLEXCH001.adno.local>

Burak Dikici wrote:
>I would like consult some subject about BGP to the experienced BGP users. We are making a BGP connection to a two different ISPs via central site router.
>We are announcing our subnet via ISP-1 normally , but for ISP2 we are announcing the subnet with AS path prepending configuration. As a result , we still see inbound traffic from internet to our subnet via ISP-2. Is that possible to adjust more tuning for inbound traffic ? We would like to achieve that there will be no inbound traffic via ISP-2.
>By the way , in the next step of the configuration we would like to configure our multihomed BGP router with PBR & NBAR. What we are going to try with this is that for example p2p traffic from our subnet to the internet will be detected with NBAR and it will be forwarded to the ISP-2 connection with PBR and the return traffic of this connection will be come through the ISP-2 connection. (Symmetric traffic flow) How can be achive that ?

Hi there,

Maybe someone has better ideas, but here goes anyway;

1) If you prepend your AS various times towards ISP-2, the BGP best path selection should prefer the path with the shortest AS-PATH, and therefore use your ISP-1 connection.
2) If your ISP-2 has a policy of assigning a higher LOCAL PREFERENCE for prefixes originated from any of it's customers, all of the customers of ISP-2 (and the ISP-2 it self) will use ISP-2's connection to you by default. This is reasonable for ISP-2, as it would use it's own internal network to reach you.

I'm not sure if ISP-2 would like to change this configuration, as it would inflict a higher usage of it's other peeringlinks, but asking doesn't hurt.. :)

If you want certain traffic to use the ISP-2 link with PBR, you would need to make sure the traffic uses IP-addresses which are preferred on the ISP-link. If you don't know which source-addresses will need to use this link, but use NBAR to discover this, you'll have to use NAT'ing.

A) Either get a pool of IP-addresses from ISP-2 (which will be preferred on ISP-2 anyway), or use a smaller prefix of your own addresses (and make sure they are preferred on the ISP-2 link, using the methods as cited above)
B) Use PBR with NBAR to make the interesting traffic use the ISP-2-link and configure NAT'ing to the addresses you aquired in A).

Best regards,
Stig Meireles Johansen

From christian at broknrobot.com  Sat Mar 14 20:34:27 2009
From: christian at broknrobot.com (Christian Koch)
Date: Sat, 14 Mar 2009 17:34:27 -0700
Subject: [c-nsp] BGP - Multihoming
In-Reply-To: <5EB9799F396A304686962AFFF740ED0CE9C50383@NOOSLEXCH001.adno.local>
References: <d9281f5c0903141613v1c165fd7y18077b5ec1609bdf@mail.gmail.com>
	<5EB9799F396A304686962AFFF740ED0CE9C50383@NOOSLEXCH001.adno.local>
Message-ID: <c93a55220903141734m532f8489m88623b5d1cd89556@mail.gmail.com>

I'd agree with Stig's suggestions and his assumption about the local
pref is probably correct. I'd also suggest you check if your SP's have
defined communities to send in order to alter attributes of the
prefixes you are sending.


On Sat, Mar 14, 2009 at 5:07 PM, Stig Johansen <Stig.Johansen at atea.no> wrote:
> Burak Dikici wrote:
>>I would like consult some subject about BGP to the experienced BGP users. We are making a BGP connection to a two different ISPs via central site router.
>>We are announcing our subnet via ISP-1 normally , but for ISP2 we are announcing the subnet with AS path prepending configuration. As a result , we still see inbound traffic from internet to our subnet via ISP-2. Is that possible to adjust more tuning for inbound traffic ? We would like to achieve that there will be no inbound traffic via ISP-2.
>>By the way , in the next step of the configuration we would like to configure our multihomed BGP router with PBR & NBAR. What we are going to try with this is that for example p2p traffic from our subnet to the internet will be detected with NBAR and it will be forwarded to the ISP-2 connection with PBR and the return traffic of this connection will be come through the ISP-2 connection. (Symmetric traffic flow) How can be achive that ?
>
> Hi there,
>
> Maybe someone has better ideas, but here goes anyway;
>
> 1) If you prepend your AS various times towards ISP-2, the BGP best path selection should prefer the path with the shortest AS-PATH, and therefore use your ISP-1 connection.
> 2) If your ISP-2 has a policy of assigning a higher LOCAL PREFERENCE for prefixes originated from any of it's customers, all of the customers of ISP-2 (and the ISP-2 it self) will use ISP-2's connection to you by default. This is reasonable for ISP-2, as it would use it's own internal network to reach you.
>
> I'm not sure if ISP-2 would like to change this configuration, as it would inflict a higher usage of it's other peeringlinks, but asking doesn't hurt.. :)
>
> If you want certain traffic to use the ISP-2 link with PBR, you would need to make sure the traffic uses IP-addresses which are preferred on the ISP-link. If you don't know which source-addresses will need to use this link, but use NBAR to discover this, you'll have to use NAT'ing.
>
> A) Either get a pool of IP-addresses from ISP-2 (which will be preferred on ISP-2 anyway), or use a smaller prefix of your own addresses (and make sure they are preferred on the ISP-2 link, using the methods as cited above)
> B) Use PBR with NBAR to make the interesting traffic use the ISP-2-link and configure NAT'ing to the addresses you aquired in A).
>
> Best regards,
> Stig Meireles Johansen
> _______________________________________________
> cisco-nsp mailing list ?cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From jlewis at lewis.org  Sat Mar 14 21:21:32 2009
From: jlewis at lewis.org (Jon Lewis)
Date: Sat, 14 Mar 2009 21:21:32 -0400 (EDT)
Subject: [c-nsp] AS5200 / 5300 Modem Cards
In-Reply-To: <036001c9a4ee$defc7af0$9cf570d0$@net>
References: <036001c9a4ee$defc7af0$9cf570d0$@net>
Message-ID: <Pine.LNX.4.61.0903142120240.6312@soloth.lewis.org>

On Sat, 14 Mar 2009, Gregory Boehnlein wrote:

> I'm having a tough time locating this information on CCO. I have an AS5200
> sitting in the back, and am wondering if I can move the two Mica carrier
> cards into an AS5300? Are they interchangeable?

I'm relatively certain the answer is no.  IIRC, 5300s are quite a bit 
deeper and the cards for them would be longer....not to mention they're 
newer, higher density units.

----------------------------------------------------------------------
  Jon Lewis                   |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

From justin at justinshore.com  Sat Mar 14 21:34:07 2009
From: justin at justinshore.com (Justin Shore)
Date: Sat, 14 Mar 2009 20:34:07 -0500
Subject: [c-nsp] service unsupported-transceiver in a 7201
Message-ID: <49BC5B0F.6090302@justinshore.com>

Does anyone know if 'service unsupported-transceiver' is or is not 
supported in a 7201 running 12.4(24)T?  I'm trying it on one of mine and 
it is not working.

7201-1.dc(config)#service unsupported-transceiver
                            ^
% Invalid input detected at '^' marker.

The command is accepted in my 7613.  For that matter it's not accepted 
in one of my 7206s either.  Is there a command that's specific to the 7200s?

Thanks
  Justin

From mtinka at globaltransit.net  Sun Mar 15 02:43:01 2009
From: mtinka at globaltransit.net (Mark Tinka)
Date: Sun, 15 Mar 2009 14:43:01 +0800
Subject: [c-nsp] 12.2(33)SXI vpnv6
In-Reply-To: <9e246b4d0903141340y48769f00v56f9bc49b938e569@mail.gmail.com>
References: <9e246b4d0903131330v72e9d04dgce7d78273faeac89@mail.gmail.com>
	<9e246b4d0903141255r3091a2e5m6e451616bbed7ab8@mail.gmail.com>
	<9e246b4d0903141340y48769f00v56f9bc49b938e569@mail.gmail.com>
Message-ID: <200903151443.06934.mtinka@globaltransit.net>

On Sunday 15 March 2009 04:40:27 am Tim Durack wrote:

> Guess this is due to the lack of IPv6 LDP. Hopefully this
> will get fixed sooner rather than later.

The draft is already out.

Indications from the leading vendors are that it'll be in 
the code by the end of the year.

Your guess is as good as mine whether that actually pans 
out.

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/20090315/1e6a9004/attachment.bin>

From gert at greenie.muc.de  Sun Mar 15 08:17:37 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Sun, 15 Mar 2009 13:17:37 +0100
Subject: [c-nsp] service unsupported-transceiver in a 7201
In-Reply-To: <49BC5B0F.6090302@justinshore.com>
References: <49BC5B0F.6090302@justinshore.com>
Message-ID: <20090315121737.GF290@greenie.muc.de>

Hi,

On Sat, Mar 14, 2009 at 08:34:07PM -0500, Justin Shore wrote:
> 7201-1.dc(config)#service unsupported-transceiver

It's a "switch" thing.

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/20090315/8c5a8559/attachment.bin>

From bdikici at gmail.com  Sun Mar 15 09:06:05 2009
From: bdikici at gmail.com (Burak Dikici)
Date: Sun, 15 Mar 2009 15:06:05 +0200
Subject: [c-nsp] BGP conditional advertisemet - NON-EXIST route map's
	access-list problem
Message-ID: <d9281f5c0903150606m3fb9e1ddwfc75c6b7179b87af@mail.gmail.com>

  I am getting full internet route from ISP-1 and getting just a default
route from ISP-2. ( Both ISP connection is terminated on the one central
site router.) What i am trying to do , to make an ISP-2 connection is
completly backup for inbound traffic. To achieve that ,i am trying to use
BGP conditional advertisemet configuration. I have got a problem with
NON-EXIST route map's access-list. In the NON-EXIST router map i am using
the commands which is written below ;


ip as-path access-list 1 permit ^200 !!! (ISP-1 AS number) !!!

access-list 65 permit any !!! (permit any packet from ISP-2) !!!

route-map NON-EXIST permit 10 !!! (this matches any route from AS200) !!!
match ip address 65
match as-path 1


router bgp 10 !!! (My AS number) !!!
neighbor X.Y.Z.W (ISP-2 ip address) advertise-map ADVERTISE non-exist-map
NON-EXIST !!! (What is says. This router will only advertise "networks
defined in the route-map named ADVERTISE" if and only if "routes that are
defined in the route-map named NON-EXISTS" do not appear in the BGP routing
table.) !!!


with this configuration when the ISP-1 connection is up , my router still
adversite my subnet to the ISP-2. What should i write in the access-list 65
to not advertise my subnet to the ISP-2 until the failure of ISP-1
connection ? ( As i said , i am getting the full internet table from ISP-1.)


Kind Regards...

Burak Dikici

From andy.bierlair at root.lu  Sun Mar 15 10:45:30 2009
From: andy.bierlair at root.lu (Andy BIERLAIR)
Date: Sun, 15 Mar 2009 15:45:30 +0100
Subject: [c-nsp] Netflow on SUP720-3BXL
Message-ID: <000501c9a57c$b05aacb0$11100610$@bierlair@root.lu>

I'm trying to run netflow on one of our Cisco core routers (SUP720-3BXL with
SXF15a), but I think I am hitting some limitations because of this:

  %EARL_NETFLOW-SP-4-TCAM_THRLD: Netflow TCAM threshold exceeded, TCAM
Utilization [99%]

The setup of netflow looks like this (globally):

  ip flow-cache entries 524288
  mls aging fast time 5 threshold 32
  mls aging long 300
  mls aging normal 60
  mls netflow usage notify 80 300
  mls flow ip full
  no mls flow ipv6
  mls nde sender version 5
  no mls verify ip checksum
  no mls acl tcam share-global

  ip flow-export source Loopback0
  ip flow-export version 5 origin-as
  ip flow-export destination <ip> <port>

Then I have this enabled on all border interfaces/vlans (peering / transit /
other core routers) that are of interest for my stats:

  ip route-cache flow

Some more details about the problem:


#sh mls netflow table-contention detailed
Earl in Module 5
Detailed Netflow CAM (TCAM and ICAM) Utilization
================================================
TCAM Utilization             :   100%
ICAM Utilization             :   13%
Netflow TCAM count           :   262033
Netflow ICAM count           :   17
Netflow Creation Failures    :   4822220
Netflow CAM aliases          :   1


#sh mls netflow table-contention aggregate
Earl in Module 5
Aggregate Netflow CAM Contention Information
=============================================
Netflow Creation Failures    :   130003616
Netflow Hash Aliases         :   4


#sh mls netflow flowmask                 
current ip   flowmask for unicast:    full   
current ipv6 flowmask for unicast:    null   



I understand that the TCAM is full, but what can I do against it? This is a
busy core router:

  Aggregated traffic: 7-8 GBIT/s
  Packets per Second: 1.0 - 1.2 Million

I have heard that more agressive aging might help, but I expect the router's
traffic and pps to increase dramatically, so I'll be hitting the roof over
and over again.

I wouldn't mind analyzing only every 10th or 100th flow (sampling), which
seems to be a common practice, but will it help?

What is the common netflow setup without additional DFCs for a busy router?

Any good piece of advice is welcome.

Thanks!


-
Andy


From blahu77 at gmail.com  Sun Mar 15 10:53:25 2009
From: blahu77 at gmail.com (Mateusz Blaszczyk)
Date: Sun, 15 Mar 2009 14:53:25 +0000 (IST)
Subject: [c-nsp] BGP conditional advertisemet - NON-EXIST route map's
	access-list problem
In-Reply-To: <d9281f5c0903150606m3fb9e1ddwfc75c6b7179b87af@mail.gmail.com>
Message-ID: <fsbujrb52s0kyzgvj9UYAxe124vaj_firegpg@mail.gmail.com>

Burak,

> ip as-path access-list 1 permit ^200 !!! (ISP-1 AS number) !!!
>
> access-list 65 permit any !!! (permit any packet from ISP-2) !!!
>
> route-map NON-EXIST permit 10 !!! (this matches any route from AS200) !!!
> match ip address 65
> match as-path 1

you can match only on ACL and prefix-list int the *-EXIST-MAPs.
Also you dont match packets rather prefixes.

So choose a ISP-1 prefix (some infrastructure IPs or so) and match in prefix-list/route-map.
Then if it is gone, start advertisiing to routes in ADVERTISE

Best Regards,

-mat

-- 
pgp-key 0x1C655CAB

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090315/efea668e/attachment.bin>

From justin at justinshore.com  Sun Mar 15 10:59:24 2009
From: justin at justinshore.com (Justin Shore)
Date: Sun, 15 Mar 2009 09:59:24 -0500
Subject: [c-nsp] service unsupported-transceiver in a 7201
In-Reply-To: <20090315121737.GF290@greenie.muc.de>
References: <49BC5B0F.6090302@justinshore.com>
	<20090315121737.GF290@greenie.muc.de>
Message-ID: <49BD17CC.9090403@justinshore.com>

Gert Doering wrote:
> Hi,
> 
> On Sat, Mar 14, 2009 at 08:34:07PM -0500, Justin Shore wrote:
>> 7201-1.dc(config)#service unsupported-transceiver
> 
> It's a "switch" thing.

D'oh!  You're breaking my heart, Gert.

Justin


From drew.weaver at thenap.com  Sun Mar 15 11:54:02 2009
From: drew.weaver at thenap.com (Drew Weaver)
Date: Sun, 15 Mar 2009 08:54:02 -0700
Subject: [c-nsp] Opinions of DDoS appliances, other techniques,
 most notably Cisco Guard
Message-ID: <F3318834F1F89D46857972DD4B411D700651DA6C@EXCHANGE.thenap.com>

Hi,

Does anyone here have any real world experience with Cisco Guard or other products such as Arbor's Peakflow that they can share?

If you've tried multiple systems and ended up with a specific one, please share the reasoning behind it.

Also, without a dedicated DDoS system deployed, what is the most reliable/fastest way to determine the destination(s) of the attacks (SNMP, NetFlow, etc)?

Any particular software tools which are helpful for detecting this, NetFlow for us has been slightly difficult to use for this task mainly because we haven't found software that is really designed for security rather than performance (would be nice if it did both?)

Either systems/techniques that automatically mitigate or systems that simply recommend mitigation steps/alert are both being evaluated.

By mitigation I mean Null routing sources, null routing destinations upstream (via communities), et cetera.

Any opinions would be helpful, we'd need something that will handle 3-6Gbps and is hopefully vertically scalable.

Thanks,
-Drew


From andy-lists at bourges.de  Sun Mar 15 12:18:19 2009
From: andy-lists at bourges.de (Andreas Bourges)
Date: Sun, 15 Mar 2009 17:18:19 +0100
Subject: [c-nsp] Netflow on SUP720-3BXL
In-Reply-To: <000501c9a57c$b05aacb0$11100610$@bierlair@root.lu>
References: <000501c9a57c$b05aacb0$11100610$@bierlair@root.lu>
Message-ID: <200903151718.22464.andy-lists@bourges.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,


On Sunday 15 March 2009 15:45:30 Andy BIERLAIR wrote:
> I'm trying to run netflow on one of our Cisco core routers (SUP720-3BXL
> with SXF15a), but I think I am hitting some limitations because of this:

>   mls aging fast time 5 threshold 32
>   mls aging long 300
>   mls aging normal 60

> Then I have this enabled on all border interfaces/vlans (peering / transit
> / other core routers) that are of interest for my stats:
>
>   ip route-cache flow

This command only affects packets processed by the MSFC - so at least with 
your IOS it doesn't matter if you configured it on all interfaces or only on 
some. Once MLS NDE is activated, it exports all observed flows regardless of 
the "ip route cache flow" command...

You could upgrade to an IOS >= SXH, which lets you enable mls nde on a per 
interface basis - this would (depending on your setup) reduce the amount of 
created flow entries (I suspect...).

> I have heard that more agressive aging might help, but I expect the
> router's traffic and pps to increase dramatically, so I'll be hitting the
> roof over and over again.
>
> I wouldn't mind analyzing only every 10th or 100th flow (sampling), which
> seems to be a common practice, but will it help?

This won't help on 65K/76K, since they only support "flow-sampling" - which 
means all flows are created in the tcam but not all of them are exported to 
the collector (to reduce export load and collector load).

> What is the common netflow setup without additional DFCs for a busy router?

Since you are already equipped with Sup720-3BXL the one thing that can help is 
to set the mls aging timers more aggressive, I suppose. 
If (and I'm not sure about that) per-interface mls nde reduces the created 
flows in the tcam, an upgrade to SXH could help, too...
Another thing would be to set the flow-mask to something different than "full" 
- - which gives you less information but produces less flows, too. Depends on 
your needs.

Regards,

Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkm9KksACgkQRrny/uOBVy490wCgiEtIs6b2GDeQiWwxOgp4Pnxg
xi0AmwRN26/oeMbBhCMFFninhmtjW4si
=ERFo
-----END PGP SIGNATURE-----

From rdobbins at cisco.com  Sun Mar 15 12:39:57 2009
From: rdobbins at cisco.com (Roland Dobbins)
Date: Mon, 16 Mar 2009 00:39:57 +0800
Subject: [c-nsp] Opinions of DDoS appliances, other techniques,
	most notably Cisco Guard
In-Reply-To: <F3318834F1F89D46857972DD4B411D700651DA6C@EXCHANGE.thenap.com>
References: <F3318834F1F89D46857972DD4B411D700651DA6C@EXCHANGE.thenap.com>
Message-ID: <725C9117-BE48-468B-A39E-B69347853BAB@cisco.com>


On Mar 15, 2009, at 11:54 PM, Drew Weaver wrote:

> Also, without a dedicated DDoS system deployed, what is the most  
> reliable/fastest way to determine the destination(s) of the attacks  
> (SNMP, NetFlow, etc)?

With or without a dedicated DDoS mitigation system, NetFlow-based  
anomaly-detection is generally considered to be the most scalable  
solution which provides network visibility of inbound/outbound/ 
crossbound traffic.

> Any particular software tools which are helpful for detecting this,  
> NetFlow for us has been slightly difficult to use for this task  
> mainly because we haven't found software that is really designed for  
> security rather than performance (would be nice if it did both?)

Arbor Peakflow SP, Narus Insight Manager, and Lancope StealthWatch Xe  
are three commercial NetFlow-based anomaly-detection systems.  There's  
a free (but not open-source, AFAIK) system which has recently been  
released on Windows (*NIX to come later); I haven't played with it  
myself, but here's a link:

<http://www.akmalabs.com/downloads_flowmatrix.php>

> Either systems/techniques that automatically mitigate or systems  
> that simply recommend mitigation steps/alert are both being evaluated.

I'm generally not a big fan of automatic mitigation, except possibly  
in some very limited situations/domains, as there's always the  
possibility it could be gamed.

> By mitigation I mean Null routing sources, null routing destinations  
> upstream (via communities), et cetera.


Again, think carefully before automating any sort of blackholing or  
other mitigation mechanism.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at cisco.com> // +852.9133.2844 mobile

   Some things are just too precious to entrust to computers.

		   -- Seth Hanford


From andy.bierlair at root.lu  Sun Mar 15 12:46:52 2009
From: andy.bierlair at root.lu (Andy BIERLAIR)
Date: Sun, 15 Mar 2009 17:46:52 +0100
Subject: [c-nsp] Netflow on SUP720-3BXL
In-Reply-To: <200903151718.22464.andy-lists@bourges.de>
References: <000501c9a57c$b05aacb0$11100610$@bierlair@root.lu>
	<200903151718.22464.andy-lists@bourges.de>
Message-ID: <000001c9a58d$a4cba0f0$ee62e2d0$@bierlair@root.lu>

I am not sure if I can upgrade this box to SXH. If would help, since a lot
of interfaces on that box are for customers who don't need the flow
counting.
This is a critical environment and I cannot afford the downtime and possible
side effects with a new IOS I haven't tested so far.

The mission I would like to achieve is not accounting for customers (would
be nice to have though), but more an analysis tool that shows me how much
traffic I am exchanging with a certain ASN, so that we can decide if direct
peering with that ASN instead of paying transit to reach it makes sense or
not.

So if for instance the Ops of ASN xxxx contact us to ask for peering on a
public exchange, we look it up in our stats and if we see that the average
traffic with ASN xxxx is 75 MBIT/s, we will probably peer. Right now I can
only guess how much we exchange, so I need a more accurate solution and I
was hoping that netflow is the key.

-
Andy

-----Original Message-----
From: Andreas Bourges [mailto:andy-lists at bourges.de] 
Sent: 15 March 2009 17:18
To: cisco-nsp at puck.nether.net
Cc: Andy BIERLAIR
Subject: Re: [c-nsp] Netflow on SUP720-3BXL

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,


On Sunday 15 March 2009 15:45:30 Andy BIERLAIR wrote:
> I'm trying to run netflow on one of our Cisco core routers (SUP720-3BXL
> with SXF15a), but I think I am hitting some limitations because of this:

>   mls aging fast time 5 threshold 32
>   mls aging long 300
>   mls aging normal 60

> Then I have this enabled on all border interfaces/vlans (peering / transit
> / other core routers) that are of interest for my stats:
>
>   ip route-cache flow

This command only affects packets processed by the MSFC - so at least with 
your IOS it doesn't matter if you configured it on all interfaces or only on

some. Once MLS NDE is activated, it exports all observed flows regardless of

the "ip route cache flow" command...

You could upgrade to an IOS >= SXH, which lets you enable mls nde on a per 
interface basis - this would (depending on your setup) reduce the amount of 
created flow entries (I suspect...).

> I have heard that more agressive aging might help, but I expect the
> router's traffic and pps to increase dramatically, so I'll be hitting the
> roof over and over again.
>
> I wouldn't mind analyzing only every 10th or 100th flow (sampling), which
> seems to be a common practice, but will it help?

This won't help on 65K/76K, since they only support "flow-sampling" - which 
means all flows are created in the tcam but not all of them are exported to 
the collector (to reduce export load and collector load).

> What is the common netflow setup without additional DFCs for a busy
router?

Since you are already equipped with Sup720-3BXL the one thing that can help
is 
to set the mls aging timers more aggressive, I suppose. 
If (and I'm not sure about that) per-interface mls nde reduces the created 
flows in the tcam, an upgrade to SXH could help, too...
Another thing would be to set the flow-mask to something different than
"full" 
- - which gives you less information but produces less flows, too. Depends
on 
your needs.

Regards,

Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkm9KksACgkQRrny/uOBVy490wCgiEtIs6b2GDeQiWwxOgp4Pnxg
xi0AmwRN26/oeMbBhCMFFninhmtjW4si
=ERFo
-----END PGP SIGNATURE-----


From rdobbins at cisco.com  Sun Mar 15 13:06:23 2009
From: rdobbins at cisco.com (Roland Dobbins)
Date: Mon, 16 Mar 2009 01:06:23 +0800
Subject: [c-nsp] Opinions of DDoS appliances, other techniques,
	most notably Cisco Guard
In-Reply-To: <725C9117-BE48-468B-A39E-B69347853BAB@cisco.com>
References: <F3318834F1F89D46857972DD4B411D700651DA6C@EXCHANGE.thenap.com>
	<725C9117-BE48-468B-A39E-B69347853BAB@cisco.com>
Message-ID: <04670DB7-99B1-4F55-8DDD-9C036F93E4AF@cisco.com>


On Mar 16, 2009, at 12:39 AM, Roland Dobbins wrote:

> Arbor Peakflow SP, Narus Insight Manager, and Lancope StealthWatch  
> Xe are three commercial NetFlow-based anomaly-detection systems.

I forgot to add Q1 Labs Q1Radar, and I believe NetQoS now have an  
anomaly-detection module, as well, though I've not seen it.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at cisco.com> // +852.9133.2844 mobile

   Some things are just too precious to entrust to computers.

		   -- Seth Hanford


From andy-lists at bourges.de  Sun Mar 15 14:04:26 2009
From: andy-lists at bourges.de (Andreas Bourges)
Date: Sun, 15 Mar 2009 19:04:26 +0100
Subject: [c-nsp] Netflow on SUP720-3BXL
In-Reply-To: <000001c9a58d$a4cba0f0$ee62e2d0$@bierlair@root.lu>
References: <000501c9a57c$b05aacb0$11100610$@bierlair@root.lu>
	<200903151718.22464.andy-lists@bourges.de>
	<000001c9a58d$a4cba0f0$ee62e2d0$@bierlair@root.lu>
Message-ID: <200903151904.27158.andy-lists@bourges.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

On Sunday 15 March 2009 17:46:52 Andy BIERLAIR wrote:
> This is a critical environment and I cannot afford the downtime and
> possible side effects with a new IOS I haven't tested so far.

I understand - quite a few threads related to SXH bugs appeared on the list, 
but most of them seem to be fixed in SXH3 if I remember correctly...

> The mission I would like to achieve is not accounting for customers (would
> be nice to have though), but more an analysis tool that shows me how much
> traffic I am exchanging with a certain ASN, so that we can decide if direct
> peering with that ASN instead of paying transit to reach it makes sense or
> not.

What about setting the mls flow mask to destination-source? Should reduce the 
generated flows significantly - at least for HTTP traffic I would suspect...

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/native/configuration/guide/netflow.html#wp1057334

> So if for instance the Ops of ASN xxxx contact us to ask for peering on a
> public exchange, we look it up in our stats and if we see that the average
> traffic with ASN xxxx is 75 MBIT/s, we will probably peer. Right now I can
> only guess how much we exchange, so I need a more accurate solution and I
> was hoping that netflow is the key.

I think NetFlow _is_ the key - it's just an odd hardware limitation that hits 
you there ;-)

Regards,

Andy


>
> -
> Andy
>
> -----Original Message-----
> From: Andreas Bourges [mailto:andy-lists at bourges.de]
> Sent: 15 March 2009 17:18
> To: cisco-nsp at puck.nether.net
> Cc: Andy BIERLAIR
> Subject: Re: [c-nsp] Netflow on SUP720-3BXL
>
> - gpg control packet
> Hi,
>
> On Sunday 15 March 2009 15:45:30 Andy BIERLAIR wrote:
> > I'm trying to run netflow on one of our Cisco core routers (SUP720-3BXL
> > with SXF15a), but I think I am hitting some limitations because of this:
> >
> >   mls aging fast time 5 threshold 32
> >   mls aging long 300
> >   mls aging normal 60
> >
> > Then I have this enabled on all border interfaces/vlans (peering /
> > transit / other core routers) that are of interest for my stats:
> >
> >   ip route-cache flow
>
> This command only affects packets processed by the MSFC - so at least with
> your IOS it doesn't matter if you configured it on all interfaces or only
> on
>
> some. Once MLS NDE is activated, it exports all observed flows regardless
> of
>
> the "ip route cache flow" command...
>
> You could upgrade to an IOS >= SXH, which lets you enable mls nde on a per
> interface basis - this would (depending on your setup) reduce the amount of
> created flow entries (I suspect...).
>
> > I have heard that more agressive aging might help, but I expect the
> > router's traffic and pps to increase dramatically, so I'll be hitting the
> > roof over and over again.
> >
> > I wouldn't mind analyzing only every 10th or 100th flow (sampling), which
> > seems to be a common practice, but will it help?
>
> This won't help on 65K/76K, since they only support "flow-sampling" - which
> means all flows are created in the tcam but not all of them are exported to
> the collector (to reduce export load and collector load).
>
> > What is the common netflow setup without additional DFCs for a busy
>
> router?
>
> Since you are already equipped with Sup720-3BXL the one thing that can help
> is
> to set the mls aging timers more aggressive, I suppose.
> If (and I'm not sure about that) per-interface mls nde reduces the created
> flows in the tcam, an upgrade to SXH could help, too...
> Another thing would be to set the flow-mask to something different than
> "full"
> - which gives you less information but produces less flows, too. Depends
> on
> your needs.
>
> Regards,
>
> Andy

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkm9QysACgkQRrny/uOBVy4fZACgsEvjjL0lHtnuDDHWDz4ZdlOl
ytkAnRgLZdD+G2BvZBGdU5HNNMDgNnE4
=8H6C
-----END PGP SIGNATURE-----

From bdikici at gmail.com  Sun Mar 15 14:15:33 2009
From: bdikici at gmail.com (Burak Dikici)
Date: Sun, 15 Mar 2009 20:15:33 +0200
Subject: [c-nsp] BGP conditional advertisemet - NON-EXIST route map's
	access-list problem
In-Reply-To: <fsbujrb52s0kyzgvj9UYAxe124vaj_firegpg@mail.gmail.com>
References: <d9281f5c0903150606m3fb9e1ddwfc75c6b7179b87af@mail.gmail.com>
	<fsbujrb52s0kyzgvj9UYAxe124vaj_firegpg@mail.gmail.com>
Message-ID: <d9281f5c0903151115m4ff0b43cv4d5754d3bf53d9fe@mail.gmail.com>

Hi Mateusz ,

For better understanding , i have attached the topology screenshot and the
router's configuration files. (By the way , this is a lab config.)

In the attached Router's configuration ,

access-list 65 permit 172.16.1.0 0.0.0.255

command is used and with this command bgp conditional advertisement is
working fine.

But when i use ,

access-list 65 permit any

command , the conditional advertisement doesn't work.

Regards.

On Sun, Mar 15, 2009 at 4:53 PM, Mateusz Blaszczyk <blahu77 at gmail.com>wrote:

> Burak,
>
> ip as-path access-list 1 permit ^200 !!! (ISP-1 AS number) !!!
>>
>> access-list 65 permit any !!! (permit any packet from ISP-2) !!!
>>
>> route-map NON-EXIST permit 10 !!! (this matches any route from AS200) !!!
>> match ip address 65
>> match as-path 1
>>
>
> you can match only on ACL and prefix-list int the *-EXIST-MAPs.
> Also you dont match packets rather prefixes.
>
> So choose a ISP-1 prefix (some infrastructure IPs or so) and match in
> prefix-list/route-map.
> Then if it is gone, start advertisiing to routes in ADVERTISE
>
> Best Regards,
>
> -mat
>
> --
> pgp-key 0x1C655CAB
>
>

From charles at thewybles.com  Sun Mar 15 13:49:55 2009
From: charles at thewybles.com (Charles Wyble)
Date: Sun, 15 Mar 2009 10:49:55 -0700
Subject: [c-nsp] Opinions of DDoS appliances, other techniques,
 most notably Cisco Guard
In-Reply-To: <725C9117-BE48-468B-A39E-B69347853BAB@cisco.com>
References: <F3318834F1F89D46857972DD4B411D700651DA6C@EXCHANGE.thenap.com>
	<725C9117-BE48-468B-A39E-B69347853BAB@cisco.com>
Message-ID: <49BD3FC3.4080903@thewybles.com>

Searching for  netflow ids

( 
http://www.google.com/search?q=netflow+ids&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a)

returns some very interesting results.


From gert at greenie.muc.de  Sun Mar 15 14:32:50 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Sun, 15 Mar 2009 19:32:50 +0100
Subject: [c-nsp] Netflow on SUP720-3BXL
In-Reply-To: <200903151904.27158.andy-lists@bourges.de>
References: <200903151718.22464.andy-lists@bourges.de>
	<200903151904.27158.andy-lists@bourges.de>
Message-ID: <20090315183250.GH290@greenie.muc.de>

Hi,

On Sun, Mar 15, 2009 at 07:04:26PM +0100, Andreas Bourges wrote:
> I understand - quite a few threads related to SXH bugs appeared on the list, 
> but most of them seem to be fixed in SXH3 if I remember correctly...

SXH3a.  SXH3 has the BGP ghost bug.

(SXI has "slow memory leaks" in BGP, at least for us.  Cisco case has been
opened, but hasn't proceeded anywhere yet).

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/20090315/412ebd24/attachment-0001.bin>

From charles at thewybles.com  Sun Mar 15 13:43:14 2009
From: charles at thewybles.com (Charles Wyble)
Date: Sun, 15 Mar 2009 10:43:14 -0700
Subject: [c-nsp] Opinions of DDoS appliances, other techniques,
 most notably Cisco Guard
In-Reply-To: <725C9117-BE48-468B-A39E-B69347853BAB@cisco.com>
References: <F3318834F1F89D46857972DD4B411D700651DA6C@EXCHANGE.thenap.com>
	<725C9117-BE48-468B-A39E-B69347853BAB@cisco.com>
Message-ID: <49BD3E32.9080405@thewybles.com>



Roland Dobbins wrote:
> 
> On Mar 15, 2009, at 11:54 PM, Drew Weaver wrote:
> 
>> Also, without a dedicated DDoS system deployed, what is the most 
>> reliable/fastest way to determine the destination(s) of the attacks 
>> (SNMP, NetFlow, etc)?
> 
> With or without a dedicated DDoS mitigation system, NetFlow-based 
> anomaly-detection is generally considered to be the most scalable 
> solution which provides network visibility of 
> inbound/outbound/crossbound traffic.


Indeed. It is built right into the gear which is nice. :) You could also 
look at Ciso Flexible Packet Matching ( 
http://www.cisco.com/en/US/products/ps6723/index.html) ... it's more of 
a snort type solution.


> 
>> Any particular software tools which are helpful for detecting this, 
>> NetFlow for us has been slightly difficult to use for this task mainly 
>> because we haven't found software that is really designed for security 
>> rather than performance (would be nice if it did both?)
> 
> Arbor Peakflow SP, Narus Insight Manager, and Lancope StealthWatch Xe 
> are three commercial NetFlow-based anomaly-detection systems.  There's a 
> free (but not open-source, AFAIK) system which has recently been 
> released on Windows (*NIX to come later); I haven't played with it 
> myself, but here's a link:
> 
> <http://www.akmalabs.com/downloads_flowmatrix.php>


Also check out ntop. From 
http://www.simpleweb.org/tutorials/implementation/ntop/ntopa2.html

   2.4 Detection of Network Security Violations

In networks, most of the security attacks come from the network itself. 
For this reason ntop provides the users support for both tracking 
ongoing attacks and identifying potential security holes including IP 
spoofing, network cards in promiscuous mode, denial of service attacks, 
trojan horses (that use well known ports) and portscan attacks.

When a security violation or a network misconfiguration is identified, 
ntop offers facilities to generate alarms for the network operator (via 
e-mail, SNMP traps or Short Messaging Systems) and to perform specific 
actions (when applicable) in order to block the attack. As it is also 
possible to keep traffic information stored into a database, the records 
can be used to understand the attack and prevent further similar 
occurrences. Further information on the use of ntop for security 
purposes is available on [7].

It is important to note that ntop, as well as other monitoring tools, 
might pose security threats if not installed and configured properly. 
Free access to ntop's web interface will allow any user with web access 
to read all the information provided by ntop, gaining knowledge about 
the network that would not be disclosed otherwise.



> 
>> Either systems/techniques that automatically mitigate or systems that 
>> simply recommend mitigation steps/alert are both being evaluated.
> 
> I'm generally not a big fan of automatic mitigation, except possibly in 
> some very limited situations/domains, as there's always the possibility 
> it could be gamed.

Indeed. Your signature is very appropriate here. :)

> 
>   Some things are just too precious to entrust to computers.


Like say getting yelled at/fired by the boss cause you knocked off a 
large portion of your customers due to a missed condition in your 
script. :)



From ip at ioshints.info  Sun Mar 15 14:46:16 2009
From: ip at ioshints.info (Ivan Pepelnjak)
Date: Sun, 15 Mar 2009 19:46:16 +0100
Subject: [c-nsp] BGP conditional advertisemet - NON-EXIST route
	map'saccess-list problem
In-Reply-To: <d9281f5c0903151115m4ff0b43cv4d5754d3bf53d9fe@mail.gmail.com>
References: <d9281f5c0903150606m3fb9e1ddwfc75c6b7179b87af@mail.gmail.com><fsbujrb52s0kyzgvj9UYAxe124vaj_firegpg@mail.gmail.com>
	<d9281f5c0903151115m4ff0b43cv4d5754d3bf53d9fe@mail.gmail.com>
Message-ID: <003b01c9a59e$5370ffa0$0a00000a@nil.si>

You can't use "permit any" because it would match any route in the IP
routing table (including the connected interfaces). The access list used in
NON-EXIST-MAP is used on the IP routing table, not on the BGP table (that's
why the AS path doesn't work either).

Ivan

> -----Original Message-----
> From: Burak Dikici [mailto:bdikici at gmail.com] 
> Sent: Sunday, March 15, 2009 7:16 PM
> To: Mateusz Blaszczyk
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] BGP conditional advertisemet - NON-EXIST 
> route map'saccess-list problem
> 
> Hi Mateusz ,
> 
> For better understanding , i have attached the topology 
> screenshot and the router's configuration files. (By the way 
> , this is a lab config.)
> 
> In the attached Router's configuration ,
> 
> access-list 65 permit 172.16.1.0 0.0.0.255
> 
> command is used and with this command bgp conditional 
> advertisement is working fine.
> 
> But when i use ,
> 
> access-list 65 permit any
> 
> command , the conditional advertisement doesn't work.


From bdikici at gmail.com  Sun Mar 15 15:19:09 2009
From: bdikici at gmail.com (Burak Dikici)
Date: Sun, 15 Mar 2009 21:19:09 +0200
Subject: [c-nsp] BGP conditional advertisemet - NON-EXIST route
	map'saccess-list problem
In-Reply-To: <003b01c9a59e$5370ffa0$0a00000a@nil.si>
References: <d9281f5c0903150606m3fb9e1ddwfc75c6b7179b87af@mail.gmail.com>
	<fsbujrb52s0kyzgvj9UYAxe124vaj_firegpg@mail.gmail.com>
	<d9281f5c0903151115m4ff0b43cv4d5754d3bf53d9fe@mail.gmail.com>
	<003b01c9a59e$5370ffa0$0a00000a@nil.si>
Message-ID: <d9281f5c0903151219i425f73f7md04ca5f34f388d66@mail.gmail.com>

Hi Ivan ,

 Ok than , what should i use for  NON-EXIST route-map's access-list ? Which
prefix should i trust from ISP-1 (Primary ISP) ?
 Is it necessary to use  "match ip address" and "match as-path" statements
together in the  NON-EXIST route-map ?

On Sun, Mar 15, 2009 at 8:46 PM, Ivan Pepelnjak <ip at ioshints.info> wrote:

> You can't use "permit any" because it would match any route in the IP
> routing table (including the connected interfaces). The access list used in
> NON-EXIST-MAP is used on the IP routing table, not on the BGP table (that's
> why the AS path doesn't work either).
>
> Ivan
>
> > -----Original Message-----
> > From: Burak Dikici [mailto:bdikici at gmail.com]
> > Sent: Sunday, March 15, 2009 7:16 PM
> > To: Mateusz Blaszczyk
> > Cc: cisco-nsp at puck.nether.net
> > Subject: Re: [c-nsp] BGP conditional advertisemet - NON-EXIST
> > route map'saccess-list problem
> >
>  > Hi Mateusz ,
> >
> > For better understanding , i have attached the topology
> > screenshot and the router's configuration files. (By the way
> > , this is a lab config.)
> >
> > In the attached Router's configuration ,
> >
> > access-list 65 permit 172.16.1.0 0.0.0.255
> >
> > command is used and with this command bgp conditional
> > advertisement is working fine.
> >
> > But when i use ,
> >
> > access-list 65 permit any
> >
> > command , the conditional advertisement doesn't work.
>
>

From yanf787 at yahoo.com  Sun Mar 15 14:46:17 2009
From: yanf787 at yahoo.com (Yan Filyurin)
Date: Sun, 15 Mar 2009 11:46:17 -0700 (PDT)
Subject: [c-nsp] BGP conditional advertisemet - NON-EXIST route map's
	access-list problem
References: <fsbujrb52s0kyzgvj9UYAxe124vaj_firegpg@mail.gmail.com>
Message-ID: <695044.82571.qm@web54004.mail.re2.yahoo.com>

If you want ISP 2 to be used as a backup for ISP1 inboud traffic could you just advertise your routes to ISP2 with, say bigger AS path to the point where even ISP2 thinks it is best to go somewhere else than directly to you?  

As far as conditional advertisement goes. Mateusz is absolutely right and you just have to pick a route, which will go into your non-esist-map.  Also as you are advertising routes to ISP2, it may make sense to create a regular outgoing route map to make sure you are not advertising ISP1 routes to ISP2, so only your route matches.  That is where you can match on the AS path.  Then you can just have an access list or prefix list in your advertise map, which can decide whether to advertise it or not. 

You could also create a static route that would be conditional on some IP SLA condition and have your route generation or conditional advertisement based on that, but that would just be weird. :)

Yan



________________________________
From: Mateusz Blaszczyk <blahu77 at gmail.com>
To: Burak Dikici <bdikici at gmail.com>
Cc: cisco-nsp at puck.nether.net
Sent: Sunday, March 15, 2009 10:53:25 AM
Subject: Re: [c-nsp] BGP conditional advertisemet - NON-EXIST route map's access-list problem

Burak,

> ip as-path access-list 1 permit ^200 !!! (ISP-1 AS number) !!!
>
> access-list 65 permit any !!! (permit any packet from ISP-2) !!!
>
> route-map NON-EXIST permit 10 !!! (this matches any route from AS200) !!!
> match ip address 65
> match as-path 1

you can match only on ACL and prefix-list int the *-EXIST-MAPs.
Also you dont match packets rather prefixes.

So choose a ISP-1 prefix (some infrastructure IPs or so) and match in prefix-list/route-map.
Then if it is gone, start advertisiing to routes in ADVERTISE

Best Regards,

-mat

-- 
pgp-key 0x1C655CAB


      

From ip at ioshints.info  Sun Mar 15 15:48:39 2009
From: ip at ioshints.info (Ivan Pepelnjak)
Date: Sun, 15 Mar 2009 20:48:39 +0100
Subject: [c-nsp] BGP conditional advertisemet - NON-EXIST route
	map'saccess-list problem
In-Reply-To: <d9281f5c0903151219i425f73f7md04ca5f34f388d66@mail.gmail.com>
References: <d9281f5c0903150606m3fb9e1ddwfc75c6b7179b87af@mail.gmail.com>
	<fsbujrb52s0kyzgvj9UYAxe124vaj_firegpg@mail.gmail.com>
	<d9281f5c0903151115m4ff0b43cv4d5754d3bf53d9fe@mail.gmail.com>
	<003b01c9a59e$5370ffa0$0a00000a@nil.si>
	<d9281f5c0903151219i425f73f7md04ca5f34f388d66@mail.gmail.com>
Message-ID: <005101c9a5a7$0a7326d0$0a00000a@nil.si>

That's the problem everyone has with the NON-EXIST-MAP :) Usually the IP
prefix used to address the ISP-1 infrastructure is the best bet.
 
The "match as-path" statement in the NON-EXIST-MAP is irrelevant (unless I'm
totally wrong about the match being made with the routes in the IP routing
table :).
 
Ivan


  _____  

From: Burak Dikici [mailto:bdikici at gmail.com] 
Sent: Sunday, March 15, 2009 8:19 PM
To: Ivan Pepelnjak
Cc: Mateusz Blaszczyk; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] BGP conditional advertisemet - NON-EXIST route
map'saccess-list problem


Hi Ivan , 
 
 Ok than , what should i use for  NON-EXIST route-map's access-list ? Which
prefix should i trust from ISP-1 (Primary ISP) ?  
 Is it necessary to use  "match ip address" and "match as-path" statements
together in the  NON-EXIST route-map ?


On Sun, Mar 15, 2009 at 8:46 PM, Ivan Pepelnjak <ip at ioshints.info> wrote:


You can't use "permit any" because it would match any route in the IP
routing table (including the connected interfaces). The access list used in
NON-EXIST-MAP is used on the IP routing table, not on the BGP table (that's
why the AS path doesn't work either).

Ivan


> -----Original Message-----
> From: Burak Dikici [mailto:bdikici at gmail.com]
> Sent: Sunday, March 15, 2009 7:16 PM
> To: Mateusz Blaszczyk
> Cc: cisco-nsp at puck.nether.net

> Subject: Re: [c-nsp] BGP conditional advertisemet - NON-EXIST
> route map'saccess-list problem
>

> Hi Mateusz ,
>
> For better understanding , i have attached the topology
> screenshot and the router's configuration files. (By the way
> , this is a lab config.)
>
> In the attached Router's configuration ,
>
> access-list 65 permit 172.16.1.0 0.0.0.255
>
> command is used and with this command bgp conditional
> advertisement is working fine.
>
> But when i use ,
>
> access-list 65 permit any
>
> command , the conditional advertisement doesn't work.





From blahu77 at gmail.com  Sun Mar 15 16:44:58 2009
From: blahu77 at gmail.com (Mateusz Blaszczyk)
Date: Sun, 15 Mar 2009 20:44:58 +0000
Subject: [c-nsp] BGP conditional advertisemet - NON-EXIST route
	map'saccess-list problem
In-Reply-To: <003b01c9a59e$5370ffa0$0a00000a@nil.si>
References: <d9281f5c0903150606m3fb9e1ddwfc75c6b7179b87af@mail.gmail.com>
	<fsbujrb52s0kyzgvj9UYAxe124vaj_firegpg@mail.gmail.com>
	<d9281f5c0903151115m4ff0b43cv4d5754d3bf53d9fe@mail.gmail.com>
	<003b01c9a59e$5370ffa0$0a00000a@nil.si>
Message-ID: <383357750903151344y62376a8cy100efe6269f420@mail.gmail.com>

Ivan,

2009/3/15 Ivan Pepelnjak <ip at ioshints.info>:
> You can't use "permit any" because it would match any route in the IP
> routing table (including the connected interfaces).

is "permit any" matching 0.0.0.0/0 le 32 or just 0.0.0.0/0, I was
thinking that the latter?

> The access list used in
> NON-EXIST-MAP is used on the IP routing table, not on the BGP table (that's
> why the AS path doesn't work either).

it doesn't work so what is the result of match ? true? false?
The whole entry has to be evaluated somehow, doesn't it?

Best Regards,

-mat

-- 
pgp-key 0x1C655CAB

From RPhookun at lecg.com  Sun Mar 15 17:03:57 2009
From: RPhookun at lecg.com (RPhookun at lecg.com)
Date: Sun, 15 Mar 2009 14:03:57 -0700
Subject: [c-nsp] BGP conditional advertisemet - NON-EXIST
 route	map'saccess-list problem
In-Reply-To: <005101c9a5a7$0a7326d0$0a00000a@nil.si>
Message-ID: <OFCEBBCF86.F0411AEE-ON8825757A.0071EEAB-8825757A.0073D706@lecg.com>

I agree with Ivan in that the tracked prefix  in the Non-Exist-Map should 
be the ISP-1 infrastructure address because in its absence you wouldn't be 
receiving any other routes from ISP-1
However, the match of the tracked prefix is from the BGP table *not* the 
IP routing table and "match-as-path" can be very relevant in some 
topologies and its absence in the Non-Exist-Map can cause the conditional 
advertisement feature to break.

Cisco has an excellent example - "Configuring and Verifying the 
Conditional Advertisement Feature"

./Randy






"Ivan Pepelnjak" <ip at ioshints.info> 
Sent by: cisco-nsp-bounces at puck.nether.net
03/15/2009 12:48 PM

To
"'Burak Dikici'" <bdikici at gmail.com>
cc
cisco-nsp at puck.nether.net
Subject
Re: [c-nsp] BGP conditional advertisemet - NON-EXIST route 
map'saccess-list problem






That's the problem everyone has with the NON-EXIST-MAP :) Usually the IP
prefix used to address the ISP-1 infrastructure is the best bet.
 
The "match as-path" statement in the NON-EXIST-MAP is irrelevant (unless 
I'm
totally wrong about the match being made with the routes in the IP routing
table :).
 
Ivan


  _____ 

From: Burak Dikici [mailto:bdikici at gmail.com] 
Sent: Sunday, March 15, 2009 8:19 PM
To: Ivan Pepelnjak
Cc: Mateusz Blaszczyk; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] BGP conditional advertisemet - NON-EXIST route
map'saccess-list problem


Hi Ivan , 
 
 Ok than , what should i use for  NON-EXIST route-map's access-list ? 
Which
prefix should i trust from ISP-1 (Primary ISP) ? 
 Is it necessary to use  "match ip address" and "match as-path" statements
together in the  NON-EXIST route-map ?


On Sun, Mar 15, 2009 at 8:46 PM, Ivan Pepelnjak <ip at ioshints.info> wrote:


You can't use "permit any" because it would match any route in the IP
routing table (including the connected interfaces). The access list used 
in
NON-EXIST-MAP is used on the IP routing table, not on the BGP table 
(that's
why the AS path doesn't work either).

Ivan


> -----Original Message-----
> From: Burak Dikici [mailto:bdikici at gmail.com]
> Sent: Sunday, March 15, 2009 7:16 PM
> To: Mateusz Blaszczyk
> Cc: cisco-nsp at puck.nether.net

> Subject: Re: [c-nsp] BGP conditional advertisemet - NON-EXIST
> route map'saccess-list problem
>

> Hi Mateusz ,
>
> For better understanding , i have attached the topology
> screenshot and the router's configuration files. (By the way
> , this is a lab config.)
>
> In the attached Router's configuration ,
>
> access-list 65 permit 172.16.1.0 0.0.0.255
>
> command is used and with this command bgp conditional
> advertisement is working fine.
>
> But when i use ,
>
> access-list 65 permit any
>
> command , the conditional advertisement doesn't work.




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


From bdikici at gmail.com  Sun Mar 15 17:21:35 2009
From: bdikici at gmail.com (Burak Dikici)
Date: Sun, 15 Mar 2009 23:21:35 +0200
Subject: [c-nsp] BGP conditional advertisemet - NON-EXIST route
	map'saccess-list problem
In-Reply-To: <OFCEBBCF86.F0411AEE-ON8825757A.0071EEAB-8825757A.0073D706@lecg.com>
References: <005101c9a5a7$0a7326d0$0a00000a@nil.si>
	<OFCEBBCF86.F0411AEE-ON8825757A.0071EEAB-8825757A.0073D706@lecg.com>
Message-ID: <d9281f5c0903151421s34c17dddt952d88537a8b2e2c@mail.gmail.com>

 I have made a change on the lab with the commands which are written below ,
but ISP-2 still getting my announcment. No success...


ip as-path access-list 1 permit ^200  (ISP-1 AS number)

ip prefix-list AS200-track seq 5 permit 192.168.200.0/24 (subnet
between multihoming router and ISP-1 router)

route-map NON-EXIST permit 10
 match ip address prefix-list AS200-track
 match as-path 1

router bgp 10
 neighbor 192.168.100.1 advertise-map ADVERTISE non-exist-map NON-EXIST








On Sun, Mar 15, 2009 at 11:03 PM, <RPhookun at lecg.com> wrote:

>
> I agree with Ivan in that the tracked prefix  in the Non-Exist-Map should
> be the ISP-1 infrastructure address because in its absence you wouldn't be
> receiving any other routes from ISP-1
> However, the match of the tracked prefix is from the BGP table *not* the IP
> routing table and "match-as-path" can be very relevant in some topologies
> and its absence in the Non-Exist-Map can cause the conditional advertisement
> feature to break.
>
> Cisco has an excellent example - "Configuring and Verifying the Conditional
> Advertisement Feature"
>
> ./Randy
>
>
>
>
>
>   *"Ivan Pepelnjak" <ip at ioshints.info>*
> Sent by: cisco-nsp-bounces at puck.nether.net
>
> 03/15/2009 12:48 PM
>    To
>  "'Burak Dikici'" <bdikici at gmail.com>
>  cc
>   cisco-nsp at puck.nether.net  Subject
> Re: [c-nsp] BGP conditional advertisemet - NON-EXIST route
>  map'saccess-list problem
>
>
>
>
>
>  That's the problem everyone has with the NON-EXIST-MAP :) Usually the IP
> prefix used to address the ISP-1 infrastructure is the best bet.
>
> The "match as-path" statement in the NON-EXIST-MAP is irrelevant (unless
> I'm
> totally wrong about the match being made with the routes in the IP routing
> table :).
>
> Ivan
>
>
>  _____
>
> From: Burak Dikici [mailto:bdikici at gmail.com]
> Sent: Sunday, March 15, 2009 8:19 PM
> To: Ivan Pepelnjak
> Cc: Mateusz Blaszczyk; cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] BGP conditional advertisemet - NON-EXIST route
> map'saccess-list problem
>
>
> Hi Ivan ,
>
> Ok than , what should i use for  NON-EXIST route-map's access-list ? Which
> prefix should i trust from ISP-1 (Primary ISP) ?
> Is it necessary to use  "match ip address" and "match as-path" statements
> together in the  NON-EXIST route-map ?
>
>
> On Sun, Mar 15, 2009 at 8:46 PM, Ivan Pepelnjak <ip at ioshints.info> wrote:
>
>
> You can't use "permit any" because it would match any route in the IP
> routing table (including the connected interfaces). The access list used in
> NON-EXIST-MAP is used on the IP routing table, not on the BGP table (that's
> why the AS path doesn't work either).
>
> Ivan
>
>
> > -----Original Message-----
> > From: Burak Dikici [mailto:bdikici at gmail.com]
> > Sent: Sunday, March 15, 2009 7:16 PM
> > To: Mateusz Blaszczyk
> > Cc: cisco-nsp at puck.nether.net
>
> > Subject: Re: [c-nsp] BGP conditional advertisemet - NON-EXIST
> > route map'saccess-list problem
> >
>
> > Hi Mateusz ,
> >
> > For better understanding , i have attached the topology
> > screenshot and the router's configuration files. (By the way
> > , this is a lab config.)
> >
> > In the attached Router's configuration ,
> >
> > access-list 65 permit 172.16.1.0 0.0.0.255
> >
> > command is used and with this command bgp conditional
> > advertisement is working fine.
> >
> > But when i use ,
> >
> > access-list 65 permit any
> >
> > command , the conditional advertisement doesn't work.
>
>
>
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>

From RPhookun at lecg.com  Sun Mar 15 17:39:46 2009
From: RPhookun at lecg.com (RPhookun at lecg.com)
Date: Sun, 15 Mar 2009 14:39:46 -0700
Subject: [c-nsp] BGP conditional advertisemet - NON-EXIST
 route	map'saccess-list problem
In-Reply-To: <d9281f5c0903151421s34c17dddt952d88537a8b2e2c@mail.gmail.com>
Message-ID: <OF6459BE61.84A0C582-ON8825757A.00764CFA-8825757A.00771E6F@lecg.com>

One gotcha I ran into sometime ago -  on 12.4 T

the  neighbor 192.168.100.1 advertise-map ADVERTISE non-exist-map 
NON-EXIST has to be configured in the address-family ipv4 

conf t
router bgp 10
address-family ipv4
neighbor 192.168.100.1 advertise-map ADVERTISE non-exist-map NON-EXIST
exit-address-family

Not sure if this is your case. 

can you include the output of - 

sh ip bgp neigh x.x.x.x
sh ip bgp neigh x.x.x.x advertised routes?

Regards,
./Randy






Burak Dikici <bdikici at gmail.com> 
Sent by: cisco-nsp-bounces at puck.nether.net
03/15/2009 02:21 PM

To
RPhookun at lecg.com
cc
Ivan Pepelnjak <ip at ioshints.info>, cisco-nsp-bounces at puck.nether.net, 
cisco-nsp at puck.nether.net
Subject
Re: [c-nsp] BGP conditional advertisemet - NON-EXIST route 
map'saccess-list problem






 I have made a change on the lab with the commands which are written below 
,
but ISP-2 still getting my announcment. No success...


ip as-path access-list 1 permit ^200  (ISP-1 AS number)

ip prefix-list AS200-track seq 5 permit 192.168.200.0/24 (subnet
between multihoming router and ISP-1 router)

route-map NON-EXIST permit 10
 match ip address prefix-list AS200-track
 match as-path 1

router bgp 10
 neighbor 192.168.100.1 advertise-map ADVERTISE non-exist-map NON-EXIST








On Sun, Mar 15, 2009 at 11:03 PM, <RPhookun at lecg.com> wrote:

>
> I agree with Ivan in that the tracked prefix  in the Non-Exist-Map 
should
> be the ISP-1 infrastructure address because in its absence you wouldn't 
be
> receiving any other routes from ISP-1
> However, the match of the tracked prefix is from the BGP table *not* the 
IP
> routing table and "match-as-path" can be very relevant in some 
topologies
> and its absence in the Non-Exist-Map can cause the conditional 
advertisement
> feature to break.
>
> Cisco has an excellent example - "Configuring and Verifying the 
Conditional
> Advertisement Feature"
>
> ./Randy
>
>
>
>
>
>   *"Ivan Pepelnjak" <ip at ioshints.info>*
> Sent by: cisco-nsp-bounces at puck.nether.net
>
> 03/15/2009 12:48 PM
>    To
>  "'Burak Dikici'" <bdikici at gmail.com>
>  cc
>   cisco-nsp at puck.nether.net  Subject
> Re: [c-nsp] BGP conditional advertisemet - NON-EXIST route
>  map'saccess-list problem
>
>
>
>
>
>  That's the problem everyone has with the NON-EXIST-MAP :) Usually the 
IP
> prefix used to address the ISP-1 infrastructure is the best bet.
>
> The "match as-path" statement in the NON-EXIST-MAP is irrelevant (unless
> I'm
> totally wrong about the match being made with the routes in the IP 
routing
> table :).
>
> Ivan
>
>
>  _____
>
> From: Burak Dikici [mailto:bdikici at gmail.com]
> Sent: Sunday, March 15, 2009 8:19 PM
> To: Ivan Pepelnjak
> Cc: Mateusz Blaszczyk; cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] BGP conditional advertisemet - NON-EXIST route
> map'saccess-list problem
>
>
> Hi Ivan ,
>
> Ok than , what should i use for  NON-EXIST route-map's access-list ? 
Which
> prefix should i trust from ISP-1 (Primary ISP) ?
> Is it necessary to use  "match ip address" and "match as-path" 
statements
> together in the  NON-EXIST route-map ?
>
>
> On Sun, Mar 15, 2009 at 8:46 PM, Ivan Pepelnjak <ip at ioshints.info> 
wrote:
>
>
> You can't use "permit any" because it would match any route in the IP
> routing table (including the connected interfaces). The access list used 
in
> NON-EXIST-MAP is used on the IP routing table, not on the BGP table 
(that's
> why the AS path doesn't work either).
>
> Ivan
>
>
> > -----Original Message-----
> > From: Burak Dikici [mailto:bdikici at gmail.com]
> > Sent: Sunday, March 15, 2009 7:16 PM
> > To: Mateusz Blaszczyk
> > Cc: cisco-nsp at puck.nether.net
>
> > Subject: Re: [c-nsp] BGP conditional advertisemet - NON-EXIST
> > route map'saccess-list problem
> >
>
> > Hi Mateusz ,
> >
> > For better understanding , i have attached the topology
> > screenshot and the router's configuration files. (By the way
> > , this is a lab config.)
> >
> > In the attached Router's configuration ,
> >
> > access-list 65 permit 172.16.1.0 0.0.0.255
> >
> > command is used and with this command bgp conditional
> > advertisement is working fine.
> >
> > But when i use ,
> >
> > access-list 65 permit any
> >
> > command , the conditional advertisement doesn't work.
>
>
>
>
> _______________________________________________
> cisco-nsp mailing 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 bdikici at gmail.com  Sun Mar 15 18:14:29 2009
From: bdikici at gmail.com (Burak Dikici)
Date: Mon, 16 Mar 2009 00:14:29 +0200
Subject: [c-nsp] BGP conditional advertisemet - NON-EXIST route
	map'saccess-list problem
In-Reply-To: <OF6459BE61.84A0C582-ON8825757A.00764CFA-8825757A.00771E6F@lecg.com>
References: <d9281f5c0903151421s34c17dddt952d88537a8b2e2c@mail.gmail.com>
	<OF6459BE61.84A0C582-ON8825757A.00764CFA-8825757A.00771E6F@lecg.com>
Message-ID: <d9281f5c0903151514j7635f6c6r7f803656b166ae4b@mail.gmail.com>

You can use this kind of configuration option , new style config.  But , the
old sytle is still supported. Here is the configs and show commands ;



Router#show run
!
interface FastEthernet0/0
 description ISP-1_connection
 ip address 192.168.200.2 255.255.255.0
 duplex auto
 speed auto
!
interface Serial0/0
 description ISP-2_connection
 ip address 192.168.100.2 255.255.255.0
 clock rate 1000000
!
interface FastEthernet0/1
 ip address 10.1.1.1 255.255.255.0
 duplex auto
 speed auto
!
router bgp 10
 bgp log-neighbor-changes
 neighbor 192.168.100.1 remote-as 100
 neighbor 192.168.200.1 remote-as 200
 !
 address-family ipv4
  neighbor 192.168.100.1 activate
  neighbor 192.168.100.1 advertise-map ADVERTISE non-exist-map NON-EXIST
  neighbor 192.168.100.1 weight 500
  neighbor 192.168.100.1 distribute-list 15 out
  neighbor 192.168.200.1 activate
  neighbor 192.168.200.1 weight 1000
  neighbor 192.168.200.1 distribute-list 15 out
  no auto-summary
  no synchronization
  network 10.1.1.0 mask 255.255.255.0
 exit-address-family
!
ip as-path access-list 1 permit ^200
!
ip prefix-list AS200-track seq 5 permit 192.168.200.0/24
access-list 15 permit 10.1.1.0
access-list 60 permit 10.1.1.0 0.0.0.255
!
route-map NON-EXIST permit 10
 match ip address prefix-list AS200-track
 match as-path 1
!
route-map ADVERTISE permit 10
 match ip address 60





ISP-1#show run
!
interface FastEthernet0/0
 description Router_connection
 ip address 192.168.200.1 255.255.255.0
 duplex auto
 speed auto
!
interface FastEthernet0/1
 ip address 172.16.1.1 255.255.255.0
 duplex auto
 speed auto
router bgp 200
 no synchronization
 bgp log-neighbor-changes
 network 172.16.1.0 mask 255.255.255.0
 neighbor 192.168.200.2 remote-as 10
 no auto-summary





ISP-2#show run
!
interface Serial0/0
 description Router_connection
 ip address 192.168.100.1 255.255.255.0
 clock rate 2000000
!
router bgp 100
 no synchronization
 bgp log-neighbor-changes
 neighbor 192.168.100.2 remote-as 10
 no auto-summary








Router#show ip bgp neighbors 192.168.200.1

BGP neighbor is 192.168.200.1,  remote AS 200, external link
  BGP version 4, remote router ID 192.168.200.1
  BGP state = Established, up for 01:15:06
  Last read 00:00:08, last write 00:00:06, hold time is 180, keepalive
interval is 60 seconds
  Neighbor capabilities:
    Route refresh: advertised and received(old & new)
    Address family IPv4 Unicast: advertised and received
  Message statistics:
    InQ depth is 0
    OutQ depth is 0
                         Sent       Rcvd
    Opens:                  1          1
    Notifications:          0          0
    Updates:                5          4
    Keepalives:            77         77
    Route Refresh:          3          0
    Total:                 86         82
  Default minimum time between advertisement runs is 30 seconds
 For address family: IPv4 Unicast
  BGP table version 4, neighbor version 4/0
 Output queue size : 0
  Index 1, Offset 0, Mask 0x2
  1 update-group member
  Outgoing update network filter list is 15
  Default weight 1000
                                 Sent       Rcvd
  Prefix activity:               ----       ----
    Prefixes Current:               1          1 (Consumes 52 bytes)
    Prefixes Total:                 5          4
    Implicit Withdraw:              4          3
    Explicit Withdraw:              0          0
    Used as bestpath:             n/a          1
    Used as multipath:            n/a          0
                                   Outbound    Inbound
  Local Policy Denied Prefixes:    --------    -------
    Suppressed duplicate:                 0          3
    Bestpath from this peer:              4        n/a
    Total:                                4          3
  Number of NLRIs in the update sent: max 1, min 1
  Connections established 1; dropped 0
  Last reset never
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 1
Local host: 192.168.200.2, Local port: 179
Foreign host: 192.168.200.1, Foreign port: 24673
Enqueued packets for retransmit: 0, input: 0  mis-ordered: 0 (0 bytes)
Event Timers (current time is 0x46DE24):
Timer          Starts    Wakeups            Next
Retrans            87          4             0x0
TimeWait            0          0             0x0
AckHold            82         81             0x0
SendWnd             0          0             0x0
KeepAlive           0          0             0x0
GiveUp              0          0             0x0
PmtuAger            0          0             0x0
DeadWait            0          0             0x0
iss: 2971400288  snduna: 2971402126  sndnxt: 2971402126     sndwnd:  16024
irs: 3172325383  rcvnxt: 3172327100  rcvwnd:      16175  delrcvwnd:    209
SRTT: 361 ms, RTTO: 488 ms, RTV: 127 ms, KRTT: 0 ms
minRTT: 144 ms, maxRTT: 948 ms, ACK hold: 200 ms
Flags: passive open, nagle, gen tcbs
IP Precedence value : 6
Datagrams (max data segment is 1460 bytes):
Rcvd: 165 (out of order: 0), with data: 82, total data bytes: 1716
Sent: 170 (retransmit: 4, fastretransmit: 0, partialack: 0, Second
Congestion: 0), with data: 85, total data bytes: 1837





Router#show ip bgp neighbors 192.168.100.1

BGP neighbor is 192.168.100.1,  remote AS 100, external link
  BGP version 4, remote router ID 192.168.100.1
  BGP state = Established, up for 01:15:01
  Last read 00:00:01, last write 00:00:01, hold time is 180, keepalive
interval is 60 seconds
  Neighbor capabilities:
    Route refresh: advertised and received(old & new)
    Address family IPv4 Unicast: advertised and received
  Message statistics:
    InQ depth is 0
    OutQ depth is 0
                         Sent       Rcvd
    Opens:                  1          1
    Notifications:          0          0
    Updates:                6          0
    Keepalives:            77         77
    Route Refresh:          3          1
    Total:                 87         79
  Default minimum time between advertisement runs is 30 seconds
 For address family: IPv4 Unicast
  BGP table version 4, neighbor version 4/0
 Output queue size : 0
  Index 2, Offset 0, Mask 0x4
  2 update-group member
  Outgoing update network filter list is 15
  Condition-map NON-EXIST, Advertise-map ADVERTISE, status: Advertise
  Default weight 500
                                 Sent       Rcvd
  Prefix activity:               ----       ----
    Prefixes Current:               1          0
    Prefixes Total:                 6          0
    Implicit Withdraw:              5          0
    Explicit Withdraw:              0          0
    Used as bestpath:             n/a          0
    Used as multipath:            n/a          0
                                   Outbound    Inbound
  Local Policy Denied Prefixes:    --------    -------
    prefix-list                           5          0
    Total:                                5          0
  Number of NLRIs in the update sent: max 1, min 1
  Connections established 1; dropped 0
  Last reset never
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 1
Local host: 192.168.100.2, Local port: 179
Foreign host: 192.168.100.1, Foreign port: 59024
Enqueued packets for retransmit: 0, input: 0  mis-ordered: 0 (0 bytes)
Event Timers (current time is 0x470FD4):
Timer          Starts    Wakeups            Next
Retrans            85          1             0x0
TimeWait            0          0             0x0
AckHold            79          2             0x0
SendWnd             0          0             0x0
KeepAlive           0          0             0x0
GiveUp              0          0             0x0
PmtuAger            0          0             0x0
DeadWait            0          0             0x0
iss: 1267845407  snduna: 1267847297  sndnxt: 1267847297     sndwnd:  15967
irs:  973353198  rcvnxt:  973354730  rcvwnd:      16327  delrcvwnd:     57
SRTT: 377 ms, RTTO: 574 ms, RTV: 197 ms, KRTT: 0 ms
minRTT: 160 ms, maxRTT: 816 ms, ACK hold: 200 ms
Flags: passive open, nagle, gen tcbs
IP Precedence value : 6
Datagrams (max data segment is 1460 bytes):
Rcvd: 164 (out of order: 0), with data: 79, total data bytes: 1531
Sent: 91 (retransmit: 1, fastretransmit: 0, partialack: 0, Second
Congestion: 0), with data: 86, total data bytes: 1889









Router#show ip bgp neighbors 192.168.100.1 advertised-routes

BGP table version is 4, local router ID is 192.168.100.2
Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network          Next Hop            Metric LocPrf Weight Path
*> 10.1.1.0/24      0.0.0.0                  0         32768 i
Total number of prefixes 1





Router#show ip bgp neighbors 192.168.200.1 advertised-routes

BGP table version is 4, local router ID is 192.168.100.2
Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network          Next Hop            Metric LocPrf Weight Path
*> 10.1.1.0/24      0.0.0.0                  0         32768 i
Total number of prefixes 1








On Sun, Mar 15, 2009 at 11:39 PM, <RPhookun at lecg.com> wrote:

>
> One gotcha I ran into sometime ago -  on 12.4 T
>
> the  neighbor 192.168.100.1 advertise-map ADVERTISE non-exist-map
> NON-EXIST has to be configured in the address-family ipv4
>
> conf t
> router bgp 10
> address-family ipv4
> neighbor 192.168.100.1 advertise-map ADVERTISE non-exist-map NON-EXIST
> exit-address-family
>
> Not sure if this is your case.
>
> can you include the output of -
>
> sh ip bgp neigh x.x.x.x
> sh ip bgp neigh x.x.x.x advertised routes?
>
> Regards,
> ./Randy
>
>
>
>
>
>   *Burak Dikici <bdikici at gmail.com>*
> Sent by: cisco-nsp-bounces at puck.nether.net
>
> 03/15/2009 02:21 PM
>    To
> RPhookun at lecg.com  cc
> Ivan Pepelnjak <ip at ioshints.info>, cisco-nsp-bounces at puck.nether.net,
> cisco-nsp at puck.nether.net
>   Subject
> Re: [c-nsp] BGP conditional advertisemet - NON-EXIST route
>  map'saccess-list problem
>
>
>
>
>
>  I have made a change on the lab with the commands which are written below
> ,
> but ISP-2 still getting my announcment. No success...
>
>
> ip as-path access-list 1 permit ^200  (ISP-1 AS number)
>
> ip prefix-list AS200-track seq 5 permit 192.168.200.0/24 (subnet
> between multihoming router and ISP-1 router)
>
> route-map NON-EXIST permit 10
> match ip address prefix-list AS200-track
> match as-path 1
>
> router bgp 10
> neighbor 192.168.100.1 advertise-map ADVERTISE non-exist-map NON-EXIST
>
>
>
>
>
>
>
>
> On Sun, Mar 15, 2009 at 11:03 PM, <RPhookun at lecg.com> wrote:
>
> >
> > I agree with Ivan in that the tracked prefix  in the Non-Exist-Map should
> > be the ISP-1 infrastructure address because in its absence you wouldn't
> be
> > receiving any other routes from ISP-1
> > However, the match of the tracked prefix is from the BGP table *not* the
> IP
> > routing table and "match-as-path" can be very relevant in some topologies
> > and its absence in the Non-Exist-Map can cause the conditional
> advertisement
> > feature to break.
> >
> > Cisco has an excellent example - "Configuring and Verifying the
> Conditional
> > Advertisement Feature"
> >
> > ./Randy
> >
> >
> >
> >
> >
> >   *"Ivan Pepelnjak" <ip at ioshints.info>*
> > Sent by: cisco-nsp-bounces at puck.nether.net
> >
> > 03/15/2009 12:48 PM
> >    To
> >  "'Burak Dikici'" <bdikici at gmail.com>
> >  cc
> >   cisco-nsp at puck.nether.net  Subject
> > Re: [c-nsp] BGP conditional advertisemet - NON-EXIST route
> >  map'saccess-list problem
> >
> >
> >
> >
> >
> >  That's the problem everyone has with the NON-EXIST-MAP :) Usually the IP
> > prefix used to address the ISP-1 infrastructure is the best bet.
> >
> > The "match as-path" statement in the NON-EXIST-MAP is irrelevant (unless
> > I'm
> > totally wrong about the match being made with the routes in the IP
> routing
> > table :).
> >
> > Ivan
> >
> >
> >  _____
> >
> > From: Burak Dikici [mailto:bdikici at gmail.com]
> > Sent: Sunday, March 15, 2009 8:19 PM
> > To: Ivan Pepelnjak
> > Cc: Mateusz Blaszczyk; cisco-nsp at puck.nether.net
> > Subject: Re: [c-nsp] BGP conditional advertisemet - NON-EXIST route
> > map'saccess-list problem
> >
> >
> > Hi Ivan ,
> >
> > Ok than , what should i use for  NON-EXIST route-map's access-list ?
> Which
> > prefix should i trust from ISP-1 (Primary ISP) ?
> > Is it necessary to use  "match ip address" and "match as-path" statements
> > together in the  NON-EXIST route-map ?
> >
> >
> > On Sun, Mar 15, 2009 at 8:46 PM, Ivan Pepelnjak <ip at ioshints.info>
> wrote:
> >
> >
> > You can't use "permit any" because it would match any route in the IP
> > routing table (including the connected interfaces). The access list used
> in
> > NON-EXIST-MAP is used on the IP routing table, not on the BGP table
> (that's
> > why the AS path doesn't work either).
> >
> > Ivan
> >
> >
> > > -----Original Message-----
> > > From: Burak Dikici [mailto:bdikici at gmail.com]
> > > Sent: Sunday, March 15, 2009 7:16 PM
> > > To: Mateusz Blaszczyk
> > > Cc: cisco-nsp at puck.nether.net
> >
> > > Subject: Re: [c-nsp] BGP conditional advertisemet - NON-EXIST
> > > route map'saccess-list problem
> > >
> >
> > > Hi Mateusz ,
> > >
> > > For better understanding , i have attached the topology
> > > screenshot and the router's configuration files. (By the way
> > > , this is a lab config.)
> > >
> > > In the attached Router's configuration ,
> > >
> > > access-list 65 permit 172.16.1.0 0.0.0.255
> > >
> > > command is used and with this command bgp conditional
> > > advertisement is working fine.
> > >
> > > But when i use ,
> > >
> > > access-list 65 permit any
> > >
> > > command , the conditional advertisement doesn't work.
> >
> >
> >
> >
> > _______________________________________________
> > cisco-nsp mailing 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 dale.shaw+cisco-nsp at gmail.com  Sun Mar 15 18:32:41 2009
From: dale.shaw+cisco-nsp at gmail.com (Dale Shaw)
Date: Mon, 16 Mar 2009 09:32:41 +1100
Subject: [c-nsp] BGP conditional advertisemet - NON-EXIST route map's
	access-list problem
In-Reply-To: <d9281f5c0903150606m3fb9e1ddwfc75c6b7179b87af@mail.gmail.com>
References: <d9281f5c0903150606m3fb9e1ddwfc75c6b7179b87af@mail.gmail.com>
Message-ID: <3329cbb40903151532i1d09a108n3a48eaa6d00785ab@mail.gmail.com>

Hi Burak,

On Mon, Mar 16, 2009 at 12:06 AM, Burak Dikici <bdikici at gmail.com> wrote:
> i am trying to use
> BGP conditional advertisemet configuration. I have got a problem with
> NON-EXIST route map's access-list. In the NON-EXIST router map i am using
> the commands which is written below ;

Here are some notes I made recently when playing with BGP conditional
advertising. I hope it helps.

1.) prefixes matched in advertise-map and exist/non-exist map must exist
(or not) in the *BGP* table
 however: they do not need to be locally originated (e.g. R1 can
match routes received from R2 and advertise (or not) to R3
 and: the validity of the prefix in the BGP table (i.e. RIB-failure)
doesn't matter. if there's there, and using exist-map, the condition
is met.

2.) when using 'exist' map, prefixes matched by advertise-map are
advertised when exist-map condition is met
 example: advertise 1.0.0.0/8 (advertise-map) from BGP table when
3.20.20.0/24 (exist-map) exists in BGP table

3.) when exist 'non-exist' map, prefixes matched by advertise-map are
advertised when non-exist-map condition is met
 example: advertise 1.0.0.0/8 (advertise-map) from BGP table when
3.20.20.0/24 (non-exist-map) does NOT exist in BGP table

4.) prefixes matched in advertise-map are the only prefixes affected --
other prefixes that may exist are advertised (or not) as normal

5.) when dealing with conditional advertisement tasks, always consider
what will happen normally (without any config)

I'd be happy to be corrected, but I think the first point is contrary
to what Ivan said. Also consider point #4 -- BGP conditional
advertising is not strictly a route filtering mechanism, although it
can be configured to achieve similar results.

cheers,
Dale

From justin at justinshore.com  Sun Mar 15 20:03:33 2009
From: justin at justinshore.com (Justin Shore)
Date: Sun, 15 Mar 2009 19:03:33 -0500
Subject: [c-nsp] Opinions of DDoS appliances, other techniques,
 most notably Cisco Guard
In-Reply-To: <04670DB7-99B1-4F55-8DDD-9C036F93E4AF@cisco.com>
References: <F3318834F1F89D46857972DD4B411D700651DA6C@EXCHANGE.thenap.com>	<725C9117-BE48-468B-A39E-B69347853BAB@cisco.com>
	<04670DB7-99B1-4F55-8DDD-9C036F93E4AF@cisco.com>
Message-ID: <49BD9755.6060608@justinshore.com>

Roland Dobbins wrote:
> 
> On Mar 16, 2009, at 12:39 AM, Roland Dobbins wrote:
> 
>> Arbor Peakflow SP, Narus Insight Manager, and Lancope StealthWatch Xe 
>> are three commercial NetFlow-based anomaly-detection systems.
> 
> I forgot to add Q1 Labs Q1Radar, and I believe NetQoS now have an 
> anomaly-detection module, as well, though I've not seen it.

How about MARS?  I'm trying to get a pair of IDSM2s returned (they don't 
work right on 7600s) in exchange for a MARS 110R appliance.  That's 
roughly the same price.  I'm planning on using it for log analysis. 
Would its Netflow abilities be useful here?

Justin


From rdobbins at cisco.com  Sun Mar 15 20:16:26 2009
From: rdobbins at cisco.com (Roland Dobbins)
Date: Mon, 16 Mar 2009 08:16:26 +0800
Subject: [c-nsp] Opinions of DDoS appliances, other techniques,
	most notably Cisco Guard
In-Reply-To: <49BD9755.6060608@justinshore.com>
References: <F3318834F1F89D46857972DD4B411D700651DA6C@EXCHANGE.thenap.com>	<725C9117-BE48-468B-A39E-B69347853BAB@cisco.com>
	<04670DB7-99B1-4F55-8DDD-9C036F93E4AF@cisco.com>
	<49BD9755.6060608@justinshore.com>
Message-ID: <92230969-C847-4C99-9F37-2045C6AB9737@cisco.com>


On Mar 16, 2009, at 8:03 AM, Justin Shore wrote:

> Would its Netflow abilities be useful here?

As with any tool, it's a good idea to test and compare in order to  
ensure one's requirements are met.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at cisco.com> // +852.9133.2844 mobile

   Some things are just too precious to entrust to computers.

		   -- Seth Hanford


From craigp at tozz.net  Sun Mar 15 20:27:13 2009
From: craigp at tozz.net (Craig Pierantozzi)
Date: Sun, 15 Mar 2009 18:27:13 -0600
Subject: [c-nsp] BGP conditional advertisemet - NON-EXIST route map's
	access-list problem
In-Reply-To: <695044.82571.qm@web54004.mail.re2.yahoo.com>
References: <fsbujrb52s0kyzgvj9UYAxe124vaj_firegpg@mail.gmail.com>
	<695044.82571.qm@web54004.mail.re2.yahoo.com>
Message-ID: <4E7EF169-54E6-4820-8DB3-630F1FC511E3@tozz.net>


On Mar 15, 2009, at 12:46 PM, Yan Filyurin wrote:

> If you want ISP 2 to be used as a backup for ISP1 inboud traffic  
> could you just advertise your routes to ISP2 with, say bigger AS  
> path to the point where even ISP2 thinks it is best to go somewhere  
> else than directly to you?

Providers will often set localpref lower on peers so customer routes  
will win even with a longer AS Path.

But several have customer traffic engineering communities to utilize  
in order to set localpref to go lower than peers which will result in  
pushing traffic to ISP1 which is the goal. Best to make an inquiry to  
the upstream provider to find out if they have BGP communities that  
can help.

From wyatt.eliasson at gmail.com  Mon Mar 16 06:34:44 2009
From: wyatt.eliasson at gmail.com (Wyatt Mattias Gyllenvarg)
Date: Mon, 16 Mar 2009 11:34:44 +0100
Subject: [c-nsp] Right IOS for 7600
Message-ID: <994752fe0903160334g377af08eia2af6262fa428d4b@mail.gmail.com>

Hi All

Asking you real IOS gurus out there for the production options on IOS upgrades.

Where running 7600 Sup720PFC3BLX
OSPF
BGP
and wish too add
microFlow policing
Netflow
Currently on 12.2(18)SXF7

I understand that are several trains too choose from.

Best Regards
Mattias Gyllenvarg
Omnitron

From jared at puck.nether.net  Mon Mar 16 08:26:50 2009
From: jared at puck.nether.net (Jared Mauch)
Date: Mon, 16 Mar 2009 08:26:50 -0400
Subject: [c-nsp] Right IOS for 7600
In-Reply-To: <994752fe0903160334g377af08eia2af6262fa428d4b@mail.gmail.com>
References: <994752fe0903160334g377af08eia2af6262fa428d4b@mail.gmail.com>
Message-ID: <FE9A6BD1-714A-4D54-A2DB-93713067BDAC@puck.nether.net>


On Mar 16, 2009, at 6:34 AM, Wyatt Mattias Gyllenvarg wrote:

> Hi All
>
> Asking you real IOS gurus out there for the production options on  
> IOS upgrades.
>
> Where running 7600 Sup720PFC3BLX
> OSPF
> BGP
> and wish too add
> microFlow policing
> Netflow
> Currently on 12.2(18)SXF7
>
> I understand that are several trains too choose from.

	I would consider going to SXF16 for now.  It will provide you a large  
number of bugfixes.  If possible you should look at SXI but wait until  
SXI1.

	- Jared

From gkg at gmx.de  Mon Mar 16 06:07:53 2009
From: gkg at gmx.de (Garry)
Date: Mon, 16 Mar 2009 11:07:53 +0100
Subject: [c-nsp] Router failure - config lost?
Message-ID: <49BE24F9.4010903@gmx.de>

Hi *

I've got something of a question that's not necessarily a clear
technical problem or config problem ... rather just scoping as to
whether other people have come across this, too ...

We have a customer who has some 400+ locations. All of these are
connected to the central office via an MPLS-based network, using aDSL
lines. Every location has an identical 876-W-G-E-k9 router, with (apart
from DSL username and IP address) identical config. This network has now
been in operation for something like 18 months, and is working nicely.

Now, on average 1-2 locations per month go down, losing DSL
connectivity, and even a power-cycle and DSL port reset by the
DSL-provider won't work, at which point we configure a replacement
router and send it out. We usually get the defective router back for
analysis, and apart from a hand full of cases in which the routers where
physically damaged (lightning, spikes on the power supply etc.), most of
the defective routers have simply lost their configuration file. On one
occasion, the whole router flash was cleared, removing the IOS. On yet
another occasion, I think we found the stock config file (the one with
the large header, "cisco" login etc.) on the router (which I thought was
really weird).

In all those cases, we have opted to re-use the router, if for nothing
else than to see whether it was an actual hardware defect ... to date,
no router has shown that behavior twice (we track the ser#).

As for the configs/routers themselves, the locations do not have any
username/pw to log in to the routers. External access shouldn't be
possible, as the network itself has no direct Internet connectivity.

Has anybody else here ever experienced effects like this?

Tnx, -garry

From paul at paulstewart.org  Mon Mar 16 09:47:51 2009
From: paul at paulstewart.org (Paul Stewart)
Date: Mon, 16 Mar 2009 09:47:51 -0400
Subject: [c-nsp] BGP - peer down w/MD5 - suppress logging
Message-ID: <000401c9a63d$cd60f870$6822e950$@org>

Is there any way without messing with the level of logging we have turned on
today to suppress these messages in particular:

 

Mar 16 09:43:24: %TCP-6-BADAUTH: No MD5 digest from 206.223.143.84(179) to
206.223.143.81(13412) (RST) tableid - 0

Mar 16 09:43:32: %TCP-6-BADAUTH: No MD5 digest from 206.223.143.84(179) to
206.223.143.81(13412) (RST) tableid - 0

 

This is a BGP peer that is not coming online at the moment - we don't want
to shutdown our actual session.  Of course this only happens with MD5
enabled peers ;)

 

Thanks,

 

Paul

 

 


From gert at greenie.muc.de  Mon Mar 16 09:50:28 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Mon, 16 Mar 2009 14:50:28 +0100
Subject: [c-nsp] Right IOS for 7600
In-Reply-To: <994752fe0903160334g377af08eia2af6262fa428d4b@mail.gmail.com>
References: <994752fe0903160334g377af08eia2af6262fa428d4b@mail.gmail.com>
Message-ID: <20090316135028.GL290@greenie.muc.de>

Hi,

On Mon, Mar 16, 2009 at 11:34:44AM +0100, Wyatt Mattias Gyllenvarg wrote:
> Asking you real IOS gurus out there for the production options on IOS upgrades.
[..]
> I understand that are several trains too choose from.

About all options seem to have been discussed in great detail on this
list.  So what are your questions that are *not* answered in the list
archives?

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/20090316/fc1f78fa/attachment.bin>

From Marcus.Gerdon at versatel.de  Mon Mar 16 04:42:00 2009
From: Marcus.Gerdon at versatel.de (Marcus.Gerdon)
Date: Mon, 16 Mar 2009 09:42:00 +0100
Subject: [c-nsp] Sup720-3BXL Stable IOS
Message-ID: <227142482560EF458FF1F7E784E26AB84ADD62@FLBVEXCH01.versatel.local>

Hi Paul,

in case you don't need any fancy 7600 only or SR only features or hardware support you might want to go back to 12.2(18)SXF. We're running SXF10 quite some time now including new 7600 with BGP and IS-IS for v4 and v6 multi-topology w/o the slightest problems up to now.

But sooner or later we'll be hit by the AS32-capable update... we'll see if SXJ will run on 7600, else it will be (forced into SRE).


regards,

Marcus

> -----Urspr?ngliche Nachricht-----
> Von: cisco-nsp-bounces at puck.nether.net 
> [mailto:cisco-nsp-bounces at puck.nether.net] Im Auftrag von Paul Stewart
> Gesendet: Samstag, 14. M?rz 2009 14:52
> An: 'Cisco-nsp'
> Betreff: [c-nsp] Sup720-3BXL Stable IOS
> 
> Hi there.
> 
>  
> 
> We're seeing issues occasionally with BGP sessions on 
> Sup720-3BXL getting
> "stuck".  When adding a new session in particular it won't come up and
> sometimes after removing and adding back into the config it 
> works.. Other
> strange unexplained stuff once in a while..
> 
>  
> 
> Anyways, talked to a few peers and they tell me "wow, you're 
> on the bleeding
> edge" because we're running 12.2.33SRD and 12.2.33SRC releases.
> 
>  
> 
> I am thinking of moving to 12.2.33SRA7 release as it's listed 
> as LD vs ED
> and is very current still - am I playing with fire?  Any feedback?
> 
>  
> 
> Box is running IPv4/IPv6, OSPF and BGP
> 
>  
> 
> Many thanks,
> 
>  
> 
> Paul
> 
>  
> 
>  
> 
>  
> 
> 
> 
> This message was delivered by MDaemon - http://www.altn.com/MDaemon/
> _______________________________________________
> cisco-nsp mailing list  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  Mon Mar 16 11:15:01 2009
From: p.mayers at imperial.ac.uk (Phil Mayers)
Date: Mon, 16 Mar 2009 15:15:01 +0000
Subject: [c-nsp] SXI leaks (was: Netflow on SUP720-3BXL)
In-Reply-To: <20090315183250.GH290@greenie.muc.de>
References: <200903151718.22464.andy-lists@bourges.de>	<200903151904.27158.andy-lists@bourges.de>
	<20090315183250.GH290@greenie.muc.de>
Message-ID: <49BE6CF5.2020708@imperial.ac.uk>


> (SXI has "slow memory leaks" in BGP, at least for us.  Cisco case has been
> opened, but hasn't proceeded anywhere yet).

Interesting. Do you have any details you can share?


From dwinkworth at att.net  Mon Mar 16 11:18:42 2009
From: dwinkworth at att.net (Derick Winkworth)
Date: Mon, 16 Mar 2009 08:18:42 -0700 (PDT)
Subject: [c-nsp] Right IOS for 7600
References: <994752fe0903160334g377af08eia2af6262fa428d4b@mail.gmail.com>
	<20090316135028.GL290@greenie.muc.de>
Message-ID: <330952.33754.qm@web180013.mail.gq1.yahoo.com>

IOS changes.  The list archives are not relevant.  Cisco needs to somehow identify something like a "gold-standard" IOS...  Like functionally stabilize some code, and then have a train off of that that is only bug fixes until it is 99.999% bug free.

Until then, expect people to ask in fear constantly what IOS to choose... 




________________________________
From: Gert Doering <gert at greenie.muc.de>
To: Wyatt Mattias Gyllenvarg <wyatt.eliasson at gmail.com>
Cc: cisco-nsp at puck.nether.net
Sent: Monday, March 16, 2009 8:50:28 AM
Subject: Re: [c-nsp] Right IOS for 7600

Hi,

On Mon, Mar 16, 2009 at 11:34:44AM +0100, Wyatt Mattias Gyllenvarg wrote:
> Asking you real IOS gurus out there for the production options on IOS upgrades.
[..]
> I understand that are several trains too choose from.

About all options seem to have been discussed in great detail on this
list.  So what are your questions that are *not* answered in the list
archives?

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 omar.parihuana at gmail.com  Mon Mar 16 11:36:54 2009
From: omar.parihuana at gmail.com (omar parihuana)
Date: Mon, 16 Mar 2009 10:36:54 -0500
Subject: [c-nsp] DLSW on Catalyst 4506-E is it possible???
Message-ID: <834c50110903160836j2d192b39pb692ba309199f297@mail.gmail.com>

Hi Guys,

DLSW is supported in Catalyst 4500 platform???? I'm searching in Cisco Doc
but it seems that DLSW doesn't run over Cat4500. Are there some way to run
DLSW over CAT4500? (in 6500 a MSFC card will solve the problem).

Here my sh version

4500# sh version

Cisco IOS Software, Catalyst 4500 L3 Switch Software

(cat4500-ENTSERVICESK9-M),

Version 12.2(44)SG1, RELEASE SOFTWARE (fc1)

Technical Support: http://www.cisco.com/techsupport

Copyright (c) 1986-2008 by Cisco Systems, Inc.

Compiled Wed 09-Jul-08 13:17 by prod_rel_team

Image text-base: 0x10000000, data-base: 0x11D1CA4C



ROM: 12.2(31r)SGA1

Pod Revision 14, Force Revision 31, Tie Revision 32



4500 uptime is 2 days, 19 hours, 53 minutes

System returned to ROM by reload

System restarted at 14:17:22 Fri Mar 13 2009

System image file is "bootflash:cat4500-entservicesk9-mz.122-44.SG1.bin"





This product contains cryptographic features and is subject to United

States and local country laws governing import, export, transfer and

use. Delivery of Cisco cryptographic products does not imply

third-party authority to import, export, distribute or use encryption.

Importers, exporters, distributors and users are responsible for

compliance with U.S. and local country laws. By using this product you

agree to comply with applicable laws and regulations. If you are unable

to comply with U.S. and local laws, return this product immediately.



A summary of U.S. laws governing Cisco cryptographic products may be found

at:

http://www.cisco.com/wwl/export/crypto/tool/stqrg.html



If you require further assistance please contact us by sending email to

export at cisco.com.



cisco WS-C4506-E (MPC8540) processor (revision 13) with 524288K bytes of

memory.

Processor board ID FOX1242H2PR

MPC8540 CPU at 800Mhz, Supervisor V-10GE

Last reset from Reload

20 Virtual Ethernet interfaces

70 Gigabit Ethernet interfaces

2 Ten Gigabit Ethernet interfaces

511K bytes of non-volatile configuration memory.


Configuration register is 0x2101


Rgds.

-- 
Omar E.P.T
-----------------
Certified Networking Professionals make better Connections!

From gert at greenie.muc.de  Mon Mar 16 11:55:04 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Mon, 16 Mar 2009 16:55:04 +0100
Subject: [c-nsp] SXI leaks (was: Netflow on SUP720-3BXL)
In-Reply-To: <49BE6CF5.2020708@imperial.ac.uk>
References: <200903151718.22464.andy-lists@bourges.de>
	<200903151904.27158.andy-lists@bourges.de>
	<20090315183250.GH290@greenie.muc.de>
	<49BE6CF5.2020708@imperial.ac.uk>
Message-ID: <20090316155504.GN290@greenie.muc.de>

Hi,

On Mon, Mar 16, 2009 at 03:15:01PM +0000, Phil Mayers wrote:
> >(SXI has "slow memory leaks" in BGP, at least for us.  Cisco case has been
> >opened, but hasn't proceeded anywhere yet).
> 
> Interesting. Do you have any details you can share?

This is on a "peering point + upstream provider" router, with full
IPv4 and IPv6 BGP (unicast only).  SXI non-modular, "advanced ip services".

We lose about 2-4 Mbyte of free memory per day, which goes into "holding"
for the "BGP Router" process.

It seems to be related to churn - we have another router running SXI, and
that one is used at the network edge with only about 500 BGP prefixes,
and nearly no churn.  That one has no (noticeable) memory leak.

TAC Case# is SR 610821739.

(... maybe we should really go for SXI modular... - "just restart the
BGP Router every 2 months, and reclaim all this memory without a 
10-minute reboot... and maybe even get a bugfixed BGP-process without
requiring a reboot").

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/20090316/bf5a9188/attachment.bin>

From gert at greenie.muc.de  Mon Mar 16 11:58:18 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Mon, 16 Mar 2009 16:58:18 +0100
Subject: [c-nsp] Right IOS for 7600
In-Reply-To: <330952.33754.qm@web180013.mail.gq1.yahoo.com>
References: <994752fe0903160334g377af08eia2af6262fa428d4b@mail.gmail.com>
	<20090316135028.GL290@greenie.muc.de>
	<330952.33754.qm@web180013.mail.gq1.yahoo.com>
Message-ID: <20090316155818.GO290@greenie.muc.de>

Hi,

On Mon, Mar 16, 2009 at 08:18:42AM -0700, Derick Winkworth wrote:
> IOS changes.  The list archives are not relevant.  

In that case, the answer is "contact your Cisco account representative".

All knowledge available on this list is "experience from the past" - and
especially for the 6500/7600, the IOS discussion is repeated *more* often
than Cisco is releasing new images.  So the archives have all the answers.

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/20090316/b6c663e1/attachment.bin>

From mtinka at globaltransit.net  Mon Mar 16 11:59:32 2009
From: mtinka at globaltransit.net (Mark Tinka)
Date: Mon, 16 Mar 2009 23:59:32 +0800
Subject: [c-nsp] Sup720-3BXL Stable IOS
In-Reply-To: <227142482560EF458FF1F7E784E26AB84ADD62@FLBVEXCH01.versatel.local>
References: <227142482560EF458FF1F7E784E26AB84ADD62@FLBVEXCH01.versatel.local>
Message-ID: <200903162359.33335.mtinka@globaltransit.net>

On Monday 16 March 2009 04:42:00 pm Marcus.Gerdon wrote:

> But sooner or later we'll be hit by the AS32-capable
> update... we'll see if SXJ will run on 7600, else it will
> be (forced into SRE).

I posit quite a number of upgrades at the (peering) edge 
come end of this year, along with ensuing moans and groans 
as we make the networks ASN 32-bit capable.

Trying to figure out how to make this pretty, particularly 
given that this very feature may be what stands between you 
and your favorite, stable code base...

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/20090316/04022d5e/attachment.bin>

From William.Murphy at uth.tmc.edu  Mon Mar 16 12:09:48 2009
From: William.Murphy at uth.tmc.edu (Murphy, William)
Date: Mon, 16 Mar 2009 11:09:48 -0500
Subject: [c-nsp] SXI leaks (was: Netflow on SUP720-3BXL)
In-Reply-To: <20090316155504.GN290@greenie.muc.de>
References: <200903151718.22464.andy-lists@bourges.de>
	<200903151904.27158.andy-lists@bourges.de>
	<20090315183250.GH290@greenie.muc.de> <49BE6CF5.2020708@imperial.ac.uk>
	<20090316155504.GN290@greenie.muc.de>
Message-ID: <F2DF7BEF9FB81F4997B7AE7191A14F660207B66DCC@UTHCMS3.uthouston.edu>

Thanks for the heads up...  Are any of the maintenance releases of SXH also
affected by this memory leak? 

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Gert Doering
Sent: Monday, March 16, 2009 10:55 AM
To: Phil Mayers
Cc: Gert Doering; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] SXI leaks (was: Netflow on SUP720-3BXL)

Hi,

On Mon, Mar 16, 2009 at 03:15:01PM +0000, Phil Mayers wrote:
> >(SXI has "slow memory leaks" in BGP, at least for us.  Cisco case has 
> >been opened, but hasn't proceeded anywhere yet).
> 
> Interesting. Do you have any details you can share?

This is on a "peering point + upstream provider" router, with full
IPv4 and IPv6 BGP (unicast only).  SXI non-modular, "advanced ip services".

We lose about 2-4 Mbyte of free memory per day, which goes into "holding"
for the "BGP Router" process.

It seems to be related to churn - we have another router running SXI, and
that one is used at the network edge with only about 500 BGP prefixes, and
nearly no churn.  That one has no (noticeable) memory leak.

TAC Case# is SR 610821739.

(... maybe we should really go for SXI modular... - "just restart the BGP
Router every 2 months, and reclaim all this memory without a 10-minute
reboot... and maybe even get a bugfixed BGP-process without requiring a
reboot").

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: smime.p7s
Type: application/x-pkcs7-signature
Size: 4327 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090316/23e203cc/attachment.bin>

From gert at greenie.muc.de  Mon Mar 16 12:26:29 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Mon, 16 Mar 2009 17:26:29 +0100
Subject: [c-nsp] SXI leaks (was: Netflow on SUP720-3BXL)
In-Reply-To: <F2DF7BEF9FB81F4997B7AE7191A14F660207B66DCC@UTHCMS3.uthouston.edu>
References: <200903151718.22464.andy-lists@bourges.de>
	<200903151904.27158.andy-lists@bourges.de>
	<20090315183250.GH290@greenie.muc.de>
	<49BE6CF5.2020708@imperial.ac.uk>
	<20090316155504.GN290@greenie.muc.de>
	<F2DF7BEF9FB81F4997B7AE7191A14F660207B66DCC@UTHCMS3.uthouston.edu>
Message-ID: <20090316162629.GP290@greenie.muc.de>

Hi,

On Mon, Mar 16, 2009 at 11:09:48AM -0500, Murphy, William wrote:
> Thanks for the heads up...  Are any of the maintenance releases of SXH also
> affected by this memory leak? 

We've not seen this in SXH3a (and you don't want to use SXH3 due to
BGP ghost bugs).  I have not tested SXH4.

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/20090316/fd0c5b88/attachment.bin>

From p.mayers at imperial.ac.uk  Mon Mar 16 12:44:42 2009
From: p.mayers at imperial.ac.uk (Phil Mayers)
Date: Mon, 16 Mar 2009 16:44:42 +0000
Subject: [c-nsp] Fast IGP on 6500 & gigE
Message-ID: <49BE81FA.4000009@imperial.ac.uk>

All,

Given a mix of 6748-SFP, 6704 and 6716 linecards, with SXI software, and 
OSPF over SVIs, what are people successfully using to speed up link loss 
and subsequent IGP convergence?

Our config broadly looks like:

int Vlan38xx
   description p2p to another router
   ip address 192.168.0.2 255.255.255.254
   ip ospf network point-to-point

int Te1/1
   switchport
   switchport mode trunk
   switchport trunk native vlan 38xx

router ospf 1
   ispf
   nsf
   network 192.168.0.0 0.0.0.255

...and then the various LDP & BGP configs on top. I'm assuming I want 
some combination of:

  1. debounce / carrier-delay (what's the difference) on the gigE
  2. IP event dampening on the SVI
  3. faster timers on the SFP process; possibly as a conservative start:

timers throttle spf 10 100 5000
timers throttle lsa all 10 100 5000
timers lsa arrival 80

The idea is that most routers are dual-attached, so I just want to 
underlying IGP to converge quickly. I'll tackle the LDP and BGP later...

I'm not able to use BFD (since it doesn't work on SVIs under SXI) and 
I'm only worried about physical link-down - we don't have any weird 
layer2 between routers except in a few out-of-the way places, and they 
can just suffer.

I realise some of these answers are "it depends" on the size of your 
network; there are ~25 routers participating in the OSPF, all reasonably 
recent and modern, it's a single area 0 design, and it has ~58 p2p & 
loopbacks (via router LSAs) another 18 E2 routes.

It seems to take ~6msec for an OSPF adjacency to form between two 
routers, almost all of which is in INIT->2WAY so I'm guessing SPF is 
going to be pretty quick.

Suggestions welcome, although "ask Cisco to tell you" is less helpful; 
I'd like to have some independent understanding of how we arrived at the 
numbers, and be able to repeat the process in future ;o)

From Marcus.Gerdon at versatel.de  Mon Mar 16 13:41:52 2009
From: Marcus.Gerdon at versatel.de (Marcus.Gerdon)
Date: Mon, 16 Mar 2009 18:41:52 +0100
Subject: [c-nsp] Fast IGP on 6500 & gigE
Message-ID: <227142482560EF458FF1F7E784E26AB84E912E@FLBVEXCH01.versatel.local>

Hi,

you've written most routers are dual-attached, so the concern mostly is failure detection and not re-establishment of a neighbor I think. If you go into debounce or carrier-delay you'll raise the convergence time as a link failure will be ignored for a short time before processes are notified.

OSPF should immediately react on an link-down event, so I'd try to speed it up this way. If you use 2 separate SVI for the 2 connections and each VLAN has only 1 port it is allowed in (either a single access port or exactly 1 trunk port) the SVI should go down along with that single port.

Playing around the timers I keep for last resort - as there's always the risk to de-stabilize the network seriously (I've seen people trying to get the last second out of a protocol resulting in occasional burn-downs far too often).


regards,

Marcus
 

> -----Urspr?ngliche Nachricht-----
> Von: cisco-nsp-bounces at puck.nether.net 
> [mailto:cisco-nsp-bounces at puck.nether.net] Im Auftrag von Phil Mayers
> Gesendet: Montag, 16. M?rz 2009 17:45
> An: cisco-nsp at puck.nether.net
> Betreff: [c-nsp] Fast IGP on 6500 & gigE
> 
> All,
> 
> Given a mix of 6748-SFP, 6704 and 6716 linecards, with SXI 
> software, and 
> OSPF over SVIs, what are people successfully using to speed 
> up link loss 
> and subsequent IGP convergence?
> 
> Our config broadly looks like:
> 
> int Vlan38xx
>    description p2p to another router
>    ip address 192.168.0.2 255.255.255.254
>    ip ospf network point-to-point
> 
> int Te1/1
>    switchport
>    switchport mode trunk
>    switchport trunk native vlan 38xx
> 
> router ospf 1
>    ispf
>    nsf
>    network 192.168.0.0 0.0.0.255
> 
> ....and then the various LDP & BGP configs on top. I'm 
> assuming I want 
> some combination of:
> 
>   1. debounce / carrier-delay (what's the difference) on the gigE
>   2. IP event dampening on the SVI
>   3. faster timers on the SFP process; possibly as a 
> conservative start:
> 
> timers throttle spf 10 100 5000
> timers throttle lsa all 10 100 5000
> timers lsa arrival 80
> 
> The idea is that most routers are dual-attached, so I just want to 
> underlying IGP to converge quickly. I'll tackle the LDP and 
> BGP later...
> 
> I'm not able to use BFD (since it doesn't work on SVIs under SXI) and 
> I'm only worried about physical link-down - we don't have any weird 
> layer2 between routers except in a few out-of-the way places, 
> and they 
> can just suffer.
> 
> I realise some of these answers are "it depends" on the size of your 
> network; there are ~25 routers participating in the OSPF, all 
> reasonably 
> recent and modern, it's a single area 0 design, and it has ~58 p2p & 
> loopbacks (via router LSAs) another 18 E2 routes.
> 
> It seems to take ~6msec for an OSPF adjacency to form between two 
> routers, almost all of which is in INIT->2WAY so I'm guessing SPF is 
> going to be pretty quick.
> 
> Suggestions welcome, although "ask Cisco to tell you" is less 
> helpful; 
> I'd like to have some independent understanding of how we 
> arrived at the 
> numbers, and be able to repeat the process in future ;o)
> _______________________________________________
> cisco-nsp mailing list  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  Mon Mar 16 14:25:00 2009
From: p.mayers at imperial.ac.uk (Phil Mayers)
Date: Mon, 16 Mar 2009 18:25:00 +0000
Subject: [c-nsp] Fast IGP on 6500 & gigE
In-Reply-To: <227142482560EF458FF1F7E784E26AB84E912E@FLBVEXCH01.versatel.local>
References: <227142482560EF458FF1F7E784E26AB84E912E@FLBVEXCH01.versatel.local>
Message-ID: <49BE997C.9040002@imperial.ac.uk>

Marcus.Gerdon wrote:
> Hi,
> 
> you've written most routers are dual-attached, so the concern mostly
> is failure detection and not re-establishment of a neighbor I think.

Correct

> If you go into debounce or carrier-delay you'll raise the convergence
> time as a link failure will be ignored for a short time before
> processes are notified.

Further reading indicates that carrier/debounce are by default as low as 
you can safely get them on a 6500, so I think I can disregard these.

> 
> OSPF should immediately react on an link-down event, so I'd try to
> speed it up this way. If you use 2 separate SVI for the 2 connections

We're already doing this.

> and each VLAN has only 1 port it is allowed in (either a single
> access port or exactly 1 trunk port) the SVI should go down along
> with that single port.

It does.

Interestingly info I've read indicates that routed interfaces signal 
upper-layer protocols much faster than SVI interfaces, which is 
something I'll have to investigate.

> 
> Playing around the timers I keep for last resort - as there's always
> the risk to de-stabilize the network seriously (I've seen people
> trying to get the last second out of a protocol resulting in
> occasional burn-downs far too often).

Hmm.

Further digging has some pretty concrete recommendations from Cisco in 
presentations and such suggesting:

timers throttle spf 10 100 5000
timers throttle lsa all 10 100 5000
timers lsa arrival 80

e.g.

http://www.ciscoexpo.sk/slides/41-vsettey_fast_convergence.pdf

The default SPF initial delay is 5 *whopping* seconds; which means that, 
no matter how fast your link detection and SPF propagation is, it'll be 
at least 5 seconds before you even *start* trying to converge.

Having read the docs, I have a hard time seeing how changing these can 
"burn down" the network - the spf and lsa timers have exponential 
backoff. Would you care to elaborate on the failure modes you have seen?

From jimmy.changa007 at gmail.com  Mon Mar 16 15:40:30 2009
From: jimmy.changa007 at gmail.com (Jimmy Changa)
Date: Mon, 16 Mar 2009 15:40:30 -0400
Subject: [c-nsp] Sup720-3BXL and diag issues
Message-ID: <7cf54880903161240lb77d76l84b16ce7b3f9224d@mail.gmail.com>

I have a 6500 with a sup720-3BXL. Every time I put a WS-X6408A-GBIC card in
the chassis, diag fails the card.

I haven't rebooted the box yet, as this carrys a significant amount of
traffic, has anyone else seen this type of problem.

Diag on the most recent card shows:

7) TestUnusedPortLoopback:

      Port  1  2  3  4  5  6  7  8
      ----------------------------
            U  U  U  F  U  U  U  F

The cards work in other chassis.

From schilling2006 at gmail.com  Mon Mar 16 16:42:38 2009
From: schilling2006 at gmail.com (schilling)
Date: Mon, 16 Mar 2009 16:42:38 -0400
Subject: [c-nsp] SXI high cpu usage and rp inband SPAN feature not available
Message-ID: <bd3771a60903161342q41395223ncf68157e53824005@mail.gmail.com>

We installed SXI Advanced Enterprise in one of our catalyst 6500 with
sup720-3BXL, and the box is having persistent high CPU over 90%/80%
where we have normal cpu utilization around 30%.?? I played with RP
SPAN on our SXF11 before, it's good to see what is punted to CPU
according to the following Doc,

SPAN RP-Inband and SP-Inband
A SPAN for the RP or SP port in Cisco IOS Software is available in
Cisco IOS Software Release 12.1(19)E and later.
http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_note09186a00804916e0.shtml

But the feature is not in the current SXI even the configuration guide
has that feature documented.
http://cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/span.html#wp1089465

test(config)#monitor session 1 ?
  destination  SPAN destination interface or VLAN
  filter              SPAN filter VLAN
  source          SPAN source interface, VLAN

test(config)#monitor session 1 source ?
  interface                                   SPAN source interface
  intrusion-detection-module   SPAN source intrusion-detection-module
  remote                                      SPAN source Remote
  vlan                                           SPAN source VLAN

test#remote login switch
Trying Switch ...
Entering CONSOLE for Switch
Type "^C^C^C" to end this session

test-sp#monitor ?
  elog         Event-logging control commands
  event-trace  Control event tracing

test-sp#test monitor ?
  crash  test crash


Schilling

From ras at e-gerbil.net  Mon Mar 16 17:18:37 2009
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Mon, 16 Mar 2009 16:18:37 -0500
Subject: [c-nsp] SXI high cpu usage and rp inband SPAN feature not
	available
In-Reply-To: <bd3771a60903161342q41395223ncf68157e53824005@mail.gmail.com>
References: <bd3771a60903161342q41395223ncf68157e53824005@mail.gmail.com>
Message-ID: <20090316211837.GE51443@gerbil.cluepon.net>

On Mon, Mar 16, 2009 at 04:42:38PM -0400, schilling wrote:
> We installed SXI Advanced Enterprise in one of our catalyst 6500 with
> sup720-3BXL, and the box is having persistent high CPU over 90%/80%
> where we have normal cpu utilization around 30%.?? I played with RP

sh proc cpu sort 5s

Start by seeing if the cpu use in IP Input or not. I've been seeing SRC3 
boxes get into weird states where the run 80-90% in BGP router, until 
they're rebooted.

-- 
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 A.L.M.Buxey at lboro.ac.uk  Mon Mar 16 17:40:53 2009
From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk)
Date: Mon, 16 Mar 2009 21:40:53 +0000
Subject: [c-nsp] Sup720-3BXL and diag issues
In-Reply-To: <7cf54880903161240lb77d76l84b16ce7b3f9224d@mail.gmail.com>
References: <7cf54880903161240lb77d76l84b16ce7b3f9224d@mail.gmail.com>
Message-ID: <20090316214053.GA25906@lboro.ac.uk>

Hi,
> I have a 6500 with a sup720-3BXL. Every time I put a WS-X6408A-GBIC card in
> the chassis, diag fails the card.
> 
> The cards work in other chassis.

same slot, or different slot?  

alan

From p.mayers at imperial.ac.uk  Mon Mar 16 18:44:17 2009
From: p.mayers at imperial.ac.uk (Phil Mayers)
Date: Mon, 16 Mar 2009 22:44:17 +0000
Subject: [c-nsp] SXI high cpu usage and rp inband SPAN feature not
	available
In-Reply-To: <bd3771a60903161342q41395223ncf68157e53824005@mail.gmail.com>
References: <bd3771a60903161342q41395223ncf68157e53824005@mail.gmail.com>
Message-ID: <20090316224417.GB9886@wildfire.net.ic.ac.uk>

On Mon, Mar 16, 2009 at 08:42:38PM +0000, schilling wrote:
>We installed SXI Advanced Enterprise in one of our catalyst 6500 with
>sup720-3BXL, and the box is having persistent high CPU over 90%/80%
>where we have normal cpu utilization around 30%.?? I played with RP
>SPAN on our SXF11 before, it's good to see what is punted to CPU
>according to the following Doc,
>
>SPAN RP-Inband and SP-Inband
>A SPAN for the RP or SP port in Cisco IOS Software is available in
>Cisco IOS Software Release 12.1(19)E and later.
>http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_note09186a00804916e0.shtml
>
>But the feature is not in the current SXI even the configuration guide
>has that feature documented.
>http://cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/span.html#wp1089465
>
>test(config)#monitor session 1 ?
>  destination  SPAN destination interface or VLAN
>  filter              SPAN filter VLAN
>  source          SPAN source interface, VLAN
>
>test(config)#monitor session 1 source ?
>  interface                                   SPAN source interface
>  intrusion-detection-module   SPAN source intrusion-detection-module
>  remote                                      SPAN source Remote
>  vlan                                           SPAN source VLAN

On SXI you configure the sp/rp CPU span via the normal span CLI; no more 
crazy remote commands:

monitor session 2 type erspan-source
 source cpu rp


From p.mayers at imperial.ac.uk  Mon Mar 16 18:47:45 2009
From: p.mayers at imperial.ac.uk (Phil Mayers)
Date: Mon, 16 Mar 2009 22:47:45 +0000
Subject: [c-nsp] Sup720-3BXL and diag issues
In-Reply-To: <7cf54880903161240lb77d76l84b16ce7b3f9224d@mail.gmail.com>
References: <7cf54880903161240lb77d76l84b16ce7b3f9224d@mail.gmail.com>
Message-ID: <20090316224745.GC9886@wildfire.net.ic.ac.uk>

On Mon, Mar 16, 2009 at 07:40:30PM +0000, Jimmy Changa wrote:
>I have a 6500 with a sup720-3BXL. Every time I put a WS-X6408A-GBIC card in
>the chassis, diag fails the card.
>
>I haven't rebooted the box yet, as this carrys a significant amount of
>traffic, has anyone else seen this type of problem.
>
>Diag on the most recent card shows:
>
>7) TestUnusedPortLoopback:
>
>      Port  1  2  3  4  5  6  7  8
>      ----------------------------
>            U  U  U  F  U  U  U  F

Some of the diags are heavily dependent on IOS config, usually only the 
disruptive ones though. I don't have any 6408s but what does:

sh diagnostic content module X

....say when the card is inserted? It should list some details about 
test #7 i.e. whether it's a bootup/health test, which I'd expect to pass 
in all circumstances.

A few weeks ago, I'd have said you may have a bad slot, but recently we 
had a slot "go funny" and no amount of fiddling would clear it *except* 
a reload of the box, so it's definitely worth trying.

>
>The cards work in other chassis.

Have you tried other cards in that slot?

From justin at justinshore.com  Mon Mar 16 22:46:05 2009
From: justin at justinshore.com (Justin Shore)
Date: Mon, 16 Mar 2009 21:46:05 -0500
Subject: [c-nsp] Sub-int based EoMPLS on a 6700 series LC in a 7600
Message-ID: <49BF0EED.3030903@justinshore.com>

I have a TAC case open right now regarding a new EoMPLS VC I'm trying to 
turn up.  This is the first I tried to terminate in a sub-int on one of 
my 7600s.  The LC is a 6748 w/ DFC.  The sup is a 720-3BXL running SRB1. 
  The other end is a ME3750 running 12.2(50)SE.  The ME's end is a 1Q 
trunk facing the CE.  The native VLAN is for Internet back to a SVI. 
The other VLAN allowed on the trunk (tagged) has a corresponding SVI 
with the xconnect to the loopback on that particular 7613.  The 7613 has 
a 1Q trunk facing the CE as well.  The port is configured with a sub-int 
though and the xconnect sits in the sub-int with 1Q encapsulation 
(tagged).  The VLAN IDs are the same on both ends.  MTU is the same on 
both ends and is the default 1500; I'm thinking that I need to raise 
this for one thing, to support the 1Q trunk over EoMPLS.  Or does MPLS 
auto-adjust for the higher MTU?

The VC is up end to end.  I can do a MPLS ping from end to end.  When I 
try to ping from the CE on the ME3750's end 2811 (with Fa0/0 configured 
with sub-ints and a 1Q config matching the ME) I get nothing back and no 
ARP entry on the 3560E.  I do however see counters on the VC increment 
end to end.  When I try to ping from the CE on the 7613's end (a 3560E 
with a trunk configured for the 1 EoMPLS VLAN and its L3 interface in a 
SVI) to the 2811 I get nothing back but the 2811 gets a matching ARP 
entry for the 3560E.  The counters on the VC do not increment either 
like they should (ping with a timeout of 0 repeating 10k times).  That's 
the exact opposite of what I would expect.

One question that was raised is if the core-facing interface had to be 
fancy WAN interfaces.  My understanding is that they do not because I 
don't have to double-tag anything.  The core-facing interface is on the 
same 6748.  For grins I moved the CE-facing interface to a 6724 w/ DFC 
in the same chassis.  No change.  The VC is up but I only get an ARP on 
the 2811 and nothing back.  From the perspective of the CEs traffic only 
flows from the 3560E to the 2811.  From the perspective of the VC's 
counters it's just the opposite.

The 7613 connects to a ME6524 (MTU 9000 on a L3 sub-int on both ends) 
and that ME6524 connect to the ME3750 (also a L3 interface with a MTU of 
9000).  MPLS is enabled end to end.  I get the targeted LDP on both ends 
of course.  IS-IS L2 is my IGP.

Do I have to have WAN ints for the core-facing links?  I'm thinking no 
but I can't say for certain.  Neither could my TAC engineer but they are 
double checking.  Anyone know?

Thanks
  Justin

From gert at greenie.muc.de  Tue Mar 17 02:59:50 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Tue, 17 Mar 2009 07:59:50 +0100
Subject: [c-nsp] Netflow on SUP720-3BXL
In-Reply-To: <49BECC6E.4020701@wbsconnect.com>
References: <200903151718.22464.andy-lists@bourges.de>
	<200903151904.27158.andy-lists@bourges.de>
	<20090315183250.GH290@greenie.muc.de>
	<49BECC6E.4020701@wbsconnect.com>
Message-ID: <20090317065950.GR290@greenie.muc.de>

Hi,

On Mon, Mar 16, 2009 at 03:02:22PM -0700, Chris Phillips wrote:
> Have you gotten to the point where the memory leaks have caused you 
> problems in SXI?

Not yet.  This is on a 3C-XL, so we still have some 300 MB left.

... which means that we'll have to reboot in about 2-3 months.

> We ran into some odd behaviour this morning, and I wanted to see if it 
> was consistent with what you are/were seeing:
> 
> A show run returns nothing:
> 
> bmf1.nyc1#sh run
> bmf1.nyc1#
> 
> Checking the logs, at the same time the "sh run" was performed, this was 
> logged:
> 
> 1515054: Mar 16 16:46:21.842 UTC: %SYS-2-MALLOCFAIL: Memory allocation 
> of 982012 bytes failed from 0x40A34B28, alignment 0
> Pool: Processor  Free: 4030284  Cause: Memory fragmentation
> Alternate Pool: None  Free: 0  Cause: No Alternate pool

We haven't seen any memory-related errors yet.  Just that the free memory
pool is going down every day...

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 gert at greenie.muc.de  Tue Mar 17 03:21:33 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Tue, 17 Mar 2009 08:21:33 +0100
Subject: [c-nsp] Sub-int based EoMPLS on a 6700 series LC in a 7600
In-Reply-To: <49BF0EED.3030903@justinshore.com>
References: <49BF0EED.3030903@justinshore.com>
Message-ID: <20090317072133.GS290@greenie.muc.de>

Hi,

On Mon, Mar 16, 2009 at 09:46:05PM -0500, Justin Shore wrote:
> both ends and is the default 1500; I'm thinking that I need to raise 
> this for one thing, to support the 1Q trunk over EoMPLS.  Or does MPLS 
> auto-adjust for the higher MTU?

For basic subif-based EoMPLS, the MTU will still be 1500 (the Q will be 
stripped off and re-added - so there's no need to use the same VLAN tag
on both ends either).  The "standard" ethernet header will automagically 
be taken into account.

If you do interface based EoMPLS and want to transport VLAN-tagged frames,
you need to increase the MTU to 1504.

[..]
> One question that was raised is if the core-facing interface had to be 
> fancy WAN interfaces.  
[..]
> Do I have to have WAN ints for the core-facing links?  

Not on the 7613.  Dunno about the ME boxes.

(We do EoMPLS over 6408A-GBIC, 6724-SFP and 6704-10GE cards, never had any 
problem with it)

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/20090317/9b1e7b2f/attachment-0001.bin>

From asturluismi at gmail.com  Tue Mar 17 06:33:47 2009
From: asturluismi at gmail.com (luismi)
Date: Tue, 17 Mar 2009 11:33:47 +0100
Subject: [c-nsp] Recommendation? USB to serial adapter working without
	problems	under linux
Message-ID: <1237286027.10040.1.camel@dsba-ipso>

Hi all,

Any recommendation about a usb to serial adapter?
We work with linux here in our laptops and some of the adapters we used
in the past got stuck when they receive too much info very quickly (for
example, messages from console) so I would like to know if you have some
idea about any model or manufacter that works without problems.


From A.L.M.Buxey at lboro.ac.uk  Tue Mar 17 06:42:03 2009
From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk)
Date: Tue, 17 Mar 2009 10:42:03 +0000
Subject: [c-nsp] Recommendation? USB to serial adapter working
	without	problems under linux
In-Reply-To: <1237286027.10040.1.camel@dsba-ipso>
References: <1237286027.10040.1.camel@dsba-ipso>
Message-ID: <20090317104203.GB28497@lboro.ac.uk>

Hi,

> Any recommendation about a usb to serial adapter?
> We work with linux here in our laptops and some of the adapters we used
> in the past got stuck when they receive too much info very quickly (for
> example, messages from console) so I would like to know if you have some
> idea about any model or manufacter that works without problems.

well, i cannot guarantee perfection or that you might not face issues -
so therefore this isnt some form of binding contractual recommendation
but I havent had any problems with the keyspan single and quad port adapters
(eg USA-19HS)

though I did find a bug in the linux kernel in 2.6.x which after much
trawling and author emails turns out that the quad port device has some
identity issues - fixed with recent kernels.  

alan

From lists at carlsson.st  Tue Mar 17 07:09:53 2009
From: lists at carlsson.st (Lists@carlsson.st)
Date: Tue, 17 Mar 2009 12:09:53 +0100
Subject: [c-nsp] Recommendation? USB to serial adapter working without
	problems under linux
In-Reply-To: <1237286027.10040.1.camel@dsba-ipso>
References: <1237286027.10040.1.camel@dsba-ipso>
Message-ID: <00d501c9a6f0$e608d470$b21a7d50$@st>

Hi

I have used Aten UC232A with good result.
http://www.aten.com/products/productItem.php?pcid=2005010513171002&psid=2007
0130144911002&pid=2005022316346005&layerid=subClass7

Works with Win/*nix/osx etc

Br
Erik

> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> bounces at puck.nether.net] On Behalf Of luismi
> Sent: den 17 mars 2009 11:34
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] Recommendation? USB to serial adapter working without
> problems under linux
> 
> Hi all,
> 
> Any recommendation about a usb to serial adapter?
> We work with linux here in our laptops and some of the adapters we used
> in the past got stuck when they receive too much info very quickly (for
> example, messages from console) so I would like to know if you have
> some
> idea about any model or manufacter that works without problems.
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


From george at three6five.com  Tue Mar 17 07:27:52 2009
From: george at three6five.com (George Stylianou)
Date: Tue, 17 Mar 2009 13:27:52 +0200
Subject: [c-nsp] Cisco 3750G-24PS Issues with POE
Message-ID: <99bc91e0903170427r6557b26ax11ed9a60e2aa9f01@mail.gmail.com>

hi,

I have 2 of these which are both on 12.2(35)SE5.

We are connecting Avaya handsets to the ports and the switches are not
pushing power to the phones. Have tried multiple phones and ports on
both switches but the phones just dont power on.

have looked at all POE related config and everything seems fine.

Has anyone else experienced similar issues?

-- 
George Stylianou
three6five network solutions
email: george at three6five.com
mobile: +27 (82) 903 5616
fax: +27 866 552 285

From nasir.shaikh at bt.com  Tue Mar 17 09:12:30 2009
From: nasir.shaikh at bt.com (nasir.shaikh at bt.com)
Date: Tue, 17 Mar 2009 13:12:30 -0000
Subject: [c-nsp] Interesting NAToverload  issue
In-Reply-To: <6E31172B4025564D861CD73627500BAC02E2FC2E@pru-mail02.pe.net>
Message-ID: <2B0ABDF9E4A1204AA7467F200753545608FF3DE1@E03MVZ4-UKDY.domain1.systemhost.net>

Hi Andrew,

Our client is using this option (in fact this service is being managed
bu MSOL themselves). Only port 443 is allowed on the firewalls and in
fact my NAT selection is based on traffic with destination ip of MS
Exchange server and port 443.
But it seems that the Outlook client will open a minimum of 12 TCP
connections with the Exchange server. These connections increase as the
client adds more mailboxes (group or functional mailboxes) or other
services (OCS etc) At an average we see 17 tcp session per outlook
client.

Kind regards


Nasir Shaikh 
This email contains information from BT Nederland N.V., which may be
privileged or confidential. 
It's meant only for the individual(s) or entity named above. If you are
not the intended recipient, note that disclosing, copying, distributing
or using this information is prohibited.  
If you have received this email in error, please let me know immediately
on the email address above.
We monitor our systems, and may record your emails.

BT Nederland N.V. 
Registered office:  Offices Minerva and Mercurius, Herikerbergweg 2,
1101 CM Amsterdam
Registered at the Amsterdam Chamber of Commerce no:  33296214



-----Original Message-----
From: Tolstykh, Andrew [mailto:ATolstykh at integrysgroup.com] 
Sent: 27 February 2009 07:24
To: John Kougoulos; Shaikh,NM,Nasir,JRS1 R
Cc: cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] Interesting NAToverload issue

Long term your client should consider migrating to the "RPC over HTTPS"
connectivity model (single HTTPS connection per client).

http://technet.microsoft.com/en-us/library/bb123741.aspx


////---////

Exchange Server 2003 enabled users to use the Windows RPC over HTTP
Proxy component to access their Exchange information from the Internet.
This technology wraps remote procedure calls (RPCs) with an HTTP layer.
This allows the traffic to traverse network firewalls without requiring
RPC ports to be opened.

You do not have to use a virtual private network (VPN) to access
Exchange servers across the Internet.

You must allow only port 443 through your firewall, because Outlook
requests use HTTP over SSL. If you already use Outlook Web Access with
SSL or Exchange ActiveSync with SSL, you do not have to open any
additional ports from the Internet.


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of John Kougoulos
Sent: Wednesday, February 25, 2009 5:49 AM
To: nasir.shaikh at bt.com
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Interesting NAToverload issue

Hello,

you could split the usage of nat pools based on statistics of the source

IP addresses eg use 1 ip/overloaded nat pool for even source IPs and
another IP for the odd source IPs

Best Regards,
John

On Wed, 25 Feb 2009, nasir.shaikh at bt.com wrote:

> Hi,
>
> I have a client who has moved their Microsoft Exchange servers to a 
> service provider location (as part of a de-perimeterization strategy).

> These servers are reachable via the Internet. Thus, the client IP are 
> NATted before they cross the corporate boundary. There are about 45000

> users. Each user needs about 17-22 sessions (that's how MS Outlook
> works) and thus as many NAT entries Therefore a NAT pool is used with 
> overload. It was working fine for more than a year now but suddenly
the 
> following phenomenon has been noticed. - When a user session is being 
> built up and he has let's say 10 NAT entries using the first IP in the

> NAT pool and the port numbers run out, the next IP in the NAT pool is 
> used to complete the required number of sessions. - Exchange server is

> apparently not happy with one client using 2 IP addresses and keeps 
> (re-)building sessions untill all of them are using the same NATted
IP. 
> This can sometimes take upto 5 miniutes.
>
> Is there a solution to this problem? There is one single destination 
> global address. Is there a way to force the usage of the same IP from 
> the NAT pool for all NAT requests from a particular source IP?
Platform 
> is7206-vxr with NPE-G2
>
> Thanks in advance
>
>
> Nasir Shaikh
> This email contains information from BT Nederland N.V., which may be
privileged or confidential.
> It's meant only for the individual(s) or entity named above. If you
are not the intended recipient, note that disclosing, copying,
distributing or using this information is prohibited.
> If you have received this email in error, please let me know
immediately on the email address above.
> We monitor our systems, and may record your emails.
>
> BT Nederland N.V.
> Registered office:  Offices Minerva and Mercurius, Herikerbergweg 2,
1101 CM Amsterdam
> Registered at the Amsterdam Chamber of Commerce no:  33296214
>
>
>
> _______________________________________________
> cisco-nsp mailing 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/

 
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited.  If you
received this in error, please contact the sender and delete the
material from any computer.


From alexmoya at bellsouth.net  Tue Mar 17 09:16:31 2009
From: alexmoya at bellsouth.net (Alex Moya)
Date: Tue, 17 Mar 2009 09:16:31 -0400
Subject: [c-nsp] Recommendation? USB to serial adapter working
	without	problems under linux
In-Reply-To: <20090317104203.GB28497@lboro.ac.uk>
References: <1237286027.10040.1.camel@dsba-ipso>
	<20090317104203.GB28497@lboro.ac.uk>
Message-ID: <8066E94B-4F8E-4C66-ABAA-9D1FEEB584DB@bellsouth.net>

Any recommendation for mac's

Sent from my iPhone

On Mar 17, 2009, at 6:42 AM, A.L.M.Buxey at lboro.ac.uk wrote:

> Hi,
>
>> Any recommendation about a usb to serial adapter?
>> We work with linux here in our laptops and some of the adapters we  
>> used
>> in the past got stuck when they receive too much info very quickly  
>> (for
>> example, messages from console) so I would like to know if you have  
>> some
>> idea about any model or manufacter that works without problems.
>
> well, i cannot guarantee perfection or that you might not face  
> issues -
> so therefore this isnt some form of binding contractual recommendation
> but I havent had any problems with the keyspan single and quad port  
> adapters
> (eg USA-19HS)
>
> though I did find a bug in the linux kernel in 2.6.x which after much
> trawling and author emails turns out that the quad port device has  
> some
> identity issues - fixed with recent kernels.
>
> 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 alex.wilkinson at dsto.defence.gov.au  Tue Mar 17 08:20:32 2009
From: alex.wilkinson at dsto.defence.gov.au (Wilkinson, Alex)
Date: Tue, 17 Mar 2009 21:20:32 +0900
Subject: [c-nsp] Recommendation? USB to serial adapter working without
 problems under linux
In-Reply-To: <8066E94B-4F8E-4C66-ABAA-9D1FEEB584DB@bellsouth.net>
References: <1237286027.10040.1.camel@dsba-ipso> 
	<20090317104203.GB28497@lboro.ac.uk> 
	<8066E94B-4F8E-4C66-ABAA-9D1FEEB584DB@bellsouth.net>
Message-ID: <20090317122032.GB7652@stlux503.dsto.defence.gov.au>


    0n Tue, Mar 17, 2009 at 09:16:31AM -0400, Alex Moya wrote: 

    >Any recommendation for mac's

Yes. Keyspan USA-19HS.

 -aW

IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914.  If you have received this email in error, you are requested to contact the sender and delete the email.



From schilling2006 at gmail.com  Tue Mar 17 09:35:58 2009
From: schilling2006 at gmail.com (schilling)
Date: Tue, 17 Mar 2009 09:35:58 -0400
Subject: [c-nsp] SXI high cpu usage and rp inband SPAN feature not
	available
In-Reply-To: <bd3771a60903161342q41395223ncf68157e53824005@mail.gmail.com>
References: <bd3771a60903161342q41395223ncf68157e53824005@mail.gmail.com>
Message-ID: <bd3771a60903170635t3139d6c5mecdfca472991a0b6@mail.gmail.com>

My bad. The RP SPAN is available on SXI.

It turns out that the existing monitor session will not have type option
available.  I configured to have a monitor session 1 destination interface
first as it is for SXF before trying the monitor session 1 ?

Schilling

On Mon, Mar 16, 2009 at 4:42 PM, schilling <schilling2006 at gmail.com> wrote:

> We installed SXI Advanced Enterprise in one of our catalyst 6500 with
> sup720-3BXL, and the box is having persistent high CPU over 90%/80%
> where we have normal cpu utilization around 30%.   I played with RP
> SPAN on our SXF11 before, it's good to see what is punted to CPU
> according to the following Doc,
>
> SPAN RP-Inband and SP-Inband
> A SPAN for the RP or SP port in Cisco IOS Software is available in
> Cisco IOS Software Release 12.1(19)E and later.
>
> http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_note09186a00804916e0.shtml
>
> But the feature is not in the current SXI even the configuration guide
> has that feature documented.
>
> http://cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/span.html#wp1089465
>
> test(config)#monitor session 1 ?
>  destination  SPAN destination interface or VLAN
>  filter              SPAN filter VLAN
>  source          SPAN source interface, VLAN
>
> test(config)#monitor session 1 source ?
>  interface                                   SPAN source interface
>  intrusion-detection-module   SPAN source intrusion-detection-module
>  remote                                      SPAN source Remote
>  vlan                                           SPAN source VLAN
>
> test#remote login switch
> Trying Switch ...
> Entering CONSOLE for Switch
> Type "^C^C^C" to end this session
>
> test-sp#monitor ?
>  elog         Event-logging control commands
>  event-trace  Control event tracing
>
> test-sp#test monitor ?
>  crash  test crash
>
>
> Schilling
>

From christian at broknrobot.com  Tue Mar 17 09:41:44 2009
From: christian at broknrobot.com (Christian Koch)
Date: Tue, 17 Mar 2009 06:41:44 -0700
Subject: [c-nsp] Recommendation? USB to serial adapter working without
	problems under linux
In-Reply-To: <20090317122032.GB7652@stlux503.dsto.defence.gov.au>
References: <1237286027.10040.1.camel@dsba-ipso>
	<20090317104203.GB28497@lboro.ac.uk>
	<8066E94B-4F8E-4C66-ABAA-9D1FEEB584DB@bellsouth.net>
	<20090317122032.GB7652@stlux503.dsto.defence.gov.au>
Message-ID: <c93a55220903170641m24260cf4m839681cb6af6074b@mail.gmail.com>

agreed, the keyspan works great with macs and under linux.. i've used
a targus one as well, which worked fine, but the hardware was flimsy



On Tue, Mar 17, 2009 at 5:20 AM, Wilkinson, Alex
<alex.wilkinson at dsto.defence.gov.au> wrote:
>
> ? ?0n Tue, Mar 17, 2009 at 09:16:31AM -0400, Alex Moya wrote:
>
> ? ?>Any recommendation for mac's
>
> Yes. Keyspan USA-19HS.
>
> ?-aW
>
> IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. ?If you have received this email in error, you are requested to contact the sender and delete the email.
>
>
> _______________________________________________
> cisco-nsp mailing list ?cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From justin at justinshore.com  Tue Mar 17 09:53:14 2009
From: justin at justinshore.com (Justin Shore)
Date: Tue, 17 Mar 2009 08:53:14 -0500
Subject: [c-nsp] Sub-int based EoMPLS on a 6700 series LC in a 7600
In-Reply-To: <20090317072133.GS290@greenie.muc.de>
References: <49BF0EED.3030903@justinshore.com>
	<20090317072133.GS290@greenie.muc.de>
Message-ID: <49BFAB4A.9040703@justinshore.com>

Gert Doering wrote:
> Hi,
> 
> On Mon, Mar 16, 2009 at 09:46:05PM -0500, Justin Shore wrote:
>> both ends and is the default 1500; I'm thinking that I need to raise 
>> this for one thing, to support the 1Q trunk over EoMPLS.  Or does MPLS 
>> auto-adjust for the higher MTU?
> 
> For basic subif-based EoMPLS, the MTU will still be 1500 (the Q will be 
> stripped off and re-added - so there's no need to use the same VLAN tag
> on both ends either).  The "standard" ethernet header will automagically 
> be taken into account.
> 
> If you do interface based EoMPLS and want to transport VLAN-tagged frames,
> you need to increase the MTU to 1504.

So if I'm touching the CEs with trunks on both ends and a tagged VLAN on 
each end is being used, is the Q tag being stripped as it goes across or 
is it being carried?  Even if it's being carried and the MTU is too low 
to carry the tag on large frames I should still get small frames through 
shouldn't I?  I could always switch the trunks around to put the 
xconnect on the native VLAN on each side.  That's easily done if that 
would help.

> Not on the 7613.  Dunno about the ME boxes.

On the ME3750 I'm using the dedicated GigE uplinks for the core-facing 
ints.  I believe those 2 ports are the only ones that you can enable 
MPLS on for that odd platform.  So that should be ok.

> (We do EoMPLS over 6408A-GBIC, 6724-SFP and 6704-10GE cards, never had any 
> problem with it)

That's good to hear.  So to be clear you're using 6700 series cards both 
for the core-facing interfaces and for the CE-facing interfaces (using 
sub-ints or full ports), correct?

I was pretty sure that this should work.  My TAC engineer got back to me 
last night and is saying that won't work which I don't think is correct. 
  Specifically they said:

"On the 7600, a PFC/DFC or ingress line card (SIP-400/ES20) that does 
EoMPLS Label imposition/deposition is needed as a MPLS uplink port."

Well my 6700 LCs all have DFCs; I wouldn't buy them any other way.  The 
engineer goes on to imply that the VC type on either end is the problem. 
  Well the VC type is the same on both ends and is working because the 
VC is up; a mismatch would keep it down (been there done that).  The 
engineer then gave a description of port-to-port, vlan-to-vlan and 
port-to-vlan modes, their VCs and how the operate on the 7600.  This 
should be a VC type 5 port-to-vlan VC I believe (sub-int to SVI). 
That's what both sides agree on when the VC comes up.

I'm going to call my engineer back and press them on their answer 
because it doesn't seem to be correct.  This should be working.  The VC 
wouldn't be up if the VC type was the problem.

Thanks for the info
  Justin


From steti at monmouth.com  Tue Mar 17 09:27:35 2009
From: steti at monmouth.com (Steve Teti)
Date: Tue, 17 Mar 2009 09:27:35 -0400
Subject: [c-nsp] Recommendation? USB to serial adapter working without
 problems	under linux
In-Reply-To: <1237286027.10040.1.camel@dsba-ipso>
References: <1237286027.10040.1.camel@dsba-ipso>
Message-ID: <49BFA547.7090801@monmouth.com>

luismi wrote:
> Any recommendation about a usb to serial adapter?
> We work with linux here in our laptops

I've been using the Tripp-Lite U209-000-R for a couple of years now
without a problem.

http://www.tripplite.com/en/products/model.cfm?txtModelID=2430

Works out of the box on CentOS 5.2.  I think it requires a driver
download on Windows XP.  I'm not lucky enough to use a Mac at my day
job, so I can't say anything about its compatibility there :).

Steve

From gert at greenie.muc.de  Tue Mar 17 10:10:17 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Tue, 17 Mar 2009 15:10:17 +0100
Subject: [c-nsp] Sub-int based EoMPLS on a 6700 series LC in a 7600
In-Reply-To: <49BFAB4A.9040703@justinshore.com>
References: <49BF0EED.3030903@justinshore.com>
	<20090317072133.GS290@greenie.muc.de>
	<49BFAB4A.9040703@justinshore.com>
Message-ID: <20090317141016.GY290@greenie.muc.de>

Hi,

On Tue, Mar 17, 2009 at 08:53:14AM -0500, Justin Shore wrote:
> So if I'm touching the CEs with trunks on both ends and a tagged VLAN on 
> each end is being used, is the Q tag being stripped as it goes across or 
> is it being carried?  

As far as I understand, it's stripped.  (You can have "vlan 52" on the
left and "vlan 300" on the right side... PVSTP will be unhappy, but that's
an independent issue).

> Even if it's being carried and the MTU is too low 
> to carry the tag on large frames I should still get small frames through 
> shouldn't I?  

Yes.  ("Been there, done that, when I did port-mode and tried to get
dot1q tagged packets across").

> I could always switch the trunks around to put the 
> xconnect on the native VLAN on each side.  That's easily done if that 
> would help.

I don't think it would help - more likely, use of native VLAN will
confuse things even *more*

> >Not on the 7613.  Dunno about the ME boxes.
> 
> On the ME3750 I'm using the dedicated GigE uplinks for the core-facing 
> ints.  I believe those 2 ports are the only ones that you can enable 
> MPLS on for that odd platform.  So that should be ok.
> 
> >(We do EoMPLS over 6408A-GBIC, 6724-SFP and 6704-10GE cards, never had any 
> >problem with it)
> 
> That's good to hear.  So to be clear you're using 6700 series cards both 
> for the core-facing interfaces and for the CE-facing interfaces (using 
> sub-ints or full ports), correct?

Yes.  Some of the 6700 cards have DFCs, some have CFCs.

We've pretty much everything everywhere.

Non-MPLS side: Sup32 onboard GE
               Sup720-10G onboard GE
               6724-SFP/CFC
               6408A-GBIC (dumb bus card, no CFC/DFC)
MPLS side: vlan on portchannel on Sup32 onboard GE ports
           vlan on switched 6708-10GE/DFC port
           vlan on switched 6704-10GE/CFC port
           routed on 6408A-GBIC port
           
and this all "just works".  No SR* IOS, though - SXF, SXH3a, SXI.

No ME boxes, though (as mentioned).

> I was pretty sure that this should work.  My TAC engineer got back to me 
> last night and is saying that won't work which I don't think is correct. 
>  Specifically they said:
> 
> "On the 7600, a PFC/DFC or ingress line card (SIP-400/ES20) that does 
> EoMPLS Label imposition/deposition is needed as a MPLS uplink port."

Well.  Technically he is right: you need a PFC/DFC.  That means, if you
have a 7600 with a Sup1 or Sup2, it will *not* do MPLS without an OSM card.

If you have a Sup720-3B/Sup32 or higher, you have a PFC... and MPLS on
LAN cards is explicitely supported there.

*V*PLS won't work without a SIP/ES20 card.

> Well my 6700 LCs all have DFCs; I wouldn't buy them any other way.  The 
> engineer goes on to imply that the VC type on either end is the problem. 
>  Well the VC type is the same on both ends and is working because the 
> VC is up; a mismatch would keep it down (been there done that).  The 
> engineer then gave a description of port-to-port, vlan-to-vlan and 
> port-to-vlan modes, their VCs and how the operate on the 7600.  This 
> should be a VC type 5 port-to-vlan VC I believe (sub-int to SVI). 
> That's what both sides agree on when the VC comes up.

That "SVI" part might be the problem.

I know that the 7600 can *not* do SVI-based EoMPLS - you need to have
a subinterface (VLAN-to-*) or dedicated port (Port-to-*).

I don't know the capabilities of the ME.

(What I'd do next is to try to sniff packets going back and forth over the 
core links, with the appropriate MPLS labels.  Just to see who is sending
and/or receiving what)

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/20090317/7e054f5a/attachment.bin>

From lowen at pari.edu  Tue Mar 17 10:25:23 2009
From: lowen at pari.edu (Lamar Owen)
Date: Tue, 17 Mar 2009 10:25:23 -0400
Subject: [c-nsp] Recommendation? USB to serial adapter working without
	problems	under linux
In-Reply-To: <1237286027.10040.1.camel@dsba-ipso>
References: <1237286027.10040.1.camel@dsba-ipso>
Message-ID: <200903171025.24076.lowen@pari.edu>

On Tuesday 17 March 2009 06:33:47 luismi wrote:
> Any recommendation about a usb to serial adapter?
> We work with linux here in our laptops and some of the adapters we used
> in the past got stuck when they receive too much info very quickly (for
> example, messages from console) so I would like to know if you have some
> idea about any model or manufacter that works without problems.

I use a Digi EdgePort/4 and it just works with any modern Linux I've tried.  
Port 1 comes up as /dev/ttyUSB0; Port 2 comes up as /dev/ttyUSB1, and so on.  
Permissions have occasionally been an issue, at least on Ubuntu 8.10, though.


From A.L.M.Buxey at lboro.ac.uk  Tue Mar 17 10:53:27 2009
From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk)
Date: Tue, 17 Mar 2009 14:53:27 +0000
Subject: [c-nsp] Recommendation? USB to serial adapter working
	without	problems under linux
In-Reply-To: <8066E94B-4F8E-4C66-ABAA-9D1FEEB584DB@bellsouth.net>
References: <1237286027.10040.1.camel@dsba-ipso>
	<20090317104203.GB28497@lboro.ac.uk>
	<8066E94B-4F8E-4C66-ABAA-9D1FEEB584DB@bellsouth.net>
Message-ID: <20090317145327.GB29308@lboro.ac.uk>

Hi,
> Any recommendation for mac's

I like 00:00:00:C0:FF:EE and 00:00:DE:AD:BE:EF myself  ;-)

but seriously, same kit - keyspan USB to serial. 

alan

From ryan at deadfrog.net  Tue Mar 17 10:43:46 2009
From: ryan at deadfrog.net (Ryan Wilkins)
Date: Tue, 17 Mar 2009 09:43:46 -0500
Subject: [c-nsp] Recommendation? USB to serial adapter working
	without	problems under linux
In-Reply-To: <8066E94B-4F8E-4C66-ABAA-9D1FEEB584DB@bellsouth.net>
References: <1237286027.10040.1.camel@dsba-ipso>
	<20090317104203.GB28497@lboro.ac.uk>
	<8066E94B-4F8E-4C66-ABAA-9D1FEEB584DB@bellsouth.net>
Message-ID: <EAEC62F1-B5C0-4EA7-B0C2-4A6D4BDF197D@deadfrog.net>

I have been using an IOGEAR GUC232A without issue on OS X for a number  
of years.

Regards,
Ryan Wilkins

On Mar 17, 2009, at 8:16 AM, Alex Moya wrote:

> Any recommendation for mac's
>


From tsaamnet at gmail.com  Tue Mar 17 12:08:59 2009
From: tsaamnet at gmail.com (Thermos Saamnet)
Date: Tue, 17 Mar 2009 19:08:59 +0300
Subject: [c-nsp] OSPF Areas
Message-ID: <b47b14a00903170908x62d1c11dj51c24bb8dc91c009@mail.gmail.com>

Hi all,

I'm having an issue setting up an OSPF border router using a VRF. Here's the
configuration:

        router ospf 20 vrf clients
         network 10.0.0.0 0.0.0.3 area 0
         network 10.0.0.4 0.0.0.1 area 1

It's pretty basic but strangely enough only routers in Area 0 see the
inter-area routes. Routers in Area 1 don't see the 10.0.0.0/30 (as
inter-area or otherwise). The adjancencies are all up and the routes are
present in the database but routers in Area 1 won't insert them into the
routing table.

Anyone encountered this type of behaviour before?

PS. We're using non-MPLS based VRFs.

From oboehmer at cisco.com  Tue Mar 17 12:19:38 2009
From: oboehmer at cisco.com (Oliver Boehmer (oboehmer))
Date: Tue, 17 Mar 2009 17:19:38 +0100
Subject: [c-nsp] OSPF Areas
In-Reply-To: <b47b14a00903170908x62d1c11dj51c24bb8dc91c009@mail.gmail.com>
References: <b47b14a00903170908x62d1c11dj51c24bb8dc91c009@mail.gmail.com>
Message-ID: <70B7A1CCBFA5C649BD562B6D9F7ED784070EE7F5@xmb-ams-333.emea.cisco.com>

Thermos Saamnet <> wrote on Tuesday, March 17, 2009 17:09:

> Hi all,
> 
> I'm having an issue setting up an OSPF border router using a VRF.
> Here's the configuration:
> 
>         router ospf 20 vrf clients
>          network 10.0.0.0 0.0.0.3 area 0
>          network 10.0.0.4 0.0.0.1 area 1
> 
> It's pretty basic but strangely enough only routers in Area 0 see the
> inter-area routes. Routers in Area 1 don't see the 10.0.0.0/30 (as
> inter-area or otherwise). The adjancencies are all up and the routes
> are present in the database but routers in Area 1 won't insert them
> into the routing table.
> 
> Anyone encountered this type of behaviour before?
> 
> PS. We're using non-MPLS based VRFs.
 
enable 

router ospf <id> vrf <foo>
 capability vrf-lite

on all VRF-lite OSPF speakers to disable the MPLS-VPN PE loop checks
(down bit, domain-it/tag).. 

	oli

From samantha at cairns.net.au  Tue Mar 17 12:21:46 2009
From: samantha at cairns.net.au (Samantha (Regional Connect))
Date: Wed, 18 Mar 2009 02:21:46 +1000
Subject: [c-nsp] 7206 NON VXR
Message-ID: <002101c9a71c$78310090$689301b0$@net.au>

Hey Guys

 

What is the max processor board I can use with a non vxr chasis?

 

 

Thanks

 

Samantha

 

 


From walter.keen at RainierConnect.net  Tue Mar 17 12:34:36 2009
From: walter.keen at RainierConnect.net (Walter Keen)
Date: Tue, 17 Mar 2009 09:34:36 -0700
Subject: [c-nsp] 7206 NON VXR
In-Reply-To: <002101c9a71c$78310090$689301b0$@net.au>
References: <002101c9a71c$78310090$689301b0$@net.au>
Message-ID: <49BFD11C.7010609@rainierconnect.net>

NPE-225, I believe

Samantha (Regional Connect) wrote:
> Hey Guys
>
>  
>
> What is the max processor board I can use with a non vxr chasis?
>
>  
>
>  
>
> Thanks
>
>  
>
> Samantha
>
>  
>
>  
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>   


From luan at netcraftsmen.net  Tue Mar 17 12:36:59 2009
From: luan at netcraftsmen.net (Luan Nguyen)
Date: Tue, 17 Mar 2009 12:36:59 -0400
Subject: [c-nsp] 7206 NON VXR
In-Reply-To: <002101c9a71c$78310090$689301b0$@net.au>
References: <002101c9a71c$78310090$689301b0$@net.au>
Message-ID: <029a01c9a71e$9826d8f0$c8748ad0$@net>

NPE-225 I think is the max you could go.

Regards,

----------------------------------------------------------------------------
---------
Luan Nguyen
Chesapeake NetCraftsmen, LLC.
[Web] http://www.netcraftsmen.net
------------------------------------------------------------------------


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Samantha (Regional
Connect)
Sent: Tuesday, March 17, 2009 12:22 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] 7206 NON VXR

Hey Guys

 

What is the max processor board I can use with a non vxr chasis?

 

 

Thanks

 

Samantha

 

 

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


From dstorandt at teljet.com  Tue Mar 17 12:46:28 2009
From: dstorandt at teljet.com (David Storandt)
Date: Tue, 17 Mar 2009 12:46:28 -0400
Subject: [c-nsp] 7206 NON VXR
In-Reply-To: <002101c9a71c$78310090$689301b0$@net.au>
References: <002101c9a71c$78310090$689301b0$@net.au>
Message-ID: <f52f476c0903170946y5272c67dx45859f495ed3e71d@mail.gmail.com>

NPE-225 with 256MB of memory. The performance barely drives an OC3;
stay away from optical interfaces on the non-VXR systems.

-D

On Tue, Mar 17, 2009 at 12:21 PM, Samantha (Regional Connect)
<samantha at cairns.net.au> wrote:
> Hey Guys
>
>
>
> What is the max processor board I can use with a non vxr chasis?
>
>
>
>
>
> Thanks
>
>
>
> Samantha
>
>
>
>
>
> _______________________________________________
> cisco-nsp mailing list ?cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From gert at greenie.muc.de  Tue Mar 17 13:25:05 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Tue, 17 Mar 2009 18:25:05 +0100
Subject: [c-nsp] SXI leaks (was: Netflow on SUP720-3BXL)
In-Reply-To: <20090317163201.GB14342@biological.warningg.com>
References: <200903151718.22464.andy-lists@bourges.de>
	<200903151904.27158.andy-lists@bourges.de>
	<20090315183250.GH290@greenie.muc.de>
	<49BE6CF5.2020708@imperial.ac.uk>
	<20090316155504.GN290@greenie.muc.de>
	<20090317163201.GB14342@biological.warningg.com>
Message-ID: <20090317172505.GZ290@greenie.muc.de>

Hi,

On Tue, Mar 17, 2009 at 11:32:01AM -0500, Brandon Ewing wrote:
> On Mon, Mar 16, 2009 at 04:55:04PM +0100, Gert Doering wrote:
> > This is on a "peering point + upstream provider" router, with full
> > IPv4 and IPv6 BGP (unicast only).  SXI non-modular, "advanced ip services".
> > 
> > We lose about 2-4 Mbyte of free memory per day, which goes into "holding"
> > for the "BGP Router" process.
> 
> How are you monitoring this?  Is there an OID that's easily watchable to
> keep an eye on this situation?  I have an SXI box carrying full tables from
> multiple providers, so I'm definitely getting some churn on the box.

There's an OID for free memory, out of CISCO-MEMORY-POOL.mib

        # query_base is the starting-point of CISCO-MEMORY-POOL.mib
        my $query_base = ".1.3.6.1.4.1.9.9.48.1.1.1";

(we just walk the whole tree and sort out which pool is what)

Which process is holding the memory is grabbed by a script that runs
once per day and runs "show proc mem" via rsh.  Not pretty, but does the
job.

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 b.turnbow at twt.it  Tue Mar 17 13:43:51 2009
From: b.turnbow at twt.it (Brian Turnbow)
Date: Tue, 17 Mar 2009 18:43:51 +0100
Subject: [c-nsp] 7206 NON VXR
In-Reply-To: <002101c9a71c$78310090$689301b0$@net.au>
References: <002101c9a71c$78310090$689301b0$@net.au>
Message-ID: <F2207DB22012F94E92D7030F81A2629401DBEE2E@twt-exch.milano.twt>

225 is the last "supported" version
300 will "work" depending on ios version. It is not supported by cisco and 12.1 and above don't let you boot with a 300 in it 12.0 will.

System returned to ROM by reload at 11:33:21 CEST Fri Aug 22 2008
System restarted at 11:34:44 CEST Fri Aug 22 2008
System image file is "disk1:c7200-p-mz.120-32.S11.bin"

cisco 7206 (NPE300) processor with 262144K/32768K bytes of memory.
Processor board ID 18283396
R7000 CPU at 262Mhz, Implementation 39, Rev 2.1, 256KB L2 Cache
6 slot midplane, Version 1.3




Brian  


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Samantha (Regional Connect)
Sent: marted? 17 marzo 2009 17.22
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] 7206 NON VXR

Hey Guys

 

What is the max processor board I can use with a non vxr chasis?

 

 

Thanks

 

Samantha

 

 

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

From will at thoughtcrime.net  Tue Mar 17 13:52:17 2009
From: will at thoughtcrime.net (Byrd, William)
Date: Tue, 17 Mar 2009 12:52:17 -0500 (CDT)
Subject: [c-nsp] 7206 NON VXR
Message-ID: <1237312337.v2.mailanyonewebmail-222491@fuse113>

I know at least an NPE-400 will work:

Cisco IOS Software, 7200 Software (C7200-P-M), Version 12.2(25)S9, RELEASE
SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2006 by Cisco Systems, Inc.
Compiled Tue 28-Mar-06 23:12 by alnguyen

ROM: System Bootstrap, Version 12.1(20000710:044039) [nlaw-121E_npeb 117],
DEVELOPMENT SOFTWARE
BOOTLDR: 7200 Software (C7200-KBOOT-M), Version 12.1(8a)E, EARLY
DEPLOYMENT RELEASE SOFTWARE (fc1)

 XXXXXXXXXX uptime is 29 weeks, 5 days, 11 hours, 26 minutes
System returned to ROM by reload at 18:38:09 EDT Wed Aug 20 2008
System restarted at 06:24:32 UTC Thu Aug 21 2008
System image file is "disk0:c7200-p-mz.122-25.S9.bin"

Cisco 7206 (NPE400) processor (revision A) with 491520K/32768K bytes of
memory.
Processor board ID 16072914
R7000 CPU at 350Mhz, Implementation 39, Rev 3.2, 256KB L2 Cache
6 slot midplane, Version 3.0

-Will

----- Original Message -----
From: "Brian Turnbow" <b.turnbow at twt.it>
Sent: Tue, March 17, 2009 13:43
Subject:Re: [c-nsp] 7206 NON VXR


225 is the last "supported" version
300 will "work" depending on ios version. It is not supported by cisco and
12.1 and
above don't let you boot with a 300 in it 12.0 will.

System returned to ROM by reload at 11:33:21 CEST Fri Aug 22 2008
System restarted at 11:34:44 CEST Fri Aug 22 2008
System image file is "disk1:c7200-p-mz.120-32.S11.bin"

cisco 7206 (NPE300) processor with 262144K/32768K bytes of memory.
Processor board ID 18283396
R7000 CPU at 262Mhz, Implementation 39, Rev 2.1, 256KB L2 Cache
6 slot midplane, Version 1.3




Brian


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net]
On Behalf Of Samantha (Regional Connect)
Sent: marted? 17 marzo 2009 17.22
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] 7206 NON VXR

Hey Guys



What is the max processor board I can use with a non vxr chasis?





Thanks



Samantha





_______________________________________________
cisco-nsp mailing 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 damin at nacs.net  Tue Mar 17 14:32:40 2009
From: damin at nacs.net (Gregory Boehnlein)
Date: Tue, 17 Mar 2009 14:32:40 -0400
Subject: [c-nsp] AS5200 / 5300 Modem Cards
In-Reply-To: <036001c9a4ee$defc7af0$9cf570d0$@net>
References: <036001c9a4ee$defc7af0$9cf570d0$@net>
Message-ID: <084201c9a72e$c1479d40$43d6d7c0$@net>

OK.. so here is an interesting secondary question that came up..

Are the Mica Modem modules swappable between the 5200 and 5300 carriers?

> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> bounces at puck.nether.net] On Behalf Of Gregory Boehnlein
> Sent: Saturday, March 14, 2009 5:50 PM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] AS5200 / 5300 Modem Cards
> 
> I'm having a tough time locating this information on CCO. I have an
> AS5200
> sitting in the back, and am wondering if I can move the two Mica
> carrier
> cards into an AS5300? Are they interchangeable?
> 
> _______________________________________________
> cisco-nsp mailing 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 message has been scanned for viruses and
> dangerous content by N2Net Mailshield, and is
> believed to be clean.


From eng_mssk at hotmail.com  Tue Mar 17 14:53:10 2009
From: eng_mssk at hotmail.com (Mohammad Khalil)
Date: Tue, 17 Mar 2009 20:53:10 +0200
Subject: [c-nsp] PPPoA Sessions MRTG
Message-ID: <BLU102-W54B52EAAC0A44B530D2800FA980@phx.gbl>




Hey all , 
im using MRTG for monitoring our network devices traffic.
i faced a problem of how to draw PPPoA sessions as it dont have an OID like PPPoE
we have a router with 2 PPP customers : PPPoA and PPPoE
the OID for the PPPoE sessions can be found easily : 1.3.6.1.4.1.9.9.194.1.1.1
to find the number of PPPoA sessions , we used  CISCO-AAA-SESSION-MIB casnActiveTableEntries "1.3.6.1.4.1.9.9.150.1.1.1"
but that will give all the active sessions on the router , when i used the snmpwalk command on a linux server it gave me over 6000 , while its on the router via show user summary command , gives around 1800 
so the needed configuration was as below:
create on-demand command under the PVC range , under the ATM sub interface (This will reserve the active connections only)
interface ATM1/0/0.11 multipoint
 range pvc 11/35 11/274
  create on-demand
 
as well as , applying the command aaa session-mib populate start in global configuration mode
 
after all , show user summary output:
Device#sh users summary 
1766 session(s) locally terminated
    PPPOA           1007
    PPPOE           759
 
[root at cacti-nms ~]# snmpwalk -v2c -c community IP .1.3.6.1.4.1.9.9.150.1.1.1
SNMPv2-SMI::enterprises.9.9.150.1.1.1.0 = Gauge32: 1766
 
Then to draw the PPPoA sessions , u have to substract the PPPoE sessions as the OID gives the total number of sessions:
Target[Device_PPPoA]:1.3.6.1.4.1.9.9.150.1.1.1.0&1.3.6.1.4.1.9.9.150.1.1.1.0:community at IP - 1.3.6.1.4.1.9.9.194.1.1.1.0&1.3.6.1.4.1.9.9.194.1.1.1.0:community at IP 
 
Thanks all
 
Best Regards,
Mohammad Khalil

 
 





What can you do with the new Windows Live? Find out


See all the ways you can stay connected to friends and family
Get news, entertainment and everything you care about at Live.com. Check it out!
_________________________________________________________________
Drag n? drop?Get easy photo sharing with Windows Live? Photos.

http://www.microsoft.com/windows/windowslive/products/photos.aspx

From eng_mssk at hotmail.com  Tue Mar 17 14:53:32 2009
From: eng_mssk at hotmail.com (Mohammad Khalil)
Date: Tue, 17 Mar 2009 20:53:32 +0200
Subject: [c-nsp] Network Drawing tool
Message-ID: <BLU102-W40644A1C5E9F41CA91C7B7FA980@phx.gbl>










hey all , 

im using visio to draw my network diagrams 
is there any useful tool that accomplish the same goal ?

Thanks

Best Regards,
Mohammad Khalil

Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! Try it!
What can you do with the new Windows Live? Find out
_________________________________________________________________
More than messages?check out the rest of the Windows Live?.
http://www.microsoft.com/windows/windowslive/

From abalashov at evaristesys.com  Tue Mar 17 15:02:22 2009
From: abalashov at evaristesys.com (Alex Balashov)
Date: Tue, 17 Mar 2009 15:02:22 -0400
Subject: [c-nsp] Network Drawing tool
In-Reply-To: <BLU102-W40644A1C5E9F41CA91C7B7FA980@phx.gbl>
References: <BLU102-W40644A1C5E9F41CA91C7B7FA980@phx.gbl>
Message-ID: <49BFF3BE.1010906@evaristesys.com>

'dia' works great under Linux.

Mohammad Khalil wrote:

> 
> 
> 
> 
> 
> 
> 
> 
> hey all , 
> 
> im using visio to draw my network diagrams 
> is there any useful tool that accomplish the same goal ?
> 
> Thanks
> 
> Best Regards,
> Mohammad Khalil
> 
> Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! Try it!
> What can you do with the new Windows Live? Find out
> _________________________________________________________________
> More than messages?check out the rest of the Windows Live?.
> http://www.microsoft.com/windows/windowslive/
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


-- 
Alex Balashov
Evariste Systems
Web    : http://www.evaristesys.com/
Tel    : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (678) 237-1775

From nasir.shaikh at bt.com  Tue Mar 17 15:25:25 2009
From: nasir.shaikh at bt.com (nasir.shaikh at bt.com)
Date: Tue, 17 Mar 2009 19:25:25 -0000
Subject: [c-nsp] Mutual redistribution between vrf and global routing table
Message-ID: <2B0ABDF9E4A1204AA7467F200753545608FF4460@E03MVZ4-UKDY.domain1.systemhost.net>

Hi,

Due to an implementation of a L2 VPN (EoMPLS) I am having to extend the boundary of my MAN running MPLS a step further towards the datacentre. 
The MAN has several sites all in a simple L3 vpn. 
There is redistribution between the rest of the corporate network (eigrp) and the MAN vrf en vice versa on the core MAN switches.
This is the relevant config:
ip vrf MAN
 rd 65041:100
 route-target export 65040:100
 route-target import 65040:100
 mdt default 239.18.250.1
 mdt data 239.18.251.0 0.0.0.255 threshold 500


interface GigabitEthernet3/1
 description ** 1G LAN **
 ip vrf forwarding MAN
 ip address 10.10.22.1 255.255.255.240
 ip access-group level0_g3/1 in
 ip verify unicast source reachable-via rx
 logging event link-status

<omitted>        

interface TenGigabitEthernet7/4
 description ** 10G to 6509_E int TenG1/1 **
 no ip address
 logging event link-status
!
interface TenGigabitEthernet7/4.100
 description *** connection to the rest of the corporate network ***
 encapsulation dot1Q 100
 ip vrf forwarding MAN
 ip address 172.18.250.130 255.255.255.252
!
<omitted>
!         
router eigrp 1
 no auto-summary
 !        
 address-family ipv4 vrf MAN
 redistribute connected
 redistribute static
 redistribute bgp 65040 route-map bgp-to-eigrp
 network 172.18.250.128 0.0.0.3
 default-metric 1000000 1 255 1 1500
 no auto-summary
 autonomous-system 1
 exit-address-family
 nsf      
!         
router isis 
<omitted>
 bfd all-interfaces
!
router bgp 65040
 bgp router-id xxxxxx
<omitted>
!
 neighbor 10.20.30.12 peer-group MAN_internal
 !
 address-family vpnv4
<omitted>
 exit-address-family
 !        
 address-family ipv4 vrf MAN
 redistribute connected
 redistribute static
 redistribute eigrp 1 route-map eigrp-to-bgp
 default-information originate
 no auto-summary
 no synchronization
 exit-address-family
 !   
As you can see the interfaces of the MAN sites and the interface towards the global network are in the same vrf & redist is done under address-families (eigrp and BGP)
     
Now due to extending the MPLS boundary (or the MAN boundary) to a device which is a part of the corporate network, I have to move the redistribution also on this device. (6509-E sup 720-3b) .
The MAN and the rest of the corporate network can be seen as one entity but redist is required because of the MPLS platform on the MAN and normal EIGRP on the rest of the network. On this 6509 (122-18.SXF7) I should have a similar redistribution as shown above but except for the interface towards the MAN there are no vrfs configured. So what are my options?
1. configure a corporate vrf and im-export the route-targets mutually between the MAN vrf
2. Use fancy PBR/VRF stuff which requires SFI
3. Do not change MPLS boundary, terminate EoMPLS on the PE, transport (trunk) all remote vlans over the corporate device (the 6509) which makes the corporate core switch part of the datacentre where the EoMPLS traffic is supposed to go.

Topology:
Remote MAN site switch =>PE--MPLS--PE=>corporate switch => datacentre switch

I am inclined towards option 1 and would like your opinions about this.
Design guidelines are:
Dynamic routing required
I can unicast more details if someone has the time and the inclination....
Sorry for the lengthy mail - trying to be as complete as possible


Nasir Shaikh 
This email contains information from BT Nederland N.V., which may be privileged or confidential. 
It's meant only for the individual(s) or entity named above. If you are not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited.  
If you have received this email in error, please let me know immediately on the email address above.
We monitor our systems, and may record your emails.

BT Nederland N.V. 
Registered office:  Offices Minerva and Mercurius, Herikerbergweg 2, 1101 CM Amsterdam
Registered at the Amsterdam Chamber of Commerce no:  33296214




From jcartier at acs.on.ca  Tue Mar 17 15:28:31 2009
From: jcartier at acs.on.ca (Jeff Cartier)
Date: Tue, 17 Mar 2009 15:28:31 -0400
Subject: [c-nsp] BGP/ACL Question
Message-ID: <BCD3E762F1767C42A5226BBACDE49BFBCE75FE@loki.acs.local>

I'm going to be configuring CoPP to match BGP traffic between
peers...and I am having a forgetful moment :-)...in order to match the
BGP peer, in my ACL, should I be matching based on the BGP local
router-ID or on the directly connected interface?

 

I'm thinking local router-ID...

 

Just looking for some feedback!  Thanks all!

 


From petelists at templin.org  Tue Mar 17 15:49:41 2009
From: petelists at templin.org (Pete Templin)
Date: Tue, 17 Mar 2009 14:49:41 -0500
Subject: [c-nsp] BGP/ACL Question
In-Reply-To: <BCD3E762F1767C42A5226BBACDE49BFBCE75FE@loki.acs.local>
References: <BCD3E762F1767C42A5226BBACDE49BFBCE75FE@loki.acs.local>
Message-ID: <49BFFED5.2090808@templin.org>

Jeff Cartier wrote:
> I'm going to be configuring CoPP to match BGP traffic between
> peers...and I am having a forgetful moment :-)...in order to match the
> BGP peer, in my ACL, should I be matching based on the BGP local
> router-ID or on the directly connected interface?

Match based on whatever the update-source is for that neighbor.  Default 
is closest physical interface at the time that the session is 
established, typical practice is to use a loopback interface for iBGP 
sessions.  Router-ID won't appear in the IP headers of the packets.

pt


From KaeglerM at tessco.com  Tue Mar 17 16:13:46 2009
From: KaeglerM at tessco.com (Kaegler, Mike)
Date: Tue, 17 Mar 2009 16:13:46 -0400
Subject: [c-nsp] Network Drawing tool
In-Reply-To: <BLU102-W40644A1C5E9F41CA91C7B7FA980@phx.gbl>
Message-ID: <C5E57CBA.7B99%KaeglerM@tessco.com>

There was a huge NANOG thread about this a few weeks ago...
http://www.merit.edu/mail.archives/nanog/msg15295.html

Because of the recommendations in that thread, I got out the credit card for
OmniGraffle, which despite being a generally unheard of mac-only product got
specific praise in perhaps more than half of the posts to the thread. I
certainly have not regretted the purchase.

Other recommendations included Dia, Powerpoint, and a dozen or more
one-offs.
-porkchop


On 3/17/09 2:53 PM, "Mohammad Khalil" <eng_mssk at hotmail.com> wrote:

> 








hey all , 

im using visio to draw my network diagrams 
is there any
> useful tool that accomplish the same goal ?

Thanks

Best Regards,
Mohammad
> Khalil

Invite your mail contacts to join your friends list with Windows Live
> Spaces. It's easy! Try it!
What can you do with the new Windows Live? Find
> out
_________________________________________________________________
More
> than messages?check out the rest of the Windows
> Live?.
http://www.microsoft.com/windows/windowslive/
_________________________
> ______________________
cisco-nsp mailing list
> cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
a
> rchive at http://puck.nether.net/pipermail/cisco-nsp/

-- 
Michael Kaegler, TESSCO Technologies: Engineering, 410 229 1295
Your wireless success, nothing less. http://www.tessco.com/


From jmplank at gmail.com  Tue Mar 17 16:20:36 2009
From: jmplank at gmail.com (Jason Plank)
Date: Tue, 17 Mar 2009 16:20:36 -0400
Subject: [c-nsp] Network Drawing tool
In-Reply-To: <C5E57CBA.7B99%KaeglerM@tessco.com>
References: <BLU102-W40644A1C5E9F41CA91C7B7FA980@phx.gbl>
	<C5E57CBA.7B99%KaeglerM@tessco.com>
Message-ID: <adc8da300903171320t470d395x971d8e92ac577d2f@mail.gmail.com>

I'm a big fan of Omni Graffle also. In a mixed vendor environment there are
definitely some quirks that come up, but for the most part I prefer to use
Omni Graffle vs Visio. Plus, this means I have one less reason to run a POS
microsoft OS in a VM.

On Tue, Mar 17, 2009 at 4:13 PM, Kaegler, Mike <KaeglerM at tessco.com> wrote:

> There was a huge NANOG thread about this a few weeks ago...
> http://www.merit.edu/mail.archives/nanog/msg15295.html
>
> Because of the recommendations in that thread, I got out the credit card
> for
> OmniGraffle, which despite being a generally unheard of mac-only product
> got
> specific praise in perhaps more than half of the posts to the thread. I
> certainly have not regretted the purchase.
>
> Other recommendations included Dia, Powerpoint, and a dozen or more
> one-offs.
> -porkchop
>
>
> On 3/17/09 2:53 PM, "Mohammad Khalil" <eng_mssk at hotmail.com> wrote:
>
> >
>
>
>
>
>
>
>
>
> hey all ,
>
> im using visio to draw my network diagrams
> is there any
> > useful tool that accomplish the same goal ?
>
> Thanks
>
> Best Regards,
> Mohammad
> > Khalil
>
> Invite your mail contacts to join your friends list with Windows Live
> > Spaces. It's easy! Try it!
> What can you do with the new Windows Live? Find
> > out
> _________________________________________________________________
> More
> > than messages?check out the rest of the Windows
> > Live?.
> http://www.microsoft.com/windows/windowslive/
> _________________________
> > ______________________
> cisco-nsp mailing list
> > cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> a
> > rchive at http://puck.nether.net/pipermail/cisco-nsp/
>
> --
> Michael Kaegler, TESSCO Technologies: Engineering, 410 229 1295
> Your wireless success, nothing less. http://www.tessco.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/
>



-- 
--
Jason Plank
(CCIE #16560)

From jkrejci at usinternet.com  Tue Mar 17 15:29:43 2009
From: jkrejci at usinternet.com (Justin Krejci)
Date: Tue, 17 Mar 2009 14:29:43 -0500
Subject: [c-nsp] Network Drawing tool
In-Reply-To: <BLU102-W40644A1C5E9F41CA91C7B7FA980@phx.gbl>
References: <BLU102-W40644A1C5E9F41CA91C7B7FA980@phx.gbl>
Message-ID: <29D80CFFB2D34663873C58BC70FE99E5@usicorp.usinternet.com>

This was just discussed on NANOG last month with a lot of suggestions

http://www.merit.edu/mail.archives/nanog/msg15295.html


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Mohammad Khalil
Sent: Tuesday, March 17, 2009 1:54 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Network Drawing tool










hey all , 

im using visio to draw my network diagrams 
is there any useful tool that accomplish the same goal ?

Thanks

Best Regards,
Mohammad Khalil

Invite your mail contacts to join your friends list with Windows Live
Spaces. It's easy! Try it!
What can you do with the new Windows Live? Find out
_________________________________________________________________
More than messages-check out the rest of the Windows LiveT.
http://www.microsoft.com/windows/windowslive/
_______________________________________________
cisco-nsp mailing list  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  Tue Mar 17 16:10:15 2009
From: pdavis at i2k.com (Phil Davis)
Date: Tue, 17 Mar 2009 16:10:15 -0400
Subject: [c-nsp] 7206 NON VXR
In-Reply-To: <1237312337.v2.mailanyonewebmail-222491@fuse113>
References: <1237312337.v2.mailanyonewebmail-222491@fuse113>
Message-ID: <49C003A7.4070908@i2k.com>

That's odd, the NPE-300s and 400s I have are keyed to prevent insertion 
in a non-VXR chassis.

Byrd, William wrote:
> I know at least an NPE-400 will work:
>
> Cisco IOS Software, 7200 Software (C7200-P-M), Version 12.2(25)S9, RELEASE
> SOFTWARE (fc1)
> Technical Support: http://www.cisco.com/techsupport
> Copyright (c) 1986-2006 by Cisco Systems, Inc.
> Compiled Tue 28-Mar-06 23:12 by alnguyen
>
> ROM: System Bootstrap, Version 12.1(20000710:044039) [nlaw-121E_npeb 117],
> DEVELOPMENT SOFTWARE
> BOOTLDR: 7200 Software (C7200-KBOOT-M), Version 12.1(8a)E, EARLY
> DEPLOYMENT RELEASE SOFTWARE (fc1)
>
>  XXXXXXXXXX uptime is 29 weeks, 5 days, 11 hours, 26 minutes
> System returned to ROM by reload at 18:38:09 EDT Wed Aug 20 2008
> System restarted at 06:24:32 UTC Thu Aug 21 2008
> System image file is "disk0:c7200-p-mz.122-25.S9.bin"
>
> Cisco 7206 (NPE400) processor (revision A) with 491520K/32768K bytes of
> memory.
> Processor board ID 16072914
> R7000 CPU at 350Mhz, Implementation 39, Rev 3.2, 256KB L2 Cache
> 6 slot midplane, Version 3.0
>
> -Will
>
> ----- Original Message -----
> From: "Brian Turnbow" <b.turnbow at twt.it>
> Sent: Tue, March 17, 2009 13:43
> Subject:Re: [c-nsp] 7206 NON VXR
>
>
> 225 is the last "supported" version
> 300 will "work" depending on ios version. It is not supported by cisco and
> 12.1 and
> above don't let you boot with a 300 in it 12.0 will.
>
> System returned to ROM by reload at 11:33:21 CEST Fri Aug 22 2008
> System restarted at 11:34:44 CEST Fri Aug 22 2008
> System image file is "disk1:c7200-p-mz.120-32.S11.bin"
>
> cisco 7206 (NPE300) processor with 262144K/32768K bytes of memory.
> Processor board ID 18283396
> R7000 CPU at 262Mhz, Implementation 39, Rev 2.1, 256KB L2 Cache
> 6 slot midplane, Version 1.3
>
>
>
>
> Brian
>
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net]
> On Behalf Of Samantha (Regional Connect)
> Sent: marted? 17 marzo 2009 17.22
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] 7206 NON VXR
>
> Hey Guys
>
>
>
> What is the max processor board I can use with a non vxr chasis?
>
>
>
>
>
> Thanks
>
>
>
> Samantha
>
>
>
>
>
> _______________________________________________
> cisco-nsp mailing 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/


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


From ip at ioshints.info  Tue Mar 17 17:20:19 2009
From: ip at ioshints.info (Ivan Pepelnjak)
Date: Tue, 17 Mar 2009 22:20:19 +0100
Subject: [c-nsp] BGP conditional advertisemet - NON-EXIST route
	map'saccess-list problem
In-Reply-To: <3329cbb40903151532i1d09a108n3a48eaa6d00785ab@mail.gmail.com>
References: <d9281f5c0903150606m3fb9e1ddwfc75c6b7179b87af@mail.gmail.com>
	<3329cbb40903151532i1d09a108n3a48eaa6d00785ab@mail.gmail.com>
Message-ID: <00a201c9a746$2d7f5a40$0a00000a@nil.si>

Did some tests on the NON-EXIST-MAP with 12.2SRC. I was spreading wrong
rumors, time to fix them:

* The route-map checks the routes in the BGP table (_not_ in the IP routing
table). Dale was right.
* It can take a while for the routes to be advertised/withdrawn; the
non-exist-map is checked only at the BGP scan intervals (60 seconds by
default, can be adjusted).
* You can use a combination of an access-list and AS-path access-list in the
route-map.

The handling of standard access-lists used in the "match ip address"
route-map condition is a bit weird, though:

* "permit any" does _NOT_ work.
* "permit prefix 0.0.0.0" (which gets translated into "permit prefix" in
standard ACL) does _NOT_ work.
* fancy wildcard tests (for example "permit 0.0.0.0 127.255.255.255) do
_NOT_ work

It looks like:

* the IP prefix in the BGP table must match the address in the ACL exactly
(wildcard bits are ignored).
* ... but you still need the wildcard bits (inverted netmask) for the match
to work.

For example: if you want to match 10.8.8.0/24, you have to use "permit
10.8.8.0 0.0.0.255". "permit 10.8.8.0" or "permit 10.8.0.0 0.0.255.255" do
_NOT_ work.

Left to do: tests with the ip prefix-list instead of IP access list (and no,
I will NOT test extended ACL :).

Hope this helps
Ivan

> -----Original Message-----
> From: Dale Shaw [mailto:dale.shaw+cisco-nsp at gmail.com] 
> Sent: Sunday, March 15, 2009 11:33 PM
> To: Burak Dikici
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] BGP conditional advertisemet - NON-EXIST 
> route map'saccess-list problem
> 
> Hi Burak,
> 
> On Mon, Mar 16, 2009 at 12:06 AM, Burak Dikici 
> <bdikici at gmail.com> wrote:
> > i am trying to use
> > BGP conditional advertisemet configuration. I have got a 
> problem with 
> > NON-EXIST route map's access-list. In the NON-EXIST router map i am 
> > using the commands which is written below ;
> 
> Here are some notes I made recently when playing with BGP 
> conditional advertising. I hope it helps.
> 
> 1.) prefixes matched in advertise-map and exist/non-exist map 
> must exist (or not) in the *BGP* table
>  however: they do not need to be locally originated (e.g. R1 
> can match routes received from R2 and advertise (or not) to R3
>  and: the validity of the prefix in the BGP table (i.e. 
> RIB-failure) doesn't matter. if there's there, and using 
> exist-map, the condition is met.
> 
> 2.) when using 'exist' map, prefixes matched by advertise-map 
> are advertised when exist-map condition is met
>  example: advertise 1.0.0.0/8 (advertise-map) from BGP table when
> 3.20.20.0/24 (exist-map) exists in BGP table
> 
> 3.) when exist 'non-exist' map, prefixes matched by 
> advertise-map are advertised when non-exist-map condition is met
>  example: advertise 1.0.0.0/8 (advertise-map) from BGP table when
> 3.20.20.0/24 (non-exist-map) does NOT exist in BGP table
> 
> 4.) prefixes matched in advertise-map are the only prefixes 
> affected -- other prefixes that may exist are advertised (or 
> not) as normal
> 
> 5.) when dealing with conditional advertisement tasks, always 
> consider what will happen normally (without any config)
> 
> I'd be happy to be corrected, but I think the first point is 
> contrary to what Ivan said. Also consider point #4 -- BGP 
> conditional advertising is not strictly a route filtering 
> mechanism, although it can be configured to achieve similar results.
> 
> cheers,
> Dale
> 
> 


From Jay.Murphy at state.nm.us  Tue Mar 17 17:12:55 2009
From: Jay.Murphy at state.nm.us (Murphy, Jay, DOH)
Date: Tue, 17 Mar 2009 15:12:55 -0600
Subject: [c-nsp] BGP/ACL Question
In-Reply-To: <49BFFED5.2090808@templin.org>
References: <BCD3E762F1767C42A5226BBACDE49BFBCE75FE@loki.acs.local>
	<49BFFED5.2090808@templin.org>
Message-ID: <A925AC5C659BD64FBA4E84EC3496887308375392@CEXMB4.nmes.lcl>

Second the suggestion


Jay Murphy 
IP Network Specialist 
NM Department of Health 
ITSD - IP Network Operations 
Santa Fe, New Mexico 87502 
Bus. Ph.: 505.827.2851

"We move the information that moves your world." 






-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Pete Templin
Sent: Tuesday, March 17, 2009 1:50 PM
To: Jeff Cartier
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] BGP/ACL Question

Jeff Cartier wrote:
> I'm going to be configuring CoPP to match BGP traffic between
> peers...and I am having a forgetful moment :-)...in order to match the
> BGP peer, in my ACL, should I be matching based on the BGP local
> router-ID or on the directly connected interface?

Match based on whatever the update-source is for that neighbor.  Default

is closest physical interface at the time that the session is 
established, typical practice is to use a loopback interface for iBGP 
sessions.  Router-ID won't appear in the IP headers of the packets.

pt

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

______________________________________________________________________
This inbound email has been scanned by the MessageLabs Email Security
System.
______________________________________________________________________


Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System. 




From mksmith at adhost.com  Tue Mar 17 17:57:10 2009
From: mksmith at adhost.com (Michael K. Smith - Adhost)
Date: Tue, 17 Mar 2009 14:57:10 -0700
Subject: [c-nsp] Cisco 3750G-24PS Issues with POE
In-Reply-To: <99bc91e0903170427r6557b26ax11ed9a60e2aa9f01@mail.gmail.com>
References: <99bc91e0903170427r6557b26ax11ed9a60e2aa9f01@mail.gmail.com>
Message-ID: <17838240D9A5544AAA5FF95F8D52031605B421A5@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 George Stylianou
> Sent: Tuesday, March 17, 2009 4:28 AM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] Cisco 3750G-24PS Issues with POE
> 
> hi,
> 
> I have 2 of these which are both on 12.2(35)SE5.
> 
> We are connecting Avaya handsets to the ports and the switches are not
> pushing power to the phones. Have tried multiple phones and ports on
> both switches but the phones just dont power on.
> 
> have looked at all POE related config and everything seems fine.
> 
> Has anyone else experienced similar issues?
> 
Have you set 'power inline auto' on the ports for the phones?

Regards,

Mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 474 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090317/2a47d98a/attachment.bin>

From sethm at rollernet.us  Tue Mar 17 18:02:49 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Tue, 17 Mar 2009 15:02:49 -0700
Subject: [c-nsp] Cisco 3750G-24PS Issues with POE
In-Reply-To: <17838240D9A5544AAA5FF95F8D52031605B421A5@ad-exh01.adhost.lan>
References: <99bc91e0903170427r6557b26ax11ed9a60e2aa9f01@mail.gmail.com>
	<17838240D9A5544AAA5FF95F8D52031605B421A5@ad-exh01.adhost.lan>
Message-ID: <49C01E09.5080409@rollernet.us>

Michael K. Smith - Adhost wrote:
> 
>> -----Original Message-----
>> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
>> bounces at puck.nether.net] On Behalf Of George Stylianou
>> Sent: Tuesday, March 17, 2009 4:28 AM
>> To: cisco-nsp at puck.nether.net
>> Subject: [c-nsp] Cisco 3750G-24PS Issues with POE
>>
>> hi,
>>
>> I have 2 of these which are both on 12.2(35)SE5.
>>
>> We are connecting Avaya handsets to the ports and the switches are not
>> pushing power to the phones. Have tried multiple phones and ports on
>> both switches but the phones just dont power on.
>>
>> have looked at all POE related config and everything seems fine.
>>
>> Has anyone else experienced similar issues?
>>
> Have you set 'power inline auto' on the ports for the phones?
> 

And do a 'show power inline' to verify availability. Example:

Module   Available     Used     Remaining
          (Watts)     (Watts)    (Watts)
------   ---------   --------   ---------
1           160.0       22.9       137.1
Interface Admin  Oper       Power   Device              Class Max
                            (Watts)
--------- ------ ---------- ------- ------------------- ----- ----
Fa1/0/1   off    off        0.0     n/a                 n/a   15.4
Fa1/0/2   off    off        0.0     n/a                 n/a   15.4
Fa1/0/3   off    off        0.0     n/a                 n/a   15.4
Fa1/0/4   off    off        0.0     n/a                 n/a   15.4
Fa1/0/5   off    off        0.0     n/a                 n/a   15.4
Fa1/0/6   off    off        0.0     n/a                 n/a   15.4
Fa1/0/7   off    off        0.0     n/a                 n/a   15.4
Fa1/0/8   auto   on         4.5     Polycom SoundPoint  1     15.4
Fa1/0/9   off    off        0.0     n/a                 n/a   15.4
Fa1/0/10  off    off        0.0     n/a                 n/a   15.4
Fa1/0/11  off    off        0.0     n/a                 n/a   15.4
Fa1/0/12  off    off        0.0     n/a                 n/a   15.4
Fa1/0/13  off    off        0.0     n/a                 n/a   15.4
Fa1/0/14  off    off        0.0     n/a                 n/a   15.4
Fa1/0/15  auto   on         4.5     Polycom SoundPoint  1     15.4
Fa1/0/16  auto   on         15.4    Ieee PD             0     15.4


~Seth

From RPhookun at lecg.com  Tue Mar 17 18:04:29 2009
From: RPhookun at lecg.com (RPhookun at lecg.com)
Date: Tue, 17 Mar 2009 15:04:29 -0700
Subject: [c-nsp] BGP conditional advertisemet - NON-EXIST
 route	map'saccess-list problem
In-Reply-To: <00a201c9a746$2d7f5a40$0a00000a@nil.si>
Message-ID: <OF694CC1E4.1EAB3DA0-ON8825757C.007916C7-8825757C.00797570@lecg.com>

The prefix-list within the Non-Exist clause also has to *exactly* match 
the prefix in the bgp table..
Regards,
./Randy





"Ivan Pepelnjak" <ip at ioshints.info> 
Sent by: cisco-nsp-bounces at puck.nether.net
03/17/2009 02:20 PM

To
"'Dale Shaw'" <dale.shaw+cisco-nsp at gmail.com>, "'Burak Dikici'" 
<bdikici at gmail.com>
cc
cisco-nsp at puck.nether.net
Subject
Re: [c-nsp] BGP conditional advertisemet - NON-EXIST route 
map'saccess-list problem






Did some tests on the NON-EXIST-MAP with 12.2SRC. I was spreading wrong
rumors, time to fix them:

* The route-map checks the routes in the BGP table (_not_ in the IP 
routing
table). Dale was right.
* It can take a while for the routes to be advertised/withdrawn; the
non-exist-map is checked only at the BGP scan intervals (60 seconds by
default, can be adjusted).
* You can use a combination of an access-list and AS-path access-list in 
the
route-map.

The handling of standard access-lists used in the "match ip address"
route-map condition is a bit weird, though:

* "permit any" does _NOT_ work.
* "permit prefix 0.0.0.0" (which gets translated into "permit prefix" in
standard ACL) does _NOT_ work.
* fancy wildcard tests (for example "permit 0.0.0.0 127.255.255.255) do
_NOT_ work

It looks like:

* the IP prefix in the BGP table must match the address in the ACL exactly
(wildcard bits are ignored).
* ... but you still need the wildcard bits (inverted netmask) for the 
match
to work.

For example: if you want to match 10.8.8.0/24, you have to use "permit
10.8.8.0 0.0.0.255". "permit 10.8.8.0" or "permit 10.8.0.0 0.0.255.255" do
_NOT_ work.

Left to do: tests with the ip prefix-list instead of IP access list (and 
no,
I will NOT test extended ACL :).

Hope this helps
Ivan

> -----Original Message-----
> From: Dale Shaw [mailto:dale.shaw+cisco-nsp at gmail.com] 
> Sent: Sunday, March 15, 2009 11:33 PM
> To: Burak Dikici
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] BGP conditional advertisemet - NON-EXIST 
> route map'saccess-list problem
> 
> Hi Burak,
> 
> On Mon, Mar 16, 2009 at 12:06 AM, Burak Dikici 
> <bdikici at gmail.com> wrote:
> > i am trying to use
> > BGP conditional advertisemet configuration. I have got a 
> problem with 
> > NON-EXIST route map's access-list. In the NON-EXIST router map i am 
> > using the commands which is written below ;
> 
> Here are some notes I made recently when playing with BGP 
> conditional advertising. I hope it helps.
> 
> 1.) prefixes matched in advertise-map and exist/non-exist map 
> must exist (or not) in the *BGP* table
>  however: they do not need to be locally originated (e.g. R1 
> can match routes received from R2 and advertise (or not) to R3
>  and: the validity of the prefix in the BGP table (i.e. 
> RIB-failure) doesn't matter. if there's there, and using 
> exist-map, the condition is met.
> 
> 2.) when using 'exist' map, prefixes matched by advertise-map 
> are advertised when exist-map condition is met
>  example: advertise 1.0.0.0/8 (advertise-map) from BGP table when
> 3.20.20.0/24 (exist-map) exists in BGP table
> 
> 3.) when exist 'non-exist' map, prefixes matched by 
> advertise-map are advertised when non-exist-map condition is met
>  example: advertise 1.0.0.0/8 (advertise-map) from BGP table when
> 3.20.20.0/24 (non-exist-map) does NOT exist in BGP table
> 
> 4.) prefixes matched in advertise-map are the only prefixes 
> affected -- other prefixes that may exist are advertised (or 
> not) as normal
> 
> 5.) when dealing with conditional advertisement tasks, always 
> consider what will happen normally (without any config)
> 
> I'd be happy to be corrected, but I think the first point is 
> contrary to what Ivan said. Also consider point #4 -- BGP 
> conditional advertising is not strictly a route filtering 
> mechanism, although it can be configured to achieve similar results.
> 
> cheers,
> Dale
> 
> 

_______________________________________________
cisco-nsp mailing list  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  Wed Mar 18 06:14:57 2009
From: eng_mssk at hotmail.com (Mohammad Khalil)
Date: Wed, 18 Mar 2009 12:14:57 +0200
Subject: [c-nsp] SFP-GE-Z
Message-ID: <BLU102-W19D14D16A93617C8C147B0FA990@phx.gbl>






Hey all
i connected the mentioned SFP to GSR , but when i make show run on that interface , i found something weiard 
sh int g6/1/1 | inc media
  Full Duplex, 1000Mbps, link type is autonegotiation, media type is unknown 0

does anyone faces this before ??

Thanks

Best Regards,
Mohammad Khalil

Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! Try it!
_________________________________________________________________
News, entertainment and everything you care about at Live.com. Get it now!
http://www.live.com/getstarted.aspx

From asturluismi at gmail.com  Wed Mar 18 07:10:06 2009
From: asturluismi at gmail.com (luismi)
Date: Wed, 18 Mar 2009 12:10:06 +0100
Subject: [c-nsp] Network Drawing tool
In-Reply-To: <BLU102-W40644A1C5E9F41CA91C7B7FA980@phx.gbl>
References: <BLU102-W40644A1C5E9F41CA91C7B7FA980@phx.gbl>
Message-ID: <1237374606.11188.2.camel@dsba-ipso>

http://www.pacestar.com/lanflow/index.html

I was working with it, it is cheap and IMHO very good software
The only problem is that it doesn't support Visio stencils :-P
I don't know if Pacestar guys have change that in the latest versions.

El mar, 17-03-2009 a las 20:53 +0200, Mohammad Khalil escribi?:
> 
> 
> 
> 
> 
> 
> 
> 
> hey all , 
> 
> im using visio to draw my network diagrams 
> is there any useful tool that accomplish the same goal ?
> 
> Thanks
> 
> Best Regards,
> Mohammad Khalil
> 
> Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! Try it!
> What can you do with the new Windows Live? Find out
> _________________________________________________________________
> More than messages?check out the rest of the Windows Live?.
> http://www.microsoft.com/windows/windowslive/
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


From hegedus.gabor at euroway.hu  Wed Mar 18 05:21:47 2009
From: hegedus.gabor at euroway.hu (Hegedus Gabor)
Date: Wed, 18 Mar 2009 10:21:47 +0100
Subject: [c-nsp] centralized mac filtering
Message-ID: <49C0BD2B.8040809@euroway.hu>

Hi all,

Is any solution to filtering wifi mac addresses from one database, if i 
have more devices and one wireless domain with one  ssid?

thank you!
br

Gabor

From eng_mssk at hotmail.com  Wed Mar 18 05:02:35 2009
From: eng_mssk at hotmail.com (Mohammad Khalil)
Date: Wed, 18 Mar 2009 11:02:35 +0200
Subject: [c-nsp] SFP-GE-Z
Message-ID: <BLU102-W557A867180439F099E1AAFA990@phx.gbl>


Hey all
i connected the mentioned SFP to GSR , but when i make show run on that interface , i found something weiard 
sh int g6/1/1 | inc media
  Full Duplex, 1000Mbps, link type is autonegotiation, media type is unknown 0

does anyone faces this before ??

Thanks

Best Regards,
Mohammad Khalil

_________________________________________________________________
Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy!
http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mkt=en-us

From szilard.matyas at yahoo.com  Wed Mar 18 05:57:46 2009
From: szilard.matyas at yahoo.com (Szilard Matyas)
Date: Wed, 18 Mar 2009 02:57:46 -0700 (PDT)
Subject: [c-nsp] Routers SPF calculation time
Message-ID: <708770.35016.qm@web45701.mail.sp1.yahoo.com>

Dear Sirs, 

I would like to collect real-world average SPF calculation times in large OSPF or IS-IS areas. If someone work for a big SP please write it to me.
And please if someone answer  write also the number of routers and the number links that the area consists, and the type of the router that made the calculations in the area.

Thank you everyone in advance.

Regards, 

szicsu



      

From shariq.qam at gmail.com  Wed Mar 18 07:04:01 2009
From: shariq.qam at gmail.com (shariq qamar)
Date: Wed, 18 Mar 2009 16:34:01 +0530
Subject: [c-nsp] equivlant of backup interface command in cisco router
	ethernet interfaces
Message-ID: <171b010e0903180404t47869e0fxc10d115ce918f7ec@mail.gmail.com>

Dear Techies ,

what is the equivalent command in juniper for below cisco commands

interface gig1/2
backup interface GigabitEthernet5/2

Regards,
Shariq Qamar,

From george at three6five.com  Wed Mar 18 02:32:38 2009
From: george at three6five.com (George Stylianou)
Date: Wed, 18 Mar 2009 08:32:38 +0200
Subject: [c-nsp] Cisco 3750G-24PS Issues with POE
In-Reply-To: <17838240D9A5544AAA5FF95F8D52031605B421A5@ad-exh01.adhost.lan>
References: <99bc91e0903170427r6557b26ax11ed9a60e2aa9f01@mail.gmail.com>
	<17838240D9A5544AAA5FF95F8D52031605B421A5@ad-exh01.adhost.lan>
Message-ID: <006e01c9a793$66ed2b20$34c78160$@com>



> -----Original Message-----
> From: Michael K. Smith - Adhost [mailto:mksmith at adhost.com]
> Sent: 17 March 2009 23:57
> To: George Stylianou; cisco-nsp at puck.nether.net
> Subject: RE: [c-nsp] Cisco 3750G-24PS Issues with POE
> 
> 
> 
> > -----Original Message-----
> > From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> > bounces at puck.nether.net] On Behalf Of George Stylianou
> > Sent: Tuesday, March 17, 2009 4:28 AM
> > To: cisco-nsp at puck.nether.net
> > Subject: [c-nsp] Cisco 3750G-24PS Issues with POE
> >
> > hi,
> >
> > I have 2 of these which are both on 12.2(35)SE5.
> >
> > We are connecting Avaya handsets to the ports and the switches are
> not
> > pushing power to the phones. Have tried multiple phones and ports on
> > both switches but the phones just dont power on.
> >
> > have looked at all POE related config and everything seems fine.
> >
> > Has anyone else experienced similar issues?
> >
> Have you set 'power inline auto' on the ports for the phones?


Yes I have.

The phones im connecting are Avaya 1608.

http://www.skccom.com/Resource_/Product_File/2138/1608factsheet.pdf

They support the IEEE 802.3af PoE standard, which afaik the 3750 also does


> 
> Regards,
> 
> Mike
> 
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.0.238 / Virus Database: 270.11.17/2007 - Release Date:
> 03/17/09 16:25:00

No virus found in this outgoing message.
Checked by AVG - www.avg.com 
Version: 8.0.238 / Virus Database: 270.11.17/2007 - Release Date: 03/17/09 16:25:00


From nasir.shaikh at bt.com  Wed Mar 18 02:49:29 2009
From: nasir.shaikh at bt.com (nasir.shaikh at bt.com)
Date: Wed, 18 Mar 2009 06:49:29 -0000
Subject: [c-nsp] Export routes from VRF to the global routing table
In-Reply-To: <9E07F8717FE8BC4FBAE6860F61EA6C1D7E0E9C@spsrvmail03.nec.br>
Message-ID: <2B0ABDF9E4A1204AA7467F200753545608FF44DE@E03MVZ4-UKDY.domain1.systemhost.net>

 Hi,
I am also looking for a way to a complete mutual redistribution between
2 vrfs. For political reasons I am not allowed to put all the interfaces
on the redistributing router in the same vrf.

Is there some way to do it?
If I mutually import/export the route-targets between both vrfs, would
that do the trick?
If yes, would I need anything else to make that work?

Thanks in advance


Nasir Shaikh 
This email contains information from BT Nederland N.V., which may be
privileged or confidential. 
It's meant only for the individual(s) or entity named above. If you are
not the intended recipient, note that disclosing, copying, distributing
or using this information is prohibited.  
If you have received this email in error, please let me know immediately
on the email address above.
We monitor our systems, and may record your emails.

BT Nederland N.V. 
Registered office:  Offices Minerva and Mercurius, Herikerbergweg 2,
1101 CM Amsterdam
Registered at the Amsterdam Chamber of Commerce no:  33296214



-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Leonardo Gama
Souza
Sent: 03 March 2009 14:12
To: Gustavo Rodrigues Ramos
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Export routes from VRF to the global routing table

Hi Gustavo,
 
Thanks for the feedback, but I would like to dynamically export the
routes, not using static routing. 
 
Regards.

 
________________________________

From: Gustavo Rodrigues Ramos [mailto:gustavo at nexthop.com.br]
Sent: Mon 3/2/2009 22:30
To: Leonardo Gama Souza
Cc: cisco-nsp
Subject: Re: [c-nsp] Export routes from VRF to the global routing table



Hello Leonardo, I guess you'll use route leaking to accomplish what you
want.

http://www.cisco.com/en/US/tech/tk436/tk832/technologies_configuration_e
xample09186a0080231a3e.shtml

Gustavo.



On Mon, Mar 2, 2009 at 10:08 PM, Leonardo Gama Souza
<leonardo.souza at nec.com.br> wrote:
> Hi list,
>
> I am almost confident this is not possible, but would like to confirm 
> whether exporting routes from some VRF to the global routing table is 
> possible or not.
> This would be a solution to overcome the constraints of using PBR+GRE 
> setup.
>
> 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 george at three6five.com  Wed Mar 18 02:19:00 2009
From: george at three6five.com (George Stylianou)
Date: Wed, 18 Mar 2009 08:19:00 +0200
Subject: [c-nsp] Cisco 3750G-24PS Issues with POE
In-Reply-To: <49C01E09.5080409@rollernet.us>
References: <99bc91e0903170427r6557b26ax11ed9a60e2aa9f01@mail.gmail.com>
	<17838240D9A5544AAA5FF95F8D52031605B421A5@ad-exh01.adhost.lan>
	<49C01E09.5080409@rollernet.us>
Message-ID: <99bc91e0903172319g413e10c7gd5e01cf63fec4157@mail.gmail.com>

sh power inline

Module   Available     Used     Remaining
          (Watts)     (Watts)    (Watts)
------   ---------   --------   ---------
1           370.0        0.0       370.0
Interface Admin  Oper       Power   Device              Class Max
                            (Watts)
--------- ------ ---------- ------- ------------------- ----- ----
Gi1/0/1   auto   off        0.0     n/a                 n/a   15.4
Gi1/0/2   auto   off        0.0     n/a                 n/a   15.4
Gi1/0/3   auto   off        0.0     n/a                 n/a   15.4
Gi1/0/4   auto   off        0.0     n/a                 n/a   15.4
Gi1/0/5   auto   off        0.0     n/a                 n/a   15.4
Gi1/0/6   auto   off        0.0     n/a                 n/a   15.4
Gi1/0/7   auto   off        0.0     n/a                 n/a   15.4
Gi1/0/8   auto   off        0.0     n/a                 n/a   15.4
Gi1/0/9   auto   off        0.0     n/a                 n/a   15.4
Gi1/0/10  auto   off        0.0     n/a                 n/a   15.4
Gi1/0/11  auto   off        0.0     n/a                 n/a   15.4
Gi1/0/12  auto   off        0.0     n/a                 n/a   15.4
Gi1/0/13  auto   off        0.0     n/a                 n/a   15.4
Gi1/0/14  auto   off        0.0     n/a                 n/a   15.4
Gi1/0/15  auto   off        0.0     n/a                 n/a   15.4
Gi1/0/16  auto   off        0.0     n/a                 n/a   15.4
Gi1/0/17  auto   off        0.0     n/a                 n/a   15.4
Gi1/0/18  auto   off        0.0     n/a                 n/a   15.4
Gi1/0/19  auto   off        0.0     n/a                 n/a   15.4
....
....


When I plug the handset (Avaya 1608) in on any port, nothing happens and
ports stays down/down


2009/3/18 Seth Mattinen <sethm at rollernet.us>

> Michael K. Smith - Adhost wrote:
> >
> >> -----Original Message-----
> >> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> >> bounces at puck.nether.net] On Behalf Of George Stylianou
> >> Sent: Tuesday, March 17, 2009 4:28 AM
> >> To: cisco-nsp at puck.nether.net
> >> Subject: [c-nsp] Cisco 3750G-24PS Issues with POE
> >>
> >> hi,
> >>
> >> I have 2 of these which are both on 12.2(35)SE5.
> >>
> >> We are connecting Avaya handsets to the ports and the switches are not
> >> pushing power to the phones. Have tried multiple phones and ports on
> >> both switches but the phones just dont power on.
> >>
> >> have looked at all POE related config and everything seems fine.
> >>
> >> Has anyone else experienced similar issues?
> >>
> > Have you set 'power inline auto' on the ports for the phones?
> >
>
> And do a 'show power inline' to verify availability. Example:
>
> Module   Available     Used     Remaining
>          (Watts)     (Watts)    (Watts)
> ------   ---------   --------   ---------
> 1           160.0       22.9       137.1
> Interface Admin  Oper       Power   Device              Class Max
>                            (Watts)
> --------- ------ ---------- ------- ------------------- ----- ----
> Fa1/0/1   off    off        0.0     n/a                 n/a   15.4
> Fa1/0/2   off    off        0.0     n/a                 n/a   15.4
> Fa1/0/3   off    off        0.0     n/a                 n/a   15.4
> Fa1/0/4   off    off        0.0     n/a                 n/a   15.4
> Fa1/0/5   off    off        0.0     n/a                 n/a   15.4
> Fa1/0/6   off    off        0.0     n/a                 n/a   15.4
> Fa1/0/7   off    off        0.0     n/a                 n/a   15.4
> Fa1/0/8   auto   on         4.5     Polycom SoundPoint  1     15.4
> Fa1/0/9   off    off        0.0     n/a                 n/a   15.4
> Fa1/0/10  off    off        0.0     n/a                 n/a   15.4
> Fa1/0/11  off    off        0.0     n/a                 n/a   15.4
> Fa1/0/12  off    off        0.0     n/a                 n/a   15.4
> Fa1/0/13  off    off        0.0     n/a                 n/a   15.4
> Fa1/0/14  off    off        0.0     n/a                 n/a   15.4
> Fa1/0/15  auto   on         4.5     Polycom SoundPoint  1     15.4
> Fa1/0/16  auto   on         15.4    Ieee PD             0     15.4
>
>
> ~Seth
>



-- 
George Stylianou
three6five network solutions
email: george at three6five.com
mobile: +27 (82) 903 5616
fax: +27 866 552 285

From andy.bierlair at root.lu  Wed Mar 18 03:16:33 2009
From: andy.bierlair at root.lu (Andy BIERLAIR)
Date: Wed, 18 Mar 2009 08:16:33 +0100
Subject: [c-nsp] Communities on local prefixes
Message-ID: <000001c9a799$77d718f0$67854ad0$@bierlair@root.lu>

Hi,

I would like to set a BGP community tag on local (non-customer) prefixes
before I send them to my peers and customers.

Right now I am doing this with a route-map when I configure the neighbor.

Somewhat like this:

router bgp 65001
...
neighbor 1.2.3.4 route-map TEST-OUT out 
...
network x.x.0.0 mask 255.255.0.0
...


route-map TEST-OUT permit 20
 match ip address prefix-list local-out
 set community 65001:9999

ip prefix-list local-out seq 5 permit x.x.0.0/16
ip prefix-list local-out seq 10 deny 0.0.0.0/0 le 32

This would tag my local prefixes with 65001:9999

While this is working, I don't find it to be the optimal solution. I want to
avoid setting communities on an outgoing route-map and I would like to have
my local prefixes tagged before they reach the "TEST-OUT" route-map.

In other words, when I do: sh ip bgp x.x.0.0 on the local router, I would
like to see this:

  Local
    0.0.0.0 from 0.0.0.0
      Origin IGP, metric 0, localpref 100, weight 32768, valid, sourced,
local, best
      Community: 65001:9999   <========

Is there a way to do so?

Thank you.

-
Andy



From anderson.levi at gmail.com  Wed Mar 18 01:02:44 2009
From: anderson.levi at gmail.com (Anderson Levi)
Date: Wed, 18 Mar 2009 08:02:44 +0300
Subject: [c-nsp] OSPF Areas
In-Reply-To: <70B7A1CCBFA5C649BD562B6D9F7ED784070EE7F5@xmb-ams-333.emea.cisco.com>
References: <b47b14a00903170908x62d1c11dj51c24bb8dc91c009@mail.gmail.com>
	<70B7A1CCBFA5C649BD562B6D9F7ED784070EE7F5@xmb-ams-333.emea.cisco.com>
Message-ID: <e22d607d0903172202v388c4026pdc330e6087e82db4@mail.gmail.com>

That resolved the issue. Thanks a lot.


On Tue, Mar 17, 2009 at 7:19 PM, Oliver Boehmer (oboehmer) <
oboehmer at cisco.com> wrote:

> Thermos Saamnet <> wrote on Tuesday, March 17, 2009 17:09:
>
> > Hi all,
> >
> > I'm having an issue setting up an OSPF border router using a VRF.
> > Here's the configuration:
> >
> >         router ospf 20 vrf clients
> >          network 10.0.0.0 0.0.0.3 area 0
> >          network 10.0.0.4 0.0.0.1 area 1
> >
> > It's pretty basic but strangely enough only routers in Area 0 see the
> > inter-area routes. Routers in Area 1 don't see the 10.0.0.0/30 (as
> > inter-area or otherwise). The adjancencies are all up and the routes
> > are present in the database but routers in Area 1 won't insert them
> > into the routing table.
> >
> > Anyone encountered this type of behaviour before?
> >
> > PS. We're using non-MPLS based VRFs.
>
> enable
>
> router ospf <id> vrf <foo>
>  capability vrf-lite
>
> on all VRF-lite OSPF speakers to disable the MPLS-VPN PE loop checks
> (down bit, domain-it/tag)..
>
>        oli
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From szilard.matyas at yahoo.com  Wed Mar 18 08:09:46 2009
From: szilard.matyas at yahoo.com (Szilard Matyas)
Date: Wed, 18 Mar 2009 05:09:46 -0700 (PDT)
Subject: [c-nsp] Routers SPF calculation time
Message-ID: <671566.2081.qm@web45713.mail.sp1.yahoo.com>

Dear Sirs, 


I would like to collect real-world average SPF calculation times in large OSPF or IS-IS areas. If someone work for a big SP please write it to me.
And please if someone answer  write also the number of routers and the number links that the area consists, and the type of the router that made the calculations in the area.

Thank you everyone in advance.

Regards, 

szicsu


      

From werner at trans.net  Wed Mar 18 08:37:28 2009
From: werner at trans.net (Werner Detter)
Date: Wed, 18 Mar 2009 13:37:28 +0100
Subject: [c-nsp] bgp_cpu2timeout and %LINK-4-NOMAC
Message-ID: <49C0EB08.8020604@trans.net>

Hi,

today I've upgraded the IOS-Software and the Boot-Image on a Lab-Router (7206VXR + NPE-G1)
to 12.4(23), since then i can see the following funny messages:

*Mar 18 11:35:04.091: bgp_cpu2timeout: seconds: 30000, slot: 3 for 5: 0% and 1: 0%
*Mar 18 11:35:34.875: bgp_cpu2timeout: seconds: 30000, slot: 3 for 5: 0% and 1: 0%

Anybody seen something like this before? These messages *only* appear with 12.4(23)

Another thing while booting this router (from the bootloader) - i don't know
why this message shows up. Any hints?

%LINK-4-NOMAC: A random default MAC address of 0000.0c82.a9fb has
  been chosen.  Ensure that this address is unique, or specify MAC
  addresses for commands (such as 'novell routing') that allow the
  use of this address as a default

thank you,
Werner


From savage at savage.za.org  Wed Mar 18 09:40:50 2009
From: savage at savage.za.org (Chris Knipe)
Date: Wed, 18 Mar 2009 15:40:50 +0200
Subject: [c-nsp] capacity planning
Message-ID: <20090318134050.GA25519@fusion.opticnetworks.net>

Hi,

Does anyone know of any (preferably free) tools that is any good in terms of
capacity planning for a enterprise?

We already have netflow in place and various other monitoring tools and there
is no doubt that we are running out of capacity (afaik, we already are), but
in the same breath we are also rapidly growing - now the question becomes how
much bandwidth, at what price, and why?

I'm sort of looking for something that I can make various models with, this
is the scenario with 100 employees, this is what happens when there's 200
employees, etc etc etc

Something as simlpe as a spreadsheet should be able to do this, but I haven't
been able to find anything up to now, so I thought I'd just ask and hopefully
not reinvent the wheel as they say.... 

Thanks allot, looking forward to any and all responces.

--
Chris.




From CB at nianet.dk  Wed Mar 18 09:58:13 2009
From: CB at nianet.dk (Christian Bering)
Date: Wed, 18 Mar 2009 14:58:13 +0100
Subject: [c-nsp] Communities on local prefixes
In-Reply-To: <000001c9a799$77d718f0$67854ad0$@bierlair@root.lu>
References: <000001c9a799$77d718f0$67854ad0$@bierlair@root.lu>
Message-ID: <D2A46EC72B5C2D4FAF017F2C8EA3E72AC50F9E@mail2.nianetas.local>

Hi,

>I would like to set a BGP community tag on local 
>(non-customer) prefixes before I send them to my 
>peers and customers.

Attach your route-map to your redistribution command(s), e.q:

router bgp 65001
 redistribute connected route-map REDIST-TO-BGP
 redistribute static route-map REDIST-TO-BGP
!

-- 
Regards
 Christian Bering

From michiel.kranenburg at concepts-ict.nl  Wed Mar 18 09:47:28 2009
From: michiel.kranenburg at concepts-ict.nl (Michiel Kranenburg)
Date: Wed, 18 Mar 2009 14:47:28 +0100
Subject: [c-nsp] Communities on local prefixes
In-Reply-To: <000001c9a799$77d718f0$67854ad0$@bierlair@root.lu>
References: <000001c9a799$77d718f0$67854ad0$@bierlair@root.lu>
Message-ID: <CC8C1EAE41520B4091A5C5FB6C929379300A58@conbrevs06.concepts.local>

Hi Andy,

Attach a route-map to your bgp network statement e.g. network x.x.0.0
mask 255.255.0.0 route-map TEST-OUT.

This will solve you issue.


Cheers,

Michiel

-----Oorspronkelijk bericht-----
Van: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] 
Verzonden: woensdag 18 maart 2009 8:17
Aan: cisco-nsp at puck.nether.net
Onderwerp: [c-nsp] Communities on local prefixes

Hi,

I would like to set a BGP community tag on local (non-customer) prefixes
before I send them to my peers and customers.

Right now I am doing this with a route-map when I configure the
neighbor.

Somewhat like this:

router bgp 65001
...
neighbor 1.2.3.4 route-map TEST-OUT out 
...
network x.x.0.0 mask 255.255.0.0
...


route-map TEST-OUT permit 20
 match ip address prefix-list local-out
 set community 65001:9999

ip prefix-list local-out seq 5 permit x.x.0.0/16
ip prefix-list local-out seq 10 deny 0.0.0.0/0 le 32

This would tag my local prefixes with 65001:9999

While this is working, I don't find it to be the optimal solution. I
want to
avoid setting communities on an outgoing route-map and I would like to
have
my local prefixes tagged before they reach the "TEST-OUT" route-map.

In other words, when I do: sh ip bgp x.x.0.0 on the local router, I
would
like to see this:

  Local
    0.0.0.0 from 0.0.0.0
      Origin IGP, metric 0, localpref 100, weight 32768, valid, sourced,
local, best
      Community: 65001:9999   <========

Is there a way to do so?

Thank you.

-
Andy


_______________________________________________
cisco-nsp mailing list  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  Wed Mar 18 10:33:21 2009
From: almog.purepeak at gmail.com (almog ohayon)
Date: Wed, 18 Mar 2009 16:33:21 +0200
Subject: [c-nsp] cisco AnyConnect - cisco 877
Message-ID: <3b53747c0903180733t25a35aa4mc3b44c40977e1965@mail.gmail.com>

Hi Everyone,Does anyone know if Cisco AnyConnect supported in cisco 877
router ??
I know that Cisco AnyConnect is supported in Cisco ASA.

This is my Details:
877 version: flash:c870-advipservicesk9-mz.124-24.T.bin

WebVpn Config :

webvpn gateway SSLVPNGW1
 ip address x.x.x.x port 443
 http-redirect port 80
 ssl trustpoint TP-self-signed-1899766392
 logging enable
 inservice
 !
webvpn context SSLVPN
 ssl authenticate verify all
 !

 !
 policy group policy_1
   functions svc-enabled
   hide-url-bar
   svc address-pool "Intranet"
   svc default-domain "test.com"
   svc keep-client-installed
   svc dpd-interval gateway 30
   svc rekey method new-tunnel
   svc dns-server primary 4.2.2.2
   svc wins-server primary 4.2.2.2
   citrix enabled
 default-group-policy policy_1
  gateway SSLVPNGW1
 max-users 10
 logging enable
 inservice
!

From petelists at templin.org  Wed Mar 18 11:27:07 2009
From: petelists at templin.org (Pete Templin)
Date: Wed, 18 Mar 2009 10:27:07 -0500
Subject: [c-nsp] BCP 38 on single-mode uRPF platforms?
Message-ID: <49C112CB.9020404@templin.org>

List,

I'm re-evaluating my BCP 38 strategy on my customer-facing Sup720-3BXL 
platforms, and would like to hear from the list on what you're doing in 
similar situations.  Since the uRPF logic on these platforms is limited 
to a global setting of 'reachable-via any' OR 'reachable-via rx', I'm 
starting to re-think the use of this tool.  Since it's also beneficial 
in source blackholing, I'm now leaning towards 'reachable-via any' on 
all Internet customer ports, with per-port (per-customer) ACLs to 
prevent spoofing.

Aside from having to maintain those per-port/per-customer ACLs and a 
risk to multi-homed customers if 'reachable-via rx' gets triggered 
accidentally, does anyone have other twists they'd like to suggest or 
other pitfalls they see?  Is there any way to globally lock the uRPF 
behavior to '...any' to avoid surprises?

Thanks,

Pete

From hegedus.gabor at euroway.hu  Wed Mar 18 12:05:01 2009
From: hegedus.gabor at euroway.hu (Hegedus Gabor)
Date: Wed, 18 Mar 2009 17:05:01 +0100
Subject: [c-nsp] centralized mac filtering
In-Reply-To: <49C0BD2B.8040809@euroway.hu>
References: <49C0BD2B.8040809@euroway.hu>
Message-ID: <49C11BAD.1080507@euroway.hu>

Hegedus Gabor wrote:
> Hi all,
>
> Is any solution to filtering wifi mac addresses from one database, if 
> i have more devices and one wireless domain with one  ssid?
>
> thank you!
> br
>
> Gabor
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
I forgot to tell i want to use wpa security.
mac filter(based on one db) and WPA security at the same time, is there 
any solution?.




From luan at netcraftsmen.net  Wed Mar 18 12:05:12 2009
From: luan at netcraftsmen.net (Luan Nguyen)
Date: Wed, 18 Mar 2009 12:05:12 -0400
Subject: [c-nsp] cisco AnyConnect - cisco 877
In-Reply-To: <3b53747c0903180733t25a35aa4mc3b44c40977e1965@mail.gmail.com>
References: <3b53747c0903180733t25a35aa4mc3b44c40977e1965@mail.gmail.com>
Message-ID: <03f501c9a7e3$51e66c00$f5b34400$@net>

There's a configuration guide here:
http://www.cisco.com/en/US/products/ps6496/products_configuration_example091
86a0080720346.shtml
According to, 877 should be supported.

Regards,

----------------------------------------------------------------------------
---------
Luan Nguyen
Chesapeake NetCraftsmen, LLC
[Web] http://www.netcraftsmen.net
------------------------------------------------------------------------


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of almog ohayon
Sent: Wednesday, March 18, 2009 10:33 AM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] cisco AnyConnect - cisco 877

Hi Everyone,Does anyone know if Cisco AnyConnect supported in cisco 877
router ??
I know that Cisco AnyConnect is supported in Cisco ASA.

This is my Details:
877 version: flash:c870-advipservicesk9-mz.124-24.T.bin

WebVpn Config :

webvpn gateway SSLVPNGW1
 ip address x.x.x.x port 443
 http-redirect port 80
 ssl trustpoint TP-self-signed-1899766392
 logging enable
 inservice
 !
webvpn context SSLVPN
 ssl authenticate verify all
 !

 !
 policy group policy_1
   functions svc-enabled
   hide-url-bar
   svc address-pool "Intranet"
   svc default-domain "test.com"
   svc keep-client-installed
   svc dpd-interval gateway 30
   svc rekey method new-tunnel
   svc dns-server primary 4.2.2.2
   svc wins-server primary 4.2.2.2
   citrix enabled
 default-group-policy policy_1
  gateway SSLVPNGW1
 max-users 10
 logging enable
 inservice
!
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


From dmitry at dmitry.net  Wed Mar 18 12:08:54 2009
From: dmitry at dmitry.net (Dmitry Kiselev)
Date: Wed, 18 Mar 2009 18:08:54 +0200
Subject: [c-nsp] TCAM at Cat4500 Sup6E
Message-ID: <20090318160854.GH27954@f17.dmitry.net>

Hello!

Could anybody clear me with TCAM on Cat4500 Sup6E?
Or Cat4900M as it is Sup6E based.

There are 64 TCAM blocks. Each of them can be DYNAMICALY
configured as 80 or 160-bit with 4096 and 2048 entries
accordingly.  IPv4 and IPv6 FIBs are builded DYNAMICALY
using one or more TCAM blocks. Additional TCAM blocks
are configured to apropriate bit-size and used if new FIB
entry is learned and all previously allocated TCAM already
used.  There are no stuff like "mls cef maximum-routes" or
"sdm template" to preconfigure TCAM allocations.

Am I right?

How about optimizing TCAM blocks usage while freeing FIB
entries?   Any other TCAM related caveats?

-- 
Dmitry Kiselev

From charles at thewybles.com  Wed Mar 18 12:46:37 2009
From: charles at thewybles.com (Charles Wyble)
Date: Wed, 18 Mar 2009 09:46:37 -0700
Subject: [c-nsp] centralized mac filtering
In-Reply-To: <49C11BAD.1080507@euroway.hu>
References: <49C0BD2B.8040809@euroway.hu> <49C11BAD.1080507@euroway.hu>
Message-ID: <49C1256D.4030306@thewybles.com>



Hegedus Gabor wrote:
> Hegedus Gabor wrote:
>> Hi all,
>>
>> Is any solution to filtering wifi mac addresses from one database, if 
>> i have more devices and one wireless domain with one  ssid?
>>
>> thank you!
>> br
>>
>> Gabor

I think this would be something that RADIUS is good for. You need to 
look at your provisioning process. Create a new user -> add a db record 
-> have AP auth to the RADIUS DB.


From sethm at rollernet.us  Wed Mar 18 13:59:47 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Wed, 18 Mar 2009 10:59:47 -0700
Subject: [c-nsp] Cisco 3750G-24PS Issues with POE
In-Reply-To: <99bc91e0903172319g413e10c7gd5e01cf63fec4157@mail.gmail.com>
References: <99bc91e0903170427r6557b26ax11ed9a60e2aa9f01@mail.gmail.com>	
	<17838240D9A5544AAA5FF95F8D52031605B421A5@ad-exh01.adhost.lan>	
	<49C01E09.5080409@rollernet.us>
	<99bc91e0903172319g413e10c7gd5e01cf63fec4157@mail.gmail.com>
Message-ID: <49C13693.2000405@rollernet.us>

George Stylianou wrote:
> 
> sh power inline
> 
> Module   Available     Used     Remaining
>           (Watts)     (Watts)    (Watts)
> ------   ---------   --------   ---------
> 1           370.0        0.0       370.0
> Interface Admin  Oper       Power   Device              Class Max
>                             (Watts)                           
> --------- ------ ---------- ------- ------------------- ----- ----
> Gi1/0/1   auto   off        0.0     n/a                 n/a   15.4
> Gi1/0/2   auto   off        0.0     n/a                 n/a   15.4
> Gi1/0/3   auto   off        0.0     n/a                 n/a   15.4
> Gi1/0/4   auto   off        0.0     n/a                 n/a   15.4
> Gi1/0/5   auto   off        0.0     n/a                 n/a   15.4
> Gi1/0/6   auto   off        0.0     n/a                 n/a   15.4
> Gi1/0/7   auto   off        0.0     n/a                 n/a   15.4
> Gi1/0/8   auto   off        0.0     n/a                 n/a   15.4
> Gi1/0/9   auto   off        0.0     n/a                 n/a   15.4
> Gi1/0/10  auto   off        0.0     n/a                 n/a   15.4
> Gi1/0/11  auto   off        0.0     n/a                 n/a   15.4
> Gi1/0/12  auto   off        0.0     n/a                 n/a   15.4
> Gi1/0/13  auto   off        0.0     n/a                 n/a   15.4
> Gi1/0/14  auto   off        0.0     n/a                 n/a   15.4
> Gi1/0/15  auto   off        0.0     n/a                 n/a   15.4
> Gi1/0/16  auto   off        0.0     n/a                 n/a   15.4
> Gi1/0/17  auto   off        0.0     n/a                 n/a   15.4
> Gi1/0/18  auto   off        0.0     n/a                 n/a   15.4
> Gi1/0/19  auto   off        0.0     n/a                 n/a   15.4
> ....
> ....
> 
> 
> When I plug the handset (Avaya 1608) in on any port, nothing happens and
> ports stays down/down
> 

Huh, that's weird. Are you plugging the phone directly into the switch
or is there wiring (patch panels, in-wall wiring, etc.) between the
switch and the phone? It seems like it's just not detecting that there's
a POE device on the other end.

~Seth

From george at three6five.com  Wed Mar 18 14:15:57 2009
From: george at three6five.com (George Stylianou)
Date: Wed, 18 Mar 2009 20:15:57 +0200
Subject: [c-nsp] Cisco 3750G-24PS Issues with POE
In-Reply-To: <49C13693.2000405@rollernet.us>
References: <99bc91e0903170427r6557b26ax11ed9a60e2aa9f01@mail.gmail.com>
	<17838240D9A5544AAA5FF95F8D52031605B421A5@ad-exh01.adhost.lan>
	<49C01E09.5080409@rollernet.us>
	<99bc91e0903172319g413e10c7gd5e01cf63fec4157@mail.gmail.com>
	<49C13693.2000405@rollernet.us>
Message-ID: <99bc91e0903181115m195a5225s899c4915fabf7c20@mail.gmail.com>

>
>
> Huh, that's weird. Are you plugging the phone directly into the switch
> or is there wiring (patch panels, in-wall wiring, etc.) between the
> switch and the phone? It seems like it's just not detecting that there's
> a POE device on the other end.
>

very weird...

phones are plugging directly in - tried various working patch leads as well.

I'm stuck on this one, think I need to try find a Cisco IP phone to test
with and see what happens with that


>
> ~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/
>



-- 
George Stylianou
three6five network solutions
email: george at three6five.com
mobile: +27 (82) 903 5616
fax: +27 866 552 285

From braaen at zcorum.com  Wed Mar 18 14:24:50 2009
From: braaen at zcorum.com (Brian Raaen)
Date: Wed, 18 Mar 2009 14:24:50 -0400
Subject: [c-nsp] PPPoA Sessions MRTG
In-Reply-To: <BLU102-W54B52EAAC0A44B530D2800FA980@phx.gbl>
References: <BLU102-W54B52EAAC0A44B530D2800FA980@phx.gbl>
Message-ID: <49C13C72.3050609@zcorum.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

We are also trying to find similar information and can not.  I believe
the engineer working on this is writing a script that gets the total ppp
sessions and then subtracts the amount of PPPoE sessions to get the
amount of PPPoA sessions.

- --
- -----------------
Brian Raaen
Network Engineer
email: braaen at zcorum.com

Mohammad Khalil wrote:
>
>
> Hey all ,
> im using MRTG for monitoring our network devices traffic.
> i faced a problem of how to draw PPPoA sessions as it dont have an OID
like PPPoE
> we have a router with 2 PPP customers : PPPoA and PPPoE
> the OID for the PPPoE sessions can be found easily :
1.3.6.1.4.1.9.9.194.1.1.1
> to find the number of PPPoA sessions , we used  CISCO-AAA-SESSION-MIB
casnActiveTableEntries "1.3.6.1.4.1.9.9.150.1.1.1"
> but that will give all the active sessions on the router , when i used
the snmpwalk command on a linux server it gave me over 6000 , while its
on the router via show user summary command , gives around 1800
> so the needed configuration was as below:
> create on-demand command under the PVC range , under the ATM sub
interface (This will reserve the active connections only)
> interface ATM1/0/0.11 multipoint
>  range pvc 11/35 11/274
>   create on-demand
> 
> as well as , applying the command aaa session-mib populate start in
global configuration mode
> 
> after all , show user summary output:
> Device#sh users summary
> 1766 session(s) locally terminated
>     PPPOA           1007
>     PPPOE           759
> 
> [root at cacti-nms ~]# snmpwalk -v2c -c community IP
.1.3.6.1.4.1.9.9.150.1.1.1
> SNMPv2-SMI::enterprises.9.9.150.1.1.1.0 = Gauge32: 1766
> 
> Then to draw the PPPoA sessions , u have to substract the PPPoE
sessions as the OID gives the total number of sessions:
> Target[Device_PPPoA]:1.3.6.1.4.1.9.9.150.1.1.1.0&1.3.6.1.4.1.9.9.150.1.1.1.0:community at IP
- 1.3.6.1.4.1.9.9.194.1.1.1.0&1.3.6.1.4.1.9.9.194.1.1.1.0:community at IP
> 
> Thanks all
> 
> Best Regards,
> Mohammad Khalil
>
> 
> 
>
>
>
>
>
> What can you do with the new Windows Live? Find out
>
>
> See all the ways you can stay connected to friends and family
> Get news, entertainment and everything you care about at Live.com.
Check it out!
> _________________________________________________________________
> Drag n? drop?Get easy photo sharing with Windows Live? Photos.
>
> http://www.microsoft.com/windows/windowslive/products/photos.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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknBPHEACgkQ+KYcND7GxdmA5ACcDsEp13SYW7+D4BNJFaGrSzbC
HnIAn0yjqRj46VMLQ/awgDTPL5d1gf6X
=jepZ
-----END PGP SIGNATURE-----


From lmeade at signal.ca  Wed Mar 18 14:45:33 2009
From: lmeade at signal.ca (Leslie Meade)
Date: Wed, 18 Mar 2009 11:45:33 -0700
Subject: [c-nsp] CCM7 Mobilty Access Dial peer question
In-Reply-To: <2B0ABDF9E4A1204AA7467F200753545608FF4460@E03MVZ4-UKDY.domain1.systemhost.net>
References: <2B0ABDF9E4A1204AA7467F200753545608FF4460@E03MVZ4-UKDY.domain1.systemhost.net>
Message-ID: <EAF4FF4AB2142D499F2F5A3B9D851529045DB632@exch-bo.MGVFS.McLeanNet>

I am trying out the mobile voice access on ccm7 and run into an issue

I have two dial peers, when I call the 2103 from my network I get into the ivr, but when I dial the whole number XXX XXXX 2103 I get the reception 

dial-peer voice 1 pots
 description ***Main Line***
 translation-profile incoming MainLine
 incoming called-number .
 direct-inward-dial
 port 0/3/0:23

dial-peer voice 2103 voip
 description ***Mobility Voice Access***
 service cmm
 session target ipv4:172.16.1.20
 incoming called-number 2103
 codec g711ulaw

I have debugged the dial peer and it is not showing a match, but when I do it from the network I get a match. Any ideas ?

2811BCH01#
075954: Mar 18 11:38:22.305 PST: //-1/xxxxxxxxxxxx/DPM/dpAssociateIncomingPeerCore:
   Calling Number=XXXXXX5000, Called Number=2103, Voice-Interface=0x48730F34,
   Timeout=TRUE, Peer Encap Type=ENCAP_VOICE, Peer Search Type=PEER_TYPE_VOICE,
   Peer Info Type=DIALPEER_INFO_SPEECH
075955: Mar 18 11:38:22.305 PST: //-1/xxxxxxxxxxxx/DPM/dpAssociateIncomingPeerCore:
   Result=Success(0) after DP_MATCH_INCOMING_DNIS; Incoming Dial-peer=1
075956: Mar 18 11:38:22.305 PST: //-1/xxxxxxxxxxxx/DPM/dpAssociateIncomingPeerCore:
   Calling Number= XXXXXX5000, Called Number=2103, Voice-Interface=0x0,
   Timeout=TRUE, Peer Encap Type=ENCAP_VOICE, Peer Search Type=PEER_TYPE_VOICE,
   Peer Info Type=DIALPEER_INFO_FAX
075957: Mar 18 11:38:22.305 PST: //-1/xxxxxxxxxxxx/DPM/dpAssociateIncomingPeerCore:
   Result=NO_MATCH(-1) After All Match Rules Attempt
075958: Mar 18 11:38:22.309 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   Calling Number=, Called Number=1700, Peer Info Type=DIALPEER_INFO_SPEECH
075959: Mar 18 11:38:22.309 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   Match Rule=DP_MATCH_DEST; Called Number=1700
075960: Mar 18 11:38:22.309 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   Result=Success(0) after DP_MATCH_DEST
075961: Mar 18 11:38:22.309 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeers:
   Result=SUCCESS(0) 
   List of Matched Outgoing Dial-peer(s): 
     1: Dial-peer Tag=20012
075962: Mar 18 11:38:22.321 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   Calling Number=1700, Called Number=1700, Peer Info Type=DIALPEER_INFO_SPEECH
075963: Mar 18 11:38:22.321 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   Match Rule=DP_MATCH_DEST; Called Number=1700
075964: Mar 18 11:38:22.321 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   Result=Success(0) after DP_MATCH_DEST
075965: Mar 18 11:38:22.321 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersMoreArg:
   Result=SUCCESS(0) 
   List of Matched Outgoing Dial-peer(s): 
     1: Dial-peer Tag=20012
075966: Mar 18 11:38:22.321 PST: //-1/xxxxxxxxxxxx/DPM/dpAssociateIncomingPeerCore:
   Calling Number=1700, Called Number=, Voice-Interface=0x0,
   Timeout=TRUE, Peer Encap Type=ENCAP_VOIP, Peer Search Type=PEER_TYPE_VOICE,
   Peer Info Type=DIALPEER_INFO_SPEECH
075967: Mar 18 11:38:22.321 PST: //-1/xxxxxxxxxxxx/DPM/dpAssociateIncomingPeerCore:
   Result=NO_MATCH(-1) After All Match Rules Attempt
075968: Mar 18 11:38:22.325 PST: //-1/CAFC6FBC9F94/DPM/dpMatchPeersCore:
   Calling Number=, Called Number=1700, Peer Info Type=DIALPEER_INFO_SPEECH
075969: Mar 18 11:38:22.325 PST: //-1/CAFC6FBC9F94/DPM/dpMatchPeersCore:
   Match Rule=DP_MATCH_DEST; Called Number=1700
075970: Mar 18 11:38:22.325 PST: //-1/CAFC6FBC9F94/DPM/dpMatchPeersCore:
   Result=Success(0) after DP_MATCH_DEST
075971: Mar 18 11:38:22.325 PST: //-1/CAFC6FBC9F94/DPM/dpMatchPeersMoreArg:
   Result=SUCCESS(0) 
   List of Matched Outgoing Dial-peer(s): 
     1: Dial-peer Tag=20012
075972: Mar 18 11:38:22.333 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   Calling Number=, Called Number=XXXXXX5000, Peer Info Type=DIALPEER_INFO_SPEECH
075973: Mar 18 11:38:22.333 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   Match Rule=DP_MATCH_DEST; Called Number=XXXXXX5000
075974: Mar 18 11:38:22.333 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   No Outgoing Dial-peer Is Matched; Result=NO_MATCH(-1)
075975: Mar 18 11:38:22.333 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersMoreArg:
   Result=NO_MATCH(-1)
075976: Mar 18 11:38:22.361 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   Calling Number=, Called Number=XXXXXX5000, Peer Info Type=DIALPEER_INFO_SPEECH
075977: Mar 18 11:38:22.361 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   Match Rule=DP_MATCH_DEST; Called Number=XXXXXX5000
075978: Mar 18 11:38:22.361 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   No Outgoing Dial-peer Is Matched; Result=NO_MATCH(-1)
075979: Mar 18 11:38:22.361 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeers:
   Result=NO_MATCH(-1)
075980: Mar 18 11:38:22.361 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   Calling Number=, Called Number=1700, Peer Info Type=DIALPEER_INFO_SPEECH
075981: Mar 18 11:38:22.361 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   Match Rule=DP_MATCH_DEST; Called Number=1700
075982: Mar 18 11:38:22.365 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   Result=Success(0) after DP_MATCH_DEST
075983: Mar 18 11:38:22.365 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeers:
   Result=SUCCESS(0) 
   List of Matched Outgoing Dial-peer(s):
2811BCH01# 
     1: Dial-peer Tag=20012
2811BCH01#
075984: Mar 18 11:38:24.737 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   Calling Number=, Called Number=XXXXXX5000, Peer Info Type=DIALPEER_INFO_SPEECH
075985: Mar 18 11:38:24.737 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   Match Rule=DP_MATCH_DEST; Called Number=XXXXXX5000
075986: Mar 18 11:38:24.737 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   No Outgoing Dial-peer Is Matched; Result=NO_MATCH(-1)
075987: Mar 18 11:38:24.737 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeers:
   Result=NO_MATCH(-1)
075988: Mar 18 11:38:24.737 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   Calling Number=, Called Number=1700, Peer Info Type=DIALPEER_INFO_SPEECH
075989: Mar 18 11:38:24.737 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   Match Rule=DP_MATCH_DEST; Called Number=1700
075990: Mar 18 11:38:24.737 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   Result=Success(0) after DP_MATCH_DEST
075991: Mar 18 11:38:24.737 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeers:
   Result=SUCCESS(0) 
   List of Matched Outgoing Dial-peer(s): 
     1: Dial-peer Tag=20012
075992: Mar 18 11:38:24.741 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   Calling Number=, Called Number=1700, Peer Info Type=DIALPEER_INFO_SPEECH
075993: Mar 18 11:38:24.741 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   Match Rule=DP_MATCH_DEST; Called Number=1700
075994: Mar 18 11:38:24.741 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   Result=Success(0) after DP_MATCH_DEST
075995: Mar 18 11:38:24.741 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeers:
   Result=SUCCESS(0) 
   List of Matched Outgoing Dial-peer(s): 
     1: Dial-peer Tag=20012
075996: Mar 18 11:38:24.741 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   Calling Number=, Called Number=XXXXXX5000, Peer Info Type=DIALPEER_INFO_SPEECH
075997: Mar 18 11:38:24.741 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   Match Rule=DP_MATCH_DEST; Called Number=XXXXXX5000
075998: Mar 18 11:38:24.741 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   No Outgoing Dial-peer Is Matched; Result=NO_MATCH(-1)
075999: Mar 18 11:38:24.741 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeers:
   Result=NO_MATCH(-1)
2811BCH01#
076000: Mar 18 11:38:24.797 PST: %ISDN-6-CONNECT: Interface Serial0/3/0:4 is now connected to XXXXXX5000 N/A
2811BCH01#
076001: Mar 18 11:38:30.797 PST: %ISDN-6-CONNECT: Interface Serial0/3/0:4 is now connected to XXXXXX5000 N/A
2811BCH01#
076002: Mar 18 11:38:33.753 PST: %ISDN-6-DISCONNECT: Interface Serial0/3/0:4  disconnected from XXXXXX5000 , call lasted 8 seconds
2811BCH01#

Cheers

Leslie


From lmeade at signal.ca  Wed Mar 18 14:48:57 2009
From: lmeade at signal.ca (Leslie Meade)
Date: Wed, 18 Mar 2009 11:48:57 -0700
Subject: [c-nsp] CCM7 Mobilty Access Dial peer question
In-Reply-To: <EAF4FF4AB2142D499F2F5A3B9D851529045DB632@exch-bo.MGVFS.McLeanNet>
References: <2B0ABDF9E4A1204AA7467F200753545608FF4460@E03MVZ4-UKDY.domain1.systemhost.net>
	<EAF4FF4AB2142D499F2F5A3B9D851529045DB632@exch-bo.MGVFS.McLeanNet>
Message-ID: <EAF4FF4AB2142D499F2F5A3B9D851529045DB637@exch-bo.MGVFS.McLeanNet>

Opss wrong group :)


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Leslie Meade
Sent: Wednesday, March 18, 2009 11:46 AM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] CCM7 Mobilty Access Dial peer question

I am trying out the mobile voice access on ccm7 and run into an issue

I have two dial peers, when I call the 2103 from my network I get into the ivr, but when I dial the whole number XXX XXXX 2103 I get the reception 

dial-peer voice 1 pots
 description ***Main Line***
 translation-profile incoming MainLine
 incoming called-number .
 direct-inward-dial
 port 0/3/0:23

dial-peer voice 2103 voip
 description ***Mobility Voice Access***
 service cmm
 session target ipv4:172.16.1.20
 incoming called-number 2103
 codec g711ulaw

I have debugged the dial peer and it is not showing a match, but when I do it from the network I get a match. Any ideas ?

2811BCH01#
075954: Mar 18 11:38:22.305 PST: //-1/xxxxxxxxxxxx/DPM/dpAssociateIncomingPeerCore:
   Calling Number=XXXXXX5000, Called Number=2103, Voice-Interface=0x48730F34,
   Timeout=TRUE, Peer Encap Type=ENCAP_VOICE, Peer Search Type=PEER_TYPE_VOICE,
   Peer Info Type=DIALPEER_INFO_SPEECH
075955: Mar 18 11:38:22.305 PST: //-1/xxxxxxxxxxxx/DPM/dpAssociateIncomingPeerCore:
   Result=Success(0) after DP_MATCH_INCOMING_DNIS; Incoming Dial-peer=1
075956: Mar 18 11:38:22.305 PST: //-1/xxxxxxxxxxxx/DPM/dpAssociateIncomingPeerCore:
   Calling Number= XXXXXX5000, Called Number=2103, Voice-Interface=0x0,
   Timeout=TRUE, Peer Encap Type=ENCAP_VOICE, Peer Search Type=PEER_TYPE_VOICE,
   Peer Info Type=DIALPEER_INFO_FAX
075957: Mar 18 11:38:22.305 PST: //-1/xxxxxxxxxxxx/DPM/dpAssociateIncomingPeerCore:
   Result=NO_MATCH(-1) After All Match Rules Attempt
075958: Mar 18 11:38:22.309 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   Calling Number=, Called Number=1700, Peer Info Type=DIALPEER_INFO_SPEECH
075959: Mar 18 11:38:22.309 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   Match Rule=DP_MATCH_DEST; Called Number=1700
075960: Mar 18 11:38:22.309 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   Result=Success(0) after DP_MATCH_DEST
075961: Mar 18 11:38:22.309 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeers:
   Result=SUCCESS(0) 
   List of Matched Outgoing Dial-peer(s): 
     1: Dial-peer Tag=20012
075962: Mar 18 11:38:22.321 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   Calling Number=1700, Called Number=1700, Peer Info Type=DIALPEER_INFO_SPEECH
075963: Mar 18 11:38:22.321 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   Match Rule=DP_MATCH_DEST; Called Number=1700
075964: Mar 18 11:38:22.321 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   Result=Success(0) after DP_MATCH_DEST
075965: Mar 18 11:38:22.321 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersMoreArg:
   Result=SUCCESS(0) 
   List of Matched Outgoing Dial-peer(s): 
     1: Dial-peer Tag=20012
075966: Mar 18 11:38:22.321 PST: //-1/xxxxxxxxxxxx/DPM/dpAssociateIncomingPeerCore:
   Calling Number=1700, Called Number=, Voice-Interface=0x0,
   Timeout=TRUE, Peer Encap Type=ENCAP_VOIP, Peer Search Type=PEER_TYPE_VOICE,
   Peer Info Type=DIALPEER_INFO_SPEECH
075967: Mar 18 11:38:22.321 PST: //-1/xxxxxxxxxxxx/DPM/dpAssociateIncomingPeerCore:
   Result=NO_MATCH(-1) After All Match Rules Attempt
075968: Mar 18 11:38:22.325 PST: //-1/CAFC6FBC9F94/DPM/dpMatchPeersCore:
   Calling Number=, Called Number=1700, Peer Info Type=DIALPEER_INFO_SPEECH
075969: Mar 18 11:38:22.325 PST: //-1/CAFC6FBC9F94/DPM/dpMatchPeersCore:
   Match Rule=DP_MATCH_DEST; Called Number=1700
075970: Mar 18 11:38:22.325 PST: //-1/CAFC6FBC9F94/DPM/dpMatchPeersCore:
   Result=Success(0) after DP_MATCH_DEST
075971: Mar 18 11:38:22.325 PST: //-1/CAFC6FBC9F94/DPM/dpMatchPeersMoreArg:
   Result=SUCCESS(0) 
   List of Matched Outgoing Dial-peer(s): 
     1: Dial-peer Tag=20012
075972: Mar 18 11:38:22.333 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   Calling Number=, Called Number=XXXXXX5000, Peer Info Type=DIALPEER_INFO_SPEECH
075973: Mar 18 11:38:22.333 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   Match Rule=DP_MATCH_DEST; Called Number=XXXXXX5000
075974: Mar 18 11:38:22.333 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   No Outgoing Dial-peer Is Matched; Result=NO_MATCH(-1)
075975: Mar 18 11:38:22.333 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersMoreArg:
   Result=NO_MATCH(-1)
075976: Mar 18 11:38:22.361 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   Calling Number=, Called Number=XXXXXX5000, Peer Info Type=DIALPEER_INFO_SPEECH
075977: Mar 18 11:38:22.361 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   Match Rule=DP_MATCH_DEST; Called Number=XXXXXX5000
075978: Mar 18 11:38:22.361 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   No Outgoing Dial-peer Is Matched; Result=NO_MATCH(-1)
075979: Mar 18 11:38:22.361 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeers:
   Result=NO_MATCH(-1)
075980: Mar 18 11:38:22.361 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   Calling Number=, Called Number=1700, Peer Info Type=DIALPEER_INFO_SPEECH
075981: Mar 18 11:38:22.361 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   Match Rule=DP_MATCH_DEST; Called Number=1700
075982: Mar 18 11:38:22.365 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   Result=Success(0) after DP_MATCH_DEST
075983: Mar 18 11:38:22.365 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeers:
   Result=SUCCESS(0) 
   List of Matched Outgoing Dial-peer(s):
2811BCH01# 
     1: Dial-peer Tag=20012
2811BCH01#
075984: Mar 18 11:38:24.737 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   Calling Number=, Called Number=XXXXXX5000, Peer Info Type=DIALPEER_INFO_SPEECH
075985: Mar 18 11:38:24.737 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   Match Rule=DP_MATCH_DEST; Called Number=XXXXXX5000
075986: Mar 18 11:38:24.737 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   No Outgoing Dial-peer Is Matched; Result=NO_MATCH(-1)
075987: Mar 18 11:38:24.737 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeers:
   Result=NO_MATCH(-1)
075988: Mar 18 11:38:24.737 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   Calling Number=, Called Number=1700, Peer Info Type=DIALPEER_INFO_SPEECH
075989: Mar 18 11:38:24.737 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   Match Rule=DP_MATCH_DEST; Called Number=1700
075990: Mar 18 11:38:24.737 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   Result=Success(0) after DP_MATCH_DEST
075991: Mar 18 11:38:24.737 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeers:
   Result=SUCCESS(0) 
   List of Matched Outgoing Dial-peer(s): 
     1: Dial-peer Tag=20012
075992: Mar 18 11:38:24.741 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   Calling Number=, Called Number=1700, Peer Info Type=DIALPEER_INFO_SPEECH
075993: Mar 18 11:38:24.741 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   Match Rule=DP_MATCH_DEST; Called Number=1700
075994: Mar 18 11:38:24.741 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   Result=Success(0) after DP_MATCH_DEST
075995: Mar 18 11:38:24.741 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeers:
   Result=SUCCESS(0) 
   List of Matched Outgoing Dial-peer(s): 
     1: Dial-peer Tag=20012
075996: Mar 18 11:38:24.741 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   Calling Number=, Called Number=XXXXXX5000, Peer Info Type=DIALPEER_INFO_SPEECH
075997: Mar 18 11:38:24.741 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   Match Rule=DP_MATCH_DEST; Called Number=XXXXXX5000
075998: Mar 18 11:38:24.741 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersCore:
   No Outgoing Dial-peer Is Matched; Result=NO_MATCH(-1)
075999: Mar 18 11:38:24.741 PST: //-1/xxxxxxxxxxxx/DPM/dpMatchPeers:
   Result=NO_MATCH(-1)
2811BCH01#
076000: Mar 18 11:38:24.797 PST: %ISDN-6-CONNECT: Interface Serial0/3/0:4 is now connected to XXXXXX5000 N/A
2811BCH01#
076001: Mar 18 11:38:30.797 PST: %ISDN-6-CONNECT: Interface Serial0/3/0:4 is now connected to XXXXXX5000 N/A
2811BCH01#
076002: Mar 18 11:38:33.753 PST: %ISDN-6-DISCONNECT: Interface Serial0/3/0:4  disconnected from XXXXXX5000 , call lasted 8 seconds
2811BCH01#

Cheers

Leslie

_______________________________________________
cisco-nsp mailing list  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  Wed Mar 18 14:57:42 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Wed, 18 Mar 2009 11:57:42 -0700
Subject: [c-nsp] centralized mac filtering
In-Reply-To: <49C0BD2B.8040809@euroway.hu>
References: <49C0BD2B.8040809@euroway.hu>
Message-ID: <49C14426.7080405@rollernet.us>

Hegedus Gabor wrote:
> Hi all,
> 
> Is any solution to filtering wifi mac addresses from one database, if i
> have more devices and one wireless domain with one  ssid?
> 

I've done this in the past with great success using FreeRADIUS, MySQL,
and HP AP420 access points. It's actually quite simple; the AP sent a
request with the MAC and you can allow/deny it.

~Seth

From gaborivanszky at gmail.com  Wed Mar 18 14:58:58 2009
From: gaborivanszky at gmail.com (Gabor Ivanszky)
Date: Wed, 18 Mar 2009 19:58:58 +0100
Subject: [c-nsp] L2TPv3 "LNS mode"
In-Reply-To: <10f693fd0903181057u631316cdgb3a58746183c1033@mail.gmail.com>
References: <10f693fd0903181057u631316cdgb3a58746183c1033@mail.gmail.com>
Message-ID: <10f693fd0903181158x763e38c6o9b85fc5afbf4f7f@mail.gmail.com>

Hello,

is there any possibility to route(L3 process) Ethernet encapsulated IP
packets arriving at a Cisco router in a L2TPv3 tunnel?

In other words, is it possible to configure a Cisco box in LNS role in
an Ethernet L2TPv3 setup?

" L2TP Network Server (LNS)

? ? ?If a given L2TP session is terminated at the L2TP node and the
? ? ?encapsulated network layer (L3) packet processed on a virtual
? ? ?interface, we refer to this L2TP node as an L2TP Network Server" (RFC3931)

Actually i'd like to implement ?"(a) LAC-LNS Reference Model:

On one side, the LAC receives traffic
? from an L2 circuit, which it forwards via L2TP across an IP or other
? packet-based network. ?On the other side, an LNS logically terminates
? the L2 circuit locally and routes network traffic to the home
? network. ?The action of session establishment is driven by the LAC
? (as an incoming call) or the LNS (as an outgoing call).

? ?+-----+ ?L2 ?+-----+ ? ? ? ? ? ? ? ? ? ? ? ?+-----+
? ?| ? ? |------| LAC |.........[ IP ].........| LNS |...[home network]
? ?+-----+ ? ? ?+-----+ ? ? ? ? ? ? ? ? ? ? ? ?+-----+
? ?remote
? ?system
? ? ? ? ? ? ? ? ? ? ? |<-- emulated service -->|
? ? ? ? ?|<----------- L2 service ------------>| "(RFC3931)

Practically an Ethernet interface with an xconnect setting on "LAC"
side, and something like an IP tunnel interface on the "LNS" side.

The obvious

interface Tunnel1
?tunnel mode l2tpv3

doesn't exist.


cheers,
Gabor

From sethm at rollernet.us  Wed Mar 18 14:44:48 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Wed, 18 Mar 2009 11:44:48 -0700
Subject: [c-nsp] Cisco 3750G-24PS Issues with POE
In-Reply-To: <99bc91e0903181115m195a5225s899c4915fabf7c20@mail.gmail.com>
References: <99bc91e0903170427r6557b26ax11ed9a60e2aa9f01@mail.gmail.com>	
	<17838240D9A5544AAA5FF95F8D52031605B421A5@ad-exh01.adhost.lan>	
	<49C01E09.5080409@rollernet.us>	
	<99bc91e0903172319g413e10c7gd5e01cf63fec4157@mail.gmail.com>	
	<49C13693.2000405@rollernet.us>
	<99bc91e0903181115m195a5225s899c4915fabf7c20@mail.gmail.com>
Message-ID: <49C14120.4020903@rollernet.us>

George Stylianou wrote:
> 
> 
> 
>     Huh, that's weird. Are you plugging the phone directly into the switch
>     or is there wiring (patch panels, in-wall wiring, etc.) between the
>     switch and the phone? It seems like it's just not detecting that there's
>     a POE device on the other end.
> 
> 
> very weird...
> 
> phones are plugging directly in - tried various working patch leads as well.
> 
> I'm stuck on this one, think I need to try find a Cisco IP phone to test
> with and see what happens with that
>  

Mine are Polycom 430's and an HP access point on a NME-16ES-1G-P which
is basically a 3750 in NME form. All are standard POE, not the
pre-standard stuff.

~Seth

From jimmy.changa007 at gmail.com  Wed Mar 18 15:34:59 2009
From: jimmy.changa007 at gmail.com (Jimmy Changa)
Date: Wed, 18 Mar 2009 15:34:59 -0400
Subject: [c-nsp] Sup720-3BXL and diag issues
In-Reply-To: <20090316224745.GC9886@wildfire.net.ic.ac.uk>
References: <7cf54880903161240lb77d76l84b16ce7b3f9224d@mail.gmail.com>
	<20090316224745.GC9886@wildfire.net.ic.ac.uk>
Message-ID: <7cf54880903181234t6fc7c6d8qac881d31c0f83778@mail.gmail.com>

Seems that all cards and in all slots seem to fail. Again, the same cards
work fine else were.

On Mon, Mar 16, 2009 at 6:47 PM, Phil Mayers <p.mayers at imperial.ac.uk>wrote:

>  On Mon, Mar 16, 2009 at 07:40:30PM +0000, Jimmy Changa wrote:
>
>> I have a 6500 with a sup720-3BXL. Every time I put a WS-X6408A-GBIC card
>> in
>> the chassis, diag fails the card.
>>
>> I haven't rebooted the box yet, as this carrys a significant amount of
>> traffic, has anyone else seen this type of problem.
>>
>> Diag on the most recent card shows:
>>
>> 7) TestUnusedPortLoopback:
>>
>>     Port  1  2  3  4  5  6  7  8
>>     ----------------------------
>>           U  U  U  F  U  U  U  F
>>
>
> Some of the diags are heavily dependent on IOS config, usually only the
> disruptive ones though. I don't have any 6408s but what does:
>
> sh diagnostic content module X
>
> ....say when the card is inserted? It should list some details about test
> #7 i.e. whether it's a bootup/health test, which I'd expect to pass in all
> circumstances.
>
> A few weeks ago, I'd have said you may have a bad slot, but recently we had
> a slot "go funny" and no amount of fiddling would clear it *except* a reload
> of the box, so it's definitely worth trying.
>
>
>> The cards work in other chassis.
>>
>
> Have you tried other cards in that slot?
>

From bbc at misn.com  Wed Mar 18 15:55:04 2009
From: bbc at misn.com (Bryan Campbell)
Date: Wed, 18 Mar 2009 14:55:04 -0500
Subject: [c-nsp] Cisco 3750G-24PS Issues with POE
In-Reply-To: <99bc91e0903181115m195a5225s899c4915fabf7c20@mail.gmail.com>
References: <99bc91e0903170427r6557b26ax11ed9a60e2aa9f01@mail.gmail.com>
	<17838240D9A5544AAA5FF95F8D52031605B421A5@ad-exh01.adhost.lan>
	<49C01E09.5080409@rollernet.us>
	<99bc91e0903172319g413e10c7gd5e01cf63fec4157@mail.gmail.com>
	<49C13693.2000405@rollernet.us>
	<99bc91e0903181115m195a5225s899c4915fabf7c20@mail.gmail.com>
Message-ID: <1237406104.10137.75.camel@home-desktop>


There is a standard Cisco document "Troubleshooting Power over Ethernet
(PoE)" that explains the whole mess.  Available via Google.

bbc at misn.com


On Wed, 2009-03-18 at 20:15 +0200, George Stylianou wrote:
> >
> >
> > Huh, that's weird. Are you plugging the phone directly into the switch
> > or is there wiring (patch panels, in-wall wiring, etc.) between the
> > switch and the phone? It seems like it's just not detecting that there's
> > a POE device on the other end.
> >
> 
> very weird...
> 
> phones are plugging directly in - tried various working patch leads as well.
> 
> I'm stuck on this one, think I need to try find a Cisco IP phone to test
> with and see what happens with that
> 
> 
> >
> > ~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 ajadav at gmail.com  Wed Mar 18 16:13:47 2009
From: ajadav at gmail.com (Asheesh Jadav)
Date: Wed, 18 Mar 2009 13:13:47 -0700
Subject: [c-nsp] Cisco 7600: unsupported module
Message-ID: <b247bbf20903181313m6d495d56i13f5708650e35c23@mail.gmail.com>

Hi,

  I have an OSM-2+4GE-WAN+ Line blade that I'm trying to use on a 7600
chassis but it wont power up. Any help as to why it doesn't? The Cisco
website seems to claim that the software I'm running should support this
Line card.

Here is the error message that I see:

*Sep 10 06:46:35.347: %C6KPWR-SP-4-UNSUPPORTED: unsupported module in slot
3, power not allowed: Not Supported.


and here is what I have:

Mod Ports Card Type                              Model              Serial
No.
--- ----- -------------------------------------- ------------------
-----------
  3    2  2+4 port GE-WAN                        OSM-2+4GE-WAN+
JAB092500TX
  5    2  Supervisor Engine 720 (Active)         WS-SUP720-3B
SAL1208GKQA

Mod MAC addresses                       Hw    Fw           Sw
Status
--- ---------------------------------- ------ ------------ ------------
-------
  3  0012.7f08.46c0 to 0012.7f08.46cf   2.2   Unknown      Unknown
PwrDown
  5  0017.9444.2688 to 0017.9444.268b   5.3   8.5(2)       12.2(33)SRB5 Ok

Mod  Sub-Module                  Model              Serial       Hw
Status
---- --------------------------- ------------------ ----------- -------
-------
  5  Policy Feature Card 3       WS-F6K-PFC3B       SAL1126W66V  2.2    Ok
  5  MSFC3 Daughterboard         WS-SUP720          SAL1126W66E  2.3    Ok

Mod  Online Diag Status
---- -------------------
  3  Not Applicable
  5  Pass
Router>
Router>
Router>show ver
Cisco IOS Software, c7600s72033_rp Software
(c7600s72033_rp-ADVIPSERVICESK9-M), Version 12.2(33)SRB5, RELEASE SOFTWARE
(fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2008 by Cisco Systems, Inc.
Compiled Wed 05-Nov-08 19:24 by prod_rel_team

ROM: System Bootstrap, Version 12.2(17r)SX5, RELEASE SOFTWARE (fc1)

 Router uptime is 31 minutes
Uptime for this control processor is 31 minutes
Time since Router switched to active is 30 minutes
System returned to ROM by reload (SP by reload)
System image file is
"bootdisk:c7600s72033-advipservicesk9-mz.122-33.SRB5.bin"
Last reload type: Normal Reload


This product contains cryptographic features and is subject to United
States and local country laws governing import, export, transfer and
use. Delivery of Cisco cryptographic products does not imply
third-party authority to import, export, distribute or use encryption.
Importers, exporters, distributors and users are responsible for
compliance with U.S. and local country laws. By using this product you
agree to comply with applicable laws and regulations. If you are unable
to comply with U.S. and local laws, return this product immediately.

A summary of U.S. laws governing Cisco cryptographic products may be found
at:
http://www.cisco.com/wwl/export/crypto/tool/stqrg.html

If you require further assistance please contact us by sending email to
export at cisco.com.

cisco CISCO7606-S (R7000) processor (revision 1.0) with 458720K/65536K bytes
of memory.
Processor board ID FOX1231GPVB
SR71000 CPU at 600Mhz, Implementation 0x504, Rev 1.2, 512KB L2 Cache
Last reset from s/w reset
1 Virtual Ethernet interface
6 Gigabit Ethernet interfaces
1917K bytes of non-volatile configuration memory.
8192K bytes of packet buffer memory.

65536K bytes of Flash internal SIMM (Sector size 512K).
Configuration register is 0x2102

Router>


Thanks in Advance.

From icox at cisco.com  Wed Mar 18 16:35:30 2009
From: icox at cisco.com (Ian Cox)
Date: Wed, 18 Mar 2009 13:35:30 -0700
Subject: [c-nsp] Cisco 7600: unsupported module
In-Reply-To: <b247bbf20903181313m6d495d56i13f5708650e35c23@mail.gmail.com>
References: <b247bbf20903181313m6d495d56i13f5708650e35c23@mail.gmail.com>
Message-ID: <49C15B12.4030808@cisco.com>

Your running a non-wan image. You need a wan image to support this card.


Ian

Asheesh Jadav wrote:
> Hi,
> 
>   I have an OSM-2+4GE-WAN+ Line blade that I'm trying to use on a 7600
> chassis but it wont power up. Any help as to why it doesn't? The Cisco
> website seems to claim that the software I'm running should support this
> Line card.
> 
> Here is the error message that I see:
> 
> *Sep 10 06:46:35.347: %C6KPWR-SP-4-UNSUPPORTED: unsupported module in slot
> 3, power not allowed: Not Supported.
> 
> 
> and here is what I have:
> 
> Mod Ports Card Type                              Model              Serial
> No.
> --- ----- -------------------------------------- ------------------
> -----------
>   3    2  2+4 port GE-WAN                        OSM-2+4GE-WAN+
> JAB092500TX
>   5    2  Supervisor Engine 720 (Active)         WS-SUP720-3B
> SAL1208GKQA
> 
> Mod MAC addresses                       Hw    Fw           Sw
> Status
> --- ---------------------------------- ------ ------------ ------------
> -------
>   3  0012.7f08.46c0 to 0012.7f08.46cf   2.2   Unknown      Unknown
> PwrDown
>   5  0017.9444.2688 to 0017.9444.268b   5.3   8.5(2)       12.2(33)SRB5 Ok
> 
> Mod  Sub-Module                  Model              Serial       Hw
> Status
> ---- --------------------------- ------------------ ----------- -------
> -------
>   5  Policy Feature Card 3       WS-F6K-PFC3B       SAL1126W66V  2.2    Ok
>   5  MSFC3 Daughterboard         WS-SUP720          SAL1126W66E  2.3    Ok
> 
> Mod  Online Diag Status
> ---- -------------------
>   3  Not Applicable
>   5  Pass
> Router>
> Router>
> Router>show ver
> Cisco IOS Software, c7600s72033_rp Software
> (c7600s72033_rp-ADVIPSERVICESK9-M), Version 12.2(33)SRB5, RELEASE SOFTWARE
> (fc2)
> Technical Support: http://www.cisco.com/techsupport
> Copyright (c) 1986-2008 by Cisco Systems, Inc.
> Compiled Wed 05-Nov-08 19:24 by prod_rel_team
> 
> ROM: System Bootstrap, Version 12.2(17r)SX5, RELEASE SOFTWARE (fc1)
> 
>  Router uptime is 31 minutes
> Uptime for this control processor is 31 minutes
> Time since Router switched to active is 30 minutes
> System returned to ROM by reload (SP by reload)
> System image file is
> "bootdisk:c7600s72033-advipservicesk9-mz.122-33.SRB5.bin"
> Last reload type: Normal Reload
> 
> 
> This product contains cryptographic features and is subject to United
> States and local country laws governing import, export, transfer and
> use. Delivery of Cisco cryptographic products does not imply
> third-party authority to import, export, distribute or use encryption.
> Importers, exporters, distributors and users are responsible for
> compliance with U.S. and local country laws. By using this product you
> agree to comply with applicable laws and regulations. If you are unable
> to comply with U.S. and local laws, return this product immediately.
> 
> A summary of U.S. laws governing Cisco cryptographic products may be found
> at:
> http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
> 
> If you require further assistance please contact us by sending email to
> export at cisco.com.
> 
> cisco CISCO7606-S (R7000) processor (revision 1.0) with 458720K/65536K bytes
> of memory.
> Processor board ID FOX1231GPVB
> SR71000 CPU at 600Mhz, Implementation 0x504, Rev 1.2, 512KB L2 Cache
> Last reset from s/w reset
> 1 Virtual Ethernet interface
> 6 Gigabit Ethernet interfaces
> 1917K bytes of non-volatile configuration memory.
> 8192K bytes of packet buffer memory.
> 
> 65536K bytes of Flash internal SIMM (Sector size 512K).
> Configuration register is 0x2102
> 
> Router>
> 
> 
> 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 icox at cisco.com  Wed Mar 18 16:41:20 2009
From: icox at cisco.com (Ian Cox)
Date: Wed, 18 Mar 2009 13:41:20 -0700
Subject: [c-nsp] Cisco 7600: unsupported module
In-Reply-To: <49C15B12.4030808@cisco.com>
References: <b247bbf20903181313m6d495d56i13f5708650e35c23@mail.gmail.com>
	<49C15B12.4030808@cisco.com>
Message-ID: <49C15C70.1000507@cisco.com>

Bad answer (Forgot the bundling changed in SR duh), how much memory is
installed on the card? Did it used to work before upgrading or is this a
new install for the card.

Are there more syslog messages than just this one?

Ian

Ian Cox wrote:
> Your running a non-wan image. You need a wan image to support this card.
> 
> 
> Ian
> 
> Asheesh Jadav wrote:
>> Hi,
>>
>>   I have an OSM-2+4GE-WAN+ Line blade that I'm trying to use on a 7600
>> chassis but it wont power up. Any help as to why it doesn't? The Cisco
>> website seems to claim that the software I'm running should support this
>> Line card.
>>
>> Here is the error message that I see:
>>
>> *Sep 10 06:46:35.347: %C6KPWR-SP-4-UNSUPPORTED: unsupported module in slot
>> 3, power not allowed: Not Supported.
>>
>>
>> and here is what I have:
>>
>> Mod Ports Card Type                              Model              Serial
>> No.
>> --- ----- -------------------------------------- ------------------
>> -----------
>>   3    2  2+4 port GE-WAN                        OSM-2+4GE-WAN+
>> JAB092500TX
>>   5    2  Supervisor Engine 720 (Active)         WS-SUP720-3B
>> SAL1208GKQA
>>
>> Mod MAC addresses                       Hw    Fw           Sw
>> Status
>> --- ---------------------------------- ------ ------------ ------------
>> -------
>>   3  0012.7f08.46c0 to 0012.7f08.46cf   2.2   Unknown      Unknown
>> PwrDown
>>   5  0017.9444.2688 to 0017.9444.268b   5.3   8.5(2)       12.2(33)SRB5 Ok
>>
>> Mod  Sub-Module                  Model              Serial       Hw
>> Status
>> ---- --------------------------- ------------------ ----------- -------
>> -------
>>   5  Policy Feature Card 3       WS-F6K-PFC3B       SAL1126W66V  2.2    Ok
>>   5  MSFC3 Daughterboard         WS-SUP720          SAL1126W66E  2.3    Ok
>>
>> Mod  Online Diag Status
>> ---- -------------------
>>   3  Not Applicable
>>   5  Pass
>> Router>
>> Router>
>> Router>show ver
>> Cisco IOS Software, c7600s72033_rp Software
>> (c7600s72033_rp-ADVIPSERVICESK9-M), Version 12.2(33)SRB5, RELEASE SOFTWARE
>> (fc2)
>> Technical Support: http://www.cisco.com/techsupport
>> Copyright (c) 1986-2008 by Cisco Systems, Inc.
>> Compiled Wed 05-Nov-08 19:24 by prod_rel_team
>>
>> ROM: System Bootstrap, Version 12.2(17r)SX5, RELEASE SOFTWARE (fc1)
>>
>>  Router uptime is 31 minutes
>> Uptime for this control processor is 31 minutes
>> Time since Router switched to active is 30 minutes
>> System returned to ROM by reload (SP by reload)
>> System image file is
>> "bootdisk:c7600s72033-advipservicesk9-mz.122-33.SRB5.bin"
>> Last reload type: Normal Reload
>>
>>
>> This product contains cryptographic features and is subject to United
>> States and local country laws governing import, export, transfer and
>> use. Delivery of Cisco cryptographic products does not imply
>> third-party authority to import, export, distribute or use encryption.
>> Importers, exporters, distributors and users are responsible for
>> compliance with U.S. and local country laws. By using this product you
>> agree to comply with applicable laws and regulations. If you are unable
>> to comply with U.S. and local laws, return this product immediately.
>>
>> A summary of U.S. laws governing Cisco cryptographic products may be found
>> at:
>> http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
>>
>> If you require further assistance please contact us by sending email to
>> export at cisco.com.
>>
>> cisco CISCO7606-S (R7000) processor (revision 1.0) with 458720K/65536K bytes
>> of memory.
>> Processor board ID FOX1231GPVB
>> SR71000 CPU at 600Mhz, Implementation 0x504, Rev 1.2, 512KB L2 Cache
>> Last reset from s/w reset
>> 1 Virtual Ethernet interface
>> 6 Gigabit Ethernet interfaces
>> 1917K bytes of non-volatile configuration memory.
>> 8192K bytes of packet buffer memory.
>>
>> 65536K bytes of Flash internal SIMM (Sector size 512K).
>> Configuration register is 0x2102
>>
>> Router>
>>
>>
>> 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 llc at dansketelecom.com  Wed Mar 18 17:03:38 2009
From: llc at dansketelecom.com (Lars Lystrup Christensen)
Date: Wed, 18 Mar 2009 22:03:38 +0100
Subject: [c-nsp] Cisco 7600: unsupported module
In-Reply-To: <b247bbf20903181313m6d495d56i13f5708650e35c23@mail.gmail.com>
References: <b247bbf20903181313m6d495d56i13f5708650e35c23@mail.gmail.com>
Message-ID: <44417CD2F19FEA4F885088340A71D33201C8F9D3@mail.office.dansketelecom.com>

Hi Asheesh,

Without remembering correctly, it could be the case, that your OSM card is not supported in the 7606-S chassis.

You should consult your local Cisco SE about specifications whether it is supported in this chassis model.

______________________________________

Med venlig hilsen / Kind regards

Lars Lystrup Christensen 
Director of Engineering, CCIE(tm) #20292

Danske Telecom A/S
Sundkrogsgade 13, 4 
2100 K?benhavn ? 


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Asheesh Jadav
Sent: 18. marts 2009 21:14
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Cisco 7600: unsupported module

Hi,

  I have an OSM-2+4GE-WAN+ Line blade that I'm trying to use on a 7600
chassis but it wont power up. Any help as to why it doesn't? The Cisco
website seems to claim that the software I'm running should support this
Line card.

Here is the error message that I see:

*Sep 10 06:46:35.347: %C6KPWR-SP-4-UNSUPPORTED: unsupported module in slot
3, power not allowed: Not Supported.


and here is what I have:

Mod Ports Card Type                              Model              Serial
No.
--- ----- -------------------------------------- ------------------
-----------
  3    2  2+4 port GE-WAN                        OSM-2+4GE-WAN+
JAB092500TX
  5    2  Supervisor Engine 720 (Active)         WS-SUP720-3B
SAL1208GKQA

Mod MAC addresses                       Hw    Fw           Sw
Status
--- ---------------------------------- ------ ------------ ------------
-------
  3  0012.7f08.46c0 to 0012.7f08.46cf   2.2   Unknown      Unknown
PwrDown
  5  0017.9444.2688 to 0017.9444.268b   5.3   8.5(2)       12.2(33)SRB5 Ok

Mod  Sub-Module                  Model              Serial       Hw
Status
---- --------------------------- ------------------ ----------- -------
-------
  5  Policy Feature Card 3       WS-F6K-PFC3B       SAL1126W66V  2.2    Ok
  5  MSFC3 Daughterboard         WS-SUP720          SAL1126W66E  2.3    Ok

Mod  Online Diag Status
---- -------------------
  3  Not Applicable
  5  Pass
Router>
Router>
Router>show ver
Cisco IOS Software, c7600s72033_rp Software
(c7600s72033_rp-ADVIPSERVICESK9-M), Version 12.2(33)SRB5, RELEASE SOFTWARE
(fc2)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2008 by Cisco Systems, Inc.
Compiled Wed 05-Nov-08 19:24 by prod_rel_team

ROM: System Bootstrap, Version 12.2(17r)SX5, RELEASE SOFTWARE (fc1)

 Router uptime is 31 minutes
Uptime for this control processor is 31 minutes
Time since Router switched to active is 30 minutes
System returned to ROM by reload (SP by reload)
System image file is
"bootdisk:c7600s72033-advipservicesk9-mz.122-33.SRB5.bin"
Last reload type: Normal Reload


This product contains cryptographic features and is subject to United
States and local country laws governing import, export, transfer and
use. Delivery of Cisco cryptographic products does not imply
third-party authority to import, export, distribute or use encryption.
Importers, exporters, distributors and users are responsible for
compliance with U.S. and local country laws. By using this product you
agree to comply with applicable laws and regulations. If you are unable
to comply with U.S. and local laws, return this product immediately.

A summary of U.S. laws governing Cisco cryptographic products may be found
at:
http://www.cisco.com/wwl/export/crypto/tool/stqrg.html

If you require further assistance please contact us by sending email to
export at cisco.com.

cisco CISCO7606-S (R7000) processor (revision 1.0) with 458720K/65536K bytes
of memory.
Processor board ID FOX1231GPVB
SR71000 CPU at 600Mhz, Implementation 0x504, Rev 1.2, 512KB L2 Cache
Last reset from s/w reset
1 Virtual Ethernet interface
6 Gigabit Ethernet interfaces
1917K bytes of non-volatile configuration memory.
8192K bytes of packet buffer memory.

65536K bytes of Flash internal SIMM (Sector size 512K).
Configuration register is 0x2102

Router>


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 moua0100 at umn.edu  Wed Mar 18 17:36:38 2009
From: moua0100 at umn.edu (Ge Moua)
Date: Wed, 18 Mar 2009 16:36:38 -0500
Subject: [c-nsp] L2TPv3 "LNS mode"
In-Reply-To: <10f693fd0903181158x763e38c6o9b85fc5afbf4f7f@mail.gmail.com>
References: <10f693fd0903181057u631316cdgb3a58746183c1033@mail.gmail.com>
	<10f693fd0903181158x763e38c6o9b85fc5afbf4f7f@mail.gmail.com>
Message-ID: <49C16966.401@umn.edu>

One could send this over vanilla crypto IPSec; IPSec is routable.  We 
are doing this over here.

Regards,
Ge Moua | Email: moua0100 at umn.edu

Network Design Engineer
University of Minnesota | Networking & Telecommunications Services



Gabor Ivanszky wrote:
> Hello,
>
> is there any possibility to route(L3 process) Ethernet encapsulated IP
> packets arriving at a Cisco router in a L2TPv3 tunnel?
>
> In other words, is it possible to configure a Cisco box in LNS role in
> an Ethernet L2TPv3 setup?
>
> " L2TP Network Server (LNS)
>
>      If a given L2TP session is terminated at the L2TP node and the
>      encapsulated network layer (L3) packet processed on a virtual
>      interface, we refer to this L2TP node as an L2TP Network Server" (RFC3931)
>
> Actually i'd like to implement  "(a) LAC-LNS Reference Model:
>
> On one side, the LAC receives traffic
>   from an L2 circuit, which it forwards via L2TP across an IP or other
>   packet-based network.  On the other side, an LNS logically terminates
>   the L2 circuit locally and routes network traffic to the home
>   network.  The action of session establishment is driven by the LAC
>   (as an incoming call) or the LNS (as an outgoing call).
>
>    +-----+  L2  +-----+                        +-----+
>    |     |------| LAC |.........[ IP ].........| LNS |...[home network]
>    +-----+      +-----+                        +-----+
>    remote
>    system
>                       |<-- emulated service -->|
>          |<----------- L2 service ------------>| "(RFC3931)
>
> Practically an Ethernet interface with an xconnect setting on "LAC"
> side, and something like an IP tunnel interface on the "LNS" side.
>
> The obvious
>
> interface Tunnel1
>  tunnel mode l2tpv3
>
> doesn't exist.
>
>
> cheers,
> Gabor
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>   

From pete at bytemark.co.uk  Wed Mar 18 17:52:06 2009
From: pete at bytemark.co.uk (Peter Taphouse)
Date: Wed, 18 Mar 2009 21:52:06 +0000
Subject: [c-nsp] Cisco 7600: unsupported module
In-Reply-To: <44417CD2F19FEA4F885088340A71D33201C8F9D3@mail.office.dansketelecom.com>
References: <b247bbf20903181313m6d495d56i13f5708650e35c23@mail.gmail.com>
	<44417CD2F19FEA4F885088340A71D33201C8F9D3@mail.office.dansketelecom.com>
Message-ID: <49C16D06.4090705@bytemark.co.uk>

Lars Lystrup Christensen wrote:
> Hi Asheesh,
> 
> Without remembering correctly, it could be the case, that your OSM
> card is not supported in the 7606-S chassis.
> 
> You should consult your local Cisco SE about specifications whether
> it is supported in this chassis model.

Was looking at this earlier today by chance, and to quote from the below
url for 12.2SR trains:

?OSMs are not supported in the Cisco 7604 or in any S-series chassis.

http://www.cisco.com/en/US/docs/routers/7600/Hardware/12.2SR_supported_hw/7600_hwd.html

HTH,

-- 
Peter Taphouse

Bytemark Hosting
http://www.bytemark.co.uk/
tel. +44 (0) 845 004 3 004

From eng_mssk at hotmail.com  Wed Mar 18 19:56:11 2009
From: eng_mssk at hotmail.com (Mohammad Khalil)
Date: Thu, 19 Mar 2009 01:56:11 +0200
Subject: [c-nsp] Cisco ACE Module error message
Message-ID: <BLU102-W1872000189AC02169851A0FA990@phx.gbl>


hey all 
we have Cisco 6509 with ACE Module installed
actually , the ACE module is used for caching purposes 
we are facing the below error 
Mar 14 08:08:01 UTC: %OSPF-4-ERRRCV: Received invalid
packet: Bad LLS Checksum from x.x.x.x, Vlan201
anyone's suggestions ??

Thanks in advance

Best Regards,
Mohammad Khalil

_________________________________________________________________
Drag n? drop?Get easy photo sharing with Windows Live? Photos.

http://www.microsoft.com/windows/windowslive/products/photos.aspx

From charles.regan at gmail.com  Wed Mar 18 20:44:51 2009
From: charles.regan at gmail.com (Charles Regan)
Date: Wed, 18 Mar 2009 21:44:51 -0300
Subject: [c-nsp] GRE Tunnel 1811 and Backhaul VLAN dot1q
Message-ID: <e353d880903181744r36dde573yef7e135d7acfb6c1@mail.gmail.com>

Will this work ?
I need to setup a GRE tunnel between the two 1811 so that everything
is transparent to the ISP that wants to use our fiber link.
ISP is using dot1q vlan. Customer vlan are tagged by modem.
Everything needs to be transparent on my side as I don't want to add
vlan database and I don't want to see his traffic on my network.
I've come to the conclusion that I couldn't do it with the switch
currently in place. So I got two 1811 laying around that might do what
I want.

What you guys think ?

BH= Wireless Backhaul
The BH will be plugged into the switch port of the 1811.
SW2924 will be plugged into the router port of the 1811 which will be
the port of the tunnel.

INTERNET -- SW2950 -- BH -- RT1811 -- SW2924 --FIBER-- SW2924 --
RT1811 -- BH --SW2950 -- INTERNET CLIENT

Thanks,
Charles (learning)

From todd at newfrontierssolutions.com  Wed Mar 18 23:03:39 2009
From: todd at newfrontierssolutions.com (Todd Shipway)
Date: Wed, 18 Mar 2009 23:03:39 -0400
Subject: [c-nsp] Virtual Access int down after IOS upgrade
In-Reply-To: <1237054954.7369.6.camel@booger>
References: <1236987481.10690.12.camel@booger> <1237054954.7369.6.camel@booger>
Message-ID: <A0B19035-FFB1-43B9-98B7-742A8FF17BCA@newfrontierssolutions.com>

For archiving purposes...

The issue with the ATM interfaces was due to an older ATM card that  
wasn't compatible with 12.4(23). Once the card was replaced with a  
newer enhanced ATM card, all PVC interfaces came online without a  
problem.

-Todd



On Mar 14, 2009, at 2:24 PM, "Todd Shipway" <todd at newfrontierssolutions.com 
 > wrote:

> I had to go back to 12.4(3) to get the virtual-access interface  
> working
> again.  But below is the config I'm using for the dsl's on the atm  
> card.
> Is there something I'm missing that has changed since 12.4(3) and  
> (23)?
> I'm sure there is, but it's becoming a huge pain to track it down.   
> Just
> looking for possible suggestions, I'm digging through release notes  
> now
> to see if I can find more info.
>
> The problem is that after upgrading to 12.4(23), the Virtual-Access
> interface stays in a down/down state.  atm and pvc interfaces are up/ 
> up.
> Since the Virtual-Access int is down, no traffic passes from DSL
> connections.
>
> This is on a 7513 with 12.0(10r)S1 bootstrap.
>
> ATM Card:
> NAME: "Card Slot 10, Bay 0", DESCR: "ATM Lite Port Adaptor (SM)"
> PID: PA-ATM-LITE-SM    , VID: Hardware Version : 1.1 Board Revision :
> D0, SN: 16743213
>
>
> Current 12.4(3) config:
>
> interface ATM10/0/0
> no ip address
> no atm ilmi-keepalive
> no clns route-cache
> !
> interface ATM10/0/0.1 multipoint
> pvc 1/6
>  encapsulation aal5snap
>  protocol ppp Virtual-Template16
> !
> pvc 1/9
>  encapsulation aal5snap
>  protocol ppp Virtual-Template13
>
>
>
> interface Virtual-Template13
> ip unnumbered FastEthernet4/0
> peer default ip address pool dsl13
> !
> interface Virtual-Template14
> ip unnumbered FastEthernet4/0
> peer default ip address pool dsl14
> !
> interface Virtual-Template15
> ip unnumbered FastEthernet4/0
> peer default ip address pool dsl15
> !
> interface Virtual-Template16
> ip unnumbered FastEthernet4/0
> peer default ip address pool dsl16
> !
>
>
>
>
> ip local pool dsl13 63.168.160.164
> ip local pool dsl14 63.168.160.165
> ip local pool dsl15 63.168.160.166
> ip local pool dsl16 198.70.13.130 198.70.13.142
>
>
>
> On Fri, 2009-03-13 at 19:38 -0400, Todd Shipway wrote:
>> We just upgraded a 7500 to 12.4(23) and everything works great except
>> DSL connections over atm card.  ATM interfaces are up, all  
>> configuration
>> is in place,  pvc interfaces are up, virtual templates are in place.
>> But the virtual-access interface refuses to come up.  Anyone have any
>> clues as to what we shoudl be looking at?  Everything I see seems  
>> like
>> it shoudl be working good.
>>
>>
>> summit#sh interfaces atm 10/0/0
>> ATM10/0/0 is up, line protocol is up
>>  Hardware is cyBus ATM
>>  MTU 4470 bytes, sub MTU 4470, BW 155520 Kbit/sec, DLY 80 usec,
>>     reliability 129/255, txload 1/255, rxload 1/255
>>  Encapsulation ATM, loopback not set
>>  Encapsulation(s): AAL5 , PVC mode
>>  2047 maximum active VCs, 1024 VCs per VP, 88 current VCCs
>>  VC Auto Creation Disabled.
>>  VC idle disconnect time: 300 seconds
>>  Last input 00:02:08, output 00:02:08, output hang never
>>  Last clearing of "show interface" counters never
>>  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output  
>> drops: 0
>>  Queueing strategy: fifo
>>  Output queue: 0/40 (size/max)
>>  5 minute input rate 30000 bits/sec, 56 packets/sec
>>  5 minute output rate 0 bits/sec, 0 packets/sec
>>     37010 packets input, 2527473 bytes, 0 no buffer
>>     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
>>     37305 input errors, 0 CRC, 0 frame, 63 overrun, 0 ignored, 1  
>> abort
>>     1 packets output, 56 bytes, 0 underruns
>>     0 output errors, 0 collisions, 0 interface resets
>>     0 unknown protocol drops
>>     0 output buffer failures, 0 output buffers swapped out
>> summit#sh interfaces atm 10/0/0.1
>> ATM10/0/0.1 is up, line protocol is up
>>  Hardware is cyBus ATM
>>  MTU 4470 bytes, BW 155520 Kbit/sec, DLY 80 usec,
>>     reliability 128/255, txload 1/255, rxload 1/255
>>  Encapsulation ATM
>>     35184 packets input, 2260236 bytes
>>     0 packets output, 0 bytes
>>     1 OAM cells input, 1 OAM cells output
>>  AAL5 Oversized SDUs : 0
>>  Last clearing of "show interface" counters never
>> summit#sh interfaces virtual-access 1
>> Virtual-Access1 is down, line protocol is down
>>  Hardware is Virtual Access interface
>>  MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100000 usec,
>>     reliability 255/255, txload 1/255, rxload 1/255
>>  Encapsulation PPP, LCP Closed
>>  Base VtMgr vaccess
>>  Vaccess status 0x0, loopback not set
>>  DTR is pulsed for 5 seconds on reset
>>  Last input never, output never, output hang never
>>  Last clearing of "show interface" counters 00:11:07
>>  Input queue: 0/4096/0/0 (size/max/drops/flushes); Total output  
>> drops:
>> 0
>>  Queueing strategy: fifo
>>  Output queue: 0/40 (size/max)
>>  5 minute input rate 0 bits/sec, 0 packets/sec
>>  5 minute output rate 0 bits/sec, 0 packets/sec
>>     0 packets input, 0 bytes, 0 no buffer
>>     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
>>     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
>>     0 packets output, 0 bytes, 0 underruns
>>     0 output errors, 0 collisions, 0 interface resets
>>     0 unknown protocol drops
>>     0 output buffer failures, 0 output buffers swapped out
>>     0 carrier transitions
>>
>> _______________________________________________
>> cisco-nsp mailing 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 linux.yahoo at gmail.com  Thu Mar 19 04:26:48 2009
From: linux.yahoo at gmail.com (Manu Chao)
Date: Thu, 19 Mar 2009 09:26:48 +0100
Subject: [c-nsp] ospf distance
Message-ID: <7100ed370903190126n3ec70d8eudf8f29c8f1e09fab@mail.gmail.com>

I want to change OSPF administrative distance for ospf-external-type-2-only
routes from a specific OSPF neighbor only.

option 1: changing distance using distance command
I know it is possible to change OSPF distance using "distance command" for a
neighbor globally or using standard ACL BUT it is not possible to
restrict-to-ospf-external only ;(

option 2:changing distance using distribute-list command
I try to use distribute-list in with a route-map BUT it is not possible to
set distance inside a route-map :(

I need help. Is it possible? Is there any hint?

Thanks for your help.

My config look like as follow:

option 1:
router ospf 1
router-id 1.1.1.1
distance 19 2.2.2.2 0.0.0.0 ospf-e2-only
!
ip access-list standard ospf-e2-only
permit ?

Router(config-std-nacl)#permit ?
  Hostname or A.B.C.D  Address to match
  any                  Any source host
  host                 A single host address

--> NOT POSSIBLE TO SPECIFY OSPF EXTERNAL E2 ROUTES :(

option 2:
router ospf 1
router-id 1.1.1.1
distribute-list set-distance-to-ospf-external-2-only in

route-map set-distance-to-ospf-external-2-only
match route-type match route-type external type-2
set ?

Router(config-route-map)#set ?
  as-path           Prepend string for a BGP AS-path attribute
  automatic-tag     Automatically compute TAG value
  clns              OSI summary address
  comm-list         set BGP community list (for deletion)
  community         BGP community attribute
  dampening         Set BGP route flap dampening parameters
  default           Set default information
  extcommunity      BGP extended community attribute
  interface         Output interface
  ip                IP specific information
  ipv6              IPv6 specific information
  level             Where to import route
  local-preference  BGP local preference path attribute
  metric            Metric value for destination routing protocol
  metric-type       Type of metric for destination routing protocol
  mpls-label        Set MPLS label for prefix
  nlri              BGP NLRI type
  origin            BGP origin code
  tag               Tag value for destination routing protocol
  traffic-index     BGP traffic classification number for accounting
  vrf               Define VRF name
  weight            BGP weight for routing table

--> NOT POSSIBLE TO CHANGE DISTANCE IN A ROUTE-MAP :(

Thanks in advance
Manu

From blahu77 at gmail.com  Thu Mar 19 04:37:55 2009
From: blahu77 at gmail.com (Mateusz Blaszczyk)
Date: Thu, 19 Mar 2009 08:37:55 +0000
Subject: [c-nsp] ospf distance
In-Reply-To: <7100ed370903190126n3ec70d8eudf8f29c8f1e09fab@mail.gmail.com>
References: <7100ed370903190126n3ec70d8eudf8f29c8f1e09fab@mail.gmail.com>
Message-ID: <383357750903190137v6acea5d3wa44aa503a33b4491@mail.gmail.com>

Manu,

2009/3/19 Manu Chao <linux.yahoo at gmail.com>:
> I want to change OSPF administrative distance for ospf-external-type-2-only
> routes from a specific OSPF neighbor only.

you can't set it for E2/N2 specificaclly but you can for all external
LSA type 5/7

router(config-router)#distance ospf external ?
  <1-255>  Distance for external type 5 and type 7 routes


Best Regards,

-mat
-- 
pgp-key 0x1C655CAB

From john at techvictim.net  Thu Mar 19 05:49:41 2009
From: john at techvictim.net (John Lyons)
Date: Thu, 19 Mar 2009 09:49:41 +0000
Subject: [c-nsp] Strict priority queue recommendations.
Message-ID: <20090319094941.GA5783@infiltrator.stdlib.net>

Hi,

The QoS SRND recommends that in order to provide a "good" data service 
on links carrying both realtime traffic and data traffic that the realtime
traffic shouldn't exceed one third of the link capacity. However, the document 
is very wooly on technical detail to back this up and from a quick product 
search it appears many service providers are willing to provide up to 70% of 
link capacity for Voice/Realtime traffic using Cisco gear. 

I'm interested to know whether folks who have provisioned more than 1/3 of link 
capacity to real time traffic have seen many real-world problems (with non-realtime
traffic) during congestion and if so what kind of problems they were ? 

FWIW, the QoS will be applied primarily on E1 circuits and shaped ethernet 
circuits from 5Mb/s to 100Mb/s and the CPE will be 1841/2811/3825/3845.

Cheers,

John


From hegedus.gabor at euroway.hu  Thu Mar 19 06:22:08 2009
From: hegedus.gabor at euroway.hu (Hegedus Gabor)
Date: Thu, 19 Mar 2009 11:22:08 +0100
Subject: [c-nsp] centralized mac filtering
In-Reply-To: <49C11BAD.1080507@euroway.hu>
References: <49C0BD2B.8040809@euroway.hu> <49C11BAD.1080507@euroway.hu>
Message-ID: <49C21CD0.5000509@euroway.hu>

okay,
I have freeRadius server it works(use for eap auth), and the cisco 861w 
router, wpa security works too.
But I don't know how can i use wpa(psk) and mac 
authentication(filtering), at the same time.
this is my configuration:

dot11 ssid test
   authentication open mac-address mac_methods
   authentication key-management wpa
!

when I try configure wpa-psk, the device tells:

Error: WPA-PSK not supported with MAC address authentication configured

not supported? and how can I set wpa security not eap peap just psk, I 
don't think it is not possible...

I just want my user type the key for wpa-psk on his laptop, and if it is 
okay and the mac address is in the database, I allow user to use the 
network.

I didn't find solution...




From bdikici at gmail.com  Thu Mar 19 08:48:44 2009
From: bdikici at gmail.com (Burak Dikici)
Date: Thu, 19 Mar 2009 14:48:44 +0200
Subject: [c-nsp] BGP conditional advertisemet - NON-EXIST route
	map'saccess-list problem
In-Reply-To: <OF694CC1E4.1EAB3DA0-ON8825757C.007916C7-8825757C.00797570@lecg.com>
References: <00a201c9a746$2d7f5a40$0a00000a@nil.si>
	<OF694CC1E4.1EAB3DA0-ON8825757C.007916C7-8825757C.00797570@lecg.com>
Message-ID: <d9281f5c0903190548k66696a79sf09264522e6766fb@mail.gmail.com>

 Sorry about my late reply. I am very busy these days with another project.
I am going to test your recommendations in a few days , and going to reply
back to you. Thank you all. Kind Regards...

Burak Dikici



On Wed, Mar 18, 2009 at 12:04 AM, <RPhookun at lecg.com> wrote:

>
> The prefix-list within the Non-Exist clause also has to *exactly* match the
> prefix in the bgp table..
> Regards,
> ./Randy
>
>
>
>
>   *"Ivan Pepelnjak" <ip at ioshints.info>*
> Sent by: cisco-nsp-bounces at puck.nether.net
>
> 03/17/2009 02:20 PM
>    To
> "'Dale Shaw'" <dale.shaw+cisco-nsp at gmail.com<dale.shaw%2Bcisco-nsp at gmail.com>>,
> "'Burak Dikici'" <bdikici at gmail.com>  cc
>   cisco-nsp at puck.nether.net  Subject
> Re: [c-nsp] BGP conditional advertisemet - NON-EXIST route
>  map'saccess-list problem
>
>
>
>
>
>  Did some tests on the NON-EXIST-MAP with 12.2SRC. I was spreading wrong
> rumors, time to fix them:
>
> * The route-map checks the routes in the BGP table (_not_ in the IP routing
> table). Dale was right.
> * It can take a while for the routes to be advertised/withdrawn; the
> non-exist-map is checked only at the BGP scan intervals (60 seconds by
> default, can be adjusted).
> * You can use a combination of an access-list and AS-path access-list in
> the
> route-map.
>
> The handling of standard access-lists used in the "match ip address"
> route-map condition is a bit weird, though:
>
> * "permit any" does _NOT_ work.
> * "permit prefix 0.0.0.0" (which gets translated into "permit prefix" in
> standard ACL) does _NOT_ work.
> * fancy wildcard tests (for example "permit 0.0.0.0 127.255.255.255) do
> _NOT_ work
>
> It looks like:
>
> * the IP prefix in the BGP table must match the address in the ACL exactly
> (wildcard bits are ignored).
> * ... but you still need the wildcard bits (inverted netmask) for the match
> to work.
>
> For example: if you want to match 10.8.8.0/24, you have to use "permit
> 10.8.8.0 0.0.0.255". "permit 10.8.8.0" or "permit 10.8.0.0 0.0.255.255" do
> _NOT_ work.
>
> Left to do: tests with the ip prefix-list instead of IP access list (and
> no,
> I will NOT test extended ACL :).
>
> Hope this helps
> Ivan
>
> > -----Original Message-----
> > From: Dale Shaw [mailto:dale.shaw+cisco-nsp at gmail.com<dale.shaw%2Bcisco-nsp at gmail.com>]
>
> > Sent: Sunday, March 15, 2009 11:33 PM
> > To: Burak Dikici
> > Cc: cisco-nsp at puck.nether.net
> > Subject: Re: [c-nsp] BGP conditional advertisemet - NON-EXIST
> > route map'saccess-list problem
> >
> > Hi Burak,
> >
> > On Mon, Mar 16, 2009 at 12:06 AM, Burak Dikici
> > <bdikici at gmail.com> wrote:
> > > i am trying to use
> > > BGP conditional advertisemet configuration. I have got a
> > problem with
> > > NON-EXIST route map's access-list. In the NON-EXIST router map i am
> > > using the commands which is written below ;
> >
> > Here are some notes I made recently when playing with BGP
> > conditional advertising. I hope it helps.
> >
> > 1.) prefixes matched in advertise-map and exist/non-exist map
> > must exist (or not) in the *BGP* table
> >  however: they do not need to be locally originated (e.g. R1
> > can match routes received from R2 and advertise (or not) to R3
> >  and: the validity of the prefix in the BGP table (i.e.
> > RIB-failure) doesn't matter. if there's there, and using
> > exist-map, the condition is met.
> >
> > 2.) when using 'exist' map, prefixes matched by advertise-map
> > are advertised when exist-map condition is met
> >  example: advertise 1.0.0.0/8 (advertise-map) from BGP table when
> > 3.20.20.0/24 (exist-map) exists in BGP table
> >
> > 3.) when exist 'non-exist' map, prefixes matched by
> > advertise-map are advertised when non-exist-map condition is met
> >  example: advertise 1.0.0.0/8 (advertise-map) from BGP table when
> > 3.20.20.0/24 (non-exist-map) does NOT exist in BGP table
> >
> > 4.) prefixes matched in advertise-map are the only prefixes
> > affected -- other prefixes that may exist are advertised (or
> > not) as normal
> >
> > 5.) when dealing with conditional advertisement tasks, always
> > consider what will happen normally (without any config)
> >
> > I'd be happy to be corrected, but I think the first point is
> > contrary to what Ivan said. Also consider point #4 -- BGP
> > conditional advertising is not strictly a route filtering
> > mechanism, although it can be configured to achieve similar results.
> >
> > cheers,
> > Dale
> >
> >
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>

From rshughes at gmail.com  Thu Mar 19 12:50:53 2009
From: rshughes at gmail.com (Ryan Hughes)
Date: Thu, 19 Mar 2009 12:50:53 -0400
Subject: [c-nsp] Opinions of DDoS appliances, other techniques,
	most 	notably Cisco Guard
In-Reply-To: <49BD9755.6060608@justinshore.com>
References: <F3318834F1F89D46857972DD4B411D700651DA6C@EXCHANGE.thenap.com>
	<725C9117-BE48-468B-A39E-B69347853BAB@cisco.com>
	<04670DB7-99B1-4F55-8DDD-9C036F93E4AF@cisco.com>
	<49BD9755.6060608@justinshore.com>
Message-ID: <e44f1b0e0903190950n43826cd3l2d2626c973a3aa09@mail.gmail.com>

MARS really isn't positioned to be a Netflow anomaly detection with the
likes of Arbor and others previously mentioned. It's simply a feature that's
in there to help bring into perspective of what's going on with your Cisco
infrastructure from a threat perspective. And I would definitely be careful
with the amount of logs and Netflow that you send to the device as you can
definitely cause it to choke whereby the device isn't storing enough events
for proper correlation.

On Sun, Mar 15, 2009 at 8:03 PM, Justin Shore <justin at justinshore.com>wrote:

> Roland Dobbins wrote:
>
>>
>> On Mar 16, 2009, at 12:39 AM, Roland Dobbins wrote:
>>
>>  Arbor Peakflow SP, Narus Insight Manager, and Lancope StealthWatch Xe are
>>> three commercial NetFlow-based anomaly-detection systems.
>>>
>>
>> I forgot to add Q1 Labs Q1Radar, and I believe NetQoS now have an
>> anomaly-detection module, as well, though I've not seen it.
>>
>
> How about MARS?  I'm trying to get a pair of IDSM2s returned (they don't
> work right on 7600s) in exchange for a MARS 110R appliance.  That's roughly
> the same price.  I'm planning on using it for log analysis. Would its
> Netflow abilities be useful here?
>
> 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 rsnyder at toontown.erial.nj.us  Thu Mar 19 14:06:16 2009
From: rsnyder at toontown.erial.nj.us (Bob Snyder)
Date: Thu, 19 Mar 2009 14:06:16 -0400
Subject: [c-nsp] Sup720-3BXL and diag issues
In-Reply-To: <7cf54880903181234t6fc7c6d8qac881d31c0f83778@mail.gmail.com>
References: <7cf54880903161240lb77d76l84b16ce7b3f9224d@mail.gmail.com>
	<20090316224745.GC9886@wildfire.net.ic.ac.uk>
	<7cf54880903181234t6fc7c6d8qac881d31c0f83778@mail.gmail.com>
Message-ID: <6edfd6c20903191106y75865506ub6eb313d66cd52af@mail.gmail.com>

On Wed, Mar 18, 2009 at 3:34 PM, Jimmy Changa <jimmy.changa007 at gmail.com>wrote:

> Seems that all cards and in all slots seem to fail. Again, the same cards
> work fine else were.


Same version of IOS on this box as elsewhere? We've seen issues with
linecards "failing" on an upgrade of 7600 code that are "fixed" if you fall
back to the previous code. Cisco's stance is that they are in fact bad cards
that the new diag tests or improved existing diag tests in the new IOS
discovered, so we RMA'ed the cards.

This problem is probably not the issue if you've tried multiple cards as is
implied, but in case you hadn't...

Bob

From astounding at gmail.com  Thu Mar 19 17:57:28 2009
From: astounding at gmail.com (Aaron Gifford)
Date: Thu, 19 Mar 2009 15:57:28 -0600
Subject: [c-nsp] Policy routing on a 3750 - What am I doing wrong?
Message-ID: <e58000750903191457s7e44278aka9c54b2d1cfac16e@mail.gmail.com>

Hi,


In trying to do some IP policy routing on a 3750, I ran into some odd
behavior.  I'd appreciate any pointers/help to get this working.

I have a pretty simple set-up.  A Cisco Catalyst 3750 switch running
IOS 12.2(46)SE connects a host IP network (10.20.30.0/24) on one VLAN
to an "upstream" network (10.20.32.0/24) on another VLAN.  All I want
to do is apply a route-map to policy route traffic that originates
from a subset of hosts (for the test, one host only) to a different
next-hop gateway on the "upstream" network.


HOST NETWORK 10.20.30.0/24 (VLAN 123):
10.20.30.1  <==  3750's interface IP on VLAN 123
...
10.20.30.94  <===  This is the test host whose traffic I want to policy route


UPSTREAM NETWORK 10.20.32.0/24 (VLAN 100):
10.20.32.1  <==  This is the normal upstream gateway router -- it
talks OSPF with the 3750
10.20.32.2  <==  3750's interface IP on VLAN 100
...
10.20.32.11  <==  The other upstream gateway device (no OSPF) to which
the policy should route traffic


THE 3750's CONFIGURATION SO FAR:
PBR (policy based routing) has been enabled on the 3750 running IOS
12.2(46)SE, and "sho sdm prefer" states that the current template is
the "desktop routing" template.

ACCESS LIST:
ip access-list extended delme
 permit ip host 10.20.30.94 any
!

ROUTE MAP:
route-map delme permit 10
 match ip address delme
 set ip next-hop 10.20.32.11
!

3750's HOST NETWORK VLAN INTERFACE:
interface Vlan123
 ip address 10.20.30.1 255.255.255.0
 ip policy route-map delme
end

3750's UPSTREAM NETWORK VLAN INTERFACE
intervace Vlan100
 ip address 10.20.32.2 255.255.255.0
 ***ospf configuration omitted***
end


TEST HOST AT 10.20.30.94:
The test host at 10.20.30.94 during testing was primarily sending ICMP
ECHO REQUESTs to remote IPs (networks NOT directly connected to the
3750).


WHAT I OBSERVED:
With debugging turned on, on the 3750 I would see:

Mar 19 15:05:34.960: IP: s=10.20.30.94 (Vlan123), d=255.255.255.255,
len 94, policy match
Mar 19 15:05:34.960: IP: route map delme, item 10, permit
Mar 19 15:05:34.968: IP: s=10.20.30.94 (Vlan123), d=255.255.255.255
(Vlan100), len 94, policy routed
Mar 19 15:05:34.968: IP: Vlan123 to Vlan100 10.20.32.11
...and other repeats of the above...


It appeared that broadcast traffic was happily matching my ACL and
being policy routed.  However, no non-broadcast traffic was matching,
or at least none was showing up with debugging.  Not one non-broadcast
packet.

When I checked the route-map and ACL counters on the router I saw:

router#sho route-map delme
route-map delme, permit, sequence 10
  Match clauses:
    ip address (access-lists): delme
  Set clauses:
    ip next-hop 10.20.32.11
Nexthop tracking current: 0.0.0.0
10.20.32.11, fib_nh:0,oce:0,status:0

  Policy routing matches: 23 packets, 2484 bytes
router#sho ip access-lists delme
Extended IP access list delme
    10 permit ip host 10.20.30.94 any (23 matches)
router#


Only 23 matching packets, over a time interval when thousands of ICMP
ECHO REQUESTs were sent.

So I checked things on the policy route's next-hop gateway device at
IP 10.20.32.11.  Its logs showed that NO packets had reached it.  And
on the 10.20.30.94 testing host saw no responses to the outbound
pings.

SO...

I reset the policy's next hop to 10.20.32.1 which is the normal
next-hop IP that non-policy-routed traffic is sent to:
route-map delme permit 10
 match ip address delme
 set ip next-hop 10.20.32.1
!

I repeated my test as above.  I saw the exact same behavior on the
3750, only broadcast packets matching in logs and ACL/route-map
counters.  But now the test host at 10.20.30.94 was getting all the
echo replies it should have.


WHAT I THINK THIS TELLS ME:
Even though the 3750 was NOT logging/debugging/counting packets from
the test host, it MUST have been doing something to those packets
because during the first test it appears it was NOT sending the
traffic to the normal gateway IP.  But it was also NOT sending it to
the policy-route next-hop gateway IP.  Once I changed the policy
route-map to set the next-hop to the same IP as non-policy routed
traffic, traffic from the test host DID seem to flow.

I'm confused.  Is the 3750 policy routing traffic, or not?  Why are
only packets to the 255.255.255.255 broadcast being matched?  What am
I doing wrong?

Thanks in advance for any/all help, advice, pointers, tips, etc.

Aaron out.

From pgurumu at gmail.com  Thu Mar 19 18:46:32 2009
From: pgurumu at gmail.com (Prabhu Gurumurthy)
Date: Thu, 19 Mar 2009 15:46:32 -0700
Subject: [c-nsp] L2TP IPv6
Message-ID: <C5C35A41-7CEC-4C70-AE1D-8ECA2032401B@gmail.com>

All -

Does anybody have experience configuring L2TP (LNS on Cisco) using  
IPv6 instead of IPv4.

Thanks
Prabhu
-

From RPhookun at lecg.com  Thu Mar 19 20:00:56 2009
From: RPhookun at lecg.com (RPhookun at lecg.com)
Date: Thu, 19 Mar 2009 17:00:56 -0700
Subject: [c-nsp] Policy routing on a 3750 - What am I doing wrong?
In-Reply-To: <e58000750903191457s7e44278aka9c54b2d1cfac16e@mail.gmail.com>
Message-ID: <OFA1B6E1E7.D35E9A2F-ON8825757E.00828A42-8825757F.00004875@lecg.com>

Hello,
On the 3750: 
does an arp entry exist for 10.20.32.11?
What does *debug arp* on the 3750 look like when the ip nex-hop is changed 
to 10.20.32.11?
The vlans: separate physical access-ports or on a trunk?
 Does 10.20.32.11 has access to vlan 100?
Regards,
./Randy






Aaron Gifford <astounding at gmail.com> 
Sent by: cisco-nsp-bounces at puck.nether.net
03/19/2009 02:57 PM

To
cisco-nsp at puck.nether.net
cc

Subject
[c-nsp] Policy routing on a 3750 - What am I doing wrong?






Hi,


In trying to do some IP policy routing on a 3750, I ran into some odd
behavior.  I'd appreciate any pointers/help to get this working.

I have a pretty simple set-up.  A Cisco Catalyst 3750 switch running
IOS 12.2(46)SE connects a host IP network (10.20.30.0/24) on one VLAN
to an "upstream" network (10.20.32.0/24) on another VLAN.  All I want
to do is apply a route-map to policy route traffic that originates
from a subset of hosts (for the test, one host only) to a different
next-hop gateway on the "upstream" network.


HOST NETWORK 10.20.30.0/24 (VLAN 123):
10.20.30.1  <==  3750's interface IP on VLAN 123
...
10.20.30.94  <===  This is the test host whose traffic I want to policy 
route


UPSTREAM NETWORK 10.20.32.0/24 (VLAN 100):
10.20.32.1  <==  This is the normal upstream gateway router -- it
talks OSPF with the 3750
10.20.32.2  <==  3750's interface IP on VLAN 100
...
10.20.32.11  <==  The other upstream gateway device (no OSPF) to which
the policy should route traffic


THE 3750's CONFIGURATION SO FAR:
PBR (policy based routing) has been enabled on the 3750 running IOS
12.2(46)SE, and "sho sdm prefer" states that the current template is
the "desktop routing" template.

ACCESS LIST:
ip access-list extended delme
 permit ip host 10.20.30.94 any
!

ROUTE MAP:
route-map delme permit 10
 match ip address delme
 set ip next-hop 10.20.32.11
!

3750's HOST NETWORK VLAN INTERFACE:
interface Vlan123
 ip address 10.20.30.1 255.255.255.0
 ip policy route-map delme
end

3750's UPSTREAM NETWORK VLAN INTERFACE
intervace Vlan100
 ip address 10.20.32.2 255.255.255.0
 ***ospf configuration omitted***
end


TEST HOST AT 10.20.30.94:
The test host at 10.20.30.94 during testing was primarily sending ICMP
ECHO REQUESTs to remote IPs (networks NOT directly connected to the
3750).


WHAT I OBSERVED:
With debugging turned on, on the 3750 I would see:

Mar 19 15:05:34.960: IP: s=10.20.30.94 (Vlan123), d=255.255.255.255,
len 94, policy match
Mar 19 15:05:34.960: IP: route map delme, item 10, permit
Mar 19 15:05:34.968: IP: s=10.20.30.94 (Vlan123), d=255.255.255.255
(Vlan100), len 94, policy routed
Mar 19 15:05:34.968: IP: Vlan123 to Vlan100 10.20.32.11
...and other repeats of the above...


It appeared that broadcast traffic was happily matching my ACL and
being policy routed.  However, no non-broadcast traffic was matching,
or at least none was showing up with debugging.  Not one non-broadcast
packet.

When I checked the route-map and ACL counters on the router I saw:

router#sho route-map delme
route-map delme, permit, sequence 10
  Match clauses:
    ip address (access-lists): delme
  Set clauses:
    ip next-hop 10.20.32.11
Nexthop tracking current: 0.0.0.0
10.20.32.11, fib_nh:0,oce:0,status:0

  Policy routing matches: 23 packets, 2484 bytes
router#sho ip access-lists delme
Extended IP access list delme
    10 permit ip host 10.20.30.94 any (23 matches)
router#


Only 23 matching packets, over a time interval when thousands of ICMP
ECHO REQUESTs were sent.

So I checked things on the policy route's next-hop gateway device at
IP 10.20.32.11.  Its logs showed that NO packets had reached it.  And
on the 10.20.30.94 testing host saw no responses to the outbound
pings.

SO...

I reset the policy's next hop to 10.20.32.1 which is the normal
next-hop IP that non-policy-routed traffic is sent to:
route-map delme permit 10
 match ip address delme
 set ip next-hop 10.20.32.1
!

I repeated my test as above.  I saw the exact same behavior on the
3750, only broadcast packets matching in logs and ACL/route-map
counters.  But now the test host at 10.20.30.94 was getting all the
echo replies it should have.


WHAT I THINK THIS TELLS ME:
Even though the 3750 was NOT logging/debugging/counting packets from
the test host, it MUST have been doing something to those packets
because during the first test it appears it was NOT sending the
traffic to the normal gateway IP.  But it was also NOT sending it to
the policy-route next-hop gateway IP.  Once I changed the policy
route-map to set the next-hop to the same IP as non-policy routed
traffic, traffic from the test host DID seem to flow.

I'm confused.  Is the 3750 policy routing traffic, or not?  Why are
only packets to the 255.255.255.255 broadcast being matched?  What am
I doing wrong?

Thanks in advance for any/all help, advice, pointers, tips, etc.

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


From netsecuredata at gmail.com  Thu Mar 19 22:31:45 2009
From: netsecuredata at gmail.com (Jorge Evangelista)
Date: Thu, 19 Mar 2009 21:31:45 -0500
Subject: [c-nsp] [cisco-voip] I.B.M. Said to Be in Talks to Buy Sun for
	$7 Billion - NYTimes.com
In-Reply-To: <811956.96023.qm@web111308.mail.gq1.yahoo.com>
References: <1520194114.2701237472108234.JavaMail.root@simcoe.cs.uoguelph.ca>
	<854628.21085.qm@web111302.mail.gq1.yahoo.com>
	<49C2834C.6020302@thewybles.com>
	<811956.96023.qm@web111308.mail.gq1.yahoo.com>
Message-ID: <de85c96f0903191931i262e9b39kb234d198caef2699@mail.gmail.com>

There is a poll about matter.

http://gigaom.com/2009/03/18/why-cisco-not-ibm-should-buy-sun/

Regards



On Thu, Mar 19, 2009 at 12:45 PM, Paul <asobihoudai at yahoo.com> wrote:

>
> That's understood. Lelio said that he thought Cisco would fit well with
> Sun.
>
>
>
> ----- Original Message ----
> From: Charles Wyble <charles at thewybles.com>
> To: Paul <asobihoudai at yahoo.com>
>  Cc: Lelio Fulgenzi <lelio at uoguelph.ca>; cisco-voip voyp list <
> cisco-voip at puck.nether.net>
> Sent: Thursday, March 19, 2009 1:39:24 PM
> Subject: Re: [cisco-voip] I.B.M. Said to Be in Talks to Buy Sun for $7
> Billion - NYTimes.com
>
> Um.... Cisco isn't rumored to be buying Sun. IBM is rumored to be buying
> SUN.
>
> Paul wrote:
> > One problem I would see immediately would be that Sun just bought Innotek
> for a good sum and they seem to be pushing for their own virtualization
> methods. This would bump heads with Vmware, Cisco's virtualization partner,
> and could cause potential squabbles. Also I don't see Cisco moving their
> applications to Solaris x86 or SPARC after investing so much in Linux. While
> Sun is a big supporter of Linux, their baby is still Solaris.
> > I work with one of the original ActiveVoice folks and he said that
> working with Cisco after the purchase for a year was okay until he got a
> Cisco manager swapped in for his former ActiveVoice boss.
> >
> > Is Cisco becoming another inflexible, slow behemoth like Microsloth? One
> Cisco guy I spoke to casually voiced the worry that Cisco was becoming less
> of a "fun" place to work at.
> >
> > ------------------------------------------------------------------------
> > *From:* Lelio Fulgenzi <lelio at uoguelph.ca>
> > *To:* Paul <asobihoudai at yahoo.com>
> > *Cc:* cisco-voip voyp list <cisco-voip at puck.nether.net>
> > *Sent:* Thursday, March 19, 2009 10:15:08 AM
> > *Subject:* Re: [cisco-voip] I.B.M. Said to Be in Talks to Buy Sun for $7
> Billion - NYTimes.com
> >
> > I'm sure in the long list of companies acquired by Cisco, there have been
> cultural differences. I recall someone telling me once that when Cisco
> bought ActiveVoice there were plenty of differences. Something about a slide
> from the top floor into the office of one of the developers. ;)
> >
> > With Cisco's foray into blade computing, I would have thought this fit
> right in.
> >
> >
> > ----- Original Message -----
> > From: "Paul" <asobihoudai at yahoo.com>
> > To: lelio at uoguelph.ca, "cisco-voip voyp list" <
> cisco-voip at puck.nether.net>
> > Sent: Thursday, March 19, 2009 10:07:12 AM GMT -05:00 US/Canada Eastern
> > Subject: Re: [cisco-voip] I.B.M. Said to Be in Talks to Buy Sun for $7
> Billion - NYTimes.com
> >
> >
> > The companies couldn't be any more different in terms of culture. I could
> see the majority of Sun's brainpower jumping ship before the ink on the
> buying contract even dries.
> >
> > You don't see things like dtrace and ZFS coming out of IBM.
> > pathetic. . .
> >
> >
> >
> > ----- Original Message ----
> > From: "lelio at uoguelph.ca" <lelio at uoguelph.ca>
> > To: cisco-voip voyp list <cisco-voip at puck.nether.net>
> > Sent: Wednesday, March 18, 2009 6:57:42 PM
> > Subject: [cisco-voip] I.B.M. Said to Be in Talks to Buy Sun for $7
> Billion - NYTimes.com
> >
> > I'm surprised Cisco didn't go after this.
> >
> >
> http://www.nytimes.com/2009/03/19/technology/companies/19sun.html?ref=technology
> >
> >
> > Lelio Fulgenzi, Senior Analyst
> > Computing & Communications
> > University of Guelph
> > 519-824-4120 x56354
> >
> > ....sent from my iPod - please pardon my fat fingers ;)
> >
> > [XKJ2000]
> > _______________________________________________
> > cisco-voip mailing list
> > cisco-voip at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-voip
> >
> >
> >
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > cisco-voip mailing list
> > cisco-voip at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>



-- 
"The network is the computer"

From Stig.Johansen at atea.no  Fri Mar 20 03:59:19 2009
From: Stig.Johansen at atea.no (Stig Johansen)
Date: Fri, 20 Mar 2009 08:59:19 +0100
Subject: [c-nsp] Policy routing on a 3750 - What am I doing wrong?
In-Reply-To: <e58000750903191457s7e44278aka9c54b2d1cfac16e@mail.gmail.com>
References: <e58000750903191457s7e44278aka9c54b2d1cfac16e@mail.gmail.com>
Message-ID: <5EB9799F396A304686962AFFF740ED0CF0EA781B@NOOSLEXCH001.adno.local>

Aaron wrote:
>In trying to do some IP policy routing on a 3750, I ran into some odd
>behavior.  I'd appreciate any pointers/help to get this working.

First of all, the 3750's does most things in hardware, and this is as a "rule" not counted anywhere. You'll only see hits and counters moved when the CPU is being hit. Interface counters are another question as they are hardwired to count. Broadcasts are punted to the CPU, so that's to be expected.

If you want to see what's really going on (and thereby changing the mode of operation), you'll have to disable CEF and prepare yourself for slowness as all traffic will be punted to the CPU. Try this and verify that all is working first.

Best regards,
Stig Meireles Johansen

From zhqasmi at cyber.net.pk  Fri Mar 20 05:39:10 2009
From: zhqasmi at cyber.net.pk (Amjad Ul Hasnain Qasmi)
Date: Fri, 20 Mar 2009 14:39:10 +0500
Subject: [c-nsp] Policy routing on a 3750 - What am I doing wrong?
In-Reply-To: <e58000750903191457s7e44278aka9c54b2d1cfac16e@mail.gmail.com>
References: <e58000750903191457s7e44278aka9c54b2d1cfac16e@mail.gmail.com>
Message-ID: <004a01c9a93f$b9989c30$2cc9d490$@net.pk>

Can you send " show sdm prefer ". You would probably need routing-pbr or
route SDM template on your 3750 in order to support PBR.
http://www.cisco.com/en/US/products/hw/switches/ps5023/products_tech_note091
86a00801e7bb9.shtml



-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Aaron Gifford
Sent: Friday, March 20, 2009 2:57 AM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Policy routing on a 3750 - What am I doing wrong?

Hi,


In trying to do some IP policy routing on a 3750, I ran into some odd
behavior.  I'd appreciate any pointers/help to get this working.

I have a pretty simple set-up.  A Cisco Catalyst 3750 switch running
IOS 12.2(46)SE connects a host IP network (10.20.30.0/24) on one VLAN
to an "upstream" network (10.20.32.0/24) on another VLAN.  All I want
to do is apply a route-map to policy route traffic that originates
from a subset of hosts (for the test, one host only) to a different
next-hop gateway on the "upstream" network.


HOST NETWORK 10.20.30.0/24 (VLAN 123):
10.20.30.1  <==  3750's interface IP on VLAN 123
...
10.20.30.94  <===  This is the test host whose traffic I want to policy
route


UPSTREAM NETWORK 10.20.32.0/24 (VLAN 100):
10.20.32.1  <==  This is the normal upstream gateway router -- it
talks OSPF with the 3750
10.20.32.2  <==  3750's interface IP on VLAN 100
...
10.20.32.11  <==  The other upstream gateway device (no OSPF) to which
the policy should route traffic


THE 3750's CONFIGURATION SO FAR:
PBR (policy based routing) has been enabled on the 3750 running IOS
12.2(46)SE, and "sho sdm prefer" states that the current template is
the "desktop routing" template.

ACCESS LIST:
ip access-list extended delme
 permit ip host 10.20.30.94 any
!

ROUTE MAP:
route-map delme permit 10
 match ip address delme
 set ip next-hop 10.20.32.11
!

3750's HOST NETWORK VLAN INTERFACE:
interface Vlan123
 ip address 10.20.30.1 255.255.255.0
 ip policy route-map delme
end

3750's UPSTREAM NETWORK VLAN INTERFACE
intervace Vlan100
 ip address 10.20.32.2 255.255.255.0
 ***ospf configuration omitted***
end


TEST HOST AT 10.20.30.94:
The test host at 10.20.30.94 during testing was primarily sending ICMP
ECHO REQUESTs to remote IPs (networks NOT directly connected to the
3750).


WHAT I OBSERVED:
With debugging turned on, on the 3750 I would see:

Mar 19 15:05:34.960: IP: s=10.20.30.94 (Vlan123), d=255.255.255.255,
len 94, policy match
Mar 19 15:05:34.960: IP: route map delme, item 10, permit
Mar 19 15:05:34.968: IP: s=10.20.30.94 (Vlan123), d=255.255.255.255
(Vlan100), len 94, policy routed
Mar 19 15:05:34.968: IP: Vlan123 to Vlan100 10.20.32.11
...and other repeats of the above...


It appeared that broadcast traffic was happily matching my ACL and
being policy routed.  However, no non-broadcast traffic was matching,
or at least none was showing up with debugging.  Not one non-broadcast
packet.

When I checked the route-map and ACL counters on the router I saw:

router#sho route-map delme
route-map delme, permit, sequence 10
  Match clauses:
    ip address (access-lists): delme
  Set clauses:
    ip next-hop 10.20.32.11
Nexthop tracking current: 0.0.0.0
10.20.32.11, fib_nh:0,oce:0,status:0

  Policy routing matches: 23 packets, 2484 bytes
router#sho ip access-lists delme
Extended IP access list delme
    10 permit ip host 10.20.30.94 any (23 matches)
router#


Only 23 matching packets, over a time interval when thousands of ICMP
ECHO REQUESTs were sent.

So I checked things on the policy route's next-hop gateway device at
IP 10.20.32.11.  Its logs showed that NO packets had reached it.  And
on the 10.20.30.94 testing host saw no responses to the outbound
pings.

SO...

I reset the policy's next hop to 10.20.32.1 which is the normal
next-hop IP that non-policy-routed traffic is sent to:
route-map delme permit 10
 match ip address delme
 set ip next-hop 10.20.32.1
!

I repeated my test as above.  I saw the exact same behavior on the
3750, only broadcast packets matching in logs and ACL/route-map
counters.  But now the test host at 10.20.30.94 was getting all the
echo replies it should have.


WHAT I THINK THIS TELLS ME:
Even though the 3750 was NOT logging/debugging/counting packets from
the test host, it MUST have been doing something to those packets
because during the first test it appears it was NOT sending the
traffic to the normal gateway IP.  But it was also NOT sending it to
the policy-route next-hop gateway IP.  Once I changed the policy
route-map to set the next-hop to the same IP as non-policy routed
traffic, traffic from the test host DID seem to flow.

I'm confused.  Is the 3750 policy routing traffic, or not?  Why are
only packets to the 255.255.255.255 broadcast being matched?  What am
I doing wrong?

Thanks in advance for any/all help, advice, pointers, tips, etc.

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


From sam_mailinglists at spacething.org  Fri Mar 20 07:57:02 2009
From: sam_mailinglists at spacething.org (Sam Stickland)
Date: Fri, 20 Mar 2009 11:57:02 +0000
Subject: [c-nsp] Names of various cisco operating systems
Message-ID: <49C3848E.5040304@spacething.org>

Hi,

I'm in the middle of preparing a patch for SNMP::Info to detect the 
operating systems and versions running on a wider range of Cisco equipment.

It's left me somewhat stumped what to write in the "os" field for most 
of the devices below. IOS has a name, CatOS has a name, but what on 
earth is the operating system called on these:

Application Content Module
Firewall Services Module
ASA (version 8+)
Content Content Switch

I can obviously called them whatever I like (e.g. Os: CSS ; Version: 
7.50.0.04), but if there are offical names I'd like to use them.

Sam

From braaen at zcorum.com  Fri Mar 20 09:07:49 2009
From: braaen at zcorum.com (Brian Raaen)
Date: Fri, 20 Mar 2009 09:07:49 -0400
Subject: [c-nsp] Names of various cisco operating systems
In-Reply-To: <49C3848E.5040304@spacething.org>
References: <49C3848E.5040304@spacething.org>
Message-ID: <49C39525.10404@zcorum.com>

If you ftp to (ftp.cisco.com), you can download all Cisco's MIB data
over anonymous ftp.  They would be contained in those files. 
Alternately, you could try using the search function on Cisco's web site.--

-----------------
Brian Raaen
Network Engineer
email: /braaen at zcorum.com/ <mailto:braaen at zcorum.com>

Sam Stickland wrote:
> Hi,
>
> I'm in the middle of preparing a patch for SNMP::Info to detect the
> operating systems and versions running on a wider range of Cisco
> equipment.
>
> It's left me somewhat stumped what to write in the "os" field for most
> of the devices below. IOS has a name, CatOS has a name, but what on
> earth is the operating system called on these:
>
> Application Content Module
> Firewall Services Module
> ASA (version 8+)
> Content Content Switch
>
> I can obviously called them whatever I like (e.g. Os: CSS ; Version:
> 7.50.0.04), but if there are offical names I'd like to use them.
>
> Sam
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

From jimmy.changa007 at gmail.com  Fri Mar 20 10:10:02 2009
From: jimmy.changa007 at gmail.com (Jimmy Changa)
Date: Fri, 20 Mar 2009 10:10:02 -0400
Subject: [c-nsp] Sup720-3BXL and diag issues
In-Reply-To: <6edfd6c20903191106y75865506ub6eb313d66cd52af@mail.gmail.com>
References: <7cf54880903161240lb77d76l84b16ce7b3f9224d@mail.gmail.com>
	<20090316224745.GC9886@wildfire.net.ic.ac.uk>
	<7cf54880903181234t6fc7c6d8qac881d31c0f83778@mail.gmail.com>
	<6edfd6c20903191106y75865506ub6eb313d66cd52af@mail.gmail.com>
Message-ID: <7cf54880903200710p3352f64er8cc63560c330f4f6@mail.gmail.com>

I have three chassis with the same SUP and IOS revisions. 1 chassis seems to
fail the cards, the other 2 seem to have no problems with them.

I will reboot the problematic 6500 during a maintenance window.

On Thu, Mar 19, 2009 at 2:06 PM, Bob Snyder <rsnyder at toontown.erial.nj.us>wrote:

> On Wed, Mar 18, 2009 at 3:34 PM, Jimmy Changa <jimmy.changa007 at gmail.com
> >wrote:
>
> > Seems that all cards and in all slots seem to fail. Again, the same cards
> > work fine else were.
>
>
> Same version of IOS on this box as elsewhere? We've seen issues with
> linecards "failing" on an upgrade of 7600 code that are "fixed" if you fall
> back to the previous code. Cisco's stance is that they are in fact bad
> cards
> that the new diag tests or improved existing diag tests in the new IOS
> discovered, so we RMA'ed the cards.
>
> This problem is probably not the issue if you've tried multiple cards as is
> implied, but in case you hadn't...
>
> Bob
>  _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From petelists at templin.org  Fri Mar 20 09:56:06 2009
From: petelists at templin.org (Pete Templin)
Date: Fri, 20 Mar 2009 08:56:06 -0500
Subject: [c-nsp] BCP 38 on single-mode uRPF platforms?
In-Reply-To: <49C39BBB.5010106@thend.org>
References: <49C112CB.9020404@templin.org> <49C39BBB.5010106@thend.org>
Message-ID: <49C3A076.9070608@templin.org>

Jerimiah Cole wrote:
> Pete Templin wrote:
> ...
>  > I'm now leaning towards 'reachable-via any' on
>> all Internet customer ports, with per-port (per-customer) ACLs to 
>> prevent spoofing.
>>
>> Aside from having to maintain those per-port/per-customer ACLs and a 
>> risk to multi-homed customers if 'reachable-via rx' gets triggered 
>> accidentally,
> ...
> 
> For me, the biggest benefit of uRPF is not having to maintain the ACLs. 
>  I've seen at least one large transit provider that seems to run 
> 'reachable-via rx' on customer interfaces (or at least on interfaces 
> that I've connected to).  It also honors no-export, so there's only a 
> small loss of control.

You're right, uRPF (normally) means you don't have to maintain the ACLs.

However, on the Sup720, it doesn't behave the same.  If you configure 
one customer with 'ip ve u s r a allow-s' and then configure a second 
customer with 'ip ve u s r r allow-s', the BOX AS A WHOLE now applies 
the equivalent of 'ip ve u s r r allow-s' to all customers who have 'ip 
ve *' configured.  It's a global mode, even though it's specific 
commands.  The PFC isn't capable of applying different uRPF behaviors to 
the ports.  Therefore, I have a reasonably refined solution in mind (use 
uRPF in 'reachable-via any' so that all customers can at least come 
under the control of our centralized blackhole infrastructure, but 
multihomed customers can still send traffic they ought to be able to send.

pt


From jcartier at acs.on.ca  Fri Mar 20 10:18:32 2009
From: jcartier at acs.on.ca (Jeff Cartier)
Date: Fri, 20 Mar 2009 10:18:32 -0400
Subject: [c-nsp] QoS Questions
Message-ID: <BCD3E762F1767C42A5226BBACDE49BFBCE788E@loki.acs.local>

This question is in regards to QoS on a 3750...

 

If I'm trying to establish the PQ for Vlan2...and I have interfaces that
aren't in vlan 2, lets say they are an access-port in vlan 11...would
this interface configuration be correct or incorrect?

 

interface GigabitEthernet1/0/1

 description xxxxxxx

 switchport access vlan 11

 switchport mode access

 switchport nonegotiate

 no logging event link-status

 load-interval 30

 srr-queue bandwidth share 1 70 25 5

 srr-queue bandwidth shape  3  0  0  0

 priority-queue out

 mls qos trust cos

 spanning-tree portfast

 

Do I need to have the 'priority-queue out' command?  And do I need the
'srr-queue' commands even though traffic passing through this interface
is to one host and not needing LLQ?

 


From justin at justinshore.com  Fri Mar 20 11:38:01 2009
From: justin at justinshore.com (Justin Shore)
Date: Fri, 20 Mar 2009 10:38:01 -0500
Subject: [c-nsp] Names of various cisco operating systems
In-Reply-To: <49C3848E.5040304@spacething.org>
References: <49C3848E.5040304@spacething.org>
Message-ID: <49C3B859.4090609@justinshore.com>

SNMPv2-MIB::sysDescr.0 = STRING: Cisco Firewall Services Module Version 
3.2(10)

I can't get SNMP to work on a IDSM2 or I'd send you that output too.

Justin


Sam Stickland wrote:
> Hi,
> 
> I'm in the middle of preparing a patch for SNMP::Info to detect the 
> operating systems and versions running on a wider range of Cisco equipment.
> 
> It's left me somewhat stumped what to write in the "os" field for most 
> of the devices below. IOS has a name, CatOS has a name, but what on 
> earth is the operating system called on these:
> 
> Application Content Module
> Firewall Services Module
> ASA (version 8+)
> Content Content Switch
> 
> I can obviously called them whatever I like (e.g. Os: CSS ; Version: 
> 7.50.0.04), but if there are offical names I'd like to use them.
> 
> Sam
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

From sam_mailinglists at spacething.org  Fri Mar 20 12:07:13 2009
From: sam_mailinglists at spacething.org (Sam Stickland)
Date: Fri, 20 Mar 2009 16:07:13 +0000
Subject: [c-nsp] Names of various cisco operating systems
In-Reply-To: <49C3B859.4090609@justinshore.com>
References: <49C3848E.5040304@spacething.org>
	<49C3B859.4090609@justinshore.com>
Message-ID: <49C3BF31.8050707@spacething.org>

All,

I should clarify. I have access to all these types of devices, that's 
why I'm adding the support to SNMP:Info in the first place :)

"Cisco Firewall Services Module Version 3.2(10)" strikes me as just a 
description of the device, rather than containing an operating system name.

A Catalyst 4948 runs 'IOS', an Cat5500 ran 'CatOS', but an FWSM simply 
runs 'Version 3.2(10)'? Does the operating system itself actually have 
an offical name on these platforms? (e.g. once upon a time PIX's ran 
Finesse)

Sam

Justin Shore wrote:
> SNMPv2-MIB::sysDescr.0 = STRING: Cisco Firewall Services Module 
> Version 3.2(10)
>
> I can't get SNMP to work on a IDSM2 or I'd send you that output too.
>
> Justin
>
>
> Sam Stickland wrote:
>> Hi,
>>
>> I'm in the middle of preparing a patch for SNMP::Info to detect the 
>> operating systems and versions running on a wider range of Cisco 
>> equipment.
>>
>> It's left me somewhat stumped what to write in the "os" field for 
>> most of the devices below. IOS has a name, CatOS has a name, but what 
>> on earth is the operating system called on these:
>>
>> Application Content Module
>> Firewall Services Module
>> ASA (version 8+)
>> Content Content Switch
>>
>> I can obviously called them whatever I like (e.g. Os: CSS ; Version: 
>> 7.50.0.04), but if there are offical names I'd like to use them.
>>
>> Sam
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/


From justin at justinshore.com  Fri Mar 20 12:14:40 2009
From: justin at justinshore.com (Justin Shore)
Date: Fri, 20 Mar 2009 11:14:40 -0500
Subject: [c-nsp] Names of various cisco operating systems
In-Reply-To: <49C3BF31.8050707@spacething.org>
References: <49C3848E.5040304@spacething.org>
	<49C3B859.4090609@justinshore.com>
	<49C3BF31.8050707@spacething.org>
Message-ID: <49C3C0F0.2020708@justinshore.com>

Ah, I'm with you now.  I'll stop messing with these damn IDSM2s then. :-)

I don't know what their internal dev name would be but then again I 
seriously doubt if many other people using SNMP::Info would either. 
Were it me I think I'd name it something like this:

FWSM 3.2(10)
IDSM2 6.0(1)E1
ACE 3.0(0)A1(2)

To the best of my knowledge those platforms are unique enough to not be 
lumped in with something else.  Perhaps that IDSM2 could be lumped 
together with IDS/IPS appliances if they run the same code (I can't 
remember).  Those guys are unique.

That's my thought anyway
  Justin



Sam Stickland wrote:
> All,
> 
> I should clarify. I have access to all these types of devices, that's 
> why I'm adding the support to SNMP:Info in the first place :)
> 
> "Cisco Firewall Services Module Version 3.2(10)" strikes me as just a 
> description of the device, rather than containing an operating system name.
> 
> A Catalyst 4948 runs 'IOS', an Cat5500 ran 'CatOS', but an FWSM simply 
> runs 'Version 3.2(10)'? Does the operating system itself actually have 
> an offical name on these platforms? (e.g. once upon a time PIX's ran 
> Finesse)
> 
> Sam
> 
> Justin Shore wrote:
>> SNMPv2-MIB::sysDescr.0 = STRING: Cisco Firewall Services Module 
>> Version 3.2(10)
>>
>> I can't get SNMP to work on a IDSM2 or I'd send you that output too.
>>
>> Justin
>>
>>
>> Sam Stickland wrote:
>>> Hi,
>>>
>>> I'm in the middle of preparing a patch for SNMP::Info to detect the 
>>> operating systems and versions running on a wider range of Cisco 
>>> equipment.
>>>
>>> It's left me somewhat stumped what to write in the "os" field for 
>>> most of the devices below. IOS has a name, CatOS has a name, but what 
>>> on earth is the operating system called on these:
>>>
>>> Application Content Module
>>> Firewall Services Module
>>> ASA (version 8+)
>>> Content Content Switch
>>>
>>> I can obviously called them whatever I like (e.g. Os: CSS ; Version: 
>>> 7.50.0.04), but if there are offical names I'd like to use them.
>>>
>>> Sam
>>> _______________________________________________
>>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 

From jcole at thend.org  Fri Mar 20 12:34:36 2009
From: jcole at thend.org (Jerimiah Cole)
Date: Fri, 20 Mar 2009 10:34:36 -0600
Subject: [c-nsp] BCP 38 on single-mode uRPF platforms?
In-Reply-To: <49C112CB.9020404@templin.org>
References: <49C112CB.9020404@templin.org>
Message-ID: <49C3C59C.5080205@thend.org>

Pete Templin wrote:
...
> I'm now leaning towards 'reachable-via any' on
> all Internet customer ports, with per-port (per-customer) ACLs to 
> prevent spoofing.
> 
> Aside from having to maintain those per-port/per-customer ACLs and a 
> risk to multi-homed customers if 'reachable-via rx' gets triggered 
> accidentally,
...

For me, the biggest benefit of uRPF is not having to maintain the ACLs.
  I've seen at least one large transit provider that seems to run
'reachable-via rx' on customer interfaces (or at least on interfaces
that I've connected to).  It also honors no-export, so there's only a
small loss of control.


Jerimiah


From SHughes at GREnergy.com  Fri Mar 20 15:45:12 2009
From: SHughes at GREnergy.com (Hughes, Scott GRE/MG)
Date: Fri, 20 Mar 2009 14:45:12 -0500
Subject: [c-nsp] Odd log messages - Cisco 3200 router
Message-ID: <D72AC2E49DA8AB4195DF356ED05663DD27809AC95D@MNCMS01.intra.grenergy.com>

We have recently noticed a few of our 3200 routers spouting weird things to the log. No debugs are turned on, and no changes have been made lately.. 

Oddly, the times between the messages are 2 hours almost to the second.

Anyone ever seen this before?

Mar 20 03:01:51: PTABLE.0[0x1F]: <VLAN_TAG=0,SP_ST=0,PRT_DIS=0,JUMBO=0,RTAG=0,TGID=0,TRUNK=0,CPU=0,PTYPE=0,BPDU=0,PORT_BITMAP=0,MI=0,CML=0,UT_PORT_BITMAP=0,MOD_MAP=0,DSCP=0,DSE_MODE=0,RPE=0,PRI=0,L3_DIS=0,MUST_BE_ONES=0x800000>
Mar 20 03:01:51: VTABLE.0[0x1]: <VLAN_TAG=1,PORT_BITMAP=0x800000C,UT_PORT_BITMAP=0xC,MOD_BMAP=0>
Mar 20 03:01:51: VTABLE.0[0x2]: <VLAN_TAG=0xFFF,PORT_BITMAP=0x8000000,UT_PORT_BITMAP=0x8000000,MOD_BMAP=0>
Mar 20 03:01:51: PTABLE.0[0x0]: <VLAN_TAG=1,SP_ST=3,PRT_DIS=0,JUMBO=0,RTAG=0,TGID=0,TRUNK=0,CPU=0,PTYPE=1,BPDU=0,PORT_BITMAP=0x8000000,MI=0,CML=0,UT_PORT_BITMAP=0,MOD_MAP=0,DSCP=0,DSE_MODE=0,RPE=0,PRI=0,L3_DIS=0,MUST_BE_ONES=0x1FFFFFFF>
Mar 20 05:01:51: PTABLE.0[0x1]: <VLAN_TAG=1,SP_ST=3,PRT_DIS=0,JUMBO=0,RTAG=0,TGID=0,TRUNK=0,CPU=0,PTYPE=1,BPDU=0,PORT_BITMAP=0x8000000,MI=0,CML=0,UT_PORT_BITMAP=0,MOD_MAP=0,DSCP=0,DSE_MODE=0,RPE=0,PRI=0,L3_DIS=0,MUST_BE_ONES=0x1FFFFFFF>
Mar 20 05:01:51: PTABLE.0[0x2]: <VLAN_TAG=1,SP_ST=3,PRT_DIS=0,JUMBO=0,RTAG=0,TGID=0,TRUNK=0,CPU=0,PTYPE=1,BPDU=0,PORT_BITMAP=0x800000C,MI=0,CML=0,UT_PORT_BITMAP=0xC,MOD_MAP=0,DSCP=0,DSE_MODE=0,RPE=0,PRI=0,L3_DIS=0,MUST_BE_ONES=0x1FFFFFFF>
Mar 20 05:01:51: PTABLE.0[0x3]: <VLAN_TAG=1,SP_ST=3,PRT_DIS=0,JUMBO=0,RTAG=0,TGID=0,TRUNK=0,CPU=0,PTYPE=1,BPDU=0,PORT_BITMAP=0x800000C,MI=0,CML=0,UT_PORT_BITMAP=0xC,MOD_MAP=0,DSCP=0,DSE_MODE=0,RPE=0,PRI=0,L3_DIS=0,MUST_BE_ONES=0x1FFFFFFF>
Mar 20 05:01:51: PTABLE.0[0x4]: <VLAN_TAG=1,SP_ST=0,PRT_DIS=0,JUMBO=0,RTAG=0,TGID=0,TRUNK=0,CPU=0,PTYPE=1,BPDU=0,PORT_BITMAP=0x8000000,MI=0,CML=0,UT_PORT_BITMAP=0,MOD_MAP=0,DSCP=0,DSE_MODE=0,RPE=0,PRI=0,L3_DIS=0,MUST_BE_ONES=0x1FFFFFFF>
Mar 20 05:01:51: PTABLE.0[0x5]: <VLAN_TAG=1,SP_ST=3,PRT_DIS=0,JUMBO=0,RTAG=0,TGID=0,TRUNK=0,CPU=0,PTYPE=1,BPDU=0,PORT_BITMAP=0x8000000,MI=0,CML=2,UT_PORT_BITMAP=0,MOD_MAP=0,DSCP=0,DSE_MODE=0,RPE=0,PRI=0,L3_DIS=0,MUST_BE_ONES=0x1FFFFFFF>
Mar 20 05:01:51: PTABLE.0[0x6]: <VLAN_TAG=1,SP_ST=0,PRT_DIS=0,JUMBO=0,RTAG=0,TGID=0,TRUNK=0,CPU=0,PTYPE=1,BPDU=0,PORT_BITMAP=0x8000000,MI=0,CML=0,UT_PORT_BITMAP=0,MOD_MAP=0,DSCP=0,DSE_MODE=0,RPE=0,PRI=0,L3_DIS=0,MUST_BE_ONES=0x1FFFFFFF>
Mar 20 05:01:51: PTABLE.0[0x7]: <VLAN_TAG=1,SP_ST=0,PRT_DIS=0,JUMBO=0,RTAG=0,TGID=0,TRUNK=0,CPU=0,PTYPE=1,BPDU=0,PORT_BITMAP=0x8000000,MI=0,CML=0,UT_PORT_BITMAP=0,MOD_MAP=0,DSCP=0,DSE_MODE=0,RPE=0,PRI=0,L3_DIS=0,MUST_BE_ONES=0x1FFFFFFF>
Mar 20 05:01:51: PTABLE.0[0x8]: <VLAN_TAG=1,SP_ST=0,PRT_DIS=0,JUMBO=0,RTAG=0,TGID=0,TRUNK=0,CPU=0,PTYPE=1,BPDU=0,PORT_BITMAP=0x8000000,MI=0,CML=0,UT_PORT_BITMAP=0,MOD_MAP=0,DSCP=0,DSE_MODE=0,RPE=0,PRI=0,L3_DIS=0,MUST_BE_ONES=0x1FFFFFFF>


-- 
Scott Hughes
Sr. Network Engineer
Great River Energy
shughes at grenergy.com


From kwoody at citytel.net  Fri Mar 20 20:25:52 2009
From: kwoody at citytel.net (Keith)
Date: Fri, 20 Mar 2009 16:25:52 -0800 (PST)
Subject: [c-nsp] Cache Flow
Message-ID: <20090320161735.W16128@pop.citytel.net>


How much cpu load does enabling ip route-cache flow on an interface put on
a router?

Have a 7206vxr with 256M of ram. Runs BGP, but we only take a default
route from that particular upstream, not full or partial tables.

Router peaks out about 300Meg of traffic total in/out with the cpu topping
out around 45-50%.

I don't want to export the flows, but at least get an idea of the flows
on the router using sho ip cache flow.

Software running on this router is (C7200-IS-M), Version 12.3(15).

Thanks,
Keith




From jarruda-cnsp at jarruda.com  Fri Mar 20 21:39:02 2009
From: jarruda-cnsp at jarruda.com (Julio Arruda)
Date: Fri, 20 Mar 2009 21:39:02 -0400
Subject: [c-nsp] Cache Flow
In-Reply-To: <20090320161735.W16128@pop.citytel.net>
References: <20090320161735.W16128@pop.citytel.net>
Message-ID: <49C44536.7080706@jarruda.com>

Keith wrote:
> How much cpu load does enabling ip route-cache flow on an interface put on
> a router?
> 
> Have a 7206vxr with 256M of ram. Runs BGP, but we only take a default
> route from that particular upstream, not full or partial tables.
> 
> Router peaks out about 300Meg of traffic total in/out with the cpu topping
> out around 45-50%.
> 
> I don't want to export the flows, but at least get an idea of the flows
> on the router using sho ip cache flow.
> 
> Software running on this router is (C7200-IS-M), Version 12.3(15).


http://www.cisco.com/en/US/technologies/tk543/tk812/technologies_white_paper0900aecd802a0eb9_ps6601_Products_White_Paper.html

Should give you some reference on this, for just enabling flow, not 
exporting, NF-enable should be the 'keyword'.


From networkstuff.training at gmail.com  Sat Mar 21 04:34:28 2009
From: networkstuff.training at gmail.com (Swati Sharma)
Date: Sat, 21 Mar 2009 14:04:28 +0530
Subject: [c-nsp] isis adjecency...
Message-ID: <8a93d4b30903210134pdbb1596hb1d8c53e6b1fcc1e@mail.gmail.com>

Hi,

I have below topology..

6500 --- 3750 --- crs1

@ 6500 I have created vlan 250, which i am trying to establish isis adj with
one of the sub-interface in crs. From 6500 to 3750 i have created trunk and
allowed vlan 250. Similarly a trunk between 3750 to crs1 (Tengig
subinterface). MTU on 3750 is 9k byte. I am not able to establish isis
adjcency.

I know the issue is with mtu as i checked with enabling ospf and ignore mtu.
But not able to rectify the issue..

6500#debug isis adj-packets vlan 250
IS-IS Adjacency related packets debugging is on
*Mar 21 08:11:32.384 UTC: ISIS-Adj: Sending serial IIH on Vlan250, length
1508
*Mar 21 08:11:34.772 UTC: ISIS-Adj: Sending serial IIH on Vlan250, length
1508
*Mar 21 08:11:37.496 UTC: ISIS-Adj: Sending serial IIH on Vlan250, length
1508
*Mar 21 08:11:40.360 UTC: ISIS-Adj: Sending serial IIH on Vlan250, length
1508
*Mar 21 08:11:42.684 UTC: ISIS-Adj: Sending serial IIH on Vlan250, length
1508

also it is not accepting - hello-password text

RP/0/RP0/CPU0:crs1.LAB(config)#router isis XXX
RP/0/RP0/CPU0:crs1.LAB(config-isis)#interface TenGigE0/1/2/0.250
RP/0/RP0/CPU0:crs1.LAB(config-isis-if)#hello-password text encrypted XXXYYY
RP/0/RP0/CPU0:crs1.LAB(config-isis-if)#commit
% Failed to commit one or more configuration items during an atomic
operation, no changes have been made. Please use 'show configuration failed'
to view the errors

@crs1 - sh int TenGigE0/1/2/0.250
TenGigE0/1/2/0.250 is up, line protocol is up
  Interface state transitions: 3
  Hardware is VLAN sub-interface(s), address is 001e.f73d.79b1
  Internet address is 10.74.66.30/31
  MTU 1530 bytes, BW 10000000 Kbit
     reliability 255/255, txload 0/255, rxload 0/255
  Encapsulation 802.1Q Virtual LAN, VLAN Id 250,  loopback not set,
  ARP type ARPA, ARP timeout 04:00:00
  Last clearing of "show interface" counters never
  5 minute input rate 5000 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     196299 packets input, 110348088 bytes, 0 total input drops
     0 drops for unrecognized upper-level protocol
     Received 2 broadcast packets, 196073 multicast packets
     258 packets output, 16772 bytes, 0 total output drops
     Output 12 broadcast packets, 63 multicast packets


any idea where is the issue ....it was working fine when i established isis
adj with 6500 physical interface...

Regards,

From blahu77 at gmail.com  Sat Mar 21 08:57:06 2009
From: blahu77 at gmail.com (Mateusz Blaszczyk)
Date: Sat, 21 Mar 2009 12:57:06 +0000 (IST)
Subject: [c-nsp] isis adjecency...
In-Reply-To: <8a93d4b30903210134pdbb1596hb1d8c53e6b1fcc1e@mail.gmail.com>
Message-ID: <fskb1awq4bl56u5tkrUYAxe124vaj_firegpg@mail.gmail.com>

Swati,

> 6500#debug isis adj-packets vlan 250
> IS-IS Adjacency related packets debugging is on
> *Mar 21 08:11:32.384 UTC: ISIS-Adj: Sending serial IIH on Vlan250, length
> 1508

you are sending serial iih from 6500 side

> any idea where is the issue ....it was working fine when i established isis
> adj with 6500 physical interface...

that might point to ptp versus lan network type.
have you configured vlan with #isis network point-to-point# ?
what is the config on 6500 and crs side?
can you set up matching mtu on both sides? 
the isis won't go up unless it's matching.

> also it is not accepting - hello-password text
>
> RP/0/RP0/CPU0:crs1.LAB(config)#router isis XXX
> RP/0/RP0/CPU0:crs1.LAB(config-isis)#interface TenGigE0/1/2/0.250
> RP/0/RP0/CPU0:crs1.LAB(config-isis-if)#hello-password text encrypted XXXYYY
> RP/0/RP0/CPU0:crs1.LAB(config-isis-if)#commit
> % Failed to commit one or more configuration items during an atomic
> operation, no changes have been made. Please use 'show configuration failed'
> to view the errors

what does #show configuration failed# show?


Best Regards,

-mat

-- 
pgp-key 0x1C655CAB

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090321/bb9a639e/attachment-0001.bin>

From bdikici at gmail.com  Sat Mar 21 11:19:16 2009
From: bdikici at gmail.com (Burak Dikici)
Date: Sat, 21 Mar 2009 17:19:16 +0200
Subject: [c-nsp] BGP conditional advertisemet - NON-EXIST route
	map'saccess-list problem
In-Reply-To: <d9281f5c0903190548k66696a79sf09264522e6766fb@mail.gmail.com>
References: <00a201c9a746$2d7f5a40$0a00000a@nil.si>
	<OF694CC1E4.1EAB3DA0-ON8825757C.007916C7-8825757C.00797570@lecg.com>
	<d9281f5c0903190548k66696a79sf09264522e6766fb@mail.gmail.com>
Message-ID: <d9281f5c0903210819j6af8e9b1s9ddc3dd6f81c1ad0@mail.gmail.com>

  Hello ,

 The main problem is which prefix should i track ? I can't use the
infrastructe subnet between my router and ISP-1 router , because it is
directly connected and it is in the routing table , not in the bgp table.
I was thinking on that , then i have decided to use reliable root DNS
servers subnets to track with acl or prefix-list , for example ;

access-list 20 permit 198.41.0.0 0.0.0.255 /* a.root-servers.net */
access-list 20 permit 192.228.79.0 0.0.0.255 /* b.root-servers.net */
access-list 20 permit 192.33.4.0 0.0.0.255 /* c.root-servers.net */
access-list 20 permit 128.8.0.0 0.0.255.255 /* d.root-servers.net */

what do you think about this idea ?

Burak Dikici




On Thu, Mar 19, 2009 at 2:48 PM, Burak Dikici <bdikici at gmail.com> wrote:

>  Sorry about my late reply. I am very busy these days with another project.
> I am going to test your recommendations in a few days , and going to reply
> back to you. Thank you all. Kind Regards...
>
> Burak Dikici
>
>
>
> On Wed, Mar 18, 2009 at 12:04 AM, <RPhookun at lecg.com> wrote:
>
>>
>> The prefix-list within the Non-Exist clause also has to *exactly* match
>> the prefix in the bgp table..
>> Regards,
>> ./Randy
>>
>>
>>
>>
>>   *"Ivan Pepelnjak" <ip at ioshints.info>*
>> Sent by: cisco-nsp-bounces at puck.nether.net
>>
>> 03/17/2009 02:20 PM
>>    To
>> "'Dale Shaw'" <dale.shaw+cisco-nsp at gmail.com<dale.shaw%2Bcisco-nsp at gmail.com>>,
>> "'Burak Dikici'" <bdikici at gmail.com>  cc
>>   cisco-nsp at puck.nether.net  Subject
>> Re: [c-nsp] BGP conditional advertisemet - NON-EXIST route
>>  map'saccess-list problem
>>
>>
>>
>>
>>
>>  Did some tests on the NON-EXIST-MAP with 12.2SRC. I was spreading wrong
>> rumors, time to fix them:
>>
>> * The route-map checks the routes in the BGP table (_not_ in the IP
>> routing
>> table). Dale was right.
>> * It can take a while for the routes to be advertised/withdrawn; the
>> non-exist-map is checked only at the BGP scan intervals (60 seconds by
>> default, can be adjusted).
>> * You can use a combination of an access-list and AS-path access-list in
>> the
>> route-map.
>>
>> The handling of standard access-lists used in the "match ip address"
>> route-map condition is a bit weird, though:
>>
>> * "permit any" does _NOT_ work.
>> * "permit prefix 0.0.0.0" (which gets translated into "permit prefix" in
>> standard ACL) does _NOT_ work.
>> * fancy wildcard tests (for example "permit 0.0.0.0 127.255.255.255) do
>> _NOT_ work
>>
>> It looks like:
>>
>> * the IP prefix in the BGP table must match the address in the ACL exactly
>> (wildcard bits are ignored).
>> * ... but you still need the wildcard bits (inverted netmask) for the
>> match
>> to work.
>>
>> For example: if you want to match 10.8.8.0/24, you have to use "permit
>> 10.8.8.0 0.0.0.255". "permit 10.8.8.0" or "permit 10.8.0.0 0.0.255.255" do
>> _NOT_ work.
>>
>> Left to do: tests with the ip prefix-list instead of IP access list (and
>> no,
>> I will NOT test extended ACL :).
>>
>> Hope this helps
>> Ivan
>>
>> > -----Original Message-----
>> > From: Dale Shaw [mailto:dale.shaw+cisco-nsp at gmail.com<dale.shaw%2Bcisco-nsp at gmail.com>]
>>
>> > Sent: Sunday, March 15, 2009 11:33 PM
>> > To: Burak Dikici
>> > Cc: cisco-nsp at puck.nether.net
>> > Subject: Re: [c-nsp] BGP conditional advertisemet - NON-EXIST
>> > route map'saccess-list problem
>> >
>> > Hi Burak,
>> >
>> > On Mon, Mar 16, 2009 at 12:06 AM, Burak Dikici
>> > <bdikici at gmail.com> wrote:
>> > > i am trying to use
>> > > BGP conditional advertisemet configuration. I have got a
>> > problem with
>> > > NON-EXIST route map's access-list. In the NON-EXIST router map i am
>> > > using the commands which is written below ;
>> >
>> > Here are some notes I made recently when playing with BGP
>> > conditional advertising. I hope it helps.
>> >
>> > 1.) prefixes matched in advertise-map and exist/non-exist map
>> > must exist (or not) in the *BGP* table
>> >  however: they do not need to be locally originated (e.g. R1
>> > can match routes received from R2 and advertise (or not) to R3
>> >  and: the validity of the prefix in the BGP table (i.e.
>> > RIB-failure) doesn't matter. if there's there, and using
>> > exist-map, the condition is met.
>> >
>> > 2.) when using 'exist' map, prefixes matched by advertise-map
>> > are advertised when exist-map condition is met
>> >  example: advertise 1.0.0.0/8 (advertise-map) from BGP table when
>> > 3.20.20.0/24 (exist-map) exists in BGP table
>> >
>> > 3.) when exist 'non-exist' map, prefixes matched by
>> > advertise-map are advertised when non-exist-map condition is met
>> >  example: advertise 1.0.0.0/8 (advertise-map) from BGP table when
>> > 3.20.20.0/24 (non-exist-map) does NOT exist in BGP table
>> >
>> > 4.) prefixes matched in advertise-map are the only prefixes
>> > affected -- other prefixes that may exist are advertised (or
>> > not) as normal
>> >
>> > 5.) when dealing with conditional advertisement tasks, always
>> > consider what will happen normally (without any config)
>> >
>> > I'd be happy to be corrected, but I think the first point is
>> > contrary to what Ivan said. Also consider point #4 -- BGP
>> > conditional advertising is not strictly a route filtering
>> > mechanism, although it can be configured to achieve similar results.
>> >
>> > cheers,
>> > Dale
>> >
>> >
>>
>> _______________________________________________
>> cisco-nsp mailing list  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  Sat Mar 21 11:01:29 2009
From: arla at rn.dk (Arne Larsen / Region Nordjylland)
Date: Sat, 21 Mar 2009 16:01:29 +0100
Subject: [c-nsp] Freeware management software
Message-ID: <8D68760F464FFD40A01BF2FB374E4A280165526EF871@SRVEXC02.aas.its.nja.dk>

Hi Folks.

Can someone give me a hint, I?m looking for freeware management software like NMIS.
Software that can provide reachability, availablility an health scores.
NMIS Dashboard doesn?t seem to scale in large network.
I like the dashboard off NMIS, it?s easy for anyone to understand the red & green function..
But it can?t discover devices, it?s a static configuration imnplementing NMIS.
Does anyone know off freeware software ala HP Openview.


/Arne

From r.engehausen at gmail.com  Sat Mar 21 12:08:37 2009
From: r.engehausen at gmail.com (Roy)
Date: Sat, 21 Mar 2009 09:08:37 -0700
Subject: [c-nsp] Freeware management software
In-Reply-To: <8D68760F464FFD40A01BF2FB374E4A280165526EF871@SRVEXC02.aas.its.nja.dk>
References: <8D68760F464FFD40A01BF2FB374E4A280165526EF871@SRVEXC02.aas.its.nja.dk>
Message-ID: <49C51105.3050205@gmail.com>

Opsview???

http://www.opsview.org

Arne Larsen / Region Nordjylland wrote:
> Hi Folks.
>
> Can someone give me a hint, I?m looking for freeware management software like NMIS.
> Software that can provide reachability, availablility an health scores.
> NMIS Dashboard doesn?t seem to scale in large network.
> I like the dashboard off NMIS, it?s easy for anyone to understand the red & green function..
> But it can?t discover devices, it?s a static configuration imnplementing NMIS.
> Does anyone know off freeware software ala HP Openview.
>
>
> /Arne
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>   


From andy.bierlair at root.lu  Sat Mar 21 13:33:39 2009
From: andy.bierlair at root.lu (Andy BIERLAIR)
Date: Sat, 21 Mar 2009 18:33:39 +0100
Subject: [c-nsp] Changing SSH Port on IOS
Message-ID: <000001c9aa4b$2cd20400$86760c00$@bierlair@root.lu>

I'm running s72033-ipservicesk9-mz.122-18.SXF15a with SSH on Port 22.

Due too many bots hammering that well-known port, I wanted to change it to
something else, but somehow I can't:

Router(config)#ip ssh port
                   ^
% Invalid input detected at '^' marker.

Router(config)#ip ssh ?   
  authentication-retries  Specify number of authentication retries
  source-interface        Specify interface for source address in SSH
connections
  time-out                Specify SSH time-out interval
  version                 Specify protocol version supported

#sh ip ssh
SSH Enabled - version 1.99
Authentication timeout: 120 secs; Authentication retries: 3

Did I miss something are is it really not possible to change the SSH port to
something less obvious than 22?


-
Andy



From charles at thewybles.com  Sat Mar 21 13:45:19 2009
From: charles at thewybles.com (Charles Wyble)
Date: Sat, 21 Mar 2009 10:45:19 -0700
Subject: [c-nsp] Changing SSH Port on IOS
In-Reply-To: <000001c9aa4b$2cd20400$86760c00$@bierlair@root.lu>
References: <000001c9aa4b$2cd20400$86760c00$@bierlair@root.lu>
Message-ID: <49C527AF.7010108@thewybles.com>

Um..... why don't you setup some ACL to limit access? It's generally ill 
advised to run dameons with shell access directly connected to the 
internet. :)

I use OpenVPN for all my access, and only run SSH on the private 
interface. I realize this isn't always possible, but is a good solution.

Andy BIERLAIR wrote:
> I'm running s72033-ipservicesk9-mz.122-18.SXF15a with SSH on Port 22.
> 
> Due too many bots hammering that well-known port, I wanted to change it to
> something else, but somehow I can't:
> 
> Router(config)#ip ssh port
>                    ^
> % Invalid input detected at '^' marker.
> 
> Router(config)#ip ssh ?   
>   authentication-retries  Specify number of authentication retries
>   source-interface        Specify interface for source address in SSH
> connections
>   time-out                Specify SSH time-out interval
>   version                 Specify protocol version supported
> 
> #sh ip ssh
> SSH Enabled - version 1.99
> Authentication timeout: 120 secs; Authentication retries: 3
> 
> Did I miss something are is it really not possible to change the SSH port to
> something less obvious than 22?
> 
> 
> -
> Andy
> 
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 

From charles at thewybles.com  Sat Mar 21 13:50:04 2009
From: charles at thewybles.com (Charles Wyble)
Date: Sat, 21 Mar 2009 10:50:04 -0700
Subject: [c-nsp] Freeware management software
In-Reply-To: <49C51105.3050205@gmail.com>
References: <8D68760F464FFD40A01BF2FB374E4A280165526EF871@SRVEXC02.aas.its.nja.dk>
	<49C51105.3050205@gmail.com>
Message-ID: <49C528CC.30108@thewybles.com>

Yep Opsview is nice.

Also check out http://www.ossec.net/ and http://www.ntop.org/news.html

Roy wrote:
> Opsview???
> 
> http://www.opsview.org
> 
> Arne Larsen / Region Nordjylland wrote:
>> Hi Folks.
>>
>> Can someone give me a hint, I?m looking for freeware management software like NMIS.
>> Software that can provide reachability, availablility an health scores.
>> NMIS Dashboard doesn?t seem to scale in large network.
>> I like the dashboard off NMIS, it?s easy for anyone to understand the red & green function..
>> But it can?t discover devices, it?s a static configuration imnplementing NMIS.
>> Does anyone know off freeware software ala HP Openview.
>>
>>
>> /Arne
>> _______________________________________________
>> cisco-nsp mailing 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 RPhookun at lecg.com  Sat Mar 21 14:12:54 2009
From: RPhookun at lecg.com (RPhookun at lecg.com)
Date: Sat, 21 Mar 2009 11:12:54 -0700
Subject: [c-nsp] BGP conditional advertisemet - NON-EXIST
 route	map'saccess-list problem
In-Reply-To: <d9281f5c0903210819j6af8e9b1s9ddc3dd6f81c1ad0@mail.gmail.com>
Message-ID: <OF87636C26.F4C6D537-ON88257580.0061B464-88257580.0064416E@lecg.com>

Hi Burak,

I had replied with the *fix* some days ago - 
You can still use the ISP-1 infrastructrure /24. You have to have the 
ISP-1 router announce the /24 to router# 
As you probably realise, this announcement is not required for the peering 
session *itself* to be up.

The annoucement by ISP-1 router of this /24 will cause it to appear in 
router#'s bgp table which you can then use as the tracked prefix.

Router#'s routing table will always install only the *connected*(d-0) 
version of this /24 which is what you want! The eBGP version(d-20) will 
exist only in the bgp table as a valid prefix you can track.

Hope this helps.
./Randy




Burak Dikici <bdikici at gmail.com> 
Sent by: cisco-nsp-bounces at puck.nether.net
03/21/2009 08:19 AM

To
RPhookun at lecg.com, ip at ioshints.info
cc
cisco-nsp-bounces at puck.nether.net, cisco-nsp at puck.nether.net
Subject
Re: [c-nsp] BGP conditional advertisemet - NON-EXIST route 
map'saccess-list problem






  Hello ,

 The main problem is which prefix should i track ? I can't use the
infrastructe subnet between my router and ISP-1 router , because it is
directly connected and it is in the routing table , not in the bgp table.
I was thinking on that , then i have decided to use reliable root DNS
servers subnets to track with acl or prefix-list , for example ;

access-list 20 permit 198.41.0.0 0.0.0.255 /* a.root-servers.net */
access-list 20 permit 192.228.79.0 0.0.0.255 /* b.root-servers.net */
access-list 20 permit 192.33.4.0 0.0.0.255 /* c.root-servers.net */
access-list 20 permit 128.8.0.0 0.0.255.255 /* d.root-servers.net */

what do you think about this idea ?

Burak Dikici




On Thu, Mar 19, 2009 at 2:48 PM, Burak Dikici <bdikici at gmail.com> wrote:

>  Sorry about my late reply. I am very busy these days with another 
project.
> I am going to test your recommendations in a few days , and going to 
reply
> back to you. Thank you all. Kind Regards...
>
> Burak Dikici
>
>
>
> On Wed, Mar 18, 2009 at 12:04 AM, <RPhookun at lecg.com> wrote:
>
>>
>> The prefix-list within the Non-Exist clause also has to *exactly* match
>> the prefix in the bgp table..
>> Regards,
>> ./Randy
>>
>>
>>
>>
>>   *"Ivan Pepelnjak" <ip at ioshints.info>*
>> Sent by: cisco-nsp-bounces at puck.nether.net
>>
>> 03/17/2009 02:20 PM
>>    To
>> "'Dale Shaw'" 
<dale.shaw+cisco-nsp at gmail.com<dale.shaw%2Bcisco-nsp at gmail.com>>,
>> "'Burak Dikici'" <bdikici at gmail.com>  cc
>>   cisco-nsp at puck.nether.net  Subject
>> Re: [c-nsp] BGP conditional advertisemet - NON-EXIST route
>>  map'saccess-list problem
>>
>>
>>
>>
>>
>>  Did some tests on the NON-EXIST-MAP with 12.2SRC. I was spreading 
wrong
>> rumors, time to fix them:
>>
>> * The route-map checks the routes in the BGP table (_not_ in the IP
>> routing
>> table). Dale was right.
>> * It can take a while for the routes to be advertised/withdrawn; the
>> non-exist-map is checked only at the BGP scan intervals (60 seconds by
>> default, can be adjusted).
>> * You can use a combination of an access-list and AS-path access-list 
in
>> the
>> route-map.
>>
>> The handling of standard access-lists used in the "match ip address"
>> route-map condition is a bit weird, though:
>>
>> * "permit any" does _NOT_ work.
>> * "permit prefix 0.0.0.0" (which gets translated into "permit prefix" 
in
>> standard ACL) does _NOT_ work.
>> * fancy wildcard tests (for example "permit 0.0.0.0 127.255.255.255) do
>> _NOT_ work
>>
>> It looks like:
>>
>> * the IP prefix in the BGP table must match the address in the ACL 
exactly
>> (wildcard bits are ignored).
>> * ... but you still need the wildcard bits (inverted netmask) for the
>> match
>> to work.
>>
>> For example: if you want to match 10.8.8.0/24, you have to use "permit
>> 10.8.8.0 0.0.0.255". "permit 10.8.8.0" or "permit 10.8.0.0 0.0.255.255" 
do
>> _NOT_ work.
>>
>> Left to do: tests with the ip prefix-list instead of IP access list 
(and
>> no,
>> I will NOT test extended ACL :).
>>
>> Hope this helps
>> Ivan
>>
>> > -----Original Message-----
>> > From: Dale Shaw 
[mailto:dale.shaw+cisco-nsp at gmail.com<dale.shaw%2Bcisco-nsp at gmail.com>]
>>
>> > Sent: Sunday, March 15, 2009 11:33 PM
>> > To: Burak Dikici
>> > Cc: cisco-nsp at puck.nether.net
>> > Subject: Re: [c-nsp] BGP conditional advertisemet - NON-EXIST
>> > route map'saccess-list problem
>> >
>> > Hi Burak,
>> >
>> > On Mon, Mar 16, 2009 at 12:06 AM, Burak Dikici
>> > <bdikici at gmail.com> wrote:
>> > > i am trying to use
>> > > BGP conditional advertisemet configuration. I have got a
>> > problem with
>> > > NON-EXIST route map's access-list. In the NON-EXIST router map i am
>> > > using the commands which is written below ;
>> >
>> > Here are some notes I made recently when playing with BGP
>> > conditional advertising. I hope it helps.
>> >
>> > 1.) prefixes matched in advertise-map and exist/non-exist map
>> > must exist (or not) in the *BGP* table
>> >  however: they do not need to be locally originated (e.g. R1
>> > can match routes received from R2 and advertise (or not) to R3
>> >  and: the validity of the prefix in the BGP table (i.e.
>> > RIB-failure) doesn't matter. if there's there, and using
>> > exist-map, the condition is met.
>> >
>> > 2.) when using 'exist' map, prefixes matched by advertise-map
>> > are advertised when exist-map condition is met
>> >  example: advertise 1.0.0.0/8 (advertise-map) from BGP table when
>> > 3.20.20.0/24 (exist-map) exists in BGP table
>> >
>> > 3.) when exist 'non-exist' map, prefixes matched by
>> > advertise-map are advertised when non-exist-map condition is met
>> >  example: advertise 1.0.0.0/8 (advertise-map) from BGP table when
>> > 3.20.20.0/24 (non-exist-map) does NOT exist in BGP table
>> >
>> > 4.) prefixes matched in advertise-map are the only prefixes
>> > affected -- other prefixes that may exist are advertised (or
>> > not) as normal
>> >
>> > 5.) when dealing with conditional advertisement tasks, always
>> > consider what will happen normally (without any config)
>> >
>> > I'd be happy to be corrected, but I think the first point is
>> > contrary to what Ivan said. Also consider point #4 -- BGP
>> > conditional advertising is not strictly a route filtering
>> > mechanism, although it can be configured to achieve similar results.
>> >
>> > cheers,
>> > Dale
>> >
>> >
>>
>> _______________________________________________
>> cisco-nsp mailing 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 rubensk at gmail.com  Sat Mar 21 15:27:38 2009
From: rubensk at gmail.com (Rubens Kuhl)
Date: Sat, 21 Mar 2009 16:27:38 -0300
Subject: [c-nsp] Freeware management software
In-Reply-To: <49C51105.3050205@gmail.com>
References: <8D68760F464FFD40A01BF2FB374E4A280165526EF871@SRVEXC02.aas.its.nja.dk>
	<49C51105.3050205@gmail.com>
Message-ID: <6bb5f5b10903211227k36bf07f5oacca2412f8ffd541@mail.gmail.com>

How well does Opsview scale to, for instance, 10 thousand devices and
20 thousand data sources ?


Rubens


On Sat, Mar 21, 2009 at 1:08 PM, Roy <r.engehausen at gmail.com> wrote:
> Opsview???
>
> http://www.opsview.org
>
> Arne Larsen / Region Nordjylland wrote:
>> Hi Folks.
>>
>> Can someone give me a hint, I?m looking for freeware management software like NMIS.
>> Software that can provide reachability, availablility an health scores.
>> NMIS Dashboard doesn?t seem to scale in large network.
>> I like the dashboard off NMIS, it?s easy for anyone to understand the red & green function..
>> But it can?t discover devices, it?s a static configuration imnplementing NMIS.
>> Does anyone know off freeware software ala HP Openview.
>>
>>
>> /Arne
>> _______________________________________________
>> cisco-nsp mailing 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 Charles at thewybles.com  Sat Mar 21 15:36:42 2009
From: Charles at thewybles.com (Charles at thewybles.com)
Date: Sat, 21 Mar 2009 19:36:42 +0000
Subject: [c-nsp] Freeware management software
In-Reply-To: <6bb5f5b10903211227k36bf07f5oacca2412f8ffd541@mail.gmail.com>
References: <8D68760F464FFD40A01BF2FB374E4A280165526EF871@SRVEXC02.aas.its.nja.dk><49C51105.3050205@gmail.com><6bb5f5b10903211227k36bf07f5oacca2412f8ffd541@mail.gmail.com>
Message-ID: <1238998791-1237664223-cardhu_decombobulator_blackberry.rim.net-376783360-@bxe1302.bisx.prod.on.blackberry>

I use nagios (which underpins opsview) to monitor 1000 plus servers deployed througout the united states. Works like a champ.  
Several sites use nagios to handle multi thousand nodes with dozens of checks per node.  
Sent via BlackBerry from T-Mobile

-----Original Message-----
From: Rubens Kuhl <rubensk at gmail.com>

Date: Sat, 21 Mar 2009 16:27:38 
To: Roy<r.engehausen at gmail.com>
Cc: cisco-nsp at puck.nether.net<cisco-nsp at puck.nether.net>
Subject: Re: [c-nsp] Freeware management software


How well does Opsview scale to, for instance, 10 thousand devices and
20 thousand data sources ?


Rubens


On Sat, Mar 21, 2009 at 1:08 PM, Roy <r.engehausen at gmail.com> wrote:
> Opsview???
>
> http://www.opsview.org
>
> Arne Larsen / Region Nordjylland wrote:
>> Hi Folks.
>>
>> Can someone give me a hint, I?m looking for freeware management software like NMIS.
>> Software that can provide reachability, availablility an health scores.
>> NMIS Dashboard doesn?t seem to scale in large network.
>> I like the dashboard off NMIS, it?s easy for anyone to understand the red & green function..
>> But it can?t discover devices, it?s a static configuration imnplementing NMIS.
>> Does anyone know off freeware software ala HP Openview.
>>
>>
>> /Arne
>>_______________________________________________
>> cisco-nsp mailing 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 diogo.montagner at gmail.com  Sat Mar 21 15:46:46 2009
From: diogo.montagner at gmail.com (Diogo Montagner)
Date: Sat, 21 Mar 2009 16:46:46 -0300
Subject: [c-nsp] Freeware management software
In-Reply-To: <1238998791-1237664223-cardhu_decombobulator_blackberry.rim.net-376783360-@bxe1302.bisx.prod.on.blackberry>
References: <8D68760F464FFD40A01BF2FB374E4A280165526EF871@SRVEXC02.aas.its.nja.dk>
	<49C51105.3050205@gmail.com>
	<6bb5f5b10903211227k36bf07f5oacca2412f8ffd541@mail.gmail.com>
	<1238998791-1237664223-cardhu_decombobulator_blackberry.rim.net-376783360-@bxe1302.bisx.prod.on.blackberry>
Message-ID: <84eb7a820903211246h42bcc793jdde51f70d94a9e7b@mail.gmail.com>

I have heard good feedback from people who used Zabbix. I never used it but
it appear to be a good software. The same guys who used it also tried nagios
and they told me that Zabbix is better.

http://www.zabbix.com/

./diogo -montagner


On Sat, Mar 21, 2009 at 4:36 PM, <Charles at thewybles.com> wrote:

> I use nagios (which underpins opsview) to monitor 1000 plus servers
> deployed througout the united states. Works like a champ.
> Several sites use nagios to handle multi thousand nodes with dozens of
> checks per node.
> Sent via BlackBerry from T-Mobile
>
> -----Original Message-----
> From: Rubens Kuhl <rubensk at gmail.com>
>
> Date: Sat, 21 Mar 2009 16:27:38
> To: Roy<r.engehausen at gmail.com>
> Cc: cisco-nsp at puck.nether.net<cisco-nsp at puck.nether.net>
> Subject: Re: [c-nsp] Freeware management software
>

>
> How well does Opsview scale to, for instance, 10 thousand devices and
> 20 thousand data sources ?
>
>
> Rubens
>
>
> On Sat, Mar 21, 2009 at 1:08 PM, Roy <r.engehausen at gmail.com> wrote:
> > Opsview???
> >
> > http://www.opsview.org
> >
> > Arne Larsen / Region Nordjylland wrote:
> >> Hi Folks.
> >>
> >> Can someone give me a hint, I?m looking for freeware management software
> like NMIS.
> >> Software that can provide reachability, availablility an health scores.
> >> NMIS Dashboard doesn?t seem to scale in large network.
> >> I like the dashboard off NMIS, it?s easy for anyone to understand the
> red & green function..
> >> But it can?t discover devices, it?s a static configuration imnplementing
> NMIS.
> >> Does anyone know off freeware software ala HP Openview.
> >>
> >>
> >> /Arne
> >>_______________________________________________
> >> cisco-nsp mailing 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/
>
> _______________________________________________
> cisco-nsp mailing list  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  Sat Mar 21 17:25:31 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Sat, 21 Mar 2009 14:25:31 -0700
Subject: [c-nsp] Freeware management software
In-Reply-To: <6bb5f5b10903211227k36bf07f5oacca2412f8ffd541@mail.gmail.com>
References: <8D68760F464FFD40A01BF2FB374E4A280165526EF871@SRVEXC02.aas.its.nja.dk>	<49C51105.3050205@gmail.com>
	<6bb5f5b10903211227k36bf07f5oacca2412f8ffd541@mail.gmail.com>
Message-ID: <49C55B4B.6040201@rollernet.us>

Rubens Kuhl wrote:
> How well does Opsview scale to, for instance, 10 thousand devices and
> 20 thousand data sources ?
> 

It scales by using distributed monitoring and clustering. Can't say I've 
ever tried it with a system that big, though.

~Seth

From bdikici at gmail.com  Sat Mar 21 18:34:51 2009
From: bdikici at gmail.com (Burak Dikici)
Date: Sun, 22 Mar 2009 00:34:51 +0200
Subject: [c-nsp] BGP conditional advertisemet - NON-EXIST route
	map'saccess-list problem
In-Reply-To: <OF87636C26.F4C6D537-ON88257580.0061B464-88257580.0064416E@lecg.com>
References: <d9281f5c0903210819j6af8e9b1s9ddc3dd6f81c1ad0@mail.gmail.com>
	<OF87636C26.F4C6D537-ON88257580.0061B464-88257580.0064416E@lecg.com>
Message-ID: <d9281f5c0903211534j63b4ef95ka41d5f376af75b1f@mail.gmail.com>

  Hi Randy ,

 I have missied the point. I am going to talk this subject with the ISP-1.
Kind Regards.

Burak Dikici




On Sat, Mar 21, 2009 at 8:12 PM, <RPhookun at lecg.com> wrote:

>
> Hi Burak,
>
> I had replied with the *fix* some days ago -
> You can still use the ISP-1 infrastructrure /24. You have to have the ISP-1
> router announce the /24 to router#
> As you probably realise, this announcement is not required for the peering
> session *itself* to be up.
>
> The annoucement by ISP-1 router of this /24 will cause it to appear in
> router#'s bgp table which you can then use as the tracked prefix.
>
> Router#'s routing table will always install only the *connected*(d-0)
> version of this /24 which is what you want! The eBGP version(d-20) will
> exist only in the bgp table as a valid prefix you can track.
>
> Hope this helps.
> ./Randy
>
>
>
>   *Burak Dikici <bdikici at gmail.com>*
> Sent by: cisco-nsp-bounces at puck.nether.net
>
> 03/21/2009 08:19 AM
>    To
> RPhookun at lecg.com, ip at ioshints.info  cc
> cisco-nsp-bounces at puck.nether.net, cisco-nsp at puck.nether.net
>  Subject
> Re: [c-nsp] BGP conditional advertisemet - NON-EXIST route
>  map'saccess-list problem
>
>
>
>
>
>    Hello ,
>
> The main problem is which prefix should i track ? I can't use the
> infrastructe subnet between my router and ISP-1 router , because it is
> directly connected and it is in the routing table , not in the bgp table.
> I was thinking on that , then i have decided to use reliable root DNS
> servers subnets to track with acl or prefix-list , for example ;
>
> access-list 20 permit 198.41.0.0 0.0.0.255 /* a.root-servers.net */
> access-list 20 permit 192.228.79.0 0.0.0.255 /* b.root-servers.net */
> access-list 20 permit 192.33.4.0 0.0.0.255 /* c.root-servers.net */
> access-list 20 permit 128.8.0.0 0.0.255.255 /* d.root-servers.net */
>
> what do you think about this idea ?
>
> Burak Dikici
>
>
>
>
> On Thu, Mar 19, 2009 at 2:48 PM, Burak Dikici <bdikici at gmail.com> wrote:
>
> >  Sorry about my late reply. I am very busy these days with another
> project.
> > I am going to test your recommendations in a few days , and going to
> reply
> > back to you. Thank you all. Kind Regards...
> >
> > Burak Dikici
> >
> >
> >
> > On Wed, Mar 18, 2009 at 12:04 AM, <RPhookun at lecg.com> wrote:
> >
> >>
> >> The prefix-list within the Non-Exist clause also has to *exactly* match
> >> the prefix in the bgp table..
> >> Regards,
> >> ./Randy
> >>
> >>
> >>
> >>
> >>   *"Ivan Pepelnjak" <ip at ioshints.info>*
> >> Sent by: cisco-nsp-bounces at puck.nether.net
> >>
> >> 03/17/2009 02:20 PM
> >>    To
> >> "'Dale Shaw'" <dale.shaw+cisco-nsp at gmail.com<dale.shaw%2Bcisco-nsp at gmail.com>
> <dale.shaw%2Bcisco-nsp at gmail.com <dale.shaw%252Bcisco-nsp at gmail.com>>>,
>
> >> "'Burak Dikici'" <bdikici at gmail.com>  cc
> >>   cisco-nsp at puck.nether.net  Subject
> >> Re: [c-nsp] BGP conditional advertisemet - NON-EXIST route
> >>  map'saccess-list problem
> >>
> >>
> >>
> >>
> >>
> >>  Did some tests on the NON-EXIST-MAP with 12.2SRC. I was spreading wrong
> >> rumors, time to fix them:
> >>
> >> * The route-map checks the routes in the BGP table (_not_ in the IP
> >> routing
> >> table). Dale was right.
> >> * It can take a while for the routes to be advertised/withdrawn; the
> >> non-exist-map is checked only at the BGP scan intervals (60 seconds by
> >> default, can be adjusted).
> >> * You can use a combination of an access-list and AS-path access-list in
> >> the
> >> route-map.
> >>
> >> The handling of standard access-lists used in the "match ip address"
> >> route-map condition is a bit weird, though:
> >>
> >> * "permit any" does _NOT_ work.
> >> * "permit prefix 0.0.0.0" (which gets translated into "permit prefix" in
> >> standard ACL) does _NOT_ work.
> >> * fancy wildcard tests (for example "permit 0.0.0.0 127.255.255.255) do
> >> _NOT_ work
> >>
> >> It looks like:
> >>
> >> * the IP prefix in the BGP table must match the address in the ACL
> exactly
> >> (wildcard bits are ignored).
> >> * ... but you still need the wildcard bits (inverted netmask) for the
> >> match
> >> to work.
> >>
> >> For example: if you want to match 10.8.8.0/24, you have to use "permit
> >> 10.8.8.0 0.0.0.255". "permit 10.8.8.0" or "permit 10.8.0.0 0.0.255.255"
> do
> >> _NOT_ work.
> >>
> >> Left to do: tests with the ip prefix-list instead of IP access list (and
> >> no,
> >> I will NOT test extended ACL :).
> >>
> >> Hope this helps
> >> Ivan
> >>
> >> > -----Original Message-----
>  >> > From: Dale Shaw [mailto:dale.shaw+cisco-nsp at gmail.com<dale.shaw%2Bcisco-nsp at gmail.com>
> <dale.shaw%2Bcisco-nsp at gmail.com <dale.shaw%252Bcisco-nsp at gmail.com>>]
> >>
> >> > Sent: Sunday, March 15, 2009 11:33 PM
> >> > To: Burak Dikici
> >> > Cc: cisco-nsp at puck.nether.net
> >> > Subject: Re: [c-nsp] BGP conditional advertisemet - NON-EXIST
> >> > route map'saccess-list problem
> >> >
> >> > Hi Burak,
> >> >
> >> > On Mon, Mar 16, 2009 at 12:06 AM, Burak Dikici
> >> > <bdikici at gmail.com> wrote:
> >> > > i am trying to use
> >> > > BGP conditional advertisemet configuration. I have got a
> >> > problem with
> >> > > NON-EXIST route map's access-list. In the NON-EXIST router map i am
> >> > > using the commands which is written below ;
> >> >
> >> > Here are some notes I made recently when playing with BGP
> >> > conditional advertising. I hope it helps.
> >> >
> >> > 1.) prefixes matched in advertise-map and exist/non-exist map
> >> > must exist (or not) in the *BGP* table
> >> >  however: they do not need to be locally originated (e.g. R1
> >> > can match routes received from R2 and advertise (or not) to R3
> >> >  and: the validity of the prefix in the BGP table (i.e.
> >> > RIB-failure) doesn't matter. if there's there, and using
> >> > exist-map, the condition is met.
> >> >
> >> > 2.) when using 'exist' map, prefixes matched by advertise-map
> >> > are advertised when exist-map condition is met
> >> >  example: advertise 1.0.0.0/8 (advertise-map) from BGP table when
> >> > 3.20.20.0/24 (exist-map) exists in BGP table
> >> >
> >> > 3.) when exist 'non-exist' map, prefixes matched by
> >> > advertise-map are advertised when non-exist-map condition is met
> >> >  example: advertise 1.0.0.0/8 (advertise-map) from BGP table when
> >> > 3.20.20.0/24 (non-exist-map) does NOT exist in BGP table
> >> >
> >> > 4.) prefixes matched in advertise-map are the only prefixes
> >> > affected -- other prefixes that may exist are advertised (or
> >> > not) as normal
> >> >
> >> > 5.) when dealing with conditional advertisement tasks, always
> >> > consider what will happen normally (without any config)
> >> >
> >> > I'd be happy to be corrected, but I think the first point is
> >> > contrary to what Ivan said. Also consider point #4 -- BGP
> >> > conditional advertising is not strictly a route filtering
> >> > mechanism, although it can be configured to achieve similar results.
> >> >
> >> > cheers,
> >> > Dale
> >> >
> >> >
> >>
> >> _______________________________________________
> >> cisco-nsp mailing 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 RPhookun at lecg.com  Sat Mar 21 19:09:49 2009
From: RPhookun at lecg.com (RPhookun at lecg.com)
Date: Sat, 21 Mar 2009 16:09:49 -0700
Subject: [c-nsp] BGP conditional advertisemet - NON-EXIST
 route	map'saccess-list problem
In-Reply-To: <d9281f5c0903211534j63b4ef95ka41d5f376af75b1f@mail.gmail.com>
Message-ID: <OF45CAE9EB.BE1D924F-ON88257580.007E8A23-88257580.007F716D@lecg.com>

Hi Burak,
Ask ISP-A to announce the infrastructure /24 to router# as a local-route 
via a network statement 192.168.x.0 mask 255.255.255.0. They may not want 
to do the same via redistribute-connected(if rtr-ISP-1 is also used for 
peerring with other customers)

./Randy




Burak Dikici <bdikici at gmail.com> 
Sent by: cisco-nsp-bounces at puck.nether.net
03/21/2009 03:34 PM

To
RPhookun at lecg.com
cc
ip at ioshints.info, cisco-nsp-bounces at puck.nether.net, 
cisco-nsp at puck.nether.net
Subject
Re: [c-nsp] BGP conditional advertisemet - NON-EXIST route 
map'saccess-list problem






  Hi Randy ,

 I have missied the point. I am going to talk this subject with the ISP-1.
Kind Regards.

Burak Dikici




On Sat, Mar 21, 2009 at 8:12 PM, <RPhookun at lecg.com> wrote:

>
> Hi Burak,
>
> I had replied with the *fix* some days ago -
> You can still use the ISP-1 infrastructrure /24. You have to have the 
ISP-1
> router announce the /24 to router#
> As you probably realise, this announcement is not required for the 
peering
> session *itself* to be up.
>
> The annoucement by ISP-1 router of this /24 will cause it to appear in
> router#'s bgp table which you can then use as the tracked prefix.
>
> Router#'s routing table will always install only the *connected*(d-0)
> version of this /24 which is what you want! The eBGP version(d-20) will
> exist only in the bgp table as a valid prefix you can track.
>
> Hope this helps.
> ./Randy
>
>
>
>   *Burak Dikici <bdikici at gmail.com>*
> Sent by: cisco-nsp-bounces at puck.nether.net
>
> 03/21/2009 08:19 AM
>    To
> RPhookun at lecg.com, ip at ioshints.info  cc
> cisco-nsp-bounces at puck.nether.net, cisco-nsp at puck.nether.net
>  Subject
> Re: [c-nsp] BGP conditional advertisemet - NON-EXIST route
>  map'saccess-list problem
>
>
>
>
>
>    Hello ,
>
> The main problem is which prefix should i track ? I can't use the
> infrastructe subnet between my router and ISP-1 router , because it is
> directly connected and it is in the routing table , not in the bgp 
table.
> I was thinking on that , then i have decided to use reliable root DNS
> servers subnets to track with acl or prefix-list , for example ;
>
> access-list 20 permit 198.41.0.0 0.0.0.255 /* a.root-servers.net */
> access-list 20 permit 192.228.79.0 0.0.0.255 /* b.root-servers.net */
> access-list 20 permit 192.33.4.0 0.0.0.255 /* c.root-servers.net */
> access-list 20 permit 128.8.0.0 0.0.255.255 /* d.root-servers.net */
>
> what do you think about this idea ?
>
> Burak Dikici
>
>
>
>
> On Thu, Mar 19, 2009 at 2:48 PM, Burak Dikici <bdikici at gmail.com> wrote:
>
> >  Sorry about my late reply. I am very busy these days with another
> project.
> > I am going to test your recommendations in a few days , and going to
> reply
> > back to you. Thank you all. Kind Regards...
> >
> > Burak Dikici
> >
> >
> >
> > On Wed, Mar 18, 2009 at 12:04 AM, <RPhookun at lecg.com> wrote:
> >
> >>
> >> The prefix-list within the Non-Exist clause also has to *exactly* 
match
> >> the prefix in the bgp table..
> >> Regards,
> >> ./Randy
> >>
> >>
> >>
> >>
> >>   *"Ivan Pepelnjak" <ip at ioshints.info>*
> >> Sent by: cisco-nsp-bounces at puck.nether.net
> >>
> >> 03/17/2009 02:20 PM
> >>    To
> >> "'Dale Shaw'" 
<dale.shaw+cisco-nsp at gmail.com<dale.shaw%2Bcisco-nsp at gmail.com>
> <dale.shaw%2Bcisco-nsp at gmail.com <dale.shaw%252Bcisco-nsp at gmail.com>>>,
>
> >> "'Burak Dikici'" <bdikici at gmail.com>  cc
> >>   cisco-nsp at puck.nether.net  Subject
> >> Re: [c-nsp] BGP conditional advertisemet - NON-EXIST route
> >>  map'saccess-list problem
> >>
> >>
> >>
> >>
> >>
> >>  Did some tests on the NON-EXIST-MAP with 12.2SRC. I was spreading 
wrong
> >> rumors, time to fix them:
> >>
> >> * The route-map checks the routes in the BGP table (_not_ in the IP
> >> routing
> >> table). Dale was right.
> >> * It can take a while for the routes to be advertised/withdrawn; the
> >> non-exist-map is checked only at the BGP scan intervals (60 seconds 
by
> >> default, can be adjusted).
> >> * You can use a combination of an access-list and AS-path access-list 
in
> >> the
> >> route-map.
> >>
> >> The handling of standard access-lists used in the "match ip address"
> >> route-map condition is a bit weird, though:
> >>
> >> * "permit any" does _NOT_ work.
> >> * "permit prefix 0.0.0.0" (which gets translated into "permit prefix" 
in
> >> standard ACL) does _NOT_ work.
> >> * fancy wildcard tests (for example "permit 0.0.0.0 127.255.255.255) 
do
> >> _NOT_ work
> >>
> >> It looks like:
> >>
> >> * the IP prefix in the BGP table must match the address in the ACL
> exactly
> >> (wildcard bits are ignored).
> >> * ... but you still need the wildcard bits (inverted netmask) for the
> >> match
> >> to work.
> >>
> >> For example: if you want to match 10.8.8.0/24, you have to use 
"permit
> >> 10.8.8.0 0.0.0.255". "permit 10.8.8.0" or "permit 10.8.0.0 
0.0.255.255"
> do
> >> _NOT_ work.
> >>
> >> Left to do: tests with the ip prefix-list instead of IP access list 
(and
> >> no,
> >> I will NOT test extended ACL :).
> >>
> >> Hope this helps
> >> Ivan
> >>
> >> > -----Original Message-----
>  >> > From: Dale Shaw 
[mailto:dale.shaw+cisco-nsp at gmail.com<dale.shaw%2Bcisco-nsp at gmail.com>
> <dale.shaw%2Bcisco-nsp at gmail.com <dale.shaw%252Bcisco-nsp at gmail.com>>]
> >>
> >> > Sent: Sunday, March 15, 2009 11:33 PM
> >> > To: Burak Dikici
> >> > Cc: cisco-nsp at puck.nether.net
> >> > Subject: Re: [c-nsp] BGP conditional advertisemet - NON-EXIST
> >> > route map'saccess-list problem
> >> >
> >> > Hi Burak,
> >> >
> >> > On Mon, Mar 16, 2009 at 12:06 AM, Burak Dikici
> >> > <bdikici at gmail.com> wrote:
> >> > > i am trying to use
> >> > > BGP conditional advertisemet configuration. I have got a
> >> > problem with
> >> > > NON-EXIST route map's access-list. In the NON-EXIST router map i 
am
> >> > > using the commands which is written below ;
> >> >
> >> > Here are some notes I made recently when playing with BGP
> >> > conditional advertising. I hope it helps.
> >> >
> >> > 1.) prefixes matched in advertise-map and exist/non-exist map
> >> > must exist (or not) in the *BGP* table
> >> >  however: they do not need to be locally originated (e.g. R1
> >> > can match routes received from R2 and advertise (or not) to R3
> >> >  and: the validity of the prefix in the BGP table (i.e.
> >> > RIB-failure) doesn't matter. if there's there, and using
> >> > exist-map, the condition is met.
> >> >
> >> > 2.) when using 'exist' map, prefixes matched by advertise-map
> >> > are advertised when exist-map condition is met
> >> >  example: advertise 1.0.0.0/8 (advertise-map) from BGP table when
> >> > 3.20.20.0/24 (exist-map) exists in BGP table
> >> >
> >> > 3.) when exist 'non-exist' map, prefixes matched by
> >> > advertise-map are advertised when non-exist-map condition is met
> >> >  example: advertise 1.0.0.0/8 (advertise-map) from BGP table when
> >> > 3.20.20.0/24 (non-exist-map) does NOT exist in BGP table
> >> >
> >> > 4.) prefixes matched in advertise-map are the only prefixes
> >> > affected -- other prefixes that may exist are advertised (or
> >> > not) as normal
> >> >
> >> > 5.) when dealing with conditional advertisement tasks, always
> >> > consider what will happen normally (without any config)
> >> >
> >> > I'd be happy to be corrected, but I think the first point is
> >> > contrary to what Ivan said. Also consider point #4 -- BGP
> >> > conditional advertising is not strictly a route filtering
> >> > mechanism, although it can be configured to achieve similar 
results.
> >> >
> >> > cheers,
> >> > Dale
> >> >
> >> >
> >>
> >> _______________________________________________
> >> cisco-nsp mailing 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 r.engehausen at gmail.com  Sat Mar 21 19:53:40 2009
From: r.engehausen at gmail.com (Roy)
Date: Sat, 21 Mar 2009 16:53:40 -0700
Subject: [c-nsp] Freeware management software
In-Reply-To: <49C55B4B.6040201@rollernet.us>
References: <8D68760F464FFD40A01BF2FB374E4A280165526EF871@SRVEXC02.aas.its.nja.dk>	<49C51105.3050205@gmail.com>	<6bb5f5b10903211227k36bf07f5oacca2412f8ffd541@mail.gmail.com>
	<49C55B4B.6040201@rollernet.us>
Message-ID: <49C57E04.1080606@gmail.com>

Seth Mattinen wrote:
> Rubens Kuhl wrote:
>> How well does Opsview scale to, for instance, 10 thousand devices and
>> 20 thousand data sources ?
>>
>
> It scales by using distributed monitoring and clustering. Can't say
> I've ever tried it with a system that big, though.
>
> ~Seth

I am in the same situation as Seth.  Opsview does have the concept of
slaves so it does do distributed monitoring.  You might ask the question
on the Opsview mailing list at opsview-users at lists.opsview.org

From mtinka at globaltransit.net  Sat Mar 21 22:18:26 2009
From: mtinka at globaltransit.net (Mark Tinka)
Date: Sun, 22 Mar 2009 10:18:26 +0800
Subject: [c-nsp] isis adjecency...
In-Reply-To: <fskb1awq4bl56u5tkrUYAxe124vaj_firegpg@mail.gmail.com>
References: <fskb1awq4bl56u5tkrUYAxe124vaj_firegpg@mail.gmail.com>
Message-ID: <200903221018.33198.mtinka@globaltransit.net>

On Saturday 21 March 2009 08:57:06 pm Mateusz Blaszczyk 
wrote:

> > RP/0/RP0/CPU0:crs1.LAB(config)#router isis XXX
> > RP/0/RP0/CPU0:crs1.LAB(config-isis)#interface
> > TenGigE0/1/2/0.250
> > RP/0/RP0/CPU0:crs1.LAB(config-isis-if)#hello-password
> > text encrypted XXXYYY
> > RP/0/RP0/CPU0:crs1.LAB(config-isis-if)#commit
> > % Failed to commit one or more configuration items
> > during an atomic operation, no changes have been made.
> > Please use 'show configuration failed' to view the
> > errors
>
> what does #show configuration failed# show?

While that's coming, I'd also consider running HMAC-MD5 as 
opposed to plain text.

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/20090322/4197517f/attachment.bin>

From bdikici at gmail.com  Sun Mar 22 03:46:40 2009
From: bdikici at gmail.com (Burak Dikici)
Date: Sun, 22 Mar 2009 09:46:40 +0200
Subject: [c-nsp] BGP conditional advertisemet - NON-EXIST route
	map'saccess-list problem
In-Reply-To: <OF45CAE9EB.BE1D924F-ON88257580.007E8A23-88257580.007F716D@lecg.com>
References: <d9281f5c0903211534j63b4ef95ka41d5f376af75b1f@mail.gmail.com>
	<OF45CAE9EB.BE1D924F-ON88257580.007E8A23-88257580.007F716D@lecg.com>
Message-ID: <d9281f5c0903220046s2b8f40daie4fe97df9dd5ee3e@mail.gmail.com>

  Hi Randy ,

I couldn't understand what you mean with a local-route  ? Could you explain
little more ?

Burak



On Sun, Mar 22, 2009 at 1:09 AM, <RPhookun at lecg.com> wrote:

>
> Hi Burak,
> Ask ISP-A to announce the infrastructure /24 to router# as a local-route
> via a network statement 192.168.x.0 mask 255.255.255.0. They may not want to
> do the same via redistribute-connected(if rtr-ISP-1 is also used for
> peerring with other customers)
>
> ./Randy
>
>
>
>   *Burak Dikici <bdikici at gmail.com>*
> Sent by: cisco-nsp-bounces at puck.nether.net
>
> 03/21/2009 03:34 PM
>    To
> RPhookun at lecg.com  cc
> ip at ioshints.info, cisco-nsp-bounces at puck.nether.net,
> cisco-nsp at puck.nether.net
>   Subject
> Re: [c-nsp] BGP conditional advertisemet - NON-EXIST route
>  map'saccess-list problem
>
>
>
>
>
>    Hi Randy ,
>
> I have missied the point. I am going to talk this subject with the ISP-1.
> Kind Regards.
>
> Burak Dikici
>
>
>
>
> On Sat, Mar 21, 2009 at 8:12 PM, <RPhookun at lecg.com> wrote:
>
> >
> > Hi Burak,
> >
> > I had replied with the *fix* some days ago -
> > You can still use the ISP-1 infrastructrure /24. You have to have the
> ISP-1
> > router announce the /24 to router#
> > As you probably realise, this announcement is not required for the
> peering
> > session *itself* to be up.
> >
> > The annoucement by ISP-1 router of this /24 will cause it to appear in
> > router#'s bgp table which you can then use as the tracked prefix.
> >
> > Router#'s routing table will always install only the *connected*(d-0)
> > version of this /24 which is what you want! The eBGP version(d-20) will
> > exist only in the bgp table as a valid prefix you can track.
> >
> > Hope this helps.
> > ./Randy
> >
> >
> >
> >   *Burak Dikici <bdikici at gmail.com>*
> > Sent by: cisco-nsp-bounces at puck.nether.net
> >
> > 03/21/2009 08:19 AM
> >    To
> > RPhookun at lecg.com, ip at ioshints.info  cc
> > cisco-nsp-bounces at puck.nether.net, cisco-nsp at puck.nether.net
> >  Subject
> > Re: [c-nsp] BGP conditional advertisemet - NON-EXIST route
> >  map'saccess-list problem
> >
> >
> >
> >
> >
> >    Hello ,
> >
> > The main problem is which prefix should i track ? I can't use the
> > infrastructe subnet between my router and ISP-1 router , because it is
> > directly connected and it is in the routing table , not in the bgp table.
> > I was thinking on that , then i have decided to use reliable root DNS
> > servers subnets to track with acl or prefix-list , for example ;
> >
> > access-list 20 permit 198.41.0.0 0.0.0.255 /* a.root-servers.net */
> > access-list 20 permit 192.228.79.0 0.0.0.255 /* b.root-servers.net */
> > access-list 20 permit 192.33.4.0 0.0.0.255 /* c.root-servers.net */
> > access-list 20 permit 128.8.0.0 0.0.255.255 /* d.root-servers.net */
> >
> > what do you think about this idea ?
> >
> > Burak Dikici
> >
> >
> >
> >
> > On Thu, Mar 19, 2009 at 2:48 PM, Burak Dikici <bdikici at gmail.com> wrote:
> >
> > >  Sorry about my late reply. I am very busy these days with another
> > project.
> > > I am going to test your recommendations in a few days , and going to
> > reply
> > > back to you. Thank you all. Kind Regards...
> > >
> > > Burak Dikici
> > >
> > >
> > >
> > > On Wed, Mar 18, 2009 at 12:04 AM, <RPhookun at lecg.com> wrote:
> > >
> > >>
> > >> The prefix-list within the Non-Exist clause also has to *exactly*
> match
> > >> the prefix in the bgp table..
> > >> Regards,
> > >> ./Randy
> > >>
> > >>
> > >>
> > >>
> > >>   *"Ivan Pepelnjak" <ip at ioshints.info>*
> > >> Sent by: cisco-nsp-bounces at puck.nether.net
> > >>
> > >> 03/17/2009 02:20 PM
> > >>    To
> > >> "'Dale Shaw'" <dale.shaw+cisco-nsp at gmail.com<dale.shaw%2Bcisco-nsp at gmail.com>
> <dale.shaw%2Bcisco-nsp at gmail.com <dale.shaw%252Bcisco-nsp at gmail.com>>
> > <dale.shaw%2Bcisco-nsp at gmail.com <dale.shaw%252Bcisco-nsp at gmail.com> <
> dale.shaw%252Bcisco-nsp at gmail.com <dale.shaw%25252Bcisco-nsp at gmail.com>>>>,
>
>
> >
> > >> "'Burak Dikici'" <bdikici at gmail.com>  cc
> > >>   cisco-nsp at puck.nether.net  Subject
> > >> Re: [c-nsp] BGP conditional advertisemet - NON-EXIST route
> > >>  map'saccess-list problem
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>  Did some tests on the NON-EXIST-MAP with 12.2SRC. I was spreading
> wrong
> > >> rumors, time to fix them:
> > >>
> > >> * The route-map checks the routes in the BGP table (_not_ in the IP
> > >> routing
> > >> table). Dale was right.
> > >> * It can take a while for the routes to be advertised/withdrawn; the
> > >> non-exist-map is checked only at the BGP scan intervals (60 seconds by
> > >> default, can be adjusted).
> > >> * You can use a combination of an access-list and AS-path access-list
> in
> > >> the
> > >> route-map.
> > >>
> > >> The handling of standard access-lists used in the "match ip address"
> > >> route-map condition is a bit weird, though:
> > >>
> > >> * "permit any" does _NOT_ work.
> > >> * "permit prefix 0.0.0.0" (which gets translated into "permit prefix"
> in
> > >> standard ACL) does _NOT_ work.
> > >> * fancy wildcard tests (for example "permit 0.0.0.0 127.255.255.255)
> do
> > >> _NOT_ work
> > >>
> > >> It looks like:
> > >>
> > >> * the IP prefix in the BGP table must match the address in the ACL
> > exactly
> > >> (wildcard bits are ignored).
> > >> * ... but you still need the wildcard bits (inverted netmask) for the
> > >> match
> > >> to work.
> > >>
> > >> For example: if you want to match 10.8.8.0/24, you have to use
> "permit
> > >> 10.8.8.0 0.0.0.255". "permit 10.8.8.0" or "permit 10.8.0.0
> 0.0.255.255"
> > do
> > >> _NOT_ work.
> > >>
> > >> Left to do: tests with the ip prefix-list instead of IP access list
> (and
> > >> no,
> > >> I will NOT test extended ACL :).
> > >>
> > >> Hope this helps
> > >> Ivan
> > >>
> > >> > -----Original Message-----
> >  >> > From: Dale Shaw [mailto:dale.shaw+cisco-nsp at gmail.com<dale.shaw%2Bcisco-nsp at gmail.com>
> <dale.shaw%2Bcisco-nsp at gmail.com <dale.shaw%252Bcisco-nsp at gmail.com>>
>  > <dale.shaw%2Bcisco-nsp at gmail.com <dale.shaw%252Bcisco-nsp at gmail.com> <
> dale.shaw%252Bcisco-nsp at gmail.com <dale.shaw%25252Bcisco-nsp at gmail.com>>>]
> > >>
> > >> > Sent: Sunday, March 15, 2009 11:33 PM
> > >> > To: Burak Dikici
> > >> > Cc: cisco-nsp at puck.nether.net
> > >> > Subject: Re: [c-nsp] BGP conditional advertisemet - NON-EXIST
> > >> > route map'saccess-list problem
> > >> >
> > >> > Hi Burak,
> > >> >
> > >> > On Mon, Mar 16, 2009 at 12:06 AM, Burak Dikici
> > >> > <bdikici at gmail.com> wrote:
> > >> > > i am trying to use
> > >> > > BGP conditional advertisemet configuration. I have got a
> > >> > problem with
> > >> > > NON-EXIST route map's access-list. In the NON-EXIST router map i
> am
> > >> > > using the commands which is written below ;
> > >> >
> > >> > Here are some notes I made recently when playing with BGP
> > >> > conditional advertising. I hope it helps.
> > >> >
> > >> > 1.) prefixes matched in advertise-map and exist/non-exist map
> > >> > must exist (or not) in the *BGP* table
> > >> >  however: they do not need to be locally originated (e.g. R1
> > >> > can match routes received from R2 and advertise (or not) to R3
> > >> >  and: the validity of the prefix in the BGP table (i.e.
> > >> > RIB-failure) doesn't matter. if there's there, and using
> > >> > exist-map, the condition is met.
> > >> >
> > >> > 2.) when using 'exist' map, prefixes matched by advertise-map
> > >> > are advertised when exist-map condition is met
> > >> >  example: advertise 1.0.0.0/8 (advertise-map) from BGP table when
> > >> > 3.20.20.0/24 (exist-map) exists in BGP table
> > >> >
> > >> > 3.) when exist 'non-exist' map, prefixes matched by
> > >> > advertise-map are advertised when non-exist-map condition is met
> > >> >  example: advertise 1.0.0.0/8 (advertise-map) from BGP table when
> > >> > 3.20.20.0/24 (non-exist-map) does NOT exist in BGP table
> > >> >
> > >> > 4.) prefixes matched in advertise-map are the only prefixes
> > >> > affected -- other prefixes that may exist are advertised (or
> > >> > not) as normal
> > >> >
> > >> > 5.) when dealing with conditional advertisement tasks, always
> > >> > consider what will happen normally (without any config)
> > >> >
> > >> > I'd be happy to be corrected, but I think the first point is
> > >> > contrary to what Ivan said. Also consider point #4 -- BGP
> > >> > conditional advertising is not strictly a route filtering
> > >> > mechanism, although it can be configured to achieve similar results.
> > >> >
> > >> > cheers,
> > >> > Dale
> > >> >
> > >> >
> > >>
> > >> _______________________________________________
> > >> cisco-nsp mailing 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 bdikici at gmail.com  Sun Mar 22 04:05:29 2009
From: bdikici at gmail.com (Burak Dikici)
Date: Sun, 22 Mar 2009 10:05:29 +0200
Subject: [c-nsp] BGP conditional advertisemet - NON-EXIST route
	map'saccess-list problem
In-Reply-To: <d9281f5c0903220046s2b8f40daie4fe97df9dd5ee3e@mail.gmail.com>
References: <d9281f5c0903211534j63b4ef95ka41d5f376af75b1f@mail.gmail.com>
	<OF45CAE9EB.BE1D924F-ON88257580.007E8A23-88257580.007F716D@lecg.com>
	<d9281f5c0903220046s2b8f40daie4fe97df9dd5ee3e@mail.gmail.com>
Message-ID: <d9281f5c0903220105g665bd9bana1dc0410f36499f4@mail.gmail.com>

By the way , in the lab topology i have tried this config , but when i
adversite 192.168.200.0 /24 subnet on ISP-1 with

network 192.168.200.0 mask 255.255.255.0
command , i am getting  RIB failure error on my router ;

Router#show ip bgp
BGP table version is 9, local router ID is 192.168.100.2
Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network          Next Hop            Metric LocPrf Weight Path
*> 10.1.1.0/24      0.0.0.0                  0         32768 i
*> 172.16.1.0/24    192.168.200.1            0          1000 200 i
r> 192.168.200.0    192.168.200.1            0          1000 200 i


What should i do ? I have just tried to advertise the subnet on the ISP-1
which is between my router and ISP-1 router.



On Sun, Mar 22, 2009 at 9:46 AM, Burak Dikici <bdikici at gmail.com> wrote:

>   Hi Randy ,
>
> I couldn't understand what you mean with a local-route  ? Could you explain
> little more ?
>
> Burak
>
>
>
> On Sun, Mar 22, 2009 at 1:09 AM, <RPhookun at lecg.com> wrote:
>
>>
>> Hi Burak,
>> Ask ISP-A to announce the infrastructure /24 to router# as a local-route
>> via a network statement 192.168.x.0 mask 255.255.255.0. They may not want to
>> do the same via redistribute-connected(if rtr-ISP-1 is also used for
>> peerring with other customers)
>>
>> ./Randy
>>
>>
>>
>>   *Burak Dikici <bdikici at gmail.com>*
>> Sent by: cisco-nsp-bounces at puck.nether.net
>>
>> 03/21/2009 03:34 PM
>>    To
>> RPhookun at lecg.com  cc
>> ip at ioshints.info, cisco-nsp-bounces at puck.nether.net,
>> cisco-nsp at puck.nether.net
>>   Subject
>> Re: [c-nsp] BGP conditional advertisemet - NON-EXIST route
>>  map'saccess-list problem
>>
>>
>>
>>
>>
>>    Hi Randy ,
>>
>> I have missied the point. I am going to talk this subject with the ISP-1.
>> Kind Regards.
>>
>> Burak Dikici
>>
>>
>>
>>
>> On Sat, Mar 21, 2009 at 8:12 PM, <RPhookun at lecg.com> wrote:
>>
>> >
>> > Hi Burak,
>> >
>> > I had replied with the *fix* some days ago -
>> > You can still use the ISP-1 infrastructrure /24. You have to have the
>> ISP-1
>> > router announce the /24 to router#
>> > As you probably realise, this announcement is not required for the
>> peering
>> > session *itself* to be up.
>> >
>> > The annoucement by ISP-1 router of this /24 will cause it to appear in
>> > router#'s bgp table which you can then use as the tracked prefix.
>> >
>> > Router#'s routing table will always install only the *connected*(d-0)
>> > version of this /24 which is what you want! The eBGP version(d-20) will
>> > exist only in the bgp table as a valid prefix you can track.
>> >
>> > Hope this helps.
>> > ./Randy
>> >
>> >
>> >
>> >   *Burak Dikici <bdikici at gmail.com>*
>> > Sent by: cisco-nsp-bounces at puck.nether.net
>> >
>> > 03/21/2009 08:19 AM
>> >    To
>> > RPhookun at lecg.com, ip at ioshints.info  cc
>> > cisco-nsp-bounces at puck.nether.net, cisco-nsp at puck.nether.net
>> >  Subject
>> > Re: [c-nsp] BGP conditional advertisemet - NON-EXIST route
>> >  map'saccess-list problem
>> >
>> >
>> >
>> >
>> >
>> >    Hello ,
>> >
>> > The main problem is which prefix should i track ? I can't use the
>> > infrastructe subnet between my router and ISP-1 router , because it is
>> > directly connected and it is in the routing table , not in the bgp
>> table.
>> > I was thinking on that , then i have decided to use reliable root DNS
>> > servers subnets to track with acl or prefix-list , for example ;
>> >
>> > access-list 20 permit 198.41.0.0 0.0.0.255 /* a.root-servers.net */
>> > access-list 20 permit 192.228.79.0 0.0.0.255 /* b.root-servers.net */
>> > access-list 20 permit 192.33.4.0 0.0.0.255 /* c.root-servers.net */
>> > access-list 20 permit 128.8.0.0 0.0.255.255 /* d.root-servers.net */
>> >
>> > what do you think about this idea ?
>> >
>> > Burak Dikici
>> >
>> >
>> >
>> >
>> > On Thu, Mar 19, 2009 at 2:48 PM, Burak Dikici <bdikici at gmail.com>
>> wrote:
>> >
>> > >  Sorry about my late reply. I am very busy these days with another
>> > project.
>> > > I am going to test your recommendations in a few days , and going to
>> > reply
>> > > back to you. Thank you all. Kind Regards...
>> > >
>> > > Burak Dikici
>> > >
>> > >
>> > >
>> > > On Wed, Mar 18, 2009 at 12:04 AM, <RPhookun at lecg.com> wrote:
>> > >
>> > >>
>> > >> The prefix-list within the Non-Exist clause also has to *exactly*
>> match
>> > >> the prefix in the bgp table..
>> > >> Regards,
>> > >> ./Randy
>> > >>
>> > >>
>> > >>
>> > >>
>> > >>   *"Ivan Pepelnjak" <ip at ioshints.info>*
>> > >> Sent by: cisco-nsp-bounces at puck.nether.net
>> > >>
>> > >> 03/17/2009 02:20 PM
>> > >>    To
>> > >> "'Dale Shaw'" <dale.shaw+cisco-nsp at gmail.com<dale.shaw%2Bcisco-nsp at gmail.com>
>> <dale.shaw%2Bcisco-nsp at gmail.com <dale.shaw%252Bcisco-nsp at gmail.com>>
>> > <dale.shaw%2Bcisco-nsp at gmail.com <dale.shaw%252Bcisco-nsp at gmail.com> <
>> dale.shaw%252Bcisco-nsp at gmail.com <dale.shaw%25252Bcisco-nsp at gmail.com>>>>,
>>
>>
>> >
>> > >> "'Burak Dikici'" <bdikici at gmail.com>  cc
>> > >>   cisco-nsp at puck.nether.net  Subject
>> > >> Re: [c-nsp] BGP conditional advertisemet - NON-EXIST route
>> > >>  map'saccess-list problem
>> > >>
>> > >>
>> > >>
>> > >>
>> > >>
>> > >>  Did some tests on the NON-EXIST-MAP with 12.2SRC. I was spreading
>> wrong
>> > >> rumors, time to fix them:
>> > >>
>> > >> * The route-map checks the routes in the BGP table (_not_ in the IP
>> > >> routing
>> > >> table). Dale was right.
>> > >> * It can take a while for the routes to be advertised/withdrawn; the
>> > >> non-exist-map is checked only at the BGP scan intervals (60 seconds
>> by
>> > >> default, can be adjusted).
>> > >> * You can use a combination of an access-list and AS-path access-list
>> in
>> > >> the
>> > >> route-map.
>> > >>
>> > >> The handling of standard access-lists used in the "match ip address"
>> > >> route-map condition is a bit weird, though:
>> > >>
>> > >> * "permit any" does _NOT_ work.
>> > >> * "permit prefix 0.0.0.0" (which gets translated into "permit prefix"
>> in
>> > >> standard ACL) does _NOT_ work.
>> > >> * fancy wildcard tests (for example "permit 0.0.0.0 127.255.255.255)
>> do
>> > >> _NOT_ work
>> > >>
>> > >> It looks like:
>> > >>
>> > >> * the IP prefix in the BGP table must match the address in the ACL
>> > exactly
>> > >> (wildcard bits are ignored).
>> > >> * ... but you still need the wildcard bits (inverted netmask) for the
>> > >> match
>> > >> to work.
>> > >>
>> > >> For example: if you want to match 10.8.8.0/24, you have to use
>> "permit
>> > >> 10.8.8.0 0.0.0.255". "permit 10.8.8.0" or "permit 10.8.0.0
>> 0.0.255.255"
>> > do
>> > >> _NOT_ work.
>> > >>
>> > >> Left to do: tests with the ip prefix-list instead of IP access list
>> (and
>> > >> no,
>> > >> I will NOT test extended ACL :).
>> > >>
>> > >> Hope this helps
>> > >> Ivan
>> > >>
>> > >> > -----Original Message-----
>> >  >> > From: Dale Shaw [mailto:dale.shaw+cisco-nsp at gmail.com<dale.shaw%2Bcisco-nsp at gmail.com>
>> <dale.shaw%2Bcisco-nsp at gmail.com <dale.shaw%252Bcisco-nsp at gmail.com>>
>>  > <dale.shaw%2Bcisco-nsp at gmail.com <dale.shaw%252Bcisco-nsp at gmail.com> <
>> dale.shaw%252Bcisco-nsp at gmail.com <dale.shaw%25252Bcisco-nsp at gmail.com>
>> >>]
>> > >>
>> > >> > Sent: Sunday, March 15, 2009 11:33 PM
>> > >> > To: Burak Dikici
>> > >> > Cc: cisco-nsp at puck.nether.net
>> > >> > Subject: Re: [c-nsp] BGP conditional advertisemet - NON-EXIST
>> > >> > route map'saccess-list problem
>> > >> >
>> > >> > Hi Burak,
>> > >> >
>> > >> > On Mon, Mar 16, 2009 at 12:06 AM, Burak Dikici
>> > >> > <bdikici at gmail.com> wrote:
>> > >> > > i am trying to use
>> > >> > > BGP conditional advertisemet configuration. I have got a
>> > >> > problem with
>> > >> > > NON-EXIST route map's access-list. In the NON-EXIST router map i
>> am
>> > >> > > using the commands which is written below ;
>> > >> >
>> > >> > Here are some notes I made recently when playing with BGP
>> > >> > conditional advertising. I hope it helps.
>> > >> >
>> > >> > 1.) prefixes matched in advertise-map and exist/non-exist map
>> > >> > must exist (or not) in the *BGP* table
>> > >> >  however: they do not need to be locally originated (e.g. R1
>> > >> > can match routes received from R2 and advertise (or not) to R3
>> > >> >  and: the validity of the prefix in the BGP table (i.e.
>> > >> > RIB-failure) doesn't matter. if there's there, and using
>> > >> > exist-map, the condition is met.
>> > >> >
>> > >> > 2.) when using 'exist' map, prefixes matched by advertise-map
>> > >> > are advertised when exist-map condition is met
>> > >> >  example: advertise 1.0.0.0/8 (advertise-map) from BGP table when
>> > >> > 3.20.20.0/24 (exist-map) exists in BGP table
>> > >> >
>> > >> > 3.) when exist 'non-exist' map, prefixes matched by
>> > >> > advertise-map are advertised when non-exist-map condition is met
>> > >> >  example: advertise 1.0.0.0/8 (advertise-map) from BGP table when
>> > >> > 3.20.20.0/24 (non-exist-map) does NOT exist in BGP table
>> > >> >
>> > >> > 4.) prefixes matched in advertise-map are the only prefixes
>> > >> > affected -- other prefixes that may exist are advertised (or
>> > >> > not) as normal
>> > >> >
>> > >> > 5.) when dealing with conditional advertisement tasks, always
>> > >> > consider what will happen normally (without any config)
>> > >> >
>> > >> > I'd be happy to be corrected, but I think the first point is
>> > >> > contrary to what Ivan said. Also consider point #4 -- BGP
>> > >> > conditional advertising is not strictly a route filtering
>> > >> > mechanism, although it can be configured to achieve similar
>> results.
>> > >> >
>> > >> > cheers,
>> > >> > Dale
>> > >> >
>> > >> >
>> > >>
>> > >> _______________________________________________
>> > >> cisco-nsp mailing 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 tseveendorj at gmail.com  Sun Mar 22 04:06:27 2009
From: tseveendorj at gmail.com (Tseveendorj)
Date: Sun, 22 Mar 2009 16:06:27 +0800
Subject: [c-nsp] PPPoE related question
Message-ID: <49C5F183.5060904@googlemail.com>


Hello,

I'm trying to do PPPoE on c3825 router but I faced VPDN related problem. 
c3825-ipvoicek9-mz.124-11.T4 IOS has only 2 (PPTP, L2TP) options in 
protocol.

vpdn-group 1
accept-dialin *
* protocol pptp* *
virtual-template 1

I want look like follow.

vpdn-group 1
accept-dialin
**protocol pppoe **
virtual-template 1

The IOS version is c3825-ipvoicek9-mz.124-11.T4 of c3825.
Which IOS version supported *protocol pppoe* command ?

Look forward hearing from you.

Best regards,
Tseveen.

From bdikici at gmail.com  Sun Mar 22 04:45:18 2009
From: bdikici at gmail.com (Burak Dikici)
Date: Sun, 22 Mar 2009 10:45:18 +0200
Subject: [c-nsp] BGP conditional advertisemet - NON-EXIST route
	map'saccess-list problem
In-Reply-To: <d9281f5c0903220105g665bd9bana1dc0410f36499f4@mail.gmail.com>
References: <d9281f5c0903211534j63b4ef95ka41d5f376af75b1f@mail.gmail.com>
	<OF45CAE9EB.BE1D924F-ON88257580.007E8A23-88257580.007F716D@lecg.com>
	<d9281f5c0903220046s2b8f40daie4fe97df9dd5ee3e@mail.gmail.com>
	<d9281f5c0903220105g665bd9bana1dc0410f36499f4@mail.gmail.com>
Message-ID: <d9281f5c0903220145w4dbbf896uc4f8587fdf6b1e4e@mail.gmail.com>

  Hello ,

 Here is the final result updates of the lab.
*** I have started to advertise the subnet on the ISP-1 which is between my
router and ISP-1 router ;
ISP-1(config)#router bgp 200
ISP-1(config-router)#network 192.168.200.0 mask 255.255.255.0
ISP-1#clear ip bgp * soft

ISP-1#show ip bgp
BGP table version is 4, local router ID is 192.168.200.1
Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network          Next Hop            Metric LocPrf Weight Path
*> 10.1.1.0/24      192.168.200.2            0             0 10 i
*> 172.16.1.0/24    0.0.0.0                  0         32768 i
*> 192.168.200.0    0.0.0.0                  0         32768 i


*** I am getting RIB-failure error for 192.168.200.0 subnet on my Router.

Router#show ip bgp
BGP table version is 9, local router ID is 192.168.100.2
Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network          Next Hop            Metric LocPrf Weight Path
*> 10.1.1.0/24      0.0.0.0                  0         32768 i
*> 172.16.1.0/24    192.168.200.1            0          1000 200 i
r> 192.168.200.0    192.168.200.1            0          1000 200 i


*** Then , i have changed the BGP conditional advertisement configuration on
my Router like this ;
Router#
access-list 60 permit 10.1.1.0 0.0.0.255
access-list 65 permit 192.168.200.0 0.0.0.255
route-map NON-EXIST permit 10
 match ip address 65
route-map ADVERTISE permit 10
 match ip address 60
router bgp 10
 neighbor 192.168.100.1 advertise-map ADVERTISE non-exist-map NON-EXIST



***  At the beginnning , the Advertise-map status for ISP-2 is Withdraw ;
Router#
 show ip bgp neighbors 192.168.100.1
  Condition-map NON-EXIST, Advertise-map ADVERTISE, status: Withdraw

ISP-2#show ip bgp
  EMPTY


*** Then , i shutdown the Router's fa0/0 interface which is ISP-1
connection.
Router#
interface FastEthernet0/0     ( ISP-1 interface )
 ip address 192.168.200.2 255.255.255.0
 shutdown


*** The Advertise-map status for ISP-2 goes Advertise ;
Router#
 show ip bgp neighbors 192.168.100.1
  Condition-map NON-EXIST, Advertise-map ADVERTISE, status: Advertise


*** And ISP-2 is getting the my Router's advertisement ;
ISP-2# show ip bgp
BGP table version is 8, local router ID is 192.168.100.1
Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network          Next Hop            Metric LocPrf Weight Path
*> 10.1.1.0/24      192.168.100.2            0             0 10 i


*** As a result , it looks working with tracking of the subnet which is
between my router and ISP-1 router. But, i am sitll getting RIB-failure on
my router for this subnet. Does it look OK for you ?

Burak




On Sun, Mar 22, 2009 at 10:05 AM, Burak Dikici <bdikici at gmail.com> wrote:

> By the way , in the lab topology i have tried this config , but when i
> adversite 192.168.200.0 /24 subnet on ISP-1 with
>
> network 192.168.200.0 mask 255.255.255.0
> command , i am getting  RIB failure error on my router ;
>
> Router#show ip bgp
> BGP table version is 9, local router ID is 192.168.100.2
> Status codes: s suppressed, d damped, h history, * valid, > best, i -
> internal,
>               r RIB-failure, S Stale
> Origin codes: i - IGP, e - EGP, ? - incomplete
>     Network          Next Hop            Metric LocPrf Weight Path
> *> 10.1.1.0/24      0.0.0.0                  0         32768 i
> *> 172.16.1.0/24    192.168.200.1            0          1000 200 i
> r> 192.168.200.0    192.168.200.1            0          1000 200 i
>
>
> What should i do ? I have just tried to advertise the subnet on the ISP-1
> which is between my router and ISP-1 router.
>
>
>
> On Sun, Mar 22, 2009 at 9:46 AM, Burak Dikici <bdikici at gmail.com> wrote:
>
>>   Hi Randy ,
>>
>> I couldn't understand what you mean with a local-route  ? Could you
>> explain little more ?
>>
>> Burak
>>
>>
>>
>> On Sun, Mar 22, 2009 at 1:09 AM, <RPhookun at lecg.com> wrote:
>>
>>>
>>> Hi Burak,
>>> Ask ISP-A to announce the infrastructure /24 to router# as a local-route
>>> via a network statement 192.168.x.0 mask 255.255.255.0. They may not want to
>>> do the same via redistribute-connected(if rtr-ISP-1 is also used for
>>> peerring with other customers)
>>>
>>> ./Randy
>>>
>>>
>>>
>>>   *Burak Dikici <bdikici at gmail.com>*
>>> Sent by: cisco-nsp-bounces at puck.nether.net
>>>
>>> 03/21/2009 03:34 PM
>>>    To
>>> RPhookun at lecg.com  cc
>>> ip at ioshints.info, cisco-nsp-bounces at puck.nether.net,
>>> cisco-nsp at puck.nether.net
>>>   Subject
>>> Re: [c-nsp] BGP conditional advertisemet - NON-EXIST route
>>>  map'saccess-list problem
>>>
>>>
>>>
>>>
>>>
>>>    Hi Randy ,
>>>
>>> I have missied the point. I am going to talk this subject with the ISP-1.
>>> Kind Regards.
>>>
>>> Burak Dikici
>>>
>>>
>>>
>>>
>>> On Sat, Mar 21, 2009 at 8:12 PM, <RPhookun at lecg.com> wrote:
>>>
>>> >
>>> > Hi Burak,
>>> >
>>> > I had replied with the *fix* some days ago -
>>> > You can still use the ISP-1 infrastructrure /24. You have to have the
>>> ISP-1
>>> > router announce the /24 to router#
>>> > As you probably realise, this announcement is not required for the
>>> peering
>>> > session *itself* to be up.
>>> >
>>> > The annoucement by ISP-1 router of this /24 will cause it to appear in
>>> > router#'s bgp table which you can then use as the tracked prefix.
>>> >
>>> > Router#'s routing table will always install only the *connected*(d-0)
>>> > version of this /24 which is what you want! The eBGP version(d-20) will
>>> > exist only in the bgp table as a valid prefix you can track.
>>> >
>>> > Hope this helps.
>>> > ./Randy
>>> >
>>> >
>>> >
>>> >   *Burak Dikici <bdikici at gmail.com>*
>>> > Sent by: cisco-nsp-bounces at puck.nether.net
>>> >
>>> > 03/21/2009 08:19 AM
>>> >    To
>>> > RPhookun at lecg.com, ip at ioshints.info  cc
>>> > cisco-nsp-bounces at puck.nether.net, cisco-nsp at puck.nether.net
>>> >  Subject
>>> > Re: [c-nsp] BGP conditional advertisemet - NON-EXIST route
>>> >  map'saccess-list problem
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >    Hello ,
>>> >
>>> > The main problem is which prefix should i track ? I can't use the
>>> > infrastructe subnet between my router and ISP-1 router , because it is
>>> > directly connected and it is in the routing table , not in the bgp
>>> table.
>>> > I was thinking on that , then i have decided to use reliable root DNS
>>> > servers subnets to track with acl or prefix-list , for example ;
>>> >
>>> > access-list 20 permit 198.41.0.0 0.0.0.255 /* a.root-servers.net */
>>> > access-list 20 permit 192.228.79.0 0.0.0.255 /* b.root-servers.net */
>>> > access-list 20 permit 192.33.4.0 0.0.0.255 /* c.root-servers.net */
>>> > access-list 20 permit 128.8.0.0 0.0.255.255 /* d.root-servers.net */
>>> >
>>> > what do you think about this idea ?
>>> >
>>> > Burak Dikici
>>> >
>>> >
>>> >
>>> >
>>> > On Thu, Mar 19, 2009 at 2:48 PM, Burak Dikici <bdikici at gmail.com>
>>> wrote:
>>> >
>>> > >  Sorry about my late reply. I am very busy these days with another
>>> > project.
>>> > > I am going to test your recommendations in a few days , and going to
>>> > reply
>>> > > back to you. Thank you all. Kind Regards...
>>> > >
>>> > > Burak Dikici
>>> > >
>>> > >
>>> > >
>>> > > On Wed, Mar 18, 2009 at 12:04 AM, <RPhookun at lecg.com> wrote:
>>> > >
>>> > >>
>>> > >> The prefix-list within the Non-Exist clause also has to *exactly*
>>> match
>>> > >> the prefix in the bgp table..
>>> > >> Regards,
>>> > >> ./Randy
>>> > >>
>>> > >>
>>> > >>
>>> > >>
>>> > >>   *"Ivan Pepelnjak" <ip at ioshints.info>*
>>> > >> Sent by: cisco-nsp-bounces at puck.nether.net
>>> > >>
>>> > >> 03/17/2009 02:20 PM
>>> > >>    To
>>> > >> "'Dale Shaw'" <dale.shaw+cisco-nsp at gmail.com<dale.shaw%2Bcisco-nsp at gmail.com>
>>> <dale.shaw%2Bcisco-nsp at gmail.com <dale.shaw%252Bcisco-nsp at gmail.com>>
>>> > <dale.shaw%2Bcisco-nsp at gmail.com <dale.shaw%252Bcisco-nsp at gmail.com> <
>>> dale.shaw%252Bcisco-nsp at gmail.com <dale.shaw%25252Bcisco-nsp at gmail.com>>>>,
>>>
>>>
>>> >
>>> > >> "'Burak Dikici'" <bdikici at gmail.com>  cc
>>> > >>   cisco-nsp at puck.nether.net  Subject
>>> > >> Re: [c-nsp] BGP conditional advertisemet - NON-EXIST route
>>> > >>  map'saccess-list problem
>>> > >>
>>> > >>
>>> > >>
>>> > >>
>>> > >>
>>> > >>  Did some tests on the NON-EXIST-MAP with 12.2SRC. I was spreading
>>> wrong
>>> > >> rumors, time to fix them:
>>> > >>
>>> > >> * The route-map checks the routes in the BGP table (_not_ in the IP
>>> > >> routing
>>> > >> table). Dale was right.
>>> > >> * It can take a while for the routes to be advertised/withdrawn; the
>>> > >> non-exist-map is checked only at the BGP scan intervals (60 seconds
>>> by
>>> > >> default, can be adjusted).
>>> > >> * You can use a combination of an access-list and AS-path
>>> access-list in
>>> > >> the
>>> > >> route-map.
>>> > >>
>>> > >> The handling of standard access-lists used in the "match ip address"
>>> > >> route-map condition is a bit weird, though:
>>> > >>
>>> > >> * "permit any" does _NOT_ work.
>>> > >> * "permit prefix 0.0.0.0" (which gets translated into "permit
>>> prefix" in
>>> > >> standard ACL) does _NOT_ work.
>>> > >> * fancy wildcard tests (for example "permit 0.0.0.0 127.255.255.255)
>>> do
>>> > >> _NOT_ work
>>> > >>
>>> > >> It looks like:
>>> > >>
>>> > >> * the IP prefix in the BGP table must match the address in the ACL
>>> > exactly
>>> > >> (wildcard bits are ignored).
>>> > >> * ... but you still need the wildcard bits (inverted netmask) for
>>> the
>>> > >> match
>>> > >> to work.
>>> > >>
>>> > >> For example: if you want to match 10.8.8.0/24, you have to use
>>> "permit
>>> > >> 10.8.8.0 0.0.0.255". "permit 10.8.8.0" or "permit 10.8.0.0
>>> 0.0.255.255"
>>> > do
>>> > >> _NOT_ work.
>>> > >>
>>> > >> Left to do: tests with the ip prefix-list instead of IP access list
>>> (and
>>> > >> no,
>>> > >> I will NOT test extended ACL :).
>>> > >>
>>> > >> Hope this helps
>>> > >> Ivan
>>> > >>
>>> > >> > -----Original Message-----
>>> >  >> > From: Dale Shaw [mailto:dale.shaw+cisco-nsp at gmail.com<dale.shaw%2Bcisco-nsp at gmail.com>
>>> <dale.shaw%2Bcisco-nsp at gmail.com <dale.shaw%252Bcisco-nsp at gmail.com>>
>>>  > <dale.shaw%2Bcisco-nsp at gmail.com <dale.shaw%252Bcisco-nsp at gmail.com><
>>> dale.shaw%252Bcisco-nsp at gmail.com <dale.shaw%25252Bcisco-nsp at gmail.com>
>>> >>]
>>> > >>
>>> > >> > Sent: Sunday, March 15, 2009 11:33 PM
>>> > >> > To: Burak Dikici
>>> > >> > Cc: cisco-nsp at puck.nether.net
>>> > >> > Subject: Re: [c-nsp] BGP conditional advertisemet - NON-EXIST
>>> > >> > route map'saccess-list problem
>>> > >> >
>>> > >> > Hi Burak,
>>> > >> >
>>> > >> > On Mon, Mar 16, 2009 at 12:06 AM, Burak Dikici
>>> > >> > <bdikici at gmail.com> wrote:
>>> > >> > > i am trying to use
>>> > >> > > BGP conditional advertisemet configuration. I have got a
>>> > >> > problem with
>>> > >> > > NON-EXIST route map's access-list. In the NON-EXIST router map i
>>> am
>>> > >> > > using the commands which is written below ;
>>> > >> >
>>> > >> > Here are some notes I made recently when playing with BGP
>>> > >> > conditional advertising. I hope it helps.
>>> > >> >
>>> > >> > 1.) prefixes matched in advertise-map and exist/non-exist map
>>> > >> > must exist (or not) in the *BGP* table
>>> > >> >  however: they do not need to be locally originated (e.g. R1
>>> > >> > can match routes received from R2 and advertise (or not) to R3
>>> > >> >  and: the validity of the prefix in the BGP table (i.e.
>>> > >> > RIB-failure) doesn't matter. if there's there, and using
>>> > >> > exist-map, the condition is met.
>>> > >> >
>>> > >> > 2.) when using 'exist' map, prefixes matched by advertise-map
>>> > >> > are advertised when exist-map condition is met
>>> > >> >  example: advertise 1.0.0.0/8 (advertise-map) from BGP table when
>>> > >> > 3.20.20.0/24 (exist-map) exists in BGP table
>>> > >> >
>>> > >> > 3.) when exist 'non-exist' map, prefixes matched by
>>> > >> > advertise-map are advertised when non-exist-map condition is met
>>> > >> >  example: advertise 1.0.0.0/8 (advertise-map) from BGP table when
>>> > >> > 3.20.20.0/24 (non-exist-map) does NOT exist in BGP table
>>> > >> >
>>> > >> > 4.) prefixes matched in advertise-map are the only prefixes
>>> > >> > affected -- other prefixes that may exist are advertised (or
>>> > >> > not) as normal
>>> > >> >
>>> > >> > 5.) when dealing with conditional advertisement tasks, always
>>> > >> > consider what will happen normally (without any config)
>>> > >> >
>>> > >> > I'd be happy to be corrected, but I think the first point is
>>> > >> > contrary to what Ivan said. Also consider point #4 -- BGP
>>> > >> > conditional advertising is not strictly a route filtering
>>> > >> > mechanism, although it can be configured to achieve similar
>>> results.
>>> > >> >
>>> > >> > cheers,
>>> > >> > Dale
>>> > >> >
>>> > >> >
>>> > >>
>>> > >> _______________________________________________
>>> > >> cisco-nsp mailing 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 oboehmer at cisco.com  Sun Mar 22 04:50:45 2009
From: oboehmer at cisco.com (Oliver Boehmer (oboehmer))
Date: Sun, 22 Mar 2009 09:50:45 +0100
Subject: [c-nsp] PPPoE related question
In-Reply-To: <49C5F183.5060904@googlemail.com>
References: <49C5F183.5060904@googlemail.com>
Message-ID: <70B7A1CCBFA5C649BD562B6D9F7ED78407141A99@xmb-ams-333.emea.cisco.com>

Tseveendorj <> wrote on Sunday, March 22, 2009 09:06:

> Hello,
> 
> I'm trying to do PPPoE on c3825 router but I faced VPDN related
> problem. c3825-ipvoicek9-mz.124-11.T4 IOS has only 2 (PPTP, L2TP)
> options in protocol.

haven't looked at this in a while, but you need to use bba-group instead
of vpdn-group for pppoe. i.e.

vpdn enable
bba-group pppoe global
 virtual-template 1
!
interface fastethernet0/0
 pppoe enable 

hope this helps..


From c at tix.at  Sun Mar 22 04:32:15 2009
From: c at tix.at (Christoph Loibl)
Date: Sun, 22 Mar 2009 09:32:15 +0100
Subject: [c-nsp] PPPoE related question
In-Reply-To: <49C5F183.5060904@googlemail.com>
References: <49C5F183.5060904@googlemail.com>
Message-ID: <8A6CAFC6-0996-444B-8FD1-9E25FA0FF153@tix.at>

Hi Tseveen,

Vpdn-group for pppoe is the "old" way. You are probably looking for:

bba-group pppoe <some_name||global>
  virtual-template 1
!
interface GigabitEthernet 0/0
   pppoe enable group <same_name>
!

interface Virtual-Template 1
  ...
!

Christoph


On Mar 22, 2009, at 9:06 AM, Tseveendorj wrote:

>
> Hello,
>
> I'm trying to do PPPoE on c3825 router but I faced VPDN related  
> problem. c3825-ipvoicek9-mz.124-11.T4 IOS has only 2 (PPTP, L2TP)  
> options in protocol.
>
> vpdn-group 1
> accept-dialin *
> * protocol pptp* *
> virtual-template 1
>
> I want look like follow.
>
> vpdn-group 1
> accept-dialin
> **protocol pppoe **
> virtual-template 1
>
> The IOS version is c3825-ipvoicek9-mz.124-11.T4 of c3825.
> Which IOS version supported *protocol pppoe* command ?
>
> Look forward hearing from you.
>
> Best regards,
> Tseveen.
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

-- 
CHRISTOPH LOIBL ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
mailto:c at tix.at   |No trees were killed in the creation of this message.
http://www.sil.at |However, many electrons were terrible inconvenienced.
CL8-RIPE ++++++++++++++++++++++++++++++++++++ PGP-Key-ID: 0x4B2C0055 +++




From blahu77 at gmail.com  Sun Mar 22 08:03:19 2009
From: blahu77 at gmail.com (Mateusz Blaszczyk)
Date: Sun, 22 Mar 2009 12:03:19 +0000 (IST)
Subject: [c-nsp] BGP conditional advertisemet - NON-EXIST route
	map'saccess-list problem
In-Reply-To: <d9281f5c0903220145w4dbbf896uc4f8587fdf6b1e4e@mail.gmail.com>
Message-ID: <fslojz68h5sm8i04ieUYAxe124vaj_firegpg@mail.gmail.com>

Burak,

>
> *** As a result , it looks working with tracking of the subnet which is
> between my router and ISP-1 router. But, i am sitll getting RIB-failure on
> my router for this subnet. Does it look OK for you ?

that is correct behaviour.
the  bgp route is not inserted into the rib (hence rib failure) because the connected route has better distance as 
Randy was explaining it here :

>>>> > Router#'s routing table will always install only the *connected*(d-0)
>>>> > version of this /24 which is what you want! The eBGP version(d-20) will
>>>> > exist only in the bgp table as a valid prefix you can track.

Best Regards,

-mat


-- 
pgp-key 0x1C655CAB

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090322/346c51df/attachment.bin>

From p.mayers at imperial.ac.uk  Sun Mar 22 08:31:53 2009
From: p.mayers at imperial.ac.uk (Phil Mayers)
Date: Sun, 22 Mar 2009 12:31:53 +0000
Subject: [c-nsp] Changing SSH Port on IOS
In-Reply-To: <000001c9aa4b$2cd20400$86760c00$@bierlair@root.lu>
References: <000001c9aa4b$2cd20400$86760c00$@bierlair@root.lu>
Message-ID: <20090322123153.GA14500@wildfire.net.ic.ac.uk>

On Sat, Mar 21, 2009 at 05:33:39PM +0000, Andy BIERLAIR wrote:
>I'm running s72033-ipservicesk9-mz.122-18.SXF15a with SSH on Port 22.
>
>Due too many bots hammering that well-known port, I wanted to change it to
>something else, but somehow I can't:

I don't think you can.

Investigate CoPP (Control-plane policing) which, unlike the VTY ACLs, 
will let you drop port 22 traffic in hardware, silently, before it hits 
the CPU (you can of course put in a trusted ACL)

From bdikici at gmail.com  Sun Mar 22 10:28:04 2009
From: bdikici at gmail.com (Burak Dikici)
Date: Sun, 22 Mar 2009 16:28:04 +0200
Subject: [c-nsp] BGP conditional advertisemet - NON-EXIST route
	map'saccess-list problem
In-Reply-To: <fslojz68h5sm8i04ieUYAxe124vaj_firegpg@mail.gmail.com>
References: <d9281f5c0903220145w4dbbf896uc4f8587fdf6b1e4e@mail.gmail.com>
	<fslojz68h5sm8i04ieUYAxe124vaj_firegpg@mail.gmail.com>
Message-ID: <d9281f5c0903220728p74652e36ld1c3914cc0863cbd@mail.gmail.com>

H?mm ,  i see that right now. I think , i should read the replies more
carefully !   Thank you so much.

Burak Dikici




On Sun, Mar 22, 2009 at 2:03 PM, Mateusz Blaszczyk <blahu77 at gmail.com>wrote:

> Burak,
>
>
>> *** As a result , it looks working with tracking of the subnet which is
>> between my router and ISP-1 router. But, i am sitll getting RIB-failure on
>> my router for this subnet. Does it look OK for you ?
>>
>
> that is correct behaviour.
> the  bgp route is not inserted into the rib (hence rib failure) because the
> connected route has better distance as Randy was explaining it here :
>
>   > Router#'s routing table will always install only the *connected*(d-0)
>>>>> > version of this /24 which is what you want! The eBGP version(d-20)
>>>>> will
>>>>> > exist only in the bgp table as a valid prefix you can track.
>>>>>
>>>>
>  Best Regards,
>
> -mat
>
>
> --
> pgp-key 0x1C655CAB
>
>

From RPhookun at lecg.com  Sun Mar 22 15:04:39 2009
From: RPhookun at lecg.com (RPhookun at lecg.com)
Date: Sun, 22 Mar 2009 12:04:39 -0700
Subject: [c-nsp] BGP conditional advertisemet - NON-EXIST
 route	map'saccess-list problem
In-Reply-To: <d9281f5c0903220145w4dbbf896uc4f8587fdf6b1e4e@mail.gmail.com>
Message-ID: <OF8487B18F.4232868D-ON88257581.0068557C-88257581.0068FF7A@lecg.com>

Hi Burak,

It is working as expected.

The rib-failure status message; is expected. Here's why:

The rib-failure is saying that  *this* /24 which is in the BGP table of 
router# couldn't be installed in the IP routing table of router#. This is 
normal because what is installed in the RIB of router # is the *connected* 
version of this /24. The connected route has an AD of 0 which takes 
precedence over the same route that is learned via eBGP with an AD of 20.

Regards,
./Randy




Burak Dikici <bdikici at gmail.com> 
Sent by: cisco-nsp-bounces at puck.nether.net
03/22/2009 01:45 AM

To
RPhookun at lecg.com
cc
ip at ioshints.info, cisco-nsp-bounces at puck.nether.net, 
cisco-nsp at puck.nether.net
Subject
Re: [c-nsp] BGP conditional advertisemet - NON-EXIST route 
map'saccess-list problem






  Hello ,

 Here is the final result updates of the lab.
*** I have started to advertise the subnet on the ISP-1 which is between 
my
router and ISP-1 router ;
ISP-1(config)#router bgp 200
ISP-1(config-router)#network 192.168.200.0 mask 255.255.255.0
ISP-1#clear ip bgp * soft

ISP-1#show ip bgp
BGP table version is 4, local router ID is 192.168.200.1
Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network          Next Hop            Metric LocPrf Weight Path
*> 10.1.1.0/24      192.168.200.2            0             0 10 i
*> 172.16.1.0/24    0.0.0.0                  0         32768 i
*> 192.168.200.0    0.0.0.0                  0         32768 i


*** I am getting RIB-failure error for 192.168.200.0 subnet on my Router.

Router#show ip bgp
BGP table version is 9, local router ID is 192.168.100.2
Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network          Next Hop            Metric LocPrf Weight Path
*> 10.1.1.0/24      0.0.0.0                  0         32768 i
*> 172.16.1.0/24    192.168.200.1            0          1000 200 i
r> 192.168.200.0    192.168.200.1            0          1000 200 i


*** Then , i have changed the BGP conditional advertisement configuration 
on
my Router like this ;
Router#
access-list 60 permit 10.1.1.0 0.0.0.255
access-list 65 permit 192.168.200.0 0.0.0.255
route-map NON-EXIST permit 10
 match ip address 65
route-map ADVERTISE permit 10
 match ip address 60
router bgp 10
 neighbor 192.168.100.1 advertise-map ADVERTISE non-exist-map NON-EXIST



***  At the beginnning , the Advertise-map status for ISP-2 is Withdraw ;
Router#
 show ip bgp neighbors 192.168.100.1
  Condition-map NON-EXIST, Advertise-map ADVERTISE, status: Withdraw

ISP-2#show ip bgp
  EMPTY


*** Then , i shutdown the Router's fa0/0 interface which is ISP-1
connection.
Router#
interface FastEthernet0/0     ( ISP-1 interface )
 ip address 192.168.200.2 255.255.255.0
 shutdown


*** The Advertise-map status for ISP-2 goes Advertise ;
Router#
 show ip bgp neighbors 192.168.100.1
  Condition-map NON-EXIST, Advertise-map ADVERTISE, status: Advertise


*** And ISP-2 is getting the my Router's advertisement ;
ISP-2# show ip bgp
BGP table version is 8, local router ID is 192.168.100.1
Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network          Next Hop            Metric LocPrf Weight Path
*> 10.1.1.0/24      192.168.100.2            0             0 10 i


*** As a result , it looks working with tracking of the subnet which is
between my router and ISP-1 router. But, i am sitll getting RIB-failure on
my router for this subnet. Does it look OK for you ?

Burak




On Sun, Mar 22, 2009 at 10:05 AM, Burak Dikici <bdikici at gmail.com> wrote:

> By the way , in the lab topology i have tried this config , but when i
> adversite 192.168.200.0 /24 subnet on ISP-1 with
>
> network 192.168.200.0 mask 255.255.255.0
> command , i am getting  RIB failure error on my router ;
>
> Router#show ip bgp
> BGP table version is 9, local router ID is 192.168.100.2
> Status codes: s suppressed, d damped, h history, * valid, > best, i -
> internal,
>               r RIB-failure, S Stale
> Origin codes: i - IGP, e - EGP, ? - incomplete
>     Network          Next Hop            Metric LocPrf Weight Path
> *> 10.1.1.0/24      0.0.0.0                  0         32768 i
> *> 172.16.1.0/24    192.168.200.1            0          1000 200 i
> r> 192.168.200.0    192.168.200.1            0          1000 200 i
>
>
> What should i do ? I have just tried to advertise the subnet on the 
ISP-1
> which is between my router and ISP-1 router.
>
>
>
> On Sun, Mar 22, 2009 at 9:46 AM, Burak Dikici <bdikici at gmail.com> wrote:
>
>>   Hi Randy ,
>>
>> I couldn't understand what you mean with a local-route  ? Could you
>> explain little more ?
>>
>> Burak
>>
>>
>>
>> On Sun, Mar 22, 2009 at 1:09 AM, <RPhookun at lecg.com> wrote:
>>
>>>
>>> Hi Burak,
>>> Ask ISP-A to announce the infrastructure /24 to router# as a 
local-route
>>> via a network statement 192.168.x.0 mask 255.255.255.0. They may not 
want to
>>> do the same via redistribute-connected(if rtr-ISP-1 is also used for
>>> peerring with other customers)
>>>
>>> ./Randy
>>>
>>>
>>>
>>>   *Burak Dikici <bdikici at gmail.com>*
>>> Sent by: cisco-nsp-bounces at puck.nether.net
>>>
>>> 03/21/2009 03:34 PM
>>>    To
>>> RPhookun at lecg.com  cc
>>> ip at ioshints.info, cisco-nsp-bounces at puck.nether.net,
>>> cisco-nsp at puck.nether.net
>>>   Subject
>>> Re: [c-nsp] BGP conditional advertisemet - NON-EXIST route
>>>  map'saccess-list problem
>>>
>>>
>>>
>>>
>>>
>>>    Hi Randy ,
>>>
>>> I have missied the point. I am going to talk this subject with the 
ISP-1.
>>> Kind Regards.
>>>
>>> Burak Dikici
>>>
>>>
>>>
>>>
>>> On Sat, Mar 21, 2009 at 8:12 PM, <RPhookun at lecg.com> wrote:
>>>
>>> >
>>> > Hi Burak,
>>> >
>>> > I had replied with the *fix* some days ago -
>>> > You can still use the ISP-1 infrastructrure /24. You have to have 
the
>>> ISP-1
>>> > router announce the /24 to router#
>>> > As you probably realise, this announcement is not required for the
>>> peering
>>> > session *itself* to be up.
>>> >
>>> > The annoucement by ISP-1 router of this /24 will cause it to appear 
in
>>> > router#'s bgp table which you can then use as the tracked prefix.
>>> >
>>> > Router#'s routing table will always install only the 
*connected*(d-0)
>>> > version of this /24 which is what you want! The eBGP version(d-20) 
will
>>> > exist only in the bgp table as a valid prefix you can track.
>>> >
>>> > Hope this helps.
>>> > ./Randy
>>> >
>>> >
>>> >
>>> >   *Burak Dikici <bdikici at gmail.com>*
>>> > Sent by: cisco-nsp-bounces at puck.nether.net
>>> >
>>> > 03/21/2009 08:19 AM
>>> >    To
>>> > RPhookun at lecg.com, ip at ioshints.info  cc
>>> > cisco-nsp-bounces at puck.nether.net, cisco-nsp at puck.nether.net
>>> >  Subject
>>> > Re: [c-nsp] BGP conditional advertisemet - NON-EXIST route
>>> >  map'saccess-list problem
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >    Hello ,
>>> >
>>> > The main problem is which prefix should i track ? I can't use the
>>> > infrastructe subnet between my router and ISP-1 router , because it 
is
>>> > directly connected and it is in the routing table , not in the bgp
>>> table.
>>> > I was thinking on that , then i have decided to use reliable root 
DNS
>>> > servers subnets to track with acl or prefix-list , for example ;
>>> >
>>> > access-list 20 permit 198.41.0.0 0.0.0.255 /* a.root-servers.net */
>>> > access-list 20 permit 192.228.79.0 0.0.0.255 /* b.root-servers.net 
*/
>>> > access-list 20 permit 192.33.4.0 0.0.0.255 /* c.root-servers.net */
>>> > access-list 20 permit 128.8.0.0 0.0.255.255 /* d.root-servers.net */
>>> >
>>> > what do you think about this idea ?
>>> >
>>> > Burak Dikici
>>> >
>>> >
>>> >
>>> >
>>> > On Thu, Mar 19, 2009 at 2:48 PM, Burak Dikici <bdikici at gmail.com>
>>> wrote:
>>> >
>>> > >  Sorry about my late reply. I am very busy these days with another
>>> > project.
>>> > > I am going to test your recommendations in a few days , and going 
to
>>> > reply
>>> > > back to you. Thank you all. Kind Regards...
>>> > >
>>> > > Burak Dikici
>>> > >
>>> > >
>>> > >
>>> > > On Wed, Mar 18, 2009 at 12:04 AM, <RPhookun at lecg.com> wrote:
>>> > >
>>> > >>
>>> > >> The prefix-list within the Non-Exist clause also has to *exactly*
>>> match
>>> > >> the prefix in the bgp table..
>>> > >> Regards,
>>> > >> ./Randy
>>> > >>
>>> > >>
>>> > >>
>>> > >>
>>> > >>   *"Ivan Pepelnjak" <ip at ioshints.info>*
>>> > >> Sent by: cisco-nsp-bounces at puck.nether.net
>>> > >>
>>> > >> 03/17/2009 02:20 PM
>>> > >>    To
>>> > >> "'Dale Shaw'" 
<dale.shaw+cisco-nsp at gmail.com<dale.shaw%2Bcisco-nsp at gmail.com>
>>> <dale.shaw%2Bcisco-nsp at gmail.com <dale.shaw%252Bcisco-nsp at gmail.com>>
>>> > <dale.shaw%2Bcisco-nsp at gmail.com <dale.shaw%252Bcisco-nsp at gmail.com> 
<
>>> dale.shaw%252Bcisco-nsp at gmail.com 
<dale.shaw%25252Bcisco-nsp at gmail.com>>>>,
>>>
>>>
>>> >
>>> > >> "'Burak Dikici'" <bdikici at gmail.com>  cc
>>> > >>   cisco-nsp at puck.nether.net  Subject
>>> > >> Re: [c-nsp] BGP conditional advertisemet - NON-EXIST route
>>> > >>  map'saccess-list problem
>>> > >>
>>> > >>
>>> > >>
>>> > >>
>>> > >>
>>> > >>  Did some tests on the NON-EXIST-MAP with 12.2SRC. I was 
spreading
>>> wrong
>>> > >> rumors, time to fix them:
>>> > >>
>>> > >> * The route-map checks the routes in the BGP table (_not_ in the 
IP
>>> > >> routing
>>> > >> table). Dale was right.
>>> > >> * It can take a while for the routes to be advertised/withdrawn; 
the
>>> > >> non-exist-map is checked only at the BGP scan intervals (60 
seconds
>>> by
>>> > >> default, can be adjusted).
>>> > >> * You can use a combination of an access-list and AS-path
>>> access-list in
>>> > >> the
>>> > >> route-map.
>>> > >>
>>> > >> The handling of standard access-lists used in the "match ip 
address"
>>> > >> route-map condition is a bit weird, though:
>>> > >>
>>> > >> * "permit any" does _NOT_ work.
>>> > >> * "permit prefix 0.0.0.0" (which gets translated into "permit
>>> prefix" in
>>> > >> standard ACL) does _NOT_ work.
>>> > >> * fancy wildcard tests (for example "permit 0.0.0.0 
127.255.255.255)
>>> do
>>> > >> _NOT_ work
>>> > >>
>>> > >> It looks like:
>>> > >>
>>> > >> * the IP prefix in the BGP table must match the address in the 
ACL
>>> > exactly
>>> > >> (wildcard bits are ignored).
>>> > >> * ... but you still need the wildcard bits (inverted netmask) for
>>> the
>>> > >> match
>>> > >> to work.
>>> > >>
>>> > >> For example: if you want to match 10.8.8.0/24, you have to use
>>> "permit
>>> > >> 10.8.8.0 0.0.0.255". "permit 10.8.8.0" or "permit 10.8.0.0
>>> 0.0.255.255"
>>> > do
>>> > >> _NOT_ work.
>>> > >>
>>> > >> Left to do: tests with the ip prefix-list instead of IP access 
list
>>> (and
>>> > >> no,
>>> > >> I will NOT test extended ACL :).
>>> > >>
>>> > >> Hope this helps
>>> > >> Ivan
>>> > >>
>>> > >> > -----Original Message-----
>>> >  >> > From: Dale Shaw 
[mailto:dale.shaw+cisco-nsp at gmail.com<dale.shaw%2Bcisco-nsp at gmail.com>
>>> <dale.shaw%2Bcisco-nsp at gmail.com <dale.shaw%252Bcisco-nsp at gmail.com>>
>>>  > <dale.shaw%2Bcisco-nsp at gmail.com 
<dale.shaw%252Bcisco-nsp at gmail.com><
>>> dale.shaw%252Bcisco-nsp at gmail.com 
<dale.shaw%25252Bcisco-nsp at gmail.com>
>>> >>]
>>> > >>
>>> > >> > Sent: Sunday, March 15, 2009 11:33 PM
>>> > >> > To: Burak Dikici
>>> > >> > Cc: cisco-nsp at puck.nether.net
>>> > >> > Subject: Re: [c-nsp] BGP conditional advertisemet - NON-EXIST
>>> > >> > route map'saccess-list problem
>>> > >> >
>>> > >> > Hi Burak,
>>> > >> >
>>> > >> > On Mon, Mar 16, 2009 at 12:06 AM, Burak Dikici
>>> > >> > <bdikici at gmail.com> wrote:
>>> > >> > > i am trying to use
>>> > >> > > BGP conditional advertisemet configuration. I have got a
>>> > >> > problem with
>>> > >> > > NON-EXIST route map's access-list. In the NON-EXIST router 
map i
>>> am
>>> > >> > > using the commands which is written below ;
>>> > >> >
>>> > >> > Here are some notes I made recently when playing with BGP
>>> > >> > conditional advertising. I hope it helps.
>>> > >> >
>>> > >> > 1.) prefixes matched in advertise-map and exist/non-exist map
>>> > >> > must exist (or not) in the *BGP* table
>>> > >> >  however: they do not need to be locally originated (e.g. R1
>>> > >> > can match routes received from R2 and advertise (or not) to R3
>>> > >> >  and: the validity of the prefix in the BGP table (i.e.
>>> > >> > RIB-failure) doesn't matter. if there's there, and using
>>> > >> > exist-map, the condition is met.
>>> > >> >
>>> > >> > 2.) when using 'exist' map, prefixes matched by advertise-map
>>> > >> > are advertised when exist-map condition is met
>>> > >> >  example: advertise 1.0.0.0/8 (advertise-map) from BGP table 
when
>>> > >> > 3.20.20.0/24 (exist-map) exists in BGP table
>>> > >> >
>>> > >> > 3.) when exist 'non-exist' map, prefixes matched by
>>> > >> > advertise-map are advertised when non-exist-map condition is 
met
>>> > >> >  example: advertise 1.0.0.0/8 (advertise-map) from BGP table 
when
>>> > >> > 3.20.20.0/24 (non-exist-map) does NOT exist in BGP table
>>> > >> >
>>> > >> > 4.) prefixes matched in advertise-map are the only prefixes
>>> > >> > affected -- other prefixes that may exist are advertised (or
>>> > >> > not) as normal
>>> > >> >
>>> > >> > 5.) when dealing with conditional advertisement tasks, always
>>> > >> > consider what will happen normally (without any config)
>>> > >> >
>>> > >> > I'd be happy to be corrected, but I think the first point is
>>> > >> > contrary to what Ivan said. Also consider point #4 -- BGP
>>> > >> > conditional advertising is not strictly a route filtering
>>> > >> > mechanism, although it can be configured to achieve similar
>>> results.
>>> > >> >
>>> > >> > cheers,
>>> > >> > Dale
>>> > >> >
>>> > >> >
>>> > >>
>>> > >> _______________________________________________
>>> > >> cisco-nsp mailing 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/
>>>
>>>
>>
>
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


From justin at justinshore.com  Sun Mar 22 23:25:43 2009
From: justin at justinshore.com (Justin Shore)
Date: Sun, 22 Mar 2009 22:25:43 -0500
Subject: [c-nsp] Changing SSH Port on IOS
In-Reply-To: <49C527AF.7010108@thewybles.com>
References: <000001c9aa4b$2cd20400$86760c00$@bierlair@root.lu>
	<49C527AF.7010108@thewybles.com>
Message-ID: <49C70137.90001@justinshore.com>

Agreed.  Never ever put an IOS box up on the Internet with a public IP 
without at least restricting VTY access.

We were directly targetted about 3 years ago right after I came back to 
the SP.  My predecessor hadn't implemented any VTY ACLs.  One day I 
while going through my rediscovery of the network I started noticing 
that I couldn't get into several devices.  The list of devices I 
couldn't access grew rapidly and within an hour I couldn't log into 
anything.  The attacker pounded every piece of network gear we had from 
hundreds of remote IPs trying to guess a working userid/password combo. 
  They consumed all VTYs on every device at once.  The gear was in 2 
states and spread out over many hours of driving so I couldn't visit 
much of it in person.  I spent well over a day getting everything tied 
down.  Fortunately syslog confirmed that we hadn't been compromised.

Forgetting the VTY ACL is like forgetting to check you fly being picking 
up your hot date for the big night or forgetting to turn off your cell 
phone ringer before showing up at the interview for the perfect job.

 >> #sh ip ssh
 >> SSH Enabled - version 1.99

Also, disable SSH version 1 support.  Only use SSHv2.

ip ssh version 2

Justin



Charles Wyble wrote:
> Um..... why don't you setup some ACL to limit access? It's generally ill 
> advised to run dameons with shell access directly connected to the 
> internet. :)
> 
> I use OpenVPN for all my access, and only run SSH on the private 
> interface. I realize this isn't always possible, but is a good solution.
> 
> Andy BIERLAIR wrote:
>> I'm running s72033-ipservicesk9-mz.122-18.SXF15a with SSH on Port 22.
>>
>> Due too many bots hammering that well-known port, I wanted to change 
>> it to
>> something else, but somehow I can't:


From Charles at thewybles.com  Sun Mar 22 23:35:36 2009
From: Charles at thewybles.com (Charles at thewybles.com)
Date: Mon, 23 Mar 2009 03:35:36 +0000
Subject: [c-nsp] Changing SSH Port on IOS
Message-ID: <1098863275-1237779357-cardhu_decombobulator_blackberry.rim.net-1785400265-@bxe1302.bisx.prod.on.blackberry>

Yes ssh 2 only. Critical point.  Cisco change the default already!! 


Sent via BlackBerry from T-Mobile

From cchurc05 at harris.com  Sun Mar 22 23:40:54 2009
From: cchurc05 at harris.com (Church, Charles)
Date: Sun, 22 Mar 2009 22:40:54 -0500
Subject: [c-nsp] Changing SSH Port on IOS
In-Reply-To: <49C70137.90001@justinshore.com>
References: <000001c9aa4b$2cd20400$86760c00$@bierlair@root.lu><49C527AF.7010108@thewybles.com>
	<49C70137.90001@justinshore.com>
Message-ID: <FA1BA229357DB640B944218F3585FECA02122914@mspe2k1.cs.myharris.net>

Another useful feature in newer IOSs is 'Cisco IOS login enhancements'.
We find it pretty useful.  Upon so many failed logins in a certain
timeframe, it can fall back to a more restrictive ACL, then go back to
the original after so many minutes.  
http://www.cisco.com/en/US/docs/ios/security/configuration/guide/sec_log
in_enhance.html

Chuck 

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Justin Shore
Sent: Sunday, March 22, 2009 11:26 PM
To: Charles Wyble
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Changing SSH Port on IOS


Agreed.  Never ever put an IOS box up on the Internet with a public IP 
without at least restricting VTY access.

We were directly targetted about 3 years ago right after I came back to 
the SP.  My predecessor hadn't implemented any VTY ACLs.  One day I 
while going through my rediscovery of the network I started noticing 
that I couldn't get into several devices.  The list of devices I 
couldn't access grew rapidly and within an hour I couldn't log into 
anything.  The attacker pounded every piece of network gear we had from 
hundreds of remote IPs trying to guess a working userid/password combo. 
  They consumed all VTYs on every device at once.  The gear was in 2 
states and spread out over many hours of driving so I couldn't visit 
much of it in person.  I spent well over a day getting everything tied 
down.  Fortunately syslog confirmed that we hadn't been compromised.

Forgetting the VTY ACL is like forgetting to check you fly being picking

up your hot date for the big night or forgetting to turn off your cell 
phone ringer before showing up at the interview for the perfect job.

 >> #sh ip ssh
 >> SSH Enabled - version 1.99

Also, disable SSH version 1 support.  Only use SSHv2.

ip ssh version 2

Justin



Charles Wyble wrote:
> Um..... why don't you setup some ACL to limit access? It's generally
ill 
> advised to run dameons with shell access directly connected to the 
> internet. :)
> 
> I use OpenVPN for all my access, and only run SSH on the private 
> interface. I realize this isn't always possible, but is a good
solution.
> 
> Andy BIERLAIR wrote:
>> I'm running s72033-ipservicesk9-mz.122-18.SXF15a with SSH on Port 22.
>>
>> Due too many bots hammering that well-known port, I wanted to change 
>> it to
>> something else, but somehow I can't:

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

From networkstuff.training at gmail.com  Mon Mar 23 01:09:43 2009
From: networkstuff.training at gmail.com (Swati Sharma)
Date: Mon, 23 Mar 2009 10:39:43 +0530
Subject: [c-nsp] isis adjecency...
In-Reply-To: <660CDBE9F5177645BF5FAE6EFE2D9BA406FB0F61@xmb-ams-332.emea.cisco.com>
References: <8a93d4b30903210134pdbb1596hb1d8c53e6b1fcc1e@mail.gmail.com>
	<660CDBE9F5177645BF5FAE6EFE2D9BA406FB0F61@xmb-ams-332.emea.cisco.com>
Message-ID: <8a93d4b30903222209y60da3600t62060867c3e39bca@mail.gmail.com>

Hi All,

Thanks for prompt reply. My fault, I forgot to put mpls ldp sync under
address family. Now it is up.

2nd point - the command is --> hello-password text clear "" , which when
display on sh config, shows as hello-password text encry...

Regards,



On Sat, Mar 21, 2009 at 3:28 PM, Mark Mckillop (mmckillo) <
mmckillo at cisco.com> wrote:

> Have you checked the MTU on the switch in the middle?
>
> R7#show system mtu
> System MTU size is 1500 bytes
>
> Mark.
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Swati Sharma
> Sent: Saturday, March 21, 2009 8:34 AM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] isis adjecency...
>
> Hi,
>
> I have below topology..
>
> 6500 --- 3750 --- crs1
>
> @ 6500 I have created vlan 250, which i am trying to establish isis adj
> with
> one of the sub-interface in crs. From 6500 to 3750 i have created trunk
> and
> allowed vlan 250. Similarly a trunk between 3750 to crs1 (Tengig
> subinterface). MTU on 3750 is 9k byte. I am not able to establish isis
> adjcency.
>
> I know the issue is with mtu as i checked with enabling ospf and ignore
> mtu.
> But not able to rectify the issue..
>
> 6500#debug isis adj-packets vlan 250
> IS-IS Adjacency related packets debugging is on
> *Mar 21 08:11:32.384 UTC: ISIS-Adj: Sending serial IIH on Vlan250,
> length
> 1508
> *Mar 21 08:11:34.772 UTC: ISIS-Adj: Sending serial IIH on Vlan250,
> length
> 1508
> *Mar 21 08:11:37.496 UTC: ISIS-Adj: Sending serial IIH on Vlan250,
> length
> 1508
> *Mar 21 08:11:40.360 UTC: ISIS-Adj: Sending serial IIH on Vlan250,
> length
> 1508
> *Mar 21 08:11:42.684 UTC: ISIS-Adj: Sending serial IIH on Vlan250,
> length
> 1508
>
> also it is not accepting - hello-password text
>
> RP/0/RP0/CPU0:crs1.LAB(config)#router isis XXX
> RP/0/RP0/CPU0:crs1.LAB(config-isis)#interface TenGigE0/1/2/0.250
> RP/0/RP0/CPU0:crs1.LAB(config-isis-if)#hello-password text encrypted
> XXXYYY
> RP/0/RP0/CPU0:crs1.LAB(config-isis-if)#commit
> % Failed to commit one or more configuration items during an atomic
> operation, no changes have been made. Please use 'show configuration
> failed'
> to view the errors
>
> @crs1 - sh int TenGigE0/1/2/0.250
> TenGigE0/1/2/0.250 is up, line protocol is up
>  Interface state transitions: 3
>  Hardware is VLAN sub-interface(s), address is 001e.f73d.79b1
>  Internet address is 10.74.66.30/31
>  MTU 1530 bytes, BW 10000000 Kbit
>     reliability 255/255, txload 0/255, rxload 0/255
>  Encapsulation 802.1Q Virtual LAN, VLAN Id 250,  loopback not set,
>  ARP type ARPA, ARP timeout 04:00:00
>  Last clearing of "show interface" counters never
>  5 minute input rate 5000 bits/sec, 0 packets/sec
>  5 minute output rate 0 bits/sec, 0 packets/sec
>     196299 packets input, 110348088 bytes, 0 total input drops
>     0 drops for unrecognized upper-level protocol
>     Received 2 broadcast packets, 196073 multicast packets
>     258 packets output, 16772 bytes, 0 total output drops
>     Output 12 broadcast packets, 63 multicast packets
>
>
> any idea where is the issue ....it was working fine when i established
> isis
> adj with 6500 physical interface...
>
> 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/
>

From tseveendorj at gmail.com  Mon Mar 23 02:14:40 2009
From: tseveendorj at gmail.com (Tseveendorj Ochirlantuu)
Date: Mon, 23 Mar 2009 14:14:40 +0800
Subject: [c-nsp] PPPoE related question
In-Reply-To: <70B7A1CCBFA5C649BD562B6D9F7ED78407141A99@xmb-ams-333.emea.cisco.com>
References: <49C5F183.5060904@googlemail.com>
	<70B7A1CCBFA5C649BD562B6D9F7ED78407141A99@xmb-ams-333.emea.cisco.com>
Message-ID: <62c908120903222314k4dc9ec3ay9625a7694110ae70@mail.gmail.com>

Thank you very much.

Christoph Loibl
Oliver Boehmer

Regards,
Tseveen.

On Sun, Mar 22, 2009 at 4:50 PM, Oliver Boehmer (oboehmer) <
oboehmer at cisco.com> wrote:

> Tseveendorj <> wrote on Sunday, March 22, 2009 09:06:
>
> > Hello,
> >
> > I'm trying to do PPPoE on c3825 router but I faced VPDN related
> > problem. c3825-ipvoicek9-mz.124-11.T4 IOS has only 2 (PPTP, L2TP)
> > options in protocol.
>
> haven't looked at this in a while, but you need to use bba-group instead
> of vpdn-group for pppoe. i.e.
>
> vpdn enable
> bba-group pppoe global
>  virtual-template 1
> !
> interface fastethernet0/0
>  pppoe enable
>
> hope this helps..
>
>

From skeeve at eintellego.net  Mon Mar 23 02:57:14 2009
From: skeeve at eintellego.net (Skeeve Stevens)
Date: Mon, 23 Mar 2009 17:57:14 +1100
Subject: [c-nsp] Pulling a VLAN out of a QinQ trunk
Message-ID: <292AF25E62B8894C921B893B53A19D97394469DED2@BUSINESSEX.business.ad>

Hey all,

Say I have a QinQ VLAN from one place to another... and it goes through a few switches.

If I wanted to do something to one of the VLAN's inside the QinQ, is that possible?

Examples of things I would like to do.

-       SVI with a IP address in an intermediate switch
-       Push it into a trunk on an intermediate switch to break it out

I've googled, but when I got to PPPoEoQinQ my mind exploded with too many layers!

...Skeeve

--
Skeeve Stevens, CEO/Technical Director
eintellego Pty Ltd - The Networking Specialists
skeeve at eintellego.net / www.eintellego.net
Phone: 1300 753 383, Fax: (+612) 8572 9954
Cell +61 (0)414 753 383 / skype://skeeve
--
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 zivl at gilat.net  Mon Mar 23 03:52:42 2009
From: zivl at gilat.net (Ziv Leyes)
Date: Mon, 23 Mar 2009 09:52:42 +0200
Subject: [c-nsp] Changing SSH Port on IOS
In-Reply-To: <FA1BA229357DB640B944218F3585FECA02122914@mspe2k1.cs.myharris.net>
References: <000001c9aa4b$2cd20400$86760c00$@bierlair@root.lu><49C527AF.7010108@thewybles.com>
	<49C70137.90001@justinshore.com>
	<FA1BA229357DB640B944218F3585FECA02122914@mspe2k1.cs.myharris.net>
Message-ID: <EC993E87D960A541A66BF21D62AA42A622E2056244@exch2k7.gilat.local>

Nice feature the login enhancement, but could you please share with me what would be a good recommended setting for all the values?
On the web page they talk about using the "auto secure" command, I don't seem to have such option on my IOS, but I have all the others, so I guess I'll have to set it up manually, so what do you recommend?
Ziv


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Church, Charles
Sent: Monday, March 23, 2009 5:41 AM
To: Justin Shore; Charles Wyble
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Changing SSH Port on IOS

Another useful feature in newer IOSs is 'Cisco IOS login enhancements'.
We find it pretty useful.  Upon so many failed logins in a certain
timeframe, it can fall back to a more restrictive ACL, then go back to
the original after so many minutes.  
http://www.cisco.com/en/US/docs/ios/security/configuration/guide/sec_log
in_enhance.html

Chuck 

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Justin Shore
Sent: Sunday, March 22, 2009 11:26 PM
To: Charles Wyble
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Changing SSH Port on IOS


Agreed.  Never ever put an IOS box up on the Internet with a public IP 
without at least restricting VTY access.

We were directly targetted about 3 years ago right after I came back to 
the SP.  My predecessor hadn't implemented any VTY ACLs.  One day I 
while going through my rediscovery of the network I started noticing 
that I couldn't get into several devices.  The list of devices I 
couldn't access grew rapidly and within an hour I couldn't log into 
anything.  The attacker pounded every piece of network gear we had from 
hundreds of remote IPs trying to guess a working userid/password combo. 
  They consumed all VTYs on every device at once.  The gear was in 2 
states and spread out over many hours of driving so I couldn't visit 
much of it in person.  I spent well over a day getting everything tied 
down.  Fortunately syslog confirmed that we hadn't been compromised.

Forgetting the VTY ACL is like forgetting to check you fly being picking

up your hot date for the big night or forgetting to turn off your cell 
phone ringer before showing up at the interview for the perfect job.

 >> #sh ip ssh
 >> SSH Enabled - version 1.99

Also, disable SSH version 1 support.  Only use SSHv2.

ip ssh version 2

Justin



Charles Wyble wrote:
> Um..... why don't you setup some ACL to limit access? It's generally
ill 
> advised to run dameons with shell access directly connected to the 
> internet. :)
> 
> I use OpenVPN for all my access, and only run SSH on the private 
> interface. I realize this isn't always possible, but is a good
solution.
> 
> Andy BIERLAIR wrote:
>> I'm running s72033-ipservicesk9-mz.122-18.SXF15a with SSH on Port 22.
>>
>> Due too many bots hammering that well-known port, I wanted to change 
>> it to
>> something else, but somehow I can't:

_______________________________________________
cisco-nsp mailing 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/
 
 
************************************************************************************
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 cphillips at wbsconnect.com  Mon Mar 23 04:50:15 2009
From: cphillips at wbsconnect.com (Chris Phillips)
Date: Mon, 23 Mar 2009 02:50:15 -0600 (MDT)
Subject: [c-nsp] Pulling a VLAN out of a QinQ trunk
In-Reply-To: <1428918582.646921237798208372.JavaMail.root@zimbra.wbsconnect.com>
Message-ID: <1346767844.646941237798215552.JavaMail.root@zimbra.wbsconnect.com>

There is a way that I know, but it's not pretty.

Build the QnQ to an additional port on the device you want to inject/break out the VLAN from.  Make sure it is mode dot1q-tunnel.  Then loop it (cross connect it) to another port on the same device and make that is a trunk port.  Specify the VLAN you want and you're done.

I've done this a few times and it works just fine.  As mentioned, it is not very elegant and someone might know a better way to do it, like tagging the native.  The method described above can inject/break out multiple VLANs, where as fiddling with the native cannot.

Good luck.

----- Original Message -----
From: "Skeeve Stevens" <skeeve at eintellego.net>
To: cisco-nsp at puck.nether.net
Sent: Monday, March 23, 2009 2:57:14 AM GMT -05:00 US/Canada Eastern
Subject: [c-nsp] Pulling a VLAN out of a QinQ trunk

Hey all,

Say I have a QinQ VLAN from one place to another... and it goes through a few switches.

If I wanted to do something to one of the VLAN's inside the QinQ, is that possible?

Examples of things I would like to do.

-       SVI with a IP address in an intermediate switch
-       Push it into a trunk on an intermediate switch to break it out

I've googled, but when I got to PPPoEoQinQ my mind exploded with too many layers!

...Skeeve

--
Skeeve Stevens, CEO/Technical Director
eintellego Pty Ltd - The Networking Specialists
skeeve at eintellego.net / www.eintellego.net
Phone: 1300 753 383, Fax: (+612) 8572 9954
Cell +61 (0)414 753 383 / skype://skeeve
--
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 blahu77 at gmail.com  Mon Mar 23 05:31:46 2009
From: blahu77 at gmail.com (Mateusz Blaszczyk)
Date: Mon, 23 Mar 2009 09:31:46 +0000 (IST)
Subject: [c-nsp] isis adjecency...
In-Reply-To: <8a93d4b30903222209y60da3600t62060867c3e39bca@mail.gmail.com>
Message-ID: <fsmykxkz4fiu3oaznsUYAxe124vaj_firegpg@mail.gmail.com>



2009/3/23 Swati Sharma <networkstuff.training at gmail.com>:
> Hi All,
>
> Thanks for prompt reply. My fault, I forgot to put mpls ldp sync under
> address family. Now it is up.

and what does it have to do with isis adj?
am I missing something here?

-- 
pgp-key 0x1C655CAB

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 270 bytes
Desc: OpenPGP digital signature
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090323/a62a0a39/attachment.bin>

From ibrahim.abozaid at gmail.com  Mon Mar 23 06:59:28 2009
From: ibrahim.abozaid at gmail.com (Ibrahim Abo Zaid)
Date: Mon, 23 Mar 2009 12:59:28 +0200
Subject: [c-nsp] stateful dynamic traffic forwarding solution
Message-ID: <a48927f70903230359w375a7f77tfdc1035c01e7968d@mail.gmail.com>

Hi All


I am looking for IOS feature or solution can do the following , there are 2
hosts A and B from the same subnet , when host A connects to host B , router
should forward traffic to next-hop X while when host B connects to A ,
router should forward traffic to next-hop Y

both A and B are random IPs from the same subnet and X and Y are fixed
next-hop

is there any kind of dynamic access-list can be used in PBR so ACL-AB
forward traffic to X and a reverse version created automatically ACL-BA
forwards the traffic to Y ?
can that be done with FW or ASA instead of router ? or can that be done
using content switch or content networking feature ?


your suggestions are highly appreciated .


best regards
--Ibrahim

From mtinka at globaltransit.net  Mon Mar 23 06:17:00 2009
From: mtinka at globaltransit.net (Mark Tinka)
Date: Mon, 23 Mar 2009 18:17:00 +0800
Subject: [c-nsp] isis adjecency...
In-Reply-To: <fsmykxkz4fiu3oaznsUYAxe124vaj_firegpg@mail.gmail.com>
References: <fsmykxkz4fiu3oaznsUYAxe124vaj_firegpg@mail.gmail.com>
Message-ID: <200903231817.01774.mtinka@globaltransit.net>

On Monday 23 March 2009 05:31:46 pm Mateusz Blaszczyk wrote:

> and what does it have to do with isis adj?
> am I missing something here?

I was thinking the same thing - it might seem more probable 
that this might have had something to do with IOS XR's 
failure to commit the configuration, but need to hear from 
the horse's mouth :-).

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/20090323/5eac3ee7/attachment.bin>

From dmitry at dmitry.net  Mon Mar 23 06:52:33 2009
From: dmitry at dmitry.net (Dmitry Kiselev)
Date: Mon, 23 Mar 2009 12:52:33 +0200
Subject: [c-nsp] TCAM at Cat4500 Sup6E
In-Reply-To: <20090318160854.GH27954@f17.dmitry.net>
References: <20090318160854.GH27954@f17.dmitry.net>
Message-ID: <20090323105233.GJ27954@f17.dmitry.net>

Hello!

On Wed, Mar 18, 2009 at 06:08:54PM +0200, Dmitry Kiselev wrote:


I complete several TCAM management tests by myself and clearly
see that current 12.2(50)SG1 software do all TCAM rearrangements
pretty well.

Nice work, Cisco! A lot of thanks!


> Could anybody clear me with TCAM on Cat4500 Sup6E?
> Or Cat4900M as it is Sup6E based.
> 
> There are 64 TCAM blocks. Each of them can be DYNAMICALY
> configured as 80 or 160-bit with 4096 and 2048 entries
> accordingly.  IPv4 and IPv6 FIBs are builded DYNAMICALY
> using one or more TCAM blocks. Additional TCAM blocks
> are configured to apropriate bit-size and used if new FIB
> entry is learned and all previously allocated TCAM already
> used.  There are no stuff like "mls cef maximum-routes" or
> "sdm template" to preconfigure TCAM allocations.
> 
> Am I right?
> 
> How about optimizing TCAM blocks usage while freeing FIB
> entries?   Any other TCAM related caveats?

-- 
Dmitry Kiselev

From cchurc05 at harris.com  Mon Mar 23 09:02:06 2009
From: cchurc05 at harris.com (Church, Charles)
Date: Mon, 23 Mar 2009 08:02:06 -0500
Subject: [c-nsp] Changing SSH Port on IOS
In-Reply-To: <EC993E87D960A541A66BF21D62AA42A622E2056244@exch2k7.gilat.local>
References: <000001c9aa4b$2cd20400$86760c00$@bierlair@root.lu><49C527AF.7010108@thewybles.com><49C70137.90001@justinshore.com><FA1BA229357DB640B944218F3585FECA02122914@mspe2k1.cs.myharris.net>
	<EC993E87D960A541A66BF21D62AA42A622E2056244@exch2k7.gilat.local>
Message-ID: <FA1BA229357DB640B944218F3585FECA0212296E@mspe2k1.cs.myharris.net>

I use it on some managed routers sitting on other ISP networks.  We
allow access via the access class from the ISPs that us admins have home
accounts on, in addition to the block dedicated to the company that
manages them.  If we get more than 3 failed attempts in a 1 minute
period, it'll lock down to an ACL that allows only the corporate network
block, then unlock after 5 minutes (and the BOT has moved on).  Of
course you'll need to fine tune it for the amount of BOT traffic you've
got, etc.

Chuck

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Ziv Leyes
Sent: Monday, March 23, 2009 3:53 AM
To: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Changing SSH Port on IOS


Nice feature the login enhancement, but could you please share with me
what would be a good recommended setting for all the values?
On the web page they talk about using the "auto secure" command, I don't
seem to have such option on my IOS, but I have all the others, so I
guess I'll have to set it up manually, so what do you recommend?
Ziv


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Church, Charles
Sent: Monday, March 23, 2009 5:41 AM
To: Justin Shore; Charles Wyble
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Changing SSH Port on IOS

Another useful feature in newer IOSs is 'Cisco IOS login enhancements'.
We find it pretty useful.  Upon so many failed logins in a certain
timeframe, it can fall back to a more restrictive ACL, then go back to
the original after so many minutes.  
http://www.cisco.com/en/US/docs/ios/security/configuration/guide/sec_log
in_enhance.html

Chuck 

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Justin Shore
Sent: Sunday, March 22, 2009 11:26 PM
To: Charles Wyble
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Changing SSH Port on IOS


Agreed.  Never ever put an IOS box up on the Internet with a public IP 
without at least restricting VTY access.

We were directly targetted about 3 years ago right after I came back to 
the SP.  My predecessor hadn't implemented any VTY ACLs.  One day I 
while going through my rediscovery of the network I started noticing 
that I couldn't get into several devices.  The list of devices I 
couldn't access grew rapidly and within an hour I couldn't log into 
anything.  The attacker pounded every piece of network gear we had from 
hundreds of remote IPs trying to guess a working userid/password combo. 
  They consumed all VTYs on every device at once.  The gear was in 2 
states and spread out over many hours of driving so I couldn't visit 
much of it in person.  I spent well over a day getting everything tied 
down.  Fortunately syslog confirmed that we hadn't been compromised.

Forgetting the VTY ACL is like forgetting to check you fly being picking

up your hot date for the big night or forgetting to turn off your cell 
phone ringer before showing up at the interview for the perfect job.

 >> #sh ip ssh
 >> SSH Enabled - version 1.99

Also, disable SSH version 1 support.  Only use SSHv2.

ip ssh version 2

Justin



Charles Wyble wrote:
> Um..... why don't you setup some ACL to limit access? It's generally
ill 
> advised to run dameons with shell access directly connected to the 
> internet. :)
> 
> I use OpenVPN for all my access, and only run SSH on the private 
> interface. I realize this isn't always possible, but is a good
solution.
> 
> Andy BIERLAIR wrote:
>> I'm running s72033-ipservicesk9-mz.122-18.SXF15a with SSH on Port 22.
>>
>> Due too many bots hammering that well-known port, I wanted to change 
>> it to
>> something else, but somehow I can't:

_______________________________________________
cisco-nsp mailing 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/
 
 
************************************************************************
************
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.
************************************************************************
************

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

From skeeve at eintellego.net  Mon Mar 23 09:48:59 2009
From: skeeve at eintellego.net (Skeeve Stevens)
Date: Tue, 24 Mar 2009 00:48:59 +1100
Subject: [c-nsp] Pulling a VLAN out of a QinQ trunk
In-Reply-To: <1346767844.646941237798215552.JavaMail.root@zimbra.wbsconnect.com>
References: <1428918582.646921237798208372.JavaMail.root@zimbra.wbsconnect.com>
	<1346767844.646941237798215552.JavaMail.root@zimbra.wbsconnect.com>
Message-ID: <292AF25E62B8894C921B893B53A19D97394469DED9@BUSINESSEX.business.ad>

Actually... this is exactly what I came up with this afternoon as a work-around... but I was kind hoping it was stupid and there was an easier more sensible way.... is there? ;-)


--
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
--
NOC, NOC, who's there?


> -----Original Message-----
> From: Chris Phillips [mailto:cphillips at wbsconnect.com]
> Sent: Monday, 23 March 2009 7:50 PM
> To: Skeeve Stevens
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] Pulling a VLAN out of a QinQ trunk
>
> There is a way that I know, but it's not pretty.
>
> Build the QnQ to an additional port on the device you want to
> inject/break out the VLAN from.  Make sure it is mode dot1q-tunnel.
> Then loop it (cross connect it) to another port on the same device and
> make that is a trunk port.  Specify the VLAN you want and you're done.
>
> I've done this a few times and it works just fine.  As mentioned, it is
> not very elegant and someone might know a better way to do it, like
> tagging the native.  The method described above can inject/break out
> multiple VLANs, where as fiddling with the native cannot.
>
> Good luck.
>
> ----- Original Message -----
> From: "Skeeve Stevens" <skeeve at eintellego.net>
> To: cisco-nsp at puck.nether.net
> Sent: Monday, March 23, 2009 2:57:14 AM GMT -05:00 US/Canada Eastern
> Subject: [c-nsp] Pulling a VLAN out of a QinQ trunk
>
> Hey all,
>
> Say I have a QinQ VLAN from one place to another... and it goes through
> a few switches.
>
> If I wanted to do something to one of the VLAN's inside the QinQ, is
> that possible?
>
> Examples of things I would like to do.
>
> -       SVI with a IP address in an intermediate switch
> -       Push it into a trunk on an intermediate switch to break it out
>
> I've googled, but when I got to PPPoEoQinQ my mind exploded with too
> many layers!
>
> ...Skeeve
>
> --
> Skeeve Stevens, CEO/Technical Director
> eintellego Pty Ltd - The Networking Specialists
> skeeve at eintellego.net / www.eintellego.net
> Phone: 1300 753 383, Fax: (+612) 8572 9954
> Cell +61 (0)414 753 383 / skype://skeeve
> --
> 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 justin at justinshore.com  Mon Mar 23 11:49:17 2009
From: justin at justinshore.com (Justin Shore)
Date: Mon, 23 Mar 2009 10:49:17 -0500
Subject: [c-nsp] Changing SSH Port on IOS
In-Reply-To: <EC993E87D960A541A66BF21D62AA42A622E2056244@exch2k7.gilat.local>
References: <000001c9aa4b$2cd20400$86760c00$@bierlair@root.lu><49C527AF.7010108@thewybles.com>	<49C70137.90001@justinshore.com>	<FA1BA229357DB640B944218F3585FECA02122914@mspe2k1.cs.myharris.net>
	<EC993E87D960A541A66BF21D62AA42A622E2056244@exch2k7.gilat.local>
Message-ID: <49C7AF7D.1010405@justinshore.com>

I would suggest testing auto secure in a lab environment first rather 
than on a production device.  You don't want to auto secure your way out 
of admin access to the device...

Justin

Ziv Leyes wrote:
> Nice feature the login enhancement, but could you please share with me what would be a good recommended setting for all the values?
> On the web page they talk about using the "auto secure" command, I don't seem to have such option on my IOS, but I have all the others, so I guess I'll have to set it up manually, so what do you recommend?
> Ziv


From vijay.ramcharan at verizonbusiness.com  Mon Mar 23 11:22:18 2009
From: vijay.ramcharan at verizonbusiness.com (Ramcharan, Vijay A)
Date: Mon, 23 Mar 2009 15:22:18 +0000
Subject: [c-nsp] GRE throughput on 3750G
In-Reply-To: <292AF25E62B8894C921B893B53A19D97394469DED9@BUSINESSEX.business.ad>
Message-ID: <8171C8272CE8FE4A8F5BFF8A97CE6AB34B3FC9@ASHEVS006.mcilink.com>

All, 
I'm just looking for confirmation that GRE on the 3750G is done in
software with the resulting low throughput (~20Mbps with iperf across
GRE tunnel on 3750G). All testing and reading that I've done indicates
that the hardware on the 3750 is not especially built for
"router-specific" features like GRE. A "show int stats" shows that all
packets on the tunnel interface in a pair of 3750G switches is process
switched. The same command on a 3845 shows the majority of the traffic
is hardware switched/forwarded. 

Just a sanity check before I open a TAC case. 

Brief test output below was obtained using a pair of 3550 switches: 
Without GRE:
------------------------------------------
C:\>iperf -f m -s -p 333
------------------------------------------------------------
Server listening on TCP port 333
TCP window size: 0.01 MByte (default)
------------------------------------------------------------
[1752] local 172.16.0.2 port 333 connected with 172.16.1.2 port 1058
[ ID] Interval       Transfer     Bandwidth
[1752]  0.0-15.0 sec   165 MBytes  92.4 Mbits/sec


With GRE:
------------------------------------------
C:\>iperf -f m -s -p 333
------------------------------------------------------------
Server listening on TCP port 333
TCP window size: 0.01 MByte (default)
------------------------------------------------------------
[1752] local 172.16.0.2 port 333 connected with 172.16.1.2 port 1061
[ ID] Interval       Transfer     Bandwidth
[1752]  0.0-15.0 sec  23.7 MBytes  13.2 Mbits/sec
------------------------------------------------------------

Thanks much. 
 
Vijay Ramcharan 

From snortbsd at yahoo.com.au  Mon Mar 23 11:30:38 2009
From: snortbsd at yahoo.com.au (snort bsd)
Date: Mon, 23 Mar 2009 08:30:38 -0700 (PDT)
Subject: [c-nsp] ios upgrade for cisco 1200 airnet ap
Message-ID: <256886.20919.qm@web38104.mail.mud.yahoo.com>


Hi all:

I am trying to upgrade the ios for Cisco Aironet 1200 AIR-AP1231G-A-K9 Wireless AP and have few questions. It has only 16MB memory in it. 

1) Do I have to delete the original code before copy new code in? It seem to be so since every time I tried to copy new code in, in the half process, it started giving out more and more 0s, eventually it aborted the process.

2) I have two versions of new code "Cisco1200-k9w7-tar.123-8.JEB1" and "Cisco1200-k9w7-tar.123-8.JEC2". which should I use?

Thanks



      Stay connected to the people that matter most with a smarter inbox. Take a look http://au.docs.yahoo.com/mail/smarterinbox

From adrian at creative.net.au  Mon Mar 23 12:33:18 2009
From: adrian at creative.net.au (Adrian Chadd)
Date: Tue, 24 Mar 2009 01:33:18 +0900
Subject: [c-nsp] GRE throughput on 3750G
In-Reply-To: <8171C8272CE8FE4A8F5BFF8A97CE6AB34B3FC9@ASHEVS006.mcilink.com>
References: <292AF25E62B8894C921B893B53A19D97394469DED9@BUSINESSEX.business.ad>
	<8171C8272CE8FE4A8F5BFF8A97CE6AB34B3FC9@ASHEVS006.mcilink.com>
Message-ID: <20090323163318.GF18828@skywalker.creative.net.au>

On Mon, Mar 23, 2009, Ramcharan, Vijay A wrote:
> All, 
> I'm just looking for confirmation that GRE on the 3750G is done in
> software with the resulting low throughput (~20Mbps with iperf across
> GRE tunnel on 3750G). All testing and reading that I've done indicates
> that the hardware on the 3750 is not especially built for
> "router-specific" features like GRE. A "show int stats" shows that all
> packets on the tunnel interface in a pair of 3750G switches is process
> switched. The same command on a 3845 shows the majority of the traffic
> is hardware switched/forwarded. 

Uhm, unless the 3845 has some sugar I completely missed, its also
software forwarding it - its just that the 3845 IOS is 'optimised' for
software forwarding. The 3845 probably has much higher bus bandwidth
between the CPU and network interfaces. The 3750(G) also probably
has a much slower CPU.

> Just a sanity check before I open a TAC case. 

I bet the answer will be "Don't do GRE on 3750G, its unsupported."

HTH,


Adrian


From jared at puck.nether.net  Mon Mar 23 12:40:03 2009
From: jared at puck.nether.net (Jared Mauch)
Date: Mon, 23 Mar 2009 12:40:03 -0400
Subject: [c-nsp] ios upgrade for cisco 1200 airnet ap
In-Reply-To: <256886.20919.qm@web38104.mail.mud.yahoo.com>
References: <256886.20919.qm@web38104.mail.mud.yahoo.com>
Message-ID: <BE61BD9D-0FFF-4389-908F-7B7496250D16@puck.nether.net>

I've always done the upgrade via the web U/I.  If it fails, you can  
delete everything then copy and extract the tar.

I'm running JEC2

	- Jared

On Mar 23, 2009, at 11:30 AM, snort bsd wrote:

>
> Hi all:
>
> I am trying to upgrade the ios for Cisco Aironet 1200 AIR-AP1231G-A- 
> K9 Wireless AP and have few questions. It has only 16MB memory in it.
>
> 1) Do I have to delete the original code before copy new code in? It  
> seem to be so since every time I tried to copy new code in, in the  
> half process, it started giving out more and more 0s, eventually it  
> aborted the process.
>
> 2) I have two versions of new code "Cisco1200-k9w7-tar.123-8.JEB1"  
> and "Cisco1200-k9w7-tar.123-8.JEC2". which should I use?
>
> Thanks
>
>
>
>      Stay connected to the people that matter most with a smarter  
> inbox. Take a look http://au.docs.yahoo.com/mail/smarterinbox
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


From sethm at rollernet.us  Mon Mar 23 12:56:04 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Mon, 23 Mar 2009 09:56:04 -0700
Subject: [c-nsp] GRE throughput on 3750G
In-Reply-To: <8171C8272CE8FE4A8F5BFF8A97CE6AB34B3FC9@ASHEVS006.mcilink.com>
References: <8171C8272CE8FE4A8F5BFF8A97CE6AB34B3FC9@ASHEVS006.mcilink.com>
Message-ID: <49C7BF24.9010703@rollernet.us>

Ramcharan, Vijay A wrote:
> All, 
> I'm just looking for confirmation that GRE on the 3750G is done in
> software with the resulting low throughput (~20Mbps with iperf across
> GRE tunnel on 3750G). All testing and reading that I've done indicates
> that the hardware on the 3750 is not especially built for
> "router-specific" features like GRE. A "show int stats" shows that all
> packets on the tunnel interface in a pair of 3750G switches is process
> switched. The same command on a 3845 shows the majority of the traffic
> is hardware switched/forwarded. 
> 

3845 is still a software platform (with hardware crypto), but the CPU is
much faster. 3750 routes in hardware, however, its CPU is much slower if
you start doing stuff not supported in hardware.

~Seth

From ray at oneunified.net  Mon Mar 23 13:22:49 2009
From: ray at oneunified.net (Ray Burkholder)
Date: Mon, 23 Mar 2009 14:22:49 -0300
Subject: [c-nsp] GRE throughput on 3750G
In-Reply-To: <49C7BF24.9010703@rollernet.us>
References: <8171C8272CE8FE4A8F5BFF8A97CE6AB34B3FC9@ASHEVS006.mcilink.com>
	<49C7BF24.9010703@rollernet.us>
Message-ID: <0c0201c9abdc$1be53210$53af9630$@net>

> Ramcharan, Vijay A wrote:
> > All,
> > I'm just looking for confirmation that GRE on the 3750G is done in
> > software with the resulting low throughput (~20Mbps with iperf across
> > GRE tunnel on 3750G). All testing and reading that I've done
> indicates
> > that the hardware on the 3750 is not especially built for
> > "router-specific" features like GRE. A "show int stats" shows that
> all
> > packets on the tunnel interface in a pair of 3750G switches is
> process
> > switched. The same command on a 3845 shows the majority of the
> traffic
> > is hardware switched/forwarded.
> >
> 
> 3845 is still a software platform (with hardware crypto), but the CPU
> is
> much faster. 3750 routes in hardware, however, its CPU is much slower
> if
> you start doing stuff not supported in hardware.
> 

And I'm told GRE is not officially supported on the 3750.  Even though it
works, it isn't recommended, because, as you've found out, it is process
switched only.


-- 
Scanned for viruses and dangerous content at 
http://www.oneunified.net and is believed to be clean.


From vijay.ramcharan at verizonbusiness.com  Mon Mar 23 12:48:21 2009
From: vijay.ramcharan at verizonbusiness.com (Ramcharan, Vijay A)
Date: Mon, 23 Mar 2009 16:48:21 +0000
Subject: [c-nsp] GRE throughput on 3750G
In-Reply-To: <20090323163318.GF18828@skywalker.creative.net.au>
Message-ID: <8171C8272CE8FE4A8F5BFF8A97CE6AB34B40C3@ASHEVS006.mcilink.com>

Thanks for the clarifications and feedback received from all. 
GRE on 3750 = software switched with no candy and tastes bad :-( 
GRE on 3845 = software switched but with candy so it's more palatable
:-) 
 
Vijay Ramcharan 
  
-----Original Message-----
From: Adrian Chadd [mailto:adrian at creative.net.au] 
Sent: March 23, 2009 12:33
To: Ramcharan, Vijay A
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] GRE throughput on 3750G

On Mon, Mar 23, 2009, Ramcharan, Vijay A wrote:
> All, 
> I'm just looking for confirmation that GRE on the 3750G is done in
> software with the resulting low throughput (~20Mbps with iperf across
> GRE tunnel on 3750G). All testing and reading that I've done indicates
> that the hardware on the 3750 is not especially built for
> "router-specific" features like GRE. A "show int stats" shows that all
> packets on the tunnel interface in a pair of 3750G switches is process
> switched. The same command on a 3845 shows the majority of the traffic
> is hardware switched/forwarded. 

Uhm, unless the 3845 has some sugar I completely missed, its also
software forwarding it - its just that the 3845 IOS is 'optimised' for
software forwarding. The 3845 probably has much higher bus bandwidth
between the CPU and network interfaces. The 3750(G) also probably
has a much slower CPU.

> Just a sanity check before I open a TAC case. 

I bet the answer will be "Don't do GRE on 3750G, its unsupported."

HTH,


Adrian


______________________________________________________________________
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 jeff-kell at utc.edu  Mon Mar 23 13:32:09 2009
From: jeff-kell at utc.edu (Jeff Kell)
Date: Mon, 23 Mar 2009 13:32:09 -0400
Subject: [c-nsp] GRE throughput on 3750G
In-Reply-To: <8171C8272CE8FE4A8F5BFF8A97CE6AB34B40C3@ASHEVS006.mcilink.com>
References: <8171C8272CE8FE4A8F5BFF8A97CE6AB34B40C3@ASHEVS006.mcilink.com>
Message-ID: <49C7C799.4000604@utc.edu>

Ramcharan, Vijay A wrote:
> Thanks for the clarifications and feedback received from all. 
> GRE on 3750 = software switched with no candy and tastes bad :-( 
> GRE on 3845 = software switched but with candy so it's more palatable

But careful, too much of it will rot your teeth :-)

Jeff

From justin at justinshore.com  Mon Mar 23 14:55:19 2009
From: justin at justinshore.com (Justin Shore)
Date: Mon, 23 Mar 2009 13:55:19 -0500
Subject: [c-nsp] Exceeding the bandwidth points on a 7200
Message-ID: <49C7DB17.6020001@justinshore.com>

I have a situation on a 7206VXR w/ a NPE-G1 where I need to add a MC DS3 
module.  The box already has 4 PA-A3-OC3SMI PAs.  I'd like to add a 
PA-MC-T3 to the box as well.  I know that the OC3 PAs max the bandwidth 
points out for each PCI bus.  However the OC3s are very lightly loaded. 
  Looking back at the graphs I don't see any of the 4 peaking over 
5Mbps.  That may seem surprising considering that there are nearly 1000 
PVCs configured on those 4 OCs for DSL customers; the DSLAMs are very 
low-end, can only do basic ADSL, and the uplinks restrictthe average 
access speeds to extremely low levels.

So my question is what happens when I exceed the bandwidth points on a 
7200 where I know that bandwidth from the existing PAs won't ever be a 
problem?  The box as a whole peaks at around 12-15Mbps on its uplinks. 
That G1 is truly bored, averaging below 10% utilization.  I know that 
IOS will bitch about it on boot but it will still continue to work won't 
it?  Any other side effects (other than TAC not liking it if they see it 
until I demonstrate with the graphs that it's not a problem)?

Thanks
  Justin


From walter.keen at RainierConnect.net  Mon Mar 23 15:09:47 2009
From: walter.keen at RainierConnect.net (Walter Keen)
Date: Mon, 23 Mar 2009 12:09:47 -0700
Subject: [c-nsp] Exceeding the bandwidth points on a 7200
In-Reply-To: <49C7DB17.6020001@justinshore.com>
References: <49C7DB17.6020001@justinshore.com>
Message-ID: <49C7DE7B.70000@rainierconnect.net>

I think there was a supportable way of adding another module via the IO
slot using a special card in the IO slot that provides you with a PA
slot that doesn't count towards the BW points of the other busses if I
remember correctly.

Justin Shore wrote:
> I have a situation on a 7206VXR w/ a NPE-G1 where I need to add a MC
> DS3 module.  The box already has 4 PA-A3-OC3SMI PAs.  I'd like to add
> a PA-MC-T3 to the box as well.  I know that the OC3 PAs max the
> bandwidth points out for each PCI bus.  However the OC3s are very
> lightly loaded.  Looking back at the graphs I don't see any of the 4
> peaking over 5Mbps.  That may seem surprising considering that there
> are nearly 1000 PVCs configured on those 4 OCs for DSL customers; the
> DSLAMs are very low-end, can only do basic ADSL, and the uplinks
> restrictthe average access speeds to extremely low levels.
>
> So my question is what happens when I exceed the bandwidth points on a
> 7200 where I know that bandwidth from the existing PAs won't ever be a
> problem?  The box as a whole peaks at around 12-15Mbps on its uplinks.
> That G1 is truly bored, averaging below 10% utilization.  I know that
> IOS will bitch about it on boot but it will still continue to work
> won't it?  Any other side effects (other than TAC not liking it if
> they see it until I demonstrate with the graphs that it's not a problem)?
>
> 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 peter at rathlev.dk  Mon Mar 23 15:29:03 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Mon, 23 Mar 2009 20:29:03 +0100
Subject: [c-nsp] stateful dynamic traffic forwarding solution
In-Reply-To: <a48927f70903230359w375a7f77tfdc1035c01e7968d@mail.gmail.com>
References: <a48927f70903230359w375a7f77tfdc1035c01e7968d@mail.gmail.com>
Message-ID: <1237836543.29151.19.camel@localhost.localdomain>

Hi Ibrahim,

On Mon, 2009-03-23 at 12:59 +0200, Ibrahim Abo Zaid wrote:
> I am looking for IOS feature or solution can do the following , there
> are 2 hosts A and B from the same subnet , when host A connects to
> host B , router should forward traffic to next-hop X while when host B
> connects to A , router should forward traffic to next-hop Y
> 
> both A and B are random IPs from the same subnet and X and Y are fixed
> next-hop

How would traffic hit the router when the hosts are on the same subnet?
Isolated/protected ports and "local-proxy-arp" or something like that?

> is there any kind of dynamic access-list can be used in PBR so ACL-AB
> forward traffic to X and a reverse version created automatically
> ACL-BA forwards the traffic to Y ?

How would you recognize the flows? I could only see this work if the
router knew what hosts to cover. What algorithm would the router use to
select next-hop X or Y for a given flow?

Are you thinking about the time difference, so the first flow in time
would select one next-hop, and the reverse flow would select another?
I'm pretty sure IOS and ASA can't do this. Don't know about ACE and the
like. You might be able to hack something together with BSD or Linux
tools.

> can that be done with FW or ASA instead of router ? or can that be
> done using content switch or content networking feature ?

Assuming X and Y are static next hops, the combination of L2 isolated
ports, local-proxy-arp and PBR would be able to do it on IOS, but only
if you know in a deterministic fashion what hosts to route where.

Regards,
Peter



From john at johnlange.ca  Mon Mar 23 15:02:01 2009
From: john at johnlange.ca (John Lange)
Date: Mon, 23 Mar 2009 14:02:01 -0500
Subject: [c-nsp] Needs some help with QOS
Message-ID: <1237834921.5059.36.camel@linux-2sym>

I have crafted and applied some rules which I thought would prioritize
traffic from an 871w (via ADSL) to one specific host. The idea is that
any traffic destined to this host should be prioritized over all other
traffic.

Unfortunately my test show absolutely no effect. If I upload a couple of
files at the same time, the one with QOS enabled doesn't seem to get any
priority.

I have two questions:

1) What is wrong with my config? (below)

2) How can I get real-time debugging of the QOS without flooding my
console?

--- config ----

class-map match-all cm-qos1
 match access-group name al-qos1

policy-map pm-qos1
 class cm-qos1
  priority percent 70

interface Dialer0
 bandwidth 200
 ip address negotiated
 ip mtu 1452
 ip nat outside
 ip virtual-reassembly
 zone-member security out-zone
 encapsulation ppp
 dialer pool 1
 dialer-group 1
 ppp authentication chap callin
 ppp chap hostname XXX at XXX
 ppp chap password 7 xxxxxx
 service-policy output pm-qos1

ip access-list extended qos1
 permit ip host XXX.XXX.XXX.XXX any
 permit ip any host XXX.XXX.XXX.XXX



-- 
John Lange
http://www.johnlange.ca



From wp at null0.nl  Mon Mar 23 16:16:28 2009
From: wp at null0.nl (Wouter Prins)
Date: Mon, 23 Mar 2009 21:16:28 +0100
Subject: [c-nsp] Needs some help with QOS
In-Reply-To: <1237834921.5059.36.camel@linux-2sym>
References: <1237834921.5059.36.camel@linux-2sym>
Message-ID: <b5da8bca0903231316h30252c1fu5cdd6b187a0f13bb@mail.gmail.com>

Hi John,

==match access-group name al-qos1==
That acl doesnt exist?
Also for DSL, use some appropiate bandwidht values:

 bandwidth xxx
 bandwidth receive yyy

Use the show policy-map interface dialer 0 to see if the matching works

Regards,
Wouter

2009/3/23 John Lange <john at johnlange.ca>

> I have crafted and applied some rules which I thought would prioritize
> traffic from an 871w (via ADSL) to one specific host. The idea is that
> any traffic destined to this host should be prioritized over all other
> traffic.
>
> Unfortunately my test show absolutely no effect. If I upload a couple of
> files at the same time, the one with QOS enabled doesn't seem to get any
> priority.
>
> I have two questions:
>
> 1) What is wrong with my config? (below)
>
> 2) How can I get real-time debugging of the QOS without flooding my
> console?
>
> --- config ----
>
> class-map match-all cm-qos1
>  match access-group name al-qos1
>
> policy-map pm-qos1
>  class cm-qos1
>  priority percent 70
>
> interface Dialer0
>  bandwidth 200
>  ip address negotiated
>  ip mtu 1452
>  ip nat outside
>  ip virtual-reassembly
>  zone-member security out-zone
>  encapsulation ppp
>  dialer pool 1
>  dialer-group 1
>  ppp authentication chap callin
>  ppp chap hostname XXX at XXX
>  ppp chap password 7 xxxxxx
>  service-policy output pm-qos1
>
> ip access-list extended qos1
>  permit ip host XXX.XXX.XXX.XXX any
>  permit ip any host XXX.XXX.XXX.XXX
>
>
>
> --
> John Lange
> http://www.johnlange.ca
>
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>



-- 
Wouter Prins
wp at null0.nl
0x301FA912

From listacct at genhex.net  Mon Mar 23 16:17:34 2009
From: listacct at genhex.net (Jeff Crowe)
Date: Mon, 23 Mar 2009 16:17:34 -0400
Subject: [c-nsp] Traffic analysis via Netflow/BGP export?
Message-ID: <000001c9abf4$66ee6840$34cb38c0$@net>

Hi all,

I am looking for a tool/a collective of tools to help me better manage my
traffic on my edge router.  I am thinking that looking at netflows and BGP
paths would be the best but I am unsure of the tools to use to start
collecting this information.

I would like to have a tool that allows me to historically view traffic
trends going to destination AS's so I can adjust some route-maps to better
balance traffic egressing my network.  Any suggestions would be appreciated.

Regards,
Jeff.



From blahu77 at gmail.com  Mon Mar 23 17:17:20 2009
From: blahu77 at gmail.com (Mateusz Blaszczyk)
Date: Mon, 23 Mar 2009 21:17:20 +0000 (IST)
Subject: [c-nsp] Traffic analysis via Netflow/BGP export?
In-Reply-To: <000001c9abf4$66ee6840$34cb38c0$@net>
Message-ID: <fsnnsaxgt1pw34aixfUYAxe124vaj_firegpg@mail.gmail.com>

Jeff,


> I would like to have a tool that allows me to historically view traffic
> trends going to destination AS's so I can adjust some route-maps to better
> balance traffic egressing my network. ?Any suggestions would be appreciated.
>

That one seems easy and straightforward.
https://neon1.net/as-stats/

Best Regards,

-mat


-- 
pgp-key 0x1C655CAB

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 267 bytes
Desc: OpenPGP digital signature
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090323/569f96d0/attachment.bin>

From charles at thewybles.com  Mon Mar 23 17:30:01 2009
From: charles at thewybles.com (Charles Wyble)
Date: Mon, 23 Mar 2009 14:30:01 -0700
Subject: [c-nsp] Traffic analysis via Netflow/BGP export?
In-Reply-To: <fsnnsaxgt1pw34aixfUYAxe124vaj_firegpg@mail.gmail.com>
References: <fsnnsaxgt1pw34aixfUYAxe124vaj_firegpg@mail.gmail.com>
Message-ID: <49C7FF59.2010300@thewybles.com>



Mateusz Blaszczyk wrote:
> Jeff,
> 
> 
>> I would like to have a tool that allows me to historically view traffic
>> trends going to destination AS's so I can adjust some route-maps to 
>> better
>> balance traffic egressing my network.  Any suggestions would be 
>> appreciated.
>>
> 
> That one seems easy and straightforward.
> https://neon1.net/as-stats/
> 
> Best Regards,
> 

Also check out ntop.

From gert at greenie.muc.de  Mon Mar 23 18:07:45 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Mon, 23 Mar 2009 23:07:45 +0100
Subject: [c-nsp] Exceeding the bandwidth points on a 7200
In-Reply-To: <49C7DB17.6020001@justinshore.com>
References: <49C7DB17.6020001@justinshore.com>
Message-ID: <20090323220745.GD290@greenie.muc.de>

Hi,

On Mon, Mar 23, 2009 at 01:55:19PM -0500, Justin Shore wrote:
> That G1 is truly bored, averaging below 10% utilization.  I know that 
> IOS will bitch about it on boot but it will still continue to work won't 
> it?  Any other side effects (other than TAC not liking it if they see it 
> until I demonstrate with the graphs that it's not a problem)?

IOS will bitch, but unless this has changed recently, all interfaces will
"just work".  Of course you're on your own - if you complain to TAC about
"high CPU" and "packet losses", they are very likely to tell you "your
own fault".

OTOH, if the PA-A3s are *so* lightly loaded, I'd just go for it.

(I'm not sure I remember that right.  I think on the NPE-G1, the I/O
board is on a separate PCI bus, and could be replaced with a PA holder
card, which has its own set of bandwith points.  But maybe I misremember
part of this - you might want to check this in the docs).

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/20090323/e7eacab9/attachment.bin>

From ddunkin at netos.net  Mon Mar 23 18:11:54 2009
From: ddunkin at netos.net (Darryl Dunkin)
Date: Mon, 23 Mar 2009 15:11:54 -0700
Subject: [c-nsp] Exceeding the bandwidth points on a 7200
References: <49C7DB17.6020001@justinshore.com>
	<49C7DE7B.70000@rainierconnect.net>
Message-ID: <56F5BC5F404CF84896C447397A1AAF20DEE907@MAIL.nosi.netos.com>

Yep, the part number is "C7200-JC-PA".

Details:
http://www.cisco.com/en/US/prod/collateral/routers/ps341/product_data_sh
eet0900aecd804419c6.html


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Walter Keen
Sent: Monday, March 23, 2009 12:10
To: Justin Shore
Cc: 'Cisco-nsp'
Subject: Re: [c-nsp] Exceeding the bandwidth points on a 7200

I think there was a supportable way of adding another module via the IO
slot using a special card in the IO slot that provides you with a PA
slot that doesn't count towards the BW points of the other busses if I
remember correctly.

Justin Shore wrote:
> I have a situation on a 7206VXR w/ a NPE-G1 where I need to add a MC
> DS3 module.  The box already has 4 PA-A3-OC3SMI PAs.  I'd like to add
> a PA-MC-T3 to the box as well.  I know that the OC3 PAs max the
> bandwidth points out for each PCI bus.  However the OC3s are very
> lightly loaded.  Looking back at the graphs I don't see any of the 4
> peaking over 5Mbps.  That may seem surprising considering that there
> are nearly 1000 PVCs configured on those 4 OCs for DSL customers; the
> DSLAMs are very low-end, can only do basic ADSL, and the uplinks
> restrictthe average access speeds to extremely low levels.
>
> So my question is what happens when I exceed the bandwidth points on a
> 7200 where I know that bandwidth from the existing PAs won't ever be a
> problem?  The box as a whole peaks at around 12-15Mbps on its uplinks.
> That G1 is truly bored, averaging below 10% utilization.  I know that
> IOS will bitch about it on boot but it will still continue to work
> won't it?  Any other side effects (other than TAC not liking it if
> they see it until I demonstrate with the graphs that it's not a
problem)?
>
> 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/

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

From brez at brezworks.com  Mon Mar 23 17:43:05 2009
From: brez at brezworks.com (Jeremy Bresley)
Date: Mon, 23 Mar 2009 16:43:05 -0500
Subject: [c-nsp] Exceeding the bandwidth points on a 7200
In-Reply-To: <49C7DE7B.70000@rainierconnect.net>
References: <49C7DB17.6020001@justinshore.com>
	<49C7DE7B.70000@rainierconnect.net>
Message-ID: <49C80269.5040007@brezworks.com>

The card Walter mentioned is the C7200-JC-PA.
http://www.cisco.com/en/US/prod/collateral/routers/ps341/product_data_sheet0900aecd804419c6.html
It works with the NPE-G1 or G2 and it looks like the PA-MC-T3 is listed 
a supported adapter in it.  This basically replaces your I/O card (or 
blank if you have always had a G1/G2 CPU in there) with a dedicated port 
adapter slot for a single high-bandwidth port adapter.  One thing that 
looks like it is conspicuously absent is support for any of the GigE 
cards in the jacket, the only supported ones are the VAM2/VAM2+, 2 port 
FastEthernet, and various 1/2 port T3/E3/SONET/ATM cards and the 8 port 
T1 card.

Jeremy

Walter Keen wrote:
> I think there was a supportable way of adding another module via the IO
> slot using a special card in the IO slot that provides you with a PA
> slot that doesn't count towards the BW points of the other busses if I
> remember correctly.
>
> Justin Shore wrote:
>   
>> I have a situation on a 7206VXR w/ a NPE-G1 where I need to add a MC
>> DS3 module.  The box already has 4 PA-A3-OC3SMI PAs.  I'd like to add
>> a PA-MC-T3 to the box as well.  I know that the OC3 PAs max the
>> bandwidth points out for each PCI bus.  However the OC3s are very
>> lightly loaded.  Looking back at the graphs I don't see any of the 4
>> peaking over 5Mbps.  That may seem surprising considering that there
>> are nearly 1000 PVCs configured on those 4 OCs for DSL customers; the
>> DSLAMs are very low-end, can only do basic ADSL, and the uplinks
>> restrictthe average access speeds to extremely low levels.
>>
>> So my question is what happens when I exceed the bandwidth points on a
>> 7200 where I know that bandwidth from the existing PAs won't ever be a
>> problem?  The box as a whole peaks at around 12-15Mbps on its uplinks.
>> That G1 is truly bored, averaging below 10% utilization.  I know that
>> IOS will bitch about it on boot but it will still continue to work
>> won't it?  Any other side effects (other than TAC not liking it if
>> they see it until I demonstrate with the graphs that it's not a problem)?
>>
>> 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/
>>     
>
> _______________________________________________
> cisco-nsp mailing list  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  Mon Mar 23 18:41:06 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Mon, 23 Mar 2009 23:41:06 +0100
Subject: [c-nsp] Etherchannel and variable latency on member links
Message-ID: <1237848066.3797.12.camel@localhost.localdomain>

Hi,

We have some bandwidth issues between two sites, experiencing "out
discards" on interfaces.

The connection is currently between 2+2 switchports in WS-X6516-GBIC
cards and they're connected by ~4 km SM connection with LX GBICs. The
redundancy is blocked by STP.

To increase bandwidth in a cost effective way we were thinking of just
merging these two link in an etherchannel. The only concern is that the
two paths aren't exactly the same, and differ in length by about 20%.
This is of course not much on such a short stretch, but how does
etherchannels handle this?

As far as I can understand the loadsharing is strictly deterministic, so
out-of-order frames shouldn't be a problem. I assume the switch itself
doesn't care about the difference; we plan to use LACP as we do on all
other etherchannels.

Should we be nervous about this? Anybody running traffic through
etherchannels like that and can give thumbs up or down to this?

Regards,
Peter



From zarenks at wp.pl  Mon Mar 23 18:50:22 2009
From: zarenks at wp.pl (zarenks)
Date: Mon, 23 Mar 2009 23:50:22 +0100
Subject: [c-nsp] BGP problem on IPSec links
Message-ID: <49C8122E.1020008@wp.pl>

Hi,

I wonder if anyone had experienced the problem I have noticed with 
dynamic routing (BGP) running over IPSec link.
I have traced the archived posts regarding the IPSec problems but could 
not find anything regarding my case.

There is a typical remote access site connected to MPLS-VPN cloud 
through IPSec tunnel.
I decide to use VTI (Virtual Tunnel Interface) configuration instead of 
IPSec+GRE to support dynamic routing.

Untill I use the OSPF as a routing prot. there is no questions about the 
functionality and connectivity.
Problem occures when the customer requires me to run BGP on link between 
CE and PE.

The BGP session is established correcty, and I can see all the prefixes 
correctly redistributed....., but....

I can not access the Customer VPN network (say: HQ) from the LAN network 
on that CE (source ping, source traceroute fails)
The same situation occures if I try to access a LAN network placed 
behind the CE from HQ site. (or other CE site)

It is strange, because from any point of customer VPN I can access the 
CE WAN interface but no LAN.
At glance it looks like the IPSec has some problems with encapsulation 
of traffic sent via BGP but in the same time, there is no problem to 
show all necessary prefixes in routing tables at both sides (CE and PE).

If I only try to manualy configure (on PE) the STATIC entry for the 
CE-LAN network, everything works fine as expected.....well, but this is 
not the big challenge :-)

Just after posting that mail I will try to find (maybe) the answer in 
section known-issues on cco regarding the 12.4T, but in the meantime, if 
someone on the forum knows the issue that causes that  problem, I would 
appreciate that kind of help.


Thanks in advance
zarenks
 

From david at hughes.com.au  Mon Mar 23 18:56:26 2009
From: david at hughes.com.au (David Hughes)
Date: Tue, 24 Mar 2009 08:56:26 +1000
Subject: [c-nsp] Traffic analysis via Netflow/BGP export?
In-Reply-To: <000001c9abf4$66ee6840$34cb38c0$@net>
References: <000001c9abf4$66ee6840$34cb38c0$@net>
Message-ID: <51247403-0301-4B1E-B638-BEFC6AB318F1@hughes.com.au>



On 24/03/2009, at 6:17 AM, Jeff Crowe wrote:

> I am looking for a tool/a collective of tools to help me better  
> manage my
> traffic on my edge router.  I am thinking that looking at netflows  
> and BGP
> paths would be the best but I am unsure of the tools to use to start
> collecting this information.

Have a look at the gear from Arbor.  Not cheap but it does exactly  
what you've outlined (i.e. BGP peers with something on your network  
and takes netflow exports).  Based on the flows and your routing table  
it can tell you how much traffic you have heading to an AS you aren't  
even directly connected to.  Nice graphs, lots of reports.  Very, very  
sweet.


David
...

From jeff-kell at utc.edu  Mon Mar 23 19:09:30 2009
From: jeff-kell at utc.edu (Jeff Kell)
Date: Mon, 23 Mar 2009 19:09:30 -0400
Subject: [c-nsp] Etherchannel and variable latency on member links
In-Reply-To: <1237848066.3797.12.camel@localhost.localdomain>
References: <1237848066.3797.12.camel@localhost.localdomain>
Message-ID: <49C816AA.60501@utc.edu>

Peter Rathlev wrote:
> As far as I can understand the loadsharing is strictly deterministic, so
> out-of-order frames shouldn't be a problem. I assume the switch itself
> doesn't care about the difference; we plan to use LACP as we do on all
> other etherchannels.

AFAIK, etherchannel will select one physical path per flow (based on 
src/dst ip/mac), so there is no out-of-order to it, nor any load-sharing 
in the sense that it pays any attention to the link load at all.  At 
least from the Cisco end... I can't speak for all vendors / host adapters.

If it *can* load-share, cisco-to-cisco, I'd love to be corrected; but 
you need something like EIGRP for that (to really look at "load") or 
equal-cost paths and per-packet load sharing.

Jeff

From jon at defenderhosting.com  Mon Mar 23 18:38:45 2009
From: jon at defenderhosting.com (Jon Wolberg)
Date: Mon, 23 Mar 2009 18:38:45 -0400 (EDT)
Subject: [c-nsp] Traffic analysis via Netflow/BGP export?
In-Reply-To: <000001c9abf4$66ee6840$34cb38c0$@net>
Message-ID: <2105188067.4756121237847925862.JavaMail.root@mail.dtgmail.com>

Hi Jeff-

Netflow Tracker is a very nice product, however it's got a reasonable price tag for it:

http://www.flukenetworks.com/fnet/en-us/products/NetFlow+Tracker/

We've been using it for quite a while.


Jon Wolberg
Operations Manager
PowerVPS / Defender Hosting
Defender Technologies Group, LLC.


----- Original Message -----
From: "Jeff Crowe" <listacct at genhex.net>
To: cisco-nsp at puck.nether.net
Sent: Monday, March 23, 2009 4:17:34 PM GMT -05:00 US/Canada Eastern
Subject: [c-nsp] Traffic analysis via Netflow/BGP export?

Hi all,

I am looking for a tool/a collective of tools to help me better manage my
traffic on my edge router.  I am thinking that looking at netflows and BGP
paths would be the best but I am unsure of the tools to use to start
collecting this information.

I would like to have a tool that allows me to historically view traffic
trends going to destination AS's so I can adjust some route-maps to better
balance traffic egressing my network.  Any suggestions would be appreciated.

Regards,
Jeff.


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

From kilobit at gmail.com  Mon Mar 23 20:02:51 2009
From: kilobit at gmail.com (bas)
Date: Tue, 24 Mar 2009 01:02:51 +0100
Subject: [c-nsp] Cisco ACE and ASN
Message-ID: <ba6c08fd0903231702s6c8847e2j7a9b96d9c76d7ba3@mail.gmail.com>

Hello list,

Does anyone have any experience with high volume webcontent that is
loadbalanced through ASN?

>From the cisco website:
Asymmetric server normalization (ASN): Cisco ACE can load balance an
initial request from the client to a real server; however, the server
directly responds to the client, bypassing Cisco ACE.

I am curious how the ACE perfomance scales.
There are no fancy requirements, just weighted round robin and keepalive tests.

We are looking to host a website that generates ~80Gbps of outward traffic.
Incoming traffic is approx 5Gbps and 8.000.000 pps

regrettably I do not have any numbers concerning hits/sec etc.

Do you think a 8Gbps license on a ACE module will work for this setup?

Thanks in advance,

Bas

From justin at justinshore.com  Mon Mar 23 21:21:21 2009
From: justin at justinshore.com (Justin Shore)
Date: Mon, 23 Mar 2009 20:21:21 -0500
Subject: [c-nsp] Exceeding the bandwidth points on a 7200
In-Reply-To: <20090323220745.GD290@greenie.muc.de>
References: <49C7DB17.6020001@justinshore.com>
	<20090323220745.GD290@greenie.muc.de>
Message-ID: <49C83591.40903@justinshore.com>

Gert Doering wrote:
> IOS will bitch, but unless this has changed recently, all interfaces will
> "just work".  Of course you're on your own - if you complain to TAC about
> "high CPU" and "packet losses", they are very likely to tell you "your
> own fault".
> 
> OTOH, if the PA-A3s are *so* lightly loaded, I'd just go for it.

That's more or less my thought too at this point.  The load on the OCs 
isn't even worth mentioning to be honest.  The single port DS3 module 
will be more likely to exert more strain on the G1 than all 4 OC3s at 
this point.

> (I'm not sure I remember that right.  I think on the NPE-G1, the I/O
> board is on a separate PCI bus, and could be replaced with a PA holder
> card, which has its own set of bandwith points.  But maybe I misremember
> part of this - you might want to check this in the docs).

I thought about that but it's a little more cost.  I'm still thinking 
about adding a GigE I/O controller to get another GigE port in these 
guys too so I can do a little bit more with them.


Thanks for the info, guys.  It's been very helpful

Justin

From oles at ovh.net  Mon Mar 23 20:51:13 2009
From: oles at ovh.net (oles at ovh.net)
Date: Tue, 24 Mar 2009 01:51:13 +0100
Subject: [c-nsp] Cisco ACE and ASN
In-Reply-To: <ba6c08fd0903231702s6c8847e2j7a9b96d9c76d7ba3@mail.gmail.com>
References: <ba6c08fd0903231702s6c8847e2j7a9b96d9c76d7ba3@mail.gmail.com>
Message-ID: <20090324005113.GU30674@ovh.net>

> >From the cisco website:
> Asymmetric server normalization (ASN): Cisco ACE can load balance an
> initial request from the client to a real server; however, the server
> directly responds to the client, bypassing Cisco ACE.
> 
> I am curious how the ACE perfomance scales.

with linux, iproute2 is your friend. the request is going to an IP1
and the answser is from the same IP1 (normal). with iproute2 you 
can choose the routing strategy like this "gateway = f(IP1)" and the 
gateway's IP can be IP on the router (and not the ip attached on the ACE). 
So incoming trafic is going thought ACE, and outcoming trafic thought 
the router.

but you have no "protection" against the attacks like SYN-flood. and
it's a big ACE's problem. you have 1'000'000 (max 2'000'000 simu sessions)
and when you get an attack with no protections like "pending" & "no unidir"
your ACE is full and doesn't accept any new connexion. the downtime begins ...

> There are no fancy requirements, just weighted round robin and keepalive tests.
> 
> We are looking to host a website that generates ~80Gbps of outward traffic.
> Incoming traffic is approx 5Gbps and 8.000.000 pps

what I would use is the ospf's "maximum-paths" to distribute your trafic to 
32 ACE (SXI the max is 32, with SXH is 8). 80/32=2.5Gbps. you can use the
"pending" & "no unidir". but it's complicated setup I agree.


From david.freedman at uk.clara.net  Tue Mar 24 07:00:25 2009
From: david.freedman at uk.clara.net (David Freedman)
Date: Tue, 24 Mar 2009 11:00:25 +0000
Subject: [c-nsp] 7200 PCI? FCS errrors
Message-ID: <gqaega$847$1@ger.gmane.org>

Should I be worried about these?, do these come from the line?, the PA?
the PCI bus? , I can't tell, all normal "show interface" counters are clean

#sh int Se6/0.1/1/2/3:0 controller   | in FCS
  PCI system errors 0, PCI parity errors 0 Rx FCS errors 1065313702
#sh int Se6/0.1/1/2/3:0 controller   | in FCS
  PCI system errors 0, PCI parity errors 0 Rx FCS errors 1065313878
#sh int Se6/0.1/1/2/3:0 controller   | in FCS
  PCI system errors 0, PCI parity errors 0 Rx FCS errors 1065314239

#sh int Se6/0.1/1/3/1:0 controller   | in FCS
  PCI system errors 0, PCI parity errors 0 Rx FCS errors 1065326600
#sh int Se6/0.1/1/3/1:0 controller   | in FCS
  PCI system errors 0, PCI parity errors 0 Rx FCS errors 1065327260
#sh int Se6/0.1/1/3/1:0 controller   | in FCS
  PCI system errors 0, PCI parity errors 0 Rx FCS errors 1065327260
#sh int Se6/0.1/1/3/1:0 controller   | in FCS
  PCI system errors 0, PCI parity errors 0 Rx FCS errors 1065327260

#sh diag 6 | in PID
        Product Identifier (PID) : PA-MC-STM-1SMI


#show controllers sonet  6/0 brief  | in larm
  No alarms detected.
  No alarms detected.


#sh ver | in uppor
Technical Support: http://www.cisco.com/techsupport
This configuration is within the PCI bus capacity and is supported.
This configuration is within the PCI bus capacity and is supported.


#sh ver | in ^Cisco
Cisco IOS Software, 7200 Software (C7200-K91P-M), Version 12.2(31)SB13,
RELEASE SOFTWARE (fc1)
Cisco 7206VXR (NPE-G1) processor (revision B) with 491520K/32768K bytes
of memory.


Anybody seen this before?

thoughts?


TIA

Dave.


From ip at ioshints.info  Tue Mar 24 08:12:14 2009
From: ip at ioshints.info (Ivan Pepelnjak)
Date: Tue, 24 Mar 2009 13:12:14 +0100
Subject: [c-nsp] Needs some help with QOS
In-Reply-To: <1237834921.5059.36.camel@linux-2sym>
References: <1237834921.5059.36.camel@linux-2sym>
Message-ID: <001901c9ac79$c548c270$0a00000a@nil.si>

> I have crafted and applied some rules which I thought would 
> prioritize traffic from an 871w (via ADSL) to one specific 
> host. The idea is that any traffic destined to this host 
> should be prioritized over all other traffic.

What is your upstream connection? If you're using PPPoE, you won't be able
to do any output queuing, as the outbound LAN interface is never saturated
(the bottleneck is experienced by the DSL modem).

Ivan


From ip at ioshints.info  Tue Mar 24 09:01:02 2009
From: ip at ioshints.info (Ivan Pepelnjak)
Date: Tue, 24 Mar 2009 14:01:02 +0100
Subject: [c-nsp] Needs some help with QOS
In-Reply-To: <6664be8ae133a1d173c1cb47ed0b0b5a.squirrel@webmail.pelican.org>
References: <1237834921.5059.36.camel@linux-2sym>
	<001901c9ac79$c548c270$0a00000a@nil.si>
	<6664be8ae133a1d173c1cb47ed0b0b5a.squirrel@webmail.pelican.org>
Message-ID: <004501c9ac80$96be3910$0a00000a@nil.si>

Exactly true ... That would be my next answer :)

However, the problem is that it's somewhat hard to estimate what the shaping
bandwidth should be in DSL environments (you have the cell tax on top of
PPPoE plus unknown amount of oversubscription in the SP network) if you want
to squeeze as much out of the DSL line as possible.

Best regards
Ivan

> -----Original Message-----
> From: Tim Franklin [mailto:tim at pelican.org] 
> Sent: Tuesday, March 24, 2009 1:57 PM
> To: Ivan Pepelnjak
> Cc: 'John Lange'; 'Cisco NSP'
> Subject: Re: [c-nsp] Needs some help with QOS
> 
> On Tue, March 24, 2009 12:12 pm, Ivan Pepelnjak wrote:
> 
> > What is your upstream connection? If you're using PPPoE, 
> you won't be 
> > able to do any output queuing, as the outbound LAN 
> interface is never 
> > saturated (the bottleneck is experienced by the DSL modem).
> 
> If you know what your upstream bandwidth is, you can wrap a 
> shaper around the queueing policy to provide the 
> back-pressure.  Useful for all sorts of 'ethernet hand-off' 
> type services where the circuit provider has some other 
> device upstream of your router.
> 
> Regards,
> Tim.
> 
> 
> 


From deric.kwok2000 at gmail.com  Tue Mar 24 09:12:05 2009
From: deric.kwok2000 at gmail.com (Deric Kwok)
Date: Tue, 24 Mar 2009 09:12:05 -0400
Subject: [c-nsp] cisco router
Message-ID: <40d8a95a0903240612l33eaeadev74c8f1c85cdbc8ff@mail.gmail.com>

Hi

I need to get chespest cisco router to learn VPN vlan tcsh

Could you suggest model?

Thank you

From mhuff at ox.com  Tue Mar 24 09:23:32 2009
From: mhuff at ox.com (Matthew Huff)
Date: Tue, 24 Mar 2009 09:23:32 -0400
Subject: [c-nsp] cisco router
In-Reply-To: <40d8a95a0903240612l33eaeadev74c8f1c85cdbc8ff@mail.gmail.com>
References: <40d8a95a0903240612l33eaeadev74c8f1c85cdbc8ff@mail.gmail.com>
Message-ID: <483E6B0272B0284BA86D7596C40D29F9BBBB800EE7@PUR-EXCH07.ox.com>

I'd recommend getting a Cisco 2651xm with a cisco WS-C3550-24-EMI switch off of ebay. Be patience and you can get both for about $500-$600.

The router will need 256MB of RAM and at least 48MB of Flash if you want to run the latest 12.4T ios. For the switch, you want 64MB of ram and 16MB of flash. If you can't get one on ebay with that, buy a cheap one and get memory from a third-party retailer such as memory



----
Matthew Huff?????? | One Manhattanville Rd
OTA Management LLC | Purchase, NY 10577
http://www.ox.com? | Phone: 914-460-4039
aim: matthewbhuff? | Fax:?? 914-460-4139

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Deric Kwok
Sent: Tuesday, March 24, 2009 9:12 AM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] cisco router

Hi

I need to get chespest cisco router to learn VPN vlan tcsh

Could you suggest model?

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

From atis at eik.bme.hu  Tue Mar 24 08:29:37 2009
From: atis at eik.bme.hu (BALLA Attila)
Date: Tue, 24 Mar 2009 13:29:37 +0100 (CET)
Subject: [c-nsp] Needs some help with QOS
In-Reply-To: <001901c9ac79$c548c270$0a00000a@nil.si>
References: <1237834921.5059.36.camel@linux-2sym>
	<001901c9ac79$c548c270$0a00000a@nil.si>
Message-ID: <Pine.GSO.4.64.0903241326240.24165@mono>

Hi,

   you should use hierarchical QoS. First of all you should shape the 
output traffic down to the upstream speed, then you can use the llq inside 
the shaped class:
http://www.cisco.com/en/US/tech/tk543/tk545/technologies_tech_note09186a00800b2d29.shtml

BR, A.

On Tue, 24 Mar 2009, Ivan Pepelnjak wrote:

>> I have crafted and applied some rules which I thought would
>> prioritize traffic from an 871w (via ADSL) to one specific
>> host. The idea is that any traffic destined to this host
>> should be prioritized over all other traffic.
>
> What is your upstream connection? If you're using PPPoE, you won't be able
> to do any output queuing, as the outbound LAN interface is never saturated
> (the bottleneck is experienced by the DSL modem).
>
> Ivan
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From tim at pelican.org  Tue Mar 24 08:56:58 2009
From: tim at pelican.org (Tim Franklin)
Date: Tue, 24 Mar 2009 12:56:58 -0000 (GMT)
Subject: [c-nsp] Needs some help with QOS
In-Reply-To: <001901c9ac79$c548c270$0a00000a@nil.si>
References: <1237834921.5059.36.camel@linux-2sym>
	<001901c9ac79$c548c270$0a00000a@nil.si>
Message-ID: <6664be8ae133a1d173c1cb47ed0b0b5a.squirrel@webmail.pelican.org>

On Tue, March 24, 2009 12:12 pm, Ivan Pepelnjak wrote:

> What is your upstream connection? If you're using PPPoE, you won't be able
> to do any output queuing, as the outbound LAN interface is never saturated
> (the bottleneck is experienced by the DSL modem).

If you know what your upstream bandwidth is, you can wrap a shaper around
the queueing policy to provide the back-pressure.  Useful for all sorts of
'ethernet hand-off' type services where the circuit provider has some
other device upstream of your router.

Regards,
Tim.



From skeeve at eintellego.net  Tue Mar 24 10:06:27 2009
From: skeeve at eintellego.net (Skeeve Stevens)
Date: Wed, 25 Mar 2009 01:06:27 +1100
Subject: [c-nsp] Cisco DSL Router As a 'modem'?
Message-ID: <292AF25E62B8894C921B893B53A19D97394469DEFE@BUSINESSEX.business.ad>

Hey all,

I am wondering if it is possible to use a 827, 828, 837, 877, 878, 888 as a bridge modem?

What I want to do is have a router like an 1811, with say 5 xDSL devices which hold their connection up, but the 1811 does the Dialer part, so they can be multi-linked, or other load balancing.

I've searched in vain, but can't seem to make it work.   A simple config for the 8xx series and what is involved would be nice if anyhow has such a beast around.

...Skeeve

--
Skeeve Stevens, CEO/Technical Director
eintellego Pty Ltd - The Networking Specialists
skeeve at eintellego.net / www.eintellego.net
Phone: 1300 753 383, Fax: (+612) 8572 9954
Cell +61 (0)414 753 383 / skype://skeeve
--
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 blahu77 at gmail.com  Tue Mar 24 10:14:01 2009
From: blahu77 at gmail.com (Mateusz Blaszczyk)
Date: Tue, 24 Mar 2009 14:14:01 +0000
Subject: [c-nsp] Cisco DSL Router As a 'modem'?
In-Reply-To: <292AF25E62B8894C921B893B53A19D97394469DEFE@BUSINESSEX.business.ad>
References: <292AF25E62B8894C921B893B53A19D97394469DEFE@BUSINESSEX.business.ad>
Message-ID: <383357750903240714p3c36dbddic93d127fc58c72e1@mail.gmail.com>

Skeeve,


> I am wondering if it is possible to use a 827, 828, 837, 877, 878, 888 as a bridge modem?
>
> What I want to do is have a router like an 1811, with say 5 xDSL devices which hold their connection up, but the 1811 does the Dialer part, so they can be multi-linked, or other load balancing.

Just thinking that even if possible that is a really expensive scenario



-- 
pgp-key 0x1C655CAB

From richard.halfpenny at exa-networks.co.uk  Tue Mar 24 10:21:51 2009
From: richard.halfpenny at exa-networks.co.uk (Richard Halfpenny)
Date: Tue, 24 Mar 2009 14:21:51 +0000
Subject: [c-nsp] Cisco DSL Router As a 'modem'?
In-Reply-To: <292AF25E62B8894C921B893B53A19D97394469DEFE@BUSINESSEX.business.ad>
References: <292AF25E62B8894C921B893B53A19D97394469DEFE@BUSINESSEX.business.ad>
Message-ID: <49C8EC7F.9020700@exa-networks.co.uk>

http://www.cisco.com/en/US/tech/tk175/tk15/technologies_configuration_example09186a008071a78c.shtml

Run each of the 5 routers into separate interfaces (or subinterfaces) on 
the 1811, config it as a PPPoE client on each interface and then do 
MLPPP across the dialers.

Rich.


Skeeve Stevens wrote:
> Hey all,
>
> I am wondering if it is possible to use a 827, 828, 837, 877, 878, 888 as a bridge modem?
>
> What I want to do is have a router like an 1811, with say 5 xDSL devices which hold their connection up, but the 1811 does the Dialer part, so they can be multi-linked, or other load balancing.
>
> I've searched in vain, but can't seem to make it work.   A simple config for the 8xx series and what is involved would be nice if anyhow has such a beast around.
>
> ...Skeeve
>
> --
> Skeeve Stevens, CEO/Technical Director
> eintellego Pty Ltd - The Networking Specialists
> skeeve at eintellego.net / www.eintellego.net
> Phone: 1300 753 383, Fax: (+612) 8572 9954
> Cell +61 (0)414 753 383 / skype://skeeve
> --
> 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/
>   


-- 
Network Operations
Exa Networks Ltd :: AS30740
richard.halfpenny at exa-networks.co.uk



From zivl at gilat.net  Tue Mar 24 10:28:51 2009
From: zivl at gilat.net (Ziv Leyes)
Date: Tue, 24 Mar 2009 16:28:51 +0200
Subject: [c-nsp] Cisco DSL Router As a 'modem'?
In-Reply-To: <292AF25E62B8894C921B893B53A19D97394469DEFE@BUSINESSEX.business.ad>
References: <292AF25E62B8894C921B893B53A19D97394469DEFE@BUSINESSEX.business.ad>
Message-ID: <EC993E87D960A541A66BF21D62AA42A622E2056726@exch2k7.gilat.local>

It's possible, but as Matheusz said, it would be too expensive to use Cisco router as a modem
You lose every advantage you have on the router, also the possibility to remote manage it, you can only control it via console/aux.

You can configure the ATM (DSL) interface to match your needs, and then put the atm and ethernet desired ports into a bridging group.
You could also give a private IP to the bridge interface to be able to manage it from the LAN I guess. Correct me if I'm wrong

Ziv



-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Skeeve Stevens
Sent: Tuesday, March 24, 2009 4:06 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Cisco DSL Router As a 'modem'?

Hey all,

I am wondering if it is possible to use a 827, 828, 837, 877, 878, 888 as a bridge modem?

What I want to do is have a router like an 1811, with say 5 xDSL devices which hold their connection up, but the 1811 does the Dialer part, so they can be multi-linked, or other load balancing.

I've searched in vain, but can't seem to make it work.   A simple config for the 8xx series and what is involved would be nice if anyhow has such a beast around.

...Skeeve

--
Skeeve Stevens, CEO/Technical Director
eintellego Pty Ltd - The Networking Specialists
skeeve at eintellego.net / www.eintellego.net
Phone: 1300 753 383, Fax: (+612) 8572 9954
Cell +61 (0)414 753 383 / skype://skeeve
--
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/
 
 
************************************************************************************
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 john at johnlange.ca  Tue Mar 24 10:36:45 2009
From: john at johnlange.ca (John Lange)
Date: Tue, 24 Mar 2009 09:36:45 -0500
Subject: [c-nsp] Needs some help with QOS
In-Reply-To: <6664be8ae133a1d173c1cb47ed0b0b5a.squirrel@webmail.pelican.org>
References: <1237834921.5059.36.camel@linux-2sym>
	<001901c9ac79$c548c270$0a00000a@nil.si>
	<6664be8ae133a1d173c1cb47ed0b0b5a.squirrel@webmail.pelican.org>
Message-ID: <1237905405.4965.14.camel@linux-2sym>

First, thanks to those who pointed out my (should have been obvious)
error where I named the access-list qos1 but then tried to reference it
with al-qos1. When you're looking for a big problem it's easy to
overlook the obvious.

On Tue, 2009-03-24 at 12:56 +0000, Tim Franklin wrote:
> On Tue, March 24, 2009 12:12 pm, Ivan Pepelnjak wrote:
> 
> > What is your upstream connection? If you're using PPPoE, you won't be able
> > to do any output queuing, as the outbound LAN interface is never saturated
> > (the bottleneck is experienced by the DSL modem).
> 
> If you know what your upstream bandwidth is, you can wrap a shaper around
> the queueing policy to provide the back-pressure.  Useful for all sorts of
> 'ethernet hand-off' type services where the circuit provider has some
> other device upstream of your router.

Ok, that also seems to be the point of this link which was provided in
another response.

> http://www.cisco.com/en/US/tech/tk543/tk545/technologies_tech_note09186a00800b2d29.shtml

Basically, the virtual interfaces "do not implement the "back-pressure
algorithm" necessary to signal that excess packets should be queued by
the Layer 3 (L3) queueing system."

Ok, so I'm going to have to implement a new solution based on that
document.

So just a final question, would the solution have worked if it was on a
regular interface? I just want to make sure I had the right idea.

Regards,
- 
John Lange
http://www.johnlange.ca




From fasterfourier at gmail.com  Tue Mar 24 10:55:11 2009
From: fasterfourier at gmail.com (Robert Johnson)
Date: Tue, 24 Mar 2009 10:55:11 -0400
Subject: [c-nsp] OSPF and iBGP session drops between 3640s
Message-ID: <4f84a6f80903240755v210553cbrd5220245ef64d59e@mail.gmail.com>

Hello list,
I have a small network with four 3640s. Each router has 128/32MB ram, and a
single FE interface connected to a catalyst 2924. Two of the routers are
running BGP, each with a session to a (single) other provider, and a session
between themselves. These are not carrying full tables. All four routers are
running OSPF between each other. The problem is that occasionally (from once
a week to 3x/day) OSPF neighbor relationships will bounce due to hello
timers expiring. Just recently the iBGP session between two of the routers
also bounced.

There do not appear to be any layer 1 or 2 connectivity problems that would
cause this behavior. However, CPU usage on the 3640s seems high- 30%
sustained and up to 90% peak, with only 1-2k max PPS. Also, I'm seeing
buffer misses and failures.

CEF is enabled. There are several relatively long access lists that are
being processed, and the routers are doing QoS classifying and tagging at
layers 2 and 3 for VoIP performance.

Without any major hardware changes, where do I begin here?

Thanks in advance.



The fun stuff (sho buffers, sho proc cpu hist, sho proc cpu, sho run):

router1#sho buffers
Buffer elements:
     1118 in free list (500 max allowed)
     707983613 hits, 0 misses, 1119 created

Public buffer pools:
Small buffers, 104 bytes (total 78, permanent 50, peak 104 @ 4w0d):
     42 in free list (20 min, 150 max allowed)
     18990955 hits, 3598 misses, 4408 trims, 4436 created
     312 failures (0 no memory)
Middle buffers, 600 bytes (total 25, permanent 25, peak 176 @ 7w0d):
     22 in free list (10 min, 150 max allowed)
     651012877 hits, 12602 misses, 30744 trims, 30744 created
     2744 failures (0 no memory)
Big buffers, 1536 bytes (total 50, permanent 50, peak 63 @ 2d19h):
     50 in free list (5 min, 150 max allowed)
     4658228 hits, 1005 misses, 102 trims, 102 created
     936 failures (0 no memory)
VeryBig buffers, 4520 bytes (total 10, permanent 10, peak 12 @ 7w0d):
     10 in free list (0 min, 100 max allowed)
     129 hits, 807 misses, 13 trims, 13 created
     807 failures (0 no memory)
Large buffers, 5024 bytes (total 1, permanent 0, peak 3 @ 7w0d):
     1 in free list (0 min, 10 max allowed)
     14 hits, 793 misses, 2764 trims, 2765 created
     793 failures (0 no memory)
Huge buffers, 18024 bytes (total 1, permanent 0, peak 3 @ 7w0d):
     1 in free list (0 min, 4 max allowed)
     16 hits, 779 misses, 3858 trims, 3859 created
     778 failures (0 no memory)

Interface buffer pools:
CD2430 I/O buffers, 1536 bytes (total 0, permanent 0):
     0 in free list (0 min, 0 max allowed)
     0 hits, 0 fallbacks

Header pools:
Header buffers, 0 bytes (total 265, permanent 256, peak 265 @ 7w0d):
     9 in free list (10 min, 512 max allowed)
     253 hits, 3 misses, 0 trims, 9 created
     0 failures (0 no memory)
     256 max cache size, 256 in cache
     7674266 hits in cache, 0 misses in cache

Particle Clones:
     1024 clones, 0 hits, 0 misses

Public particle pools:
F/S buffers, 256 bytes (total 384, permanent 384):
     128 in free list (128 min, 1024 max allowed)
     256 hits, 0 misses, 0 trims, 0 created
     0 failures (0 no memory)
     256 max cache size, 256 in cache
     0 hits in cache, 0 misses in cache
Normal buffers, 1548 bytes (total 512, permanent 512):
     384 in free list (128 min, 1024 max allowed)
     21114 hits, 0 misses, 0 trims, 0 created
     0 failures (0 no memory)
     128 max cache size, 128 in cache
     0 hits in cache, 0 misses in cache

Private particle pools:
IDS SM buffers, 240 bytes (total 128, permanent 128):
     0 in free list (0 min, 128 max allowed)
     128 hits, 0 fallbacks
     128 max cache size, 128 in cache
     0 hits in cache, 0 misses in cache
FastEthernet0/0 buffers, 1548 bytes (total 192, permanent 192):
     0 in free list (0 min, 192 max allowed)
     192 hits, 0 fallbacks
     192 max cache size, 128 in cache
     694772430 hits in cache, 20986 misses in cache

router1#sho proc cpu hist

router1   02:40:53 PM Tuesday Mar 24 2009 UTC


    4444444444444444444444444444444555554444444444444443333355
    8333332222200000000004444411111111110000000000222227777722
100
 90
 80
 70
 60
 50 *                              *****                    ****
 40 ************************************************************
 30 ************************************************************
 20 ************************************************************
 10 ************************************************************
   0....5....1....1....2....2....3....3....4....4....5....5....
             0    5    0    5    0    5    0    5    0    5
               CPU% per second (last 60 seconds)

    5656435544454334664445454566532243344446444645545774454545
    2900663259495363238448467911347711166900544033873220265057
100
 90
 80
 70  *                                               **
 60  * *       *    **   * * ***           *   *  *  **  *   *
 50 ***#* *#** **   ***  * **###*      *** **  * ****#*  *******
 40 ##*##*####*#* **####*#***###*   *  **********######****#####
 30 ##############################**#***##*#**##################
 20 ############################################################
 10 ############################################################
   0....5....1....1....2....2....3....3....4....4....5....5....
             0    5    0    5    0    5    0    5    0    5
               CPU% per minute (last 60 minutes)
              * = maximum CPU%   # = average CPU%

    7664665666756555557666776555554545664455555555455555654555556565545654
    2734555279005332498657259890379052808981353640965081868135475217086638
100
 90
 80                   *    *
 70 **  **  *** *     *******         *                 *       *      *   *
 60 *** ******* *    **********  *    **  *  * *   ** * **   * ** **  **  **
 50 *** ********************************************************************
 40 ****##########****#***##****########################*###################
 30 ##**###########***########**############################################
 20 ###*############*##########*############################################
 10 ########################################################################
   0....5....1....1....2....2....3....3....4....4....5....5....6....6....7.
             0    5    0    5    0    5    0    5    0    5    0    5    0
                   CPU% per hour (last 72 hours)
                  * = maximum CPU%   # = average CPU%


sho proc cpu:

CPU utilization for five seconds: 42%/39%; one minute: 43%; five minutes:
40%

router1#sho run
Building configuration...

Current configuration : 8460 bytes
!
! Last configuration change at 01:54:37 UTC Tue Mar 24 2009
! NVRAM config last updated at 22:25:51 UTC Thu Mar 5 2009
!
version 12.4
service timestamps debug uptime
service timestamps log uptime
service password-encryption
!
hostname router1
!
boot-start-marker
boot system flash c3640-jk9o3s-mz.124-3.bin
boot-end-marker
!
no logging console
enable secret 5 **
!
no aaa new-model
!
resource policy
!
ip subnet-zero
no ip source-route
!
!
ip cef
!
!
class-map match-all assure
 match ip dscp af31
class-map match-all critical
 match ip dscp cs6
class-map match-all expedite
 match ip dscp ef
class-map match-any rtp-vox
 match ip rtp 13456 13462
 match ip rtp 13556 13560
 match ip rtp 13656 13660
 match ip rtp 13756 13760
class-map match-all sip
 match protocol sip
class-map match-all voice
 match packet length min 1 max 200
 match class-map rtp-vox
!
!
policy-map output-cos
 class expedite
  set cos 6
 class assure
  set cos 5
 class critical
  set cos 7
policy-map input-mark
 class sip
  set ip dscp af31
 class voice
  set dscp ef
!
!
!
!
!
!
interface FastEthernet0/0
 description Trunk to cat2924-pri
 no ip address
 full-duplex
!
interface FastEthernet0/0.5
 description Switch management segment
 encapsulation dot1Q 5
 ip address 10.1.5.254 255.255.255.0
 ip access-group mgmt-only in
 ip access-group mgmt-only out
 no snmp trap link-status
!
interface FastEthernet0/0.15
 description AP management segment
 encapsulation dot1Q 15
 ip address 10.1.15.254 255.255.255.0
 ip access-group mgmt-only in
 ip access-group mgmt-only out
 no snmp trap link-status
!
interface FastEthernet0/0.25
 description CTM management segment
 encapsulation dot1Q 25
 ip address 10.1.25.254 255.255.255.0
 ip access-group mgmt-only in
 ip access-group mgmt-only out
 no snmp trap link-status
!
interface FastEthernet0/0.35
 description UPS management segment
 encapsulation dot1Q 35
 ip address 10.1.35.254 255.255.255.0
 ip access-group mgmt-only in
 ip access-group mgmt-only out
 no snmp trap link-status
!
interface FastEthernet0/0.50
 description Management link to router3
 bandwidth 9850
 encapsulation dot1Q 50
 ip address 10.1.50.254 255.255.255.0
 ip access-group mgmt-only in
 ip access-group mgmt-only out
 ip ospf message-digest-key 1 md5 7 *secret*
 ip ospf hello-interval 1
 ip ospf dead-interval 5
 no snmp trap link-status
!
interface FastEthernet0/0.51
 description Management link to router2
 encapsulation dot1Q 51
 ip address 10.1.51.254 255.255.255.0
 ip access-group mgmt-only in
 ip access-group mgmt-only out
 ip ospf message-digest-key 1 md5 7 **
 ip ospf hello-interval 1
 ip ospf dead-interval 5
 no snmp trap link-status
!
interface FastEthernet0/0.52
 description Management link to **
 bandwidth 10610
 encapsulation dot1Q 52
 ip address 10.1.52.254 255.255.255.0
 ip access-group mgmt-only in
 ip access-group mgmt-only out
 no snmp trap link-status
!
interface FastEthernet0/0.300
 description Production traffic link to router3
 bandwidth 9850
 encapsulation dot1Q 300
 ip address xxx.xxx.xxx.xxx 255.255.255.252
 ip ospf message-digest-key 10 md5 7 **
 ip ospf dead-interval minimal hello-multiplier 4
 no snmp trap link-status
 service-policy output output-cos
!
interface FastEthernet0/0.301
 description Production traffic link to router2
 encapsulation dot1Q 301
 ip address xxx.xxx.xxx.xxx 255.255.255.252
 ip ospf message-digest-key 10 md5 7 **
 ip ospf dead-interval minimal hello-multiplier 4
 no snmp trap link-status
 service-policy output output-cos
!
interface FastEthernet0/0.302
 description Production traffic link to **
 bandwidth 10610
 encapsulation dot1Q 302
 ip address xxx.xxx.xxx.xxx 255.255.255.252
 ip access-group internet-edge-ingress in
 ip access-group internet-edge-egress out
 no snmp trap link-status
 service-policy input input-mark
 service-policy output output-cos
!
interface FastEthernet0/0.500
 description Customer access subnet
 encapsulation dot1Q 500
 ip address xxx.xxx.xxx.xxx 255.255.255.240
 ip access-group block-customercrap in
 ip verify unicast reverse-path
 rate-limit input access-group 100 768000 10000 200000 conform-action
transmit e
xceed-action drop
 rate-limit output access-group 100 768000 40000000 80000000 conform-action
tran
smit exceed-action drop
 no snmp trap link-status
 service-policy output output-cos
!
router ospf 1000
 log-adjacency-changes
 area 0.0.0.0 authentication message-digest
 passive-interface default
 no passive-interface FastEthernet0/0.300
 no passive-interface FastEthernet0/0.301
 network xxx.xxx.xxx.xxx 0.0.0.63 area 0.0.0.0
 network xxx.xxx.xxx.xxx 0.0.0.63 area 0.0.0.0
 network xxx.xxx.xxx.xxx 0.0.0.63 area 0.0.0.0
 network xxx.xxx.xxx.xxx 0.0.0.63 area 0.0.0.0
 default-information originate metric-type 1
!
router ospf 100
 log-adjacency-changes
 area 10.0.0.0 authentication message-digest
 area 10.0.0.0 stub no-summary
 passive-interface default
 no passive-interface FastEthernet0/0.50
 no passive-interface FastEthernet0/0.51
 network 10.0.0.0 0.255.255.255 area 10.0.0.0
!
router bgp *****
 no synchronization
 bgp log-neighbor-changes
 network xxx.xxx.xxx.xxx mask 255.255.255.192
 network xxx.xxx.xxx.xxx mask 255.255.255.192
 network xxx.xxx.xxx.xxx mask 255.255.255.192
 network xxx.xxx.xxx.xxx mask 255.255.255.192
 aggregate-address xxx.xxx.xxx.xxx 255.255.255.192 as-set summary-only
 aggregate-address xxx.xxx.xxx.xxx 255.255.255.192 as-set summary-only
 aggregate-address xxx.xxx.xxx.xxx 255.255.255.192 as-set summary-only
 aggregate-address xxx.xxx.xxx.xxx 255.255.255.192 as-set summary-only
 redistribute ospf 1000
 neighbor xxx.xxx.xxx.xxx remote-as ****
 neighbor xxx.xxx.xxx.xxx route-map pri-map out
 neighbor xxx.xxx.xxx.xxx remote-as *****
 neighbor xxx.xxx.xxx.xxx next-hop-self
 no auto-summary
!
no ip http server
no ip http secure-server
ip classless
!
!
!
!
ip access-list standard mgmt-only
 permit 10.0.0.0 0.255.255.255
 permit 192.168.101.0 0.0.0.255
!
ip access-list extended block-customercrap
 deny   udp any any eq bootps
 deny   tcp any any eq 139
 deny   tcp any any eq 445
 deny   udp any any eq netbios-ns
 deny   udp any any eq netbios-dgm
 permit ip any any
ip access-list extended internet-edge-egress
 deny   ip 10.0.0.0 0.255.255.255 any
 deny   ip 172.16.0.0 0.15.255.255 any
 deny   ip 192.168.0.0 0.0.255.255 any
 deny   ip 127.0.0.0 0.0.255.255 any
 deny   ip 224.0.0.0 31.255.255.255 any
 deny   ip 169.254.0.0 0.0.255.255 any
 deny   udp any any eq bootps
 deny   udp any any eq bootpc
 deny   tcp any any eq 139
 deny   tcp any any eq 445
 deny   udp any any eq netbios-ns
 deny   udp any any eq netbios-dgm
 deny   ip any xxx.xxx.xxx.xxx 0.0.0.63
 deny   ip any xxx.xxx.xxx.xxx 0.0.0.63
 deny   ip any xxx.xxx.xxx.xxx 0.0.0.63
 deny   ip any xxx.xxx.xxx.xxx 0.0.0.63
 permit ip any any
ip access-list extended internet-edge-ingress
 deny   ip 10.0.0.0 0.255.255.255 any
 deny   ip 172.16.0.0 0.15.255.255 any
 deny   ip 192.168.0.0 0.0.255.255 any
 deny   ip 127.0.0.0 0.0.255.255 any
 deny   ip 224.0.0.0 31.255.255.255 any
 deny   ip 169.254.0.0 0.0.255.255 any
 deny   udp any any eq bootps
 deny   udp any any eq bootpc
 deny   tcp any any eq 139
 deny   tcp any any eq 445
 deny   udp any any eq netbios-ns
 deny   udp any any eq netbios-dgm
 deny   ip xxx.xxx.xxx.xxx 0.0.0.63 any
 deny   ip xxx.xxx.xxx.xxx 0.0.0.63 any
 deny   ip xxx.xxx.xxx.xxx 0.0.0.63 any
 deny   ip xxx.xxx.xxx.xxx 0.0.0.63 any
 permit ip any any
logging facility local5
logging 10.3.40.105
access-list 1 permit xxx.xxx.xxx.xxx 0.0.0.63
access-list 1 permit xxx.xxx.xxx.xxx 0.0.0.63
access-list 2 permit xxx.xxx.xxx.xxx 0.0.0.63
access-list 2 permit xxx.xxx.xxx.xxx 0.0.0.63
access-list 100 permit ip host xxx.xxx.xxx.xxx any
access-list 100 permit ip any host xxx.xxx.xxx.xxx
snmp-server community ** RO mgmt-only
!
route-map pri-map permit 10
 match ip address 1
!
route-map pri-map permit 20
 match ip address 2
!
!
!
control-plane
!
!
!
!
!
!
!
!
!
banner login ^C Property of **. Unauthorized access attempt
s will be prosecuted. ^C
!
line con 0
 password 7 **
 login
line aux 0
 password 7 **
 login
line vty 0 4
 access-class mgmt-only in
 password 7 **
 login
!
ntp clock-period 17179597
ntp server 10.3.40.105
!
end

From skeeve at eintellego.net  Tue Mar 24 11:02:15 2009
From: skeeve at eintellego.net (Skeeve Stevens)
Date: Wed, 25 Mar 2009 02:02:15 +1100
Subject: [c-nsp] Cisco DSL Router As a 'modem'?
In-Reply-To: <EC993E87D960A541A66BF21D62AA42A622E2056726@exch2k7.gilat.local>
References: <292AF25E62B8894C921B893B53A19D97394469DEFE@BUSINESSEX.business.ad>
	<EC993E87D960A541A66BF21D62AA42A622E2056726@exch2k7.gilat.local>
Message-ID: <292AF25E62B8894C921B893B53A19D97394469DF01@BUSINESSEX.business.ad>

How is it too expensive?  If you are doing DSL1, 827/837's, even SOHO87 can be had for a few $$$

...Skeeve

--
Skeeve Stevens, CEO/Technical Director
eintellego Pty Ltd - The Networking Specialists
skeeve at eintellego.net / www.eintellego.net
Phone: 1300 753 383, Fax: (+612) 8572 9954
Cell +61 (0)414 753 383 / skype://skeeve
--
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.


> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> bounces at puck.nether.net] On Behalf Of Ziv Leyes
> Sent: Wednesday, 25 March 2009 1:29 AM
> To: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] Cisco DSL Router As a 'modem'?
>
> It's possible, but as Matheusz said, it would be too expensive to use
> Cisco router as a modem
> You lose every advantage you have on the router, also the possibility
> to remote manage it, you can only control it via console/aux.
>
> You can configure the ATM (DSL) interface to match your needs, and then
> put the atm and ethernet desired ports into a bridging group.
> You could also give a private IP to the bridge interface to be able to
> manage it from the LAN I guess. Correct me if I'm wrong
>
> Ziv
>
>
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> bounces at puck.nether.net] On Behalf Of Skeeve Stevens
> Sent: Tuesday, March 24, 2009 4:06 PM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] Cisco DSL Router As a 'modem'?
>
> Hey all,
>
> I am wondering if it is possible to use a 827, 828, 837, 877, 878, 888
> as a bridge modem?
>
> What I want to do is have a router like an 1811, with say 5 xDSL
> devices which hold their connection up, but the 1811 does the Dialer
> part, so they can be multi-linked, or other load balancing.
>
> I've searched in vain, but can't seem to make it work.   A simple
> config for the 8xx series and what is involved would be nice if anyhow
> has such a beast around.
>
> ...Skeeve
>
> --
> Skeeve Stevens, CEO/Technical Director
> eintellego Pty Ltd - The Networking Specialists
> skeeve at eintellego.net / www.eintellego.net
> Phone: 1300 753 383, Fax: (+612) 8572 9954
> Cell +61 (0)414 753 383 / skype://skeeve
> --
> 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/
>
>
> ***********************************************************************
> *************
> 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.
> ***********************************************************************
> *************
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

From zivl at gilat.net  Tue Mar 24 11:24:16 2009
From: zivl at gilat.net (Ziv Leyes)
Date: Tue, 24 Mar 2009 17:24:16 +0200
Subject: [c-nsp] Cisco DSL Router As a 'modem'?
In-Reply-To: <292AF25E62B8894C921B893B53A19D97394469DF01@BUSINESSEX.business.ad>
References: <292AF25E62B8894C921B893B53A19D97394469DEFE@BUSINESSEX.business.ad>
	<EC993E87D960A541A66BF21D62AA42A622E2056726@exch2k7.gilat.local>
	<292AF25E62B8894C921B893B53A19D97394469DF01@BUSINESSEX.business.ad>
Message-ID: <EC993E87D960A541A66BF21D62AA42A622E205677B@exch2k7.gilat.local>

A cisco router, even a SOHO97 is still more expensive than any little simple DSL modem, isn't it?
Anyway, shouldn't you get a modem from your DLS provider?
But if you can spare a 827 or a SOHO then go for it, it will work good, that we can be sure, and you can still get the added value of monitoring the DSL line statistics which you can't have on a regular "blackbox" modem.
Ziv



-----Original Message-----
From: Skeeve Stevens [mailto:skeeve at eintellego.net] 
Sent: Tuesday, March 24, 2009 5:02 PM
To: Ziv Leyes; cisco-nsp at puck.nether.net
Subject: RE: Cisco DSL Router As a 'modem'?

How is it too expensive?  If you are doing DSL1, 827/837's, even SOHO87 can be had for a few $$$

...Skeeve

--
Skeeve Stevens, CEO/Technical Director
eintellego Pty Ltd - The Networking Specialists
skeeve at eintellego.net / www.eintellego.net
Phone: 1300 753 383, Fax: (+612) 8572 9954
Cell +61 (0)414 753 383 / skype://skeeve
--
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.


> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> bounces at puck.nether.net] On Behalf Of Ziv Leyes
> Sent: Wednesday, 25 March 2009 1:29 AM
> To: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] Cisco DSL Router As a 'modem'?
>
> It's possible, but as Matheusz said, it would be too expensive to use
> Cisco router as a modem
> You lose every advantage you have on the router, also the possibility
> to remote manage it, you can only control it via console/aux.
>
> You can configure the ATM (DSL) interface to match your needs, and then
> put the atm and ethernet desired ports into a bridging group.
> You could also give a private IP to the bridge interface to be able to
> manage it from the LAN I guess. Correct me if I'm wrong
>
> Ziv
>
>
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> bounces at puck.nether.net] On Behalf Of Skeeve Stevens
> Sent: Tuesday, March 24, 2009 4:06 PM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] Cisco DSL Router As a 'modem'?
>
> Hey all,
>
> I am wondering if it is possible to use a 827, 828, 837, 877, 878, 888
> as a bridge modem?
>
> What I want to do is have a router like an 1811, with say 5 xDSL
> devices which hold their connection up, but the 1811 does the Dialer
> part, so they can be multi-linked, or other load balancing.
>
> I've searched in vain, but can't seem to make it work.   A simple
> config for the 8xx series and what is involved would be nice if anyhow
> has such a beast around.
>
> ...Skeeve
>
> --
> Skeeve Stevens, CEO/Technical Director
> eintellego Pty Ltd - The Networking Specialists
> skeeve at eintellego.net / www.eintellego.net
> Phone: 1300 753 383, Fax: (+612) 8572 9954
> Cell +61 (0)414 753 383 / skype://skeeve
> --
> 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/
>
>
> ***********************************************************************
> *************
> 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.
> ***********************************************************************
> *************
>
> _______________________________________________
> cisco-nsp mailing 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 andy.bierlair at root.lu  Tue Mar 24 11:28:26 2009
From: andy.bierlair at root.lu (Andy BIERLAIR)
Date: Tue, 24 Mar 2009 16:28:26 +0100
Subject: [c-nsp] match multiple communities in route-map
Message-ID: <000301c9ac95$2d1a9070$874fb150$@bierlair@root.lu>

I have read that multiple match lines in a route-map are treated with AND
logic.

But this scenario here does not do AND, but OR:

route-map IX-TEST-OUT permit 10
  match community PREPEND-1-PEERING
  match community PEERING-OUT
  set as-path prepend 65001

route-map IX-TEST-OUT permit 20
  match community PREPEND-2-PEERING
  match community PEERING-OUT
  set as-path prepend 65001 65001

route-map IX-TEST-OUT permit 30
  match community PEERING-OUT

What I am trying to do is this:

1) Every customer who is sending me prefixes gets a community tag via
inbound route-map. Every prefix gets injected into community PEERING-OUT.

PEERING-OUT has all the prefixes I want to announce to my peers (not
transits!) on a public Internet Exchange


2) The customer can send a certain number of communities to us in order to
manipulate ingress traffic towards his ASN. For instance community list
PREPEND-x-PEERING has all the prefixes that customers want to apply
prepending to.

Prepending Communities are:

64600:X - Prepend X times to Transit (x = 0 - 4)
64700:X - Prepend X times to Peer (x = 0 - 4)


In order to announce all my prefixes correctly to my peers, I need to match
multiple communities - or find a different solution.

In my scenario above all my peers will get ALL my prefixes with 1x
prepending of 65001, and not just those that match PREPEND-1-PEERING.

I also tried the "continue" statement in route-maps, but this didn't seem to
help either.

What is wrong with this scenario?

Thanks.

-
Andy



From cchurc05 at harris.com  Tue Mar 24 11:31:54 2009
From: cchurc05 at harris.com (Church, Charles)
Date: Tue, 24 Mar 2009 10:31:54 -0500
Subject: [c-nsp] OSPF and iBGP session drops between 3640s
In-Reply-To: <4f84a6f80903240755v210553cbrd5220245ef64d59e@mail.gmail.com>
References: <4f84a6f80903240755v210553cbrd5220245ef64d59e@mail.gmail.com>
Message-ID: <FA1BA229357DB640B944218F3585FECA02122C45@mspe2k1.cs.myharris.net>

That 12.4(3) IOS is pretty old.  Trying a newer one might help, as
you're vulnerable to many things.  It's possible there are bugs you're
hitting that are affecting performance.  If you could consolidate some
things, that may help.  You're matching RTP, but also matching packet
length, that might be overkill.  The fast hellos for OSPF probably
aren't helping either.  Another thought might be to score a 2950 or 3550
L2 switch, and put that in place of the 2924.  Then move all the ACls to
that, as it can do them in hardware.  You could probably do a little
buffer tuning, middle ones look pretty ugly.  Probably not long term
solution.  I think MCQ is more efficient than CAR, might want to move to
that completely.

Chuck


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Robert Johnson
Sent: Tuesday, March 24, 2009 10:55 AM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] OSPF and iBGP session drops between 3640s


Hello list,
I have a small network with four 3640s. Each router has 128/32MB ram,
and a
single FE interface connected to a catalyst 2924. Two of the routers are
running BGP, each with a session to a (single) other provider, and a
session
between themselves. These are not carrying full tables. All four routers
are
running OSPF between each other. The problem is that occasionally (from
once
a week to 3x/day) OSPF neighbor relationships will bounce due to hello
timers expiring. Just recently the iBGP session between two of the
routers
also bounced.

There do not appear to be any layer 1 or 2 connectivity problems that
would
cause this behavior. However, CPU usage on the 3640s seems high- 30%
sustained and up to 90% peak, with only 1-2k max PPS. Also, I'm seeing
buffer misses and failures.

CEF is enabled. There are several relatively long access lists that are
being processed, and the routers are doing QoS classifying and tagging
at
layers 2 and 3 for VoIP performance.

Without any major hardware changes, where do I begin here?

Thanks in advance.



The fun stuff (sho buffers, sho proc cpu hist, sho proc cpu, sho run):

router1#sho buffers
Buffer elements:
     1118 in free list (500 max allowed)
     707983613 hits, 0 misses, 1119 created

Public buffer pools:
Small buffers, 104 bytes (total 78, permanent 50, peak 104 @ 4w0d):
     42 in free list (20 min, 150 max allowed)
     18990955 hits, 3598 misses, 4408 trims, 4436 created
     312 failures (0 no memory)
Middle buffers, 600 bytes (total 25, permanent 25, peak 176 @ 7w0d):
     22 in free list (10 min, 150 max allowed)
     651012877 hits, 12602 misses, 30744 trims, 30744 created
     2744 failures (0 no memory)
Big buffers, 1536 bytes (total 50, permanent 50, peak 63 @ 2d19h):
     50 in free list (5 min, 150 max allowed)
     4658228 hits, 1005 misses, 102 trims, 102 created
     936 failures (0 no memory)
VeryBig buffers, 4520 bytes (total 10, permanent 10, peak 12 @ 7w0d):
     10 in free list (0 min, 100 max allowed)
     129 hits, 807 misses, 13 trims, 13 created
     807 failures (0 no memory)
Large buffers, 5024 bytes (total 1, permanent 0, peak 3 @ 7w0d):
     1 in free list (0 min, 10 max allowed)
     14 hits, 793 misses, 2764 trims, 2765 created
     793 failures (0 no memory)
Huge buffers, 18024 bytes (total 1, permanent 0, peak 3 @ 7w0d):
     1 in free list (0 min, 4 max allowed)
     16 hits, 779 misses, 3858 trims, 3859 created
     778 failures (0 no memory)

Interface buffer pools:
CD2430 I/O buffers, 1536 bytes (total 0, permanent 0):
     0 in free list (0 min, 0 max allowed)
     0 hits, 0 fallbacks

Header pools:
Header buffers, 0 bytes (total 265, permanent 256, peak 265 @ 7w0d):
     9 in free list (10 min, 512 max allowed)
     253 hits, 3 misses, 0 trims, 9 created
     0 failures (0 no memory)
     256 max cache size, 256 in cache
     7674266 hits in cache, 0 misses in cache

Particle Clones:
     1024 clones, 0 hits, 0 misses

Public particle pools:
F/S buffers, 256 bytes (total 384, permanent 384):
     128 in free list (128 min, 1024 max allowed)
     256 hits, 0 misses, 0 trims, 0 created
     0 failures (0 no memory)
     256 max cache size, 256 in cache
     0 hits in cache, 0 misses in cache
Normal buffers, 1548 bytes (total 512, permanent 512):
     384 in free list (128 min, 1024 max allowed)
     21114 hits, 0 misses, 0 trims, 0 created
     0 failures (0 no memory)
     128 max cache size, 128 in cache
     0 hits in cache, 0 misses in cache

Private particle pools:
IDS SM buffers, 240 bytes (total 128, permanent 128):
     0 in free list (0 min, 128 max allowed)
     128 hits, 0 fallbacks
     128 max cache size, 128 in cache
     0 hits in cache, 0 misses in cache
FastEthernet0/0 buffers, 1548 bytes (total 192, permanent 192):
     0 in free list (0 min, 192 max allowed)
     192 hits, 0 fallbacks
     192 max cache size, 128 in cache
     694772430 hits in cache, 20986 misses in cache

router1#sho proc cpu hist

router1   02:40:53 PM Tuesday Mar 24 2009 UTC


    4444444444444444444444444444444555554444444444444443333355
    8333332222200000000004444411111111110000000000222227777722
100
 90
 80
 70
 60
 50 *                              *****                    ****
 40 ************************************************************
 30 ************************************************************
 20 ************************************************************
 10 ************************************************************
   0....5....1....1....2....2....3....3....4....4....5....5....
             0    5    0    5    0    5    0    5    0    5
               CPU% per second (last 60 seconds)

    5656435544454334664445454566532243344446444645545774454545
    2900663259495363238448467911347711166900544033873220265057
100
 90
 80
 70  *                                               **
 60  * *       *    **   * * ***           *   *  *  **  *   *
 50 ***#* *#** **   ***  * **###*      *** **  * ****#*  *******
 40 ##*##*####*#* **####*#***###*   *  **********######****#####
 30 ##############################**#***##*#**##################
 20 ############################################################
 10 ############################################################
   0....5....1....1....2....2....3....3....4....4....5....5....
             0    5    0    5    0    5    0    5    0    5
               CPU% per minute (last 60 minutes)
              * = maximum CPU%   # = average CPU%

 
7664665666756555557666776555554545664455555555455555654555556565545654
 
2734555279005332498657259890379052808981353640965081868135475217086638
100
 90
 80                   *    *
 70 **  **  *** *     *******         *                 *       *      *
*
 60 *** ******* *    **********  *    **  *  * *   ** * **   * ** **  **
**
 50 ***
********************************************************************
 40
****##########****#***##****########################*###################
 30
##**###########***########**############################################
 20
###*############*##########*############################################
 10
########################################################################
 
0....5....1....1....2....2....3....3....4....4....5....5....6....6....7.
             0    5    0    5    0    5    0    5    0    5    0    5
0
                   CPU% per hour (last 72 hours)
                  * = maximum CPU%   # = average CPU%


sho proc cpu:

CPU utilization for five seconds: 42%/39%; one minute: 43%; five
minutes:
40%

router1#sho run
Building configuration...

Current configuration : 8460 bytes
!
! Last configuration change at 01:54:37 UTC Tue Mar 24 2009
! NVRAM config last updated at 22:25:51 UTC Thu Mar 5 2009
!
version 12.4
service timestamps debug uptime
service timestamps log uptime
service password-encryption
!
hostname router1
!
boot-start-marker
boot system flash c3640-jk9o3s-mz.124-3.bin
boot-end-marker
!
no logging console
enable secret 5 **
!
no aaa new-model
!
resource policy
!
ip subnet-zero
no ip source-route
!
!
ip cef
!
!
class-map match-all assure
 match ip dscp af31
class-map match-all critical
 match ip dscp cs6
class-map match-all expedite
 match ip dscp ef
class-map match-any rtp-vox
 match ip rtp 13456 13462
 match ip rtp 13556 13560
 match ip rtp 13656 13660
 match ip rtp 13756 13760
class-map match-all sip
 match protocol sip
class-map match-all voice
 match packet length min 1 max 200
 match class-map rtp-vox
!
!
policy-map output-cos
 class expedite
  set cos 6
 class assure
  set cos 5
 class critical
  set cos 7
policy-map input-mark
 class sip
  set ip dscp af31
 class voice
  set dscp ef
!
!
!
!
!
!
interface FastEthernet0/0
 description Trunk to cat2924-pri
 no ip address
 full-duplex
!
interface FastEthernet0/0.5
 description Switch management segment
 encapsulation dot1Q 5
 ip address 10.1.5.254 255.255.255.0
 ip access-group mgmt-only in
 ip access-group mgmt-only out
 no snmp trap link-status
!
interface FastEthernet0/0.15
 description AP management segment
 encapsulation dot1Q 15
 ip address 10.1.15.254 255.255.255.0
 ip access-group mgmt-only in
 ip access-group mgmt-only out
 no snmp trap link-status
!
interface FastEthernet0/0.25
 description CTM management segment
 encapsulation dot1Q 25
 ip address 10.1.25.254 255.255.255.0
 ip access-group mgmt-only in
 ip access-group mgmt-only out
 no snmp trap link-status
!
interface FastEthernet0/0.35
 description UPS management segment
 encapsulation dot1Q 35
 ip address 10.1.35.254 255.255.255.0
 ip access-group mgmt-only in
 ip access-group mgmt-only out
 no snmp trap link-status
!
interface FastEthernet0/0.50
 description Management link to router3
 bandwidth 9850
 encapsulation dot1Q 50
 ip address 10.1.50.254 255.255.255.0
 ip access-group mgmt-only in
 ip access-group mgmt-only out
 ip ospf message-digest-key 1 md5 7 *secret*
 ip ospf hello-interval 1
 ip ospf dead-interval 5
 no snmp trap link-status
!
interface FastEthernet0/0.51
 description Management link to router2
 encapsulation dot1Q 51
 ip address 10.1.51.254 255.255.255.0
 ip access-group mgmt-only in
 ip access-group mgmt-only out
 ip ospf message-digest-key 1 md5 7 **
 ip ospf hello-interval 1
 ip ospf dead-interval 5
 no snmp trap link-status
!
interface FastEthernet0/0.52
 description Management link to **
 bandwidth 10610
 encapsulation dot1Q 52
 ip address 10.1.52.254 255.255.255.0
 ip access-group mgmt-only in
 ip access-group mgmt-only out
 no snmp trap link-status
!
interface FastEthernet0/0.300
 description Production traffic link to router3
 bandwidth 9850
 encapsulation dot1Q 300
 ip address xxx.xxx.xxx.xxx 255.255.255.252
 ip ospf message-digest-key 10 md5 7 **
 ip ospf dead-interval minimal hello-multiplier 4
 no snmp trap link-status
 service-policy output output-cos
!
interface FastEthernet0/0.301
 description Production traffic link to router2
 encapsulation dot1Q 301
 ip address xxx.xxx.xxx.xxx 255.255.255.252
 ip ospf message-digest-key 10 md5 7 **
 ip ospf dead-interval minimal hello-multiplier 4
 no snmp trap link-status
 service-policy output output-cos
!
interface FastEthernet0/0.302
 description Production traffic link to **
 bandwidth 10610
 encapsulation dot1Q 302
 ip address xxx.xxx.xxx.xxx 255.255.255.252
 ip access-group internet-edge-ingress in
 ip access-group internet-edge-egress out
 no snmp trap link-status
 service-policy input input-mark
 service-policy output output-cos
!
interface FastEthernet0/0.500
 description Customer access subnet
 encapsulation dot1Q 500
 ip address xxx.xxx.xxx.xxx 255.255.255.240
 ip access-group block-customercrap in
 ip verify unicast reverse-path
 rate-limit input access-group 100 768000 10000 200000 conform-action
transmit e
xceed-action drop
 rate-limit output access-group 100 768000 40000000 80000000
conform-action
tran
smit exceed-action drop
 no snmp trap link-status
 service-policy output output-cos
!
router ospf 1000
 log-adjacency-changes
 area 0.0.0.0 authentication message-digest
 passive-interface default
 no passive-interface FastEthernet0/0.300
 no passive-interface FastEthernet0/0.301
 network xxx.xxx.xxx.xxx 0.0.0.63 area 0.0.0.0
 network xxx.xxx.xxx.xxx 0.0.0.63 area 0.0.0.0
 network xxx.xxx.xxx.xxx 0.0.0.63 area 0.0.0.0
 network xxx.xxx.xxx.xxx 0.0.0.63 area 0.0.0.0
 default-information originate metric-type 1
!
router ospf 100
 log-adjacency-changes
 area 10.0.0.0 authentication message-digest
 area 10.0.0.0 stub no-summary
 passive-interface default
 no passive-interface FastEthernet0/0.50
 no passive-interface FastEthernet0/0.51
 network 10.0.0.0 0.255.255.255 area 10.0.0.0
!
router bgp *****
 no synchronization
 bgp log-neighbor-changes
 network xxx.xxx.xxx.xxx mask 255.255.255.192
 network xxx.xxx.xxx.xxx mask 255.255.255.192
 network xxx.xxx.xxx.xxx mask 255.255.255.192
 network xxx.xxx.xxx.xxx mask 255.255.255.192
 aggregate-address xxx.xxx.xxx.xxx 255.255.255.192 as-set summary-only
 aggregate-address xxx.xxx.xxx.xxx 255.255.255.192 as-set summary-only
 aggregate-address xxx.xxx.xxx.xxx 255.255.255.192 as-set summary-only
 aggregate-address xxx.xxx.xxx.xxx 255.255.255.192 as-set summary-only
 redistribute ospf 1000
 neighbor xxx.xxx.xxx.xxx remote-as ****
 neighbor xxx.xxx.xxx.xxx route-map pri-map out
 neighbor xxx.xxx.xxx.xxx remote-as *****
 neighbor xxx.xxx.xxx.xxx next-hop-self
 no auto-summary
!
no ip http server
no ip http secure-server
ip classless
!
!
!
!
ip access-list standard mgmt-only
 permit 10.0.0.0 0.255.255.255
 permit 192.168.101.0 0.0.0.255
!
ip access-list extended block-customercrap
 deny   udp any any eq bootps
 deny   tcp any any eq 139
 deny   tcp any any eq 445
 deny   udp any any eq netbios-ns
 deny   udp any any eq netbios-dgm
 permit ip any any
ip access-list extended internet-edge-egress
 deny   ip 10.0.0.0 0.255.255.255 any
 deny   ip 172.16.0.0 0.15.255.255 any
 deny   ip 192.168.0.0 0.0.255.255 any
 deny   ip 127.0.0.0 0.0.255.255 any
 deny   ip 224.0.0.0 31.255.255.255 any
 deny   ip 169.254.0.0 0.0.255.255 any
 deny   udp any any eq bootps
 deny   udp any any eq bootpc
 deny   tcp any any eq 139
 deny   tcp any any eq 445
 deny   udp any any eq netbios-ns
 deny   udp any any eq netbios-dgm
 deny   ip any xxx.xxx.xxx.xxx 0.0.0.63
 deny   ip any xxx.xxx.xxx.xxx 0.0.0.63
 deny   ip any xxx.xxx.xxx.xxx 0.0.0.63
 deny   ip any xxx.xxx.xxx.xxx 0.0.0.63
 permit ip any any
ip access-list extended internet-edge-ingress
 deny   ip 10.0.0.0 0.255.255.255 any
 deny   ip 172.16.0.0 0.15.255.255 any
 deny   ip 192.168.0.0 0.0.255.255 any
 deny   ip 127.0.0.0 0.0.255.255 any
 deny   ip 224.0.0.0 31.255.255.255 any
 deny   ip 169.254.0.0 0.0.255.255 any
 deny   udp any any eq bootps
 deny   udp any any eq bootpc
 deny   tcp any any eq 139
 deny   tcp any any eq 445
 deny   udp any any eq netbios-ns
 deny   udp any any eq netbios-dgm
 deny   ip xxx.xxx.xxx.xxx 0.0.0.63 any
 deny   ip xxx.xxx.xxx.xxx 0.0.0.63 any
 deny   ip xxx.xxx.xxx.xxx 0.0.0.63 any
 deny   ip xxx.xxx.xxx.xxx 0.0.0.63 any
 permit ip any any
logging facility local5
logging 10.3.40.105
access-list 1 permit xxx.xxx.xxx.xxx 0.0.0.63
access-list 1 permit xxx.xxx.xxx.xxx 0.0.0.63
access-list 2 permit xxx.xxx.xxx.xxx 0.0.0.63
access-list 2 permit xxx.xxx.xxx.xxx 0.0.0.63
access-list 100 permit ip host xxx.xxx.xxx.xxx any
access-list 100 permit ip any host xxx.xxx.xxx.xxx
snmp-server community ** RO mgmt-only
!
route-map pri-map permit 10
 match ip address 1
!
route-map pri-map permit 20
 match ip address 2
!
!
!
control-plane
!
!
!
!
!
!
!
!
!
banner login ^C Property of **. Unauthorized access attempt
s will be prosecuted. ^C
!
line con 0
 password 7 **
 login
line aux 0
 password 7 **
 login
line vty 0 4
 access-class mgmt-only in
 password 7 **
 login
!
ntp clock-period 17179597
ntp server 10.3.40.105
!
end
_______________________________________________
cisco-nsp mailing list  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  Tue Mar 24 11:59:17 2009
From: mksmith at adhost.com (Michael K. Smith - Adhost)
Date: Tue, 24 Mar 2009 08:59:17 -0700
Subject: [c-nsp] No GRP images for GSR's?
Message-ID: <17838240D9A5544AAA5FF95F8D52031605B42804@ad-exh01.adhost.lan>

Hello All:

I just want to make sure I haven't lost my mind.  I logged into CCO looking for 12.0S images for the GRP and all I see is PRP images.  Has Cisco stopped supplying images for the GRP-based GSR's?

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)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 474 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090324/91b08076/attachment.bin>

From hegedus.gabor at euroway.hu  Tue Mar 24 11:32:13 2009
From: hegedus.gabor at euroway.hu (Hegedus Gabor)
Date: Tue, 24 Mar 2009 16:32:13 +0100
Subject: [c-nsp] learning materials, curriculum, config guide for MARS
Message-ID: <49C8FCFD.6010303@euroway.hu>

Hi all!

I need some help!

Can somebody give me a curriculum or e-book, or link for MARS, CSA, IDS, 
IPS.
I want to learn about them, but I can't find materials.

config guides, 'howto's, e-learning materials,  e-book web pages...  
everything can be good.



thank you
Gabor

From mksmith at adhost.com  Tue Mar 24 12:04:39 2009
From: mksmith at adhost.com (Michael K. Smith - Adhost)
Date: Tue, 24 Mar 2009 09:04:39 -0700
Subject: [c-nsp] match multiple communities in route-map
In-Reply-To: <000301c9ac95$2d1a9070$874fb150$@bierlair@root.lu>
References: <000301c9ac95$2d1a9070$874fb150$@bierlair@root.lu>
Message-ID: <17838240D9A5544AAA5FF95F8D52031605B42808@ad-exh01.adhost.lan>

Hello Andy:

I don't think you want the two match-community statements in your first two route-map statements.  So, that would be:
> 
> route-map IX-TEST-OUT permit 10
>   match community PREPEND-1-PEERING
--   match community PEERING-OUT
>   set as-path prepend 65001
> 
> route-map IX-TEST-OUT permit 20
>   match community PREPEND-2-PEERING
--   match community PEERING-OUT
>   set as-path prepend 65001 65001
> 
> route-map IX-TEST-OUT permit 30
>   match community PEERING-OUT
> 

Also, you might want to confirm you're seeing the right stuff in your community sets using the "sho ip bgp community-list PEERING-OUT|PREPEND-1-PEERING, etc.

Regards,

Mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 474 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090324/1820735f/attachment.bin>

From nicotine at warningg.com  Tue Mar 24 12:15:17 2009
From: nicotine at warningg.com (Brandon Ewing)
Date: Tue, 24 Mar 2009 11:15:17 -0500
Subject: [c-nsp] No GRP images for GSR's?
In-Reply-To: <17838240D9A5544AAA5FF95F8D52031605B42804@ad-exh01.adhost.lan>
References: <17838240D9A5544AAA5FF95F8D52031605B42804@ad-exh01.adhost.lan>
Message-ID: <20090324161517.GG15184@biological.warningg.com>

On Tue, Mar 24, 2009 at 08:59:17AM -0700, Michael K. Smith - Adhost wrote:
> Hello All:
> 
> I just want to make sure I haven't lost my mind.  I logged into CCO looking for 12.0S images for the GRP and all I see is PRP images.  Has Cisco stopped supplying images for the GRP-based GSR's?
> 
> 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)
> 
> 

GRP and GRP-B are EOL/EOS at this time.  Last release is 12.0(32)S

Looks like in the new browser, they're filed as "12000 Performance Route
Processor Engine" images.  Filename is still gsr-p-mz, which runs on the
GRP.


Note that 12.0(32)S12 contains the 4-byte ASN problems discussed here and on
NANOG, so 12.0(32)S11 is your best bet.

-- 
Brandon Ewing                                        (nicotine at warningg.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090324/c7afce93/attachment.bin>

From swmike at swm.pp.se  Tue Mar 24 12:21:40 2009
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Tue, 24 Mar 2009 17:21:40 +0100 (CET)
Subject: [c-nsp] No GRP images for GSR's?
In-Reply-To: <20090324161517.GG15184@biological.warningg.com>
References: <17838240D9A5544AAA5FF95F8D52031605B42804@ad-exh01.adhost.lan>
	<20090324161517.GG15184@biological.warningg.com>
Message-ID: <alpine.DEB.1.10.0903241720380.25843@uplift.swm.pp.se>

On Tue, 24 Mar 2009, Brandon Ewing wrote:

> Note that 12.0(32)S12 contains the 4-byte ASN problems discussed here 
> and on NANOG, so 12.0(32)S11 is your best bet.

As far as I have heard, most people are at 12.0(32)SY, which is (I would 
say) a better bet.

I've also been told there will be no 12.0(33)S for GRP, just as you 
stated.

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

From blahu77 at gmail.com  Tue Mar 24 12:32:27 2009
From: blahu77 at gmail.com (Mateusz Blaszczyk)
Date: Tue, 24 Mar 2009 16:32:27 +0000
Subject: [c-nsp] match multiple communities in route-map
In-Reply-To: <519097609226851261@unknownmsgid>
References: <519097609226851261@unknownmsgid>
Message-ID: <383357750903240932l5398ae84pcb495c1bfdc3595b@mail.gmail.com>

Andy,

Try using policy-list which don't get merged like community-lists...

ip policy-list PERMIT200 permit
   match community 2
!
ip policy-list PERMIT100 permit
   match community 1
!
ip community-list 1 permit 123:100
ip community-list 2 permit 123:200
!
!
!
route-map OUT permit 10
   match policy-list PERMIT200
   match policy-list PERMIT100
!


Best Regards,


-mat



2009/3/24 Andy BIERLAIR <andy.bierlair at root.lu>:
> I have read that multiple match lines in a route-map are treated with AND
> logic.
>
> But this scenario here does not do AND, but OR:
>
> route-map IX-TEST-OUT permit 10
> ?match community PREPEND-1-PEERING
> ?match community PEERING-OUT
> ?set as-path prepend 65001
>
> route-map IX-TEST-OUT permit 20
> ?match community PREPEND-2-PEERING
> ?match community PEERING-OUT
> ?set as-path prepend 65001 65001
>
> route-map IX-TEST-OUT permit 30
> ?match community PEERING-OUT
>
> What I am trying to do is this:
>
> 1) Every customer who is sending me prefixes gets a community tag via
> inbound route-map. Every prefix gets injected into community PEERING-OUT.
>
> PEERING-OUT has all the prefixes I want to announce to my peers (not
> transits!) on a public Internet Exchange
>
>
> 2) The customer can send a certain number of communities to us in order to
> manipulate ingress traffic towards his ASN. For instance community list
> PREPEND-x-PEERING has all the prefixes that customers want to apply
> prepending to.
>
> Prepending Communities are:
>
> 64600:X - Prepend X times to Transit (x = 0 - 4)
> 64700:X - Prepend X times to Peer (x = 0 - 4)
>
>
> In order to announce all my prefixes correctly to my peers, I need to match
> multiple communities - or find a different solution.
>
> In my scenario above all my peers will get ALL my prefixes with 1x
> prepending of 65001, and not just those that match PREPEND-1-PEERING.
>
> I also tried the "continue" statement in route-maps, but this didn't seem to
> help either.
>
> What is wrong with this scenario?
>
> Thanks.
>
> -
> Andy
>
>
> _______________________________________________
> cisco-nsp mailing list ?cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>



-- 
pgp-key 0x1C655CAB

From chris at chrisserafin.com  Tue Mar 24 12:41:10 2009
From: chris at chrisserafin.com (ChrisSerafin)
Date: Tue, 24 Mar 2009 11:41:10 -0500
Subject: [c-nsp] How not to redistribute statics into VRFs/BGP
Message-ID: <49C90D26.2050604@chrisserafin.com>

I have a Sprint MPLS cloud for which they extend the VRF configs down to 
the CE. I am in the middle of divesting a section of these MPLS 
routers/subnets off of the main cloud and onto their own VRFs. I 
essentially want to start by making a handfull of the sites, change 
their default route for Internet. Normally I would just add a new static 
route and then NOT use 'redistribute static' in the BGP config, but this 
whole VRF is new to me.

Any thoughts would be great! Thanks:

ip cef
!
!
ip vrf xxxx-General
 rd 1:10
 route-target export 1:10
 route-target import 1:10
!
ip vrf xxxx-Guest
 rd 1:30
 route-target export 1:30
 route-target import 1:30
!
ip vrf xxxx-Voice
 rd 1:20
 route-target export 1:20
 route-target import 1:20
!

!
!
!
!
!
!
interface Loopback0
 ip address 10.10.10.10 255.255.255.255
!
!
interface GigabitEthernet0/0
 description [ Link to Core Switch ]
 no ip address
 duplex auto
 speed auto
!
interface GigabitEthernet0/0.1
 description [ VLAN 1 - General xxxx Data VLAN ]
 encapsulation dot1Q 1 native
 ip vrf forwarding xxxx-General
 ip address 10.120.64.1 255.255.255.0
 ip virtual-reassembly
!
interface GigabitEthernet0/0.100
 description [ VLAN 100 - General xxxx Voice VLAN ]
 encapsulation dot1Q 100
 ip vrf forwarding xxxx-Voice
 ip address 10.121.64.1 255.255.255.0
!
interface GigabitEthernet0/0.200
 description [ VLAN 200 - General xxxx Guest VLAN ]
 encapsulation dot1Q 200
 ip vrf forwarding xxxx-Guest
 ip address 172.16.10.1 255.255.255.0
!
!
interface Serial0/0/0:1
 no ip address
 encapsulation frame-relay
 shutdown
 frame-relay lmi-type ansi
!
interface Serial0/1/0
 description [ Sprint MPLS Circuit ]
 no ip address
 encapsulation frame-relay
 frame-relay lmi-type ansi
 service-policy output VOIP-WAN
!
interface Serial0/1/0.310 point-to-point
 description [ MPLS VRF - Data VLAN ]
 ip vrf forwarding xxxx-General
 ip address 10.150.1.37 255.255.255.252
 snmp trap link-status
 frame-relay interface-dlci 310  
!
interface Serial0/1/0.410 point-to-point
 description [ MPLS VRF - Voice VLAN ]
 ip vrf forwarding xxxx-Voice
 ip address 10.151.1.37 255.255.255.252
 snmp trap link-status
 frame-relay interface-dlci 410  
!
interface Serial0/1/0.510 point-to-point
 description [ MPLS VRF - Guest VLAN ]
 ip vrf forwarding xxxx-Guest
 ip address 10.152.1.37 255.255.255.252
 snmp trap link-status
 frame-relay interface-dlci 510  
!
router eigrp 217
 no auto-summary
 !
 address-family ipv4 vrf xxxx-General
  network 10.11.0.0 0.0.0.255
  network 10.120.64.0 0.0.0.255
  no auto-summary
  autonomous-system 19
 exit-address-family
 eigrp router-id 1.1.1.2
 eigrp event-logging
!
router bgp 65010
 bgp log-neighbor-changes
 neighbor 10.150.1.38 remote-as 1803
 neighbor 10.150.1.38 password 7 153E020A1xx373C3627
 neighbor 10.150.1.38 version 4
 !
 address-family ipv4
  neighbor 10.150.1.38 activate
  no auto-summary
  no synchronization
 exit-address-family
 !
 address-family ipv4 vrf xxxx-Voice
  neighbor 10.151.1.38 remote-as 1803
  neighbor 10.151.1.38 password 7 0328520Dxx205F5A0C0B
  neighbor 10.151.1.38 version 4
  neighbor 10.151.1.38 activate
  no synchronization
 exit-address-family
 !
 address-family ipv4 vrf xxxx-Guest
  neighbor 10.152.1.38 remote-as 1803
  neighbor 10.152.1.38 password 7 013F0F024xx071C35495C
  neighbor 10.152.1.38 version 4
  neighbor 10.152.1.38 activate
  no synchronization
 exit-address-family
 !
 address-family ipv4 vrf xxxx-General
  neighbor 10.150.1.38 remote-as 1803
  neighbor 10.150.1.38 password 7 047702001xx4D5D1D1C17
  neighbor 10.150.1.38 version 4
  neighbor 10.150.1.38 activate
  no synchronization
  network 10.120.64.0 mask 255.255.255.0
 exit-address-family


thanks,

Chris

From steve at ibctech.ca  Tue Mar 24 11:44:43 2009
From: steve at ibctech.ca (Steve Bertrand)
Date: Tue, 24 Mar 2009 11:44:43 -0400
Subject: [c-nsp] OSPF and iBGP session drops between 3640s
In-Reply-To: <4f84a6f80903240755v210553cbrd5220245ef64d59e@mail.gmail.com>
References: <4f84a6f80903240755v210553cbrd5220245ef64d59e@mail.gmail.com>
Message-ID: <49C8FFEB.8030006@ibctech.ca>

Robert Johnson wrote:
> Hello list,
> I have a small network with four 3640s. Each router has 128/32MB ram, and a
> single FE interface connected to a catalyst 2924. Two of the routers are
> running BGP, each with a session to a (single) other provider, and a session
> between themselves. These are not carrying full tables. All four routers are
> running OSPF between each other. The problem is that occasionally (from once
> a week to 3x/day) OSPF neighbor relationships will bounce due to hello
> timers expiring. Just recently the iBGP session between two of the routers
> also bounced.
> 
> There do not appear to be any layer 1 or 2 connectivity problems that would
> cause this behavior. However, CPU usage on the 3640s seems high- 30%
> sustained and up to 90% peak, with only 1-2k max PPS. Also, I'm seeing
> buffer misses and failures.
> 
> CEF is enabled. There are several relatively long access lists that are
> being processed, and the routers are doing QoS classifying and tagging at
> layers 2 and 3 for VoIP performance.
> 
> Without any major hardware changes, where do I begin here?

The first thing that I would do is remove all of the common ACL "deny"
statements, and route all of those blocks to the discard interface
instead. You could also request a peering session with Team Cymru, and
they will feed to you the invalid routes dynamically.

Then, perhaps a basic configuration to measure if there is
excessive/unnecessary traffic making it to the receive interface(s).

This is a very basic one that I generally manipulate. It will allow and
count all, except for dropping everything in -DENY. Basically, I use it
as a counter, and then tweak to shape and drop traffic as the router
gains operational experience.

I find these methods quite effective in preserving resources in
older/lower end routers.

class-map match-all COPP-NORMAL
 match access-group name COPP-NORMAL
class-map match-any COPP-DENY
 match access-group name COPP-DENY
class-map match-all COPP-ROUTING
 match access-group name COPP-ROUTING
class-map match-all COPP-REMAINING
 match access-group name COPP-CATCHALL
!
policy-map COPP
 class COPP-DENY
   police 8000 1500 1500 conform-action drop  exceed-action drop
 class COPP-ROUTING
   police 125000 1500 1500 conform-action transmit  exceed-action transmit
 class COPP-NORMAL
   police 15000 1500 1500 conform-action transmit  exceed-action transmit
 class COPP-CATCHALL
   police 8000 1500 1500 conform-action transmit  exceed-action transmit
 class class-default
   police 8000 1500 1500 conform-action transmit  exceed-action transmit
!
ip access-list extended COPP-DENY
 permit tcp any any fragments
 permit udp any any fragments
 permit icmp any any fragments
 permit ip any any fragments
ip access-list extended COPP-NORMAL
 permit icmp any any echo
 permit icmp any any echo-reply
 permit icmp any any ttl-exceeded
 permit icmp any any unreachable
 permit icmp any any port-unreachable
 permit icmp any any packet-too-big
 permit udp host x.x.x.x any eq snmp
 permit tcp x.x.x.x 0 0.0.7.255 any eq ssh
 permit tcp x.x.x.x 0 0.0.0.7 eq ssh any established
ip access-list extended COPP-CATCHALL
 permit ip any any
ip access-list extended COPP-ROUTING
 permit tcp any gt 1024 any eq bgp
 permit tcp any eq bgp any gt 1024 established
 permit ospf x.x.x.x 0.0.0.3 any precedence internet
 permit ospf any any precedence internet

control-plane
 service-policy input COPP

Hope this helps,

Steve

From nasir.shaikh at bt.com  Tue Mar 24 13:16:56 2009
From: nasir.shaikh at bt.com (nasir.shaikh at bt.com)
Date: Tue, 24 Mar 2009 17:16:56 -0000
Subject: [c-nsp] Rolling over preshared keys
Message-ID: <D312CD05C8083447B01F57DCDECCF60033D1EA@E03MVZ4-UKDY.domain1.systemhost.net>

Hi,
I am familiar with auto rollover of CA certificates but is there also a way to do an automatic rollover for pre-shared keys?
I am looking to do this in a still to be deployed DMVPN environment and security people would like a policy to change the keys periodically.

Kind regards

Nasir Shaikh 

This email contains information from BT Nederland N.V., which may be privileged or confidential. 
It's meant only for the individual(s) or entity named above. If you are not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited.  
If you have received this email in error, please let me know immediately on the email address above.
We monitor our systems, and may record your emails.

BT Nederland N.V. 
Registered office:  Offices Minerva and Mercurius, Herikerbergweg 2, 1101 CM Amsterdam
Registered at the Amsterdam Chamber of Commerce no:  33296214




From andy.bierlair at root.lu  Tue Mar 24 13:38:59 2009
From: andy.bierlair at root.lu (Andy BIERLAIR)
Date: Tue, 24 Mar 2009 18:38:59 +0100
Subject: [c-nsp] match multiple communities in route-map
In-Reply-To: <17838240D9A5544AAA5FF95F8D52031605B42808@ad-exh01.adhost.lan>
References: <000301c9ac95$2d1a9070$874fb150$@bierlair@root.lu>
	<17838240D9A5544AAA5FF95F8D52031605B42808@ad-exh01.adhost.lan>
Message-ID: <001c01c9aca7$69d9ff20$3d8dfd60$@bierlair@root.lu>

Hi Mike,

Actually I need both conditions set, because the community-list PREPEND-X-PEERING may contain prefixes that we don't want to announce to our peerings, that is why I was looking for some sort of AND logic here.

A real-life example with ASN 1234 would be:

Customer sends us three prefixes:

1.0.0.0/8 with community 64700:3
2.0.0.0/8 without community
3.0.0.0/8 with community 64700:2

With an inbound route-map we tag the first two prefixes with additive communities:

1234:3000 (customer prefix)
1234:3001 (customer 1)
1234:7000 (route learned in Europe)
1234:7003 (route learned in Germany)

The last prefix is only tagged: 1234:9999 (bogon route)

Definition of PEERING-OUT (tag customers from EUROPE):

ip community-list expanded PEERING-OUT permit 1234:3000
ip community-list expanded PEERING-OUT permit 1234:7000

In your scenario 3.0.0.0/8 would be announced to our peers, but would not be part of PEERING-OUT.


Policy-list was mentionned here, but they don't seem to support expanded community-lists.

I hope you get the idea of what I am trying to do.

Thanks.

-
Andy

-----Original Message-----
From: Michael K. Smith - Adhost [mailto:mksmith at adhost.com] 
Sent: Tuesday, March 24, 2009 17:05
To: Andy BIERLAIR; cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] match multiple communities in route-map

Hello Andy:

I don't think you want the two match-community statements in your first two route-map statements.  So, that would be:
> 
> route-map IX-TEST-OUT permit 10
>   match community PREPEND-1-PEERING
--   match community PEERING-OUT
>   set as-path prepend 65001
> 
> route-map IX-TEST-OUT permit 20
>   match community PREPEND-2-PEERING
--   match community PEERING-OUT
>   set as-path prepend 65001 65001
> 
> route-map IX-TEST-OUT permit 30
>   match community PEERING-OUT
> 

Also, you might want to confirm you're seeing the right stuff in your community sets using the "sho ip bgp community-list PEERING-OUT|PREPEND-1-PEERING, etc.

Regards,

Mike


From david.freedman at uk.clara.net  Tue Mar 24 13:51:39 2009
From: david.freedman at uk.clara.net (David Freedman)
Date: Tue, 24 Mar 2009 17:51:39 +0000
Subject: [c-nsp] How not to redistribute statics into VRFs/BGP
In-Reply-To: <49C90D26.2050604@chrisserafin.com>
References: <49C90D26.2050604@chrisserafin.com>
Message-ID: <gqb6jb$te$1@ger.gmane.org>

Chris, the key thing here are the vrf address-families
"> address-family ipv4 vrf xxxx-Voice" e.g

Imagine these like the equivalent of the normal ipv4 address-family, but
for each VRF process.

These do not currently have "redistribute static" in them so you can
quite safely install "ip route vrf xxxx-Voice 0.0.0.0 0.0.0.0 x.x.x.x"
and then this will not be injected into the VRF through BGP until you
add "redistribute static" into the appropriate address-family

if I'm reading your post right?



ChrisSerafin wrote:
> I have a Sprint MPLS cloud for which they extend the VRF configs down to
> the CE. I am in the middle of divesting a section of these MPLS
> routers/subnets off of the main cloud and onto their own VRFs. I
> essentially want to start by making a handfull of the sites, change
> their default route for Internet. Normally I would just add a new static
> route and then NOT use 'redistribute static' in the BGP config, but this
> whole VRF is new to me.
> 
> Any thoughts would be great! Thanks:
> 
> ip cef
> !
> !
> ip vrf xxxx-General
> rd 1:10
> route-target export 1:10
> route-target import 1:10
> !
> ip vrf xxxx-Guest
> rd 1:30
> route-target export 1:30
> route-target import 1:30
> !
> ip vrf xxxx-Voice
> rd 1:20
> route-target export 1:20
> route-target import 1:20
> !
> 
> !
> !
> !
> !
> !
> !
> interface Loopback0
> ip address 10.10.10.10 255.255.255.255
> !
> !
> interface GigabitEthernet0/0
> description [ Link to Core Switch ]
> no ip address
> duplex auto
> speed auto
> !
> interface GigabitEthernet0/0.1
> description [ VLAN 1 - General xxxx Data VLAN ]
> encapsulation dot1Q 1 native
> ip vrf forwarding xxxx-General
> ip address 10.120.64.1 255.255.255.0
> ip virtual-reassembly
> !
> interface GigabitEthernet0/0.100
> description [ VLAN 100 - General xxxx Voice VLAN ]
> encapsulation dot1Q 100
> ip vrf forwarding xxxx-Voice
> ip address 10.121.64.1 255.255.255.0
> !
> interface GigabitEthernet0/0.200
> description [ VLAN 200 - General xxxx Guest VLAN ]
> encapsulation dot1Q 200
> ip vrf forwarding xxxx-Guest
> ip address 172.16.10.1 255.255.255.0
> !
> !
> interface Serial0/0/0:1
> no ip address
> encapsulation frame-relay
> shutdown
> frame-relay lmi-type ansi
> !
> interface Serial0/1/0
> description [ Sprint MPLS Circuit ]
> no ip address
> encapsulation frame-relay
> frame-relay lmi-type ansi
> service-policy output VOIP-WAN
> !
> interface Serial0/1/0.310 point-to-point
> description [ MPLS VRF - Data VLAN ]
> ip vrf forwarding xxxx-General
> ip address 10.150.1.37 255.255.255.252
> snmp trap link-status
> frame-relay interface-dlci 310  !
> interface Serial0/1/0.410 point-to-point
> description [ MPLS VRF - Voice VLAN ]
> ip vrf forwarding xxxx-Voice
> ip address 10.151.1.37 255.255.255.252
> snmp trap link-status
> frame-relay interface-dlci 410  !
> interface Serial0/1/0.510 point-to-point
> description [ MPLS VRF - Guest VLAN ]
> ip vrf forwarding xxxx-Guest
> ip address 10.152.1.37 255.255.255.252
> snmp trap link-status
> frame-relay interface-dlci 510  !
> router eigrp 217
> no auto-summary
> !
> address-family ipv4 vrf xxxx-General
>  network 10.11.0.0 0.0.0.255
>  network 10.120.64.0 0.0.0.255
>  no auto-summary
>  autonomous-system 19
> exit-address-family
> eigrp router-id 1.1.1.2
> eigrp event-logging
> !
> router bgp 65010
> bgp log-neighbor-changes
> neighbor 10.150.1.38 remote-as 1803
> neighbor 10.150.1.38 password 7 153E020A1xx373C3627
> neighbor 10.150.1.38 version 4
> !
> address-family ipv4
>  neighbor 10.150.1.38 activate
>  no auto-summary
>  no synchronization
> exit-address-family
> !
> address-family ipv4 vrf xxxx-Voice
>  neighbor 10.151.1.38 remote-as 1803
>  neighbor 10.151.1.38 password 7 0328520Dxx205F5A0C0B
>  neighbor 10.151.1.38 version 4
>  neighbor 10.151.1.38 activate
>  no synchronization
> exit-address-family
> !
> address-family ipv4 vrf xxxx-Guest
>  neighbor 10.152.1.38 remote-as 1803
>  neighbor 10.152.1.38 password 7 013F0F024xx071C35495C
>  neighbor 10.152.1.38 version 4
>  neighbor 10.152.1.38 activate
>  no synchronization
> exit-address-family
> !
> address-family ipv4 vrf xxxx-General
>  neighbor 10.150.1.38 remote-as 1803
>  neighbor 10.150.1.38 password 7 047702001xx4D5D1D1C17
>  neighbor 10.150.1.38 version 4
>  neighbor 10.150.1.38 activate
>  no synchronization
>  network 10.120.64.0 mask 255.255.255.0
> exit-address-family
> 
> 
> 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/
> 


From chris at chrisserafin.com  Tue Mar 24 14:01:55 2009
From: chris at chrisserafin.com (ChrisSerafin)
Date: Tue, 24 Mar 2009 13:01:55 -0500
Subject: [c-nsp] How not to redistribute statics into VRFs/BGP
In-Reply-To: <gqb6jb$te$1@ger.gmane.org>
References: <49C90D26.2050604@chrisserafin.com> <gqb6jb$te$1@ger.gmane.org>
Message-ID: <49C92013.4070609@chrisserafin.com>

That does sound correct, I will schedule some testing time, thanks for 
your input!

David Freedman wrote:
> Chris, the key thing here are the vrf address-families
> "> address-family ipv4 vrf xxxx-Voice" e.g
>
> Imagine these like the equivalent of the normal ipv4 address-family, but
> for each VRF process.
>
> These do not currently have "redistribute static" in them so you can
> quite safely install "ip route vrf xxxx-Voice 0.0.0.0 0.0.0.0 x.x.x.x"
> and then this will not be injected into the VRF through BGP until you
> add "redistribute static" into the appropriate address-family
>
> if I'm reading your post right?
>
>
>
> ChrisSerafin wrote:
>   
>> I have a Sprint MPLS cloud for which they extend the VRF configs down to
>> the CE. I am in the middle of divesting a section of these MPLS
>> routers/subnets off of the main cloud and onto their own VRFs. I
>> essentially want to start by making a handfull of the sites, change
>> their default route for Internet. Normally I would just add a new static
>> route and then NOT use 'redistribute static' in the BGP config, but this
>> whole VRF is new to me.
>>
>> Any thoughts would be great! Thanks:
>>
>> ip cef
>> !
>> !
>> ip vrf xxxx-General
>> rd 1:10
>> route-target export 1:10
>> route-target import 1:10
>> !
>> ip vrf xxxx-Guest
>> rd 1:30
>> route-target export 1:30
>> route-target import 1:30
>> !
>> ip vrf xxxx-Voice
>> rd 1:20
>> route-target export 1:20
>> route-target import 1:20
>> !
>>
>> !
>> !
>> !
>> !
>> !
>> !
>> interface Loopback0
>> ip address 10.10.10.10 255.255.255.255
>> !
>> !
>> interface GigabitEthernet0/0
>> description [ Link to Core Switch ]
>> no ip address
>> duplex auto
>> speed auto
>> !
>> interface GigabitEthernet0/0.1
>> description [ VLAN 1 - General xxxx Data VLAN ]
>> encapsulation dot1Q 1 native
>> ip vrf forwarding xxxx-General
>> ip address 10.120.64.1 255.255.255.0
>> ip virtual-reassembly
>> !
>> interface GigabitEthernet0/0.100
>> description [ VLAN 100 - General xxxx Voice VLAN ]
>> encapsulation dot1Q 100
>> ip vrf forwarding xxxx-Voice
>> ip address 10.121.64.1 255.255.255.0
>> !
>> interface GigabitEthernet0/0.200
>> description [ VLAN 200 - General xxxx Guest VLAN ]
>> encapsulation dot1Q 200
>> ip vrf forwarding xxxx-Guest
>> ip address 172.16.10.1 255.255.255.0
>> !
>> !
>> interface Serial0/0/0:1
>> no ip address
>> encapsulation frame-relay
>> shutdown
>> frame-relay lmi-type ansi
>> !
>> interface Serial0/1/0
>> description [ Sprint MPLS Circuit ]
>> no ip address
>> encapsulation frame-relay
>> frame-relay lmi-type ansi
>> service-policy output VOIP-WAN
>> !
>> interface Serial0/1/0.310 point-to-point
>> description [ MPLS VRF - Data VLAN ]
>> ip vrf forwarding xxxx-General
>> ip address 10.150.1.37 255.255.255.252
>> snmp trap link-status
>> frame-relay interface-dlci 310  !
>> interface Serial0/1/0.410 point-to-point
>> description [ MPLS VRF - Voice VLAN ]
>> ip vrf forwarding xxxx-Voice
>> ip address 10.151.1.37 255.255.255.252
>> snmp trap link-status
>> frame-relay interface-dlci 410  !
>> interface Serial0/1/0.510 point-to-point
>> description [ MPLS VRF - Guest VLAN ]
>> ip vrf forwarding xxxx-Guest
>> ip address 10.152.1.37 255.255.255.252
>> snmp trap link-status
>> frame-relay interface-dlci 510  !
>> router eigrp 217
>> no auto-summary
>> !
>> address-family ipv4 vrf xxxx-General
>>  network 10.11.0.0 0.0.0.255
>>  network 10.120.64.0 0.0.0.255
>>  no auto-summary
>>  autonomous-system 19
>> exit-address-family
>> eigrp router-id 1.1.1.2
>> eigrp event-logging
>> !
>> router bgp 65010
>> bgp log-neighbor-changes
>> neighbor 10.150.1.38 remote-as 1803
>> neighbor 10.150.1.38 password 7 153E020A1xx373C3627
>> neighbor 10.150.1.38 version 4
>> !
>> address-family ipv4
>>  neighbor 10.150.1.38 activate
>>  no auto-summary
>>  no synchronization
>> exit-address-family
>> !
>> address-family ipv4 vrf xxxx-Voice
>>  neighbor 10.151.1.38 remote-as 1803
>>  neighbor 10.151.1.38 password 7 0328520Dxx205F5A0C0B
>>  neighbor 10.151.1.38 version 4
>>  neighbor 10.151.1.38 activate
>>  no synchronization
>> exit-address-family
>> !
>> address-family ipv4 vrf xxxx-Guest
>>  neighbor 10.152.1.38 remote-as 1803
>>  neighbor 10.152.1.38 password 7 013F0F024xx071C35495C
>>  neighbor 10.152.1.38 version 4
>>  neighbor 10.152.1.38 activate
>>  no synchronization
>> exit-address-family
>> !
>> address-family ipv4 vrf xxxx-General
>>  neighbor 10.150.1.38 remote-as 1803
>>  neighbor 10.150.1.38 password 7 047702001xx4D5D1D1C17
>>  neighbor 10.150.1.38 version 4
>>  neighbor 10.150.1.38 activate
>>  no synchronization
>>  network 10.120.64.0 mask 255.255.255.0
>> exit-address-family
>>
>>
>> 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/
>>
>>     
>
> _______________________________________________
> cisco-nsp mailing 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.0.238 / Virus Database: 270.11.26/2020 - Release Date: 03/24/09 09:19:00
>
>   


From ip at ioshints.info  Tue Mar 24 15:02:26 2009
From: ip at ioshints.info (Ivan Pepelnjak)
Date: Tue, 24 Mar 2009 20:02:26 +0100
Subject: [c-nsp] Needs some help with QOS
In-Reply-To: <1237905405.4965.14.camel@linux-2sym>
References: <1237834921.5059.36.camel@linux-2sym>
	<001901c9ac79$c548c270$0a00000a@nil.si>
	<6664be8ae133a1d173c1cb47ed0b0b5a.squirrel@webmail.pelican.org>
	<1237905405.4965.14.camel@linux-2sym>
Message-ID: <004d01c9acb3$136269f0$0a00000a@nil.si>

> http://www.cisco.com/en/US/tech/tk543/tk545/technologies_tech_note0918
> > 6a00800b2d29.shtml
> 
> Basically, the virtual interfaces "do not implement the 
> "back-pressure algorithm" necessary to signal that excess 
> packets should be queued by the Layer 3 (L3) queueing system."
> 
> Ok, so I'm going to have to implement a new solution based on 
> that document.
> 
> So just a final question, would the solution have worked if 
> it was on a regular interface? I just want to make sure I had 
> the right idea.

Yes, assuming that your outgoing interface is the bottleneck. For example,
if you have a point-to-point uplink, it's usually the bottleneck and the
queuing works as expected. But if you have a Fast Ethernet link into the SP
network which polices you @ 2 Mbps, the output queue will never form at your
output FE interface. Yet again, you'll have to configure shaping to
introduce an artificial bottleneck.

Ivan
 
http://www.ioshints.info/about
http://blog.ioshints.info/


From jloiacon at csc.com  Tue Mar 24 15:05:47 2009
From: jloiacon at csc.com (Joe Loiacono)
Date: Tue, 24 Mar 2009 15:05:47 -0400
Subject: [c-nsp] Traffic analysis via Netflow/BGP export?
In-Reply-To: <000001c9abf4$66ee6840$34cb38c0$@net>
Message-ID: <OF4766B860.5FDC7B85-ON85257583.0067C900-85257583.0068EA0C@csc.com>

Also take a look at flow-tools / FlowViewer. Uses netflow and keeps up to 
three years based on filtering by AS, combination AS's, exclusion of AS's 
etc. Open-source.

http://ensight.eos.nasa.gov/FlowViewer/

Joe



"Jeff Crowe" <listacct at genhex.net> 
Sent by: cisco-nsp-bounces at puck.nether.net
03/23/2009 04:17 PM

To
<cisco-nsp at puck.nether.net>
cc

Subject
[c-nsp] Traffic analysis via Netflow/BGP export?






Hi all,

I am looking for a tool/a collective of tools to help me better manage my
traffic on my edge router.  I am thinking that looking at netflows and BGP
paths would be the best but I am unsure of the tools to use to start
collecting this information.

I would like to have a tool that allows me to historically view traffic
trends going to destination AS's so I can adjust some route-maps to better
balance traffic egressing my network.  Any suggestions would be 
appreciated.

Regards,
Jeff.


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


From perc69 at gmail.com  Tue Mar 24 15:18:39 2009
From: perc69 at gmail.com (Per Carlson)
Date: Tue, 24 Mar 2009 20:18:39 +0100
Subject: [c-nsp] Needs some help with QOS
In-Reply-To: <1237905405.4965.14.camel@linux-2sym>
References: <1237834921.5059.36.camel@linux-2sym>
	<001901c9ac79$c548c270$0a00000a@nil.si>
	<6664be8ae133a1d173c1cb47ed0b0b5a.squirrel@webmail.pelican.org>
	<1237905405.4965.14.camel@linux-2sym>
Message-ID: <746ca6da0903241218g5de55bb5w29ac0d14752e113a@mail.gmail.com>

Hi.

> So just a final question, would the solution have worked if it was on a
> regular interface? I just want to make sure I had the right idea.

Yes, in this case the ATM-interface where the PVC lives. But the PVC
must be something else than the default "ubr" class of service. The U
in UBR stands for Unspecified, i.e. no QoS. Try vbr-nrt instead.

-- 
Pelle

From perc69 at gmail.com  Tue Mar 24 15:39:03 2009
From: perc69 at gmail.com (Per Carlson)
Date: Tue, 24 Mar 2009 20:39:03 +0100
Subject: [c-nsp] No GRP images for GSR's?
In-Reply-To: <alpine.DEB.1.10.0903241720380.25843@uplift.swm.pp.se>
References: <17838240D9A5544AAA5FF95F8D52031605B42804@ad-exh01.adhost.lan>
	<20090324161517.GG15184@biological.warningg.com>
	<alpine.DEB.1.10.0903241720380.25843@uplift.swm.pp.se>
Message-ID: <746ca6da0903241239v52e494cfn858e822b6ec4a6fc@mail.gmail.com>

Hi

> As far as I have heard, most people are at 12.0(32)SY, which is (I would
> say) a better bet.

If you have Eng5 LC's and is doing MPLS-VPNs there is a bug
(CSCsq83540) potentially killing 0.0.0.0/0 in VRFs. Affected are
basically everything upto 32S11, 32SY6 and 33S1. 32S12, 32SY7/8 and
33S2 should be ok (according to BugToolkit).

-- 
Pelle

From john at johnlange.ca  Tue Mar 24 15:39:19 2009
From: john at johnlange.ca (John Lange)
Date: Tue, 24 Mar 2009 14:39:19 -0500
Subject: [c-nsp] Needs some help with QOS
In-Reply-To: <Pine.GSO.4.64.0903241326240.24165@mono>
References: <1237834921.5059.36.camel@linux-2sym>
	<001901c9ac79$c548c270$0a00000a@nil.si>
	<Pine.GSO.4.64.0903241326240.24165@mono>
Message-ID: <1237923559.10614.102.camel@linux-2sym>

On Tue, 2009-03-24 at 13:29 +0100, BALLA Attila wrote:
> Hi,
> 
>    you should use hierarchical QoS. First of all you should shape the 
> output traffic down to the upstream speed, then you can use the llq inside 
> the shaped class:
> http://www.cisco.com/en/US/tech/tk543/tk545/technologies_tech_note09186a00800b2d29.shtml
> 

I followed the examples on that page but I'm not having any luck. As far
as I can tell the queue is dropping at least some packets that it should
be prioritizing (look for 582 below).

First, here is what i have in my config, and below that is the results
of "show policy-map interface". As a side question, the file copy now
seems to work much differently in that it does a big "burst" at the
start of the copy and then "stalls". Is this a burst while the packet
queue fills up?

--- config ---

class-map match-all cm-qos1
 match access-group name al-qos1

policy-map parent_shaping
 class class-default
  shape average 128000
  service-policy child_queueing

policy-map child_queueing
 class cm-qos1
  priority percent 70

interface FastEthernet4
 service-policy output parent_shaping

ip access-list extended al-qos1
 permit ip host xxx.xxx.xxx.xxx any
 permit ip any host xxx.xxx.xxx.xxx

----========-----

l#show policy-map interface 
 FastEthernet4 

Service-policy output: parent_shaping

 Class-map: class-default (match-any)
  157430 packets, 69675635 bytes
  5 minute offered rate 150000 bps, drop rate 25000 bps
  Match: any 
  Queueing
  queue limit 64 packets
  (queue depth/total drops/no-buffer drops) 47/618/0
  (pkts output/bytes output) 15633/18270484
  shape (average) cir 128000, bc 512, be 512
  target shape rate 128000

   Service-policy : child_queueing

    queue stats for all priority classes:
     Queueing
     queue limit 64 packets
     (queue depth/total drops/no-buffer drops) 0/582/0
     (pkts output/bytes output) 3228/2120973

     Class-map: cm-qos1 (match-all)
      3810 packets, 2978841 bytes
      5 minute offered rate 71000 bps, drop rate 25000 bps
      Match: access-group name al-qos1
      Priority: 70% (89 kbps), burst bytes 2200, b/w exceed drops: 582
          

     Class-map: class-default (match-any)
      12441 packets, 16201283 bytes
      5 minute offered rate 69000 bps, drop rate 0 bps
      Match: any 
          
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 46/36/0
      (pkts output/bytes output) 12405/16149511


- 
John Lange
http://www.johnlange.ca



From coloccia at geneseo.edu  Tue Mar 24 15:42:46 2009
From: coloccia at geneseo.edu (Rick Coloccia)
Date: Tue, 24 Mar 2009 15:42:46 -0400
Subject: [c-nsp] Blocking "bad users" based on MAC Address
Message-ID: <49C937B6.1080403@geneseo.edu>

Is anyone doing anything like this in a Catalyst 6500?  I'm running a 
sup 720 with ios 12.2(33)SXH4. I have a "bad user" that I need to block, 
regardless of where or how they connect to the lan.  I hoped that by 
blocking their mac address, where-ever it may appear, I might be able to 
accomplish what I need. 
This doesn't seem to work on my test device.  My gut tells me that the 
problem is in my mac address acl.  Thoughts? Other ways to do this? 

Thanks!
-Rick

mac access-list extended AllDevices
 permit any any
mac access-list extended BadDevices
 permit host 0016.6f99.9e61 any
 permit any host 0016.6f99.9e61
!
!
vlan access-map DropBadDevices 10
 match mac address BadDevices
 action drop
vlan access-map DropBadDevices 20
 match mac address AllDevices
 action forward
!
vlan filter DropBadDevices vlan-list 3030


c6513#show run int vlan 3030
interface Vlan3030
 description ~VLAN 3030 - Encrypted Wireless
 ip dhcp relay information trusted
 ip address 137.238.100.1 255.255.252.0
 ip helper-address 137.238.1.16
 ip flow ingress
 ip pim sparse-dense-mode
end


c6513#show vlan access-map DropBadDevices
Vlan access-map "DropBadDevices"  10
        match: mac address BadDevices
        action: drop
Vlan access-map "DropBadDevices"  20
        match: mac address AllDevices
        action: forward

c6513#show vlan filter vlan 3030
Vlan 3030 has filter DropBadDevices.
        filter is active

c6513#show vlan filter acc     
c6513#show vlan filter access-map DropBadDevices
VLAN Map DropBadDevices:
        Configured on VLANs:  3030
            Active on VLANs:  3030

c6513#show mac-address-table | include 9e61
* 3030  0016.6f99.9e61   dynamic  Yes          0   Po1


-- 
Rick Coloccia, Jr.
Network Manager
State University of NY College at Geneseo
1 College Circle, 119 South Hall
Geneseo, NY 14454
V: 585-245-5577
F: 585-245-5579


From peter at rathlev.dk  Tue Mar 24 15:41:29 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Tue, 24 Mar 2009 20:41:29 +0100
Subject: [c-nsp] Etherchannel and variable latency on member links
In-Reply-To: <49C816AA.60501@utc.edu>
References: <1237848066.3797.12.camel@localhost.localdomain>
	<49C816AA.60501@utc.edu>
Message-ID: <1237923689.3633.9.camel@localhost.localdomain>

Thank you to Ian who replied off list with an example of an
unproblematic implementation of exactly this. I'm more calm now. :-)

On Mon, 2009-03-23 at 19:09 -0400, Jeff Kell wrote:
> AFAIK, etherchannel will select one physical path per flow (based on 
> src/dst ip/mac), so there is no out-of-order to it, nor any load-sharing 
> in the sense that it pays any attention to the link load at all.  At 
> least from the Cisco end... I can't speak for all vendors / host adapters.
> 
> If it *can* load-share, cisco-to-cisco, I'd love to be corrected; but 
> you need something like EIGRP for that (to really look at "load") or 
> equal-cost paths and per-packet load sharing.

You are of course right, but I think this is really a discussion about
what the term "load sharing" means. From my perspective the "load" is
all the traffic, and the etherchannel hashing "shares" this load between
several paths. It is not "fair" or "intelligent" load-sharing in the
same way as per-packet ECMP, MLPPP or actual "load balancing" is, but it
does still split the load.

I was basically trying to say that I didn't consider OoO a problem in
this context. My question was more about what the EC itself and maybe
LACP would say about it. And if it would be wise to use some specific
hashing, like staying away from L4 informations to not confuse certain
hosts. (We always use the default src-dst-ip anyway.)

We'll go through with and tomorrow evening GMT. I'll make sure to update
if we run into any problems. :-)

Regards,
Peter



From schilling2006 at gmail.com  Tue Mar 24 15:51:19 2009
From: schilling2006 at gmail.com (schilling)
Date: Tue, 24 Mar 2009 15:51:19 -0400
Subject: [c-nsp] Blocking "bad users" based on MAC Address
In-Reply-To: <49C937B6.1080403@geneseo.edu>
References: <49C937B6.1080403@geneseo.edu>
Message-ID: <bd3771a60903241251v780a8fame719359ebeb7cec5@mail.gmail.com>

You can just do

mac-address-table static 0016.6f99.9e61 vlan 3030 drop.

Schilling

On Tue, Mar 24, 2009 at 3:42 PM, Rick Coloccia <coloccia at geneseo.edu> wrote:
> Is anyone doing anything like this in a Catalyst 6500? ?I'm running a sup
> 720 with ios 12.2(33)SXH4. I have a "bad user" that I need to block,
> regardless of where or how they connect to the lan. ?I hoped that by
> blocking their mac address, where-ever it may appear, I might be able to
> accomplish what I need. This doesn't seem to work on my test device. ?My gut
> tells me that the problem is in my mac address acl. ?Thoughts? Other ways to
> do this?
> Thanks!
> -Rick
>
> mac access-list extended AllDevices
> permit any any
> mac access-list extended BadDevices
> permit host 0016.6f99.9e61 any
> permit any host 0016.6f99.9e61
> !
> !
> vlan access-map DropBadDevices 10
> match mac address BadDevices
> action drop
> vlan access-map DropBadDevices 20
> match mac address AllDevices
> action forward
> !
> vlan filter DropBadDevices vlan-list 3030
>
>
> c6513#show run int vlan 3030
> interface Vlan3030
> description ~VLAN 3030 - Encrypted Wireless
> ip dhcp relay information trusted
> ip address 137.238.100.1 255.255.252.0
> ip helper-address 137.238.1.16
> ip flow ingress
> ip pim sparse-dense-mode
> end
>
>
> c6513#show vlan access-map DropBadDevices
> Vlan access-map "DropBadDevices" ?10
> ? ? ? match: mac address BadDevices
> ? ? ? action: drop
> Vlan access-map "DropBadDevices" ?20
> ? ? ? match: mac address AllDevices
> ? ? ? action: forward
>
> c6513#show vlan filter vlan 3030
> Vlan 3030 has filter DropBadDevices.
> ? ? ? filter is active
>
> c6513#show vlan filter acc ? ? c6513#show vlan filter access-map
> DropBadDevices
> VLAN Map DropBadDevices:
> ? ? ? Configured on VLANs: ?3030
> ? ? ? ? ? Active on VLANs: ?3030
>
> c6513#show mac-address-table | include 9e61
> * 3030 ?0016.6f99.9e61 ? dynamic ?Yes ? ? ? ? ?0 ? Po1
>
>
> --
> Rick Coloccia, Jr.
> Network Manager
> State University of NY College at Geneseo
> 1 College Circle, 119 South Hall
> Geneseo, NY 14454
> V: 585-245-5577
> F: 585-245-5579
>
> _______________________________________________
> cisco-nsp mailing list ?cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From coloccia at geneseo.edu  Tue Mar 24 16:11:20 2009
From: coloccia at geneseo.edu (Rick Coloccia)
Date: Tue, 24 Mar 2009 16:11:20 -0400
Subject: [c-nsp] Blocking "bad users" based on MAC Address
In-Reply-To: <bd3771a60903241251v780a8fame719359ebeb7cec5@mail.gmail.com>
References: <49C937B6.1080403@geneseo.edu>
	<bd3771a60903241251v780a8fame719359ebeb7cec5@mail.gmail.com>
Message-ID: <49C93E68.6040200@geneseo.edu>

oh, thank you, I see how direct and precise this is, and if I wanted to 
drop the person in several vlans, I assume I could  do

mac-address-table static 0016.6f99.9e61 vlan 3030 drop
mac-address-table static 0016.6f99.9e61 vlan 3010 drop
mac-address-table static 0016.6f99.9e61 vlan 3020 drop

but would that begin to be bad regarding how much impact that would have on the core itself? Is there a more appropriate way for me to do what I need as this scales, so when I have 4, 5, or 10 mac addresses I'm blocking on several vlans?

Thanks, all!

-Rick



schilling wrote:
> You can just do
>
> mac-address-table static 0016.6f99.9e61 vlan 3030 drop.
>
> Schilling
>
> On Tue, Mar 24, 2009 at 3:42 PM, Rick Coloccia <coloccia at geneseo.edu> wrote:
>   
>> Is anyone doing anything like this in a Catalyst 6500?  I'm running a sup
>> 720 with ios 12.2(33)SXH4. I have a "bad user" that I need to block,
>> regardless of where or how they connect to the lan.  I hoped that by
>> blocking their mac address, where-ever it may appear, I might be able to
>> accomplish what I need. This doesn't seem to work on my test device.  My gut
>> tells me that the problem is in my mac address acl.  Thoughts? Other ways to
>> do this?
>> Thanks!
>> -Rick
>>
>> mac access-list extended AllDevices
>> permit any any
>> mac access-list extended BadDevices
>> permit host 0016.6f99.9e61 any
>> permit any host 0016.6f99.9e61
>> !
>> !
>> vlan access-map DropBadDevices 10
>> match mac address BadDevices
>> action drop
>> vlan access-map DropBadDevices 20
>> match mac address AllDevices
>> action forward
>> !
>> vlan filter DropBadDevices vlan-list 3030
>>
>>
>> c6513#show run int vlan 3030
>> interface Vlan3030
>> description ~VLAN 3030 - Encrypted Wireless
>> ip dhcp relay information trusted
>> ip address 137.238.100.1 255.255.252.0
>> ip helper-address 137.238.1.16
>> ip flow ingress
>> ip pim sparse-dense-mode
>> end
>>
>>
>> c6513#show vlan access-map DropBadDevices
>> Vlan access-map "DropBadDevices"  10
>>       match: mac address BadDevices
>>       action: drop
>> Vlan access-map "DropBadDevices"  20
>>       match: mac address AllDevices
>>       action: forward
>>
>> c6513#show vlan filter vlan 3030
>> Vlan 3030 has filter DropBadDevices.
>>       filter is active
>>
>> c6513#show vlan filter acc     c6513#show vlan filter access-map
>> DropBadDevices
>> VLAN Map DropBadDevices:
>>       Configured on VLANs:  3030
>>           Active on VLANs:  3030
>>
>> c6513#show mac-address-table | include 9e61
>> * 3030  0016.6f99.9e61   dynamic  Yes          0   Po1
>>
>>
>> --
>> Rick Coloccia, Jr.
>> Network Manager
>> State University of NY College at Geneseo
>> 1 College Circle, 119 South Hall
>> Geneseo, NY 14454
>> V: 585-245-5577
>> F: 585-245-5579
>>
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>>     

-- 
Rick Coloccia,  Jr.
Network Manager
State University of NY College at Geneseo
1 College Circle, 119 South Hall
Geneseo, NY 14454
V: 585-245-5577
F: 585-245-5579


From matt at overloaded.net  Tue Mar 24 16:43:23 2009
From: matt at overloaded.net (Matt Buford)
Date: Tue, 24 Mar 2009 15:43:23 -0500
Subject: [c-nsp] Opinions of DDoS appliances, other techniques,
	most 	notably Cisco Guard
In-Reply-To: <F3318834F1F89D46857972DD4B411D700651DA6C@EXCHANGE.thenap.com>
References: <Acmlhn3oYhaIJBFzTGm8+Im+aJBnSg==>
	<F3318834F1F89D46857972DD4B411D700651DA6C@EXCHANGE.thenap.com>
Message-ID: <8e157ab40903241343i6a8c4ab1ja047ea8eec48c3e1@mail.gmail.com>

On Sun, Mar 15, 2009 at 10:54 AM, Drew Weaver <drew.weaver at thenap.com>wrote:

> Does anyone here have any real world experience with Cisco Guard or other
> products such as Arbor's Peakflow that they can share?
>
> If you've tried multiple systems and ended up with a specific one, please
> share the reasoning behind it.
>

I have had Cisco/Riverhead Guards deployed for years.  I bought them back
before Cisco bought Riverhead.  I do not have the the detectors though.


> Also, without a dedicated DDoS system deployed, what is the most
> reliable/fastest way to determine the destination(s) of the attacks (SNMP,
> NetFlow, etc)?
>

Netflow is what we use.  Something as simple as a "top 100 sources" and "top
100 destinations" page, which then lets you click on a listed IP and see a
random selection of flows is tremendously useful for this.

Our focus is to keep the victim site active, so null routing (locally or
upstream) isn't an option unless traffic levels reach catastrophic levels.
 For this purpose, we've found the Guard to be very effective at flood
attacks, but pretty much useless for zombie attacks.

SYN floods, UDP floods, or really any kind of raw packet flood is easily
handled by the Guard.

However, build a zombie network of 10,000 hosts, each of which hits a
high-cost URL (say /search.cgi?query=findme) only hit per second, and the
guard just passes it through.

In one situation (back in 2004 I believe), I had a long list of zombies that
I detected through simple perl analysis of the web server log files.  I
think the method I used was something like "exluding all GIF/JPG hits, any
host that hit this search URL, and only this URL, at least once during each
hour of the last 12 hours".  This generated a list of roughly 20,000
attacking hosts. But even knowing that, how could I block them?  The
firewall can't handle a config of 20,000 /32's.  The router can't handle
that either.  I tried putting them in the guard, and nope it couldn't handle
the blacklist either.

So, what worked?  I put them in .htaccess.  It was trivial for the web
server to handle a 20,000 line .htaccess file, accept these connections, and
return 403 forbidden.  This kept the attackers from hitting the high-cost
dynamically generated URL and brought load on the servers to near-normal
levels.

So, in short, I've found the Guard to be very effective at blocking flood
type attacks, but I've found zombie attacks (where each zombie is actually
hitting the site very slowly) is generally best handled on the server.

From peter at rathlev.dk  Tue Mar 24 16:47:27 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Tue, 24 Mar 2009 21:47:27 +0100
Subject: [c-nsp] BGP problem on IPSec links
In-Reply-To: <49C8122E.1020008@wp.pl>
References: <49C8122E.1020008@wp.pl>
Message-ID: <1237927647.4398.7.camel@localhost.localdomain>

On Mon, 2009-03-23 at 23:50 +0100, zarenks wrote:
> I wonder if anyone had experienced the problem I have noticed with 
> dynamic routing (BGP) running over IPSec link.
...
> I decide to use VTI (Virtual Tunnel Interface) configuration instead
> of IPSec+GRE to support dynamic routing.
> 
> Untill I use the OSPF as a routing prot. there is no questions about
> the functionality and connectivity.

So running OSPF on the PE-CE-link gives you full connectivity?

> The BGP session is established correcty, and I can see all the
> prefixes correctly redistributed....., but....
> 
> I can not access the Customer VPN network (say: HQ) from the LAN
> network on that CE (source ping, source traceroute fails)
> The same situation occures if I try to access a LAN network placed 
> behind the CE from HQ site. (or other CE site)
> 
> It is strange, because from any point of customer VPN I can access the
> CE WAN interface but no LAN.
> At glance it looks like the IPSec has some problems with encapsulation
> of traffic sent via BGP but in the same time, there is no problem to 
> show all necessary prefixes in routing tables at both sides (CE and
> PE).

BGP is purely control-plane, so the forwarding of traffic has nothing to
do with this. BGP feeds the routing table (RIB) which in turn feeds the
forwarding table (FIB).

How does the next-hop appear in the RIB of the PE and the CE?

> If I only try to manualy configure (on PE) the STATIC entry for the 
> CE-LAN network, everything works fine as expected.....well, but this
> is not the big challenge :-)

You wouldn't happen to use summaries in the PE? This could lead to
problems when removing labels and forwarding via "regular" RIB lookups.
As a rule of thumb the LFIB prefixes announced via BGP should match the
real routes in an MPLS VPN network. (I'm not saying this can't work,
just that it could lead to interesting scenarios.)

Regards,
Peter



From tkacprzynski at SpencerStuart.com  Tue Mar 24 17:04:07 2009
From: tkacprzynski at SpencerStuart.com (tkacprzynski at SpencerStuart.com)
Date: Tue, 24 Mar 2009 16:04:07 -0500
Subject: [c-nsp] BGP - Multihoming
In-Reply-To: <c93a55220903141734m532f8489m88623b5d1cd89556@mail.gmail.com>
References: <d9281f5c0903141613v1c165fd7y18077b5ec1609bdf@mail.gmail.com><5EB9799F396A304686962AFFF740ED0CE9C50383@NOOSLEXCH001.adno.local>
	<c93a55220903141734m532f8489m88623b5d1cd89556@mail.gmail.com>
Message-ID: <A8A11BA006DA57498FAC0A56686865042A53ED1A@usilwdex04.spencerstuart.com>

I would defiantly check out http://onesc.net/communities/ it lists communities of major providers. You can see if your ISP_2 is on there and supports modifying the LOCAL_PREF with communities. That happened to me before where one ISP was setting a higher preference for a path with longer AS.

Tom


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Christian Koch
Sent: Saturday, March 14, 2009 7:34 PM
To: Stig Johansen
Cc: Burak Dikici; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] BGP - Multihoming

I'd agree with Stig's suggestions and his assumption about the local
pref is probably correct. I'd also suggest you check if your SP's have
defined communities to send in order to alter attributes of the
prefixes you are sending.


On Sat, Mar 14, 2009 at 5:07 PM, Stig Johansen <Stig.Johansen at atea.no> wrote:
> Burak Dikici wrote:
>>I would like consult some subject about BGP to the experienced BGP users. We are making a BGP connection to a two different ISPs via central site router.
>>We are announcing our subnet via ISP-1 normally , but for ISP2 we are announcing the subnet with AS path prepending configuration. As a result , we still see inbound traffic from internet to our subnet via ISP-2. Is that possible to adjust more tuning for inbound traffic ? We would like to achieve that there will be no inbound traffic via ISP-2.
>>By the way , in the next step of the configuration we would like to configure our multihomed BGP router with PBR & NBAR. What we are going to try with this is that for example p2p traffic from our subnet to the internet will be detected with NBAR and it will be forwarded to the ISP-2 connection with PBR and the return traffic of this connection will be come through the ISP-2 connection. (Symmetric traffic flow) How can be achive that ?
>
> Hi there,
>
> Maybe someone has better ideas, but here goes anyway;
>
> 1) If you prepend your AS various times towards ISP-2, the BGP best path selection should prefer the path with the shortest AS-PATH, and therefore use your ISP-1 connection.
> 2) If your ISP-2 has a policy of assigning a higher LOCAL PREFERENCE for prefixes originated from any of it's customers, all of the customers of ISP-2 (and the ISP-2 it self) will use ISP-2's connection to you by default. This is reasonable for ISP-2, as it would use it's own internal network to reach you.
>
> I'm not sure if ISP-2 would like to change this configuration, as it would inflict a higher usage of it's other peeringlinks, but asking doesn't hurt.. :)
>
> If you want certain traffic to use the ISP-2 link with PBR, you would need to make sure the traffic uses IP-addresses which are preferred on the ISP-link. If you don't know which source-addresses will need to use this link, but use NBAR to discover this, you'll have to use NAT'ing.
>
> A) Either get a pool of IP-addresses from ISP-2 (which will be preferred on ISP-2 anyway), or use a smaller prefix of your own addresses (and make sure they are preferred on the ISP-2 link, using the methods as cited above)
> B) Use PBR with NBAR to make the interesting traffic use the ISP-2-link and configure NAT'ing to the addresses you aquired in A).
>
> Best regards,
> Stig Meireles Johansen
> _______________________________________________
> cisco-nsp mailing 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 Mar 24 17:20:17 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Tue, 24 Mar 2009 22:20:17 +0100
Subject: [c-nsp] Needs some help with QOS
In-Reply-To: <1237923559.10614.102.camel@linux-2sym>
References: <1237834921.5059.36.camel@linux-2sym>
	<001901c9ac79$c548c270$0a00000a@nil.si>
	<Pine.GSO.4.64.0903241326240.24165@mono>
	<1237923559.10614.102.camel@linux-2sym>
Message-ID: <1237929617.4398.28.camel@localhost.localdomain>

On Tue, 2009-03-24 at 14:39 -0500, John Lange wrote:
> I followed the examples on that page but I'm not having any luck. As
> far as I can tell the queue is dropping at least some packets that it
> should be prioritizing (look for 582 below).
...
> policy-map parent_shaping
>  class class-default
>   shape average 128000
>   service-policy child_queueing
> 
> policy-map child_queueing
>  class cm-qos1
>   priority percent 70
> 
> interface FastEthernet4
>  service-policy output parent_shaping
...
>      Class-map: cm-qos1 (match-all)
>       3810 packets, 2978841 bytes
>       5 minute offered rate 71000 bps, drop rate 25000 bps
>       Match: access-group name al-qos1
>       Priority: 70% (89 kbps), burst bytes 2200, b/w exceed drops: 582

You only give priority to 89kbps, so if you try to force more traffic
through, the excess will of course be dropped when others use the
remaining bandwidth. The "5 minute offered rate" can never exceed the
configured rate, but it can easily land below. Or did you push traffic
through for more than five minutes?

Maybe the burst allowed in the shaping combined with a harder (less
buffered) limit on the WAN interface drops more packets than necessary?

>                                 As a side question, the file copy now
> seems to work much differently in that it does a big "burst" at the
> start of the copy and then "stalls". Is this a burst while the packet
> queue fills up?

Hmm... TCP should take care of finding the correct level. Is the stall
permanent, i.e. the connection is dropped? Or does it just take a long
break and then resume?

You could try playing with the burst size definitions with "priority
percent 70 <burst-size>". Default is 200 ms of burst, but that may not
suit the purpose. You could try lowering it a little and see if this
works better.

Regards,
Peter



From pshem.k at gmail.com  Tue Mar 24 19:15:58 2009
From: pshem.k at gmail.com (Pshem Kowalczyk)
Date: Wed, 25 Mar 2009 12:15:58 +1300
Subject: [c-nsp] ASR - modular image
Message-ID: <20fe625b0903241615v70cf555flbdafd93b33eef770@mail.gmail.com>

Hi,

We're considering getting some ASR (1004 and 1006) as peering routers.
I would like to know what sort of experience you had with them.
What are the advantages of running the 'modular' IOS XE? We tried the
'modular' software on 6500 and we ran into some issues that we didn't
have on the integrated one.
Should we expect something similar from the ASR platform?

regards
Pshem

From perc69 at gmail.com  Tue Mar 24 19:46:24 2009
From: perc69 at gmail.com (Per Carlson)
Date: Wed, 25 Mar 2009 00:46:24 +0100
Subject: [c-nsp] Needs some help with QOS
In-Reply-To: <1237923559.10614.102.camel@linux-2sym>
References: <1237834921.5059.36.camel@linux-2sym>
	<001901c9ac79$c548c270$0a00000a@nil.si>
	<Pine.GSO.4.64.0903241326240.24165@mono>
	<1237923559.10614.102.camel@linux-2sym>
Message-ID: <746ca6da0903241646g1d251399r983fe7eb0d1eef0a@mail.gmail.com>

Hi.

Which direction are you trying to prioritize? In the first post the
policy were on the Dialer0-interface (traffic from LAN towards DSL),
but in the last post it's on the Fa4-interface (traffic from DSL
towards LAN).

I assume it's the first one because there is less point shaping when
going from slow to fast interfaces. It also fit's better with the 128k
cap in the shaper. But as Peter sort of pointed out, 70% out of 128k
isn't much...

-- 
Pelle

From pshem.k at gmail.com  Tue Mar 24 19:59:46 2009
From: pshem.k at gmail.com (Pshem Kowalczyk)
Date: Wed, 25 Mar 2009 12:59:46 +1300
Subject: [c-nsp] ASR - modular image
In-Reply-To: <20fe625b0903241615v70cf555flbdafd93b33eef770@mail.gmail.com>
References: <20fe625b0903241615v70cf555flbdafd93b33eef770@mail.gmail.com>
Message-ID: <20fe625b0903241659t2b156d77x6c462d2103287f89@mail.gmail.com>

Hi,

Thank you for the off-list replies. I've read some more documentation
regarding the ASRs and I'm a bit unsure what the advantages of running
a sub-packaged image are. According to the Cisco website:

" Individual sub-package upgrades are atypical on the Cisco ASR 1000
Series Routers, because it is very rare to experience a case where a
single sub-package is upgraded without upgrading all the sub-packages
from the consolidated package. Individual sub-package upgrades are
most useful when only a single sub-package of an otherwise functioning
set of sub-packages requires an upgrade. "

which leaves me even more perplexed about the usefulness of the
'sub-packaged' version.

kind regards
Pshem


2009/3/25 Pshem Kowalczyk <pshem.k at gmail.com>:
> Hi,
>
> We're considering getting some ASR (1004 and 1006) as peering routers.
> I would like to know what sort of experience you had with them.
> What are the advantages of running the 'modular' IOS XE? We tried the
> 'modular' software on 6500 and we ran into some issues that we didn't
> have on the integrated one.
> Should we expect something similar from the ASR platform?
>
> regards
> Pshem
>

From andy.saykao at staff.netspace.net.au  Tue Mar 24 20:15:52 2009
From: andy.saykao at staff.netspace.net.au (Andy Saykao)
Date: Wed, 25 Mar 2009 11:15:52 +1100
Subject: [c-nsp] Question about CBWFQ and PING times
Message-ID: <56F211C5E3F24F47B103EA1B253822BE03654CAB@vic-cr-ex1.staff.netspace.net.au>

Hi All,
 
Two questions...
 
1/ We have a 200mb link between two POPS that is being congested in the
evening. Congestion is happening on the outbound direction from POP2 to
POP1, so from a user's perspective in GROUP1 it would be impacting their
download.
 
[GROUP1] --> [ POP1] <--> [POP2] --> [HOSTED SERVICES + INTERNET]
 
Users in GROUP1 traverse POP1 and POP2 to reach the Internet and hosted
services (eg: dns, web, etc). During periods of congestion, I would like
to ensure that users in GROUP1 have bandwidth readily available to
access our hosted services. To do this I have used CBWFQ and applied the
service-policy on the POP2 router in the outbound direction.
 
class-map match-all POP2-POP1-PRIORITY-CLASS
  match access-group name POP2-POP1-PRIORITY-ACL
!
policy-map POP2-POP1-QOS-POLICY
  class POP2-POP1-PRIORITY-CLASS
    bandwidth percent 5
  class class-default
    random-detect
!
ip access-list extended POP2-POP1-PRIORITY-ACL
 permit ip <DNS_SERVER_FARM> any
 permit ip <WEB_SERVER_FARM> any
!
interface GigabitEthernet4/0/2
 service-policy output POP2-POP1-QOS-POLICY

I can see matches for this when doing a show policy-map interface. Is it
as simple as this to ensure that users in GROUP1 will be assured of
bandwidth to access our hosted services?

2/ If I wanted to prioritze ping times between POP1 to POP2, how would
this be done? During non-congested periods, a ping from POP1 to POP2
will have a round trip time of less than 20ms. During congestion, this
jumps up to over 150ms. Can you prioritze the ping response so that
during congestion, the round trip times are still relatively low. I
tried permitting ICMP to the ACL above, but it didn't make any
difference to the ping time.
 
eg:
 
ip access-list extended POP2-POP1-PRIORITY-ACL
 permit ip <DNS_SERVER_FARM> any
 permit ip <WEB_SERVER_FARM> any
 permit icmp any any
 permit icmp any any echo-reply
 permit icmp any any traceroute

In desperation, I even tried putting everything into the LLQ, but no
change to the ping times. 
 
eg:
 
policy-map POP2-POP1-QOS-POLICY
  class POP2-POP1-PRIORITY-CLASS
    priority percent 5
  class class-default
    random-detect
 
I thought with the ping traffic being in the LLQ they would be serviced
first, but not so. Could it be that eventhough the ping packets are
being placed in the hardware queue before any other packets in the
software queues, they still have to wait their turn to be serviced while
in the hardware queue. So if there are already a lot of packets in the
hardware queue, the ping packets in there will suffer and just have to
wait their turn?? I'm just trying to understand the queuing mechanisms
between the hardware and software queues and whether there's a way to
prioritize ping times.
 
Any help with the two above scenarios would be greatly appreciated.
 
Thanks.
 
Andy

From peter at rathlev.dk  Tue Mar 24 21:37:43 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Wed, 25 Mar 2009 02:37:43 +0100
Subject: [c-nsp] Question about CBWFQ and PING times
In-Reply-To: <56F211C5E3F24F47B103EA1B253822BE03654CAB@vic-cr-ex1.staff.netspace.net.au>
References: <56F211C5E3F24F47B103EA1B253822BE03654CAB@vic-cr-ex1.staff.netspace.net.au>
Message-ID: <1237945063.6441.138.camel@localhost.localdomain>

Hi Andy,

On Wed, 2009-03-25 at 11:15 +1100, Andy Saykao wrote: 
> 1/ We have a 200mb link between two POPS that is being congested in the
> evening. Congestion is happening on the outbound direction from POP2 to
> POP1, so from a user's perspective in GROUP1 it would be impacting their
> download.
...
> interface GigabitEthernet4/0/2
>  service-policy output POP2-POP1-QOS-POLICY
> 
> I can see matches for this when doing a show policy-map interface. Is it
> as simple as this to ensure that users in GROUP1 will be assured of
> bandwidth to access our hosted services?

If you have a 200mbps connection going out from GigabitEthernet-link
your prioritising won't take effect, since buffers will never saturate.
Heirarchical QoS (as discussed thoroughly many times recently on this
list) with a parent shaper could solve this, but it is uncertain if your
platform can do this. What hardware and IOS version are you using?

Another possibility would be to police some of the traffic that causes
the congestion, which even the least feature rich switches with L3
features can do.

If you have some SRR-device (Catalyst 3560, 3750, some 6500 modules) you
could do some crude shaping, but the number of queues available often
makes this an interesting task and traffic limited this way could be an
unpleasant experience for the users.

> 2/ If I wanted to prioritze ping times between POP1 to POP2, how would
> this be done?

On a side note: Giving priority to ICMP Echo is in my eyes a bad
strategy. This is almost by definition not important business traffic,
so the main reason to give it higher priority would be to avoid
problematic questions from incompetent users who only know how to
measure latency and loss this way. It will not give them a better
experience in using the network connection itself and might instead hide
certain symptoms that could be helpful in troubleshooting one day.

Regards,
Peter



From andy.saykao at staff.netspace.net.au  Tue Mar 24 22:17:09 2009
From: andy.saykao at staff.netspace.net.au (Andy Saykao)
Date: Wed, 25 Mar 2009 13:17:09 +1100
Subject: [c-nsp] Question about CBWFQ and PING times
Message-ID: <56F211C5E3F24F47B103EA1B253822BE03654CAE@vic-cr-ex1.staff.netspace.net.au>

Hi Peter,

Thanks for the detailed reply. I forgot to include the router platforms
we are using for this.

[GROUP1] --> [ POP1] <--> [POP2] --> [HOSTED SERVICES + INTERNET]

POP1 = Cisco 7204VXR (NPE-G1) GigE Interface running 12.2(31)SB13

POP2 = Cisco 7606 with 4-subslot SPA Interface (7600-SIP-400) running
12.2(33)SRB3

1/ "If you have a 200mbps connection going out from GigabitEthernet-link
your prioritising won't take effect, since buffers will never saturate."
So if we were to prioritize something like Voice, we would need to
implement some Heirarchical QoS solution on the Cisco 7606???

2/ I understand your arguments exactly about not prioritizing ICMP
traffic, but I was told to look into this. I guess based on 1/ above,
some form of Heirarchical QoS solution is needed for this also.

Cheers.

Andy


-----Original Message-----
From: Peter Rathlev [mailto:peter at rathlev.dk] 
Sent: Wednesday, 25 March 2009 12:38 PM
To: Andy Saykao
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Question about CBWFQ and PING times

Hi Andy,

On Wed, 2009-03-25 at 11:15 +1100, Andy Saykao wrote: 
> 1/ We have a 200mb link between two POPS that is being congested in 
> the evening. Congestion is happening on the outbound direction from 
> POP2 to POP1, so from a user's perspective in GROUP1 it would be 
> impacting their download.
...
> interface GigabitEthernet4/0/2
>  service-policy output POP2-POP1-QOS-POLICY
> 
> I can see matches for this when doing a show policy-map interface. Is 
> it as simple as this to ensure that users in GROUP1 will be assured of

> bandwidth to access our hosted services?

If you have a 200mbps connection going out from GigabitEthernet-link
your prioritising won't take effect, since buffers will never saturate.
Heirarchical QoS (as discussed thoroughly many times recently on this
list) with a parent shaper could solve this, but it is uncertain if your
platform can do this. What hardware and IOS version are you using?

Another possibility would be to police some of the traffic that causes
the congestion, which even the least feature rich switches with L3
features can do.

If you have some SRR-device (Catalyst 3560, 3750, some 6500 modules) you
could do some crude shaping, but the number of queues available often
makes this an interesting task and traffic limited this way could be an
unpleasant experience for the users.

> 2/ If I wanted to prioritze ping times between POP1 to POP2, how would

> this be done?

On a side note: Giving priority to ICMP Echo is in my eyes a bad
strategy. This is almost by definition not important business traffic,
so the main reason to give it higher priority would be to avoid
problematic questions from incompetent users who only know how to
measure latency and loss this way. It will not give them a better
experience in using the network connection itself and might instead hide
certain symptoms that could be helpful in troubleshooting one day.

Regards,
Peter



______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

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 jimmy.changa007 at gmail.com  Tue Mar 24 22:32:12 2009
From: jimmy.changa007 at gmail.com (Jimmy Changa)
Date: Tue, 24 Mar 2009 22:32:12 -0400
Subject: [c-nsp] Cisco Guard and VRF-Lite
Message-ID: <7cf54880903241932i425282dfoae6b3d9f37dfdc0f@mail.gmail.com>

Good Afternoon,

I?m in the process of setting up a proof of concept on our network for the
Cisco Guard and Detector. I had them up and running for a small /28 test
zone (I?ve attached configs and diagrams) However, in thinking through fully
implementing this into production, I realized that I needed to support the
following:

? Divert only the attack destination IP - I have 4500 customer servers I
need to protect (yes, I know this will require more cards then I am
testing). Unfortunately, the previous networking folks didn?t believe in
proper IP provisioning, so instead of assigning aggregate blocks to
switches, they assigned blocks all over the place. So I need to build zones
based on our ARIN allocation (one per allocation), with the guard only
protecting the /32 under attack (subzones).
? Inject traffic to the correct next hop ? I?m not sure this is possible
unless the VRF is aware of the routes on my AGG switches. Can OSPF be
redistributed in to the VRF?

I would like to understand how best to make this a scalable solution. I
envisioned a dedicated 6500 chassis with several guard modules. This chassis
would do IBGP with GWY01, GWY02, GWY03, but how do I handle injecting
traffic to the next hop. I?m attempting to use a VRF and a GRE tunnel for my
test, but the injected traffic is not making its intended destination. I did
check to see if the /32 is being redistributed into my IGRP and it is not. I
also don?t see the /32 in the vrf instance.
-------------- next part --------------
GUARD01 Config

interface eth1
  ip address 10.10.191.42 255.255.255.252
  mtu 1500
  no shutdown
exit
interface giga2
  mtu 1500
  proxy 10.10.191.91
  proxy 10.10.191.92
  no shutdown
exit
interface giga2.50
  ip address 10.10.191.50 255.255.255.252
  mtu 1500
  no shutdown
exit
interface giga2.51
  ip address 10.10.191.90 255.255.255.248
  mtu 1500
  no shutdown
exit


default-gateway 10.10.191.41

diversion hijacking receive-via-vlan 50
diversion injection 0.0.0.0 0.0.0.0 nexthop 10.10.191.89


6500 - GWY03 Config

anomaly-guard module 9 port 1 allowed-vlan 10
anomaly-guard module 9 port 2 allowed-vlan 50,51
anomaly-guard module 9 port 1 native-vlan 10 
!
ip vrf GUARD-VRF
 rd 00088:1
 import ipv4 unicast map GRT2VRF
!
interface Tunnel1
 description [GUARD] Injection Tunnel - AGG01
 ip address 10.10.191.45 255.255.255.252
 tunnel source 10.10.191.226
 tunnel destination x.x.x.x
 !
interface Vlan50
 description [GUARD] Traffic Diversion Interface - GUARD01
 ip vrf forwarding GUARD-VRF
 ip address 10.10.191.49 255.255.255.252
!
interface Vlan51
 description [GUARD] Traffic Injection Interface - GUARD01
 ip vrf forwarding GUARD-VRF
 ip address 10.10.191.89 255.255.255.248
!
ip route vrf GUARD-VRF 0.0.0.0 0.0.0.0 XXX.XX.183.37 global ! ISP located on GWY03
ip route vrf GUARD-VRF 10.11.100.0 255.255.255.0 10.10.191.46 global
ip community-list standard RHI-INJECTED permit 00088:666
 !
route-map GRT2VRF permit 10
 match community RHI-INJECTED

!
route-map STATIC-ROUTES deny 5
 match ip address prefix-list Scatology
!
route-map STATIC-ROUTES permit 10
 match ip next-hop 50
 set community 00088:666
!
route-map STATIC-ROUTES permit 20
 match ip address prefix-list ISP-BlackedHole
 
 router bgp 00088
 !
 address-family ipv4
  redistribute static route-map STATIC-ROUTES
 exit-address-family
 !
 address-family ipv4 vrf GUARD-VRF
  no synchronization
 exit-address-family

From skeeve at eintellego.net  Tue Mar 24 22:39:39 2009
From: skeeve at eintellego.net (Skeeve Stevens)
Date: Wed, 25 Mar 2009 13:39:39 +1100
Subject: [c-nsp] Cisco 887 CPE and 890series?!?!?!?!?!
Message-ID: <292AF25E62B8894C921B893B53A19D97394469DF07@BUSINESSEX.business.ad>


Hey all,  I was just going to download the latest IOS for a Cisco 877 and below is the current list of 800 series routes on the Cisco website.

What caught my eye was the 3 entries for the Cisco 887 (887, 887W, 887SRSTW).

I was like "WHAT THE...." ??!?!?!?

Went to the product pages... nothing
Went to Google... nothing useful, especially from Cisco

Searching around I also came across the Cisco 890 series
http://www.cisco.com/en/US/prod/collateral/routers/ps380/qa_c67-520756_ps380_Products_Q_and_A_Item.html

Seriously!!!! This is the biggest tease I've ever had!  Anyone got any more information?

...Skeeve



Cisco 888 Integrated Services Router
Cisco 888SRST Integrated Services Router
Cisco 888SRSTW Integrated Services Router
Cisco 888W Integrated Services Router
Cisco 887 SRST Integrated Services Router
Cisco 887SRSTW Integrated Services Router
Cisco 887W Integrated Services Router
Cisco 881 Integrated Services Router
Cisco 881SRST Integrated Services Router
Cisco 881SRSTW Integrated Services Router
Cisco 881W Integrated Services Router
Cisco 878 Integrated Services Router
Cisco 877 Integrated Services Router
Cisco 876 Integrated Services Router
Cisco 871 Integrated Services Router
Cisco 861 Integrated Services Router
Cisco 861W Integrated Services Router
Cisco 857 Integrated Services Router
Cisco 851 Integrated Services Router
Cisco 837 ADSL Broadband Router
Cisco 836 ADSL over ISDN Broadband Router
Cisco 831 Ethernet Broadband Router
Cisco 815 Integrated Services Router




--
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
--
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 tseveendorj at gmail.com  Tue Mar 24 23:31:45 2009
From: tseveendorj at gmail.com (Tseveendorj)
Date: Wed, 25 Mar 2009 11:31:45 +0800
Subject: [c-nsp] about policy-map
Message-ID: <49C9A5A1.40706@gmail.com>

Hello,

Is it possible to use policy-map if the packet goes to specific IP address.

example:

If packet goes to subnet 192.168.0.0/24 then router  should use 
policy-map 512Kbps.

If packet goes to subnet any then router  should use policy-map 256Kbps.

How to do it with PPPoE.

Really appreciate for any help.

Sincerely,
Tseveen.

From gregariouspearl at gmail.com  Wed Mar 25 02:22:00 2009
From: gregariouspearl at gmail.com (Muhammad Salman Zahid)
Date: Wed, 25 Mar 2009 11:22:00 +0500
Subject: [c-nsp] about policy-map
In-Reply-To: <49C9A5A1.40706@gmail.com>
References: <49C9A5A1.40706@gmail.com>
Message-ID: <44c523750903242322j75f421f0r100c9be84925ce1b@mail.gmail.com>

ip access-list extended IP-Pool-Allowed
permit ip any 192.168.0.0 0.0.0.255
permit ip 192.168.0.0 0.0.0.255 any

ip access-list extended IP-All
permit ip any any


Class-map match-all IP-Pool-Allowed
match access-group name IP-Pool-Allowed

Class-map match-all IP-All
match access-group name IP-All

Policy-map PPPoE
class IP-All
police cir 256000 bc 16000 be 16000 conform-action set-dscp-transmit default
exceed-action drop violate-action drop
class IP-Pool-Allowed
police cir 512000 bc 16000 be 16000 conform-action set-dscp-transmit default
exceed-action drop violate-action drop

int [Name]
service-policy input PPPoE
Service-policy output PPP0E
*Note: This Policy can also be pushed via AAA Server.*
**
*MSZ*



On Wed, Mar 25, 2009 at 8:31 AM, Tseveendorj <tseveendorj at gmail.com> wrote:

> Hello,
>
> Is it possible to use policy-map if the packet goes to specific IP address.
>
> example:
>
> If packet goes to subnet 192.168.0.0/24 then router  should use policy-map
> 512Kbps.
>
> If packet goes to subnet any then router  should use policy-map 256Kbps.
>
> How to do it with PPPoE.
>
> Really appreciate for any help.
>
> Sincerely,
> Tseveen.
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>



-- 
"Death is no the greatest loss in life ....
The greatest loss is what dies inside
 you while U live...!"

From mohacsi at niif.hu  Wed Mar 25 04:22:14 2009
From: mohacsi at niif.hu (Mohacsi Janos)
Date: Wed, 25 Mar 2009 09:22:14 +0100 (CET)
Subject: [c-nsp] ASR - modular image
In-Reply-To: <20fe625b0903241615v70cf555flbdafd93b33eef770@mail.gmail.com>
References: <20fe625b0903241615v70cf555flbdafd93b33eef770@mail.gmail.com>
Message-ID: <alpine.BSF.2.00.0903250903240.3041@mignon.ki.iif.hu>




On Wed, 25 Mar 2009, Pshem Kowalczyk wrote:

> Hi,
>
> We're considering getting some ASR (1004 and 1006) as peering routers.
> I would like to know what sort of experience you had with them.
> What are the advantages of running the 'modular' IOS XE? We tried the
> 'modular' software on 6500 and we ran into some issues that we didn't
> have on the integrated one.
> Should we expect something similar from the ASR platform?

Dear Pshem,
 	We started to use ASR 1002 for WAN aggregation a while ago. We did 
not have much experience with it, but I share what we have:

- We started to use 'monolithic' IOS XE, but recently upgraded to 'modular' 
version. We expecting that IOS XE rebuilds, similar to 12.2(x)Tn, where n 
is the rebuild number,  does not require full reload of the router. We 
could not prove this yet, since not much rebuild exists for IOS XE. The 
full reload takes considerable more time than on 7200 or 7600.

- We wanted to implement QoS on virtual interface templates as we did on 
7200. This not supported yet.

- We wanted to implement IPv6 on PPPoE with this device. however Cisco 
claims the ASR 1000 series has IPv6 support, the IPv6 support exists only 
for bridged mode broadband solution. Development of few hundred lines of 
code is postponed  recently :(

- The device has more horse-power and potential capabilities than 7200 
with any NPE. It survived several DoS attacks, while 7200 died.

For summary, the ASR100 platform for WAN aggregation is quite ready yet, 
potentially it will be good in a year time.

Best Regards,
 		Janos Mohacsi


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

From jarruda-cnsp at jarruda.com  Wed Mar 25 05:31:55 2009
From: jarruda-cnsp at jarruda.com (Julio Arruda)
Date: Wed, 25 Mar 2009 05:31:55 -0400
Subject: [c-nsp] ASR - modular image
In-Reply-To: <alpine.BSF.2.00.0903250903240.3041@mignon.ki.iif.hu>
References: <20fe625b0903241615v70cf555flbdafd93b33eef770@mail.gmail.com>
	<alpine.BSF.2.00.0903250903240.3041@mignon.ki.iif.hu>
Message-ID: <49C9FA0B.4050302@jarruda.com>

Mohacsi Janos wrote:
> 
> 
> 
> On Wed, 25 Mar 2009, Pshem Kowalczyk wrote:
> 
>> Hi,
>>
>> We're considering getting some ASR (1004 and 1006) as peering routers.
>> I would like to know what sort of experience you had with them.
>> What are the advantages of running the 'modular' IOS XE? We tried the
>> 'modular' software on 6500 and we ran into some issues that we didn't
>> have on the integrated one.
>> Should we expect something similar from the ASR platform?
> 
> Dear Pshem,
>     We started to use ASR 1002 for WAN aggregation a while ago. We did 
> not have much experience with it, but I share what we have:
> 
> - We started to use 'monolithic' IOS XE, but recently upgraded to 
> 'modular' version. We expecting that IOS XE rebuilds, similar to 
> 12.2(x)Tn, where n is the rebuild number,  does not require full reload 
> of the router. We could not prove this yet, since not much rebuild 
> exists for IOS XE. The full reload takes considerable more time than on 
> 7200 or 7600.
> 
> - We wanted to implement QoS on virtual interface templates as we did on 
> 7200. This not supported yet.
> 
> - We wanted to implement IPv6 on PPPoE with this device. however Cisco 
> claims the ASR 1000 series has IPv6 support, the IPv6 support exists 
> only for bridged mode broadband solution. Development of few hundred 
> lines of code is postponed  recently :(
> 
> - The device has more horse-power and potential capabilities than 7200 
> with any NPE. It survived several DoS attacks, while 7200 died.

Interesting, the Control-plane in the IOS-XE, from what I understand, is 
not the legacy piece IOS, correct ? Is this better DDoS survival because 
of the raw CPU power being better, or because the attack was against a 
downstream customer ? The IP under attack was the router itself ? Or 
even better, it was some attack that would 'punt' traffic from the QFP 
to the Route processor ?


> 
> For summary, the ASR100 platform for WAN aggregation is quite ready yet, 
> potentially it will be good in a year time.
> 
> Best Regards,
>         Janos Mohacsi
> 
> 
>>
>> regards
>> Pshem
>> _______________________________________________
>> cisco-nsp mailing 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 mohacsi at niif.hu  Wed Mar 25 05:56:36 2009
From: mohacsi at niif.hu (Mohacsi Janos)
Date: Wed, 25 Mar 2009 10:56:36 +0100 (CET)
Subject: [c-nsp] ASR - modular image
In-Reply-To: <49C9FA0B.4050302@jarruda.com>
References: <20fe625b0903241615v70cf555flbdafd93b33eef770@mail.gmail.com>
	<alpine.BSF.2.00.0903250903240.3041@mignon.ki.iif.hu>
	<49C9FA0B.4050302@jarruda.com>
Message-ID: <alpine.BSF.2.00.0903251053330.3041@mignon.ki.iif.hu>




On Wed, 25 Mar 2009, Julio Arruda wrote:

>> 
>> - The device has more horse-power and potential capabilities than 7200 with 
>> any NPE. It survived several DoS attacks, while 7200 died.
>
> Interesting, the Control-plane in the IOS-XE, from what I understand, is not 
> the legacy piece IOS, correct ? Is this better DDoS survival because of the 
> raw CPU power being better, or because the attack was against a downstream 
> customer ? The IP under attack was the router itself ? Or even better, it was 
> some attack that would 'punt' traffic from the QFP to the Route processor ?

DoS attacks against the downstream customer. I would be interested in the 
mitigating possibilities for the other possibilities with ASR 1000.

Best Regards,
 		Janos Mohacsi

>> For summary, the ASR100 platform for WAN aggregation is quite ready yet, 
>> potentially it will be good in a year time.
>> 
>> Best Regards,
>>         Janos Mohacsi
>> 
>>

From p.mayers at imperial.ac.uk  Wed Mar 25 06:32:04 2009
From: p.mayers at imperial.ac.uk (Phil Mayers)
Date: Wed, 25 Mar 2009 10:32:04 +0000
Subject: [c-nsp] Blocking "bad users" based on MAC Address
In-Reply-To: <49C93E68.6040200@geneseo.edu>
References: <49C937B6.1080403@geneseo.edu>	<bd3771a60903241251v780a8fame719359ebeb7cec5@mail.gmail.com>
	<49C93E68.6040200@geneseo.edu>
Message-ID: <49CA0824.5080604@imperial.ac.uk>

Rick Coloccia wrote:
> oh, thank you, I see how direct and precise this is, and if I wanted
> to drop the person in several vlans, I assume I could  do
> 
> mac-address-table static 0016.6f99.9e61 vlan 3030 drop 
> mac-address-table static 0016.6f99.9e61 vlan 3010 drop 
> mac-address-table static 0016.6f99.9e61 vlan 3020 drop

Yes

> 
> but would that begin to be bad regarding how much impact that would
> have on the core itself? Is there a more appropriate way for me to do

They're just FDB entries.

> what I need as this scales, so when I have 4, 5, or 10 mac addresses
> I'm blocking on several vlans?

Some kind of MAC auth - so MAB to a radius server, or VMPS (avoid).

From jcartier at acs.on.ca  Wed Mar 25 08:11:20 2009
From: jcartier at acs.on.ca (Jeff Cartier)
Date: Wed, 25 Mar 2009 08:11:20 -0400
Subject: [c-nsp] QoS on Tunnel Interfaces w/ DSL
Message-ID: <BCD3E762F1767C42A5226BBACDE49BFBCE7ACD@loki.acs.local>

Greetings All,

 

I was wondering if anyone had any examples of how to impose QoS on a
Site that would be doing IPSec VPN tunnels to another site via a
standard DSL feed.

 

I'm curious to see if best-practice is to place the policy-shaping on
the interface tunnel and/or the Internet interface.

 

Thanks!

 


From clane1875 at gmail.com  Wed Mar 25 08:16:37 2009
From: clane1875 at gmail.com (Chris Lane)
Date: Wed, 25 Mar 2009 08:16:37 -0400
Subject: [c-nsp] CIsco3750ME Platform Crashing
Message-ID: <2e1cd850903250516u25d8867ci17b453a34bb4f29c@mail.gmail.com>

All,
Been running this IOS for over a year without errors, 12.2(37)SE1.
The only change to the device was changing one of the ES ports from access
to a trunk port. I have did one of the recommendations with this crash and
upgraded the IOS to: c3750me-i5k91-mz.122-46.SE.bin
Anyone here of this with these devices?

*Feb 28 16:01:47.038 PST: %PLATFORM-1-CRASHED: System previously crashed
with the following message:
*Feb 28 16:01:47.038 PST: %PLATFORM-1-CRASHED: Cisco IOS Software, C3750ME
Software (C3750ME-I5K91-M), Version 12.2(37)SE1, RELEASE SOFTWARE (fc1)
*Feb 28 16:01:47.038 PST: %PLATFORM-1-CRASHED: Copyright (c) 1986-2007 by
Cisco Systems, Inc.
*Feb 28 16:01:47.038 PST: %PLATFORM-1-CRASHED: Compiled Thu 05-Jul-07 23:20
by antonino
*Feb 28 16:01:47.038 PST: %PLATFORM-1-CRASHED:
*Feb 28 16:01:47.038 PST: %PLATFORM-1-CRASHED: Debug Exception (Could be
NULL pointer dereference) Exception (0x2000)!
*Feb 28 16:01:47.038 PST: %PLATFORM-1-CRASHED:
*Feb 28 16:01:47.038 PST: %PLATFORM-1-CRASHED: SRR0 = 0x0039EBA0  SRR1 =
0x00029230  SRR2 = 0x004E1D24  SRR3 = 0x00021000
*Feb 28 16:01:47.038 PST: %PLATFORM-1-CRASHED: ESR = 0x00000000  DEAR =
0x00000000  TSR = 0x8C000000  DBSR = 0x01000000
*Feb 28 16:01:47.038 PST: %PLATFORM-1-CRASHED:
*Feb 28 16:01:47.038 PST: %PLATFORM-1-CRASHED: CPU Register Context:
*Feb 28 16:01:47.038 PST: %PLATFORM-1-CRASHED: Vector = 0x00002000  PC =
0x01728A74  MSR = 0x00029230  CR = 0x33000009
*Feb 28 16:01:47.038 PST: %PLATFORM-1-CRASHED: LR = 0x01728A70  CTR =
0x00000000  XER = 0xE0000000
*Feb 28 16:01:47.038 PST: %PLATFORM-1-CRASHED: R0 = 0x01728A70  R1 =
0x04430C20  R2 = 0x00000000  R3 = 0x0404048C
*Feb 28 16:01:47.038 PST: %PLATFORM-1-CRASHED: R4 = 0x04430C0E  R5 =
0x00000000  R6 = 0x00029230  R7 = 0xBEEFCAFE
*Feb 28 16:01:47.038 PST: %PLATFORM-1-CRASHED: R8 = 0x00000000  R9 =
0x04430C0D  R10 = 0x04440FAE  R11 = 0x04440FAD
*Feb 28 16:01:47.038 PST: %PLATFORM-1-CRASHED: R12 = 0x06107304  R13 =
0x00110000  R14 = 0x0172002C  R15 = 0x00000000
*Feb 28 16:01:47.038 PST: %PLATFORM-1-CRASHED: R16 = 0x00000000  R17 =
0x00000000  R18 = 0x00000000  R19 = 0x00000000
*Feb 28 16:01:47.038 PST: %PLATFORM-1-CRASHED: R20 = 0x00000000  R21 =
0x00000000  R22 = 0x00000000  R23 = 0x00000000
*Feb 28 16:01:47.038 PST: %PLATFORM-1-CRASHED: R24 = 0x00000000  R25 =
0x00000000  R26 = 0x00000000  R27 = 0x00000000
*Feb 28 16:01:47.038 PST: %PLATFORM-1-CRASHED: R28 = 0x0403FA04  R29 =
0x0404048C  R30 = 0x00000000  R31 = 0x0404048C
*Feb 28 16:01:47.038 PST: %PLATFORM-1-CRASHED:
*Feb 28 16:01:47.038 PST: %PLATFORM-1-CRASHED: Stack trace:
*Feb 28 16:01:47.038 PST: %PLATFORM-1-CRASHED: PC = 0x01728A74, SP =
0x04430C20
*Feb 28 16:01:47.038 PST: %PLATFORM-1-CRASHED: Frame 00: SP = 0x04430C30
 PC = 0x01728A70
*Feb 28 16:01:47.038 PST: %PLATFORM-1-CRASHED: Frame 01: SP = 0x04430C60
 PC = 0x0171D1F4
*Feb 28 16:01:47.038 PST: %PLATFORM-1-CRASHED: Frame 02: SP = 0x04430C88
 PC = 0x00216D28
*Feb 28 16:01:47.038 PST: %PLATFORM-1-CRASHED: Frame 03: SP = 0x04430CA8
 PC = 0x0172034C
*Feb 28 16:01:47.038 PST: %PLATFORM-1-CRASHED: Frame 04: SP = 0x04430CB0
 PC = 0x003AE81C
*Feb 28 16:01:47.038 PST: %PLATFORM-1-CRASHED: Frame 05: SP = 0x00000000
 PC = 0x003A5BE4
*Feb 28 16:01:47.038 PST: %PLATFORM-1-CRASHED:

Regards,Chris
-- 
//CL

From ardabalkanay at gmail.com  Wed Mar 25 08:21:46 2009
From: ardabalkanay at gmail.com (Arda Balkanay)
Date: Wed, 25 Mar 2009 14:21:46 +0200
Subject: [c-nsp] BGP - Multihoming
In-Reply-To: <c93a55220903141734m532f8489m88623b5d1cd89556@mail.gmail.com>
References: <d9281f5c0903141613v1c165fd7y18077b5ec1609bdf@mail.gmail.com>
	<5EB9799F396A304686962AFFF740ED0CE9C50383@NOOSLEXCH001.adno.local>
	<c93a55220903141734m532f8489m88623b5d1cd89556@mail.gmail.com>
Message-ID: <9af987420903250521t6b45263dr1a9b60c8142abda@mail.gmail.com>

I also aggree with Stig,
If you want to use ISP-2 as a backup of ISP-1 and because of local-pref or
similar config of ISP-2 you see inbound traffic; you can announce more
specific routes towards ISP-1 to break local-pref.
You have a /16. just advertise two /17s and a /16(just for backup) to ISP-1
and advertise the /16 to ISP-2.
ISP-2 would choose /17s and send traffic across ISP-1.
Kind Regards
Arda



On Sun, Mar 15, 2009 at 2:34 AM, Christian Koch <christian at broknrobot.com>wrote:

> I'd agree with Stig's suggestions and his assumption about the local
> pref is probably correct. I'd also suggest you check if your SP's have
> defined communities to send in order to alter attributes of the
> prefixes you are sending.
>
>
> On Sat, Mar 14, 2009 at 5:07 PM, Stig Johansen <Stig.Johansen at atea.no>
> wrote:
> > Burak Dikici wrote:
> >>I would like consult some subject about BGP to the experienced BGP users.
> We are making a BGP connection to a two different ISPs via central site
> router.
> >>We are announcing our subnet via ISP-1 normally , but for ISP2 we are
> announcing the subnet with AS path prepending configuration. As a result ,
> we still see inbound traffic from internet to our subnet via ISP-2. Is that
> possible to adjust more tuning for inbound traffic ? We would like to
> achieve that there will be no inbound traffic via ISP-2.
> >>By the way , in the next step of the configuration we would like to
> configure our multihomed BGP router with PBR & NBAR. What we are going to
> try with this is that for example p2p traffic from our subnet to the
> internet will be detected with NBAR and it will be forwarded to the ISP-2
> connection with PBR and the return traffic of this connection will be come
> through the ISP-2 connection. (Symmetric traffic flow) How can be achive
> that ?
> >
> > Hi there,
> >
> > Maybe someone has better ideas, but here goes anyway;
> >
> > 1) If you prepend your AS various times towards ISP-2, the BGP best path
> selection should prefer the path with the shortest AS-PATH, and therefore
> use your ISP-1 connection.
> > 2) If your ISP-2 has a policy of assigning a higher LOCAL PREFERENCE for
> prefixes originated from any of it's customers, all of the customers of
> ISP-2 (and the ISP-2 it self) will use ISP-2's connection to you by default.
> This is reasonable for ISP-2, as it would use it's own internal network to
> reach you.
> >
> > I'm not sure if ISP-2 would like to change this configuration, as it
> would inflict a higher usage of it's other peeringlinks, but asking doesn't
> hurt.. :)
> >
> > If you want certain traffic to use the ISP-2 link with PBR, you would
> need to make sure the traffic uses IP-addresses which are preferred on the
> ISP-link. If you don't know which source-addresses will need to use this
> link, but use NBAR to discover this, you'll have to use NAT'ing.
> >
> > A) Either get a pool of IP-addresses from ISP-2 (which will be preferred
> on ISP-2 anyway), or use a smaller prefix of your own addresses (and make
> sure they are preferred on the ISP-2 link, using the methods as cited above)
> > B) Use PBR with NBAR to make the interesting traffic use the ISP-2-link
> and configure NAT'ing to the addresses you aquired in A).
> >
> > Best regards,
> > Stig Meireles Johansen
> > _______________________________________________
> > cisco-nsp mailing 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 Mar 25 08:46:56 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Wed, 25 Mar 2009 13:46:56 +0100
Subject: [c-nsp] Question about CBWFQ and PING times
In-Reply-To: <56F211C5E3F24F47B103EA1B253822BE03654CAE@vic-cr-ex1.staff.netspace.net.au>
References: <56F211C5E3F24F47B103EA1B253822BE03654CAE@vic-cr-ex1.staff.netspace.net.au>
Message-ID: <1237985216.11010.14.camel@localhost.localdomain>

On Wed, 2009-03-25 at 13:17 +1100, Andy Saykao wrote:
> POP1 = Cisco 7204VXR (NPE-G1) GigE Interface running 12.2(31)SB13
> 
> POP2 = Cisco 7606 with 4-subslot SPA Interface (7600-SIP-400) running
> 12.2(33)SRB3
> 
> 1/ "If you have a 200mbps connection going out from GigabitEthernet-link
> your prioritising won't take effect, since buffers will never saturate."
> So if we were to prioritize something like Voice, we would need to
> implement some Heirarchical QoS solution on the Cisco 7606???

Generally speaking: Yes. When the scheduler needs to figure out if there
is bandwidth enough for non-priority traffic it needs to know how much
bandwidth is available. You need to tell the router that it only has 200
mbps and not the full 1 Gbps. Otherwise it will allocate ~50 mbps (your
5%) for priority traffic and ~950 mbps for class-default.

AFAIK both the SIP-400 and the G1 should be able to shape an interface
this way, but I could be wrong. :-)

> 2/ I understand your arguments exactly about not prioritizing ICMP
> traffic, but I was told to look into this. I guess based on 1/ above,
> some form of Heirarchical QoS solution is needed for this also.

Yes, you just need to wrap a shaping parent policy around your existing
"POP2-POP1-QOS-POLICY" policy.

Regards,
Peter



From biged7600 at gmail.com  Wed Mar 25 09:51:33 2009
From: biged7600 at gmail.com (James Edmondson)
Date: Wed, 25 Mar 2009 08:51:33 -0500
Subject: [c-nsp] Multichassis Multilink PPP
Message-ID: <d35a6baf0903250651y1acf5a28we4c57b6026be6da2@mail.gmail.com>

Question for the pros.

Need advise on having multiple (2 right now and separate carriers, 6 in the
future) T1's spread across two 7606 routers acting as one logical pipe.

7606----
    |         ------- (WAN) ----   Router
7606----
Looking for redundancy of T1 circuits across two physical routers, Is MCMMP
the answer, GLBP, or HSRP with multilink?

Your suggestions are welcome.  Thank you in advance.
-- 
James

From harbor235 at gmail.com  Wed Mar 25 10:51:06 2009
From: harbor235 at gmail.com (harbor235)
Date: Wed, 25 Mar 2009 10:51:06 -0400
Subject: [c-nsp] network management
Message-ID: <836bf1f90903250751j206ade9fyd1c3fe61ed47d3d9@mail.gmail.com>

I am looking to gather information on what metrics NOCs collect for a tier 2
, tier 3 personnel for WAN status and performance monitoring.

I feel the following are useful, any additional info on beneficial metrics
will be helpful.

Interface/Node availability
latency/jitter on major network paths as well as other requested links
(define threshholds for nominal, impacted, severly impacted)
overall WAN availbility
network path availability
interface utilizations (thresholds defined)
top sources (netflow,sflow)
top As        (netflow,sflow)
top talkers   (netflow,sflow)
packet loss (how is packet loss done, is it done from a probing perspective
or collecting interace stats?)


Just off the top of my head, i am looking to quantify/identify a well
perfroming network as well a problem network.

mike

From paul.cosgrove at heanet.ie  Wed Mar 25 11:54:33 2009
From: paul.cosgrove at heanet.ie (Paul Cosgrove)
Date: Wed, 25 Mar 2009 15:54:33 +0000
Subject: [c-nsp] BGP session resets if NLRI exchanged
Message-ID: <49CA53B9.5080404@heanet.ie>

We are attempting to establish a new BGP session between one of our 
CRS-1 routers, and a Redback SE800 router owned by another provider.  Am 
not familiar with Redbacks myself and we have not peered with any before 
(as far as we know anyway).  The BGP session only remains up if no NLRI 
is exchanged.  If the other provider sends any prefixes to us we reply 
with a "invalid length for attribute" notification; if we send any 
prefixes to them they reply with  "invalid or corrupt AS path". 

The other provider uses VPNv4 within their network, though I understand 
that it is not configured on this peering.  I'm wondering whether these 
errors could result if their router expects a RD (and sends one) on the 
advertisements, perhaps due to a software bug or typo in the config. 

Perhaps someone has seen this problem before?

Paul.






From psirt at cisco.com  Wed Mar 25 12:00:00 2009
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Wed, 25 Mar 2009 17:00:00 +0100
Subject: [c-nsp] Cisco Security Advisory: Cisco IOS Software Mobile IP and
	Mobile IPv6 Vulnerabilities
Message-ID: <200903251705.mobileip@psirt.cisco.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cisco Security Advisory: Cisco IOS Software Mobile IP and Mobile IPv6
Vulnerabilities

Advisory ID: cisco-sa-20090325-mobileip

http://www.cisco.com/warp/public/707/cisco-sa-20090325-mobileip.shtml

Revision 1.0

For Public Release 2009 March 25 1600 UTC (GMT)

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

Summary
=======

Devices that are running Cisco IOS Software and configured for Mobile
IP Network Address Translation (NAT) Traversal feature or Mobile IPv6
are vulnerable to a denial of service (DoS) attack that may result in
a blocked interface.

Cisco has released free software updates that address these
vulnerabilities.

This advisory is posted at the following link 
http://www.cisco.com/warp/public/707/cisco-sa-20090325-mobileip.shtml

Note: The March 25, 2009, Cisco IOS Security Advisory bundled
publication includes eight Security Advisories. All of the advisories
address vulnerabilities in Cisco IOS Software. Each advisory lists
the releases that correct the vulnerability or vulnerabilities in the
advisory. The following table lists releases that correct all Cisco
IOS Software vulnerabilities that have been published in Cisco
Security Advisories on March 25, 2009, or earlier.

http://www.cisco.com/warp/public/707/cisco-sa-20090325-bundle.shtml

Individual publication links are listed below:

  * Cisco IOS cTCP Denial of Service Vulnerability
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-ctcp.shtml

  * Cisco IOS Software Multiple Features IP Sockets Vulnerability
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-ip.shtml

  * Cisco IOS Software Mobile IP and Mobile IPv6 Vulnerabilities
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-mobileip.shtml

  * Cisco IOS Software Secure Copy Privilege Escalation Vulnerability
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-scp.shtml

  * Cisco IOS Software Session Initiation Protocol Denial of Service
    Vulnerability
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-sip.shtml

  * Cisco IOS Software Multiple Features Crafted TCP Sequence
    Vulnerability
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-tcp.shtml

  * Cisco IOS Software Multiple Features Crafted UDP Packet
    Vulnerability
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-udp.shtml

  * Cisco IOS Software WebVPN and SSLVPN Vulnerabilities
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-webvpn.shtml

Affected Products
=================

Devices that are running an affected version of Cisco IOS Software
and configured for Mobile IP NAT Traversal feature or Mobile IPv6 are
vulnerable.

Vulnerable Products
+------------------

Devices running Cisco IOS Software and configured for Mobile IP NAT
Traversal feature will have a line similar to the following in the
output of the show running-config command:

    ip mobile home-agent nat traversal [...]

or

    ip mobile foreign-agent nat traversal [...]

or

    ip mobile router-service collocated registration nat traversal [...]

Devices running Cisco IOS Software and configured for Mobile IPv6
will have a line similar to the following in the output of the show
running-config command:

    ipv6 mobile home-agent

To determine the Cisco IOS Software release that is running on a
Cisco product, administrators can log in to the device and issue the
show version command to display the system banner. The system banner
confirms that the device is running Cisco IOS Software by displaying
text similar to "Cisco Internetwork Operating System Software" or
"Cisco IOS Software." The image name displays in parentheses,
followed by "Version" and the Cisco IOS Software release name. Other
Cisco devices do not have the show version command or may provide
different output.

The following example identifies a Cisco product that is running
Cisco IOS Software Release 12.3(26) with an installed image name of
C2500-IS-L:

        Router#show version
        Cisco Internetwork Operating System Software
        IOS (tm) 2500 Software (C2500-IS-L), Version 12.3(26), RELEASE SOFTWARE (fc2)
        Technical Support: http://www.cisco.com/techsupport
        Copyright (c) 1986-2008 by cisco Systems, Inc.
        Compiled Mon 17-Mar-08 14:39 by dchih
        !--- output truncated


The following example identifies a Cisco product that is running
Cisco IOS Software Release 12.4(20)T with an installed image name of
C1841-ADVENTERPRISEK9-M:

        Router#show version
        Cisco IOS Software, 1841 Software (C1841-ADVENTERPRISEK9-M), Version 12.4(20)T, RELEASE SOFTWARE (fc3)
        Technical Support: http://www.cisco.com/techsupport
        Copyright (c) 1986-2008 by Cisco Systems, Inc.
        Compiled Thu 10-Jul-08 20:25 by prod_rel_team
        !--- output truncated


Additional information about Cisco IOS Software release naming
conventions is available in "White Paper: Cisco IOS Reference Guide"
at the following link: http://www.cisco.com/warp/public/620/1.html

Products Confirmed Not Vulnerable
+--------------------------------

Cisco IOS XR is not affected by these vulnerabilities.

Cisco IOS XE is not affected by these vulnerabilities.

No other Cisco products are currently known to be affected by these
vulnerabilities.

Details
=======

Mobile IP is part of both IPv4 and IPv6 standards. Mobile IP allows a
host device to be identified by a single IP address even though the
device may move its physical point of attachment from one network to
another. Regardless of movement between different networks,
connectivity at the different points is achieved seamlessly without
user intervention. Roaming from a wired network to a wireless or
wide-area network is also possible.

More information on Mobile IPv6 can be found at the following link:
http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-mobile.html

The Mobile IP Support NAT Traversal feature is documented in RFC
3519. It introduces an alternative method for tunneling Mobile IP
data traffic. New extensions in the Mobile IP registration request
and reply messages have been added for establishing User Datagram
Protocol (UDP) tunneling. This feature allows mobile devices in
collocated mode that use a private IP address (RFC 1918) or foreign
agents (FAs) that use a private IP address for the care-of address
(CoA) to establish a tunnel and traverse a NAT-enabled router with
mobile node (MN) data traffic from the home agent (HA).

More information on Mobile IP NAT Traversal feature can be found at
the following link: 
http://www.cisco.com/en/US/docs/ios/12_3t/12_3t8/feature/guide/gtnatmip.html

Devices that are running an affected version of Cisco IOS Software
and configured for Mobile IPv6 or Mobile IP NAT Traversal feature are
affected by a DoS vulnerability. A successful exploitation of this
vulnerability could cause an interface to stop processing traffic
until the system is restarted. Offending packets need to be destined
to the router for a successful exploit.

These vulnerabilities are documented in the Cisco Bug IDs CSCsm97220 
and CSCso05337 and have been assigned Common Vulnerabilities and 
Exposures (CVE) IDs CVE-2009-0633 and CVE-2009-0634.

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

CSCsm97220 - Input queue wedged by MIPv6 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

CSCso05337 - HA: Input queue wedged by ICMP packet

CVSS Base Score - 7.1

 Access Vector           - Network
 Access Complexity       - Medium
 Authentication          - None
 Confidentiality Impact  - None
 Integrity Impact        - None
 Availability Impact     - Complete

CVSS Temporal Score - 5.9

 Exploitability	         - Functional
 Remediation Level       - Official-Fix
 Report Confidence       - Confirmed

Impact
======

Successful exploitation of the vulnerability may result in an
interface to stop processing traffic, causing a DoS condition.

Software Versions and Fixes
===========================

When considering software upgrades, also consult 
http://www.cisco.com/go/psirt and any subsequent advisories to 
determine exposure and a complete upgrade solution.

In all cases, customers should exercise caution to be certain the
devices to be upgraded contain sufficient memory and that current
hardware and software configurations will continue to be supported
properly by the new release. If the information is not clear, contact
the Cisco Technical Assistance Center (TAC) or your contracted
maintenance provider for assistance.

Each row of the Cisco IOS software table (below) names a Cisco IOS
release train. If a given release train is vulnerable, then the
earliest possible releases that contain the fix (along with the
anticipated date of availability for each, if applicable) are listed
in the "First Fixed Release" column of the table. The "Recommended
Release" column indicates the releases which have fixes for all the
published vulnerabilities at the time of this Advisory. A device
running a release in the given train that is earlier than the release
in a specific column (less than the First Fixed Release) is known to
be vulnerable. Cisco recommends upgrading to a release equal to or
later than the release in the "Recommended Releases" column of the
table.

+-------------------------------------------------------------------+
|   Major    |          Availability of Repaired Releases           |
|  Release   |                                                      |
|------------+------------------------------------------------------|
| Affected   |                                      | Recommended   |
| 12.0-Based | First Fixed Release                  | Release       |
| Releases   |                                      |               |
|-------------------------------------------------------------------|
| There are no affected 12.0 based releases                         |
|-------------------------------------------------------------------|
| Affected   |                                      | Recommended   |
| 12.1-Based | First Fixed Release                  | Release       |
| Releases   |                                      |               |
|-------------------------------------------------------------------|
| There are no affected 12.1 based releases                         |
|-------------------------------------------------------------------|
| Affected   |                                      | Recommended   |
| 12.2-Based | First Fixed Release                  | Release       |
| Releases   |                                      |               |
|-------------------------------------------------------------------|
| There are no affected 12.2 based releases                         |
|-------------------------------------------------------------------|
| Affected   |                                      | Recommended   |
| 12.3-Based | First Fixed Release                  | Release       |
| Releases   |                                      |               |
|------------+--------------------------------------+---------------|
| 12.3       | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3B      | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3BC     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3BW     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3EU     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3JA     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3JEA    | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3JEB    | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3JEC    | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3JK     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3JL     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3JX     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(22)T1    |
|            |                                      |               |
| 12.3T      | Vulnerable; first fixed in 12.4T     | 12.4(15)T9;   |
|            |                                      | Available on  |
|            |                                      | 29-APR-2009   |
|------------+--------------------------------------+---------------|
| 12.3TPC    | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3VA     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3XA     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3XB     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3XC     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3XD     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3XE     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3XF     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3XG     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3XI     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3XJ     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3XK     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3XL     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3XQ     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3XR     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3XS     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3XU     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3XW     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3XX     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3XY     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3XZ     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3YA     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3YD     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3YF     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3YG     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3YH     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3YI     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3YJ     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            | Releases prior to 12.3(11)YK3 are    | 12.4(22)T1    |
|            | vulnerable, release 12.3(11)YK3 and  |               |
| 12.3YK     | later are not vulnerable; first      | 12.4(15)T9;   |
|            | fixed in 12.4T                       | Available on  |
|            |                                      | 29-APR-2009   |
|------------+--------------------------------------+---------------|
| 12.3YM     | 12.3(14)YM13                         | 12.3(14)YM13  |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(22)T1    |
|            |                                      |               |
| 12.3YQ     | Vulnerable; first fixed in 12.4T     | 12.4(15)T9;   |
|            |                                      | Available on  |
|            |                                      | 29-APR-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(22)T1    |
|            |                                      |               |
| 12.3YS     | Vulnerable; first fixed in 12.4T     | 12.4(15)T9;   |
|            |                                      | Available on  |
|            |                                      | 29-APR-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(22)T1    |
|            |                                      |               |
| 12.3YT     | Vulnerable; first fixed in 12.4T     | 12.4(15)T9;   |
|            |                                      | Available on  |
|            |                                      | 29-APR-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(22)T1    |
|            |                                      |               |
| 12.3YU     | Vulnerable; migrate to 12.4T         | 12.4(15)T9;   |
|            |                                      | Available on  |
|            |                                      | 29-APR-2009   |
|------------+--------------------------------------+---------------|
|            | Releases prior to 12.3(14)YX10 are   |               |
| 12.3YX     | vulnerable, release 12.3(14)YX10 and | 12.3(14)YX14  |
|            | later are not vulnerable;            |               |
|------------+--------------------------------------+---------------|
| 12.3YZ     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3ZA     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| Affected   |                                      | Recommended   |
| 12.4-Based | First Fixed Release                  | Release       |
| Releases   |                                      |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(18e)     |
|            | 12.4(18e)                            |               |
| 12.4       |                                      | 12.4(23a);    |
|            | 12.4(23a); Available on 30-APR-2009  | Available on  |
|            |                                      | 30-APR-2009   |
|------------+--------------------------------------+---------------|
| 12.4JA     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.4JDA    | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.4JK     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.4JL     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.4JMA    | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.4JMB    | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.4JX     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.4MD     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.4MR     | 12.4(19)MR                           | 12.4(19)MR2   |
|------------+--------------------------------------+---------------|
| 12.4SW     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            | 12.4(20)T                            | 12.4(22)T1    |
|            |                                      |               |
| 12.4T      | 12.4(15)T8                           | 12.4(15)T9;   |
|            |                                      | Available on  |
|            | 12.4(15)T9; Available on 29-APR-2009 | 29-APR-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(22)T1    |
|            |                                      |               |
| 12.4XA     | Vulnerable; first fixed in 12.4T     | 12.4(15)T9;   |
|            |                                      | Available on  |
|            |                                      | 29-APR-2009   |
|------------+--------------------------------------+---------------|
|            | 12.4(15)T8                           | 12.4(22)T1    |
|            |                                      |               |
| 12.4XB     | 12.4(20)T                            | 12.4(15)T9;   |
|            |                                      | Available on  |
|            | 12.4(15)T9; Available on 29-APR-2009 | 29-APR-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(22)T1    |
|            |                                      |               |
| 12.4XC     | Vulnerable; first fixed in 12.4T     | 12.4(15)T9;   |
|            |                                      | Available on  |
|            |                                      | 29-APR-2009   |
|------------+--------------------------------------+---------------|
|            | 12.4(4)XD12; Available on            | 12.4(4)XD12;  |
| 12.4XD     | 27-MAR-2009                          | Available on  |
|            |                                      | 27-MAR-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(22)T1    |
|            |                                      |               |
| 12.4XE     | Vulnerable; first fixed in 12.4T     | 12.4(15)T9;   |
|            |                                      | Available on  |
|            |                                      | 29-APR-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(22)T1    |
|            |                                      |               |
| 12.4XF     | Vulnerable; first fixed in 12.4T     | 12.4(15)T9;   |
|            |                                      | Available on  |
|            |                                      | 29-APR-2009   |
|------------+--------------------------------------+---------------|
| 12.4XG     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(22)T1    |
|            |                                      |               |
| 12.4XJ     | Vulnerable; first fixed in 12.4T     | 12.4(15)T9;   |
|            |                                      | Available on  |
|            |                                      | 29-APR-2009   |
|------------+--------------------------------------+---------------|
| 12.4XK     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.4XL     | 12.4(15)XL4                          | 12.4(15)XL4   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(22)T1    |
|            |                                      |               |
| 12.4XM     | Vulnerable; first fixed in 12.4T     | 12.4(15)T9;   |
|            |                                      | Available on  |
|            |                                      | 29-APR-2009   |
|------------+--------------------------------------+---------------|
| 12.4XN     | Vulnerable; contact TAC              |               |
|------------+--------------------------------------+---------------|
| 12.4XP     | Vulnerable; contact TAC              |               |
|------------+--------------------------------------+---------------|
| 12.4XQ     | 12.4(15)XQ2                          | 12.4(15)XQ2   |
|------------+--------------------------------------+---------------|
| 12.4XR     | 12.4(15)XR4                          | 12.4(22)T1    |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(22)T1    |
|            |                                      |               |
| 12.4XT     | Vulnerable; first fixed in 12.4T     | 12.4(15)T9;   |
|            |                                      | Available on  |
|            |                                      | 29-APR-2009   |
|------------+--------------------------------------+---------------|
| 12.4XV     | Vulnerable; contact TAC              |               |
|------------+--------------------------------------+---------------|
| 12.4XW     | 12.4(11)XW10                         | 12.4(11)XW10  |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(22)T1    |
|            |                                      |               |
| 12.4XY     | 12.4(15)XY4                          | 12.4(15)T9;   |
|            |                                      | Available on  |
|            |                                      | 29-APR-2009   |
|------------+--------------------------------------+---------------|
| 12.4XZ     | 12.4(15)XZ1                          | 12.4(15)XZ2   |
|------------+--------------------------------------+---------------|
| 12.4YA     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.4YB     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.4YD     | Not Vulnerable                       |               |
+-------------------------------------------------------------------+

Workarounds
===========

The following mitigation and identification methods have been
identified for these vulnerabilities:

Infrastructure Access Control Lists
+----------------------------------

Although it is often difficult to block traffic that transits a
network, it is possible to identify traffic that should never be
allowed to target infrastructure devices and block that traffic at
the border of networks. Infrastructure Access Control Lists (iACLs)
are a network security best practice and should be considered as a
long-term addition to good network security as well as a workaround
for these specific vulnerabilities. The iACL example below should be
included as part of the deployed infrastructure access-list which
will protect all devices with IP addresses in the infrastructure IP
address range:

IPv4 example:


    !--- Anti-spoofing entries are shown here.

    !--- Deny special-use address sources.
    !--- Refer to RFC 3330 for additional special use addresses.

    access-list 110 deny ip host 0.0.0.0 any
    access-list 110 deny ip 127.0.0.0 0.255.255.255 any
    access-list 110 deny ip 192.0.2.0 0.0.0.255 any
    access-list 110 deny ip 224.0.0.0 31.255.255.255 any

    !--- Filter RFC 1918 space.

    access-list 110 deny ip 10.0.0.0 0.255.255.255 any
    access-list 110 deny ip 172.16.0.0 0.15.255.255 any
    access-list 110 deny ip 192.168.0.0 0.0.255.255 any

    !--- Deny your space as source from entering your AS.
    !--- Deploy only at the AS edge.

    access-list 110 deny ip YOUR_CIDR_BLOCK any

    !--- Permit BGP.

    access-list 110 permit tcp host bgp_peer host router_ip eq bgp
    access-list 110 permit tcp host bgp_peer eq bgp host router_ip

    !--- Deny access to internal infrastructure addresses.

    access-list 110 deny ip any INTERNAL_INFRASTRUCTURE_ADDRESSES

    !--- Permit transit traffic.

    access-list 110 permit ip any any

IPv6 example:


    !--- Configure the access-list.

    ipv6 access-list iacl

    !--- Deny your space as source from entering your AS.
    !--- Deploy only at the AS edge.

    deny ipv6 YOUR_CIDR_BLOCK_IPV6 any

    !--- Permit multiprotocol BGP.

    permit tcp host bgp_peer_ipv6 host router_ipv6 eq bgp
    permit tcp host bgp_peer_ipv6 eq bgp host router_ipv6

    !--- Deny access to internal infrastructure addresses.

    deny ipv6 any INTERNAL_INFRASTRUCTURE_ADDRESSES_IPV6

    !--- Permit transit traffic.

    permit ipv6 any any

The white paper entitled "Protecting Your Core: Infrastructure
Protection Access Control Lists" presents guidelines and recommended
deployment techniques for infrastructure protection access lists.
This white paper can be obtained at the following link 
http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801a1a55.shtml

Cisco IOS Embedded Event Manager
+-------------------------------

It is possible to detect blocked interface queues with a Cisco IOS
Embedded Event Manager (EEM) policy. EEM provides event detection and
reaction capabilities on a Cisco IOS device. EEM can alert
administrators of blocked interfaces with email, a syslog message, or
a Simple Network Management Protocol (SNMP) trap.

A sample EEM policy that uses syslog to alert administrators of
blocked interfaces is available at Cisco Beyond, an online community
dedicated to EEM. A sample script is available at the following link:

http://forums.cisco.com/eforum/servlet/EEM?page=eem&fn=script&scriptId=981

More information about EEM is available from Cisco.com at the
following link: 
http://www.cisco.com/en/US/products/ps6815/products_ios_protocol_group_home.html

Obtaining Fixed Software
========================

Cisco has released free software updates that address these
vulnerabilities. Prior to deploying software, customers should
consult their maintenance provider or check the software for feature
set compatibility and known issues specific to their environment.

Customers may only install and expect support for the feature sets
they have purchased. By installing, downloading, accessing or
otherwise using such software upgrades, customers agree to be bound
by the terms of Cisco's software license terms found at 
http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html,
or as otherwise set forth at Cisco.com Downloads at 
http://www.cisco.com/public/sw-center/sw-usingswc.shtml

Do not contact psirt at cisco.com or security-alert at cisco.com for
software upgrades.

Customers with Service Contracts
+-------------------------------

Customers with contracts should obtain upgraded software through
their regular update channels. For most customers, this means that
upgrades should be obtained through the Software Center on Cisco's
worldwide website at http://www.cisco.com

Customers using Third Party Support Organizations
+------------------------------------------------

Customers whose Cisco products are provided or maintained through
prior or existing agreements with third-party support organizations,
such as Cisco Partners, authorized resellers, or service providers
should contact that support organization for guidance and assistance
with the appropriate course of action in regards to this advisory.

The effectiveness of any workaround or fix is dependent on specific
customer situations, such as product mix, network topology, traffic
behavior, and organizational mission. Due to the variety of affected
products and releases, customers should consult with their service
provider or support organization to ensure any applied workaround or
fix is the most appropriate for use in the intended network before it
is deployed.

Customers without Service Contracts
+----------------------------------

Customers who purchase direct from Cisco but do not hold a Cisco
service contract, and customers who purchase through third-party
vendors but are unsuccessful in obtaining fixed software through
their point of sale should acquire upgrades by contacting the Cisco
Technical Assistance Center (TAC). TAC contacts are as follows.

  * +1 800 553 2447 (toll free from within North America)
  * +1 408 526 7209 (toll call from anywhere in the world)
  * e-mail: tac at cisco.com

Customers should have their product serial number available and be
prepared to give the URL of this notice as evidence of entitlement to
a free upgrade. Free upgrades for non-contract customers must be
requested through the TAC.

Refer to http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html
for additional TAC contact information, including localized telephone
numbers, and instructions and e-mail addresses for use in various 
languages.

Exploitation and Public Announcements
=====================================

The Cisco PSIRT is not aware of any public announcements or malicious
use of the vulnerability described in this advisory.

This vulnerability was reported to Cisco by a customer.

Status of this Notice: FINAL
============================

THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY
KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE
INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS
AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS
DOCUMENT AT ANY TIME.

A stand-alone copy or Paraphrase of the text of this document that
omits the distribution URL in the following section is an
uncontrolled copy, and may lack important information or contain
factual errors.

Distribution
============

This advisory is posted on Cisco's worldwide website at :

http://www.cisco.com/warp/public/707/cisco-sa-20090325-mobileip.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-Mar-25 | 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-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAknKUa8ACgkQ86n/Gc8U/uBD0ACfYblb5Nscx1zIWMLeihiaZAe7
TtsAoIGgf8/ubiolVwSDmu/tCTgH8skm
=YxAj
-----END PGP SIGNATURE-----

From psirt at cisco.com  Wed Mar 25 12:00:00 2009
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Wed, 25 Mar 2009 17:00:00 +0100
Subject: [c-nsp] Cisco Security Advisory: Cisco IOS cTCP Denial of Service
	Vulnerability
Message-ID: <200903251705.ctcp@psirt.cisco.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cisco Security Advisory: Cisco IOS cTCP Denial of Service
Vulnerability

Advisory ID: cisco-sa-20090325-ctcp

http://www.cisco.com/warp/public/707/cisco-sa-20090325-ctcp.shtml

Revision 1.0

For Public Release 2009 March 25 1600 UTC (GMT)

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

Summary
=======

A series of TCP packets may cause a denial of service (DoS) condition
on Cisco IOS devices that are configured as Easy VPN servers with the
Cisco Tunneling Control Protocol (cTCP) encapsulation feature. Cisco
has released free software updates that address this vulnerability.
No workarounds are available; however, the IPSec NAT traversal
(NAT-T) feature can be used as an alternative.

This advisory is posted at 
http://www.cisco.com/warp/public/707/cisco-sa-20090325-ctcp.shtml

Note: The March 25, 2009, Cisco IOS Security Advisory bundled
publication includes eight Security Advisories. All of the advisories
address vulnerabilities in Cisco IOS Software. Each advisory lists
the releases that correct the vulnerability or vulnerabilities in the
advisory. The following table lists releases that correct all Cisco
IOS Software vulnerabilities that have been published in Cisco
Security Advisories on March 25, 2009, or earlier.

http://www.cisco.com/warp/public/707/cisco-sa-20090325-bundle.shtml

Individual publication links are listed below:

  * Cisco IOS cTCP Denial of Service Vulnerability
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-ctcp.shtml

  * Cisco IOS Software Multiple Features IP Sockets Vulnerability
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-ip.shtml

  * Cisco IOS Software Mobile IP and Mobile IPv6 Vulnerabilities
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-mobileip.shtml

  * Cisco IOS Software Secure Copy Privilege Escalation Vulnerability
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-scp.shtml

  * Cisco IOS Software Session Initiation Protocol Denial of Service
    Vulnerability
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-sip.shtml

  * Cisco IOS Software Multiple Features Crafted TCP Sequence
    Vulnerability
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-tcp.shtml

  * Cisco IOS Software Multiple Features Crafted UDP Packet
    Vulnerability
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-udp.shtml

  * Cisco IOS Software WebVPN and SSLVPN Vulnerabilities
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-webvpn.shtml

Affected Products
=================

Vulnerable Products
+------------------

Cisco IOS devices running versions 12.4(9)T or later and configured
for Cisco Tunneling Control Protocol (cTCP) encapsulation for EZVPN
server are vulnerable.

Note: The cTCP encapsulation feature was introduced in Cisco IOS
version 12.4(9)T. The cTCP encapsulation feature is disabled by
default. Cisco IOS devices configured for EZVPN client are not
affected by this vulnerability. Only devices configured as EZVPN
servers are vulnerable.

To configure the cTCP encapsulation feature for Easy VPN, use the
crypto ctcp command in global configuration mode. You can optionally
specify the port number that the device will listen to with the
crypto ctcp port <port> command. Up to ten numbers can be configured
and the port value can be from 1 through 65535. If the port keyword
is not configured, the default port number is 10000. In the following
example, the Cisco IOS device is configured to listen for cTCP
messages on port 10000.

    crypto ctcp port 10000

Note: The port keyword is configured only on the Cisco IOS device
acting as an EZVPN server.

To determine the version of the Cisco IOS software running on a Cisco
product, log in to the device and issue the show version command to
display the system banner. Cisco IOS software will identify itself as
"Internetwork Operating System Software" or simply "IOS". On the next
line of output, the image name will be displayed between parentheses,
followed by "Version" and the IOS release name. Other Cisco devices
will not have the show version command or will give different output.

The following example identifies a Cisco product 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 next example shows a product running Cisco IOS Software release
12.4(20)T with an image name of C1841-ADVENTERPRISEK9-M:

        Router#show version
        Cisco IOS Software, 1841 Software (C1841-ADVENTERPRISEK9-M), Version 12.4(20)T, RELEASE SOFTWARE (fc3)
        Technical Support: http://www.cisco.com/techsupport
        Copyright (c) 1986-2008 by Cisco Systems, Inc.
        Compiled Thu 10-Jul-08 20:25 by prod_rel_team

      <output truncated>

Additional information on the Cisco IOS release naming conventions
can be found on the document entitled "White Paper: Cisco IOS
Reference Guide", which is available at 
http://www.cisco.com/warp/public/620/1.html

Products Confirmed Not Vulnerable
+--------------------------------

Cisco IOS devices that are not configured for cTCP are not affected
by this vulnerability. The Cisco ASA and Cisco VPN 3000 series
concentrators are not vulnerable. Cisco IOS devices configured as
EZVPN clients are not affected by this vulnerability. The Cisco VPN
Client is not vulnerable. Cisco IOS-XR and Cisco IOS-XE software are
not affected by this vulnerability. No other Cisco products are
currently known to be affected by this vulnerability.

Details
=======

The Cisco Tunneling Control Protocol (cTCP) feature is used by Easy
VPN remote device operating in an environment in which standard IPSec
does not function transparently without modification to existing
firewall rules. The cTCP traffic is actually TCP traffic. Cisco IOS
cTCP packets are Internet Key Exchange (IKE) or Encapsulating
Security Payload (ESP) packets that are being transmitted over TCP.

A vulnerability exists where a series of TCP packets may cause a
Cisco IOS device that is configured as an Easy VPN server with the
cTCP encapsulation feature to run out of memory. This vulnerability
is documented in Cisco Bug IDs CSCsr16693 and CSCsu21828; and has 
been assigned the Common Vulnerabilities and Exposures (CVE) 
identifier CVE-2009-0635.

Vulnerability Scoring Details
=============================

Cisco has provided scores for the vulnerability in this advisory
based on the Common Vulnerability Scoring System (CVSS). The CVSS
scoring in this Security Advisory is done in accordance with CVSS
version 2.0.

CVSS is a standards-based scoring method that conveys vulnerability
severity and helps determine urgency and priority of response.

Cisco has provided a base and temporal score. Customers can then
compute environmental scores to assist in determining the impact of
the vulnerability in individual networks.

Cisco has provided an FAQ to answer additional questions regarding
CVSS at

http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html

Cisco has also provided a CVSS calculator to help compute the
environmental impact for individual networks at

http://intellishield.cisco.com/security/alertmanager/cvss.

CSCsr16693 - cTCP server may crash when processing a series of 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

CSCsu21828 - Cisco IOS Device may crash with cTCP enabled

CVSS Base Score - 7.8

 Access Vector           - Network
 Access Complexity       - Low
 Authentication          - None
 Confidentiality Impact  - None
 Integrity Impact        - None
 Availability Impact     - Complete

CVSS Temporal Score - 6.4

 Exploitability          - Functional
 Remediation Level       - Official-Fix
 Report Confidence       - Confirmed

Impact
======

Successful exploitation of this vulnerability may cause the affected
device to run out of memory. Repeated exploitation will result in a
denial of service (DoS) condition.

Software Versions and Fixes
===========================

When considering software upgrades, also consult 
http://www.cisco.com/go/psirt and any subsequent advisories to 
determine exposure and a complete upgrade solution.

In all cases, customers should exercise caution to be certain the
devices to be upgraded contain sufficient memory and that current
hardware and software configurations will continue to be supported
properly by the new release. If the information is not clear, contact
the Cisco Technical Assistance Center (TAC) or your contracted
maintenance provider for assistance.

Each row of the Cisco IOS software table (below) names a Cisco IOS
release train. If a given release train is vulnerable, then the
earliest possible releases that contain the fix (along with the
anticipated date of availability for each, if applicable) are listed
in the "First Fixed Release" column of the table. The "Recommended
Release" column indicates the releases which have fixes for all the
published vulnerabilities at the time of this Advisory. A device
running a release in the given train that is earlier than the release
in a specific column (less than the First Fixed Release) is known to
be vulnerable. Cisco recommends upgrading to a release equal to or
later than the release in the "Recommended Releases" column of the
table.

+-------------------------------------------------------------------+
|   Major Release   |       Availability of Repaired Releases       |
|-------------------+-----------------------------------------------|
| Affected          |                       |                       |
| 12.0-Based        | First Fixed Release   | Recommended Release   |
| Releases          |                       |                       |
|-------------------------------------------------------------------|
| There are no affected 12.0 based releases                         |
|-------------------------------------------------------------------|
| Affected          |                       |                       |
| 12.1-Based        | First Fixed Release   | Recommended Release   |
| Releases          |                       |                       |
|-------------------------------------------------------------------|
| There are no affected 12.1 based releases                         |
|-------------------------------------------------------------------|
| Affected          |                       |                       |
| 12.2-Based        | First Fixed Release   | Recommended Release   |
| Releases          |                       |                       |
|-------------------------------------------------------------------|
| There are no affected 12.2 based releases                         |
|-------------------------------------------------------------------|
| Affected          |                       |                       |
| 12.3-Based        | First Fixed Release   | Recommended Release   |
| Releases          |                       |                       |
|-------------------------------------------------------------------|
| There are no affected 12.3 based releases                         |
|-------------------------------------------------------------------|
| Affected          |                       |                       |
| 12.4-Based        | First Fixed Release   | Recommended Release   |
| Releases          |                       |                       |
|-------------------+-----------------------+-----------------------|
| 12.4              | Not Vulnerable        |                       |
|-------------------+-----------------------+-----------------------|
| 12.4JA            | Not Vulnerable        |                       |
|-------------------+-----------------------+-----------------------|
| 12.4JDA           | Not Vulnerable        |                       |
|-------------------+-----------------------+-----------------------|
| 12.4JK            | Not Vulnerable        |                       |
|-------------------+-----------------------+-----------------------|
| 12.4JL            | Not Vulnerable        |                       |
|-------------------+-----------------------+-----------------------|
| 12.4JMA           | Not Vulnerable        |                       |
|-------------------+-----------------------+-----------------------|
| 12.4JMB           | Not Vulnerable        |                       |
|-------------------+-----------------------+-----------------------|
| 12.4JX            | Not Vulnerable        |                       |
|-------------------+-----------------------+-----------------------|
| 12.4MD            | Not Vulnerable        |                       |
|-------------------+-----------------------+-----------------------|
| 12.4MR            | Not Vulnerable        |                       |
|-------------------+-----------------------+-----------------------|
| 12.4SW            | Not Vulnerable        |                       |
|-------------------+-----------------------+-----------------------|
|                   | 12.4(20)T2            | 12.4(22)T1            |
| 12.4T             |                       |                       |
|                   | 12.4(15)T9; Available | 12.4(15)T9; Available |
|                   | on 29-APR-2009        | on 29-APR-2009        |
|-------------------+-----------------------+-----------------------|
| 12.4XA            | Not Vulnerable        |                       |
|-------------------+-----------------------+-----------------------|
| 12.4XB            | Not Vulnerable        |                       |
|-------------------+-----------------------+-----------------------|
| 12.4XC            | Not Vulnerable        |                       |
|-------------------+-----------------------+-----------------------|
| 12.4XD            | Not Vulnerable        |                       |
|-------------------+-----------------------+-----------------------|
| 12.4XE            | Not Vulnerable        |                       |
|-------------------+-----------------------+-----------------------|
| 12.4XF            | Not Vulnerable        |                       |
|-------------------+-----------------------+-----------------------|
| 12.4XG            | Not Vulnerable        |                       |
|-------------------+-----------------------+-----------------------|
| 12.4XJ            | Not Vulnerable        |                       |
|-------------------+-----------------------+-----------------------|
| 12.4XK            | Not Vulnerable        |                       |
|-------------------+-----------------------+-----------------------|
| 12.4XL            | Not Vulnerable        |                       |
|-------------------+-----------------------+-----------------------|
| 12.4XM            | Not Vulnerable        |                       |
|-------------------+-----------------------+-----------------------|
| 12.4XN            | Not Vulnerable        |                       |
|-------------------+-----------------------+-----------------------|
| 12.4XP            | Not Vulnerable        |                       |
|-------------------+-----------------------+-----------------------|
| 12.4XQ            | Not Vulnerable        |                       |
|-------------------+-----------------------+-----------------------|
| 12.4XR            | Not Vulnerable        |                       |
|-------------------+-----------------------+-----------------------|
| 12.4XT            | Not Vulnerable        |                       |
|-------------------+-----------------------+-----------------------|
| 12.4XV            | Not Vulnerable        |                       |
|-------------------+-----------------------+-----------------------|
| 12.4XW            | Not Vulnerable        |                       |
|-------------------+-----------------------+-----------------------|
| 12.4XY            | Not Vulnerable        |                       |
|-------------------+-----------------------+-----------------------|
| 12.4XZ            | 12.4(15)XZ2           | 12.4(15)XZ2           |
|-------------------+-----------------------+-----------------------|
| 12.4YA            | 12.4(20)YA2           | 12.4(20)YA3           |
|-------------------+-----------------------+-----------------------|
| 12.4YB            | Not Vulnerable        |                       |
|-------------------+-----------------------+-----------------------|
| 12.4YD            | Not Vulnerable        |                       |
+-------------------------------------------------------------------+

Workarounds
===========

No workarounds are available.

As an alternative, the IPSec NAT traversal (NAT-T) feature can be
used. The IPSec NAT-T feature introduces support for IP Security
(IPSec) traffic to travel through Network Address Translation (NAT)
or Port Address Translation (PAT) points in the network by addressing
many known incompatabilites between NAT and IPSec.

Note: The NAT-T feature was introduced in Cisco IOS version 12.2(13)
T.

NAT Traversal is a feature that is auto detected by VPN devices.
There are no configuration steps for a router running Cisco IOS
Release 12.2(13)T and later. If both VPN devices are NAT-T capable,
NAT Traversal is auto-detected and auto-negotiated.

Note: When you enable NAT-T, the Cisco IOS device automatically opens
UDP port 4500 on all IPSec enabled interfaces.

Caution: Be aware that you may need to enable IPSec over UDP on Cisco
VPN software clients to support NAT-T. Additionally, you may need to
change firewall rules to allow UDP port 500 for Internet Key Exchange
(IKE) and UDP port 4500 for NAT-T.

For more information about NAT-T, refer to the white paper at:

http://www.cisco.com/en/US/docs/ios/security/configuration/guide/sec_ipsec_nat_transp.html

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-20090325-ctcp.shtml

Obtaining Fixed Software
========================

Cisco has released free software updates that address this
vulnerability. Prior to deploying software, customers should consult
their maintenance provider or check the software for feature set
compatibility and known issues specific to their environment.

Customers may only install and expect support for the feature sets
they have purchased. By installing, downloading, accessing or
otherwise using such software upgrades, customers agree to be bound
by the terms of Cisco's software license terms found at 
http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html
or as otherwise set forth at Cisco.com Downloads at 
http://www.cisco.com/public/sw-center/sw-usingswc.shtml

Do not contact psirt at cisco.com or security-alert at cisco.com for
software upgrades.

Customers with Service Contracts
+-------------------------------

Customers with contracts should obtain upgraded software through
their regular update channels. For most customers, this means that
upgrades should be obtained through the Software Center on Cisco's
worldwide website at http://www.cisco.com.

Customers using Third Party Support Organizations
+------------------------------------------------

Customers whose Cisco products are provided or maintained through
prior or existing agreements with third-party support organizations,
such as Cisco Partners, authorized resellers, or service providers
should contact that support organization for guidance and assistance
with the appropriate course of action in regards to this advisory.

The effectiveness of any workaround or fix is dependent on specific
customer situations, such as product mix, network topology, traffic
behavior, and organizational mission. Due to the variety of affected
products and releases, customers should consult with their service
provider or support organization to ensure any applied workaround or
fix is the most appropriate for use in the intended network before it
is deployed.

Customers without Service Contracts
+----------------------------------

Customers who purchase direct from Cisco but do not hold a Cisco
service contract, and customers who purchase through third-party
vendors but are unsuccessful in obtaining fixed software through
their point of sale should acquire upgrades by contacting the Cisco
Technical Assistance Center (TAC). TAC contacts are as follows.

  * +1 800 553 2447 (toll free from within North America)
  * +1 408 526 7209 (toll call from anywhere in the world)
  * e-mail: tac at cisco.com

Customers should have their product serial number available and be
prepared to give the URL of this notice as evidence of entitlement to
a free upgrade. Free upgrades for non-contract customers must be
requested through the TAC.

Refer to http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html
for additional TAC contact information, including localized 
telephone numbers, and instructions and e-mail addresses for use in
various languages.

Exploitation and Public Announcements
=====================================

The Cisco PSIRT is not aware of any public announcements or malicious
use of the vulnerability described in this advisory.

This vulnerability was found during the resolution of a technical
support service request.

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-20090325-ctcp.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-March-25 | 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-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAknKUaYACgkQ86n/Gc8U/uBSWwCbBgAQRNBNdft9MYK8bC1MP/Z4
4D8AnA7qaiFqAdeWWbS+p4K601XNoo4S
=Rvhp
-----END PGP SIGNATURE-----

From psirt at cisco.com  Wed Mar 25 12:00:00 2009
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Wed, 25 Mar 2009 17:00:00 +0100
Subject: [c-nsp] Cisco Security Advisory: Cisco IOS Software WebVPN and
	SSLVPN Vulnerabilities
Message-ID: <200903251705.webvpn@psirt.cisco.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cisco Security Advisory: Cisco IOS Software WebVPN and SSLVPN
Vulnerabilities

Advisory ID: cisco-sa-20090325-webvpn

http://www.cisco.com/warp/public/707/cisco-sa-20090325-webvpn.shtml

Revision 1.0

For Public Release 2009 March 25 1600 UTC (GMT)

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

Summary
=======

Cisco IOS software contains two vulnerabilities within the Cisco IOS
WebVPN or Cisco IOS SSLVPN feature (SSLVPN) that can be remotely
exploited without authentication to cause a denial of service
condition. Both vulnerabilities affect both Cisco IOS WebVPN and
Cisco IOS SSLVPN features:

 1. Crafted HTTPS packet will crash device.
 2. SSLVPN sessions cause a memory leak in the device.

Cisco has released free software updates that address these
vulnerabilities.

There are no workarounds that mitigate these vulnerabilities.

This advisory is posted at the following link: 
http://www.cisco.com/warp/public/707/cisco-sa-20090325-webvpn.shtml

Note: The March 25, 2009, Cisco IOS Security Advisory bundled
publication includes eight Security Advisories. All of the advisories
address vulnerabilities in Cisco IOS Software. Each advisory lists
the releases that correct the vulnerability or vulnerabilities in the
advisory. The following table lists releases that correct all Cisco
IOS Software vulnerabilities that have been published in Cisco
Security Advisories on March 25, 2009, or earlier.

http://www.cisco.com/warp/public/707/cisco-sa-20090325-bundle.shtml

Individual publication links are listed below:

  * Cisco IOS cTCP Denial of Service Vulnerability
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-ctcp.shtml

  * Cisco IOS Software Multiple Features IP Sockets Vulnerability
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-ip.shtml

  * Cisco IOS Software Mobile IP and Mobile IPv6 Vulnerabilities
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-mobileip.shtml

  * Cisco IOS Software Secure Copy Privilege Escalation Vulnerability
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-scp.shtml

  * Cisco IOS Software Session Initiation Protocol Denial of Service
    Vulnerability
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-sip.shtml

  * Cisco IOS Software Multiple Features Crafted TCP Sequence
    Vulnerability
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-tcp.shtml

  * Cisco IOS Software Multiple Features Crafted UDP Packet
    Vulnerability
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-udp.shtml

  * Cisco IOS Software WebVPN and SSLVPN Vulnerabilities
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-webvpn.shtml

Affected Products
=================

Vulnerable Products
+------------------

Devices running affected versions of Cisco IOS software are affected
if configured with SSLVPN.

To determine the Cisco IOS Software release that is running on a
Cisco product, administrators can log in to the device and issue the
"show version" command to display the system banner. The system
banner confirms that the device is running Cisco IOS Software by
displaying text similar to "Cisco Internetwork Operating System
Software" or "Cisco IOS Software." The image name displays in
parentheses, followed by "Version" and the Cisco IOS Software release
name. Other Cisco devices do not have the "show version" command or
may provide different output.

The following example identifies a Cisco product that is running
Cisco IOS Software Release 12.3(26) with an installed image name of
C2500-IS-L:

    Router#show version
    Cisco Internetwork Operating System Software
    IOS (tm) 2500 Software (C2500-IS-L), Version 12.3(26), RELEASE SOFTWARE (fc2)
    Technical Support: http://www.cisco.com/techsupport
    Copyright (c) 1986-2008 by cisco Systems, Inc.
    Compiled Mon 17-Mar-08 14:39 by dchih

    <output truncated>

The following example shows a product that is running Cisco IOS
Software release 12.4(20)T with an image name of
C1841-ADVENTERPRISEK9-M:

    Router#show version
    Cisco IOS Software, 1841 Software (C1841-ADVENTERPRISEK9-M), Version 12.4(20)T, RELEASE SOFTWARE (fc3)
    Technical Support: http://www.cisco.com/techsupport
    Copyright (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

To determine that SSLVPN is enabled on your device, log in to the
device and issue the command-line interface (CLI) command "show
running-config | include webvpn". If the device returns any output
this means that SSLVPN is configured on the device and the device may
be vulnerable. Vulnerable configurations vary depending on whether
the device is supporting Cisco IOS WebVPN (introduced in Release 12.3
(14)T) or Cisco IOS SSLVPNs (introduced in Release 12.4(6)T). The
following methods describe how to confirm if the device is
vulnerable:

If the output from "show running-config | include webvpn" contains
"webvpn enable" then the device is configured with the original Cisco
IOS WebVPN. The only way to confirm the device is vulnerable is to
examine the output of "show running-config" to confirm that webvpn is
enabled via the command "webvpn enable" and that a "ssl trustpoint"
has been configured. The following example shows a vulnerable device
configured with Cisco IOS WebVPN:

    webvpn enable
    !
    webvpn
     ssl trustpoint TP-self-signed-29742012

If the output from "show running-config | include webvpn" contains
"webvpn gateway <word>" then the device is supporting the Cisco IOS
SSLVPN feature. A device is vulnerable if it has the "inservice"
command in at least one of the "webvpn gateway" sections. The
following example shows a vulnerable device configured with Cisco IOS
SSLVPN:

    Router# show running | section webvpn
    webvpn gateway Gateway
     ip address 10.1.1.1 port 443
     ssl trustpoint Gateway-TP
     inservice
     !
    Router#

A device that supports the Cisco IOS SSLVPN is not vulnerable if it
has no "webvpn gateways" configured or all the configured "webvpn
gateways" contain the "no inservice" "webvpn gateway" command.

Products Confirmed Not Vulnerable
+--------------------------------

The following products are not affected by this vulnerability:

  * Cisco ASA 5500 Series Adaptive Security Appliances
  * Cisco IOS XR Software
  * Cisco IOS XE Software

No other Cisco products are currently known to be affected by these
vulnerabilities.

Details
=======

The Cisco SSLVPN feature provides remote access to enterprise sites
by users from anywhere on the Internet. The SSLVPN provides users
with secure access to specific enterprise applications, such as
e-mail and web browsing, without requiring them to have VPN client
software installed on their end-user devices.

The WebVPN Enhancements feature (Cisco IOS SSLVPN), released in Cisco
IOS Release 12.4(6)T, obsoletes the commands and configurations
originally put forward in Cisco IOS WebVPN.

Further information about Cisco IOS WebVPN is available in the "Cisco
IOS Software Release 12.3T WebVPN feature guide" at the following
link: 
http://www.cisco.com/en/US/docs/ios/12_3t/12_3t14/feature/guide/g_sslvpn.html

Further information about Cisco IOS SSLVPN is available in the "Cisco
IOS Software Release 12.4T SSLVPN feature guide" at the following
link: http://www.cisco.com/en/US/docs/ios/12_4t/12_4t11/htwebvpn.html

Details regarding these two vulnerabilities in Cisco IOS devices that
are running affected versions of system software are:

Crafted HTTPS packet will crash device
+--------------------------------------

A device configured for SSLVPN may reload or hang when it receives a
specially crafted HTTPS packet. Completion of the 3-way handshake to
the associated TCP port number of the SSLVPN feature is required in
order for the vulnerability to be successfully exploited, however
authentication is "not" required. The default TCP port number for
SSLVPN is 443.

This vulnerability is documented in Cisco bug ID CSCsk62253 
and Common Vulnerabilities and Exposures (CVE) identifier 
CVE-2009-0626 has been assigned to this vulnerability.

SSLVPN sessions cause a memory leak in the device
+------------------------------------------------

A device configured for SSLVPN may leak transmission control blocks
(TCBs) when processing an abnormally disconnected SSL session.
Continued exploitation may result in the device depleting its memory
resources and result in a crash of the device. Authentication is
"not" required to exploit this vulnerability.

The memory leak can be detected by running the command "show tcp
brief", like in the following example:

    Router#show tcp brief
    TCB       Local Address      Foreign Address     (state)
    468BBDC0  192.168.0.22.443   192.168.0.33.19794   CLOSEWAIT
    482D4730  192.168.0.22.443   192.168.0.33.22092   CLOSEWAIT
    482779A4  192.168.0.22.443   192.168.0.33.16978   CLOSEWAIT
    4693DEBC  192.168.0.22.443   192.168.0.33.21580   CLOSEWAIT
    482D3418  192.168.0.22.443   192.168.0.33.17244   CLOSEWAIT
    482B8ACC  192.168.0.22.443   192.168.0.33.16564   CLOSEWAIT
    46954EB0  192.168.0.22.443   192.168.0.33.19532   CLOSEWAIT
    468BA9B8  192.168.0.22.443   192.168.0.33.15781   CLOSEWAIT
    482908C4  192.168.0.22.443   192.168.0.33.19275   CLOSEWAIT
    4829D66C  192.168.0.22.443   192.168.0.33.19314   CLOSEWAIT
    468A2D94  192.168.0.22.443   192.168.0.33.14736   CLOSEWAIT
    4688F590  192.168.0.22.443   192.168.0.33.18786   CLOSEWAIT
    4693CBA4  192.168.0.22.443   192.168.0.33.12176   CLOSEWAIT
    4829ABC4  192.168.0.22.443   192.168.0.33.39629   CLOSEWAIT
    4691206C  192.168.0.22.443   192.168.0.33.17818   CLOSEWAIT
    46868224  192.168.0.22.443   192.168.0.33.16774   CLOSEWAIT
    4832BFAC  192.168.0.22.443   192.168.0.33.39883   CLOSEWAIT
    482D10CC  192.168.0.22.443   192.168.0.33.13677   CLOSEWAIT
    4829B120  192.168.0.22.443   192.168.0.33.20870   CLOSEWAIT
    482862FC  192.168.0.22.443   192.168.0.33.17035   CLOSEWAIT
    482EC13C  192.168.0.22.443   192.168.0.33.16053   CLOSEWAIT
    482901D8  192.168.0.22.443   192.168.0.33.16200   CLOSEWAIT

In the output above, those Transmission Control Blocks (TCBs) in the
state CLOSEWAIT will not go away and represent memory leaks. Please
note that only TCP connections with a local TCP port of 443 (the
well-known port for HTTPS) are relevant.

This vulnerability is documented in Cisco bug ID CSCsw24700 
and Common Vulnerabilities and Exposures (CVE) identifier 
CVE-2009-0628 has been assigned to this vulnerability.

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 

CSCsk62253 - Crafted HTTPS packet will crash device.

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


CSCsw24700 - SSLVPN sessions cause a memory leak in the device.

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 any of the two vulnerabilities may result
in the device crashing, not accepting any new SSLVPN sessions or a
memory leak. Repeated exploitation may result in an extended denial
of service (DoS) condition.

Software Versions and Fixes
===========================

When considering software upgrades, also consult 
http://www.cisco.com/go/psirt and any subsequent advisories to 
determine exposure and a complete upgrade solution.

In all cases, customers should exercise caution to be certain the
devices to be upgraded contain sufficient memory and that current
hardware and software configurations will continue to be supported
properly by the new release. If the information is not clear, contact
the Cisco Technical Assistance Center (TAC) or your contracted
maintenance provider for assistance.

Each row of the Cisco IOS software table (below) names a Cisco IOS
release train. If a given release train is vulnerable, then the
earliest possible releases that contain the fix (along with the
anticipated date of availability for each, if applicable) are listed
in the "First Fixed Release" column of the table. The "Recommended
Release" column indicates the releases which have fixes for all the
published vulnerabilities at the time of this Advisory. A device
running a release in the given train that is earlier than the release
in a specific column (less than the First Fixed Release) is known to
be vulnerable. Cisco recommends upgrading to a release equal to or
later than the release in the "Recommended Releases" column of the
table.

+-------------------------------------------------------------------+
|   Major    |          Availability of Repaired Releases           |
|  Release   |                                                      |
|------------+------------------------------------------------------|
| Affected   |                                      | Recommended   |
| 12.0-Based | First Fixed Release                  | Release       |
| Releases   |                                      |               |
|-------------------------------------------------------------------|
| There are no affected 12.0 based releases                         |
|-------------------------------------------------------------------|
| Affected   |                                      | Recommended   |
| 12.1-Based | First Fixed Release                  | Release       |
| Releases   |                                      |               |
|-------------------------------------------------------------------|
| There are no affected 12.1 based releases                         |
|-------------------------------------------------------------------|
| Affected   |                                      | Recommended   |
| 12.2-Based | First Fixed Release                  | Release       |
| Releases   |                                      |               |
|-------------------------------------------------------------------|
| There are no affected 12.2 based releases                         |
|-------------------------------------------------------------------|
| Affected   |                                      | Recommended   |
| 12.3-Based | First Fixed Release                  | Release       |
| Releases   |                                      |               |
|------------+--------------------------------------+---------------|
| 12.3       | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3B      | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3BC     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3BW     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3EU     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3JA     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3JEA    | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3JEB    | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3JEC    | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3JK     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3JL     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3JX     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(22)T1    |
|            |                                      |               |
| 12.3T      | Vulnerable; first fixed in 12.4T     | 12.4(15)T9;   |
|            |                                      | Available on  |
|            |                                      | 29-APR-2009   |
|------------+--------------------------------------+---------------|
| 12.3TPC    | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3VA     | Vulnerable; contact TAC              |               |
|------------+--------------------------------------+---------------|
| 12.3XA     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3XB     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3XC     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3XD     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3XE     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3XF     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3XG     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3XI     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3XJ     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3XK     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3XL     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3XQ     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3XR     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3XS     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3XU     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3XW     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3XX     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3XY     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3XZ     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3YA     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3YD     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3YF     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3YG     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3YH     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3YI     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3YJ     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            | Releases prior to 12.3(11)YK3 are    | 12.4(22)T1    |
|            | vulnerable, release 12.3(11)YK3 and  |               |
| 12.3YK     | later are not vulnerable; first      | 12.4(15)T9;   |
|            | fixed in 12.4T                       | Available on  |
|            |                                      | 29-APR-2009   |
|------------+--------------------------------------+---------------|
| 12.3YM     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(22)T1    |
|            |                                      |               |
| 12.3YQ     | Vulnerable; first fixed in 12.4T     | 12.4(15)T9;   |
|            |                                      | Available on  |
|            |                                      | 29-APR-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(22)T1    |
|            |                                      |               |
| 12.3YS     | Vulnerable; first fixed in 12.4T     | 12.4(15)T9;   |
|            |                                      | Available on  |
|            |                                      | 29-APR-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(22)T1    |
|            |                                      |               |
| 12.3YT     | Vulnerable; first fixed in 12.4T     | 12.4(15)T9;   |
|            |                                      | Available on  |
|            |                                      | 29-APR-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(22)T1    |
|            |                                      |               |
| 12.3YU     | Vulnerable; first fixed in 12.4T     | 12.4(15)T9;   |
|            |                                      | Available on  |
|            |                                      | 29-APR-2009   |
|------------+--------------------------------------+---------------|
| 12.3YX     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3YZ     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.3ZA     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| Affected   |                                      | Recommended   |
| 12.4-Based | First Fixed Release                  | Release       |
| Releases   |                                      |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(18e)     |
|            | 12.4(18e)                            |               |
| 12.4       |                                      | 12.4(23a);    |
|            | 12.4(23a); Available on 30-APR-2009  | Available on  |
|            |                                      | 30-APR-2009   |
|------------+--------------------------------------+---------------|
| 12.4JA     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.4JDA    | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.4JK     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.4JL     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.4JMA    | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.4JMB    | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.4JX     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.4MD     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.4MR     | 12.4(16)MR                           | 12.4(19)MR2   |
|------------+--------------------------------------+---------------|
| 12.4SW     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            | 12.4(15)T7                           | 12.4(22)T1    |
|            |                                      |               |
| 12.4T      | 12.4(20)T                            | 12.4(15)T9;   |
|            |                                      | Available on  |
|            | 12.4(15)T9; Available on 29-APR-2009 | 29-APR-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(22)T1    |
|            |                                      |               |
| 12.4XA     | Vulnerable; first fixed in 12.4T     | 12.4(15)T9;   |
|            |                                      | Available on  |
|            |                                      | 29-APR-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(22)T1    |
|            |                                      |               |
| 12.4XB     | Vulnerable; first fixed in 12.4T     | 12.4(15)T9;   |
|            |                                      | Available on  |
|            |                                      | 29-APR-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(22)T1    |
|            |                                      |               |
| 12.4XC     | Vulnerable; first fixed in 12.4T     | 12.4(15)T9;   |
|            |                                      | Available on  |
|            |                                      | 29-APR-2009   |
|------------+--------------------------------------+---------------|
|            | 12.4(4)XD12; Available on            | 12.4(4)XD12;  |
| 12.4XD     | 27-MAR-2009                          | Available on  |
|            |                                      | 27-MAR-2009   |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(22)T1    |
|            |                                      |               |
| 12.4XE     | Vulnerable; first fixed in 12.4T     | 12.4(15)T9;   |
|            |                                      | Available on  |
|            |                                      | 29-APR-2009   |
|------------+--------------------------------------+---------------|
| 12.4XF     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.4XG     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(22)T1    |
|            |                                      |               |
| 12.4XJ     | Vulnerable; first fixed in 12.4T     | 12.4(15)T9;   |
|            |                                      | Available on  |
|            |                                      | 29-APR-2009   |
|------------+--------------------------------------+---------------|
| 12.4XK     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.4XL     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.4XM     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.4XN     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.4XP     | Vulnerable; contact TAC              |               |
|------------+--------------------------------------+---------------|
| 12.4XQ     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.4XR     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
|            |                                      | 12.4(22)T1    |
|            |                                      |               |
| 12.4XT     | Vulnerable; first fixed in 12.4T     | 12.4(15)T9;   |
|            |                                      | Available on  |
|            |                                      | 29-APR-2009   |
|------------+--------------------------------------+---------------|
| 12.4XV     | Vulnerable; contact TAC              |               |
|------------+--------------------------------------+---------------|
| 12.4XW     | 12.4(11)XW10                         | 12.4(11)XW10  |
|------------+--------------------------------------+---------------|
| 12.4XY     | 12.4(15)XY4                          | 12.4(22)T1    |
|------------+--------------------------------------+---------------|
| 12.4XZ     | 12.4(15)XZ1                          | 12.4(15)XZ2   |
|------------+--------------------------------------+---------------|
| 12.4YA     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.4YB     | Not Vulnerable                       |               |
|------------+--------------------------------------+---------------|
| 12.4YD     | Not Vulnerable                       |               |
+-------------------------------------------------------------------+

Workarounds
===========

There are no workarounds for the vulnerabilities described in this
advisory.

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/warp/public/687/Directory/DirTAC.shtml
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 vulnerabilities described in this advisory.

These vulnerabilities were discovered when handling customer support
calls.

Status of this Notice: FINAL
============================

THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY
KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE
INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS
AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS
DOCUMENT AT ANY TIME.

A stand-alone copy or Paraphrase of the text of this document that
omits the distribution URL in the following section is an
uncontrolled copy, and may lack important information or contain
factual errors.

Distribution
============

This advisory is posted on Cisco's worldwide website at :

http://www.cisco.com/warp/public/707/cisco-sa-20090325-webvpn.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-teams at 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-March-25 | 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-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAknKUdcACgkQ86n/Gc8U/uALXwCgmcIGTSzRIHpHRbVVmMNqPFT4
+CIAn27HdwwpkhVDgEIWTMsIX6NE4BgR
=+f8D
-----END PGP SIGNATURE-----

From tdurack at gmail.com  Wed Mar 25 13:06:34 2009
From: tdurack at gmail.com (Tim Durack)
Date: Wed, 25 Mar 2009 13:06:34 -0400
Subject: [c-nsp] match and remove no-export
Message-ID: <9e246b4d0903251006j2e208304oc7cf7bfa71c24533@mail.gmail.com>

This is probably a stupid question, but anyway:

Can I match and remove no-export from routes? I need to shuffle some
routes between global and a vrf. I have a "fake" eBGP session up, but
the routes I need to move are marked no-export.

I've tried applying a simple match/set route-map to the eBGP session,
without success. I'm going to assume no-export gets taken into account
before the routes even hit the route-map.

Any ideas?

Tim:>

From chiel at gmx.net  Wed Mar 25 12:37:51 2009
From: chiel at gmx.net (chiel)
Date: Wed, 25 Mar 2009 17:37:51 +0100
Subject: [c-nsp] Cisco 887 CPE and 890series?!?!?!?!?!
In-Reply-To: <292AF25E62B8894C921B893B53A19D97394469DF07@BUSINESSEX.business.ad>
References: <292AF25E62B8894C921B893B53A19D97394469DF07@BUSINESSEX.business.ad>
Message-ID: <49CA5DDF.80600@gmx.net>

Great to see that the 890 will have 8 lan ports, unfortunately not at 
gig speed.


Skeeve Stevens wrote:
> Hey all,  I was just going to download the latest IOS for a Cisco 877 and below is the current list of 800 series routes on the Cisco website.
>
> What caught my eye was the 3 entries for the Cisco 887 (887, 887W, 887SRSTW).
>
> I was like "WHAT THE...." ??!?!?!?
>
> Went to the product pages... nothing
> Went to Google... nothing useful, especially from Cisco
>
> Searching around I also came across the Cisco 890 series
> http://www.cisco.com/en/US/prod/collateral/routers/ps380/qa_c67-520756_ps380_Products_Q_and_A_Item.html
>
> Seriously!!!! This is the biggest tease I've ever had!  Anyone got any more information?
>
> ...Skeeve
>
>
>
> Cisco 888 Integrated Services Router
> Cisco 888SRST Integrated Services Router
> Cisco 888SRSTW Integrated Services Router
> Cisco 888W Integrated Services Router
> Cisco 887 SRST Integrated Services Router
> Cisco 887SRSTW Integrated Services Router
> Cisco 887W Integrated Services Router
> Cisco 881 Integrated Services Router
> Cisco 881SRST Integrated Services Router
> Cisco 881SRSTW Integrated Services Router
> Cisco 881W Integrated Services Router
> Cisco 878 Integrated Services Router
> Cisco 877 Integrated Services Router
> Cisco 876 Integrated Services Router
> Cisco 871 Integrated Services Router
> Cisco 861 Integrated Services Router
> Cisco 861W Integrated Services Router
> Cisco 857 Integrated Services Router
> Cisco 851 Integrated Services Router
> Cisco 837 ADSL Broadband Router
> Cisco 836 ADSL over ISDN Broadband Router
> Cisco 831 Ethernet Broadband Router
> Cisco 815 Integrated Services Router
>
>
>
>
> --
> 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
> --
> 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 psirt at cisco.com  Wed Mar 25 12:00:00 2009
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Wed, 25 Mar 2009 17:00:00 +0100
Subject: [c-nsp] Cisco Security Advisory: Cisco IOS Software Secure Copy
	Privilege Escalation Vulnerability
Message-ID: <200903251705.scp@psirt.cisco.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cisco Security Advisory: Cisco IOS Software Secure Copy Privilege
Escalation Vulnerability

Advisory ID: cisco-sa-20090325-scp

http://www.cisco.com/warp/public/707/cisco-sa-20090325-scp.shtml

Revision 1.0

For Public Release 2009 March 25 1600 UTC (GMT)

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

Summary
=======

The server side of the Secure Copy (SCP) implementation in Cisco IOS
software contains a vulnerability that could allow authenticated
users with an attached command-line interface (CLI) view to transfer
files to and from a Cisco IOS device that is configured to be an SCP
server, regardless of what users are authorized to do, per the CLI
view configuration. This vulnerability could allow valid users to
retrieve or write to any file on the device's file system, including
the device's saved configuration and Cisco IOS image files, even if
the CLI view attached to the user does not allow it. This
configuration file may include passwords or other sensitive
information.

The Cisco IOS SCP server is an optional service that is disabled by
default. CLI views are a fundamental component of the Cisco IOS
Role-Based CLI Access feature, which is also disabled by default.
Devices that are not specifically configured to enable the Cisco IOS
SCP server, or that are configured to use it but do not use
role-based CLI access, are not affected by this vulnerability.

This vulnerability does not apply to the Cisco IOS SCP client
feature.

Cisco has released free software updates that address this
vulnerability.

There are no workarounds available for this vulnerability apart from
disabling either the SCP server or the CLI view feature if these
services are not required by administrators.

This advisory is posted at the following link: 
http://www.cisco.com/warp/public/707/cisco-sa-20090325-scp.shtml

Note: The March 25, 2009, Cisco IOS Security Advisory bundled
publication includes eight Security Advisories. All of the advisories
address vulnerabilities in Cisco IOS Software. Each advisory lists
the releases that correct the vulnerability or vulnerabilities in the
advisory. The following table lists releases that correct all Cisco
IOS Software vulnerabilities that have been published in Cisco
Security Advisories on March 25, 2009, or earlier.

http://www.cisco.com/warp/public/707/cisco-sa-20090325-bundle.shtml

Individual publication links are listed below:

  * Cisco IOS cTCP Denial of Service Vulnerability
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-ctcp.shtml

  * Cisco IOS Software Multiple Features IP Sockets Vulnerability
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-ip.shtml

  * Cisco IOS Software Mobile IP and Mobile IPv6 Vulnerabilities
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-mobileip.shtml

  * Cisco IOS Software Secure Copy Privilege Escalation Vulnerability
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-scp.shtml

  * Cisco IOS Software Session Initiation Protocol Denial of Service
    Vulnerability
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-sip.shtml

  * Cisco IOS Software Multiple Features Crafted TCP Sequence
    Vulnerability
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-tcp.shtml

  * Cisco IOS Software Multiple Features Crafted UDP Packet
    Vulnerability
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-udp.shtml

  * Cisco IOS Software WebVPN and SSLVPN Vulnerabilities
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-webvpn.shtml

Affected Products
=================

Vulnerable Products
+------------------

Cisco devices running an affected Cisco IOS software release,
configured to offer SCP server functionality, and configured to use
role-based ACL access are affected by this issue.

A device running a vulnerable Cisco IOS software release is affected
if its configuration is similar to the following:

    parser view <view name>
     <Definition of the CLI view>
    !
    username <user ID> view <view name> secret <some secret>
    !
    ip scp server enable

In the above configuration snippet, the parser view command defines a
view that specifies what commands users in that view can execute. The
username command defines a local user and attaches, via the view
keyword, the previously defined view to the user. And finally, the ip
scp server enable command enables the Cisco IOS SCP server.

The absence of the username command does not guarantee that the
device's configuration is not affected by this vulnerability because
the name of a CLI view can be supplied by means of an Authentication,
Authorization, and Accounting (AAA) server by using the cli-view-name
attribute.

Note: The CLI view attached to a user can be supplied by a AAA
server. When inspecting a device's configuration to determine if it
is affected by this vulnerability it is better to check if the SCP
service is enabled (ip scp server enabled command) and whether there
are any CLI views defined (parser view command).

The Cisco IOS SCP server and role-based CLI access features are
disabled by default.

The SCP server functionality is only available on encryption-capable
images. Encryption-capable images are those that contain either a
"k8" or "k9" in the image name, for example, "C7200-ADVSECURITYK9-M".
Devices that do not run encryption-capable images are not vulnerable.
If a device is running an encryption-capable image, the presence in
the configuration of the ip scp server enable command, the existence
of CLI views (parser view command), and whether there are users
(local or remote) attached to these views will determine if the
device is affected.

To determine the Cisco IOS Software release that is running on a
Cisco product, administrators can log in to the device and issue the
show version command to display the system banner. The system banner
confirms that the device is running Cisco IOS Software by displaying
text similar to "Cisco Internetwork Operating System Software" or
"Cisco IOS Software." The image name displays in parentheses,
followed by "Version" and the Cisco IOS Software release name. Other
Cisco devices do not have the show version command or may provide
different output.

The following example identifies a Cisco product that is running
Cisco IOS Software Release 12.3(26) with an installed image name of
C2500-IS-L:

    Router#show version
    Cisco Internetwork Operating System Software
    IOS (tm) 2500 Software (C2500-IS-L), Version 12.3(26), RELEASE SOFTWARE (fc2)
    Technical Support: http://www.cisco.com/techsupport
    Copyright (c) 1986-2008 by cisco Systems, Inc.
    Compiled Mon 17-Mar-08 14:39 by dchih

    !--- output truncated


The following example identifies a Cisco product that is running
Cisco IOS Software Release 12.4(20)T with an installed image name of
C1841-ADVENTERPRISEK9-M:

    Router#show version
    Cisco IOS Software, 1841 Software (C1841-ADVENTERPRISEK9-M), Version 12.4(20)T, RELEASE SOFTWARE (fc3)
    Technical Support: http://www.cisco.com/techsupport
    Copyright (c) 1986-2008 by Cisco Systems, Inc.
    Compiled Thu 10-Jul-08 20:25 by prod_rel_team

    !--- output truncated


Additional information about Cisco IOS Software release naming
conventions is available in "White Paper: Cisco IOS Reference Guide"
at the following link: http://www.cisco.com/warp/public/620/1.html

Cisco IOS XE Software is also affected by this vulnerability.

Products Confirmed Not Vulnerable
+--------------------------------

Cisco devices that do not run Cisco IOS software are not affected.

Cisco IOS devices that do not have the SCP server feature enabled, or
that make use of the feature but do not have the role-based CLI
feature enabled, are not affected.

Cisco IOS XR Software is not affected.

No other Cisco products are currently known to be affected by this
vulnerability.

Details
=======

SCP is a protocol similar to the Remote Copy (RCP) protocol, which
allows the transfer of files between systems. The main difference
between SCP and RCP is that in SCP, all aspects of the file transfer
session, including authentication, occur in encrypted form, which
makes SCP a more secure alternative than RCP. SCP relies on the
Secure Shell (SSH) protocol, which uses TCP port 22 by default.

The Role-Based CLI Access feature allows the network administrator to
define "views". Views are sets of operational commands and
configuration capabilities that provide selective or partial access
to Cisco IOS software EXEC and configuration (Config) mode commands.
Views restrict user access to Cisco IOS command-line interface (CLI)
and configuration information; that is, a view can define what
commands are accepted and what configuration information is visible.
For more information about the Role-Based CLI Access feature,
reference 
http://www.cisco.com/en/US/docs/ios/12_3t/12_3t7/feature/guide/gtclivws.html

The server side of the SCP implementation in Cisco IOS software
contains a vulnerability that allows authenticated users with an
attached command-line interface (CLI) view to transfer files to and
from a Cisco IOS device that is configured to be a SCP server,
regardless of what users are authorized to do, per the CLI view
configuration. This vulnerability could allow authenticated users to
retrieve or write to any file on the device's file system, including
the device's saved configuration and Cisco IOS image files. This
configuration file may include passwords or other sensitive
information.

In the affected configuration presented in the Affected Products
section, users confined to a CLI view can elevate their privileges by
using SCP to write to the device's configuration. Note that a view
can be attached to a user when defining the user in the local
database (via the username <user name> view ... command), or by
passing the attribute cli-view-name from an AAA server.

This vulnerability does not allow for authentication bypass; login
credentials are verified and access is only granted if a valid
username and password is provided. This vulnerability may cause
authorization to be bypassed.

This vulnerability is documented in the Cisco Bug ID CSCsv38166 
and has been assigned Common Vulnerabilities and Exposures (CVE) ID
CVE-2009-0637.

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

CSCsv38166 - SCP + views (role-based CLI) allows privilege escalation

CVSS Base Score - 9.0

 Access Vector           - Network
 Access Complexity       - Low
 Authentication          - Single
 Confidentiality Impact  - Complete
 Integrity Impact        - Complete
 Availability Impact     - Complete

CVSS Temporal Score - 7.4

 Exploitability          - Functional
 Remediation Level       - Official-Fix
 Report Confidence       - Confirmed

Impact
======

Successful exploitation of the vulnerability described in this
advisory may allow valid but unauthorized users to retrieve or write
to any file on the device's file system, including the device's saved
configuration and Cisco IOS image files. This configuration file may
include passwords or other sensitive information.

Software Versions and Fixes
===========================

When considering software upgrades, also consult 
http://www.cisco.com/go/psirt and any subsequent advisories to 
determine exposure and a complete upgrade solution.

In all cases, customers should exercise caution to be certain the
devices to be upgraded contain sufficient memory and that current
hardware and software configurations will continue to be supported
properly by the new release. If the information is not clear, contact
the Cisco Technical Assistance Center (TAC) or your contracted
maintenance provider for assistance.

Each row of the Cisco IOS software table (below) names a Cisco IOS
release train. If a given release train is vulnerable, then the
earliest possible releases that contain the fix (along with the
anticipated date of availability for each, if applicable) are listed
in the "First Fixed Release" column of the table. The "Recommended
Release" column indicates the releases which have fixes for all the
published vulnerabilities at the time of this Advisory. A device
running a release in the given train that is earlier than the release
in a specific column (less than the First Fixed Release) is known to
be vulnerable. Cisco recommends upgrading to a release equal to or
later than the release in the "Recommended Releases" column of the
table.

+-------------------------------------------------------------------+
|   Major    |          Availability of Repaired Releases           |
|  Release   |                                                      |
|------------+------------------------------------------------------|
| Affected   |                                    | Recommended     |
| 12.0-Based | First Fixed Release                | Release         |
| Releases   |                                    |                 |
|-------------------------------------------------------------------|
| There are no affected 12.0 based releases                         |
|-------------------------------------------------------------------|
| Affected   |                                    | Recommended     |
| 12.1-Based | First Fixed Release                | Release         |
| Releases   |                                    |                 |
|-------------------------------------------------------------------|
| There are no affected 12.1 based releases                         |
|-------------------------------------------------------------------|
| Affected   |                                    | Recommended     |
| 12.2-Based | First Fixed Release                | Release         |
| Releases   |                                    |                 |
|------------+------------------------------------+-----------------|
| 12.2       | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2B      | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2BC     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2BW     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2BX     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2BY     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2BZ     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2CX     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2CY     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2CZ     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2DA     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2DD     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2DX     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2EW     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2EWA    | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2EX     | Vulnerable; migrate to any release | 12.2(44)SE6     |
|            | in 12.2SEG                         |                 |
|------------+------------------------------------+-----------------|
| 12.2EY     | Vulnerable; first fixed in 12.2SE  | 12.2(44)SE6     |
|------------+------------------------------------+-----------------|
| 12.2EZ     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2FX     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2FY     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2FZ     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
|            |                                    | 12.2(33)SRC4;   |
| 12.2IRA    | Vulnerable; first fixed in 12.2SRC | Available on    |
|            |                                    | 18-MAY-2009     |
|------------+------------------------------------+-----------------|
|            |                                    | 12.2(33)SRC4;   |
| 12.2IRB    | Vulnerable; first fixed in 12.2SRC | Available on    |
|            |                                    | 18-MAY-2009     |
|------------+------------------------------------+-----------------|
| 12.2IXA    | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2IXB    | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2IXC    | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2IXD    | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2IXE    | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2IXF    | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2IXG    | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2JA     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2JK     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2MB     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2MC     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2S      | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2SB     | 12.2(33)SB4                        | 12.2(33)SB4     |
|------------+------------------------------------+-----------------|
| 12.2SBC    | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2SCA    | Vulnerable; first fixed in 12.2SCB | 12.2(33)SCB1    |
|------------+------------------------------------+-----------------|
| 12.2SCB    | 12.2(33)SCB1                       | 12.2(33)SCB1    |
|------------+------------------------------------+-----------------|
|            | 12.2(50)SE                         |                 |
| 12.2SE     |                                    | 12.2(44)SE6     |
|            | 12.2(44)SE6                        |                 |
|------------+------------------------------------+-----------------|
| 12.2SEA    | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2SEB    | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2SEC    | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2SED    | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2SEE    | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2SEF    | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2SEG    | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
|            | 12.2(52)SG; Available on           | 12.2(52)SG;     |
| 12.2SG     | 15-MAY-2009                        | Available on    |
|            |                                    | 15-MAY-2009     |
|------------+------------------------------------+-----------------|
| 12.2SGA    | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2SL     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2SM     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2SO     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2SQ     | Vulnerable; contact TAC            |                 |
|------------+------------------------------------+-----------------|
| 12.2SRA    | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
|            |                                    | 12.2(33)SRC4;   |
|            |                                    | Available on    |
|            |                                    | 18-MAY-2009     |
| 12.2SRB    | Vulnerable; first fixed in 12.2SRC |                 |
|            |                                    | 12.2(33)SRB5a;  |
|            |                                    | Available on    |
|            |                                    | 3-April-2009    |
|------------+------------------------------------+-----------------|
|            | 12.2(33)SRC4; Available on         | 12.2(33)SRC4;   |
| 12.2SRC    | 18-MAY-2009                        | Available on    |
|            |                                    | 18-MAY-2009     |
|------------+------------------------------------+-----------------|
| 12.2SRD    | 12.2(33)SRD1                       | 12.2(33)SRD1    |
|------------+------------------------------------+-----------------|
| 12.2STE    | Vulnerable; contact TAC            |                 |
|------------+------------------------------------+-----------------|
| 12.2SU     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2SV     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2SVA    | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2SVC    | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2SVD    | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2SVE    | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2SW     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2SX     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2SXA    | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2SXB    | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2SXD    | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2SXE    | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2SXF    | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2SXH    | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2SXI    | 12.2(33)SXI1                       | 12.2(33)SXI1    |
|------------+------------------------------------+-----------------|
| 12.2SY     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2SZ     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2T      | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2TPC    | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2XA     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2XB     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2XC     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2XD     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2XE     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2XF     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2XG     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2XH     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2XI     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2XJ     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2XK     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2XL     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2XM     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
|            |                                    | 12.2(33)SB4     |
|            |                                    |                 |
|            |                                    | 12.2(33)SRD1    |
| 12.2XN     | Vulnerable; first fixed in 12.2SRC |                 |
|            |                                    | 12.2(33)SRC4;   |
|            |                                    | Available on    |
|            |                                    | 18-MAY-2009     |
|------------+------------------------------------+-----------------|
|            |                                    | 12.2(33)SRD1    |
|            |                                    |                 |
| 12.2XNA    | Vulnerable; first fixed in 12.2SRD | 12.2(33)SRC4;   |
|            |                                    | Available on    |
|            |                                    | 18-MAY-2009     |
|------------+------------------------------------+-----------------|
| 12.2XNB    | 12.2(33)XNB3                       | 12.2(33)XNB3    |
|------------+------------------------------------+-----------------|
| 12.2XNC    | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2XO     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2XQ     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2XR     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2XS     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2XT     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2XU     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2XV     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2XW     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2YA     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2YB     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2YC     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2YD     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2YE     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2YF     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2YG     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2YH     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2YJ     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2YK     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2YL     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2YM     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2YN     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2YO     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2YP     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2YQ     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2YR     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2YS     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2YT     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2YU     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2YV     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2YW     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2YX     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2YY     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2YZ     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2ZA     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2ZB     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2ZC     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2ZD     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2ZE     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2ZF     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2ZG     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2ZH     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2ZJ     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2ZL     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2ZP     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2ZU     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2ZX     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2ZY     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.2ZYA    | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| Affected   |                                    | Recommended     |
| 12.3-Based | First Fixed Release                | Release         |
| Releases   |                                    |                 |
|------------+------------------------------------+-----------------|
| 12.3       | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.3B      | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.3BC     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.3BW     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.3EU     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.3JA     | Vulnerable; contact TAC            |                 |
|------------+------------------------------------+-----------------|
| 12.3JEA    | Vulnerable; contact TAC            |                 |
|------------+------------------------------------+-----------------|
| 12.3JEB    | Vulnerable; contact TAC            |                 |
|------------+------------------------------------+-----------------|
| 12.3JEC    | Vulnerable; contact TAC            |                 |
|------------+------------------------------------+-----------------|
|            |                                    | 12.4(22)T1      |
|            |                                    |                 |
| 12.3JK     | Vulnerable; first fixed in 12.4T   | 12.4(15)T9;     |
|            |                                    | Available on    |
|            |                                    | 29-APR-2009     |
|------------+------------------------------------+-----------------|
| 12.3JL     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.3JX     | Vulnerable; contact TAC            |                 |
|------------+------------------------------------+-----------------|
|            |                                    | 12.4(22)T1      |
|            |                                    |                 |
| 12.3T      | Vulnerable; first fixed in 12.4T   | 12.4(15)T9;     |
|            |                                    | Available on    |
|            |                                    | 29-APR-2009     |
|------------+------------------------------------+-----------------|
| 12.3TPC    | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.3VA     | Vulnerable; contact TAC            |                 |
|------------+------------------------------------+-----------------|
| 12.3XA     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.3XB     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.3XC     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.3XD     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.3XE     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.3XF     | Vulnerable; contact TAC            |                 |
|------------+------------------------------------+-----------------|
|            |                                    | 12.4(22)T1      |
|            |                                    |                 |
| 12.3XG     | Vulnerable; first fixed in 12.4T   | 12.4(15)T9;     |
|            |                                    | Available on    |
|            |                                    | 29-APR-2009     |
|------------+------------------------------------+-----------------|
| 12.3XI     | Vulnerable; first fixed in 12.2SB  | 12.2(33)SB4     |
|------------+------------------------------------+-----------------|
| 12.3XJ     | Vulnerable; first fixed in 12.3YX  | 12.3(14)YX14    |
|------------+------------------------------------+-----------------|
|            |                                    | 12.4(22)T1      |
|            |                                    |                 |
| 12.3XK     | Vulnerable; first fixed in 12.4T   | 12.4(15)T9;     |
|            |                                    | Available on    |
|            |                                    | 29-APR-2009     |
|------------+------------------------------------+-----------------|
|            |                                    | 12.4(22)T1      |
|            |                                    |                 |
| 12.3XL     | Vulnerable; first fixed in 12.4T   | 12.4(15)T9;     |
|            |                                    | Available on    |
|            |                                    | 29-APR-2009     |
|------------+------------------------------------+-----------------|
|            |                                    | 12.4(22)T1      |
|            |                                    |                 |
| 12.3XQ     | Vulnerable; first fixed in 12.4T   | 12.4(15)T9;     |
|            |                                    | Available on    |
|            |                                    | 29-APR-2009     |
|------------+------------------------------------+-----------------|
|            |                                    | 12.4(18e)       |
|            |                                    |                 |
| 12.3XR     | Vulnerable; first fixed in 12.4    | 12.4(23a);      |
|            |                                    | Available on    |
|            |                                    | 30-APR-2009     |
|------------+------------------------------------+-----------------|
|            |                                    | 12.4(22)T1      |
|            |                                    |                 |
| 12.3XS     | Vulnerable; first fixed in 12.4T   | 12.4(15)T9;     |
|            |                                    | Available on    |
|            |                                    | 29-APR-2009     |
|------------+------------------------------------+-----------------|
|            |                                    | 12.4(22)T1      |
|            |                                    |                 |
| 12.3XU     | Vulnerable; first fixed in 12.4T   | 12.4(15)T9;     |
|            |                                    | Available on    |
|            |                                    | 29-APR-2009     |
|------------+------------------------------------+-----------------|
| 12.3XW     | Vulnerable; first fixed in 12.3YX  | 12.3(14)YX14    |
|------------+------------------------------------+-----------------|
|            |                                    | 12.4(22)T1      |
|            |                                    |                 |
| 12.3XX     | Vulnerable; first fixed in 12.4T   | 12.4(15)T9;     |
|            |                                    | Available on    |
|            |                                    | 29-APR-2009     |
|------------+------------------------------------+-----------------|
|            |                                    | 12.4(22)T1      |
|            |                                    |                 |
| 12.3XY     | Vulnerable; first fixed in 12.4T   | 12.4(15)T9;     |
|            |                                    | Available on    |
|            |                                    | 29-APR-2009     |
|------------+------------------------------------+-----------------|
| 12.3XZ     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
|            |                                    | 12.4(22)T1      |
|            |                                    |                 |
| 12.3YA     | Vulnerable; first fixed in 12.4T   | 12.4(15)T9;     |
|            |                                    | Available on    |
|            |                                    | 29-APR-2009     |
|------------+------------------------------------+-----------------|
|            |                                    | 12.4(22)T1      |
|            |                                    |                 |
| 12.3YD     | Vulnerable; first fixed in 12.4T   | 12.4(15)T9;     |
|            |                                    | Available on    |
|            |                                    | 29-APR-2009     |
|------------+------------------------------------+-----------------|
| 12.3YF     | Vulnerable; first fixed in 12.3YX  | 12.3(14)YX14    |
|------------+------------------------------------+-----------------|
|            |                                    | 12.4(22)T1      |
|            |                                    |                 |
| 12.3YG     | Vulnerable; first fixed in 12.4T   | 12.4(15)T9;     |
|            |                                    | Available on    |
|            |                                    | 29-APR-2009     |
|------------+------------------------------------+-----------------|
|            |                                    | 12.4(22)T1      |
|            |                                    |                 |
| 12.3YH     | Vulnerable; first fixed in 12.4T   | 12.4(15)T9;     |
|            |                                    | Available on    |
|            |                                    | 29-APR-2009     |
|------------+------------------------------------+-----------------|
|            |                                    | 12.4(22)T1      |
|            |                                    |                 |
| 12.3YI     | Vulnerable; first fixed in 12.4T   | 12.4(15)T9;     |
|            |                                    | Available on    |
|            |                                    | 29-APR-2009     |
|------------+------------------------------------+-----------------|
|            |                                    | 12.4(22)T1      |
|            |                                    |                 |
| 12.3YJ     | Vulnerable; first fixed in 12.4T   | 12.4(15)T9;     |
|            |                                    | Available on    |
|            |                                    | 29-APR-2009     |
|------------+------------------------------------+-----------------|
|            |                                    | 12.4(22)T1      |
|            |                                    |                 |
| 12.3YK     | Vulnerable; first fixed in 12.4T   | 12.4(15)T9;     |
|            |                                    | Available on    |
|            |                                    | 29-APR-2009     |
|------------+------------------------------------+-----------------|
| 12.3YM     | 12.3(14)YM13                       | 12.3(14)YM13    |
|------------+------------------------------------+-----------------|
|            |                                    | 12.4(22)T1      |
|            |                                    |                 |
| 12.3YQ     | Vulnerable; first fixed in 12.4T   | 12.4(15)T9;     |
|            |                                    | Available on    |
|            |                                    | 29-APR-2009     |
|------------+------------------------------------+-----------------|
|            |                                    | 12.4(22)T1      |
|            |                                    |                 |
| 12.3YS     | Vulnerable; first fixed in 12.4T   | 12.4(15)T9;     |
|            |                                    | Available on    |
|            |                                    | 29-APR-2009     |
|------------+------------------------------------+-----------------|
|            |                                    | 12.4(22)T1      |
|            |                                    |                 |
| 12.3YT     | Vulnerable; first fixed in 12.4T   | 12.4(15)T9;     |
|            |                                    | Available on    |
|            |                                    | 29-APR-2009     |
|------------+------------------------------------+-----------------|
|            |                                    | 12.4(22)T1      |
|            |                                    |                 |
| 12.3YU     | Vulnerable; first fixed in 12.4T   | 12.4(15)T9;     |
|            |                                    | Available on    |
|            |                                    | 29-APR-2009     |
|------------+------------------------------------+-----------------|
| 12.3YX     | 12.3(14)YX14                       | 12.3(14)YX14    |
|------------+------------------------------------+-----------------|
| 12.3YZ     | Vulnerable; contact TAC            |                 |
|------------+------------------------------------+-----------------|
|            |                                    | 12.4(22)T1      |
|            |                                    |                 |
| 12.3ZA     | Vulnerable; first fixed in 12.4T   | 12.4(15)T9;     |
|            |                                    | Available on    |
|            |                                    | 29-APR-2009     |
|------------+------------------------------------+-----------------|
| Affected   |                                    | Recommended     |
| 12.4-Based | First Fixed Release                | Release         |
| Releases   |                                    |                 |
|------------+------------------------------------+-----------------|
|            | 12.4(18e)                          | 12.4(18e)       |
|            |                                    |                 |
| 12.4       | 12.4(23a); Available on            | 12.4(23a);      |
|            | 30-APR-2009                        | Available on    |
|            |                                    | 30-APR-2009     |
|------------+------------------------------------+-----------------|
| 12.4JA     | Vulnerable; contact TAC            |                 |
|------------+------------------------------------+-----------------|
| 12.4JDA    | Vulnerable; contact TAC            |                 |
|------------+------------------------------------+-----------------|
| 12.4JK     | Vulnerable; contact TAC            |                 |
|------------+------------------------------------+-----------------|
| 12.4JL     | Vulnerable; contact TAC            |                 |
|------------+------------------------------------+-----------------|
| 12.4JMA    | Vulnerable; contact TAC            |                 |
|------------+------------------------------------+-----------------|
| 12.4JMB    | Vulnerable; contact TAC            |                 |
|------------+------------------------------------+-----------------|
| 12.4JX     | Vulnerable; contact TAC            |                 |
|------------+------------------------------------+-----------------|
| 12.4MD     | 12.4(11)MD7                        | 12.4(11)MD7     |
|------------+------------------------------------+-----------------|
| 12.4MR     | 12.4(19)MR2                        | 12.4(19)MR2     |
|------------+------------------------------------+-----------------|
| 12.4SW     | Vulnerable; contact TAC            |                 |
|------------+------------------------------------+-----------------|
|            | 12.4(24)T                          |                 |
|            |                                    | 12.4(22)T1      |
|            | 12.4(20)T2                         |                 |
| 12.4T      |                                    | 12.4(15)T9;     |
|            | 12.4(22)T1                         | Available on    |
|            |                                    | 29-APR-2009     |
|            | 12.4(15)T9; Available on           |                 |
|            | 29-APR-2009                        |                 |
|------------+------------------------------------+-----------------|
|            |                                    | 12.4(22)T1      |
|            |                                    |                 |
| 12.4XA     | Vulnerable; first fixed in 12.4T   | 12.4(15)T9;     |
|            |                                    | Available on    |
|            |                                    | 29-APR-2009     |
|------------+------------------------------------+-----------------|
|            |                                    | 12.4(22)T1      |
|            |                                    |                 |
| 12.4XB     | Vulnerable; first fixed in 12.4T   | 12.4(15)T9;     |
|            |                                    | Available on    |
|            |                                    | 29-APR-2009     |
|------------+------------------------------------+-----------------|
|            |                                    | 12.4(22)T1      |
|            |                                    |                 |
| 12.4XC     | Vulnerable; first fixed in 12.4T   | 12.4(15)T9;     |
|            |                                    | Available on    |
|            |                                    | 29-APR-2009     |
|------------+------------------------------------+-----------------|
|            | 12.4(4)XD12; Available on          | 12.4(4)XD12;    |
| 12.4XD     | 27-MAR-2009                        | Available on    |
|            |                                    | 27-MAR-2009     |
|------------+------------------------------------+-----------------|
|            |                                    | 12.4(22)T1      |
|            |                                    |                 |
| 12.4XE     | Vulnerable; first fixed in 12.4T   | 12.4(15)T9;     |
|            |                                    | Available on    |
|            |                                    | 29-APR-2009     |
|------------+------------------------------------+-----------------|
|            |                                    | 12.4(22)T1      |
|            |                                    |                 |
| 12.4XF     | Vulnerable; first fixed in 12.4T   | 12.4(15)T9;     |
|            |                                    | Available on    |
|            |                                    | 29-APR-2009     |
|------------+------------------------------------+-----------------|
|            |                                    | 12.4(22)T1      |
|            | 12.4(20)T2                         |                 |
| 12.4XG     |                                    | 12.4(15)T9;     |
|            | 12.4(22)T1                         | Available on    |
|            |                                    | 29-APR-2009     |
|------------+------------------------------------+-----------------|
|            |                                    | 12.4(22)T1      |
|            |                                    |                 |
| 12.4XJ     | Vulnerable; first fixed in 12.4T   | 12.4(15)T9;     |
|            |                                    | Available on    |
|            |                                    | 29-APR-2009     |
|------------+------------------------------------+-----------------|
|            |                                    | 12.4(22)T1      |
|            |                                    |                 |
| 12.4XK     | Vulnerable; first fixed in 12.4T   | 12.4(15)T9;     |
|            |                                    | Available on    |
|            |                                    | 29-APR-2009     |
|------------+------------------------------------+-----------------|
|            | Releases prior to 12.4(15)XL4 are  |                 |
| 12.4XL     | vulnerable, release 12.4(15)XL4    | 12.4(15)XL4     |
|            | and later are not vulnerable;      |                 |
|------------+------------------------------------+-----------------|
|            |                                    | 12.4(22)T1      |
|            |                                    |                 |
| 12.4XM     | Vulnerable; first fixed in 12.4T   | 12.4(15)T9;     |
|            |                                    | Available on    |
|            |                                    | 29-APR-2009     |
|------------+------------------------------------+-----------------|
| 12.4XN     | Vulnerable; contact TAC            |                 |
|------------+------------------------------------+-----------------|
| 12.4XP     | Vulnerable; contact TAC            |                 |
|------------+------------------------------------+-----------------|
| 12.4XQ     | 12.4(15)XQ2                        | 12.4(15)XQ2     |
|------------+------------------------------------+-----------------|
|            |                                    | 12.4(22)T1      |
|            |                                    |                 |
| 12.4XR     | Vulnerable; first fixed in 12.4T   | 12.4(15)T9;     |
|            |                                    | Available on    |
|            |                                    | 29-APR-2009     |
|------------+------------------------------------+-----------------|
|            |                                    | 12.4(22)T1      |
|            |                                    |                 |
| 12.4XT     | Vulnerable; first fixed in 12.4T   | 12.4(15)T9;     |
|            |                                    | Available on    |
|            |                                    | 29-APR-2009     |
|------------+------------------------------------+-----------------|
| 12.4XV     | Vulnerable; contact TAC            |                 |
|------------+------------------------------------+-----------------|
| 12.4XW     | 12.4(11)XW10                       | 12.4(11)XW10    |
|------------+------------------------------------+-----------------|
|            |                                    | 12.4(22)T1      |
|            |                                    |                 |
| 12.4XY     | Vulnerable; first fixed in 12.4T   | 12.4(15)T9;     |
|            |                                    | Available on    |
|            |                                    | 29-APR-2009     |
|------------+------------------------------------+-----------------|
| 12.4XZ     | 12.4(15)XZ2                        | 12.4(15)XZ2     |
|------------+------------------------------------+-----------------|
| 12.4YA     | 12.4(20)YA2                        | 12.4(20)YA3     |
|------------+------------------------------------+-----------------|
| 12.4YB     | Not Vulnerable                     |                 |
|------------+------------------------------------+-----------------|
| 12.4YD     | Not Vulnerable                     |                 |
+-------------------------------------------------------------------+

Workarounds
===========

If the Cisco IOS SCP server functionality is not needed then the
vulnerability described in this document can be mitigated by
disabling the SCP server or the CLI view feature. The SCP server can
be disabled by executing the following command in global
configuration mode:

    no ip scp server enable

If the SCP server cannot be disabled due to operational concerns,
then no workarounds exist. The risk posed by this vulnerability can
be mitigated by following the best practices detailed in "Cisco Guide
to Harden Cisco IOS Devices" at 
http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080120f48.shtml
Please refer to the Obtaining Fixed Software section of this advisory
for appropriate solutions to resolve this vulnerability.

Due to the nature of this vulnerability, networking best practices
like access control lists (ACLs) and Control Plane Policing (CoPP)
that restrict access to a device to certain IP addresses or
subnetworks may not be effective. If access is already granted to a
specific IP address or subnetwork, a user with low privileges will be
able to establish an SCP session with the device, which would allow
the user to exploit this vulnerability.

Obtaining Fixed Software
========================

Cisco has released free software updates that address these
vulnerabilities. Prior to deploying software, customers should
consult their maintenance provider or check the software for feature
set compatibility and known issues specific to their environment.

Customers may only install and expect support for the feature sets
they have purchased. By installing, downloading, accessing or
otherwise using such software upgrades, customers agree to be bound
by the terms of Cisco's software license terms found at 
http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html, or as
otherwise set forth at Cisco.com Downloads at 
http://www.cisco.com/public/sw-center/sw-usingswc.shtml

Do not contact psirt at cisco.com or security-alert at cisco.com for
software upgrades.

Customers with Service Contracts
+-------------------------------

Customers with contracts should obtain upgraded software through
their regular update channels. For most customers, this means that
upgrades should be obtained through the Software Center on Cisco's
worldwide website at http://www.cisco.com

Customers using Third Party Support Organizations
+------------------------------------------------

Customers whose Cisco products are provided or maintained through
prior or existing agreements with third-party support organizations,
such as Cisco Partners, authorized resellers, or service providers
should contact that support organization for guidance and assistance
with the appropriate course of action in regards to this advisory.

The effectiveness of any workaround or fix is dependent on specific
customer situations, such as product mix, network topology, traffic
behavior, and organizational mission. Due to the variety of affected
products and releases, customers should consult with their service
provider or support organization to ensure any applied workaround or
fix is the most appropriate for use in the intended network before it
is deployed.

Customers without Service Contracts
+----------------------------------

Customers who purchase direct from Cisco but do not hold a Cisco
service contract, and customers who purchase through third-party
vendors but are unsuccessful in obtaining fixed software through
their point of sale should acquire upgrades by contacting the Cisco
Technical Assistance Center (TAC). TAC contacts are as follows.

  * +1 800 553 2447 (toll free from within North America)
  * +1 408 526 7209 (toll call from anywhere in the world)
  * e-mail: tac at cisco.com

Customers should have their product serial number available and be
prepared to give the URL of this notice as evidence of entitlement to
a free upgrade. Free upgrades for non-contract customers must be
requested through the TAC.

Refer to http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html
for additional TAC contact information, including localized telephone 
numbers, and instructions and e-mail addresses for use in various 
languages.

Exploitation and Public Announcements
=====================================

The Cisco PSIRT is not aware of any public announcements or malicious
use of the vulnerability described in this advisory.

This vulnerability was reported to Cisco by Kevin Graham. Cisco would
like to thank Mr. Graham for reporting this vulnerability and working
with us towards coordinated disclosure of the vulnerability.

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-20090325-scp.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-March-25 | 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-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAknKUbQACgkQ86n/Gc8U/uBoggCdGbEAh9pGrV/ApbhENou5MF4M
vTIAn03h9J//T0V6BZBxwwS2hKs/JIXi
=JGEE
-----END PGP SIGNATURE-----

From psirt at cisco.com  Wed Mar 25 12:00:00 2009
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Wed, 25 Mar 2009 17:00:00 +0100
Subject: [c-nsp] Cisco Security Advisory: Cisco IOS Software Multiple
	Features IP Sockets Vulnerability
Message-ID: <200903251705.ip@psirt.cisco.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cisco Security Advisory: Cisco IOS Software Multiple Features IP
Sockets Vulnerability

Advisory ID: cisco-sa-20090325-ip

http://www.cisco.com/warp/public/707/cisco-sa-20090325-ip.shtml

Revision 1.0

For Public Release 2009 March 25 1600 UTC (GMT)

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

Summary
=======

A vulnerability in the handling of IP sockets can cause devices to be
vulnerable to a denial of service attack when any of several features
of Cisco IOS  Software are enabled. A sequence of specially crafted
TCP/IP packets could cause any of the following results:

  * The configured feature may stop accepting new connections or
    sessions.
  * The memory of the device may be consumed.
  * The device may experience prolonged high CPU utilization.
  * The device may reload.

Cisco has released free software updates that address this
vulnerability.

Several mitigation strategies are outlined in the "Workarounds"
section of this advisory.

This advisory is posted at 
http://www.cisco.com/warp/public/707/cisco-sa-20090325-ip.shtml

Note: The March 25, 2009, Cisco IOS Security Advisory bundled
publication includes eight Security Advisories. All of the advisories
address vulnerabilities in Cisco IOS Software. Each advisory lists
the releases that correct the vulnerability or vulnerabilities in the
advisory. The following table lists releases that correct all Cisco
IOS Software vulnerabilities that have been published in Cisco
Security Advisories on March 25, 2009, or earlier.

http://www.cisco.com/warp/public/707/cisco-sa-20090325-bundle.shtml

Individual publication links are listed below:

  * Cisco IOS cTCP Denial of Service Vulnerability
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-ctcp.shtml

  * Cisco IOS Software Multiple Features IP Sockets Vulnerability
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-ip.shtml

  * Cisco IOS Software Mobile IP and Mobile IPv6 Vulnerabilities
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-mobileip.shtml

  * Cisco IOS Software Secure Copy Privilege Escalation Vulnerability
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-scp.shtml

  * Cisco IOS Software Session Initiation Protocol Denial of Service
    Vulnerability
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-sip.shtml

  * Cisco IOS Software Multiple Features Crafted TCP Sequence
    Vulnerability
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-tcp.shtml

  * Cisco IOS Software Multiple Features Crafted UDP Packet
    Vulnerability
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-udp.shtml

  * Cisco IOS Software WebVPN and SSLVPN Vulnerabilities
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-webvpn.shtml

Affected Products
=================

Vulnerable Products
+------------------

Devices that are running affected versions of Cisco IOS Software and
Cisco IOS XE Software are affected if they are running any of the
following features. Details about confirming whether the affected
feature is enabled on a device are in the "Details" section of this
advisory.

  * Cisco Unified Communications Manager Express
  * SIP Gateway Signaling Support Over Transport Layer Security (TLS)
    Transport
  * Secure Signaling and Media Encryption
  * Blocks Extensible Exchange Protocol (BEEP)
  * Network Admission Control HTTP Authentication Proxy
  * Per-user URL Redirect for EAPoUDP, Dot1x, and MAC Authentication
    Bypass
  * Distributed Director with HTTP Redirects
  * DNS (TCP mode only)

To determine the Cisco IOS Software release that is running on a
Cisco product, administrators can log in to the device and issue the
"show version" command to display the system banner. The system
banner confirms that the device is running Cisco IOS Software by
displaying text similar to "Cisco Internetwork Operating System
Software" or "Cisco IOS Software." The image name displays in
parentheses, followed by "Version" and the Cisco IOS Software release
name. Other Cisco devices do not have the "show version" command or
may provide different output.

The following example identifies a Cisco product that is running
Cisco IOS Software Release 12.3(26) with an installed image name of
C2500-IS-L:

    Router#show version
    Cisco Internetwork Operating System Software
    IOS (tm) 2500 Software (C2500-IS-L), Version 12.3(26), RELEASE SOFTWARE (fc2)
    Technical Support: http://www.cisco.com/techsupport
    Copyright (c) 1986-2008 by cisco Systems, Inc.
    Compiled Mon 17-Mar-08 14:39 by dchih

    <output truncated>

The following example shows a product that is running Cisco IOS
Software Release 12.4(20)T with an image name of
C1841-ADVENTERPRISEK9-M:

    Router#show version
    Cisco IOS Software, 1841 Software (C1841-ADVENTERPRISEK9-M), Version 12.4(20)T, RELEASE SOFTWARE (fc3)
    Technical Support: http://www.cisco.com/techsupport
    Copyright (c) 1986-2008 by Cisco Systems, Inc.
    Compiled Thu 10-Jul-08 20:25 by prod_rel_team

    <output truncated>

Additional information about Cisco IOS Software release naming
conventions is available in "White Paper: Cisco IOS Reference Guide"
at the following link: http://www.cisco.com/warp/public/620/1.html

Products Confirmed Not Vulnerable
+--------------------------------

The following product is not affected by this vulnerability:

  * Cisco IOS XR Software

No other Cisco products or features configured in Cisco IOS or Cisco
IOS XE Software are currently known to be affected by this
vulnerability.

Details
========

For successful exploitation of this vulnerability, the TCP three-way
handshake must be completed to the associated TCP port number(s) for
any of the features described in this section.

Cisco Unified Communications Manager Express
+-------------------------------------------

The following configurations are vulnerable for different Cisco
Unified Communications Manager Express services:

A certificate authority proxy function (CAPF) server has been
configured.

The following example shows a vulnerable CAPF server configuration:

    capf-server
     auth-mode null-string
     cert-enroll-trustpoint root password 1 104D000A061843595F
     trustpoint-label cme_cert
     source-addr 10.0.0.1

The default TCP port used for CAPF server is 3804.

Further information about CAPF-server is in the Cisco Unified
Communications Manager Express System Administrator Guide at 
http://www.cisco.com/en/US/docs/voice_ip_comm/cucme/admin/configuration/guide/cmeauth.html#wp1085744

Telephony-service security parameters have been configured.

If the telephony-service security parameters have been configured
with "device-security-mode", the device is vulnerable. The following
example shows three vulnerable configurations for telephony-service
security parameters:

    ephone 1
     device-security-mode encrypted

    ephone 2
     device-security-mode authenticated

    ephone 3
     device-security-mode none

The TCP port used is defined with the "ip source-address <address>
port <port-number>" telephony-service configuration command.

Further information about Telephony-service security parameters is in
the Cisco Unified Communications Manager Express System Administrator
Guide at 
http://www.cisco.com/en/US/docs/voice_ip_comm/cucme/admin/configuration/guide/cmeauth.html#wp1080079

The global telephony-service or call-manager-fallback command has
been configured.

Any Cisco IOS configuration with the global "telephony-service" or
"call-manager-fallback" command is vulnerable if any subcommands are
in the telephony-service or call-manager-fallback configuration mode.
The following examples show vulnerable configurations:

    telephony-service
     ip source-address 192.168.0.1 port 2011

or

    call-manager-fallback
     ip source-address 192.168.0.1 port 2011

The TCP port used is defined with the "ip source-address <address>
port <port-number>" configuration command.

Further information about telephony service and call-manager-fallback
is in the Cisco Unified Communications Manager Express System
Administrator Guide at 
http://www.cisco.com/en/US/docs/voice_ip_comm/cucme/admin/configuration/guide/cmesystm.html

SIP Gateway Signaling Support over TLS Transport
+----------------------------------------------

Note: For customers with devices enabled with SIP, also consult the
document "Cisco Security Advisory: Cisco IOS Session Initiation
Protocol Denial of Service Vulnerability" at the following link 
http://www.cisco.com/warp/public/707/cisco-sa-20090325-sip.html

Devices that are configured for SIP gateway signaling support over
TLS transport are vulnerable. The following examples show vulnerable
configurations:

    voice service voip
     sip
      session transport tcp tls
      url sips

- -- or --

    dial-peer voice 3456 voip
     voice-class sip url sips
     session protocol sipv2
     session transport tcp tls

For the SIP gateway signaling support over TLS transport to function
correctly, administrators must first configure a trustpoint using the
following configuration:

    sip-ua
         crypto signaling default trustpoint example_trustpoint_name

The default TCP port used for the SIP gateway signaling support over
TLS transport feature is 5061.

Further information about Cisco IOS SIP gateway signaling support
over TLS transport is in the Cisco IOS Software Release 12.4T feature
guide at 
http://www.cisco.com/en/US/docs/ios/12_4t/12_4t11/FeatTLS.html

Secure Signaling and Media Encryption
+------------------------------------

A device is vulnerable if it is configured with the Media and
Signaling Encryption (SRTP/TLS) on DSP Farm Conferencing feature or
with Secure Signaling and Media Encryption for analog phones with
Skinny Call Control Protocol (SCCP).

The following examples show three different vulnerable secure DSP
farm configurations. Several other parts are required for a full
configuration, such as certificates and SCCP configuration, but these
parts have been excluded for brevity.

    dspfarm profile 2 transcode security
     trustpoint 2851ClientMina
     codec g711ulaw
     codec g711alaw
     codec g729ar8
     codec g729abr8
     codec gsmfr
     codec g729r8
     codec g729br8
     maximum sessions 3
     associate application SCCP

    dspfarm profile 3 conference security
     trustpoint sec2800-cfb
     codec g711ulaw
     codec g711alaw
     codec g729ar8
     codec g729abr8
     codec g729r8
     codec g729br8
     maximum sessions 2
     associate application SCCP

    dspfarm profile 5 mtp security
     trustpoint 2851ClientMina
     codec g711alaw
     maximum sessions hardware 1
     associate application SCCP

The default TCP port used for the Media and Signaling Encryption on
DSP Farm Conferencing feature is 2443.

Further information about the Media and Signaling Encryption on DSP
Farm Conferencing feature is in the "Cisco IOS Software Release 12.4
Special and Early Deployments feature guide" at the following link
http://www.cisco.com/en/US/docs/ios/12_4t/12_4t15/itsdsp.html

The following output shows the relevant section of Secure Signaling
and Media Encryption for analog phones and is a vulnerable
configuration (Several other parts are required for a full
configuration, such as certificates, SCCP configuration, and dial
peers):


    !--- The following lines show SCCP Telephony Control Application 
    !--- (STCAPP) security enabled at the system level:

    stcapp ccm-group 1
    stcapp security trustpoint analog
    stcapp security mode encrypted
    stcapp

    <-- output removed for brevity -->

    dial-peer voice 5002 pots
    service stcapp

    !--- The following line shows the security mode configured on the 
    !--- dial peer.

    security mode authenticated
    port 2/1

The default TCP port used for Media and Signaling Encryption for
analog phones is 2443.

Further information about Media and Signaling Encryption for analog
phones is in the "Supplementary Services Features for FXS Ports on
Cisco IOS Voice Gateways Configuration Guide, Release 12.4T" at the
following link 
http://www.cisco.com/en/US/docs/ios/voice/fxs/configuration/guide/fsxsecur.html

Blocks Extensible Exchange Protocol
+----------------------------------

Any configuration or executable command that leverages Blocks
Extensible Exchange Protocol (BEEP) as a transport protocol is
vulnerable. The following example shows the vulnerable configuration
of the feature NETCONF over BEEP. NETCONF over BEEP using SASL is
also vulnerable.

    crypto key generate rsa general-keys
    crypto pki trustpoint my_trustpoint
    enrollment url http://10.2.3.3:80
    subject-name CN=dns_name_of_host.com
    revocation-check none

    crypto pki authenticate my_trustpoint
    crypto pki enroll my_trustpoint

    line vty 0 15
    netconf lock-time 60
    netconf max-sessions 16

    netconf beep initiator host1 23 user my_user password
       my_password encrypt my_trustpoint
    reconnect-time 60

    netconf beep listener 23 sasl user1 encrypt my_trustpoint

The TCP port used is defined with the "netconf beep initiator" and
"netconf beep listener" configuration commands.

Further information about NETCONF over BEEP is in the "Cisco IOS
Software Release 12.4T feature guide" at the following link 
http://www.cisco.com/en/US/docs/ios/12_4t/12_4t11/htnetbe.html#wp1049404

The BEEP executable commands "bingd" and "bingng" could cause this
vulnerability to be triggered when they are invoked. The following
shows an example of these commands being executed:

    bingng device 192.168.0.1 23
    bingd device 23

Network Admission Control HTTP Authentication Proxy
+--------------------------------------------------

Devices configured with Network Admission Control HTTP Authentication
Proxy are vulnerable. For the device to be vulnerable the
authentication proxy rule must exist and be applied to an interface.

The following configuration creates an authentication proxy rule.

    ip admission name example-ap-rule-name proxy http

The following configuration attaches the authentication proxy rule
(created in the previous example) to an interface.

    interface GigabitEthernet 0/0
     ip admission example-ap-rule-name

The default TCP port used for Network Admission Control HTTP
Authentication Proxy is 80.

Further information about Network Admission Control HTTP
Authentication Proxy is in the "Cisco IOS Security Configuration
Guide, Release 12.4" at the following link 
http://www.cisco.com/en/US/docs/ios/security/configuration/guide/sec_net_admssn_ctrl_ps6350_TSD_Products_Configuration_Guide_Chapter.html#wp1053957

Per-user URL Redirect for EAPoUDP, Dot1x, and MAC Authentication Bypass
+----------------------------------------------------------------------

Devices that have URL redirect feature configured are vulnerable. URL
redirect is supported for EAP over UDP (EAPoUDP), Dot1x and MAC
Authentication Bypass (MAB) authentication mechanisms. The URL
redirect configuration can either be on the server or set up as part
of a locally defined profile or policy. Both configurations are
vulnerable. A device is vulnerable with either of the following
configurations.

URL Redirect Feature Enabled for EAPoUDP
+---------------------------------------

The URL redirect feature is enabled for EAPoUDP with the following
global configuration command:

    ip admission name <EAPoUDP-rule-name> eapoudp

The following configuration attaches the EAPoUDP rule (created in the
previous example) to an interface.

    ip admission name <EAPoUDP-rule-name>

URL Redirect Feature Enabled for Dot1x and MAB
+---------------------------------------------

The URL redirect feature for both Dot1x and MAB are vulnerable and
will have a URL redirect AV pair on the RADIUS server defined in a
method that is similar to the following:

    url-redirect="http://example.com"
    url-redirect="urlacl"

For the Dot1x and MAB URL redirect feature to work successfully on
the switch, the minimum following configuration would also be
required. There is no interface-specific configuration for URL
redirect. Basically the interface has to be configured for Dot1x/MAB.

    ip http {server | secure-server}
    ip device tracking

The default TCP port used for per-user URL redirect for EAPoUDP,
Dot1x, and MAB is 80 and 443.

Further information about per-user URL redirect for EAPoUDP, Dot1x,
and MAB is in the "Catalyst 4500 Series Switch Software Configuration
Guide, 12.2(50)SG" at the following link 
http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/50sg/configuration/guide/dot1x.html#wp1311079

Distributed Director with HTTP Redirects
+---------------------------------------

A device is vulnerable if Distributed Director is configured with
HTTP redirects. The following example shows a vulnerable
configuration:

    ip director ip-address 192.168.0.1

The default TCP port used for distributed director with HTTP redirect
is 53.

Further information about Distributed Director with HTTP redirects is
in "Distributed Director Configuration Example Overview" at the
following link 
http://www.cisco.com/en/US/products/hw/contnetw/ps813/products_tech_note09186a00801fa9dd.shtml#topic8b

DNS
+--

Devices that are configured with the Cisco IOS DNS feature are
vulnerable. A pure DNS over UDP implementation is not vulnerable. See
the "Workarounds" section of this advisory for information about
filtering DNS over TCP traffic to the device. If any of the commands
in the following example appear in the device configuration, the
device is vulnerable:

    ip dns server
    ip dns primary example.com soa www.example.com admin at example.com
    ip dns spoofing 192.168.0.1

The default TCP port used for DNS is 53.

Further information about Cisco IOS DNS is in the "Cisco IOS IP
Addressing Services Configuration Guide, Release 12.4" at the
following link 
http://www.cisco.com/en/US/docs/ios/ipaddr/configuration/guide/iad_config_dns_ps6350_TSD_Products_Configuration_Guide_Chapter.html

This vulnerability is documented in the following Cisco Bug ID:
CSCsm27071 and has been assigned the Common Vulnerabilities and
Exposures (CVE) identifiers CVE-2009-0630.

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

CSCsm27071: Cisco IOS Software Multiple Features IP Sockets

CVSS Base Score - 7.8

 Access Vector           - Network
 Access Complexity       - Low
 Authentication          - None
 Confidentiality Impact  - None
 Integrity Impact        - None
 Availability Impact     - Complete

CVSS Temporal Score - 6.4

 Exploitability          - Functional
 Remediation Level       - Official-Fix
 Report Confidence       - Confirmed

Impact
======

Successful exploitation of the vulnerability may result in the any of
the following occurring:

  * The configured feature may stop accepting new connections or
    sessions.
  * The memory of the device may be consumed.
  * The device may experience prolonged high CPU utilization.
  * The device may reload.

Repeated attempts to exploit this vulnerability could result in a
sustained DoS condition.

Software Versions and Fixes
===========================

When considering software upgrades, also consult 
http://www.cisco.com/go/psirt and any subsequent advisories to 
determine exposure and a complete upgrade solution.

In all cases, customers should exercise caution to be certain the
devices to be upgraded contain sufficient memory and that current
hardware and software configurations will continue to be supported
properly by the new release. If the information is not clear, contact
the Cisco Technical Assistance Center (TAC) or your contracted
maintenance provider for assistance.

Each row of the Cisco IOS software table (below) names a Cisco IOS
release train. If a given release train is vulnerable, then the
earliest possible releases that contain the fix (along with the
anticipated date of availability for each, if applicable) are listed
in the "First Fixed Release" column of the table. The "Recommended
Release" column indicates the releases which have fixes for all the
published vulnerabilities at the time of this Advisory. A device
running a release in the given train that is earlier than the release
in a specific column (less than the First Fixed Release) is known to
be vulnerable. Cisco recommends upgrading to a release equal to or
later than the release in the "Recommended Releases" column of the
table.

+-------------------------------------------------------------------+
|   Major    |          Availability of Repaired Releases           |
|  Release   |                                                      |
|------------+------------------------------------------------------|
| Affected   |                                     | Recommended    |
| 12.0-Based | First Fixed Release                 | Release        |
| Releases   |                                     |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0       | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0DA     | Vulnerable; first fixed in 12.2DA   | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0DB     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0DC     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.0S      | 12.0(32)S12                         | 12.0(32)S12    |
|------------+-------------------------------------+----------------|
| 12.0SC     | Vulnerable; first fixed in 12.0S    | 12.0(32)S12    |
|------------+-------------------------------------+----------------|
| 12.0SL     | Vulnerable; first fixed in 12.0S    | 12.0(32)S12    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0SP     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.0ST     | Vulnerable; first fixed in 12.0S    | 12.0(32)S12    |
|------------+-------------------------------------+----------------|
| 12.0SX     | Vulnerable; first fixed in 12.0S    | 12.0(32)S12    |
|------------+-------------------------------------+----------------|
| 12.0SY     | 12.0(32)SY8                         | 12.0(32)SY8    |
|------------+-------------------------------------+----------------|
| 12.0SZ     | Vulnerable; first fixed in 12.0S    | 12.0(32)S12    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0T      | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.0W      | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.0WC     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.0WT     | Not Vulnerable                      |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0XA     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0XB     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0XC     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0XD     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0XE     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.0XF     | Not Vulnerable                      |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0XG     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0XH     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            | Releases prior to 12.0(4)XI2 are    | 12.4(18e)      |
|            | vulnerable, release 12.0(4)XI2 and  |                |
| 12.0XI     | later are not vulnerable; first     | 12.4(23a);     |
|            | fixed in 12.4                       | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0XJ     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0XK     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0XL     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0XM     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0XN     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0XQ     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0XR     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0XS     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0XT     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0XV     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| Affected   |                                     | Recommended    |
| 12.1-Based | First Fixed Release                 | Release        |
| Releases   |                                     |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1       | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.1AA     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.1AX     | Vulnerable; first fixed in 12.2SE   | 12.2(44)SE6    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.1(22)EA13   |
| 12.1AY     | Vulnerable; first fixed in 12.1EA   |                |
|            |                                     | 12.2(44)SE6    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.1(22)EA13   |
| 12.1AZ     | Vulnerable; first fixed in 12.1EA   |                |
|            |                                     | 12.2(44)SE6    |
|------------+-------------------------------------+----------------|
| 12.1CX     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1DA     | Vulnerable; first fixed in 12.2DA   | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.1DB     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.1DC     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.1E      | Vulnerable; first fixed in 12.2SXF  | 12.2(18)SXF16  |
|------------+-------------------------------------+----------------|
| 12.1EA     | 12.1(22)EA13                        | 12.1(22)EA13   |
|------------+-------------------------------------+----------------|
| 12.1EB     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.2(33)SCB1   |
| 12.1EC     | Vulnerable; first fixed in 12.3BC   |                |
|            |                                     | 12.3(23)BC6    |
|------------+-------------------------------------+----------------|
| 12.1EO     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.1EU     | Vulnerable; first fixed in 12.2SG   | 12.2(31)SGA9   |
|------------+-------------------------------------+----------------|
| 12.1EV     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.1EW     | Vulnerable; migrate to 12.2SGA      |                |
|------------+-------------------------------------+----------------|
| 12.1EX     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.1EY     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.1EZ     | Vulnerable; first fixed in 12.2SXF  | 12.2(18)SXF16  |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1GA     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1GB     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1T      | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XA     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XB     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XC     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XD     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XE     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XF     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XG     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XH     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XI     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XJ     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XL     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XM     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XP     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XQ     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XR     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XS     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XT     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XU     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XV     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XW     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XX     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XY     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XZ     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1YA     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1YB     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1YC     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1YD     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            | Releases prior to 12.1(5)YE6 are    | 12.4(18e)      |
|            | vulnerable, release 12.1(5)YE6 and  |                |
| 12.1YE     | later are not vulnerable; first     | 12.4(23a);     |
|            | fixed in 12.4                       | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1YF     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1YH     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.1YI     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.1(22)EA13   |
| 12.1YJ     | Vulnerable; first fixed in 12.1EA   |                |
|            |                                     | 12.2(44)SE6    |
|------------+-------------------------------------+----------------|
| Affected   |                                     | Recommended    |
| 12.2-Based | First Fixed Release                 | Release        |
| Releases   |                                     |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2       | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.2B      | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            | Vulnerable; migrate to 12.2SCB1 or  | 12.2(33)SCB1   |
| 12.2BC     | 12.3BC                              |                |
|            |                                     | 12.3(23)BC6    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2BW     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.2BX     | Vulnerable; migrate to 12.2SB4      | 12.2(33)SB4    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2BY     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2BZ     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            | Vulnerable; migrate to 12.2SCB or   | 12.2(33)SCB1   |
| 12.2CX     | 12.3BC                              |                |
|            |                                     | 12.3(23)BC6    |
|------------+-------------------------------------+----------------|
|            | Vulnerable; migrate to 12.2SCB or   | 12.2(33)SCB1   |
| 12.2CY     | 12.3BC                              |                |
|            |                                     | 12.3(23)BC6    |
|------------+-------------------------------------+----------------|
| 12.2CZ     | Vulnerable; first fixed in 12.2SB   | 12.2(33)SB4    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            | 12.2(12)DA14; Available on          |                |
| 12.2DA     | 30-JUL-2009                         | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2DD     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2DX     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.2EW     | Vulnerable; first fixed in 12.2SG   | 12.2(31)SGA9   |
|------------+-------------------------------------+----------------|
| 12.2EWA    | Vulnerable; first fixed in 12.2SG   | 12.2(31)SGA9   |
|------------+-------------------------------------+----------------|
| 12.2EX     | Vulnerable; first fixed in 12.2SE   | 12.2(44)SE6    |
|------------+-------------------------------------+----------------|
| 12.2EY     | 12.2(44)EY                          | 12.2(44)SE6    |
|------------+-------------------------------------+----------------|
| 12.2EZ     | Vulnerable; first fixed in 12.2SE   | 12.2(44)SE6    |
|------------+-------------------------------------+----------------|
| 12.2FX     | Vulnerable; first fixed in 12.2SE   | 12.2(44)SE6    |
|------------+-------------------------------------+----------------|
| 12.2FY     | Vulnerable; first fixed in 12.2SE   | 12.2(44)SE6    |
|------------+-------------------------------------+----------------|
| 12.2FZ     | Vulnerable; first fixed in 12.2SE   | 12.2(44)SE6    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.2(33)SRC4;  |
| 12.2IRA    | Vulnerable; first fixed in 12.2SRC  | Available on   |
|            |                                     | 18-MAY-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.2(33)SRC4;  |
| 12.2IRB    | Vulnerable; first fixed in 12.2SRC  | Available on   |
|            |                                     | 18-MAY-2009    |
|------------+-------------------------------------+----------------|
|            | Vulnerable; migrate to any release  | 12.2(18)IXH;   |
| 12.2IXA    | in 12.2IXH                          | Available on   |
|            |                                     | 31-MAR-2009    |
|------------+-------------------------------------+----------------|
|            | Vulnerable; migrate to any release  | 12.2(18)IXH;   |
| 12.2IXB    | in 12.2IXH                          | Available on   |
|            |                                     | 31-MAR-2009    |
|------------+-------------------------------------+----------------|
|            | Vulnerable; migrate to any release  | 12.2(18)IXH;   |
| 12.2IXC    | in 12.2IXH                          | Available on   |
|            |                                     | 31-MAR-2009    |
|------------+-------------------------------------+----------------|
|            | Vulnerable; migrate to any release  | 12.2(18)IXH;   |
| 12.2IXD    | in 12.2IXH                          | Available on   |
|            |                                     | 31-MAR-2009    |
|------------+-------------------------------------+----------------|
|            | Vulnerable; migrate to any release  | 12.2(18)IXH;   |
| 12.2IXE    | in 12.2IXH                          | Available on   |
|            |                                     | 31-MAR-2009    |
|------------+-------------------------------------+----------------|
|            | Vulnerable; migrate to any release  | 12.2(18)IXH;   |
| 12.2IXF    | in 12.2IXH                          | Available on   |
|            |                                     | 31-MAR-2009    |
|------------+-------------------------------------+----------------|
|            | Vulnerable; migrate to any release  | 12.2(18)IXH;   |
| 12.2IXG    | in 12.2IXH                          | Available on   |
|            |                                     | 31-MAR-2009    |
|------------+-------------------------------------+----------------|
| 12.2JA     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.2JK     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2MB     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.2MC     | 12.2(15)MC2m                        | 12.2(15)MC2m   |
|------------+-------------------------------------+----------------|
| 12.2S      | Vulnerable; first fixed in 12.2SB   | 12.2(33)SB4    |
|------------+-------------------------------------+----------------|
|            | 12.2(31)SB14                        |                |
|            |                                     |                |
| 12.2SB     | 12.2(33)SB1                         | 12.2(33)SB4    |
|            |                                     |                |
|            | 12.2(28)SB13                        |                |
|------------+-------------------------------------+----------------|
| 12.2SBC    | Vulnerable; first fixed in 12.2SB   | 12.2(33)SB4    |
|------------+-------------------------------------+----------------|
| 12.2SCA    | 12.2(33)SCA2                        | 12.2(33)SCB1   |
|------------+-------------------------------------+----------------|
| 12.2SCB    | Not Vulnerable                      |                |
|------------+-------------------------------------+----------------|
|            | 12.2(50)SE                          |                |
|            |                                     |                |
| 12.2SE     | 12.2(46)SE2                         | 12.2(44)SE6    |
|            |                                     |                |
|            | 12.2(44)SE5                         |                |
|------------+-------------------------------------+----------------|
| 12.2SEA    | Vulnerable; first fixed in 12.2SE   | 12.2(44)SE6    |
|------------+-------------------------------------+----------------|
| 12.2SEB    | Vulnerable; first fixed in 12.2SE   | 12.2(44)SE6    |
|------------+-------------------------------------+----------------|
| 12.2SEC    | Vulnerable; first fixed in 12.2SE   | 12.2(44)SE6    |
|------------+-------------------------------------+----------------|
| 12.2SED    | Vulnerable; first fixed in 12.2SE   | 12.2(44)SE6    |
|------------+-------------------------------------+----------------|
| 12.2SEE    | Vulnerable; first fixed in 12.2SE   | 12.2(44)SE6    |
|------------+-------------------------------------+----------------|
| 12.2SEF    | Vulnerable; first fixed in 12.2SE   | 12.2(44)SE6    |
|------------+-------------------------------------+----------------|
| 12.2SEG    | Vulnerable; first fixed in 12.2SE   | 12.2(44)SE6    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.2(52)SG;    |
| 12.2SG     | 12.2(50)SG                          | Available on   |
|            |                                     | 15-MAY-2009    |
|------------+-------------------------------------+----------------|
| 12.2SGA    | 12.2(31)SGA9                        | 12.2(31)SGA9   |
|------------+-------------------------------------+----------------|
| 12.2SL     | Not Vulnerable                      |                |
|------------+-------------------------------------+----------------|
| 12.2SM     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2SO     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2SQ     | Not Vulnerable                      |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.2(33)SRC4;  |
| 12.2SRA    | Vulnerable; first fixed in 12.2SRC  | Available on   |
|            |                                     | 18-MAY-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.2(33)SRB5a; |
|            |                                     | Available on   |
|            |                                     | 3-April-2009   |
| 12.2SRB    | Vulnerable; first fixed in 12.2SRC  |                |
|            |                                     | 12.2(33)SRC4;  |
|            |                                     | Available on   |
|            |                                     | 18-MAY-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.2(33)SRC4;  |
| 12.2SRC    | 12.2(33)SRC1                        | Available on   |
|            |                                     | 18-MAY-2009    |
|------------+-------------------------------------+----------------|
| 12.2SRD    | Not Vulnerable                      |                |
|------------+-------------------------------------+----------------|
| 12.2STE    | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.2SU     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.2SV     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2SVA    | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2SVC    | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2SVD    | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2SVE    | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2SW     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2SX     | Vulnerable; first fixed in 12.2SXF  | 12.2(18)SXF16  |
|------------+-------------------------------------+----------------|
| 12.2SXA    | Vulnerable; first fixed in 12.2SXF  | 12.2(18)SXF16  |
|------------+-------------------------------------+----------------|
| 12.2SXB    | Vulnerable; first fixed in 12.2SXF  | 12.2(18)SXF16  |
|------------+-------------------------------------+----------------|
| 12.2SXD    | Vulnerable; first fixed in 12.2SXF  | 12.2(18)SXF16  |
|------------+-------------------------------------+----------------|
| 12.2SXE    | Vulnerable; first fixed in 12.2SXF  | 12.2(18)SXF16  |
|------------+-------------------------------------+----------------|
| 12.2SXF    | 12.2(18)SXF16                       | 12.2(18)SXF16  |
|------------+-------------------------------------+----------------|
|            | 12.2(33)SXH5; Available on          | 12.2(33)SXH5;  |
| 12.2SXH    | 20-APR-2009                         | Available on   |
|            |                                     | 20-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.2SXI    | Not Vulnerable                      |                |
|------------+-------------------------------------+----------------|
| 12.2SY     | Vulnerable; first fixed in 12.2SB   | 12.2(33)SB4    |
|------------+-------------------------------------+----------------|
| 12.2SZ     | Vulnerable; first fixed in 12.2SB   | 12.2(33)SB4    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2T      | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.2TPC    | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XA     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XB     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XC     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XD     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XE     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            | Vulnerable; migrate to 12.2SCB or   | 12.2(33)SCB1   |
| 12.2XF     | 12.3BC                              |                |
|            |                                     | 12.3(23)BC6    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XG     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XH     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XI     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XJ     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XK     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XL     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XM     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.2(33)SB4    |
| 12.2XN     | Vulnerable; first fixed in 12.2SRC  |                |
|            |                                     | 12.2(33)SRD1   |
|------------+-------------------------------------+----------------|
| 12.2XNA    | Vulnerable; migrate to any release  | 12.2(33)SRD1   |
|            | in 12.2SRD                          |                |
|------------+-------------------------------------+----------------|
| 12.2XNB    | Not Vulnerable                      |                |
|------------+-------------------------------------+----------------|
| 12.2XNC    | Not Vulnerable                      |                |
|------------+-------------------------------------+----------------|
| 12.2XO     | 12.2(46)XO                          | 12.2(46)XO     |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XQ     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XR     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XS     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XT     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XU     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XV     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XW     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2YA     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.2YB     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YC     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YD     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YE     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YF     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YG     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YH     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YJ     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YK     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YL     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.2YM     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.2YN     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YO     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2YP     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.2YQ     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YR     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YS     | Not Vulnerable                      |                |
|------------+-------------------------------------+----------------|
| 12.2YT     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YU     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YV     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YW     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YX     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YY     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YZ     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2ZA     | Vulnerable; first fixed in 12.2SXF  | 12.2(18)SXF16  |
|------------+-------------------------------------+----------------|
| 12.2ZB     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2ZC     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2ZD     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2ZE     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.2ZF     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.2ZG     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2ZH     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.2ZJ     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2ZL     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2ZP     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.2(33)SXH5;  |
| 12.2ZU     | Vulnerable; first fixed in 12.2SXH  | Available on   |
|            |                                     | 20-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.2ZX     | Vulnerable; first fixed in 12.2SB   | 12.2(33)SB4    |
|------------+-------------------------------------+----------------|
| 12.2ZY     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2ZYA    | 12.2(18)ZYA1                        | 12.2(18)ZYA1   |
|------------+-------------------------------------+----------------|
| Affected   |                                     | Recommended    |
| 12.3-Based | First Fixed Release                 | Release        |
| Releases   |                                     |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.3       | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3B      | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.3BC     | 12.3(23)BC6                         | 12.3(23)BC6    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3BW     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.3EU     | Not Vulnerable                      |                |
|------------+-------------------------------------+----------------|
| 12.3JA     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.3JEA    | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.3JEB    | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.3JEC    | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3JK     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.3JL     | Vulnerable; first fixed in 12.4JK   |                |
|------------+-------------------------------------+----------------|
| 12.3JX     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3T      | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.3TPC    | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.3VA     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.3XA     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.3XB     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3XC     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3XD     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.3XE     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.3XF     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3XG     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.3XI     | Vulnerable; first fixed in 12.2SB   | 12.2(33)SB4    |
|------------+-------------------------------------+----------------|
| 12.3XJ     | Vulnerable; first fixed in 12.3YX   | 12.3(14)YX14   |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3XK     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3XL     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3XQ     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.3XR     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3XS     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3XU     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.3XW     | Vulnerable; first fixed in 12.3YX   | 12.3(14)YX14   |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3XX     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3XY     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3XZ     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3YA     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3YD     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.3YF     | Vulnerable; first fixed in 12.3YX   | 12.3(14)YX14   |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3YG     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3YH     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3YI     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3YJ     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3YK     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.3YM     | 12.3(14)YM13                        | 12.3(14)YM13   |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3YQ     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3YS     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3YT     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3YU     | Vulnerable; first fixed in 12.4XB   | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.3YX     | 12.3(14)YX14                        | 12.3(14)YX14   |
|------------+-------------------------------------+----------------|
| 12.3YZ     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3ZA     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
| Affected   |                                     | Recommended    |
| 12.4-Based | First Fixed Release                 | Release        |
| Releases   |                                     |                |
|------------+-------------------------------------+----------------|
|            | 12.4(19)                            | 12.4(18e)      |
|            |                                     |                |
| 12.4       | 12.4(18a)                           | 12.4(23a);     |
|            |                                     | Available on   |
|            | 12.4(23a); Available on 30-APR-2009 | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.4JA     | 12.4(16b)JA1                        |                |
|------------+-------------------------------------+----------------|
| 12.4JDA    | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.4JK     | 12.4(3)JK4                          |                |
|------------+-------------------------------------+----------------|
| 12.4JL     | 12.4(3)JL1                          |                |
|------------+-------------------------------------+----------------|
| 12.4JMA    | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.4JMB    | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.4JX     | Vulnerable; first fixed in 12.4JA   |                |
|------------+-------------------------------------+----------------|
| 12.4MD     | 12.4(11)MD7                         | 12.4(11)MD7    |
|------------+-------------------------------------+----------------|
| 12.4MR     | 12.4(19)MR                          | 12.4(19)MR2    |
|------------+-------------------------------------+----------------|
| 12.4SW     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
|            | 12.4(20)T                           | 12.4(22)T1     |
|            |                                     |                |
| 12.4T      | 12.4(15)T8                          | 12.4(15)T9;    |
|            |                                     | Available on   |
|            | 12.4(15)T9; Available on            | 29-APR-2009    |
|            | 29-APR-2009                         |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.4XA     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            | 12.4(15)T8                          |                |
| 12.4XB     |                                     | 12.4(15)T9;    |
|            | 12.4(20)T                           | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.4XC     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            | 12.4(4)XD12; Available on           | 12.4(4)XD12;   |
| 12.4XD     | 27-MAR-2009                         | Available on   |
|            |                                     | 27-MAR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.4XE     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.4XF     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.4XG     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.4XJ     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.4XK     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.4XL     | 12.4(15)XL4                         | 12.4(15)XL4    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.4XM     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.4XN     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.4XP     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.4XQ     | 12.4(15)XQ2                         | 12.4(15)XQ2    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.4XR     | 12.4(15)XR4                         | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.4XT     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.4XV     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.4XW     | 12.4(11)XW10                        | 12.4(11)XW10   |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.4XY     | 12.4(15)XY4                         | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.4XZ     | Not Vulnerable                      |                |
|------------+-------------------------------------+----------------|
| 12.4YA     | Not Vulnerable                      |                |
|------------+-------------------------------------+----------------|
| 12.4YB     | Not Vulnerable                      |                |
|------------+-------------------------------------+----------------|
| 12.4YD     | Not Vulnerable                      |                |
+-------------------------------------------------------------------+

Workarounds
===========

The following mitigations have been identified for this
vulnerability:

Infrastructure Access Control Lists
+----------------------------------

Although it is often difficult to block traffic that transits a
network, it is possible to identify traffic that should never be
allowed to target infrastructure devices and block that traffic at
the border of networks. Infrastructure Access Control Lists (iACLs)
are a network security best practice and should be considered as a
long-term addition to good network security as well as a workaround
for these specific vulnerabilities. The iACL example below should be
included as part of the deployed infrastructure access-list which
will protect all devices with IP addresses in the infrastructure IP
address range:


    !--- Only sections pertaining to features enabled on the device
    !--- need be configured.
    !---
    !--- Feature: Cisco Unified Communications Manager Express 
    !---
    !--- CAPF server configuration
    !---

    access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD
         INFRASTRUCTURE_ADDRESSES WILDCARD eq 3804

    !---
    !--- Telephony-Service configuration
    !--- The TCP port is as per the ip source-address
    !--- <ip-address> port <port-number> telephony
    !--- service configuration command.  Example below 2999
    !--- 

    access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD
         INFRASTRUCTURE_ADDRESSES WILDCARD eq 2999

    !---
    !--- Deny Cisco Unified Communications Manager Express traffic 
    !--- from all other sources destined to infrastructure addresses.
    !---

    access-list 150 deny tcp any
         INFRASTRUCTURE_ADDRESSES WILDCARD eq 3804
    access-list 150 deny tcp any
         INFRASTRUCTURE_ADDRESSES WILDCARD eq 2999

    !---
    !--- Feature: SIP Gateway Signaling Support Over TLS Transport
    !---

    access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD
         INFRASTRUCTURE_ADDRESSES WILDCARD eq 5061

    !--- Deny SIP Gateway Signaling Support Over TLS Transport 
    !--- traffic from all other sources destined to infrastructure 
    !--- addresses.

    access-list 150 deny tcp any
         INFRASTRUCTURE_ADDRESSES WILDCARD eq 5061

    !---
    !--- Feature: Secure Signaling and Media Encryption
    !---

    access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD
         INFRASTRUCTURE_ADDRESSES WILDCARD eq 2443

    !--- Deny Secure Signaling and Media Encryption traffic from all 
    !--- other sources destined to infrastructure addresses.

    access-list 150 deny tcp any
         INFRASTRUCTURE_ADDRESSES WILDCARD eq 2443

    !---
    !--- Feature: Blocks Extensible Exchange Protocol (BEEP)
    !--- The TCP port used is defined with the netconf beep initiator 
    !--- and netconf beep listener configuration
    !--- commands.  This example uses 3001
    !---

    access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD
         INFRASTRUCTURE_ADDRESSES WILDCARD eq 3001

    !--- Deny BEEP traffic from all other sources destined to 
    !--- infrastructure addresses.

    access-list 150 deny tcp any
         INFRASTRUCTURE_ADDRESSES WILDCARD eq 3001

    !---
    !--- Feature: Network Admission Control HTTP Authentication Proxy
    !--- and
    !--- Per-user URL Redirect for EAP over UDP, Dot1x and MAC 
    !--- Authentication Bybass
    !---

    access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD
         INFRASTRUCTURE_ADDRESSES WILDCARD eq 80
    access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD
         INFRASTRUCTURE_ADDRESSES WILDCARD eq 443

    !---
    !--- Deny Network Admission Control HTTP Authentication Proxy
    !--- and
    !--- Per-user URL Redirect for EAP over UDP, Dot1x and MAC 
    !--- Authentication Bybass traffic to infrastructue
    !---

    access-list 150 deny tcp any
         INFRASTRUCTURE_ADDRESSES WILDCARD eq 80
    access-list 150 deny tcp any
         INFRASTRUCTURE_ADDRESSES WILDCARD eq 443

    !---
    !--- Features: Distributed Director with HTTP Redirects and DNS
    !---

    access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD
         INFRASTRUCTURE_ADDRESSES WILDCARD eq 53

    !--- Deny Distributed Director with HTTP Redirects traffic and DNS 
    !--- from all other sources destined to infrastructure addresses.

    access-list 150 deny tcp any
         INFRASTRUCTURE_ADDRESSES WILDCARD eq 53

    !--- Permit/deny all other Layer 3 and Layer 4 traffic in 
    !--- accordance with existing security policies and configurations
    !--- Permit all other traffic to transit the device.

    access-list 150 permit ip any any

    !--- Apply access-list to all interfaces (only one example shown)

    interface serial 2/0
    ip access-group 150 in

The white paper entitled "Protecting Your Core: Infrastructure
Protection Access Control Lists" presents guidelines and recommended
deployment techniques for infrastructure protection access lists.
This white paper can be obtained at the following link 
http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801a1a55.shtml

Receive ACLs (rACL)
+------------------

For distributed platforms, Receive ACLs may be an option starting in
Cisco IOS Software Versions 12.0(21)S2 for the 12000 (GSR), 12.0(24)S
for the 7500, and 12.0(31)S for the 10720. The Receive ACL protects
the device from harmful traffic before the traffic can impact the
route processor. Receive ACLs are designed to only protect the device
on which it is configured. On the 12000, 7500, and 10720, transit
traffic is never affected by a receive ACL. Because of this, the
destination IP address "any" used in the example ACL entries below
only refer to the router's own physical or virtual IP addresses.
Receive ACLs are considered a network security best practice, and
should be considered as a long-term addition to good network
security, as well as a workaround for this specific vulnerability.
The white paper entitled "GSR: Receive Access Control Lists" will
help you identify and allow legitimate traffic to your device and
deny all unwanted packets. This white paper is available at the
following link 
http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801a0a5e.shtml

The following is the receive path ACL written to permit this type of
traffic from trusted hosts:


    !---
    !--- Only sections pertaining to features enabled on the device
    !--- need be configured.
    !---

    !---
    !--- Feature: Cisco Unified Communications Manager Express 
    !---
    !---

    !---
    !--- Permit CAPF server traffic from trusted hosts allowed to 
    !--- the RP.
    !---

    access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD
         any eq 3804

    !---
    !--- Telephony-Service configuration
    !---

    !---
    !--- The TCP port is as per the ip source-address
    !--- <address> port <port-number> telephony-service 
    !--- configuration command.  Example below 2999
    !---
    !--- Permit Telephony-Service traffic from trusted hosts allowed 
    !--- to the RP.

    access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD
         any eq 2999

    !---
    !--- Deny Cisco Unified Communications Manager Express 
    !--- traffic from all other sources to the RP.
    !---

    access-list 150 deny tcp any any eq 3804
    access-list 150 deny tcp any any eq 2999

    !---
    !--- Permit SIP Gateway Signaling Support Over TLS Transport
    !--- traffic from trusted hosts allowed to the RP.
    !---

    access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD
         any eq 5061

    !---
    !--- Deny SIP Gateway Signaling Support Over TLS Transport 
    !--- traffic from all other sources to the RP.
    !---

    access-list 150 deny tcp any any eq 5061

    !---
    !--- Permit Secure Signaling and Media Encryption traffic 
    !--- from trusted hosts allowed to the RP.
    !---

    access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD
         any eq 2443

    !---
    !--- Deny Secure Signaling and Media Encryption traffic from 
    !--- all other sources to the RP.
    !---

    access-list 150 deny tcp any any eq 2443

    !---
    !--- Feature: Blocks Extensible Exchange Protocol (BEEP)
    !--- The TCP port used is defined with the netconf beep initiator 
    !--- and netconf beep listener configuration commands.  
    !--- This example uses 3001
    !---

    !---
    !--- Permit BEEP traffic from trusted hosts allowed to the RP.
    !---

    access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD
         any eq 3001

    !---
    !--- Deny BEEP traffic from all other sources to the RP.
    !---

    access-list 150 deny tcp any any eq 3001

    !---
    !--- Feature: Network Admission Control HTTP Authentication Proxy
    !--- and
    !--- Per-user URL Redirect for EAP over UDP, Dot1x and MAC 
    !--- Authentication Bybass
    !---

    !---
    !--- Permit Per-user URL Redirect for EAP over UDP, Dot1x and MAC 
    !--- Authentication Bybass traffic from trusted hosts allowed to 
    !--- the RP.
    !---

    access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD
         any eq 80
    access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD
         any eq 443

    !---
    !--- Deny Network Admission Control HTTP Authentication Proxy
    !--- and
    !--- Per-user URL Redirect for EAP over UDP, Dot1x and MAC 
    !--- Authentication Bybass traffic from all other sources to 
    !--- the RP.
    !---

    access-list 150 deny tcp any any eq 80
    access-list 150 deny tcp any any eq 443

    !---
    !--- Features: Distributed Director with HTTP Redirects and DNS
    !---

    !---
    !--- Permit Distribute Director and DNS traffic from trusted hosts
    !--- allowed to the RP.
    !---

    access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD
         any eq 53

    !---
    !--- Deny distributed director and DNS traffic from all other 
    !--- sources to the RP.
    !---

    access-list 150 deny tcp any any eq 53

    !---
    !--- Permit all other traffic to the RP.
    !--- according to security policy and configurations.
    !---

    access-list 150 permit ip any any

    !---
    !--- Apply this access list to the 'receive' path.
    !---

    ip receive access-list 150

Control Plane Policing
+---------------------

Control Plane Policing (CoPP) can be used to block the affected
features TCP traffic access to the device. Cisco IOS software
releases 12.0S, 12.2SX, 12.2S, 12.3T, 12.4, and 12.4T support the
CoPP feature. CoPP can be configured on a device to protect the
management and control planes and minimize the risk and effectiveness
of direct infrastructure attacks by explicitly permitting only
authorized traffic that is sent to infrastructure devices in
accordance with existing security policies and configurations. The
CoPP example below should be included as part of the deployed CoPP
which will protect all devices with IP addresses in the
infrastructure IP address range.


    !---
    !--- Only sections pertaining to features enabled on the device
    !--- need be configured.
    !---
    !--- Feature: Cisco Unified Communications Manager Express
    !---
    !--- CAPF Server configuration
    !---

    access-list 150 deny tcp TRUSTED_SOURCE_ADDRESSES WILDCARD
       any eq 3804

    !---
    !--- Telephony-Service configuration
    !--- The TCP port is as per the ip source-address
    !--- <address> port <port-number> telephony-service
    !--- configuration command.  Example below 2999
    !---

    access-list 150 deny tcp TRUSTED_SOURCE_ADDRESSES WILDCARD
       any eq 2999

    !---
    !--- Permit Cisco Unified Communications Manager Express traffic 
    !--- sent to all IP addresses configured on all interfaces of 
    !--- the affected device so that it will be policed and dropped
    !--- by the CoPP feature
    !---
    !--- CAPF server configuration
    !---

    access-list 150 permit tcp any any eq 3804

    !---
    !--- Telephony-Service configuration
    !---

    access-list 150 permit tcp any any eq 2999

    !---
    !--- Feature: SIP Gateway Signaling Support Over TLS Transport
    !---

    access-list 150 deny tcp TRUSTED_SOURCE_ADDRESSES WILDCARD
       any eq 5061

    !---
    !--- Permit SIP Gateway Signaling Support Over TLS Transport 
    !--- traffic sent to all IP addresses configured on all interfaces
    !--- of the affected device so that it will be policed and  
    !--- dropped by the CoPP feature
    !--- 

    access-list 150 permit tcp any any eq 5061

    !---
    !--- Feature: Secure Signaling and Media Encryption
    !---

    access-list 150 deny tcp TRUSTED_SOURCE_ADDRESSES WILDCARD
       any eq 2443

    !---
    !--- Permit Secure Signaling and Media Encryption traffic sent to
    !--- all IP addresses configured on all interfaces of the affected 
    !--- device so that it will be policed and dropped by the CoPP 
    !--- feature
    !---

    access-list 150 permit tcp any any eq 2443

    !---
    !--- Feature: Blocks Extensible Exchange Protocol (BEEP)
    !--- The TCP port used is defined with the netconf beep initiator 
    !--- and netconf beep listener configuration commands.  
    !--- This example uses 3001
    !---

    access-list 150 deny tcp TRUSTED_SOURCE_ADDRESSES WILDCARD
       any eq 3001

    !---
    !--- Permit BEEP traffic sent to all IP addresses configured
    !--- on all interfaces of the affected device so that it
    !--- will be policed and dropped by the CoPP feature
    !---

    access-list 150 permit tcp any any eq 3001

    !---
    !--- Feature: Network Admission Control HTTP Authentication Proxy
    !--- and
    !--- Per-user URL Redirect for EAP over UDP, Dot1x and MAC 
    !--- Authentication Bybass
    !---

    access-list 150 deny tcp TRUSTED_SOURCE_ADDRESSES WILDCARD
       any eq 80
    access-list 150 deny tcp TRUSTED_SOURCE_ADDRESSES WILDCARD
       any eq 443

    !---
    !--- Permit Network Admission Control HTTP Authentication Proxy
    !--- and Per-user URL Redirect for EAP over UDP, Dot1x and MAC 
    !--- Authentication Bybass traffic sent to all IP addresses
    !--- configured on all interfaces of the affected device so that it
    !--- will be policed and dropped by the CoPP feature
    !---

    access-list 150 permit tcp any any eq 80
    access-list 150 permit tcp any any eq 443

    !---
    !--- Features: Distributed Director with HTTP Redirects and DNS
    !---

    access-list 150 deny tcp TRUSTED_SOURCE_ADDRESSES WILDCARD
       any eq 53

    !---
    !--- Permit Distributed Director with HTTP Redirects and DNS 
    !--- traffic sent to all IP addresses configured on all interfaces
    !--- of the affected device so that it will be policed and dropped
    !--- by the CoPP feature
    !---

    access-list 150 permit tcp any any eq 53

    !---
    !--- Permit (Police or Drop)/Deny (Allow) all other Layer3 and
    !--- Layer4 traffic in accordance with existing security policies
    !--- and configurations for traffic that is authorized to be sent
    !--- to infrastructure devices
    !---

    !---
    !--- Create a Class-Map for traffic to be policed by
    !--- the CoPP feature
    !---

    class-map match-all drop-tcpip-class
    match access-group 150

    !---
    !--- Create a Policy-Map that will be applied to the
    !--- Control-Plane of the device.
    !---

    policy-map drop-tcpip-traffic

    class drop-tcpip-class
    drop

    !---
    !--- Apply the Policy-Map to the 
    !--- Control-Plane of the device
    !---

    control-plane
    service-policy input drop-tcpip-traffic

In the above CoPP example, the access control list entries (ACEs)
that match the potential exploit packets with the "permit" action
result in these packets being discarded by the policy-map "drop"
function, while packets that match the "deny" action (not shown) are
not affected by the policy-map drop function. Please note that the
policy-map syntax is different in the 12.2S and 12.0S Cisco IOS
trains:

    policy-map drop-tcpip-traffic
      class drop-tcpip-class
        police 32000 1500 1500 conform-action drop exceed-action drop

Additional information on the configuration and use of the CoPP
feature can be found in the documents, "Control Plane Policing
Implementation Best Practices" and "Cisco IOS Software Releases 12.2
S - Control Plane Policing" at the following links 
http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html and
http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gtrtlimt.html

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 at the following link 
http://www.cisco.com/warp/public/707/cisco-amb-20090325-tcp-and-ip.shtml

Obtaining Fixed Software
========================

Cisco has released free software updates that address these
vulnerabilities. Prior to deploying software, customers should
consult their maintenance provider or check the software for feature
set compatibility and known issues specific to their environment.

Customers may only install and expect support for the feature sets
they have purchased. By installing, downloading, accessing or
otherwise using such software upgrades, customers agree to be bound
by the terms of Cisco's software license terms found at 
http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html,
or as otherwise set forth at Cisco.com Downloads at 
http://www.cisco.com/public/sw-center/sw-usingswc.shtml

Do not contact psirt at cisco.com or security-alert at cisco.com for
software upgrades.

Customers with Service Contracts
+-------------------------------

Customers with contracts should obtain upgraded software through
their regular update channels. For most customers, this means that
upgrades should be obtained through the Software Center on Cisco's
worldwide website at http://www.cisco.com

Customers using Third Party Support Organizations
+------------------------------------------------

Customers whose Cisco products are provided or maintained through
prior or existing agreements with third-party support organizations,
such as Cisco Partners, authorized resellers, or service providers
should contact that support organization for guidance and assistance
with the appropriate course of action in regards to this advisory.

The effectiveness of any workaround or fix is dependent on specific
customer situations, such as product mix, network topology, traffic
behavior, and organizational mission. Due to the variety of affected
products and releases, customers should consult with their service
provider or support organization to ensure any applied workaround or
fix is the most appropriate for use in the intended network before it
is deployed.

Customers without Service Contracts
+----------------------------------

Customers who purchase direct from Cisco but do not hold a Cisco
service contract, and customers who purchase through third-party
vendors but are unsuccessful in obtaining fixed software through
their point of sale should acquire upgrades by contacting the Cisco
Technical Assistance Center (TAC). TAC contacts are as follows.

  * +1 800 553 2447 (toll free from within North America)
  * +1 408 526 7209 (toll call from anywhere in the world)
  * e-mail: tac at cisco.com

Customers should have their product serial number available and be
prepared to give the URL of this notice as evidence of entitlement to
a free upgrade. Free upgrades for non-contract customers must be
requested through the TAC.

Refer to http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html
for additional TAC contact information, including localized telephone 
numbers, and instructions and e-mail addresses for use in various 
languages.

Exploitation and Public Announcements
=====================================

The Cisco PSIRT is not aware of any public announcements or malicious
use of the vulnerability described in this advisory.

This vulnerability was discovered by Cisco when performing internal
vulnerability testing. We would also like to thank Jens Link,
freelance consultant, for also reporting this vulnerability to us.

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-20090325-tcpip.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-March-25 | 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-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAknKUasACgkQ86n/Gc8U/uBbjACeIwNWs1Rt18l5RAnnaMCvg4GA
kK0AnjoeX6PBI/y6tro0tjJUCfrAAr30
=Ijff
-----END PGP SIGNATURE-----

From psirt at cisco.com  Wed Mar 25 12:00:00 2009
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Wed, 25 Mar 2009 17:00:00 +0100
Subject: [c-nsp] Cisco Security Advisory: Cisco IOS Software Session
	Initiation Protocol Denial of Service Vulnerability
Message-ID: <200903251705.sip@psirt.cisco.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cisco Security Advisory: Cisco IOS Software Session Initiation
Protocol Denial of Service Vulnerability

Advisory ID: cisco-sa-20090325-sip

http://www.cisco.com/warp/public/707/cisco-sa-20090325-sip.shtml

Revision 1.0

For Public Release 2009 March 25 1600 UTC (GMT)

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

Summary
=======

A vulnerability exists in the Session Initiation Protocol (SIP)
implementation in Cisco IOS Software that can be exploited remotely
to cause a reload of the Cisco IOS device.

Cisco has released free software updates that address this
vulnerability. There are no workarounds available to mitigate the
vulnerability apart from disabling SIP, if the Cisco IOS device does
not need to run SIP for VoIP services. However, mitigation techniques
are available to help limit exposure to the vulnerability.

This advisory is posted at the following link: 
http://www.cisco.com/warp/public/707/cisco-sa-20090325-sip.shtml

Note: The March 25, 2009, Cisco IOS Security Advisory bundled
publication includes eight Security Advisories. All of the advisories
address vulnerabilities in Cisco IOS Software. Each advisory lists
the releases that correct the vulnerability or vulnerabilities in the
advisory. The following table lists releases that correct all Cisco
IOS Software vulnerabilities that have been published in Cisco
Security Advisories on March 25, 2009, or earlier.

http://www.cisco.com/warp/public/707/cisco-sa-20090325-bundle.shtml

Individual publication links are listed below:

  * Cisco IOS cTCP Denial of Service Vulnerability
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-ctcp.shtml

  * Cisco IOS Software Multiple Features IP Sockets Vulnerability
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-ip.shtml

  * Cisco IOS Software Mobile IP and Mobile IPv6 Vulnerabilities
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-mobileip.shtml

  * Cisco IOS Software Secure Copy Privilege Escalation Vulnerability
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-scp.shtml

  * Cisco IOS Software Session Initiation Protocol Denial of Service
    Vulnerability
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-sip.shtml

  * Cisco IOS Software Multiple Features Crafted TCP Sequence
    Vulnerability
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-tcp.shtml

  * Cisco IOS Software Multiple Features Crafted UDP Packet
    Vulnerability
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-udp.shtml

  * Cisco IOS Software WebVPN and SSLVPN Vulnerabilities
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-webvpn.shtml

Affected Products
=================

This vulnerability only affects devices running Cisco IOS Software
with SIP voice services enabled.

Vulnerable Products
+------------------

Cisco devices running affected Cisco IOS Software versions that
process SIP messages are affected. The only requirement for this
vulnerability is that the Cisco IOS device process SIP messages as
part of configured VoIP functionality. Note that this does not apply
to the processing of SIP messages as part of the NAT and firewall
feature sets.

Recent versions of Cisco IOS Software do not process SIP messages by
default. Creating a dial peer by way of the command dial-peer voice
will start the SIP processes and cause the Cisco IOS device to start
processing SIP messages. In addition, several features within Cisco
Unified Communications Manager Express, such as ePhones, once
configured will also automatically start the SIP process, which will
cause the device to start processing SIP messages. An example of an
affected configuration is as follows:

    dial-peer voice <Voice dial-peer tag> voip
     ...
    !

Note: Older versions of Cisco IOS Software were affected by a bug
that caused Cisco IOS Software to process SIP messages without being
configured for SIP operation. Refer to http://www.cisco.com/warp/
public/707/cisco-sa-20070131-sip.shtml for additional information on
Cisco bug ID CSCsb25337.

In addition to inspecting the Cisco IOS device configuration for a
dial-peer command that causes the device to process SIP messages,
administrators can also use the command show processes | include SIP
to determine whether Cisco IOS Software is running the processes that
handle SIP messages. In the following example, the presence of the
processes CCSIP_UDP_SOCKET and CCSIP_TCP_SOCKET indicates that the
Cisco IOS device is processing SIP messages:

        Router#show processes | include SIP
         147 Mwe 40F46DF4           12          2    600023468/24000  0 CCSIP_SPI_CONTRO
         148 Mwe 40F21244            0          1       0 5524/6000   0 CCSIP_DNS
         149 Mwe 40F48254            4          1    400023108/24000  0 CCSIP_UDP_SOCKET
         150 Mwe 40F48034            4          1    400023388/24000  0 CCSIP_TCP_SOCKET

Warning: Since there are several ways a device running Cisco IOS
Software can start processing SIP messages, it is recommended that
the show processes | include SIP command be used to determine whether
the device is processing SIP messages instead of relying on the
presence of specific configuration commands.

To determine the Cisco IOS Software release that is running on a
Cisco product, administrators can log in to the device and issue the
show version command to display the system banner. The system banner
confirms that the device is running Cisco IOS Software by displaying
text similar to "Cisco Internetwork Operating System Software" or
"Cisco IOS Software." The image name displays in parentheses,
followed by "Version" and the Cisco IOS Software release name. Other
Cisco devices do not have the show version command or may provide
different output.

The following example identifies a Cisco product that is running
Cisco IOS Software Release 12.3(26) with an installed image name of
C2500-IS-L:

    Router#show version
    Cisco Internetwork Operating System Software
    IOS (tm) 2500 Software (C2500-IS-L), Version 12.3(26), RELEASE SOFTWARE (fc2)
    Technical Support: http://www.cisco.com/techsupport
    Copyright (c) 1986-2008 by cisco Systems, Inc.
    Compiled Mon 17-Mar-08 14:39 by dchih

    !--- output truncated


The following example identifies a Cisco product that is running
Cisco IOS Software Release 12.4(20)T with an installed image name of
C1841-ADVENTERPRISEK9-M:

    Router#show version
    Cisco IOS Software, 1841 Software (C1841-ADVENTERPRISEK9-M), Version 12.4(20)T, RELEASE SOFTWARE (fc3)
    Technical Support: http://www.cisco.com/techsupport
    Copyright (c) 1986-2008 by Cisco Systems, Inc.
    Compiled Thu 10-Jul-08 20:25 by prod_rel_team

    !--- output truncated


Additional information about Cisco IOS Software release naming
conventions is available in "White Paper: Cisco IOS Reference Guide"
at the following link: http://www.cisco.com/warp/public/620/1.html

Products Confirmed Not Vulnerable
+--------------------------------

The SIP Application Layer Gateway (ALG), which is used by the Cisco
IOS NAT and firewall features of Cisco IOS Software, is not affected
by this vulnerability.

Cisco devices that are running Cisco IOS XE Software and Cisco IOS XR
Software are not affected.

No other Cisco products are currently known to be affected by this
vulnerability.

Details
=======

SIP is a popular signaling protocol that is used to manage voice and
video calls across IP networks such as the Internet. SIP is
responsible for handling all aspects of call setup and termination.
Voice and video are the most popular types of sessions that SIP
handles, but the protocol has the flexibility to accommodate other
applications that require call setup and termination. SIP call
signaling can use UDP (port 5060), TCP (port 5060), or TLS (TCP port
5061) as the underlying transport protocol.

A denial of service (DoS) vulnerability exists in the SIP
implementation in Cisco IOS Software. This vulnerability is triggered
by processing a specific and valid SIP message.

This vulnerability is documented in Cisco Bug ID CSCsu11522 and has
been assigned Common Vulnerabilities and Exposures (CVE) ID 
CVE-2009-0636.

Note: The vulnerabilities described in the advisories Cisco IOS
Software Multiple Features IP Sockets Vulnerability and Cisco IOS
Software Multiple Features Crafted UDP Packet Vulnerability, both
part of this bundle of Cisco IOS advisories, may also impact SIP
operations.

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

CSCsu11522 - A voice gateway may crash when processing valid SIP

CVSS Base Score - 7.8

 Access Vector           - Network
 Access Complexity       - Low
 Authentication          - None
 Confidentiality Impact  - None
 Integrity Impact        - None
 Availability Impact     - Complete

CVSS Temporal Score - 6.4

 Exploitability          - Functional
 Remediation Level       - Official-Fix
 Report Confidence       - Confirmed

Impact
======

Successful exploitation of the vulnerability described in this
document may result in a reload of the device. The issue could be
repeatedly exploited to cause an extended DoS condition.

Software Versions and Fixes
===========================

When considering software upgrades, also consult 
http://www.cisco.com/go/psirt and any subsequent advisories to 
determine exposure and a complete upgrade solution.

In all cases, customers should exercise caution to be certain the
devices to be upgraded contain sufficient memory and that current
hardware and software configurations will continue to be supported
properly by the new release. If the information is not clear, contact
the Cisco Technical Assistance Center (TAC) or your contracted
maintenance provider for assistance.

Each row of the Cisco IOS software table (below) names a Cisco IOS
release train. If a given release train is vulnerable, then the
earliest possible releases that contain the fix (along with the
anticipated date of availability for each, if applicable) are listed
in the "First Fixed Release" column of the table. The "Recommended
Release" column indicates the releases which have fixes for all the
published vulnerabilities at the time of this Advisory. A device
running a release in the given train that is earlier than the release
in a specific column (less than the First Fixed Release) is known to
be vulnerable. Cisco recommends upgrading to a release equal to or
later than the release in the "Recommended Releases" column of the
table.

Note: In addition to CSCsu11522 and because of its impact on SIP
operation, this table of fixed software takes into consideration the
vulnerability tracked by Cisco Bug CSCsk64158 , from "Cisco Security
Advisory: Crafted UDP Packet Affects Multiple Cisco IOS Features" 
(http://www.cisco.com/warp/public/707/cisco-sa-20090325-udp.shtml)
The table does not take into consideration the vulnerability
disclosed by "Cisco Security Advisory: Cisco IOS IP Sockets
Vulnerability Affecting Multiple Cisco IOS Features", which may
impact SIP over TLS.

+-------------------------------------------------------------------+
|   Major    |          Availability of Repaired Releases           |
|  Release   |                                                      |
|------------+------------------------------------------------------|
| Affected   |                                     | Recommended    |
| 12.0-Based | First Fixed Release                 | Release        |
| Releases   |                                     |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0       | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0DA     | Vulnerable; first fixed in 12.2DA   | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0DB     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0DC     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.0S      | 12.0(32)S12                         | 12.0(32)S12    |
|------------+-------------------------------------+----------------|
| 12.0SC     | Vulnerable; first fixed in 12.0S    | 12.0(32)S12    |
|------------+-------------------------------------+----------------|
| 12.0SL     | Vulnerable; first fixed in 12.0S    | 12.0(32)S12    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0SP     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.0ST     | Vulnerable; first fixed in 12.0S    | 12.0(32)S12    |
|------------+-------------------------------------+----------------|
| 12.0SX     | Vulnerable; first fixed in 12.0S    | 12.0(32)S12    |
|------------+-------------------------------------+----------------|
| 12.0SY     | 12.0(32)SY8                         | 12.0(32)SY8    |
|------------+-------------------------------------+----------------|
| 12.0SZ     | Vulnerable; first fixed in 12.0S    | 12.0(32)S12    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0T      | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.0W      | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.0WC     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.0WT     | Not Vulnerable                      |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0XA     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0XB     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0XC     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0XD     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0XE     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.0XF     | Not Vulnerable                      |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0XG     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0XH     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            | Releases prior to 12.0(4)XI2 are    | 12.4(18e)      |
|            | vulnerable, release 12.0(4)XI2 and  |                |
| 12.0XI     | later are not vulnerable; first     | 12.4(23a);     |
|            | fixed in 12.4                       | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0XJ     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0XK     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0XL     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0XM     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0XN     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0XQ     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0XR     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0XS     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0XT     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0XV     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| Affected   |                                     | Recommended    |
| 12.1-Based | First Fixed Release                 | Release        |
| Releases   |                                     |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1       | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.1AA     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.1AX     | Vulnerable; first fixed in 12.2SE   | 12.2(44)SE6    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.1(22)EA13   |
| 12.1AY     | Vulnerable; first fixed in 12.1EA   |                |
|            |                                     | 12.2(44)SE6    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.1(22)EA13   |
| 12.1AZ     | Vulnerable; first fixed in 12.1EA   |                |
|            |                                     | 12.2(44)SE6    |
|------------+-------------------------------------+----------------|
| 12.1CX     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.1DA     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.1DB     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.1DC     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.1E      | Vulnerable; first fixed in 12.2SXF  | 12.2(18)SXF16  |
|------------+-------------------------------------+----------------|
| 12.1EA     | 12.1(22)EA13                        | 12.1(22)EA13   |
|------------+-------------------------------------+----------------|
| 12.1EB     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.2(33)SCB1   |
| 12.1EC     | Vulnerable; first fixed in 12.3BC   |                |
|            |                                     | 12.3(23)BC6    |
|------------+-------------------------------------+----------------|
| 12.1EO     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.1EU     | Vulnerable; first fixed in 12.2SG   | 12.2(31)SGA9   |
|------------+-------------------------------------+----------------|
| 12.1EV     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.1EW     | Vulnerable; migrate to 12.2SGA      | 12.2(31)SGA9   |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1EX     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.1EY     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.1EZ     | Vulnerable; first fixed in 12.2SXF  | 12.2(18)SXF16  |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1GA     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1GB     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1T      | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XA     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XB     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XC     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XD     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XE     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XF     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XG     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XH     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XI     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XJ     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XL     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XM     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XP     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XQ     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XR     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XS     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XT     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XU     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XV     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XW     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XX     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XY     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XZ     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1YA     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1YB     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1YC     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1YD     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            | Releases prior to 12.1(5)YE6 are    | 12.4(18e)      |
|            | vulnerable, release 12.1(5)YE6 and  |                |
| 12.1YE     | later are not vulnerable; first     | 12.4(23a);     |
|            | fixed in 12.4                       | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1YF     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1YH     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.1YI     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.1(22)EA13   |
| 12.1YJ     | Vulnerable; first fixed in 12.1EA   |                |
|            |                                     | 12.2(44)SE6    |
|------------+-------------------------------------+----------------|
| Affected   |                                     | Recommended    |
| 12.2-Based | First Fixed Release                 | Release        |
| Releases   |                                     |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2       | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.2B      | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            | Vulnerable; migrate to 12.2SCB or   | 12.2(33)SCB1   |
| 12.2BC     | 12.3BC                              |                |
|            |                                     | 12.3(23)BC6    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2BW     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.2BX     | Vulnerable; migrate to 12.2SB       | 12.2(33)SB4    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2BY     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2BZ     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            | Vulnerable; migrate to 12.2SCB or   | 12.2(33)SCB1   |
| 12.2CX     | 12.3BC                              |                |
|            |                                     | 12.3(23)BC6    |
|------------+-------------------------------------+----------------|
|            | Vulnerable; migrate to 12.2SCB or   | 12.2(33)SCB1   |
| 12.2CY     | 12.3BC                              |                |
|            |                                     | 12.3(23)BC6    |
|------------+-------------------------------------+----------------|
| 12.2CZ     | Vulnerable; first fixed in 12.2SB   | 12.2(33)SB4    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            | 12.2(12)DA14; Available on          |                |
| 12.2DA     | 30-JUL-2009                         | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2DD     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2DX     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.2EW     | Vulnerable; first fixed in 12.2SG   | 12.2(31)SGA9   |
|------------+-------------------------------------+----------------|
| 12.2EWA    | Vulnerable; first fixed in 12.2SG   | 12.2(31)SGA9   |
|------------+-------------------------------------+----------------|
| 12.2EX     | Vulnerable; first fixed in 12.2SE   | 12.2(44)SE6    |
|------------+-------------------------------------+----------------|
| 12.2EY     | 12.2(44)EY                          | 12.2(44)SE6    |
|------------+-------------------------------------+----------------|
| 12.2EZ     | Vulnerable; first fixed in 12.2SE   | 12.2(44)SE6    |
|------------+-------------------------------------+----------------|
| 12.2FX     | Vulnerable; first fixed in 12.2SE   | 12.2(44)SE6    |
|------------+-------------------------------------+----------------|
| 12.2FY     | Vulnerable; first fixed in 12.2SE   | 12.2(44)SE6    |
|------------+-------------------------------------+----------------|
| 12.2FZ     | Vulnerable; first fixed in 12.2SE   | 12.2(44)SE6    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.2(33)SRC4;  |
| 12.2IRA    | Vulnerable; first fixed in 12.2SRC  | Available on   |
|            |                                     | 18-MAY-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.2(33)SRC4;  |
| 12.2IRB    | Vulnerable; first fixed in 12.2SRC  | Available on   |
|            |                                     | 18-MAY-2009    |
|------------+-------------------------------------+----------------|
|            | Vulnerable; migrate to any release  | 12.2(18)IXH;   |
| 12.2IXA    | in 12.2IXH                          | Available on   |
|            |                                     | 31-MAR-2009    |
|------------+-------------------------------------+----------------|
|            | Vulnerable; migrate to any release  | 12.2(18)IXH;   |
| 12.2IXB    | in 12.2IXH                          | Available on   |
|            |                                     | 31-MAR-2009    |
|------------+-------------------------------------+----------------|
|            | Vulnerable; migrate to any release  | 12.2(18)IXH;   |
| 12.2IXC    | in 12.2IXH                          | Available on   |
|            |                                     | 31-MAR-2009    |
|------------+-------------------------------------+----------------|
|            | Vulnerable; migrate to any release  | 12.2(18)IXH;   |
| 12.2IXD    | in 12.2IXH                          | Available on   |
|            |                                     | 31-MAR-2009    |
|------------+-------------------------------------+----------------|
|            | Vulnerable; migrate to any release  | 12.2(18)IXH;   |
| 12.2IXE    | in 12.2IXH                          | Available on   |
|            |                                     | 31-MAR-2009    |
|------------+-------------------------------------+----------------|
|            | Vulnerable; migrate to any release  | 12.2(18)IXH;   |
| 12.2IXF    | in 12.2IXH                          | Available on   |
|            |                                     | 31-MAR-2009    |
|------------+-------------------------------------+----------------|
|            | Vulnerable; migrate to any release  | 12.2(18)IXH;   |
| 12.2IXG    | in 12.2IXH                          | Available on   |
|            |                                     | 31-MAR-2009    |
|------------+-------------------------------------+----------------|
| 12.2JA     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.2JK     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2MB     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.2MC     | 12.2(15)MC2m                        | 12.2(15)MC2m   |
|------------+-------------------------------------+----------------|
| 12.2S      | Vulnerable; first fixed in 12.2SB   | 12.2(33)SB4    |
|------------+-------------------------------------+----------------|
|            | 12.2(28)SB13                        |                |
|            |                                     |                |
| 12.2SB     | 12.2(31)SB14                        | 12.2(33)SB4    |
|            |                                     |                |
|            | 12.2(33)SB3                         |                |
|------------+-------------------------------------+----------------|
| 12.2SBC    | Vulnerable; first fixed in 12.2SB   | 12.2(33)SB4    |
|------------+-------------------------------------+----------------|
| 12.2SCA    | Vulnerable; first fixed in 12.2SCB  | 12.2(33)SCB1   |
|------------+-------------------------------------+----------------|
| 12.2SCB    | 12.2(33)SCB1                        | 12.2(33)SCB1   |
|------------+-------------------------------------+----------------|
|            | 12.2(50)SE                          |                |
|            |                                     |                |
| 12.2SE     | 12.2(46)SE2                         | 12.2(44)SE6    |
|            |                                     |                |
|            | 12.2(44)SE5                         |                |
|------------+-------------------------------------+----------------|
| 12.2SEA    | Vulnerable; first fixed in 12.2SE   | 12.2(44)SE6    |
|------------+-------------------------------------+----------------|
| 12.2SEB    | Vulnerable; first fixed in 12.2SE   | 12.2(44)SE6    |
|------------+-------------------------------------+----------------|
| 12.2SEC    | Vulnerable; first fixed in 12.2SE   | 12.2(44)SE6    |
|------------+-------------------------------------+----------------|
| 12.2SED    | Vulnerable; first fixed in 12.2SE   | 12.2(44)SE6    |
|------------+-------------------------------------+----------------|
| 12.2SEE    | Vulnerable; first fixed in 12.2SE   | 12.2(44)SE6    |
|------------+-------------------------------------+----------------|
| 12.2SEF    | Vulnerable; first fixed in 12.2SE   | 12.2(44)SE6    |
|------------+-------------------------------------+----------------|
| 12.2SEG    | Vulnerable; first fixed in 12.2SE   | 12.2(44)SE6    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.2(52)SG;    |
| 12.2SG     | 12.2(50)SG                          | Available on   |
|            |                                     | 15-MAY-2009    |
|------------+-------------------------------------+----------------|
| 12.2SGA    | 12.2(31)SGA9                        | 12.2(31)SGA9   |
|------------+-------------------------------------+----------------|
| 12.2SL     | Not Vulnerable                      |                |
|------------+-------------------------------------+----------------|
| 12.2SM     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2SO     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2SQ     | 12.2(44)SQ1                         |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.2(33)SRD1   |
|            |                                     |                |
| 12.2SRA    | Vulnerable; first fixed in 12.2SRC  | 12.2(33)SRC4;  |
|            |                                     | Available on   |
|            |                                     | 18-MAY-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.2(33)SRC4;  |
|            |                                     | Available on   |
|            |                                     | 18-MAY-2009    |
|            |                                     |                |
| 12.2SRB    | Vulnerable; first fixed in 12.2SRC  | 12.2(33)SRD1   |
|            |                                     |                |
|            |                                     | 12.2(33)SRB5a; |
|            |                                     | Available on   |
|            |                                     | 3-April-2009   |
|------------+-------------------------------------+----------------|
|            | 12.2(33)SRC4; Available on          | 12.2(33)SRC4;  |
| 12.2SRC    | 18-MAY-2009                         | Available on   |
|            |                                     | 18-MAY-2009    |
|------------+-------------------------------------+----------------|
| 12.2SRD    | Not Vulnerable                      |                |
|------------+-------------------------------------+----------------|
| 12.2STE    | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.2SU     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.2SV     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2SVA    | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2SVC    | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2SVD    | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2SVE    | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2SW     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2SX     | Vulnerable; first fixed in 12.2SXF  | 12.2(18)SXF16  |
|------------+-------------------------------------+----------------|
| 12.2SXA    | Vulnerable; first fixed in 12.2SXF  | 12.2(18)SXF16  |
|------------+-------------------------------------+----------------|
| 12.2SXB    | Vulnerable; first fixed in 12.2SXF  | 12.2(18)SXF16  |
|------------+-------------------------------------+----------------|
| 12.2SXD    | Vulnerable; first fixed in 12.2SXF  | 12.2(18)SXF16  |
|------------+-------------------------------------+----------------|
| 12.2SXE    | Vulnerable; first fixed in 12.2SXF  | 12.2(18)SXF16  |
|------------+-------------------------------------+----------------|
| 12.2SXF    | 12.2(18)SXF16                       | 12.2(18)SXF16  |
|------------+-------------------------------------+----------------|
|            | 12.2(33)SXH5; Available on          | 12.2(33)SXH5;  |
| 12.2SXH    | 20-APR-2009                         | Available on   |
|            |                                     | 20-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.2SXI    | Not Vulnerable                      |                |
|------------+-------------------------------------+----------------|
| 12.2SY     | Vulnerable; first fixed in 12.2SB   | 12.2(33)SB4    |
|------------+-------------------------------------+----------------|
| 12.2SZ     | Vulnerable; first fixed in 12.2SB   | 12.2(33)SB4    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2T      | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.2TPC    | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XA     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XB     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XC     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XD     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XE     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            | Vulnerable; migrate to 12.2SCB or   | 12.2(33)SCB1   |
| 12.2XF     | 12.3BC                              |                |
|            |                                     | 12.3(23)BC6    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XG     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XH     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XI     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XJ     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XK     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XL     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XM     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.2(33)SB4    |
| 12.2XN     | Vulnerable; first fixed in 12.2SRC  |                |
|            |                                     | 12.2(33)SRD1   |
|------------+-------------------------------------+----------------|
| 12.2XNA    | Vulnerable; migrate to any release  | 12.2(33)SRD1   |
|            | in 12.2SRD                          |                |
|------------+-------------------------------------+----------------|
| 12.2XNB    | 12.2(33)XNB1                        | 12.2(33)XNB3   |
|------------+-------------------------------------+----------------|
| 12.2XNC    | Not Vulnerable                      |                |
|------------+-------------------------------------+----------------|
| 12.2XO     | 12.2(46)XO                          | 12.2(46)XO     |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XQ     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XR     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XS     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XT     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XU     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XV     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XW     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2YA     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.2YB     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YC     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YD     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YE     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YF     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YG     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YH     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YJ     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YK     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YL     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.2YM     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.2YN     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YO     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2YP     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.2YQ     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YR     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YS     | Not Vulnerable                      |                |
|------------+-------------------------------------+----------------|
| 12.2YT     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YU     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YV     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YW     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YX     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YY     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YZ     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2ZA     | Vulnerable; first fixed in 12.2SXF  | 12.2(18)SXF16  |
|------------+-------------------------------------+----------------|
| 12.2ZB     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2ZC     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2ZD     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2ZE     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.2ZF     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.2ZG     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2ZH     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.2ZJ     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2ZL     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2ZP     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.2(33)SXH5;  |
| 12.2ZU     | Vulnerable; first fixed in 12.2SXH  | Available on   |
|            |                                     | 20-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.2ZX     | Vulnerable; first fixed in 12.2SB   | 12.2(33)SB4    |
|------------+-------------------------------------+----------------|
| 12.2ZY     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2ZYA    | 12.2(18)ZYA1                        | 12.2(18)ZYA1   |
|------------+-------------------------------------+----------------|
| Affected   |                                     | Recommended    |
| 12.3-Based | First Fixed Release                 | Release        |
| Releases   |                                     |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.3       | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3B      | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.3BC     | 12.3(23)BC6                         | 12.3(23)BC6    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3BW     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.3EU     | Not Vulnerable                      |                |
|------------+-------------------------------------+----------------|
| 12.3JA     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.3JEA    | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.3JEB    | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.3JEC    | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3JK     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.3JL     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.3JX     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3T      | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.3TPC    | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.3VA     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.3XA     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.3XB     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3XC     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3XD     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.3XE     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.3XF     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3XG     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.3XI     | Vulnerable; first fixed in 12.2SB   | 12.2(33)SB4    |
|------------+-------------------------------------+----------------|
| 12.3XJ     | Vulnerable; first fixed in 12.3YX   | 12.3(14)YX14   |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3XK     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3XL     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3XQ     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.3XR     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3XS     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3XU     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.3XW     | Vulnerable; first fixed in 12.3YX   | 12.3(14)YX14   |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3XX     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3XY     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3XZ     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3YA     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3YD     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.3YF     | Vulnerable; first fixed in 12.3YX   | 12.3(14)YX14   |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3YG     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3YH     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3YI     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3YJ     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3YK     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.3YM     | 12.3(14)YM13                        | 12.3(14)YM13   |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3YQ     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3YS     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3YT     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3YU     | Vulnerable; first fixed in 12.4XB   | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.3YX     | 12.3(14)YX14                        | 12.3(14)YX14   |
|------------+-------------------------------------+----------------|
| 12.3YZ     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3ZA     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
| Affected   |                                     | Recommended    |
| 12.4-Based | First Fixed Release                 | Release        |
| Releases   |                                     |                |
|------------+-------------------------------------+----------------|
|            | 12.4(18e)                           | 12.4(18e)      |
|            |                                     |                |
| 12.4       | 12.4(23)                            | 12.4(23a);     |
|            |                                     | Available on   |
|            | 12.4(23a); Available on 30-APR-2009 | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.4JA     | 12.4(16b)JA1                        |                |
|------------+-------------------------------------+----------------|
| 12.4JDA    | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.4JK     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.4JL     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.4JMA    | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.4JMB    | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.4JX     | Vulnerable; first fixed in 12.4JA   |                |
|------------+-------------------------------------+----------------|
| 12.4MD     | 12.4(11)MD7                         | 12.4(11)MD7    |
|------------+-------------------------------------+----------------|
| 12.4MR     | 12.4(19)MR1                         | 12.4(19)MR2    |
|------------+-------------------------------------+----------------|
| 12.4SW     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
|            | 12.4(20)T2                          |                |
|            |                                     | 12.4(22)T1     |
|            | 12.4(15)T8                          |                |
| 12.4T      |                                     | 12.4(15)T9;    |
|            | 12.4(22)T                           | Available on   |
|            |                                     | 29-APR-2009    |
|            | 12.4(15)T9; Available on            |                |
|            | 29-APR-2009                         |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.4XA     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            | 12.4(15)T8                          | 12.4(22)T1     |
|            |                                     |                |
| 12.4XB     | 12.4(20)T2                          | 12.4(15)T9;    |
|            |                                     | Available on   |
|            | 12.4(15)T9; Available on            | 29-APR-2009    |
|            | 29-APR-2009                         |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.4XC     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            | 12.4(4)XD12; Available on           | 12.4(4)XD12;   |
| 12.4XD     | 27-MAR-2009                         | Available on   |
|            |                                     | 27-MAR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.4XE     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.4XF     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            | 12.4(15)T8                          |                |
| 12.4XG     |                                     | 12.4(15)T9;    |
|            | 12.4(20)T2                          | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.4XJ     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.4XK     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.4XL     | 12.4(15)XL4                         | 12.4(15)XL4    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.4XM     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.4XN     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.4XP     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.4XQ     | 12.4(15)XQ2                         | 12.4(15)XQ2    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.4XR     | 12.4(15)XR4                         | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.4XT     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.4XV     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.4XW     | 12.4(11)XW10                        | 12.4(11)XW10   |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.4XY     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.4XZ     | 12.4(15)XZ2                         | 12.4(15)XZ2    |
|------------+-------------------------------------+----------------|
| 12.4YA     | 12.4(20)YA2                         | 12.4(20)YA3    |
|------------+-------------------------------------+----------------|
| 12.4YB     | Not Vulnerable                      |                |
|------------+-------------------------------------+----------------|
| 12.4YD     | Not Vulnerable                      |                |
+-------------------------------------------------------------------+

Workarounds
===========

If the affected Cisco IOS device requires SIP for VoIP services, SIP
cannot be disabled, and therefore, no workarounds are available.
Users are advised to apply mitigation techniques to help limit
exposure to the vulnerability. Mitigation consists of allowing only
legitimate devices to connect to the routers. To increase
effectiveness, the mitigation must be coupled with anti-spoofing
measures on the network edge. This action is required because SIP can
use UDP as the transport protocol.

Additional mitigations that can be deployed on Cisco devices within
the network are available in the companion document "Cisco Applied
Mitigation Bulletin: Identifying and Mitigating Exploitation of the
Cisco IOS SIP and Crafted UDP Vulnerabilities", which is available at
the following location: 
http://www.cisco.com/warp/public/707/cisco-amb-20090325-sip-and-udp.shtml

Disable SIP Listening Ports
+--------------------------

For devices that do not require SIP to be enabled, the simplest and
most effective workaround is to disable SIP processing on the device.
Some versions of Cisco IOS Software allow administrators to
accomplish this with the following commands:

    sip-ua
     no transport udp
     no transport tcp

Warning: When applying this workaround to devices that are processing
Media Gateway Control Protocol (MGCP) or H.323 calls, the device will
not stop SIP processing while active calls are being processed. Under
these circumstances, this workaround should be implemented during a
maintenance window when active calls can be briefly stopped.

After applying this workaround, administrators are advised to use the
show commands, as discussed in the Affected Products section of this
advisory, to confirm that the Cisco IOS device is no longer
processing SIP messages.

Control Plane Policing
+---------------------

For devices that need to offer SIP services it is possible to use
Control Plane Policing (CoPP) to block SIP traffic to the device from
untrusted sources. Cisco IOS Releases 12.0S, 12.2SX, 12.2S, 12.3T,
12.4, and 12.4T support the CoPP feature. CoPP may be configured on a
device to protect the management and control planes to minimize the
risk and effectiveness of direct infrastructure attacks by explicitly
permitting only authorized traffic sent to infrastructure devices in
accordance with existing security policies and configurations. The
following example can be adapted to the network:


    !-- The 192.168.1.0/24 network and the 172.16.1.1 host are trusted.
    !-- Everything else is not trusted. The following access list is used
    !-- to determine what traffic needs to be dropped by a control plane
    !-- policy (the CoPP feature.) If the access list matches (permit)
    !-- then traffic will be dropped and if the access list does not
    !-- match (deny) then traffic will be processed by the router.

    access-list 100 deny udp 192.168.1.0 0.0.0.255 any eq 5060
    access-list 100 deny tcp 192.168.1.0 0.0.0.255 any eq 5060
    access-list 100 deny tcp 192.168.1.0 0.0.0.255 any eq 5061
    access-list 100 deny udp host 172.16.1.1 any eq 5060
    access-list 100 deny tcp host 172.16.1.1 any eq 5060
    access-list 100 deny tcp host 172.16.1.1 any eq 5061
    access-list 100 permit udp any any eq 5060
    access-list 100 permit tcp any any eq 5060
    access-list 100 permit tcp any any eq 5061

    !-- Permit (Police or Drop)/Deny (Allow) all other Layer3 and Layer4
    !-- traffic in accordance with existing security policies and
    !-- configurations for traffic that is authorized to be sent
    !-- to infrastructure devices.
    !-- Create a Class-Map for traffic to be policed by
    !-- the CoPP feature.

    class-map match-all drop-sip-class
      match access-group 100

    !-- Create a Policy-Map that will be applied to the
    !-- Control-Plane of the device.

    policy-map drop-sip-traffic
     class drop-sip-class
      drop

    !-- Apply the Policy-Map to the Control-Plane of the
    !-- device.

    control-plane
     service-policy input drop-sip-traffic

Warning: Because SIP can use UDP as a transport protocol, it is
possible to easily spoof the IP address of the sender, which may
defeat access control lists that permit communication to these ports
from trusted IP addresses.

In the above CoPP example, the access control entries (ACEs) that
match the potential exploit packets with the "permit" action result
in these packets being discarded by the policy-map "drop" function,
while packets that match the "deny" action (not shown) are not
affected by the policy-map drop function. Additional information on
the configuration and use of the CoPP feature can be found at 
http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html
and 
http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gtrtlimt.html

Obtaining Fixed Software
========================

Cisco has released free software updates that address these
vulnerabilities. Prior to deploying software, customers should
consult their maintenance provider or check the software for feature
set compatibility and known issues specific to their environment.

Customers may only install and expect support for the feature sets
they have purchased. By installing, downloading, accessing or
otherwise using such software upgrades, customers agree to be bound
by the terms of Cisco's software license terms found at 
http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html,
or as otherwise set forth at Cisco.com Downloads at 
http://www.cisco.com/public/sw-center/sw-usingswc.shtml

Do not contact psirt at cisco.com or security-alert at cisco.com for
software upgrades.

Customers with Service Contracts
+-------------------------------

Customers with contracts should obtain upgraded software through
their regular update channels. For most customers, this means that
upgrades should be obtained through the Software Center on Cisco's
worldwide website at http://www.cisco.com

Customers using Third Party Support Organizations
+------------------------------------------------

Customers whose Cisco products are provided or maintained through
prior or existing agreements with third-party support organizations,
such as Cisco Partners, authorized resellers, or service providers
should contact that support organization for guidance and assistance
with the appropriate course of action in regards to this advisory.

The effectiveness of any workaround or fix is dependent on specific
customer situations, such as product mix, network topology, traffic
behavior, and organizational mission. Due to the variety of affected
products and releases, customers should consult with their service
provider or support organization to ensure any applied workaround or
fix is the most appropriate for use in the intended network before it
is deployed.

Customers without Service Contracts
+----------------------------------

Customers who purchase direct from Cisco but do not hold a Cisco
service contract, and customers who purchase through third-party
vendors but are unsuccessful in obtaining fixed software through
their point of sale should acquire upgrades by contacting the Cisco
Technical Assistance Center (TAC). TAC contacts are as follows.

  * +1 800 553 2447 (toll free from within North America)
  * +1 408 526 7209 (toll call from anywhere in the world)
  * e-mail: tac at cisco.com

Customers should have their product serial number available and be
prepared to give the URL of this notice as evidence of entitlement to
a free upgrade. Free upgrades for non-contract customers must be
requested through the TAC.

Refer to 
http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html
for additional TAC contact information, including localized telephone
numbers, and instructions and e-mail addresses for use in various
languages.

Exploitation and Public Announcements
=====================================

The Cisco PSIRT is not aware of any public announcements or malicious
use of the vulnerability described in this advisory.

This vulnerability was discovered during handling of customer service
requests.

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-20090325-sip.shtml

In addition to worldwide web posting, a text version of this notice
is clear-signed with the Cisco PSIRT PGP key and is posted to the
following e-mail and Usenet news recipients.

  * cust-security-announce at cisco.com
  * first-bulletins at lists.first.org
  * bugtraq at securityfocus.com
  * vulnwatch at vulnwatch.org
  * cisco at spot.colorado.edu
  * cisco-nsp at puck.nether.net
  * full-disclosure at lists.grok.org.uk
  * comp.dcom.sys.cisco at newsgate.cisco.com

Future updates of this advisory, if any, will be placed on Cisco's
worldwide website, but may or may not be actively announced on
mailing lists or newsgroups. Users concerned about this problem are
encouraged to check the above URL for any updates.

Revision History
================

+---------------------------------------+
| Revision |               | Initial    |
| 1.0      | 2009-March-25 | 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-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAknKUboACgkQ86n/Gc8U/uCi+gCfZaAw0PuDJWKg2K42vzfdJe+h
XHwAnRRdQQTeuhmW0liolMtU1ZzKg+Ke
=VvxT
-----END PGP SIGNATURE-----

From psirt at cisco.com  Wed Mar 25 12:00:00 2009
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Wed, 25 Mar 2009 17:00:00 +0100
Subject: [c-nsp] Cisco Security Advisory: Cisco IOS Software Multiple
	Features Crafted TCP Sequence Vulnerability
Message-ID: <200903251705.tcp@psirt.cisco.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cisco Security Advisory: Cisco IOS Software Multiple Features Crafted
TCP Sequence Vulnerability

Advisory ID: cisco-sa-20090325-tcp

http://www.cisco.com/warp/public/707/cisco-sa-20090325-tcp.shtml

Revision 1.0

For Public Release 2009 March 25 1600 UTC (GMT)

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

Summary
=======

Cisco IOS  Software contains a vulnerability in multiple features
that could allow an attacker to cause a denial of service (DoS)
condition on the affected device. A sequence of specially crafted TCP
packets can cause the vulnerable device to reload.

Cisco has released free software updates that address this
vulnerability.

Several mitigation strategies are outlined in the workarounds section
of this advisory.

This advisory is posted at 
http://www.cisco.com/warp/public/707/cisco-sa-20090325-tcp.shtml

Note: The March 25, 2009, Cisco IOS Security Advisory bundled
publication includes eight Security Advisories. All of the advisories
address vulnerabilities in Cisco IOS Software. Each advisory lists
the releases that correct the vulnerability or vulnerabilities in the
advisory. The following table lists releases that correct all Cisco
IOS Software vulnerabilities that have been published in Cisco
Security Advisories on March 25, 2009, or earlier.

http://www.cisco.com/warp/public/707/cisco-sa-20090325-bundle.shtml

Individual publication links are listed below:

  * Cisco IOS cTCP Denial of Service Vulnerability
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-ctcp.shtml

  * Cisco IOS Software Multiple Features IP Sockets Vulnerability
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-ip.shtml

  * Cisco IOS Software Mobile IP and Mobile IPv6 Vulnerabilities
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-mobileip.shtml

  * Cisco IOS Software Secure Copy Privilege Escalation Vulnerability
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-scp.shtml

  * Cisco IOS Software Session Initiation Protocol Denial of Service
    Vulnerability
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-sip.shtml

  * Cisco IOS Software Multiple Features Crafted TCP Sequence
    Vulnerability
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-tcp.shtml

  * Cisco IOS Software Multiple Features Crafted UDP Packet
    Vulnerability
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-udp.shtml

  * Cisco IOS Software WebVPN and SSLVPN Vulnerabilities
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-webvpn.shtml

Affected Products
=================

Vulnerable Products
+------------------

Devices running affected versions of Cisco IOS Software and Cisco IOS
XE Software are affected when configured to use any of the following
features within Cisco IOS:

  * Airline Product Set (ALPS)
  * Serial Tunnel Code (STUN) and Block Serial Tunnel Code (BSTUN)
  * Native Client Interface Architecture support (NCIA)
  * Data-link switching (DLSw)
  * Remote Source-Route Bridging (RSRB)
  * Point to Point Tunneling Protocol (PPTP)
  * X.25 for Record Boundary Preservation (RBP)
  * X.25 over TCP (XOT)
  * X.25 Routing

Information on how to determine whether an affected feature is
enabled on a device are provided in the Details section of this
advisory.

To determine the Cisco IOS Software release that is running on a
Cisco product, administrators can log in to the device and issue the
"show version" command to display the system banner. The system
banner confirms that the device is running Cisco IOS Software by
displaying text similar to "Cisco Internetwork Operating System
Software" or "Cisco IOS Software." The image name displays in
parentheses, followed by "Version" and the Cisco IOS Software release
name. Other Cisco devices do not have the "show version" command or
may provide different output.

The following example identifies a Cisco product that is running
Cisco IOS Software Release 12.3(26) with an installed image name of
C2500-IS-L:

    Router#show version
    Cisco Internetwork Operating System Software
    IOS (tm) 2500 Software (C2500-IS-L), Version 12.3(26), RELEASE SOFTWARE (fc2)
    Technical Support: http://www.cisco.com/techsupport
    Copyright (c) 1986-2008 by cisco Systems, Inc.
    Compiled Mon 17-Mar-08 14:39 by dchih

    <output truncated>

The following example shows a product that is running Cisco IOS
Software Release 12.4(20)T with an image name of
C1841-ADVENTERPRISEK9-M:

    Router#show version
    Cisco IOS Software, 1841 Software (C1841-ADVENTERPRISEK9-M), Version 12.4(20)T, RELEASE SOFTWARE (fc3)
    Technical Support: http://www.cisco.com/techsupport
    Copyright (c) 1986-2008 by Cisco Systems, Inc.
    Compiled Thu 10-Jul-08 20:25 by prod_rel_team

    <output truncated>

Additional information about Cisco IOS Software release naming
conventions is available in "White Paper: Cisco IOS Reference Guide"
at the following link: http://www.cisco.com/warp/public/620/1.html .

Products Confirmed Not Vulnerable
+--------------------------------

The following product and feature have been confirmed not vulnerable:

  * Cisco IOS XR Software
  * BGP is not affected

No other Cisco products or features configured within Cisco IOS
Software are currently known to be affected by this vulnerability.

Details
=======

Completion of the 3-way handshake to the associated TCP port number
(s) of any of the features outlined below is required in order for
the vulnerability to be successfully exploited.

Airline Product Set (ALPS)
+-------------------------

Devices configured for ALPS are vulnerable. The default TCP listening
ports for ALPS are 350 and 10000. The following example shows a
vulnerable ALPS configuration:

    alps local-peer <ip address>

Further information about ALPS is available in "Cisco IOS Bridging
and IBM Networking Configuration Guide, Release 12.2 - Configuring
the Airline Product Set" at the following link
http://www.cisco.com/en/US/docs/ios/12_2/ibm/configuration/guide/bcfalps_ps1835_TSD_Products_Configuration_Guide_Chapter.html

Serial Tunnel Code (STUN) and Block Serial Tunneling (BSTUN)
+-----------------------------------------------------------

Devices configured for either STUN or BSTUN are vulnerable. The
default listening TCP ports for STUN are 1990,1991 1992 and 1994. The
default listening TCP ports for BSTUN are 1963, 1976, 1977, 1978 and
1979 The following example shows a vulnerable STUN configuration:

    interface serial 0/0/0
    encapsulation stun

The following example shows a vulnerable BSTUN configuration:

    interface serial 0/0/0
    encapsulation bstun

Further information about STUN and BSTUN is available in "Cisco IOS
Bridging and IBM Networking Configuration Guide, Release 12.2 -
Configuring Serial Tunnel and Block Serial Tunnel" at the following
link 
http://www.cisco.com/en/US/docs/ios/12_2/ibm/configuration/guide/bcfstun_ps1835_TSD_Products_Configuration_Guide_Chapter.html

Native Client Interface Architecture support (NCIA)
+--------------------------------------------------

Devices configured for NCIA are vulnerable, because of the underlying
transport they will use. The default listening TCP ports will be
dependent on the protocol used with NCIA, such as RSRB or DSLw. The
following examples shows a vulnerable configuration:

    ncia server 1 10.66.91.138 0000.1111.2222 2222.2222.2222 1

Further information about NCIA is available in "Cisco IOS Bridging
and IBM Networking Configuration Guide, Release 12.4 - Configuring
NCIA Client/Server" at the following link 
http://www.cisco.com/en/US/docs/ios/bridging/configuration/guide/br_ncia_client_svr_ps6350_TSD_Products_Configuration_Guide_Chapter.html

Data-link switching (DLSw)
+-------------------------

Devices configured for DLSw are vulnerable. The default listening TCP
ports for DSLw are 2065, 2067, 1981, 1982 and 1983. The following
example shows a vulnerable configuration:

    dlsw local-peer peer-id <ip address>

Devices configured with either FST Encapsulation or Direct
Encapsulation are still vulnerable as the affected TCP ports are
opened by the "dslw local-peer peer-id ip address" command.

Further information about DLSw is available in "Cisco IOS Bridging
and IBM Networking Configuration Guide, Release 12.4 - Configuring
Data-Link Switching Plus" at the following link 
http://www.cisco.com/en/US/docs/ios/bridging/configuration/guide/br_dlsw_plus_ps6350_TSD_Products_Configuration_Guide_Chapter.html

Remote Source-Route Bridging (RSRB)
+----------------------------------

Devices configured for RSRB Using IP Encapsulation over a TCP
connection are vulnerable. The default listening TCP ports for RSRB
are 1996,1987, 1988 and 1989. The following example shows a
vulnerable configuration:

    source-bridge ring-group 10
    source-bridge remote-peer 10 tcp <ip address>

Devices configured with either RSRB Using Direct Encapsulation or
RSRB Using IP Encapsulation over an FST Connection are not affected.

Further information about RSRB is available in "Cisco IOS Bridging
and IBM Networking Configuration Guide, Release 12.2 - Configuring
Remote Source-Route Bridging" at the following link 
http://www.cisco.com/en/US/docs/ios/12_2/ibm/configuration/guide/bcfrsrb_ps1835_TSD_Products_Configuration_Guide_Chapter.html

Point to Point Tunneling Protocol (PPTP)
+---------------------------------------

Devices configured for PPTP are vulnerable. The default listening TCP
port for PPTP is 1723. The following examples shows a vulnerable
configuration:

    vpdn enable
    !
    vpdn-group pptp
    ! Default PPTP VPDN group
     accept-dialin
      protocol pptp
      virtual-template 1

Or

    vpdn enable
    !
    vpdn-group L2_Tunneling
    ! Default L2TP VPDN group
    ! Default PPTP VPDN group
     accept-dialin
      protocol any
      virtual-template 1

Further information about PPTP is available in "Cisco IOS VPDN
Configuration Guide, Release 12.4 - Configuring Client-Initiated
Dial-In VPDN Tunneling" at the following link 
http://www.cisco.com/en/US/docs/ios/vpdn/configuration/guide/client_init_dial-in_ps6350_TSD_Products_Configuration_Guide_Chapter.html#wp1105140

X.25 Record Boundary Preservation (RBP)
+--------------------------------------

Devices configured for RBP are vulnerable. The listening TCP port is
configured with the "local port port_number" CLI command, as shown in
the next examples. The following examples shows vulnerable
configurations. The first leverages switched virtual circuits (SVC):

    interface Serial1/0
       x25 map rbp 1111 local port <port_number>

The second example, leverages a permanent virtual circuit (PVC):

    interface Serial1/0
       x25 map pvc <pvc_number> rbp local port <port_number>

Further information about RBP is available in "Cisco IOS Wide-Area
Networking Configuration Guide, Release 12.4 - X.25 Record Boundary
Preservation for Data Communications Networks" at the following link
http://www.cisco.com/en/US/docs/ios/wan/configuration/guide/wan_x25_rbp_dcn_ps6350_TSD_Products_Configuration_Guide_Chapter.html

X.25 over TCP (XOT)
+------------------

Devices configured for XOT are vulnerable. The default listening TCP
port for XOT is 1998. The following example shows a vulnerable
configuration.

    xot access-group 1

    and a corresponding access-list 1.

Further information about XOT is available in "Cisco IOS Wide-Area
Networking Configuration Guide, Release 12.4 - X.25 over TCP
Profiles" at the following link 
http://www.cisco.com/en/US/docs/ios/wan/configuration/guide/wan_x25otcp_pro_ps6350_TSD_Products_Configuration_Guide_Chapter.html

X25 Routing
+----------

Devices configured with X25 are vulnerable. The default listening TCP
port for X25 Routing is 1998. The following example shows a
vulnerable configuration.

    x25 routing

Further information about X25 is available in "Cisco IOS Wide-Area
Networking Configuration Guide, Release 12.4 - Configuring X.25 and
LAPB" at the following link 
http://www.cisco.com/en/US/docs/ios/wan/configuration/guide/wan_cfg_x25_lapb_ps6350_TSD_Products_Configuration_Guide_Chapter.html

This vulnerability is documented in the following Cisco Bug ID:
CSCsr29468 and has been assigned the Common Vulnerabilities and 
Exposures (CVE) identifier CVE-2009-0629.

Vulnerability Scoring Details
=============================

Cisco has provided scores for the vulnerability in this advisory
based on the Common Vulnerability Scoring System (CVSS). The CVSS
scoring in this Security Advisory is done in accordance with CVSS
version 2.0.

CVSS is a standards-based scoring method that conveys vulnerability
severity and helps determine urgency and priority of response.

Cisco has provided a base and temporal score. Customers can then
compute environmental scores to assist in determining the impact of
the vulnerability in individual networks.

Cisco has provided an FAQ to answer additional questions regarding
CVSS at

http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html

Cisco has also provided a CVSS calculator to help compute the
environmental impact for individual networks at

http://intellishield.cisco.com/security/alertmanager/cvss

CSCsr29468: Cisco IOS Software Multiple Features Crafted TCP Sequence
            Vulnerability

CVSS Base Score - 7.8

 Access Vector           - Network
 Access Complexity       - Low
 Authentication          - None
 Confidentiality Impact  - None
 Integrity Impact        - None
 Availability Impact     - Complete

CVSS Temporal Score - 6.4

 Exploitability          - Functional
 Remediation Level       - Official-Fix
 Report Confidence       - Confirmed

Impact
======

Successful exploitation of this vulnerability will cause the device
to reload. Repeated attempts to exploit this vulnerability could
result in a sustained DoS condition.

Software Versions and Fixes
===========================

When considering software upgrades, also consult 
http://www.cisco.com/go/psirt and any subsequent advisories to 
determine exposure and a complete upgrade solution.

In all cases, customers should exercise caution to be certain the
devices to be upgraded contain sufficient memory and that current
hardware and software configurations will continue to be supported
properly by the new release. If the information is not clear, contact
the Cisco Technical Assistance Center (TAC) or your contracted
maintenance provider for assistance.

Each row of the Cisco IOS software table (below) names a Cisco IOS
release train. If a given release train is vulnerable, then the
earliest possible releases that contain the fix (along with the
anticipated date of availability for each, if applicable) are listed
in the "First Fixed Release" column of the table. The "Recommended
Release" column indicates the releases which have fixes for all the
published vulnerabilities at the time of this Advisory. A device
running a release in the given train that is earlier than the release
in a specific column (less than the First Fixed Release) is known to
be vulnerable. Cisco recommends upgrading to a release equal to or
later than the release in the "Recommended Releases" column of the
table.

+-------------------------------------------------------------------+
|   Major    |          Availability of Repaired Releases           |
|  Release   |                                                      |
|------------+------------------------------------------------------|
| Affected   |                             |                        |
| 12.0-Based | First Fixed Release         | Recommended Release    |
| Releases   |                             |                        |
|-------------------------------------------------------------------|
| There are no affected 12.0 based releases                         |
|-------------------------------------------------------------------|
| Affected   |                             |                        |
| 12.1-Based | First Fixed Release         | Recommended Release    |
| Releases   |                             |                        |
|-------------------------------------------------------------------|
| There are no affected 12.1 based releases                         |
|-------------------------------------------------------------------|
| Affected   |                             |                        |
| 12.2-Based | First Fixed Release         | Recommended Release    |
| Releases   |                             |                        |
|------------+-----------------------------+------------------------|
| 12.2       | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2B      | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2BC     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2BW     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2BX     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2BY     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2BZ     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2CX     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2CY     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2CZ     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2DA     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2DD     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2DX     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2EW     | Vulnerable; first fixed in  | 12.2(31)SGA9           |
|            | 12.2SG                      |                        |
|------------+-----------------------------+------------------------|
| 12.2EWA    | Vulnerable; first fixed in  | 12.2(31)SGA9           |
|            | 12.2SG                      |                        |
|------------+-----------------------------+------------------------|
|            | Releases prior to 12.2(44)  |                        |
|            | EX are vulnerable, release  |                        |
| 12.2EX     | 12.2(44)EX and later are    | 12.2(44)SE6            |
|            | not vulnerable; first fixed |                        |
|            | in 12.2SE                   |                        |
|------------+-----------------------------+------------------------|
| 12.2EY     | 12.2(44)EY                  | 12.2(44)SE6            |
|------------+-----------------------------+------------------------|
| 12.2EZ     | Vulnerable; first fixed in  | 12.2(44)SE6            |
|            | 12.2SE                      |                        |
|------------+-----------------------------+------------------------|
| 12.2FX     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2FY     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2FZ     | Vulnerable; first fixed in  | 12.2(44)SE6            |
|            | 12.2SE                      |                        |
|------------+-----------------------------+------------------------|
|            | Vulnerable; first fixed in  | 12.2(33)SRC4;          |
| 12.2IRA    | 12.2SRC                     | Available on           |
|            |                             | 18-MAY-2009            |
|------------+-----------------------------+------------------------|
|            | Vulnerable; first fixed in  | 12.2(33)SRC4;          |
| 12.2IRB    | 12.2SRC                     | Available on           |
|            |                             | 18-MAY-2009            |
|------------+-----------------------------+------------------------|
| 12.2IXA    | Vulnerable; migrate to any  | 12.2(18)IXH; Available |
|            | release in 12.2IXH          | on 31-MAR-2009         |
|------------+-----------------------------+------------------------|
| 12.2IXB    | Vulnerable; migrate to any  | 12.2(18)IXH; Available |
|            | release in 12.2IXH          | on 31-MAR-2009         |
|------------+-----------------------------+------------------------|
| 12.2IXC    | Vulnerable; migrate to any  | 12.2(18)IXH; Available |
|            | release in 12.2IXH          | on 31-MAR-2009         |
|------------+-----------------------------+------------------------|
| 12.2IXD    | Vulnerable; migrate to any  | 12.2(18)IXH; Available |
|            | release in 12.2IXH          | on 31-MAR-2009         |
|------------+-----------------------------+------------------------|
| 12.2IXE    | Vulnerable; migrate to any  | 12.2(18)IXH; Available |
|            | release in 12.2IXH          | on 31-MAR-2009         |
|------------+-----------------------------+------------------------|
| 12.2IXF    | Vulnerable; migrate to any  | 12.2(18)IXH; Available |
|            | release in 12.2IXH          | on 31-MAR-2009         |
|------------+-----------------------------+------------------------|
| 12.2IXG    | Vulnerable; migrate to any  | 12.2(18)IXH; Available |
|            | release in 12.2IXH          | on 31-MAR-2009         |
|------------+-----------------------------+------------------------|
| 12.2JA     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2JK     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2MB     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2MC     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2S      | Vulnerable; first fixed in  | 12.2(33)SB4            |
|            | 12.2SB                      |                        |
|------------+-----------------------------+------------------------|
|            | 12.2(33)SB3                 |                        |
|            |                             |                        |
| 12.2SB     | 12.2(28)SB13                | 12.2(33)SB4            |
|            |                             |                        |
|            | 12.2(31)SB14                |                        |
|------------+-----------------------------+------------------------|
| 12.2SBC    | Vulnerable; first fixed in  | 12.2(33)SB4            |
|            | 12.2SB                      |                        |
|------------+-----------------------------+------------------------|
| 12.2SCA    | Vulnerable; first fixed in  | 12.2(33)SCB1           |
|            | 12.2SCB                     |                        |
|------------+-----------------------------+------------------------|
| 12.2SCB    | 12.2(33)SCB1                | 12.2(33)SCB1           |
|------------+-----------------------------+------------------------|
|            | 12.2(46)SE2                 |                        |
|            |                             |                        |
| 12.2SE     | 12.2(50)SE                  | 12.2(44)SE6            |
|            |                             |                        |
|            | 12.2(44)SE5                 |                        |
|------------+-----------------------------+------------------------|
| 12.2SEA    | Vulnerable; first fixed in  | 12.2(44)SE6            |
|            | 12.2SE                      |                        |
|------------+-----------------------------+------------------------|
| 12.2SEB    | Vulnerable; first fixed in  | 12.2(44)SE6            |
|            | 12.2SE                      |                        |
|------------+-----------------------------+------------------------|
| 12.2SEC    | Vulnerable; first fixed in  | 12.2(44)SE6            |
|            | 12.2SE                      |                        |
|------------+-----------------------------+------------------------|
| 12.2SED    | Vulnerable; first fixed in  | 12.2(44)SE6            |
|            | 12.2SE                      |                        |
|------------+-----------------------------+------------------------|
| 12.2SEE    | Vulnerable; first fixed in  | 12.2(44)SE6            |
|            | 12.2SE                      |                        |
|------------+-----------------------------+------------------------|
| 12.2SEF    | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
|            | Releases prior to 12.2(25)  |                        |
|            | SEG4 are vulnerable,        |                        |
| 12.2SEG    | release 12.2(25)SEG4 and    | 12.2(44)SE6            |
|            | later are not vulnerable;   |                        |
|            | first fixed in 12.2SE       |                        |
|------------+-----------------------------+------------------------|
| 12.2SG     | 12.2(50)SG                  | 12.2(52)SG; Available  |
|            |                             | on 15-MAY-2009         |
|------------+-----------------------------+------------------------|
| 12.2SGA    | 12.2(31)SGA9                | 12.2(31)SGA9           |
|------------+-----------------------------+------------------------|
| 12.2SL     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2SM     | Vulnerable; contact TAC     |                        |
|------------+-----------------------------+------------------------|
| 12.2SO     | Vulnerable; contact TAC     |                        |
|------------+-----------------------------+------------------------|
| 12.2SQ     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
|            | Vulnerable; first fixed in  | 12.2(33)SRC4;          |
| 12.2SRA    | 12.2SRC                     | Available on           |
|            |                             | 18-MAY-2009            |
|------------+-----------------------------+------------------------|
|            |                             | 12.2(33)SRB5a;         |
|            |                             | Available on           |
| 12.2SRB    | Vulnerable; first fixed in  | 3-April-2009 12.2(33)  |
|            | 12.2SRC                     | SRC4; Available on     |
|            |                             | 18-MAY-2009 12.2(33)   |
|            |                             | SRD1                   |
|------------+-----------------------------+------------------------|
|            |                             | 12.2(33)SRC4;          |
| 12.2SRC    | 12.2(33)SRC3                | Available on           |
|            |                             | 18-MAY-2009 12.2(33)   |
|            |                             | SRD1                   |
|------------+-----------------------------+------------------------|
| 12.2SRD    | 12.2(33)SRD1                | 12.2(33)SRD1           |
|------------+-----------------------------+------------------------|
| 12.2STE    | Vulnerable; contact TAC     |                        |
|------------+-----------------------------+------------------------|
| 12.2SU     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2SV     | Vulnerable; contact TAC     |                        |
|------------+-----------------------------+------------------------|
| 12.2SVA    | Vulnerable; contact TAC     |                        |
|------------+-----------------------------+------------------------|
| 12.2SVC    | Vulnerable; contact TAC     |                        |
|------------+-----------------------------+------------------------|
| 12.2SVD    | Vulnerable; contact TAC     |                        |
|------------+-----------------------------+------------------------|
| 12.2SVE    | Vulnerable; contact TAC     |                        |
|------------+-----------------------------+------------------------|
| 12.2SW     | Vulnerable; migrate to any  |                        |
|            | release in 12.4SW           |                        |
|------------+-----------------------------+------------------------|
| 12.2SX     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2SXA    | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2SXB    | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2SXD    | Vulnerable; first fixed in  | 12.2(18)SXF16          |
|            | 12.2SXF                     |                        |
|------------+-----------------------------+------------------------|
| 12.2SXE    | Vulnerable; first fixed in  | 12.2(18)SXF16          |
|            | 12.2SXF                     |                        |
|------------+-----------------------------+------------------------|
| 12.2SXF    | 12.2(18)SXF16               | 12.2(18)SXF16          |
|------------+-----------------------------+------------------------|
|            | 12.2(33)SXH5; Available on  | 12.2(33)SXH5;          |
| 12.2SXH    | 20-APR-2009                 | Available on           |
|            |                             | 20-APR-2009            |
|------------+-----------------------------+------------------------|
| 12.2SXI    | 12.2(33)SXI1                | 12.2(33)SXI1           |
|------------+-----------------------------+------------------------|
| 12.2SY     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2SZ     | Vulnerable; first fixed in  | 12.2(33)SB4            |
|            | 12.2SB                      |                        |
|------------+-----------------------------+------------------------|
| 12.2T      | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2TPC    | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2XA     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2XB     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2XC     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2XD     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2XE     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2XF     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2XG     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2XH     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2XI     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2XJ     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2XK     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2XL     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2XM     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
|            | Vulnerable; first fixed in  | 12.2(33)SB4            |
| 12.2XN     | 12.2SRC                     |                        |
|            |                             | 12.2(33)SRD1           |
|------------+-----------------------------+------------------------|
| 12.2XNA    | Vulnerable; first fixed in  | 12.2(33)SRD1           |
|            | 12.2SRD                     |                        |
|------------+-----------------------------+------------------------|
| 12.2XNB    | 12.2(33)XNB1                | 12.2(33)XNB3           |
|------------+-----------------------------+------------------------|
| 12.2XNC    | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2XO     | 12.2(46)XO                  | 12.2(46)XO             |
|------------+-----------------------------+------------------------|
| 12.2XQ     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2XR     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2XS     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2XT     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2XU     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2XV     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2XW     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2YA     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2YB     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2YC     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2YD     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2YE     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2YF     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2YG     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2YH     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2YJ     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2YK     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2YL     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2YM     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2YN     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2YO     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2YP     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2YQ     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2YR     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2YS     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2YT     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2YU     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2YV     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2YW     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2YX     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2YY     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2YZ     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2ZA     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2ZB     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2ZC     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2ZD     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2ZE     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2ZF     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2ZG     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2ZH     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2ZJ     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2ZL     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.2ZP     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
|            | Vulnerable; first fixed in  | 12.2(33)SXH5;          |
| 12.2ZU     | 12.2SXH                     | Available on           |
|            |                             | 20-APR-2009            |
|------------+-----------------------------+------------------------|
| 12.2ZX     | Vulnerable; first fixed in  | 12.2(33)SB4            |
|            | 12.2SB                      |                        |
|------------+-----------------------------+------------------------|
| 12.2ZY     | Vulnerable; contact TAC     |                        |
|------------+-----------------------------+------------------------|
| 12.2ZYA    | 12.2(18)ZYA1                | 12.2(18)ZYA1           |
|------------+-----------------------------+------------------------|
| Affected   |                             |                        |
| 12.3-Based | First Fixed Release         | Recommended Release    |
| Releases   |                             |                        |
|-------------------------------------------------------------------|
| There are no affected 12.3 based releases                         |
|-------------------------------------------------------------------|
| Affected   |                             |                        |
| 12.4-Based | First Fixed Release         | Recommended Release    |
| Releases   |                             |                        |
|------------+-----------------------------+------------------------|
| 12.4       | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.4JA     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.4JDA    | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.4JK     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.4JL     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.4JMA    | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.4JMB    | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.4JX     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
|            | 12.4(15)MD2                 |                        |
|            |                             |                        |
| 12.4MD     | Releases prior to 12.4(11)  | 12.4(11)MD7            |
|            | MD6 are not vulnerable,     |                        |
|            | releases 12.4(15)MD and     |                        |
|            | later are vulnerable.       |                        |
|------------+-----------------------------+------------------------|
|            | 12.4(19)MR1                 |                        |
|            |                             |                        |
| 12.4MR     | Releases prior to 12.4(16)  | 12.4(19)MR2            |
|            | MR2 are not vulnerable,     |                        |
|            | releases 12.4(19)MR and     |                        |
|            | later are vulnerable        |                        |
|------------+-----------------------------+------------------------|
| 12.4SW     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
|            | 12.4(22)T                   |                        |
|            |                             | 12.4(22)T1             |
| 12.4T      | 12.4(20)T2                  |                        |
|            |                             | 12.4(15)T9; Available  |
|            | Releases prior to 12.4(20)T | on 29-APR-2009         |
|            | are NOT vulnerable          |                        |
|------------+-----------------------------+------------------------|
| 12.4XA     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.4XB     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.4XC     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.4XD     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.4XE     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.4XF     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.4XG     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.4XJ     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.4XK     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.4XL     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.4XM     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.4XN     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.4XP     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.4XQ     | 12.4(15)XQ2                 | 12.4(15)XQ2            |
|------------+-----------------------------+------------------------|
|            |                             | 12.4(22)T1             |
| 12.4XR     | 12.4(15)XR4                 |                        |
|            |                             | 12.4(15)T9; Available  |
|            |                             | on 29-APR-2009         |
|------------+-----------------------------+------------------------|
| 12.4XT     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.4XV     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.4XW     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
|            |                             | 12.4(22)T1             |
| 12.4XY     | 12.4(15)XY4                 |                        |
|            |                             | 12.4(15)T9; Available  |
|            |                             | on 29-APR-2009         |
|------------+-----------------------------+------------------------|
| 12.4XZ     | 12.4(15)XZ2                 | 12.4(15)XZ2            |
|------------+-----------------------------+------------------------|
| 12.4YA     | 12.4(20)YA2                 | 12.4(20)YA3            |
|------------+-----------------------------+------------------------|
| 12.4YB     | Not Vulnerable              |                        |
|------------+-----------------------------+------------------------|
| 12.4YD     | Not Vulnerable              |                        |
+-------------------------------------------------------------------+

Workarounds
===========

The following mitigations have been identified for this
vulnerability, which may help protect an infrastructure until an
upgrade to a fixed version of Cisco IOS software can be scheduled:

Infrastructure Access Control Lists
+----------------------------------

Although it is often difficult to block traffic that transits a
network, it is possible to identify traffic that should never be
allowed to target infrastructure devices and block that traffic at
the border of networks. Infrastructure Access Control Lists (iACLs)
are a network security best practice and should be considered as a
long-term addition to good network security as well as a workaround
for these specific vulnerabilities. The iACL example below should be
included as part of the deployed infrastructure access-list which
will protect all devices with IP addresses in the infrastructure IP
address range:


    !---
    !--- Only sections pertaining to features enabled on the device
    !--- need be configured.
    !---
    !--- Feature: ALPS
    !---

    access-list 150 permit tcp TRUSTED_HOSTS WILDCARD
        INFRASTRUCTURE_ADDRESSES WILDCARD eq 350
    access-list 150 permit tcp TRUSTED_HOSTS WILDCARD
        INFRASTRUCTURE_ADDRESSES WILDCARD eq 10000

    !---
    !--- Deny ALPS TCP traffic from all other sources destined
    !--- to infrastructure addresses.
    !---

    access-list 150 deny tcp any
         INFRASTRUCTURE_ADDRESSES WILDCARD eq 350
    access-list 150 deny tcp any
         INFRASTRUCTURE_ADDRESSES WILDCARD eq 10000

    !---
    !--- Feature: STUN
    !---

    access-list 150 permit tcp TRUSTED_HOSTS WILDCARD
         INFRASTRUCTURE_ADDRESSES WILDCARD eq 1994
    access-list 150 permit tcp TRUSTED_HOSTS WILDCARD
         INFRASTRUCTURE_ADDRESSES WILDCARD range 1990 1992

    !---
    !--- Deny STUN TCP traffic from all other sources destined
    !--- to infrastructure addresses.
    !---

    access-list 150 deny tcp any
        INFRASTRUCTURE_ADDRESSES WILDCARD eq 1994
    access-list 150 deny tcp any
        INFRASTRUCTURE_ADDRESSES WILDCARD range 1990 1992

    !---
    !--- Feature: BSTUN
    !---

    access-list 150 permit tcp TRUSTED_HOSTS WILDCARD
         INFRASTRUCTURE_ADDRESSES WILDCARD eq 1963
    access-list 150 permit tcp TRUSTED_HOSTS WILDCARD
         INFRASTRUCTURE_ADDRESSES WILDCARD range 1976 1979

    !---
    !--- Deny BSTUN TCP traffic from all other sources destined
    !--- to infrastructure addresses.
    !---

    access-list 150 deny tcp any
         INFRASTRUCTURE_ADDRESSES WILDCARD eq 1963
    access-list 150 deny tcp any
         INFRASTRUCTURE_ADDRESSES WILDCARD range 1976 1979

    !---
    !--- Feature: NCIA
    !---

    !---
    !--- Leverage the underlying protocols, DLSw, RSRB, etc.
    !---

    !---
    !--- Feature: DLSW
    !---

    access-list 150 permit tcp TRUSTED_HOSTS WILDCARD
         INFRASTRUCTURE_ADDRESSES WILDCARD eq 2065
    access-list 150 permit tcp TRUSTED_HOSTS WILDCARD
         INFRASTRUCTURE_ADDRESSES WILDCARD eq 2067
    access-list 150 permit tcp TRUSTED_HOSTS WILDCARD
         INFRASTRUCTURE_ADDRESSES WILDCARD range 1981 1983

    !---
    !--- Deny DLSW TCP traffic from all other sources destined
    !--- to infrastructure addresses.
    !---

    access-list 150 deny tcp any
         INFRASTRUCTURE_ADDRESSES WILDCARD eq 2065
    access-list 150 deny tcp any
         INFRASTRUCTURE_ADDRESSES WILDCARD eq 2067
    access-list 150 deny tcp any
         INFRASTRUCTURE_ADDRESSES WILDCARD range 1981 1983

    !---
    !--- Feature: RSRB
    !---

    access-list 150 permit tcp TRUSTED_HOSTS WILDCARD
         INFRASTRUCTURE_ADDRESSES WILDCARD range 1987 1989
    access-list 150 permit tcp TRUSTED_HOSTS WILDCARD
         INFRASTRUCTURE_ADDRESSES WILDCARD eq 1996

    !---
    !--- Deny RSRB TCP traffic from all other sources destined
    !--- to infrastructure addresses.
    !---

    access-list 150 deny tcp any
         INFRASTRUCTURE_ADDRESSES WILDCARD range 1987 1989
    access-list 150 deny tcp any
         INFRASTRUCTURE_ADDRESSES WILDCARD eq 1996

    !---
    !--- Feature: PPTP
    !---

    access-list 150 permit tcp TRUSTED_HOSTS WILDCARD
         INFRASTRUCTURE_ADDRESSES WILDCARD eq 1723

    !---
    !--- Deny PPTP TCP traffic from all other sources destined
    !--- to infrastructure addresses.
    !---

    access-list 150 deny tcp any
         INFRASTRUCTURE_ADDRESSES WILDCARD eq 1723

    !---
    !--- Feature: RBP
    !---
    !--- RBP will listen for TCP connections on the configured port
    !--- as per "local port <port_number>". The following example
    !--- uses port 1055
    !---

    access-list 150 permit tcp TRUSTED_HOSTS WILDCARD
         INFRASTRUCTURE_ADDRESSES WILDCARD eq 1055

    !---
    !--- Deny RBP traffic from all other sources destined
    !--- to infrastructure addresses.
    !---

    access-list 150 deny tcp any
         INFRASTRUCTURE_ADDRESSES WILDCARD eq 1055

    !---
    !--- Feature: XOT and X.25 Routing
    !---

    access-list 150 permit tcp TRUSTED_HOSTS WILDCARD
         INFRASTRUCTURE_ADDRESSES WILDCARD eq 1998

    !---
    !--- Deny XOT and X25 TCP traffic from all other sources 
    !--- destined to infrastructure addresses.
    !---

    access-list 150 deny tcp any
         INFRASTRUCTURE_ADDRESSES WILDCARD eq 1998

    !---
    !--- Permit/deny all other Layer 3 and Layer 4 traffic in 
    !--- accordance with existing security policies and 
    !--- configurations Permit all other traffic to transit the
    !--- device.
    !---

    access-list 150 permit ip any any

    !---
    !--- Apply access-list to all interfaces (only one example
    !--- shown)
    !---

    interface serial 2/0
     ip access-group 150 in

The white paper entitled "Protecting Your Core: Infrastructure
Protection Access Control Lists" presents guidelines and recommended
deployment techniques for infrastructure protection access lists.
This white paper can be obtained at the following link: 
http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801a1a55.shtml

Receive ACLs (rACL)
+------------------

For distributed platforms, Receive ACLs may be an option starting in
Cisco IOS Software Versions 12.0(21)S2 for the 12000 (GSR), 12.0(24)S
for the 7500, and 12.0(31)S for the 10720. The Receive ACL protects
the device from harmful traffic before the traffic can impact the
route processor. Receive ACLs are designed to only protect the device
on which it is configured. On the 12000, 7500, and 10720, transit
traffic is never affected by a receive ACL. Because of this, the
destination IP address "any" used in the example ACL entries below
only refer to the router's own physical or virtual IP addresses.
Receive ACLs are considered a network security best practice, and
should be considered as a long-term addition to good network
security, as well as a workaround for this specific vulnerability.
The white paper entitled "Protecting Your Core: Infrastructure
Protection Access Control Lists" presents guidelines and recommended
deployment techniques for infrastructure protection access lists.
This white paper can be obtained at the following link 
http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801a0a5e.shtml

The following is the receive path ACL written to permit this type of
traffic from trusted hosts:


    !---
    !--- Only sections pertaining to features enabled on the device
    !--- need be configured.
    !---

    !---
    !--- Permit ALPS traffic from trusted hosts allowed to the RP.
    !--- 

    access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD
         any eq 350
    access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD
        any eq 10000

    !---
    !--- Deny ALPS traffic from all other sources to the RP.
    !--- 

    access-list 150 deny tcp any any eq 350
    access-list 150 deny tcp any any eq 10000

    !---
    !--- Permit STUN traffic from trusted hosts allowed to the RP.
    !--- 

    access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD
         any eq 1994
    access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD
         any range 1990 1992

    !---
    !--- Deny STUN traffic from all other sources to the RP.
    !--- 

    access-list 150 deny tcp any any eq 1994
    access-list 150 deny tcp any any eq range 1990 1992

    !---
    !--- Permit BSTUN traffic from trusted hosts allowed to the RP.
    !--- 

    access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD
         any eq 1963
    access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD
         any range 1976 1979

    !---
    !--- Deny BSTUN traffic from all other sources to the RP.
    !--- 

    access-list 150 deny tcp any any eq 1963
    access-list 150 deny tcp any any eq range 1976 1979

    !---
    !--- Permit DLSw from trusted hosts allowed to the RP.
    !--- 

    access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD
         any eq 2065
    access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD
         any eq 2067
    access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD
         any range 1981 1983

    !---
    !--- Deny DLSw all other sources to the RP.
    !--- 

    access-list 150 deny tcp any any eq 2065
    access-list 150 deny tcp any any eq 2067
    access-list 150 deny tcp any any range 1981 1983

    !---
    !--- Permit RSRB traffic from trusted hosts allowed to the RP.
    !---

    access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD
         any eq 1996
    access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD
         any range 1987 1989

    !---
    !--- Deny RSRB traffic from all other sources to the RP.
    !---

    access-list 150 deny tcp any any eq 1996
    access-list 150 deny tcp any any range 1987 1989

    !--- 
    !--- Permit PPTP traffic from trusted hosts allowed to the RP.
    !--- 

    access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD
         any eq 1723

    !---
    !--- Deny PPTP traffic from all other sources to the RP.
    !--- 

    access-list 150 deny tcp any any eq 1723

    !---
    !--- Permit RBP traffic from trusted hosts allowed to the RP.
    !--- RBP will listen for TCP connections on the configured port
    !--- as per "local port <port_number>".  The following example
    !--- uses port 1055
    !---

    access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD
         any eq 1055

    !---
    !--- Deny RBP traffic from all other sources to the RP.
    !---

    access-list 150 deny tcp any any eq 1055

    !---
    !--- Permit XOT and X.25 Routing traffic from trusted hosts allowed 
    !--- to the RP.
    !---

    access-list 150 permit tcp TRUSTED_SOURCE_ADDRESSES WILDCARD
         any eq 1998

    !---
    !--- Deny XOT and X.25 Routing traffic from all other sources to 
    !---  the RP.
    !---

    access-list 150 deny tcp any any  eq 1998

    !--- Permit all other traffic to the RP.
    !--- according to security policy and configurations.

    access-list 150 permit ip any any

    !--- Apply this access list to the 'receive' path.

    ip receive access-list 150

Control Plane Policing
+---------------------

Control Plane Policing (CoPP) can be used to block the affected
features TCP traffic access to the device. Cisco IOS software
releases 12.0S, 12.2SX, 12.2S, 12.3T, 12.4, and 12.4T support the
CoPP feature. CoPP can be configured on a device to protect the
management and control planes and minimize the risk and effectiveness
of direct infrastructure attacks by explicitly permitting only
authorized traffic that is sent to infrastructure devices in
accordance with existing security policies and configurations. The
CoPP example below should be included as part of the deployed CoPP
that will protect all devices with IP addresses in the infrastructure
IP address range.


    !---
    !--- Only sections pertaining to features enabled on the device
    !--- need be configured.
    !---
    !--- Feature: ALPS
    !---

    access-list 150 deny tcp TRUSTED_HOSTS WILDCARD any eq 350
    access-list 150 deny tcp TRUSTED_HOSTS WILDCARD any eq 10000

    !---
    !--- Permit ALPS traffic sent to all IP addresses
    !--- configured on all interfaces of the affected device so
    !--- that it will be policed and dropped by the CoPP feature
    !---

    access-list 150 permit tcp any any eq 350
    access-list 150 permit tcp any any eq 10000

    !---
    !--- Feature: STUN
    !---

    access-list 150 deny tcp TRUSTED_HOSTS WILDCARD
         any eq 1994
    access-list 150 deny tcp TRUSTED_HOSTS WILDCARD
         any range 1990 1992

    !---
    !--- Permit STUN traffic sent to all IP addresses
    !--- configured on all interfaces of the affected device so 
    !--- that it will be policed and dropped by the CoPP feature
    !---

    access-list 150 permit tcp any any eq 1994
    access-list 150 permit tcp any any range 1990 1992

    !---
    !--- Feature: BSTUN
    !---

    access-list 150 deny tcp TRUSTED_HOSTS WILDCARD
         any eq 1963
    access-list 150 deny tcp TRUSTED_HOSTS WILDCARD
         any range 1976 1979

    !---
    !--- Permit BSTUN traffic sent to all IP addresses
    !--- configured on all interfaces of the affected device so
    !--- that it will be policed and dropped by the CoPP feature
    !---

    access-list 150 permit tcp any any eq 1963
    access-list 150 permit tcp any any range 1976 1979

    !---
    !--- Feature: NCIA
    !---
    !--- Leverage the underlying protocols, DLSw, RSRB, etc.
    !---

    !---
    !--- Feature: DLSW
    !---

    access-list 150 deny tcp TRUSTED_HOSTS WILDCARD
         any eq 2065
    access-list 150 deny tcp TRUSTED_HOSTS WILDCARD
         any eq 2067
    access-list 150 deny tcp TRUSTED_HOSTS WILDCARD
         any range 1981 1983

    !---
    !--- Permit DLSW traffic sent to all IP addresses
    !--- configured on all interfaces of the affected device so 
    !--- that it will be policed and dropped by the CoPP feature
    !---

    access-list 150 permit tcp any any eq 2065
    access-list 150 permit tcp any any eq 2067
    access-list 150 permit tcp any any range 1981 1983

    !---
    !--- Feature: RSRB
    !---

    access-list 150 deny tcp TRUSTED_HOSTS WILDCARD
         any range 1987 1989
    access-list 150 deny tcp TRUSTED_HOSTS WILDCARD
         any eq 1996

    !---
    !--- Permit RSRB traffic sent to all IP addresses
    !--- configured on all interfaces of the affected device so 
    !--- that it will be policed and dropped by the CoPP feature
    !---

    access-list 150 permit tcp any any range 1987 1989
    access-list 150 permit tcp any any eq 1996

    !---
    !--- Feature: PPTP
    !---

    access-list 150 deny tcp TRUSTED_HOSTS WILDCARD
         any eq 1723

    !---
    !--- Permit PPTP traffic sent to all IP addresses
    !--- configured on all interfaces of the affected device so 
    !--- that it will be policed and dropped by the CoPP feature
    !---

    access-list 150 permit tcp any any eq 1723

    !---
    !--- Feature: RBP
    !---
    !--- RBP will listen for TCP connections on the configured port
    !--- as per "local port <port_number>".  The following example
    !--- uses port 1055

    access-list 150 deny tcp TRUSTED_HOSTS WILDCARD
         any eq 1055

    !---
    !--- Permit RBP traffic sent to all IP addresses
    !--- configured on all interfaces of the affected device so 
    !--- that it will be policed and dropped by the CoPP feature
    !---

    access-list 150 permit tcp any any eq 1055

    !---
    !--- Feature: XOT and X.25 Routing
    !---

    access-list 150 deny tcp TRUSTED_HOSTS WILDCARD
         any eq 1998

    !---
    !--- Permit XOT and X25 traffic sent to all IP addresses
    !--- configured on all interfaces of the affected device so 
    !--- that it will be policed and dropped by the CoPP feature
    !---

    access-list 150 permit tcp any any eq 1998

    !---
    !--- Permit (Police or Drop)/Deny (Allow) all other Layer3 and 
    !--- Layer4 traffic in accordance with existing security policies
    !--- configurations for traffic that is authorized to be sent
    !--- and to infrastructure devices
    !--- Create a Class-Map for traffic to be policed by
    !--- the CoPP feature
    !---

    class-map match-all drop-tcp-class
     match access-group 150

    !---
    !--- Create a Policy-Map that will be applied to the
    !--- Control-Plane of the device.
    !---

    policy-map drop-tcp-traffic
     class drop-tcp-class
      drop

    !---
    !--- Apply the Policy-Map to the 
    !--- Control-Plane of the device
    !---

    control-plane
     service-policy input drop-tcp-traffic

In the above CoPP example, the access control list entries (ACEs)
that match the potential exploit packets with the "permit" action
result in these packets being discarded by the policy-map "drop"
function, while packets that match the "deny" action (not shown) are
not affected by the policy-map drop function. Please note that the
policy-map syntax is different in the 12.2S and 12.0S Cisco IOS
trains:

    policy-map drop-tcp-traffic
      class drop-tcp-class
        police 32000 1500 1500 conform-action drop exceed-action drop

Additional information on the configuration and use of the CoPP
feature can be found in the documents, "Control Plane Policing
Implementation Best Practices" and "Cisco IOS Software Releases 12.2S
- - Control Plane Policing" at the following links 
http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html
and
http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gtrtlimt.html

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, at the following link 
http://www.cisco.com/warp/public/707/cisco-amb-20090325-tcp-and-ip.shtml

Obtaining Fixed Software
========================

Cisco has released free software updates that address these
vulnerabilities. Prior to deploying software, customers should
consult their maintenance provider or check the software for feature
set compatibility and known issues specific to their environment.

Customers may only install and expect support for the feature sets
they have purchased. By installing, downloading, accessing or
otherwise using such software upgrades, customers agree to be bound
by the terms of Cisco's software license terms found at 
http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html,
or as otherwise set forth at Cisco.com Downloads at 
http://www.cisco.com/public/sw-center/sw-usingswc.shtml 

Do not contact psirt at cisco.com or security-alert at cisco.com for
software upgrades.

Customers with Service Contracts
+-------------------------------

Customers with contracts should obtain upgraded software through
their regular update channels. For most customers, this means that
upgrades should be obtained through the Software Center on Cisco's
worldwide website at http://www.cisco.com

Customers using Third Party Support Organizations
+------------------------------------------------

Customers whose Cisco products are provided or maintained through
prior or existing agreements with third-party support organizations,
such as Cisco Partners, authorized resellers, or service providers
should contact that support organization for guidance and assistance
with the appropriate course of action in regards to this advisory.

The effectiveness of any workaround or fix is dependent on specific
customer situations, such as product mix, network topology, traffic
behavior, and organizational mission. Due to the variety of affected
products and releases, customers should consult with their service
provider or support organization to ensure any applied workaround or
fix is the most appropriate for use in the intended network before it
is deployed.

Customers without Service Contracts
+----------------------------------

Customers who purchase direct from Cisco but do not hold a Cisco
service contract, and customers who purchase through third-party
vendors but are unsuccessful in obtaining fixed software through
their point of sale should acquire upgrades by contacting the Cisco
Technical Assistance Center (TAC). TAC contacts are as follows.

  * +1 800 553 2447 (toll free from within North America)
  * +1 408 526 7209 (toll call from anywhere in the world)
  * e-mail: tac at cisco.com

Customers should have their product serial number available and be
prepared to give the URL of this notice as evidence of entitlement to
a free upgrade. Free upgrades for non-contract customers must be
requested through the TAC.

Refer to http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html
for additional TAC contact information, including localized telephone
numbers, and instructions and e-mail addresses for use in various 
languages.

Exploitation and Public Announcements
=====================================

The Cisco PSIRT is not aware of any public announcements or malicious
use of the vulnerability described in this advisory.

This vulnerability was found by Cisco internal testing.

Status of this Notice: FINAL
============================

THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY
KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE
INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS
AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS
DOCUMENT AT ANY TIME.

A stand-alone copy or Paraphrase of the text of this document that
omits the distribution URL in the following section is an
uncontrolled copy, and may lack important information or contain
factual errors.

Distribution
============

This advisory is posted on Cisco's worldwide website at :

http://www.cisco.com/warp/public/707/cisco-sa-20090325-tcp.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-March-25 | 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-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAknKUb8ACgkQ86n/Gc8U/uCp1gCfS6aMv74rf1bDoby1JcGRFsN3
hpYAn1Oqp7nQxPwBrtptF3WM42HgGdIk
=NVYK
-----END PGP SIGNATURE-----

From psirt at cisco.com  Wed Mar 25 12:00:00 2009
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Wed, 25 Mar 2009 17:00:00 +0100
Subject: [c-nsp] Cisco Security Advisory: Cisco IOS Software Multiple
	Features Crafted UDP Packet Vulnerability
Message-ID: <200903251705.udp@psirt.cisco.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cisco Security Advisory: Cisco IOS Software Multiple Features Crafted
UDP Packet Vulnerability

Advisory ID: cisco-sa-20090325-udp

http://www.cisco.com/warp/public/707/cisco-sa-20090325-udp.shtml

Revision 1.0

For Public Release 2009 March 25 1600 UTC (GMT)

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

Summary
=======

Several features within Cisco IOS Software are affected by a crafted
UDP packet vulnerability. If any of the affected features are
enabled, a successful attack will result in a blocked input queue on
the inbound interface. Only crafted UDP packets destined for the
device could result in the interface being blocked, transit traffic
will not block the interface.

Cisco has released free software updates that address this
vulnerability.

Workarounds that mitigate this vulnerability are available.

This advisory is posted at the following link: 
http://www.cisco.com/warp/public/707/cisco-sa-20090325-udp.shtml

Note: The March 25, 2009, Cisco IOS Security Advisory bundled
publication includes eight Security Advisories. All of the advisories
address vulnerabilities in Cisco IOS Software. Each advisory lists
the releases that correct the vulnerability or vulnerabilities in the
advisory. The following table lists releases that correct all Cisco
IOS Software vulnerabilities that have been published in Cisco
Security Advisories on March 25, 2009, or earlier.

http://www.cisco.com/warp/public/707/cisco-sa-20090325-bundle.shtml

Individual publication links are listed below:

  * Cisco IOS cTCP Denial of Service Vulnerability
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-ctcp.shtml

  * Cisco IOS Software Multiple Features IP Sockets Vulnerability
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-ip.shtml

  * Cisco IOS Software Mobile IP and Mobile IPv6 Vulnerabilities
    http://www.cisco.com/warp/public/707/ cisco-sa-20090325-mobileip.shtml

  * Cisco IOS Software Secure Copy Privilege Escalation Vulnerability
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-scp.shtml

  * Cisco IOS Software Session Initiation Protocol Denial of Service
    Vulnerability
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-sip.shtml

  * Cisco IOS Software Multiple Features Crafted TCP Sequence
    Vulnerability
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-tcp.shtml

  * Cisco IOS Software Multiple Features Crafted UDP Packet
    Vulnerability
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-udp.shtml

  * Cisco IOS Software WebVPN and SSLVPN Vulnerabilities
    http://www.cisco.com/warp/public/707/cisco-sa-20090325-webvpn.shtml

Affected Products
=================

Vulnerable Products
+------------------

Devices running affected versions of Cisco IOS Software and Cisco IOS
XE Software are affected when running any of the following features:

  * IP Service Level Agreements (SLA) Responder
  * Session Initiation Protocol (SIP)
  * H.323 Annex E Call Signaling Transport
  * Media Gateway Control Protocol (MGCP)

Details on how to see if the affected feature is enabled on a device,
is provided within the details section of this advisory.

To determine the Cisco IOS Software release that is running on a
Cisco product, administrators can log in to the device and issue the
"show version" command to display the system banner. The system
banner confirms that the device is running Cisco IOS Software by
displaying text similar to "Cisco Internetwork Operating System
Software" or "Cisco IOS Software." The image name displays in
parentheses, followed by "Version" and the Cisco IOS Software release
name. Other Cisco devices do not have the "show version" command or
may provide different output.

The following example identifies a Cisco product that is running
Cisco IOS Software Release 12.3(26) with an installed image name of
C2500-IS-L:

     Router#show version
     Cisco Internetwork Operating System Software
     IOS (tm) 2500 Software (C2500-IS-L), Version 12.3(26), RELEASE SOFTWARE (fc2)
     Technical Support: http://www.cisco.com/techsupport
     Copyright (c) 1986-2008 by cisco Systems, Inc.
     Compiled Mon 17-Mar-08 14:39 by dchih

     <output truncated>

The following example shows a product that is running Cisco IOS
Software release 12.4(20)T with an image name of
C1841-ADVENTERPRISEK9-M:

    Router#show version
    Cisco IOS Software, 1841 Software (C1841-ADVENTERPRISEK9-M), Version 12.4(20)T, RELEASE SOFTWARE (fc3)
    Technical Support: http://www.cisco.com/techsupport
    Copyright (c) 1986-2008 by Cisco Systems, Inc.
    Compiled Thu 10-Jul-08 20:25 by prod_rel_team

    <output truncated>

Additional information about Cisco IOS Software release naming
conventions is available in "White Paper: Cisco IOS Reference Guide"
at the following link: http://www.cisco.com/warp/public/620/1.html

Products Confirmed Not Vulnerable
+--------------------------------

The following products and features are not affected by this
vulnerability:

  * Cisco IOS XR Software
  * Service Assurance Agent (SAA)
  * Response Time Reporter (RTR)
  * No other feature or protocol on Cisco IOS is known to be affected

No other Cisco products are currently known to be affected by this
vulnerability.

Details
=======

A device is vulnerable if any of the features outlined below is
configured and their associated UDP port number accessible. For each
feature, in addition to inspecting the Cisco IOS device for
vulnerable configurations, administrators can also use some show
commands to determine if the Cisco IOS device is running processes
that handle the UDP service, or if the device is listening on the
affected UDP ports.

Different versions of Cisco IOS Software have different methods of
showing the UDP ports on which the Cisco IOS Software device is
listening. The "show ip sockets" or "show udp" commands can be used
to determine these ports. For each feature, one example is given
using the above commands to show the affected UDP port number.

Successful exploitation of this vulnerability can block an interface
on the device. The interface type is not relevant for this
vulnerability so all Ethernet based interfaces, ATM, Serial, POS and
other types of interfaces can be affected. All defined sub interfaces
under a main physical interface are affected if the main interface is
blocked. If the attack originates over a sub interface, the main
interface will block. A blocked interface will stop receiving any
subsequent packets until it is unblocked. All other interfaces are
not affected and they will continue receiving and transmitting
packets.

Only packets destined for a reachable configured IP address on any
interface of the device can exploit this vulnerability. Transit
traffic will not exploit this vulnerability.

A symptom of this type of blocked queue is the failure of
control-plane protocols such as routing protocols (OSPF, EIGRP, BGP,
ISIS, etc.) and MPLS TDP/LDP to properly establish connections over
an affected interface. Transit traffic may be affected once protocol
timers expire on the affected device.

In order to identify a blocked input interface, issue the "show
interfaces" command, and search for the Input Queue line. The size of
the input queue can continue to increase. If the current size, which
is 76 in the example below, is equal or larger than the maximum size
(default being 75), the input queue may be blocked.

It is possible that a device receives a high rate of traffic destined
to the control plane, and the full queue is only a transient event.
In order to verify if the interface is actually blocked, shut down
the interface with the shutdown interface configuration command and
examine the input queue. If the input queue does not display 0
packets, the interface is blocked.

    Router#show interface ethernet 0/0
    Ethernet0/0 is up, line protocol is up
     Hardware is AmdP2, address is 0050.500e.f1e0 (bia 0050.500e.f1e0)
     Internet address is 192.168.0.1/24
     MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/255, load 1/255
     Encapsulation ARPA, loopback not set, keepalive set (10 sec)
     ARP type: ARPA, ARP Timeout 04:00:00
     Last input 00:00:41, output 00:00:07, output hang never
     Last clearing of "show interface" counters 00:07:18
     Input queue: 76/75/1091/0 (size/max/drops/flushes); Total output drops: 0

IP Service Level Agreements (SLAs) Responder
+-------------------------------------------

Devices configured with the Cisco IOS IP Service Level Agreements
(SLAs) Responder for User Datagram Protocol (UDP) echo or jitter
operations feature are vulnerable. Any device configured to act as a
responder is vulnerable. The following shows two different vulnerable
configurations. The first being a generic IP SLA responder:

    ip sla responder

or

    ip sla monitor responder

The following shows this second configuration with a more specific
UDP responder configured:

    ip sla responder
    ip sla responder udp-echo ipaddress 10.10.10.10 port 1025

Service Assurance Agent (SAA) and Response Time Reporter (RTR)
feature are "not" affected and use the "rtr" CLI command syntax. The
following example shows a configuration, which is not vulnerable:

    rtr responder

The following example shows a device listening on the default IP SLA
control channel with the affected UDP port 1967.

    Router#show udp
    Proto    Remote      Port      Local       Port  In Out Stat TTY OutputIF
     17 0.0.0.0             0 10.2.6.1         1967   0   0  211   0

Further information about Cisco IOS IP SLAs is available in "Cisco
IOS IP SLAs Configuration Guide, Release 12.4 - Cisco IOS IP SLAs
Overview" at the following link: 
http://www.cisco.com/en/US/docs/ios/12_4/ip_sla/configuration/guide/hsoverv.html

Session Initiation Protocol (SIP)
+--------------------------------

Note: For customers with devices enabled with SIP, please also
consult the document "Cisco Security Advisory: Cisco IOS Session
Initiation Protocol Denial of Service Vulnerability" at the following
link: http://www.cisco.com/warp/public/707/cisco-sa-20090325-sip.html

Cisco devices that process SIP messages are affected. Recent versions
of Cisco IOS Software do not process SIP messages by default.
Creating a "dial peer" via the command "dial-peer voice" with any
option will start the SIP processes and cause Cisco IOS Software to
begin processing SIP messages. Several features within Cisco Call
Manager Express, such as ePhones, once configured will also
automatically start the SIP process and the device will begin
processing SIP messages. It is recommended if the device is running
any voice configurations to confirm the existence of the SIP process
with the "show ip socket" or "show udp" command. The following is one
example of an affected configuration:

    dial-peer voice <Voice dial-peer tag> voip
     ...
    !

Note: Older versions of Cisco IOS Software were affected by a bug
that caused Cisco IOS Software to process SIP messages even without
being configured for SIP operation. Please refer to "Cisco Security
Advisory: SIP Packets Reload IOS Devices with support for SIP" at the
following link: 
http://www.cisco.com/warp/public/707/cisco-sa-20070131-sip.shtml

The following example shows a device that will process SIP messages,
on the default affected UDP port 5060:

    Router#show ip socket
    Proto    Remote      Port      Local       Port  In Out Stat TTY OutputIF
     17 0.0.0.0             0 192.168.0.2      5060   0   0  211   0

Further information about SIP, is available in the "Cisco IOS SIP
Configuration Guide" at the following link: 
http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123cgcr/vvfax_c/callc_c/sip_c/sipc1_c/index.htm

H.323 Annex E Call Signaling Transport
+-------------------------------------

Cisco devices that are configured to support H.323 are affected. The
affected protocol is H.323 Annex E Call Signaling Transport over UDP.
ITU-T recommendation H.323 Annex E describes the signaling framework
and wire-protocol for transporting H.225.0 call signaling messages
over UDP. Recent versions of Cisco IOS Software do not open H.225.0
UDP port by default. Creating a "dial peer" via the command
"dial-peer voice" with any option will open the H.225.0 UDP port.
Several features within Cisco Call Manager Express, such as ePhones,
once configured will also automatically start the H.323 process and
the device will begin processing H.323 packets. It is recommended if
the device is running any voice configurations to confirm the
existence of the H.323 process with the "show ip socket" or "show
udp" command. The following is one example of an affected
configuration:

    dial-peer voice <Voice dial-peer tag> voip
     ...
    !

Note: Older versions of Cisco IOS Software were affected by a bug
that caused Cisco IOS Software to listen on H.323 ports without being
configured for H.323 operation. Please refer to Cisco bug ID:
CSCsb25337

The following example shows a device that will process H.225.0
packets, on the default affected UDP port 2517:

    Router#show ip socket
    Proto    Remote      Port      Local       Port  In Out Stat TTY OutputIF

     17 0.0.0.0             0 192.168.0.2      2517   0   0  211   0

Further information about H.323, is available in the "Cisco IOS H.323
Configuration Guide" at the following link: 
http://www.cisco.com/en/US/docs/ios/12_3/vvf_c/cisco_ios_h323_configuration_guide/old_archives_h323/323confg.html

Media Gateway Control Protocol (MGCP)
+------------------------------------

Devices configured with the MGCP feature are vulnerable. MGCP is
enabled globally with the command "mgcp". The default listening port
for MGCP is UDP 2427. The following example shows a vulnerable
configuration:

    mgcp

The following example shows a device that will process MGCP packets
on the affected UDP ports:

    Router#show ip socket
    Proto    Remote      Port      Local       Port  In Out Stat TTY OutputIF
     17 192.168.0.1     2427 10.66.91.138      2427   0   0  211   0

Further information about MGCP is available in the "Configuring the
Cisco IOS MGCP Gateway reference" at the following link: 
http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_tech_note09186a008017787b.shtml

This vulnerability is documented in the following Cisco Bug ID:
CSCsk64158 and has been assigned the Common Vulnerabilities and Exposures
(CVE) identifiers CVE-2009-0631.

Vulnerability Scoring Details
=============================

Cisco has provided scores for the vulnerability in this advisory
based on the Common Vulnerability Scoring System (CVSS). The CVSS
scoring in this Security Advisory is done in accordance with CVSS
version 2.0.

CVSS is a standards-based scoring method that conveys vulnerability
severity and helps determine urgency and priority of response.

Cisco has provided a base and temporal score. Customers can then
compute environmental scores to assist in determining the impact of
the vulnerability in individual networks.

Cisco has provided an FAQ to answer additional questions regarding
CVSS at

http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html

Cisco has also provided a CVSS calculator to help compute the
environmental impact for individual networks at

http://intellishield.cisco.com/security/alertmanager/cvss

CSCsk64158: Cisco IOS Software Multiple Features Crafted UDP Packet
            Vulnerability

CVSS Base Score - 7.8

 Access Vector           - Network
 Access Complexity       - Low
 Authentication          - None
 Confidentiality Impact  - None
 Integrity Impact        - None
 Availability Impact     - Complete

CVSS Temporal Score - 6.4

 Exploitability          - Functional
 Remediation Level       - Official-Fix
 Report Confidence       - Confirmed

Impact
======

Successful exploitation of this vulnerability may cause the inbound
interface to be blocked and will silently drop any received traffic.
A reload of the device is required to restore normal functionality.

Software Versions and Fixes
===========================

When considering software upgrades, also consult 
http://www.cisco.com/go/psirt and any subsequent advisories to 
determine exposure and a complete upgrade solution.

In all cases, customers should exercise caution to be certain the
devices to be upgraded contain sufficient memory and that current
hardware and software configurations will continue to be supported
properly by the new release. If the information is not clear, contact
the Cisco Technical Assistance Center (TAC) or your contracted
maintenance provider for assistance.

Each row of the Cisco IOS software table (below) names a Cisco IOS
release train. If a given release train is vulnerable, then the
earliest possible releases that contain the fix (along with the
anticipated date of availability for each, if applicable) are listed
in the "First Fixed Release" column of the table. The "Recommended
Release" column indicates the releases which have fixes for all the
published vulnerabilities at the time of this Advisory. A device
running a release in the given train that is earlier than the release
in a specific column (less than the First Fixed Release) is known to
be vulnerable. Cisco recommends upgrading to a release equal to or
later than the release in the "Recommended Releases" column of the
table.

+-------------------------------------------------------------------+
|   Major    |          Availability of Repaired Releases           |
|  Release   |                                                      |
|------------+------------------------------------------------------|
| Affected   |                                     | Recommended    |
| 12.0-Based | First Fixed Release                 | Release        |
| Releases   |                                     |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0       | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0DA     | Vulnerable; first fixed in 12.2DA   | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0DB     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0DC     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.0S      | 12.0(32)S12                         | 12.0(32)S12    |
|------------+-------------------------------------+----------------|
| 12.0SC     | Vulnerable; first fixed in 12.0S    | 12.0(32)S12    |
|------------+-------------------------------------+----------------|
| 12.0SL     | Vulnerable; first fixed in 12.0S    | 12.0(32)S12    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0SP     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.0ST     | Vulnerable; first fixed in 12.0S    | 12.0(32)S12    |
|------------+-------------------------------------+----------------|
| 12.0SX     | Vulnerable; first fixed in 12.0S    | 12.0(32)S12    |
|------------+-------------------------------------+----------------|
| 12.0SY     | 12.0(32)SY8                         | 12.0(32)SY8    |
|------------+-------------------------------------+----------------|
| 12.0SZ     | Vulnerable; first fixed in 12.0S    | 12.0(32)S12    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0T      | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.0W      | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.0WC     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.0WT     | Not Vulnerable                      |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0XA     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0XB     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0XC     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0XD     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0XE     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.0XF     | Not Vulnerable                      |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0XG     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0XH     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            | Releases prior to 12.0(4)XI2 are    | 12.4(18e)      |
|            | vulnerable, release 12.0(4)XI2 and  |                |
| 12.0XI     | later are not vulnerable; first     | 12.4(23a);     |
|            | fixed in 12.4                       | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0XJ     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0XK     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0XL     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0XM     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0XN     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0XQ     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0XR     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0XS     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0XT     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.0XV     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| Affected   |                                     | Recommended    |
| 12.1-Based | First Fixed Release                 | Release        |
| Releases   |                                     |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1       | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.1AA     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.1AX     | Vulnerable; first fixed in 12.2SE   | 12.2(44)SE6    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.1(22)EA13   |
| 12.1AY     | Vulnerable; first fixed in 12.1EA   |                |
|            |                                     | 12.2(44)SE6    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.1(22)EA13   |
| 12.1AZ     | Vulnerable; first fixed in 12.1EA   |                |
|            |                                     | 12.2(44)SE6    |
|------------+-------------------------------------+----------------|
| 12.1CX     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.1DA     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.1DB     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.1DC     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.1E      | Vulnerable; first fixed in 12.2SXF  | 12.2(18)SXF16  |
|------------+-------------------------------------+----------------|
| 12.1EA     | 12.1(22)EA13                        | 12.1(22)EA13   |
|------------+-------------------------------------+----------------|
| 12.1EB     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.2(33)SCB1   |
| 12.1EC     | Vulnerable; first fixed in 12.3BC   |                |
|            |                                     | 12.3(23)BC6    |
|------------+-------------------------------------+----------------|
| 12.1EO     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.1EU     | Vulnerable; first fixed in 12.2SG   | 12.2(31)SGA9   |
|------------+-------------------------------------+----------------|
| 12.1EV     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.1EW     | Vulnerable; migrate to 12.2SGA      | 12.2(31)SGA9   |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1EX     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.1EY     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.1EZ     | Vulnerable; first fixed in 12.2SXF  | 12.2(18)SXF16  |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1GA     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1GB     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1T      | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XA     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XB     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XC     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XD     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XE     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XF     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XG     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XH     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XI     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XJ     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XL     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XM     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XP     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XQ     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XR     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XS     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XT     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XU     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XV     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XW     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XX     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XY     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1XZ     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1YA     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1YB     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1YC     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1YD     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            | Releases prior to 12.1(5)YE6 are    | 12.4(18e)      |
|            | vulnerable, release 12.1(5)YE6 and  |                |
| 12.1YE     | later are not vulnerable; first     | 12.4(23a);     |
|            | fixed in 12.4                       | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1YF     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.1YH     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.1YI     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.1(22)EA13   |
| 12.1YJ     | Vulnerable; first fixed in 12.1EA   |                |
|            |                                     | 12.2(44)SE6    |
|------------+-------------------------------------+----------------|
| Affected   |                                     | Recommended    |
| 12.2-Based | First Fixed Release                 | Release        |
| Releases   |                                     |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2       | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.2B      | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            | Vulnerable; migrate to 12.2SCB or   | 12.2(33)SCB1   |
| 12.2BC     | 12.3BC                              |                |
|            |                                     | 12.3(23)BC6    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2BW     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.2BX     | Vulnerable; migrate to 12.2SB       | 12.2(33)SB4    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2BY     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2BZ     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            | Vulnerable; migrate to 12.2SCB or   | 12.2(33)SCB1   |
| 12.2CX     | 12.3BC                              |                |
|            |                                     | 12.3(23)BC6    |
|------------+-------------------------------------+----------------|
|            | Vulnerable; migrate to 12.2SCB or   | 12.2(33)SCB1   |
| 12.2CY     | 12.3BC                              |                |
|            |                                     | 12.3(23)BC6    |
|------------+-------------------------------------+----------------|
| 12.2CZ     | Vulnerable; first fixed in 12.2SB   | 12.2(33)SB4    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            | 12.2(12)DA14; Available on          |                |
| 12.2DA     | 30-JUL-2009                         | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2DD     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2DX     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.2EW     | Vulnerable; first fixed in 12.2SG   | 12.2(31)SGA9   |
|------------+-------------------------------------+----------------|
| 12.2EWA    | Vulnerable; first fixed in 12.2SG   | 12.2(31)SGA9   |
|------------+-------------------------------------+----------------|
| 12.2EX     | Vulnerable; first fixed in 12.2SE   | 12.2(44)SE6    |
|------------+-------------------------------------+----------------|
| 12.2EY     | 12.2(44)EY                          | 12.2(44)SE6    |
|------------+-------------------------------------+----------------|
| 12.2EZ     | Vulnerable; first fixed in 12.2SE   | 12.2(44)SE6    |
|------------+-------------------------------------+----------------|
| 12.2FX     | Vulnerable; first fixed in 12.2SE   | 12.2(44)SE6    |
|------------+-------------------------------------+----------------|
| 12.2FY     | Vulnerable; first fixed in 12.2SE   | 12.2(44)SE6    |
|------------+-------------------------------------+----------------|
| 12.2FZ     | Vulnerable; first fixed in 12.2SE   | 12.2(44)SE6    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.2(33)SRC4;  |
| 12.2IRA    | Vulnerable; first fixed in 12.2SRC  | Available on   |
|            |                                     | 18-MAY-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.2(33)SRC4;  |
| 12.2IRB    | Vulnerable; first fixed in 12.2SRC  | Available on   |
|            |                                     | 18-MAY-2009    |
|------------+-------------------------------------+----------------|
|            | Vulnerable; migrate to any release  | 12.2(18)IXH;   |
| 12.2IXA    | in 12.2IXH                          | Available on   |
|            |                                     | 31-MAR-2009    |
|------------+-------------------------------------+----------------|
|            | Vulnerable; migrate to any release  | 12.2(18)IXH;   |
| 12.2IXB    | in 12.2IXH                          | Available on   |
|            |                                     | 31-MAR-2009    |
|------------+-------------------------------------+----------------|
|            | Vulnerable; migrate to any release  | 12.2(18)IXH;   |
| 12.2IXC    | in 12.2IXH                          | Available on   |
|            |                                     | 31-MAR-2009    |
|------------+-------------------------------------+----------------|
|            | Vulnerable; migrate to any release  | 12.2(18)IXH;   |
| 12.2IXD    | in 12.2IXH                          | Available on   |
|            |                                     | 31-MAR-2009    |
|------------+-------------------------------------+----------------|
|            | Vulnerable; migrate to any release  | 12.2(18)IXH;   |
| 12.2IXE    | in 12.2IXH                          | Available on   |
|            |                                     | 31-MAR-2009    |
|------------+-------------------------------------+----------------|
|            | Vulnerable; migrate to any release  | 12.2(18)IXH;   |
| 12.2IXF    | in 12.2IXH                          | Available on   |
|            |                                     | 31-MAR-2009    |
|------------+-------------------------------------+----------------|
|            | Vulnerable; migrate to any release  | 12.2(18)IXH;   |
| 12.2IXG    | in 12.2IXH                          | Available on   |
|            |                                     | 31-MAR-2009    |
|------------+-------------------------------------+----------------|
| 12.2JA     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.2JK     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2MB     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.2MC     | 12.2(15)MC2m                        | 12.2(15)MC2m   |
|------------+-------------------------------------+----------------|
| 12.2S      | Vulnerable; first fixed in 12.2SB   | 12.2(33)SB4    |
|------------+-------------------------------------+----------------|
|            | 12.2(31)SB14                        |                |
|            |                                     |                |
| 12.2SB     | 12.2(33)SB3                         | 12.2(33)SB4    |
|            |                                     |                |
|            | 12.2(28)SB13                        |                |
|------------+-------------------------------------+----------------|
| 12.2SBC    | Vulnerable; first fixed in 12.2SB   | 12.2(33)SB4    |
|------------+-------------------------------------+----------------|
| 12.2SCA    | Vulnerable; first fixed in 12.2SCB  | 12.2(33)SCB1   |
|------------+-------------------------------------+----------------|
| 12.2SCB    | 12.2(33)SCB1                        | 12.2(33)SCB1   |
|------------+-------------------------------------+----------------|
|            | 12.2(46)SE2                         |                |
|            |                                     |                |
| 12.2SE     | 12.2(44)SE5                         | 12.2(44)SE6    |
|            |                                     |                |
|            | 12.2(50)SE                          |                |
|------------+-------------------------------------+----------------|
| 12.2SEA    | Vulnerable; first fixed in 12.2SE   | 12.2(44)SE6    |
|------------+-------------------------------------+----------------|
| 12.2SEB    | Vulnerable; first fixed in 12.2SE   | 12.2(44)SE6    |
|------------+-------------------------------------+----------------|
| 12.2SEC    | Vulnerable; first fixed in 12.2SE   | 12.2(44)SE6    |
|------------+-------------------------------------+----------------|
| 12.2SED    | Vulnerable; first fixed in 12.2SE   | 12.2(44)SE6    |
|------------+-------------------------------------+----------------|
| 12.2SEE    | Vulnerable; first fixed in 12.2SE   | 12.2(44)SE6    |
|------------+-------------------------------------+----------------|
| 12.2SEF    | Vulnerable; first fixed in 12.2SE   | 12.2(44)SE6    |
|------------+-------------------------------------+----------------|
| 12.2SEG    | Vulnerable; first fixed in 12.2SE   | 12.2(44)SE6    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.2(52)SG;    |
| 12.2SG     | 12.2(50)SG                          | Available on   |
|            |                                     | 15-MAY-2009    |
|------------+-------------------------------------+----------------|
| 12.2SGA    | 12.2(31)SGA9                        | 12.2(31)SGA9   |
|------------+-------------------------------------+----------------|
| 12.2SL     | Not Vulnerable                      |                |
|------------+-------------------------------------+----------------|
| 12.2SM     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2SO     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2SQ     | 12.2(44)SQ1                         |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.2(33)SRC4;  |
| 12.2SRA    | Vulnerable; first fixed in 12.2SRC  | Available on   |
|            |                                     | 18-MAY-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.2(33)SRC4;  |
|            |                                     | Available on   |
|            |                                     | 18-MAY-2009    |
| 12.2SRB    | Vulnerable; first fixed in 12.2SRC  |                |
|            |                                     | 12.2(33)SRB5a; |
|            |                                     | Available on   |
|            |                                     | 3-April-2009   |
|------------+-------------------------------------+----------------|
|            |                                     | 12.2(33)SRC4;  |
| 12.2SRC    | 12.2(33)SRC3                        | Available on   |
|            |                                     | 18-MAY-2009    |
|------------+-------------------------------------+----------------|
| 12.2SRD    | Not Vulnerable                      |                |
|------------+-------------------------------------+----------------|
| 12.2STE    | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.2SU     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.2SV     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2SVA    | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2SVC    | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2SVD    | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2SVE    | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2SW     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2SX     | Vulnerable; first fixed in 12.2SXF  | 12.2(18)SXF16  |
|------------+-------------------------------------+----------------|
| 12.2SXA    | Vulnerable; first fixed in 12.2SXF  | 12.2(18)SXF16  |
|------------+-------------------------------------+----------------|
| 12.2SXB    | Vulnerable; first fixed in 12.2SXF  | 12.2(18)SXF16  |
|------------+-------------------------------------+----------------|
| 12.2SXD    | Vulnerable; first fixed in 12.2SXF  | 12.2(18)SXF16  |
|------------+-------------------------------------+----------------|
| 12.2SXE    | Vulnerable; first fixed in 12.2SXF  | 12.2(18)SXF16  |
|------------+-------------------------------------+----------------|
| 12.2SXF    | 12.2(18)SXF16                       | 12.2(18)SXF16  |
|------------+-------------------------------------+----------------|
|            | 12.2(33)SXH5; Available on          | 12.2(33)SXH5;  |
| 12.2SXH    | 20-APR-2009                         | Available on   |
|            |                                     | 20-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.2SXI    | Not Vulnerable                      |                |
|------------+-------------------------------------+----------------|
| 12.2SY     | Vulnerable; first fixed in 12.2SB   | 12.2(33)SB4    |
|------------+-------------------------------------+----------------|
| 12.2SZ     | Vulnerable; first fixed in 12.2SB   | 12.2(33)SB4    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2T      | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.2TPC    | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XA     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XB     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XC     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XD     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XE     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            | Vulnerable; migrate to 12.2SCB or   | 12.2(33)SCB1   |
| 12.2XF     | 12.3BC                              |                |
|            |                                     | 12.3(23)BC6    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XG     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XH     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XI     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XJ     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XK     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XL     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XM     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.2(33)SB4    |
| 12.2XN     | Vulnerable; first fixed in 12.2SRC  |                |
|            |                                     | 12.2(33)SRD1   |
|------------+-------------------------------------+----------------|
| 12.2XNA    | Vulnerable; migrate to any release  | 12.2(33)SRD1   |
|            | in 12.2SRD                          |                |
|------------+-------------------------------------+----------------|
| 12.2XNB    | 12.2(33)XNB1                        | 12.2(33)XNB3   |
|------------+-------------------------------------+----------------|
| 12.2XNC    | Not Vulnerable                      |                |
|------------+-------------------------------------+----------------|
| 12.2XO     | 12.2(46)XO                          | 12.2(46)XO     |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XQ     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XR     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XS     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XT     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XU     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XV     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2XW     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2YA     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.2YB     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YC     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YD     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YE     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YF     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YG     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YH     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YJ     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YK     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YL     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.2YM     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.2YN     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YO     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2YP     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.2YQ     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YR     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YS     | Not Vulnerable                      |                |
|------------+-------------------------------------+----------------|
| 12.2YT     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YU     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YV     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YW     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YX     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YY     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2YZ     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2ZA     | Vulnerable; first fixed in 12.2SXF  | 12.2(18)SXF16  |
|------------+-------------------------------------+----------------|
| 12.2ZB     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2ZC     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2ZD     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2ZE     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.2ZF     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.2ZG     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.2ZH     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.2ZJ     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2ZL     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2ZP     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.2(33)SRC4;  |
| 12.2ZU     | Vulnerable; first fixed in 12.2SXH  | Available on   |
|            |                                     | 18-MAY-2009    |
|------------+-------------------------------------+----------------|
| 12.2ZX     | Vulnerable; first fixed in 12.2SB   | 12.2(33)SB4    |
|------------+-------------------------------------+----------------|
| 12.2ZY     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.2ZYA    | 12.2(18)ZYA1                        | 12.2(18)ZYA1   |
|------------+-------------------------------------+----------------|
| Affected   |                                     | Recommended    |
| 12.3-Based | First Fixed Release                 | Release        |
| Releases   |                                     |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.3       | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3B      | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.3BC     | 12.3(23)BC6                         | 12.3(23)BC6    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3BW     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.3EU     | Not Vulnerable                      |                |
|------------+-------------------------------------+----------------|
| 12.3JA     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.3JEA    | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.3JEB    | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.3JEC    | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3JK     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.3JL     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.3JX     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3T      | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.3TPC    | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.3VA     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.3XA     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.3XB     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3XC     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3XD     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.3XE     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.3XF     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3XG     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.3XI     | Vulnerable; first fixed in 12.2SB   | 12.2(33)SB4    |
|------------+-------------------------------------+----------------|
| 12.3XJ     | Vulnerable; first fixed in 12.3YX   | 12.3(14)YX14   |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3XK     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3XL     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3XQ     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(18e)      |
|            |                                     |                |
| 12.3XR     | Vulnerable; first fixed in 12.4     | 12.4(23a);     |
|            |                                     | Available on   |
|            |                                     | 30-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3XS     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3XU     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.3XW     | Vulnerable; first fixed in 12.3YX   | 12.3(14)YX14   |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3XX     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3XY     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3XZ     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3YA     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3YD     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.3YF     | Vulnerable; first fixed in 12.3YX   | 12.3(14)YX14   |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3YG     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3YH     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3YI     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3YJ     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3YK     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.3YM     | 12.3(14)YM13                        | 12.3(14)YM13   |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3YQ     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3YS     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3YT     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.3YU     | Vulnerable; first fixed in 12.4XB   | 12.4(22)T1     |
|------------+-------------------------------------+----------------|
| 12.3YX     | 12.3(14)YX14                        | 12.3(14)YX14   |
|------------+-------------------------------------+----------------|
| 12.3YZ     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.3ZA     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
| Affected   |                                     | Recommended    |
| 12.4-Based | First Fixed Release                 | Release        |
| Releases   |                                     |                |
|------------+-------------------------------------+----------------|
|            | 12.4(23)                            | 12.4(18e)      |
|            |                                     |                |
| 12.4       | 12.4(18e)                           | 12.4(23a);     |
|            |                                     | Available on   |
|            | 12.4(23a); Available on 30-APR-2009 | 30-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.4JA     | 12.4(16b)JA1                        |                |
|------------+-------------------------------------+----------------|
| 12.4JDA    | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.4JK     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.4JL     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.4JMA    | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.4JMB    | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.4JX     | Vulnerable; first fixed in 12.4JA   |                |
|------------+-------------------------------------+----------------|
| 12.4MD     | 12.4(11)MD7                         | 12.4(11)MD7    |
|------------+-------------------------------------+----------------|
| 12.4MR     | 12.4(19)MR1                         | 12.4(19)MR2    |
|------------+-------------------------------------+----------------|
| 12.4SW     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
|            | 12.4(15)T8                          |                |
|            |                                     | 12.4(22)T1     |
|            | 12.4(20)T2                          |                |
| 12.4T      |                                     | 12.4(15)T9;    |
|            | 12.4(22)T                           | Available on   |
|            |                                     | 29-APR-2009    |
|            | 12.4(15)T9; Available on            |                |
|            | 29-APR-2009                         |                |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.4XA     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            | 12.4(15)T8                          |                |
| 12.4XB     |                                     | 12.4(15)T9;    |
|            | 12.4(20)T2                          | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.4XC     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            | 12.4(4)XD12; Available on           | 12.4(4)XD12;   |
| 12.4XD     | 27-MAR-2009                         | Available on   |
|            |                                     | 27-MAR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.4XE     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.4XF     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            | 12.4(15)T8                          | 12.4(22)T1     |
|            |                                     |                |
| 12.4XG     | 12.4(20)T2                          | 12.4(15)T9;    |
|            |                                     | Available on   |
|            | 12.4(22)T1                          | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.4XJ     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.4XK     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.4XL     | 12.4(15)XL4                         | 12.4(15)XL4    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.4XM     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.4XN     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.4XP     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.4XQ     | 12.4(15)XQ2                         | 12.4(15)XQ2    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.4XR     | 12.4(15)XR4                         | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.4XT     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.4XV     | Vulnerable; contact TAC             |                |
|------------+-------------------------------------+----------------|
| 12.4XW     | 12.4(11)XW10                        | 12.4(11)XW10   |
|------------+-------------------------------------+----------------|
|            |                                     | 12.4(22)T1     |
|            |                                     |                |
| 12.4XY     | Vulnerable; first fixed in 12.4T    | 12.4(15)T9;    |
|            |                                     | Available on   |
|            |                                     | 29-APR-2009    |
|------------+-------------------------------------+----------------|
| 12.4XZ     | 12.4(15)XZ2                         | 12.4(15)XZ2    |
|------------+-------------------------------------+----------------|
| 12.4YA     | 12.4(20)YA2                         | 12.4(20)YA3    |
|------------+-------------------------------------+----------------|
| 12.4YB     | Not Vulnerable                      |                |
|------------+-------------------------------------+----------------|
| 12.4YD     | Not Vulnerable                      |                |
+-------------------------------------------------------------------+

Workarounds
===========

The following mitigations have been identified for this
vulnerability; only packets destined for any configured IP address on
the device can exploit this vulnerability. Transit traffic will not
exploit this vulnerability.

Disable Affected Listening Ports
+-------------------------------

If an affected feature is not required it can be explicitly disabled.
Once disabled confirm the listening UDP port has been closed by
entering the CLI command "show udp" or "show ip socket". Some
features may require a reload of the device after disabling the
feature in order to close the listening UDP port.

For SIP it is possible to disable UDP listening if only TCP services
are required. The following example shows how to disable SIP from
listening on its associated UDP port.

Warning: When applying this workaround to devices that are processing
MGCP or H.323 calls, the device will not allow the stopping SIP
processing while active calls are being processed. When possible,
this workaround should be implemented during a maintenance window
when active calls can be briefly stopped.

    Enter configuration commands, one per line.  End with CNTL/Z.
    Router(config)#sip-ua
    Router(config-sip-ua)#no transport udp
    Router(config-sip-ua)#end

For SIP it is possible to bind the process to a privately-addressed
interface, with the command below. This will cause SIP to only listen
on the internal interface, which may assist in limiting the exposure
of this vulnerability:

    voice service voip
     sip
      bind control source-interface <int>
      bind media source-interface <int>

Infrastructure Access Control Lists
+----------------------------------

Warning: Because the features in this vulnerability utilize UDP as a
transport, it is possible to spoof the sender's IP address, which may
defeat ACLs that permit communication to these ports from trusted IP
addresses. Unicast RPF should be considered to be used in conjunction
to offer a better mitigation solution.

Although it is often difficult to block traffic that transits a
network, it is possible to identify traffic that should never be
allowed to target infrastructure devices and block that traffic at
the border of networks. Infrastructure Access Control Lists (iACLs)
are a network security best practice and should be considered as a
long-term addition to good network security as well as a workaround
for this specific vulnerability. The iACL example below should be
included as part of the deployed infrastructure access-list which
will protect all devices with IP addresses in the infrastructure IP
address range:


    !--- Only sections pertaining to features enabled on the device
    !--- need be configured.
    !---
    !---
    !--- Feature: IP SLAs UDP Responder
    !---

    access-list 150 permit udp TRUSTED_SOURCE_ADDRESSES WILDCARD
        INFRASTRUCTURE_ADDRESSES WILDCARD eq 1967

    !--- Deny IP SLAs UDP Responder traffic from all other sources 
    !--- destined to infrastructure addresses.

    access-list 150 deny udp any
         INFRASTRUCTURE_ADDRESSES WILDCARD eq 1967

    !---
    !--- Feature: Session Initiation Protocol (SIP)
    !---

    access-list 150 permit udp TRUSTED_SOURCE_ADDRESSES WILDCARD
         INFRASTRUCTURE_ADDRESSES WILDCARD eq 5060

    !--- Deny SIP traffic from all other sources destined
    !--- to infrastructure addresses.

    access-list 150 deny udp any
         INFRASTRUCTURE_ADDRESSES WILDCARD eq 5060

    !---
    !--- Feature: H.323 Call Signaling
    !---

    access-list 150 permit udp TRUSTED_SOURCE_ADDRESSES WILDCARD
         INFRASTRUCTURE_ADDRESSES WILDCARD eq 2517

    !--- Deny H.323 Call Signaling traffic from all other sources
    !--- destined to infrastructure addresses.

    access-list 150 deny udp any
         INFRASTRUCTURE_ADDRESSES WILDCARD eq 2517

    !---
    !--- Feature: Media Gateway Control Protocol (MGCP)
    !---

    access-list 150 permit udp TRUSTED_SOURCE_ADDRESSES WILDCARD
        INFRASTRUCTURE_ADDRESSES WILDCARD eq 2427

    !--- Deny MGCP traffic from all other sources destined
    !--- to infrastructure addresses.

    access-list 150 deny udp any
         INFRASTRUCTURE_ADDRESSES WILDCARD eq 2427

    !--- Permit/deny all other Layer 3 and Layer 4 traffic in 
    !--- accordance with existing security policies and 
    !--- configurations.  Permit all other traffic to transit the
    !--- device.

    access-list 150 permit ip any any

    !--- Apply access-list to all interfaces (only one example
    !--- shown)

    interface serial 2/0
     ip access-group 150 in

The white paper entitled "Protecting Your Core: Infrastructure
Protection Access Control Lists" presents guidelines and recommended
deployment techniques for infrastructure protection access lists and
is available at the following link 
http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801a1a55.shtml

Control Plane Policing
+---------------------

Warning: Because the features in this vulnerability utilizes UDP as a
transport, it is possible to spoof the sender's IP address, which may
defeat ACLs that permit communication to these ports from trusted IP
addresses. Unicast RPF should be considered to be used in conjunction
to offer better mitigation solution.

Control Plane Policing (CoPP) can be used to block untrusted UDP
traffic to the device. Cisco IOS software releases 12.0S, 12.2SX,
12.2S, 12.3T, 12.4, and 12.4T support the CoPP feature. CoPP can be
configured on a device to protect the management and control planes
and minimize the risk and effectiveness of direct infrastructure
attacks by explicitly permitting only authorized traffic that is sent
to infrastructure devices in accordance with existing security
policies and configurations. The CoPP example below should be
included as part of the deployed CoPP which will protect all devices
with IP addresses in the infrastructure IP address range.


    !---
    !--- Only sections pertaining to features enabled on the device
    !--- need be configured.
    !---

    !---
    !--- Feature: IP SLAs UDP Responder
    !---

    access-list 150 deny udp TRUSTED_SOURCE_ADDRESSES WILDCARD
         any eq 1967

    !---
    !--- Deny IP SLAs UDP Responder traffic from all other sources 
    !--- destined to the device control plane.
    !---

    access-list 150 permit udp any any eq 1967

    !---
    !--- Feature: Session Initiation Protocol (SIP)
    !---

    access-list 150 deny udp TRUSTED_SOURCE_ADDRESSES WILDCARD
        any eq 5060

    !---
    !--- Deny SIP traffic from all other sources destined
    !--- to the device control plane.
    !---

    access-list 150 permit udp any any eq 5060

    !---
    !--- Feature: H.323 Call Signaling
    !---

    access-list 150 deny udp TRUSTED_SOURCE_ADDRESSES WILDCARD
        any eq 2517

    !---
    !--- Deny H.323 call signaling traffic from all other sources 
    !--- destined to the device control plane.
    !---

    access-list 150 permit udp any any eq 2517

    !---
    !--- Feature: Media Gateway Control Protocol (MGCP)
    !---

    access-list 150 deny udp TRUSTED_SOURCE_ADDRESSES WILDCARD
         any eq 2427

    !---
    !--- Deny MGCP traffic from all other sources destined
    !--- to the device control plane.
    !---

    access-list 150 permit udp any any eq 2427

    !---
    !--- Permit (Police or Drop)/Deny (Allow) all other Layer3 and 
    !--- Layer4 traffic in accordance with existing security policies
    !--- and configurations for traffic that is authorized to be sent
    !--- to infrastructure devices
    !--- Create a Class-Map for traffic to be policed by
    !--- the CoPP feature
    !---

    class-map match-all drop-udp-class
     match access-group 150

    !---
    !--- Create a Policy-Map that will be applied to the
    !--- Control-Plane of the device.
    !---

    policy-map drop-udp-traffic
     class drop-udp-class
      drop

    !---
    !--- Apply the Policy-Map to the 
    !--- Control-Plane of the device
    !---

    control-plane
     service-policy input drop-udp-traffic

In the above CoPP example, the access control list entries (ACEs)
that match the potential exploit packets with the "permit" action
result in these packets being discarded by the policy-map "drop"
function, while packets that match the "deny" action (not shown) are
not affected by the policy-map drop function. Please note that the
policy-map syntax is different in the 12.2S and 12.0S Cisco IOS
trains:

    policy-map drop-udp-traffic
    class drop-udp-class
    police 32000 1500 1500 conform-action drop exceed-action drop

Additional information on the configuration and use of the CoPP
feature can be found in the documents, "Control Plane Policing
Implementation Best Practices" and "Cisco IOS Software Releases 
12.2S - Control Plane Policing" at the following links: 
http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html
and
http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gtrtlimt.html

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 at the following link: 
http://www.cisco.com/warp/public/707/cisco-amb-20090325-sip-and-udp.shtml

Exploit Detection
+----------------

It is possible to detect blocked interface queues with an Cisco IOS
Embedded Event Manager (EEM) policy. EEM provides event detection and
reaction capabilities on a Cisco IOS device. EEM can alert
administrators of blocked interfaces with email, a syslog message, or
a Simple Network Management Protocol (SNMP) trap.

A sample EEM policy that uses syslog to alert administrators of
blocked interfaces is available at Cisco Beyond, an online community
dedicated to EEM. A sample script is available at the following link:
http://forums.cisco.com/eforum/servlet/EEM?page=eem&fn=script&scriptId=981

Further information about EEM is available from Cisco.com at the
following link: 
http://www.cisco.com/en/US/products/ps6815/products_ios_protocol_group_home.htm

Obtaining Fixed Software
========================

Cisco has released free software updates that address this
vulnerability. Prior to deploying software, customers should consult
their maintenance provider or check the software for feature set
compatibility and known issues specific to their environment.

Customers may only install and expect support for the feature sets
they have purchased. By installing, downloading, accessing or
otherwise using such software upgrades, customers agree to be bound
by the terms of Cisco's software license terms found at 
http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html,
or as otherwise set forth at Cisco.com Downloads at 
http://www.cisco.com/public/sw-center/sw-usingswc.shtml

Do not contact psirt at cisco.com or security-alert at cisco.com for
software upgrades.

Customers with Service Contracts
+-------------------------------

Customers with contracts should obtain upgraded software through
their regular update channels. For most customers, this means that
upgrades should be obtained through the Software Center on Cisco's
worldwide website at http://www.cisco.com.

Customers using Third Party Support Organizations
+------------------------------------------------

Customers whose Cisco products are provided or maintained through
prior or existing agreements with third-party support organizations,
such as Cisco Partners, authorized resellers, or service providers
should contact that support organization for guidance and assistance
with the appropriate course of action in regards to this advisory.

The effectiveness of any workaround or fix is dependent on specific
customer situations, such as product mix, network topology, traffic
behavior, and organizational mission. Due to the variety of affected
products and releases, customers should consult with their service
provider or support organization to ensure any applied workaround or
fix is the most appropriate for use in the intended network before it
is deployed.

Customers without Service Contracts
+----------------------------------

Customers who purchase direct from Cisco but do not hold a Cisco
service contract, and customers who purchase through third-party
vendors but are unsuccessful in obtaining fixed software through
their point of sale should acquire upgrades by contacting the Cisco
Technical Assistance Center (TAC). TAC contacts are as follows.

  * +1 800 553 2447 (toll free from within North America)
  * +1 408 526 7209 (toll call from anywhere in the world)
  * e-mail: tac at cisco.com

Customers should have their product serial number available and be
prepared to give the URL of this notice as evidence of entitlement to
a free upgrade. Free upgrades for non-contract customers must be
requested through the TAC.

Refer to http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html
for additional TAC contact information, including localized telephone 
numbers, and instructions and e-mail addresses for use in various 
languages.

Exploitation and Public Announcements
=====================================

The Cisco PSIRT is not aware of any public announcements or malicious
use of the vulnerability described in this advisory.

This vulnerability was discovered by Cisco during routine internal
testing.

Status of this Notice: FINAL
============================

THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY
KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE
INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS
AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS
DOCUMENT AT ANY TIME.

A stand-alone copy or Paraphrase of the text of this document that
omits the distribution URL in the following section is an
uncontrolled copy, and may lack important information or contain
factual errors.

Distribution
============

This advisory is posted on Cisco's worldwide website at :

http://www.cisco.com/warp/public/707/cisco-sa-20090325-udp.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-March-25 | 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-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAknKUdAACgkQ86n/Gc8U/uB5UACfTuBFTIs6/V/FKPdLnLYCvGXF
CyIAn3XqDhmEqM24yznj0IHjMPpGQ7Y2
=mpQF
-----END PGP SIGNATURE-----

From charles at thewybles.com  Wed Mar 25 13:28:23 2009
From: charles at thewybles.com (Charles Wyble)
Date: Wed, 25 Mar 2009 10:28:23 -0700
Subject: [c-nsp] QoS on Tunnel Interfaces w/ DSL
In-Reply-To: <BCD3E762F1767C42A5226BBACDE49BFBCE7ACD@loki.acs.local>
References: <BCD3E762F1767C42A5226BBACDE49BFBCE7ACD@loki.acs.local>
Message-ID: <49CA69B7.8060503@thewybles.com>

DSL on both ends? Cisco on both ends? What gear/ios version?

I'm curious to this as well. I have an 1841 ISR I'm using as my 
production home router, and want to deploy an IPSEC endpoint at another 
location, and optimize as much as possible.



Jeff Cartier wrote:
> Greetings All,
> 
>  
> 
> I was wondering if anyone had any examples of how to impose QoS on a
> Site that would be doing IPSec VPN tunnels to another site via a
> standard DSL feed.
> 
>  
> 
> I'm curious to see if best-practice is to place the policy-shaping on
> the interface tunnel and/or the Internet interface.
> 
>  
> 
> Thanks!
> 
>  
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 

From hritter at cisco.com  Wed Mar 25 14:17:02 2009
From: hritter at cisco.com (Harold Ritter (hritter))
Date: Wed, 25 Mar 2009 14:17:02 -0400
Subject: [c-nsp] match and remove no-export
In-Reply-To: <9e246b4d0903251006j2e208304oc7cf7bfa71c24533@mail.gmail.com>
References: <9e246b4d0903251006j2e208304oc7cf7bfa71c24533@mail.gmail.com>
Message-ID: <F4469404D9886545AD22355D96D8620F07369981@xmb-rtp-20a.amer.cisco.com>

Tim,

You should definitely be able to remove the no-export well know
community using an inbound route-map but you will not be able to do it
outbound on an eBGP session as the path will not even be considered for
advertisement in the latter case.

Regards 

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Tim Durack
Sent: Wednesday, March 25, 2009 1:07 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] match and remove no-export

This is probably a stupid question, but anyway:

Can I match and remove no-export from routes? I need to shuffle some
routes between global and a vrf. I have a "fake" eBGP session up, but
the routes I need to move are marked no-export.

I've tried applying a simple match/set route-map to the eBGP session,
without success. I'm going to assume no-export gets taken into account
before the routes even hit the route-map.

Any ideas?

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

From tdurack at gmail.com  Wed Mar 25 14:29:38 2009
From: tdurack at gmail.com (Tim Durack)
Date: Wed, 25 Mar 2009 14:29:38 -0400
Subject: [c-nsp] match and remove no-export
In-Reply-To: <F4469404D9886545AD22355D96D8620F07369981@xmb-rtp-20a.amer.cisco.com>
References: <9e246b4d0903251006j2e208304oc7cf7bfa71c24533@mail.gmail.com>
	<F4469404D9886545AD22355D96D8620F07369981@xmb-rtp-20a.amer.cisco.com>
Message-ID: <9e246b4d0903251129p7496b871u21518727b50e2cdb@mail.gmail.com>

On Wed, Mar 25, 2009 at 2:17 PM, Harold Ritter (hritter)
<hritter at cisco.com> wrote:
> Tim,
>
> You should definitely be able to remove the no-export well know
> community using an inbound route-map but you will not be able to do it
> outbound on an eBGP session as the path will not even be considered for
> advertisement in the latter case.
>
> Regards

That was my guess. Thanks for confirming.

Tim:>

From billw at waveform.net  Wed Mar 25 15:03:34 2009
From: billw at waveform.net (Bill Wichers)
Date: Wed, 25 Mar 2009 15:03:34 -0400
Subject: [c-nsp] Strange OC3 issue between GSR and old POSIP card in 7507
Message-ID: <EE3A1AFB71A1E54BA3D302718EA382F95050@server1.WaveformTechnology.local>

I'm seeing a strange problem with an OC3 link that should be really
simple. The link runs from a 4-port OC3 card in a 12012 to an old
POSIP-OC3-50 in a 7507. Earlier in the day one of the two POSIP cards in
the 7507 started running a *lot* of receive errors, all CRC, so we
thought maybe the optic died. We traded the link to a second POSIP card
in the same 7507 (GSR port was the same in both cases). The link came
right up, started running around 60-70Mb/s and was clean.

 

We then noticed the dCEF wasn't running so tried starting that. That
caused a bunch of line card reloads. We tried doing a complete reload of
the entire chassis, which took down dCEF but .... Brought back the same
weird problem on the second OC3 linecard! 

 

Normally I'd think the RX level on the POSIP was too high and burned out
the received, but we're down around -14dB or so (it's a singlemode link,
IR optics). I can't figure out why the link would have worked before the
reload but not after either since the optics weren't touched. 

 

Does anyone have any ideas? I've already checked light levels, CRC (set
the same on both ends - CRC16), clocking is line on one end, internal on
the other, all the other settings are identical on both ends. What is
happening right now is that the line shows "up" on both ends, but line
protocol is going up/down on about 20 second cyles:

 

Mar 25 14:00:01: %LINEPROTO-5-UPDOWN: Line protocol on Interface
POS6/0/0, changed state to down

Mar 25 14:00:11: %LINEPROTO-5-UPDOWN: Line protocol on Interface
POS6/0/0, changed state to up

Mar 25 14:00:31: %LINEPROTO-5-UPDOWN: Line protocol on Interface
POS6/0/0, changed state to down

Mar 25 14:00:41: %LINEPROTO-5-UPDOWN: Line protocol on Interface
POS6/0/0, changed state to up

Mar 25 14:01:01: %LINEPROTO-5-UPDOWN: Line protocol on Interface
POS6/0/0, changed state to down

Mar 25 14:01:11: %LINEPROTO-5-UPDOWN: Line protocol on Interface
POS6/0/0, changed state to up

 

I've tried doing a 'shut / no shut' on both ends to reset the interface
but that doesn't change anything. I've pretty much run out of ideas at
this point... Any help is appreciated.

 

   -Bill

 

We show the following on the links (IPs changed to private net):

 

7507:

POS6/0/0 is up, line protocol is up

  Hardware is cyBus Packet over Sonet

  Description: OC-3 to GSR-Core-Right

  Internet address is 172.16.1.1/30

  MTU 4470 bytes, BW 155000 Kbit, DLY 100 usec,

     reliability 255/255, txload 1/255, rxload 1/255

  Encapsulation HDLC, loopback not set

  Keepalive set (10 sec)

  Scramble disabled

  Last input 00:00:00, output 00:00:00, output hang never

  Last clearing of "show interface" counters 00:18:34

  Queueing strategy: fifo

  Output queue 0/40, 0 drops; input queue 0/75, 0 drops

  30 second input rate 0 bits/sec, 0 packets/sec

  30 second output rate 1000 bits/sec, 1 packets/sec

     180 packets input, 9873 bytes, 0 no buffer

     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles

              0 parity

     3 input errors, 3 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

     722 packets output, 85050 bytes, 0 underruns

     0 output errors, 0 applique, 71 interface resets

     0 output buffer failures, 0 output buffers swapped out

     1 carrier transitions

 

12012:

POS3/3 is up, line protocol is down

  Hardware is Packet over SONET

  Internet address is 172.16.1.2/30

  MTU 4470 bytes, BW 155000 Kbit, DLY 100 usec, rely 255/255, load 1/255

  Encapsulation HDLC, crc 16, loopback not set

  Keepalive set (10 sec)

  Scramble disabled

  Last input 02:04:33, output 00:00:03, output hang never

  Last clearing of "show interface" counters 00:42:02

  Queueing strategy: fifo

  Output queue 0/40, 0 drops; input queue 0/75, 0 drops

  30 second input rate 0 bits/sec, 0 packets/sec

  30 second output rate 0 bits/sec, 0 packets/sec

     0 packets input, 0 bytes, 0 no buffer

     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles

              0 parity

     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

     203 packets output, 11126 bytes, 0 underruns

     0 output errors, 0 applique, 8 interface resets

     0 output buffer failures, 0 output buffers swapped out

     4 carrier transitions

 

    -Bill


From bdikici at gmail.com  Wed Mar 25 15:27:52 2009
From: bdikici at gmail.com (Burak Dikici)
Date: Wed, 25 Mar 2009 21:27:52 +0200
Subject: [c-nsp] Configuring Cisco IPS High Bandwidth Using EtherChannel
	Load Balancing
Message-ID: <d9281f5c0903251227r66311782q693f0a81a31a32b5@mail.gmail.com>

  Hello ,

 I have got two core switches. They are running redundant with HSRP. One of
them is hsrp active and spanning tree root for all vlans , the other is hsrp
passive and spanning tree secondary for all vlans. I have got a server vlan
which i would like to inspect traffic to this vlan from all other user
vlans. All servers are connected to the backbone switches via another
aggregation switches. We have got 6 aggragation swtiches and all of them are
connected to the backbone switches via 1 gigabit f/o uplinks. Because of
that , i need 6 gbps throghput for the IPS system which will protect the
server VLAN.
 Which topology do you recommend for this purpose ? Should i use another
switches to connect all IPS devices to the backbone switches ? Or should i
connect IPS devices directly to the backbone switches ? Which one is more
preferrable for performance and redundancy ?

Another question is ;
I saw the message which is written below in this address ;
http://cisco.com/en/US/products/hw/vpndevc/ps4077/products_configuration_example09186a0080671a8d.shtml
?The IPS appliances must be in on-a-stick mode, meaning that the IPS
appliance can only use one sensing port on that Catalyst switch. That port
is trunked so that the IPS appliance has an inbound and outbound path to and
from the switch.?
My question is ;
Can I have one IPS with three or four ports attached to the same switch in
an etherchannel?

Kind Regards...

Burak Dikici

From lowen at pari.edu  Wed Mar 25 15:42:27 2009
From: lowen at pari.edu (Lamar Owen)
Date: Wed, 25 Mar 2009 15:42:27 -0400
Subject: [c-nsp] Strange OC3 issue between GSR and old POSIP card in 7507
In-Reply-To: <EE3A1AFB71A1E54BA3D302718EA382F95050@server1.WaveformTechnology.local>
References: <EE3A1AFB71A1E54BA3D302718EA382F95050@server1.WaveformTechnology.local>
Message-ID: <200903251542.27475.lowen@pari.edu>

On Wednesday 25 March 2009 15:03:34 Bill Wichers wrote:
> Does anyone have any ideas? I've already checked light levels, CRC (set
> the same on both ends - CRC16), clocking is line on one end, internal on
> the other, all the other settings are identical on both ends. What is
> happening right now is that the line shows "up" on both ends, but line
> protocol is going up/down on about 20 second cyles:

One quick question: is this your own dark fiber, or through a SONET ADM, or 
through a service provider?  Interestingly enough, the recommendation for dark 
fiber is internal clocking on both ends.

Also note that the quad OC3 line cards in the 12000 have some limitations as 
to clocking individual ports.

Also, what IOS versions are you running?
-- 
Lamar Owen
Chief Information Officer
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
http://www.pari.edu

From billw at waveform.net  Wed Mar 25 16:19:56 2009
From: billw at waveform.net (Bill Wichers)
Date: Wed, 25 Mar 2009 16:19:56 -0400
Subject: [c-nsp] Strange OC3 issue between GSR and old POSIP card in 7507
In-Reply-To: <200903251542.27475.lowen@pari.edu>
References: <EE3A1AFB71A1E54BA3D302718EA382F95050@server1.WaveformTechnology.local>
	<200903251542.27475.lowen@pari.edu>
Message-ID: <EE3A1AFB71A1E54BA3D302718EA382F95055@server1.WaveformTechnology.local>


> One quick question: is this your own dark fiber, or through a SONET
ADM,
> or
> through a service provider?  Interestingly enough, the recommendation
for
> dark
> fiber is internal clocking on both ends.
> 
> Also note that the quad OC3 line cards in the 12000 have some
limitations
> as
> to clocking individual ports.

It's a jumper, maybe 10m long. The routers are in adjacent bays. That's
one of the things that was making me crazy -- there is no carrier in the
link at all. I'll try internal clocking on both ends. Seems strange that
way but it's worth a shot.

> Also, what IOS versions are you running?

12.0(32)S7 on the GSR, 12.2(6a) on the 7507.

  -Bill



From cordmacleod at gmail.com  Wed Mar 25 16:31:04 2009
From: cordmacleod at gmail.com (Cord MacLeod)
Date: Wed, 25 Mar 2009 13:31:04 -0700
Subject: [c-nsp] 3550 pps limitations
Message-ID: <E08B4ABD-13D4-4F40-9BEA-6E5AD66750D0@gmail.com>

Does any one know the packets per second limitations on a 3550's gig  
interface?  I'm seeing some weirdness when I do a show controllers  
utilization.  Several interfaces register 100 on either transmit or  
receive.  This doesn't seem to be the case when I show int g0/? to see  
what the pps and bandwidth utilization is.  The highest I am usually  
seeing is around 485mbit at 75000 packets per second on a given  
interface.

From jason at pins.net  Wed Mar 25 16:35:50 2009
From: jason at pins.net (Jason Berenson)
Date: Wed, 25 Mar 2009 16:35:50 -0400
Subject: [c-nsp] MLPPP
Message-ID: <49CA95A6.3030107@pins.net>

Greetings,

I've got a 7206VXR NPE-G1 with a bunch of DS3 cards in it (PA-MC-T3).  
There's about 25 multilinks with an average of 2 T1s per bundle.  I see 
a lot of process switching on the router and I have a feeling it's 
because we don't have the PA-MC-T3-EC card so the processor has to step 
in for the MLPPP. 

Is this the case?  If I get some PA-MC-T3-EC cards to swap in, will that 
take a lot of load off the NPE-G1?  Any output needed, please let me know.

Thanks,
Jason

From rodunn at cisco.com  Wed Mar 25 16:59:18 2009
From: rodunn at cisco.com (Rodney Dunn)
Date: Wed, 25 Mar 2009 16:59:18 -0400
Subject: [c-nsp] MLPPP
In-Reply-To: <49CA95A6.3030107@pins.net>
References: <49CA95A6.3030107@pins.net>
Message-ID: <20090325205918.GG26674@rtp-cse-489.cisco.com>

The G1's with MLPPP should not be process switching the traffic.

What is the config?

The EC cards just offload the MLPPP to the new asic on the PA.

Rodney

On Wed, Mar 25, 2009 at 04:35:50PM -0400, Jason Berenson wrote:
> Greetings,
> 
> I've got a 7206VXR NPE-G1 with a bunch of DS3 cards in it (PA-MC-T3).  
> There's about 25 multilinks with an average of 2 T1s per bundle.  I see 
> a lot of process switching on the router and I have a feeling it's 
> because we don't have the PA-MC-T3-EC card so the processor has to step 
> in for the MLPPP. 
> 
> Is this the case?  If I get some PA-MC-T3-EC cards to swap in, will that 
> take a lot of load off the NPE-G1?  Any output needed, please let me know.
> 
> Thanks,
> Jason
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

From jason at pins.net  Wed Mar 25 17:03:03 2009
From: jason at pins.net (Jason Berenson)
Date: Wed, 25 Mar 2009 17:03:03 -0400
Subject: [c-nsp] MLPPP
In-Reply-To: <20090325205918.GG26674@rtp-cse-489.cisco.com>
References: <49CA95A6.3030107@pins.net>
	<20090325205918.GG26674@rtp-cse-489.cisco.com>
Message-ID: <49CA9C07.7030007@pins.net>

Here's a sample:

interface Multilink2
 ip vrf forwarding VPN1
 ip address x.x.x.x 255.255.255.252
 no cdp enable
 ppp multilink
 ppp multilink group 2
 service-policy output voice
!
interface Serial6/0/25:0
 no ip address
 encapsulation ppp
 down-when-looped
 no cdp enable
 ppp multilink
 ppp multilink group 2
!
interface Serial6/0/26:0
 no ip address
 encapsulation ppp
 down-when-looped
 no cdp enable
 ppp multilink
 ppp multilink group 2
!

-Jason


Rodney Dunn wrote:
> The G1's with MLPPP should not be process switching the traffic.
>
> What is the config?
>
> The EC cards just offload the MLPPP to the new asic on the PA.
>
> Rodney
>
> On Wed, Mar 25, 2009 at 04:35:50PM -0400, Jason Berenson wrote:
>   
>> Greetings,
>>
>> I've got a 7206VXR NPE-G1 with a bunch of DS3 cards in it (PA-MC-T3).  
>> There's about 25 multilinks with an average of 2 T1s per bundle.  I see 
>> a lot of process switching on the router and I have a feeling it's 
>> because we don't have the PA-MC-T3-EC card so the processor has to step 
>> in for the MLPPP. 
>>
>> Is this the case?  If I get some PA-MC-T3-EC cards to swap in, will that 
>> take a lot of load off the NPE-G1?  Any output needed, please let me know.
>>
>> Thanks,
>> Jason
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>     

From ulici at teleson.ro  Wed Mar 25 17:47:58 2009
From: ulici at teleson.ro (Ulici Alexandru)
Date: Wed, 25 Mar 2009 23:47:58 +0200 (EET)
Subject: [c-nsp] 3550 pps limitations
In-Reply-To: <E08B4ABD-13D4-4F40-9BEA-6E5AD66750D0@gmail.com>
References: <E08B4ABD-13D4-4F40-9BEA-6E5AD66750D0@gmail.com>
Message-ID: <8d5a1eb461f540e75394b12820d3f3e2.squirrel@mail.teleson.ro>

Hi,
 We have a 3550-12T switch.The highest load on one GE port (till now):
 820 mbps down/700 mbps up
 110k pps unicast+ 15k pps multicast

Alexandru Ulici
> Does any one know the packets per second limitations on a 3550's gig
> interface?  I'm seeing some weirdness when I do a show controllers
> utilization.  Several interfaces register 100 on either transmit or
> receive.  This doesn't seem to be the case when I show int g0/? to see
> what the pps and bandwidth utilization is.  The highest I am usually
> seeing is around 485mbit at 75000 packets per second on a given
> interface.
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>



From illcritikz at gmail.com  Wed Mar 25 19:56:01 2009
From: illcritikz at gmail.com (Ben Steele)
Date: Thu, 26 Mar 2009 10:26:01 +1030
Subject: [c-nsp] Multichassis Multilink PPP
In-Reply-To: <d35a6baf0903250651y1acf5a28we4c57b6026be6da2@mail.gmail.com>
References: <d35a6baf0903250651y1acf5a28we4c57b6026be6da2@mail.gmail.com>
Message-ID: <4422cf660903251656i56cf0744y30b11eefcf3088d7@mail.gmail.com>

Do you control both ends of the link(s)? any reason you can't just run L3
without PPP on the links with a routing protocol for redundancy and use
cef's load sharing abilities?

I'd avoid the overhead and processing requirements of MMP if you can.


On Thu, Mar 26, 2009 at 12:21 AM, James Edmondson <biged7600 at gmail.com>wrote:

> Question for the pros.
>
> Need advise on having multiple (2 right now and separate carriers, 6 in the
> future) T1's spread across two 7606 routers acting as one logical pipe.
>
> 7606----
>    |         ------- (WAN) ----   Router
> 7606----
> Looking for redundancy of T1 circuits across two physical routers, Is MCMMP
> the answer, GLBP, or HSRP with multilink?
>
> Your suggestions are welcome.  Thank you in advance.
> --
> James
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From andy.saykao at staff.netspace.net.au  Wed Mar 25 20:04:23 2009
From: andy.saykao at staff.netspace.net.au (Andy Saykao)
Date: Thu, 26 Mar 2009 11:04:23 +1100
Subject: [c-nsp] Question about CBWFQ and PING times
Message-ID: <56F211C5E3F24F47B103EA1B253822BE03654CB1@vic-cr-ex1.staff.netspace.net.au>

Hi Peter,

Much appreciate your help with understanding QoS a little better.

---

I tried to create a Heirarchical QoS policy on a spare 7606 we have here
and no go. Tried to create a parent shaper and policer and neither
worked when the service-policy was applied to the interface.

With parent shaper:

POP2(config-if)#service-policy output POP2-POP2-PRI-PARENT-POLICY
shape average command is not supported for this interface
Configuration failed!

With parent policer:

POP2(config-if)#service-policy output MEL-TAS-PRI-PARENT-POLICY
Hierarchical policymap is not supported for this interface.
Configuration failed!

---

You wrote - "You need to tell the router that it only has 200 mbps and
not the full 1 Gbps. Otherwise it will allocate ~50 mbps (your
5%) for priority traffic and ~950 mbps for class-default."

This statement may be true but when I do a "show policy-map interface"
command, it seems to allocate the percentage of bandwidth correctly as
to what I've specified with the "bandwidth" interface command (ie:
bandwidth 5% (10000 kbps)). I read somewhere that the QoS policy takes
into account what you set the "bandwidth" interface command to. This
seems to be true when I do a "show policy-map interface" because it's
using the "bandwidth" interface command to allocate the bandwidth as
shown below.

Eg:

POP2#sh run int g4/0/2

interface GigabitEthernet4/0/2
 description POP2 to POP1
 bandwidth 200000
 ip address 203.17.96.x 255.255.255.252
 load-interval 30
 negotiation auto
 mpls ip
 service-policy output POP2-POP1-QOS-POLICY

POP2#sh policy-map int g4/0/2

 GigabitEthernet4/0/2

  Service-policy output: POP2-POP1-QOS-POLICY

  Counters last updated 00:00:00 ago

    Class-map: POP2-POP1-PRIORITY-CLASS (match-all)
      257210114 packets, 100115814069 bytes
      30 second offered rate 714000 bps, drop rate 0 bps
      Match: access-group name POP2-POP1-PRIORITY-ACL
      Queueing
      queue limit 2500 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 257210496/100115335835

      bandwidth 5% (10000 kbps)

    Class-map: class-default (match-any)
      17135073305 packets, 13449181375380 bytes
      30 second offered rate 118450000 bps, drop rate 0 bps
      Match: any

      queue limit 47500 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 17135119901/13449209630832

        Exp-weight-constant: 9 (1/512)
        Mean queue depth: 1 packets

---

So will issuing the "bandwidth" interface command allow the scheduler to
issue the correct bandwidth requirements for each class? Or does the
fact that it's a GigE interface mean that the buffers never become
exhausted and in theory no congestion will take place, so the
"bandwidth" interface command (eventhough set) plays no real part ???

Thanks.

--

Regards,
 
Andy Saykao
Systems Administrator
Netspace Online Systems Pty Ltd
Phone : 03 9811 0049
Mobile : 0401 422 406
Fax     : 03 9811 0044
E-Mail : andy.saykao at staff.netspace.net.au

-----Original Message-----
From: Peter Rathlev [mailto:peter at rathlev.dk] 
Sent: Wednesday, 25 March 2009 11:47 PM
To: Andy Saykao
Cc: cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] Question about CBWFQ and PING times

On Wed, 2009-03-25 at 13:17 +1100, Andy Saykao wrote:
> POP1 = Cisco 7204VXR (NPE-G1) GigE Interface running 12.2(31)SB13
> 
> POP2 = Cisco 7606 with 4-subslot SPA Interface (7600-SIP-400) running
> 12.2(33)SRB3
> 
> 1/ "If you have a 200mbps connection going out from 
> GigabitEthernet-link your prioritising won't take effect, since
buffers will never saturate."
> So if we were to prioritize something like Voice, we would need to 
> implement some Heirarchical QoS solution on the Cisco 7606???

Generally speaking: Yes. When the scheduler needs to figure out if there
is bandwidth enough for non-priority traffic it needs to know how much
bandwidth is available. You need to tell the router that it only has 200
mbps and not the full 1 Gbps. Otherwise it will allocate ~50 mbps (your
5%) for priority traffic and ~950 mbps for class-default.

AFAIK both the SIP-400 and the G1 should be able to shape an interface
this way, but I could be wrong. :-)

> 2/ I understand your arguments exactly about not prioritizing ICMP 
> traffic, but I was told to look into this. I guess based on 1/ above, 
> some form of Heirarchical QoS solution is needed for this also.

Yes, you just need to wrap a shaping parent policy around your existing
"POP2-POP1-QOS-POLICY" policy.

Regards,
Peter



______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

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 danletkeman at gmail.com  Wed Mar 25 20:24:50 2009
From: danletkeman at gmail.com (Dan Letkeman)
Date: Wed, 25 Mar 2009 19:24:50 -0500
Subject: [c-nsp] vpn configuration
Message-ID: <dcbb85870903251724i8ccac39y3c66fd774fb2949a@mail.gmail.com>

Hello,

I have the need to create a vpn between two routers.  R2 is behind R1
which is doing nat, and R3 has an interface with a public ip.  R3 has
to initiate the vpn connection because it has a dynamic public ip.  I
also need to be able to run ospf across the vpn and monitor the vpn
traffic.

What would be the best way to do this? Does anyone have any
configuration examples?

Thanks
Dan.

From illcritikz at gmail.com  Wed Mar 25 20:51:00 2009
From: illcritikz at gmail.com (Ben Steele)
Date: Thu, 26 Mar 2009 11:21:00 +1030
Subject: [c-nsp] vpn configuration
In-Reply-To: <dcbb85870903251724i8ccac39y3c66fd774fb2949a@mail.gmail.com>
References: <dcbb85870903251724i8ccac39y3c66fd774fb2949a@mail.gmail.com>
Message-ID: <4422cf660903251751u7dfba796hd2005a68f23e528c@mail.gmail.com>

DMVPN with GRE is your friend
http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a008019d6f7.shtml

On Thu, Mar 26, 2009 at 10:54 AM, Dan Letkeman <danletkeman at gmail.com>wrote:

> Hello,
>
> I have the need to create a vpn between two routers.  R2 is behind R1
> which is doing nat, and R3 has an interface with a public ip.  R3 has
> to initiate the vpn connection because it has a dynamic public ip.  I
> also need to be able to run ospf across the vpn and monitor the vpn
> traffic.
>
> What would be the best way to do this? Does anyone have any
> configuration examples?
>
> Thanks
> Dan.
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From rshughes at gmail.com  Thu Mar 26 00:36:22 2009
From: rshughes at gmail.com (Ryan Hughes)
Date: Thu, 26 Mar 2009 00:36:22 -0400
Subject: [c-nsp] EIGRP Neighbor tracking
Message-ID: <e44f1b0e0903252136w5e212f5n934f80c8731dae2@mail.gmail.com>

Hi,

Just wondering if anyone on list has run into issues where their routed
Metro-E links will sometimes stay up as the mux isn't properly downing the
interface ( cheap gear without interface tracking per se) when the circuit
goes down. Pinging the interface doesn't really apply in this situation as
there is routed dark fiber links for backup connectivity. I was thinking
along the lines of an EEM script to source pings from the connected
interface and see if its up and send an SNMP but I haven't had time to
script it. I really don't need to accomlish anything fancy - just an alarm
so the NOC can see it and report it to us.

Researching the SNMP MIB but there didn't seem to be anything available. I
had run into this issue in the past but I was doing BGP over the link which
obviously offers the neighbor down snmp trap.Honestly, I'd prefer to have
the provider resolve the issue on their gear but given the aggressive
pricing of the circuit I'm not sure I have much recourse.

Appreciate the feedback.

Ryan

From tvarriale at comcast.net  Thu Mar 26 00:59:05 2009
From: tvarriale at comcast.net (Tony Varriale)
Date: Wed, 25 Mar 2009 23:59:05 -0500
Subject: [c-nsp] EIGRP Neighbor tracking
References: <e44f1b0e0903252136w5e212f5n934f80c8731dae2@mail.gmail.com>
Message-ID: <880187D0409F43889F6DD05CDA2FB39B@flamdt01>

What are you trying to accomplish?  Your subnet says something about EIGRP 
but the message doesn't. :)

tv
----- Original Message ----- 
From: "Ryan Hughes" <rshughes at gmail.com>
To: <cisco-nsp at puck.nether.net>
Sent: Wednesday, March 25, 2009 11:36 PM
Subject: [c-nsp] EIGRP Neighbor tracking


> Hi,
>
> Just wondering if anyone on list has run into issues where their routed
> Metro-E links will sometimes stay up as the mux isn't properly downing the
> interface ( cheap gear without interface tracking per se) when the circuit
> goes down. Pinging the interface doesn't really apply in this situation as
> there is routed dark fiber links for backup connectivity. I was thinking
> along the lines of an EEM script to source pings from the connected
> interface and see if its up and send an SNMP but I haven't had time to
> script it. I really don't need to accomlish anything fancy - just an alarm
> so the NOC can see it and report it to us.
>
> Researching the SNMP MIB but there didn't seem to be anything available. I
> had run into this issue in the past but I was doing BGP over the link 
> which
> obviously offers the neighbor down snmp trap.Honestly, I'd prefer to have
> the provider resolve the issue on their gear but given the aggressive
> pricing of the circuit I'm not sure I have much recourse.
>
> Appreciate the feedback.
>
> Ryan
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/ 


From networkstuff.training at gmail.com  Thu Mar 26 01:06:20 2009
From: networkstuff.training at gmail.com (Swati Sharma)
Date: Thu, 26 Mar 2009 10:36:20 +0530
Subject: [c-nsp] mls cef max route
Message-ID: <8a93d4b30903252206o593769aan82e16eb82e1fa93d@mail.gmail.com>

Hi,

Though I have just few routes still I am getting

Mar 26 04:49:06.406 UTC: %MLSCEF-SP-4-FIB_EXCEPTION: FIB TCAM exception for
IPv4 unicast, Some routes will be software switched.
Use "mls cef maximum-routes" to modify FIB TCAM  partition.

6500.LAB#sh mls cef maximum-routes
FIB TCAM maximum routes :
=======================
Current :-
-------
 IPv4 + MPLS         - 512k (default)
 IPv6 + IP Multicast - 256k (default)


6500.LAB#sh mls cef maximum-routes ?
  |  Output modifiers
  <cr>

6500.LAB#sh mls cef maximum-routes
FIB TCAM maximum routes :
=======================
Current :-
-------
 IPv4 + MPLS         - 512k (default)
 IPv6 + IP Multicast - 256k (default)


6500.LAB#sh ip route SUMMary
IP routing table name is Default-IP-Routing-Table(0)
Route Source    Networks    Subnets     Overhead    Memory (bytes)
connected       0           4           256         640
static          0           3           192         480
isis COLT       0           25          1856        4000
  Level 1: 16 Level 2: 0 Inter-area: 9
bgp 8220        1           2           192         480
  External: 0 Internal: 3 Local: 0
internal        5                                   5900
Total           6           34          2496        11500
6500.LAB#

any idea !!!

Regards,

From ip at ioshints.info  Thu Mar 26 01:35:59 2009
From: ip at ioshints.info (Ivan Pepelnjak)
Date: Thu, 26 Mar 2009 06:35:59 +0100
Subject: [c-nsp] EIGRP Neighbor tracking
In-Reply-To: <e44f1b0e0903252136w5e212f5n934f80c8731dae2@mail.gmail.com>
References: <e44f1b0e0903252136w5e212f5n934f80c8731dae2@mail.gmail.com>
Message-ID: <002d01c9add4$bf870a20$0a00000a@nil.si>

If all you need is to track whether you can ping the directly connected IP
address and react on the tracked object "down" status, you can use EEM with
the "event track X state up|down" trigger.

See the "Not so very static routes" section in this article
http://www.nil.com/ipcorner/SmallSiteMultiHoming/ for the SLA and tracking
object configuration. The "Monitoring reliable static routing" section in
the same article has the EEM examples.

If you happen to be running EIGRP on the link (as your message subject would
indicate), you can use syslog event detector in EEM to detect when the EIGRP
neighbor goes down. EEM is also able to generate SNMP traps if that's what
you prefer to receive.

If you need more EEM sample code (for example, how to send an e-mail), check
my EEM posts (http://blog.ioshints.info/search/label/EEM) or EEM sample
scripts in our wiki (http://wiki.nil.com/Category:EEM).

Hope this helps
Ivan
 
http://www.ioshints.info/about
http://blog.ioshints.info/

> -----Original Message-----
> From: Ryan Hughes [mailto:rshughes at gmail.com] 
> Sent: Thursday, March 26, 2009 5:36 AM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] EIGRP Neighbor tracking
> 
> Hi,
> 
> Just wondering if anyone on list has run into issues where 
> their routed Metro-E links will sometimes stay up as the mux 
> isn't properly downing the interface ( cheap gear without 
> interface tracking per se) when the circuit goes down. 
> Pinging the interface doesn't really apply in this situation 
> as there is routed dark fiber links for backup connectivity. 
> I was thinking along the lines of an EEM script to source 
> pings from the connected interface and see if its up and send 
> an SNMP but I haven't had time to script it. I really don't 
> need to accomlish anything fancy - just an alarm so the NOC 
> can see it and report it to us.
> 
> Researching the SNMP MIB but there didn't seem to be anything 
> available. I had run into this issue in the past but I was 
> doing BGP over the link which obviously offers the neighbor 
> down snmp trap.Honestly, I'd prefer to have the provider 
> resolve the issue on their gear but given the aggressive 
> pricing of the circuit I'm not sure I have much recourse.
> 
> Appreciate the feedback.
> 
> Ryan
> 
> 


From peter at rathlev.dk  Thu Mar 26 04:58:13 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Thu, 26 Mar 2009 09:58:13 +0100
Subject: [c-nsp] mls cef max route
In-Reply-To: <8a93d4b30903252206o593769aan82e16eb82e1fa93d@mail.gmail.com>
References: <8a93d4b30903252206o593769aan82e16eb82e1fa93d@mail.gmail.com>
Message-ID: <1238057893.3754.2.camel@localhost.localdomain>

On Thu, 2009-03-26 at 10:36 +0530, Swati Sharma wrote:
> Though I have just few routes still I am getting
> 
> Mar 26 04:49:06.406 UTC: %MLSCEF-SP-4-FIB_EXCEPTION: FIB TCAM
> exception for IPv4 unicast, Some routes will be software switched.
> Use "mls cef maximum-routes" to modify FIB TCAM  partition.
> 
> 6500.LAB#sh mls cef maximum-routes
> FIB TCAM maximum routes :
> =======================
> Current :-
> -------
>  IPv4 + MPLS         - 512k (default)
>  IPv6 + IP Multicast - 256k (default)
...
> any idea !!!

What does "show tcam counts" and "show platform hardware capacity pfc"
say?

Regards,
Peter



From MLouis at nwnit.com  Thu Mar 26 07:17:53 2009
From: MLouis at nwnit.com (Mike Louis)
Date: Thu, 26 Mar 2009 07:17:53 -0400
Subject: [c-nsp] Getvpn same box ks and gm
Message-ID: <CBBF2C7B2547D14A910A349B58810AC25C4CDBF1C6@mncmx1.NWNIT.CORP>

Does anyone know when cisco plans to support getvpn key server and group member configurations on the same box?
________________________________
Note: This message and any attachments is intended solely for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, legally privileged, confidential, and/or exempt from disclosure. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the original sender immediately by telephone or return email and destroy or delete this message along with any attachments immediately.

From gert at greenie.muc.de  Thu Mar 26 07:21:22 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Thu, 26 Mar 2009 12:21:22 +0100
Subject: [c-nsp] mls cef max route
In-Reply-To: <8a93d4b30903252206o593769aan82e16eb82e1fa93d@mail.gmail.com>
References: <8a93d4b30903252206o593769aan82e16eb82e1fa93d@mail.gmail.com>
Message-ID: <20090326112122.GN290@greenie.muc.de>

Hi,

On Thu, Mar 26, 2009 at 10:36:20AM +0530, Swati Sharma wrote:
> 6500.LAB#sh mls cef maximum-routes

Try: "sh mls cef su"

to see what IOS is thinking about TCAM usage.

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/20090326/f12a1b58/attachment.bin>

From peter at rathlev.dk  Thu Mar 26 08:27:13 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Thu, 26 Mar 2009 12:27:13 +0000
Subject: [c-nsp] Question about CBWFQ and PING times
In-Reply-To: <56F211C5E3F24F47B103EA1B253822BE03654CB1@vic-cr-ex1.staff.netspace.net.au>
References: <56F211C5E3F24F47B103EA1B253822BE03654CB1@vic-cr-ex1.staff.netspace.net.au>
Message-ID: <1238070433.3754.74.camel@localhost.localdomain>

On Thu, 2009-03-26 at 11:04 +1100, Andy Saykao wrote:
> I tried to create a Heirarchical QoS policy on a spare 7606 we have here
> and no go. Tried to create a parent shaper and policer and neither
> worked when the service-policy was applied to the interface.

I would've thought the SIP-400 could do shaping. Data sheet says DTS is
supported, but I don't have one at hand to test it. The specific PA
might also set limitations. You may be out of luck with those
interfaces.

I assume it is a SPA in the SIP-400 you add the service-policy to,
right? Interface on LAN cards can't do it this way.

> You wrote - "You need to tell the router that it only has 200 mbps and
> not the full 1 Gbps. Otherwise it will allocate ~50 mbps (your
> 5%) for priority traffic and ~950 mbps for class-default."
> 
> This statement may be true but when I do a "show policy-map interface"
> command, it seems to allocate the percentage of bandwidth correctly as
> to what I've specified with the "bandwidth" interface command (ie:
> bandwidth 5% (10000 kbps)). I read somewhere that the QoS policy takes
> into account what you set the "bandwidth" interface command to. This
> seems to be true when I do a "show policy-map interface" because it's
> using the "bandwidth" interface command to allocate the bandwidth as
> shown below.

The "bandwidth" command doesn't do anything by itself, other than
letting e.g. routing protocols know what bandwidth is available on this
link. EIGRP and RSVP could use this. The command does not in itself help
with shaping/policing.

It's correct that the policy-map "percent" parameter looks at exactly
this parameter, but this is just configuration short-hand. Disregarding
everything but your priority queue, these four methods all reserve 100
mbps on a Gigabit-interface:

- No "bandwidth" parameter (default), "priority percent 10"
- No "bandwidth" parameter (default), "priority 100000"
- Specify "bandwidth 200000", "priority percent 50"
- Specify "bandwidth 200000", "priority 100000"

Consider the "bandwidth" parameter strictly informational.

You would have to find out what features your interface supports. DTS
and hierarchical QoS should let you use a parent shaper. Some LAN cards
support SRR which could give you a crude way of shaping.

We use shaping on 7200s with no problems, but I have never used DTS on
the switch platforms (7600/6500) so I may make some wrong conclusions.
And my SRR experience has so far been limited to lab tests.

Regards,
Peter



From hritter at cisco.com  Thu Mar 26 08:55:57 2009
From: hritter at cisco.com (Harold Ritter (hritter))
Date: Thu, 26 Mar 2009 08:55:57 -0400
Subject: [c-nsp] BGP session resets if NLRI exchanged
In-Reply-To: <49CA53B9.5080404@heanet.ie>
References: <49CA53B9.5080404@heanet.ie>
Message-ID: <F4469404D9886545AD22355D96D8620F07369C35@xmb-rtp-20a.amer.cisco.com>

Paul,

You might be running into CSCsl72955. If so, you could try the
workaround suggested by the following link or upgrade the code.

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method
=fetchBugDetails&bugId=CSCsl72955 

Regards

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Paul Cosgrove
Sent: Wednesday, March 25, 2009 11:55 AM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] BGP session resets if NLRI exchanged

We are attempting to establish a new BGP session between one of our
CRS-1 routers, and a Redback SE800 router owned by another provider.  Am
not familiar with Redbacks myself and we have not peered with any before
(as far as we know anyway).  The BGP session only remains up if no NLRI
is exchanged.  If the other provider sends any prefixes to us we reply
with a "invalid length for attribute" notification; if we send any
prefixes to them they reply with  "invalid or corrupt AS path". 

The other provider uses VPNv4 within their network, though I understand
that it is not configured on this peering.  I'm wondering whether these
errors could result if their router expects a RD (and sends one) on the
advertisements, perhaps due to a software bug or typo in the config. 

Perhaps someone has seen this problem before?

Paul.





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

From alex.wilkinson at dsto.defence.gov.au  Thu Mar 26 08:15:45 2009
From: alex.wilkinson at dsto.defence.gov.au (Wilkinson, Alex)
Date: Thu, 26 Mar 2009 21:15:45 +0900
Subject: [c-nsp] Tracking bandwidth hogs ... any recommendations ?
Message-ID: <20090326121545.GI10080@stlux503.dsto.defence.gov.au>

Hi all,

I would like to put in place measures to be able to pin point the particular
user(s) who are thrashing out our WAN connection. I am thinking ...

  Mirror all ports (SPAN) to a spare port and use trafshow to pinpoint the culprit.

However, i am curious how others deal with this situation ?

 -aW

IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914.  If you have received this email in error, you are requested to contact the sender and delete the email.



From p.mayers at imperial.ac.uk  Thu Mar 26 09:48:27 2009
From: p.mayers at imperial.ac.uk (Phil Mayers)
Date: Thu, 26 Mar 2009 13:48:27 +0000
Subject: [c-nsp] Tracking bandwidth hogs ... any recommendations ?
In-Reply-To: <20090326121545.GI10080@stlux503.dsto.defence.gov.au>
References: <20090326121545.GI10080@stlux503.dsto.defence.gov.au>
Message-ID: <49CB87AB.7050302@imperial.ac.uk>

Wilkinson, Alex wrote:
> Hi all,
> 
> I would like to put in place measures to be able to pin point the particular
> user(s) who are thrashing out our WAN connection. I am thinking ...
> 
>   Mirror all ports (SPAN) to a spare port and use trafshow to pinpoint the culprit.
> 
> However, i am curious how others deal with this situation ?

Netflow.

From rodunn at cisco.com  Thu Mar 26 09:50:23 2009
From: rodunn at cisco.com (Rodney Dunn)
Date: Thu, 26 Mar 2009 09:50:23 -0400
Subject: [c-nsp] Tracking bandwidth hogs ... any recommendations ?
In-Reply-To: <20090326121545.GI10080@stlux503.dsto.defence.gov.au>
References: <20090326121545.GI10080@stlux503.dsto.defence.gov.au>
Message-ID: <20090326135023.GG27263@rtp-cse-489.cisco.com>

Why not use Netflow?

On Thu, Mar 26, 2009 at 09:15:45PM +0900, Wilkinson, Alex wrote:
> Hi all,
> 
> I would like to put in place measures to be able to pin point the particular
> user(s) who are thrashing out our WAN connection. I am thinking ...
> 
>   Mirror all ports (SPAN) to a spare port and use trafshow to pinpoint the culprit.
> 
> However, i am curious how others deal with this situation ?
> 
>  -aW
> 
> IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914.  If you have received this email in error, you are requested to contact the sender and delete the email.
> 
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

From James.Pender at PAETEC.com  Thu Mar 26 10:06:25 2009
From: James.Pender at PAETEC.com (Pender, James)
Date: Thu, 26 Mar 2009 10:06:25 -0400
Subject: [c-nsp] Tracking bandwidth hogs ... any recommendations ?
In-Reply-To: <20090326135023.GG27263@rtp-cse-489.cisco.com>
References: <20090326121545.GI10080@stlux503.dsto.defence.gov.au>
	<20090326135023.GG27263@rtp-cse-489.cisco.com>
Message-ID: <B1FBCC0EF362994491030771D94D15E6371B8827DF@NYMAILCLUSTER1.corp.paetec.com>

http://www.cisco.com/en/US/products/sw/iosswrel/ps1838/products_feature_guide09186a0080259533.html

How to setup netflow to monitor top talkers, and even poll the results with SNMP.

 

-----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, March 26, 2009 9:50 AM
To: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Tracking bandwidth hogs ... any recommendations ?

Why not use Netflow?

On Thu, Mar 26, 2009 at 09:15:45PM +0900, Wilkinson, Alex wrote:
> Hi all,
> 
> I would like to put in place measures to be able to pin point the particular
> user(s) who are thrashing out our WAN connection. I am thinking ...
> 
>   Mirror all ports (SPAN) to a spare port and use trafshow to pinpoint the culprit.
> 
> However, i am curious how others deal with this situation ?
> 
>  -aW
> 
> IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914.  If you have received this email in error, you are requested to contact the sender and delete the email.
> 
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________
cisco-nsp mailing list  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  Thu Mar 26 10:20:11 2009
From: rodunn at cisco.com (Rodney Dunn)
Date: Thu, 26 Mar 2009 10:20:11 -0400
Subject: [c-nsp] MLPPP
In-Reply-To: <49CA9C07.7030007@pins.net>
References: <49CA95A6.3030107@pins.net>
	<20090325205918.GG26674@rtp-cse-489.cisco.com>
	<49CA9C07.7030007@pins.net>
Message-ID: <20090326142011.GS27263@rtp-cse-489.cisco.com>

You have it in a VRF which really shouldn't cause an issue as it's
tag2ip and ip2tag.

What code is it?

Make sure it's the latest 12.4 mainline as we did some work in 12.4 to make
this work.

Can you get a 'sh int mul 2 stat' after a clear counters...get it a few
times and send it?

Also, what are the other interface configs feeding this bundle?
It could be features on them causing the punts.

What does 'sh cef int' say?


Rodney

On Wed, Mar 25, 2009 at 05:03:03PM -0400, Jason Berenson wrote:
> Here's a sample:
> 
> interface Multilink2
> ip vrf forwarding VPN1
> ip address x.x.x.x 255.255.255.252
> no cdp enable
> ppp multilink
> ppp multilink group 2
> service-policy output voice
> !
> interface Serial6/0/25:0
> no ip address
> encapsulation ppp
> down-when-looped
> no cdp enable
> ppp multilink
> ppp multilink group 2
> !
> interface Serial6/0/26:0
> no ip address
> encapsulation ppp
> down-when-looped
> no cdp enable
> ppp multilink
> ppp multilink group 2
> !
> 
> -Jason
> 
> 
> Rodney Dunn wrote:
> >The G1's with MLPPP should not be process switching the traffic.
> >
> >What is the config?
> >
> >The EC cards just offload the MLPPP to the new asic on the PA.
> >
> >Rodney
> >
> >On Wed, Mar 25, 2009 at 04:35:50PM -0400, Jason Berenson wrote:
> >  
> >>Greetings,
> >>
> >>I've got a 7206VXR NPE-G1 with a bunch of DS3 cards in it (PA-MC-T3).  
> >>There's about 25 multilinks with an average of 2 T1s per bundle.  I see 
> >>a lot of process switching on the router and I have a feeling it's 
> >>because we don't have the PA-MC-T3-EC card so the processor has to step 
> >>in for the MLPPP. 
> >>
> >>Is this the case?  If I get some PA-MC-T3-EC cards to swap in, will that 
> >>take a lot of load off the NPE-G1?  Any output needed, please let me know.
> >>
> >>Thanks,
> >>Jason
> >>_______________________________________________
> >>cisco-nsp mailing list  cisco-nsp at puck.nether.net
> >>https://puck.nether.net/mailman/listinfo/cisco-nsp
> >>archive at http://puck.nether.net/pipermail/cisco-nsp/
> >>    

From jason at pins.net  Thu Mar 26 10:30:08 2009
From: jason at pins.net (Jason Berenson)
Date: Thu, 26 Mar 2009 10:30:08 -0400
Subject: [c-nsp] MLPPP
In-Reply-To: <20090326142011.GS27263@rtp-cse-489.cisco.com>
References: <49CA95A6.3030107@pins.net>
	<20090325205918.GG26674@rtp-cse-489.cisco.com>
	<49CA9C07.7030007@pins.net>
	<20090326142011.GS27263@rtp-cse-489.cisco.com>
Message-ID: <49CB9170.40407@pins.net>

Rodney,

It's running: 12.4(18a).  I had to downgrade from the latest about 6 
months ago because of a bug where 'show policy' would show no output 
even if QoS was working properly.

router#show int mul2 stat
Multilink2
          Switching path    Pkts In   Chars In   Pkts Out  Chars Out
               Processor          0          0          0          0
             Route cache      18049    3982931      25553   14234069
                   Total      18049    3982931      25553   14234069
router#show int mul2 stat
Multilink2
          Switching path    Pkts In   Chars In   Pkts Out  Chars Out
               Processor          0          0          0          0
             Route cache      18601    4110973      26553   14682852
                   Total      18601    4110973      26553   14682852

fonseca#show cef in mul 2
Multilink2 is up (if_number 132)
  Corresponding hwidb fast_if_number 132
  Corresponding hwidb firstsw->if_number 132
  Internet address is 10.3.4.229/30
  ICMP redirects are always sent
  Per packet load-sharing is disabled
  IP unicast RPF check is disabled
  Inbound access list is not set
  Outbound access list is not set
  Interface is marked as point to point interface
  Hardware idb is Multilink2
  Fast switching type 7, interface type 105
  IP CEF switching enabled
  IP CEF VPN Feature Fast switching turbo vector
  IP Null turbo vector
  VPN Forwarding table "nypirg"
  Input fast flags 0x1000, Input fast flags2 0x0, Output fast flags 
0x4000, Output fast flags2 0x0
  ifindex 127(127)
  Slot -1 Slot unit 2 Unit 2 VC -1
  Transmit limit accumulator 0x0 (0x0)
  IP MTU 1500

Does that mean that there's no processor switching going on there?  Why 
would a VRF make any difference to the MLPPP?  I see the same outputs 
for a non VRF'd MLPPP.

-Jason

Rodney Dunn wrote:
> You have it in a VRF which really shouldn't cause an issue as it's
> tag2ip and ip2tag.
>
> What code is it?
>
> Make sure it's the latest 12.4 mainline as we did some work in 12.4 to make
> this work.
>
> Can you get a 'sh int mul 2 stat' after a clear counters...get it a few
> times and send it?
>
> Also, what are the other interface configs feeding this bundle?
> It could be features on them causing the punts.
>
> What does 'sh cef int' say?
>
>
> Rodney
>
> On Wed, Mar 25, 2009 at 05:03:03PM -0400, Jason Berenson wrote:
>   
>> Here's a sample:
>>
>> interface Multilink2
>> ip vrf forwarding VPN1
>> ip address x.x.x.x 255.255.255.252
>> no cdp enable
>> ppp multilink
>> ppp multilink group 2
>> service-policy output voice
>> !
>> interface Serial6/0/25:0
>> no ip address
>> encapsulation ppp
>> down-when-looped
>> no cdp enable
>> ppp multilink
>> ppp multilink group 2
>> !
>> interface Serial6/0/26:0
>> no ip address
>> encapsulation ppp
>> down-when-looped
>> no cdp enable
>> ppp multilink
>> ppp multilink group 2
>> !
>>
>> -Jason
>>
>>
>> Rodney Dunn wrote:
>>     
>>> The G1's with MLPPP should not be process switching the traffic.
>>>
>>> What is the config?
>>>
>>> The EC cards just offload the MLPPP to the new asic on the PA.
>>>
>>> Rodney
>>>
>>> On Wed, Mar 25, 2009 at 04:35:50PM -0400, Jason Berenson wrote:
>>>  
>>>       
>>>> Greetings,
>>>>
>>>> I've got a 7206VXR NPE-G1 with a bunch of DS3 cards in it (PA-MC-T3).  
>>>> There's about 25 multilinks with an average of 2 T1s per bundle.  I see 
>>>> a lot of process switching on the router and I have a feeling it's 
>>>> because we don't have the PA-MC-T3-EC card so the processor has to step 
>>>> in for the MLPPP. 
>>>>
>>>> Is this the case?  If I get some PA-MC-T3-EC cards to swap in, will that 
>>>> take a lot of load off the NPE-G1?  Any output needed, please let me know.
>>>>
>>>> Thanks,
>>>> Jason
>>>> _______________________________________________
>>>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>>>    
>>>>         

From paul at paulstewart.org  Thu Mar 26 10:07:31 2009
From: paul at paulstewart.org (Paul Stewart)
Date: Thu, 26 Mar 2009 10:07:31 -0400
Subject: [c-nsp] Tracking bandwidth hogs ... any recommendations ?
In-Reply-To: <20090326121545.GI10080@stlux503.dsto.defence.gov.au>
References: <20090326121545.GI10080@stlux503.dsto.defence.gov.au>
Message-ID: <003301c9ae1c$34545870$9cfd0950$@org>

Netflow would be our first choice if possible...

Paul


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Wilkinson, Alex
Sent: Thursday, March 26, 2009 8:16 AM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Tracking bandwidth hogs ... any recommendations ?

Hi all,

I would like to put in place measures to be able to pin point the particular
user(s) who are thrashing out our WAN connection. I am thinking ...

  Mirror all ports (SPAN) to a spare port and use trafshow to pinpoint the
culprit.

However, i am curious how others deal with this situation ?

 -aW

IMPORTANT: This email remains the property of the Australian Defence
Organisation and is subject to the jurisdiction of section 70 of the CRIMES
ACT 1914.  If you have received this email in error, you are requested to
contact the sender and delete the email.


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




This message was delivered by MDaemon - http://www.altn.com/MDaemon/



From jeff-kell at utc.edu  Thu Mar 26 11:17:20 2009
From: jeff-kell at utc.edu (Jeff Kell)
Date: Thu, 26 Mar 2009 11:17:20 -0400
Subject: [c-nsp] Tracking bandwidth hogs ... any recommendations ?
In-Reply-To: <003301c9ae1c$34545870$9cfd0950$@org>
References: <20090326121545.GI10080@stlux503.dsto.defence.gov.au>
	<003301c9ae1c$34545870$9cfd0950$@org>
Message-ID: <49CB9C80.40405@utc.edu>

Paul Stewart wrote:
> Netflow would be our first choice if possible...

If you can monitor it on a single span port, iftop is nice, quick, easy,
and free.

Jeff

From wmaton at ryouko.imsb.nrc.ca  Thu Mar 26 10:45:08 2009
From: wmaton at ryouko.imsb.nrc.ca (William F. Maton Sotomayor)
Date: Thu, 26 Mar 2009 10:45:08 -0400 (EDT)
Subject: [c-nsp] Tracking bandwidth hogs ... any recommendations ?
In-Reply-To: <003301c9ae1c$34545870$9cfd0950$@org>
References: <20090326121545.GI10080@stlux503.dsto.defence.gov.au>
	<003301c9ae1c$34545870$9cfd0950$@org>
Message-ID: <Pine.LNX.4.64.0903261041230.29215@ryouko.imsb.nrc.ca>

On Thu, 26 Mar 2009, Paul Stewart wrote:

> Netflow would be our first choice if possible...

+1

Definitely NetFlow.  In a pinch, one could do 'show ip ca fl' over and 
over a few times to try and eyeball quickly rising counters, then isolate 
the interesting line by doing 'show ip ca fl | inc <an IP address>' to 
verify the type of traffic, etc for that IP.

For something longer-term OSU/Google code flow-tools is a good option.


> Paul
>
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Wilkinson, Alex
> Sent: Thursday, March 26, 2009 8:16 AM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] Tracking bandwidth hogs ... any recommendations ?
>
> Hi all,
>
> I would like to put in place measures to be able to pin point the particular
> user(s) who are thrashing out our WAN connection. I am thinking ...
>
>  Mirror all ports (SPAN) to a spare port and use trafshow to pinpoint the
> culprit.
>
> However, i am curious how others deal with this situation ?
>
> -aW
>
> IMPORTANT: This email remains the property of the Australian Defence
> Organisation and is subject to the jurisdiction of section 70 of the CRIMES
> ACT 1914.  If you have received this email in error, you are requested to
> contact the sender and delete the email.
>
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>
>
>
> This message was delivered by MDaemon - http://www.altn.com/MDaemon/
>
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>


wfms

From paul at paulstewart.org  Thu Mar 26 10:07:51 2009
From: paul at paulstewart.org (Paul Stewart)
Date: Thu, 26 Mar 2009 10:07:51 -0400
Subject: [c-nsp] Tracking bandwidth hogs ... any recommendations ?
In-Reply-To: <20090326121545.GI10080@stlux503.dsto.defence.gov.au>
References: <20090326121545.GI10080@stlux503.dsto.defence.gov.au>
Message-ID: <000001c9ae1c$4dbe8a60$e93b9f20$@org>

Netflow would be our first choice if possible...

Paul


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Wilkinson, Alex
Sent: Thursday, March 26, 2009 8:16 AM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Tracking bandwidth hogs ... any recommendations ?

Hi all,

I would like to put in place measures to be able to pin point the particular
user(s) who are thrashing out our WAN connection. I am thinking ...

  Mirror all ports (SPAN) to a spare port and use trafshow to pinpoint the
culprit.

However, i am curious how others deal with this situation ?

 -aW

IMPORTANT: This email remains the property of the Australian Defence
Organisation and is subject to the jurisdiction of section 70 of the CRIMES
ACT 1914.  If you have received this email in error, you are requested to
contact the sender and delete the email.


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



From jeff-kell at utc.edu  Thu Mar 26 12:02:13 2009
From: jeff-kell at utc.edu (Jeff Kell)
Date: Thu, 26 Mar 2009 12:02:13 -0400
Subject: [c-nsp] Tracking bandwidth hogs ... any recommendations ?
In-Reply-To: <49CB9C80.40405@utc.edu>
References: <20090326121545.GI10080@stlux503.dsto.defence.gov.au>	<003301c9ae1c$34545870$9cfd0950$@org>
	<49CB9C80.40405@utc.edu>
Message-ID: <49CBA705.7010202@utc.edu>

To add to my previous note...

Jeff Kell wrote:
> If you can monitor it on a single span port, iftop is nice, quick, easy,
> and free.

Or ipaudit, if you want longer-term samples (provides 30-minute, daily,
weekly).

Jeff

From lowen at pari.edu  Thu Mar 26 12:37:22 2009
From: lowen at pari.edu (Lamar Owen)
Date: Thu, 26 Mar 2009 12:37:22 -0400
Subject: [c-nsp] Tracking bandwidth hogs ... any recommendations ?
In-Reply-To: <20090326121545.GI10080@stlux503.dsto.defence.gov.au>
References: <20090326121545.GI10080@stlux503.dsto.defence.gov.au>
Message-ID: <200903261237.23088.lowen@pari.edu>

On Thursday 26 March 2009 08:15:45 Wilkinson, Alex wrote:
> I would like to put in place measures to be able to pin point the
> particular user(s) who are thrashing out our WAN connection. I am thinking

> However, i am curious how others deal with this situation ?

NetFlow feeding nTop. (www.ntop.org).
-- 
Lamar Owen
Chief Information Officer
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
http://www.pari.edu

From nick.jon.griffin at gmail.com  Thu Mar 26 12:48:16 2009
From: nick.jon.griffin at gmail.com (Nick Griffin)
Date: Thu, 26 Mar 2009 11:48:16 -0500
Subject: [c-nsp] Cisco and Foundry and MST
Message-ID: <a2b352c40903260948o453212br559018635629ae41@mail.gmail.com>

I'm working with a client that is migrating to Foundry from Cisco and they
need to have interoperability on STP between the two vendors. I usually try
to do MST when I can, usually in a cisco environment, so I'm pretty
comfortable with it. Does anyone have any experience getting the 2 to play
together? It's a critical environment, so minimal disruption is required.
There is a core 6500 that can connects to a number of Cisco access switches,
the Cisco 6500 also connects into the Foundry FESX switches. I wanted to go
ahead and enable MST on the core 6500, and then working my way to the access
layer (assuming the interoperability works just fine), and then the Foundry
boxes. Just looking for any pro-pointers here to try to avoid baptism by
fire! Thanks in advance.

Nick Griffin
Systems Consultant, CCIE R&S 17381

From rodunn at cisco.com  Thu Mar 26 12:53:13 2009
From: rodunn at cisco.com (Rodney Dunn)
Date: Thu, 26 Mar 2009 12:53:13 -0400
Subject: [c-nsp] MLPPP
In-Reply-To: <49CB9170.40407@pins.net>
References: <49CA95A6.3030107@pins.net>
	<20090325205918.GG26674@rtp-cse-489.cisco.com>
	<49CA9C07.7030007@pins.net>
	<20090326142011.GS27263@rtp-cse-489.cisco.com>
	<49CB9170.40407@pins.net>
Message-ID: <20090326165313.GD27263@rtp-cse-489.cisco.com>

On Thu, Mar 26, 2009 at 10:30:08AM -0400, Jason Berenson wrote:
> Rodney,
> 
> It's running: 12.4(18a).  I had to downgrade from the latest about 6 
> months ago because of a bug where 'show policy' would show no output 
> even if QoS was working properly.
> 
> router#show int mul2 stat
> Multilink2
>          Switching path    Pkts In   Chars In   Pkts Out  Chars Out
>               Processor          0          0          0          0
>             Route cache      18049    3982931      25553   14234069
>                   Total      18049    3982931      25553   14234069
> router#show int mul2 stat
> Multilink2
>          Switching path    Pkts In   Chars In   Pkts Out  Chars Out
>               Processor          0          0          0          0
>             Route cache      18601    4110973      26553   14682852
>                   Total      18601    4110973      26553   14682852
> 
> fonseca#show cef in mul 2
> Multilink2 is up (if_number 132)
>  Corresponding hwidb fast_if_number 132
>  Corresponding hwidb firstsw->if_number 132
>  Internet address is 10.3.4.229/30
>  ICMP redirects are always sent
>  Per packet load-sharing is disabled
>  IP unicast RPF check is disabled
>  Inbound access list is not set
>  Outbound access list is not set
>  Interface is marked as point to point interface
>  Hardware idb is Multilink2
>  Fast switching type 7, interface type 105
>  IP CEF switching enabled
>  IP CEF VPN Feature Fast switching turbo vector
>  IP Null turbo vector
>  VPN Forwarding table "nypirg"
>  Input fast flags 0x1000, Input fast flags2 0x0, Output fast flags 
> 0x4000, Output fast flags2 0x0
>  ifindex 127(127)
>  Slot -1 Slot unit 2 Unit 2 VC -1
>  Transmit limit accumulator 0x0 (0x0)
>  IP MTU 1500
> 
> Does that mean that there's no processor switching going on there? 

Yep. It's all being interrupt switched so you should be fine.

> Why 
> would a VRF make any difference to the MLPPP?

forwarding vectors are different. But in this code we have the hooks
to do MPLSoMLPPP if that's what you were doing..which you are not.
The vrf interface on a bundle isn't what we call MPLSoMLPPP...that's when
you enable MPLS on the bundle.

  I see the same outputs 
> for a non VRF'd MLPPP.

It's working as it should.

With the new PA the overall CPU would be less b/c the mlppp work is offloaded
to an asic on the PA.

> 
> -Jason
> 
> Rodney Dunn wrote:
> >You have it in a VRF which really shouldn't cause an issue as it's
> >tag2ip and ip2tag.
> >
> >What code is it?
> >
> >Make sure it's the latest 12.4 mainline as we did some work in 12.4 to make
> >this work.
> >
> >Can you get a 'sh int mul 2 stat' after a clear counters...get it a few
> >times and send it?
> >
> >Also, what are the other interface configs feeding this bundle?
> >It could be features on them causing the punts.
> >
> >What does 'sh cef int' say?
> >
> >
> >Rodney
> >
> >On Wed, Mar 25, 2009 at 05:03:03PM -0400, Jason Berenson wrote:
> >  
> >>Here's a sample:
> >>
> >>interface Multilink2
> >>ip vrf forwarding VPN1
> >>ip address x.x.x.x 255.255.255.252
> >>no cdp enable
> >>ppp multilink
> >>ppp multilink group 2
> >>service-policy output voice
> >>!
> >>interface Serial6/0/25:0
> >>no ip address
> >>encapsulation ppp
> >>down-when-looped
> >>no cdp enable
> >>ppp multilink
> >>ppp multilink group 2
> >>!
> >>interface Serial6/0/26:0
> >>no ip address
> >>encapsulation ppp
> >>down-when-looped
> >>no cdp enable
> >>ppp multilink
> >>ppp multilink group 2
> >>!
> >>
> >>-Jason
> >>
> >>
> >>Rodney Dunn wrote:
> >>    
> >>>The G1's with MLPPP should not be process switching the traffic.
> >>>
> >>>What is the config?
> >>>
> >>>The EC cards just offload the MLPPP to the new asic on the PA.
> >>>
> >>>Rodney
> >>>
> >>>On Wed, Mar 25, 2009 at 04:35:50PM -0400, Jason Berenson wrote:
> >>> 
> >>>      
> >>>>Greetings,
> >>>>
> >>>>I've got a 7206VXR NPE-G1 with a bunch of DS3 cards in it (PA-MC-T3).  
> >>>>There's about 25 multilinks with an average of 2 T1s per bundle.  I see 
> >>>>a lot of process switching on the router and I have a feeling it's 
> >>>>because we don't have the PA-MC-T3-EC card so the processor has to step 
> >>>>in for the MLPPP. 
> >>>>
> >>>>Is this the case?  If I get some PA-MC-T3-EC cards to swap in, will 
> >>>>that take a lot of load off the NPE-G1?  Any output needed, please let 
> >>>>me know.
> >>>>
> >>>>Thanks,
> >>>>Jason
> >>>>_______________________________________________
> >>>>cisco-nsp mailing list  cisco-nsp at puck.nether.net
> >>>>https://puck.nether.net/mailman/listinfo/cisco-nsp
> >>>>archive at http://puck.nether.net/pipermail/cisco-nsp/
> >>>>   
> >>>>        

From Ian.Mackinnon at lumison.net  Thu Mar 26 13:00:17 2009
From: Ian.Mackinnon at lumison.net (Ian MacKinnon)
Date: Thu, 26 Mar 2009 17:00:17 +0000
Subject: [c-nsp] Cisco and Foundry and MST
In-Reply-To: <a2b352c40903260948o453212br559018635629ae41@mail.gmail.com>
References: <a2b352c40903260948o453212br559018635629ae41@mail.gmail.com>
Message-ID: <B5F945E48C137C49A98BC86DD35939C012B9ADA217@nbg01-exch-01.entlstaff.domain.lumison.net>

Hi Nick,
I did something similar a while ago, so here are some thoughts.

Plan for downtime :-(
Don't expect it to be totally transparent, so make the changes in a maintenance window.

I think SXH and later do a real standards compliant version of MSTP with interop with standard STP.
Are you planning to use multiple instances, or just use one?
Make sure that your instance 0 (ie the STP) is the same on both sides, and if you are only using one instance ensure it is 0 on both sides.

Be aware of the differences between Cisco RSTP and A.N.Other Spanning tree in rapid mode.

I realise I am teaching you to suck eggs here, but plan what devices are going to be the root and backup, and manually configure them.

Hope this is useful.
Ian


> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> bounces at puck.nether.net] On Behalf Of Nick Griffin
> Sent: 26 March 2009 16:48
> To: cisco-nsp
> Subject: [c-nsp] Cisco and Foundry and MST
>
> I'm working with a client that is migrating to Foundry from Cisco and
> they
> need to have interoperability on STP between the two vendors. I usually
> try
> to do MST when I can, usually in a cisco environment, so I'm pretty
> comfortable with it. Does anyone have any experience getting the 2 to
> play
> together? It's a critical environment, so minimal disruption is
> required.
> There is a core 6500 that can connects to a number of Cisco access
> switches,
> the Cisco 6500 also connects into the Foundry FESX switches. I wanted
> to go
> ahead and enable MST on the core 6500, and then working my way to the
> access
> layer (assuming the interoperability works just fine), and then the
> Foundry
> boxes. Just looking for any pro-pointers here to try to avoid baptism
> by
> fire! Thanks in advance.
>
> Nick Griffin
> Systems Consultant, CCIE R&S 17381
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

--

This email 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 and nPlusOne.
Finally, the recipient should check this email and any attachments for the
presence of viruses.  Lumison and nPlusOne accept no liability for any
damage caused by any virus transmitted by this email.

From jason at pins.net  Thu Mar 26 13:03:06 2009
From: jason at pins.net (Jason Berenson)
Date: Thu, 26 Mar 2009 13:03:06 -0400
Subject: [c-nsp] MLPPP
In-Reply-To: <20090326165313.GD27263@rtp-cse-489.cisco.com>
References: <49CA95A6.3030107@pins.net>
	<20090325205918.GG26674@rtp-cse-489.cisco.com>
	<49CA9C07.7030007@pins.net>
	<20090326142011.GS27263@rtp-cse-489.cisco.com>
	<49CB9170.40407@pins.net>
	<20090326165313.GD27263@rtp-cse-489.cisco.com>
Message-ID: <49CBB54A.6010406@pins.net>

Rodney,

With the PA-MC-T3-EC, any idea how much would be offloaded to the PA?  
The router is running at about 75% peak average utilization, which is a 
bit high considering it's mostly doing routing and not pushing more then 
100Mbits.  If this is being interrupt switched, I wouldn't expect the EC 
PA to help, right?

-Jason

Rodney Dunn wrote:
> On Thu, Mar 26, 2009 at 10:30:08AM -0400, Jason Berenson wrote:
>   
>> Rodney,
>>
>> It's running: 12.4(18a).  I had to downgrade from the latest about 6 
>> months ago because of a bug where 'show policy' would show no output 
>> even if QoS was working properly.
>>
>> router#show int mul2 stat
>> Multilink2
>>          Switching path    Pkts In   Chars In   Pkts Out  Chars Out
>>               Processor          0          0          0          0
>>             Route cache      18049    3982931      25553   14234069
>>                   Total      18049    3982931      25553   14234069
>> router#show int mul2 stat
>> Multilink2
>>          Switching path    Pkts In   Chars In   Pkts Out  Chars Out
>>               Processor          0          0          0          0
>>             Route cache      18601    4110973      26553   14682852
>>                   Total      18601    4110973      26553   14682852
>>
>> fonseca#show cef in mul 2
>> Multilink2 is up (if_number 132)
>>  Corresponding hwidb fast_if_number 132
>>  Corresponding hwidb firstsw->if_number 132
>>  Internet address is 10.3.4.229/30
>>  ICMP redirects are always sent
>>  Per packet load-sharing is disabled
>>  IP unicast RPF check is disabled
>>  Inbound access list is not set
>>  Outbound access list is not set
>>  Interface is marked as point to point interface
>>  Hardware idb is Multilink2
>>  Fast switching type 7, interface type 105
>>  IP CEF switching enabled
>>  IP CEF VPN Feature Fast switching turbo vector
>>  IP Null turbo vector
>>  VPN Forwarding table "nypirg"
>>  Input fast flags 0x1000, Input fast flags2 0x0, Output fast flags 
>> 0x4000, Output fast flags2 0x0
>>  ifindex 127(127)
>>  Slot -1 Slot unit 2 Unit 2 VC -1
>>  Transmit limit accumulator 0x0 (0x0)
>>  IP MTU 1500
>>
>> Does that mean that there's no processor switching going on there? 
>>     
>
> Yep. It's all being interrupt switched so you should be fine.
>
>   
>> Why 
>> would a VRF make any difference to the MLPPP?
>>     
>
> forwarding vectors are different. But in this code we have the hooks
> to do MPLSoMLPPP if that's what you were doing..which you are not.
> The vrf interface on a bundle isn't what we call MPLSoMLPPP...that's when
> you enable MPLS on the bundle.
>
>   I see the same outputs 
>   
>> for a non VRF'd MLPPP.
>>     
>
> It's working as it should.
>
> With the new PA the overall CPU would be less b/c the mlppp work is offloaded
> to an asic on the PA.
>
>   
>> -Jason
>>
>> Rodney Dunn wrote:
>>     
>>> You have it in a VRF which really shouldn't cause an issue as it's
>>> tag2ip and ip2tag.
>>>
>>> What code is it?
>>>
>>> Make sure it's the latest 12.4 mainline as we did some work in 12.4 to make
>>> this work.
>>>
>>> Can you get a 'sh int mul 2 stat' after a clear counters...get it a few
>>> times and send it?
>>>
>>> Also, what are the other interface configs feeding this bundle?
>>> It could be features on them causing the punts.
>>>
>>> What does 'sh cef int' say?
>>>
>>>
>>> Rodney
>>>
>>> On Wed, Mar 25, 2009 at 05:03:03PM -0400, Jason Berenson wrote:
>>>  
>>>       
>>>> Here's a sample:
>>>>
>>>> interface Multilink2
>>>> ip vrf forwarding VPN1
>>>> ip address x.x.x.x 255.255.255.252
>>>> no cdp enable
>>>> ppp multilink
>>>> ppp multilink group 2
>>>> service-policy output voice
>>>> !
>>>> interface Serial6/0/25:0
>>>> no ip address
>>>> encapsulation ppp
>>>> down-when-looped
>>>> no cdp enable
>>>> ppp multilink
>>>> ppp multilink group 2
>>>> !
>>>> interface Serial6/0/26:0
>>>> no ip address
>>>> encapsulation ppp
>>>> down-when-looped
>>>> no cdp enable
>>>> ppp multilink
>>>> ppp multilink group 2
>>>> !
>>>>
>>>> -Jason
>>>>
>>>>
>>>> Rodney Dunn wrote:
>>>>    
>>>>         
>>>>> The G1's with MLPPP should not be process switching the traffic.
>>>>>
>>>>> What is the config?
>>>>>
>>>>> The EC cards just offload the MLPPP to the new asic on the PA.
>>>>>
>>>>> Rodney
>>>>>
>>>>> On Wed, Mar 25, 2009 at 04:35:50PM -0400, Jason Berenson wrote:
>>>>>
>>>>>      
>>>>>           
>>>>>> Greetings,
>>>>>>
>>>>>> I've got a 7206VXR NPE-G1 with a bunch of DS3 cards in it (PA-MC-T3).  
>>>>>> There's about 25 multilinks with an average of 2 T1s per bundle.  I see 
>>>>>> a lot of process switching on the router and I have a feeling it's 
>>>>>> because we don't have the PA-MC-T3-EC card so the processor has to step 
>>>>>> in for the MLPPP. 
>>>>>>
>>>>>> Is this the case?  If I get some PA-MC-T3-EC cards to swap in, will 
>>>>>> that take a lot of load off the NPE-G1?  Any output needed, please let 
>>>>>> me know.
>>>>>>
>>>>>> Thanks,
>>>>>> Jason
>>>>>> _______________________________________________
>>>>>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>>>>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>>>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>>>>>   
>>>>>>        
>>>>>>             

From tincan at gmail.com  Thu Mar 26 13:10:17 2009
From: tincan at gmail.com (Inca)
Date: Thu, 26 Mar 2009 10:10:17 -0700
Subject: [c-nsp] Free/low-cost traffic generator?
Message-ID: <f8da69c80903261010o76da818cm4d06c548ad3bde39@mail.gmail.com>

Does anyone know of a free (open source or otherwise) or low cost
traffic generator that we can use to stress test multiple gigabit
links simultaneously? Ideally, it would be a software package that one
can install on *nix/OSX/Windows.

Thanks!

From ASikkema at office.unet.nl  Thu Mar 26 12:16:56 2009
From: ASikkema at office.unet.nl (Andreas Sikkema)
Date: Thu, 26 Mar 2009 17:16:56 +0100
Subject: [c-nsp] Sending connected number from AS5350
In-Reply-To: <OFC129ADB2.21329615-ONC1257577.0057C5A2-C1257577.0059CC14@office.unet.nl>
Message-ID: <OF9ACB02E4.2362FDDE-ONC1257585.0059470D-C1257585.00597154@office.unet.nl>

[Reply to my own post]

I've tried more or less everythin but failed, so I asked our supplier to 
just set COLP to temporary restricted.

Thanks for thinking with me.

-- 
Andreas Sikkema

From rich.davies at gmail.com  Thu Mar 26 13:14:02 2009
From: rich.davies at gmail.com (Rich Davies)
Date: Thu, 26 Mar 2009 13:14:02 -0400
Subject: [c-nsp] Tracking bandwidth hogs ... any recommendations ?
In-Reply-To: <20090326121545.GI10080@stlux503.dsto.defence.gov.au>
References: <20090326121545.GI10080@stlux503.dsto.defence.gov.au>
Message-ID: <3e4b8fe10903261014q4f37b5f9ud352bdf67c1ef7e0@mail.gmail.com>

You can turn up a NetFlow server which is at times complex or time
consuming.   A quick/dirty way to find out who is causing your issue may be
just to enable "ip route-cache flow" on a L3 interface that his traffic is
flowing through, then doing "show ip cache flow" - if he's sending out a ton
of packets you may be able to catch it w/ this versus going the NetFlow
route (NetFlow is much much better but unless you have a ton of unix/linux
background getting the netflow collector/analyzer active may be a complex
chore in itself..)

FYI I saw that SolarWinds just put out a free/30 day demo NetFlow
collector/analyzer in the past few months you can try that for a quick Win32
NetFlow software solution to isolate this quick...

http://www.solarwinds.com/products/orion/nta/


Best of luck!


-Rich


On Thu, Mar 26, 2009 at 8:15 AM, Wilkinson, Alex <
alex.wilkinson at dsto.defence.gov.au> wrote:

> Hi all,
>
> I would like to put in place measures to be able to pin point the
> particular
> user(s) who are thrashing out our WAN connection. I am thinking ...
>
>  Mirror all ports (SPAN) to a spare port and use trafshow to pinpoint the
> culprit.
>
> However, i am curious how others deal with this situation ?
>
>  -aW
>
> IMPORTANT: This email remains the property of the Australian Defence
> Organisation and is subject to the jurisdiction of section 70 of the CRIMES
> ACT 1914.  If you have received this email in error, you are requested to
> contact the sender and delete the email.
>
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From charles at thewybles.com  Thu Mar 26 13:20:16 2009
From: charles at thewybles.com (Charles Wyble)
Date: Thu, 26 Mar 2009 10:20:16 -0700
Subject: [c-nsp] Free/low-cost traffic generator?
In-Reply-To: <f8da69c80903261010o76da818cm4d06c548ad3bde39@mail.gmail.com>
References: <f8da69c80903261010o76da818cm4d06c548ad3bde39@mail.gmail.com>
Message-ID: <49CBB950.6000607@thewybles.com>

Conflicker is free and comes with unpatched windows systems. :)

On a more serious note, what sort of traffic/apps are you testing? 
Voice? Web?

Inca wrote:
> Does anyone know of a free (open source or otherwise) or low cost
> traffic generator that we can use to stress test multiple gigabit
> links simultaneously? Ideally, it would be a software package that one
> can install on *nix/OSX/Windows.
> 
> Thanks!

From A.L.M.Buxey at lboro.ac.uk  Thu Mar 26 13:26:53 2009
From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk)
Date: Thu, 26 Mar 2009 17:26:53 +0000
Subject: [c-nsp] Free/low-cost traffic generator?
In-Reply-To: <f8da69c80903261010o76da818cm4d06c548ad3bde39@mail.gmail.com>
References: <f8da69c80903261010o76da818cm4d06c548ad3bde39@mail.gmail.com>
Message-ID: <20090326172653.GD9954@lboro.ac.uk>

Hi,

> Does anyone know of a free (open source or otherwise) or low cost
> traffic generator that we can use to stress test multiple gigabit
> links simultaneously? Ideally, it would be a software package that one
> can install on *nix/OSX/Windows.

netperf? the Linux packet generator?  what purpose? what do you want - 
lots of small SIP-style packets for QoS testing or lots of big FTP
frames that suck up massive TCP windows?

alan

From steve at ibctech.ca  Thu Mar 26 13:27:10 2009
From: steve at ibctech.ca (Steve Bertrand)
Date: Thu, 26 Mar 2009 13:27:10 -0400
Subject: [c-nsp] Free/low-cost traffic generator?
In-Reply-To: <f8da69c80903261010o76da818cm4d06c548ad3bde39@mail.gmail.com>
References: <f8da69c80903261010o76da818cm4d06c548ad3bde39@mail.gmail.com>
Message-ID: <49CBBAEE.5060600@ibctech.ca>

Inca wrote:
> Does anyone know of a free (open source or otherwise) or low cost
> traffic generator that we can use to stress test multiple gigabit
> links simultaneously? Ideally, it would be a software package that one
> can install on *nix/OSX/Windows.

iperf. Single binary application for both *nix and Windows.

Steve

From peter at rathlev.dk  Thu Mar 26 13:37:01 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Thu, 26 Mar 2009 18:37:01 +0100
Subject: [c-nsp] Free/low-cost traffic generator?
In-Reply-To: <f8da69c80903261010o76da818cm4d06c548ad3bde39@mail.gmail.com>
References: <f8da69c80903261010o76da818cm4d06c548ad3bde39@mail.gmail.com>
Message-ID: <1238089021.11929.20.camel@localhost.localdomain>

On Thu, 2009-03-26 at 10:10 -0700, Inca wrote:
> Does anyone know of a free (open source or otherwise) or low cost
> traffic generator that we can use to stress test multiple gigabit
> links simultaneously? Ideally, it would be a software package that one
> can install on *nix/OSX/Windows.

Any non-small collection of Windows machines will do this all by
themselves. :-)

Joke aside, you could use IPerf in UDP mode between to hosts:

server$ iperf -s -u -p 4999
client$ iperf -c <server_ip> -u -b 1000M -p 4999

If you just want to stress a link a don't care about measuring loss etc.
you could use "nc" in UDP mode sourcing from /dev/zero:

client$ dd if=/dev/zero count=666666 bs=1500 | nc -u <server_ip>

You might face some problems trying to make PC hardware deliver multi
gigabit loads, but several PCs in parallel can do it.

Regards,
Peter



From christian at automatick.net  Thu Mar 26 13:39:21 2009
From: christian at automatick.net (Christian Koch)
Date: Thu, 26 Mar 2009 10:39:21 -0700
Subject: [c-nsp] Free/low-cost traffic generator?
In-Reply-To: <49CBBAEE.5060600@ibctech.ca>
References: <f8da69c80903261010o76da818cm4d06c548ad3bde39@mail.gmail.com>
	<49CBBAEE.5060600@ibctech.ca>
Message-ID: <c4d480f60903261039r546a2797xfa0697e71053adfd@mail.gmail.com>

d-itg
http://www.grid.unina.it/software/ITG/link.php
pageant ios

On Thu, Mar 26, 2009 at 10:27 AM, Steve Bertrand <steve at ibctech.ca> wrote:

> Inca wrote:
> > Does anyone know of a free (open source or otherwise) or low cost
> > traffic generator that we can use to stress test multiple gigabit
> > links simultaneously? Ideally, it would be a software package that one
> > can install on *nix/OSX/Windows.
>
> iperf. Single binary application for both *nix and Windows.
>
> Steve
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From networkstuff.training at gmail.com  Thu Mar 26 14:10:46 2009
From: networkstuff.training at gmail.com (Swati Sharma)
Date: Thu, 26 Mar 2009 23:40:46 +0530
Subject: [c-nsp] mls cef max route
In-Reply-To: <1238057893.3754.2.camel@localhost.localdomain>
References: <8a93d4b30903252206o593769aan82e16eb82e1fa93d@mail.gmail.com>
	<1238057893.3754.2.camel@localhost.localdomain>
Message-ID: <8a93d4b30903261110g353c0840r42453ac030c5fbde@mail.gmail.com>

Hi Peter,

most of the resources are available,,,,

6500.LAB#sh platform hardware capacity pfc
L2 Forwarding Resources
           MAC Table usage:   Module  Collisions  Total       Used
%Used
                              5                0  65536         24
1%
             VPN CAM usage:                       Total       Used
%Used
                                                    512          0
0%
L3 Forwarding Resources
             FIB TCAM usage:                     Total        Used
%Used
                  72 bits (IPv4, MPLS, EoM)     524288          75
1%
                 144 bits (IP mcast, IPv6)      262144           5
1%
                     detail:      Protocol                    Used
%Used
                                  IPv4                          43
1%
                                  MPLS                          32
1%
                                  EoM                            0
0%
                                  IPv6                           2
1%
                                  IPv4 mcast                     3
1%
                                  IPv6 mcast                     0
0%
            Adjacency usage:                     Total        Used
%Used
                                               1048576         239
1%
     Forwarding engine load:
                     Module       pps   peak-pps
peak-time
                     5             17        589  03:42:33 UTC Wed Mar 18
2009
Netflow Resources
          TCAM utilization:       Module       Created      Failed
%Used
                                  5                  3           0
0%
          ICAM utilization:       Module       Created      Failed
%Used
                                  5                  0           0
0%
                 Flowmasks:   Mask#   Type        Features
                        IPv4:     0   reserved    none
                        IPv4:     1   unused      none
                        IPv4:     2   unused      none
                        IPv4:     3   reserved    none
                        IPv6:     0   reserved    none
                        IPv6:     1   unused      none
                        IPv6:     2   unused      none
                        IPv6:     3   reserved    none
CPU Rate Limiters Resources
             Rate limiters:       Total         Used      Reserved
%Used
                    Layer 3           9            4             1
44%
                    Layer 2           4            2             2
50%
ACL/QoS TCAM Resources
  Key: ACLent - ACL TCAM entries, ACLmsk - ACL TCAM masks, AND - ANDOR,
       QoSent - QoS TCAM entries, QOSmsk - QoS TCAM masks, OR - ORAND,
       Lbl-in - ingress label, Lbl-eg - egress label, LOUsrc - LOU source,
       LOUdst - LOU destination, ADJ - ACL adjacency
  Module ACLent ACLmsk QoSent QoSmsk Lbl-in Lbl-eg LOUsrc LOUdst  AND  OR
ADJ
  5          1%     1%     1%     1%     1%     1%     0%     0%   0%  0%
1%
6500.LAB#
6500.LAB#
6500.LAB#sh tcam counts
           Used        Free        Percent Used       Reserved
           ----        ----        ------------       --------
 Labels:(in)  6        4090            0
 Labels:(eg)  2        4094            0
ACL_TCAM
--------
  Masks:     11        4085            0                    72
Entries:     60       32708            0                   576
QOS_TCAM
--------
  Masks:      7        4089            0                    18
Entries:     32       32736            0                   144
    LOU:      0         128            0
  ANDOR:      0          16            0
  ORAND:      0          16            0
    ADJ:      3        2045            0
6500.LAB#
Regards,

On Thu, Mar 26, 2009 at 2:28 PM, Peter Rathlev <peter at rathlev.dk> wrote:

> On Thu, 2009-03-26 at 10:36 +0530, Swati Sharma wrote:
> > Though I have just few routes still I am getting
> >
> > Mar 26 04:49:06.406 UTC: %MLSCEF-SP-4-FIB_EXCEPTION: FIB TCAM
> > exception for IPv4 unicast, Some routes will be software switched.
> > Use "mls cef maximum-routes" to modify FIB TCAM  partition.
> >
> > 6500.LAB#sh mls cef maximum-routes
> > FIB TCAM maximum routes :
> > =======================
> > Current :-
> > -------
> >  IPv4 + MPLS         - 512k (default)
> >  IPv6 + IP Multicast - 256k (default)
> ...
> > any idea !!!
>
> What does "show tcam counts" and "show platform hardware capacity pfc"
> say?
>
> Regards,
> Peter
>
>
>

From tincan at gmail.com  Thu Mar 26 14:11:07 2009
From: tincan at gmail.com (Inca)
Date: Thu, 26 Mar 2009 11:11:07 -0700
Subject: [c-nsp] Free/low-cost traffic generator?
In-Reply-To: <c4d480f60903261039r546a2797xfa0697e71053adfd@mail.gmail.com>
References: <f8da69c80903261010o76da818cm4d06c548ad3bde39@mail.gmail.com>
	<49CBBAEE.5060600@ibctech.ca>
	<c4d480f60903261039r546a2797xfa0697e71053adfd@mail.gmail.com>
Message-ID: <f8da69c80903261111l280abcaeke2ecd0129a6f0f01@mail.gmail.com>

Thanks for all of the responses. Some of them like interesting.

Ideally, we would like send out multiple streams of traffic (both
small and large packets) simultaneously through multiple gigabit
interfaces. While QoS testing maybe of interest later on, we more
mainly focus on seeing if some network gears can handle the load.

From networkstuff.training at gmail.com  Thu Mar 26 14:12:44 2009
From: networkstuff.training at gmail.com (Swati Sharma)
Date: Thu, 26 Mar 2009 23:42:44 +0530
Subject: [c-nsp] mls cef max route
In-Reply-To: <20090326112122.GN290@greenie.muc.de>
References: <8a93d4b30903252206o593769aan82e16eb82e1fa93d@mail.gmail.com>
	<20090326112122.GN290@greenie.muc.de>
Message-ID: <8a93d4b30903261112n3900f48exa79780c1c94f8dc8@mail.gmail.com>

Hi Gert,

6500.LAB#sh mls cef su
6500.LAB#sh mls cef summary
Total routes:                     80
    IPv4 unicast routes:          43
    IPv4 Multicast routes:        3
    MPLS routes:                  32
    IPv6 unicast routes:          2
    IPv6 multicast routes:        0
    EoM routes:                   0
6500.LAB#
Regards,

On Thu, Mar 26, 2009 at 4:51 PM, Gert Doering <gert at greenie.muc.de> wrote:

> Hi,
>
> On Thu, Mar 26, 2009 at 10:36:20AM +0530, Swati Sharma wrote:
> > 6500.LAB#sh mls cef maximum-routes
>
> Try: "sh mls cef su"
>
> to see what IOS is thinking about TCAM usage.
>
> 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 gtb at slac.stanford.edu  Thu Mar 26 13:29:42 2009
From: gtb at slac.stanford.edu (Buhrmaster, Gary)
Date: Thu, 26 Mar 2009 10:29:42 -0700
Subject: [c-nsp] MLPPP
In-Reply-To: <49CBB54A.6010406@pins.net>
References: <49CA95A6.3030107@pins.net><20090325205918.GG26674@rtp-cse-489.cisco.com><49CA9C07.7030007@pins.net><20090326142011.GS27263@rtp-cse-489.cisco.com><49CB9170.40407@pins.net><20090326165313.GD27263@rtp-cse-489.cisco.com>
	<49CBB54A.6010406@pins.net>
Message-ID: <D0D0330CBD07114D85B70B784E80C2F2022FD10F@exch-mail2.win.slac.stanford.edu>


> Rodney,
> 
> With the PA-MC-T3-EC, any idea how much would be offloaded to 
> the PA?  

As always, your mileage will vary, but Cisco has some
examples and estimates available at:

http://www.cisco.com/en/US/prod/collateral/modules/ps2033/prod_white_paper0900aecd8056d3cb.html 

(Note you need the appropriate IOS level to gain the benefits).

From jasongurtz at npumail.com  Thu Mar 26 14:53:01 2009
From: jasongurtz at npumail.com (Jason Gurtz)
Date: Thu, 26 Mar 2009 14:53:01 -0400
Subject: [c-nsp] Stratum 0 PPS Hardware clock compatibility
Message-ID: <A92EAF652EC423438D55C14C60771C870147C60A@exchgsrv.nputilities.local>

I have found a lot of documentation online that states the 7200 is the
only Cisco device that supports a PPS hardware clock via the Aux port.  I
see recommendations for Trimble Acutime 2000 since replaced by mfr. and
other solutions but these documents are a few years old.  Has this feature
been added to other platforms such as the 6500 series?

~JasonG

From sfischer1967 at gmail.com  Thu Mar 26 16:06:17 2009
From: sfischer1967 at gmail.com (Steven Fischer)
Date: Thu, 26 Mar 2009 16:06:17 -0400
Subject: [c-nsp] spanning-tree bpduguard vs. bpdufilter
Message-ID: <500ffb690903261306ufc2f177q21f0e328b1b902bf@mail.gmail.com>

When deploying our new network a few months ago, we set up Cisco Works to
manage it.  Cisco Works detected and flagged the lack of the following
commands as configuration errors:

spanning-tree bpduguard enable
spanning-tree bpdufilter enable

Thinking this recommendation came from Cisco Works, it follows that this
would make sense to do, right?  As some more information on the effect of
these commands has come to light, this is really not a good idea.  The
commands almost seem to serve opposite purposes - one shuts the port down if
a bpdu is detected, the other obstensibly ignores bpdus.  Which one of these
commands takes precendence?

>From what I understand, spanning-tree portfast will in effect serve the same
purpose as spanning-tree bpdufilter enable IF the port is an active access
port...is that correct?

Thanks

Steve

-- 
To him who is able to keep you from falling and to present you before his
glorious presence without fault and with great joy

From A.L.M.Buxey at lboro.ac.uk  Thu Mar 26 16:29:17 2009
From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk)
Date: Thu, 26 Mar 2009 20:29:17 +0000
Subject: [c-nsp] spanning-tree bpduguard vs. bpdufilter
In-Reply-To: <500ffb690903261306ufc2f177q21f0e328b1b902bf@mail.gmail.com>
References: <500ffb690903261306ufc2f177q21f0e328b1b902bf@mail.gmail.com>
Message-ID: <20090326202917.GB10446@lboro.ac.uk>

Hi,

> spanning-tree bpduguard enable
> spanning-tree bpdufilter enable
> 
> Thinking this recommendation came from Cisco Works, it follows that this
> would make sense to do, right?  As some more information on the effect of
> these commands has come to light, this is really not a good idea.  The
> commands almost seem to serve opposite purposes - one shuts the port down if
> a bpdu is detected, the other obstensibly ignores bpdus.  Which one of these
> commands takes precendence?
> 
> >From what I understand, spanning-tree portfast will in effect serve the same
> purpose as spanning-tree bpdufilter enable IF the port is an active access
> port...is that correct?

no.  spanning-tree portfast wont listen/discover/span. if you want it do 
do this, you need to have the global spanning-tree command

spanning-tree portfast bpdufilter default

this will filter on portfast (what you alluded to).

however, if you have a switch in portfast mode then it should never receive
a bpdu from that port - if it does then something aint right on the network.
so perhaps it is worth having protection - which is what bpduguard does.

incidentally, it appears that some of this behvaiour changes from IOS to
IOS - we had many links with spanning-tree portfast trunk enabled...
and they got clobbered by bpduguard seeing bpdu coming down those links
from the other end switch - which we knew about....caveat empor etc

alan

From paul.cosgrove at heanet.ie  Thu Mar 26 16:36:36 2009
From: paul.cosgrove at heanet.ie (Paul Cosgrove)
Date: Thu, 26 Mar 2009 20:36:36 +0000
Subject: [c-nsp] BGP session resets if NLRI exchanged
In-Reply-To: <F4469404D9886545AD22355D96D8620F07369C35@xmb-rtp-20a.amer.cisco.com>
References: <49CA53B9.5080404@heanet.ie>
	<F4469404D9886545AD22355D96D8620F07369C35@xmb-rtp-20a.amer.cisco.com>
Message-ID: <49CBE754.40702@heanet.ie>

Many thanks Harold! that does indeed look like the issue.  We are using 
32byte ASNs, but since the problem was occuring even after we filtered 
that advertisement we had begun looking elsewhere.

Paul.


Harold Ritter (hritter) wrote:
> Paul,
>
> You might be running into CSCsl72955. If so, you could try the
> workaround suggested by the following link or upgrade the code.
>
> http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method
> =fetchBugDetails&bugId=CSCsl72955 
>
> Regards
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Paul Cosgrove
> Sent: Wednesday, March 25, 2009 11:55 AM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] BGP session resets if NLRI exchanged
>
> We are attempting to establish a new BGP session between one of our
> CRS-1 routers, and a Redback SE800 router owned by another provider.  Am
> not familiar with Redbacks myself and we have not peered with any before
> (as far as we know anyway).  The BGP session only remains up if no NLRI
> is exchanged.  If the other provider sends any prefixes to us we reply
> with a "invalid length for attribute" notification; if we send any
> prefixes to them they reply with  "invalid or corrupt AS path". 
>
> The other provider uses VPNv4 within their network, though I understand
> that it is not configured on this peering.  I'm wondering whether these
> errors could result if their router expects a RD (and sends one) on the
> advertisements, perhaps due to a software bug or typo in the config. 
>
> Perhaps someone has seen this problem before?
>
> Paul.
>
>
>
>
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>   


From AMcglinchey at wiseman-dairies.co.uk  Thu Mar 26 16:39:50 2009
From: AMcglinchey at wiseman-dairies.co.uk (Alun Mcglinchey)
Date: Thu, 26 Mar 2009 20:39:50 +0000
Subject: [c-nsp] Alun Mcglinchey is out of the office.
Message-ID: <OF04691DBE.23DE67F6-ON80257585.007182BC-80257585.007182BC@wiseman-dairies.co.uk>


I will be out of the office starting  26/03/2009 and will not return until
01/04/2009.

I will respond to your message when I return, if your query is urgent
please contact the IT servicedesk team on 6634 or email Cameron McKinnon
(cmckinnon at wiseman-dairies.co.uk)



*********************************************************************************
Disclaimer: This electronic mail, together with any attachments, is for the exclusive and confidential use of the recipient addressee. Any other distribution, use or reproduction without our prior consent is unauthorised and strictly prohibited. If you have received this message in error, please delete it immediately and contact the sender directly or the Robert Wiseman & Sons Ltd IT Helpdesk on +44 (0)1355 270634. Any views or opinions expressed in this message are those of the author and do not necessarily represent those of Robert Wiseman & Sons Ltd or of any of its associated companies. No reliance may be placed on this message without written confirmation from an authorised representative of the company.

Robert Wiseman & Sons Limited reserves the right to monitor all e-mail communications through its network.

This message has been checked for viruses but the recipient is strongly advised to re-scan the message before opening any attachments or attached executable files.

ROBERT WISEMAN & SONS LIMITED
Registered Number: 87376 Scotland
Registered Office: 159 Glasgow Road,
East Kilbride, Glasgow, G74 4PA

********************************************************************************

From sfischer1967 at gmail.com  Thu Mar 26 16:51:41 2009
From: sfischer1967 at gmail.com (Steven Fischer)
Date: Thu, 26 Mar 2009 16:51:41 -0400
Subject: [c-nsp] spanning-tree bpduguard vs. bpdufilter
In-Reply-To: <20090326202917.GB10446@lboro.ac.uk>
References: <500ffb690903261306ufc2f177q21f0e328b1b902bf@mail.gmail.com>
	<20090326202917.GB10446@lboro.ac.uk>
Message-ID: <500ffb690903261351g1ea23cbw82a33c820827c651@mail.gmail.com>

On Thu, Mar 26, 2009 at 4:29 PM, <A.L.M.Buxey at lboro.ac.uk> wrote:

> Hi,
>
> > spanning-tree bpduguard enable
> > spanning-tree bpdufilter enable
> >
> > Thinking this recommendation came from Cisco Works, it follows that this
> > would make sense to do, right?  As some more information on the effect of
> > these commands has come to light, this is really not a good idea.  The
> > commands almost seem to serve opposite purposes - one shuts the port down
> if
> > a bpdu is detected, the other obstensibly ignores bpdus.  Which one of
> these
> > commands takes precendence?
> >
> > >From what I understand, spanning-tree portfast will in effect serve the
> same
> > purpose as spanning-tree bpdufilter enable IF the port is an active
> access
> > port...is that correct?
>
> no.  spanning-tree portfast wont listen/discover/span. if you want it do
> do this, you need to have the global spanning-tree command


Right, it goes immediately from not active into forwarding state.

>
>
> spanning-tree portfast bpdufilter default
>
> this will filter on portfast (what you alluded to).


So, I need to add this "spanning-tree portfast bpdufilter default" if I want
bpdufilter as the default condition of interfaces configured with
portfast...correct?

The question is, if I'm using bpduguard on an interface, is there any
additional protection afforded by bpdufilter?

>
>
> however, if you have a switch in portfast mode then it should never receive
> a bpdu from that port - if it does then something aint right on the
> network.
> so perhaps it is worth having protection - which is what bpduguard does.
>
> incidentally, it appears that some of this behvaiour changes from IOS to
> IOS - we had many links with spanning-tree portfast trunk enabled...
> and they got clobbered by bpduguard seeing bpdu coming down those links
> from the other end switch - which we knew about....caveat empor etc
>
> alan


I prefer the "protection" of bpduguard over bpdufilter.  Sure, it's more
drastic, but its more idiot proof ...ok...idiot-resistent as well.

Thanks....



-- 
To him who is able to keep you from falling and to present you before his
glorious presence without fault and with great joy

From dwbielawa at liberty.edu  Thu Mar 26 18:10:34 2009
From: dwbielawa at liberty.edu (Bielawa, Daniel W. (NS))
Date: Thu, 26 Mar 2009 18:10:34 -0400
Subject: [c-nsp] spanning-tree bpduguard vs. bpdufilter
In-Reply-To: <500ffb690903261306ufc2f177q21f0e328b1b902bf@mail.gmail.com>
References: <500ffb690903261306ufc2f177q21f0e328b1b902bf@mail.gmail.com>
Message-ID: <83FBF523E7955843A01EDB632E39CDC4E8960835@LUEMS03VS.University.liberty.edu>

Hello

	From experience, I can tell you that the bpdufilter command will override the bpduguard command. Bpdufilter effectively turns off spanning tree on a port, but portfast keeps spanning tree enabled on a port, With bpdufilter enabled there is nothing to protect you from a loop.

Thank You

Daniel Bielawa
Network Engineer
Liberty University Information Services

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Steven Fischer
Sent: Thursday, March 26, 2009 4:06 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] spanning-tree bpduguard vs. bpdufilter

When deploying our new network a few months ago, we set up Cisco Works to
manage it.  Cisco Works detected and flagged the lack of the following
commands as configuration errors:

spanning-tree bpduguard enable
spanning-tree bpdufilter enable

Thinking this recommendation came from Cisco Works, it follows that this
would make sense to do, right?  As some more information on the effect of
these commands has come to light, this is really not a good idea.  The
commands almost seem to serve opposite purposes - one shuts the port down if
a bpdu is detected, the other obstensibly ignores bpdus.  Which one of these
commands takes precendence?

>From what I understand, spanning-tree portfast will in effect serve the same
purpose as spanning-tree bpdufilter enable IF the port is an active access
port...is that correct?

Thanks

Steve

-- 
To him who is able to keep you from falling and to present you before his
glorious presence without fault and with great joy
_______________________________________________
cisco-nsp mailing list  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 Mar 26 19:26:16 2009
From: brad.henshaw at qcn.com.au (Brad Henshaw)
Date: Fri, 27 Mar 2009 09:26:16 +1000
Subject: [c-nsp] Cisco 887 CPE and 890series?!?!?!?!?!
Message-ID: <8B25B862BC09784B9B74FB950D4F64D40F825C@qcnapp01.corp.qcn>

Skeeve Stevens wrote:

> Seriously!!!! This is the biggest tease I've ever had!

Interesting sounding box. Glad to see the lack of those awful shared
console/aux ports.

GigE port "to support the high-bandwidth demands of Metro Ethernet
deployments"
on a low end software forwarding box, though? That's a bit of a joke
isn't it?
(unless I missed some amazing pps specification in the data sheet)

Regards,
Brad

From andy.saykao at staff.netspace.net.au  Thu Mar 26 22:34:41 2009
From: andy.saykao at staff.netspace.net.au (Andy Saykao)
Date: Fri, 27 Mar 2009 13:34:41 +1100
Subject: [c-nsp] Question about CBWFQ and PING times
Message-ID: <56F211C5E3F24F47B103EA1B253822BE03654CC0@vic-cr-ex1.staff.netspace.net.au>

Hi Peter,

Yes, it's a SPA in the SIP-400 that we add the service-policy to. DTS
and hierarchical qos should be supported as per the data sheet, and I'll
bring it up with our Cisco rep to see what the deal is.

> Consider the "bandwidth" parameter strictly informational.

How misleading is that then. When you issue the "show policy-map"
command, it calculates the bandwidth % using what's set with the
bandwidth interface command. I'll make a note to disregard this piece of
cosmetic from cisco when using the "show policy-map" command.

Just a few things with the "show policy-map" command. 

1/ There's an "offered rate" for each class - is this the amount of
bandwidth the router is currently reserving for each class?

POP2#sh policy-map int g4/0/2

 GigabitEthernet4/0/2

  Service-policy output: POP2-POP1-QOS-POLICY

  Counters last updated 00:00:00 ago

    Class-map: POP2-POP1-PRIORITY-CLASS (match-all)
      299895137 packets, 119941773853 bytes
      30 second offered rate 1887000 bps, drop rate 0 bps
      Match: access-group name POP2-POP1-PRIORITY-ACL
      Queueing
      queue limit 2500 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 299892091/119940222481

      bandwidth 5% (10000 kbps)

    Class-map: class-default (match-any)
      19483508661 packets, 15273909817898 bytes
      30 second offered rate 115958000 bps, drop rate 0 bps
      Match: any

POP2#sh access-lists POP2-POP1-PRIORITY-ACL
Extended IP access list POP2-POP1-PRIORITY-ACL
    20 permit ip 210.15.254.0 0.0.0.255 any
    30 permit ip 203.10.110.0 0.0.0.255 any
    40 permit ip 210.15.210.0 0.0.0.255 any
    50 permit ip 203.17.103.0 0.0.0.255 any
    60 permit icmp any any

2/ One odd thing I've found is that when I permit additional icmp's to
the ACL, the "offered rate" rapidly decreases until the "offered rate"
is ZERO. 

    70 permit icmp any any echo-reply
    80 permit icmp any any traceroute

POP2#sh policy-map int g4/0/2

 GigabitEthernet4/0/2

  Service-policy output: POP2-POP1-QOS-POLICY

  Counters last updated 00:00:00 ago

    Class-map: POP2-POP1-PRIORITY-CLASS (match-all)
      300148641 packets, 120077235727 bytes
      30 second offered rate 0 bps, drop rate 0 bps
      Match: access-group name POP2-POP1-PRIORITY-ACL
      Queueing
      queue limit 2500 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 300150499/120077414678

      bandwidth 5% (10000 kbps)

    Class-map: class-default (match-any)
      19493929309 packets, 15281493202187 bytes
      30 second offered rate 0 bps, drop rate 0 bps
      Match: any

The throughput on the interface is still as expected.

POP2#sh int g4/0/2
  30 second input rate 50875000 bits/sec, 18880 packets/sec
  30 second output rate 117992000 bits/sec, 20690 packets/sec

Why does adding the extra icmp lines in the ACL cause the "offered rate"
to be zero in both classes???

Cheers.

Andy

This email and any files transmitted with it are confidential and intended
 solely for the use of the individual or entity to whom they are addressed. 
Please notify the sender immediately by email if you have received this 
email by mistake and delete this email from your system. Please note that
 any views or opinions presented in this email are solely those of the
 author and do not necessarily represent those of the organisation. 
Finally, the recipient should check this email and any attachments for 
the presence of viruses. The organisation accepts no liability for any 
damage caused by any virus transmitted by this email.


From networkstuff.training at gmail.com  Fri Mar 27 00:00:52 2009
From: networkstuff.training at gmail.com (Swati Sharma)
Date: Fri, 27 Mar 2009 09:30:52 +0530
Subject: [c-nsp] QoS on Tunnel Interfaces w/ DSL
Message-ID: <8a93d4b30903262100l5f5f1f3cm9057ae84cf923d86@mail.gmail.com>

Hi,

This depends whether you want to do QoS based on tos bit or source /
destination ip... if it is based on tos bit, u do not need to do anything
and if it is based on S/S ip
use QoS-pre classify command..

Regards,





Message: 2
Date: Wed, 25 Mar 2009 08:11:20 -0400
From: "Jeff Cartier" <jcartier at acs.on.ca>
Subject: [c-nsp] QoS on Tunnel Interfaces w/ DSL
To: <cisco-nsp at puck.nether.net>
Message-ID: <BCD3E762F1767C42A5226BBACDE49BFBCE7ACD at loki.acs.local>
Content-Type: text/plain;       charset="us-ascii"
Greetings All,

I was wondering if anyone had any examples of how to impose QoS on a
Site that would be doing IPSec VPN tunnels to another site via a
standard DSL feed.

I'm curious to see if best-practice is to place the policy-shaping on
the interface tunnel and/or the Internet interface.

Thanks!

From fwissue at gmail.com  Fri Mar 27 00:20:29 2009
From: fwissue at gmail.com (Michael Lee)
Date: Thu, 26 Mar 2009 21:20:29 -0700
Subject: [c-nsp] qos on standard ethernet port for me3750
Message-ID: <709a72990903262120g6c87189bn750195f0ff4f79d0@mail.gmail.com>

Hello:

 Did anyone have experiences with QoS on ME3750 standard port (not ES port),
it looks like that it does not support CBWFQ,
how about SRR and priority queueing, is priority queue on the first queue?

thx,

~mike

From brad.henshaw at qcn.com.au  Fri Mar 27 00:56:05 2009
From: brad.henshaw at qcn.com.au (Brad Henshaw)
Date: Fri, 27 Mar 2009 14:56:05 +1000
Subject: [c-nsp] qos on standard ethernet port for me3750
Message-ID: <8B25B862BC09784B9B74FB950D4F64D40F8260@qcnapp01.corp.qcn>

Michael Lee wrote: 

> Did anyone have experiences with QoS on ME3750 standard port
> (not ES port), it looks like that it does not support CBWFQ,
> how about SRR and priority queueing, is priority queue on the
> first queue?

Yes it supports SRR (sharing and shaping) and priority queueing.

And yes, the priority queue is queue 1 if enabled on the port
(priority-queue out)

Regards,
Brad

From s.ganschow at buelow-masiak.de  Fri Mar 27 03:47:53 2009
From: s.ganschow at buelow-masiak.de (Sebastian Ganschow)
Date: Fri, 27 Mar 2009 08:47:53 +0100
Subject: [c-nsp] Lightstream freeze
Message-ID: <49CC84A9.2020308@buelow-masiak.de>

Hi,

as far as i know and cisco says, a lightstream should be hot-swap capable.

Does anyone know which reason could be, that a lightstream freezes, if you
pull a WAI-E3-4BNC Card?

Sebastian

From koug at intracom.gr  Fri Mar 27 05:05:32 2009
From: koug at intracom.gr (John Kougoulos)
Date: Fri, 27 Mar 2009 11:05:32 +0200 (GTB Standard Time)
Subject: [c-nsp] Lightstream freeze
In-Reply-To: <49CC84A9.2020308@buelow-masiak.de>
References: <49CC84A9.2020308@buelow-masiak.de>
Message-ID: <alpine.WNT.2.00.0903271054020.2204@pckoug1.intranet.gr>

Hi,

do you run 12.0 mainline?

perhaps you are affected by: CSCdw36579

Regards,
John

On Fri, 27 Mar 2009, Sebastian Ganschow wrote:

> Hi,
>
> as far as i know and cisco says, a lightstream should be hot-swap capable.
>
> Does anyone know which reason could be, that a lightstream freezes, if you
> pull a WAI-E3-4BNC Card?
>
> Sebastian
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From dloughlin at otc.fsu.edu  Fri Mar 27 10:51:43 2009
From: dloughlin at otc.fsu.edu (Loughlin, Daniel J.)
Date: Fri, 27 Mar 2009 10:51:43 -0400
Subject: [c-nsp] Cisco and Foundry and MST
In-Reply-To: <B5F945E48C137C49A98BC86DD35939C012B9ADA217@nbg01-exch-01.entlstaff.domain.lumison.net>
References: <a2b352c40903260948o453212br559018635629ae41@mail.gmail.com>
	<B5F945E48C137C49A98BC86DD35939C012B9ADA217@nbg01-exch-01.entlstaff.domain.lumison.net>
Message-ID: <0B5DA805D198954F8E6160D2AB3B43A5800FF5@fsu-exch-11.fsu.edu>

I would lean towards the MIST (802.1s) route, as well. However, you
might be interested to know that Foundry will also speak PVST+ with your
ciscos. If you want to also do rapid spanning tree along with PVST+
there is a gotcha... Foundry has rstp and 802.1w. Use the 802.1w
commands! Ignore the rstp stuff. It's non-standard stuff that happened,
I believe, before 802.1w was standardized. So be aware! Another thing
you'll get mad at is the show commands :). After enabling 802.1w on your
vlans, "show span" won't give you the information you need. You'll need
to type "show 802.1w".


Foundry-switch(config-if-e1000-1)#pvst-mod? 
  pvst-mode                     Interoperate with Cisco PVST+ for
                                multi-spanning tree

You'll put spanning-tree 802-1w under each vlan... for example...

vlan 1 name DEFAULT-VLAN by port
 spanning-tree 802-1w


I hope I didn't leave anything out... 

-Danny

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Ian MacKinnon
Sent: Thursday, March 26, 2009 1:00 PM
To: Nick Griffin; cisco-nsp
Subject: Re: [c-nsp] Cisco and Foundry and MST

Hi Nick,
I did something similar a while ago, so here are some thoughts.

Plan for downtime :-(
Don't expect it to be totally transparent, so make the changes in a
maintenance window.

I think SXH and later do a real standards compliant version of MSTP with
interop with standard STP.
Are you planning to use multiple instances, or just use one?
Make sure that your instance 0 (ie the STP) is the same on both sides,
and if you are only using one instance ensure it is 0 on both sides.

Be aware of the differences between Cisco RSTP and A.N.Other Spanning
tree in rapid mode.

I realise I am teaching you to suck eggs here, but plan what devices are
going to be the root and backup, and manually configure them.

Hope this is useful.
Ian


> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> bounces at puck.nether.net] On Behalf Of Nick Griffin
> Sent: 26 March 2009 16:48
> To: cisco-nsp
> Subject: [c-nsp] Cisco and Foundry and MST
>
> I'm working with a client that is migrating to Foundry from Cisco and
> they
> need to have interoperability on STP between the two vendors. I
usually
> try
> to do MST when I can, usually in a cisco environment, so I'm pretty
> comfortable with it. Does anyone have any experience getting the 2 to
> play
> together? It's a critical environment, so minimal disruption is
> required.
> There is a core 6500 that can connects to a number of Cisco access
> switches,
> the Cisco 6500 also connects into the Foundry FESX switches. I wanted
> to go
> ahead and enable MST on the core 6500, and then working my way to the
> access
> layer (assuming the interoperability works just fine), and then the
> Foundry
> boxes. Just looking for any pro-pointers here to try to avoid baptism
> by
> fire! Thanks in advance.
>
> Nick Griffin
> Systems Consultant, CCIE R&S 17381
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

--

This email 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 and nPlusOne.
Finally, the recipient should check this email and any attachments for
the
presence of viruses.  Lumison and nPlusOne accept no liability for any
damage caused by any virus transmitted by this email.
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From lowen at pari.edu  Fri Mar 27 13:15:15 2009
From: lowen at pari.edu (Lamar Owen)
Date: Fri, 27 Mar 2009 13:15:15 -0400
Subject: [c-nsp] Lightstream freeze
In-Reply-To: <49CC84A9.2020308@buelow-masiak.de>
References: <49CC84A9.2020308@buelow-masiak.de>
Message-ID: <200903271315.15635.lowen@pari.edu>

On Friday 27 March 2009 03:47:53 Sebastian Ganschow wrote:
> Hi,
>
> as far as i know and cisco says, a lightstream should be hot-swap capable.
>
> Does anyone know which reason could be, that a lightstream freezes, if you
> pull a WAI-E3-4BNC Card?

Are you pulling the PAM only, or the whole CAM?

What IOS release are you on?  This is an LS1010, I assume.  ASP-B or ASP-C (or 
8515MSRP)?

Those boxes are quite old, now, and you may be tickling an old hardware or IOS 
bug.  If you have support on it, it's EOL Last Date of Support isn't until 
April 29, 2011.  Can't get a new contract now, but you can renew an existing 
one until April 2010.

I had an 8510MSR 'section' in an old Catalyst 5500 I retired a few months ago, 
and never had issues with OIR on IOS 12.1(26)E3 (itself a pretty old, but 
still supported, IOS train).  I only used OC3 and OC12 PAMs in it, so you 
might be tickling a bug in your particular PAM.

There is a 12.0 mainline caveat for the LS1010, CSCdw36579, that relates to 
this issue.  The description is:

Symptom: OIR of port adapters does not work as expected using 12.0 mainline 
software on the LightStream 1010.

Workaround: Use the latest W5 image or do not OIR the port adapters 
individually. OIR the carrier module, remove the port adapter and then 
reinstall the carrier module. 
( from 
http://www.cisco.com/en/US/products/hw/switches/ps718/prod_release_note09186a008049913f.html#wp36005 
)

So you want to be on the latest 12.0W5 train image, or upgrade to the 12.1E 
train.
-- 
Lamar Owen
Chief Information Officer
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
http://www.pari.edu

From everton at lab.ipaccess.diveo.net.br  Fri Mar 27 13:17:40 2009
From: everton at lab.ipaccess.diveo.net.br (Everton da Silva Marques)
Date: Fri, 27 Mar 2009 14:17:40 -0300
Subject: [c-nsp] Free/low-cost traffic generator?
In-Reply-To: <f8da69c80903261010o76da818cm4d06c548ad3bde39@mail.gmail.com>
References: <f8da69c80903261010o76da818cm4d06c548ad3bde39@mail.gmail.com>
Message-ID: <20090327171740.GA28944@diveo.net.br>

On Thu, Mar 26, 2009 at 10:10:17AM -0700, Inca wrote:
> Does anyone know of a free (open source or otherwise) or low cost
> traffic generator that we can use to stress test multiple gigabit
> links simultaneously? Ideally, it would be a software package that one
> can install on *nix/OSX/Windows.

Benchmarking network performance with Network Pipemeter, LMbench, and nuttcp
http://linux.com/feature/144532

Everton

From mduksa at gmail.com  Fri Mar 27 14:26:02 2009
From: mduksa at gmail.com (Marlon Duksa)
Date: Fri, 27 Mar 2009 11:26:02 -0700
Subject: [c-nsp] Y.1731 frame loss measurement on Cisco
Message-ID: <a89d89ac0903271126p3ae8fa30t78bd3a20f42bc0d9@mail.gmail.com>

Hi  - does anyone know if Cisco 7600/GSR/CRS  platforms support Y.1731
standard, I'm particularly interested in frame loss measurement?Thanks,
Marlon

From juxiangt at yahoo.com  Fri Mar 27 14:05:12 2009
From: juxiangt at yahoo.com (judy teng)
Date: Fri, 27 Mar 2009 11:05:12 -0700 (PDT)
Subject: [c-nsp] NSF timer
Message-ID: <92220.3718.qm@web90604.mail.mud.yahoo.com>


Hello,

I would like to change NSF timer on Cisco 7600 router and could not find any command on Cisco website.? Does anybody know the command to verify and change the NSF timer? I was told the default timer is 20 sec.? 

Thanks,

Judy


      

From JShao at dtcc.com  Fri Mar 27 16:02:13 2009
From: JShao at dtcc.com (Jay Shao)
Date: Fri, 27 Mar 2009 16:02:13 -0400
Subject: [c-nsp] Jay Shao is out of the office.
Message-ID: <OF057C5A03.840AC586-ON85257586.006E10F8-85257586.006E10F8@dtcc.com>


I will be out of the office starting  03/27/2009 and will not return until
03/30/2009.

I will respond to your message when I return. Please contact with
NETTCP at DTCC.COM for any production issues

-----------------------------------------
________________________________________________________
DTCC DISCLAIMER: 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 us immediately and delete the email and any
attachments from your system. The recipient should check this email
and any attachments for the presence of viruses.  The company
accepts no liability for any damage caused by any virus transmitted
by this email.

From s.ganschow at buelow-masiak.de  Fri Mar 27 18:50:40 2009
From: s.ganschow at buelow-masiak.de (Sebastian Ganschow)
Date: Fri, 27 Mar 2009 23:50:40 +0100
Subject: [c-nsp] Lightstream freeze
In-Reply-To: <200903271315.15635.lowen@pari.edu>
References: <49CC84A9.2020308@buelow-masiak.de>
	<200903271315.15635.lowen@pari.edu>
Message-ID: <49CD5840.9090304@buelow-masiak.de>

Hi,

thanks for your answer.

I've pulled the PAM only.

its a lightstream 1010 (8515MSRP, I think).

We're running IOS 12.1(26)E

Unfortunatly, we've got no support on that box. But I'm afraid that it
could be a hardware issue.

Sebastian

Lamar Owen schrieb:
> On Friday 27 March 2009 03:47:53 Sebastian Ganschow wrote:
>> Hi,
>>
>> as far as i know and cisco says, a lightstream should be hot-swap capable.
>>
>> Does anyone know which reason could be, that a lightstream freezes, if you
>> pull a WAI-E3-4BNC Card?
> 
> Are you pulling the PAM only, or the whole CAM?
> 
> What IOS release are you on?  This is an LS1010, I assume.  ASP-B or ASP-C (or 
> 8515MSRP)?
> 
> Those boxes are quite old, now, and you may be tickling an old hardware or IOS 
> bug.  If you have support on it, it's EOL Last Date of Support isn't until 
> April 29, 2011.  Can't get a new contract now, but you can renew an existing 
> one until April 2010.
> 
> I had an 8510MSR 'section' in an old Catalyst 5500 I retired a few months ago, 
> and never had issues with OIR on IOS 12.1(26)E3 (itself a pretty old, but 
> still supported, IOS train).  I only used OC3 and OC12 PAMs in it, so you 
> might be tickling a bug in your particular PAM.
> 
> There is a 12.0 mainline caveat for the LS1010, CSCdw36579, that relates to 
> this issue.  The description is:
> 
> Symptom: OIR of port adapters does not work as expected using 12.0 mainline 
> software on the LightStream 1010.
> 
> Workaround: Use the latest W5 image or do not OIR the port adapters 
> individually. OIR the carrier module, remove the port adapter and then 
> reinstall the carrier module. 
> ( from 
> http://www.cisco.com/en/US/products/hw/switches/ps718/prod_release_note09186a008049913f.html#wp36005 
> )
> 
> So you want to be on the latest 12.0W5 train image, or upgrade to the 12.1E 
> train.


From peter at rathlev.dk  Fri Mar 27 18:51:37 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Fri, 27 Mar 2009 23:51:37 +0100
Subject: [c-nsp] Question about CBWFQ and PING times
In-Reply-To: <56F211C5E3F24F47B103EA1B253822BE03654CC0@vic-cr-ex1.staff.netspace.net.au>
References: <56F211C5E3F24F47B103EA1B253822BE03654CC0@vic-cr-ex1.staff.netspace.net.au>
Message-ID: <1238194297.4011.13.camel@localhost.localdomain>

On Fri, 2009-03-27 at 13:34 +1100, Andy Saykao wrote:
> How misleading is that then. When you issue the "show policy-map"
> command, it calculates the bandwidth % using what's set with the
> bandwidth interface command. I'll make a note to disregard this piece of
> cosmetic from cisco when using the "show policy-map" command.

Well, the "bandwidth" command does have it's uses, just not very much in
doing QoS. People running e.g. EIGRP would use it a lot. :-)

> 1/ There's an "offered rate" for each class - is this the amount of
> bandwidth the router is currently reserving for each class?

The "30 second offered rate" tells you how much this class has been used
in the past 30 seconds. It you reserve 64kbps for a specific class but
no traffic in this class arrives at the router the offered rate would be
0. If you have a very smooth stream of relevant traffic the offered rate
would be very close to the reserved rate.

> 2/ One odd thing I've found is that when I permit additional icmp's to
> the ACL, the "offered rate" rapidly decreases until the "offered rate"
> is ZERO. 
...
> The throughput on the interface is still as expected.
...
> Why does adding the extra icmp lines in the ACL cause the "offered rate"
> to be zero in both classes???

A little strange, but the simplest explanation would be that no incoming
traffic falls in this specific class. If you're running a known standard
load through the router where you are certain there is traffic of this
class it is strange indeed. If this is just "normal" traffic then you
might just not receive any interesting traffic.

Regards,
Peter



From steve at ibctech.ca  Fri Mar 27 19:23:23 2009
From: steve at ibctech.ca (Steve Bertrand)
Date: Fri, 27 Mar 2009 19:23:23 -0400
Subject: [c-nsp] Modifying eBGP routes prior to exporting
Message-ID: <49CD5FEB.5070101@ibctech.ca>

Hi everyone,

I think I'm overlooking something here, but can't pinpoint what.

>From a couple of eBGP peers, I'm receiving a few dozen routes which I
then pass along to specific PE routers via iBGP.

What I've done up until this point is accept the routes, and then tag
them with specific internal communities and next-hop on the way back out
to the iBGP peers.

I've run into an issue where I now need to send routes from different
external peers (from the same router) to the iBGP peers, so I can't
blindly "set" the attributes on all outgoing prefixes.

I could do this with multiple levels of route-maps and/or complex
prefix-lists on the outbound interface to the iBGP peers, but that
doesn't seem scalable.

What I'd like to do, is re-tag the routes inbound from the eBGP peers,
and then let the PE deal with things when the routes are received.

I've tried setting attributes via route-map as the prefixes are received
from the eBGP peers, but for some reason, they don't appear to stick
(per what the iBGP peer puts into it's FIB).

Could someone provide a config snip of what this kind of thing should
look like? When one does a "sh ip bgp route x.x.x.x", do the *incoming*
applied route-map set clauses appear here? If not, how to I check for them?

tcpdump is what I would normally use for something like this, but since
my internal BGP peers aren't affected by the announcing router, the BGP
updates on the wire are useless.

Steve


From tedm at toybox.placo.com  Fri Mar 27 18:42:34 2009
From: tedm at toybox.placo.com (Ted Mittelstaedt)
Date: Fri, 27 Mar 2009 15:42:34 -0700
Subject: [c-nsp] Is this a bug or is it just me not understanding something?
Message-ID: <49CD565A.4090908@toybox.placo.com>

Hi All,

  I have a 7206 router that has a PA-A3-3 card in it running IOS 12.2.46a

The router has the following config snippit in it:

interface ATM1/0.2 multipoint
 description NEW Qwest DSL
 no ip route-cache
 no ip mroute-cache
 pvc 5555555555 1/56
  vbr-nrt 896 896 120
 !
 pvc 5555555556 1/98
  vbr-nrt 1600 1600 120
 !
etc.

It's been working fine for some time.


Anyway, as we know Cisco released the
Multiple Features Crafted UDP Vulnerability
so I tried loading  IOS 12.2.33.SRD1  on it
to fix the vulnerability.

Everthing seemed to work except that the
new IOS bitched about the vbr-nrt statements.

If I changed the snippit above to:


interface ATM1/0.2 multipoint
 description NEW Qwest DSL
 no ip route-cache
 no ip mroute-cache
 pvc 5555555555 1/56
  vbr-nrt 896 896 1
 !
 pvc 5555555556 1/98
  vbr-nrt 1600 1600 1
 !
etc.


it works.  I tried running command line help and this is what i got:

router(config-if-atm-vc)#vbr-nrt ?  
  <1-44209>  Peak Cell Rate(PCR) in Kbps

router(config-if-atm-vc)#vbr-nrt 320 ?
  <1-320>  Sustainable Cell Rate(SCR) in Kbps

router(config-if-atm-vc)#vbr-nrt 320 320 ?
  <1-1>  Maximum Burst Size(MBS) in Cells
  <cr>

Why is the IOS suddenly not allowing MSB's larger than 1?

Ted

From danletkeman at gmail.com  Fri Mar 27 20:57:44 2009
From: danletkeman at gmail.com (Dan Letkeman)
Date: Fri, 27 Mar 2009 19:57:44 -0500
Subject: [c-nsp] multiple wic-1adsl
Message-ID: <dcbb85870903271757h4450858al12aa5ea646a3498e@mail.gmail.com>

Hello,

I'm wondering if there is a low cost router that could handle six
wic-1adsl cards?  I'm looking at replacing six cisco 827 routers
(connected to dsl) that are sitting in-front of another router which
is doing cef load sharing between the six 827's


users-------cef load sharing router ---------six 827 routers, pppoe &
nat----------internet

From steve at ibctech.ca  Fri Mar 27 22:10:35 2009
From: steve at ibctech.ca (Steve Bertrand)
Date: Fri, 27 Mar 2009 22:10:35 -0400 (EDT)
Subject: [c-nsp] Modifying eBGP routes prior to exporting
Message-ID: <1226.69.49.38.10.1238206235.squirrel@webmail.ibctech.ca>


> What I'd like to do, is re-tag the routes inbound from the eBGP peers,
> and then let the PE deal with things when the routes are received.
>
> I've tried setting attributes via route-map as the prefixes are received
> from the eBGP peers, but for some reason, they don't appear to stick
> (per what the iBGP peer puts into it's FIB).

Apologizing for replying my own post, I'd like to rephrase my initial
question...

How does one set classification on ingress prefixes from specific eBGP
peers (or the eBGP peer itself), so that the said assigned classification
is retained when the prefixes are passed along to iBGP peers?

Steve


From amsoares at netcabo.pt  Fri Mar 27 22:49:50 2009
From: amsoares at netcabo.pt (Antonio Soares)
Date: Sat, 28 Mar 2009 02:49:50 -0000
Subject: [c-nsp] 12.4(24)T Bug ?
Message-ID: <0BEB32FAA297437686BC18695BF920EA@int.convex.pt>

Hello group,

I have a 7200 running 12.4(24)T ADVIPSERVICESK9-M configured for 6VPE:

++++++++++++++++++++++++++++++++++++++++++++++++++++++++
PE1#sh runn
Building configuration...

Current configuration : 2346 bytes
!
upgrade fpd auto
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname PE1
!
boot-start-marker
boot-end-marker
!
vrf definition vrf1
 rd 1:1
 !
 address-family ipv4
 route-target export 1:1
 route-target import 1:1
 exit-address-family
 !
 address-family ipv6
 route-target export 1:1
 route-target import 1:1
 exit-address-family
!
logging message-counter syslog
enable password cisco
!
no aaa new-model
ip source-route
ip cef
!
!
!
!
no ip domain lookup
ipv6 unicast-routing
ipv6 cef
!
multilink bundle-name authenticated
!
!
!
!
!         
!
!
!
!
!
!
!
!
!
!
!
archive
 log config
  hidekeys
! 
!
!
!
!
!
class-map match-any PRECEDENCE-0
 match  precedence 0 
!         
!
policy-map MONITOR
 class PRECEDENCE-0
!
!
!
!
!
interface Loopback0
 ip address 100.100.100.1 255.255.255.255
!
interface FastEthernet0/0
 vrf forwarding vrf1
 ip address 10.10.10.254 255.255.255.0
 duplex auto
 speed auto
 ipv6 address 2001:10::2/64
 service-policy input MONITOR
!
interface FastEthernet0/1
 ip address 13.13.13.1 255.255.255.0
 duplex auto
 speed auto
 mpls ip
!
router ospf 1
 router-id 100.100.100.1
 log-adjacency-changes
 network 0.0.0.0 255.255.255.255 area 0
!
router bgp 1
 bgp router-id 100.100.100.1
 no bgp default ipv4-unicast
 bgp log-neighbor-changes
 neighbor 100.100.100.2 remote-as 1
 neighbor 100.100.100.2 update-source Loopback0
 !
 address-family vpnv6
  neighbor 100.100.100.2 activate
  neighbor 100.100.100.2 send-community extended
 exit-address-family
 !
 address-family vpnv4
  neighbor 100.100.100.2 activate
  neighbor 100.100.100.2 send-community extended
 exit-address-family
 !
 address-family ipv4 vrf vrf1
  redistribute connected
  redistribute static
  no synchronization
 exit-address-family
 !
 address-family ipv6 vrf vrf1
  redistribute connected
  redistribute static
  no synchronization
 exit-address-family
!
ip forward-protocol nd
ip route vrf vrf1 1.1.1.1 255.255.255.255 10.10.10.1
no ip http server
no ip http secure-server
!
!
!
ipv6 route vrf vrf1 2001:1::/64 2001:10::1
!
!         
!
!
!
!
control-plane
!
!
!
mgcp fax t38 ecm
!
!
!
!
gatekeeper
 shutdown
!
!
line con 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
 stopbits 1
line aux 0
 exec-timeout 0 0
 privilege level 15
 stopbits 1
line vty 0 4
 password cisco
 login
!
end

PE1#
++++++++++++++++++++++++++++++++++++++++++++++++++++++++

And i have this connectivity problem between CE devices (CE1 is directly connected to PE1):

++++++++++++++++++++++++++++++++++++++++++++++++++++++++
CE1#ping
Protocol [ip]: ipv6
Target IPv6 address: 2001:2::1
Repeat count [5]: 1000
Datagram size [100]: 
Timeout in seconds [2]: 
Extended commands? [no]: 
Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 2001:2::1, timeout is 2 seconds:
....!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!......
.............!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!...................!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!...................!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!...................!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!...................!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!...................!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!...................!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!...................!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.............
......!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!......
.............!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!...................!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!...................!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!
Success rate is 76 percent (768/1000), round-trip min/avg/max = 48/134/400 ms
CE1#
++++++++++++++++++++++++++++++++++++++++++++++++++++++++

The problem does not occur when the input service-policy facing CE1 is removed:

++++++++++++++++++++++++++++++++++++++++++++++++++++++++
CE1#ping
Protocol [ip]: ipv6
Target IPv6 address: 2001:2::1
Repeat count [5]: 1000
Datagram size [100]: 
Timeout in seconds [2]: 
Extended commands? [no]: 
Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 2001:2::1, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (1000/1000), round-trip min/avg/max = 28/133/340 ms
CE1#
++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Any ideas of what could be causing this ?


Thanks.

Regards,

Antonio Soares, CCIE #18473 (R&S)
amsoares at netcabo.pt


From damin at nacs.net  Sat Mar 28 00:51:09 2009
From: damin at nacs.net (Gregory Boehnlein)
Date: Sat, 28 Mar 2009 00:51:09 -0400
Subject: [c-nsp] 7507 - 12.4.23 - bgp_cpu2timeout message
Message-ID: <020d01c9af60$d02d7110$70885330$@net>

One of our core routers was upgraded to 12.4.23 a few hours ago, and since
the upgrade, we have been seeing the following message in our log files.

Mar 27 23:32:15.570 EDT: bgp_cpu2timeout: seconds: 30000, slot: 3 for 5: 51%
and 1: 27%

I can't really find any specific references to this error message on the
7500 anywhere on the net, but I did see someone posting here about having
the issue on a 7206-VXR. Anyone have any clues as to wether this is a benign
message? 


From pshem.k at gmail.com  Sat Mar 28 05:15:40 2009
From: pshem.k at gmail.com (Pshem Kowalczyk)
Date: Sat, 28 Mar 2009 22:15:40 +1300
Subject: [c-nsp] Modifying eBGP routes prior to exporting
In-Reply-To: <1226.69.49.38.10.1238206235.squirrel@webmail.ibctech.ca>
References: <1226.69.49.38.10.1238206235.squirrel@webmail.ibctech.ca>
Message-ID: <20fe625b0903280215k5da68f24wffdd8dced4530a8a@mail.gmail.com>

I'm not sure if I got your question right, but we do the following:

neighbor xx.yy.41.93 route-map NBR-UP2-IN in

route-map NBR-UP2-IN permit 10
 match as-path 52
 set local-preference 100
 set community aaa:5000 aaa:5600
!
route-map NBR-UP2-IN permit 20
 set local-preference 90
 set community aaa:5000 aaa:5600

and it does work on all of the iBGP peers - every prefix that is
selected as 'best path' has the community denoting where it came from.
As long as you have send-community on the iBGP session that should
work. If you do 'sh ip bgp' for a prefix learnt from one of the peers
- can you see the communities set by the route-map?

kind regards
Pshem

2009/3/28 Steve Bertrand <steve at ibctech.ca>:
>
>> What I'd like to do, is re-tag the routes inbound from the eBGP peers,
>> and then let the PE deal with things when the routes are received.
>>
>> I've tried setting attributes via route-map as the prefixes are received
>> from the eBGP peers, but for some reason, they don't appear to stick
>> (per what the iBGP peer puts into it's FIB).
>
> Apologizing for replying my own post, I'd like to rephrase my initial
> question...
>
> How does one set classification on ingress prefixes from specific eBGP
> peers (or the eBGP peer itself), so that the said assigned classification
> is retained when the prefixes are passed along to iBGP peers?
>
> Steve
>
> _______________________________________________
> cisco-nsp mailing list ?cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From harbor235 at gmail.com  Sat Mar 28 08:06:52 2009
From: harbor235 at gmail.com (harbor235)
Date: Sat, 28 Mar 2009 08:06:52 -0400
Subject: [c-nsp] 7507 - 12.4.23 - bgp_cpu2timeout message
In-Reply-To: <020d01c9af60$d02d7110$70885330$@net>
References: <020d01c9af60$d02d7110$70885330$@net>
Message-ID: <836bf1f90903280506w3af5d52cpff1719715f08286b@mail.gmail.com>

Greg,

I looked up the message and it appears to be a cosmetic bug.

http://forum.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Network%20Infrastructure&topic=WAN%2C%20Routing%20and%20Switching&topicID=.ee71a06&CommCmd=MB%3Fcmd%3Dpass_through%26location%3Doutline%40
^1%40%40.2cd25b2a/1#selected_message

mike

On Sat, Mar 28, 2009 at 12:51 AM, Gregory Boehnlein <damin at nacs.net> wrote:

> One of our core routers was upgraded to 12.4.23 a few hours ago, and since
> the upgrade, we have been seeing the following message in our log files.
>
> Mar 27 23:32:15.570 EDT: bgp_cpu2timeout: seconds: 30000, slot: 3 for 5:
> 51%
> and 1: 27%
>
> I can't really find any specific references to this error message on the
> 7500 anywhere on the net, but I did see someone posting here about having
> the issue on a 7206-VXR. Anyone have any clues as to wether this is a
> benign
> 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 lowen at pari.edu  Sat Mar 28 12:49:37 2009
From: lowen at pari.edu (Lamar Owen)
Date: Sat, 28 Mar 2009 12:49:37 -0400
Subject: [c-nsp] Lightstream freeze
In-Reply-To: <49CD5840.9090304@buelow-masiak.de>
References: <49CC84A9.2020308@buelow-masiak.de>
Message-ID: <200903281249.38233.lowen@pari.edu>

On Friday 27 March 2009 18:50:40 Sebastian Ganschow wrote:
> Hi,
>
> thanks for your answer.
>
> I've pulled the PAM only.
>
> its a lightstream 1010 (8515MSRP, I think).
>
> We're running IOS 12.1(26)E
>
> Unfortunatly, we've got no support on that box. But I'm afraid that it
> could be a hardware issue.

Possibly a hardware issue.

But please see 
https://www.cisco.com/en/US/products/products_security_advisory09186a0080a01538.shtml 
as that might entitle you to a newer IOS for the beast.
-- 
Lamar Owen
Chief Information Officer
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
http://www.pari.edu


From shimshah at cisco.com  Sat Mar 28 15:40:18 2009
From: shimshah at cisco.com (Shimol Shah  ( Cisco ))
Date: Sat, 28 Mar 2009 15:40:18 -0400
Subject: [c-nsp] 7507 - 12.4.23 - bgp_cpu2timeout message
In-Reply-To: <020d01c9af60$d02d7110$70885330$@net>
References: <020d01c9af60$d02d7110$70885330$@net>
Message-ID: <00c701c9afdd$06488920$629d6640@cisco.com>

It is CSCek77849. Will be fixed in 12.4(23a) 

> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net 
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of 
> Gregory Boehnlein
> Sent: Saturday, March 28, 2009 12:51 AM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] 7507 - 12.4.23 - bgp_cpu2timeout message
> 
> One of our core routers was upgraded to 12.4.23 a few hours 
> ago, and since the upgrade, we have been seeing the following 
> message in our log files.
> 
> Mar 27 23:32:15.570 EDT: bgp_cpu2timeout: seconds: 30000, 
> slot: 3 for 5: 51% and 1: 27%
> 
> I can't really find any specific references to this error 
> message on the 7500 anywhere on the net, but I did see 
> someone posting here about having the issue on a 7206-VXR. 
> Anyone have any clues as to wether this is a benign 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 amsoares at netcabo.pt  Sat Mar 28 22:10:28 2009
From: amsoares at netcabo.pt (Antonio Soares)
Date: Sun, 29 Mar 2009 03:10:28 +0100
Subject: [c-nsp] 12.4(24)T Bug ?
In-Reply-To: <0BEB32FAA297437686BC18695BF920EA@int.convex.pt>
References: <0BEB32FAA297437686BC18695BF920EA@int.convex.pt>
Message-ID: <43456CA84FEF45AFA585E4AED89C88F5@int.convex.pt>

Just to add that i found this problem in a production network and i was able to reproduce the issue with dynamips.

In both situations, i have sequences of 19 reply failures. Weird, isnt' it ?


Regards,

Antonio Soares, CCIE #18473 (R&S)
amsoares at netcabo.pt

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Antonio Soares
Sent: s?bado, 28 de Mar?o de 2009 2:50
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] 12.4(24)T Bug ?

Hello group,

I have a 7200 running 12.4(24)T ADVIPSERVICESK9-M configured for 6VPE:

++++++++++++++++++++++++++++++++++++++++++++++++++++++++
PE1#sh runn
Building configuration...

Current configuration : 2346 bytes
!
upgrade fpd auto
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname PE1
!
boot-start-marker
boot-end-marker
!
vrf definition vrf1
 rd 1:1
 !
 address-family ipv4
 route-target export 1:1
 route-target import 1:1
 exit-address-family
 !
 address-family ipv6
 route-target export 1:1
 route-target import 1:1
 exit-address-family
!
logging message-counter syslog
enable password cisco
!
no aaa new-model
ip source-route
ip cef
!
!
!
!
no ip domain lookup
ipv6 unicast-routing
ipv6 cef
!
multilink bundle-name authenticated
!
!
!
!
!         
!
!
!
!
!
!
!
!
!
!
!
archive
 log config
  hidekeys
! 
!
!
!
!
!
class-map match-any PRECEDENCE-0
 match  precedence 0 
!         
!
policy-map MONITOR
 class PRECEDENCE-0
!
!
!
!
!
interface Loopback0
 ip address 100.100.100.1 255.255.255.255
!
interface FastEthernet0/0
 vrf forwarding vrf1
 ip address 10.10.10.254 255.255.255.0
 duplex auto
 speed auto
 ipv6 address 2001:10::2/64
 service-policy input MONITOR
!
interface FastEthernet0/1
 ip address 13.13.13.1 255.255.255.0
 duplex auto
 speed auto
 mpls ip
!
router ospf 1
 router-id 100.100.100.1
 log-adjacency-changes
 network 0.0.0.0 255.255.255.255 area 0
!
router bgp 1
 bgp router-id 100.100.100.1
 no bgp default ipv4-unicast
 bgp log-neighbor-changes
 neighbor 100.100.100.2 remote-as 1
 neighbor 100.100.100.2 update-source Loopback0
 !
 address-family vpnv6
  neighbor 100.100.100.2 activate
  neighbor 100.100.100.2 send-community extended
 exit-address-family
 !
 address-family vpnv4
  neighbor 100.100.100.2 activate
  neighbor 100.100.100.2 send-community extended
 exit-address-family
 !
 address-family ipv4 vrf vrf1
  redistribute connected
  redistribute static
  no synchronization
 exit-address-family
 !
 address-family ipv6 vrf vrf1
  redistribute connected
  redistribute static
  no synchronization
 exit-address-family
!
ip forward-protocol nd
ip route vrf vrf1 1.1.1.1 255.255.255.255 10.10.10.1
no ip http server
no ip http secure-server
!
!
!
ipv6 route vrf vrf1 2001:1::/64 2001:10::1
!
!         
!
!
!
!
control-plane
!
!
!
mgcp fax t38 ecm
!
!
!
!
gatekeeper
 shutdown
!
!
line con 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
 stopbits 1
line aux 0
 exec-timeout 0 0
 privilege level 15
 stopbits 1
line vty 0 4
 password cisco
 login
!
end

PE1#
++++++++++++++++++++++++++++++++++++++++++++++++++++++++

And i have this connectivity problem between CE devices (CE1 is directly connected to PE1):

++++++++++++++++++++++++++++++++++++++++++++++++++++++++
CE1#ping
Protocol [ip]: ipv6
Target IPv6 address: 2001:2::1
Repeat count [5]: 1000
Datagram size [100]: 
Timeout in seconds [2]: 
Extended commands? [no]: 
Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 2001:2::1, timeout is 2 seconds:
....!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!......
.............!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!...................!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!...................!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!...................!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!...................!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!...................!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!...................!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!...................!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.............
......!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!......
.............!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!...................!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!...................!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!
Success rate is 76 percent (768/1000), round-trip min/avg/max = 48/134/400 ms
CE1#
++++++++++++++++++++++++++++++++++++++++++++++++++++++++

The problem does not occur when the input service-policy facing CE1 is removed:

++++++++++++++++++++++++++++++++++++++++++++++++++++++++
CE1#ping
Protocol [ip]: ipv6
Target IPv6 address: 2001:2::1
Repeat count [5]: 1000
Datagram size [100]: 
Timeout in seconds [2]: 
Extended commands? [no]: 
Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 2001:2::1, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (1000/1000), round-trip min/avg/max = 28/133/340 ms
CE1#
++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Any ideas of what could be causing this ?


Thanks.

Regards,

Antonio Soares, CCIE #18473 (R&S)
amsoares at netcabo.pt

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


From jjsurlenet at hotmail.fr  Sun Mar 29 03:19:40 2009
From: jjsurlenet at hotmail.fr (JJ JJ)
Date: Sun, 29 Mar 2009 09:19:40 +0200
Subject: [c-nsp] cisco problem over 500mbps per port, microburst ? queue ?
Message-ID: <COL113-W365C72F2D8EFF21F4D4A03B88C0@phx.gbl>


 Hi,

 

I am experementing per port limitation at 500mps on a Cisco 2960G 24 TCL. Uplink 1gbps port 24.

 When my bandwith goes over 500mps on 1 port (24), all my video streams thru port 24 goes down from 900kps to 200kps ! And i see a lot of DROPS in the port 24 statistics.


 Also i see that i still can read video at 900kps from port 1 to 8, while  24 is "overloaded" at 500mps.
 So the switch bandwith is ok, but the port 24 looks like too busy.
 Note that i changed the cisco switch for a Dlink gigabit switch, and had the  same problem !

 

 I do streaming video, and i read that microburst could be a problem.

This thread was open, but never been solved :

http://www.gossamer-threads.com/lists/cisco/nsp/96188

 

What does Cisco recommends for this problem ? Can't a 2960G handle >500mps ?

_________________________________________________________________
In?dit ! Des Emotic?nes D?jant?es! Installez les dans votre Messenger ! 
http://www.ilovemessenger.fr/Emoticones/EmoticonesDejantees.aspx

From peter at rathlev.dk  Sun Mar 29 06:23:16 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Sun, 29 Mar 2009 12:23:16 +0200
Subject: [c-nsp] FWSM HA secondary reload & long downtime
In-Reply-To: <1236889348.4133.15.camel@localhost.localdomain>
References: <1236633344.3572.13.camel@localhost.localdomain>
	<Pine.LNX.4.64.0903101125050.6781@zippy.stdio.be>
	<1236719408.4513.51.camel@localhost.localdomain>
	<Pine.LNX.4.64.0903111101340.21155@zippy.stdio.be>
	<1236793626.3563.339.camel@localhost.localdomain>
	<Pine.LNX.4.64.0903111901550.21155@zippy.stdio.be>
	<1236889348.4133.15.camel@localhost.localdomain>
Message-ID: <1238322196.3466.3.camel@localhost.localdomain>

Follow-up for the archives:

On Thu, 2009-03-12 at 21:22 +0100, Peter Rathlev wrote:
> It is of course a joy to have figured this out, but I can't seem to find
> anything much on what "monitor-interface" in a multiple context setup
> actually does or doesn't do.
> 
> Should every context have one monitor-interface? Should all interfaces
> be monitored or just one per context?

We had a window to play around with this on the productions system and
it seems that with at least one "monitor-interface" per context we can
reboot the non-active unit without any problems. We have a window more
soon where we'll test a full reboot cycle for both units.

Regards,
Peter



From gert at greenie.muc.de  Sun Mar 29 06:59:44 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Sun, 29 Mar 2009 12:59:44 +0200
Subject: [c-nsp] Modifying eBGP routes prior to exporting
In-Reply-To: <1226.69.49.38.10.1238206235.squirrel@webmail.ibctech.ca>
References: <1226.69.49.38.10.1238206235.squirrel@webmail.ibctech.ca>
Message-ID: <20090329105944.GJ290@greenie.muc.de>

Hi,

On Fri, Mar 27, 2009 at 10:10:35PM -0400, Steve Bertrand wrote:
> How does one set classification on ingress prefixes from specific eBGP
> peers (or the eBGP peer itself), so that the said assigned classification
> is retained when the prefixes are passed along to iBGP peers?

community settings on the inbound route-map?

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/20090329/9350ac33/attachment.bin>

From dmitry at dmitry.net  Mon Mar 30 04:51:43 2009
From: dmitry at dmitry.net (Dmitry Kiselev)
Date: Mon, 30 Mar 2009 11:51:43 +0300
Subject: [c-nsp] C7600 power allocation
Message-ID: <20090330085143.GM27954@f17.dmitry.net>

Hello!

  Could anybody explain me how exactly IOS choise which module to
disable if system run in combined power mode and one of power inputs
failed?


http://www.cisco.com/en/US/docs/routers/7600/ios/12.2SR/configuration/guide/pwr_envr.html#wp1020384

However, if one power supply fails and there is not enough power
for all of the previously powered-up modules, the system powers
down those modules. 



  Could I do some pre-configuration to point IOS to modules "less
critical" for me?


P.S. 12.2(33)SRC3, C7609-S, dual PS

-- 
Dmitry Kiselev

From kev.edmunds at googlemail.com  Mon Mar 30 05:31:58 2009
From: kev.edmunds at googlemail.com (Kevin Edmunds)
Date: Mon, 30 Mar 2009 10:31:58 +0100
Subject: [c-nsp] VPN Concentrator returns error when saving config
Message-ID: <e29dedbf0903300231t2b491c71kfc9d3a87aa87fcf9@mail.gmail.com>

Hi List,

I have a VPN 3020 concentrator running version 4.7.2, lately its started to
give the following error when we save the config via the web GUI:

Syslog:

SEV=3 CONFIG/25 RPT=8  GET post-validation Bad Value Error on
alIpLocDefRtPref.0.
SEV=4 CONFIG/17 RPT=15  Done writing configuration file, Bad Value Error.

Has anyone come across this problem before? We haven't been able to reboot
the box yet to see if its holding the new changes yet and slightly worried I
may loose my config.

Thanks for your time.

Kev.

From techconfig at yahoo.com  Mon Mar 30 05:41:12 2009
From: techconfig at yahoo.com (Mark Tech)
Date: Mon, 30 Mar 2009 02:41:12 -0700 (PDT)
Subject: [c-nsp] 10GE card for 7609
Message-ID: <863386.41277.qm@web44809.mail.sp1.yahoo.com>


Hi
I have a prospect for a 10G upstream customer and Upstream ISP connections. I would need to connect these into our 7609s running RSP 720-3CXL's, at the moment I have found that the WS-X6704-10GE card may be suitable.

My technical requirements are:
10Gbps line rate
IPv4
Able to handle full Internet routing table
Potentially IPv6 and MPLS in the future

With the WS-X6704-10GE, there seems to be several options that are available with it i.e.

Memory Option: 
MEM-XCEF720-256M 
Catalyst 6500 256MB DDR, xCEF720 (67xx interface, DFC3A) 
MEM-XCEF720-512M 
Cat 6500 512MB DDR, xCEF720 (67xx interface, DFC3A/DFC3B)? 
MEM-XCEF720-1GB 
Catalyst 6500 1GB DDR, xCEF720 (67xx interface, DFC3BXL) 

====================================================
Distributed Forwarding Card Option

WS-F6700-CFC 
Catalyst 6500 Central Fwd Card for WS-X67xx modules 
WS-F6700-DFC3B 
Catalyst 6500 Dist Fwd Card, 256K Routes for WS-X67xx? 
WS-F6700-DFC3A 
Catalyst 6500 Dist Fwd Card for WS-X67xx modules 
WS-F6700-DFC3BXL 
Catalyst 6500 Dist Fwd Card- 3BXL, for WS-X67xx 
WS-F6700-DFC3C 
Catalyst 6500 Dist Fwd Card for WS-X67xx modules 
WS-F6700-DFC3CXL 
Catalyst 6500 Dist Fwd Card- 3CXL, for WS-X67xx

I assume that I would need MEM-XCEF720-1GB and WS-F6700-DFC3CXL?

Regards

Mark


      


From mtinka at globaltransit.net  Mon Mar 30 06:13:51 2009
From: mtinka at globaltransit.net (Mark Tinka)
Date: Mon, 30 Mar 2009 18:13:51 +0800
Subject: [c-nsp] 10GE card for 7609
In-Reply-To: <863386.41277.qm@web44809.mail.sp1.yahoo.com>
References: <863386.41277.qm@web44809.mail.sp1.yahoo.com>
Message-ID: <200903301816.15917.mtinka@globaltransit.net>

On Monday 30 March 2009 05:41:12 pm Mark Tech wrote:

> I have a prospect for a 10G upstream customer and
> Upstream ISP connections. I would need to connect these
> into our 7609s running RSP 720-3CXL's, at the moment I
> have found that the WS-X6704-10GE card may be suitable.

We typically order our WS-X67xx-based 10Gbps line cards like 
so, for a complete set:

* WS-X6704-10GE
* WS-F6700-DFC3CXL
* XENPAK-10GB-SR (depends on your distance needs)
* MEM-XCEF720-1GB (part of this bundle)

Since you're running a 7600, you may also consider an ES+20 
or ES+40 line card, if the price is right, of course (watch 
out for that v6 license).

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/20090330/3a74ea0f/attachment.bin>

From techconfig at yahoo.com  Mon Mar 30 06:18:13 2009
From: techconfig at yahoo.com (Mark Tech)
Date: Mon, 30 Mar 2009 03:18:13 -0700 (PDT)
Subject: [c-nsp] 10GE card for 7609
In-Reply-To: <200903301816.15917.mtinka@globaltransit.net>
References: <863386.41277.qm@web44809.mail.sp1.yahoo.com>
	<200903301816.15917.mtinka@globaltransit.net>
Message-ID: <412535.16004.qm@web44803.mail.sp1.yahoo.com>


Hi thanks fot that. I was looking at the ES card until the licence pricing was introduced. Then it suddenly went away very quicky!!

Cheers

Mark



----- Original Message ----
From: Mark Tinka <mtinka at globaltransit.net>
To: cisco-nsp at puck.nether.net
Cc: Mark Tech <techconfig at yahoo.com>
Sent: Monday, March 30, 2009 11:13:51 AM
Subject: Re: [c-nsp] 10GE card for 7609

On Monday 30 March 2009 05:41:12 pm Mark Tech wrote:

> I have a prospect for a 10G upstream customer and
> Upstream ISP connections. I would need to connect these
> into our 7609s running RSP 720-3CXL's, at the moment I
> have found that the WS-X6704-10GE card may be suitable.

We typically order our WS-X67xx-based 10Gbps line cards like 
so, for a complete set:

* WS-X6704-10GE
* WS-F6700-DFC3CXL
* XENPAK-10GB-SR (depends on your distance needs)
* MEM-XCEF720-1GB (part of this bundle)

Since you're running a 7600, you may also consider an ES+20 
or ES+40 line card, if the price is right, of course (watch 
out for that v6 license).

Cheers,

Mark.



      


From ib_cims at yahoo.com  Mon Mar 30 05:35:36 2009
From: ib_cims at yahoo.com (Ibrahim Alsharif)
Date: Mon, 30 Mar 2009 02:35:36 -0700 (PDT)
Subject: [c-nsp] Cisco PIX Boot Error
Message-ID: <872252.71437.qm@web63805.mail.re1.yahoo.com>

Hello Dears,
I'm facing a problem with Cisco PIX 515E, when I do reload on it it goes to the Monitor Mode although there is an image file in the flash memory.
and the Boot Variable pointing to it.
also when I do upload new Image by TFTP it's working but when I reload it, same Issue (Monitor Mode)
please help me if u have any idea

here is the show version

sh ver
Cisco PIX Security Appliance Software Version 8.0(4) 
Compiled on Thu 07-Aug-08 19:42 by builders
System image file is "Unknown, monitor mode tftp booted image"
Config file at boot was "flash:/startup-config"
cisco-pix up 30 secs
Hardware: PIX-515E, 128 MB RAM, CPU Pentium II 433 MHz
Flash E28F128J3 @ 0xfff00000, 16MB
BIOS Flash AM29F400B @ 0xfffd8000, 32KB
Encryption hardware device : VAC+ (Crypto5823 revision 0x1)
0: Ext: Ethernet0 : address is 000b.fd19.93f9, irq 10
1: Ext: Ethernet1 : address is 000b.fd19.93fa, irq 11
2: Ext: Ethernet2 : address is 0005.5d18.390d, irq 11
3: Ext: Ethernet3 : address is 0005.5d18.390e, irq 10
4: Ext: Ethernet4 : address is 0005.5d18.390f, irq 9
5: Ext: Ethernet5 : address is 0005.5d18.3910, irq 5
Licensed features for this platform:
Maximum Physical Interfaces : 6 
Maximum VLANs : 25 
Inside Hosts : Unlimited 
<--- More --->
Failover : Active/Active
VPN-DES : Enabled 
VPN-3DES-AES : Enabled 
Cut-through Proxy : Enabled 
Guards : Enabled 
URL Filtering : Enabled 
Security Contexts : 2 
GTP/GPRS : Disabled 
VPN Peers : Unlimited 
This platform has an Unrestricted (UR) license.
Serial Number: 807031324
Running Activation Key: 0xcf034f76 0x78b40c51 0xa00275f4 0x865440e0 0x0601ca9e 
Configuration has not been modified since last system restart.
cisco-pix# 
?
?
Thank you
Ibrahim Alsharif


      

From amsoares at netcabo.pt  Mon Mar 30 08:04:57 2009
From: amsoares at netcabo.pt (Antonio Soares)
Date: Mon, 30 Mar 2009 13:04:57 +0100
Subject: [c-nsp] 12.4(24)T Bug ?
In-Reply-To: <43456CA84FEF45AFA585E4AED89C88F5@int.convex.pt>
References: <0BEB32FAA297437686BC18695BF920EA@int.convex.pt>
	<43456CA84FEF45AFA585E4AED89C88F5@int.convex.pt>
Message-ID: <9000D4B1EBE5453C9C160A6684A45D1F@int.convex.pt>

I found in the meanwhile that IPv6 traffic is completely broken between CE and PE:

CE1#ping 2001:10::2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:10::2, timeout is 2 seconds:
UUUUU
Success rate is 0 percent (0/5)
CE1#

PE1#sh runn int f0/0
Building configuration...

Current configuration : 176 bytes
!
interface FastEthernet0/0
 vrf forwarding vrf1
 ip address 10.10.10.254 255.255.255.0
 duplex auto
 speed auto
 ipv6 address 2001:10::2/64
 service-policy input MONITOR
end

PE1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
PE1(config)#int f0/0
PE1(config-if)#no  service-policy input MONITOR
PE1(config-if)#


CE1#ping 2001:10::2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:10::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/87/272 ms
CE1#
CE1#

PE1(config-if)#
PE1(config-if)#  service-policy input MONITOR  
PE1(config-if)#


CE1#
CE1#ping 2001:10::2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:10::2, timeout is 2 seconds:
UUUUU
Success rate is 0 percent (0/5)
CE1#

It seems the Service Policy breaks IPv6 ICMP ND but i still don't understand very well why.

Anyone running 12.2(24)T ?


Regards,

Antonio Soares, CCIE #18473 (R&S)
amsoares at netcabo.pt

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Antonio Soares
Sent: domingo, 29 de Mar?o de 2009 3:10
To: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] 12.4(24)T Bug ?

Just to add that i found this problem in a production network and i was able to reproduce the issue with dynamips.

In both situations, i have sequences of 19 reply failures. Weird, isnt' it ?


Regards,

Antonio Soares, CCIE #18473 (R&S)
amsoares at netcabo.pt

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Antonio Soares
Sent: s?bado, 28 de Mar?o de 2009 2:50
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] 12.4(24)T Bug ?

Hello group,

I have a 7200 running 12.4(24)T ADVIPSERVICESK9-M configured for 6VPE:

++++++++++++++++++++++++++++++++++++++++++++++++++++++++
PE1#sh runn
Building configuration...

Current configuration : 2346 bytes
!
upgrade fpd auto
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname PE1
!
boot-start-marker
boot-end-marker
!
vrf definition vrf1
 rd 1:1
 !
 address-family ipv4
 route-target export 1:1
 route-target import 1:1
 exit-address-family
 !
 address-family ipv6
 route-target export 1:1
 route-target import 1:1
 exit-address-family
!
logging message-counter syslog
enable password cisco
!
no aaa new-model
ip source-route
ip cef
!
!
!
!
no ip domain lookup
ipv6 unicast-routing
ipv6 cef
!
multilink bundle-name authenticated
!
!
!
!
!         
!
!
!
!
!
!
!
!
!
!
!
archive
 log config
  hidekeys
! 
!
!
!
!
!
class-map match-any PRECEDENCE-0
 match  precedence 0 
!         
!
policy-map MONITOR
 class PRECEDENCE-0
!
!
!
!
!
interface Loopback0
 ip address 100.100.100.1 255.255.255.255 !
interface FastEthernet0/0
 vrf forwarding vrf1
 ip address 10.10.10.254 255.255.255.0
 duplex auto
 speed auto
 ipv6 address 2001:10::2/64
 service-policy input MONITOR
!
interface FastEthernet0/1
 ip address 13.13.13.1 255.255.255.0
 duplex auto
 speed auto
 mpls ip
!
router ospf 1
 router-id 100.100.100.1
 log-adjacency-changes
 network 0.0.0.0 255.255.255.255 area 0
!
router bgp 1
 bgp router-id 100.100.100.1
 no bgp default ipv4-unicast
 bgp log-neighbor-changes
 neighbor 100.100.100.2 remote-as 1
 neighbor 100.100.100.2 update-source Loopback0  !
 address-family vpnv6
  neighbor 100.100.100.2 activate
  neighbor 100.100.100.2 send-community extended  exit-address-family  !
 address-family vpnv4
  neighbor 100.100.100.2 activate
  neighbor 100.100.100.2 send-community extended  exit-address-family  !
 address-family ipv4 vrf vrf1
  redistribute connected
  redistribute static
  no synchronization
 exit-address-family
 !
 address-family ipv6 vrf vrf1
  redistribute connected
  redistribute static
  no synchronization
 exit-address-family
!
ip forward-protocol nd
ip route vrf vrf1 1.1.1.1 255.255.255.255 10.10.10.1 no ip http server no ip http secure-server !
!
!
ipv6 route vrf vrf1 2001:1::/64 2001:10::1 !
!         
!
!
!
!
control-plane
!
!
!
mgcp fax t38 ecm
!
!
!
!
gatekeeper
 shutdown
!
!
line con 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
 stopbits 1
line aux 0
 exec-timeout 0 0
 privilege level 15
 stopbits 1
line vty 0 4
 password cisco
 login
!
end

PE1#
++++++++++++++++++++++++++++++++++++++++++++++++++++++++

And i have this connectivity problem between CE devices (CE1 is directly connected to PE1):

++++++++++++++++++++++++++++++++++++++++++++++++++++++++
CE1#ping
Protocol [ip]: ipv6
Target IPv6 address: 2001:2::1
Repeat count [5]: 1000
Datagram size [100]: 
Timeout in seconds [2]: 
Extended commands? [no]: 
Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 2001:2::1, timeout is 2 seconds:
....!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!......
.............!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!...................!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!...................!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!...................!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!...................!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!...................!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!...................!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!...................!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.............
......!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!......
.............!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!...................!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!...................!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!
Success rate is 76 percent (768/1000), round-trip min/avg/max = 48/134/400 ms CE1#
++++++++++++++++++++++++++++++++++++++++++++++++++++++++

The problem does not occur when the input service-policy facing CE1 is removed:

++++++++++++++++++++++++++++++++++++++++++++++++++++++++
CE1#ping
Protocol [ip]: ipv6
Target IPv6 address: 2001:2::1
Repeat count [5]: 1000
Datagram size [100]: 
Timeout in seconds [2]: 
Extended commands? [no]: 
Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 2001:2::1, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (1000/1000), round-trip min/avg/max = 28/133/340 ms CE1#
++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Any ideas of what could be causing this ?


Thanks.

Regards,

Antonio Soares, CCIE #18473 (R&S)
amsoares at netcabo.pt

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

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


From snar at snar.spb.ru  Mon Mar 30 07:59:25 2009
From: snar at snar.spb.ru (Alexandre Snarskii)
Date: Mon, 30 Mar 2009 15:59:25 +0400
Subject: [c-nsp] C7600 power allocation
In-Reply-To: <20090330085143.GM27954@f17.dmitry.net>
References: <20090330085143.GM27954@f17.dmitry.net>
Message-ID: <20090330115925.GA74488@snar.spb.ru>

On Mon, Mar 30, 2009 at 11:51:43AM +0300, Dmitry Kiselev wrote:
> Hello!
> 
>   Could anybody explain me how exactly IOS choise which module to
> disable if system run in combined power mode and one of power inputs
> failed?
> 
> 
> http://www.cisco.com/en/US/docs/routers/7600/ios/12.2SR/configuration/guide/pwr_envr.html#wp1020384
> 
> However, if one power supply fails and there is not enough power
> for all of the previously powered-up modules, the system powers
> down those modules. 
> 
> 
> 
>   Could I do some pre-configuration to point IOS to modules "less
> critical" for me?

As per this letter, 

http://puck.nether.net/pipermail/cisco-nsp/2006-March/028767.html

you can achieve this placing less critical modules in highest 
numbered slots and more critical - to lowest.  


From sandmaier at schlund.net  Mon Mar 30 09:28:37 2009
From: sandmaier at schlund.net (Jan Sandmaier)
Date: Mon, 30 Mar 2009 15:28:37 +0200
Subject: [c-nsp] MTU settings on GSR linecard 3GE-GBIC-SC
Message-ID: <49D0C905.4030903@schlund.net>

Hi,

does anybody know the reason why I can configure a 9180 byte MTU on port 
0 and 1 on a GSR 3-port Gigabit Ethernet port (3GE-GBIC-SC) but only 
4470 byte on the third port. I use IOS 12.0(32)S12 and 12.0(31)S6.

12012-lab(config-if)#exit
12012-lab(config)#int Gig 2/0
12012-lab(config-if)#mtu ?
  <1500-9180>  MTU size in bytes

12012-lab(config-if)#exit
12012-lab(config)#int Gig 2/1
12012-lab(config-if)#mtu ?
  <1500-9180>  MTU size in bytes

12012-lab(config-if)#int Gig 2/2
12012-lab(config-if)#mtu ?
  <1500-4470>  MTU size in bytes

Thanks,
Jan

From maillist at thelan.no  Mon Mar 30 10:10:39 2009
From: maillist at thelan.no (Harald Firing Karlsen)
Date: Mon, 30 Mar 2009 16:10:39 +0200
Subject: [c-nsp] C7600 power allocation
In-Reply-To: <20090330115925.GA74488@snar.spb.ru>
References: <20090330085143.GM27954@f17.dmitry.net>
	<20090330115925.GA74488@snar.spb.ru>
Message-ID: <49D0D2DF.4020306@thelan.no>

Alexandre Snarskii wrote:
> On Mon, Mar 30, 2009 at 11:51:43AM +0300, Dmitry Kiselev wrote:
>   
>> Hello!
>>
>>   Could anybody explain me how exactly IOS choise which module to
>> disable if system run in combined power mode and one of power inputs
>> failed?
>>
>>
>> http://www.cisco.com/en/US/docs/routers/7600/ios/12.2SR/configuration/guide/pwr_envr.html#wp1020384
>>
>> However, if one power supply fails and there is not enough power
>> for all of the previously powered-up modules, the system powers
>> down those modules. 
>>
>>
>>
>>   Could I do some pre-configuration to point IOS to modules "less
>> critical" for me?
>>     
>
> As per this letter, 
>
> http://puck.nether.net/pipermail/cisco-nsp/2006-March/028767.html
>
> you can achieve this placing less critical modules in highest 
> numbered slots and more critical - to lowest.  
>   
Note however that the two SUP-slots got dedicated/reserved power, so 
they will never shut down. That means if you only got one SUP you should 
have a linecard in the other SUP-slot as well (as the power for this 
slot is reserved anyway).

-- 
Harald Firing Karlsen

From eric at roxanne.org  Mon Mar 30 11:16:00 2009
From: eric at roxanne.org (Eric Gauthier)
Date: Mon, 30 Mar 2009 11:16:00 -0400
Subject: [c-nsp] 10GE card for 7609
In-Reply-To: <863386.41277.qm@web44809.mail.sp1.yahoo.com>
References: <863386.41277.qm@web44809.mail.sp1.yahoo.com>
Message-ID: <20090330151600.GA408@roxanne.org>

Mark,

I'm not sure if you have other 10g links, but keep in mind that Cisco has 
(at least) two 10g optics - Xenpak and X2 - that are not intercompatible.  
I believe that the 6704-10ge uses Xenpak and the 6708-10gE, which is the
"same" card but with 8 ports, uses X2.  If everything else you do is X2,
it might make sense to jump up to the 8 port card to prevent yourself
from having to buy/spare two types of optics.

Eric :)


On Mon, Mar 30, 2009 at 02:41:12AM -0700, Mark Tech wrote:
> 
> Hi
> I have a prospect for a 10G upstream customer and Upstream ISP connections. I would need to connect these into our 7609s running RSP 720-3CXL's, at the moment I have found that the WS-X6704-10GE card may be suitable.
> 
> My technical requirements are:
> 10Gbps line rate
> IPv4
> Able to handle full Internet routing table
> Potentially IPv6 and MPLS in the future
> 
> With the WS-X6704-10GE, there seems to be several options that are available with it i.e.
> 
> Memory Option: 
> MEM-XCEF720-256M 
> Catalyst 6500 256MB DDR, xCEF720 (67xx interface, DFC3A) 
> MEM-XCEF720-512M 
> Cat 6500 512MB DDR, xCEF720 (67xx interface, DFC3A/DFC3B)? 
> MEM-XCEF720-1GB 
> Catalyst 6500 1GB DDR, xCEF720 (67xx interface, DFC3BXL) 
> 
> ====================================================
> Distributed Forwarding Card Option
> 
> WS-F6700-CFC 
> Catalyst 6500 Central Fwd Card for WS-X67xx modules 
> WS-F6700-DFC3B 
> Catalyst 6500 Dist Fwd Card, 256K Routes for WS-X67xx? 
> WS-F6700-DFC3A 
> Catalyst 6500 Dist Fwd Card for WS-X67xx modules 
> WS-F6700-DFC3BXL 
> Catalyst 6500 Dist Fwd Card- 3BXL, for WS-X67xx 
> WS-F6700-DFC3C 
> Catalyst 6500 Dist Fwd Card for WS-X67xx modules 
> WS-F6700-DFC3CXL 
> Catalyst 6500 Dist Fwd Card- 3CXL, for WS-X67xx
> 
> I assume that I would need MEM-XCEF720-1GB and WS-F6700-DFC3CXL?
> 
> Regards
> 
> 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 rjs at eng.gxn.net  Mon Mar 30 10:52:00 2009
From: rjs at eng.gxn.net (Rob Shakir)
Date: Mon, 30 Mar 2009 15:52:00 +0100
Subject: [c-nsp] No GRP images for GSR's?
In-Reply-To: <alpine.DEB.1.10.0903241720380.25843@uplift.swm.pp.se>
References: <17838240D9A5544AAA5FF95F8D52031605B42804@ad-exh01.adhost.lan>
	<20090324161517.GG15184@biological.warningg.com>
	<alpine.DEB.1.10.0903241720380.25843@uplift.swm.pp.se>
Message-ID: <20090330145200.GQ18009@cappuccino.rob.sh>

On Tue, Mar 24, 2009 at 05:21:40PM +0100, Mikael Abrahamsson wrote:
> On Tue, 24 Mar 2009, Brandon Ewing wrote:
>
>> Note that 12.0(32)S12 contains the 4-byte ASN problems discussed here  
>> and on NANOG, so 12.0(32)S11 is your best bet.
>
> As far as I have heard, most people are at 12.0(32)SY, which is (I would  
> say) a better bet.
>
> I've also been told there will be no 12.0(33)S for GRP, just as you  
> stated.

Additionally, 12.0(32)S13 should be available within the next week or so with a
fix for the 4-byte ASN problem.

Kind regards,
Rob

-- 
Rob Shakir                      <rjs at eng.gxn.net>
Network Development Engineer    GX Networks/Vialtus Solutions
ddi: +44208 587 6077            mob: +44797 155 4098
pgp: 0xc07e6deb                 nic-hdl: RJS-RIPE

This email is subject to: http//www.vialtus.com/disclaimer.html


From rjs at eng.gxn.net  Mon Mar 30 10:48:34 2009
From: rjs at eng.gxn.net (Rob Shakir)
Date: Mon, 30 Mar 2009 15:48:34 +0100
Subject: [c-nsp] Opinions of DDoS appliances, other techniques,
	most	notably Cisco Guard
In-Reply-To: <725C9117-BE48-468B-A39E-B69347853BAB@cisco.com>
References: <F3318834F1F89D46857972DD4B411D700651DA6C@EXCHANGE.thenap.com>
	<725C9117-BE48-468B-A39E-B69347853BAB@cisco.com>
Message-ID: <20090330144834.GP18009@cappuccino.rob.sh>

Hi,

We have a deployed Riverhead/Cisco Guard + Detector platform, that I've been
working reasonably closely with over the last 6-9 months. We run the appliances,
rather than the 6500/7600 modules, and are pretty happy with how they function.
I think that the major issue with this platform right now is the fact that it's
got quite a limited life left.

The appliances went EoS on 29th December 2008, but it doesn't look like there's
going to be any useful support past 29th of September this year -- perhaps a bit
quick to kill of a bunch of products like this? 

The Appliances work in ways that the modules don't necessarily, we don't really
want shared-fate of filtering appliances with other 6500/7600, and we deploy
one Detector for 2 or more 6500 chassis -- it doesn't make sense to have one per
chassis from either a technical or financial point-of-view.

On Mon, Mar 16, 2009 at 12:39:57AM +0800, Roland Dobbins wrote:
>
> On Mar 15, 2009, at 11:54 PM, Drew Weaver wrote:
>
>> Also, without a dedicated DDoS system deployed, what is the most  
>> reliable/fastest way to determine the destination(s) of the attacks  
>> (SNMP, NetFlow, etc)?
>
> With or without a dedicated DDoS mitigation system, NetFlow-based  
> anomaly-detection is generally considered to be the most scalable  
> solution which provides network visibility of inbound/outbound/ 
> crossbound traffic.

The problem here (as I've already voiced with my Cisco AM and another security
person from Cisco) is that the boxes that we're currently running (as a UK SP)
don't reliably produce NetFlow data. If you have 7600/6500 in place currently,
it's quite difficult to look at the NetFlow-based detectors as anywhere near as
reliable as mirroring traffic with SPAN.

When I discussed this, the (albeit tongue-in-cheek) suggestion was 'buy ASR...',
I guess there's more benefit to looking at optical taps, or NetFlow probes here.

The Riverhead platform of Appliances and Detectors are good -- and definitely
aid being able to mitigate attacks coming into the network. As mentioned in this
thread, they are best at mitigating flood attacks that exceed the specified
threshold -- but their overall performance is much better than trying to detect
and mitigate attacks manually. Even if the Guard can't necessarily protect your
kit in some cases, there's additional data that one can acquire from the Guard
to be able to take further mitigation measures.

I'd be really interested to hear about what other Guard-type appliances people
are deploying - and how people are working around the 6500/7600 limitations with
NetFlow.

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 billbuhlman at yahoo.com  Mon Mar 30 12:00:01 2009
From: billbuhlman at yahoo.com (Bill Buhlman)
Date: Mon, 30 Mar 2009 09:00:01 -0700 (PDT)
Subject: [c-nsp] Network Survey Document?
Message-ID: <359075.1532.qm@web43139.mail.sp1.yahoo.com>

Does anyone have a document they follow when doing a network survey? I'd rather not create one from scratch. Please send replies to billbuhlman at yahoo.com
?
Thanks,
Bill


      

From chris at chrisserafin.com  Mon Mar 30 12:33:13 2009
From: chris at chrisserafin.com (ChrisSerafin)
Date: Mon, 30 Mar 2009 11:33:13 -0500
Subject: [c-nsp] How not to redistribute statics into VRFs/BGP
In-Reply-To: <49C92013.4070609@chrisserafin.com>
References: <49C90D26.2050604@chrisserafin.com> <gqb6jb$te$1@ger.gmane.org>
	<49C92013.4070609@chrisserafin.com>
Message-ID: <49D0F449.7050503@chrisserafin.com>

ChrisSerafin wrote:
> That does sound correct, I will schedule some testing time, thanks for 
> your input!
>
> David Freedman wrote:
>> Chris, the key thing here are the vrf address-families
>> "> address-family ipv4 vrf xxxx-Voice" e.g
>>
>> Imagine these like the equivalent of the normal ipv4 address-family, but
>> for each VRF process.
>>
>> These do not currently have "redistribute static" in them so you can
>> quite safely install "ip route vrf xxxx-Voice 0.0.0.0 0.0.0.0 x.x.x.x"
>> and then this will not be injected into the VRF through BGP until you
>> add "redistribute static" into the appropriate address-family
>>
>> if I'm reading your post right?
>>
>>
>>
>> ChrisSerafin wrote:
>>  
>>> I have a Sprint MPLS cloud for which they extend the VRF configs 
>>> down to
>>> the CE. I am in the middle of divesting a section of these MPLS
>>> routers/subnets off of the main cloud and onto their own VRFs. I
>>> essentially want to start by making a handfull of the sites, change
>>> their default route for Internet. Normally I would just add a new 
>>> static
>>> route and then NOT use 'redistribute static' in the BGP config, but 
>>> this
>>> whole VRF is new to me.
>>>
>>> Any thoughts would be great! Thanks:
>>>
>>> ip cef
>>> !
>>> !
>>> ip vrf xxxx-General
>>> rd 1:10
>>> route-target export 1:10
>>> route-target import 1:10
>>> !
>>> ip vrf xxxx-Guest
>>> rd 1:30
>>> route-target export 1:30
>>> route-target import 1:30
>>> !
>>> ip vrf xxxx-Voice
>>> rd 1:20
>>> route-target export 1:20
>>> route-target import 1:20
>>> !
>>>
>>> !
>>> !
>>> !
>>> !
>>> !
>>> !
>>> interface Loopback0
>>> ip address 10.10.10.10 255.255.255.255
>>> !
>>> !
>>> interface GigabitEthernet0/0
>>> description [ Link to Core Switch ]
>>> no ip address
>>> duplex auto
>>> speed auto
>>> !
>>> interface GigabitEthernet0/0.1
>>> description [ VLAN 1 - General xxxx Data VLAN ]
>>> encapsulation dot1Q 1 native
>>> ip vrf forwarding xxxx-General
>>> ip address 10.120.64.1 255.255.255.0
>>> ip virtual-reassembly
>>> !
>>> interface GigabitEthernet0/0.100
>>> description [ VLAN 100 - General xxxx Voice VLAN ]
>>> encapsulation dot1Q 100
>>> ip vrf forwarding xxxx-Voice
>>> ip address 10.121.64.1 255.255.255.0
>>> !
>>> interface GigabitEthernet0/0.200
>>> description [ VLAN 200 - General xxxx Guest VLAN ]
>>> encapsulation dot1Q 200
>>> ip vrf forwarding xxxx-Guest
>>> ip address 172.16.10.1 255.255.255.0
>>> !
>>> !
>>> interface Serial0/0/0:1
>>> no ip address
>>> encapsulation frame-relay
>>> shutdown
>>> frame-relay lmi-type ansi
>>> !
>>> interface Serial0/1/0
>>> description [ Sprint MPLS Circuit ]
>>> no ip address
>>> encapsulation frame-relay
>>> frame-relay lmi-type ansi
>>> service-policy output VOIP-WAN
>>> !
>>> interface Serial0/1/0.310 point-to-point
>>> description [ MPLS VRF - Data VLAN ]
>>> ip vrf forwarding xxxx-General
>>> ip address 10.150.1.37 255.255.255.252
>>> snmp trap link-status
>>> frame-relay interface-dlci 310  !
>>> interface Serial0/1/0.410 point-to-point
>>> description [ MPLS VRF - Voice VLAN ]
>>> ip vrf forwarding xxxx-Voice
>>> ip address 10.151.1.37 255.255.255.252
>>> snmp trap link-status
>>> frame-relay interface-dlci 410  !
>>> interface Serial0/1/0.510 point-to-point
>>> description [ MPLS VRF - Guest VLAN ]
>>> ip vrf forwarding xxxx-Guest
>>> ip address 10.152.1.37 255.255.255.252
>>> snmp trap link-status
>>> frame-relay interface-dlci 510  !
>>> router eigrp 217
>>> no auto-summary
>>> !
>>> address-family ipv4 vrf xxxx-General
>>>  network 10.11.0.0 0.0.0.255
>>>  network 10.120.64.0 0.0.0.255
>>>  no auto-summary
>>>  autonomous-system 19
>>> exit-address-family
>>> eigrp router-id 1.1.1.2
>>> eigrp event-logging
>>> !
>>> router bgp 65010
>>> bgp log-neighbor-changes
>>> neighbor 10.150.1.38 remote-as 1803
>>> neighbor 10.150.1.38 password 7 153E020A1xx373C3627
>>> neighbor 10.150.1.38 version 4
>>> !
>>> address-family ipv4
>>>  neighbor 10.150.1.38 activate
>>>  no auto-summary
>>>  no synchronization
>>> exit-address-family
>>> !
>>> address-family ipv4 vrf xxxx-Voice
>>>  neighbor 10.151.1.38 remote-as 1803
>>>  neighbor 10.151.1.38 password 7 0328520Dxx205F5A0C0B
>>>  neighbor 10.151.1.38 version 4
>>>  neighbor 10.151.1.38 activate
>>>  no synchronization
>>> exit-address-family
>>> !
>>> address-family ipv4 vrf xxxx-Guest
>>>  neighbor 10.152.1.38 remote-as 1803
>>>  neighbor 10.152.1.38 password 7 013F0F024xx071C35495C
>>>  neighbor 10.152.1.38 version 4
>>>  neighbor 10.152.1.38 activate
>>>  no synchronization
>>> exit-address-family
>>> !
>>> address-family ipv4 vrf xxxx-General
>>>  neighbor 10.150.1.38 remote-as 1803
>>>  neighbor 10.150.1.38 password 7 047702001xx4D5D1D1C17
>>>  neighbor 10.150.1.38 version 4
>>>  neighbor 10.150.1.38 activate
>>>  no synchronization
>>>  network 10.120.64.0 mask 255.255.255.0
>>> exit-address-family
>>>
>>>
>>> thanks,
>>>
>>> Chris
>>>
This router is currently using it's own egress point for Internet, which 
is what I am trying to change. Their is a static route for the correct 
VRF, and points to the next hop which is a layer 2 hop out the 
'internal' interface on the router. BGP is running for the VRF's EIGRP 
is configured but not working since the upstream ISP is not listening 
(wasn't me!)

ip route vrf Chmbr-General 0.0.0.0 0.0.0.0 10.120.24.2 ! This is an ASA 
on the 'LAN' for this site
ip route vrf Chmbr-General 10.0.0.0 255.0.0.0 Serial0/1/0.310

So I remove the static route pointing to 10.120.24.2 and point it to the 
remote MPLS spoke, 10.120.24.2.

ip route vrf Chmbr-General 0.0.0.0 0.0.0.0 10.120.112.2 ! This is a 
different FW at a remote MPLS spoke
ip route vrf Chmbr-General 10.0.0.0 255.0.0.0 Serial0/1/0.310


Traceroutes after the change show that it is using the main egress route 
going out the US, which is a gateway of last resort being propagated via 
BGP/VRF. I was hoping that the static route I added would take 
precedence over any BGP route, even though the new default route to 
10.120.112.2 goes out to the cloud to get to the other remote MPLS spoke.

Any Ideas?






From david.freedman at uk.clara.net  Mon Mar 30 13:28:25 2009
From: david.freedman at uk.clara.net (David Freedman)
Date: Mon, 30 Mar 2009 18:28:25 +0100
Subject: [c-nsp] How not to redistribute statics into VRFs/BGP
References: <49C90D26.2050604@chrisserafin.com> <gqb6jb$te$1@ger.gmane.org>
	<49C92013.4070609@chrisserafin.com>
	<49D0F449.7050503@chrisserafin.com>
Message-ID: <1BD38DD97E9BEB40A599BFCCED93CC7F478079@EXVS01.claranet.local>

>ip route vrf Chmbr-General 0.0.0.0 0.0.0.0 10.120.24.2 ! This is an ASA
>on the 'LAN' for this site
>ip route vrf Chmbr-General 10.0.0.0 255.0.0.0 Serial0/1/0.310

Right, got you so far

>So I remove the static route pointing to 10.120.24.2 and point it to the
>remote MPLS spoke, 10.120.24.2.

You mean 10.120.112.2? 

>ip route vrf Chmbr-General 0.0.0.0 0.0.0.0 10.120.112.2 ! This is a
>different FW at a remote MPLS spoke
>ip route vrf Chmbr-General 10.0.0.0 255.0.0.0 Serial0/1/0.310

So both 10.120.24.2 and 10.120.112.2 are at the remote site?
any chance you can knock up a small ascii diagram else it gets a bit confusing.

>Traceroutes after the change show that it is using the main egress route
>going out the US, which is a gateway of last resort being propagated via
>BGP/VRF. 

US? 

How are you tracerouting? using "traceroute vrf Chmbr-General x.x.x.x" command?

Also worth noting that since you are doing what is called "recursive" routing here
(i.e point default at something which is also pointed at an interface) your traffic
will always go via Serial0/1/0.310 and onto your MPLS provider , anything past this
you have no direct influence over (usually) and hence you will need to have them change the
way the default is advertised into their VRF as well.

Does this make sense?

Dave.


From chris at chrisserafin.com  Mon Mar 30 13:48:31 2009
From: chris at chrisserafin.com (ChrisSerafin)
Date: Mon, 30 Mar 2009 12:48:31 -0500
Subject: [c-nsp] How not to redistribute statics into VRFs/BGP
In-Reply-To: <1BD38DD97E9BEB40A599BFCCED93CC7F478079@EXVS01.claranet.local>
References: <49C90D26.2050604@chrisserafin.com> <gqb6jb$te$1@ger.gmane.org>
	<49C92013.4070609@chrisserafin.com>
	<49D0F449.7050503@chrisserafin.com>
	<1BD38DD97E9BEB40A599BFCCED93CC7F478079@EXVS01.claranet.local>
Message-ID: <49D105EF.1050707@chrisserafin.com>

David Freedman wrote:
>
> >ip route vrf Chmbr-General 0.0.0.0 0.0.0.0 10.120.24.2 ! This is an ASA
> >on the 'LAN' for this site
> >ip route vrf Chmbr-General 10.0.0.0 255.0.0.0 Serial0/1/0.310
>
> Right, got you so far
>
> >So I remove the static route pointing to 10.120.24.2 and point it to the
> >remote MPLS spoke, 10.120.24.2.
>
> You mean 10.120.112.2?
>

Yes, I'm sorry
>
>
> >ip route vrf Chmbr-General 0.0.0.0 0.0.0.0 10.120.112.2 ! This is a
> >different FW at a remote MPLS spoke
> >ip route vrf Chmbr-General 10.0.0.0 255.0.0.0 Serial0/1/0.310
>
> So both 10.120.24.2 and 10.120.112.2 are at the remote site?
> any chance you can knock up a small ascii diagram else it gets a bit 
> confusing.
>

> >Traceroutes after the change show that it is using the main egress route
> >going out the US, which is a gateway of last resort being propagated via
> >BGP/VRF.
>
> US?
>
USA
>
>
> How are you tracerouting? using "traceroute vrf Chmbr-General x.x.x.x" 
> command?
>
Yes I am doing this.
>
>
> Also worth noting that since you are doing what is called "recursive" 
> routing here
> (i.e point default at something which is also pointed at an interface) 
> your traffic
> will always go via Serial0/1/0.310 and onto your MPLS provider , 
> anything past this
> you have no direct influence over (usually) and hence you will need to 
> have them change the
> way the default is advertised into their VRF as well.
>
> Does this make sense?
>
Yes/Maybe :) .......All 10.x.x.x traffic should be thrown out the 
serial0/1/0.310 interface, out to the MPLS cloud. I'm engaging the ISP 
to see if 'we' are advertising the default route or the ISP is.


THANKS for your comments!




From ssaner at pantheranet.com  Mon Mar 30 15:07:57 2009
From: ssaner at pantheranet.com (Steven Saner)
Date: Mon, 30 Mar 2009 14:07:57 -0500
Subject: [c-nsp] Multilink PPPoA
Message-ID: <5FE5BC34-7ECD-4905-B0FD-42C124C54DCC@pantheranet.com>

I am trying to configure multilink PPPoA of two ADSL circuits. At the  
head end I have a 7206 and at the client end a 1721. I do have PPPoA  
working on a single circuit, but it isn't quite clear to me if I can  
bind two circuits using MPP and how to do it. There are quite a few  
working PPPoA circuits in production on the head end, so I am hoping  
to minimize the amount of trial and error experimenting on that side  
at least.

I looked at this list's archives and see that this topic has been  
discussed before, but with little in the way of examples or  
documentation of how to do it. If someone would care to share some  
config examples or point me in the direction of some useful  
documentation, I would be grateful.

Thanks.

Steve

--
---------------------------------------------------------------
Steven Saner
ssaner at pantheranet.com






From eng_mssk at hotmail.com  Mon Mar 30 15:53:07 2009
From: eng_mssk at hotmail.com (Mohammad Khalil)
Date: Mon, 30 Mar 2009 22:53:07 +0300
Subject: [c-nsp] Subnet Traffic
Message-ID: <BLU102-W18A6D1C426EFE0F24D53E6FA8D0@phx.gbl>


Hey all , 
we have multiple international links , and we have multiple customers with their own subnets in addition to our subnets
is there a way to know how much each subnet consumes traffic ?
is there any way to draw this traffic /per subnet ?
thanks in advance

Best Regards,
Mohammad Khalil

_________________________________________________________________
News, entertainment and everything you care about at Live.com. Get it now!
http://www.live.com/getstarted.aspx

From llc at dansketelecom.com  Mon Mar 30 16:07:58 2009
From: llc at dansketelecom.com (Lars Lystrup Christensen)
Date: Mon, 30 Mar 2009 22:07:58 +0200
Subject: [c-nsp] Subnet Traffic
In-Reply-To: <BLU102-W18A6D1C426EFE0F24D53E6FA8D0@phx.gbl>
References: <BLU102-W18A6D1C426EFE0F24D53E6FA8D0@phx.gbl>
Message-ID: <44417CD2F19FEA4F885088340A71D33201C902B8@mail.office.dansketelecom.com>

Hi Mohammad

Netflow is probably the best solution for you. Take some time to explore it on CCO.

______________________________________

Med venlig hilsen / Kind regards

Lars Lystrup Christensen 
Director of Engineering, CCIE(tm) #20292

Danske Telecom A/S
Sundkrogsgade 13, 4 
2100 K?benhavn ? 


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Mohammad Khalil
Sent: 30. marts 2009 21:53
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Subnet Traffic


Hey all , 
we have multiple international links , and we have multiple customers with their own subnets in addition to our subnets
is there a way to know how much each subnet consumes traffic ?
is there any way to draw this traffic /per subnet ?
thanks in advance

Best Regards,
Mohammad Khalil

_________________________________________________________________
News, entertainment and everything you care about at Live.com. Get it now!
http://www.live.com/getstarted.aspx
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From Charles at thewybles.com  Mon Mar 30 16:15:23 2009
From: Charles at thewybles.com (Charles at thewybles.com)
Date: Mon, 30 Mar 2009 20:15:23 +0000
Subject: [c-nsp] Subnet Traffic
Message-ID: <540111142-1238444150-cardhu_decombobulator_blackberry.rim.net-89708013-@bxe1302.bisx.prod.on.blackberry>

Put each subnet in its own vlan and use netflow? 
------Original Message------
From: Mohammad Khalil
Sender: cisco-nsp-bounces at puck.nether.net
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Subnet Traffic
Sent: Mar 30, 2009 12:53 PM


Hey all , 
we have multiple international links , and we have multiple customers with their own subnets in addition to our subnets
is there a way to know how much each subnet consumes traffic ?
is there any way to draw this traffic /per subnet ?
thanks in advance

Best Regards,
Mohammad Khalil

_________________________________________________________________
News, entertainment and everything you care about at Live.com. Get it now!
http://www.live.com/getstarted.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/



Sent via BlackBerry from T-Mobile

From jeff-kell at utc.edu  Mon Mar 30 16:20:11 2009
From: jeff-kell at utc.edu (Jeff Kell)
Date: Mon, 30 Mar 2009 16:20:11 -0400
Subject: [c-nsp] 3750/3750E stack upgrade downtime?
Message-ID: <49D1297B.2080106@utc.edu>

Is there any way to "roll" an upgrade out to a 3750 stack without
abruptly rebooting the entire stack? 

I've done the images, but this is our first production "reload" of a
stack...  I've slept since the initial deployment/upgrade...

Jeff

From eng_mssk at hotmail.com  Mon Mar 30 16:25:11 2009
From: eng_mssk at hotmail.com (Mohammad Khalil)
Date: Mon, 30 Mar 2009 23:25:11 +0300
Subject: [c-nsp] Subnet Traffic
In-Reply-To: <540111142-1238444150-cardhu_decombobulator_blackberry.rim.net-89708013-@bxe1302.bisx.prod.on.blackberry>
References: <540111142-1238444150-cardhu_decombobulator_blackberry.rim.net-89708013-@bxe1302.bisx.prod.on.blackberry>
Message-ID: <BLU102-W10680784533DE6F927154EFA8D0@phx.gbl>


The subnets are mostly advertised via BGP


> To: eng_mssk at hotmail.com; cisco-nsp-bounces at puck.nether.net; cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] Subnet Traffic
> From: Charles at thewybles.com
> Date: Mon, 30 Mar 2009 20:15:23 +0000
> 
> Put each subnet in its own vlan and use netflow? 
> ------Original Message------
> From: Mohammad Khalil
> Sender: cisco-nsp-bounces at puck.nether.net
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] Subnet Traffic
> Sent: Mar 30, 2009 12:53 PM
> 
> 
> Hey all , 
> we have multiple international links , and we have multiple customers with their own subnets in addition to our subnets
> is there a way to know how much each subnet consumes traffic ?
> is there any way to draw this traffic /per subnet ?
> thanks in advance
> 
> Best Regards,
> Mohammad Khalil
> 
> _________________________________________________________________
> News, entertainment and everything you care about at Live.com. Get it now!
> http://www.live.com/getstarted.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/
> 
> 
> 
> Sent via BlackBerry from T-Mobile

_________________________________________________________________
More than messages?check out the rest of the Windows Live?.
http://www.microsoft.com/windows/windowslive/

From ip at ioshints.info  Mon Mar 30 16:39:31 2009
From: ip at ioshints.info (Ivan Pepelnjak)
Date: Mon, 30 Mar 2009 22:39:31 +0200
Subject: [c-nsp] Subnet Traffic
In-Reply-To: <540111142-1238444150-cardhu_decombobulator_blackberry.rim.net-89708013-@bxe1302.bisx.prod.on.blackberry>
References: <540111142-1238444150-cardhu_decombobulator_blackberry.rim.net-89708013-@bxe1302.bisx.prod.on.blackberry>
Message-ID: <001101c9b177$a20ee700$0a00000a@nil.si>

If you put each subnet in a VLAN, you could use interface counters.
Unfortunately, life is rarely so simple.

> -----Original Message-----
> From: Charles at thewybles.com [mailto:Charles at thewybles.com] 
> Sent: Monday, March 30, 2009 10:15 PM
> To: Mohammad Khalil; cisco-nsp-bounces at puck.nether.net; 
> cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] Subnet Traffic
> 
> Put each subnet in its own vlan and use netflow? 
> ------Original Message------
> From: Mohammad Khalil
> Sender: cisco-nsp-bounces at puck.nether.net
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] Subnet Traffic
> Sent: Mar 30, 2009 12:53 PM
> 
> 
> Hey all ,
> we have multiple international links , and we have multiple 
> customers with their own subnets in addition to our subnets 
> is there a way to know how much each subnet consumes traffic ?
> is there any way to draw this traffic /per subnet ?
> thanks in advance
> 
> Best Regards,
> Mohammad Khalil
> 
> _________________________________________________________________
> News, entertainment and everything you care about at 
> Live.com. Get it now!
> http://www.live.com/getstarted.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/
> 
> 
> 
> Sent via BlackBerry from T-Mobile
> 
> 


From llc at dansketelecom.com  Mon Mar 30 16:46:29 2009
From: llc at dansketelecom.com (Lars Lystrup Christensen)
Date: Mon, 30 Mar 2009 22:46:29 +0200
Subject: [c-nsp] Subnet Traffic
In-Reply-To: <BLU102-W10680784533DE6F927154EFA8D0@phx.gbl>
References: <540111142-1238444150-cardhu_decombobulator_blackberry.rim.net-89708013-@bxe1302.bisx.prod.on.blackberry>
	<BLU102-W10680784533DE6F927154EFA8D0@phx.gbl>
Message-ID: <44417CD2F19FEA4F885088340A71D33201C902BA@mail.office.dansketelecom.com>

In that case, it's quite easy... Just do aggregation based on source AS and use next-hop-as to determine the usage of traffic from each customer on you uplink peers.

______________________________________

Med venlig hilsen / Kind regards

Lars Lystrup Christensen 
Director of Engineering, CCIE(tm) #20292

Danske Telecom A/S
Sundkrogsgade 13, 4 
2100 K?benhavn ? 


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Mohammad Khalil
Sent: 30. marts 2009 22:25
To: charles at thewybles.com; cisco-nsp-bounces at puck.nether.net; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Subnet Traffic


The subnets are mostly advertised via BGP


> To: eng_mssk at hotmail.com; cisco-nsp-bounces at puck.nether.net; cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] Subnet Traffic
> From: Charles at thewybles.com
> Date: Mon, 30 Mar 2009 20:15:23 +0000
> 
> Put each subnet in its own vlan and use netflow? 
> ------Original Message------
> From: Mohammad Khalil
> Sender: cisco-nsp-bounces at puck.nether.net
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] Subnet Traffic
> Sent: Mar 30, 2009 12:53 PM
> 
> 
> Hey all , 
> we have multiple international links , and we have multiple customers with their own subnets in addition to our subnets
> is there a way to know how much each subnet consumes traffic ?
> is there any way to draw this traffic /per subnet ?
> thanks in advance
> 
> Best Regards,
> Mohammad Khalil
> 
> _________________________________________________________________
> News, entertainment and everything you care about at Live.com. Get it now!
> http://www.live.com/getstarted.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/
> 
> 
> 
> Sent via BlackBerry from T-Mobile

_________________________________________________________________
More than messages-check out the rest of the Windows Live(tm).
http://www.microsoft.com/windows/windowslive/
_______________________________________________
cisco-nsp mailing list  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  Mon Mar 30 16:45:16 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Mon, 30 Mar 2009 22:45:16 +0200
Subject: [c-nsp] 3750/3750E stack upgrade downtime?
In-Reply-To: <49D1297B.2080106@utc.edu>
References: <49D1297B.2080106@utc.edu>
Message-ID: <1238445916.4440.7.camel@localhost.localdomain>

On Mon, 2009-03-30 at 16:20 -0400, Jeff Kell wrote:
> Is there any way to "roll" an upgrade out to a 3750 stack without
> abruptly rebooting the entire stack? 

I would very much like to know if there is. AFAIK you can't complete the
upgrade without downtime. Two switches with even just rebuild version
differences can't live together in the same stack, so there's no chance
of upgrading without significant downtime.

We're starting to use 3750E with 10G trunks in between them instead of
Stackwise. This makes it possible to upgrade practically without
downtime.

Regards,
Peter



From rshughes at gmail.com  Mon Mar 30 17:33:20 2009
From: rshughes at gmail.com (Ryan Hughes)
Date: Mon, 30 Mar 2009 17:33:20 -0400
Subject: [c-nsp] 3750/3750E stack upgrade downtime?
In-Reply-To: <49D1297B.2080106@utc.edu>
References: <49D1297B.2080106@utc.edu>
Message-ID: <e44f1b0e0903301433g87767d0u38cbe793cde3350@mail.gmail.com>

This was discussed a few months back on list. ISSU isn't supported on the
3750's and to be honest, quite a few people have issues with stacks as is.
Cisco is driving ISSU with the modular switching platforms
(4500/6500/Nexus). What Peter describes with using the 10G links on the -E
series is definitely less worrysome than relying on stackwise.

I personnally have good experiences with the 3750's and used them quite
extensively at a previous job, however I have run into situations of where
the stack loses its master when doing upgrades and/or adding switches to the
stack.

Ryan

On Mon, Mar 30, 2009 at 4:20 PM, Jeff Kell <jeff-kell at utc.edu> wrote:

> Is there any way to "roll" an upgrade out to a 3750 stack without
> abruptly rebooting the entire stack?
>
> I've done the images, but this is our first production "reload" of a
> stack...  I've slept since the initial deployment/upgrade...
>
> Jeff
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From asturluismi at gmail.com  Mon Mar 30 17:37:53 2009
From: asturluismi at gmail.com (luismi)
Date: Mon, 30 Mar 2009 23:37:53 +0200
Subject: [c-nsp] 3750/3750E stack upgrade downtime?
In-Reply-To: <1238445916.4440.7.camel@localhost.localdomain>
References: <49D1297B.2080106@utc.edu>
	<1238445916.4440.7.camel@localhost.localdomain>
Message-ID: <1238449073.14874.4.camel@dsba-ipso>

Hi Peter,

I agree with you but in that case you loose the option to use
cross-etherchannel against the stack :-/


El lun, 30-03-2009 a las 22:45 +0200, Peter Rathlev escribi?:
> On Mon, 2009-03-30 at 16:20 -0400, Jeff Kell wrote:
> > Is there any way to "roll" an upgrade out to a 3750 stack without
> > abruptly rebooting the entire stack? 
> 
> I would very much like to know if there is. AFAIK you can't complete the
> upgrade without downtime. Two switches with even just rebuild version
> differences can't live together in the same stack, so there's no chance
> of upgrading without significant downtime.
> 
> We're starting to use 3750E with 10G trunks in between them instead of
> Stackwise. This makes it possible to upgrade practically without
> downtime.
> 
> 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 achatz at forthnet.gr  Mon Mar 30 18:14:49 2009
From: achatz at forthnet.gr (Tassos Chatzithomaoglou)
Date: Tue, 31 Mar 2009 01:14:49 +0300
Subject: [c-nsp] Y.1731 frame loss measurement on Cisco
In-Reply-To: <a89d89ac0903271126p3ae8fa30t78bd3a20f42bc0d9@mail.gmail.com>
References: <a89d89ac0903271126p3ae8fa30t78bd3a20f42bc0d9@mail.gmail.com>
Message-ID: <49D14459.6000101@forthnet.gr>

Marlon,

Current Y.1731 implementation supports mainly fault management (i.e. ETH-AIS, ETH-RDI).
For performance management we use IP SLA for CFM (ping/jitter), which works fine in our case:
http://www.cisco.com/en/US/docs/ios/12_2sr/12_2srb/feature/guide/sr_meth.html#wp1056192

-- 
Tassos

Marlon Duksa wrote on 27/03/2009 20:26:
> Hi  - does anyone know if Cisco 7600/GSR/CRS  platforms support Y.1731
> standard, I'm particularly interested in frame loss measurement?Thanks,
> Marlon
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 


From jason at lixfeld.ca  Mon Mar 30 17:47:15 2009
From: jason at lixfeld.ca (Jason Lixfeld)
Date: Mon, 30 Mar 2009 17:47:15 -0400
Subject: [c-nsp] Multilink PPPoA
In-Reply-To: <5FE5BC34-7ECD-4905-B0FD-42C124C54DCC@pantheranet.com>
References: <5FE5BC34-7ECD-4905-B0FD-42C124C54DCC@pantheranet.com>
Message-ID: <F1BF3051-4E06-439D-B51D-66C5D22CF88F@lixfeld.ca>

I actually just set this up on the weekend.  You can use virtual- 
template 1 ip unnumbered with an ip pool on the headend and dialer0 ip  
address negotiated on the client too if you don't want statically  
routed clients.

Headend:
!
username * password *
!
vpdn enable
!
vpdn-group 1
  accept-dialin
   protocol pppoe
   virtual-template 1
!
ip tcp path-mtu-discovery
!
interface FastEthernet1/0.10
  encapsulation dot1Q 10
  ip address 1.1.1.1 255.255.255.255
  ip nat outside
  ip policy route-map RAVPN
  crypto map VPN
!
interface FastEthernet1/0.636
  encapsulation dot1Q 636
  pppoe enable
!
interface FastEthernet1/0.637
  encapsulation dot1Q 637
  pppoe enable
!
interface Virtual-Template1
  ip address 172.17.100.1 255.255.255.0
  ip nat inside
  peer default ip address PPPoE
  ppp authentication chap
  ppp multilink
!

Client:
!
vpdn enable
!
vpdn-group 1
  accept-dialin
   protocol pppoe
!
ip tcp path-mtu-discovery
!
interface FastEthernet0/0
  ip address 192.168.100.1 255.255.255.0
  ip tcp adjust-mss 1452
  load-interval 30
  duplex auto
  speed auto
!
interface ATM0/0
  no ip address
  load-interval 30
  no atm ilmi-keepalive
  dsl operating-mode auto
!
interface ATM0/0.1 point-to-point
  no ip redirects
  no ip unreachables
  atm route-bridged ip
  pvc 0/35
   tx-ring-limit 3
   oam-pvc 10
   encapsulation aal5snap
   pppoe-client dial-pool-number 1
  !
!
interface ATM0/1
  no ip address
  load-interval 30
  no atm ilmi-keepalive
  dsl operating-mode auto
!
interface ATM0/1.1 point-to-point
  no ip redirects
  no ip unreachables
  atm route-bridged ip
  pvc 0/35
   tx-ring-limit 3
   oam-pvc 10
   encapsulation aal5snap
   pppoe-client dial-pool-number 1
  !
!
interface Dialer0
  ip address 172.17.100.2 255.255.255.0
  ip mtu 1492
  encapsulation ppp
  dialer pool 1
  dialer-group 1
  ppp authentication chap callin
  ppp chap hostname *
  ppp chap password 0 *
  ppp multilink
!
dialer-list 1 protocol ip permit
!

On 30-Mar-09, at 3:07 PM, Steven Saner wrote:

> I am trying to configure multilink PPPoA of two ADSL circuits. At  
> the head end I have a 7206 and at the client end a 1721. I do have  
> PPPoA working on a single circuit, but it isn't quite clear to me if  
> I can bind two circuits using MPP and how to do it. There are quite  
> a few working PPPoA circuits in production on the head end, so I am  
> hoping to minimize the amount of trial and error experimenting on  
> that side at least.
>
> I looked at this list's archives and see that this topic has been  
> discussed before, but with little in the way of examples or  
> documentation of how to do it. If someone would care to share some  
> config examples or point me in the direction of some useful  
> documentation, I would be grateful.
>
> Thanks.
>
> Steve
>
> --
> ---------------------------------------------------------------
> Steven Saner
> ssaner at pantheranet.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 walter.keen at RainierConnect.net  Sat Mar 21 12:09:29 2009
From: walter.keen at RainierConnect.net (Walter Keen)
Date: Sat, 21 Mar 2009 09:09:29 -0700
Subject: [c-nsp] Freeware management software
Message-ID: <10bb01c9aa3f$69b64cdd$2c0011ac@RainierConnect.local>

Try nagios or opennms, each are a little different.  Nagios is a bit more customizable in service checks, but perhaps that has changed in the last few releases 

Walter Keen
NETWORK TECHNICIAN
RAINIER CONNECT


-----Original Message-----
From: Arne Larsen / Region Nordjylland <arla at rn.dk>
Sent: Saturday, March 21, 2009 8:47 AM
To: cisco-nsp at puck.nether.net <cisco-nsp at puck.nether.net>
Subject: [c-nsp] Freeware management software

Hi Folks.

Can someone give me a hint, I'm looking for freeware management software like NMIS.
Software that can provide reachability, availablility an health scores.
NMIS Dashboard doesn't seem to scale in large network.
I like the dashboard off NMIS, it's easy for anyone to understand the red & green function..
But it can't discover devices, it's a static configuration imnplementing NMIS.
Does anyone know off freeware software ala HP Openview.


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

From skeeve at eintellego.net  Mon Mar 30 22:44:25 2009
From: skeeve at eintellego.net (Skeeve Stevens)
Date: Tue, 31 Mar 2009 13:44:25 +1100
Subject: [c-nsp] Cisco 7970 Screen Saver wake on ring
Message-ID: <292AF25E62B8894C921B893B53A19D97394469DF87@BUSINESSEX.business.ad>

Hey all,

This is a little question which is driving me nuts.... and my google-fu isn't working.

My 7970 (hanging off an Asterisk box) has a screen saver... which is nice.... but when the phone rings, the screen stays blank.

I don't know if I should be answering it if it is blank... currently I have to reach over and push the lit screen button to bring the screen back.

Is there any 'wake screen on ring' option on the handset that anyone knows?

...Skeeve

--
Skeeve Stevens, CEO/Technical Director
eintellego Pty Ltd - The Networking Specialists
skeeve at eintellego.net / www.eintellego.net
Phone: 1300 753 383, Fax: (+612) 8572 9954
Cell +61 (0)414 753 383 / skype://skeeve
--
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 jay at west.net  Tue Mar 31 00:41:18 2009
From: jay at west.net (Jay Hennigan)
Date: Mon, 30 Mar 2009 21:41:18 -0700
Subject: [c-nsp] ATM on 7206 - PVC < 255 "BICI" ?
Message-ID: <49D19EEE.5030305@west.net>

We have a DSL aggregation circuit terminating on a PA-A3-OC3SMI in a 
7206VXR.   Our provider is delivering PVCs with a VP of 450.  As far as 
I can tell IOS won't support VPs over 255.

The provider referring to a "BICI" interface connection type.  Is there 
support for this on the 7206 platform or do we need to have them use VP 
of 255 or less?

I found some reference to BICI on CCO but nothing specific.

--
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 skoal at skoal.name  Tue Mar 31 02:54:47 2009
From: skoal at skoal.name (Gergely Antal)
Date: Tue, 31 Mar 2009 08:54:47 +0200
Subject: [c-nsp] 10GE card for 7609
In-Reply-To: <20090330151600.GA408@roxanne.org>
References: <863386.41277.qm@web44809.mail.sp1.yahoo.com>
	<20090330151600.GA408@roxanne.org>
Message-ID: <49D1BE37.8060402@skoal.name>

And also keep in mind that WS-X6708-10GE is a true line-rate card...

Eric Gauthier wrote:
> Mark,
> 
> I'm not sure if you have other 10g links, but keep in mind that Cisco has 
> (at least) two 10g optics - Xenpak and X2 - that are not intercompatible.  
> I believe that the 6704-10ge uses Xenpak and the 6708-10gE, which is the
> "same" card but with 8 ports, uses X2.  If everything else you do is X2,
> it might make sense to jump up to the 8 port card to prevent yourself
> from having to buy/spare two types of optics.
> 
> Eric :)
> 
> 
> On Mon, Mar 30, 2009 at 02:41:12AM -0700, Mark Tech wrote:
>> Hi
>> I have a prospect for a 10G upstream customer and Upstream ISP connections. I would need to connect these into our 7609s running RSP 720-3CXL's, at the moment I have found that the WS-X6704-10GE card may be suitable.
>>
>> My technical requirements are:
>> 10Gbps line rate
>> IPv4
>> Able to handle full Internet routing table
>> Potentially IPv6 and MPLS in the future
>>
>> With the WS-X6704-10GE, there seems to be several options that are available with it i.e.
>>
>> Memory Option: 
>> MEM-XCEF720-256M 
>> Catalyst 6500 256MB DDR, xCEF720 (67xx interface, DFC3A) 
>> MEM-XCEF720-512M 
>> Cat 6500 512MB DDR, xCEF720 (67xx interface, DFC3A/DFC3B)  
>> MEM-XCEF720-1GB 
>> Catalyst 6500 1GB DDR, xCEF720 (67xx interface, DFC3BXL) 
>>
>> ====================================================
>> Distributed Forwarding Card Option
>>
>> WS-F6700-CFC 
>> Catalyst 6500 Central Fwd Card for WS-X67xx modules 
>> WS-F6700-DFC3B 
>> Catalyst 6500 Dist Fwd Card, 256K Routes for WS-X67xx  
>> WS-F6700-DFC3A 
>> Catalyst 6500 Dist Fwd Card for WS-X67xx modules 
>> WS-F6700-DFC3BXL 
>> Catalyst 6500 Dist Fwd Card- 3BXL, for WS-X67xx 
>> WS-F6700-DFC3C 
>> Catalyst 6500 Dist Fwd Card for WS-X67xx modules 
>> WS-F6700-DFC3CXL 
>> Catalyst 6500 Dist Fwd Card- 3CXL, for WS-X67xx
>>
>> I assume that I would need MEM-XCEF720-1GB and WS-F6700-DFC3CXL?
>>
>> Regards
>>
>> 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/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090331/ed780bc1/attachment.bin>

From paul at paulstewart.org  Tue Mar 31 03:02:40 2009
From: paul at paulstewart.org (Paul Stewart)
Date: Tue, 31 Mar 2009 03:02:40 -0400
Subject: [c-nsp] 10GE card for 7609
In-Reply-To: <49D1BE37.8060402@skoal.name>
References: <863386.41277.qm@web44809.mail.sp1.yahoo.com>	<20090330151600.GA408@roxanne.org>
	<49D1BE37.8060402@skoal.name>
Message-ID: <000901c9b1ce$af671ec0$0e355c40$@org>

I don't have the spec sheets handy but I do believe though that the 6708 is
1:2 oversubscribed though correct?  The 6704 is 1:1 if that's important to
the application....

Paul


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Gergely Antal
Sent: Tuesday, March 31, 2009 2:55 AM
To: Eric Gauthier
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] 10GE card for 7609

And also keep in mind that WS-X6708-10GE is a true line-rate card...

Eric Gauthier wrote:
> Mark,
> 
> I'm not sure if you have other 10g links, but keep in mind that Cisco 
> has (at least) two 10g optics - Xenpak and X2 - that are not
intercompatible.
> I believe that the 6704-10ge uses Xenpak and the 6708-10gE, which is 
> the "same" card but with 8 ports, uses X2.  If everything else you do 
> is X2, it might make sense to jump up to the 8 port card to prevent 
> yourself from having to buy/spare two types of optics.
> 
> Eric :)
> 
> 
> On Mon, Mar 30, 2009 at 02:41:12AM -0700, Mark Tech wrote:
>> Hi
>> I have a prospect for a 10G upstream customer and Upstream ISP
connections. I would need to connect these into our 7609s running RSP
720-3CXL's, at the moment I have found that the WS-X6704-10GE card may be
suitable.
>>
>> My technical requirements are:
>> 10Gbps line rate
>> IPv4
>> Able to handle full Internet routing table Potentially IPv6 and MPLS 
>> in the future
>>
>> With the WS-X6704-10GE, there seems to be several options that are
available with it i.e.
>>
>> Memory Option: 
>> MEM-XCEF720-256M
>> Catalyst 6500 256MB DDR, xCEF720 (67xx interface, DFC3A) 
>> MEM-XCEF720-512M Cat 6500 512MB DDR, xCEF720 (67xx interface, 
>> DFC3A/DFC3B) MEM-XCEF720-1GB Catalyst 6500 1GB DDR, xCEF720 (67xx 
>> interface, DFC3BXL)
>>
>> ====================================================
>> Distributed Forwarding Card Option
>>
>> WS-F6700-CFC
>> Catalyst 6500 Central Fwd Card for WS-X67xx modules WS-F6700-DFC3B 
>> Catalyst 6500 Dist Fwd Card, 256K Routes for WS-X67xx WS-F6700-DFC3A 
>> Catalyst 6500 Dist Fwd Card for WS-X67xx modules WS-F6700-DFC3BXL 
>> Catalyst 6500 Dist Fwd Card- 3BXL, for WS-X67xx WS-F6700-DFC3C 
>> Catalyst 6500 Dist Fwd Card for WS-X67xx modules WS-F6700-DFC3CXL 
>> Catalyst 6500 Dist Fwd Card- 3CXL, for WS-X67xx
>>
>> I assume that I would need MEM-XCEF720-1GB and WS-F6700-DFC3CXL?
>>
>> Regards
>>
>> Mark
>>
>>
>>       
>>
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net 
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net 
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/



From gert at greenie.muc.de  Tue Mar 31 03:46:20 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Tue, 31 Mar 2009 09:46:20 +0200
Subject: [c-nsp] 10GE card for 7609
In-Reply-To: <49D1BE37.8060402@skoal.name>
References: <863386.41277.qm@web44809.mail.sp1.yahoo.com>
	<20090330151600.GA408@roxanne.org> <49D1BE37.8060402@skoal.name>
Message-ID: <20090331074620.GV290@greenie.muc.de>

Hi,

On Tue, Mar 31, 2009 at 08:54:47AM +0200, Gergely Antal wrote:
> And also keep in mind that WS-X6708-10GE is a true line-rate card...

Hardly.

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/20090331/62aadd36/attachment.bin>

From skoal at skoal.name  Tue Mar 31 04:01:24 2009
From: skoal at skoal.name (Gergely Antal)
Date: Tue, 31 Mar 2009 10:01:24 +0200
Subject: [c-nsp] 10GE card for 7609
In-Reply-To: <20090331074620.GV290@greenie.muc.de>
References: <863386.41277.qm@web44809.mail.sp1.yahoo.com>
	<20090330151600.GA408@roxanne.org> <49D1BE37.8060402@skoal.name>
	<20090331074620.GV290@greenie.muc.de>
Message-ID: <49D1CDD4.3080301@skoal.name>

I meant that you can not push 40G out of a 6704
even with a dfc attached to it.But you can do it with a 6708
with 1:1 subscription.

Gert Doering wrote:
> Hi,
> 
> On Tue, Mar 31, 2009 at 08:54:47AM +0200, Gergely Antal wrote:
>> And also keep in mind that WS-X6708-10GE is a true line-rate card...
> 
> Hardly.
> 
> gert

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090331/0a3a20c9/attachment.bin>

From gary.ciscomail at gmail.com  Tue Mar 31 04:17:50 2009
From: gary.ciscomail at gmail.com (Gary Roberton)
Date: Tue, 31 Mar 2009 09:17:50 +0100
Subject: [c-nsp] IP Address management software
Message-ID: <cf9098540903310117l724411e8h89bc05630d076ab7@mail.gmail.com>

Hello all

What IP address management software do you use to control the allocation of
subnets to your customers/department?

Thanks

Gary

From achatz at forthnet.gr  Tue Mar 31 04:28:41 2009
From: achatz at forthnet.gr (Tassos Chatzithomaoglou)
Date: Tue, 31 Mar 2009 11:28:41 +0300
Subject: [c-nsp] 10GE card for 7609
In-Reply-To: <49D1CDD4.3080301@skoal.name>
References: <863386.41277.qm@web44809.mail.sp1.yahoo.com>	<20090330151600.GA408@roxanne.org>
	<49D1BE37.8060402@skoal.name>	<20090331074620.GV290@greenie.muc.de>
	<49D1CDD4.3080301@skoal.name>
Message-ID: <49D1D439.8080509@forthnet.gr>

Why is that? Small (16MB) buffers?
We are at about 32G without any problem until now.

-- 
Tassos

Gergely Antal wrote on 31/03/2009 11:01:
> I meant that you can not push 40G out of a 6704
> even with a dfc attached to it.But you can do it with a 6708
> with 1:1 subscription.
> 
> Gert Doering wrote:
>> Hi,
>>
>> On Tue, Mar 31, 2009 at 08:54:47AM +0200, Gergely Antal wrote:
>>> And also keep in mind that WS-X6708-10GE is a true line-rate card...
>> Hardly.
>>
>> 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/



From asturluismi at gmail.com  Tue Mar 31 04:29:19 2009
From: asturluismi at gmail.com (luismi)
Date: Tue, 31 Mar 2009 10:29:19 +0200
Subject: [c-nsp] IP Address management software
In-Reply-To: <cf9098540903310117l724411e8h89bc05630d076ab7@mail.gmail.com>
References: <cf9098540903310117l724411e8h89bc05630d076ab7@mail.gmail.com>
Message-ID: <1238488159.7827.0.camel@dsba-ipso>

We use here IPPlan.

El mar, 31-03-2009 a las 09:17 +0100, Gary Roberton escribi?:
> Hello all
> 
> What IP address management software do you use to control the allocation of
> subnets to your customers/department?
> 
> Thanks
> 
> Gary
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


From saku+cisco-nsp at ytti.fi  Tue Mar 31 03:47:40 2009
From: saku+cisco-nsp at ytti.fi (Saku Ytti)
Date: Tue, 31 Mar 2009 10:47:40 +0300
Subject: [c-nsp] 10GE card for 7609
In-Reply-To: <000901c9b1ce$af671ec0$0e355c40$@org>
References: <863386.41277.qm@web44809.mail.sp1.yahoo.com>
	<20090330151600.GA408@roxanne.org> <49D1BE37.8060402@skoal.name>
	<000901c9b1ce$af671ec0$0e355c40$@org>
Message-ID: <20090331074739.GA2018@mx.ytti.net>

On (2009-03-31 03:02 -0400), Paul Stewart wrote:

> I don't have the spec sheets handy but I do believe though that the 6708 is
> 1:2 oversubscribed though correct?  The 6704 is 1:1 if that's important to
> the application....

6704 is not exactly 1:1, while 6708 is exactly 1:2. So if you stick
play-doh on 4 ports in 6708 you have wire-speed card (FSVO wire-speed,
I really hate the term though, I mean wire-speed surely has to mean
overspeed of maxports-1 * maxportspeed?)
Also as an interesting curiosity LAN cards prior to 6708 are slow
to detect linedown, so if you're venturing inside the subsecond
convergency world, it is relevant.

> Paul
> 
> 
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Gergely Antal
> Sent: Tuesday, March 31, 2009 2:55 AM
> To: Eric Gauthier
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] 10GE card for 7609
> 
> And also keep in mind that WS-X6708-10GE is a true line-rate card...
> 
> Eric Gauthier wrote:
> > Mark,
> > 
> > I'm not sure if you have other 10g links, but keep in mind that Cisco 
> > has (at least) two 10g optics - Xenpak and X2 - that are not
> intercompatible.
> > I believe that the 6704-10ge uses Xenpak and the 6708-10gE, which is 
> > the "same" card but with 8 ports, uses X2.  If everything else you do 
> > is X2, it might make sense to jump up to the 8 port card to prevent 
> > yourself from having to buy/spare two types of optics.
> > 
> > Eric :)
> > 
> > 
> > On Mon, Mar 30, 2009 at 02:41:12AM -0700, Mark Tech wrote:
> >> Hi
> >> I have a prospect for a 10G upstream customer and Upstream ISP
> connections. I would need to connect these into our 7609s running RSP
> 720-3CXL's, at the moment I have found that the WS-X6704-10GE card may be
> suitable.
> >>
> >> My technical requirements are:
> >> 10Gbps line rate
> >> IPv4
> >> Able to handle full Internet routing table Potentially IPv6 and MPLS 
> >> in the future
> >>
> >> With the WS-X6704-10GE, there seems to be several options that are
> available with it i.e.
> >>
> >> Memory Option: 
> >> MEM-XCEF720-256M
> >> Catalyst 6500 256MB DDR, xCEF720 (67xx interface, DFC3A) 
> >> MEM-XCEF720-512M Cat 6500 512MB DDR, xCEF720 (67xx interface, 
> >> DFC3A/DFC3B) MEM-XCEF720-1GB Catalyst 6500 1GB DDR, xCEF720 (67xx 
> >> interface, DFC3BXL)
> >>
> >> ====================================================
> >> Distributed Forwarding Card Option
> >>
> >> WS-F6700-CFC
> >> Catalyst 6500 Central Fwd Card for WS-X67xx modules WS-F6700-DFC3B 
> >> Catalyst 6500 Dist Fwd Card, 256K Routes for WS-X67xx WS-F6700-DFC3A 
> >> Catalyst 6500 Dist Fwd Card for WS-X67xx modules WS-F6700-DFC3BXL 
> >> Catalyst 6500 Dist Fwd Card- 3BXL, for WS-X67xx WS-F6700-DFC3C 
> >> Catalyst 6500 Dist Fwd Card for WS-X67xx modules WS-F6700-DFC3CXL 
> >> Catalyst 6500 Dist Fwd Card- 3CXL, for WS-X67xx
> >>
> >> I assume that I would need MEM-XCEF720-1GB and WS-F6700-DFC3CXL?
> >>
> >> Regards
> >>
> >> 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/
> 
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

-- 
  ++ytti

From frosya84 at mail.ru  Tue Mar 31 04:46:37 2009
From: frosya84 at mail.ru (=?koi8-r?Q?=EF=CC=D8=C7=C1_=F2=D5=D6=C1=CE=D3=CB=C1=D1?=)
Date: Tue, 31 Mar 2009 12:46:37 +0400
Subject: [c-nsp] Crash 7206VXR after changing IP address on interface
Message-ID: <E1LoZcD-0003eh-00.frosya84-mail-ru@f105.mail.ru>


Hello, List!
 
Does anyone had the problem with changing IP address on GigabitEthernet interface on 7206VXR (NPE-G1)?
 
We tried to change address on interface twice - the same effect.
It's an Internet address, after changing - router reboots and saves only the crash info.
In crash info :
Cause 00000008 (Code 0x2): TLB (load or instruction fetch) exception.

Software Version 12.2(31)SB11.
 
Best regards, 
Olga


From frederic.loui at renater.fr  Tue Mar 31 04:15:21 2009
From: frederic.loui at renater.fr (Frederic LOUI)
Date: Tue, 31 Mar 2009 10:15:21 +0200
Subject: [c-nsp] 10GE card for 7609
In-Reply-To: <863386.41277.qm@web44809.mail.sp1.yahoo.com>
References: <863386.41277.qm@web44809.mail.sp1.yahoo.com>
Message-ID: <49D1D119.6000907@renater.fr>


Hi Mark,
Mark Tech a ?crit :
> Hi
>   
...
> I have a prospect for a 10G upstream customer and Upstream ISP connections. I would need to connect these into our 7609s running RSP 720-3CXL's, at the moment I have found that the WS-X6704-10GE card may be suitable.
>   
We've re-used  WS-X6704-10GE (from our 6500 without DFC3CXL daughter card)
> My technical requirements are:
> 10Gbps line rate
>   
10G => yes
> IPv4
> Able to handle full Internet routing table
> Potentially IPv6 and MPLS in the future
>   
We're implementing all of these features without (as from now) any issue 
except VPLS which needs ES20/ES40 or ES(combo)
We're also using IPv4 (sparse mode with anycast RP ) /IPv6 multicast 
with embedded RP, pseudowire, L3VPN with MPLS.
As far as it goes 6VPE is also supported... (We also tested in lab, 
traffic-engineering with CRS1 in the tunnel path and it has worked at 
10Gb rate)
For whatever reason CISCO recommended a 4gb RAM RSP memory upgrade if 
the 7600 need but I'm not convinced about this recommendation.
(Note that if you need to upgrade you need to purchase 2x4Gb in case of 
redundant RSP)
> With the WS-X6704-10GE, there seems to be several options that are available with it i.e.
>
> Memory Option: 
> MEM-XCEF720-256M 
> Catalyst 6500 256MB DDR, xCEF720 (67xx interface, DFC3A) 
> MEM-XCEF720-512M 
> Cat 6500 512MB DDR, xCEF720 (67xx interface, DFC3A/DFC3B)  
> MEM-XCEF720-1GB 
> Catalyst 6500 1GB DDR, xCEF720 (67xx interface, DFC3BXL) 
>
> ====================================================
> Distributed Forwarding Card Option
>
> WS-F6700-CFC 
> Catalyst 6500 Central Fwd Card for WS-X67xx modules 
> WS-F6700-DFC3B 
> Catalyst 6500 Dist Fwd Card, 256K Routes for WS-X67xx  
> WS-F6700-DFC3A 
> Catalyst 6500 Dist Fwd Card for WS-X67xx modules 
> WS-F6700-DFC3BXL 
> Catalyst 6500 Dist Fwd Card- 3BXL, for WS-X67xx 
> WS-F6700-DFC3C 
> Catalyst 6500 Dist Fwd Card for WS-X67xx modules 
> WS-F6700-DFC3CXL 
> Catalyst 6500 Dist Fwd Card- 3CXL, for WS-X67xx
>
> I assume that I would need MEM-XCEF720-1GB and WS-F6700-DFC3CXL?
>
>   
Yes. WS-F6700-DFC3CXL becomes handy if you're planning to use netflow as 
the NDE(we extensively use it at full flow)  is handle by the Forwarding 
card.
(So the RSP7203CXL won't handle NDE burden) Again, more RAM would help 
to have more room for NETFLOW cache. But maybe this RAM is useful for 
another feature that I'm not awre of.

Netflow is useful and the only way (we found) to monitor IPv6 traffic on 
this platform as IPv6 MIBs are not available on this architecture.
> Regards
>
> Mark
>
>   
Cheers/Fred

From tamas.sziraki at hu.digi.tv  Tue Mar 31 04:01:46 2009
From: tamas.sziraki at hu.digi.tv (Tamas Sziraki)
Date: Tue, 31 Mar 2009 10:01:46 +0200
Subject: [c-nsp] 10GE card for 7609
In-Reply-To: <000901c9b1ce$af671ec0$0e355c40$@org>
References: <863386.41277.qm@web44809.mail.sp1.yahoo.com>	<20090330151600.GA408@roxanne.org>
	<49D1BE37.8060402@skoal.name> <000901c9b1ce$af671ec0$0e355c40$@org>
Message-ID: <6A144738-7A7D-4239-A128-39D4A8378AA1@hu.digi.tv>

6704 is just said to be 1:1 with dfc. What we experienced, is that if  
you need the full 4G use the 6708, regardless if it's oversubscribed  
2:1.


Tamas

On Mar 31, 2009, at 9:02 AM, Paul Stewart wrote:

> I don't have the spec sheets handy but I do believe though that the  
> 6708 is
> 1:2 oversubscribed though correct?  The 6704 is 1:1 if that's  
> important to
> the application....
>
> Paul
>
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Gergely Antal
> Sent: Tuesday, March 31, 2009 2:55 AM
> To: Eric Gauthier
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] 10GE card for 7609
>
> And also keep in mind that WS-X6708-10GE is a true line-rate card...
>
> Eric Gauthier wrote:
>> Mark,
>>
>> I'm not sure if you have other 10g links, but keep in mind that Cisco
>> has (at least) two 10g optics - Xenpak and X2 - that are not
> intercompatible.
>> I believe that the 6704-10ge uses Xenpak and the 6708-10gE, which is
>> the "same" card but with 8 ports, uses X2.  If everything else you do
>> is X2, it might make sense to jump up to the 8 port card to prevent
>> yourself from having to buy/spare two types of optics.
>>
>> Eric :)
>>
>>
>> On Mon, Mar 30, 2009 at 02:41:12AM -0700, Mark Tech wrote:
>>> Hi
>>> I have a prospect for a 10G upstream customer and Upstream ISP
> connections. I would need to connect these into our 7609s running RSP
> 720-3CXL's, at the moment I have found that the WS-X6704-10GE card  
> may be
> suitable.
>>>
>>> My technical requirements are:
>>> 10Gbps line rate
>>> IPv4
>>> Able to handle full Internet routing table Potentially IPv6 and MPLS
>>> in the future
>>>
>>> With the WS-X6704-10GE, there seems to be several options that are
> available with it i.e.
>>>
>>> Memory Option:
>>> MEM-XCEF720-256M
>>> Catalyst 6500 256MB DDR, xCEF720 (67xx interface, DFC3A)
>>> MEM-XCEF720-512M Cat 6500 512MB DDR, xCEF720 (67xx interface,
>>> DFC3A/DFC3B) MEM-XCEF720-1GB Catalyst 6500 1GB DDR, xCEF720 (67xx
>>> interface, DFC3BXL)
>>>
>>> ====================================================
>>> Distributed Forwarding Card Option
>>>
>>> WS-F6700-CFC
>>> Catalyst 6500 Central Fwd Card for WS-X67xx modules WS-F6700-DFC3B
>>> Catalyst 6500 Dist Fwd Card, 256K Routes for WS-X67xx WS-F6700-DFC3A
>>> Catalyst 6500 Dist Fwd Card for WS-X67xx modules WS-F6700-DFC3BXL
>>> Catalyst 6500 Dist Fwd Card- 3BXL, for WS-X67xx WS-F6700-DFC3C
>>> Catalyst 6500 Dist Fwd Card for WS-X67xx modules WS-F6700-DFC3CXL
>>> Catalyst 6500 Dist Fwd Card- 3CXL, for WS-X67xx
>>>
>>> I assume that I would need MEM-XCEF720-1GB and WS-F6700-DFC3CXL?
>>>
>>> Regards
>>>
>>> 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/
>
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/






From lowen at pari.edu  Tue Mar 31 08:01:03 2009
From: lowen at pari.edu (Lamar Owen)
Date: Tue, 31 Mar 2009 08:01:03 -0400
Subject: [c-nsp] ATM on 7206 - PVC < 255 "BICI" ?
In-Reply-To: <49D19EEE.5030305@west.net>
References: <49D19EEE.5030305@west.net>
Message-ID: <200903310801.03850.lowen@pari.edu>

On Tuesday 31 March 2009 00:41:18 Jay Hennigan wrote:
> The provider referring to a "BICI" interface connection type.  Is there
> support for this on the 7206 platform or do we need to have them use VP
> of 255 or less?

The Broadband InterCarrier Interface, AFAIK, is only supported by Cisco on 
their WAN ATM switches/concentrators (such as MGX 8900 and BPX 8600); but I 
reserve the right to be wrong.  The LAN version, PNNI, is typically supported 
switch-to-switch.  AFAIK, the PA's for 7200 only support UNI.  Catalyst 
8500MSR and LightStream 1010 support PNNI, but not B-ICI (except for ATM to 
Frame Relay Interworking, AFAIK).

> I found some reference to BICI on CCO but nothing specific.

Try with a dash: B-ICI.
-- 
Lamar Owen
Chief Information Officer
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
http://www.pari.edu

From ioan.branet at gmail.com  Tue Mar 31 08:43:04 2009
From: ioan.branet at gmail.com (Ioan Branet)
Date: Tue, 31 Mar 2009 15:43:04 +0300
Subject: [c-nsp] Cisco 3750 high CPU utilization HL3U bkgrd]
Message-ID: <257d19980903310543n644d75fdsff69326f6bc1ca2f@mail.gmail.com>

Hello,

We have many Cisco 3750 switches in our network which have high CPU
utilization.It seems that the process that cause this high load is:HL3U
bkgrd process.

The problem is solved after a reload but appears again after 3-4 months.

We changed also the IOS but with no results.

It seems that it is a bug but I am not very sure.



sh processes cpu sorted | ex 0.00
CPU utilization for five seconds: 99%/28%; one minute: 85%; five minutes:
81%
PID Runtime(ms)   Invoked      uSecs   5Sec   1Min   5Min TTY Process
108   389775804   4389443      88799 57.57% 40.01% 39.39%   0 HL3U bkgrd
proce
58    11854779  72185839        164  3.50%  2.77%  2.31%   0 HLFM address
lea
292         689       192       3588  1.91%  0.33%  0.07%   1 Virtual
Exec     47    12845296   2142151       5996  1.11%  1.00%  1.04%   0 FE
free chunk   245    17376827    532655      32623  0.63%  0.51%  0.52%   0
MFI LFD Stats Pr
107     5476276  58476944         93  0.63%  0.62%  0.58%   0 Hulc LED
Process
74      768210  21312879         36  0.31%  0.09%  0.08%   0 hpm main
process
135     6540410  20282165        322  0.15%  0.18%  0.22%   0 IP
Input        143     3566619  27781902        128  0.15%  0.24%  0.20%   0
Spanning Tree    45     1004640 128285520          7  0.15%  0.15%  0.13%
0 Fifo Error Detec
138     1152329   2735155        421  0.15%  0.13%  0.12%   0 PI MATM Aging
Pr


sh version
Cisco IOS Software, C3750ME Software (C3750ME-I5-M), Version 12.2(37)SE1,
RELEASE SOFTWARE (fc1)
Copyright (c) 1986-2007 by Cisco Systems, Inc.
Compiled Thu 05-Jul-07 20:06 by antonino
Image text-base: 0x00003000, data-base: 0x0163F400

ROM: Bootstrap program is C3750 boot loader
BOOTLDR: C3750ME Boot Loader (C3750ME-HBOOT-M) Version 12.1(14r)AX, RELEASE
SOFTWARE (fc1)

vic102 uptime is 4 weeks, 4 days, 10 hours, 9 minutes
System returned to ROM by power-on
System restarted at 03:01:54 GMT Fri Feb 27 2009
System image file is "flash:c3750me-i5-mz.122-37.SE1.bin"

cisco ME-C3750-24TE (PowerPC405) processor (revision F0) with 118784K/12280K
bytes of memory.
Processor board ID CAT1043NM05
Last reset from power-on
8 Virtual Ethernet interfaces
24 FastEthernet interfaces
4 Gigabit Ethernet interfaces
The password-recovery mechanism is enabled.

1024K bytes of flash-simulated non-volatile configuration memory.
Base ethernet MAC Address       : 00:19:E8:87:23:00
Motherboard assembly number     : 73-9938-04
Motherboard serial number       : CAT104356B7
Model revision number           : F0
Motherboard revision number     : A0
Model number                    : ME-C3750-24TE-M
Daughterboard assembly number   : 73-9939-02
Daughterboard serial number     : CAT104355CQ
System serial number            : CAT1043NM05
Top Assembly Part Number        : 800-25952-04
Top Assembly Revision Number    : C0
Version ID                      : V05
CLEI Code Number                : COM1510ARA
Daughterboard revision number   : A0
Hardware Board Revision Number  : 0x09


Switch   Ports  Model              SW Version              SW
Image           ------   -----  -----              ----------
----------         *    1   28     ME-C3750-24TE
12.2(37)SE1             C3750ME-I5-M
Configuration register is 0xF

#sh memory | i HL
030C8118 0000005000 030C804C 030C94CC 001  -------- -------- 005CF8E4  HLFM
MAC
030C94CC 0000000808 030C8118 030C9820 001  -------- -------- 005CF93C  HLFM
IP
0320A434 0000000808 0320A008 0320A788 001  -------- -------- 00CB2F74
HL3U_IPV4_TABLE_CHUNK
0320A788 0000020000 0320A434 0320F5D4 001  -------- -------- 00CB2F9C
HL3U_FIB_TYPE_CHUNK
0320F5D4 0000032768 0320A788 03217600 001  -------- -------- 00CB2FC4
HL3U_MPATH_ADJ_TYPE_CHUNK
03217600 0000000808 0320F5D4 03217954 001  -------- -------- 00CB2FEC
HL3U_FIB_WITH_ADJ_OR_TCAM_FAIL_CHUNK
03217954 0000002000 03217600 03218150 001  -------- -------- 00CB3014
HL3U_COVERING_FIB_CHUNK
03218150 0000000808 03217954 032184A4 001  -------- -------- 00CB303C
HL3U_ARP_HRPC_THROTTLE_CHUNKS
032184A4 0000000432 03218150 03218680 001  -------- -------- 00CB3064
HL3U_HSRP_RETRY_CHUNKS
03218680 0000000808 032184A4 032189D4 001  -------- -------- 00CB308C
HL3U_PROXY_ARP_CHUNKS
032189D4 0000000432 03218680 03218BB0 001  -------- -------- 00CB30B4
HL3U_QUERIER_INFO_CHUNKS
03218BB0 0000003620 032189D4 03219A00 001  -------- -------- 00CB30DC
HL3U_ICMP_REDIRECT_Q_CHUNK
03219A00 0000000296 03218BB0 03219B54 001  -------- -------- 00CB3104
HL3U_OUT_ACL_FULL_CHUNKS
032F2BCC 0000000960 032F252C 032F2FB8 001  -------- -------- 00CBE090
HL3U_FIB_WITH_
0330BD38 0000000176 0330B698 0330BE14 001  -------- -------- 00B18A5C
HL2MCM
0330C174 0000000160 0330C0C0 0330C240 001  -------- -------- 01622A8C
HL2MCM
036F9C6C 0000000972 036F9A8C 036FA064 001  -------- -------- 00CB7108
HL3U_FIB_WITH_
036FA064 0000000872 036F9C6C 036FA3F8 001  -------- -------- 00CBE090
HL3U_FIB_WITH_
0390629C 0000000024 03906258 039062E0 001  -------- -------- 00B1AFAC
HL2MCM
039906D8 0000001292 0399008C 03990C10 001  -------- -------- 00CBE090
HL3U_FIB_WITH_
03993CC4 0000000808 03993690 03994018 001  -------- -------- 00CBE090
HL3U_FIB_WITH_
0399C258 0000001476 0399BC14 0399C848 001  -------- -------- 00CB7108
HL3U_FIB_WITH_
0399C964 0000005000 0399C848 0399DD18 001  -------- -------- 005CB1E0  HLFM
MAC
03A0A610 0000001096 03A0A3EC 03A0AA84 001  -------- -------- 00CBE090
HL3U_FIB_WITH_
03A2B8E4 0000000808 03A2B858 03A2BC38 001  -------- -------- 00CBE090
HL3U_FIB_WITH_
03A2BC38 0000000872 03A2B8E4 03A2BFCC 001  -------- -------- 00CBE090
HL3U_FIB_WITH_
03A2E864 0000007768 03A2E624 03A306E8 001  -------- -------- 005CB1E0  HLFM
MAC
03A30D28 0000000808 03A30CBC 03A3107C 001  -------- -------- 00CBE090
HL3U_FIB_WITH_
03A92BD4 0000000808 03A92590 03A92F28 001  -------- -------- 00CBE090
HL3U_FIB_WITH_
03EE36A8 0000005000 03EE3634 03EE4A5C 001  -------- -------- 005CB1E0  HLFM
MAC
03F24DCC 0000001008 03F24D54 03F251E8 001  -------- -------- 00CBE090
HL3U_FIB_WITH_
03F43C34 0000008200 03F43BE8 03F45C68 001  -------- -------- 005CB1E0  HLFM
MAC
03F4C260 0000000808 03F4C1CC 03F4C5B4 001  -------- -------- 005CB5B8  HLFM
IP
03F85410 0000000808 03F84DBC 03F85764 001  -------- -------- 00CBE090
HL3U_FIB_WITH_
03F85EF0 0000001008 03F85764 03F8630C 001  -------- -------- 00CBE090
HL3U_FIB_WITH_
03F872A8 0000001288 03F86F08 03F877DC 001  -------- -------- 00CBE090
HL3U_FIB_WITH_
03FEBD34 0000000808 03FEB5A8 03FEC088 001  -------- -------- 00CB7108
HL3U_FIB_WITH_
03FEC088 0000001076 03FEBD34 03FEC4E8 001  -------- -------- 00CB7108
HL3U_FIB_WITH_
03FEEF64 0000000808 03FEE7D8 03FEF2B8 001  -------- -------- 00CBE090
HL3U_FIB_WITH_
03FEF2B8 0000000832 03FEEF64 03FEF624 001  -------- -------- 00CBE090
HL3U_FIB_WITH_
03FF05F0 0000005944 03FF04FC 03FF1D54 001  -------- -------- 005CB1E0  HLFM
MAC


#sh sdm prefer
The current template is "desktop routing" template.
The selected template optimizes the resources in
the switch to support this level of features for
8 routed interfaces and 1024 VLANs.

number of unicast mac addresses:                  3K
number of IPv4 IGMP groups + multicast routes:    1K
number of IPv4 unicast routes:                    11K
  number of directly-connected IPv4 hosts:        3K
  number of indirect IPv4 routes:                 8K
number of IPv4 policy based routing aces:         0.5K
number of IPv4/MAC qos aces:                      0.5K
number of IPv4/MAC security aces:                 1K

Mar 31 12:48:11: %OCE-3-MISSING_HANDLER_FOR_SW_OBJ_TYPE: Missing handler for
'non choice oce get next' function for type Midchain
Mar 31 12:48:17: %OCE-3-MISSING_HANDLER_FOR_SW_OBJ_TYPE: Missing handler for
'non choice oce get next' function for type Midchain
Mar 31 12:48:28: %OCE-3-MISSING_HANDLER_FOR_SW_OBJ_TYPE: Missing handler for
'non choice oce get next' function for type Midchain
Mar 31 12:48:46: %OCE-3-MISSING_HANDLER_FOR_SW_OBJ_TYPE: Missing handler for
'non choice oce get next' function for type Midchain
Mar 31 12:49:00: %OCE-3-MISSING_HANDLER_FOR_SW_OBJ_TYPE: Missing handler for
'non choice oce get next' function for type Midchain
Mar 31 12:49:47: %OCE-3-MISSING_HANDLER_FOR_SW_OBJ_TYPE: Missing handler for
'non choice oce get next' function for type Midchain
Mar 31 12:50:39: %OCE-3-MISSING_HANDLER_FOR_SW_OBJ_TYPE: Missing handler for
'non choice oce get next' function for type Midchain
Mar 31 12:51:02: %OCE-3-MISSING_HANDLER_FOR_SW_OBJ_TYPE: Missing handler for
'non choice oce get next' function for type Midchain
Mar 31 12:51:34: %OCE-3-MISSING_HANDLER_FOR_SW_OBJ_TYPE: Missing handler for
'non choice oce get next' function for type Midchain
Mar 31 12:51:55: %OCE-3-MISSING_HANDLER_FOR_SW_OBJ_TYPE: Missing handler for
'non choice oce get next' function for type Midchain
Mar 31 12:53:11: %OCE-3-MISSING_HANDLER_FOR_SW_OBJ_TYPE: Missing handler for
'non choice oce get next' function for type Midchain
Mar 31 12:53:25: %OCE-3-MISSING_HANDLER_FOR_SW_OBJ_TYPE: Missing handler for
'non choice oce get next' function for type Midchain
Mar 31 12:53:37: %OCE-3-MISSING_HANDLER_FOR_SW_OBJ_TYPE: Missing handler for
'non choice oce get next' function for type Midchain
Mar 31 12:54:36: %OCE-3-MISSING_HANDLER_FOR_SW_OBJ_TYPE: Missing handler for
'non choice oce get next' function for type Midchain
Mar 31 12:56:44: %OCE-3-MISSING_HANDLER_FOR_SW_OBJ_TYPE: Missing handler for
'non choice oce get next' function for type Midchain
Mar 31 12:57:48: %OCE-3-MISSING_HANDLER_FOR_SW_OBJ_TYPE: Missing handler for
'non choice oce get next' function for type Midchain
Mar 31 13:02:22: %OCE-3-MISSING_HANDLER_FOR_SW_OBJ_TYPE: Missing handler for
'non choice oce get next' function for type Midchain
Mar 31 13:02:48: %OCE-3-MISSING_HANDLER_FOR_SW_OBJ_TYPE: Missing handler for
'non choice oce get next' function for type Midchain
Mar 31 13:03:56: %OCE-3-MISSING_HANDLER_FOR_SW_OBJ_TYPE: Missing handler for
'non choice oce get next' function for type Midchain
Mar 31 13:07:31: %OCE-3-MISSING_HANDLER_FOR_SW_OBJ_TYPE: Missing handler for
'non choice oce get next' function for type Midchain
Mar 31 13:30:37: %OCE-3-MISSING_HANDLER_FOR_SW_OBJ_TYPE: Missing handler for
'non choice oce get next' function for type Midchain


On other 3750 from our network:

sh processes cpu  sorted | ex 0.00
CPU utilization for five seconds: 43%/2%; one minute: 58%; five minutes: 59%

PID Runtime(ms)   Invoked      uSecs   5Sec   1Min   5Min TTY Process
108  2635783702  47442165      55558 30.55% 48.37% 49.28%   0 HL3U bkgrd
proce
294         500      2692        185  3.19%  0.55%  0.13%   1 Virtual
Exec     47   296813504  43714587       6789  1.43%  1.70%  1.74%   0 FE
free chunk   107    58156203 265066803        219  0.63%  0.42%  0.37%   0
Hulc LED Process
247    88726248   2800468      31682  0.47%  0.45%  0.47%   0 MFI LFD Stats
Pr
117     3310849   6664259        496  0.15%  0.04%  0.03%   0 HRPC qos
request
135     8065160  45776840        176  0.15%  0.07%  0.04%   0 IP
Input        243    28572622  56335656        507  0.15%  0.17%  0.18%   0
ISIS Upd
#sh ver
Cisco IOS Software, C3750ME Software (C3750ME-I5-M), Version 12.2(37)SE1,
RELEASE SOFTWARE (fc1)
Copyright (c) 1986-2007 by Cisco Systems, Inc.
Compiled Thu 05-Jul-07 20:06 by antonino
Image text-base: 0x00003000, data-base: 0x0163F400

ROM: Bootstrap program is C3750 boot loader
BOOTLDR: C3750ME Boot Loader (C3750ME-HBOOT-M) Version 12.1(14r)AX, RELEASE
SOFTWARE (fc1)

rom101 uptime is 27 weeks, 5 days, 18 hours, 13 minutes
System returned to ROM by power-on
System restarted at 20:03:10 CETDST Wed Sep 17 2008
System image file is "flash:c3750me-i5-mz.122-37.SE1.bin"

cisco ME-C3750-24TE (PowerPC405) processor (revision F0) with 118784K/12280K
bytes of memory.
Processor board ID CAT1111NLH3
Last reset from power-on
3 Virtual Ethernet interfaces
24 FastEthernet interfaces
4 Gigabit Ethernet interfaces
The password-recovery mechanism is enabled.

1024K bytes of flash-simulated non-volatile configuration memory.
Base ethernet MAC Address       : 00:1B:2B:E6:4B:00
Motherboard assembly number     : 73-9938-04
Motherboard serial number       : CAT11115HNX
Model revision number           : F0
Motherboard revision number     : B0
Model number                    : ME-C3750-24TE-M
Daughterboard assembly number   : 73-9939-02
Daughterboard serial number     : CAT11115KVD
System serial number            : CAT1111NLH3
Top Assembly Part Number        : 800-25952-04
Top Assembly Revision Number    : C0
Version ID                      : V05
CLEI Code Number                : COM1510ARA
Daughterboard revision number   : A0
Hardware Board Revision Number  : 0x09


Switch   Ports  Model              SW Version              SW
Image           ------   -----  -----              ----------
----------         *    1   28     ME-C3750-24TE
12.2(37)SE1             C3750ME-I5-M
Configuration register is 0xF
       Do you have any idea what is the root cause of this issue?




Thnak you,

-- 
Ioan Branet

From peter at rathlev.dk  Tue Mar 31 08:50:42 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Tue, 31 Mar 2009 14:50:42 +0200
Subject: [c-nsp] C2800 IP Base and IP SLA / RTR
Message-ID: <1238503842.3435.63.camel@localhost.localdomain>

Hello,

We're about to buy setup a new batch of IP SLA/RTR units and are looking
at the C2800 for the purpose. I can see from FN that IP Base apparantly
doesn't do IP SLA/RTR, and that we have to get Enterprise Base for that.
Can this be true?

I only have C2800 Enterprise Base in production right now, but we have a
lot of C2600 IP Feature Set (12.3(26)) routers doing RTR now. Do we have
to shell out the extra ?? for the Enterprise Base or do anyone have any
other ideas for rack mountable RTR units?

Thank you.

Regards,
Peter



From zivl at gilat.net  Tue Mar 31 09:04:21 2009
From: zivl at gilat.net (Ziv Leyes)
Date: Tue, 31 Mar 2009 16:04:21 +0300
Subject: [c-nsp] C2800 IP Base and IP SLA / RTR
In-Reply-To: <1238503842.3435.63.camel@localhost.localdomain>
References: <1238503842.3435.63.camel@localhost.localdomain>
Message-ID: <EC993E87D960A541A66BF21D62AA42A622E20EF55A@exch2k7.gilat.local>

We have 7200VXR with c7200-is-mz.124-13b.bin which does support IP SLA, but I don't know if the same IOS version on a different platform may not have it.
I think also IP advanced services support IP SLA if it's cheaper than enterprise then you could go for it.
Hope this helps
Ziv




-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Peter Rathlev
Sent: Tuesday, March 31, 2009 3:51 PM
To: cisco-nsp
Subject: [c-nsp] C2800 IP Base and IP SLA / RTR

Hello,

We're about to buy setup a new batch of IP SLA/RTR units and are looking
at the C2800 for the purpose. I can see from FN that IP Base apparantly
doesn't do IP SLA/RTR, and that we have to get Enterprise Base for that.
Can this be true?

I only have C2800 Enterprise Base in production right now, but we have a
lot of C2600 IP Feature Set (12.3(26)) routers doing RTR now. Do we have
to shell out the extra ???? for the Enterprise Base or do anyone have any
other ideas for rack mountable RTR units?

Thank you.

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/???+??????g????????w???k-??????m???+???????????????,j
???j??????z{jy???u?????????w????????????T???
??????~?????????kz??q?????????br*.??????z??????u???lr??????????????*???
N?~?-??^r?????????zf??g?????y??q??y??>)??Lj)Rx+?y?+???????~f??????(u???????&??^??????
From techconfig at yahoo.com  Tue Mar 31 09:15:01 2009
From: techconfig at yahoo.com (Mark Tech)
Date: Tue, 31 Mar 2009 06:15:01 -0700 (PDT)
Subject: [c-nsp] 7600 SNMP stats and processes issue
Message-ID: <90424.40444.qm@web44803.mail.sp1.yahoo.com>


Hi
I have migrated an Ethernet customer connected?from?our 7206 (PE)?to?our new?7609 (PE)?and I am now seeing some very strange SNMP interface results from the 7600. The graph itself looks very spikey and when for example a BGP change takes place the is a trough of about 20Mbps, then a peak of about 20Mbps, then a trough of about 20Mbps then back to normal. 
?
The customer is only using about 60Mbps so its very obvious
?
Its almost as if SNMP is being low prioritised whilst other process i.e. BGP do their work. This is affecting us as the customer who monitors their own network is asking why our graphs look so different whereas before when they were connected to the VXR, they matched almost perfectly
?
My concern is that SNMP is not working as well as it should be which in turn will alter our results for 95 percentile customers etc
?
Has anyone else ever experienced this?
?
Regards
?
Mark


      


From david at davidcoulson.net  Tue Mar 31 09:44:00 2009
From: david at davidcoulson.net (David Coulson)
Date: Tue, 31 Mar 2009 09:44:00 -0400
Subject: [c-nsp] High IPC LC Message Header utilization
Message-ID: <49D21E20.5060709@davidcoulson.net>

I've noticed weird CPU utilization on a 7513 recently upgraded to 
12.4(23) (AdvIP w/ SSH). The two top processes, by CPU usage, are these:

 103     5834624   9290243        628  2.78%  2.58%  2.50%   0 IPC LC 
Message H
   3     3708356  10387227        357  0.98%  0.87%  0.82%   0 IPC CBus 
process

Not exactly anything to get excited about, but that's ~4% CPU which 
wasn't in use last week. I compared it to another 7500 running the same 
code, which has very different CPU utilization for these processes:

 103        9492   2990653          3  0.00%  0.00%  0.00%   0 IPC LC 
Message H
  48     1319160   3539843        372  0.08%  0.15%  0.15%   0 IPC CBus 
process

The runtime on the IPC LC Message Header process is obviously way out of 
whack on the first one - Is there a way to track down what is causing 
this process to consume CPU? I had a quick look through the ipc sessions 
and queues, with nothing which would really account for such a 
difference in runtime.

Any idea where to look?

From steve at ibctech.ca  Tue Mar 31 10:06:34 2009
From: steve at ibctech.ca (Steve Bertrand)
Date: Tue, 31 Mar 2009 10:06:34 -0400
Subject: [c-nsp] IP Address management software
In-Reply-To: <1238488159.7827.0.camel@dsba-ipso>
References: <cf9098540903310117l724411e8h89bc05630d076ab7@mail.gmail.com>
	<1238488159.7827.0.camel@dsba-ipso>
Message-ID: <49D2236A.8060601@ibctech.ca>

luismi wrote:
> We use here IPPlan.

Us too. The only drawback is that it doesn't handle IPv6.

Steve

From MLouis at nwnit.com  Tue Mar 31 10:05:00 2009
From: MLouis at nwnit.com (Mike Louis)
Date: Tue, 31 Mar 2009 10:05:00 -0400
Subject: [c-nsp] Redundant switch fabric
Message-ID: <CBBF2C7B2547D14A910A349B58810AC25C4CDBF234@mncmx1.NWNIT.CORP>

I have a solution design that requires redundant switch fabrics. I am interpreting this beyond just have redundant supervisors meaning redundant backplanes on the switch cards. Do the 6500 and 4500 support redundant fabrics? Will a 6748 function with one trace failed?
________________________________
Note: This message and any attachments is intended solely for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, legally privileged, confidential, and/or exempt from disclosure. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the original sender immediately by telephone or return email and destroy or delete this message along with any attachments immediately.

From asturluismi at gmail.com  Tue Mar 31 11:33:03 2009
From: asturluismi at gmail.com (luismi)
Date: Tue, 31 Mar 2009 17:33:03 +0200
Subject: [c-nsp] IP Address management software
In-Reply-To: <49D2236A.8060601@ibctech.ca>
References: <cf9098540903310117l724411e8h89bc05630d076ab7@mail.gmail.com>
	<1238488159.7827.0.camel@dsba-ipso>  <49D2236A.8060601@ibctech.ca>
Message-ID: <1238513583.7827.3.camel@dsba-ipso>

Well, I think the best option then is donate code or money to the
project to develop it as we need.

In my case, right now, we don't need IPv6, but don't consider that as an
excude to give some funds or other resourcers to the developers.

El mar, 31-03-2009 a las 10:06 -0400, Steve Bertrand escribi?:
> luismi wrote:
> > We use here IPPlan.
> 
> Us too. The only drawback is that it doesn't handle IPv6.
> 
> Steve


From brhedlun at cisco.com  Tue Mar 31 12:11:54 2009
From: brhedlun at cisco.com (Brad Hedlund)
Date: Tue, 31 Mar 2009 11:11:54 -0500
Subject: [c-nsp] Redundant switch fabric
In-Reply-To: <CBBF2C7B2547D14A910A349B58810AC25C4CDBF234@mncmx1.NWNIT.CORP>
Message-ID: <C5F7AAFA.31818%brhedlun@cisco.com>

Mike,
The 6500 and 4500 have the "switch fabric" on the supervisor engines, so by
having dual supervisors, you in effect have a redundant fabric.

The 6748 actually has 4 traces, each 20G.  2 traces connect to the active
supervisor containing the active switch fabric.  The remaining 2 traces are
standby connections to the standby supervisor/fabric.  So, when a supervisor
engine and its fabric fails, the 2 standby traces are enabled and the full
40G of bandwidth remains.  You never, under normal circumstances, have only
a single trace active on 6748.  Newer versions of IOS provide a "hot
standby" fabric feature which allows this fabric trace switch over to happen
faster - roughly 50ms.

For the best in redundant designs, consider the Nexus 7000, where the switch
fabric is decoupled from the supervisor engines into a series redundant
"fabric modules" installed into the back of the switch.  Should a supervisor
engine fail in Nexus 7000 there is ZERO impact to the switch fabric, because
the supervisor engine does not forward data plane traffic.

Cheers,

Brad Hedlund
bhedlund at cisco.com
http://www.internetworkexpert.org


On 3/31/09 9:05 AM, "Mike Louis" <MLouis at nwnit.com> wrote:

> I have a solution design that requires redundant switch fabrics. I am
> interpreting this beyond just have redundant supervisors meaning redundant
> backplanes on the switch cards. Do the 6500 and 4500 support redundant
> fabrics? Will a 6748 function with one trace failed?
> ________________________________
> Note: This message and any attachments is intended solely for the use of the
> individual or entity to which it is addressed and may contain information that
> is non-public, proprietary, legally privileged, confidential, and/or exempt
> from disclosure. If you are not the intended recipient, you are hereby
> notified that any use, dissemination, distribution, or copying of this
> communication is strictly prohibited. If you have received this communication
> in error, please notify the original sender immediately by telephone or return
> email and destroy or delete this message along with any attachments
> immediately.
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/





From cchurc05 at harris.com  Tue Mar 31 12:23:23 2009
From: cchurc05 at harris.com (Church, Charles)
Date: Tue, 31 Mar 2009 11:23:23 -0500
Subject: [c-nsp] C2800 IP Base and IP SLA / RTR
In-Reply-To: <EC993E87D960A541A66BF21D62AA42A622E20EF55A@exch2k7.gilat.local>
References: <1238503842.3435.63.camel@localhost.localdomain>
	<EC993E87D960A541A66BF21D62AA42A622E20EF55A@exch2k7.gilat.local>
Message-ID: <FA1BA229357DB640B944218F3585FECA021A47D0@mspe2k1.cs.myharris.net>

Definitely need to check feature navigator.  We found this same thing out.  IP Base on 2600-2800 does not equal IP Base on small switches or 7200s.  "IP SLA...' is the feature to look for.

Chuck

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Ziv Leyes
Sent: Tuesday, March 31, 2009 9:04 AM
To: cisco-nsp
Subject: Re: [c-nsp] C2800 IP Base and IP SLA / RTR

We have 7200VXR with c7200-is-mz.124-13b.bin which does support IP SLA, but I don't know if the same IOS version on a different platform may not have it.
I think also IP advanced services support IP SLA if it's cheaper than enterprise then you could go for it.
Hope this helps
Ziv




-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Peter Rathlev
Sent: Tuesday, March 31, 2009 3:51 PM
To: cisco-nsp
Subject: [c-nsp] C2800 IP Base and IP SLA / RTR

Hello,

We're about to buy setup a new batch of IP SLA/RTR units and are looking at the C2800 for the purpose. I can see from FN that IP Base apparantly doesn't do IP SLA/RTR, and that we have to get Enterprise Base for that.
Can this be true?

I only have C2800 Enterprise Base in production right now, but we have a lot of C2600 IP Feature Set (12.3(26)) routers doing RTR now. Do we have to shell out the extra ?? for the Enterprise Base or do anyone have any other ideas for rack mountable RTR units?

Thank you.

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/ +  g ? w k-  m +
     ,j
 j  z{
jy u   w    T 
  ~   kz?q   br*.  
z  u lr   ? * 
N~-^r?zfg
yqy>)Lj)Rx+y+
?~f?(u??&^?

From geoff at pendery.net  Tue Mar 31 12:24:05 2009
From: geoff at pendery.net (Geoffrey Pendery)
Date: Tue, 31 Mar 2009 11:24:05 -0500
Subject: [c-nsp] 10GE card for 7609
In-Reply-To: <863386.41277.qm@web44809.mail.sp1.yahoo.com>
References: <863386.41277.qm@web44809.mail.sp1.yahoo.com>
Message-ID: <d6966e4b0903310924r3f857c6dmf7c7a1fb2ee5712a@mail.gmail.com>

The stuff we've been reading (look at "Supervisor Engines Supported"
on the data sheets for "Cisco Catalyst 6500 Series 10 Gigabit Ethernet
Interface Modules", or browse the line cards for the 7600, or go into
Configurator tool) claims that the RSP 720 won't support the X6704 or
X6708 10 Gig "LAN" cards, only the SIP/SPA/ES "WAN" type cards.

I don't mean to kick off a big "6500 vs 7600" storm again, but does
anyone know if this is incorrect?
Can we buy a new 7609-S chassis, put a new RSP 720 in it, put 7600 IOS
on that Sup, then plug in a WS-X6708-10G-3C and have it work?


-Geoff


On Mon, Mar 30, 2009 at 4:41 AM, Mark Tech <techconfig at yahoo.com> wrote:
>
> Hi
> I have a prospect for a 10G upstream customer and Upstream ISP connections. I would need to connect these into our 7609s running RSP 720-3CXL's, at the moment I have found that the WS-X6704-10GE card may be suitable.
>
> My technical requirements are:
> 10Gbps line rate
> IPv4
> Able to handle full Internet routing table
> Potentially IPv6 and MPLS in the future
>
> With the WS-X6704-10GE, there seems to be several options that are available with it i.e.
>
> Memory Option:
> MEM-XCEF720-256M
> Catalyst 6500 256MB DDR, xCEF720 (67xx interface, DFC3A)
> MEM-XCEF720-512M
> Cat 6500 512MB DDR, xCEF720 (67xx interface, DFC3A/DFC3B)
> MEM-XCEF720-1GB
> Catalyst 6500 1GB DDR, xCEF720 (67xx interface, DFC3BXL)
>
> ====================================================
> Distributed Forwarding Card Option
>
> WS-F6700-CFC
> Catalyst 6500 Central Fwd Card for WS-X67xx modules
> WS-F6700-DFC3B
> Catalyst 6500 Dist Fwd Card, 256K Routes for WS-X67xx
> WS-F6700-DFC3A
> Catalyst 6500 Dist Fwd Card for WS-X67xx modules
> WS-F6700-DFC3BXL
> Catalyst 6500 Dist Fwd Card- 3BXL, for WS-X67xx
> WS-F6700-DFC3C
> Catalyst 6500 Dist Fwd Card for WS-X67xx modules
> WS-F6700-DFC3CXL
> Catalyst 6500 Dist Fwd Card- 3CXL, for WS-X67xx
>
> I assume that I would need MEM-XCEF720-1GB and WS-F6700-DFC3CXL?
>
> Regards
>
> 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 jcdarby at usgs.gov  Tue Mar 31 12:51:58 2009
From: jcdarby at usgs.gov (Justin C. Darby)
Date: Tue, 31 Mar 2009 11:51:58 -0500
Subject: [c-nsp] Redundant switch fabric
In-Reply-To: <C5F7AAFA.31818%brhedlun@cisco.com>
References: <C5F7AAFA.31818%brhedlun@cisco.com>
Message-ID: <49D24A2E.8010200@usgs.gov>

Mike,

Just to chime in here a bit with some experience - we've had Nexus 7K 
switch backplane modules fail - unless you are pushing near 100% 
backplane utilization you don't even notice until it emails you or your 
config monitoring program notices the failed module. In recent NX-OS 
releases, In Service Software Upgrades are working properly 100% of the 
time for us, and outside of the fact it can take 3-4 hours to upgrade a 
fully loaded switch, there's no real downtime if you've got working port 
redundancy across modules, and modules only go down one at a time like 
they're supposed to.

Considering how distributed and redundant components of the switch are - 
it's pretty unlikely you'd run into huge redundancy problems with any 
single component. I don't have enough N7K's to play with Virtual Port 
Channels (vPCs), but it'd be interesting to see if they have any issues 
when upgrading switches. vPCs can add extreme (and usable) redundancy to 
multi-chassis design, if you want to go a step farther.

Justin

P.S. Comments made here are my own and should not in any way be 
considered an endorsement by the U.S. Federal Government.

Brad Hedlund wrote:
> Mike,
> The 6500 and 4500 have the "switch fabric" on the supervisor engines, so by
> having dual supervisors, you in effect have a redundant fabric.
>
> The 6748 actually has 4 traces, each 20G.  2 traces connect to the active
> supervisor containing the active switch fabric.  The remaining 2 traces are
> standby connections to the standby supervisor/fabric.  So, when a supervisor
> engine and its fabric fails, the 2 standby traces are enabled and the full
> 40G of bandwidth remains.  You never, under normal circumstances, have only
> a single trace active on 6748.  Newer versions of IOS provide a "hot
> standby" fabric feature which allows this fabric trace switch over to happen
> faster - roughly 50ms.
>
> For the best in redundant designs, consider the Nexus 7000, where the switch
> fabric is decoupled from the supervisor engines into a series redundant
> "fabric modules" installed into the back of the switch.  Should a supervisor
> engine fail in Nexus 7000 there is ZERO impact to the switch fabric, because
> the supervisor engine does not forward data plane traffic.
>
> Cheers,
>
> Brad Hedlund
> bhedlund at cisco.com
> http://www.internetworkexpert.org
>
>
> On 3/31/09 9:05 AM, "Mike Louis" <MLouis at nwnit.com> wrote:
>
>   
>> I have a solution design that requires redundant switch fabrics. I am
>> interpreting this beyond just have redundant supervisors meaning redundant
>> backplanes on the switch cards. Do the 6500 and 4500 support redundant
>> fabrics? Will a 6748 function with one trace failed?
>> ________________________________
>> Note: This message and any attachments is intended solely for the use of the
>> individual or entity to which it is addressed and may contain information that
>> is non-public, proprietary, legally privileged, confidential, and/or exempt
>> from disclosure. If you are not the intended recipient, you are hereby
>> notified that any use, dissemination, distribution, or copying of this
>> communication is strictly prohibited. If you have received this communication
>> in error, please notify the original sender immediately by telephone or return
>> email and destroy or delete this message along with any attachments
>> immediately.
>> _______________________________________________
>> cisco-nsp mailing 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 gtb at slac.stanford.edu  Tue Mar 31 13:08:23 2009
From: gtb at slac.stanford.edu (Buhrmaster, Gary)
Date: Tue, 31 Mar 2009 10:08:23 -0700
Subject: [c-nsp] Redundant switch fabric
In-Reply-To: <CBBF2C7B2547D14A910A349B58810AC25C4CDBF234@mncmx1.NWNIT.CORP>
References: <CBBF2C7B2547D14A910A349B58810AC25C4CDBF234@mncmx1.NWNIT.CORP>
Message-ID: <D0D0330CBD07114D85B70B784E80C2F2022FD157@exch-mail2.win.slac.stanford.edu>


> I have a solution design that requires redundant switch 
> fabrics. I am interpreting this beyond just have redundant 
> supervisors meaning redundant backplanes on the switch cards. 
> Do the 6500 and 4500 support redundant fabrics? Will a 6748 
> function with one trace failed?

If you really need redundancy at those levels, you
really want two chassis.  While rare, even the
chassis can fail (as documented, about once a year,
by someone on this list), and for "interesting"
problems TAC may want you to OIR cards that cause
"interesting" results on the entire chassis,
and no matter how good the hardware, software bugs
can always take out the entire box.

In box reliability is valuable and desirable, but
when you need really high availability, you have
to at least consider an out of the box solution.

From brhedlun at cisco.com  Tue Mar 31 13:14:03 2009
From: brhedlun at cisco.com (Brad Hedlund)
Date: Tue, 31 Mar 2009 12:14:03 -0500
Subject: [c-nsp] Redundant switch fabric
In-Reply-To: <49D24A2E.8010200@usgs.gov>
Message-ID: <C5F7B98B.31832%brhedlun@cisco.com>

Justin / Mike,

When performing ISSU on Nexus 7000 the interface modules only need to be
reset if the code you are upgrading to also requires an upgrade of the
module's EPLD (erasable programmable logic device).  This is not always
required.  So in many cases you can perform an ISSU upgrade with ZERO impact
to the interface modules.

The CLI will inform you if a software upgrade will be disruptive to the
interface modules before you proceed with the upgrade.

Additionally, you can check the Nexus 7000 EPLD Release Notes prior to an
upgrade so see if your new code will require any change to the EPLD.

http://www.cisco.com/en/US/docs/switches/datacenter/sw/4_1/epld/epld_rn.html

Cheers,

Brad Hedlund
bhedlund at cisco.com
http://www.internetworkexpert.org


On 3/31/09 11:51 AM, "Justin C. Darby" <jcdarby at usgs.gov> wrote:

> Mike,
> 
> Just to chime in here a bit with some experience - we've had Nexus 7K
> switch backplane modules fail - unless you are pushing near 100%
> backplane utilization you don't even notice until it emails you or your
> config monitoring program notices the failed module. In recent NX-OS
> releases, In Service Software Upgrades are working properly 100% of the
> time for us, and outside of the fact it can take 3-4 hours to upgrade a
> fully loaded switch, there's no real downtime if you've got working port
> redundancy across modules, and modules only go down one at a time like
> they're supposed to.
> 
> Considering how distributed and redundant components of the switch are -
> it's pretty unlikely you'd run into huge redundancy problems with any
> single component. I don't have enough N7K's to play with Virtual Port
> Channels (vPCs), but it'd be interesting to see if they have any issues
> when upgrading switches. vPCs can add extreme (and usable) redundancy to
> multi-chassis design, if you want to go a step farther.
> 
> Justin
> 
> P.S. Comments made here are my own and should not in any way be
> considered an endorsement by the U.S. Federal Government.
> 
> Brad Hedlund wrote:
>> Mike,
>> The 6500 and 4500 have the "switch fabric" on the supervisor engines, so by
>> having dual supervisors, you in effect have a redundant fabric.
>> 
>> The 6748 actually has 4 traces, each 20G.  2 traces connect to the active
>> supervisor containing the active switch fabric.  The remaining 2 traces are
>> standby connections to the standby supervisor/fabric.  So, when a supervisor
>> engine and its fabric fails, the 2 standby traces are enabled and the full
>> 40G of bandwidth remains.  You never, under normal circumstances, have only
>> a single trace active on 6748.  Newer versions of IOS provide a "hot
>> standby" fabric feature which allows this fabric trace switch over to happen
>> faster - roughly 50ms.
>> 
>> For the best in redundant designs, consider the Nexus 7000, where the switch
>> fabric is decoupled from the supervisor engines into a series redundant
>> "fabric modules" installed into the back of the switch.  Should a supervisor
>> engine fail in Nexus 7000 there is ZERO impact to the switch fabric, because
>> the supervisor engine does not forward data plane traffic.
>> 
>> Cheers,
>> 
>> Brad Hedlund
>> bhedlund at cisco.com
>> http://www.internetworkexpert.org
>> 
>> 
>> On 3/31/09 9:05 AM, "Mike Louis" <MLouis at nwnit.com> wrote:
>> 
>>   
>>> I have a solution design that requires redundant switch fabrics. I am
>>> interpreting this beyond just have redundant supervisors meaning redundant
>>> backplanes on the switch cards. Do the 6500 and 4500 support redundant
>>> fabrics? Will a 6748 function with one trace failed?
>>> ________________________________
>>> Note: This message and any attachments is intended solely for the use of the
>>> individual or entity to which it is addressed and may contain information
>>> that
>>> is non-public, proprietary, legally privileged, confidential, and/or exempt
>>> from disclosure. If you are not the intended recipient, you are hereby
>>> notified that any use, dissemination, distribution, or copying of this
>>> communication is strictly prohibited. If you have received this
>>> communication
>>> in error, please notify the original sender immediately by telephone or
>>> return
>>> email and destroy or delete this message along with any attachments
>>> immediately.
>>> _______________________________________________
>>> cisco-nsp mailing 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 tvarriale at comcast.net  Tue Mar 31 13:18:41 2009
From: tvarriale at comcast.net (Tony Varriale)
Date: Tue, 31 Mar 2009 12:18:41 -0500
Subject: [c-nsp] Redundant switch fabric
References: <C5F7AAFA.31818%brhedlun@cisco.com> <49D24A2E.8010200@usgs.gov>
Message-ID: <980303CA84BD4FAC978E53062A1EFE1A@flamdt01>

I've had a colleague run into an issue going to 4.1.3 (long story but it's 
intrusive either way you slice it and is how all boxes are).  What was your 
upgrade from and to?

tv
----- Original Message ----- 
From: "Justin C. Darby" <jcdarby at usgs.gov>
To: "Brad Hedlund" <brhedlun at cisco.com>
Cc: <cisco-nsp at puck.nether.net>
Sent: Tuesday, March 31, 2009 11:51 AM
Subject: Re: [c-nsp] Redundant switch fabric


> Mike,
>
> Just to chime in here a bit with some experience - we've had Nexus 7K 
> switch backplane modules fail - unless you are pushing near 100% backplane 
> utilization you don't even notice until it emails you or your config 
> monitoring program notices the failed module. In recent NX-OS releases, In 
> Service Software Upgrades are working properly 100% of the time for us, 
> and outside of the fact it can take 3-4 hours to upgrade a fully loaded 
> switch, there's no real downtime if you've got working port redundancy 
> across modules, and modules only go down one at a time like they're 
> supposed to.
>
> Considering how distributed and redundant components of the switch are - 
> it's pretty unlikely you'd run into huge redundancy problems with any 
> single component. I don't have enough N7K's to play with Virtual Port 
> Channels (vPCs), but it'd be interesting to see if they have any issues 
> when upgrading switches. vPCs can add extreme (and usable) redundancy to 
> multi-chassis design, if you want to go a step farther.
>
> Justin
>
> P.S. Comments made here are my own and should not in any way be considered 
> an endorsement by the U.S. Federal Government.
>
> Brad Hedlund wrote:
>> Mike,
>> The 6500 and 4500 have the "switch fabric" on the supervisor engines, so 
>> by
>> having dual supervisors, you in effect have a redundant fabric.
>>
>> The 6748 actually has 4 traces, each 20G.  2 traces connect to the active
>> supervisor containing the active switch fabric.  The remaining 2 traces 
>> are
>> standby connections to the standby supervisor/fabric.  So, when a 
>> supervisor
>> engine and its fabric fails, the 2 standby traces are enabled and the 
>> full
>> 40G of bandwidth remains.  You never, under normal circumstances, have 
>> only
>> a single trace active on 6748.  Newer versions of IOS provide a "hot
>> standby" fabric feature which allows this fabric trace switch over to 
>> happen
>> faster - roughly 50ms.
>>
>> For the best in redundant designs, consider the Nexus 7000, where the 
>> switch
>> fabric is decoupled from the supervisor engines into a series redundant
>> "fabric modules" installed into the back of the switch.  Should a 
>> supervisor
>> engine fail in Nexus 7000 there is ZERO impact to the switch fabric, 
>> because
>> the supervisor engine does not forward data plane traffic.
>>
>> Cheers,
>>
>> Brad Hedlund
>> bhedlund at cisco.com
>> http://www.internetworkexpert.org
>>
>>
>> On 3/31/09 9:05 AM, "Mike Louis" <MLouis at nwnit.com> wrote:
>>
>>
>>> I have a solution design that requires redundant switch fabrics. I am
>>> interpreting this beyond just have redundant supervisors meaning 
>>> redundant
>>> backplanes on the switch cards. Do the 6500 and 4500 support redundant
>>> fabrics? Will a 6748 function with one trace failed?
>>> ________________________________
>>> Note: This message and any attachments is intended solely for the use of 
>>> the
>>> individual or entity to which it is addressed and may contain 
>>> information that
>>> is non-public, proprietary, legally privileged, confidential, and/or 
>>> exempt
>>> from disclosure. If you are not the intended recipient, you are hereby
>>> notified that any use, dissemination, distribution, or copying of this
>>> communication is strictly prohibited. If you have received this 
>>> communication
>>> in error, please notify the original sender immediately by telephone or 
>>> return
>>> email and destroy or delete this message along with any attachments
>>> immediately.
>>> _______________________________________________
>>> cisco-nsp mailing 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 tvarriale at comcast.net  Tue Mar 31 13:21:09 2009
From: tvarriale at comcast.net (Tony Varriale)
Date: Tue, 31 Mar 2009 12:21:09 -0500
Subject: [c-nsp] Redundant switch fabric
References: <CBBF2C7B2547D14A910A349B58810AC25C4CDBF234@mncmx1.NWNIT.CORP>
Message-ID: <0B39A3090B0B4F4CBC170CB78AE9CE74@flamdt01>

In Ciscoland, that is redundant sups.

I would recommend asking for clarification and educating on how redundant 
sups and redundant boxes provide some different resiliency options.

tv
----- Original Message ----- 
From: "Mike Louis" <MLouis at nwnit.com>
To: <cisco-nsp at puck.nether.net>
Sent: Tuesday, March 31, 2009 9:05 AM
Subject: [c-nsp] Redundant switch fabric


>I have a solution design that requires redundant switch fabrics. I am 
>interpreting this beyond just have redundant supervisors meaning redundant 
>backplanes on the switch cards. Do the 6500 and 4500 support redundant 
>fabrics? Will a 6748 function with one trace failed?
> ________________________________
> Note: This message and any attachments is intended solely for the use of 
> the individual or entity to which it is addressed and may contain 
> information that is non-public, proprietary, legally privileged, 
> confidential, and/or exempt from disclosure. If you are not the intended 
> recipient, you are hereby notified that any use, dissemination, 
> distribution, or copying of this communication is strictly prohibited. If 
> you have received this communication in error, please notify the original 
> sender immediately by telephone or return email and destroy or delete this 
> message along with any attachments immediately.
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/ 


From jcdarby at usgs.gov  Tue Mar 31 13:58:25 2009
From: jcdarby at usgs.gov (Justin C. Darby)
Date: Tue, 31 Mar 2009 12:58:25 -0500
Subject: [c-nsp] Redundant switch fabric
In-Reply-To: <980303CA84BD4FAC978E53062A1EFE1A@flamdt01>
References: <C5F7AAFA.31818%brhedlun@cisco.com> <49D24A2E.8010200@usgs.gov>
	<980303CA84BD4FAC978E53062A1EFE1A@flamdt01>
Message-ID: <49D259C1.3020901@usgs.gov>

We had issues with 4.0(?) releases, mostly related to strange behavior 
of a few features (dhcp relay, DAI, port security, etc) that required a 
full reload after a software upgrade to clear up completely. 4.1(?) has 
been fine so far, and the last upgrade we did was 4.1(2) to 4.1(4) and 
it went through without any downtime. We skipped over 4.1(3) since we 
never got around to scheduling it.

Justin

Tony Varriale wrote:
> I've had a colleague run into an issue going to 4.1.3 (long story but 
> it's intrusive either way you slice it and is how all boxes are).  
> What was your upgrade from and to?
>
> tv
> ----- Original Message ----- From: "Justin C. Darby" <jcdarby at usgs.gov>
> To: "Brad Hedlund" <brhedlun at cisco.com>
> Cc: <cisco-nsp at puck.nether.net>
> Sent: Tuesday, March 31, 2009 11:51 AM
> Subject: Re: [c-nsp] Redundant switch fabric
>
>
>> Mike,
>>
>> Just to chime in here a bit with some experience - we've had Nexus 7K 
>> switch backplane modules fail - unless you are pushing near 100% 
>> backplane utilization you don't even notice until it emails you or 
>> your config monitoring program notices the failed module. In recent 
>> NX-OS releases, In Service Software Upgrades are working properly 
>> 100% of the time for us, and outside of the fact it can take 3-4 
>> hours to upgrade a fully loaded switch, there's no real downtime if 
>> you've got working port redundancy across modules, and modules only 
>> go down one at a time like they're supposed to.
>>
>> Considering how distributed and redundant components of the switch 
>> are - it's pretty unlikely you'd run into huge redundancy problems 
>> with any single component. I don't have enough N7K's to play with 
>> Virtual Port Channels (vPCs), but it'd be interesting to see if they 
>> have any issues when upgrading switches. vPCs can add extreme (and 
>> usable) redundancy to multi-chassis design, if you want to go a step 
>> farther.
>>
>> Justin
>>
>> P.S. Comments made here are my own and should not in any way be 
>> considered an endorsement by the U.S. Federal Government.
>>
>> Brad Hedlund wrote:
>>> Mike,
>>> The 6500 and 4500 have the "switch fabric" on the supervisor 
>>> engines, so by
>>> having dual supervisors, you in effect have a redundant fabric.
>>>
>>> The 6748 actually has 4 traces, each 20G.  2 traces connect to the 
>>> active
>>> supervisor containing the active switch fabric.  The remaining 2 
>>> traces are
>>> standby connections to the standby supervisor/fabric.  So, when a 
>>> supervisor
>>> engine and its fabric fails, the 2 standby traces are enabled and 
>>> the full
>>> 40G of bandwidth remains.  You never, under normal circumstances, 
>>> have only
>>> a single trace active on 6748.  Newer versions of IOS provide a "hot
>>> standby" fabric feature which allows this fabric trace switch over 
>>> to happen
>>> faster - roughly 50ms.
>>>
>>> For the best in redundant designs, consider the Nexus 7000, where 
>>> the switch
>>> fabric is decoupled from the supervisor engines into a series redundant
>>> "fabric modules" installed into the back of the switch.  Should a 
>>> supervisor
>>> engine fail in Nexus 7000 there is ZERO impact to the switch fabric, 
>>> because
>>> the supervisor engine does not forward data plane traffic.
>>>
>>> Cheers,
>>>
>>> Brad Hedlund
>>> bhedlund at cisco.com
>>> http://www.internetworkexpert.org
>>>
>>>
>>> On 3/31/09 9:05 AM, "Mike Louis" <MLouis at nwnit.com> wrote:
>>>
>>>
>>>> I have a solution design that requires redundant switch fabrics. I am
>>>> interpreting this beyond just have redundant supervisors meaning 
>>>> redundant
>>>> backplanes on the switch cards. Do the 6500 and 4500 support redundant
>>>> fabrics? Will a 6748 function with one trace failed?
>>>> ________________________________
>>>> Note: This message and any attachments is intended solely for the 
>>>> use of the
>>>> individual or entity to which it is addressed and may contain 
>>>> information that
>>>> is non-public, proprietary, legally privileged, confidential, 
>>>> and/or exempt
>>>> from disclosure. If you are not the intended recipient, you are hereby
>>>> notified that any use, dissemination, distribution, or copying of this
>>>> communication is strictly prohibited. If you have received this 
>>>> communication
>>>> in error, please notify the original sender immediately by 
>>>> telephone or return
>>>> email and destroy or delete this message along with any attachments
>>>> immediately.
>>>> _______________________________________________
>>>> cisco-nsp mailing 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/ 
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


From asturluismi at gmail.com  Tue Mar 31 14:26:48 2009
From: asturluismi at gmail.com (luismi)
Date: Tue, 31 Mar 2009 20:26:48 +0200
Subject: [c-nsp] IPSec tunnel between Cisco router and PFSense firewall.
Message-ID: <1238524008.7827.13.camel@dsba-ipso>

Is there anyone with a template to connect a Cisco router to a PFSense
firewall using IPSec?

Well, I think any other template would be a good start point too.

Thanks in advance.


From ssaner at pantheranet.com  Tue Mar 31 16:05:41 2009
From: ssaner at pantheranet.com (Steven Saner)
Date: Tue, 31 Mar 2009 15:05:41 -0500
Subject: [c-nsp] Multilink PPPoA
In-Reply-To: <F1BF3051-4E06-439D-B51D-66C5D22CF88F@lixfeld.ca>
References: <5FE5BC34-7ECD-4905-B0FD-42C124C54DCC@pantheranet.com>
	<F1BF3051-4E06-439D-B51D-66C5D22CF88F@lixfeld.ca>
Message-ID: <38B81063-1142-4D15-8ABB-2178745DCA56@pantheranet.com>


On Mar 30, 2009, at 4:47 PM, Jason Lixfeld wrote:

> I actually just set this up on the weekend.  You can use virtual- 
> template 1 ip unnumbered with an ip pool on the headend and dialer0  
> ip address negotiated on the client too if you don't want statically  
> routed clients.


Thanks to a couple offline replies, I got this working. I'm replying  
with my working config for the benefit of anyone searching the  
archives and in case anyone has any comments on something that could  
be done different/better. Thanks for the help.

On the 7206 all I needed to do was add a Virtual-Template interface  
for the multilink and point the relevant pvcs to it:

interface Virtual-Template3
  ip unnumbered Loopback0
  ppp authentication pap dsl
  ppp authorization dsl
  ppp multilink

The only line different than my "normal" template is the "ppp  
multilink" line. The reference to "dsl" is the name of the radius  
profile that I'm using.

interface ATM2/0.1000 multipoint
  pvc 3/70
   encapsulation aal5mux ppp Virtual-Template3

  pvc 3/177
   encapsulation aal5mux ppp Virtual-Template3


On the client side (1721) I have the following:

interface Virtual-Template1
  ip address negotiated
  ppp pap sent-username xxxxxxx password xxxxxxxx
  ppp multilink

The two ATM interfaces look like the following

interface ATM0
  no ip address
  no atm ilmi-keepalive
  dsl operating-mode auto
  dsl enable-training-log
  pvc 0/35
   encapsulation aal5mux ppp Virtual-Template1


That's it. I needed no Dialer interface. The two links come up, get  
bound and stay up. Is there any particular reason why a Dialer  
interface would be better or advisable?

Also the 1721 is running 12.3 mainline with ADSL WIC support and the  
7206 is running 12.4 mainline.

Steve

--
---------------------------------------------------------------
Steven Saner
steve at saner.net






From ras at e-gerbil.net  Tue Mar 31 16:12:10 2009
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Tue, 31 Mar 2009 15:12:10 -0500
Subject: [c-nsp] 10GE card for 7609
In-Reply-To: <49D1CDD4.3080301@skoal.name>
References: <863386.41277.qm@web44809.mail.sp1.yahoo.com>
	<20090330151600.GA408@roxanne.org> <49D1BE37.8060402@skoal.name>
	<20090331074620.GV290@greenie.muc.de> <49D1CDD4.3080301@skoal.name>
Message-ID: <20090331201210.GF51443@gerbil.cluepon.net>

On Tue, Mar 31, 2009 at 10:01:24AM +0200, Gergely Antal wrote:
> I meant that you can not push 40G out of a 6704
> even with a dfc attached to it.But you can do it with a 6708
> with 1:1 subscription.

Worse, some days you can't even get 7G in from a single port on a 6704
with the other 3 ports unused. We routinely have problems with ingress
interface overruns or egress interface output queue overflows on 6704 
in that traffic range, and DFC doesn't make any difference.

It seems like it is head of line blocking, and TAC's only answer is
"those things have no buffers, buy a 6708". The problem can usually be
worked around by changing the way traffic is being mapped between the
ports. For example, the one that seems to be the absolute worst case is
"in one port and out the other on the same fabric channel", i.e. in port
1 and out port 2 or the same thing on 3/4.

-- 
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 gokhanciscottl at yahoo.com  Tue Mar 31 15:17:59 2009
From: gokhanciscottl at yahoo.com (gokhan senol)
Date: Tue, 31 Mar 2009 12:17:59 -0700 (PDT)
Subject: [c-nsp] cisco-nsp Digest, Vol 76, Issue 117
In-Reply-To: <mailman.1198.1238519700.2460.cisco-nsp@puck.nether.net>
References: <mailman.1198.1238519700.2460.cisco-nsp@puck.nether.net>
Message-ID: <291381.19726.qm@web38504.mail.mud.yahoo.com>

Hi 
I need a help about designing the topology below.
?
the customer has HQ and now wanna design disaster center. As you can guess both HQ and Disaster side have server farms. (Actv.Dir. - Exc. - some appl?cation servers)
also there are ?about 50 remote sides. its an mpls topology.
?
case? : if? HQ connection to ISP goes down then the server farm in HQ?will be unreachable and the remote sides will access to disaster side. its ok
but if only one server goes down in HQ , what kind of config should I do on the HQ router so the connections come to that server will be rerouted to the backup server in disaster side. 
?
and also I thougt giving same ip subnet for HQ and disaster and also I thought using overlapping nat to access both side to eachtoher.? Is it correct design ?
?
thnkx evry1


      

From jason at lixfeld.ca  Tue Mar 31 16:37:53 2009
From: jason at lixfeld.ca (Jason Lixfeld)
Date: Tue, 31 Mar 2009 16:37:53 -0400
Subject: [c-nsp] 10GE card for 7609
In-Reply-To: <20090331201210.GF51443@gerbil.cluepon.net>
References: <863386.41277.qm@web44809.mail.sp1.yahoo.com>
	<20090330151600.GA408@roxanne.org> <49D1BE37.8060402@skoal.name>
	<20090331074620.GV290@greenie.muc.de> <49D1CDD4.3080301@skoal.name>
	<20090331201210.GF51443@gerbil.cluepon.net>
Message-ID: <4B420328-2977-4D30-A7EC-EA81B0A19BAB@lixfeld.ca>

Looks like the 6708 isn't as bad as we think.

On 2009-03-31, at 4:12 PM, Richard A Steenbergen <ras at e-gerbil.net>  
wrote:

> On Tue, Mar 31, 2009 at 10:01:24AM +0200, Gergely Antal wrote:
>> I meant that you can not push 40G out of a 6704
>> even with a dfc attached to it.But you can do it with a 6708
>> with 1:1 subscription.
>
> Worse, some days you can't even get 7G in from a single port on a 6704
> with the other 3 ports unused. We routinely have problems with ingress
> interface overruns or egress interface output queue overflows on 6704
> in that traffic range, and DFC doesn't make any difference.
>
> It seems like it is head of line blocking, and TAC's only answer is
> "those things have no buffers, buy a 6708". The problem can usually be
> worked around by changing the way traffic is being mapped between the
> ports. For example, the one that seems to be the absolute worst case  
> is
> "in one port and out the other on the same fabric channel", i.e. in  
> port
> 1 and out port 2 or the same thing on 3/4.
>
> -- 
> 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)
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From stevend at uidaho.edu  Tue Mar 31 16:43:08 2009
From: stevend at uidaho.edu (Dodd, Steven)
Date: Tue, 31 Mar 2009 13:43:08 -0700
Subject: [c-nsp] 10GE card for 7609
In-Reply-To: <4B420328-2977-4D30-A7EC-EA81B0A19BAB@lixfeld.ca>
References: <863386.41277.qm@web44809.mail.sp1.yahoo.com><20090330151600.GA408@roxanne.org>
	<49D1BE37.8060402@skoal.name><20090331074620.GV290@greenie.muc.de>
	<49D1CDD4.3080301@skoal.name><20090331201210.GF51443@gerbil.cluepon.net>
	<4B420328-2977-4D30-A7EC-EA81B0A19BAB@lixfeld.ca>
Message-ID: <4C0A1E4AB1B97642AFB097A8CDA0B223D7D5EC@EXVS1.its.uidaho.edu>

Keith Tokash has a pretty good writeup on the 6704 vs 6708 buffer issue:

http://www.cciecandidate.com/?p=505

-Steve

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Jason Lixfeld
Sent: Tuesday, March 31, 2009 1:38 PM
To: Richard A Steenbergen
Cc: Gert Doering; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] 10GE card for 7609

Looks like the 6708 isn't as bad as we think.

On 2009-03-31, at 4:12 PM, Richard A Steenbergen <ras at e-gerbil.net>  
wrote:

> On Tue, Mar 31, 2009 at 10:01:24AM +0200, Gergely Antal wrote:
>> I meant that you can not push 40G out of a 6704
>> even with a dfc attached to it.But you can do it with a 6708
>> with 1:1 subscription.
>
> Worse, some days you can't even get 7G in from a single port on a 6704
> with the other 3 ports unused. We routinely have problems with ingress
> interface overruns or egress interface output queue overflows on 6704
> in that traffic range, and DFC doesn't make any difference.
>
> It seems like it is head of line blocking, and TAC's only answer is
> "those things have no buffers, buy a 6708". The problem can usually be
> worked around by changing the way traffic is being mapped between the
> ports. For example, the one that seems to be the absolute worst case  
> is
> "in one port and out the other on the same fabric channel", i.e. in  
> port
> 1 and out port 2 or the same thing on 3/4.
>
> -- 
> 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)
> _______________________________________________
> cisco-nsp mailing 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 c-nsp at djvh.nl  Tue Mar 31 16:44:15 2009
From: c-nsp at djvh.nl (Dirk-Jan van Helmond)
Date: Tue, 31 Mar 2009 22:44:15 +0200
Subject: [c-nsp] 3750/3750E stack upgrade downtime?
In-Reply-To: <1238445916.4440.7.camel@localhost.localdomain>
References: <49D1297B.2080106@utc.edu>
	<1238445916.4440.7.camel@localhost.localdomain>
Message-ID: <D1297168-1BF4-4A8C-AC48-E041AE7A0766@djvh.nl>

I'm also interested in this question.

We're thinking about getting some Cisco CBS 3110 blade switches to  
aggeregate the interfaces from the bladeservers. The CBS3110 can stack  
and is factually just an 3750 in a blade enclosure and has the same  
roadmap as the 3750.
I would very much like to have ISSU on these switches, otherwise an  
IOS upgrade means downtime for an entire bladechassis, which is  
unacceptable.
Unfortunately ISSU is not supported and not on the roadmap :(

I've asked my accountmanager @Cisco, so you please ask yours. Maybe if  
we ask kind enough, they will think about it ;)


regards,
Dirk-Jan





On Mar 30, 2009, at 22:45 , Peter Rathlev wrote:

> On Mon, 2009-03-30 at 16:20 -0400, Jeff Kell wrote:
>> Is there any way to "roll" an upgrade out to a 3750 stack without
>> abruptly rebooting the entire stack?
>
> I would very much like to know if there is. AFAIK you can't complete  
> the
> upgrade without downtime. Two switches with even just rebuild version
> differences can't live together in the same stack, so there's no  
> chance
> of upgrading without significant downtime.
>
> We're starting to use 3750E with 10G trunks in between them instead of
> Stackwise. This makes it possible to upgrade practically without
> downtime.
>
> 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 bmengel at gmail.com  Tue Mar 31 16:48:12 2009
From: bmengel at gmail.com (Brian Mengel)
Date: Tue, 31 Mar 2009 16:48:12 -0400
Subject: [c-nsp] 10GE card for 7609
In-Reply-To: <4B420328-2977-4D30-A7EC-EA81B0A19BAB@lixfeld.ca>
References: <863386.41277.qm@web44809.mail.sp1.yahoo.com>
	<20090330151600.GA408@roxanne.org> <49D1BE37.8060402@skoal.name>
	<20090331074620.GV290@greenie.muc.de> <49D1CDD4.3080301@skoal.name>
	<20090331201210.GF51443@gerbil.cluepon.net>
	<4B420328-2977-4D30-A7EC-EA81B0A19BAB@lixfeld.ca>
Message-ID: <f67ff60b0903311348h7348073ax944bec4a8db08d64@mail.gmail.com>

This got me curious, so I did a bit of digging.

http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/product_data_sheet09186a00801dce34.html

WS-X6704-10GE - 16MB port buffers
WS-X6708-10G-3CXL - 200 MB port buffers

http://www.cisco.com/en/US/prod/collateral/routers/ps368/data_sheet_c78-49152.html

7600-ES+4TG3CXL - 512MB port buffers



On Tue, Mar 31, 2009 at 4:37 PM, Jason Lixfeld <jason at lixfeld.ca> wrote:
> Looks like the 6708 isn't as bad as we think.
>
> On 2009-03-31, at 4:12 PM, Richard A Steenbergen <ras at e-gerbil.net> wrote:
>
>> On Tue, Mar 31, 2009 at 10:01:24AM +0200, Gergely Antal wrote:
>>>
>>> I meant that you can not push 40G out of a 6704
>>> even with a dfc attached to it.But you can do it with a 6708
>>> with 1:1 subscription.
>>
>> Worse, some days you can't even get 7G in from a single port on a 6704
>> with the other 3 ports unused. We routinely have problems with ingress
>> interface overruns or egress interface output queue overflows on 6704
>> in that traffic range, and DFC doesn't make any difference.
>>
>> It seems like it is head of line blocking, and TAC's only answer is
>> "those things have no buffers, buy a 6708". The problem can usually be
>> worked around by changing the way traffic is being mapped between the
>> ports. For example, the one that seems to be the absolute worst case is
>> "in one port and out the other on the same fabric channel", i.e. in port
>> 1 and out port 2 or the same thing on 3/4.
>>
>> --
>> 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)
>> _______________________________________________
>> cisco-nsp mailing 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 kloch at kl.net  Tue Mar 31 17:16:27 2009
From: kloch at kl.net (Kevin Loch)
Date: Tue, 31 Mar 2009 17:16:27 -0400
Subject: [c-nsp] 10GE card for 7609
In-Reply-To: <20090331201210.GF51443@gerbil.cluepon.net>
References: <863386.41277.qm@web44809.mail.sp1.yahoo.com>	<20090330151600.GA408@roxanne.org>
	<49D1BE37.8060402@skoal.name>	<20090331074620.GV290@greenie.muc.de>
	<49D1CDD4.3080301@skoal.name>
	<20090331201210.GF51443@gerbil.cluepon.net>
Message-ID: <49D2882B.4010900@kl.net>

Richard A Steenbergen wrote:
> On Tue, Mar 31, 2009 at 10:01:24AM +0200, Gergely Antal wrote:
>> I meant that you can not push 40G out of a 6704
>> even with a dfc attached to it.But you can do it with a 6708
>> with 1:1 subscription.
 >
> Worse, some days you can't even get 7G in from a single port on a 6704
> with the other 3 ports unused. We routinely have problems with ingress
> interface overruns or egress interface output queue overflows on 6704 
> in that traffic range, and DFC doesn't make any difference.

Did you have any fabric channel on the router with
utilization over 90% while this was happening?  We had a similar
problem where any one fabric channel being maxed out would cause
unrelated cards to have input buffer overruns.

- Kevin

From Trevor.Korthuis at telus.com  Tue Mar 31 17:26:47 2009
From: Trevor.Korthuis at telus.com (Trevor Korthuis)
Date: Tue, 31 Mar 2009 15:26:47 -0600
Subject: [c-nsp] 7609 SP fails over on KPA failure
Message-ID: <BD4E71BD9756DF45BAA01378F7F257ED84848F1FC4@WP40046.corp.ads>

We have 2 7609's that are failing over to the redundant SP approximately every 5 days. These boxes are in network with PIM-SM multicast and IPV4 routed traffic running sup720's with SRA2. These failovers  started after 2 6516 GE cards were removed and replaced with 2 6704 10GE cards. When the 6516 cards were pulled, the boxes changed from Ingress Multicast Replication Mode to Egress mode. We have now forced the boxes back into Ingress Mode and have pulled the new 6704 cards.

We have a number of boxes with this configuration and these are the only 2 boxes with these symptoms. Only difference with these boxes is that they have 2 6704 cards running 4.7 firmware whereas the majority of 6704 cards in our network have 4.6 firmware.  In the lab, we have the same configuration and have multiple 6704's with the 4.7 firmware and in the same serial number range and cannot reproduce the issue. Cisco is currently trying to reproduce the issue in their labs. 

Cisco has determined that the ICC channel looks to be congested during one of these failovers, but cannot determine why.  Any chance that there is someone currently running 7609's in a multicast network having a similar sup720 failover issue?

Trevor

From felixnkansah at gmail.com  Tue Mar 31 17:36:36 2009
From: felixnkansah at gmail.com (Felix Nkansah)
Date: Tue, 31 Mar 2009 21:36:36 +0000
Subject: [c-nsp] OT: Cisco Anyconnect Client with IOS SSL
Message-ID: <18dba4e50903311436i67bef46dx55ffb9fd97c15bda@mail.gmail.com>

Hi Team,
I am trying to setup the Cisco IOS SSL to support Anyconnect client.

Much as I have entered all the required commands, the configuration doesn't
work. My IOS is (C2800NM-ADVIPSERVICESK9-M), Version 12.4(22)T.

I would appreciate if any in this team with experience setting up anyconnect
with IOS can draw my attention to any caveats.

I have selected the necessary portion of my router config for your review,
if necessary.

Many thanks.

*
aaa new-model
!
aaa authentication login VPN local
aaa authorization network VPN local

crypto pki trustpoint TP-self-signed-2613188008
 enrollment selfsigned
 subject-name cn=IOS-Self-Signed-Certificate-2613188008
 revocation-check none
 rsakeypair TP-self-signed-2613188008

username remote secret 5 $1$86qN$CJ2uc1l7PYy7a5sNMrPK2/

ip local pool WEBVPN 192.168.250.11 192.168.250.111

webvpn gateway SSL
 hostname CIS-EDGE1
 ip address 80.87.77.18 port 443
 http-redirect port 80
 ssl encryption 3des-sha1 aes-sha1
 ssl trustpoint TP-self-signed-2613188008
 inservice
 !
webvpn install svc flash:/webvpn/svc_1.pkg sequence 1
 !
webvpn install svc flash:/webvpn/svc_2.pkg sequence 2
 !
webvpn install svc flash:/webvpn/svc_3.pkg sequence 3
 !
webvpn context SSL
 ssl authenticate verify all
 !
 !
 policy group SSL
   functions svc-enabled
   svc address-pool "WEBVPN"
   svc default-domain "cisghana.com"
   svc keep-client-installed
   svc dpd-interval gateway 30
   svc keepalive 300
   svc split dns "cisghana.com"
   svc split include 192.168.1.0 255.255.255.0
   svc split include 192.168.3.0 255.255.255.0
   svc split include 192.168.4.0 255.255.255.0
   svc split include 192.168.21.0 255.255.255.0
   svc dns-server primary 192.168.21.17
   svc dns-server secondary 192.168.21.18
 default-group-policy SSL
 aaa authentication list VPN
 aaa authorization list VPN
 gateway SSL domain cisghana.com
 logging enable
 inservice

interface Loopback1
 description For SSL VPN Use
 ip address 192.168.250.250 255.255.255.0

interface GigabitEthernet0/0.80
 encapsulation dot1Q 80
 ip address 80.87.77.18 255.255.255.248
 ip access-group OUTSIDE in //this acl permits ports 80 and 443 to the
interface
 no ip unreachables
 ip nat outside
 ip inspect CBAC out
 ip virtual-reassembly*

From peter at rathlev.dk  Tue Mar 31 17:50:44 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Tue, 31 Mar 2009 23:50:44 +0200
Subject: [c-nsp] 3750/3750E stack upgrade downtime?
In-Reply-To: <D1297168-1BF4-4A8C-AC48-E041AE7A0766@djvh.nl>
References: <49D1297B.2080106@utc.edu>
	<1238445916.4440.7.camel@localhost.localdomain>
	<D1297168-1BF4-4A8C-AC48-E041AE7A0766@djvh.nl>
Message-ID: <1238536244.3604.0.camel@localhost.localdomain>

On Tue, 2009-03-31 at 22:44 +0200, Dirk-Jan van Helmond wrote:
> I've asked my accountmanager @Cisco, so you please ask yours. Maybe if  
> we ask kind enough, they will think about it ;)

Yeah, that usually works like a charm. Remember BFD for SVIs? ;-)

Regards,
Peter



From tvarriale at comcast.net  Tue Mar 31 18:48:59 2009
From: tvarriale at comcast.net (Tony Varriale)
Date: Tue, 31 Mar 2009 17:48:59 -0500
Subject: [c-nsp] 3750/3750E stack upgrade downtime?
References: <49D1297B.2080106@utc.edu><1238445916.4440.7.camel@localhost.localdomain><D1297168-1BF4-4A8C-AC48-E041AE7A0766@djvh.nl>
	<1238536244.3604.0.camel@localhost.localdomain>
Message-ID: <EBBDD8F06E0F4F2AB7C3027C2CD0C83A@flamdt01>

What was asked of the account manager?

tv
----- Original Message ----- 
From: "Peter Rathlev" <peter at rathlev.dk>
To: "Dirk-Jan van Helmond" <c-nsp at djvh.nl>
Cc: "cisco-nsp" <cisco-nsp at puck.nether.net>
Sent: Tuesday, March 31, 2009 4:50 PM
Subject: Re: [c-nsp] 3750/3750E stack upgrade downtime?


> On Tue, 2009-03-31 at 22:44 +0200, Dirk-Jan van Helmond wrote:
>> I've asked my accountmanager @Cisco, so you please ask yours. Maybe if  
>> we ask kind enough, they will think about it ;)
> 
> Yeah, that usually works like a charm. Remember BFD for SVIs? ;-)
> 
> 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 jared at corp.sonic.net  Tue Mar 31 19:44:40 2009
From: jared at corp.sonic.net (Jared Gillis)
Date: Tue, 31 Mar 2009 16:44:40 -0700
Subject: [c-nsp] L2TPv3 password keeps changing
In-Reply-To: <44417CD2F19FEA4F885088340A71D33201B4F41D@mail.office.dansketelecom.com>
References: <44417CD2F19FEA4F885088340A71D33201B4F41D@mail.office.dansketelecom.com>
Message-ID: <49D2AAE8.3030503@corp.sonic.net>

I'm seeing this behavior as well on a 7204VXR, and google only turns up two
threads on c-nsp that have no replies.
Is this expected? Is there a workaround?

Lars Lystrup Christensen wrote:
>  
> 
> Hi all,
> 
>  
> 
> When configuring L2TPv3 on one of our routers, I've noticed that the
> password keeps changing all the time, even tough the configuration has
> not been altered.
> 
>  
> 
> The router is a 1811 running 12.4(6)T11 Advanced IP Services.
> 
> ______________________________________
> 
> Med venlig hilsen / Kind regards
> 
> Lars Lystrup Christensen 
> Director of Engineering, CCIE(tm) #20292
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 


-- 
Jared Gillis - jared at corp.sonic.net       Sonic.net, Inc.
Network Operations                        2260 Apollo Way
707.522.1000 (Voice)                      Santa Rosa, CA 95407
707.547.3400 (Support)                    http://www.sonic.net/

From peter at rathlev.dk  Tue Mar 31 20:22:38 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Wed, 01 Apr 2009 02:22:38 +0200
Subject: [c-nsp] 3750/3750E stack upgrade downtime?
In-Reply-To: <EBBDD8F06E0F4F2AB7C3027C2CD0C83A@flamdt01>
References: <49D1297B.2080106@utc.edu>
	<1238445916.4440.7.camel@localhost.localdomain>
	<D1297168-1BF4-4A8C-AC48-E041AE7A0766@djvh.nl>
	<1238536244.3604.0.camel@localhost.localdomain>
	<EBBDD8F06E0F4F2AB7C3027C2CD0C83A@flamdt01>
Message-ID: <1238545358.3604.26.camel@localhost.localdomain>

> > On Tue, 2009-03-31 at 22:44 +0200, Dirk-Jan van Helmond wrote:
> >> I've asked my accountmanager @Cisco, so you please ask yours. Maybe if  
> >> we ask kind enough, they will think about it ;)

> Tuesday, March 31, 2009 4:50 PM, Peter Rathlev wrote:
> > Yeah, that usually works like a charm. Remember BFD for SVIs? ;-)

On Tue, 2009-03-31 at 17:48 -0500, Tony Varriale wrote:
> What was asked of the account manager?

We asked if we could have BFD for SVIs in SXH (and further). The AM
would do back with it, but we haven't seen any BFD for SVIs yet.

(I assume the question was for me.)

Regards,
Peter



From illcritikz at gmail.com  Tue Mar 31 20:53:14 2009
From: illcritikz at gmail.com (Ben Steele)
Date: Wed, 1 Apr 2009 11:23:14 +1030
Subject: [c-nsp] 10GE card for 7609
In-Reply-To: <d6966e4b0903310924r3f857c6dmf7c7a1fb2ee5712a@mail.gmail.com>
References: <863386.41277.qm@web44809.mail.sp1.yahoo.com>
	<d6966e4b0903310924r3f857c6dmf7c7a1fb2ee5712a@mail.gmail.com>
Message-ID: <4422cf660903311753s3f7b7e40j140c32891bcd472e@mail.gmail.com>

Yes you can use the WS-670x in the 7600 with an RSP, I have a couple of
chassis with this at the moment, given they are the 6704(one with DFC)
10GE's but I can't see a 6708 not working either...
7600#sh mod
Mod Ports Card Type                              Model              Serial
No.
--- ----- -------------------------------------- ------------------
-----------
  1    4  CEF720 4 port 10-Gigabit Ethernet      WS-X6704-10GE      SERIAL
  2    4  CEF720 4 port 10-Gigabit Ethernet      WS-X6704-10GE      SERIAL
  3   48  CEF720 48 port 10/100/1000mb Ethernet  WS-X6748-GE-TX     SERIAL
  5    2  Route Switch Processor 720 (Active)    RSP720-3CXL-GE     SERIAL

On Wed, Apr 1, 2009 at 2:54 AM, Geoffrey Pendery <geoff at pendery.net> wrote:

> The stuff we've been reading (look at "Supervisor Engines Supported"
> on the data sheets for "Cisco Catalyst 6500 Series 10 Gigabit Ethernet
> Interface Modules", or browse the line cards for the 7600, or go into
> Configurator tool) claims that the RSP 720 won't support the X6704 or
> X6708 10 Gig "LAN" cards, only the SIP/SPA/ES "WAN" type cards.
>
> I don't mean to kick off a big "6500 vs 7600" storm again, but does
> anyone know if this is incorrect?
> Can we buy a new 7609-S chassis, put a new RSP 720 in it, put 7600 IOS
> on that Sup, then plug in a WS-X6708-10G-3C and have it work?
>
>
> -Geoff
>
>
> On Mon, Mar 30, 2009 at 4:41 AM, Mark Tech <techconfig at yahoo.com> wrote:
> >
> > Hi
> > I have a prospect for a 10G upstream customer and Upstream ISP
> connections. I would need to connect these into our 7609s running RSP
> 720-3CXL's, at the moment I have found that the WS-X6704-10GE card may be
> suitable.
> >
> > My technical requirements are:
> > 10Gbps line rate
> > IPv4
> > Able to handle full Internet routing table
> > Potentially IPv6 and MPLS in the future
> >
> > With the WS-X6704-10GE, there seems to be several options that are
> available with it i.e.
> >
> > Memory Option:
> > MEM-XCEF720-256M
> > Catalyst 6500 256MB DDR, xCEF720 (67xx interface, DFC3A)
> > MEM-XCEF720-512M
> > Cat 6500 512MB DDR, xCEF720 (67xx interface, DFC3A/DFC3B)
> > MEM-XCEF720-1GB
> > Catalyst 6500 1GB DDR, xCEF720 (67xx interface, DFC3BXL)
> >
> > ====================================================
> > Distributed Forwarding Card Option
> >
> > WS-F6700-CFC
> > Catalyst 6500 Central Fwd Card for WS-X67xx modules
> > WS-F6700-DFC3B
> > Catalyst 6500 Dist Fwd Card, 256K Routes for WS-X67xx
> > WS-F6700-DFC3A
> > Catalyst 6500 Dist Fwd Card for WS-X67xx modules
> > WS-F6700-DFC3BXL
> > Catalyst 6500 Dist Fwd Card- 3BXL, for WS-X67xx
> > WS-F6700-DFC3C
> > Catalyst 6500 Dist Fwd Card for WS-X67xx modules
> > WS-F6700-DFC3CXL
> > Catalyst 6500 Dist Fwd Card- 3CXL, for WS-X67xx
> >
> > I assume that I would need MEM-XCEF720-1GB and WS-F6700-DFC3CXL?
> >
> > Regards
> >
> > Mark
> >
> >
> >
> >
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> >
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From jon at defenderhosting.com  Tue Mar 31 21:00:14 2009
From: jon at defenderhosting.com (Jon Wolberg)
Date: Tue, 31 Mar 2009 21:00:14 -0400 (EDT)
Subject: [c-nsp] 10GE card for 7609
In-Reply-To: <936646648.5478201238547496521.JavaMail.root@mail.dtgmail.com>
Message-ID: <2069085910.5478341238547614255.JavaMail.root@mail.dtgmail.com>

How much RAM do you have in your 6704?  I have some too running in a RSP without issues and just got a new one.  It refused to push the FIB to the DFC and blew up due to low memory.  Our vendor only put a 256MB stick of RAM in this card when they usually have 1GB.

Other than that, I haven't had any issues.


Jon Wolberg
Operations Manager
PowerVPS / Defender Hosting
Defender Technologies Group, LLC.


----- Original Message -----
From: "Ben Steele" <illcritikz at gmail.com>
To: "Geoffrey Pendery" <geoff at pendery.net>
Cc: cisco-nsp at puck.nether.net
Sent: Tuesday, March 31, 2009 8:53:14 PM GMT -05:00 US/Canada Eastern
Subject: Re: [c-nsp] 10GE card for 7609

Yes you can use the WS-670x in the 7600 with an RSP, I have a couple of
chassis with this at the moment, given they are the 6704(one with DFC)
10GE's but I can't see a 6708 not working either...
7600#sh mod
Mod Ports Card Type                              Model              Serial
No.
--- ----- -------------------------------------- ------------------
-----------
  1    4  CEF720 4 port 10-Gigabit Ethernet      WS-X6704-10GE      SERIAL
  2    4  CEF720 4 port 10-Gigabit Ethernet      WS-X6704-10GE      SERIAL
  3   48  CEF720 48 port 10/100/1000mb Ethernet  WS-X6748-GE-TX     SERIAL
  5    2  Route Switch Processor 720 (Active)    RSP720-3CXL-GE     SERIAL

On Wed, Apr 1, 2009 at 2:54 AM, Geoffrey Pendery <geoff at pendery.net> wrote:

> The stuff we've been reading (look at "Supervisor Engines Supported"
> on the data sheets for "Cisco Catalyst 6500 Series 10 Gigabit Ethernet
> Interface Modules", or browse the line cards for the 7600, or go into
> Configurator tool) claims that the RSP 720 won't support the X6704 or
> X6708 10 Gig "LAN" cards, only the SIP/SPA/ES "WAN" type cards.
>
> I don't mean to kick off a big "6500 vs 7600" storm again, but does
> anyone know if this is incorrect?
> Can we buy a new 7609-S chassis, put a new RSP 720 in it, put 7600 IOS
> on that Sup, then plug in a WS-X6708-10G-3C and have it work?
>
>
> -Geoff
>
>
> On Mon, Mar 30, 2009 at 4:41 AM, Mark Tech <techconfig at yahoo.com> wrote:
> >
> > Hi
> > I have a prospect for a 10G upstream customer and Upstream ISP
> connections. I would need to connect these into our 7609s running RSP
> 720-3CXL's, at the moment I have found that the WS-X6704-10GE card may be
> suitable.
> >
> > My technical requirements are:
> > 10Gbps line rate
> > IPv4
> > Able to handle full Internet routing table
> > Potentially IPv6 and MPLS in the future
> >
> > With the WS-X6704-10GE, there seems to be several options that are
> available with it i.e.
> >
> > Memory Option:
> > MEM-XCEF720-256M
> > Catalyst 6500 256MB DDR, xCEF720 (67xx interface, DFC3A)
> > MEM-XCEF720-512M
> > Cat 6500 512MB DDR, xCEF720 (67xx interface, DFC3A/DFC3B)
> > MEM-XCEF720-1GB
> > Catalyst 6500 1GB DDR, xCEF720 (67xx interface, DFC3BXL)
> >
> > ====================================================
> > Distributed Forwarding Card Option
> >
> > WS-F6700-CFC
> > Catalyst 6500 Central Fwd Card for WS-X67xx modules
> > WS-F6700-DFC3B
> > Catalyst 6500 Dist Fwd Card, 256K Routes for WS-X67xx
> > WS-F6700-DFC3A
> > Catalyst 6500 Dist Fwd Card for WS-X67xx modules
> > WS-F6700-DFC3BXL
> > Catalyst 6500 Dist Fwd Card- 3BXL, for WS-X67xx
> > WS-F6700-DFC3C
> > Catalyst 6500 Dist Fwd Card for WS-X67xx modules
> > WS-F6700-DFC3CXL
> > Catalyst 6500 Dist Fwd Card- 3CXL, for WS-X67xx
> >
> > I assume that I would need MEM-XCEF720-1GB and WS-F6700-DFC3CXL?
> >
> > Regards
> >
> > 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/
>
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From illcritikz at gmail.com  Tue Mar 31 21:30:21 2009
From: illcritikz at gmail.com (Ben Steele)
Date: Wed, 1 Apr 2009 12:00:21 +1030
Subject: [c-nsp] 10GE card for 7609
In-Reply-To: <2069085910.5478341238547614255.JavaMail.root@mail.dtgmail.com>
References: <936646648.5478201238547496521.JavaMail.root@mail.dtgmail.com>
	<2069085910.5478341238547614255.JavaMail.root@mail.dtgmail.com>
Message-ID: <4422cf660903311830l7c7bae95gcf712bdad2d90fbf@mail.gmail.com>

1GB on the DFC, 256MB definitely wouldn't cut it for us.

On Wed, Apr 1, 2009 at 11:30 AM, Jon Wolberg <jon at defenderhosting.com>wrote:

> How much RAM do you have in your 6704?  I have some too running in a RSP
> without issues and just got a new one.  It refused to push the FIB to the
> DFC and blew up due to low memory.  Our vendor only put a 256MB stick of RAM
> in this card when they usually have 1GB.
>
> Other than that, I haven't had any issues.
>
>
> Jon Wolberg
> Operations Manager
> PowerVPS / Defender Hosting
> Defender Technologies Group, LLC.
>
>
> ----- Original Message -----
> From: "Ben Steele" <illcritikz at gmail.com>
> To: "Geoffrey Pendery" <geoff at pendery.net>
> Cc: cisco-nsp at puck.nether.net
> Sent: Tuesday, March 31, 2009 8:53:14 PM GMT -05:00 US/Canada Eastern
> Subject: Re: [c-nsp] 10GE card for 7609
>
> Yes you can use the WS-670x in the 7600 with an RSP, I have a couple of
> chassis with this at the moment, given they are the 6704(one with DFC)
> 10GE's but I can't see a 6708 not working either...
> 7600#sh mod
> Mod Ports Card Type                              Model              Serial
> No.
> --- ----- -------------------------------------- ------------------
> -----------
>  1    4  CEF720 4 port 10-Gigabit Ethernet      WS-X6704-10GE      SERIAL
>  2    4  CEF720 4 port 10-Gigabit Ethernet      WS-X6704-10GE      SERIAL
>  3   48  CEF720 48 port 10/100/1000mb Ethernet  WS-X6748-GE-TX     SERIAL
>  5    2  Route Switch Processor 720 (Active)    RSP720-3CXL-GE     SERIAL
>
> On Wed, Apr 1, 2009 at 2:54 AM, Geoffrey Pendery <geoff at pendery.net>
> wrote:
>
> > The stuff we've been reading (look at "Supervisor Engines Supported"
> > on the data sheets for "Cisco Catalyst 6500 Series 10 Gigabit Ethernet
> > Interface Modules", or browse the line cards for the 7600, or go into
> > Configurator tool) claims that the RSP 720 won't support the X6704 or
> > X6708 10 Gig "LAN" cards, only the SIP/SPA/ES "WAN" type cards.
> >
> > I don't mean to kick off a big "6500 vs 7600" storm again, but does
> > anyone know if this is incorrect?
> > Can we buy a new 7609-S chassis, put a new RSP 720 in it, put 7600 IOS
> > on that Sup, then plug in a WS-X6708-10G-3C and have it work?
> >
> >
> > -Geoff
> >
> >
> > On Mon, Mar 30, 2009 at 4:41 AM, Mark Tech <techconfig at yahoo.com> wrote:
> > >
> > > Hi
> > > I have a prospect for a 10G upstream customer and Upstream ISP
> > connections. I would need to connect these into our 7609s running RSP
> > 720-3CXL's, at the moment I have found that the WS-X6704-10GE card may be
> > suitable.
> > >
> > > My technical requirements are:
> > > 10Gbps line rate
> > > IPv4
> > > Able to handle full Internet routing table
> > > Potentially IPv6 and MPLS in the future
> > >
> > > With the WS-X6704-10GE, there seems to be several options that are
> > available with it i.e.
> > >
> > > Memory Option:
> > > MEM-XCEF720-256M
> > > Catalyst 6500 256MB DDR, xCEF720 (67xx interface, DFC3A)
> > > MEM-XCEF720-512M
> > > Cat 6500 512MB DDR, xCEF720 (67xx interface, DFC3A/DFC3B)
> > > MEM-XCEF720-1GB
> > > Catalyst 6500 1GB DDR, xCEF720 (67xx interface, DFC3BXL)
> > >
> > > ====================================================
> > > Distributed Forwarding Card Option
> > >
> > > WS-F6700-CFC
> > > Catalyst 6500 Central Fwd Card for WS-X67xx modules
> > > WS-F6700-DFC3B
> > > Catalyst 6500 Dist Fwd Card, 256K Routes for WS-X67xx
> > > WS-F6700-DFC3A
> > > Catalyst 6500 Dist Fwd Card for WS-X67xx modules
> > > WS-F6700-DFC3BXL
> > > Catalyst 6500 Dist Fwd Card- 3BXL, for WS-X67xx
> > > WS-F6700-DFC3C
> > > Catalyst 6500 Dist Fwd Card for WS-X67xx modules
> > > WS-F6700-DFC3CXL
> > > Catalyst 6500 Dist Fwd Card- 3CXL, for WS-X67xx
> > >
> > > I assume that I would need MEM-XCEF720-1GB and WS-F6700-DFC3CXL?
> > >
> > > Regards
> > >
> > > 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/
> >
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>