[c-nsp] cisco-nsp Digest - RSP Problems

Iacono, Diego - (Arg) diego.iacono at telmex.com
Mon Mar 27 13:44:56 EST 2006


Hi everyone,

                   For the last 4 month i have been experiencing RSP constants restart, we changed both RSP, VIP´s, PA, but the problem it persists.

Do you have any idea ??

Mar 24 13:47:25: %RSP-2-QAERROR: write to alternate queue error, write at addr 1B8C (QA)
  log 0A1B8C40, data E4200000 00000000
Mar 24 13:47:26: %RSP-3-RESTART: cbus complex
-Traceback= 4032BDBC 40467F18 40467718 4047263C
Mar 24 13:47:26: %HA-5-MODE: Operating mode is hsa, configured mode is sso.
Mar 24 13:49:05: %CONTROLLER-5-UPDOWN: Controller E1 4/0/0, changed state to up
Mar 24 13:49:05: %CONTROLLER-5-UPDOWN: Controller E1 4/0/0, changed state to up
Mar 24 13:49:05: %CONTROLLER-5-UPDOWN: Controller E1 4/0/1, changed state to up
Mar 24 13:49:05: %CONTROLLER-5-UPDOWN: Controller E1 4/0/1, changed state to up
Mar 24 13:49:05: %RSP-3-RESTART: interface ATM6/1/0, not transmitting
-Traceback= 4032BDBC 40467AD4 40472660
Mar 24 13:49:05.248: Output Stuck on ATM6/1/0
Mar 24 13:49:05.248: MEMD TxAcc counter E8001B8A has value of 0
Mar 24 13:49:05: %RSP-2-QADIAG: QA Diagnostic read error at 0xE8E08000
-Traceback= 4032BCAC 40460F88 404614E4 404677B4 40467B68 40472660
Mar 24 13:49:05: %RSP-2-QADIAG: QA Diagnostic read error at 0xE8E08020
-Traceback= 4032BCAC 40460F88 404614E4 404677B4 40467B68 40472660
Mar 24 13:49:05.260: hwidb->tx_q_ptr is E8001B88

Thanks in advance!




-----Mensaje original-----
De: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] En nombre de cisco-nsp-request at puck.nether.net
Enviado el: Lunes, 27 de Marzo de 2006 12:25
Para: cisco-nsp at puck.nether.net
Asunto: cisco-nsp Digest, Vol 40, Issue 91

Send cisco-nsp mailing list submissions to
	cisco-nsp at puck.nether.net

To subscribe or unsubscribe via the World Wide Web, visit
	https://puck.nether.net/mailman/listinfo/cisco-nsp
or, via email, send a message with subject or body 'help' to
	cisco-nsp-request at puck.nether.net

You can reach the person managing the list at
	cisco-nsp-owner at puck.nether.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of cisco-nsp digest..."


Today's Topics:

   1. Re: Traffic Engineering Internet links automatically
      (Pete Templin)
   2. 6500: egress replication mix and match with non-forwarding
      line cards (christian.macnevin at uk.bnpparibas.com)
   3. Re: Cisco 1801W wireless configuration woes. (Dave Temkin)
   4. Re: High interrupt CPU load on Cat3750, caused by ACL?
      (Tassos Chatzithomaoglou)
   5. 12.2(18)SXF3 vs. 12.1E (John Neiberger)
   6. Re: High interrupt CPU load on Cat3750, caused by ACL?
      (Johannes Resch)
   7. Cisco 2950G Question (Paul Stewart)
   8. Re: High interrupt CPU load on Cat3750, caused by ACL?
      (Clinton Work)


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

Message: 1
Date: Mon, 27 Mar 2006 08:35:47 -0600
From: Pete Templin <petelists at templin.org>
Subject: Re: [c-nsp] Traffic Engineering Internet links automatically
To: Kim Onnel <karim.adel at gmail.com>
Cc: "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>
Message-ID: <4427F843.7010208 at templin.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Kim Onnel wrote:
> This is exactly how we do it, but as you guys pointed, its very boring, 
> and our upstream isnt that cooperative, my best bet would be waiting for 
> a the new OER or increasing bandwidth.
> 
> *note: in third-world countries, engineers times is not more valuable 
> than bandwidth.

OK, I think we're down to the "wah" point.  Dedicate an engineer to the 
task, add more bandwidth, or deal.  I highly doubt you'll find any black 
magic that'll adjust inbound traffic well, today or tomorrow.

pt


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

Message: 2
Date: Mon, 27 Mar 2006 15:43:23 +0100
From: christian.macnevin at uk.bnpparibas.com
Subject: [c-nsp] 6500: egress replication mix and match with
	non-forwarding	line cards
To: cisco-nsp at puck.nether.net
Message-ID:
	<OFF57DC69B.8C43BD07-ON8025713E.004E6FAE-8025713E.0050E048 at bnpparibas.com>
	
Content-Type: text/plain; charset="us-ascii"

Hello,

I'm aware that egress multicast replication only works on the 6500 if all 
cards are capable. But what if one of the
cards isn't capable, but also isn't forwarding multicast? does this step 
around the issue? or do all of my line cards
need to be 67 series, even if they're not intended for multicast?

(I'm guessing yes...)

Cheers
Christian


This message and any attachments (the "message") is 
intended solely for the addressees and is confidential. 
If you receive this message in error, please delete it and
immediately notify the sender. Any use not in accord with
its purpose, any dissemination or disclosure, either whole
or partial, is prohibited except formal approval. The internet
can not guarantee the integrity of this message.
BNP PARIBAS (and its subsidiaries) shall (will) not
therefore be liable for the message if modified. 

**********************************************************************************************

BNP Paribas Private Bank London Branch is authorised
by CECEI & AMF and is regulated by the Financial Services
Authority for the conduct of its investment business in
the United Kingdom.

BNP Paribas Securities Services London Branch is authorised 
by CECEI & AMF and is regulated by the Financial Services 
Authority for the conduct of its investment business in 
the United Kingdom.
  
BNP Paribas Fund Services UK Limited is authorised and 
regulated by the Financial Services Authority



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

Message: 3
Date: Mon, 27 Mar 2006 09:45:30 -0500 (EST)
From: Dave Temkin <dave at ordinaryworld.com>
Subject: Re: [c-nsp] Cisco 1801W wireless configuration woes.
To: Dave Lim <dave.daturax at gmail.com>
Cc: cisco-nsp at puck.nether.net
Message-ID: <Pine.LNX.4.58.0603270944400.5634 at ordinaryworld.com>
Content-Type: TEXT/PLAIN; charset=US-ASCII

Wow...  you should probably change the passwords on that router NOW.

#1 rule of pasting configs onto a mailing list - remove all identifying
information, passwords, and SNMP communities.




-Dave

On Mon, 27 Mar 2006, Dave Lim wrote:

> Hi guys,
>
> I am not really adept at configuring Cisco Wireless. Presently, I have
> a customer who bought a Cisco 1801 to replace their Cisco 877 ADSL
> router. I have no problems configurng their ADSL.
>
> But he had a special request for his wireless. He wants the wireless
> clients connect to the Cisco 1801 wireless, denied LAN access and only
> internet access.
>
> The only thing I can think of, is applying an acl to interface
> Dot11Radio0 denying access to the servers.
>
> Here's my running config
> clock timezone PCTime 8
> !
> !
> ip cef
> no ip dhcp use vrf connected
> ip dhcp excluded-address 10.10.10.1
> ip dhcp excluded-address 192.168.1.201 192.168.1.254
> ip dhcp excluded-address 192.168.1.1 192.168.1.100
> !
> ip dhcp pool JamTech at KA
>    import all
>    network 192.168.1.0 255.255.255.0
>    dns-server 210.193.2.34 210.193.2.36
>    default-router 192.168.1.1
> !
> !
> no ip domain lookup
> ip domain name jamtech.com.sg
> ip name-server 210.193.2.34
> !
> username jamadmin privilege 15 password 7 0521520215494D013954424B
> !
> !
> !
> !
> !
> !
> interface FastEthernet0
>  ip address 10.10.1.1 255.255.255.0
>  duplex auto
>  speed auto
> !
> interface BRI0
>  no ip address
>  encapsulation hdlc
>  shutdown
> !
> interface FastEthernet1
> !
> interface FastEthernet2
> !
> interface FastEthernet3
> !
> interface FastEthernet4
> !
> interface FastEthernet5
> !
> interface FastEthernet6
> !
> interface FastEthernet7
> !
> interface FastEthernet8
> !
> interface Dot11Radio0
>  no ip address
>  shutdown
>  !
>  encryption mode ciphers wep128
>  speed basic-1.0 basic-2.0 basic-5.5 6.0 9.0 basic-11.0 12.0 18.0 24.0
> 36.0 48.0 54.0
>  station-role root
> !
> interface Dot11Radio0.1
>  encapsulation dot1Q 1 native
>  no snmp trap link-status
>  no cdp enable
>  bridge-group 1
>  bridge-group 1 subscriber-loop-control
>  bridge-group 1 spanning-disabled
>  bridge-group 1 block-unknown-source
>  no bridge-group 1 source-learning
>  no bridge-group 1 unicast-flooding
> !
> interface Dot11Radio1
>  no ip address
>  shutdown
>  speed basic-6.0 9.0 basic-12.0 18.0 basic-24.0 36.0 48.0 54.0
>  station-role root
> !
> interface ATM0
>  no ip address
>  no ip redirects
>  no ip unreachables
>  no ip proxy-arp
>  no atm ilmi-keepalive
>  dsl operating-mode auto
> !
> interface ATM0.1 point-to-point
>  description $ES_WAN$$FW_OUTSIDE$
>  no ip redirects
>  no ip unreachables
>  no ip proxy-arp
>  no snmp trap link-status
>  pvc 0/100
>   encapsulation aal5mux ppp dialer
>   dialer pool-member 1
>  !
> !
> interface Vlan1
>  description $ETH-SW-LAUNCH$$INTF-INFO-FE 1$
>  ip address 192.168.1.1 255.255.255.0
>  ip nat inside
>  ip virtual-reassembly
> !
> interface Dialer0
>  description $FW_OUTSIDE$
>  ip address negotiated
>  ip access-group 101 in
>  no ip redirects
>  no ip unreachables
>  no ip proxy-arp
>  ip mtu 1452
>  ip nat outside
>  ip virtual-reassembly
>  encapsulation ppp
>  ip route-cache flow
>  dialer pool 1
>  dialer-group 1
>  no cdp enable
>  ppp authentication pap callin
>  ppp pap sent-username jamtech at qala.com.sg password 7 05280E2B117C19
> !
> ip route 0.0.0.0 0.0.0.0 Dialer0
> ip route 192.168.10.0 255.255.255.0 FastEthernet0
> !
> !
> ip http server
> ip http authentication local
> ip http secure-server
> ip http timeout-policy idle 5 life 86400 requests 10000
> ip nat inside source list 1 interface Dialer0 overload
> !
> access-list 1 remark INSIDE_IF=Vlan1
> access-list 1 remark SDM_ACL Category=2
> access-list 1 permit 192.168.1.0 0.0.0.255
> access-list 1 permit any
> access-list 100 permit ip any any
> access-list 101 permit udp host 210.193.2.36 eq domain any
> access-list 101 permit udp host 210.193.2.34 eq domain any
> access-list 101 deny   ip 192.168.1.0 0.0.0.255 any
> access-list 101 permit icmp any any echo-reply
> access-list 101 permit icmp any any
> access-list 101 permit icmp any any unreachable
> access-list 101 deny   ip 10.0.0.0 0.255.255.255 any
> access-list 101 deny   ip 172.16.0.0 0.15.255.255 any
> access-list 101 deny   ip 192.168.0.0 0.0.255.255 any
> access-list 101 deny   ip 127.0.0.0 0.255.255.255 any
> access-list 101 deny   ip host 255.255.255.255 any
> access-list 101 deny   ip host 0.0.0.0 any
> access-list 101 deny   ip any any
> dialer-list 1 protocol ip permit
> no cdp run
> !
> !
> !
> !
> !
> !
> control-plane
> !
> !
> line con 0
>  login local
> line aux 0
> line vty 0 4
>  privilege level 15
>  login local
>  transport input telnet ssh
> line vty 5 15
>  privilege level 15
>  login local
>  transport input telnet ssh
> !
> !
> webvpn context Default_context
>  ssl authenticate verify all
>  !
>  no inservice
> !
> end
>
> router1#
>
>
> BTW, does anyone know if Cisco 1801w supports WPA2-PSK? I can only see
> WEP from the SDM wizard. Can someone point me to a guide on
> configuring wireless for Cisco 1801w router?
>
> 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/
>


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

Message: 4
Date: Mon, 27 Mar 2006 17:56:08 +0300
From: Tassos Chatzithomaoglou <achatz at forthnet.gr>
Subject: Re: [c-nsp] High interrupt CPU load on Cat3750, caused by
	ACL?
To: Johannes Resch <jr at xor.at>
Cc: cisco-nsp at puck.nether.net
Message-ID: <4427FD08.5080808 at forthnet.gr>
Content-Type: text/plain; charset=us-ascii; format=flowed

I don't know much about the acls, but all these 3750 switches have a limitation 
on the number of routed interfaces; 8 if i'm right.

Also on 3550s you could use the following in order to find out more info about 
the tcam resource usage:

3550#sh tcam ?
   inacl   Show Ingress ACL TCAM
   outacl  Show Egress ACL TCAM
   pbr     Show PBR TCAM
   qos     Show Ingress QoS TCAM

There is something similar on 3750s, "sh platform tcam", but CCO doesn't want to 
give more information about it :(

http://www.cisco.com/en/US/products/hw/switches/ps5023/products_command_reference_chapter09186a00805a743f.html

"You should use this command only when you are working directly with your 
technical support representative while troubleshooting a problem. Do not use 
this command unless your technical support representative asks you to do so."

Tassos

Johannes Resch wrote on 27/3/2006 16:43:

> hi there,
> 
> I've got a stack of 2x C3750G-24T running c3750-ipservicesk9-mz.122-25.SEE
> giving me some trouble.
> 
> the device uses OSPF and BGP (~3k routes total) and has about 35 routed
> SVIs (some of them with rate limiting).
> all routed traffic is below 50 mbit/sec, plus about 70mbit of switched
> traffic, less than 15kpps total. no QoS, PBR, L2-ACLs or other fancy
> features.
> 
> however, "show proc cpu" shows a high level of interrupt CPU load:
> 
> CPU utilization for five seconds: 78%/72%; one minute: 79%; five minutes: 77%
> 
> thinking of possible reasons I first looked into ACLs.
> "sh access-lists hardware counters" shows that the "L3 ACL INPUT
> Statistics" "forwarded to CPU" counter increases about 300-500 packets per
> second. is this already enough to cause 70% interrupt CPU traffic?
> 
> there are 3 ACLs set on SVIs (all set on outgoing traffic).
> as far as I can interprete the output of "sh platform acl label" (see
> below), the ACLs should have been loaded into TCAM - please correct me if
> I'm wrong.
> 
> all 3 ACLs use the "established" keyword for filtering TCP connections,
> could this be the reason?
> 
> also, I'm wondering why "L3 ACL INPUT statistics" shows cpu forwarded
> packets, while the ACLs are only set for outgoing traffic..
> 
> 
> IPv4/MAC ACL label
> ------------------
> 
> Input Op Select Index 255:
> Output Op Select Index 0:
> Input Features:
>   Interfaces or VLANs:
>   Priority: low
>   Vlan Map: (none), 0 VMRs.
>   Access Group: (none), 0 VMRs.
>   Multicast Boundary: (none), 0 VMRs.
> Output Features:
>   Interfaces or VLANs:  Vl701
>   Priority: normal
>   Bridge Group Member: no
>   Vlan Map: (none), 0 VMRs.
>   Access Group: 114, 116 VMRs
> 
> IPv4/MAC ACL label
> ------------------
> 
> Input Op Select Index 255:
> Output Op Select Index 0:
> Input Features:
>   Interfaces or VLANs:
>   Priority: low
>   Vlan Map: (none), 0 VMRs.
>   Access Group: (none), 0 VMRs.
>   Multicast Boundary: (none), 0 VMRs.
> Output Features:
>   Interfaces or VLANs:  Vl703
>   Priority: normal
>   Bridge Group Member: no
>   Vlan Map: (none), 0 VMRs.
>   Access Group: 115, 26 VMRs.
> 
> 
> 
> IPv4/MAC ACL label
> ------------------
> 
> Input Op Select Index 255:
> Output Op Select Index 0:
> Input Features:
>   Interfaces or VLANs:
>   Priority: low
>   Vlan Map: (none), 0 VMRs.
>   Access Group: (none), 0 VMRs.
>   Multicast Boundary: (none), 0 VMRs.
> Output Features:
>   Interfaces or VLANs:  Vl704
>   Priority: normal
>   Bridge Group Member: no
>   Vlan Map: (none), 0 VMRs.
>   Access Group: 113, 39 VMRs.
> 
> 
> any feedback is appreciated,
> 
> best regards,
> -jr
> 
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 


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

Message: 5
Date: Mon, 27 Mar 2006 07:54:58 -0700
From: "John Neiberger" <John.Neiberger at efirstbank.com>
Subject: [c-nsp] 12.2(18)SXF3 vs. 12.1E
To: <cisco-nsp at puck.nether.net>
Message-ID: <s4279a2e.052 at efirstbank.com>
Content-Type: text/plain; charset=US-ASCII

We have a 6513 with SUP2/MSFC2 running a later version of 12.1E. Our
security admin wants to upgrade an FWSM module to the latest code but
that requires an upgrade of the 6513 code to 12.2(18)SXF3. That code has
*way* more features than we need but it is a required release to support
the new FWSM code.

My big worry is stability. Do any of you have any comments about its
stability, especially in relation to 12.1E? Maybe it's just me but I get
a little freaked out running code with multiple initials at the end.

Any thoughts?

John
--


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

Message: 6
Date: Mon, 27 Mar 2006 17:12:36 +0200 (CEST)
From: "Johannes Resch" <jr at xor.at>
Subject: Re: [c-nsp] High interrupt CPU load on Cat3750, caused by
	ACL?
To: "Tassos Chatzithomaoglou" <achatz at forthnet.gr>
Cc: cisco-nsp at puck.nether.net
Message-ID: <62767.193.72.75.33.1143472356.squirrel at and.xor.at>
Content-Type: text/plain;charset=iso-8859-1

Hi Tassos,

On Mon, March 27, 2006 16:56, Tassos Chatzithomaoglou said:
> I don't know much about the acls, but all these 3750 switches have a
> limitation
> on the number of routed interfaces; 8 if i'm right.

yep, thats what cisco says in their specs. however, I've seen 3750-stacks
with more than 30 SVIs working without issues, at much higher traffic
loads with interrupt CPU load of 10%.


> Also on 3550s you could use the following in order to find out more info
> about
> the tcam resource usage:
>
> 3550#sh tcam ?
>    inacl   Show Ingress ACL TCAM
>    outacl  Show Egress ACL TCAM
>    pbr     Show PBR TCAM
>    qos     Show Ingress QoS TCAM
>
> There is something similar on 3750s, "sh platform tcam", but CCO doesn't
> want to
> give more information about it :(

I think on 3750 it is this:

hostname#sh platform tcam utilization

CAM Utilization for ASIC# 0                      Max            Used
                                             Masks/Values    Masks/values

 Unicast mac addresses:                        784/6272         46/305
 IPv4 IGMP groups + multicast routes:          144/1152          6/26
 IPv4 unicast directly-connected routes:       784/6272         46/305
 IPv4 unicast indirectly-connected routes:     272/2176        264/2072
 IPv4 policy based routing aces:                 0/0             0/0
 IPv4 qos aces:                                512/512           6/6
 IPv4 security aces:                          1024/1024        119/119

Note: Allocation of TCAM entries per feature uses
a complex algorithm. The above information is meant
to provide an abstract view of the current TCAM utilization


hostname#sh platform tcam usage

=============================================================================
                                  TCAM Table
 TCAM / SSRAM Table            TCAM            SSRAM
                                Start   Size X    Start   Size Y
=============================================================================
 Local Forwarding Table:            0   1D00 1        0   1D00   4
 Local Learning Table:              0   1D00 1     7400   1D00   2
 Secondary Forwarding Table:     1880    D00 1     AE00    D00   8
 QoS Table:                      2580   1000 1    11600   1000   4
 ACL Table:                      3580   2000 1    15600   2000   4
 IPV6 Secondary Forwarding Tabl  7E40     C0 2    1D600     60   8
 IPV6 Classification Table:      7F00     80 2    1D900     40   4
 IPV6 ACL Table:                 7F80     70 2    1DA00     38   4
 Station Table:                     0      0 0    1DB00   1D00   4
 MAC Address Table:                 0      0 0    24F00   1800   8
 Multicast Expansion Table:         0      0 0    30F00    420   8
 VLAN List Table:                   0      0 0    34000    400  10
 Equal Cost Route Table:            0      0 0    33000     80  20

 X - Number of 144-bit TCAM entries per descriptor
 Y - Number of bytes per descriptor
=============================================================================

given this output, to me it seems the device has not yet reached its
TCAM-limits (the number of "IPv4 unicast indirectly-connected routes"
seems to be a bit tight, though).

regards,
-jr




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

Message: 7
Date: Mon, 27 Mar 2006 10:25:14 -0500
From: "Paul Stewart" <pstewart at nexicomgroup.net>
Subject: [c-nsp] Cisco 2950G Question
To: <cisco-nsp at puck.nether.net>
Message-ID:
	<89D27DE3375BB6428DDCC2927489826A1E47D2 at nexus.nexicomgroup.net>
Content-Type: text/plain;	charset="us-ascii"

We are looking at putting a Cisco WS-C2950G-24-EI into a remote
location.  Our goal is to trunk VLAN's from one GigE port to another
GigE port.  This may be a silly question but will that work on this
particular switch?  I know that if we trunk in VLAN's from the Copper
100 meg ports and "uplink" them to the GigE it works just fine....

Thanks,

Paul Stewart
IP Routing/Switching
Nexicom Inc.
http://www.nexicom.net/ 



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

Message: 8
Date: Mon, 27 Mar 2006 08:25:10 -0700
From: Clinton Work <clinton at scripty.com>
Subject: Re: [c-nsp] High interrupt CPU load on Cat3750, caused by
	ACL?
To: Johannes Resch <jr at xor.at>
Cc: cisco-nsp at puck.nether.net
Message-ID: <442803D6.8040105 at scripty.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed


Neither the 3550 or 3750 can support ACLs with a lot of L4 operations (TCP / 
UDP ports or flags). I would try removing and reapplying the ACLs to see if 
you get an error message in the log.

Also check that your not exceeding the unicast route limits for your current 
SDM template. Both the number of unicast routes and ARP entries
are important. On the 3550 at least, each ARP entry uses one
unicast CEF entry (unicast route).
http://www.cisco.com/en/US/products/hw/switches/ps5023/products_tech_note09186a00801e7bb9.shtml#topic4

I would also check the "show controllers cpu-interface" for a lot of
sw forwarding frames. I have seen both complicated ACLs and too many unicast
routes force all IP packets to be routed by the CPU.



Johannes Resch wrote:
> hi there,
> 
> I've got a stack of 2x C3750G-24T running c3750-ipservicesk9-mz.122-25.SEE
> giving me some trouble.
> 
> the device uses OSPF and BGP (~3k routes total) and has about 35 routed
> SVIs (some of them with rate limiting).
> all routed traffic is below 50 mbit/sec, plus about 70mbit of switched
> traffic, less than 15kpps total. no QoS, PBR, L2-ACLs or other fancy
> features.
> 
> however, "show proc cpu" shows a high level of interrupt CPU load:
> 
> CPU utilization for five seconds: 78%/72%; one minute: 79%; five minutes: 77%
> 



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

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


End of cisco-nsp Digest, Vol 40, Issue 91
*****************************************



More information about the cisco-nsp mailing list