From quinn at activehost.com  Wed Jul  1 00:02:10 2009
From: quinn at activehost.com (Quinn Mahoney)
Date: Wed, 1 Jul 2009 00:02:10 -0400
Subject: [c-nsp] DNS rewrite & global capabilities
In-Reply-To: <44385206-0907-4D3D-87A2-0073FCF2D1AA@arbor.net>
References: <725755F5E728EE4086DAAF1A54DACF4F150AD905@sea5exbe1.speakeasy.hq>
	<44385206-0907-4D3D-87A2-0073FCF2D1AA@arbor.net>
Message-ID: <8685783A8C22C640AD1361E78659B7D7697713@ahex02.activehost.local>

These claims depend on the level of attack.  Firewalls do have features,
for instance, they can proxy a tcp-syn connection and not send it to the
server if it doesn't get an ack.  If the firewall can sustain the
attack, and the server doesn't have syn-cookies, this would be a
mitigation of a ddos by the firewall.  Also they obviously block
traffic, which is a security benefit.

Also, what if the attack has spoofed source addresses, and is evasive of
profiling.  In other words, what are you going to null route. The
ingress path of the attack packets would have to be traced and cut off
at the border of upstream providers, killing legit traffic as well.
While the real sources are hunted down, this would be the effort to
mitigate the attack.  An advanced firewall or load balancer (that
multiplex's the connections) would be able to mitigate this attack.

So to me, it doesn't look like a one thing fits solution.



-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Roland Dobbins
Sent: Monday, June 29, 2009 10:17 AM
To: Cisco-nsp
Subject: Re: [c-nsp] DNS rewrite & global capabilities


On Jun 29, 2009, at 8:33 PM, Jonathan Brashear wrote:

> t seems like the ability to rewrite DNS against certain DDoS attacks

Marketing claims aside, firewalls have no utility whatsoever in terms  
of defending against DDoS attacks, and actually tend to make the  
situation worse and the server behind them *more* vulnerable to DDoS,  
and not less, due to the limitations of the stateful capacity they  
embody.

You'd be far better off using S/RTBH as a reaction tool, and depending  
upon your application and its importance/scale, may wish to  
investigate other tools intended to protect firewalls and the things  
behind them from DDoS (full disclosure; I work for a company which  
makes such tools).

But even more than that, putting your public-facing DNS (or any other  
kind of server) behind a firewall is a very serious architectural  
mistake; firewalls in front of public-facing servers provide no  
security value whatsoever, and degrade the overall security posture  
due to the issues denoted above.  Far, far better to bring your public- 
facing DNS servers out from behind the firewall, employ all the  
various host- and application-/service-specific BCPs, ensure your DNS  
architecture is properly designed and scaled, and make use of S/RTBH,  
et. al. to deal with DDoS.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

         Unfortunately, inefficiency scales really well.

		   -- Kevin Lawton

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



From rdobbins at arbor.net  Wed Jul  1 00:09:42 2009
From: rdobbins at arbor.net (Roland Dobbins)
Date: Wed, 1 Jul 2009 11:09:42 +0700
Subject: [c-nsp] DNS rewrite & global capabilities
In-Reply-To: <8685783A8C22C640AD1361E78659B7D7697713@ahex02.activehost.local>
References: <725755F5E728EE4086DAAF1A54DACF4F150AD905@sea5exbe1.speakeasy.hq>
	<44385206-0907-4D3D-87A2-0073FCF2D1AA@arbor.net>
	<8685783A8C22C640AD1361E78659B7D7697713@ahex02.activehost.local>
Message-ID: <DBCE07D4-D084-4DDE-8CCD-276F4E6F56F4@arbor.net>


On Jul 1, 2009, at 11:02 AM, Quinn Mahoney wrote:

> irewalls do have features,
> for instance, they can proxy a tcp-syn connection and not send it to  
> the
> server if it doesn't get an ack.

Doesn't scale.  Server alone handle this much better, even without syn- 
cookies.

> Also they obviously block traffic, which is a security benefit.

So do stateless ACLs in hardware - much more efficiently.

> Also, what if the attack has spoofed source addresses, and is  
> evasive of
> profiling.  In other words, what are you going to null route. The
> ingress path of the attack packets would have to be traced and cut off
> at the border of upstream providers, killing legit traffic as well.

Appropriate detection/classification/traceback tools and S/RTBH handle  
most of this; the rest is where intelligent DDoS mitigation  
capabilities come into play.  Stateful firewalls don't do this, and  
the stateful part is what makes them fall down.

> An advanced firewall or load balancer (that multiplex's the  
> connections) would be able to mitigate this attack.


Again, they a) don't do what you're asserting they do and b) don't  
scale.

This isn't a matter of opinion, it's a matter of operational  
experience and fact.  Putting stateful firewalls in front of servers  
is both unnecessary and counterproductive.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

         Unfortunately, inefficiency scales really well.

		   -- Kevin Lawton


From quinn at activehost.com  Wed Jul  1 01:09:45 2009
From: quinn at activehost.com (Quinn Mahoney)
Date: Wed, 1 Jul 2009 01:09:45 -0400
Subject: [c-nsp] DNS rewrite & global capabilities
In-Reply-To: <DBCE07D4-D084-4DDE-8CCD-276F4E6F56F4@arbor.net>
References: <725755F5E728EE4086DAAF1A54DACF4F150AD905@sea5exbe1.speakeasy.hq><44385206-0907-4D3D-87A2-0073FCF2D1AA@arbor.net><8685783A8C22C640AD1361E78659B7D7697713@ahex02.activehost.local>
	<DBCE07D4-D084-4DDE-8CCD-276F4E6F56F4@arbor.net>
Message-ID: <8685783A8C22C640AD1361E78659B7D7697714@ahex02.activehost.local>

The server alone handles a syn attack much better, Without a firewall
proxying the tcp connection?  That would depend on how many servers
there are and what the firewalls can handle.  The server never gets
traffic from the spoofed addresses with the firewall, or from a
load-balancer that multiplex's the tcp connections.

> Also they obviously block traffic, which is a security benefit.

"So do stateless ACLs in hardware - much more efficiently."

I wouldn't say much more efficiently, since more advanced load balancers
and firewalls route via asic's and fpga's.

> Also, what if the attack has spoofed source addresses, and is  
> evasive of
> profiling.  In other words, what are you going to null route. The
> ingress path of the attack packets would have to be traced and cut off
> at the border of upstream providers, killing legit traffic as well.

"
Appropriate detection/classification/traceback tools and S/RTBH handle  
most of this; the rest is where intelligent DDoS mitigation  
capabilities come into play.  Stateful firewalls don't do this, and  
the stateful part is what makes them fall down.
"

If the packet is the same as a normal request but a spoofed address,
you're going to have some trouble even with automated systems looking
for no syn/ack, and then hunting the source down and automatically
blocking the true sources at the ingress of the upstreams.  That's even
if such an effective system actually existed. While the load-balancer or
advanced firewall never sent the connection to the server, and the
device is designed to be able to handle allocating memory for bogus
connections.


"
Again, they a) don't do what you're asserting they do and b) don't  
scale.

This isn't a matter of opinion, it's a matter of operational  
experience and fact.  Putting stateful firewalls in front of servers  
is both unnecessary and counterproductive.
"

Microsoft.com runs without a stateful firewall.  However that wasn't my
argument.  My argument was the claims you made depend on the level and
type of attack, and that the arbor networks system is not effective in
all situations.  Hence the one size fits all solution is not adequate in
all situations, and the solution is not always effective.  Anyways I
have always been impressed with their products.





-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Roland Dobbins
Sent: Wednesday, July 01, 2009 12:10 AM
To: Cisco-nsp
Subject: Re: [c-nsp] DNS rewrite & global capabilities


On Jul 1, 2009, at 11:02 AM, Quinn Mahoney wrote:

> irewalls do have features,
> for instance, they can proxy a tcp-syn connection and not send it to  
> the
> server if it doesn't get an ack.

Doesn't scale.  Server alone handle this much better, even without syn- 
cookies.

> Also they obviously block traffic, which is a security benefit.

So do stateless ACLs in hardware - much more efficiently.

> Also, what if the attack has spoofed source addresses, and is  
> evasive of
> profiling.  In other words, what are you going to null route. The
> ingress path of the attack packets would have to be traced and cut off
> at the border of upstream providers, killing legit traffic as well.

Appropriate detection/classification/traceback tools and S/RTBH handle  
most of this; the rest is where intelligent DDoS mitigation  
capabilities come into play.  Stateful firewalls don't do this, and  
the stateful part is what makes them fall down.

> An advanced firewall or load balancer (that multiplex's the  
> connections) would be able to mitigate this attack.


Again, they a) don't do what you're asserting they do and b) don't  
scale.

This isn't a matter of opinion, it's a matter of operational  
experience and fact.  Putting stateful firewalls in front of servers  
is both unnecessary and counterproductive.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

         Unfortunately, inefficiency scales really well.

		   -- Kevin Lawton

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



From rdobbins at arbor.net  Wed Jul  1 01:24:27 2009
From: rdobbins at arbor.net (Roland Dobbins)
Date: Wed, 1 Jul 2009 12:24:27 +0700
Subject: [c-nsp] DNS rewrite & global capabilities
In-Reply-To: <8685783A8C22C640AD1361E78659B7D7697714@ahex02.activehost.local>
References: <725755F5E728EE4086DAAF1A54DACF4F150AD905@sea5exbe1.speakeasy.hq><44385206-0907-4D3D-87A2-0073FCF2D1AA@arbor.net><8685783A8C22C640AD1361E78659B7D7697713@ahex02.activehost.local>
	<DBCE07D4-D084-4DDE-8CCD-276F4E6F56F4@arbor.net>
	<8685783A8C22C640AD1361E78659B7D7697714@ahex02.activehost.local>
Message-ID: <8891CCEF-1BE2-40F1-BCB4-58B29D967DE0@arbor.net>


On Jul 1, 2009, at 12:09 PM, Quinn Mahoney wrote:

> Without a firewall proxying the tcp connection?  That would depend  
> on how many servers
> there are and what the firewalls can handle.  The server never gets
> traffic from the spoofed addresses with the firewall, or from a
> load-balancer that multiplex's the tcp connections.

There isn't a firewall made which has the capacity to handle this more  
efficiently than a well-configured server or server farm.

> I wouldn't say much more efficiently, since more advanced load  
> balancers
> and firewalls route via asic's and fpga's.

I certainly would, and do; they none of them run into the mpps, as  
routers can and do.

> If the packet is the same as a normal request but a spoofed address,
> you're going to have some trouble even with automated systems looking
> for no syn/ack, and then hunting the source down and automatically
> blocking the true sources at the ingress of the upstreams.

Not with appropriate detection/classification/traceback tools.  This  
isn't new technology.

And blocking at the edges isn't generally accomplished automatically,  
but manually, upon demand.  Intelligent DDoS mitigation devices can  
and do black automatically.

>  That's even if such an effective system actually existed.

They do, see above.

> While the load-balancer or advanced firewall never sent the  
> connection to the server, and the
> device is designed to be able to handle allocating memory for bogus
> connections.

They never send the legitimate traffic, either, being overwhelmed by  
the DDoS.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

         Unfortunately, inefficiency scales really well.

		   -- Kevin Lawton


From ip at ioshints.info  Wed Jul  1 01:35:51 2009
From: ip at ioshints.info (Ivan Pepelnjak)
Date: Wed, 1 Jul 2009 07:35:51 +0200
Subject: [c-nsp] MPLS/BGP - want to add backup IPSEC VPN
In-Reply-To: <1246398642.6267.85.camel@localhost.localdomain>
References: <4A4A636E.4090301@chrisserafin.com>
	<1246398642.6267.85.camel@localhost.localdomain>
Message-ID: <003a01c9fa0d$cca739c0$0a00000a@nil.si>

If you're the customer (having only CE routers), this is a classic
primary/backup problem, only this time using BGP as the core routing
protocol. 

If you're the provider (using MPLS between your BGP routers to offer
whatever services), you can run MPLS over GRE over IPSec on the backup link
(just watch for MTU issues). We built a pretty large network using it and
after the initial kinks it works perfectly.

Ivan
 
http://www.ioshints.info/about
http://blog.ioshints.info/

> -----Original Message-----
> From: Peter Rathlev [mailto:peter at rathlev.dk] 
> Sent: Tuesday, June 30, 2009 11:51 PM
> To: ChrisSerafin
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] MPLS/BGP - want to add backup IPSEC VPN
> 
> On Tue, 2009-06-30 at 14:11 -0500, ChrisSerafin wrote:
> > I have a few MPLS routers running BGP as the routing protocol.
> > 
> > I added a public IP'ed interface on a free ports on the 
> same router, 
> > and I'm able to get to it and use it for Internet bound 
> traffic if I 
> > wish. I would like to configure an IPSEC VPN to provide 
> backup if the 
> > MPLS provider fails. I'm having a hard time with Cisco TAC on this, 
> > mainly them getting back to me.
> > 
> > dumb'ed down diagram is at: http://chrisserafin.com/design.jpg
> > 
> > I just want a basic split tunnel VPN in the event the 
> primary MPLS/BGP 
> > link goes down. I'm assuming let BGP take care of the MPLS side and 
> > add static routes with a very high weight for the VPN failover?
> 
> And the VPN-link needs to carry MPLS traffic too? MPLSoGRE 
> could be an option, but support is very limited AFAIK.
> 
> Otherwise some extra equipment doing L2TPv3 might work. 
> Performance limitations might very well rule this out.
> 
> If MPLS isn't needed a simple GRE tunnel would of course do. 
> You could even create a new tunnel per VRF if you need 
> reachability in several of these. It scales bad concerning 
> administration though.
> 
> 
> Regards,
> Peter
> 
> 
> 
> 


From dirk.kurfuerst at isarnet.de  Wed Jul  1 01:50:16 2009
From: dirk.kurfuerst at isarnet.de (Dirk Kurfuerst)
Date: Wed, 01 Jul 2009 07:50:16 +0200
Subject: [c-nsp] Non export of netflow  of dscp bits from PCF3A
In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9D122127DF0@PUR-EXCH07.ox.com>
References: <F3318834F1F89D46857972DD4B411D7011C3D3A4@EXCHANGE.thenap.com>	<Pine.LNX.4.61.0906301535510.6312@soloth.lewis.org>
	<483E6B0272B0284BA86D7596C40D29F9D122127DF0@PUR-EXCH07.ox.com>
Message-ID: <4A4AF918.3080504@isarnet.de>

Works like designed. The PFC3A doesn't export QoS informations. This has
been one major reason to go for the B version for us some times ago at
Qimonda. (rem: QoS-netflow-collecting seems a L2-netflow-feature; this
is supported in the B versions only)


Matthew Huff schrieb:
> We use Fluke's Netflow Tracker for netflow analysis. I've run into a weird one though. Our netflow export from our distribution switches which are running 12.2(33)SXI1 does not seem to export the dscp bits, but our core switches running 12.2(33)SXI1 as well, do export the dscp bits. The difference is the distribution switch is a PFC3A where the core switches are PFC3Bs. Anyone seen this issue before? I've verified that the netflow configurations are identical, and that the packets do have the attributes set as they pass throught he distribution.
>
>
>
> ----
> 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
>
>
>   

-- 
--------------------------------------------
 Dirk Kurfuerst

 Tel. +49 811 99829 130
 Fax: +49 89 97007 200
 GSM: +49 178 7072043
 e-mail: dirk.kurfuerst at isarnet.de
 http://www.isarnet.de
 http://www.isarflow.de
--------------------------------------------
 IsarNet AG
 Terminalstrasse Mitte 18
 85356 Muenchen
 Sitz der Gesellschaft: Oberding
 Handelsregister Muenchen, HRB 127295
 USt.-ID Nr. DE203054669
 Vorstand: 
 Andreas Perthel, Harald Weikert
 Vorsitzender des Aufsichtsrates: 
 Andreas Gallenmueller
-------------------------------------------- 


From arla at rn.dk  Wed Jul  1 02:08:21 2009
From: arla at rn.dk (Arne Larsen / Region Nordjylland)
Date: Wed, 1 Jul 2009 08:08:21 +0200
Subject: [c-nsp] tacacs+ an nexus 5010
In-Reply-To: <59083.1246397647@lavin-llc.com>
References: <59083.1246397647@lavin-llc.com>
Message-ID: <8D68760F464FFD40A01BF2FB374E4A2801CC19061CB8@SRVEXC02.aas.its.nja.dk>

No, it should be right. My problem is that if I do a tcpdump on the tacacs+ server I dont see anything from the nexus.
It's like it doesn't leave the box at all.

/Arne

-----Oprindelig meddelelse-----
Fra: chris at lavin-llc.com [mailto:chris at lavin-llc.com]
Sendt: 30. juni 2009 23:34
Til: cisco-nsp at puck.nether.net; Arne Larsen / Region Nordjylland
Emne: Re: [c-nsp] tacacs+ an nexus 5010

On Tue Jun 30 13:47 , Arne Larsen / Region Nordjylland  sent:

>Hi all.
>
>Can someone help me out here.
>I'm having trouble getting tacacs+ to work an a nexus 5010.
>When ever I'm trying to access the nexus the debug prints.:  Skipping
>DEAD TACACS+ server 10.0.100.233 I can ping and telnet to the tac-server from the nexus. Am I missiing somthing in my config ??
>
>my conf.
>
>vrf context management
>  ip name-server 10.2.4.63 10.2.4.64 10.2.4.65 ip host aasnxu1
>10.2.8.14 ip host helios 10.0.100.233 tacacs-server key 7 "xxxxxxxxx"
>tacacs-server host 10.0.100.233
>aaa group server tacacs+ REG_TAC
>    server 10.0.100.233
>    deadtime 5
>    use-vrf management
>aaa authentication login default group REG_TAC aaa authentication login
>error-enable tacacs-server directed-request vrf context management
>  ip route 0.0.0.0/0 10.2.8.1
>
>
>
>aasnxu1# sh tacacs-server
>Global TACACS+ shared secret:********
>timeout value:5
>deadtime value:0
>total number of servers:1
>
>following TACACS+ servers are configured:
>        10.0.100.233:
>                available on port:49
>
>following TACACS+ server groups are configured:
>        group REG_TAC:
>                server 10.0.100.233 on port 49
>                deadtime is 5
>                vrf is management
>

Is there a chance you have a mismatch TACACS key?

-chris


From quinn at activehost.com  Wed Jul  1 03:05:24 2009
From: quinn at activehost.com (Quinn Mahoney)
Date: Wed, 1 Jul 2009 03:05:24 -0400
Subject: [c-nsp] DNS rewrite & global capabilities
In-Reply-To: <F308716D736FE64E9082DB665757E91B036714E6@ahex02.activehost.local>
References: <725755F5E728EE4086DAAF1A54DACF4F150AD905@sea5exbe1.speakeasy.hq><44385206-0907-4D3D-87A2-0073FCF2D1AA@arbor.net><8685783A8C22C640AD1361E78659B7D7697713@ahex02.activehost.local><DBCE07D4-D084-4DDE-8CCD-276F4E6F56F4@arbor.net><8685783A8C22C640AD1361E78659B7D7697714@ahex02.activehost.local>
	<8891CCEF-1BE2-40F1-BCB4-58B29D967DE0@arbor.net>
	<F308716D736FE64E9082DB665757E91B036714E6@ahex02.activehost.local>
Message-ID: <8685783A8C22C640AD1361E78659B7D7697716@ahex02.activehost.local>


> Without a firewall proxying the tcp connection?  That would depend  
> on how many servers
> there are and what the firewalls can handle.  The server never gets
> traffic from the spoofed addresses with the firewall, or from a
> load-balancer that multiplex's the tcp connections.
"
There isn't a firewall made which has the capacity to handle this more  
efficiently than a well-configured server or server farm.
"

That's not saying a whole lot.  You could always get more bandwidth and
more servers.  That doesn't mean it's not helpful to have a specialized
device multiplexing the connections to the servers, and doing more
sophisticated analysis of the packets before sending them to the server.


> I wouldn't say much more efficiently, since more advanced load  
> balancers
> and firewalls route via asic's and fpga's.
"
I certainly would, and do; they none of them run into the mpps, as  
routers can and do.
"
You are claiming that certain firewalls/load-balancers can't firewall
and inspect packets at millions of packets per second.  This claim is
inconsistent with current data.

> If the packet is the same as a normal request but a spoofed address,
> you're going to have some trouble even with automated systems looking
> for no syn/ack, and then hunting the source down and automatically
> blocking the true sources at the ingress of the upstreams.
"
Not with appropriate detection/classification/traceback tools.  This  
isn't new technology.

And blocking at the edges isn't generally accomplished automatically,  
but manually, upon demand.  Intelligent DDoS mitigation devices can  
and do black automatically.
"
These packets are the same as legit packets, I do not believe a fully
effective automated system exists.  


> While the load-balancer or advanced firewall never sent the  
> connection to the server, and the
> device is designed to be able to handle allocating memory for bogus
> connections.
"
They never send the legitimate traffic, either, being overwhelmed by  
the DDoS.
"
Not really saying a whole lot again. My argument was not that the
products you refer to aren't a part of an effective security solution.



-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Roland Dobbins
Sent: Wednesday, July 01, 2009 1:24 AM
To: Cisco-nsp
Subject: Re: [c-nsp] DNS rewrite & global capabilities


On Jul 1, 2009, at 12:09 PM, Quinn Mahoney wrote:

> Without a firewall proxying the tcp connection?  That would depend  
> on how many servers
> there are and what the firewalls can handle.  The server never gets
> traffic from the spoofed addresses with the firewall, or from a
> load-balancer that multiplex's the tcp connections.

There isn't a firewall made which has the capacity to handle this more  
efficiently than a well-configured server or server farm.

> I wouldn't say much more efficiently, since more advanced load  
> balancers
> and firewalls route via asic's and fpga's.

I certainly would, and do; they none of them run into the mpps, as  
routers can and do.

> If the packet is the same as a normal request but a spoofed address,
> you're going to have some trouble even with automated systems looking
> for no syn/ack, and then hunting the source down and automatically
> blocking the true sources at the ingress of the upstreams.

Not with appropriate detection/classification/traceback tools.  This  
isn't new technology.

And blocking at the edges isn't generally accomplished automatically,  
but manually, upon demand.  Intelligent DDoS mitigation devices can  
and do black automatically.

>  That's even if such an effective system actually existed.

They do, see above.

> While the load-balancer or advanced firewall never sent the  
> connection to the server, and the
> device is designed to be able to handle allocating memory for bogus
> connections.

They never send the legitimate traffic, either, being overwhelmed by  
the DDoS.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

         Unfortunately, inefficiency scales really well.

		   -- Kevin Lawton

_______________________________________________
cisco-nsp mailing list  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  Wed Jul  1 04:01:50 2009
From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk)
Date: Wed, 1 Jul 2009 09:01:50 +0100
Subject: [c-nsp] tacacs+ an nexus 5010
In-Reply-To: <8D68760F464FFD40A01BF2FB374E4A2801CC19061CB8@SRVEXC02.aas.its.nja.dk>
References: <59083.1246397647@lavin-llc.com>
	<8D68760F464FFD40A01BF2FB374E4A2801CC19061CB8@SRVEXC02.aas.its.nja.dk>
Message-ID: <20090701080150.GE32316@lboro.ac.uk>

Hi,
> No, it should be right. My problem is that if I do a tcpdump on the tacacs+ server I dont see anything from the nexus.
> It's like it doesn't leave the box at all.

or is blocked elsewhere - check the network that the TACACS+
traffic is being sent on and check ACLs etc that might be in the way
on the way to the server. check firewall on server to ensure
such traffic is allowed.  ping and telnet are okay but they
wont test the actual method used.


alan

From tom at netspot.com.au  Wed Jul  1 04:09:12 2009
From: tom at netspot.com.au (Tom Lanyon)
Date: Wed, 1 Jul 2009 17:39:12 +0930
Subject: [c-nsp] tacacs+ an nexus 5010
In-Reply-To: <20090701080150.GE32316@lboro.ac.uk>
References: <59083.1246397647@lavin-llc.com>
	<8D68760F464FFD40A01BF2FB374E4A2801CC19061CB8@SRVEXC02.aas.its.nja.dk>
	<20090701080150.GE32316@lboro.ac.uk>
Message-ID: <1E2E1EC2-04AA-4F50-BC52-16424E5E184D@netspot.com.au>

>> No, it should be right. My problem is that if I do a tcpdump on the  
>> tacacs+ server I dont see anything from the nexus.
>> It's like it doesn't leave the box at all.
>
> or is blocked elsewhere - check the network that the TACACS+
> traffic is being sent on and check ACLs etc that might be in the way
> on the way to the server. check firewall on server to ensure
> such traffic is allowed.  ping and telnet are okay but they
> wont test the actual method used.


... and are you using the correct 'ip tacacs source-interface' to  
source the traffic?

From ltd at cisco.com  Wed Jul  1 04:23:12 2009
From: ltd at cisco.com (Lincoln Dale)
Date: Wed, 01 Jul 2009 18:23:12 +1000
Subject: [c-nsp] tacacs+ an nexus 5010
In-Reply-To: <8D68760F464FFD40A01BF2FB374E4A2801CC19061CB8@SRVEXC02.aas.its.nja.dk>
References: <59083.1246397647@lavin-llc.com>
	<8D68760F464FFD40A01BF2FB374E4A2801CC19061CB8@SRVEXC02.aas.its.nja.dk>
Message-ID: <4A4B1CF0.2010708@cisco.com>

Cisco Nexus platforms make a distinction between out-of-band management 
access (mgmt0 interface) and inband management access.  the former is in 
a 'management' VRF while the latter is in the 'default' VRF.
make sure you've configured TACACS+ to match the appropriate VRF.


cheers,

lincoln.

 

Arne Larsen / Region Nordjylland wrote:
> No, it should be right. My problem is that if I do a tcpdump on the tacacs+ server I dont see anything from the nexus.
> It's like it doesn't leave the box at all.
>
> /Arne
>
> -----Oprindelig meddelelse-----
> Fra: chris at lavin-llc.com [mailto:chris at lavin-llc.com]
> Sendt: 30. juni 2009 23:34
> Til: cisco-nsp at puck.nether.net; Arne Larsen / Region Nordjylland
> Emne: Re: [c-nsp] tacacs+ an nexus 5010
>
> On Tue Jun 30 13:47 , Arne Larsen / Region Nordjylland  sent:
>
>   
>> Hi all.
>>
>> Can someone help me out here.
>> I'm having trouble getting tacacs+ to work an a nexus 5010.
>> When ever I'm trying to access the nexus the debug prints.:  Skipping
>> DEAD TACACS+ server 10.0.100.233 I can ping and telnet to the tac-server from the nexus. Am I missiing somthing in my config ??
>>
>> my conf.
>>
>> vrf context management
>>  ip name-server 10.2.4.63 10.2.4.64 10.2.4.65 ip host aasnxu1
>> 10.2.8.14 ip host helios 10.0.100.233 tacacs-server key 7 "xxxxxxxxx"
>> tacacs-server host 10.0.100.233
>> aaa group server tacacs+ REG_TAC
>>    server 10.0.100.233
>>    deadtime 5
>>    use-vrf management
>> aaa authentication login default group REG_TAC aaa authentication login
>> error-enable tacacs-server directed-request vrf context management
>>  ip route 0.0.0.0/0 10.2.8.1
>>
>>
>>
>> aasnxu1# sh tacacs-server
>> Global TACACS+ shared secret:********
>> timeout value:5
>> deadtime value:0
>> total number of servers:1
>>
>> following TACACS+ servers are configured:
>>        10.0.100.233:
>>                available on port:49
>>
>> following TACACS+ server groups are configured:
>>        group REG_TAC:
>>                server 10.0.100.233 on port 49
>>                deadtime is 5
>>                vrf is management
>>
>>     
>
> Is there a chance you have a mismatch TACACS key?
>
> -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 linux.yahoo at gmail.com  Wed Jul  1 04:39:21 2009
From: linux.yahoo at gmail.com (Manu Chao)
Date: Wed, 1 Jul 2009 10:39:21 +0200
Subject: [c-nsp] Would an MTU mis-match cause one-way ICMP over EoMPLS
	VC?
In-Reply-To: <C37B3F86-A515-4EA7-8D0F-7D44DDEEA631@lixfeld.ca>
References: <C37B3F86-A515-4EA7-8D0F-7D44DDEEA631@lixfeld.ca>
Message-ID: <7100ed370907010139o4ce9f3fbp718077dcc8e0bd1f@mail.gmail.com>

wrong mtu setting = normal problem, normal drop ;)

you must have the same mtu on a ptp link, if not fragmentation will fail

On Mon, Jun 29, 2009 at 6:17 AM, Jason Lixfeld <jason at lixfeld.ca> wrote:

> Diagram:
>
>  siteA CE
>    ||
> +---++---+
> | 7206PE |
> +---++---+
>   f2/0 (mtu 1500)
>    ||
>   f0/1 (mtu 1504)
> +---++---+
> | ME3400 |
> +---++---+
>   g0/1 (mtu 1504)
>    ||
>   g1/1 (mtu 9216)
> +---++---+
> |  7609  |
> +---++---+
>   g7/2 (mtu 9216)
>    ||
>   g0/0 (mtu 9216)
> +---++---+
> | 7301PE |
> +---++---+
>    ||
>  siteB CE
>
> I'm getting one-way ICMP over a VC that is terminated on the 7206PE;
> meaning ICMP echo requests sourced from siteA CE to siteB CE cannot be seen
> on the siteB CE.  However, ICMP echo requests sourced from the siteB CE can
> be seen on the siteA CE (but the echo reply packest are not seen by siteB
> CE).
>
> I understand that MTU issues would most certainly cause problems if the
> packet size was closer to the 1500 byte mark (1474 or there about,
> depending, maybe), but would this particular MTU mis-match even cause issues
> with such small ICMP packets?
>
> If MTU wouldn't cause this, then I'm back to square one with trying to
> figure out this one-way traffic thing I've got going on here.
>
> 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 ayourtch at cisco.com  Wed Jul  1 05:12:31 2009
From: ayourtch at cisco.com (Andrew Yourtchenko)
Date: Wed, 1 Jul 2009 11:12:31 +0200 (CEST)
Subject: [c-nsp] Question about Cisco PIX VPN
In-Reply-To: <4A4AA63C.7000609@corp.sonic.net>
References: <4A4AA63C.7000609@corp.sonic.net>
Message-ID: <Pine.LNX.4.64.0907011104040.17423@zippy.stdio.be>

Hi Jared,

On Tue, 30 Jun 2009, Jared Gillis wrote:

> Hi all,
>
> I'm configuring a PIX 501 running v6.3.5 code to terminate VPN connections from
> remote users. I've got the config intact, but need to learn how the PIX handles
> these connections internally.
> Here's the relevant config:
>
> access-list nonatvpn permit ip 192.168.0.0 255.255.255.0 192.168.1.0 255.255.255.0
> ip pool vpnswclient 192.168.1.2-192.168.1.254
> nat (inside) 0 access-list nonatvpn
>
> and I've got vpngroups defined per-user to pull from the vpnswclient pool and
> split-tunnel based on the nonatvpn acl.
>
> So my "inside" network is 192.168.0.0/24, and the vpnclients will get addressed
> into 192.168.1.0/24 (correct?), and there will be no NAT on communication
> between them. My question is, are my vpn clients in the same broadcast domain as

nope, they are not. Also, unless you have "sysopt connection permit-ipsec" 
you will need to explicitly allow their traffic into the inside.

> my "inside" interface, or will they be required to unicast to 192.168.0.x
> addresses? Is there a way to influence how they can communicate?

They'll talk unicast, as two different subnets. You can think as if the 
192.168.1.x subnet is something  hanging off the outside interface.
BTW, that's the reason why no internet communication via VPN without split 
tunneling was possible till the "same-security permit intra-interface" - 
because in that case you arrive from "outside" and need to go back to "outside".


cheers,
andrew

>
> I've been looking all over Cisco's website and can find plenty of configuration
> examples, but nothing explaining how communication between the inside and vpn
> clients is handled.
>
> -- 
> 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/
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From mhuff at ox.com  Wed Jul  1 06:25:15 2009
From: mhuff at ox.com (Matthew Huff)
Date: Wed, 1 Jul 2009 06:25:15 -0400
Subject: [c-nsp] Non export of netflow  of dscp bits from PCF3A
In-Reply-To: <4A4AF918.3080504@isarnet.de>
References: <F3318834F1F89D46857972DD4B411D7011C3D3A4@EXCHANGE.thenap.com>
	<Pine.LNX.4.61.0906301535510.6312@soloth.lewis.org>
	<483E6B0272B0284BA86D7596C40D29F9D122127DF0@PUR-EXCH07.ox.com>
	<4A4AF918.3080504@isarnet.de>
Message-ID: <483E6B0272B0284BA86D7596C40D29F9D122127DF1@PUR-EXCH07.ox.com>

That's what I suspected, but I couldn't find a release note/tech note that detailed that. And cisco support hasn't been helpful either, even though I mentioned that I suspected it was a limitation of the PFC3A.

----
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: Dirk Kurfuerst [mailto:dirk.kurfuerst at isarnet.de] 
Sent: Wednesday, July 01, 2009 1:50 AM
To: Matthew Huff
Cc: 'cisco-nsp at puck.nether.net'
Subject: Re: [c-nsp] Non export of netflow of dscp bits from PCF3A

Works like designed. The PFC3A doesn't export QoS informations. This has
been one major reason to go for the B version for us some times ago at
Qimonda. (rem: QoS-netflow-collecting seems a L2-netflow-feature; this
is supported in the B versions only)


Matthew Huff schrieb:
> We use Fluke's Netflow Tracker for netflow analysis. I've run into a weird one though. Our netflow export from our distribution switches which are running 12.2(33)SXI1 does not seem to export the dscp bits, but our core switches running 12.2(33)SXI1 as well, do export the dscp bits. The difference is the distribution switch is a PFC3A where the core switches are PFC3Bs. Anyone seen this issue before? I've verified that the netflow configurations are identical, and that the packets do have the attributes set as they pass throught he distribution.
>
>
>
> ----
> 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
>
>
>   

-- 
--------------------------------------------
 Dirk Kurfuerst

 Tel. +49 811 99829 130
 Fax: +49 89 97007 200
 GSM: +49 178 7072043
 e-mail: dirk.kurfuerst at isarnet.de
 http://www.isarnet.de
 http://www.isarflow.de
--------------------------------------------
 IsarNet AG
 Terminalstrasse Mitte 18
 85356 Muenchen
 Sitz der Gesellschaft: Oberding
 Handelsregister Muenchen, HRB 127295
 USt.-ID Nr. DE203054669
 Vorstand: 
 Andreas Perthel, Harald Weikert
 Vorsitzender des Aufsichtsrates: 
 Andreas Gallenmueller
-------------------------------------------- 


From arla at rn.dk  Wed Jul  1 07:26:49 2009
From: arla at rn.dk (Arne Larsen / Region Nordjylland)
Date: Wed, 1 Jul 2009 13:26:49 +0200
Subject: [c-nsp] tacacs+ an nexus 5010
In-Reply-To: <1E2E1EC2-04AA-4F50-BC52-16424E5E184D@netspot.com.au>
References: <59083.1246397647@lavin-llc.com>
	<8D68760F464FFD40A01BF2FB374E4A2801CC19061CB8@SRVEXC02.aas.its.nja.dk>
	<20090701080150.GE32316@lboro.ac.uk>
	<1E2E1EC2-04AA-4F50-BC52-16424E5E184D@netspot.com.au>
Message-ID: <8D68760F464FFD40A01BF2FB374E4A2801CC19061CBE@SRVEXC02.aas.its.nja.dk>

I guess, I can fid that command, I've seen in doc also. But the config points to mng vrf.

aaa group server tacacs+ REG_TAC
    server xxx.xxxx.xxx.xxx
    deadtime 5
    use-vrf management

/Arne

-----Oprindelig meddelelse-----
Fra: Tom Lanyon [mailto:tom at netspot.com.au]
Sendt: 1. juli 2009 10:09
Til: Arne Larsen / Region Nordjylland
Cc: cisco-nsp
Emne: Re: [c-nsp] tacacs+ an nexus 5010

>> No, it should be right. My problem is that if I do a tcpdump on the
>> tacacs+ server I dont see anything from the nexus.
>> It's like it doesn't leave the box at all.
>
> or is blocked elsewhere - check the network that the TACACS+ traffic
> is being sent on and check ACLs etc that might be in the way on the
> way to the server. check firewall on server to ensure such traffic is
> allowed.  ping and telnet are okay but they wont test the actual
> method used.


... and are you using the correct 'ip tacacs source-interface' to source the traffic?

From rdobbins at arbor.net  Wed Jul  1 07:39:40 2009
From: rdobbins at arbor.net (Roland Dobbins)
Date: Wed, 1 Jul 2009 18:39:40 +0700
Subject: [c-nsp] DNS rewrite & global capabilities
In-Reply-To: <8685783A8C22C640AD1361E78659B7D7697716@ahex02.activehost.local>
References: <725755F5E728EE4086DAAF1A54DACF4F150AD905@sea5exbe1.speakeasy.hq><44385206-0907-4D3D-87A2-0073FCF2D1AA@arbor.net><8685783A8C22C640AD1361E78659B7D7697713@ahex02.activehost.local><DBCE07D4-D084-4DDE-8CCD-276F4E6F56F4@arbor.net><8685783A8C22C640AD1361E78659B7D7697714@ahex02.activehost.local>
	<8891CCEF-1BE2-40F1-BCB4-58B29D967DE0@arbor.net>
	<F308716D736FE64E9082DB665757E91B036714E6@ahex02.activehost.local>
	<8685783A8C22C640AD1361E78659B7D7697716@ahex02.activehost.local>
Message-ID: <8FE21039-C1C4-4243-A90C-3A12898F07A1@arbor.net>


On Jul 1, 2009, at 2:05 PM, Quinn Mahoney wrote:

> That's not saying a whole lot.  You could always get more bandwidth  
> and
> more servers.  That doesn't mean it's not helpful to have a  
> specialized
> device multiplexing the connections to the servers, and doing more
> sophisticated analysis of the packets before sending them to the  
> server.

On the contrary, it's absolutely detrimental to attempt to perform  
such analysis on a device which is yet another attack vector, and  
which can easily be overwhelmed due to its limited stateful capacity  
(multiplexing is useful, but is unrelated to this general topic).

I speak from personal hands-on operational experience, and from the  
personal hands-on operational experience of others who with whom I've  
worked in this sector.

> "You are claiming that certain firewalls/load-balancers can't firewall
> and inspect packets at millions of packets per second.  This claim is
> inconsistent with current data.

I know how these devices work from the inside-out, having utilized,  
deployed, and participated in feature specifications for same.  They  
don't do what you claim, and can't ever, due to their inherent design  
principles.

> These packets are the same as legit packets, I do not believe a fully
> effective automated system exists.

My hands-on personal operational experience detecting, classifying,  
tracing back, and mitigating multi-gb/sec, multi-mpps DDoS attacks  
using precisely the approaches I've outlined indicate otherwise.

> Not really saying a whole lot again. My argument was not that the
> products you refer to aren't a part of an effective security solution.


My arguments are based on large-scale operational experience and  
detailed knowledge of this topic and of the performance envelopes/ 
characteristics of these types of devices in real-world situations, as  
well as from a design and development perspective.  They are factual,  
and represent ground truth, not opinions.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

         Unfortunately, inefficiency scales really well.

		   -- Kevin Lawton


From drew.weaver at thenap.com  Wed Jul  1 11:12:04 2009
From: drew.weaver at thenap.com (Drew Weaver)
Date: Wed, 1 Jul 2009 08:12:04 -0700
Subject: [c-nsp] Fun with interface counters.
In-Reply-To: <d6966e4b0906301324h31fdbbf8s9fe8fb6e68d6c472@mail.gmail.com>
References: <F3318834F1F89D46857972DD4B411D7011C3D3A4@EXCHANGE.thenap.com>
	<d6966e4b0906301324h31fdbbf8s9fe8fb6e68d6c472@mail.gmail.com>
Message-ID: <F3318834F1F89D46857972DD4B411D7011C3D3CA@EXCHANGE.thenap.com>

Hi,

It's just a Gigabit Ethernet interface with an IP, it's not attached to a VLAN.

-Drew
-----Original Message-----
From: gpendery at gmail.com [mailto:gpendery at gmail.com] On Behalf Of Geoffrey Pendery
Sent: Tuesday, June 30, 2009 4:25 PM
To: Drew Weaver
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Fun with interface counters.

Trunk port or access port?

One of the main places I've seen mismatching amounts of tx/rx is on
trunk ports, where either the "switchport trunk allowed vlan" doesn't
match on both sides, or in the case of the router interface, you only
have .1Q subinterfaces configured for certain VLANs, but other VLANs
are flooding across the link.


-Geoff


On Tue, Jun 30, 2009 at 4:59 PM, Drew Weaver<drew.weaver at thenap.com> wrote:
> I assume this is either a bug, or something else equally enjoyable.
>
> Today, I noticed that one of our switches was acting up, so I logged into it and did the usual show interfaces, sh proc cpu sort, etc etc.
>
> I noticed that the switch's uplink interface indicated that it was doing 700Mbps to the router it is connected to, the router indicated that it was only getting 200Mbps from the switch.
>
> So either there is a counter bug, or the switch was sending traffic that was being dropped by the router or dropped later by the switch (after it was counted?), or something else equally amusing?
>
> Does anyone have any thoughts on this/seen this before?
>
> 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 geoff at pendery.net  Wed Jul  1 09:46:42 2009
From: geoff at pendery.net (Geoffrey Pendery)
Date: Wed, 1 Jul 2009 08:46:42 -0500
Subject: [c-nsp] using a /29 mask on a /30 point-to-point
In-Reply-To: <1246407916.7941.10.camel@localhost.localdomain>
References: <c979a8a40906301244i17c81955v9693b2f501af6f76@mail.gmail.com>
	<1246407916.7941.10.camel@localhost.localdomain>
Message-ID: <d6966e4b0907010646t59a85540saa04dd386a724edc@mail.gmail.com>

Or short of changing ISP, change your layout.

I assume you are receiving either:
A.  One hand-off going to a switch, then ports on that switch used to
connect to outside interfaces of both PIXes.
B.  Two hand-offs, each one going to a PIX outside interface.

If it's A, then adding a router isn't really "adding a single point of
failure", since you already have SPoFs (the single hand-off and the
single switch).  Just replace the switch with either a router or a
layer 3 switch (like a 3560/3750).
If it's B, then add two routers, one for each hand-off, and have them
do HSRP/VRRP/GLBP on the inside for your firewalls.

Either solution seems less likely to get your "Internet Drivers
License revoked" than trying to wrangle some IP trickery on a /28
(suggested above in lieu of /29, probably a better idea since none of
the actual interface addresses will be seen as the broadcast address
by your hosts).

But yes, it would probably work.  And of course correct me if your
layout is actually C.


-Geoff


On Tue, Jun 30, 2009 at 7:25 PM, Peter Rathlev<peter at rathlev.dk> wrote:
> On Tue, 2009-06-30 at 15:44 -0400, Deny IP Any Any wrote:
>> Could I configure the subnet on my side of the WAN as a /29? My
>> broadcast address would be wrong, but since its basically a
>> point-to-point anyway, I shouldn't need broadcasts. I realize this is
>> semi-evil, and might get my Internet drivers license revoked, but what
>> would I break by doing this?
>
> To clear up: The PIX uses only two addresses, one for the active unit
> and one for the standby unit. The address for the standby unit is only
> used to reach the standby when the primary is still active/live. Upon
> failover the standby unit becomes active and takes over the IP adress of
> the former active. Every NAT/PAT is carried over statefully between the
> pair. A failover is pratically "invisible" for neighbors.
>
> If you couldn't change ISP and absolutely _had_ to do something that
> would almost certainly make your successor hate you, then you _could_
> configure the PIX with a /29 mask where the addressing is thus:
>
> - PIX primary address is "your" side of the ISP assigned /30
> - PIX secondary address is one of the broadcast addresses from the ISP
> assigned /30 (the one that is a valid host address in the /29)
> - Insert a static /30 route for the other part of the /29.
>
> Example, if the ISP assigned 10.0.0.0/30 for your link and took 10.0.0.1
> for themselves (in v7+ format):
>
> ! *** pix ***
> interface GigabitEthernet0/0
> ?nameif outside
> ?security-level 0
> ?ip address 10.0.0.2 255.255.255.248 standby 10.0.0.3
> !
> route outside 10.0.0.4 255.255.255.252 10.0.0.1
> !
>
> Please just change ISP. :-)
>
> 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 tkacprzynski at SpencerStuart.com  Wed Jul  1 11:34:07 2009
From: tkacprzynski at SpencerStuart.com (tkacprzynski at SpencerStuart.com)
Date: Wed, 1 Jul 2009 10:34:07 -0500
Subject: [c-nsp] MPLS/BGP - want to add backup IPSEC VPN
In-Reply-To: <003a01c9fa0d$cca739c0$0a00000a@nil.si>
References: <4A4A636E.4090301@chrisserafin.com><1246398642.6267.85.camel@localhost.localdomain>
	<003a01c9fa0d$cca739c0$0a00000a@nil.si>
Message-ID: <A8A11BA006DA57498FAC0A56686865042ABBAA6F@usilwdex04.spencerstuart.com>

Peter
If you are the customer and have multiple sites, then I would suggest
you look at Dynamic Multipoint VPN (DMVPN). With DMVPN you can have each
branch site create a tunnel dynamically when it needs to send traffic to
the other sites in case of the MPLS link failure. DMVPN only works on
routrs, not firewall, as far as I know. With Phase 3 of the DMVPN your
failover to the backup network would work with normal routing protocols
like EIGRP, changing a route..

Let me know if that's something you are looking for ( I could give you
more info on that ) , here are some links I gathered over the time for
DMVPN
http://delicious.com/search?context=userposts&p=dmvpn&lc=1&u=tomek0001

Tom


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Ivan Pepelnjak
Sent: Wednesday, July 01, 2009 12:36 AM
To: 'Peter Rathlev'; 'ChrisSerafin'
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] MPLS/BGP - want to add backup IPSEC VPN

If you're the customer (having only CE routers), this is a classic
primary/backup problem, only this time using BGP as the core routing
protocol. 

If you're the provider (using MPLS between your BGP routers to offer
whatever services), you can run MPLS over GRE over IPSec on the backup
link
(just watch for MTU issues). We built a pretty large network using it
and
after the initial kinks it works perfectly.

Ivan
 
http://www.ioshints.info/about
http://blog.ioshints.info/

> -----Original Message-----
> From: Peter Rathlev [mailto:peter at rathlev.dk] 
> Sent: Tuesday, June 30, 2009 11:51 PM
> To: ChrisSerafin
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] MPLS/BGP - want to add backup IPSEC VPN
> 
> On Tue, 2009-06-30 at 14:11 -0500, ChrisSerafin wrote:
> > I have a few MPLS routers running BGP as the routing protocol.
> > 
> > I added a public IP'ed interface on a free ports on the 
> same router, 
> > and I'm able to get to it and use it for Internet bound 
> traffic if I 
> > wish. I would like to configure an IPSEC VPN to provide 
> backup if the 
> > MPLS provider fails. I'm having a hard time with Cisco TAC on this, 
> > mainly them getting back to me.
> > 
> > dumb'ed down diagram is at: http://chrisserafin.com/design.jpg
> > 
> > I just want a basic split tunnel VPN in the event the 
> primary MPLS/BGP 
> > link goes down. I'm assuming let BGP take care of the MPLS side and 
> > add static routes with a very high weight for the VPN failover?
> 
> And the VPN-link needs to carry MPLS traffic too? MPLSoGRE 
> could be an option, but support is very limited AFAIK.
> 
> Otherwise some extra equipment doing L2TPv3 might work. 
> Performance limitations might very well rule this out.
> 
> If MPLS isn't needed a simple GRE tunnel would of course do. 
> You could even create a new tunnel per VRF if you need 
> reachability in several of these. It scales bad concerning 
> administration though.
> 
> 
> 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 tsuther at i3businesssolutions.com  Wed Jul  1 12:19:58 2009
From: tsuther at i3businesssolutions.com (Tom Sutherland)
Date: Wed, 1 Jul 2009 12:19:58 -0400
Subject: [c-nsp] Cisco ASA digital certificate
In-Reply-To: <3b53747c0906240035q41470221gd9092926e0bfae02@mail.gmail.com>
References: <3b53747c0906240035q41470221gd9092926e0bfae02@mail.gmail.com>
Message-ID: <1246465198.4504.11.camel@angry-butler09>

I've not used it myself, but I believe an ASA running 8.x code can
actually act as a certificate authority itself.

On Wed, 2009-06-24 at 03:35 -0400, almog ohayon wrote:
> Hello Everyone,I have the following requirements for small integration
> project and it's not working:
> 1. Remote access VPN for only 1-2 users.
> 2. Remote users can get access to the internal network only with certificate
> - software or hardware.
> 3. the gateway is Cisco ASA 5510.
> 
> *notes:*
> 1. i don't want to use Microsoft CA server or any dedicated CA server for
> certificate enrollment.
> 2. i want to install the ASA as standalone device and the certificates will
> be installed on it.
> 3. i can use both Cisco IPsec client or Cisco anyconnect client.
> 
> 
> if someone has solution for me or recommendation it will be great.
> if anyone think of a better security authetication solution also be great.
> 
> thanks.
> --
> Almog Ohayon.
> _______________________________________________
> cisco-nsp mailing list  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  Wed Jul  1 12:49:23 2009
From: ip at ioshints.info (Ivan Pepelnjak)
Date: Wed, 1 Jul 2009 18:49:23 +0200
Subject: [c-nsp] MPLS/BGP - want to add backup IPSEC VPN
In-Reply-To: <4A4B8FCF.509@chrisserafin.com>
References: <4A4A636E.4090301@chrisserafin.com>
	<1246398642.6267.85.camel@localhost.localdomain>
	<003a01c9fa0d$cca739c0$0a00000a@nil.si>
	<4A4B8FCF.509@chrisserafin.com>
Message-ID: <007501c9fa6b$e3d8ca10$0a00000a@nil.si>

> > If you're the customer (having only CE routers), this is a classic 
> > primary/backup problem, only this time using BGP as the 
> core routing 
> > protocol.
> >
     
> This sounds like what I'm planning on doing.....GRE for the 
> routing protocols....we are on the CE end. If you could, 
> please elaborate on the routing that is involved, thanks!

The simplest thing would be to run BGP everywhere and make the paths over
the GRE tunnels less preferred (for example, by using lower local
preference).

Ivan
 
http://www.ioshints.info/about
http://blog.ioshints.info/


From chale99 at gmail.com  Wed Jul  1 12:56:39 2009
From: chale99 at gmail.com (Chris Hale)
Date: Wed, 1 Jul 2009 12:56:39 -0400
Subject: [c-nsp] CPU comparison - bridge vs. route on 7206?
Message-ID: <db092ca60907010956s622ca2fdq18cc492eff7761e7@mail.gmail.com>

We have a set of 7206VXR's, NPE400 CPUs on each end of a point to point OC3
using PA-POS-OC3 cards.  We bridge these circuits through a PA-GE interface
(essentially turning the 7206's into a OC-3 to GigE converter) with a single
bridge group.

We are trying to push nearly 130-140Mbps, but per the MRTG graphs, we seem
to be capping @ ~110Mbps.  The CPU is also averaging 80-90%.  We're seeing a
large number of input errors (ignored, total of 5% of input packets) and a
fair amount of output pauses (0.12% of output packets).

GigabitEthernet1/0 is up, line protocol is up
  Hardware is WISEMAN, address is 0016.46e6.1c1c (bia 0016.46e6.1c1c)
  MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
     reliability 255/255, txload 36/255, rxload 16/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex, 1000Mb/s, link type is autonegotiation, media type is unknown
media type
  output flow-control is XON, input flow-control is XON
  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 12w0d
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 208
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  30 second input rate 66046000 bits/sec, 29231 packets/sec
  30 second output rate 141617000 bits/sec, 31690 packets/sec
     2816822087 packets input, 1367339773 bytes, 0 no buffer
     Received 7138653 broadcasts, 0 runts, 0 giants, 0 throttles
     143326584 input errors, 0 CRC, 0 frame, 481945 overrun, 142844639
ignored
     0 watchdog, 4536607 multicast, 0 pause input
     0 input packets with dribble condition detected
     3993978307 packets output, 979813878 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 babbles, 0 late collision, 0 deferred
     4 lost carrier, 0 no carrier, 4808187 pause output
     0 output buffer failures, 0 output buffers swapped out

If we move this to a routed infrastructure with CEF, can we expect the CPU
to drop considerably?   The routing will be static only, very simple config
with no ACLs, no policy maps, etc.  We're just trying to get the routers to
let us push as much of the OC3 bandwidth as possible.

We would rather not upgrade the NPE400's if possible.  The internal LAN
equipment is Nortel L3 switches which don't seem to support flow-control.

Thanks in advance for any ideas.

Chris

-- 
------------------
Chris Hale
chale99 at gmail.com

From zivl at gilat.net  Wed Jul  1 13:01:59 2009
From: zivl at gilat.net (Ziv Leyes)
Date: Wed, 1 Jul 2009 20:01:59 +0300
Subject: [c-nsp] OT: Best Online Antispam Service
In-Reply-To: <18dba4e50906301556o5c9d66b1p6737642e36a45e4c@mail.gmail.com>
References: <18dba4e50906301555j1b0d8c85j68259fe320f024c3@mail.gmail.com>
	<18dba4e50906301556o5c9d66b1p6737642e36a45e4c@mail.gmail.com>
Message-ID: <EC993E87D960A541A66BF21D62AA42A623014B3CE5@exch2k7.gilat.local>

Once I used to have a mail server at home and a domain for my family and friends, I tried and liked very much the free service google apps can offer, you could host your mail domain at their servers and then make the mails be automatically forwarded to your corporate mail. This way you'll enjoy both good anti-virus/anti-spam AND mail backup for free, it supports up to 500 mailboxes for free, need more? You can pay and get as much as you want.
I think yahoo offers a similar service, and their integration with Outlook seems better, but I never tried it.
Ziv

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Felix Nkansah
Sent: Wednesday, July 01, 2009 1:57 AM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] OT: Best Online Antispam Service

Hi Team,
I am interested in subscribing to a GOOD online email filtering service,
through which all emails destined to an enterprise domain transit, are
scanned and filtered for spam and viruses, before legitimate mails relayed
to the destination mail server.

As a bonus, the service should also store emails for some time if the
destination mail server is down.

Much as IronPort and Barracuda appliances do a good antispam job, they are
typically placed onsite for which reason the network bandwidth still gets
chocked with arriving spam.

Please share your experienced recommendations with me on this one. It's
better for me than following google search.

Felix
_______________________________________________
cisco-nsp mailing 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 chris at chrisserafin.com  Wed Jul  1 12:30:53 2009
From: chris at chrisserafin.com (ChrisSerafin)
Date: Wed, 01 Jul 2009 11:30:53 -0500
Subject: [c-nsp] MPLS/BGP - want to add backup IPSEC VPN
In-Reply-To: <1246398642.6267.85.camel@localhost.localdomain>
References: <4A4A636E.4090301@chrisserafin.com>
	<1246398642.6267.85.camel@localhost.localdomain>
Message-ID: <4A4B8F3D.3070400@chrisserafin.com>

Peter Rathlev wrote:
> On Tue, 2009-06-30 at 14:11 -0500, ChrisSerafin wrote:
>   
>> I have a few MPLS routers running BGP as the routing protocol.
>>
>> I added a public IP'ed interface on a free ports on the same router, and 
>> I'm able to get to it and use it for Internet bound traffic if I wish. I 
>> would like to configure an IPSEC VPN to provide backup if the MPLS 
>> provider fails. I'm having a hard time with Cisco TAC on this, mainly 
>> them getting back to me.
>>
>> dumb'ed down diagram is at: http://chrisserafin.com/design.jpg
>>
>> I just want a basic split tunnel VPN in the event the primary MPLS/BGP 
>> link goes down. I'm assuming let BGP take care of the MPLS side and add 
>> static routes with a very high weight for the VPN failover?
>>     
>
> And the VPN-link needs to carry MPLS traffic too? MPLSoGRE could be an
> option, but support is very limited AFAIK.
>
> Otherwise some extra equipment doing L2TPv3 might work. Performance
> limitations might very well rule this out.
>
> If MPLS isn't needed a simple GRE tunnel would of course do. You could
> even create a new tunnel per VRF if you need reachability in several of
> these. It scales bad concerning administration though.
>   
The VPN will only need to carry the traffic behind router (the remote 
subnet) and no MPLS 'traffic', so I'm going to look into GRE.....

Found this: 
http://supportwiki.cisco.com/ViewWiki/index.php/Tech_Insights:Preferring_MPLS_VPN_BGP_Path_with_IGP_Backup 
<http://supportwiki.cisco.com/ViewWiki/index.php/Tech_Insights:Preferring_MPLS_VPN_BGP_Path_with_IGP_Backup>

But I have no idea how to implement it yet.


From chris at chrisserafin.com  Wed Jul  1 12:33:19 2009
From: chris at chrisserafin.com (ChrisSerafin)
Date: Wed, 01 Jul 2009 11:33:19 -0500
Subject: [c-nsp] MPLS/BGP - want to add backup IPSEC VPN
In-Reply-To: <003a01c9fa0d$cca739c0$0a00000a@nil.si>
References: <4A4A636E.4090301@chrisserafin.com>
	<1246398642.6267.85.camel@localhost.localdomain>
	<003a01c9fa0d$cca739c0$0a00000a@nil.si>
Message-ID: <4A4B8FCF.509@chrisserafin.com>

Ivan Pepelnjak wrote:
> If you're the customer (having only CE routers), this is a classic
> primary/backup problem, only this time using BGP as the core routing
> protocol. 
>
> If you're the provider (using MPLS between your BGP routers to offer
> whatever services), you can run MPLS over GRE over IPSec on the backup link
> (just watch for MTU issues). We built a pretty large network using it and
> after the initial kinks it works perfectly.
>
> Ivan
>  
> http://www.ioshints.info/about
> http://blog.ioshints.info/
>
>   
>> -----Original Message-----
>> From: Peter Rathlev [mailto:peter at rathlev.dk] 
>> Sent: Tuesday, June 30, 2009 11:51 PM
>> To: ChrisSerafin
>> Cc: cisco-nsp at puck.nether.net
>> Subject: Re: [c-nsp] MPLS/BGP - want to add backup IPSEC VPN
>>
>> On Tue, 2009-06-30 at 14:11 -0500, ChrisSerafin wrote:
>>     
>>> I have a few MPLS routers running BGP as the routing protocol.
>>>
>>> I added a public IP'ed interface on a free ports on the 
>>>       
>> same router, 
>>     
>>> and I'm able to get to it and use it for Internet bound 
>>>       
>> traffic if I 
>>     
>>> wish. I would like to configure an IPSEC VPN to provide 
>>>       
>> backup if the 
>>     
>>> MPLS provider fails. I'm having a hard time with Cisco TAC on this, 
>>> mainly them getting back to me.
>>>
>>> dumb'ed down diagram is at: http://chrisserafin.com/design.jpg
>>>
>>> I just want a basic split tunnel VPN in the event the 
>>>       
>> primary MPLS/BGP 
>>     
>>> link goes down. I'm assuming let BGP take care of the MPLS side and 
>>> add static routes with a very high weight for the VPN failover?
>>>       
>> And the VPN-link needs to carry MPLS traffic too? MPLSoGRE 
>> could be an option, but support is very limited AFAIK.
>>
>> Otherwise some extra equipment doing L2TPv3 might work. 
>> Performance limitations might very well rule this out.
>>
>> If MPLS isn't needed a simple GRE tunnel would of course do. 
>> You could even create a new tunnel per VRF if you need 
>> reachability in several of these. It scales bad concerning 
>> administration though.
>>
>>     
This sounds like what I'm planning on doing.....GRE for the routing 
protocols....we are on the CE end. If you could, please elaborate on the 
routing that is involved, thanks!

From rodunn at cisco.com  Wed Jul  1 13:41:44 2009
From: rodunn at cisco.com (Rodney Dunn)
Date: Wed, 1 Jul 2009 13:41:44 -0400
Subject: [c-nsp] CPU comparison - bridge vs. route on 7206?
In-Reply-To: <db092ca60907010956s622ca2fdq18cc492eff7761e7@mail.gmail.com>
References: <db092ca60907010956s622ca2fdq18cc492eff7761e7@mail.gmail.com>
Message-ID: <20090701174144.GJ12789@rtp-cse-489.cisco.com>

The PA-GE has issues at higher speeds.

You should move to L2TPV3 and see if it's better in regards
to performance. Your best would be pure L3 forwarding.

If the PA-GE is the issue you will have to get off that PA.

What happens if you move it to one of the onboard GigE ports on the NPE-400?

Rodney

On Wed, Jul 01, 2009 at 12:56:39PM -0400, Chris Hale wrote:
> We have a set of 7206VXR's, NPE400 CPUs on each end of a point to point OC3
> using PA-POS-OC3 cards.  We bridge these circuits through a PA-GE interface
> (essentially turning the 7206's into a OC-3 to GigE converter) with a single
> bridge group.
> 
> We are trying to push nearly 130-140Mbps, but per the MRTG graphs, we seem
> to be capping @ ~110Mbps.  The CPU is also averaging 80-90%.  We're seeing a
> large number of input errors (ignored, total of 5% of input packets) and a
> fair amount of output pauses (0.12% of output packets).
> 
> GigabitEthernet1/0 is up, line protocol is up
>   Hardware is WISEMAN, address is 0016.46e6.1c1c (bia 0016.46e6.1c1c)
>   MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
>      reliability 255/255, txload 36/255, rxload 16/255
>   Encapsulation ARPA, loopback not set
>   Keepalive set (10 sec)
>   Full-duplex, 1000Mb/s, link type is autonegotiation, media type is unknown
> media type
>   output flow-control is XON, input flow-control is XON
>   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 12w0d
>   Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 208
>   Queueing strategy: fifo
>   Output queue: 0/40 (size/max)
>   30 second input rate 66046000 bits/sec, 29231 packets/sec
>   30 second output rate 141617000 bits/sec, 31690 packets/sec
>      2816822087 packets input, 1367339773 bytes, 0 no buffer
>      Received 7138653 broadcasts, 0 runts, 0 giants, 0 throttles
>      143326584 input errors, 0 CRC, 0 frame, 481945 overrun, 142844639
> ignored
>      0 watchdog, 4536607 multicast, 0 pause input
>      0 input packets with dribble condition detected
>      3993978307 packets output, 979813878 bytes, 0 underruns
>      0 output errors, 0 collisions, 0 interface resets
>      0 babbles, 0 late collision, 0 deferred
>      4 lost carrier, 0 no carrier, 4808187 pause output
>      0 output buffer failures, 0 output buffers swapped out
> 
> If we move this to a routed infrastructure with CEF, can we expect the CPU
> to drop considerably?   The routing will be static only, very simple config
> with no ACLs, no policy maps, etc.  We're just trying to get the routers to
> let us push as much of the OC3 bandwidth as possible.
> 
> We would rather not upgrade the NPE400's if possible.  The internal LAN
> equipment is Nortel L3 switches which don't seem to support flow-control.
> 
> Thanks in advance for any ideas.
> 
> Chris
> 
> -- 
> ------------------
> Chris Hale
> chale99 at gmail.com
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

From jay at west.net  Wed Jul  1 13:53:28 2009
From: jay at west.net (Jay Hennigan)
Date: Wed, 01 Jul 2009 10:53:28 -0700
Subject: [c-nsp] CPU comparison - bridge vs. route on 7206?
In-Reply-To: <20090701174144.GJ12789@rtp-cse-489.cisco.com>
References: <db092ca60907010956s622ca2fdq18cc492eff7761e7@mail.gmail.com>
	<20090701174144.GJ12789@rtp-cse-489.cisco.com>
Message-ID: <4A4BA298.3060708@west.net>

Rodney Dunn wrote:
> The PA-GE has issues at higher speeds.
> 
> You should move to L2TPV3 and see if it's better in regards
> to performance. Your best would be pure L3 forwarding.
> 
> If the PA-GE is the issue you will have to get off that PA.
> 
> What happens if you move it to one of the onboard GigE ports on the NPE-400?

There aren't any onboard gigE ports on an NPE-400.  You need NPE-G1 for 
those.

--
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 rwest at zyedge.com  Wed Jul  1 15:28:00 2009
From: rwest at zyedge.com (Ryan West)
Date: Wed, 1 Jul 2009 15:28:00 -0400
Subject: [c-nsp] Cisco ASA digital certificate
In-Reply-To: <1246465198.4504.11.camel@angry-butler09>
References: <3b53747c0906240035q41470221gd9092926e0bfae02@mail.gmail.com>
	<1246465198.4504.11.camel@angry-butler09>
Message-ID: <6E21B2BDEF6E714EA0B5BA8D5D0E140124835C5BCB@zy-ex1.zyedge.local>

Tom,

Thanks for making me take a look:

http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/cert_cfg.html#wp1067484

Good info to have handy.  Guide above is for 8.2, but it's supported in all 8.x.

-ryan

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Tom Sutherland
Sent: Wednesday, July 01, 2009 12:20 PM
To: almog ohayon
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Cisco ASA digital certificate

I've not used it myself, but I believe an ASA running 8.x code can
actually act as a certificate authority itself.

On Wed, 2009-06-24 at 03:35 -0400, almog ohayon wrote:
> Hello Everyone,I have the following requirements for small integration
> project and it's not working:
> 1. Remote access VPN for only 1-2 users.
> 2. Remote users can get access to the internal network only with certificate
> - software or hardware.
> 3. the gateway is Cisco ASA 5510.
> 
> *notes:*
> 1. i don't want to use Microsoft CA server or any dedicated CA server for
> certificate enrollment.
> 2. i want to install the ASA as standalone device and the certificates will
> be installed on it.
> 3. i can use both Cisco IPsec client or Cisco anyconnect client.
> 
> 
> if someone has solution for me or recommendation it will be great.
> if anyone think of a better security authetication solution also be great.
> 
> thanks.
> --
> Almog Ohayon.
> _______________________________________________
> cisco-nsp mailing 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 chris at chrisserafin.com  Wed Jul  1 13:56:18 2009
From: chris at chrisserafin.com (ChrisSerafin)
Date: Wed, 01 Jul 2009 12:56:18 -0500
Subject: [c-nsp] MPLS/BGP - want to add backup IPSEC VPN
In-Reply-To: <007501c9fa6b$e3d8ca10$0a00000a@nil.si>
References: <4A4A636E.4090301@chrisserafin.com>
	<1246398642.6267.85.camel@localhost.localdomain>
	<003a01c9fa0d$cca739c0$0a00000a@nil.si>
	<4A4B8FCF.509@chrisserafin.com>
	<007501c9fa6b$e3d8ca10$0a00000a@nil.si>
Message-ID: <4A4BA342.4070706@chrisserafin.com>

Ivan Pepelnjak wrote:
>>> If you're the customer (having only CE routers), this is a classic 
>>> primary/backup problem, only this time using BGP as the 
>>>       
>> core routing 
>>     
>>> protocol.
>>>
>>>       
>      
>   
>> This sounds like what I'm planning on doing.....GRE for the 
>> routing protocols....we are on the CE end. If you could, 
>> please elaborate on the routing that is involved, thanks!
>>     
>
> The simplest thing would be to run BGP everywhere and make the paths over
> the GRE tunnels less preferred (for example, by using lower local
> preference).
>
> Ivan
>  
> http://www.ioshints.info/about
> http://blog.ioshints.info/
>   
Well looking at the Cisoc docs, I cannot terminate a GRE tunnel on an 
ASA firewall......any other ideas....thanks

From rodunn at cisco.com  Wed Jul  1 16:02:48 2009
From: rodunn at cisco.com (Rodney Dunn)
Date: Wed, 1 Jul 2009 16:02:48 -0400
Subject: [c-nsp] CPU comparison - bridge vs. route on 7206?
In-Reply-To: <4A4BA298.3060708@west.net>
References: <db092ca60907010956s622ca2fdq18cc492eff7761e7@mail.gmail.com>
	<20090701174144.GJ12789@rtp-cse-489.cisco.com>
	<4A4BA298.3060708@west.net>
Message-ID: <20090701200248.GN12789@rtp-cse-489.cisco.com>

I couldn't remember so I looked for a picture and thought I saw one it did
have.

They would need the G1/G2 then.

Or maybe go to routed mode.

Rodney


On Wed, Jul 01, 2009 at 10:53:28AM -0700, Jay Hennigan wrote:
> Rodney Dunn wrote:
> >The PA-GE has issues at higher speeds.
> >
> >You should move to L2TPV3 and see if it's better in regards
> >to performance. Your best would be pure L3 forwarding.
> >
> >If the PA-GE is the issue you will have to get off that PA.
> >
> >What happens if you move it to one of the onboard GigE ports on the 
> >NPE-400?
> 
> There aren't any onboard gigE ports on an NPE-400.  You need NPE-G1 for 
> those.
> 
> --
> 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 luan at netcraftsmen.net  Wed Jul  1 16:51:14 2009
From: luan at netcraftsmen.net (luan at netcraftsmen.net)
Date: Wed, 1 Jul 2009 16:51:14 -0400 (EDT)
Subject: [c-nsp] MPLS/BGP - want to add backup IPSEC VPN
In-Reply-To: <4A4BA342.4070706@chrisserafin.com>
References: <4A4A636E.4090301@chrisserafin.com>
	<1246398642.6267.85.camel@localhost.localdomain>
	<003a01c9fa0d$cca739c0$0a00000a@nil.si> <4A4B8FCF.509@chrisserafin.com>
	<007501c9fa6b$e3d8ca10$0a00000a@nil.si>
	<4A4BA342.4070706@chrisserafin.com>
Message-ID: <44614.63.82.115.195.1246481474.squirrel@mail.netcraftsmen.net>

> Ivan Pepelnjak wrote:
>>>> If you're the customer (having only CE routers), this is a classic
>>>> primary/backup problem, only this time using BGP as the
>>>>
>>> core routing
>>>
>>>> protocol.
>>>>
>>>>
>>
>>
>>> This sounds like what I'm planning on doing.....GRE for the
>>> routing protocols....we are on the CE end. If you could,
>>> please elaborate on the routing that is involved, thanks!
>>>
>>
>> The simplest thing would be to run BGP everywhere and make the paths
>> over
>> the GRE tunnels less preferred (for example, by using lower local
>> preference).
>>
>> Ivan
>>
>> http://www.ioshints.info/about
>> http://blog.ioshints.info/
>>
> Well looking at the Cisoc docs, I cannot terminate a GRE tunnel on an
> ASA firewall......any other ideas....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/
>


Terminate the GRE tunnel in the same router that has MPLS VPN.
You could just run EIGRP over the GRE (add IPSEC as well since it's over
the internet).

Regards,

-Luan


From gregpclark at gmail.com  Wed Jul  1 17:28:01 2009
From: gregpclark at gmail.com (Greg Clark)
Date: Wed, 1 Jul 2009 16:28:01 -0500
Subject: [c-nsp] tacacs+ an nexus 5010
In-Reply-To: <8D68760F464FFD40A01BF2FB374E4A2801CC19061CBE@SRVEXC02.aas.its.nja.dk>
References: <59083.1246397647@lavin-llc.com>
	<8D68760F464FFD40A01BF2FB374E4A2801CC19061CB8@SRVEXC02.aas.its.nja.dk>
	<20090701080150.GE32316@lboro.ac.uk>
	<1E2E1EC2-04AA-4F50-BC52-16424E5E184D@netspot.com.au>
	<8D68760F464FFD40A01BF2FB374E4A2801CC19061CBE@SRVEXC02.aas.its.nja.dk>
Message-ID: <44ae085f0907011428u4028aa7w881f16a46e77bd29@mail.gmail.com>

Arne,

   This config looks good I've run a similar config in  a production
environment and it worked.  The only thing I didn't see in your config
but I would assume is there is the correct ip address assigned to your
mgmt0 interface and the "feature tacacs+" command.



feature tacacs+

tacacs-server timeout 4
 tacacs-server host 10.0.100.233 key 7 "xxxxxxxxx"
 aaa group server tacacs+ access
     server 10.0.100.233
     use-vrf management

 tacacs-server directed-request
 vrf context management
   ip route 0.0.0.0/0 10.2.8.1

 interface mgmt0
   ip address 10.2.8.14

Also when you're performing your ping tests are you using the
management vrf? I believe the command is "ping 10.0.100.233 vrf
management"

Thanks,

Greg

On Wed, Jul 1, 2009 at 6:26 AM, Arne Larsen / Region
Nordjylland<arla at rn.dk> wrote:
> I guess, I can fid that command, I've seen in doc also. But the config points to mng vrf.
>
> aaa group server tacacs+ REG_TAC
> ? ?server xxx.xxxx.xxx.xxx
> ? ?deadtime 5
> ? ?use-vrf management
>
> /Arne
>
> -----Oprindelig meddelelse-----
> Fra: Tom Lanyon [mailto:tom at netspot.com.au]
> Sendt: 1. juli 2009 10:09
> Til: Arne Larsen / Region Nordjylland
> Cc: cisco-nsp
> Emne: Re: [c-nsp] tacacs+ an nexus 5010
>
>>> No, it should be right. My problem is that if I do a tcpdump on the
>>> tacacs+ server I dont see anything from the nexus.
>>> It's like it doesn't leave the box at all.
>>
>> or is blocked elsewhere - check the network that the TACACS+ traffic
>> is being sent on and check ACLs etc that might be in the way on the
>> way to the server. check firewall on server to ensure such traffic is
>> allowed. ?ping and telnet are okay but they wont test the actual
>> method used.
>
>
> ... and are you using the correct 'ip tacacs source-interface' to source the traffic?
> _______________________________________________
> cisco-nsp mailing list ?cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From stephane.tsacas at gmail.com  Wed Jul  1 16:29:22 2009
From: stephane.tsacas at gmail.com (Stephane Tsacas)
Date: Wed, 1 Jul 2009 22:29:22 +0200
Subject: [c-nsp] OT: Best Online Antispam Service
In-Reply-To: <EC993E87D960A541A66BF21D62AA42A623014B3CE5@exch2k7.gilat.local>
References: <18dba4e50906301555j1b0d8c85j68259fe320f024c3@mail.gmail.com>
	<18dba4e50906301556o5c9d66b1p6737642e36a45e4c@mail.gmail.com>
	<EC993E87D960A541A66BF21D62AA42A623014B3CE5@exch2k7.gilat.local>
Message-ID: <ebdb53760907011329i2c356aaap34b5f440007edc17@mail.gmail.com>

On Wed, Jul 1, 2009 at 19:01, Ziv Leyes <zivl at gilat.net> wrote:

> Once I used to have a mail server at home and a domain for my family and
> friends, I tried and liked very much the free service google apps can offer,
> you could host your mail domain at their servers and then make the mails be
> automatically forwarded to your corporate mail. This way you'll enjoy both
> good anti-virus/anti-spam AND mail backup for free, it supports up to 500
> mailboxes for free, need more? You can pay and get as much as you want.


The maximum is 50 accounts for the Standard Edition, with ads.
http://www.google.com/support/a/bin/answer.py?hl=en&answer=113251
There is a limit on the number of email you can send every day (I think it's
500).

Google apps is nice anyway, but if your site suddenly drives to much traffic
it'll be automatically turned off by Google. And you have no access to any
stats regarding to the traffic volume.

Anyway, it's certainly a nice platform to play with (still speaking about
the free version).

-- 
Stephane
Paris, France.

From eng_mssk at hotmail.com  Wed Jul  1 17:33:53 2009
From: eng_mssk at hotmail.com (Mohammad Khalil)
Date: Thu, 2 Jul 2009 00:33:53 +0300
Subject: [c-nsp] NSAP address
Message-ID: <BLU102-W5F24F5231A74DDE74299AFA2E0@phx.gbl>


hi all 
i have a machine with windows server 2003 installed on it
i have another SDH device that deals with NSAP address
now i want a static root on the server pointing to the SDH device but i dont know the syntax 
any ideas ?

thanks

_________________________________________________________________
Drag n? drop?Get easy photo sharing with Windows Live? Photos.

http://www.microsoft.com/windows/windowslive/products/photos.aspx

From jimmi at netpoint.com.br  Wed Jul  1 16:01:27 2009
From: jimmi at netpoint.com.br (jimmi)
Date: Wed, 1 Jul 2009 17:01:27 -0300
Subject: [c-nsp] Default Route Handler
Message-ID: <20090701200103.M11287@netpoint.com.br>

Folks.

Regarding CEF & FIB, despite the fact this term sounds self understandable,
Does someone knows the exactly definition of "Default Route Handler"?

Best regards.

Jimmi. 


From sgranger at randfinancial.com  Wed Jul  1 17:46:35 2009
From: sgranger at randfinancial.com (Sean Granger)
Date: Wed, 01 Jul 2009 16:46:35 -0500
Subject: [c-nsp] OT: Best Online Antispam Service
Message-ID: <4A4B92EB020000D90000298E@mail.randfinancial.com>

After a rocky start w/ false positives, we've had a decent go of things with MXLogic.
They're consistently improving value to the service by adding functionality.

>>> Felix Nkansah <felixnkansah at gmail.com> 6/30/2009 5:56 PM >>>
Hi Team,
I am interested in subscribing to a GOOD online email filtering service,
through which all emails destined to an enterprise domain transit, are
scanned and filtered for spam and viruses, before legitimate mails relayed
to the destination mail server.

As a bonus, the service should also store emails for some time if the
destination mail server is down.

Much as IronPort and Barracuda appliances do a good antispam job, they are
typically placed onsite for which reason the network bandwidth still gets
chocked with arriving spam.

Please share your experienced recommendations with me on this one. It's
better for me than following google search.

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

From mike at schuler.me  Wed Jul  1 18:03:23 2009
From: mike at schuler.me (MIchael Schuler)
Date: Wed, 01 Jul 2009 17:03:23 -0500
Subject: [c-nsp] OT: Best Online Antispam Service
In-Reply-To: <4A4B92EB020000D90000298E@mail.randfinancial.com>
Message-ID: <C671475B.3F50%mike@schuler.me>

I've had some really phenomenal experience using Postini.  It's pricing is
extremely reasonable at 12/year per user for just spam/virus filtering.  It
can do SMS/email alerts of host down and spooling until the server comes
back up.  The firm I work at uses it for about 1700 users and I have a
client I support of about 30 users that use it with extremely great results.
Easy for users to use.  Easy to implement for inbound and outbound scanning.


On 7/1/09 4:46 PM, "Sean Granger" <sgranger at randfinancial.com> wrote:

> After a rocky start w/ false positives, we've had a decent go of things with
> MXLogic.
> They're consistently improving value to the service by adding functionality.
> 
>>>> Felix Nkansah <felixnkansah at gmail.com> 6/30/2009 5:56 PM >>>
> Hi Team,
> I am interested in subscribing to a GOOD online email filtering service,
> through which all emails destined to an enterprise domain transit, are
> scanned and filtered for spam and viruses, before legitimate mails relayed
> to the destination mail server.
> 
> As a bonus, the service should also store emails for some time if the
> destination mail server is down.
> 
> Much as IronPort and Barracuda appliances do a good antispam job, they are
> typically placed onsite for which reason the network bandwidth still gets
> chocked with arriving spam.
> 
> Please share your experienced recommendations with me on this one. It's
> better for me than following google search.
> 
> Felix
> _______________________________________________
> cisco-nsp mailing 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 paul at paulstewart.org  Wed Jul  1 18:19:02 2009
From: paul at paulstewart.org (Paul Stewart)
Date: Wed, 1 Jul 2009 15:19:02 -0700
Subject: [c-nsp] OT: Best Online Antispam Service
In-Reply-To: <C671475B.3F50%mike@schuler.me>
References: <4A4B92EB020000D90000298E@mail.randfinancial.com>
	<C671475B.3F50%mike@schuler.me>
Message-ID: <000801c9fa99$fdb30d00$f9192700$@org>

Yeah, Postini is what we use today... been very good to date.  Service
Provider pricing you can get them much more aggressive in pricing depending
on volume.  I believe we're doing about 35,000 mailboxes today with them -
overall pretty happy.

Paul


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of MIchael Schuler
Sent: Wednesday, July 01, 2009 3:03 PM
To: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] OT: Best Online Antispam Service

I've had some really phenomenal experience using Postini.  It's pricing is
extremely reasonable at 12/year per user for just spam/virus filtering.  It
can do SMS/email alerts of host down and spooling until the server comes
back up.  The firm I work at uses it for about 1700 users and I have a
client I support of about 30 users that use it with extremely great results.
Easy for users to use.  Easy to implement for inbound and outbound scanning.


On 7/1/09 4:46 PM, "Sean Granger" <sgranger at randfinancial.com> wrote:

> After a rocky start w/ false positives, we've had a decent go of things
with
> MXLogic.
> They're consistently improving value to the service by adding
functionality.
> 
>>>> Felix Nkansah <felixnkansah at gmail.com> 6/30/2009 5:56 PM >>>
> Hi Team,
> I am interested in subscribing to a GOOD online email filtering service,
> through which all emails destined to an enterprise domain transit, are
> scanned and filtered for spam and viruses, before legitimate mails relayed
> to the destination mail server.
> 
> As a bonus, the service should also store emails for some time if the
> destination mail server is down.
> 
> Much as IronPort and Barracuda appliances do a good antispam job, they are
> typically placed onsite for which reason the network bandwidth still gets
> chocked with arriving spam.
> 
> Please share your experienced recommendations with me on this one. It's
> better for me than following google search.
> 
> Felix
> _______________________________________________
> cisco-nsp mailing 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 mduksa at gmail.com  Wed Jul  1 18:20:20 2009
From: mduksa at gmail.com (Marlon Duksa)
Date: Wed, 1 Jul 2009 15:20:20 -0700
Subject: [c-nsp] LNS/LAC on 7600
Message-ID: <a89d89ac0907011520p56e1f0c2pfb43147960e776ae@mail.gmail.com>

Hi - does anyone know if Cisco 7600 supports LAC/LNS functionality on the
latest ES+ cards.
I'm not interested in old MWAM cards that they used to be supported  on 7600
but I'm interested in the more recent implementation.
Thanks,
Marlon

From ak at gaaga.org  Wed Jul  1 19:34:13 2009
From: ak at gaaga.org (Andrey Kozlov)
Date: Thu, 2 Jul 2009 02:34:13 +0300
Subject: [c-nsp] Cisco 881G gprs connection problem
Message-ID: <fc8a6cc10907011634l7b45593al7a64c3559c644149@mail.gmail.com>

Hi,

Is anyone here have successful deployment of Cisco 881G router in gsm
network (EDGE)? I'm looking for advise, please help :)

According to this sources (
http://inetpro.org/wiki/Initial_configuration_of_a_881G_router_Cellular_interfaceand
http://www.cisco.com/en/US/docs/routers/access/800/860-880-890/software/configuration/guide/backup.html#wp1064962
)

I've
- unlock SIM
- created gsm-profile on modem
- created chat script
- describe interesting traffic
- configured cellular interface & line

When some ip packets arrives toward gprs-network, cellular0 interface
becomes up (L1 & L2), but, at the same time, gsm-profile still inactive and
the ip address for cellular0 remains unassigned.

wan-rok#show ip interface brief
Interface                  IP-Address      OK? Method Status
Protocol
Cellular0                  unassigned      YES NVRAM  up
up

wan-rok#show cellular 0 profile
Profile 2 = INACTIVE
--------
PDP Type = IPv4
Access Point Name (APN) = xl.kyivstar.net
Authentication = PAP
Username: internet, Password: internet


The biggest question is why state of gsm-profile remains inactive? How I can
debug what happens with packet session?

Thanks in advance.


Config details:

! The dial-string refers second gsm-profile
!
chat-script gsm "" "ATDT*99*2#" TIMEOUT 60 "CONNECT"
!
!  configuration of the data interface
!
interface Cellular0
 ip address negotiated
 encapsulation ppp
 dialer in-band
 dialer idle-timeout 0
 dialer string gsm
 dialer-group 1
 async mode interactive
 no ppp lcp fast-start
 ppp authentication pap
 ppp pap sent-username internet password 7 0828425A0C0B0B1206
 ppp ipcp dns request
!
! configuration of the control channel
!
line 3
 exec-timeout 0 0
 script dialer gsm
 modem InOut
 no exec
 transport input all
 transport output all
 rxspeed 236800
 txspeed 118000
!
! traffic definition
!
dialer-list 1 protocol ip permit
!
!
ip route 0.0.0.0 0.0.0.0 cellular 0


Diagnostic data from modem:

wan-rok#show cellular 0 all
Hardware Information
====================
Modem Firmware Version = F1_2_3_15AP C:/WS/F
Modem Firmware built = 07/09/08
Hardware Version = 1.1
Modem Status = Online
Current Modem Temperature = 29 deg C, State = Normal


Network Information
===================
Current Service Status = Normal, Service Error = None
Current Service = Combined
Packet Service = EDGE (Attached)
*Packet Session Status = Inactive*
Current Roaming Status = Home
Network Selection Mode = Manual
Country = UKR, Network = UA-KS
Mobile Country Code (MCC) = 255
Mobile Network Code (MNC) = 3
Location Area Code (LAC) = 47100
Routing Area Code (RAC) = 1
Cell ID = 6634
Primary Scrambling Code = 0
PLMN Selection = Manual
Registered PLMN = UA-KYIVSTAR , Abbreviated = UA-KS
Service Provider = KYIVSTAR

Radio Information
=================
Current Band = GSM 1800, Channel Number = 642
Current RSSI = -70 dBm
Band Selected = GSM all band

Modem Security Information
==========================
Card Holder Verification (CHV1) = Disabled
SIM Status = OK
SIM User Operation Required = None
Number of Retries remaining = 3


I've read probably all solutions that google can find, but any solution
doesn't resolve the problem.

From max.reid at saikonetworks.com  Wed Jul  1 21:49:19 2009
From: max.reid at saikonetworks.com (Maxwell Reid)
Date: Wed, 1 Jul 2009 18:49:19 -0700
Subject: [c-nsp] DNS rewrite & global capabilities
In-Reply-To: <8891CCEF-1BE2-40F1-BCB4-58B29D967DE0@arbor.net>
References: <725755F5E728EE4086DAAF1A54DACF4F150AD905@sea5exbe1.speakeasy.hq><44385206-0907-4D3D-87A2-0073FCF2D1AA@arbor.net><8685783A8C22C640AD1361E78659B7D7697713@ahex02.activehost.local>
	<DBCE07D4-D084-4DDE-8CCD-276F4E6F56F4@arbor.net>
	<8685783A8C22C640AD1361E78659B7D7697714@ahex02.activehost.local>
	<8891CCEF-1BE2-40F1-BCB4-58B29D967DE0@arbor.net>
Message-ID: <89AE338A-67ED-4CB3-817D-24CA2C791B5A@saikonetworks.com>

HI Quin & Roland,

It's a known fact that both "state" tracking and bandwidth are finite  
resources... the other finite resource that isn't talked about much is  
dollars for arbor boxes :-) The point I think is to balance the  
architecture in a manner that leaves bandwidth as the final  
bottleneck; at that point toss the "interesting" traffic into a  
sinkhole and filter it, drop it  etc.  but you need to get to that  
point first.

 From a foundation perspective, Roland is correct in stating that a  
well designed and configured server farm floating anycasted IP's can  
handle a load far greater than a single upstream firewall; but often  
times for various reasons a "well designed" server farm includes a mix  
of stateless filtering at the edge of the cluster farm, stateful  
filtering and multiplexing the next level down, and finally enough  
servers to handle the load up until the point of bandwidth  
exhaustion.  Yes, it's multiple "attack points" or layers of potential  
failure, but It's pretty naive to expect people to bolt their systems  
to the Internet  enmasse with Iptables of pf as their primary means of  
access control.

Sinkhole routing is also not a be all end all solution.   
Sophisticated, DDoS prevention is great if your dealing with the  
absolute end target in the chain of a reflection or amplification  
attack.   It even works really well when the "attackers" are using the  
same automated patterns, or scripts, or doing something silly like  
violating protocol rules or behavior. Granted, that will cover about  
90% of the miscreant attacks out there but It's harder to automate  
such a response if the attacks are well distributed and the attacker  
is adhering to know protocol behaviors.... even looking at backscatter  
isn't as reliable an indicator as it used to be.

~Max





On Jun 30, 2009, at 10:24 PM, Roland Dobbins wrote:

>
> On Jul 1, 2009, at 12:09 PM, Quinn Mahoney wrote:
>
>> Without a firewall proxying the tcp connection?  That would depend  
>> on how many servers
>> there are and what the firewalls can handle.  The server never gets
>> traffic from the spoofed addresses with the firewall, or from a
>> load-balancer that multiplex's the tcp connections.
>
> There isn't a firewall made which has the capacity to handle this  
> more efficiently than a well-configured server or server farm.
>
>> I wouldn't say much more efficiently, since more advanced load  
>> balancers
>> and firewalls route via asic's and fpga's.
>
> I certainly would, and do; they none of them run into the mpps, as  
> routers can and do.
>
>> If the packet is the same as a normal request but a spoofed address,
>> you're going to have some trouble even with automated systems looking
>> for no syn/ack, and then hunting the source down and automatically
>> blocking the true sources at the ingress of the upstreams.
>
> Not with appropriate detection/classification/traceback tools.  This  
> isn't new technology.
>
> And blocking at the edges isn't generally accomplished  
> automatically, but manually, upon demand.  Intelligent DDoS  
> mitigation devices can and do black automatically.
>
>> That's even if such an effective system actually existed.
>
> They do, see above.
>
>> While the load-balancer or advanced firewall never sent the  
>> connection to the server, and the
>> device is designed to be able to handle allocating memory for bogus
>> connections.
>
> They never send the legitimate traffic, either, being overwhelmed by  
> the DDoS.
>
> -----------------------------------------------------------------------
> Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>
>
>        Unfortunately, inefficiency scales really well.
>
> 		   -- Kevin Lawton
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


From max.reid at saikonetworks.com  Wed Jul  1 21:58:07 2009
From: max.reid at saikonetworks.com (Maxwell Reid)
Date: Wed, 1 Jul 2009 18:58:07 -0700
Subject: [c-nsp] OT: Best Online Antispam Service
In-Reply-To: <000801c9fa99$fdb30d00$f9192700$@org>
References: <4A4B92EB020000D90000298E@mail.randfinancial.com>
	<C671475B.3F50%mike@schuler.me>
	<000801c9fa99$fdb30d00$f9192700$@org>
Message-ID: <E72CFD2C-349A-45E7-B980-22BE9A996D39@saikonetworks.com>


Our experience with Postini was pretty good until Google bought them  
out.  When that happened some of postini's 'quirks' became more  
apparent (black holed mails) and the service sorta went down hill from  
there.


I'd recommend using a provider more *focused* on email that hasn't  
been bought out by a giant advertising firm or getting an appliance /  
rolling your own system.

I'd point out that Postini et. al. don't really save you that much in  
terms of bandwidth.  They aren't generally setup as store and forward  
services,  they operate by opening  a backend proxy connection to your  
mail server anyway, so you'll see header traffic, and most spam is  
relatively small fry byte wise.  If you're starving bandwidth wise,  
traffic shaping and ratelimiting are better options.

Also, if you're an ISP, they won't solve the problem of outbound  
scanning; that only applies to Enterprises.


~Max





On Jul 1, 2009, at 3:19 PM, Paul Stewart wrote:

> Yeah, Postini is what we use today... been very good to date.  Service
> Provider pricing you can get them much more aggressive in pricing  
> depending
> on volume.  I believe we're doing about 35,000 mailboxes today with  
> them -
> overall pretty happy.
>
> Paul
>
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of MIchael  
> Schuler
> Sent: Wednesday, July 01, 2009 3:03 PM
> To: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] OT: Best Online Antispam Service
>
> I've had some really phenomenal experience using Postini.  It's  
> pricing is
> extremely reasonable at 12/year per user for just spam/virus  
> filtering.  It
> can do SMS/email alerts of host down and spooling until the server  
> comes
> back up.  The firm I work at uses it for about 1700 users and I have a
> client I support of about 30 users that use it with extremely great  
> results.
> Easy for users to use.  Easy to implement for inbound and outbound  
> scanning.
>
>
> On 7/1/09 4:46 PM, "Sean Granger" <sgranger at randfinancial.com> wrote:
>
>> After a rocky start w/ false positives, we've had a decent go of  
>> things
> with
>> MXLogic.
>> They're consistently improving value to the service by adding
> functionality.
>>
>>>>> Felix Nkansah <felixnkansah at gmail.com> 6/30/2009 5:56 PM >>>
>> Hi Team,
>> I am interested in subscribing to a GOOD online email filtering  
>> service,
>> through which all emails destined to an enterprise domain transit,  
>> are
>> scanned and filtered for spam and viruses, before legitimate mails  
>> relayed
>> to the destination mail server.
>>
>> As a bonus, the service should also store emails for some time if the
>> destination mail server is down.
>>
>> Much as IronPort and Barracuda appliances do a good antispam job,  
>> they are
>> typically placed onsite for which reason the network bandwidth  
>> still gets
>> chocked with arriving spam.
>>
>> Please share your experienced recommendations with me on this one.  
>> It's
>> better for me than following google search.
>>
>> Felix
>> _______________________________________________
>> cisco-nsp mailing 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 arla at rn.dk  Thu Jul  2 02:00:56 2009
From: arla at rn.dk (Arne Larsen / Region Nordjylland)
Date: Thu, 2 Jul 2009 08:00:56 +0200
Subject: [c-nsp] tacacs+ an nexus 5010
In-Reply-To: <44ae085f0907011428u4028aa7w881f16a46e77bd29@mail.gmail.com>
References: <59083.1246397647@lavin-llc.com>
	<8D68760F464FFD40A01BF2FB374E4A2801CC19061CB8@SRVEXC02.aas.its.nja.dk>
	<20090701080150.GE32316@lboro.ac.uk>
	<1E2E1EC2-04AA-4F50-BC52-16424E5E184D@netspot.com.au>
	<8D68760F464FFD40A01BF2FB374E4A2801CC19061CBE@SRVEXC02.aas.its.nja.dk>
	<44ae085f0907011428u4028aa7w881f16a46e77bd29@mail.gmail.com>
Message-ID: <8D68760F464FFD40A01BF2FB374E4A2801CC19061CC3@SRVEXC02.aas.its.nja.dk>

Yes, I have no problem accessing the box via ssh or telnet and I can even connect to the tacacs+ server by doing a telnet from the mng vrf to the server on port 49

aasnxu1# telnet 10.0.100.233 49 vrf management
Trying 10.0.100.233...
Connected to 10.0.100.233.
Escape character is '^]'.

/Arne

-----Oprindelig meddelelse-----
Fra: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] P? vegne af Greg Clark
Sendt: 1. juli 2009 23:28
Til: cisco-nsp at puck.nether.net
Emne: Re: [c-nsp] tacacs+ an nexus 5010

Arne,

   This config looks good I've run a similar config in  a production environment and it worked.  The only thing I didn't see in your config but I would assume is there is the correct ip address assigned to your mgmt0 interface and the "feature tacacs+" command.



feature tacacs+

tacacs-server timeout 4
 tacacs-server host 10.0.100.233 key 7 "xxxxxxxxx"
 aaa group server tacacs+ access
     server 10.0.100.233
     use-vrf management

 tacacs-server directed-request
 vrf context management
   ip route 0.0.0.0/0 10.2.8.1

 interface mgmt0
   ip address 10.2.8.14

Also when you're performing your ping tests are you using the management vrf? I believe the command is "ping 10.0.100.233 vrf management"

Thanks,

Greg

On Wed, Jul 1, 2009 at 6:26 AM, Arne Larsen / Region Nordjylland<arla at rn.dk> wrote:
> I guess, I can fid that command, I've seen in doc also. But the config points to mng vrf.
>
> aaa group server tacacs+ REG_TAC
>    server xxx.xxxx.xxx.xxx
>    deadtime 5
>    use-vrf management
>
> /Arne
>
> -----Oprindelig meddelelse-----
> Fra: Tom Lanyon [mailto:tom at netspot.com.au]
> Sendt: 1. juli 2009 10:09
> Til: Arne Larsen / Region Nordjylland
> Cc: cisco-nsp
> Emne: Re: [c-nsp] tacacs+ an nexus 5010
>
>>> No, it should be right. My problem is that if I do a tcpdump on the
>>> tacacs+ server I dont see anything from the nexus.
>>> It's like it doesn't leave the box at all.
>>
>> or is blocked elsewhere - check the network that the TACACS+ traffic
>> is being sent on and check ACLs etc that might be in the way on the
>> way to the server. check firewall on server to ensure such traffic is
>> allowed.  ping and telnet are okay but they wont test the actual
>> method used.
>
>
> ... and are you using the correct 'ip tacacs source-interface' to source the traffic?
> _______________________________________________
> cisco-nsp mailing 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 sam_mailinglists at spacething.org  Thu Jul  2 06:39:41 2009
From: sam_mailinglists at spacething.org (Sam Stickland)
Date: Thu, 02 Jul 2009 11:39:41 +0100
Subject: [c-nsp] CPU comparison - bridge vs. route on 7206?
In-Reply-To: <db092ca60907010956s622ca2fdq18cc492eff7761e7@mail.gmail.com>
References: <db092ca60907010956s622ca2fdq18cc492eff7761e7@mail.gmail.com>
Message-ID: <4A4C8E6D.9080607@spacething.org>

Chris Hale wrote:
> We have a set of 7206VXR's, NPE400 CPUs on each end of a point to point OC3
> using PA-POS-OC3 cards.  We bridge these circuits through a PA-GE interface
> (essentially turning the 7206's into a OC-3 to GigE converter) with a single
> bridge group.
>
> We are trying to push nearly 130-140Mbps, but per the MRTG graphs, we seem
> to be capping @ ~110Mbps.  The CPU is also averaging 80-90%.  We're seeing a
> large number of input errors (ignored, total of 5% of input packets) and a
> fair amount of output pauses (0.12% of output packets)
On a slightly different tack, make sure you are using 64 bit counters in 
MRTG or you will never record more than 114Mbps (the MRTG graph will 
wrap). (Probably you already know this, but I was struck by the 
similarity between ~110Mbps and 114Mbps).

Sam

From sam_mailinglists at spacething.org  Thu Jul  2 07:38:40 2009
From: sam_mailinglists at spacething.org (Sam Stickland)
Date: Thu, 02 Jul 2009 12:38:40 +0100
Subject: [c-nsp] WS-X6716-10G local switching and etherchanneling
Message-ID: <4A4C9C40.6030804@spacething.org>

Hi,

I've read: 
http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod_white_paper0900aecd80673385.html

If I'm understanding this correctly, communication between each bank of 
8 ports on a 6716-10G will be line-rate, but communication between the 
first and second groups of 8 ports will need to traverse the switch fabric?

On a similar note, if I create an etherchannel between two 6716-10G's 
will a module favour forwarding out of it's locally attached channel member?

Regards,

Sam

From oboehmer at cisco.com  Thu Jul  2 08:38:21 2009
From: oboehmer at cisco.com (Oliver Boehmer (oboehmer))
Date: Thu, 2 Jul 2009 14:38:21 +0200
Subject: [c-nsp] Default Route Handler
In-Reply-To: <20090701200103.M11287@netpoint.com.br>
References: <20090701200103.M11287@netpoint.com.br>
Message-ID: <70B7A1CCBFA5C649BD562B6D9F7ED7840798E49A@xmb-ams-333.emea.cisco.com>

jimmi <> wrote on Wednesday, July 01, 2009 22:01:

> Folks.
> 
> Regarding CEF & FIB, despite the fact this term sounds self
> understandable, Does someone knows the exactly definition of "Default
> Route Handler"? 

it's a special FIB entry dealing with the default route. The default
route is treated specially to make default route changes more efficient
in the FIB.

	oli

From Jeff.Wojciechowski at midlandpaper.com  Thu Jul  2 09:15:24 2009
From: Jeff.Wojciechowski at midlandpaper.com (Jeff Wojciechowski)
Date: Thu, 2 Jul 2009 08:15:24 -0500
Subject: [c-nsp] OT: Best Online Antispam Service
In-Reply-To: <E72CFD2C-349A-45E7-B980-22BE9A996D39@saikonetworks.com>
References: <4A4B92EB020000D90000298E@mail.randfinancial.com>
	<C671475B.3F50%mike@schuler.me>	<000801c9fa99$fdb30d00$f9192700$@org>
	<E72CFD2C-349A-45E7-B980-22BE9A996D39@saikonetworks.com>
Message-ID: <6B8401A83219DF499C34DEAEE9A59992125611803A@XBOX.midlandpaper.com>

We just cut over to Postini a few months ago and there have definitely been some quirks.

Awhile back we had a mail loop where one message that keep spooling back and forth between Postini and us that kept getting a few k bigger each trip back and forth and eventually swamped out our entire internet connection. Don't recall what our mail admin had to do to stop the loop but the Postini tech was useless. Thank goodness for Netflow or I would have never figured out what the heck was going on.

Also, all the spam I get is 'from me'. I would think that if a message originates out on the public internet that is from me, to me, not originating from our SMTP server would be looked at a little closer?

So there are a few gaps.
 
Naturally this is better than when I worked for a dial-up ISP with ~ 500 customers. We used Declude and I had to manually sort mail that the didn't fall into the "probably not spam" or the "probably spam" buckets! 

-Jeff


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Maxwell Reid
Sent: Wednesday, July 01, 2009 8:58 PM
To: Cisco-nsp
Subject: Re: [c-nsp] OT: Best Online Antispam Service


Our experience with Postini was pretty good until Google bought them  
out.  When that happened some of postini's 'quirks' became more  
apparent (black holed mails) and the service sorta went down hill from  
there.


I'd recommend using a provider more *focused* on email that hasn't  
been bought out by a giant advertising firm or getting an appliance /  
rolling your own system.

I'd point out that Postini et. al. don't really save you that much in  
terms of bandwidth.  They aren't generally setup as store and forward  
services,  they operate by opening  a backend proxy connection to your  
mail server anyway, so you'll see header traffic, and most spam is  
relatively small fry byte wise.  If you're starving bandwidth wise,  
traffic shaping and ratelimiting are better options.

Also, if you're an ISP, they won't solve the problem of outbound  
scanning; that only applies to Enterprises.


~Max





On Jul 1, 2009, at 3:19 PM, Paul Stewart wrote:

> Yeah, Postini is what we use today... been very good to date.  Service
> Provider pricing you can get them much more aggressive in pricing  
> depending
> on volume.  I believe we're doing about 35,000 mailboxes today with  
> them -
> overall pretty happy.
>
> Paul
>
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of MIchael  
> Schuler
> Sent: Wednesday, July 01, 2009 3:03 PM
> To: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] OT: Best Online Antispam Service
>
> I've had some really phenomenal experience using Postini.  It's  
> pricing is
> extremely reasonable at 12/year per user for just spam/virus  
> filtering.  It
> can do SMS/email alerts of host down and spooling until the server  
> comes
> back up.  The firm I work at uses it for about 1700 users and I have a
> client I support of about 30 users that use it with extremely great  
> results.
> Easy for users to use.  Easy to implement for inbound and outbound  
> scanning.
>
>
> On 7/1/09 4:46 PM, "Sean Granger" <sgranger at randfinancial.com> wrote:
>
>> After a rocky start w/ false positives, we've had a decent go of  
>> things
> with
>> MXLogic.
>> They're consistently improving value to the service by adding
> functionality.
>>
>>>>> Felix Nkansah <felixnkansah at gmail.com> 6/30/2009 5:56 PM >>>
>> Hi Team,
>> I am interested in subscribing to a GOOD online email filtering  
>> service,
>> through which all emails destined to an enterprise domain transit,  
>> are
>> scanned and filtered for spam and viruses, before legitimate mails  
>> relayed
>> to the destination mail server.
>>
>> As a bonus, the service should also store emails for some time if the
>> destination mail server is down.
>>
>> Much as IronPort and Barracuda appliances do a good antispam job,  
>> they are
>> typically placed onsite for which reason the network bandwidth  
>> still gets
>> chocked with arriving spam.
>>
>> Please share your experienced recommendations with me on this one.  
>> It's
>> better for me than following google search.
>>
>> Felix
>> _______________________________________________
>> cisco-nsp mailing 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/

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


From eriks at nationalfastfreight.com  Thu Jul  2 09:33:49 2009
From: eriks at nationalfastfreight.com (Erik Soosalu)
Date: Thu, 2 Jul 2009 09:33:49 -0400
Subject: [c-nsp] OT: Best Online Antispam Service
In-Reply-To: <6B8401A83219DF499C34DEAEE9A59992125611803A@XBOX.midlandpaper.com>
References: <4A4B92EB020000D90000298E@mail.randfinancial.com><C671475B.3F50%mike@schuler.me>	<000801c9fa99$fdb30d00$f9192700$@org><E72CFD2C-349A-45E7-B980-22BE9A996D39@saikonetworks.com>
	<6B8401A83219DF499C34DEAEE9A59992125611803A@XBOX.midlandpaper.com>
Message-ID: <0B224A2FE01CC54C860290D42474BF6003C1735C@exchange.nff.local>

I've been using Forefront Online Security for Exchange (formerly
Exchange Hosted Filtering, formerly FrontBridge) for a number of years.
We find it works extremely well.  It is store and forward (they will
store for 5 days if your MX goes down).  Last year we had a few issues
with handoffs to the service from a limited set of clients (but these
self resolved in 4-5 hours).

> Also, all the spam I get is 'from me'. I would think that if a message
originates out on the public internet >that is from me, to me, not
originating from our SMTP server would be looked at a little closer?

In FOSE you can set a policy to block this kind of stuff.  It is
actually part of their best practices config guide.

Thanks,
Erik


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Jeff
Wojciechowski
Sent: Thursday, July 02, 2009 9:15 AM
To: Maxwell Reid; Cisco-nsp
Subject: Re: [c-nsp] OT: Best Online Antispam Service

We just cut over to Postini a few months ago and there have definitely
been some quirks.

Awhile back we had a mail loop where one message that keep spooling back
and forth between Postini and us that kept getting a few k bigger each
trip back and forth and eventually swamped out our entire internet
connection. Don't recall what our mail admin had to do to stop the loop
but the Postini tech was useless. Thank goodness for Netflow or I would
have never figured out what the heck was going on.

Also, all the spam I get is 'from me'. I would think that if a message
originates out on the public internet that is from me, to me, not
originating from our SMTP server would be looked at a little closer?

So there are a few gaps.
 
Naturally this is better than when I worked for a dial-up ISP with ~ 500
customers. We used Declude and I had to manually sort mail that the
didn't fall into the "probably not spam" or the "probably spam" buckets!


-Jeff


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Maxwell Reid
Sent: Wednesday, July 01, 2009 8:58 PM
To: Cisco-nsp
Subject: Re: [c-nsp] OT: Best Online Antispam Service


Our experience with Postini was pretty good until Google bought them  
out.  When that happened some of postini's 'quirks' became more  
apparent (black holed mails) and the service sorta went down hill from  
there.


I'd recommend using a provider more *focused* on email that hasn't  
been bought out by a giant advertising firm or getting an appliance /  
rolling your own system.

I'd point out that Postini et. al. don't really save you that much in  
terms of bandwidth.  They aren't generally setup as store and forward  
services,  they operate by opening  a backend proxy connection to your  
mail server anyway, so you'll see header traffic, and most spam is  
relatively small fry byte wise.  If you're starving bandwidth wise,  
traffic shaping and ratelimiting are better options.

Also, if you're an ISP, they won't solve the problem of outbound  
scanning; that only applies to Enterprises.


~Max





On Jul 1, 2009, at 3:19 PM, Paul Stewart wrote:

> Yeah, Postini is what we use today... been very good to date.  Service
> Provider pricing you can get them much more aggressive in pricing  
> depending
> on volume.  I believe we're doing about 35,000 mailboxes today with  
> them -
> overall pretty happy.
>
> Paul
>
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of MIchael  
> Schuler
> Sent: Wednesday, July 01, 2009 3:03 PM
> To: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] OT: Best Online Antispam Service
>
> I've had some really phenomenal experience using Postini.  It's  
> pricing is
> extremely reasonable at 12/year per user for just spam/virus  
> filtering.  It
> can do SMS/email alerts of host down and spooling until the server  
> comes
> back up.  The firm I work at uses it for about 1700 users and I have a
> client I support of about 30 users that use it with extremely great  
> results.
> Easy for users to use.  Easy to implement for inbound and outbound  
> scanning.
>
>
> On 7/1/09 4:46 PM, "Sean Granger" <sgranger at randfinancial.com> wrote:
>
>> After a rocky start w/ false positives, we've had a decent go of  
>> things
> with
>> MXLogic.
>> They're consistently improving value to the service by adding
> functionality.
>>
>>>>> Felix Nkansah <felixnkansah at gmail.com> 6/30/2009 5:56 PM >>>
>> Hi Team,
>> I am interested in subscribing to a GOOD online email filtering  
>> service,
>> through which all emails destined to an enterprise domain transit,  
>> are
>> scanned and filtered for spam and viruses, before legitimate mails  
>> relayed
>> to the destination mail server.
>>
>> As a bonus, the service should also store emails for some time if the
>> destination mail server is down.
>>
>> Much as IronPort and Barracuda appliances do a good antispam job,  
>> they are
>> typically placed onsite for which reason the network bandwidth  
>> still gets
>> chocked with arriving spam.
>>
>> Please share your experienced recommendations with me on this one.  
>> It's
>> better for me than following google search.
>>
>> Felix
>> _______________________________________________
>> cisco-nsp mailing 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/

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

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


From mulitskiy at acedsl.com  Thu Jul  2 11:00:29 2009
From: mulitskiy at acedsl.com (Michael Ulitskiy)
Date: Thu, 2 Jul 2009 11:00:29 -0400
Subject: [c-nsp] CPU comparison - bridge vs. route on 7206?
In-Reply-To: <20090701174144.GJ12789@rtp-cse-489.cisco.com>
References: <db092ca60907010956s622ca2fdq18cc492eff7761e7@mail.gmail.com>
	<20090701174144.GJ12789@rtp-cse-489.cisco.com>
Message-ID: <200907021100.30009.mulitskiy@acedsl.com>

Could you please elaborate on the PA-GE issues? Or may be you could provide some pointers to where they're described?
We're using quite a few of those with traffic rate anywhere from 50M to 100M and I didn't notice
any issues so far, but traffic rate is increasing and I'd really like to know what to expect in the future,
especially if there are any known caveats.
Thank you,

Michael

On Wednesday 01 July 2009 01:41:44 pm Rodney Dunn wrote:
> The PA-GE has issues at higher speeds.
> 
> You should move to L2TPV3 and see if it's better in regards
> to performance. Your best would be pure L3 forwarding.
> 
> If the PA-GE is the issue you will have to get off that PA.
> 
> What happens if you move it to one of the onboard GigE ports on the NPE-400?
> 
> Rodney
> 
> On Wed, Jul 01, 2009 at 12:56:39PM -0400, Chris Hale wrote:
> > We have a set of 7206VXR's, NPE400 CPUs on each end of a point to point OC3
> > using PA-POS-OC3 cards.  We bridge these circuits through a PA-GE interface
> > (essentially turning the 7206's into a OC-3 to GigE converter) with a single
> > bridge group.
> > 
> > We are trying to push nearly 130-140Mbps, but per the MRTG graphs, we seem
> > to be capping @ ~110Mbps.  The CPU is also averaging 80-90%.  We're seeing a
> > large number of input errors (ignored, total of 5% of input packets) and a
> > fair amount of output pauses (0.12% of output packets).
> > 
> > GigabitEthernet1/0 is up, line protocol is up
> >   Hardware is WISEMAN, address is 0016.46e6.1c1c (bia 0016.46e6.1c1c)
> >   MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
> >      reliability 255/255, txload 36/255, rxload 16/255
> >   Encapsulation ARPA, loopback not set
> >   Keepalive set (10 sec)
> >   Full-duplex, 1000Mb/s, link type is autonegotiation, media type is unknown
> > media type
> >   output flow-control is XON, input flow-control is XON
> >   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 12w0d
> >   Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 208
> >   Queueing strategy: fifo
> >   Output queue: 0/40 (size/max)
> >   30 second input rate 66046000 bits/sec, 29231 packets/sec
> >   30 second output rate 141617000 bits/sec, 31690 packets/sec
> >      2816822087 packets input, 1367339773 bytes, 0 no buffer
> >      Received 7138653 broadcasts, 0 runts, 0 giants, 0 throttles
> >      143326584 input errors, 0 CRC, 0 frame, 481945 overrun, 142844639
> > ignored
> >      0 watchdog, 4536607 multicast, 0 pause input
> >      0 input packets with dribble condition detected
> >      3993978307 packets output, 979813878 bytes, 0 underruns
> >      0 output errors, 0 collisions, 0 interface resets
> >      0 babbles, 0 late collision, 0 deferred
> >      4 lost carrier, 0 no carrier, 4808187 pause output
> >      0 output buffer failures, 0 output buffers swapped out
> > 
> > If we move this to a routed infrastructure with CEF, can we expect the CPU
> > to drop considerably?   The routing will be static only, very simple config
> > with no ACLs, no policy maps, etc.  We're just trying to get the routers to
> > let us push as much of the OC3 bandwidth as possible.
> > 
> > We would rather not upgrade the NPE400's if possible.  The internal LAN
> > equipment is Nortel L3 switches which don't seem to support flow-control.
> > 
> > Thanks in advance for any ideas.
> > 
> > Chris
> > 
> > -- 
> > ------------------
> > Chris Hale
> > chale99 at gmail.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/
> _______________________________________________
> cisco-nsp mailing list  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 Jul  2 11:26:33 2009
From: rodunn at cisco.com (Rodney Dunn)
Date: Thu, 2 Jul 2009 11:26:33 -0400
Subject: [c-nsp] CPU comparison - bridge vs. route on 7206?
In-Reply-To: <200907021100.30009.mulitskiy@acedsl.com>
References: <db092ca60907010956s622ca2fdq18cc492eff7761e7@mail.gmail.com>
	<20090701174144.GJ12789@rtp-cse-489.cisco.com>
	<200907021100.30009.mulitskiy@acedsl.com>
Message-ID: <20090702152633.GB22261@rtp-cse-489.cisco.com>

Michael,

I can't find the performance document I saw once before now. I'm still trying
to find it.

If you want real Gige you should go with the ASR1000. Even the G1 GE ports
will have problems at high rates with any features enabled.

Rodney

On Thu, Jul 02, 2009 at 11:00:29AM -0400, Michael Ulitskiy wrote:
> Could you please elaborate on the PA-GE issues? Or may be you could provide some pointers to where they're described?
> We're using quite a few of those with traffic rate anywhere from 50M to 100M and I didn't notice
> any issues so far, but traffic rate is increasing and I'd really like to know what to expect in the future,
> especially if there are any known caveats.
> Thank you,
> 
> Michael
> 
> On Wednesday 01 July 2009 01:41:44 pm Rodney Dunn wrote:
> > The PA-GE has issues at higher speeds.
> > 
> > You should move to L2TPV3 and see if it's better in regards
> > to performance. Your best would be pure L3 forwarding.
> > 
> > If the PA-GE is the issue you will have to get off that PA.
> > 
> > What happens if you move it to one of the onboard GigE ports on the NPE-400?
> > 
> > Rodney
> > 
> > On Wed, Jul 01, 2009 at 12:56:39PM -0400, Chris Hale wrote:
> > > We have a set of 7206VXR's, NPE400 CPUs on each end of a point to point OC3
> > > using PA-POS-OC3 cards.  We bridge these circuits through a PA-GE interface
> > > (essentially turning the 7206's into a OC-3 to GigE converter) with a single
> > > bridge group.
> > > 
> > > We are trying to push nearly 130-140Mbps, but per the MRTG graphs, we seem
> > > to be capping @ ~110Mbps.  The CPU is also averaging 80-90%.  We're seeing a
> > > large number of input errors (ignored, total of 5% of input packets) and a
> > > fair amount of output pauses (0.12% of output packets).
> > > 
> > > GigabitEthernet1/0 is up, line protocol is up
> > >   Hardware is WISEMAN, address is 0016.46e6.1c1c (bia 0016.46e6.1c1c)
> > >   MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
> > >      reliability 255/255, txload 36/255, rxload 16/255
> > >   Encapsulation ARPA, loopback not set
> > >   Keepalive set (10 sec)
> > >   Full-duplex, 1000Mb/s, link type is autonegotiation, media type is unknown
> > > media type
> > >   output flow-control is XON, input flow-control is XON
> > >   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 12w0d
> > >   Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 208
> > >   Queueing strategy: fifo
> > >   Output queue: 0/40 (size/max)
> > >   30 second input rate 66046000 bits/sec, 29231 packets/sec
> > >   30 second output rate 141617000 bits/sec, 31690 packets/sec
> > >      2816822087 packets input, 1367339773 bytes, 0 no buffer
> > >      Received 7138653 broadcasts, 0 runts, 0 giants, 0 throttles
> > >      143326584 input errors, 0 CRC, 0 frame, 481945 overrun, 142844639
> > > ignored
> > >      0 watchdog, 4536607 multicast, 0 pause input
> > >      0 input packets with dribble condition detected
> > >      3993978307 packets output, 979813878 bytes, 0 underruns
> > >      0 output errors, 0 collisions, 0 interface resets
> > >      0 babbles, 0 late collision, 0 deferred
> > >      4 lost carrier, 0 no carrier, 4808187 pause output
> > >      0 output buffer failures, 0 output buffers swapped out
> > > 
> > > If we move this to a routed infrastructure with CEF, can we expect the CPU
> > > to drop considerably?   The routing will be static only, very simple config
> > > with no ACLs, no policy maps, etc.  We're just trying to get the routers to
> > > let us push as much of the OC3 bandwidth as possible.
> > > 
> > > We would rather not upgrade the NPE400's if possible.  The internal LAN
> > > equipment is Nortel L3 switches which don't seem to support flow-control.
> > > 
> > > Thanks in advance for any ideas.
> > > 
> > > Chris
> > > 
> > > -- 
> > > ------------------
> > > Chris Hale
> > > chale99 at gmail.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/
> > _______________________________________________
> > cisco-nsp mailing 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 Jul  2 11:48:26 2009
From: rodunn at cisco.com (Rodney Dunn)
Date: Thu, 2 Jul 2009 11:48:26 -0400
Subject: [c-nsp] CPU comparison - bridge vs. route on 7206?
In-Reply-To: <20090702152633.GB22261@rtp-cse-489.cisco.com>
References: <db092ca60907010956s622ca2fdq18cc492eff7761e7@mail.gmail.com>
	<20090701174144.GJ12789@rtp-cse-489.cisco.com>
	<200907021100.30009.mulitskiy@acedsl.com>
	<20090702152633.GB22261@rtp-cse-489.cisco.com>
Message-ID: <20090702154826.GD22261@rtp-cse-489.cisco.com>

I found what I was looking. The test was on older code but in concept it
still applies.

Bi-directional going native gige port to another native gige port on the
G1 you are looking at around 470 kpps (double 940 kpps bi-directional)
at 64 byte packets with NO features.

At 1500 byte packets it can pretty much fill up the gig in both directions
without dropping frames...again with no features.

It appears from the tet you can just about fill up the links with 256 byte
packets for native gige to native gige.

However, with the PA-GE it appears it's around 127 kpps in one direction (double
to get bi-directional) at 64 byte packets. Which ends up being about 400 Mbps
total (200 M tx and 200 M rx) going from a native Gig port to the PA-GE.

These are rough numbers from a lab test with absolutly nothing configured.

And also this is from a test set where there are no micro-burst from the
real world traffic flows. We've seen that way too many times where some
L3 forwarding switch is connected and it overruns the GigE ability on the
connecting device. That's why the ASR1k is the suggested platform for that
space now as it can do linerate Gige.

Hope this helps. As always with performance numbers YMMV depending on actual
code and configuration and design.

Rodney



On Thu, Jul 02, 2009 at 11:26:33AM -0400, Rodney Dunn wrote:
> Michael,
> 
> I can't find the performance document I saw once before now. I'm still trying
> to find it.
> 
> If you want real Gige you should go with the ASR1000. Even the G1 GE ports
> will have problems at high rates with any features enabled.
> 
> Rodney
> 
> On Thu, Jul 02, 2009 at 11:00:29AM -0400, Michael Ulitskiy wrote:
> > Could you please elaborate on the PA-GE issues? Or may be you could provide some pointers to where they're described?
> > We're using quite a few of those with traffic rate anywhere from 50M to 100M and I didn't notice
> > any issues so far, but traffic rate is increasing and I'd really like to know what to expect in the future,
> > especially if there are any known caveats.
> > Thank you,
> > 
> > Michael
> > 
> > On Wednesday 01 July 2009 01:41:44 pm Rodney Dunn wrote:
> > > The PA-GE has issues at higher speeds.
> > > 
> > > You should move to L2TPV3 and see if it's better in regards
> > > to performance. Your best would be pure L3 forwarding.
> > > 
> > > If the PA-GE is the issue you will have to get off that PA.
> > > 
> > > What happens if you move it to one of the onboard GigE ports on the NPE-400?
> > > 
> > > Rodney
> > > 
> > > On Wed, Jul 01, 2009 at 12:56:39PM -0400, Chris Hale wrote:
> > > > We have a set of 7206VXR's, NPE400 CPUs on each end of a point to point OC3
> > > > using PA-POS-OC3 cards.  We bridge these circuits through a PA-GE interface
> > > > (essentially turning the 7206's into a OC-3 to GigE converter) with a single
> > > > bridge group.
> > > > 
> > > > We are trying to push nearly 130-140Mbps, but per the MRTG graphs, we seem
> > > > to be capping @ ~110Mbps.  The CPU is also averaging 80-90%.  We're seeing a
> > > > large number of input errors (ignored, total of 5% of input packets) and a
> > > > fair amount of output pauses (0.12% of output packets).
> > > > 
> > > > GigabitEthernet1/0 is up, line protocol is up
> > > >   Hardware is WISEMAN, address is 0016.46e6.1c1c (bia 0016.46e6.1c1c)
> > > >   MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
> > > >      reliability 255/255, txload 36/255, rxload 16/255
> > > >   Encapsulation ARPA, loopback not set
> > > >   Keepalive set (10 sec)
> > > >   Full-duplex, 1000Mb/s, link type is autonegotiation, media type is unknown
> > > > media type
> > > >   output flow-control is XON, input flow-control is XON
> > > >   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 12w0d
> > > >   Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 208
> > > >   Queueing strategy: fifo
> > > >   Output queue: 0/40 (size/max)
> > > >   30 second input rate 66046000 bits/sec, 29231 packets/sec
> > > >   30 second output rate 141617000 bits/sec, 31690 packets/sec
> > > >      2816822087 packets input, 1367339773 bytes, 0 no buffer
> > > >      Received 7138653 broadcasts, 0 runts, 0 giants, 0 throttles
> > > >      143326584 input errors, 0 CRC, 0 frame, 481945 overrun, 142844639
> > > > ignored
> > > >      0 watchdog, 4536607 multicast, 0 pause input
> > > >      0 input packets with dribble condition detected
> > > >      3993978307 packets output, 979813878 bytes, 0 underruns
> > > >      0 output errors, 0 collisions, 0 interface resets
> > > >      0 babbles, 0 late collision, 0 deferred
> > > >      4 lost carrier, 0 no carrier, 4808187 pause output
> > > >      0 output buffer failures, 0 output buffers swapped out
> > > > 
> > > > If we move this to a routed infrastructure with CEF, can we expect the CPU
> > > > to drop considerably?   The routing will be static only, very simple config
> > > > with no ACLs, no policy maps, etc.  We're just trying to get the routers to
> > > > let us push as much of the OC3 bandwidth as possible.
> > > > 
> > > > We would rather not upgrade the NPE400's if possible.  The internal LAN
> > > > equipment is Nortel L3 switches which don't seem to support flow-control.
> > > > 
> > > > Thanks in advance for any ideas.
> > > > 
> > > > Chris
> > > > 
> > > > -- 
> > > > ------------------
> > > > Chris Hale
> > > > chale99 at gmail.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/
> > > _______________________________________________
> > > cisco-nsp mailing 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 rodunn at cisco.com  Thu Jul  2 11:50:29 2009
From: rodunn at cisco.com (Rodney Dunn)
Date: Thu, 2 Jul 2009 11:50:29 -0400
Subject: [c-nsp] CPU comparison - bridge vs. route on 7206?
In-Reply-To: <20090702154826.GD22261@rtp-cse-489.cisco.com>
References: <db092ca60907010956s622ca2fdq18cc492eff7761e7@mail.gmail.com>
	<20090701174144.GJ12789@rtp-cse-489.cisco.com>
	<200907021100.30009.mulitskiy@acedsl.com>
	<20090702152633.GB22261@rtp-cse-489.cisco.com>
	<20090702154826.GD22261@rtp-cse-489.cisco.com>
Message-ID: <20090702155029.GE22261@rtp-cse-489.cisco.com>

One note, I'd be really interested to see how it worked if you configured
it as a L2TPV3 tunnel to connect the L2 segments vs. bridging it.
The bridge code was never designed for high speed switching.

Can you try that?

Rodney


On Thu, Jul 02, 2009 at 11:48:26AM -0400, Rodney Dunn wrote:
> I found what I was looking. The test was on older code but in concept it
> still applies.
> 
> Bi-directional going native gige port to another native gige port on the
> G1 you are looking at around 470 kpps (double 940 kpps bi-directional)
> at 64 byte packets with NO features.
> 
> At 1500 byte packets it can pretty much fill up the gig in both directions
> without dropping frames...again with no features.
> 
> It appears from the tet you can just about fill up the links with 256 byte
> packets for native gige to native gige.
> 
> However, with the PA-GE it appears it's around 127 kpps in one direction (double
> to get bi-directional) at 64 byte packets. Which ends up being about 400 Mbps
> total (200 M tx and 200 M rx) going from a native Gig port to the PA-GE.
> 
> These are rough numbers from a lab test with absolutly nothing configured.
> 
> And also this is from a test set where there are no micro-burst from the
> real world traffic flows. We've seen that way too many times where some
> L3 forwarding switch is connected and it overruns the GigE ability on the
> connecting device. That's why the ASR1k is the suggested platform for that
> space now as it can do linerate Gige.
> 
> Hope this helps. As always with performance numbers YMMV depending on actual
> code and configuration and design.
> 
> Rodney
> 
> 
> 
> On Thu, Jul 02, 2009 at 11:26:33AM -0400, Rodney Dunn wrote:
> > Michael,
> > 
> > I can't find the performance document I saw once before now. I'm still trying
> > to find it.
> > 
> > If you want real Gige you should go with the ASR1000. Even the G1 GE ports
> > will have problems at high rates with any features enabled.
> > 
> > Rodney
> > 
> > On Thu, Jul 02, 2009 at 11:00:29AM -0400, Michael Ulitskiy wrote:
> > > Could you please elaborate on the PA-GE issues? Or may be you could provide some pointers to where they're described?
> > > We're using quite a few of those with traffic rate anywhere from 50M to 100M and I didn't notice
> > > any issues so far, but traffic rate is increasing and I'd really like to know what to expect in the future,
> > > especially if there are any known caveats.
> > > Thank you,
> > > 
> > > Michael
> > > 
> > > On Wednesday 01 July 2009 01:41:44 pm Rodney Dunn wrote:
> > > > The PA-GE has issues at higher speeds.
> > > > 
> > > > You should move to L2TPV3 and see if it's better in regards
> > > > to performance. Your best would be pure L3 forwarding.
> > > > 
> > > > If the PA-GE is the issue you will have to get off that PA.
> > > > 
> > > > What happens if you move it to one of the onboard GigE ports on the NPE-400?
> > > > 
> > > > Rodney
> > > > 
> > > > On Wed, Jul 01, 2009 at 12:56:39PM -0400, Chris Hale wrote:
> > > > > We have a set of 7206VXR's, NPE400 CPUs on each end of a point to point OC3
> > > > > using PA-POS-OC3 cards.  We bridge these circuits through a PA-GE interface
> > > > > (essentially turning the 7206's into a OC-3 to GigE converter) with a single
> > > > > bridge group.
> > > > > 
> > > > > We are trying to push nearly 130-140Mbps, but per the MRTG graphs, we seem
> > > > > to be capping @ ~110Mbps.  The CPU is also averaging 80-90%.  We're seeing a
> > > > > large number of input errors (ignored, total of 5% of input packets) and a
> > > > > fair amount of output pauses (0.12% of output packets).
> > > > > 
> > > > > GigabitEthernet1/0 is up, line protocol is up
> > > > >   Hardware is WISEMAN, address is 0016.46e6.1c1c (bia 0016.46e6.1c1c)
> > > > >   MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
> > > > >      reliability 255/255, txload 36/255, rxload 16/255
> > > > >   Encapsulation ARPA, loopback not set
> > > > >   Keepalive set (10 sec)
> > > > >   Full-duplex, 1000Mb/s, link type is autonegotiation, media type is unknown
> > > > > media type
> > > > >   output flow-control is XON, input flow-control is XON
> > > > >   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 12w0d
> > > > >   Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 208
> > > > >   Queueing strategy: fifo
> > > > >   Output queue: 0/40 (size/max)
> > > > >   30 second input rate 66046000 bits/sec, 29231 packets/sec
> > > > >   30 second output rate 141617000 bits/sec, 31690 packets/sec
> > > > >      2816822087 packets input, 1367339773 bytes, 0 no buffer
> > > > >      Received 7138653 broadcasts, 0 runts, 0 giants, 0 throttles
> > > > >      143326584 input errors, 0 CRC, 0 frame, 481945 overrun, 142844639
> > > > > ignored
> > > > >      0 watchdog, 4536607 multicast, 0 pause input
> > > > >      0 input packets with dribble condition detected
> > > > >      3993978307 packets output, 979813878 bytes, 0 underruns
> > > > >      0 output errors, 0 collisions, 0 interface resets
> > > > >      0 babbles, 0 late collision, 0 deferred
> > > > >      4 lost carrier, 0 no carrier, 4808187 pause output
> > > > >      0 output buffer failures, 0 output buffers swapped out
> > > > > 
> > > > > If we move this to a routed infrastructure with CEF, can we expect the CPU
> > > > > to drop considerably?   The routing will be static only, very simple config
> > > > > with no ACLs, no policy maps, etc.  We're just trying to get the routers to
> > > > > let us push as much of the OC3 bandwidth as possible.
> > > > > 
> > > > > We would rather not upgrade the NPE400's if possible.  The internal LAN
> > > > > equipment is Nortel L3 switches which don't seem to support flow-control.
> > > > > 
> > > > > Thanks in advance for any ideas.
> > > > > 
> > > > > Chris
> > > > > 
> > > > > -- 
> > > > > ------------------
> > > > > Chris Hale
> > > > > chale99 at gmail.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/
> > > > _______________________________________________
> > > > cisco-nsp mailing 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 chale99 at gmail.com  Thu Jul  2 14:16:43 2009
From: chale99 at gmail.com (Chris Hale)
Date: Thu, 2 Jul 2009 14:16:43 -0400
Subject: [c-nsp] CPU comparison - bridge vs. route on 7206?
In-Reply-To: <20090702155029.GE22261@rtp-cse-489.cisco.com>
References: <db092ca60907010956s622ca2fdq18cc492eff7761e7@mail.gmail.com>
	<20090701174144.GJ12789@rtp-cse-489.cisco.com>
	<200907021100.30009.mulitskiy@acedsl.com>
	<20090702152633.GB22261@rtp-cse-489.cisco.com>
	<20090702154826.GD22261@rtp-cse-489.cisco.com>
	<20090702155029.GE22261@rtp-cse-489.cisco.com>
Message-ID: <db092ca60907021116x2dd6dfe7q4e15c135b2a5729c@mail.gmail.com>

Can you give me some sample code for this?  I'm willing to try it, but need
some help!

We moved to routed mode with plain static routing, and the customer is still
seeing issues.  CPU dropped about 15-20%, but we're still being overrun
everywhere...  One side is using the GE on the IO card, and the other side
is using a PA-GE.  I'm trying to muster up some NPE-G1's for testing as
well, but if this is a buffer problem, will there be any difference between
the onboard GigE ports on the NPE-G1 vs. the PA-GE or IO/GE?

navisite#sho proc cpu hist



navisite   11:21:24 AM Sunday Apr 2 2000 UTC





    666666666666666666666666666666666666666666666666666666666666

    337777733333111112222200000333337777700000333331111133333555

100

 90

 80

 70   *****                         *****                    ***

 60 ************************************************************

 50 ************************************************************

 40 ************************************************************

 30 ************************************************************

 20 ************************************************************

 10 ************************************************************

   0....5....1....1....2....2....3....3....4....4....5....5....6

             0    5    0    5    0    5    0    5    0    5    0

               CPU% per second (last 60 seconds)





    676776776666677667767766766777666777767777777766666777677777

    728127116878800870080189179140978027095020565788988001913103

100

 90

 80                                    *  *   ****

 70 ****#***************##***********####*##########*#**########

 60 ############################################################

 50 ############################################################

 40 ############################################################

 30 ############################################################

 20 ############################################################

 10 ############################################################

   0....5....1....1....2....2....3....3....4....4....5....5....6

             0    5    0    5    0    5    0    5    0    5    0

               CPU% per minute (last 60 minutes)

              * = maximum CPU%   # = average CPU%





    787656 85676666688999999999987877566666788999999999987877666686688899999

    725865488000023924177656882061167925468753067768775014474733397914817667

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%



navisite#sh int gigabitEthernet 0/0

GigabitEthernet0/0 is up, line protocol is up

  Hardware is i82543 (Livengood), address is 000f.8f58.3908 (bia
000f.8f58.3908)

  Internet address is 10.10.254.25/30

  MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,

     reliability 255/255, txload 20/255, rxload 29/255

  Encapsulation ARPA, loopback not set

  Keepalive set (10 sec)

  Full-duplex, 1000Mb/s, link type is autonegotiation, media type is T

  output flow-control is XON, input flow-control is XON

  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: 2/75/0/0 (size/max/drops/flushes); Total output drops: 82

  Queueing strategy: fifo

  Output queue: 0/40 (size/max)

  5 minute input rate 114705000 bits/sec, 33699 packets/sec

  5 minute output rate 79291000 bits/sec, 32889 packets/sec

     3562588727 packets input, 3062002285 bytes, 0 no buffer

     Received 7861538 broadcasts, 0 runts, 0 giants, 0 throttles

     297165303 input errors, 0 CRC, 0 frame, 5842451 overrun, 291322852
ignored

     0 watchdog, 5171889 multicast, 0 pause input

     0 input packets with dribble condition detected

     1554205161 packets output, 3202662663 bytes, 0 underruns

     10 output errors, 0 collisions, 1 interface resets

     0 babbles, 0 late collision, 0 deferred

     10 lost carrier, 0 no carrier, 56190635 pause output

     0 output buffer failures, 0 output buffers swapped out



POS2/0 is up, line protocol is up

  Hardware is Packet over Sonet

  Internet address is 10.10.254.22/30

  MTU 4470 bytes, BW 155000 Kbit, DLY 100 usec,

     reliability 255/255, txload 181/255, rxload 126/255

  Encapsulation HDLC, crc 16, loopback not set

  Keepalive set (10 sec)

  Scramble disabled

  Last input 00:00:06, output 00:00:00, output hang never

  Last clearing of "show interface" counters never

  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops:
260014089

  Queueing strategy: fifo

  Output queue: 0/40 (size/max)

  5 minute input rate 76517000 bits/sec, 32983 packets/sec

  5 minute output rate 110318000 bits/sec, 33701 packets/sec

     1555732979 packets input, 1503248082 bytes, 0 no buffer

     Received 1907623 broadcasts, 0 runts, 0 giants, 0 throttles

              0 parity

     479899 input errors, 342177 CRC, 0 frame, 137722 overrun, 0 ignored, 0
abort

     3301042153 packets output, 3444928001 bytes, 0 underruns

     0 output errors, 0 applique, 5 interface resets

     0 output buffer failures, 0 output buffers swapped out

     3 carrier transitions

On Thu, Jul 2, 2009 at 11:50 AM, Rodney Dunn <rodunn at cisco.com> wrote:

> One note, I'd be really interested to see how it worked if you configured
> it as a L2TPV3 tunnel to connect the L2 segments vs. bridging it.
> The bridge code was never designed for high speed switching.
>
> Can you try that?
>
> Rodney
>
>
> On Thu, Jul 02, 2009 at 11:48:26AM -0400, Rodney Dunn wrote:
> > I found what I was looking. The test was on older code but in concept it
> > still applies.
> >
> > Bi-directional going native gige port to another native gige port on the
> > G1 you are looking at around 470 kpps (double 940 kpps bi-directional)
> > at 64 byte packets with NO features.
> >
> > At 1500 byte packets it can pretty much fill up the gig in both
> directions
> > without dropping frames...again with no features.
> >
> > It appears from the tet you can just about fill up the links with 256
> byte
> > packets for native gige to native gige.
> >
> > However, with the PA-GE it appears it's around 127 kpps in one direction
> (double
> > to get bi-directional) at 64 byte packets. Which ends up being about 400
> Mbps
> > total (200 M tx and 200 M rx) going from a native Gig port to the PA-GE.
> >
> > These are rough numbers from a lab test with absolutly nothing
> configured.
> >
> > And also this is from a test set where there are no micro-burst from the
> > real world traffic flows. We've seen that way too many times where some
> > L3 forwarding switch is connected and it overruns the GigE ability on the
> > connecting device. That's why the ASR1k is the suggested platform for
> that
> > space now as it can do linerate Gige.
> >
> > Hope this helps. As always with performance numbers YMMV depending on
> actual
> > code and configuration and design.
> >
> > Rodney
> >
> >
> >
> > On Thu, Jul 02, 2009 at 11:26:33AM -0400, Rodney Dunn wrote:
> > > Michael,
> > >
> > > I can't find the performance document I saw once before now. I'm still
> trying
> > > to find it.
> > >
> > > If you want real Gige you should go with the ASR1000. Even the G1 GE
> ports
> > > will have problems at high rates with any features enabled.
> > >
> > > Rodney
> > >
> > > On Thu, Jul 02, 2009 at 11:00:29AM -0400, Michael Ulitskiy wrote:
> > > > Could you please elaborate on the PA-GE issues? Or may be you could
> provide some pointers to where they're described?
> > > > We're using quite a few of those with traffic rate anywhere from 50M
> to 100M and I didn't notice
> > > > any issues so far, but traffic rate is increasing and I'd really like
> to know what to expect in the future,
> > > > especially if there are any known caveats.
> > > > Thank you,
> > > >
> > > > Michael
> > > >
> > > > On Wednesday 01 July 2009 01:41:44 pm Rodney Dunn wrote:
> > > > > The PA-GE has issues at higher speeds.
> > > > >
> > > > > You should move to L2TPV3 and see if it's better in regards
> > > > > to performance. Your best would be pure L3 forwarding.
> > > > >
> > > > > If the PA-GE is the issue you will have to get off that PA.
> > > > >
> > > > > What happens if you move it to one of the onboard GigE ports on the
> NPE-400?
> > > > >
> > > > > Rodney
> > > > >
> > > > > On Wed, Jul 01, 2009 at 12:56:39PM -0400, Chris Hale wrote:
> > > > > > We have a set of 7206VXR's, NPE400 CPUs on each end of a point to
> point OC3
> > > > > > using PA-POS-OC3 cards.  We bridge these circuits through a PA-GE
> interface
> > > > > > (essentially turning the 7206's into a OC-3 to GigE converter)
> with a single
> > > > > > bridge group.
> > > > > >
> > > > > > We are trying to push nearly 130-140Mbps, but per the MRTG
> graphs, we seem
> > > > > > to be capping @ ~110Mbps.  The CPU is also averaging 80-90%.
>  We're seeing a
> > > > > > large number of input errors (ignored, total of 5% of input
> packets) and a
> > > > > > fair amount of output pauses (0.12% of output packets).
> > > > > >
> > > > > > GigabitEthernet1/0 is up, line protocol is up
> > > > > >   Hardware is WISEMAN, address is 0016.46e6.1c1c (bia
> 0016.46e6.1c1c)
> > > > > >   MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
> > > > > >      reliability 255/255, txload 36/255, rxload 16/255
> > > > > >   Encapsulation ARPA, loopback not set
> > > > > >   Keepalive set (10 sec)
> > > > > >   Full-duplex, 1000Mb/s, link type is autonegotiation, media type
> is unknown
> > > > > > media type
> > > > > >   output flow-control is XON, input flow-control is XON
> > > > > >   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 12w0d
> > > > > >   Input queue: 0/75/0/0 (size/max/drops/flushes); Total output
> drops: 208
> > > > > >   Queueing strategy: fifo
> > > > > >   Output queue: 0/40 (size/max)
> > > > > >   30 second input rate 66046000 bits/sec, 29231 packets/sec
> > > > > >   30 second output rate 141617000 bits/sec, 31690 packets/sec
> > > > > >      2816822087 packets input, 1367339773 bytes, 0 no buffer
> > > > > >      Received 7138653 broadcasts, 0 runts, 0 giants, 0 throttles
> > > > > >      143326584 input errors, 0 CRC, 0 frame, 481945 overrun,
> 142844639
> > > > > > ignored
> > > > > >      0 watchdog, 4536607 multicast, 0 pause input
> > > > > >      0 input packets with dribble condition detected
> > > > > >      3993978307 packets output, 979813878 bytes, 0 underruns
> > > > > >      0 output errors, 0 collisions, 0 interface resets
> > > > > >      0 babbles, 0 late collision, 0 deferred
> > > > > >      4 lost carrier, 0 no carrier, 4808187 pause output
> > > > > >      0 output buffer failures, 0 output buffers swapped out
> > > > > >
> > > > > > If we move this to a routed infrastructure with CEF, can we
> expect the CPU
> > > > > > to drop considerably?   The routing will be static only, very
> simple config
> > > > > > with no ACLs, no policy maps, etc.  We're just trying to get the
> routers to
> > > > > > let us push as much of the OC3 bandwidth as possible.
> > > > > >
> > > > > > We would rather not upgrade the NPE400's if possible.  The
> internal LAN
> > > > > > equipment is Nortel L3 switches which don't seem to support
> flow-control.
> > > > > >
> > > > > > Thanks in advance for any ideas.
> > > > > >
> > > > > > Chris
> > > > > >
> > > > > > --
> > > > > > ------------------
> > > > > > Chris Hale
> > > > > > chale99 at gmail.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/
> > > > > _______________________________________________
> > > > > cisco-nsp mailing 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/
>



-- 
------------------
Chris Hale
chale99 at gmail.com

From mulitskiy at acedsl.com  Thu Jul  2 16:58:22 2009
From: mulitskiy at acedsl.com (Michael Ulitskiy)
Date: Thu, 2 Jul 2009 16:58:22 -0400
Subject: [c-nsp] CPU comparison - bridge vs. route on 7206?
In-Reply-To: <20090702154826.GD22261@rtp-cse-489.cisco.com>
References: <db092ca60907010956s622ca2fdq18cc492eff7761e7@mail.gmail.com>
	<20090702152633.GB22261@rtp-cse-489.cisco.com>
	<20090702154826.GD22261@rtp-cse-489.cisco.com>
Message-ID: <200907021658.22772.mulitskiy@acedsl.com>

 Rodney,

Thanks for the reply. Please let me clarify it a little.
So you're saying that switching packets through PA-GE involves 3.5 times more processing overhead
compared to switching them through native port (btw, by native port you mean G1/G2 builtin one, right?),
hence pps goes down from 470kpps to 127kpps. Is that right?
I actually always thought that for the software-based platform max pps is a function of CPU.
Do you think that these figures can be improved in G2 chassis?
Thanks,

Michael

On Thursday 02 July 2009 11:48:26 am you wrote:
> I found what I was looking. The test was on older code but in concept it
> still applies.
> 
> Bi-directional going native gige port to another native gige port on the
> G1 you are looking at around 470 kpps (double 940 kpps bi-directional)
> at 64 byte packets with NO features.
> 
> At 1500 byte packets it can pretty much fill up the gig in both directions
> without dropping frames...again with no features.
> 
> It appears from the tet you can just about fill up the links with 256 byte
> packets for native gige to native gige.
> 
> However, with the PA-GE it appears it's around 127 kpps in one direction (double
> to get bi-directional) at 64 byte packets. Which ends up being about 400 Mbps
> total (200 M tx and 200 M rx) going from a native Gig port to the PA-GE.
> 
> These are rough numbers from a lab test with absolutly nothing configured.
> 
> And also this is from a test set where there are no micro-burst from the
> real world traffic flows. We've seen that way too many times where some
> L3 forwarding switch is connected and it overruns the GigE ability on the
> connecting device. That's why the ASR1k is the suggested platform for that
> space now as it can do linerate Gige.
> 
> Hope this helps. As always with performance numbers YMMV depending on actual
> code and configuration and design.
> 
> Rodney
> 
> 
> 
> On Thu, Jul 02, 2009 at 11:26:33AM -0400, Rodney Dunn wrote:
> > Michael,
> > 
> > I can't find the performance document I saw once before now. I'm still trying
> > to find it.
> > 
> > If you want real Gige you should go with the ASR1000. Even the G1 GE ports
> > will have problems at high rates with any features enabled.
> > 
> > Rodney
> > 
> > On Thu, Jul 02, 2009 at 11:00:29AM -0400, Michael Ulitskiy wrote:
> > > Could you please elaborate on the PA-GE issues? Or may be you could provide some pointers to where they're described?
> > > We're using quite a few of those with traffic rate anywhere from 50M to 100M and I didn't notice
> > > any issues so far, but traffic rate is increasing and I'd really like to know what to expect in the future,
> > > especially if there are any known caveats.
> > > Thank you,
> > > 
> > > Michael
> > > 
> > > On Wednesday 01 July 2009 01:41:44 pm Rodney Dunn wrote:
> > > > The PA-GE has issues at higher speeds.
> > > > 
> > > > You should move to L2TPV3 and see if it's better in regards
> > > > to performance. Your best would be pure L3 forwarding.
> > > > 
> > > > If the PA-GE is the issue you will have to get off that PA.
> > > > 
> > > > What happens if you move it to one of the onboard GigE ports on the NPE-400?
> > > > 
> > > > Rodney
> > > > 
> > > > On Wed, Jul 01, 2009 at 12:56:39PM -0400, Chris Hale wrote:
> > > > > We have a set of 7206VXR's, NPE400 CPUs on each end of a point to point OC3
> > > > > using PA-POS-OC3 cards.  We bridge these circuits through a PA-GE interface
> > > > > (essentially turning the 7206's into a OC-3 to GigE converter) with a single
> > > > > bridge group.
> > > > > 
> > > > > We are trying to push nearly 130-140Mbps, but per the MRTG graphs, we seem
> > > > > to be capping @ ~110Mbps.  The CPU is also averaging 80-90%.  We're seeing a
> > > > > large number of input errors (ignored, total of 5% of input packets) and a
> > > > > fair amount of output pauses (0.12% of output packets).
> > > > > 
> > > > > GigabitEthernet1/0 is up, line protocol is up
> > > > >   Hardware is WISEMAN, address is 0016.46e6.1c1c (bia 0016.46e6.1c1c)
> > > > >   MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
> > > > >      reliability 255/255, txload 36/255, rxload 16/255
> > > > >   Encapsulation ARPA, loopback not set
> > > > >   Keepalive set (10 sec)
> > > > >   Full-duplex, 1000Mb/s, link type is autonegotiation, media type is unknown
> > > > > media type
> > > > >   output flow-control is XON, input flow-control is XON
> > > > >   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 12w0d
> > > > >   Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 208
> > > > >   Queueing strategy: fifo
> > > > >   Output queue: 0/40 (size/max)
> > > > >   30 second input rate 66046000 bits/sec, 29231 packets/sec
> > > > >   30 second output rate 141617000 bits/sec, 31690 packets/sec
> > > > >      2816822087 packets input, 1367339773 bytes, 0 no buffer
> > > > >      Received 7138653 broadcasts, 0 runts, 0 giants, 0 throttles
> > > > >      143326584 input errors, 0 CRC, 0 frame, 481945 overrun, 142844639
> > > > > ignored
> > > > >      0 watchdog, 4536607 multicast, 0 pause input
> > > > >      0 input packets with dribble condition detected
> > > > >      3993978307 packets output, 979813878 bytes, 0 underruns
> > > > >      0 output errors, 0 collisions, 0 interface resets
> > > > >      0 babbles, 0 late collision, 0 deferred
> > > > >      4 lost carrier, 0 no carrier, 4808187 pause output
> > > > >      0 output buffer failures, 0 output buffers swapped out
> > > > > 
> > > > > If we move this to a routed infrastructure with CEF, can we expect the CPU
> > > > > to drop considerably?   The routing will be static only, very simple config
> > > > > with no ACLs, no policy maps, etc.  We're just trying to get the routers to
> > > > > let us push as much of the OC3 bandwidth as possible.
> > > > > 
> > > > > We would rather not upgrade the NPE400's if possible.  The internal LAN
> > > > > equipment is Nortel L3 switches which don't seem to support flow-control.
> > > > > 
> > > > > Thanks in advance for any ideas.
> > > > > 
> > > > > Chris
> > > > > 
> > > > > -- 
> > > > > ------------------
> > > > > Chris Hale
> > > > > chale99 at gmail.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/
> > > > _______________________________________________
> > > > cisco-nsp mailing 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  Thu Jul  2 21:33:08 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Thu, 02 Jul 2009 18:33:08 -0700
Subject: [c-nsp] Experiences with a3845 and NM-1A-OC3-POM ?
Message-ID: <4A4D5FD4.6060409@rollernet.us>

I'm interested in hearing from anyone on list who is using the
NM-1A-OC3-POM module to feed an OC-3 into a 3800 series router.

~Seth

From ariemer at wesenergy.com.au  Thu Jul  2 21:48:21 2009
From: ariemer at wesenergy.com.au (Aaron Riemer)
Date: Fri, 3 Jul 2009 09:48:21 +0800
Subject: [c-nsp] matched ACL - counters not updating
Message-ID: <0867622C64B50C4B878AB45C95F43F1106E16282@MAILWA01.wesenergy.local>

Hey guys,
 
Just a quick one I am interested to know why an ACL I have applied to a
VLAN is not showing counters for a particular line in the access-list
that I know is denying packets. See below for example
 
Extended IP access list virus-traffic
    10 deny ip host 10.x.x.x 10.y.y.y.y 0.0.255.255
    20 permit ip any any (167199 matches)
 
The permit ip any any shows matches as normal. What am I missing here?
 
Cheers,
 
Aaron.
 

LEGAL DISCLAIMER: This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

From s00664233 at gmail.com  Thu Jul  2 21:48:51 2009
From: s00664233 at gmail.com (cc loo)
Date: Fri, 3 Jul 2009 09:48:51 +0800
Subject: [c-nsp] [BGP] Multiple peering sessions with same ASN/prefixes
	possible ?
Message-ID: <49999c420907021848u14291c87icfaf22790111e4e4@mail.gmail.com>

Hi all,

my company's network has a peering connection with a client.
Recently, they requested us to set up another concurrent peering link (for
testing purposes).

The 2 BGP routers will be advertising the same ASN and prefixes.
As i have limited knowledge in BGP, i wondered if such a set up would screw
up the entire routing for this client ?


Wouldnt my router be confused with 2 peers advertising the same prefixes ?
How would it decide which peer to send to ?

Appreciate your kind advise. Thanks.

From rdobbins at arbor.net  Thu Jul  2 22:03:48 2009
From: rdobbins at arbor.net (Roland Dobbins)
Date: Fri, 3 Jul 2009 09:03:48 +0700
Subject: [c-nsp] matched ACL - counters not updating
In-Reply-To: <0867622C64B50C4B878AB45C95F43F1106E16282@MAILWA01.wesenergy.local>
References: <0867622C64B50C4B878AB45C95F43F1106E16282@MAILWA01.wesenergy.local>
Message-ID: <53695C6E-901D-45C1-A3AC-C15F940BAF23@arbor.net>


On Jul 3, 2009, at 8:48 AM, Aaron Riemer wrote:

> The permit ip any any shows matches as normal. What am I missing here?

If this is a 6500 with an older Sup2, note that ACL counters aren't  
supported.

How do you *know* that traffic matching the ACL stanza in question is  
actually traversing the relevant interface(s)?

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

         Unfortunately, inefficiency scales really well.

		   -- Kevin Lawton


From dcp at dcptech.com  Thu Jul  2 22:08:11 2009
From: dcp at dcptech.com (David Prall)
Date: Thu, 2 Jul 2009 22:08:11 -0400
Subject: [c-nsp] matched ACL - counters not updating
In-Reply-To: <0867622C64B50C4B878AB45C95F43F1106E16282@MAILWA01.wesenergy.local>
References: <0867622C64B50C4B878AB45C95F43F1106E16282@MAILWA01.wesenergy.local>
Message-ID: <003c01c9fb83$2f2ebed0$8d8c3c70$@com>

If you have "mls rate-limit unicast ip icmp unreachable acl-drop 0"
configured the counters on deny's don't get incremented. The default for
this rate-limiter is 100 pps with a burst of 10, you could have other acl's
being hammered and your reaching the 100pps limit via others so this one
isn't be incremented. You can use "sh int <interface> stats" to see what is
happening with the deny's. With the default you will see packets in the
Processor as icmp unreachables are returned. If "no ip unreachables" is
configured then they will be sent through the Route cache.

David

--
http://dcp.dcptech.com
 

> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> bounces at puck.nether.net] On Behalf Of Aaron Riemer
> Sent: Thursday, July 02, 2009 9:48 PM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] matched ACL - counters not updating
> 
> Hey guys,
> 
> Just a quick one I am interested to know why an ACL I have applied to a
> VLAN is not showing counters for a particular line in the access-list
> that I know is denying packets. See below for example
> 
> Extended IP access list virus-traffic
>     10 deny ip host 10.x.x.x 10.y.y.y.y 0.0.255.255
>     20 permit ip any any (167199 matches)
> 
> The permit ip any any shows matches as normal. What am I missing here?
> 
> Cheers,
> 
> Aaron.
> 
> 
> LEGAL DISCLAIMER: This message contains confidential information and is
> intended only for the individual named. If you are not the named
> addressee you should not disseminate, distribute or copy this e-mail.
> Please notify the sender immediately by e-mail if you have received
> this e-mail by mistake and delete this e-mail from your system. If you
> are not the intended recipient you are notified that disclosing,
> copying, distributing or taking any action in reliance on the contents
> of this information is strictly prohibited.
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


From BBlackford at nwresd.k12.or.us  Thu Jul  2 22:29:56 2009
From: BBlackford at nwresd.k12.or.us (Bill Blackford)
Date: Thu, 2 Jul 2009 19:29:56 -0700
Subject: [c-nsp] [BGP] Multiple peering sessions with same
	ASN/prefixes	possible ?
In-Reply-To: <49999c420907021848u14291c87icfaf22790111e4e4@mail.gmail.com>
References: <49999c420907021848u14291c87icfaf22790111e4e4@mail.gmail.com>
Message-ID: <6069A203FD01884885C037F81DD7508016CF5920F8@wsc-mail-01.intra.nwresd.k12.or.us>

<snip>
Wouldnt my router be confused with 2 peers advertising the same prefixes ?
How would it decide which peer to send to ?
</snip>

No. BGP will see both routes in the RIB and select the best path and insert into the forwarding table.
If all else is equal, chances are the forwarding decision will be based on the lower IP address, or which peer has the longest uptime.

You should be fine

If you issue a 'sh ip bgp' you will see two routes to your clients destination. One with a ">" indicating the best path which is the one selected for the forwarding table. My explanation may not be as eloquent as it should be, but I hope the content of the information is helpful.
 
-b


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of cc loo
Sent: Thursday, July 02, 2009 6:49 PM
To: cisco-nsp mailing list
Subject: [c-nsp] [BGP] Multiple peering sessions with same ASN/prefixes possible ?

Hi all,

my company's network has a peering connection with a client.
Recently, they requested us to set up another concurrent peering link (for
testing purposes).

The 2 BGP routers will be advertising the same ASN and prefixes.
As i have limited knowledge in BGP, i wondered if such a set up would screw
up the entire routing for this client ?


Wouldnt my router be confused with 2 peers advertising the same prefixes ?
How would it decide which peer to send to ?

Appreciate your kind advise. 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 ariemer at wesenergy.com.au  Thu Jul  2 22:38:35 2009
From: ariemer at wesenergy.com.au (Aaron Riemer)
Date: Fri, 3 Jul 2009 10:38:35 +0800
Subject: [c-nsp] matched ACL - counters not updating
In-Reply-To: <53695C6E-901D-45C1-A3AC-C15F940BAF23@arbor.net>
References: <0867622C64B50C4B878AB45C95F43F1106E16282@MAILWA01.wesenergy.local>
	<53695C6E-901D-45C1-A3AC-C15F940BAF23@arbor.net>
Message-ID: <0867622C64B50C4B878AB45C95F43F1106E162E2@MAILWA01.wesenergy.local>

It is a 6500 with a SUP2 however other extended ACL's are showing
matches with each ACE.

The traffic must be traversing this interface as it is the only way to
route out the subnet.

Cheers, 


Aaron.

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Roland Dobbins
Sent: Friday, 3 July 2009 10:04 AM
To: Cisco-nsp
Subject: Re: [c-nsp] matched ACL - counters not updating


On Jul 3, 2009, at 8:48 AM, Aaron Riemer wrote:

> The permit ip any any shows matches as normal. What am I missing here?

If this is a 6500 with an older Sup2, note that ACL counters aren't  
supported.

How do you *know* that traffic matching the ACL stanza in question is  
actually traversing the relevant interface(s)?

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

         Unfortunately, inefficiency scales really well.

		   -- Kevin Lawton

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

LEGAL DISCLAIMER: This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

From rdobbins at arbor.net  Thu Jul  2 22:43:31 2009
From: rdobbins at arbor.net (Roland Dobbins)
Date: Fri, 3 Jul 2009 09:43:31 +0700
Subject: [c-nsp] matched ACL - counters not updating
In-Reply-To: <0867622C64B50C4B878AB45C95F43F1106E162E2@MAILWA01.wesenergy.local>
References: <0867622C64B50C4B878AB45C95F43F1106E16282@MAILWA01.wesenergy.local>
	<53695C6E-901D-45C1-A3AC-C15F940BAF23@arbor.net>
	<0867622C64B50C4B878AB45C95F43F1106E162E2@MAILWA01.wesenergy.local>
Message-ID: <8CBD9A3A-D77A-415A-8E38-90A1122D23CF@arbor.net>


On Jul 3, 2009, at 9:38 AM, Aaron Riemer wrote:

> It is a 6500 with a SUP2 however other extended ACL's are showing
> matches with each ACE.

This may indicate that the traffic in question is being punted; you  
may wish to verify via sh proc c sort | e 0.00 and sh fm sum.

> The traffic must be traversing this interface as it is the only way to
> route out the subnet.

Are you sure the traffic is in fact reaching the interface in the  
first place?

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

         Unfortunately, inefficiency scales really well.

		   -- Kevin Lawton


From s00664233 at gmail.com  Thu Jul  2 22:55:47 2009
From: s00664233 at gmail.com (cc loo)
Date: Fri, 3 Jul 2009 10:55:47 +0800
Subject: [c-nsp] [BGP] Multiple peering sessions with same ASN/prefixes
	possible ?
In-Reply-To: <6069A203FD01884885C037F81DD7508016CF5920F8@wsc-mail-01.intra.nwresd.k12.or.us>
References: <49999c420907021848u14291c87icfaf22790111e4e4@mail.gmail.com>
	<6069A203FD01884885C037F81DD7508016CF5920F8@wsc-mail-01.intra.nwresd.k12.or.us>
Message-ID: <49999c420907021955u347c45edp9d4846dd5ea89764@mail.gmail.com>

Hi Bill,

Thanks for your kind explanation.

So far we discussed about having 2 peering links advertising the same
prefix, however the routing table would only choose _1_ out of 2 links to
send packets.

We have a requirement that a client must advertise prefix > /24 only.

Does this impose a limitation that if
- a /30 is only reachable via the first link only
- another /30 is only reachable via second link only
(Both /30 are subnets of the advertised /24)

Both /30 wouldnt be reachable at the same time, is that right ? (assuming
that the 2 routers for both links are not inter-connected, as the latter is
used for testing purposes only.)

On Fri, Jul 3, 2009 at 10:29 AM, Bill Blackford <BBlackford at nwresd.k12.or.us
> wrote:

> <snip>
> Wouldnt my router be confused with 2 peers advertising the same prefixes ?
> How would it decide which peer to send to ?
> </snip>
>
> No. BGP will see both routes in the RIB and select the best path and insert
> into the forwarding table.
> If all else is equal, chances are the forwarding decision will be based on
> the lower IP address, or which peer has the longest uptime.
>
> You should be fine
>
> If you issue a 'sh ip bgp' you will see two routes to your clients
> destination. One with a ">" indicating the best path which is the one
> selected for the forwarding table. My explanation may not be as eloquent as
> it should be, but I hope the content of the information is helpful.
>
> -b
>
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:
> cisco-nsp-bounces at puck.nether.net] On Behalf Of cc loo
> Sent: Thursday, July 02, 2009 6:49 PM
> To: cisco-nsp mailing list
> Subject: [c-nsp] [BGP] Multiple peering sessions with same ASN/prefixes
> possible ?
>
> Hi all,
>
> my company's network has a peering connection with a client.
> Recently, they requested us to set up another concurrent peering link (for
> testing purposes).
>
> The 2 BGP routers will be advertising the same ASN and prefixes.
> As i have limited knowledge in BGP, i wondered if such a set up would screw
> up the entire routing for this client ?
>
>
> Wouldnt my router be confused with 2 peers advertising the same prefixes ?
> How would it decide which peer to send to ?
>
> Appreciate your kind advise. 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 tstevens at cisco.com  Thu Jul  2 23:19:50 2009
From: tstevens at cisco.com (Tim Stevenson)
Date: Thu, 02 Jul 2009 20:19:50 -0700
Subject: [c-nsp] WS-X6716-10G local switching and etherchanneling
In-Reply-To: <4A4C9C40.6030804@spacething.org>
References: <4A4C9C40.6030804@spacething.org>
Message-ID: <200907030320.n633K6Zx012286@sj-core-2.cisco.com>

Sam, please see inline below:

At 04:38 AM 7/2/2009, Sam Stickland contended:

>Hi,
>
>I've read:
><http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod_white_paper0900aecd80673385.html>http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod_white_paper0900aecd80673385.html
>
>If I'm understanding this correctly,

I don't see any mention of 6716 in this white paper. 6716 does not 
share the same architecture as any other 10G cards (eg 6708) 
mentioned there. 6716 is actually more like a 6704 front ended by 4:1 
muxes (at a high level - in reality, different chips are being used, 
ie, metro & r2d2 et al, not janus & rohini).

>communication between each bank of
>8 ports on a 6716-10G will be line-rate, but communication between the
>first and second groups of 8 ports will need to traverse the switch fabric?

While it's correct that ports 1-8 & 9-16 are on separate fabric 
channels, the key in the 6716 is that there is built-in *port-based* 
4:1 oversubscription.

In other words, 4 physical 10G ports feed into a single 10G chip 
(there are 4 such 10G chips on the card), ie, 4 ports share 10G of 
bandwidth at the port level.

So the maximum local switching performance you'd see in one half of 
the card is 20G, the same as you'd get into the fabric.

>On a similar note, if I create an etherchannel between two 6716-10G's
>will a module favour forwarding out of it's locally attached channel member?

No, it's just a hash decision - luck of the draw. Eg, packet comes in 
on t1/1 and channel member ports are t1/5 and t2/5. You've basically 
got a 50/50 chance that you'd pass over the fabric.

HTH,
Tim



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




Tim Stevenson, tstevens at cisco.com
Routing & Switching CCIE #5561
Technical Marketing Engineer, Cisco Nexus 7000
Cisco - http://www.cisco.com
IP Phone: 408-526-6759
********************************************************
The contents of this message may be *Cisco Confidential*
and are intended for the specified recipients only.

From BBlackford at nwresd.k12.or.us  Thu Jul  2 23:23:09 2009
From: BBlackford at nwresd.k12.or.us (Bill Blackford)
Date: Thu, 2 Jul 2009 20:23:09 -0700
Subject: [c-nsp] [BGP] Multiple peering sessions with same ASN/prefixes
 possible ?
In-Reply-To: <49999c420907021955u347c45edp9d4846dd5ea89764@mail.gmail.com>
References: <49999c420907021848u14291c87icfaf22790111e4e4@mail.gmail.com>
	<6069A203FD01884885C037F81DD7508016CF5920F8@wsc-mail-01.intra.nwresd.k12.or.us>
	<49999c420907021955u347c45edp9d4846dd5ea89764@mail.gmail.com>
Message-ID: <6069A203FD01884885C037F81DD7508016CF5920F9@wsc-mail-01.intra.nwresd.k12.or.us>

If I understand your question correctly,  the /30's would be the infrastructure links? If this is the case, then they would be connected routes. If they are not then a static route between you and your client would suffice as no one is adding a /30 to the global announcements.

-b

From: cc loo [mailto:s00664233 at gmail.com]
Sent: Thursday, July 02, 2009 7:56 PM
To: Bill Blackford
Cc: cisco-nsp mailing list
Subject: Re: [c-nsp] [BGP] Multiple peering sessions with same ASN/prefixes possible ?

Hi Bill,

Thanks for your kind explanation.

So far we discussed about having 2 peering links advertising the same prefix, however the routing table would only choose _1_ out of 2 links to send packets.

We have a requirement that a client must advertise prefix > /24 only.

Does this impose a limitation that if
- a /30 is only reachable via the first link only
- another /30 is only reachable via second link only
(Both /30 are subnets of the advertised /24)

Both /30 wouldnt be reachable at the same time, is that right ? (assuming that the 2 routers for both links are not inter-connected, as the latter is used for testing purposes only.)
On Fri, Jul 3, 2009 at 10:29 AM, Bill Blackford <BBlackford at nwresd.k12.or.us<mailto:BBlackford at nwresd.k12.or.us>> wrote:
<snip>
Wouldnt my router be confused with 2 peers advertising the same prefixes ?
How would it decide which peer to send to ?
</snip>

No. BGP will see both routes in the RIB and select the best path and insert into the forwarding table.
If all else is equal, chances are the forwarding decision will be based on the lower IP address, or which peer has the longest uptime.

You should be fine

If you issue a 'sh ip bgp' you will see two routes to your clients destination. One with a ">" indicating the best path which is the one selected for the forwarding table. My explanation may not be as eloquent as it should be, but I hope the content of the information is helpful.

-b


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net<mailto:cisco-nsp-bounces at puck.nether.net> [mailto:cisco-nsp-bounces at puck.nether.net<mailto:cisco-nsp-bounces at puck.nether.net>] On Behalf Of cc loo
Sent: Thursday, July 02, 2009 6:49 PM
To: cisco-nsp mailing list
Subject: [c-nsp] [BGP] Multiple peering sessions with same ASN/prefixes possible ?

Hi all,

my company's network has a peering connection with a client.
Recently, they requested us to set up another concurrent peering link (for
testing purposes).

The 2 BGP routers will be advertising the same ASN and prefixes.
As i have limited knowledge in BGP, i wondered if such a set up would screw
up the entire routing for this client ?


Wouldnt my router be confused with 2 peers advertising the same prefixes ?
How would it decide which peer to send to ?

Appreciate your kind advise. Thanks.
_______________________________________________
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 chris.brown at acsalaska.net  Thu Jul  2 23:38:01 2009
From: chris.brown at acsalaska.net (Christopher E. Brown)
Date: Thu, 02 Jul 2009 19:38:01 -0800
Subject: [c-nsp] CPU comparison - bridge vs. route on 7206?
In-Reply-To: <200907021658.22772.mulitskiy@acedsl.com>
References: <db092ca60907010956s622ca2fdq18cc492eff7761e7@mail.gmail.com>	<20090702152633.GB22261@rtp-cse-489.cisco.com>	<20090702154826.GD22261@rtp-cse-489.cisco.com>
	<200907021658.22772.mulitskiy@acedsl.com>
Message-ID: <4A4D7D19.8070503@acsalaska.net>


IIRC the 7000 series PA buses are derived from classic PCI tech, or
something similar.  Is a simplex bus limited to around 600Mbit.


This imposes a 600Mbit minus overhead simplex burst limit on the bus.


Microbursts are an issue, the bus and the CPU limit how fast the buffers
on the PA can be drained.


Personally, I treat NPE-400 systems as capable of 100Mbit full duplex
average flow and NPE-G1 as capable of 200Mbit.  This leaves some
headroom for peaks/etc, as they both can (more or less) handle twice
that for most traffic mixes (assuming a clean/simple config).


I have seen an NPE-400 doing 250 - 300 one way and 50 - 100 the other
between Gig-IO and PA-GE for an extended perion of time, but it was
dropping a couple packets _every_ burst.



Moral of the story...  If you are connecting to things via line rate
GigE, and those things are happy doing GigE bursts (just about any
modern PC), use something other than a 7200


Michael Ulitskiy wrote:
>  Rodney,
> 
> Thanks for the reply. Please let me clarify it a little.
> So you're saying that switching packets through PA-GE involves 3.5 times more processing overhead
> compared to switching them through native port (btw, by native port you mean G1/G2 builtin one, right?),
> hence pps goes down from 470kpps to 127kpps. Is that right?
> I actually always thought that for the software-based platform max pps is a function of CPU.
> Do you think that these figures can be improved in G2 chassis?
> Thanks,
> 
> Michael
> 
> On Thursday 02 July 2009 11:48:26 am you wrote:
>> I found what I was looking. The test was on older code but in concept it
>> still applies.
>>
>> Bi-directional going native gige port to another native gige port on the
>> G1 you are looking at around 470 kpps (double 940 kpps bi-directional)
>> at 64 byte packets with NO features.
>>
>> At 1500 byte packets it can pretty much fill up the gig in both directions
>> without dropping frames...again with no features.
>>
>> It appears from the tet you can just about fill up the links with 256 byte
>> packets for native gige to native gige.
>>
>> However, with the PA-GE it appears it's around 127 kpps in one direction (double
>> to get bi-directional) at 64 byte packets. Which ends up being about 400 Mbps
>> total (200 M tx and 200 M rx) going from a native Gig port to the PA-GE.
>>
>> These are rough numbers from a lab test with absolutly nothing configured.
>>
>> And also this is from a test set where there are no micro-burst from the
>> real world traffic flows. We've seen that way too many times where some
>> L3 forwarding switch is connected and it overruns the GigE ability on the
>> connecting device. That's why the ASR1k is the suggested platform for that
>> space now as it can do linerate Gige.
>>
>> Hope this helps. As always with performance numbers YMMV depending on actual
>> code and configuration and design.
>>
>> Rodney
>>
>>
>>
>> On Thu, Jul 02, 2009 at 11:26:33AM -0400, Rodney Dunn wrote:
>>> Michael,
>>>
>>> I can't find the performance document I saw once before now. I'm still trying
>>> to find it.
>>>
>>> If you want real Gige you should go with the ASR1000. Even the G1 GE ports
>>> will have problems at high rates with any features enabled.
>>>
>>> Rodney
>>>
>>> On Thu, Jul 02, 2009 at 11:00:29AM -0400, Michael Ulitskiy wrote:
>>>> Could you please elaborate on the PA-GE issues? Or may be you could provide some pointers to where they're described?
>>>> We're using quite a few of those with traffic rate anywhere from 50M to 100M and I didn't notice
>>>> any issues so far, but traffic rate is increasing and I'd really like to know what to expect in the future,
>>>> especially if there are any known caveats.
>>>> Thank you,
>>>>
>>>> Michael
>>>>
>>>> On Wednesday 01 July 2009 01:41:44 pm Rodney Dunn wrote:
>>>>> The PA-GE has issues at higher speeds.
>>>>>
>>>>> You should move to L2TPV3 and see if it's better in regards
>>>>> to performance. Your best would be pure L3 forwarding.
>>>>>
>>>>> If the PA-GE is the issue you will have to get off that PA.
>>>>>
>>>>> What happens if you move it to one of the onboard GigE ports on the NPE-400?
>>>>>
>>>>> Rodney
>>>>>
>>>>> On Wed, Jul 01, 2009 at 12:56:39PM -0400, Chris Hale wrote:
>>>>>> We have a set of 7206VXR's, NPE400 CPUs on each end of a point to point OC3
>>>>>> using PA-POS-OC3 cards.  We bridge these circuits through a PA-GE interface
>>>>>> (essentially turning the 7206's into a OC-3 to GigE converter) with a single
>>>>>> bridge group.
>>>>>>
>>>>>> We are trying to push nearly 130-140Mbps, but per the MRTG graphs, we seem
>>>>>> to be capping @ ~110Mbps.  The CPU is also averaging 80-90%.  We're seeing a
>>>>>> large number of input errors (ignored, total of 5% of input packets) and a
>>>>>> fair amount of output pauses (0.12% of output packets).
>>>>>>
>>>>>> GigabitEthernet1/0 is up, line protocol is up
>>>>>>   Hardware is WISEMAN, address is 0016.46e6.1c1c (bia 0016.46e6.1c1c)
>>>>>>   MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
>>>>>>      reliability 255/255, txload 36/255, rxload 16/255
>>>>>>   Encapsulation ARPA, loopback not set
>>>>>>   Keepalive set (10 sec)
>>>>>>   Full-duplex, 1000Mb/s, link type is autonegotiation, media type is unknown
>>>>>> media type
>>>>>>   output flow-control is XON, input flow-control is XON
>>>>>>   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 12w0d
>>>>>>   Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 208
>>>>>>   Queueing strategy: fifo
>>>>>>   Output queue: 0/40 (size/max)
>>>>>>   30 second input rate 66046000 bits/sec, 29231 packets/sec
>>>>>>   30 second output rate 141617000 bits/sec, 31690 packets/sec
>>>>>>      2816822087 packets input, 1367339773 bytes, 0 no buffer
>>>>>>      Received 7138653 broadcasts, 0 runts, 0 giants, 0 throttles
>>>>>>      143326584 input errors, 0 CRC, 0 frame, 481945 overrun, 142844639
>>>>>> ignored
>>>>>>      0 watchdog, 4536607 multicast, 0 pause input
>>>>>>      0 input packets with dribble condition detected
>>>>>>      3993978307 packets output, 979813878 bytes, 0 underruns
>>>>>>      0 output errors, 0 collisions, 0 interface resets
>>>>>>      0 babbles, 0 late collision, 0 deferred
>>>>>>      4 lost carrier, 0 no carrier, 4808187 pause output
>>>>>>      0 output buffer failures, 0 output buffers swapped out
>>>>>>
>>>>>> If we move this to a routed infrastructure with CEF, can we expect the CPU
>>>>>> to drop considerably?   The routing will be static only, very simple config
>>>>>> with no ACLs, no policy maps, etc.  We're just trying to get the routers to
>>>>>> let us push as much of the OC3 bandwidth as possible.
>>>>>>
>>>>>> We would rather not upgrade the NPE400's if possible.  The internal LAN
>>>>>> equipment is Nortel L3 switches which don't seem to support flow-control.
>>>>>>
>>>>>> Thanks in advance for any ideas.
>>>>>>
>>>>>> Chris
>>>>>>
>>>>>> -- 
>>>>>> ------------------
>>>>>> Chris Hale
>>>>>> chale99 at gmail.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/
>>>>> _______________________________________________
>>>>> cisco-nsp mailing 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 dkeeton.mail.list at gmail.com  Fri Jul  3 00:40:41 2009
From: dkeeton.mail.list at gmail.com (Dan Keeton)
Date: Thu, 2 Jul 2009 23:40:41 -0500
Subject: [c-nsp] Long Uptime
In-Reply-To: <018201c9f0e0$f65e3740$e31aa5c0$@net>
References: <AcnwRGSeaeYn23fdTg6cU4wHQ48hcAAm7WZwAAAgH4A=>
	<018201c9f0e0$f65e3740$e31aa5c0$@net>
Message-ID: <ecd825c40907022140i475a585ayda995e4a4176e3b7@mail.gmail.com>

Cisco Internetwork Operating System Software
IOS (tm) 3000 Software (IGS-J-L), Version 11.1(8), RELEASE SOFTWARE (fc1)
Copyright (c) 1986-1996 by cisco Systems, Inc.
Compiled Thu 05-Dec-96 11:41 by tamb
Image text-base: 0x03038820, data-base: 0x00001000

ROM: System Bootstrap, Version 5.2(8a), RELEASE SOFTWARE
ROM: 3000 Bootstrap Software (IGS-RXBOOT), Version 10.2(8a), RELEASE
SOFTWARE (f
c1)
******* uptime is 11 years, 50 weeks, 2 days, 4 hours, 22 minutes
System restarted by reload at 23:58:50 UTC Fri Jul 18 1997
System image file is "flash:igs-j-l_111-8.bin", booted via flash

We've got a whole collection of 11 year routers, and some older ones that I
haven't found yet.


On Fri, Jun 19, 2009 at 8:22 AM, Nic McCartney <nic at gblx.net> wrote:

> Not techy, just interesting anyone beat this uptime?
>
> Liverpool_St_A#sho ver
> Cisco Internetwork Operating System Software IOS (tm) 3000 Software
> (IGS-J-L), Version 11.0(13), RELEASE SOFTWARE (fc1) Copyright (c) 1986-1996
> by cisco Systems, Inc.
> Compiled Mon 09-Dec-96 19:48 by athavale Image text-base: 0x030348D8,
> data-base: 0x00001000
>
> ROM: System Bootstrap, Version 5.2(8a), RELEASE SOFTWARE
> ROM: 3000 Bootstrap Software (IGS-RXBOOT), Version 10.2(8a), RELEASE
> SOFTWARE (fc1)
>
> Liverpool_St_A uptime is 529 weeks, 3 days, 9 hours, 2 minutes System
> restarted by power-on System image file is "flash:igs-j-l.110-13", booted
> via flash
>
> cisco 2500 (68030) processor (revision F) with 4096K/2048K bytes of memory.
> Processor board ID 04812778, with hardware revision 00000000 Bridging
> software.
> SuperLAT software copyright 1990 by Meridian Technology Corp).
> X.25 software, Version 2.0, NET2, BFE and GOSIP compliant.
> TN3270 Emulation software (copyright 1994 by TGV Inc).
> 1 Ethernet/IEEE 802.3 interface.
> 2 Serial network interfaces.
> 32K bytes of non-volatile configuration memory.
> 8192K bytes of processor board System flash (Read ONLY)
>
> Configuration register is 0x2102
>
> Liverpool_St_A#
>
>
> Thanks
>
> Nic
>
>
> _______________________________________________
> cisco-nsp mailing list  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  Fri Jul  3 00:20:43 2009
From: tseveendorj at gmail.com (Tseveendorj)
Date: Fri, 03 Jul 2009 13:20:43 +0900
Subject: [c-nsp] about duplex
Message-ID: <4A4D871B.1090206@gmail.com>

Hello,

I was reading about duplex need to find which one is give me good 
bandwidth and what is this. I have question about it.

How to configure duplex on router and switch port ?  These 2 ports are 
connected each other.
How do I troubleshooting duplex ? I saw router and switches log but 
nothing about duplex in it.

My understanding is If duplex mismatch and misconfigured it does 
bandwidth slowly. If I'm wrong please correct me.

I got the basic understanding on this link. 
http://en.wikipedia.org/wiki/Duplex_(telecommunications)

Best regards,
Tseveen.



From tarantul at gmail.com  Fri Jul  3 02:44:55 2009
From: tarantul at gmail.com (Nick 'tarantul' Novikov)
Date: Fri, 3 Jul 2009 10:44:55 +0400
Subject: [c-nsp] IOS XR BFD
Message-ID: <501de4ea0907022344o2d57271cob04635b8f8557b6f@mail.gmail.com>

Hola, amigos!
In the documentation about "Configuring Bidirectional Forwarding
Detection on Cisco IOS XR" cisco writes:
"BFD is supported on IPv4 directly connected external BGP peers."
The question arises, why IOS XR can't run BFD with internal BGP peers
(as old school IOS)?

-- 
tarantul
Dios es Amor

From j4bles at gmail.com  Fri Jul  3 03:10:24 2009
From: j4bles at gmail.com (jack b)
Date: Fri, 3 Jul 2009 00:10:24 -0700
Subject: [c-nsp] Full BGP feed with DFC3A's
Message-ID: <622e99f30907030010p484e604cvbf22f876149b3379@mail.gmail.com>

I have a 6509 with a Sup7203BXL that has a few WS-X6816-GBIC with DFC3A's,
its my understanding that it will select the lowest common denominator so
the Sup is effectively running as a PFC3A. What would happen if I sent this
device a full BGP feed?

From tarantul at gmail.com  Fri Jul  3 03:12:16 2009
From: tarantul at gmail.com (Nick 'tarantul' Novikov)
Date: Fri, 3 Jul 2009 11:12:16 +0400
Subject: [c-nsp] IOS XR BFD
In-Reply-To: <100362309621454DAA534950B17E55DB0116319951F1@isp-per-exc01.win2k.iinet.net.au>
References: <501de4ea0907022344o2d57271cob04635b8f8557b6f@mail.gmail.com>
	<100362309621454DAA534950B17E55DB0116319951F1@isp-per-exc01.win2k.iinet.net.au>
Message-ID: <501de4ea0907030012g638a0554o40deab1abf8f8204@mail.gmail.com>

On Fri, Jul 3, 2009 at 10:55 AM, Ian Henderson<ianh at chime.net.au> wrote:
> Nick 'tarantul' Novikov wrote on 2009-07-03:
>
>> The question arises, why IOS XR can't run BFD with internal BGP peers
>> (as old school IOS)?
>
> Because its assumed you're already using an IGP with which you can use it?

I need drop down BGP session (between ASBR) if this (and only this)
link doesn't transmit packets. BGP timers very slow for it.


-- 
tarantul
Dios es Amor

From tseveendorj at gmail.com  Fri Jul  3 02:13:19 2009
From: tseveendorj at gmail.com (Tseveendorj)
Date: Fri, 03 Jul 2009 15:13:19 +0900
Subject: [c-nsp] sh ip interface brief
Message-ID: <4A4DA17F.1020608@gmail.com>

Hello,

I have never seen interface named NVI0. What is this NVI0?

router#sh ip interface brief
Interface                  IP-Address      OK? Method 
Status                Protocol
GigabitEthernet0/0         x.x.x.x   YES NVRAM  up                    up
GigabitEthernet0/0.1       x.x.x.x    YES NVRAM  up                    up
GigabitEthernet0/0.2       x.x.x.x    YES NVRAM  up                    up
GigabitEthernet0/1         x.x.x.x  YES NVRAM  up                    up
FastEthernet0/0/0          unassigned      YES unset  
up                    down
FastEthernet0/0/1          unassigned      YES unset  
up                    down
FastEthernet0/0/2          unassigned      YES unset  
up                    down
FastEthernet0/0/3          unassigned      YES unset  
up                    down
Vlan1                            unassigned      YES NVRAM  
up                    down
*NVI0                            unassigned      NO  unset  
up                    up*
Virtual-Access1            unassigned      YES unset  
down                  down

Sincerely,
Tseveen.

From nuskov at mail.ru  Fri Jul  3 01:56:20 2009
From: nuskov at mail.ru (=?koi8-r?Q?=EE=C9=CB=C9=D4=C1__=F5=D3=CB=CF=D7?=)
Date: Fri, 03 Jul 2009 09:56:20 +0400
Subject: [c-nsp]
	=?koi8-r?b?W0JHUF0gTXVsdGlwbGUgcGVlcmluZyBzZXNzaW9ucyB3?=
	=?koi8-r?b?aXRoIHNhbWUgQVNOL3ByZWZpeGVzIHBvc3NpYmxlID8=?=
In-Reply-To: <49999c420907021848u14291c87icfaf22790111e4e4@mail.gmail.com>
References: <49999c420907021848u14291c87icfaf22790111e4e4@mail.gmail.com>
Message-ID: <E1MMbky-0003BH-00.nuskov-mail-ru@f138.mail.ru>

You can also use multipath command for load-balancing between two links and client's /24 net will be reachable through both links.

-----Original Message-----
From: cc loo <s00664233 at gmail.com>
To: cisco-nsp mailing list <cisco-nsp at puck.nether.net>
Date: Fri, 3 Jul 2009 09:48:51 +0800
Subject: [c-nsp] [BGP] Multiple peering sessions with same ASN/prefixes
possible ?

> Hi all,
> 
> my company's network has a peering connection with a client.
> Recently, they requested us to set up another concurrent peering link (for
> testing purposes).
> 
> The 2 BGP routers will be advertising the same ASN and prefixes.
> As i have limited knowledge in BGP, i wondered if such a set up would screw
> up the entire routing for this client ?
> 
> 
> Wouldnt my router be confused with 2 peers advertising the same prefixes ?
> How would it decide which peer to send to ?
> 
> Appreciate your kind advise. 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 swmike at swm.pp.se  Fri Jul  3 03:22:38 2009
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Fri, 3 Jul 2009 09:22:38 +0200 (CEST)
Subject: [c-nsp] Full BGP feed with DFC3A's
In-Reply-To: <622e99f30907030010p484e604cvbf22f876149b3379@mail.gmail.com>
References: <622e99f30907030010p484e604cvbf22f876149b3379@mail.gmail.com>
Message-ID: <alpine.DEB.1.10.0907030922050.15149@uplift.swm.pp.se>

On Fri, 3 Jul 2009, jack b wrote:

> I have a 6509 with a Sup7203BXL that has a few WS-X6816-GBIC with DFC3A's,
> its my understanding that it will select the lowest common denominator so
> the Sup is effectively running as a PFC3A. What would happen if I sent this
> device a full BGP feed?

Read the archives regarding full feed for Sup32. Basically it will 
cpu-switch traffic to some prefixes.

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

From ianh at chime.net.au  Fri Jul  3 02:55:23 2009
From: ianh at chime.net.au (Ian Henderson)
Date: Fri, 3 Jul 2009 14:55:23 +0800
Subject: [c-nsp] IOS XR BFD
In-Reply-To: <501de4ea0907022344o2d57271cob04635b8f8557b6f@mail.gmail.com>
References: <501de4ea0907022344o2d57271cob04635b8f8557b6f@mail.gmail.com>
Message-ID: <100362309621454DAA534950B17E55DB0116319951F1@isp-per-exc01.win2k.iinet.net.au>

Nick 'tarantul' Novikov wrote on 2009-07-03:

> The question arises, why IOS XR can't run BFD with internal BGP peers
> (as old school IOS)?

Because its assumed you're already using an IGP with which you can use it?


--
Ian Henderson, CCIE #14721
Senior Network Engineer, iiNet Limited



From achatz at forthnet.gr  Fri Jul  3 03:41:03 2009
From: achatz at forthnet.gr (Tassos Chatzithomaoglou)
Date: Fri, 03 Jul 2009 10:41:03 +0300
Subject: [c-nsp] sh ip interface brief
In-Reply-To: <4A4DA17F.1020608@gmail.com>
References: <4A4DA17F.1020608@gmail.com>
Message-ID: <4A4DB60F.7060703@forthnet.gr>

NVI = NAT Virtual Interface

http://www.cisco.com/en/US/docs/ios/12_3t/12_3t14/feature/guide/gtnatvi.html

-- 
Tassos


Tseveendorj wrote on 03/07/2009 09:13:
> Hello,
> 
> I have never seen interface named NVI0. What is this NVI0?
> 
> router#sh ip interface brief
> Interface                  IP-Address      OK? Method 
> Status                Protocol
> GigabitEthernet0/0         x.x.x.x   YES NVRAM  up                    up
> GigabitEthernet0/0.1       x.x.x.x    YES NVRAM  up                    up
> GigabitEthernet0/0.2       x.x.x.x    YES NVRAM  up                    up
> GigabitEthernet0/1         x.x.x.x  YES NVRAM  up                    up
> FastEthernet0/0/0          unassigned      YES unset  
> up                    down
> FastEthernet0/0/1          unassigned      YES unset  
> up                    down
> FastEthernet0/0/2          unassigned      YES unset  
> up                    down
> FastEthernet0/0/3          unassigned      YES unset  
> up                    down
> Vlan1                            unassigned      YES NVRAM  
> up                    down
> *NVI0                            unassigned      NO  unset  
> up                    up*
> Virtual-Access1            unassigned      YES unset  
> down                  down
> 
> 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/
> 

From pigsign.pykota at gmail.com  Fri Jul  3 03:58:59 2009
From: pigsign.pykota at gmail.com (Darren Yang)
Date: Fri, 3 Jul 2009 15:58:59 +0800
Subject: [c-nsp] Cisco PfR PIRO problems...
Message-ID: <c914c50e0907030058n2cfd45c0k75d9e515ead2b68b@mail.gmail.com>

Hi all,

I using Cisco 1812 and firmware version is
"c181x-adventerprisek9-mz.124-24.T.bin".
My problem is PfR that didn't use OSPF as parent route, it only accept
Static route as parent.

My PfR configuration is list below...
-----------------
oer master
 logging
 !
 border 192.168.1.2 key-chain GREEN

  interface Vlan2 internal
  interface Tunnel114 external
  interface Tunnel14 external
  interface Tunnel113 external
  interface Tunnel13 external
  interface Tunnel111 external
  interface Tunnel11 external
 !
 learn
  throughput
  delay
  periodic-interval 0
  monitor-period 1
  traffic-class filter access-list pfr-filter
  expire after time 5
  aggregation-type prefix-length 32
 backoff 90 3000
 mode route control
 mode monitor passive
 mode select-exit best
 periodic 180
 !
!
oer border
 logging
 local Vlan254
 master 192.168.1.2 key-chain GREEN
-----------------


Another I see debug information....
-------------
*Jul  3 07:34:45.291: %OER_BR-5-NOTICE: Prefix Learning STOPPED
*Jul  3 07:34:45.491: %OER_MC-5-NOTICE: Prefix Learning WRITING DATA
*Jul  3 07:34:45.555: %OER_MC-5-NOTICE: Prefix Learning STARTED
*Jul  3 07:34:45.555: %OER_BR-5-NOTICE: Prefix Learning STARTED
*Jul  3 07:34:29.367: PFR PIRO: Control Route, 10.11.1.16/32, NH
0.0.0.0, IF Tunnel11
*Jul  3 07:34:29.371: PFR PIRO: Control Route, 10.11.1.16/32, NH
0.0.0.0, IF Tunnel111
*Jul  3 07:34:29.371: %OER_MC-5-NOTICE: Uncontrol Prefix
10.11.1.16/32, Couldn't control
-------------

I don't know why PfR can't control that prefix...



Appreciate your kind advise. Thanks.

pigsign

From asturluismi at gmail.com  Fri Jul  3 04:21:39 2009
From: asturluismi at gmail.com (luismi)
Date: Fri, 03 Jul 2009 10:21:39 +0200
Subject: [c-nsp] Free NMS Tools
In-Reply-To: <4A4652C0.7010309@memetic.org>
References: <461308.822.qm@web76301.mail.sg1.yahoo.com>
	<4A4652C0.7010309@memetic.org>
Message-ID: <1246609299.7973.0.camel@dsba-ipso>

HMMM quite interesting...
We use here NMIS.

El s?b, 27-06-2009 a las 18:11 +0100, Adam Armstrong escribi?:
> > Dear All,
> >
> > Currently I looking for NMS ( Network Monitoring) tools which is Free Open source base.
> > I need you suggestion. Currently I have more then 100 Cisco Routers and some for L3 3com Switches. 
> >
> > I thank you in advanced for any sugesstion.
> >   
> JFFNMS, OpenNMS, Cacti, Nagios, Cricket and Weathermap are all are 
> useful bits of network management software.
> 
> I develop ObserverNMS (http://www.observernms.org) which I use here at 
> Jersey Telecom. I also use RANCID, NFSEN and Smokeping.
> 
> adam.
> _______________________________________________
> cisco-nsp mailing list  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  Fri Jul  3 05:08:24 2009
From: p.mayers at imperial.ac.uk (Phil Mayers)
Date: Fri, 03 Jul 2009 10:08:24 +0100
Subject: [c-nsp] Full BGP feed with DFC3A's
In-Reply-To: <622e99f30907030010p484e604cvbf22f876149b3379@mail.gmail.com>
References: <622e99f30907030010p484e604cvbf22f876149b3379@mail.gmail.com>
Message-ID: <4A4DCA88.2010506@imperial.ac.uk>

jack b wrote:
> I have a 6509 with a Sup7203BXL that has a few WS-X6816-GBIC with DFC3A's,
> its my understanding that it will select the lowest common denominator so
> the Sup is effectively running as a PFC3A. What would happen if I sent this
> device a full BGP feed?

It will fail, and software switch many prefixes.

From masood at nexlinx.net.pk  Fri Jul  3 06:29:02 2009
From: masood at nexlinx.net.pk (masood at nexlinx.net.pk)
Date: Fri, 3 Jul 2009 15:29:02 +0500 (PKT)
Subject: [c-nsp] sh ip interface brief
In-Reply-To: <4A4DA17F.1020608@gmail.com>
References: <4A4DA17F.1020608@gmail.com>
Message-ID: <54841.196.46.241.57.1246616942.squirrel@nexmail1.nexlinx.net.pk>

r u running NAT on ths box, if yes; NVI, usually used for NATing out of VFRs.

Regards,
Masood
Blog: http://weblogs.com.pk/jahil/


> Hello,
>
> I have never seen interface named NVI0. What is this NVI0?
>
> router#sh ip interface brief
> Interface                  IP-Address      OK? Method
> Status                Protocol
> GigabitEthernet0/0         x.x.x.x   YES NVRAM  up                    up
> GigabitEthernet0/0.1       x.x.x.x    YES NVRAM  up                    up
> GigabitEthernet0/0.2       x.x.x.x    YES NVRAM  up                    up
> GigabitEthernet0/1         x.x.x.x  YES NVRAM  up                    up
> FastEthernet0/0/0          unassigned      YES unset
> up                    down
> FastEthernet0/0/1          unassigned      YES unset
> up                    down
> FastEthernet0/0/2          unassigned      YES unset
> up                    down
> FastEthernet0/0/3          unassigned      YES unset
> up                    down
> Vlan1                            unassigned      YES NVRAM
> up                    down
> *NVI0                            unassigned      NO  unset
> up                    up*
> Virtual-Access1            unassigned      YES unset
> down                  down
>
> 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/
>



From joshua.eyres at gmail.com  Fri Jul  3 05:31:22 2009
From: joshua.eyres at gmail.com (Joshua Eyres)
Date: Fri, 3 Jul 2009 10:31:22 +0100
Subject: [c-nsp] Free NMS Tools
In-Reply-To: <c4a366d50907030221r14a4b6d0n84a13e66f91417c1@mail.gmail.com>
References: <c4a366d50907030221r14a4b6d0n84a13e66f91417c1@mail.gmail.com>
Message-ID: <c4a366d50907030231o405c212dj27987c6c55d5237e@mail.gmail.com>

We use ns4 (http://www.noodles.org.uk) and RANCID (http://www.shrubbery.net)
here.

Both tools work very well. However, we have recently been pushed to convert
these solutions to commercial ones as management feels they will get better
support if they pay for a solution...


> HMMM quite interesting...

> We use here NMIS.

From sam_mailinglists at spacething.org  Fri Jul  3 05:43:40 2009
From: sam_mailinglists at spacething.org (Sam Stickland)
Date: Fri, 03 Jul 2009 10:43:40 +0100
Subject: [c-nsp] WS-X6716-10G local switching and etherchanneling
In-Reply-To: <200907030320.n633K6Zx012286@sj-core-2.cisco.com>
References: <4A4C9C40.6030804@spacething.org>
	<200907030320.n633K6Zx012286@sj-core-2.cisco.com>
Message-ID: <4A4DD2CC.1010806@spacething.org>

Thanks the reply Tim,

Are the port's similarly oversubscribed on the 6708, or can line-rate be 
achieved between ports 1-4 & 5-6?

Sam

Tim Stevenson wrote:
> Sam, please see inline below:
>
> At 04:38 AM 7/2/2009, Sam Stickland contended:
>
>> Hi,
>>
>> I've read:
>> http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod_white_paper0900aecd80673385.html 
>>
>>
>> If I'm understanding this correctly, 
>
> I don't see any mention of 6716 in this white paper. 6716 does not 
> share the same architecture as any other 10G cards (eg 6708) mentioned 
> there. 6716 is actually more like a 6704 front ended by 4:1 muxes (at 
> a high level - in reality, different chips are being used, ie, metro & 
> r2d2 et al, not janus & rohini).
>
>> communication between each bank of
>> 8 ports on a 6716-10G will be line-rate, but communication between the
>> first and second groups of 8 ports will need to traverse the switch 
>> fabric?
>
> While it's correct that ports 1-8 & 9-16 are on separate fabric 
> channels, the key in the 6716 is that there is built-in *port-based* 
> 4:1 oversubscription.
>
> In other words, 4 physical 10G ports feed into a single 10G chip 
> (there are 4 such 10G chips on the card), ie, 4 ports share 10G of 
> bandwidth at the port level.
>
> So the maximum local switching performance you'd see in one half of 
> the card is 20G, the same as you'd get into the fabric.
>
>> On a similar note, if I create an etherchannel between two 6716-10G's
>> will a module favour forwarding out of it's locally attached channel 
>> member?
>
> No, it's just a hash decision - luck of the draw. Eg, packet comes in 
> on t1/1 and channel member ports are t1/5 and t2/5. You've basically 
> got a 50/50 chance that you'd pass over the fabric.
>
> HTH,
> Tim
>
>
>
>> 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/
>
>
>
> Tim Stevenson, tstevens at cisco.com
> Routing & Switching CCIE #5561
> Technical Marketing Engineer, Cisco Nexus 7000
> Cisco - http://www.cisco.com
> <http://www.cisco.com/>IP Phone: 408-526-6759
> ********************************************************
> The contents of this message may be *Cisco Confidential*
> and are intended for the specified recipients only.
>


From marco at linuxgoeroe.dhs.org  Fri Jul  3 05:27:51 2009
From: marco at linuxgoeroe.dhs.org (Marco van den Bovenkamp)
Date: Fri, 03 Jul 2009 11:27:51 +0200
Subject: [c-nsp] Full BGP feed with DFC3A's
In-Reply-To: <4A4DCA88.2010506@imperial.ac.uk>
References: <622e99f30907030010p484e604cvbf22f876149b3379@mail.gmail.com>
	<4A4DCA88.2010506@imperial.ac.uk>
Message-ID: <4A4DCF17.2060406@linuxgoeroe.dhs.org>

Phil Mayers wrote:

> jack b wrote:
>> I have a 6509 with a Sup7203BXL that has a few WS-X6816-GBIC with 
>> DFC3A's,
>> its my understanding that it will select the lowest common denominator so
>> the Sup is effectively running as a PFC3A. What would happen if I sent 
>> this
>> device a full BGP feed?
> 
> It will fail, and software switch many prefixes.

If you're lucky, that is. That's what's supposed to happen, but I have 
run into this (Sup720non-XL with full feed overflowing the TCAM) and Odd 
Things happened. Packets that took paths both the routing table and CEF 
FIB said they shouldn't, stuff like that.

Be afraid, be very afraid...

		Regards,

			Marco.

From bogdan at constanta.rdsnet.ro  Fri Jul  3 05:08:32 2009
From: bogdan at constanta.rdsnet.ro (Bogdan Radulescu)
Date: Fri, 03 Jul 2009 12:08:32 +0300
Subject: [c-nsp] Cisco Local Area Mobility - (LAM)
Message-ID: <4A4DCA90.3010200@constanta.rdsnet.ro>

Hello all,

I'm trying to use LAM on the following topology without much luck...

V100left---|3560G|---p-t-pL3link--|6500|---l2link--|7600|--V100right

V100left = SVI = 172.16.224.0/19
V100right = SVI = 192.168.224.0/19
V100right just random subnet, no clients
7600#interface Vlan100
         ip address 192.168.224.1 255.255.0.0
         ip mobile arp timers 1 1
        end

Between 6500 and 7600 i have a dynamic routing protocol and 6500 
announces V100left into BGP.
6500 has a static route for V100left to 3560G.
Connected to 7600 there is a server on V150 that needs to "talk" with 
these "clients"
Clients don't need to talk to each other.

I would like to move clients from V100 left to V100 right. I don't want 
to change ip addresses.
V100left will be moved when all clients move to the right.

It looks like 7600 detects the foreign ip on it's interface V100right, 
but doesn't put a "mobile" route for it.
All i can see is this:
--------------------------------
Local MobileIP: aging arp mobility cache entries
Local MobileIP: aging arp entry 172.16.225.153 60028 60000 60000
Local MobileIP: Vlan100 add 172.16.225.153 accepted
Local MobileIP: Vlan100 add 172.16.225.153 accepted
Local MobileIP: Vlan100 add 172.16.225.153 accepted
----------------------------------
7600#sh arp vlan 100 detail
ARP entry for 172.16.225.153, link type IP.
  Simple Application, via Vlan100, last updated 0 minute ago.
  Created by "IP Mobility".
  Encap type is ARPA, hardware address is 0006.1901.2925, 6 bytes long.
  ARP subblocks:
  * Application Simple ARP Subblock
    Entry is complete.
  * IP ARP Adjacency
    Adjacency (for 172.16.225.153 on Vlan100) was installed.
  * IP Mobility
    ARP Application entry for application IP Mobility.
  * IP ARP VLAN ID
    Subblock data size is 4 bytes.
    VLAN IN ID: 100
    VLAN OUT ID: 100
------------------------------------------
7600#sh ip route | i 172.16.225.153
*?        172.16.225.153/32 [0/1] via 172.16.225.153*
------------------------------------------
sh ip route 172.16.225.153
Routing entry for 172.16.225.153/32
  Known via "connected", distance 0, metric 1
  Last update from 172.16.225.153 00:41:57 ago
  Routing Descriptor Blocks:
  * 172.16.225.153
      Route metric is 1, traffic share count is 1
------------------------------------------

debug ip packet detail gives me this

Jul  2 23:32:19: FIBipv4-packet-proc: route packet from (local) src 
172.16.0.1 dst 172.16.225.153
Jul  2 23:32:19: FIBfwd-proc: Default:172.16.225.153/32 proces level 
forwarding
Jul  2 23:32:19: FIBfwd-proc: depth 0 first_idx 0 paths 1 long 0(0)
Jul  2 23:32:19: FIBfwd-proc: try path 0 (of 1) v4-rcrsv-172.16.225.153 
first short ext 0(-1)
Jul  2 23:32:19: FIBfwd-proc: v4-rcrsv-172.16.225.153 valid
Jul  2 23:32:19: FIBfwd-proc: ip_pak_table 0 ip_nh_table 0 if none nh 
172.16.225.153 deag 0 via fib 0 path type recursive
Jul  2 23:32:19: FIBfwd-proc: Default:172.16.225.153/32 not enough info 
to forward via fib (none 172.16.225.153)
Jul  2 23:32:19: FIBipv4-packet-proc: packet routing failed
Jul  2 23:32:19: IP: s=172.16.0.1 (local), d=172.16.225.153, len 100, 
unroutable
Jul  2 23:32:19:     ICMP type=8, code=0

On the same 7600 i have several other VLANs with subnets from  
172.16.0.0/16 and some
L3 interfaces part of other VRFs


Is what i want possible or i\m wasting my time and yours? :)

Thank you









-- 
...................................

Bogdan Radulescu



From robert at tellurian.com  Fri Jul  3 05:28:02 2009
From: robert at tellurian.com (Robert Boyle)
Date: Fri, 03 Jul 2009 05:28:02 -0400
Subject: [c-nsp] IOS XR BFD
In-Reply-To: <100362309621454DAA534950B17E55DB0116319951F1@isp-per-exc01
	.win2k.iinet.net.au>
References: <501de4ea0907022344o2d57271cob04635b8f8557b6f@mail.gmail.com>
	<100362309621454DAA534950B17E55DB0116319951F1@isp-per-exc01.win2k.iinet.net.au>
Message-ID: <1246613652_586037@mail1.tellurian.net>

At 02:55 AM 7/3/2009, Ian Henderson wrote:
>Nick 'tarantul' Novikov wrote on 2009-07-03:
>
> > The question arises, why IOS XR can't run BFD with internal BGP peers
> > (as old school IOS)?
>
>Because its assumed you're already using an IGP with which you can use it?

What about those of us who use BGP as our IGP? I'm sure that customer 
pressure will eventually lead Cisco to put that back into the code. 
We use BFD and BGP internally and (obviously) BGP externally.

-R



Tellurian Networks - A Perot Systems Company
http://www.tellurian.com | 888-TELLURIAN | 973-300-9211
"Well done is better than well said." - Benjamin Franklin


From achatz at forthnet.gr  Fri Jul  3 06:32:07 2009
From: achatz at forthnet.gr (Tassos Chatzithomaoglou)
Date: Fri, 03 Jul 2009 13:32:07 +0300
Subject: [c-nsp] Cisco Local Area Mobility - (LAM)
In-Reply-To: <4A4DCA90.3010200@constanta.rdsnet.ro>
References: <4A4DCA90.3010200@constanta.rdsnet.ro>
Message-ID: <4A4DDE27.8090706@forthnet.gr>

Do you have the global "router mobile" configured?

--
Tassos

Bogdan Radulescu wrote on 03/07/2009 12:08:
> Hello all,
> 
> I'm trying to use LAM on the following topology without much luck...
> 
> V100left---|3560G|---p-t-pL3link--|6500|---l2link--|7600|--V100right
> 
> V100left = SVI = 172.16.224.0/19
> V100right = SVI = 192.168.224.0/19
> V100right just random subnet, no clients
> 7600#interface Vlan100
>         ip address 192.168.224.1 255.255.0.0
>         ip mobile arp timers 1 1
>        end
> 
> Between 6500 and 7600 i have a dynamic routing protocol and 6500 
> announces V100left into BGP.
> 6500 has a static route for V100left to 3560G.
> Connected to 7600 there is a server on V150 that needs to "talk" with 
> these "clients"
> Clients don't need to talk to each other.
> 
> I would like to move clients from V100 left to V100 right. I don't want 
> to change ip addresses.
> V100left will be moved when all clients move to the right.
> 
> It looks like 7600 detects the foreign ip on it's interface V100right, 
> but doesn't put a "mobile" route for it.
> All i can see is this:
> --------------------------------
> Local MobileIP: aging arp mobility cache entries
> Local MobileIP: aging arp entry 172.16.225.153 60028 60000 60000
> Local MobileIP: Vlan100 add 172.16.225.153 accepted
> Local MobileIP: Vlan100 add 172.16.225.153 accepted
> Local MobileIP: Vlan100 add 172.16.225.153 accepted
> ----------------------------------
> 7600#sh arp vlan 100 detail
> ARP entry for 172.16.225.153, link type IP.
>  Simple Application, via Vlan100, last updated 0 minute ago.
>  Created by "IP Mobility".
>  Encap type is ARPA, hardware address is 0006.1901.2925, 6 bytes long.
>  ARP subblocks:
>  * Application Simple ARP Subblock
>    Entry is complete.
>  * IP ARP Adjacency
>    Adjacency (for 172.16.225.153 on Vlan100) was installed.
>  * IP Mobility
>    ARP Application entry for application IP Mobility.
>  * IP ARP VLAN ID
>    Subblock data size is 4 bytes.
>    VLAN IN ID: 100
>    VLAN OUT ID: 100
> ------------------------------------------
> 7600#sh ip route | i 172.16.225.153
> *?        172.16.225.153/32 [0/1] via 172.16.225.153*
> ------------------------------------------
> sh ip route 172.16.225.153
> Routing entry for 172.16.225.153/32
>  Known via "connected", distance 0, metric 1
>  Last update from 172.16.225.153 00:41:57 ago
>  Routing Descriptor Blocks:
>  * 172.16.225.153
>      Route metric is 1, traffic share count is 1
> ------------------------------------------
> 
> debug ip packet detail gives me this
> 
> Jul  2 23:32:19: FIBipv4-packet-proc: route packet from (local) src 
> 172.16.0.1 dst 172.16.225.153
> Jul  2 23:32:19: FIBfwd-proc: Default:172.16.225.153/32 proces level 
> forwarding
> Jul  2 23:32:19: FIBfwd-proc: depth 0 first_idx 0 paths 1 long 0(0)
> Jul  2 23:32:19: FIBfwd-proc: try path 0 (of 1) v4-rcrsv-172.16.225.153 
> first short ext 0(-1)
> Jul  2 23:32:19: FIBfwd-proc: v4-rcrsv-172.16.225.153 valid
> Jul  2 23:32:19: FIBfwd-proc: ip_pak_table 0 ip_nh_table 0 if none nh 
> 172.16.225.153 deag 0 via fib 0 path type recursive
> Jul  2 23:32:19: FIBfwd-proc: Default:172.16.225.153/32 not enough info 
> to forward via fib (none 172.16.225.153)
> Jul  2 23:32:19: FIBipv4-packet-proc: packet routing failed
> Jul  2 23:32:19: IP: s=172.16.0.1 (local), d=172.16.225.153, len 100, 
> unroutable
> Jul  2 23:32:19:     ICMP type=8, code=0
> 
> On the same 7600 i have several other VLANs with subnets from  
> 172.16.0.0/16 and some
> L3 interfaces part of other VRFs
> 
> 
> Is what i want possible or i\m wasting my time and yours? :)
> 
> Thank you
> 
> 
> 
> 
> 
> 
> 
> 
> 

From A.L.M.Buxey at lboro.ac.uk  Fri Jul  3 06:46:12 2009
From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk)
Date: Fri, 3 Jul 2009 11:46:12 +0100
Subject: [c-nsp] Free NMS Tools
In-Reply-To: <c4a366d50907030231o405c212dj27987c6c55d5237e@mail.gmail.com>
References: <c4a366d50907030221r14a4b6d0n84a13e66f91417c1@mail.gmail.com>
	<c4a366d50907030231o405c212dj27987c6c55d5237e@mail.gmail.com>
Message-ID: <20090703104612.GC28810@lboro.ac.uk>

Hi,

> Both tools work very well. However, we have recently been pushed to convert
> these solutions to commercial ones as management feels they will get better
> support if they pay for a solution...

absolute rubbish. they should stick with their job and let you
do your job which is ensuring that you have the tools
you need to do yours. i've used several commercial toolls
and not only have they failed on basic things (like
actually finding all the devices on the network even when given
seeding addresses) but they also cannot be modified/enhanced
one evening when you feel like adding a new feature...lets say
adding a few new buttons on the web interface to allow SSH'ing to
the router on hat page.

commercial solution? put in a request...hope it aligns with their
idea of their product (or maybe you pay enough money to get
their attention)..

if networking was based on purely commercial/proprietary tools
then there'd be no internet, no web, no social network sites

alan

From dean at eatworms.org.uk  Fri Jul  3 06:55:20 2009
From: dean at eatworms.org.uk (Dean Smith)
Date: Fri, 3 Jul 2009 11:55:20 +0100
Subject: [c-nsp] Free NMS Tools
Message-ID: <F1755DA0C92B4B0F8EEA558869BD8D1B@experienbd1776>



 On occasion I've had to essentially out-source the provision of open source 
tools to a local Linux/Unix consultancy.

-I get the tools I need - with some very good people to tweak them on demand
 -Management pay a re-assuringly expensive bill to have someone to shout at 
if the tools break (which they rarely do)

Daft....but its a living.

Dean

> ----- Original Message ----- 
> From: <A.L.M.Buxey at lboro.ac.uk>
> To: "Joshua Eyres" <joshua.eyres at gmail.com>
> Cc: <cisco-nsp at puck.nether.net>
> Sent: Friday, July 03, 2009 11:46 AM
> Subject: Re: [c-nsp] Free NMS Tools
>
>
>> Hi,
>>
>>> Both tools work very well. However, we have recently been pushed to 
>>> convert
>>> these solutions to commercial ones as management feels they will get 
>>> better
>>> support if they pay for a solution...
>>
>> absolute rubbish. they should stick with their job and let you
>> do your job which is ensuring that you have the tools
>> you need to do yours. i've used several commercial toolls
>> and not only have they failed on basic things (like
>> actually finding all the devices on the network even when given
>> seeding addresses) but they also cannot be modified/enhanced
>> one evening when you feel like adding a new feature...lets say
>> adding a few new buttons on the web interface to allow SSH'ing to
>> the router on hat page.
>>
>> commercial solution? put in a request...hope it aligns with their
>> idea of their product (or maybe you pay enough money to get
>> their attention)..
>>
>> if networking was based on purely commercial/proprietary tools
>> then there'd be no internet, no web, no social network sites
>>
>> 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/
>>
>> __________ NOD32 4212 (20090703) Information __________
>>
>> This message was checked by NOD32 antivirus system.
>> http://www.eset.com
>>
>>
> 


From jesus_leung at ahm.honda.com  Fri Jul  3 07:05:49 2009
From: jesus_leung at ahm.honda.com (jesus_leung at ahm.honda.com)
Date: Fri, 3 Jul 2009 04:05:49 -0700
Subject: [c-nsp] CN=Jesus Leung/OU=AHM/OU=AM/O=HONDA is out of the office.
Message-ID: <OF98C7FB8C.8BF7ADD8-ON882575E8.003CF531-882575E8.003CF533@ahm.honda.com>


I will be out of the office starting  07/03/2009 and will not return until
07/09/2009.



From bogdan at constanta.rdsnet.ro  Fri Jul  3 07:32:52 2009
From: bogdan at constanta.rdsnet.ro (Bogdan Radulescu)
Date: Fri, 03 Jul 2009 14:32:52 +0300
Subject: [c-nsp] Cisco Local Area Mobility - (LAM)
In-Reply-To: <4A4DDE27.8090706@forthnet.gr>
References: <4A4DCA90.3010200@constanta.rdsnet.ro>
	<4A4DDE27.8090706@forthnet.gr>
Message-ID: <4A4DEC64.90503@constanta.rdsnet.ro>

No. afaik i dont need it. (although I've tried it)
I've tested this with dyna and real switches, the same logical topology 
and it works as expected.


Tassos Chatzithomaoglou wrote:
> Do you have the global "router mobile" configured?
>
> -- 
> Tassos
>
> Bogdan Radulescu wrote on 03/07/2009 12:08:
>> Hello all,
>>
>> I'm trying to use LAM on the following topology without much luck...
>>
>> V100left---|3560G|---p-t-pL3link--|6500|---l2link--|7600|--V100right
>>
>> V100left = SVI = 172.16.224.0/19
>> V100right = SVI = 192.168.224.0/19
>> V100right just random subnet, no clients
>> 7600#interface Vlan100
>>         ip address 192.168.224.1 255.255.0.0
>>         ip mobile arp timers 1 1
>>        end
>>
>> Between 6500 and 7600 i have a dynamic routing protocol and 6500 
>> announces V100left into BGP.
>> 6500 has a static route for V100left to 3560G.
>> Connected to 7600 there is a server on V150 that needs to "talk" with 
>> these "clients"
>> Clients don't need to talk to each other.
>>
>> I would like to move clients from V100 left to V100 right. I don't 
>> want to change ip addresses.
>> V100left will be moved when all clients move to the right.
>>
>> It looks like 7600 detects the foreign ip on it's interface 
>> V100right, but doesn't put a "mobile" route for it.
>> All i can see is this:
>> --------------------------------
>> Local MobileIP: aging arp mobility cache entries
>> Local MobileIP: aging arp entry 172.16.225.153 60028 60000 60000
>> Local MobileIP: Vlan100 add 172.16.225.153 accepted
>> Local MobileIP: Vlan100 add 172.16.225.153 accepted
>> Local MobileIP: Vlan100 add 172.16.225.153 accepted
>> ----------------------------------
>> 7600#sh arp vlan 100 detail
>> ARP entry for 172.16.225.153, link type IP.
>>  Simple Application, via Vlan100, last updated 0 minute ago.
>>  Created by "IP Mobility".
>>  Encap type is ARPA, hardware address is 0006.1901.2925, 6 bytes long.
>>  ARP subblocks:
>>  * Application Simple ARP Subblock
>>    Entry is complete.
>>  * IP ARP Adjacency
>>    Adjacency (for 172.16.225.153 on Vlan100) was installed.
>>  * IP Mobility
>>    ARP Application entry for application IP Mobility.
>>  * IP ARP VLAN ID
>>    Subblock data size is 4 bytes.
>>    VLAN IN ID: 100
>>    VLAN OUT ID: 100
>> ------------------------------------------
>> 7600#sh ip route | i 172.16.225.153
>> *?        172.16.225.153/32 [0/1] via 172.16.225.153*
>> ------------------------------------------
>> sh ip route 172.16.225.153
>> Routing entry for 172.16.225.153/32
>>  Known via "connected", distance 0, metric 1
>>  Last update from 172.16.225.153 00:41:57 ago
>>  Routing Descriptor Blocks:
>>  * 172.16.225.153
>>      Route metric is 1, traffic share count is 1
>> ------------------------------------------
>>
>> debug ip packet detail gives me this
>>
>> Jul  2 23:32:19: FIBipv4-packet-proc: route packet from (local) src 
>> 172.16.0.1 dst 172.16.225.153
>> Jul  2 23:32:19: FIBfwd-proc: Default:172.16.225.153/32 proces level 
>> forwarding
>> Jul  2 23:32:19: FIBfwd-proc: depth 0 first_idx 0 paths 1 long 0(0)
>> Jul  2 23:32:19: FIBfwd-proc: try path 0 (of 1) 
>> v4-rcrsv-172.16.225.153 first short ext 0(-1)
>> Jul  2 23:32:19: FIBfwd-proc: v4-rcrsv-172.16.225.153 valid
>> Jul  2 23:32:19: FIBfwd-proc: ip_pak_table 0 ip_nh_table 0 if none nh 
>> 172.16.225.153 deag 0 via fib 0 path type recursive
>> Jul  2 23:32:19: FIBfwd-proc: Default:172.16.225.153/32 not enough 
>> info to forward via fib (none 172.16.225.153)
>> Jul  2 23:32:19: FIBipv4-packet-proc: packet routing failed
>> Jul  2 23:32:19: IP: s=172.16.0.1 (local), d=172.16.225.153, len 100, 
>> unroutable
>> Jul  2 23:32:19:     ICMP type=8, code=0
>>
>> On the same 7600 i have several other VLANs with subnets from  
>> 172.16.0.0/16 and some
>> L3 interfaces part of other VRFs
>>
>>
>> Is what i want possible or i\m wasting my time and yours? :)
>>
>> 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/
>
>

-- 
...................................

Bogdan Radulescu

IP Backbone Engineer
RCS & RDS Constanta
Phone: +40 341-400440
Fax  : +40 341-400450

E-mail: bogdan at constanta.rdsnet.ro
...................................

Privileged/Confidential Information may be contained in this message.
If you are not the addressee indicated in this message (or responsible
for delivery of the message to such person), you may not copy or deliver
this message to anyone. In such a case, you should destroy this message
and kindly notify the sender by reply e-mail. 


From spinthiras.mario at gmail.com  Fri Jul  3 09:00:27 2009
From: spinthiras.mario at gmail.com (Mario Spinthiras)
Date: Fri, 3 Jul 2009 14:00:27 +0100
Subject: [c-nsp] Free NMS Tools
In-Reply-To: <F1755DA0C92B4B0F8EEA558869BD8D1B@experienbd1776>
References: <F1755DA0C92B4B0F8EEA558869BD8D1B@experienbd1776>
Message-ID: <4f890e580907030600y3f8e6c15qfa6c4b4db539fec@mail.gmail.com>

I would say Zenoss is looking good because of the inventory management you
can do and because of the logical structure it puts everything in. I wrote
an old dusty article a long long time ago on NMSs , maybe you can take a
peak.
http://www.spinthiras.org/2008/07/network-monitoring/

Everything else just seems inadequate or poor.

And for goodness sake don't put nagios because it will take ages to
configure :)


Mario.

From nicolasleiva at gmail.com  Fri Jul  3 11:24:41 2009
From: nicolasleiva at gmail.com (=?ISO-8859-1?Q?Nicol=E1s_Leiva?=)
Date: Fri, 3 Jul 2009 11:24:41 -0400
Subject: [c-nsp] PIM-SM - Configuring join/prune message interval
Message-ID: <13a807350907030824j68f087dal3e652507b0c81a9d@mail.gmail.com>

Hi,

How can I configure the periodic PIM?s join/prune message interval on IOS
12.2 or later?. ip pim message-interval would do the trick on 12.1, but it
does not seem to be supported on 12.2 nor found info on DocCD for later
releases. Is it that changing the 60 seconds default make no much sense?.
What am I missing?

Please advice,

Nicol?s

From dudepron at gmail.com  Fri Jul  3 12:28:31 2009
From: dudepron at gmail.com (Aaron)
Date: Fri, 3 Jul 2009 12:28:31 -0400
Subject: [c-nsp] IOS XR BFD
In-Reply-To: <1246613652_586037@mail1.tellurian.net>
References: <501de4ea0907022344o2d57271cob04635b8f8557b6f@mail.gmail.com> 
	<100362309621454DAA534950B17E55DB0116319951F1@isp-per-exc01.win2k.iinet.net.au>
	<1246613652_586037@mail1.tellurian.net>
Message-ID: <480dad640907030928g409fb93cle53eca875bae3c31@mail.gmail.com>

You must be using something else besides BGP. You need static, RIP, IGRP,
EIGRP, ISIS, or OSPF to get your routes into the table. BGP cannot do it
alone.

On Fri, Jul 3, 2009 at 05:28, Robert Boyle <robert at tellurian.com> wrote:

> At 02:55 AM 7/3/2009, Ian Henderson wrote:
>
>> Nick 'tarantul' Novikov wrote on 2009-07-03:
>>
>> > The question arises, why IOS XR can't run BFD with internal BGP peers
>> > (as old school IOS)?
>>
>> Because its assumed you're already using an IGP with which you can use it?
>>
>
> What about those of us who use BGP as our IGP? I'm sure that customer
> pressure will eventually lead Cisco to put that back into the code. We use
> BFD and BGP internally and (obviously) BGP externally.
>
> -R
>
>
>
> Tellurian Networks - A Perot Systems Company
> http://www.tellurian.com | 888-TELLURIAN | 973-300-9211
> "Well done is better than well said." - Benjamin Franklin
>
>
> _______________________________________________
> cisco-nsp mailing list  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  Fri Jul  3 13:01:00 2009
From: achatz at forthnet.gr (Tassos Chatzithomaoglou)
Date: Fri, 03 Jul 2009 20:01:00 +0300
Subject: [c-nsp] PIM-SM - Configuring join/prune message interval
In-Reply-To: <13a807350907030824j68f087dal3e652507b0c81a9d@mail.gmail.com>
References: <13a807350907030824j68f087dal3e652507b0c81a9d@mail.gmail.com>
Message-ID: <4A4E394C.6010801@forthnet.gr>

You don't need this command. Check CSCej32303.

Tassos

Nicola's Leiva wrote on 03/07/2009 18:24:
> Hi,
> 
> How can I configure the periodic PIM?s join/prune message interval on IOS
> 12.2 or later?. ip pim message-interval would do the trick on 12.1, but it
> does not seem to be supported on 12.2 nor found info on DocCD for later
> releases. Is it that changing the 60 seconds default make no much sense?.
> What am I missing?
> 
> Please advice,
> 
> Nicola's
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 


From jared at puck.nether.net  Fri Jul  3 13:09:43 2009
From: jared at puck.nether.net (Jared Mauch)
Date: Fri, 3 Jul 2009 13:09:43 -0400
Subject: [c-nsp] Free NMS Tools
In-Reply-To: <c4a366d50907030231o405c212dj27987c6c55d5237e@mail.gmail.com>
References: <c4a366d50907030221r14a4b6d0n84a13e66f91417c1@mail.gmail.com>
	<c4a366d50907030231o405c212dj27987c6c55d5237e@mail.gmail.com>
Message-ID: <993AC75C-0B40-4D5F-9694-FB8B01BE42D7@puck.nether.net>


On Jul 3, 2009, at 5:31 AM, Joshua Eyres wrote:

> We use ns4 (http://www.noodles.org.uk) and RANCID (http://www.shrubbery.net 
> )
> here.
>
> Both tools work very well. However, we have recently been pushed to  
> convert
> these solutions to commercial ones as management feels they will get  
> better
> support if they pay for a solution...

I seem to recall that you can get consulting services/support for  
RANCID from the author(s).

	- Jared

From marc at sniff.de  Fri Jul  3 12:39:24 2009
From: marc at sniff.de (Marc Binderberger)
Date: Fri, 3 Jul 2009 12:39:24 -0400
Subject: [c-nsp] IOS XR BFD
In-Reply-To: <501de4ea0907022344o2d57271cob04635b8f8557b6f@mail.gmail.com>
References: <501de4ea0907022344o2d57271cob04635b8f8557b6f@mail.gmail.com>
Message-ID: <1C808F8D-3295-4286-AAD2-F8FDA3C5AC48@sniff.de>

Hello Nick,

IOS-XR BFD does not support multihop yet, I think that's the reason  
they do not support iBGP.

If you think about iBGP between directly connected peers: have you  
tried it? The documentation may not cover this special case.


Regards, Marc


On 3-Jul-09, at 2:44 AM, Nick 'tarantul' Novikov wrote:

> Hola, amigos!
> In the documentation about "Configuring Bidirectional Forwarding
> Detection on Cisco IOS XR" cisco writes:
> "BFD is supported on IPv4 directly connected external BGP peers."
> The question arises, why IOS XR can't run BFD with internal BGP peers
> (as old school IOS)?
>
> -- 
> tarantul
> Dios es Amor
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

--
Marc Binderberger           <marc at sniff.de>


From tim at selfnet.de  Fri Jul  3 13:13:15 2009
From: tim at selfnet.de (Tim)
Date: Fri, 03 Jul 2009 19:13:15 +0200
Subject: [c-nsp] [c3560g] Not in truth table when modyfing ACL
In-Reply-To: <383357750906290817x6eb1acf8nb12c457d44b89f88@mail.gmail.com>
References: <383357750906290817x6eb1acf8nb12c457d44b89f88@mail.gmail.com>
Message-ID: <4A4E3C2B.10203@selfnet.de>

Hi,

Mateusz Blaszczyk wrote:
> This error message shows up every now end then when adding or modyfing
> an ACL (with or without access-group config on the SVI):
> 
> Jun  4 03:33:23.347: %ACLMGR-3-INTTABLE: Not in truth table: VLMAP 9
> RACL 9 Rtprot 9 Mcb 13 Feat 3
> Jun  4 03:33:23.347: %ACLMGR-3-INTTABLE: Not in truth table: VLMAP 9
> RACL 9 Rtprot 9 Mcb 13 Feat 3
> Jun  4 03:33:23.355: %ACLMGR-3-INTTABLE: Not in truth table: VLMAP 9
> RACL 9 Rtprot 9 Mcb 13 Feat 3
> Jun  4 03:33:23.355: %ACLMGR-3-INTTABLE: Not in truth table: VLMAP 9
> RACL 9 Rtprot 9 Mcb 13 Feat 3
> 
> Can anyone tell me what is the severity of that problem? google is
> quite quiet apart from link to cisco's error messages list, which is
> not really helpful.

I am getting this on several C3750G, but only with inbound ACLs.  Beside
the error messages, there is indeed a big impact:  the router will
(sometimes) drop IP packets with a destination IP address located on the
interface (e.g., a BGP session - the BGP session will NOT come up
again).  Transit traffic were not affected.  I can reproduce the error
in my Lab.

I decided to downgrade to 12.2(46)SE, because I need the BGP sessions...

But maybe someone found a solution and/or knows, that Cisco will fix it
(soon)?

Regards,
	Tim
####################

For the sake of completeness my setup:

IP Service 12.2(50)SE and 12.2(50)SE2
  on a WS-C3750G-12S-S and WS-C3750G-24TS-S

%ACLMGR-3-INTTABLE: Not in truth table: VLMAP 9 RACL 9 Rtprot 9 Mcb 13
Feat 3

When I configure an ACL inbound on a routed interface, the Router
throws this error message.

Also, the router will (sometimes) drop IP packets with a destination IP
address located on the router (e.g., a BGP session).

Transit traffic is - as far as I can see - not affected.

I can reproduce the error.  With the older IP Advanced Service
12.2(46)SE it works fine.

Setup (IP addresses were anonymised):
              Gi1/0/12
C3750G-12S-S --------------------------- Uplink Provider
 |            2.0.0.1/30     2.0.0.2/30
 |
1.16.0.0/16

Config snips:

router bgp 65454
 bgp router-id 2.0.1.1
 bgp log-neighbor-changes
 neighbor 2.0.0.2 remote-as 65000
 neighbor 2.0.0.2 transport path-mtu-discovery
 !
 address-family ipv4
  neighbor 2.0.0.2 activate
  neighbor 2.0.0.2 soft-reconfiguration inbound
  neighbor 2.0.0.2 prefix-list from-UPLINK in
  neighbor 2.0.0.2 distribute-list 10 out
  no auto-summary
  no synchronization
  network 1.16.0.0 mask 255.255.0.0
 exit-address-family
!
interface GigabitEthernet1/0/12
 description Uplink
 no switchport
 ip address 2.0.0.1 255.255.255.252
 ip access-group uplink-inbound in
 ip access-group uplink-outbound out
 no cdp enable
 spanning-tree portfast
!
ip access-list extended uplink-inbound
 deny   ip 127.0.0.0 0.255.255.255 any
 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
 permit ip any 2.0.0.0 0.0.0.3
 permit ip any 1.16.0.0 0.0.255.255
!
ip access-list extended uplink-outbound
 deny   ip any 127.0.0.0 0.255.255.255
 deny   ip any 10.0.0.0 0.255.255.255
 deny   ip any 172.16.0.0 0.15.255.255
 deny   ip any 192.168.0.0 0.0.255.255
 permit ip 2.0.0.0 0.0.0.3 any
 permit ip 1.16.0.0 0.0.255.255 any
!

It only affects the inbound ACL, example log output:

Jul  3 12:31:14: %PARSER-5-CFGLOG_LOGGEDCMD: User:tim  logged
command:interface GigabitEthernet1/0/28
Jul  3 12:31:20: %PARSER-5-CFGLOG_LOGGEDCMD: User:tim  logged command:ip
access-group uplink-inbound in
Jul  3 12:31:20: %ACLMGR-3-INTTABLE: Not in truth table: VLMAP 9 RACL 9
Rtprot 9 Mcb 13 Feat 3
Jul  3 12:31:20: %ACLMGR-3-INTTABLE: Not in truth table: VLMAP 9 RACL 9
Rtprot 9 Mcb 13 Feat 3

The error message comes also with an ACL, which does not exist:

Jul  3 12:32:45: %PARSER-5-CFGLOG_LOGGEDCMD: User:tim  logged command:ip
access-group doesnotexists in
Jul  3 12:32:45: %ACLMGR-3-INTTABLE: Not in truth table: VLMAP 9 RACL 9
Rtprot 9 Mcb 13 Feat 3
Jul  3 12:32:45: %ACLMGR-3-INTTABLE: Not in truth table: VLMAP 9 RACL 9
Rtprot 9 Mcb 13 Feat 3


The only statement from Cisco says:
"""
Explanation    An unrecoverable software error occurred while trying to
merge the configured input features. [dec] are internal action codes.
""" [1]

Also, the "Output Interpreter" does not help.  And the "Bug Toolkit"
does not show any bug.

[1]
http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_25_see/system/message/msg_desc.html




From jcartier at acs.on.ca  Fri Jul  3 15:54:29 2009
From: jcartier at acs.on.ca (Jeff Cartier)
Date: Fri, 3 Jul 2009 15:54:29 -0400
Subject: [c-nsp] Nat Question
Message-ID: <BCD3E762F1767C42A5226BBACDE49BFBED831A@loki.acs.local>

Here's the scenario...

 

I have a Cisco 1800ISR already configured to a DSL modem for
internet...its doing great.

 

The customer now brought in another internet feed and wants two websites
that they use to go out that internet feed...no problem.

 

The sticking issue I'm having right now is with NAT.  The current
configuration is a route-map that matches an ACL and overloads the
Dialer interface.

 

I know what I need to do...which is stop those two IP addresses from
matching the NAT statement and match another NAT statement and overload
the FastEthernet interface...but I'm totally stumped on how to do this.


 

If anyone could point me in the direction of some whitepapers or tell me
the "Cisco Speek" for what exactly I'm asking for...that would be most
appreciated.

 

Thanks!!!


From robert at tellurian.com  Fri Jul  3 16:53:23 2009
From: robert at tellurian.com (Robert Boyle)
Date: Fri, 03 Jul 2009 16:53:23 -0400
Subject: [c-nsp] IOS XR BFD
In-Reply-To: <480dad640907030928g409fb93cle53eca875bae3c31@mail.gmail.co
 m>
References: <501de4ea0907022344o2d57271cob04635b8f8557b6f@mail.gmail.com>
	<100362309621454DAA534950B17E55DB0116319951F1@isp-per-exc01.win2k.iinet.net.au>
	<1246613652_586037@mail1.tellurian.net>
	<480dad640907030928g409fb93cle53eca875bae3c31@mail.gmail.com>
Message-ID: <1246654774_599838@mail1.tellurian.net>

At 12:28 PM 7/3/2009, Aaron wrote:
>You must be using something else besides BGP. You need static, RIP, 
>IGRP, EIGRP, ISIS, or OSPF to get your routes into the table. BGP 
>cannot do it alone.

True. It was late/early when I read that and replied. :) We use ISIS 
to carry router loopback addresses and links and BGP for everything 
else. We do run BFD for ISIS. BGP runs on top of that. Nevermind.

-Robert



>On Fri, Jul 3, 2009 at 05:28, Robert Boyle 
><<mailto:robert at tellurian.com>robert at tellurian.com> wrote:
>At 02:55 AM 7/3/2009, Ian Henderson wrote:
>Nick 'tarantul' Novikov wrote on 2009-07-03:
>
> > The question arises, why IOS XR can't run BFD with internal BGP peers
> > (as old school IOS)?
>
>Because its assumed you're already using an IGP with which you can use it?
>
>
>What about those of us who use BGP as our IGP? I'm sure that 
>customer pressure will eventually lead Cisco to put that back into 
>the code. We use BFD and BGP internally and (obviously) BGP externally.
>
>-R
>
>
>
>Tellurian Networks - A Perot Systems Company
><http://www.tellurian.com>http://www.tellurian.com | 888-TELLURIAN | 
>973-300-9211
>"Well done is better than well said." - Benjamin Franklin
>
>
>_______________________________________________
>cisco-nsp mailing 
>list  <mailto:cisco-nsp at puck.nether.net>cisco-nsp at puck.nether.net
>https://puck.nether.net/mailman/listinfo/cisco-nsp
>archive at 
><http://puck.nether.net/pipermail/cisco-nsp/>http://puck.nether.net/pipermail/cisco-nsp/
>

Tellurian Networks - A Perot Systems Company
http://www.tellurian.com | 888-TELLURIAN | 973-300-9211
"Well done is better than well said." - Benjamin Franklin


From largent at ai.net  Fri Jul  3 19:35:00 2009
From: largent at ai.net (LA)
Date: Fri, 03 Jul 2009 19:35:00 -0400
Subject: [c-nsp] BFD with MP-BGP
Message-ID: <4A4E95A4.50900@ai.net>


When running labels in BGP (in P routers), one has to use BGP between 
loopback addresses (and disable the connected check in BGP). When you
try to use BFD to enable path failure detection, you get an error that 
says BFD can only be used with connected hosts.

Is there a way around this? (e.g. BFD on the static route pointing to 
the loopbacks or similar).

If one is trying to get to fast failover times without OSPF or 
similar... BFD with BGP should be the way to accomplish it.

Thanks.


From tarantul at gmail.com  Sat Jul  4 02:12:08 2009
From: tarantul at gmail.com (Nick 'tarantul' Novikov)
Date: Sat, 4 Jul 2009 10:12:08 +0400
Subject: [c-nsp] IOS XR BFD
In-Reply-To: <1C808F8D-3295-4286-AAD2-F8FDA3C5AC48@sniff.de>
References: <501de4ea0907022344o2d57271cob04635b8f8557b6f@mail.gmail.com>
	<1C808F8D-3295-4286-AAD2-F8FDA3C5AC48@sniff.de>
Message-ID: <501de4ea0907032312s6051035fk1996bc0cdef42517@mail.gmail.com>

On Fri, Jul 3, 2009 at 8:39 PM, Marc Binderberger<marc at sniff.de> wrote:
> Hello Nick,
>
> IOS-XR BFD does not support multihop yet, I think that's the reason they do
> not support iBGP.

Yep, but what if I have BGP session between IPs from subinterfaces
(special case, don't ask me why it was necessary to do so)? Old school
IOS allows enable BFD in this case, but XR no.


> If you think about iBGP between directly connected peers: have you tried it?
> The documentation may not cover this special case.

Yep.
RP/0/0/CPU0:cs1(config-bgp-nbr)#bfd fast-detect
RP/0/0/CPU0:cs1(config-bgp-nbr)#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
RP/0/0/CPU0:cs1(config-bgp-nbr)#show configuration failed
!! SEMANTIC ERRORS: This configuration was rejected by
!! the system due to semantic errors. The individual
!! errors with each failed configuration command can be
!! found below.


router bgp XXXX
 neighbor X.X.X.X
  bfd fast-detect
!!% Change would result in internal neighbor (X.X.X.X) with external-only config
 !
!
end



-- 
tarantul
Dios es Amor

From tarantul at gmail.com  Sat Jul  4 02:19:14 2009
From: tarantul at gmail.com (Nick 'tarantul' Novikov)
Date: Sat, 4 Jul 2009 10:19:14 +0400
Subject: [c-nsp] IOS XR BFD
In-Reply-To: <480dad640907030928g409fb93cle53eca875bae3c31@mail.gmail.com>
References: <501de4ea0907022344o2d57271cob04635b8f8557b6f@mail.gmail.com>
	<100362309621454DAA534950B17E55DB0116319951F1@isp-per-exc01.win2k.iinet.net.au>
	<1246613652_586037@mail1.tellurian.net>
	<480dad640907030928g409fb93cle53eca875bae3c31@mail.gmail.com>
Message-ID: <501de4ea0907032319y60b0ef9ahb0d246bb245ad7f4@mail.gmail.com>

On Fri, Jul 3, 2009 at 8:28 PM, Aaron<dudepron at gmail.com> wrote:
> You must be using something else besides BGP. You need static, RIP, IGRP,
> EIGRP, ISIS, or OSPF to get your routes into the table. BGP cannot do it
> alone.

Redistribute full BGP table to IS-IS? No way...
And this doesn't decide my problem. Traffic to another ASBR _must_
sent through special link. There's no other way.



-- 
tarantul
Dios es Amor

From dudepron at gmail.com  Sat Jul  4 11:41:03 2009
From: dudepron at gmail.com (Aaron)
Date: Sat, 4 Jul 2009 11:41:03 -0400
Subject: [c-nsp] IOS XR BFD
In-Reply-To: <501de4ea0907032319y60b0ef9ahb0d246bb245ad7f4@mail.gmail.com>
References: <501de4ea0907022344o2d57271cob04635b8f8557b6f@mail.gmail.com> 
	<100362309621454DAA534950B17E55DB0116319951F1@isp-per-exc01.win2k.iinet.net.au>
	<1246613652_586037@mail1.tellurian.net>
	<480dad640907030928g409fb93cle53eca875bae3c31@mail.gmail.com> 
	<501de4ea0907032319y60b0ef9ahb0d246bb245ad7f4@mail.gmail.com>
Message-ID: <480dad640907040841p7f056af5l55e0d14f7aff432d@mail.gmail.com>

No one said redistribute BGP into your IGP.

On Sat, Jul 4, 2009 at 02:19, Nick 'tarantul' Novikov <tarantul at gmail.com>wrote:

> On Fri, Jul 3, 2009 at 8:28 PM, Aaron<dudepron at gmail.com> wrote:
> > You must be using something else besides BGP. You need static, RIP, IGRP,
> > EIGRP, ISIS, or OSPF to get your routes into the table. BGP cannot do it
> > alone.
>
> Redistribute full BGP table to IS-IS? No way...
> And this doesn't decide my problem. Traffic to another ASBR _must_
> sent through special link. There's no other way.
>
>
>
> --
> tarantul
> Dios es Amor
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From plunin at senetsy.ru  Sat Jul  4 16:40:20 2009
From: plunin at senetsy.ru (Pavel Lunin)
Date: Sun, 5 Jul 2009 00:40:20 +0400
Subject: [c-nsp] IOS XR BFD
In-Reply-To: <501de4ea0907032319y60b0ef9ahb0d246bb245ad7f4@mail.gmail.com>
References: <501de4ea0907022344o2d57271cob04635b8f8557b6f@mail.gmail.com> 
	<100362309621454DAA534950B17E55DB0116319951F1@isp-per-exc01.win2k.iinet.net.au>
	<1246613652_586037@mail1.tellurian.net>
	<480dad640907030928g409fb93cle53eca875bae3c31@mail.gmail.com> 
	<501de4ea0907032319y60b0ef9ahb0d246bb245ad7f4@mail.gmail.com>
Message-ID: <77c10e260907041340x5177e348h2eadca6d4928c75c@mail.gmail.com>

2009/7/4 Nick 'tarantul' Novikov <tarantul at gmail.com>

> On Fri, Jul 3, 2009 at 8:28 PM, Aaron<dudepron at gmail.com> wrote:
> > You must be using something else besides BGP. You need static, RIP, IGRP,
> > EIGRP, ISIS, or OSPF to get your routes into the table. BGP cannot do it
> > alone.
>
> Redistribute full BGP table to IS-IS? No way...
> And this doesn't decide my problem. Traffic to another ASBR _must_
> sent through special link. There's no other way.


Nick, folks are telling clever things.

It is not BGP's deal anyway to control reachability. It's an IGP's task, as
well as the best path calculating. Just let IGP carry loopback /32 prefixes,
then run iBGP on them, not on subifs. iBGP's job is to carry routes
regardless of the topology state.

This sort of design is a standard for some last two decades, so it's at
least strange to go a different way. Moreover I can imagine an only reason
why you can't run IGP --  a lack of control plane resources. I hope it's not
you case (with IOS XR, huh :), otherwise static routes will save you (does
IOS XR support BFD for them? :)

--
Kind regards,
Pavel

From tarantul at gmail.com  Sun Jul  5 01:50:00 2009
From: tarantul at gmail.com (Nick 'tarantul' Novikov)
Date: Sun, 5 Jul 2009 09:50:00 +0400
Subject: [c-nsp] IOS XR BFD
In-Reply-To: <77c10e260907041340x5177e348h2eadca6d4928c75c@mail.gmail.com>
References: <501de4ea0907022344o2d57271cob04635b8f8557b6f@mail.gmail.com>
	<100362309621454DAA534950B17E55DB0116319951F1@isp-per-exc01.win2k.iinet.net.au>
	<1246613652_586037@mail1.tellurian.net>
	<480dad640907030928g409fb93cle53eca875bae3c31@mail.gmail.com>
	<501de4ea0907032319y60b0ef9ahb0d246bb245ad7f4@mail.gmail.com>
	<77c10e260907041340x5177e348h2eadca6d4928c75c@mail.gmail.com>
Message-ID: <501de4ea0907042250t64f4514m9350c45e398330b1@mail.gmail.com>

On Sun, Jul 5, 2009 at 12:40 AM, Pavel Lunin<plunin at senetsy.ru> wrote:
> Nick, folks are telling clever things.
>
> It is not BGP's deal anyway to control reachability. It's an IGP's task, as
> well as the best path calculating. Just let IGP carry loopback /32 prefixes,
> then run iBGP on them, not on subifs. iBGP's job is to carry routes
> regardless of the topology state.

Ok. Example of physical topology:
http://pastebin.ca/1484472
All physical links protected by IS-IS.
RR* routers can't keep full BGP table and for this reason ASBR*
announce 0/0 route only. If I configure BGP session between ASBR* and
use for it lo0 interfaces I will have a loop. Do not you think?


> This sort of design is a standard for some last two decades, so it's at
> least strange to go a different way. Moreover I can imagine an only reason
> why you can't run IGP --? a lack of control plane resources. I hope it's not
> you case (with IOS XR, huh :), otherwise static routes will save you (does
> IOS XR support BFD for them? :)

So fsck... No. IOS XR can't. If I configure (X.X.X.X - subif BGP
neighbor, not lo0 address)
router static
 address-family ipv4 unicast
  X.X.X.X/32 Null0
 !
!
BGP session don't drop!
In old school IOS a similar construction works great.



-- 
tarantul
Dios es Amor

From oboehmer at cisco.com  Sun Jul  5 03:00:05 2009
From: oboehmer at cisco.com (Oliver Boehmer (oboehmer))
Date: Sun, 5 Jul 2009 09:00:05 +0200
Subject: [c-nsp] IOS XR BFD
In-Reply-To: <501de4ea0907042250t64f4514m9350c45e398330b1@mail.gmail.com>
References: <501de4ea0907022344o2d57271cob04635b8f8557b6f@mail.gmail.com><100362309621454DAA534950B17E55DB0116319951F1@isp-per-exc01.win2k.iinet.net.au><1246613652_586037@mail1.tellurian.net><480dad640907030928g409fb93cle53eca875bae3c31@mail.gmail.com><501de4ea0907032319y60b0ef9ahb0d246bb245ad7f4@mail.gmail.com><77c10e260907041340x5177e348h2eadca6d4928c75c@mail.gmail.com>
	<501de4ea0907042250t64f4514m9350c45e398330b1@mail.gmail.com>
Message-ID: <70B7A1CCBFA5C649BD562B6D9F7ED7840798EB35@xmb-ams-333.emea.cisco.com>

Nick 'tarantul' Novikov <> wrote on Sunday, July 05, 2009 07:50:

> On Sun, Jul 5, 2009 at 12:40 AM, Pavel Lunin<plunin at senetsy.ru> wrote:
>> Nick, folks are telling clever things.
>> 
>> It is not BGP's deal anyway to control reachability. It's an IGP's
>> task, as well as the best path calculating. Just let IGP carry
>> loopback /32 prefixes, then run iBGP on them, not on subifs. iBGP's
>> job is to carry routes regardless of the topology state.
> 
> Ok. Example of physical topology:
> http://pastebin.ca/1484472
> All physical links protected by IS-IS.
> RR* routers can't keep full BGP table and for this reason ASBR*
> announce 0/0 route only. If I configure BGP session between ASBR* and
> use for it lo0 interfaces I will have a loop. Do not you think?

So you are running iBGP between the ASBRs to announce full routing
between the two, but the ASBRs itself only announce 0/0 towards the RR
(and in turn to the RR-clients). right? But I might be missing something
obvious because I don't see how BFD on the ASBR's iBGP session between
each other is possible (even in IOS) as they're not directly adjacent?

I guess the main problem to address is ASBR1 <-> ASBR2 traffic with RRs
in the middle not having full routing table (I infer this from you
mentioning the loop). This asks for tunnels, so why don't you just
enable MPLS on the ASBRs and the RRs (it seems you already have MPLS in
the core), and then the ASBRs can switch traffic between each other via
the LSP (tunnel).

The second issue is convergence (i.e. failure detection). Running
IGP/ISIS on all nodes (with BFD on the links) sounds possible, ASBR1
will see ASBR2's failure using IGP, and can react accordingly
(invalidates all the routes when next-hop tracking kicks in). 
Tearing down an iBGP session because the BGP-next-hop is gone is usually
a bad thing, it might only be for a second or so in case of a link flap,
and tearing down a full-bgp-feed session only to re-enable it a few
seconds later is not really good use of resources..

> In old school IOS a similar construction works great.

can you post the config in IOS? Not sure I got the full picture.. 

	oli

From plunin at senetsy.ru  Sun Jul  5 08:59:21 2009
From: plunin at senetsy.ru (Pavel Lunin)
Date: Sun, 5 Jul 2009 16:59:21 +0400
Subject: [c-nsp] IOS XR BFD
In-Reply-To: <501de4ea0907042250t64f4514m9350c45e398330b1@mail.gmail.com>
References: <501de4ea0907022344o2d57271cob04635b8f8557b6f@mail.gmail.com> 
	<100362309621454DAA534950B17E55DB0116319951F1@isp-per-exc01.win2k.iinet.net.au>
	<1246613652_586037@mail1.tellurian.net>
	<480dad640907030928g409fb93cle53eca875bae3c31@mail.gmail.com> 
	<501de4ea0907032319y60b0ef9ahb0d246bb245ad7f4@mail.gmail.com> 
	<77c10e260907041340x5177e348h2eadca6d4928c75c@mail.gmail.com> 
	<501de4ea0907042250t64f4514m9350c45e398330b1@mail.gmail.com>
Message-ID: <77c10e260907050559i4bfd323ch41435b5446efd333@mail.gmail.com>

2009/7/5 Nick 'tarantul' Novikov <tarantul at gmail.com>

>
> Ok. Example of physical topology:
> http://pastebin.ca/1484472
> All physical links protected by IS-IS.
> RR* routers can't keep full BGP table and for this reason ASBR*
> announce 0/0 route only. If I configure BGP session between ASBR* and
> use for it lo0 interfaces I will have a loop. Do not you think?


You know, I might also be missing something, but I don't see much difference
from iBGP's point of view. Traffic anyway goes through RRs on the way from
the core to outside as well as between ASBRs and RRs know only defaults.
What advantage does iBGP on subifs give here? I'd understand if you had a
link or an LSP between ASBRs and wanted to exclude a possibility of passing
plain IP traffic from one ASBR to another through RRs, but in this case...
am I missing something? How loops are avoided now?

Moreover what is a reason of separation of RRs and ASBRs in such a manner?
Normally you want RRs to carry traffic as little as possible but do well
their control plane jobs with no excuse. Why RRs can't fit full BGP? I bet
because their FIBs are constrained (sort of sup32 TCAM capability problem),
but not due to thier RIBs. Ideally RRs should stand out of forwarding
topology and not carry transit traffic at all.


> otherwise static routes will save you (does
> > IOS XR support BFD for them? :)
>
> So fsck... No. IOS XR can't. If I configure (X.X.X.X - subif BGP
> neighbor, not lo0 address)
> router static
>  address-family ipv4 unicast
>  X.X.X.X/32 Null0
>  !
> !
> BGP session don't drop!
> In old school IOS a similar construction works great.


Hm...  seems strange anyway. Does this route come active? Isn't it possible
that something like an ARP entry for x.x.x.x treated as a connected route
with lower admin distance? I know some non-cisco devices which can do so. Or
something else might beat this static route. What about 'sh ip route
x.x.x.x' (or whatever this command looks like in IOS XR) and 'ping x.x.x.x'
after adding this route? And if the route to null0 comes active and ping
fails, but iBGP stills alive, can you do some sort of investigation to know
how traffic reaches the peer, which path it goes along?

--
Regards,
Pavel

From sthaug at nethelp.no  Sun Jul  5 11:06:42 2009
From: sthaug at nethelp.no (sthaug at nethelp.no)
Date: Sun, 05 Jul 2009 17:06:42 +0200 (CEST)
Subject: [c-nsp] IOS XR BFD
In-Reply-To: <77c10e260907050559i4bfd323ch41435b5446efd333@mail.gmail.com>
References: <77c10e260907041340x5177e348h2eadca6d4928c75c@mail.gmail.com>
	<501de4ea0907042250t64f4514m9350c45e398330b1@mail.gmail.com>
	<77c10e260907050559i4bfd323ch41435b5446efd333@mail.gmail.com>
Message-ID: <20090705.170642.41730979.sthaug@nethelp.no>

> Moreover what is a reason of separation of RRs and ASBRs in such a manner?
> Normally you want RRs to carry traffic as little as possible but do well
> their control plane jobs with no excuse. Why RRs can't fit full BGP? I bet
> because their FIBs are constrained (sort of sup32 TCAM capability problem),
> but not due to thier RIBs. Ideally RRs should stand out of forwarding
> topology and not carry transit traffic at all.

I don't believe there is any kind of universal agreement that RRs 
should always be out of the forwarding path.

Steinar Haug, Nethelp consulting, sthaug at nethelp.no

From tarantul at gmail.com  Sun Jul  5 12:02:14 2009
From: tarantul at gmail.com (Nick 'tarantul' Novikov)
Date: Sun, 5 Jul 2009 20:02:14 +0400
Subject: [c-nsp] IOS XR BFD
In-Reply-To: <77c10e260907050559i4bfd323ch41435b5446efd333@mail.gmail.com>
References: <501de4ea0907022344o2d57271cob04635b8f8557b6f@mail.gmail.com>
	<100362309621454DAA534950B17E55DB0116319951F1@isp-per-exc01.win2k.iinet.net.au>
	<1246613652_586037@mail1.tellurian.net>
	<480dad640907030928g409fb93cle53eca875bae3c31@mail.gmail.com>
	<501de4ea0907032319y60b0ef9ahb0d246bb245ad7f4@mail.gmail.com>
	<77c10e260907041340x5177e348h2eadca6d4928c75c@mail.gmail.com>
	<501de4ea0907042250t64f4514m9350c45e398330b1@mail.gmail.com>
	<77c10e260907050559i4bfd323ch41435b5446efd333@mail.gmail.com>
Message-ID: <501de4ea0907050902i675d53basfca4350ecabeabfe@mail.gmail.com>

On Sun, Jul 5, 2009 at 4:59 PM, Pavel Lunin<plunin at senetsy.ru> wrote:
> You know, I might also be missing something, but I don't see much difference
> from iBGP's point of view. Traffic anyway goes through RRs on the way from
> the core to outside as well as between ASBRs and RRs know only defaults.
> What advantage does iBGP on subifs give here? I'd understand if you had a
> link or an LSP between ASBRs and wanted to exclude a possibility of passing
> plain IP traffic from one ASBR to another through RRs, but in this case...
> am I missing something? How loops are avoided now?

1. RR1 have 0/0 from ASBR1 (as best route) and send packets to RR1
2. ASBR1 have BGP session with ASBR2 and destination prefix close through ASBR2
3. ASBR1 send packets back to RR1
4. Go to p.1

Ok, I can configure separated L2 path for ASBR1-ASBR2:
ASBR1 -trunk- RR1 - xconnect - RR2 -trunk- ASBR2
But if xconnect fails, I get the situation described above for the BGP
timeout (3*60 seconds by default)
To avoid this possible to configure the BGP session from ASBR subif
and use BDF for fast session drop if L2 connect fails.



> Moreover what is a reason of separation of RRs and ASBRs in such a manner?

It is easier to operate.

> Normally you want RRs to carry traffic as little as possible but do well
> their control plane jobs with no excuse. Why RRs can't fit full BGP? I bet
> because their FIBs are constrained (sort of sup32 TCAM capability problem),
> but not due to thier RIBs. Ideally RRs should stand out of forwarding
> topology and not carry transit traffic at all.

RR is a 7600 with notXL RSP. 256k prefixes only.

>> otherwise static routes will save you (does
>> > IOS XR support BFD for them? :)
>>
>> So fsck... No. IOS XR can't. If I configure (X.X.X.X - subif BGP
>> neighbor, not lo0 address)
>> router static
>> ?address-family ipv4 unicast
>> ?X.X.X.X/32 Null0
>> ?!
>> !
>> BGP session don't drop!
>> In old school IOS a similar construction works great.
>
> Hm...? seems strange anyway. Does this route come active? Isn't it possible
> that something like an ARP entry for x.x.x.x treated as a connected route
> with lower admin distance? I know some non-cisco devices which can do so. Or
> something else might beat this static route. What about 'sh ip route
> x.x.x.x' (or whatever this command looks like in IOS XR) and 'ping x.x.x.x'
> after adding this route? And if the route to null0 comes active and ping
> fails, but iBGP stills alive, can you do some sort of investigation to know
> how traffic reaches the peer, which path it goes along?

sh ip route indicates Null0, ping work. Static route /32 longest match
than connected to interface /30. I think the traffic should go to
Null0 and ping must be broken (and BGP session).
However, this design does not help me. Oldschool IOS for my ASBR (12k)
don't support BFD for static route feature (but IOS XR support it).

And my question is not how I should be in this situation.
What is the logical explanation that BFD does not work in internal neighbors?

-- 
tarantul
Dios es Amor

From nick at inex.ie  Sun Jul  5 11:51:16 2009
From: nick at inex.ie (Nick Hilliard)
Date: Sun, 05 Jul 2009 16:51:16 +0100
Subject: [c-nsp] ipv6 traffic layer2-switched netflow data export on c65k
Message-ID: <4A50CBF4.30007@inex.ie>

Is there anyone out there who has managed to get layer2 netflow data export 
working for l2 switched ipv6 traffic on a c65k?  I've been beating my head 
against a wall trying to get it to work and just can't seem to.

The box in question has a sup720/pfc3b and is running sxi1. The relevant 
configuration is:

> ipv6 unicast-routing
> ip flow ingress layer2-switched vlan NNN
> mls netflow interface
> mls netflow usage notify 75 120
> mls flow ip interface-full
> mls flow ipv6 interface-full
> mls nde sender
> ip flow-export version 9
> ip flow-export destination x.x.x.x yyyy
> ip flow-aggregation cache destination-prefix
> interface VlanNNN
>  ip address x.x.x.x y.y.y.y
>  ip access-group N in
>  ip access-group N out
>  no ip proxy-arp
>  ip flow ingress
>  ipv6 address zz:zz::zz/64
>  ipv6 enable
> end

With this configuration, I can see netflow v9 records for ipv4 L2 traffic 
getting exported to the collector - indicating that NDE is working, and 
exporting correctly-formed v9 records.  NDE on the switch also says the 
right sort of stuff:

> switch#sh mls nde
>  Netflow Data Export enabled
>  Exporting flows to  x.x.x.x (yyyy)
>  Exporting flows from x.x.x.x (zzzz)
>  Version: 9
>  Layer2 flow creation is enabled on vlan 10
>  Layer2 flow export is enabled on vlan 10
>  Include Filter not configured
>  Exclude Filter not configured
>  Total Netflow Data Export Packets are:
>     1331555 packets, 0 no packets, 42469446 records
>  Total Netflow Data Export Send Errors:
>         IPWRITE_NO_FIB = 0
>         IPWRITE_ADJ_FAILED = 0
>         IPWRITE_PROCESS = 0
>         IPWRITE_ENQUEUE_FAILED = 0
>         IPWRITE_IPC_FAILED = 0
>         IPWRITE_OUTPUT_FAILED = 0
>         IPWRITE_MTU_FAILED = 0
>         IPWRITE_ENCAPFIX_FAILED = 0
>         IPWRITE_CARD_FAILED = 0
>  Netflow Aggregation Disabled

I'm also seeing ipv6 netflow data being collected on the switch - these 
flows look ok to me.

> switch#sh mls netflow ipv6 nowrap
> Displaying Netflow entries in Active Supervisor EARL in module 5
> DstIP                                   SrcIP                                   Prot:SrcPort:DstPort   Src i/f          :AdjPtr      Pkts        Bytes       Age  LastSeen    Attributes
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> 2001:0:CF2E:3096:C10:13FA:C555:FD0D     2001:770:100:143::2                     tcp :52212  :32385     Vl10             :0x0         20          21080       12   16:30:48    L2 - Dynamic
> 2001:678:4::2                           2001:7C8:3:2::2                         udp :21131  :dns       Vl10             :0x0         1           83          4    16:30:45    L2 - Dynamic
> 2001:500:14:6036:AD::1                  2001:7C8:42:1::2                        udp :62258  :dns       Vl10             :0x0         1           97          6    16:30:43    L2 - Dynamic
> 2001:7C8:42:1::2                        2001:500:14:6036:AD::1                  udp :dns    :62258     Vl10             :0x0         1           146         6    16:30:43    L2 - Dynamic
[...]

... indicating that the pfc is actually collecting ipv6 netflow data.

However, there are no ipv6 netflow data records appearing on the netflow 
collector.  I've tried both flowd and nfcapd, just in case one of them was 
playing silly buggers with v6 records, but neither of them is reporting any 
ipv6 data records at all, just ipv4.

The relevant documentation suggests that this should work.  Also, ipv6 NDE 
for L3 traffic appears to work, from what I hear of other people.

Any suggestions here?

Nick

From p.mayers at imperial.ac.uk  Sun Jul  5 18:05:59 2009
From: p.mayers at imperial.ac.uk (Phil Mayers)
Date: Sun, 05 Jul 2009 23:05:59 +0100
Subject: [c-nsp] Free NMS Tools
In-Reply-To: <4f890e580907030600y3f8e6c15qfa6c4b4db539fec@mail.gmail.com>
References: <F1755DA0C92B4B0F8EEA558869BD8D1B@experienbd1776>
	<4f890e580907030600y3f8e6c15qfa6c4b4db539fec@mail.gmail.com>
Message-ID: <4A5123C7.6010903@imperial.ac.uk>

Mario Spinthiras wrote:
> I would say Zenoss is looking good because of the inventory management you
> can do and because of the logical structure it puts everything in. I wrote
> an old dusty article a long long time ago on NMSs , maybe you can take a
> peak.
> http://www.spinthiras.org/2008/07/network-monitoring/
> 
> Everything else just seems inadequate or poor.
> 
> And for goodness sake don't put nagios because it will take ages to
> configure :)

Heh. In all seriousness though... it depends on your monitoring paradigm.

For example: many people use autodiscovery and friends to configure 
their monitoring, or manual configurations.

We do the opposite. We have a single central registration database. All 
hosts (and I do mean all) get entered into it. The nagios config is 
built *from* that database. Rather than edit the config, you make the 
database "be correct".

So, we spend essentially zero time configuring nagios. It's (re)built 
once every 5 minutes automatically.

From tstevens at cisco.com  Sun Jul  5 20:55:32 2009
From: tstevens at cisco.com (Tim Stevenson)
Date: Sun, 05 Jul 2009 17:55:32 -0700
Subject: [c-nsp] WS-X6716-10G local switching and etherchanneling
In-Reply-To: <4A4DD2CC.1010806@spacething.org>
References: <4A4C9C40.6030804@spacething.org>
	<200907030320.n633K6Zx012286@sj-core-2.cisco.com>
	<4A4DD2CC.1010806@spacething.org>
Message-ID: <200907060055.n660tWt9027916@sj-core-2.cisco.com>

The 6708 is oversubscribed at the fabric, not at the port. But there 
are other limiting factors in the architecture. With 6708 you get 40G 
into the fabric, and up to 64G with local switching. But you won't 
get 80G out of this card.

HTH,
Tim

At 02:43 AM 7/3/2009, Sam Stickland contended:

>Thanks the reply Tim,
>
>Are the port's similarly oversubscribed on the 6708, or can line-rate be
>achieved between ports 1-4 & 5-6?
>
>Sam
>
>Tim Stevenson wrote:
> > Sam, please see inline below:
> >
> > At 04:38 AM 7/2/2009, Sam Stickland contended:
> >
> >> Hi,
> >>
> >> I've read:
> >> 
> <http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod_white_paper0900aecd80673385.html>http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod_white_paper0900aecd80673385.html
> >>
> >>
> >> If I'm understanding this correctly,
> >
> > I don't see any mention of 6716 in this white paper. 6716 does not
> > share the same architecture as any other 10G cards (eg 6708) mentioned
> > there. 6716 is actually more like a 6704 front ended by 4:1 muxes (at
> > a high level - in reality, different chips are being used, ie, metro &
> > r2d2 et al, not janus & rohini).
> >
> >> communication between each bank of
> >> 8 ports on a 6716-10G will be line-rate, but communication between the
> >> first and second groups of 8 ports will need to traverse the switch
> >> fabric?
> >
> > While it's correct that ports 1-8 & 9-16 are on separate fabric
> > channels, the key in the 6716 is that there is built-in *port-based*
> > 4:1 oversubscription.
> >
> > In other words, 4 physical 10G ports feed into a single 10G chip
> > (there are 4 such 10G chips on the card), ie, 4 ports share 10G of
> > bandwidth at the port level.
> >
> > So the maximum local switching performance you'd see in one half of
> > the card is 20G, the same as you'd get into the fabric.
> >
> >> On a similar note, if I create an etherchannel between two 6716-10G's
> >> will a module favour forwarding out of it's locally attached channel
> >> member?
> >
> > No, it's just a hash decision - luck of the draw. Eg, packet comes in
> > on t1/1 and channel member ports are t1/5 and t2/5. You've basically
> > got a 50/50 chance that you'd pass over the fabric.
> >
> > HTH,
> > Tim
> >
> >
> >
> >> Regards,
> >>
> >> Sam
> >> _______________________________________________
> >> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> >> 
> <https://puck.nether.net/mailman/listinfo/cisco-nsp>https://puck.nether.net/mailman/listinfo/cisco-nsp
> >> archive at 
> <http://puck.nether.net/pipermail/cisco-nsp/>http://puck.nether.net/pipermail/cisco-nsp/
> >
> >
> >
> > Tim Stevenson, tstevens at cisco.com
> > Routing & Switching CCIE #5561
> > Technical Marketing Engineer, Cisco Nexus 7000
> > Cisco - <http://www.cisco.com>http://www.cisco.com
> > <http://www.cisco.com/>IP Phone: 408-526-6759
> > ********************************************************
> > The contents of this message may be *Cisco Confidential*
> > and are intended for the specified recipients only.
> >




Tim Stevenson, tstevens at cisco.com
Routing & Switching CCIE #5561
Technical Marketing Engineer, Cisco Nexus 7000
Cisco - http://www.cisco.com
IP Phone: 408-526-6759
********************************************************
The contents of this message may be *Cisco Confidential*
and are intended for the specified recipients only.

From blahu77 at gmail.com  Mon Jul  6 04:38:58 2009
From: blahu77 at gmail.com (Mateusz Blaszczyk)
Date: Mon, 6 Jul 2009 09:38:58 +0100 (IST)
Subject: [c-nsp] [c3560g] Not in truth table when modyfing ACL
In-Reply-To: <4A4E3C2B.10203@selfnet.de>
Message-ID: <fwsxxhkws8pa6tj07rUYAxe124vaj_firegpg@mail.gmail.com>

It seems it's a bug that appeared first in 12.2(50)SE and later releases.
To be fixed in SE3, scheduled for release on 23th July.

Best Regards,

-mat

2009/7/3 Tim <tim at selfnet.de>:
> Hi,
>
> Mateusz Blaszczyk wrote:
>> This error message shows up every now end then when adding or modyfing
>> an ACL (with or without access-group config on the SVI):
>>
>> Jun ?4 03:33:23.347: %ACLMGR-3-INTTABLE: Not in truth table: VLMAP 9
>> RACL 9 Rtprot 9 Mcb 13 Feat 3
>> Jun ?4 03:33:23.347: %ACLMGR-3-INTTABLE: Not in truth table: VLMAP 9
>> RACL 9 Rtprot 9 Mcb 13 Feat 3
>> Jun ?4 03:33:23.355: %ACLMGR-3-INTTABLE: Not in truth table: VLMAP 9
>> RACL 9 Rtprot 9 Mcb 13 Feat 3
>> Jun ?4 03:33:23.355: %ACLMGR-3-INTTABLE: Not in truth table: VLMAP 9
>> RACL 9 Rtprot 9 Mcb 13 Feat 3
>>
>> Can anyone tell me what is the severity of that problem? google is
>> quite quiet apart from link to cisco's error messages list, which is
>> not really helpful.
>
> I am getting this on several C3750G, but only with inbound ACLs. ?Beside
> the error messages, there is indeed a big impact: ?the router will
> (sometimes) drop IP packets with a destination IP address located on the
> interface (e.g., a BGP session - the BGP session will NOT come up
> again). ?Transit traffic were not affected. ?I can reproduce the error
> in my Lab.
>
> I decided to downgrade to 12.2(46)SE, because I need the BGP sessions...
>
> But maybe someone found a solution and/or knows, that Cisco will fix it
> (soon)?
>
> Regards,
> ? ? ? ?Tim
> ####################
>
> For the sake of completeness my setup:
>
> IP Service 12.2(50)SE and 12.2(50)SE2
> ?on a WS-C3750G-12S-S and WS-C3750G-24TS-S
>
> %ACLMGR-3-INTTABLE: Not in truth table: VLMAP 9 RACL 9 Rtprot 9 Mcb 13
> Feat 3
>
> When I configure an ACL inbound on a routed interface, the Router
> throws this error message.
>
> Also, the router will (sometimes) drop IP packets with a destination IP
> address located on the router (e.g., a BGP session).
>
> Transit traffic is - as far as I can see - not affected.
>
> I can reproduce the error. ?With the older IP Advanced Service
> 12.2(46)SE it works fine.
>
> Setup (IP addresses were anonymised):
> ? ? ? ? ? ? ?Gi1/0/12
> C3750G-12S-S --------------------------- Uplink Provider
> ?| ? ? ? ? ? ?2.0.0.1/30 ? ? 2.0.0.2/30
> ?|
> 1.16.0.0/16
>
> Config snips:
>
> router bgp 65454
> ?bgp router-id 2.0.1.1
> ?bgp log-neighbor-changes
> ?neighbor 2.0.0.2 remote-as 65000
> ?neighbor 2.0.0.2 transport path-mtu-discovery
> ?!
> ?address-family ipv4
> ?neighbor 2.0.0.2 activate
> ?neighbor 2.0.0.2 soft-reconfiguration inbound
> ?neighbor 2.0.0.2 prefix-list from-UPLINK in
> ?neighbor 2.0.0.2 distribute-list 10 out
> ?no auto-summary
> ?no synchronization
> ?network 1.16.0.0 mask 255.255.0.0
> ?exit-address-family
> !
> interface GigabitEthernet1/0/12
> ?description Uplink
> ?no switchport
> ?ip address 2.0.0.1 255.255.255.252
> ?ip access-group uplink-inbound in
> ?ip access-group uplink-outbound out
> ?no cdp enable
> ?spanning-tree portfast
> !
> ip access-list extended uplink-inbound
> ?deny ? ip 127.0.0.0 0.255.255.255 any
> ?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
> ?permit ip any 2.0.0.0 0.0.0.3
> ?permit ip any 1.16.0.0 0.0.255.255
> !
> ip access-list extended uplink-outbound
> ?deny ? ip any 127.0.0.0 0.255.255.255
> ?deny ? ip any 10.0.0.0 0.255.255.255
> ?deny ? ip any 172.16.0.0 0.15.255.255
> ?deny ? ip any 192.168.0.0 0.0.255.255
> ?permit ip 2.0.0.0 0.0.0.3 any
> ?permit ip 1.16.0.0 0.0.255.255 any
> !
>
> It only affects the inbound ACL, example log output:
>
> Jul ?3 12:31:14: %PARSER-5-CFGLOG_LOGGEDCMD: User:tim ?logged
> command:interface GigabitEthernet1/0/28
> Jul ?3 12:31:20: %PARSER-5-CFGLOG_LOGGEDCMD: User:tim ?logged command:ip
> access-group uplink-inbound in
> Jul ?3 12:31:20: %ACLMGR-3-INTTABLE: Not in truth table: VLMAP 9 RACL 9
> Rtprot 9 Mcb 13 Feat 3
> Jul ?3 12:31:20: %ACLMGR-3-INTTABLE: Not in truth table: VLMAP 9 RACL 9
> Rtprot 9 Mcb 13 Feat 3
>
> The error message comes also with an ACL, which does not exist:
>
> Jul ?3 12:32:45: %PARSER-5-CFGLOG_LOGGEDCMD: User:tim ?logged command:ip
> access-group doesnotexists in
> Jul ?3 12:32:45: %ACLMGR-3-INTTABLE: Not in truth table: VLMAP 9 RACL 9
> Rtprot 9 Mcb 13 Feat 3
> Jul ?3 12:32:45: %ACLMGR-3-INTTABLE: Not in truth table: VLMAP 9 RACL 9
> Rtprot 9 Mcb 13 Feat 3
>
>
> The only statement from Cisco says:
> """
> Explanation ? ?An unrecoverable software error occurred while trying to
> merge the configured input features. [dec] are internal action codes.
> """ [1]
>
> Also, the "Output Interpreter" does not help. ?And the "Bug Toolkit"
> does not show any bug.
>
> [1]
> http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_25_see/system/message/msg_desc.html
>
>
>
>

-------------- 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/20090706/affbdefb/attachment-0001.bin>

From oboehmer at cisco.com  Mon Jul  6 04:41:52 2009
From: oboehmer at cisco.com (Oliver Boehmer (oboehmer))
Date: Mon, 6 Jul 2009 10:41:52 +0200
Subject: [c-nsp] IOS XR BFD
In-Reply-To: <501de4ea0907050902i675d53basfca4350ecabeabfe@mail.gmail.com>
References: <501de4ea0907022344o2d57271cob04635b8f8557b6f@mail.gmail.com><100362309621454DAA534950B17E55DB0116319951F1@isp-per-exc01.win2k.iinet.net.au><1246613652_586037@mail1.tellurian.net><480dad640907030928g409fb93cle53eca875bae3c31@mail.gmail.com><501de4ea0907032319y60b0ef9ahb0d246bb245ad7f4@mail.gmail.com><77c10e260907041340x5177e348h2eadca6d4928c75c@mail.gmail.com><501de4ea0907042250t64f4514m9350c45e398330b1@mail.gmail.com><77c10e260907050559i4bfd323ch41435b5446efd333@mail.gmail.com>
	<501de4ea0907050902i675d53basfca4350ecabeabfe@mail.gmail.com>
Message-ID: <70B7A1CCBFA5C649BD562B6D9F7ED7840798ECBA@xmb-ams-333.emea.cisco.com>

Nick 'tarantul' Novikov <> wrote on Sunday, July 05, 2009 18:02:

> On Sun, Jul 5, 2009 at 4:59 PM, Pavel Lunin<plunin at senetsy.ru> wrote:
>> You know, I might also be missing something, but I don't see much
>> difference from iBGP's point of view. Traffic anyway goes through
>> RRs on the way from the core to outside as well as between ASBRs and
>> RRs know only defaults. What advantage does iBGP on subifs give
>> here? I'd understand if you had a link or an LSP between ASBRs and
>> wanted to exclude a possibility of passing plain IP traffic from one
>> ASBR to another through RRs, but in this case... am I missing
>> something? How loops are avoided now? 
> 
> 1. RR1 have 0/0 from ASBR1 (as best route) and send packets to RR1
> 2. ASBR1 have BGP session with ASBR2 and destination prefix close
> through ASBR2 
> 3. ASBR1 send packets back to RR1
> 4. Go to p.1
> 
> Ok, I can configure separated L2 path for ASBR1-ASBR2:
> ASBR1 -trunk- RR1 - xconnect - RR2 -trunk- ASBR2
> But if xconnect fails, I get the situation described above for the BGP
> timeout (3*60 seconds by default)
> To avoid this possible to configure the BGP session from ASBR subif
> and use BDF for fast session drop if L2 connect fails.

or, as I mentioned in another post, enable MPLS on ASBRs and RRs to get
the traffic tunnelled, and you can use ISIS BFD and next-hop tracking
and/or BGP-PIC for speedy convergence.

> And my question is not how I should be in this situation.
> What is the logical explanation that BFD does not work in internal
> neighbors? 

because it hasn't been developed to work in this scenario under XR,
which is likely due because it's not a commonly deployed setup.

	oli

From vitya at list.ru  Mon Jul  6 08:46:35 2009
From: vitya at list.ru (victor)
Date: Mon, 06 Jul 2009 16:46:35 +0400
Subject: [c-nsp] Q-in-Q bridging
Message-ID: <op.uwnce7oh2vrlim@localhost.localdomain>

Hi
For the redundancy/failover sake I'm bridging 2 Q-in-Q interfaces. Here is  
config:

interface BVI1
  ip address 10.67.201.100 255.255.255.0

interface GigabitEthernet0/2.4012010
  encapsulation dot1Q 401 second-dot1q 2010
  no cdp enable
  bridge-group 1

interface GigabitEthernet0/3.4012010
  encapsulation dot1Q 401 second-dot1q 2010
  no cdp enable
  bridge-group 1

interface BVI1
  ip address  255.255.255.0

bridge 1 protocol ieees

Network looks like this:

Router==QinQ==(MAN Switches Ring)----LanSwitch---Host(10.67.201.5)

Router physically connected to 2 core switches and terminates dot.Q  
tunnels.
MAN switches carry vlan tunnels and the when the LAN enters into the MAN  
Ring it is assigned outer tag 401.
The Host is inside LAN on VLAN 2010 and connected through access port.
The ip 10.67.201.100 is going to be default GW for the LAN Host and must  
remain reachable even if one of the core switches goes down.
When I assign IP address to either G0/2.4012010 or G0/3.4012010 sub  
interfaces I'm able to ping it from the Host. But after bridging them I  
can't ping BVI1 from the Host. What am I doing wrong? Is it supposed to  
work this way?

Regards, Victor
-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

From jkrejci at usinternet.com  Mon Jul  6 10:01:42 2009
From: jkrejci at usinternet.com (Justin Krejci)
Date: Mon, 6 Jul 2009 09:01:42 -0500
Subject: [c-nsp] Netflow Collector shows minimal bandwidth from 6509
Message-ID: <505D3C9734BC4BBA8249E637EC5F2A71@usicorp.usinternet.com>

List,

 

My netflow collector was running just fine with my previous 7206VXR-NPEG1.
After swapping out to a new 6509 (hardware specs below, same as discussed in
earliar LX vs LH thread) our netflow (ver 5) collector is reporting a
fraction (around 30-40% on inbound and around 0-1% on outbound) of the
traffic across the gig5/1 interface. The results of my netflow collector
indicate my netflow configuration is not setup properly though after reading
thru these Cisco documents it does not appear I am missing anything from the
config. I've tried playing around with various other configs but nothing
seems to work. Am I missing some config or is my hardware not going to give
me the data I am looking for?

 

http://www.cisco.com/en/US/products/hw/switches/ps708/products_configuration
_example09186a0080721701.shtml

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configu
ration/guide/netflow.html

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/native
/configuration/guide/nde.html

 

Though I did read this line from the first URL above that seems ominous for
me since I am looking for L3 traffic (router interface gig5/1)
The Policy Feature Card 3 (PFC3) and Policy Feature Card 2 (PFC2) do not use
the NetFlow table for Layer 3 switching in hardware.

 

 

Also when I run a tcpdump on the collector server for the netflow traffic
from this 6509 it shows traffic in small batches whereas on other netflow
collectors still receiving from 7206 routers it's a steady stream of UDP
packets.

 

Cat6509

IOS: Version 12.2(33)SXI

 

Mod Ports Card Type                              Model          

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

  1   48  CEF720 48 port 10/100/1000mb Ethernet  WS-X6748-GE-TX 

  5    2  Supervisor Engine 720 (Active)         WS-SUP720-3BXL 

 

Mod  Sub-Module                  Model              

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

  1  Centralized Forwarding Card WS-F6700-CFC   

  5  Policy Feature Card 3       WS-F6K-PFC3BXL 

  5  MSFC3 Daughterboard         WS-SUP720      

 

6509#show run | inc mls

mls ip slb purge global

mls aging normal 120

mls exclude acl-deny

mls netflow interface

mls flow ip interface-full

no mls flow ipv6

mls nde sender version 5

mls cef error action freeze

 

6509#show run | inc flow-ex

ip flow-export source GigabitEthernet1/1

ip flow-export version 5

ip flow-export destination 10.255.244.71 9996

 

6509#show mls netflow flowmas                   

 current ip   flowmask for unicast:   if-full 

 current ipv6 flowmask for unicast:    null   

 

6509#show mls netflow table-contention detailed 

Earl in Module 5

Detailed Netflow CAM (TCAM and ICAM) Utilization

================================================

TCAM Utilization             :   20% 

ICAM Utilization             :   1% 

Netflow TCAM count           :   54697 

Netflow ICAM count           :   2 

Netflow Creation Failures    :   0 

Netflow CAM aliases          :   0 

 

6509#sh mls nde                                 

 Netflow Data Export enabled 

 Exporting flows to  10.255.244.71 (9996)

 Exporting flows from 10.255.244.4 (56343)

 Version: 5

 Layer2 flow creation is disabled

 Layer2 flow export is disabled

 Include Filter not configured 

 Exclude Filter not configured 

 Total Netflow Data Export Packets are:

    6640025 packets, 0 no packets, 192559651 records

 Total Netflow Data Export Send Errors:

        IPWRITE_NO_FIB = 0

        IPWRITE_ADJ_FAILED = 0

        IPWRITE_PROCESS = 0

        IPWRITE_ENQUEUE_FAILED = 0

        IPWRITE_IPC_FAILED = 0

        IPWRITE_OUTPUT_FAILED = 0

        IPWRITE_MTU_FAILED = 0

        IPWRITE_ENCAPFIX_FAILED = 0

        IPWRITE_CARD_FAILED = 0

 Netflow Aggregation Disabled 

 

 

interface GigabitEthernet5/1

 ip flow ingress

 ip flow egress

 

6509#show int g5/1 | inc 30 second

  30 second input rate 102688000 bits/sec, 18410 packets/sec

  30 second output rate 136059000 bits/sec, 30058 packets/sec

 

 

Sincerely and thanks, 
Justin Krejci 



 


From nigel at theroys.me.uk  Mon Jul  6 09:21:27 2009
From: nigel at theroys.me.uk (Nigel Roy)
Date: Mon, 6 Jul 2009 14:21:27 +0100
Subject: [c-nsp] Q-in-Q bridging
In-Reply-To: <op.uwnce7oh2vrlim@localhost.localdomain>
Message-ID: <200976142127.566321@easynet-2438>

I think you need two additional commands:

bridge irb  	- 	to enable integrated routing and bridging
bridge 1 route ip 	-  to enable routing of IP from routed network to bridged.

Regards Nigel


> Hi
> For the redundancy/failover sake I'm bridging 2 Q-in-Q interfaces.
> Here is config:
>
> interface BVI1
> ip address 10.67.201.100 255.255.255.0
>
> interface GigabitEthernet0/2.4012010
> encapsulation dot1Q 401 second-dot1q 2010
> no cdp enable
> bridge-group 1
>
> interface GigabitEthernet0/3.4012010
> encapsulation dot1Q 401 second-dot1q 2010
> no cdp enable
> bridge-group 1
>
> interface BVI1
> ip address  255.255.255.0
>
> bridge 1 protocol ieees
>
> Network looks like this:
>
> Router==QinQ==(MAN Switches Ring)----LanSwitch---Host(10.67.201.5)
>
> Router physically connected to 2 core switches and terminates dot.Q
> tunnels.
> MAN switches carry vlan tunnels and the when the LAN enters into
> the MAN Ring it is assigned outer tag 401.
> The Host is inside LAN on VLAN 2010 and connected through access
> port. The ip 10.67.201.100 is going to be default GW for the LAN
> Host and must remain reachable even if one of the core switches
> goes down. When I assign IP address to either G0/2.4012010 or
> G0/3.4012010 sub interfaces I'm able to ping it from the Host. But
> after bridging them I can't ping BVI1 from the Host. What am I
> doing wrong? Is it supposed to work this way?
>
> Regards, Victor

From linux.yahoo at gmail.com  Mon Jul  6 10:13:25 2009
From: linux.yahoo at gmail.com (Manu Chao)
Date: Mon, 6 Jul 2009 16:13:25 +0200
Subject: [c-nsp] XR versus SR
Message-ID: <7100ed370907060713y3e5760cfx7b64807db77bb198@mail.gmail.com>

It seems all MPLS features not yet available on ASR9000, true?

Is there a different timeframe for implementing MPLS features between IOS
XR and IOS 12.2SR teams?

R/
Manu

From andy-lists at bourges.de  Mon Jul  6 10:38:53 2009
From: andy-lists at bourges.de (Andreas Bourges)
Date: Mon, 6 Jul 2009 16:38:53 +0200
Subject: [c-nsp] Netflow Collector shows minimal bandwidth from 6509
In-Reply-To: <505D3C9734BC4BBA8249E637EC5F2A71@usicorp.usinternet.com>
References: <505D3C9734BC4BBA8249E637EC5F2A71@usicorp.usinternet.com>
Message-ID: <200907061638.59842.andy-lists@bourges.de>

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

Hi,

On Monday 06 July 2009 16:01:42 Justin Krejci wrote:
>
>
> interface GigabitEthernet5/1
>
>  ip flow ingress
>
>  ip flow egress

...ip flow egress will only catch the software-processed flows. So you will 
need to modify your netflow setup to enable ip flow ingress on all layer3 
interfaces to catch all output traffic for gig5/1.

which doesn't explain why you're still missing 50% of your ingress flows ?!


Regards,

Andy

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkpSDH0ACgkQRrny/uOBVy43UACgoOdfbyaS8X8Td34Twi5OUJID
RAEAnjZiiCWqdDBiNXavjk5DTkLBr+ei
=9gLx
-----END PGP SIGNATURE-----

From vitya at list.ru  Mon Jul  6 10:49:11 2009
From: vitya at list.ru (victor)
Date: Mon, 06 Jul 2009 18:49:11 +0400
Subject: [c-nsp] Q-in-Q bridging
In-Reply-To: <200976142127.566321@easynet-2438>
References: <200976142127.566321@easynet-2438>
Message-ID: <op.uwnh39bn2vrlim@localhost.localdomain>

On Mon, 06 Jul 2009 17:21:27 +0400, Nigel Roy <nigel at theroys.me.uk> wrote:
Tried but with no positive result:

bridge irb
bridge 1 route ip

And even:
no bridge 1 bridge ip

> I think you need two additional commands:
>
> bridge irb  	- 	to enable integrated routing and bridging
> bridge 1 route ip 	-  to enable routing of IP from routed network to  
> bridged.
>
> Regards Nigel
>
>
>> Hi
>> For the redundancy/failover sake I'm bridging 2 Q-in-Q interfaces.
>> Here is config:
>>
>> interface BVI1
>> ip address 10.67.201.100 255.255.255.0
>>
>> interface GigabitEthernet0/2.4012010
>> encapsulation dot1Q 401 second-dot1q 2010
>> no cdp enable
>> bridge-group 1
>>
>> interface GigabitEthernet0/3.4012010
>> encapsulation dot1Q 401 second-dot1q 2010
>> no cdp enable
>> bridge-group 1
>>
>> interface BVI1
>> ip address  255.255.255.0
>>
>> bridge 1 protocol ieees
>>
>> Network looks like this:
>>
>> Router==QinQ==(MAN Switches Ring)----LanSwitch---Host(10.67.201.5)
>>
>> Router physically connected to 2 core switches and terminates dot.Q
>> tunnels.
>> MAN switches carry vlan tunnels and the when the LAN enters into
>> the MAN Ring it is assigned outer tag 401.
>> The Host is inside LAN on VLAN 2010 and connected through access
>> port. The ip 10.67.201.100 is going to be default GW for the LAN
>> Host and must remain reachable even if one of the core switches
>> goes down. When I assign IP address to either G0/2.4012010 or
>> G0/3.4012010 sub interfaces I'm able to ping it from the Host. But
>> after bridging them I can't ping BVI1 from the Host. What am I
>> doing wrong? Is it supposed to work this way?
>>
>> Regards, Victor
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

From chris.fournier at dal.ca  Mon Jul  6 10:34:25 2009
From: chris.fournier at dal.ca (Chris Fournier)
Date: Mon, 06 Jul 2009 11:34:25 -0300
Subject: [c-nsp] Multipoint L2TPv3?
Message-ID: <1246890865.3156.25.camel@linux-xvcs>


Does anyone have a mesh/multipoint instance of L2TPv3? What
documentation I come across hints that this may be possible, but I
haven't seen any specific configuration examples. 

I'm looking to establish a TLS service akin to VPLS.

Cheers!

-- 
Chris


From ip at ioshints.info  Mon Jul  6 12:08:17 2009
From: ip at ioshints.info (Ivan Pepelnjak)
Date: Mon, 6 Jul 2009 18:08:17 +0200
Subject: [c-nsp] IOS XR BFD
In-Reply-To: <70B7A1CCBFA5C649BD562B6D9F7ED7840798ECBA@xmb-ams-333.emea.cisco.com>
References: <501de4ea0907022344o2d57271cob04635b8f8557b6f@mail.gmail.com><100362309621454DAA534950B17E55DB0116319951F1@isp-per-exc01.win2k.iinet.net.au><1246613652_586037@mail1.tellurian.net><480dad640907030928g409fb93cle53eca875bae3c31@mail.gmail.com><501de4ea0907032319y60b0ef9ahb0d246bb245ad7f4@mail.gmail.com><77c10e260907041340x5177e348h2eadca6d4928c75c@mail.gmail.com><501de4ea0907042250t64f4514m9350c45e398330b1@mail.gmail.com><77c10e260907050559i4bfd323ch41435b5446efd333@mail.gmail.com><501de4ea0907050902i675d53basfca4350ecabeabfe@mail.gmail.com>
	<70B7A1CCBFA5C649BD562B6D9F7ED7840798ECBA@xmb-ams-333.emea.cisco.com>
Message-ID: <004301c9fe53$fa010000$0a00000a@nil.si>

> > And my question is not how I should be in this situation.
> > What is the logical explanation that BFD does not work in internal 
> > neighbors?
> 
> because it hasn't been developed to work in this scenario 
> under XR, which is likely due because it's not a commonly 
> deployed setup.

... because most Service Provider designs use IGP to address next-hop
reachability issues and convergence and BGP solely to transport reachability
information (which IP prefix is reachable through which next-hop). And,
lacking the infinite development resources, Cisco (and all other vendors)
usually implement what people that buy lots of boxes use in their networks
(that's why the IS-IS implementation is so good).

BTW, even the more "traditional" fast convergence techniques (internal BGP
fast fallover) might be too aggressive and do more harm than good.

Ivan
 
http://www.ioshints.info/about
http://blog.ioshints.info/



From moua0100 at umn.edu  Mon Jul  6 12:29:46 2009
From: moua0100 at umn.edu (Ge Moua)
Date: Mon, 06 Jul 2009 11:29:46 -0500
Subject: [c-nsp] Multipoint L2TPv3?
In-Reply-To: <1246890865.3156.25.camel@linux-xvcs>
References: <1246890865.3156.25.camel@linux-xvcs>
Message-ID: <4A52267A.8040605@umn.edu>

I too didn't think that this was possbile; I'd be interested to know if 
this can be done; I think I"ve seen example of EoMPLS x-connect doing 
mesh/multipoint otherwise as Chris Fournier mentioned you have the VPLS 
option.

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

Network Design Engineer
University of Minnesota | Networking & Telecommunications Services
2218 University Ave SE | Minneapolis, MN 55414-3029
Office: 612.626.2779 | Pager: 612.648.0103 | Fax: 612.626.1818



Chris Fournier wrote:
> Does anyone have a mesh/multipoint instance of L2TPv3? What
> documentation I come across hints that this may be possible, but I
> haven't seen any specific configuration examples. 
>
> I'm looking to establish a TLS service akin to VPLS.
>
> Cheers!
>
>   

From gul at gul.kiev.ua  Mon Jul  6 12:13:08 2009
From: gul at gul.kiev.ua (Pavel Gulchouck)
Date: Mon, 6 Jul 2009 19:13:08 +0300
Subject: [c-nsp] 6500 DFC QoS
Message-ID: <20090706161307.GB27775@happy.kiev.ua>

Hi.

I have some problems with QoS on DFC-featured module (WS-X6708-10GE).
6500/sup720/pfc3bxl, 12.2(18)SXF15.

At first, I cannot limit egress traffic for SVI, because traffic from 
this module and traffic from another modules policing separately, so 
customer can get twice more traffic then specified in service-policy 
on his SVI. Is any solution?

Second, dscp marking does not work for traffic incoming from this module 
and outgoing to another module. Config related to this issue:

mls qos
no mls qos rewrite ip dscp
!
class-map match-all dscp1
  match  dscp 1
!
policy-map from-10
  class class-default
   set dscp 1
!
policy-map to-20
  class dscp1
   police cir 300000000 bc 1000000 be 2000000 conform-action transmit exceed-action drop violate-action drop
  class class-default
   police cir 650000000 bc 1000000 be 2000000 conform-action transmit exceed-action drop violate-action drop
!
interface Vlan10
 ip address 10.0.0.1 255.255.255.0
 platform ip features sequential  
 service-policy input from-10
!
interface Vlan20
 ip address 10.0.1.1 255.255.255.0
 service-policy output to-20

Vlan10 allowed only on DFC-equipped module. I see only little 
traffic matching class dscp1, I think it's traffic with such dscp 
on ip header, but interface is untrusted and I suppose this 
service-map should matches internal (not real) dscp which set by
service-map from-10.
This config works good if vlan10 switched to another module (without DFC).
If I set "mls qos rewrite ip dscp" then marking and matching works good, 
but I do not want to modify IP headers.
Any suggestions?

May be there's a way to turn off DFC and use PFC?

-- 
Pavel

From bacon at walleyesoftware.com  Mon Jul  6 12:56:25 2009
From: bacon at walleyesoftware.com (Jeff Bacon)
Date: Mon, 6 Jul 2009 11:56:25 -0500
Subject: [c-nsp] Q-in-Q over a switchport trunk
In-Reply-To: <mailman.3.1246896002.71396.cisco-nsp@puck.nether.net>
References: <mailman.3.1246896002.71396.cisco-nsp@puck.nether.net>
Message-ID: <5A69C25361FED34F83ABF05F5047524505CD810F@wally.walleyetrading.net>

<flame suit on>
I know this seems stupid. But it's what I've got to work with.


I have several metro-e point-to-points from a major provider. Their CPE
is a ME3400-class, which is connected to my cat6504 via a gig SMF. The
connection is configured as a dot1q trunk, with each of the P-T-Ps
coming in to me on different VLANs. 

My hardware: sup720-3B, X6816A/DFC3B, 12.2(18)SXF8 (moving to 33SXH4). 

Right now, the configuration is straightforward: 

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

interface GigabitEthernet2/1
 switchport
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 3000-3100
 switchport mode trunk
 switchport vlan mapping enable
 switchport vlan mapping 3467 3004
 switchport vlan mapping 3610 3003
 switchport vlan mapping 3654 3006
 switchport vlan mapping 3755 3005
 switchport vlan mapping 3795 3002
 switchport vlan mapping 3843 3001
 no ip address
 load-interval 60
 speed nonegotiate
 no cdp enable
 no mop enabled
 spanning-tree bpdufilter enable 


int vlan3001 
  ip address blah
  do something useful;
int vlan 3002
   same
...

int g4/46 
  switchport 
  switchport access vlan 3005
  switchport mode access

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

In other words, some ckts I terminate L3 on the 6500, and some I pass
through as L2 to other devices. 


A new ckt/VLAN-appearance is being installed. I'd _really_ like to be
able to use it as a dot1q trunk to the other site.

(The other site will just be a gig line into a switch and I can trunk
away, on that end. The provider is doing EoMPLS and will happily support
double-tagging.) 

Q-in-Q seems straightforward, if I was using sub-interfaces and
terminating all of the ckts on the 6500 - encapsulation dot1q blah
second-dot1q blabla. But I'm not, and I can't (or don't think I can),
because I _have_ to pass at least one of the point-to-points through as
L2 to another device. 

Is there a way to do this or am I whistlin' in the breeze? 

Thanks,
-bacon


From pkranz at unwiredltd.com  Mon Jul  6 15:24:55 2009
From: pkranz at unwiredltd.com (Peter Kranz)
Date: Mon, 6 Jul 2009 12:24:55 -0700
Subject: [c-nsp] Netflow Collector shows minimal bandwidth from 6509
In-Reply-To: <200907061638.59842.andy-lists@bourges.de>
References: <505D3C9734BC4BBA8249E637EC5F2A71@usicorp.usinternet.com>
	<200907061638.59842.andy-lists@bourges.de>
Message-ID: <036101c9fe6f$71c60e80$55522b80$@com>

We needed the following to see all of the flow data (we use sampling as
well):

int x/x
 ip flow ingress
 ip route-cache flow
 mls netflow sampling

Peter Kranz
Founder/CEO - Unwired Ltd
www.UnwiredLtd.com
Desk: 510-868-1614 x100
Mobile: 510-207-0000
pkranz at unwiredltd.com


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Andreas Bourges
Sent: Monday, July 06, 2009 7:39 AM
To: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Netflow Collector shows minimal bandwidth from 6509

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

Hi,

On Monday 06 July 2009 16:01:42 Justin Krejci wrote:
>
>
> interface GigabitEthernet5/1
>
>  ip flow ingress
>
>  ip flow egress

...ip flow egress will only catch the software-processed flows. So you will 
need to modify your netflow setup to enable ip flow ingress on all layer3 
interfaces to catch all output traffic for gig5/1.

which doesn't explain why you're still missing 50% of your ingress flows ?!


Regards,

Andy

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkpSDH0ACgkQRrny/uOBVy43UACgoOdfbyaS8X8Td34Twi5OUJID
RAEAnjZiiCWqdDBiNXavjk5DTkLBr+ei
=9gLx
-----END PGP SIGNATURE-----
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


From kgraham at industrial-marshmallow.com  Mon Jul  6 16:23:32 2009
From: kgraham at industrial-marshmallow.com (Kevin Graham)
Date: Mon, 6 Jul 2009 13:23:32 -0700 (PDT)
Subject: [c-nsp] 2gb on 720BXL w/ SXI
Message-ID: <40934.66328.qm@web1215.biz.mail.gq1.yahoo.com>



Stumbled across this when reading SXI release notes, which is the only mention I'd seen of it. As of SXI, 2gb of DRAM is supported on both RP and SP of Sup720BXL. Not sure what the motivation was to take SP up, but MSFC3 w/ 2gb takes some of the sting out of MSFC4 getting blocked on 6500...

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/release/notes/ol_14271.html#wp4148909

From jkrejci at usinternet.com  Mon Jul  6 17:19:22 2009
From: jkrejci at usinternet.com (Justin Krejci)
Date: Mon, 6 Jul 2009 16:19:22 -0500
Subject: [c-nsp] Netflow Collector shows minimal bandwidth from 6509
In-Reply-To: <036101c9fe6f$71c60e80$55522b80$@com>
References: <505D3C9734BC4BBA8249E637EC5F2A71@usicorp.usinternet.com><200907061638.59842.andy-lists@bourges.de>
	<036101c9fe6f$71c60e80$55522b80$@com>
Message-ID: <53AE08713AC24864A1C1A91896A4559E@usicorp.usinternet.com>

Thanks,

ip flow ingress is already defined on my setup

We are trying to avoid sampling (currently we're not seeing any contention
or other load issues)

Apparently when putting in "ip route-cache flow" it changes the syntax to
"ip flow ingress"

conf t
int g5/1
no ip flow ingress
no ip route-cache flow
ip route-cache flow
end
show run | section interface GigabitEthernet5/1

yields: 
ip flow ingress


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Peter Kranz
Sent: Monday, July 06, 2009 2:25 PM
To: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Netflow Collector shows minimal bandwidth from 6509

We needed the following to see all of the flow data (we use sampling as
well):

int x/x
 ip flow ingress
 ip route-cache flow
 mls netflow sampling

Peter Kranz
Founder/CEO - Unwired Ltd
www.UnwiredLtd.com
Desk: 510-868-1614 x100
Mobile: 510-207-0000
pkranz at unwiredltd.com


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Andreas Bourges
Sent: Monday, July 06, 2009 7:39 AM
To: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Netflow Collector shows minimal bandwidth from 6509

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

Hi,

On Monday 06 July 2009 16:01:42 Justin Krejci wrote:
>
>
> interface GigabitEthernet5/1
>
>  ip flow ingress
>
>  ip flow egress

...ip flow egress will only catch the software-processed flows. So you will 
need to modify your netflow setup to enable ip flow ingress on all layer3 
interfaces to catch all output traffic for gig5/1.

which doesn't explain why you're still missing 50% of your ingress flows ?!


Regards,

Andy

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkpSDH0ACgkQRrny/uOBVy43UACgoOdfbyaS8X8Td34Twi5OUJID
RAEAnjZiiCWqdDBiNXavjk5DTkLBr+ei
=9gLx
-----END PGP SIGNATURE-----
_______________________________________________
cisco-nsp mailing 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 jarruda-cnsp at jarruda.com  Mon Jul  6 17:41:20 2009
From: jarruda-cnsp at jarruda.com (Julio Arruda)
Date: Mon, 06 Jul 2009 17:41:20 -0400
Subject: [c-nsp] Netflow Collector shows minimal bandwidth from 6509
In-Reply-To: <53AE08713AC24864A1C1A91896A4559E@usicorp.usinternet.com>
References: <505D3C9734BC4BBA8249E637EC5F2A71@usicorp.usinternet.com><200907061638.59842.andy-lists@bourges.de>	<036101c9fe6f$71c60e80$55522b80$@com>
	<53AE08713AC24864A1C1A91896A4559E@usicorp.usinternet.com>
Message-ID: <4A526F80.8000706@jarruda.com>

Justin Krejci wrote:
> Thanks,
> 
> ip flow ingress is already defined on my setup
> 
> We are trying to avoid sampling (currently we're not seeing any contention
> or other load issues)

As I understand, netflow sampling in the current 7600/6500 based gear, 
would not help with Netflow TCAM contention...

Is more on the lines of "after-the-fact", it will do some kind of 
sampling of the already collected information..
EARL8, like in the Nexus 7K, is supposed to do packet-sampling 'as other 
  boxes do', before creating the netflow entry.

> 
> Apparently when putting in "ip route-cache flow" it changes the syntax to
> "ip flow ingress"
> 
> conf t
> int g5/1
> no ip flow ingress
> no ip route-cache flow
> ip route-cache flow
> end
> show run | section interface GigabitEthernet5/1
> 
> yields: 
> ip flow ingress
> 
> 
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Peter Kranz
> Sent: Monday, July 06, 2009 2:25 PM
> To: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] Netflow Collector shows minimal bandwidth from 6509
> 
> We needed the following to see all of the flow data (we use sampling as
> well):
> 
> int x/x
>  ip flow ingress
>  ip route-cache flow
>  mls netflow sampling
> 
> Peter Kranz
> Founder/CEO - Unwired Ltd
> www.UnwiredLtd.com
> Desk: 510-868-1614 x100
> Mobile: 510-207-0000
> pkranz at unwiredltd.com
> 
> 
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Andreas Bourges
> Sent: Monday, July 06, 2009 7:39 AM
> To: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] Netflow Collector shows minimal bandwidth from 6509
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 
> On Monday 06 July 2009 16:01:42 Justin Krejci wrote:
>>
>> interface GigabitEthernet5/1
>>
>>  ip flow ingress
>>
>>  ip flow egress
> 
> ...ip flow egress will only catch the software-processed flows. So you will 
> need to modify your netflow setup to enable ip flow ingress on all layer3 
> interfaces to catch all output traffic for gig5/1.
> 
> which doesn't explain why you're still missing 50% of your ingress flows ?!
> 
> 
> Regards,
> 
> Andy
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> 
> iEYEARECAAYFAkpSDH0ACgkQRrny/uOBVy43UACgoOdfbyaS8X8Td34Twi5OUJID
> RAEAnjZiiCWqdDBiNXavjk5DTkLBr+ei
> =9gLx
> -----END PGP SIGNATURE-----
> _______________________________________________
> cisco-nsp mailing 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 nbernadeau at gallantsys.com  Mon Jul  6 18:45:52 2009
From: nbernadeau at gallantsys.com (Nathaniel Bernadeau)
Date: Mon, 06 Jul 2009 18:45:52 -0400
Subject: [c-nsp] BPX-BCC-4V/B is timing out
Message-ID: <4A527EA0.9000306@gallantsys.com>

Anyone here familiar with this card?

-- 
thanks

Nathaniel Bernadeau
Gallant Systems,  LLC



From DLasher at newedgenetworks.com  Mon Jul  6 19:40:39 2009
From: DLasher at newedgenetworks.com (Lasher, Donn)
Date: Mon, 6 Jul 2009 16:40:39 -0700
Subject: [c-nsp] Same-Router VRRP / HSRP
Message-ID: <C97F73E15F1F0D48A3AC0C423F8C221A018FD02D@rancor.ad.newedgenetworks.com>

 

LAN on a switch, multiple PC's. .Single router with 1+ Ethernet ports.
What's the currently recommended method of handing off redundant LAN
connections on the same physical router? (I looked at but not into GLBP,
maybe that?) HSRP and VRRP complain about IP overlap when done on the
same router..

 

Thoughts?

 


From william.mccall at gmail.com  Mon Jul  6 21:00:16 2009
From: william.mccall at gmail.com (William McCall)
Date: Mon, 6 Jul 2009 20:00:16 -0500
Subject: [c-nsp] Same-Router VRRP / HSRP
In-Reply-To: <C97F73E15F1F0D48A3AC0C423F8C221A018FD02D@rancor.ad.newedgenetworks.com>
References: <C97F73E15F1F0D48A3AC0C423F8C221A018FD02D@rancor.ad.newedgenetworks.com>
Message-ID: <f9a8f300907061800k13a0a0e4sa967fcc9a154e9ad@mail.gmail.com>

Bvi?

On 7/6/09, Lasher, Donn <DLasher at newedgenetworks.com> wrote:
>
>
> LAN on a switch, multiple PC's. .Single router with 1+ Ethernet ports.
> What's the currently recommended method of handing off redundant LAN
> connections on the same physical router? (I looked at but not into GLBP,
> maybe that?) HSRP and VRRP complain about IP overlap when done on the
> same router..
>
>
>
> Thoughts?
>
>
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From tstevens at cisco.com  Mon Jul  6 21:13:03 2009
From: tstevens at cisco.com (Tim Stevenson)
Date: Mon, 06 Jul 2009 18:13:03 -0700
Subject: [c-nsp] Netflow Collector shows minimal bandwidth from 6509
In-Reply-To: <53AE08713AC24864A1C1A91896A4559E@usicorp.usinternet.com>
References: <505D3C9734BC4BBA8249E637EC5F2A71@usicorp.usinternet.com>
	<200907061638.59842.andy-lists@bourges.de>
	<036101c9fe6f$71c60e80$55522b80$@com>
	<53AE08713AC24864A1C1A91896A4559E@usicorp.usinternet.com>
Message-ID: <200907070113.n671D7Y6016180@sj-core-1.cisco.com>

Yes, the syntax changed and ip route-cache flow is now changed to ip 
flow ingress.

As others pointed out, c6k only supports ingress NF for unicast, so 
ip flow egress will only capture egress flows that were software 
routed (should be very few). Why you are only getting ~50% of the 
ingress records is a puzzle. Might be a tough correllation exercise 
to figure it out.

The config looks ok, only thing I can suggest is open a case.... :(

Tim

At 02:19 PM 7/6/2009, Justin Krejci noted:

>Thanks,
>
>ip flow ingress is already defined on my setup
>
>We are trying to avoid sampling (currently we're not seeing any contention
>or other load issues)
>
>Apparently when putting in "ip route-cache flow" it changes the syntax to
>"ip flow ingress"
>
>conf t
>int g5/1
>no ip flow ingress
>no ip route-cache flow
>ip route-cache flow
>end
>show run | section interface GigabitEthernet5/1
>
>yields:
>ip flow ingress
>
>
>-----Original Message-----
>From: cisco-nsp-bounces at puck.nether.net
>[<mailto:cisco-nsp-bounces at puck.nether.net>mailto:cisco-nsp-bounces at puck.nether.net] 
>On Behalf Of Peter Kranz
>Sent: Monday, July 06, 2009 2:25 PM
>To: cisco-nsp at puck.nether.net
>Subject: Re: [c-nsp] Netflow Collector shows minimal bandwidth from 6509
>
>We needed the following to see all of the flow data (we use sampling as
>well):
>
>int x/x
>  ip flow ingress
>  ip route-cache flow
>  mls netflow sampling
>
>Peter Kranz
>Founder/CEO - Unwired Ltd
>www.UnwiredLtd.com
>Desk: 510-868-1614 x100
>Mobile: 510-207-0000
>pkranz at unwiredltd.com
>
>
>-----Original Message-----
>From: cisco-nsp-bounces at puck.nether.net
>[<mailto:cisco-nsp-bounces at puck.nether.net>mailto:cisco-nsp-bounces at puck.nether.net] 
>On Behalf Of Andreas Bourges
>Sent: Monday, July 06, 2009 7:39 AM
>To: cisco-nsp at puck.nether.net
>Subject: Re: [c-nsp] Netflow Collector shows minimal bandwidth from 6509
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Hi,
>
>On Monday 06 July 2009 16:01:42 Justin Krejci wrote:
> >
> >
> > interface GigabitEthernet5/1
> >
> >  ip flow ingress
> >
> >  ip flow egress
>
>...ip flow egress will only catch the software-processed flows. So you will
>need to modify your netflow setup to enable ip flow ingress on all layer3
>interfaces to catch all output traffic for gig5/1.
>
>which doesn't explain why you're still missing 50% of your ingress flows ?!
>
>
>Regards,
>
>Andy
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.9 (GNU/Linux)
>
>iEYEARECAAYFAkpSDH0ACgkQRrny/uOBVy43UACgoOdfbyaS8X8Td34Twi5OUJID
>RAEAnjZiiCWqdDBiNXavjk5DTkLBr+ei
>=9gLx
>-----END PGP SIGNATURE-----
>_______________________________________________
>cisco-nsp mailing list  cisco-nsp at puck.nether.net
><https://puck.nether.net/mailman/listinfo/cisco-nsp>https://puck.nether.net/mailman/listinfo/cisco-nsp
>archive at 
><http://puck.nether.net/pipermail/cisco-nsp/>http://puck.nether.net/pipermail/cisco-nsp/
>
>_______________________________________________
>cisco-nsp mailing list  cisco-nsp at puck.nether.net
><https://puck.nether.net/mailman/listinfo/cisco-nsp>https://puck.nether.net/mailman/listinfo/cisco-nsp
>archive at 
><http://puck.nether.net/pipermail/cisco-nsp/>http://puck.nether.net/pipermail/cisco-nsp/
>
>_______________________________________________
>cisco-nsp mailing list  cisco-nsp at puck.nether.net
><https://puck.nether.net/mailman/listinfo/cisco-nsp>https://puck.nether.net/mailman/listinfo/cisco-nsp
>archive at 
><http://puck.nether.net/pipermail/cisco-nsp/>http://puck.nether.net/pipermail/cisco-nsp/




Tim Stevenson, tstevens at cisco.com
Routing & Switching CCIE #5561
Technical Marketing Engineer, Cisco Nexus 7000
Cisco - http://www.cisco.com
IP Phone: 408-526-6759
********************************************************
The contents of this message may be *Cisco Confidential*
and are intended for the specified recipients only.

From tstevens at cisco.com  Mon Jul  6 21:15:38 2009
From: tstevens at cisco.com (Tim Stevenson)
Date: Mon, 06 Jul 2009 18:15:38 -0700
Subject: [c-nsp] Netflow Collector shows minimal bandwidth from 6509
In-Reply-To: <4A526F80.8000706@jarruda.com>
References: <505D3C9734BC4BBA8249E637EC5F2A71@usicorp.usinternet.com>
	<200907061638.59842.andy-lists@bourges.de>
	<036101c9fe6f$71c60e80$55522b80$@com>
	<53AE08713AC24864A1C1A91896A4559E@usicorp.usinternet.com>
	<4A526F80.8000706@jarruda.com>
Message-ID: <200907070115.n671FjHI001254@sj-core-3.cisco.com>

At 02:41 PM 7/6/2009, Julio Arruda noted:

>Justin Krejci wrote:
> > Thanks,
> >
> > ip flow ingress is already defined on my setup
> >
> > We are trying to avoid sampling (currently we're not seeing any contention
> > or other load issues)
>
>As I understand, netflow sampling in the current 7600/6500 based gear,
>would not help with Netflow TCAM contention...
>
>Is more on the lines of "after-the-fact", it will do some kind of
>sampling of the already collected information..

Correct, it is a sampling of the flows that made it into the hw. It 
does not appear from the outputs that any significant contention is happening.


>EARL8, like in the Nexus 7K, is supposed to do packet-sampling 'as other
>   boxes do', before creating the netflow entry.

That it does, we do both full & sampled NF. Eg, with 1 in 1000 
sampling, 1 packet out of 1000 passing the interface in the specified 
direction (7k supports both ingress & egress NF) is sampled, and that 
packet creates/updates a flow entry in the hw table.

Once in the hw, the flow entry is treated as any other, ie, updated, 
aged, exported.


HTH,
Tim


> >
> > Apparently when putting in "ip route-cache flow" it changes the syntax to
> > "ip flow ingress"
> >
> > conf t
> > int g5/1
> > no ip flow ingress
> > no ip route-cache flow
> > ip route-cache flow
> > end
> > show run | section interface GigabitEthernet5/1
> >
> > yields:
> > ip flow ingress
> >
> >
> > -----Original Message-----
> > From: cisco-nsp-bounces at puck.nether.net
> > 
> [<mailto:cisco-nsp-bounces at puck.nether.net>mailto:cisco-nsp-bounces at puck.nether.net] 
> On Behalf Of Peter Kranz
> > Sent: Monday, July 06, 2009 2:25 PM
> > To: cisco-nsp at puck.nether.net
> > Subject: Re: [c-nsp] Netflow Collector shows minimal bandwidth from 6509
> >
> > We needed the following to see all of the flow data (we use sampling as
> > well):
> >
> > int x/x
> >  ip flow ingress
> >  ip route-cache flow
> >  mls netflow sampling
> >
> > Peter Kranz
> > Founder/CEO - Unwired Ltd
> > www.UnwiredLtd.com
> > Desk: 510-868-1614 x100
> > Mobile: 510-207-0000
> > pkranz at unwiredltd.com
> >
> >
> > -----Original Message-----
> > From: cisco-nsp-bounces at puck.nether.net
> > 
> [<mailto:cisco-nsp-bounces at puck.nether.net>mailto:cisco-nsp-bounces at puck.nether.net] 
> On Behalf Of Andreas Bourges
> > Sent: Monday, July 06, 2009 7:39 AM
> > To: cisco-nsp at puck.nether.net
> > Subject: Re: [c-nsp] Netflow Collector shows minimal bandwidth from 6509
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Hi,
> >
> > On Monday 06 July 2009 16:01:42 Justin Krejci wrote:
> >>
> >> interface GigabitEthernet5/1
> >>
> >>  ip flow ingress
> >>
> >>  ip flow egress
> >
> > ...ip flow egress will only catch the software-processed flows. So you will
> > need to modify your netflow setup to enable ip flow ingress on all layer3
> > interfaces to catch all output traffic for gig5/1.
> >
> > which doesn't explain why you're still missing 50% of your ingress flows ?!
> >
> >
> > Regards,
> >
> > Andy
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.9 (GNU/Linux)
> >
> > iEYEARECAAYFAkpSDH0ACgkQRrny/uOBVy43UACgoOdfbyaS8X8Td34Twi5OUJID
> > RAEAnjZiiCWqdDBiNXavjk5DTkLBr+ei
> > =9gLx
> > -----END PGP SIGNATURE-----
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > 
> <https://puck.nether.net/mailman/listinfo/cisco-nsp>https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at 
> <http://puck.nether.net/pipermail/cisco-nsp/>http://puck.nether.net/pipermail/cisco-nsp/
> >
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > 
> <https://puck.nether.net/mailman/listinfo/cisco-nsp>https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at 
> <http://puck.nether.net/pipermail/cisco-nsp/>http://puck.nether.net/pipermail/cisco-nsp/
> >
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > 
> <https://puck.nether.net/mailman/listinfo/cisco-nsp>https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at 
> <http://puck.nether.net/pipermail/cisco-nsp/>http://puck.nether.net/pipermail/cisco-nsp/
>
>_______________________________________________
>cisco-nsp mailing list  cisco-nsp at puck.nether.net
><https://puck.nether.net/mailman/listinfo/cisco-nsp>https://puck.nether.net/mailman/listinfo/cisco-nsp
>archive at 
><http://puck.nether.net/pipermail/cisco-nsp/>http://puck.nether.net/pipermail/cisco-nsp/




Tim Stevenson, tstevens at cisco.com
Routing & Switching CCIE #5561
Technical Marketing Engineer, Cisco Nexus 7000
Cisco - http://www.cisco.com
IP Phone: 408-526-6759
********************************************************
The contents of this message may be *Cisco Confidential*
and are intended for the specified recipients only.

From zivl at gilat.net  Tue Jul  7 02:35:02 2009
From: zivl at gilat.net (Ziv Leyes)
Date: Tue, 7 Jul 2009 09:35:02 +0300
Subject: [c-nsp] Q-in-Q over a switchport trunk
In-Reply-To: <5A69C25361FED34F83ABF05F5047524505CD810F@wally.walleyetrading.net>
References: <mailman.3.1246896002.71396.cisco-nsp@puck.nether.net>
	<5A69C25361FED34F83ABF05F5047524505CD810F@wally.walleyetrading.net>
Message-ID: <EC993E87D960A541A66BF21D62AA42A623014B4542@exch2k7.gilat.local>

This answer may seem stupid as well, and is actually a question more than an answer...
Does L2TPv3 come in count for this case?


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Jeff Bacon
Sent: Monday, July 06, 2009 6:56 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Q-in-Q over a switchport trunk

<flame suit on>
I know this seems stupid. But it's what I've got to work with.


I have several metro-e point-to-points from a major provider. Their CPE
is a ME3400-class, which is connected to my cat6504 via a gig SMF. The
connection is configured as a dot1q trunk, with each of the P-T-Ps
coming in to me on different VLANs. 

My hardware: sup720-3B, X6816A/DFC3B, 12.2(18)SXF8 (moving to 33SXH4). 

Right now, the configuration is straightforward: 

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

interface GigabitEthernet2/1
 switchport
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 3000-3100
 switchport mode trunk
 switchport vlan mapping enable
 switchport vlan mapping 3467 3004
 switchport vlan mapping 3610 3003
 switchport vlan mapping 3654 3006
 switchport vlan mapping 3755 3005
 switchport vlan mapping 3795 3002
 switchport vlan mapping 3843 3001
 no ip address
 load-interval 60
 speed nonegotiate
 no cdp enable
 no mop enabled
 spanning-tree bpdufilter enable 


int vlan3001 
  ip address blah
  do something useful;
int vlan 3002
   same
...

int g4/46 
  switchport 
  switchport access vlan 3005
  switchport mode access

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

In other words, some ckts I terminate L3 on the 6500, and some I pass
through as L2 to other devices. 


A new ckt/VLAN-appearance is being installed. I'd _really_ like to be
able to use it as a dot1q trunk to the other site.

(The other site will just be a gig line into a switch and I can trunk
away, on that end. The provider is doing EoMPLS and will happily support
double-tagging.) 

Q-in-Q seems straightforward, if I was using sub-interfaces and
terminating all of the ckts on the 6500 - encapsulation dot1q blah
second-dot1q blabla. But I'm not, and I can't (or don't think I can),
because I _have_ to pass at least one of the point-to-points through as
L2 to another device. 

Is there a way to do this or am I whistlin' in the breeze? 

Thanks,
-bacon

_______________________________________________
cisco-nsp mailing 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 victor.lyapunov at gmail.com  Tue Jul  7 03:54:32 2009
From: victor.lyapunov at gmail.com (Victor Lyapunov)
Date: Tue, 7 Jul 2009 10:54:32 +0300
Subject: [c-nsp] Cisco router DHCP accounting / option82
Message-ID: <bf19ffb40907070054k41e5e25du3c87792145bcb193@mail.gmail.com>

Hello all

I am experimenting with a 7200 router playing the role of DHCP server
for xDSL subscribers.
In this simple setup the 7200 is the first L3 node for the xDSL
subscribers. Apart from playing
the role of the default gateway, the 7200 using its local DHCP server
also handles the address
allocation  for the users.
One requirement is for the  DHCP server be able to store accounting
data about the bindings,
especially the option82 information inserted by the DSLAM in  the DHCP
requiests.

The DHCP accounting works (the router is able to inform a radius
server when it has performed
an IP allocation or release) but I have not been able to make the 7200
to also send the option82
information to the radius.
(I have verified that the option82 information indeed reaches the 7200).

I have experimented with various radius options (overiding nas-port-id
attribute with circuit-id)
but with no luck so far.

Has anyone succeded in making the DHCP server of a cisco router to
include the Option82
information in the accouting records it sends to a radius?

From blahu77 at gmail.com  Tue Jul  7 10:31:29 2009
From: blahu77 at gmail.com (Mateusz Blaszczyk)
Date: Tue, 7 Jul 2009 15:31:29 +0100
Subject: [c-nsp] IOS XR BFD
In-Reply-To: <004301c9fe53$fa010000$0a00000a@nil.si>
References: <501de4ea0907022344o2d57271cob04635b8f8557b6f@mail.gmail.com> 
	<1246613652_586037@mail1.tellurian.net>
	<480dad640907030928g409fb93cle53eca875bae3c31@mail.gmail.com> 
	<501de4ea0907032319y60b0ef9ahb0d246bb245ad7f4@mail.gmail.com> 
	<77c10e260907041340x5177e348h2eadca6d4928c75c@mail.gmail.com> 
	<501de4ea0907042250t64f4514m9350c45e398330b1@mail.gmail.com> 
	<77c10e260907050559i4bfd323ch41435b5446efd333@mail.gmail.com> 
	<501de4ea0907050902i675d53basfca4350ecabeabfe@mail.gmail.com> 
	<70B7A1CCBFA5C649BD562B6D9F7ED7840798ECBA@xmb-ams-333.emea.cisco.com> 
	<004301c9fe53$fa010000$0a00000a@nil.si>
Message-ID: <383357750907070731g677aa1fdm8638101f1bc0cdb2@mail.gmail.com>

Ivan,

>
> BTW, even the more "traditional" fast convergence techniques (internal BGP
> fast fallover) might be too aggressive and do more harm than good.
>

Could you elaborate little more on that?
I thought it would be a good idea (e.g. neighbor X fall-over
route-map) to drop BGP session with a neighbour that suddenly
"dissapeared" from the network.
In my scenario I am concerned that the scanner doesn't invalidate the
routes because I have catch-all aggregate covering all my NHs floating
there (I can't have full table so I have 0/0 from upstreams so I need
the aggregate for my routes) so in other words it takes 3 minutes to
close the broken session.

Best Regards,

-mat

From listacct at genhex.net  Tue Jul  7 13:51:57 2009
From: listacct at genhex.net (Jeff Crowe)
Date: Tue, 7 Jul 2009 13:51:57 -0400
Subject: [c-nsp] Bridging solution for 5 locations
Message-ID: <000001c9ff2b$9f7dace0$de7906a0$@net>

Hi all,

I am trying to establish a bridged solution for 5 locations that are served
via ADSL non-authenticated connections.  These ADSL connections are
delivered to us via a wholesale provider and we do not have the ability to
control the network or implement changes.

The network topology of the locations is a flat 192.168.0.x/24 with the
address space spread across each of the 5 locations.

Each separate ADSL connection is delivered to me via separate VLAN's over an
Ethernet trunk.  I have put that trunk into a Cisco 2651 and created a
bridge using IRB.  Data flows for a short while, but then packets stop
flowing between locations.  After some troubleshooting and guessing - I
think the problem is with MAC address flapping on the wholesale provider
network.  Either they have spanning tree enabled or mac-address learning
enabled on their core and this is causing my bridged connections to cause
grief on their network equipment and shut down the paths.

My question is:  What would be a simple solution to allow these 5 locations
to communicate between each other without changing the network topology?  I
looked into GRE tunnels, but they will not allow a broadcast network to span
multiple locations.  

Should I be looking into L2TPv3 type tunnels and put a CPE at each location
to control the tunnels?  If so - what is the lowest form of router that
could be used? (Cisco 17xx?).

Is it possible to do MAC NAT'ing on a Cisco device?  This would allow me to
keep the mac addresses separated on each vlan and still allow for bridging.

Thanks,

Jeff.






From drew.weaver at thenap.com  Tue Jul  7 15:49:16 2009
From: drew.weaver at thenap.com (Drew Weaver)
Date: Tue, 7 Jul 2009 15:49:16 -0400
Subject: [c-nsp] Baseline CoPP policies?
Message-ID: <F3318834F1F89D46857972DD4B411D7011C3D55F@EXCHANGE.thenap.com>

	Hi all,

	Does anyone have any baseline CoPP policies to put in place on a switch where you can't really anticipate the kind of traffic that will be coming into it but you need the IP INPUT processes, etc to stay at some level of control? 

I've seen the Cisco TTL Expiry attack documentation etc, are there any good generalized guidelines Cisco published or not?

Thanks,
-Drew



From daniel.dib at reaper.nu  Tue Jul  7 16:37:19 2009
From: daniel.dib at reaper.nu (Daniel Dib)
Date: Tue, 7 Jul 2009 22:37:19 +0200
Subject: [c-nsp] Baseline CoPP policies?
In-Reply-To: <F3318834F1F89D46857972DD4B411D7011C3D55F@EXCHANGE.thenap.com>
References: <F3318834F1F89D46857972DD4B411D7011C3D55F@EXCHANGE.thenap.com>
Message-ID: <000001c9ff42$b95d1760$2101a8c0@reap>


	Hi all,

	Does anyone have any baseline CoPP policies to put in place on a
switch where you can't really anticipate the kind of traffic that will be
coming into it but you need the IP INPUT processes, etc to stay at some
level of control? 

I've seen the Cisco TTL Expiry attack documentation etc, are there any good
generalized guidelines Cisco published or not?

Thanks,
-Drew

This will probably be highly dependant on what platform you are running.
What switch are we talking about? You should probably try to blast it with
different types of traffic to see what it can handle. Will you be running
dynamic routingprotocols? What protocols will you use for remote access etc?
More info is needed if we are going to try to answer your question.

/Daniel
 

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 4222 (20090707) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
 


From cluestore at gmail.com  Tue Jul  7 16:43:18 2009
From: cluestore at gmail.com (Clue Store)
Date: Tue, 7 Jul 2009 15:43:18 -0500
Subject: [c-nsp]  QoS on 837 using PPPoE
Message-ID: <580af3b90907071343i2f4cdabble3445111fe9d0466@mail.gmail.com>

Hi All,


I am having a hard time trying to figure how to apply a QoS policy on this
router. I have applied a few typical service-policies on the dialer
interfaces, but a "show policy interface di0" shows packets being matched
but nothing being dropped and the link is saturated. I believe the policy
needs to be applied to the virtual-access interface that comes up when PPP
negotiates, but i'm not quite sure how this would be done since the use of
vpdn-groups are no longer used. Relevent config posted. Any suggestions are
greatly appreciated. *And yes I know the service-policy is not applied to
the dialer interface...this was due to it not working.


class-map match-any VoIP
 match ip rtp 16384 16383
 match access-group name VoicePorts
!
!
policy-map Voice
 class VoIP
  priority 256
!
!
!
!
!
interface Ethernet0
 ip address 192.168.10.1 255.255.255.0
 ip nat inside
 ip virtual-reassembly
!
interface Ethernet2
 no ip address
 shutdown
 hold-queue 100 out
!
interface ATM0
 no ip address
 load-interval 30
 no atm ilmi-keepalive
 dsl operating-mode auto
!
interface ATM0.1 point-to-point
 pvc 1/100
  encapsulation aal5snap
  pppoe-client dial-pool-number 1
 !
!
interface FastEthernet1
 duplex auto
 speed auto
!
interface FastEthernet2
 duplex auto
 speed auto
!
interface FastEthernet3
 duplex auto
 speed auto
!
interface FastEthernet4
 duplex auto
 speed auto
!
!
interface Dialer0
 ip address negotiated
 ip mtu 1492
 ip nat outside
 ip virtual-reassembly
 encapsulation ppp
 ip tcp adjust-mss 1412
 dialer pool 1
 no cdp enable
<ppp info ************>
!
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 Dialer0
!
ip http server
no ip http secure-server
!
no ip nat service skinny tcp port 2000
no ip nat service sip udp port 5060
ip nat inside source list 10 interface Dialer0 overload
!
!
ip access-list extended VoicePorts
 permit udp any host *.*.*.* range 22026 62025
 permit udp any host *.*.*.* range 22026 62025
access-list 10 permit 192.168.10.0 0.0.0.255

From svalliap at cisco.com  Tue Jul  7 17:06:18 2009
From: svalliap at cisco.com (Siva Valliappan)
Date: Tue, 7 Jul 2009 14:06:18 -0700 (PDT)
Subject: [c-nsp] QoS on 837 using PPPoE
In-Reply-To: <580af3b90907071343i2f4cdabble3445111fe9d0466@mail.gmail.com>
References: <580af3b90907071343i2f4cdabble3445111fe9d0466@mail.gmail.com>
Message-ID: <Pine.GSO.4.64.0907071404280.8751@sj-cse-717.cisco.com>

IIRC you need to apply it on the ATM interface
e.g.

Interface ATM0.1 point-to-point
.
.
pvc 1/100
    service-policy output Voice

regards
.siva


On Tue, 7 Jul 2009, Clue Store wrote:

> Hi All,
>
>
> I am having a hard time trying to figure how to apply a QoS policy on this
> router. I have applied a few typical service-policies on the dialer
> interfaces, but a "show policy interface di0" shows packets being matched
> but nothing being dropped and the link is saturated. I believe the policy
> needs to be applied to the virtual-access interface that comes up when PPP
> negotiates, but i'm not quite sure how this would be done since the use of
> vpdn-groups are no longer used. Relevent config posted. Any suggestions are
> greatly appreciated. *And yes I know the service-policy is not applied to
> the dialer interface...this was due to it not working.
>
>
> class-map match-any VoIP
> match ip rtp 16384 16383
> match access-group name VoicePorts
> !
> !
> policy-map Voice
> class VoIP
>  priority 256
> !
> !
> !
> !
> !
> interface Ethernet0
> ip address 192.168.10.1 255.255.255.0
> ip nat inside
> ip virtual-reassembly
> !
> interface Ethernet2
> no ip address
> shutdown
> hold-queue 100 out
> !
> interface ATM0
> no ip address
> load-interval 30
> no atm ilmi-keepalive
> dsl operating-mode auto
> !
> interface ATM0.1 point-to-point
> pvc 1/100
>  encapsulation aal5snap
>  pppoe-client dial-pool-number 1
> !
> !
> interface FastEthernet1
> duplex auto
> speed auto
> !
> interface FastEthernet2
> duplex auto
> speed auto
> !
> interface FastEthernet3
> duplex auto
> speed auto
> !
> interface FastEthernet4
> duplex auto
> speed auto
> !
> !
> interface Dialer0
> ip address negotiated
> ip mtu 1492
> ip nat outside
> ip virtual-reassembly
> encapsulation ppp
> ip tcp adjust-mss 1412
> dialer pool 1
> no cdp enable
> <ppp info ************>
> !
> ip forward-protocol nd
> ip route 0.0.0.0 0.0.0.0 Dialer0
> !
> ip http server
> no ip http secure-server
> !
> no ip nat service skinny tcp port 2000
> no ip nat service sip udp port 5060
> ip nat inside source list 10 interface Dialer0 overload
> !
> !
> ip access-list extended VoicePorts
> permit udp any host *.*.*.* range 22026 62025
> permit udp any host *.*.*.* range 22026 62025
> access-list 10 permit 192.168.10.0 0.0.0.255
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From svalliap at cisco.com  Tue Jul  7 17:11:32 2009
From: svalliap at cisco.com (Siva Valliappan)
Date: Tue, 7 Jul 2009 14:11:32 -0700 (PDT)
Subject: [c-nsp] Baseline CoPP policies?
In-Reply-To: <000001c9ff42$b95d1760$2101a8c0@reap>
References: <F3318834F1F89D46857972DD4B411D7011C3D55F@EXCHANGE.thenap.com>
	<000001c9ff42$b95d1760$2101a8c0@reap>
Message-ID: <Pine.GSO.4.64.0907071410460.8751@sj-cse-717.cisco.com>

Hi Drew,

    have you looked at the following docs:

http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html

and

http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6642/prod_white_paper0900aecd804fa16a.html

regards
.siva

On Tue, 7 Jul 2009, Daniel Dib wrote:

>
> 	Hi all,
>
> 	Does anyone have any baseline CoPP policies to put in place on a
> switch where you can't really anticipate the kind of traffic that will be
> coming into it but you need the IP INPUT processes, etc to stay at some
> level of control?
>
> I've seen the Cisco TTL Expiry attack documentation etc, are there any good
> generalized guidelines Cisco published or not?
>
> Thanks,
> -Drew
>
> This will probably be highly dependant on what platform you are running.
> What switch are we talking about? You should probably try to blast it with
> different types of traffic to see what it can handle. Will you be running
> dynamic routingprotocols? What protocols will you use for remote access etc?
> More info is needed if we are going to try to answer your question.
>
> /Daniel
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus signature
> database 4222 (20090707) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.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 cluestore at gmail.com  Tue Jul  7 17:12:23 2009
From: cluestore at gmail.com (Clue Store)
Date: Tue, 7 Jul 2009 16:12:23 -0500
Subject: [c-nsp] QoS on 837 using PPPoE
In-Reply-To: <Pine.GSO.4.64.0907071404280.8751@sj-cse-717.cisco.com>
References: <580af3b90907071343i2f4cdabble3445111fe9d0466@mail.gmail.com>
	<Pine.GSO.4.64.0907071404280.8751@sj-cse-717.cisco.com>
Message-ID: <580af3b90907071412v1c9d8651s7a7fdcc4bb95fdd6@mail.gmail.com>

On A0.1.....

config-subif)#service-policy output Voice
CBWFQ : Not supported on subinterfaces

On A0

(config-if)#service-policy output Voice
CBWFQ : Not supported on this interface

It would seem out old ways of QoS have changed  ;)

On Tue, Jul 7, 2009 at 4:06 PM, Siva Valliappan <svalliap at cisco.com> wrote:

> IIRC you need to apply it on the ATM interface
> e.g.
>
> Interface ATM0.1 point-to-point
> .
> .
> pvc 1/100
>   service-policy output Voice
>
> regards
> .siva
>
>
>
> On Tue, 7 Jul 2009, Clue Store wrote:
>
>   Hi All,
>>
>>
>> I am having a hard time trying to figure how to apply a QoS policy on this
>> router. I have applied a few typical service-policies on the dialer
>> interfaces, but a "show policy interface di0" shows packets being matched
>> but nothing being dropped and the link is saturated. I believe the policy
>> needs to be applied to the virtual-access interface that comes up when PPP
>> negotiates, but i'm not quite sure how this would be done since the use of
>> vpdn-groups are no longer used. Relevent config posted. Any suggestions
>> are
>> greatly appreciated. *And yes I know the service-policy is not applied to
>> the dialer interface...this was due to it not working.
>>
>>
>> class-map match-any VoIP
>> match ip rtp 16384 16383
>> match access-group name VoicePorts
>> !
>> !
>> policy-map Voice
>> class VoIP
>>  priority 256
>> !
>> !
>> !
>> !
>> !
>> interface Ethernet0
>> ip address 192.168.10.1 255.255.255.0
>> ip nat inside
>> ip virtual-reassembly
>> !
>> interface Ethernet2
>> no ip address
>> shutdown
>> hold-queue 100 out
>> !
>> interface ATM0
>> no ip address
>> load-interval 30
>> no atm ilmi-keepalive
>> dsl operating-mode auto
>> !
>> interface ATM0.1 point-to-point
>> pvc 1/100
>>  encapsulation aal5snap
>>  pppoe-client dial-pool-number 1
>> !
>> !
>> interface FastEthernet1
>> duplex auto
>> speed auto
>> !
>> interface FastEthernet2
>> duplex auto
>> speed auto
>> !
>> interface FastEthernet3
>> duplex auto
>> speed auto
>> !
>> interface FastEthernet4
>> duplex auto
>> speed auto
>> !
>> !
>> interface Dialer0
>> ip address negotiated
>> ip mtu 1492
>> ip nat outside
>> ip virtual-reassembly
>> encapsulation ppp
>> ip tcp adjust-mss 1412
>> dialer pool 1
>> no cdp enable
>> <ppp info ************>
>> !
>> ip forward-protocol nd
>> ip route 0.0.0.0 0.0.0.0 Dialer0
>> !
>> ip http server
>> no ip http secure-server
>> !
>> no ip nat service skinny tcp port 2000
>> no ip nat service sip udp port 5060
>> ip nat inside source list 10 interface Dialer0 overload
>> !
>> !
>> ip access-list extended VoicePorts
>> permit udp any host *.*.*.* range 22026 62025
>> permit udp any host *.*.*.* range 22026 62025
>> access-list 10 permit 192.168.10.0 0.0.0.255
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>>

From cluestore at gmail.com  Tue Jul  7 17:16:09 2009
From: cluestore at gmail.com (Clue Store)
Date: Tue, 7 Jul 2009 16:16:09 -0500
Subject: [c-nsp] QoS on 837 using PPPoE
In-Reply-To: <Pine.GSO.4.64.0907071404280.8751@sj-cse-717.cisco.com>
References: <580af3b90907071343i2f4cdabble3445111fe9d0466@mail.gmail.com>
	<Pine.GSO.4.64.0907071404280.8751@sj-cse-717.cisco.com>
Message-ID: <580af3b90907071416u69853e7co5aa77fe3f5235793@mail.gmail.com>

My apologies, I did not apply it under the PVC section. It took that just
fine and would make sense that the policy is applied to the VC itself. I
will test and see how well this works.

Thanks

On Tue, Jul 7, 2009 at 4:06 PM, Siva Valliappan <svalliap at cisco.com> wrote:

> IIRC you need to apply it on the ATM interface
> e.g.
>
> Interface ATM0.1 point-to-point
> .
> .
> pvc 1/100
>   service-policy output Voice
>
> regards
> .siva
>
>
>
> On Tue, 7 Jul 2009, Clue Store wrote:
>
>   Hi All,
>>
>>
>> I am having a hard time trying to figure how to apply a QoS policy on this
>> router. I have applied a few typical service-policies on the dialer
>> interfaces, but a "show policy interface di0" shows packets being matched
>> but nothing being dropped and the link is saturated. I believe the policy
>> needs to be applied to the virtual-access interface that comes up when PPP
>> negotiates, but i'm not quite sure how this would be done since the use of
>> vpdn-groups are no longer used. Relevent config posted. Any suggestions
>> are
>> greatly appreciated. *And yes I know the service-policy is not applied to
>> the dialer interface...this was due to it not working.
>>
>>
>> class-map match-any VoIP
>> match ip rtp 16384 16383
>> match access-group name VoicePorts
>> !
>> !
>> policy-map Voice
>> class VoIP
>>  priority 256
>> !
>> !
>> !
>> !
>> !
>> interface Ethernet0
>> ip address 192.168.10.1 255.255.255.0
>> ip nat inside
>> ip virtual-reassembly
>> !
>> interface Ethernet2
>> no ip address
>> shutdown
>> hold-queue 100 out
>> !
>> interface ATM0
>> no ip address
>> load-interval 30
>> no atm ilmi-keepalive
>> dsl operating-mode auto
>> !
>> interface ATM0.1 point-to-point
>> pvc 1/100
>>  encapsulation aal5snap
>>  pppoe-client dial-pool-number 1
>> !
>> !
>> interface FastEthernet1
>> duplex auto
>> speed auto
>> !
>> interface FastEthernet2
>> duplex auto
>> speed auto
>> !
>> interface FastEthernet3
>> duplex auto
>> speed auto
>> !
>> interface FastEthernet4
>> duplex auto
>> speed auto
>> !
>> !
>> interface Dialer0
>> ip address negotiated
>> ip mtu 1492
>> ip nat outside
>> ip virtual-reassembly
>> encapsulation ppp
>> ip tcp adjust-mss 1412
>> dialer pool 1
>> no cdp enable
>> <ppp info ************>
>> !
>> ip forward-protocol nd
>> ip route 0.0.0.0 0.0.0.0 Dialer0
>> !
>> ip http server
>> no ip http secure-server
>> !
>> no ip nat service skinny tcp port 2000
>> no ip nat service sip udp port 5060
>> ip nat inside source list 10 interface Dialer0 overload
>> !
>> !
>> ip access-list extended VoicePorts
>> permit udp any host *.*.*.* range 22026 62025
>> permit udp any host *.*.*.* range 22026 62025
>> access-list 10 permit 192.168.10.0 0.0.0.255
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>>

From cluestore at gmail.com  Tue Jul  7 17:20:50 2009
From: cluestore at gmail.com (Clue Store)
Date: Tue, 7 Jul 2009 16:20:50 -0500
Subject: [c-nsp] QoS on 837 using PPPoE
In-Reply-To: <Pine.GSO.4.64.0907071404280.8751@sj-cse-717.cisco.com>
References: <580af3b90907071343i2f4cdabble3445111fe9d0466@mail.gmail.com>
	<Pine.GSO.4.64.0907071404280.8751@sj-cse-717.cisco.com>
Message-ID: <580af3b90907071420y43b8b5d8n56d863d2216a36c1@mail.gmail.com>

It took the command under the pvc section, but after a "sho run" the config
did not show up. Nor when I did a "show policy-map interface a0.1" did
anything show up.

I've looked through several docs on the cisco site, but did not come up with
anything that seem'd to work.

Will try to upgrade the IOS later tonight. Anyone else with any ideas??

On Tue, Jul 7, 2009 at 4:06 PM, Siva Valliappan <svalliap at cisco.com> wrote:

> IIRC you need to apply it on the ATM interface
> e.g.
>
> Interface ATM0.1 point-to-point
> .
> .
> pvc 1/100
>   service-policy output Voice
>
> regards
> .siva
>
>
>
> On Tue, 7 Jul 2009, Clue Store wrote:
>
>   Hi All,
>>
>>
>> I am having a hard time trying to figure how to apply a QoS policy on this
>> router. I have applied a few typical service-policies on the dialer
>> interfaces, but a "show policy interface di0" shows packets being matched
>> but nothing being dropped and the link is saturated. I believe the policy
>> needs to be applied to the virtual-access interface that comes up when PPP
>> negotiates, but i'm not quite sure how this would be done since the use of
>> vpdn-groups are no longer used. Relevent config posted. Any suggestions
>> are
>> greatly appreciated. *And yes I know the service-policy is not applied to
>> the dialer interface...this was due to it not working.
>>
>>
>> class-map match-any VoIP
>> match ip rtp 16384 16383
>> match access-group name VoicePorts
>> !
>> !
>> policy-map Voice
>> class VoIP
>>  priority 256
>> !
>> !
>> !
>> !
>> !
>> interface Ethernet0
>> ip address 192.168.10.1 255.255.255.0
>> ip nat inside
>> ip virtual-reassembly
>> !
>> interface Ethernet2
>> no ip address
>> shutdown
>> hold-queue 100 out
>> !
>> interface ATM0
>> no ip address
>> load-interval 30
>> no atm ilmi-keepalive
>> dsl operating-mode auto
>> !
>> interface ATM0.1 point-to-point
>> pvc 1/100
>>  encapsulation aal5snap
>>  pppoe-client dial-pool-number 1
>> !
>> !
>> interface FastEthernet1
>> duplex auto
>> speed auto
>> !
>> interface FastEthernet2
>> duplex auto
>> speed auto
>> !
>> interface FastEthernet3
>> duplex auto
>> speed auto
>> !
>> interface FastEthernet4
>> duplex auto
>> speed auto
>> !
>> !
>> interface Dialer0
>> ip address negotiated
>> ip mtu 1492
>> ip nat outside
>> ip virtual-reassembly
>> encapsulation ppp
>> ip tcp adjust-mss 1412
>> dialer pool 1
>> no cdp enable
>> <ppp info ************>
>> !
>> ip forward-protocol nd
>> ip route 0.0.0.0 0.0.0.0 Dialer0
>> !
>> ip http server
>> no ip http secure-server
>> !
>> no ip nat service skinny tcp port 2000
>> no ip nat service sip udp port 5060
>> ip nat inside source list 10 interface Dialer0 overload
>> !
>> !
>> ip access-list extended VoicePorts
>> permit udp any host *.*.*.* range 22026 62025
>> permit udp any host *.*.*.* range 22026 62025
>> access-list 10 permit 192.168.10.0 0.0.0.255
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>>

From svalliap at cisco.com  Tue Jul  7 17:30:35 2009
From: svalliap at cisco.com (Siva Valliappan)
Date: Tue, 7 Jul 2009 14:30:35 -0700 (PDT)
Subject: [c-nsp] QoS on 837 using PPPoE
In-Reply-To: <580af3b90907071412v1c9d8651s7a7fdcc4bb95fdd6@mail.gmail.com>
References: <580af3b90907071343i2f4cdabble3445111fe9d0466@mail.gmail.com> 
	<Pine.GSO.4.64.0907071404280.8751@sj-cse-717.cisco.com>
	<580af3b90907071412v1c9d8651s7a7fdcc4bb95fdd6@mail.gmail.com>
Message-ID: <Pine.GSO.4.64.0907071414510.7822@sj-cse-717.cisco.com>

it's been many years since i worked in this area, so you will need to
bear with me.

couple of things to check.  can you do a "show log" and is there any
other messages that were generated when you tried to configure the
service policy on the ATM interface?

do you have a "vbr-nrt <bw>" definition under the ATM interface?
can you configure that first, and then configure the service policy
statement?  does it resolve the issue?  if not, what were the log messages
that were generated?

thanks
.siva


On Tue, 7 Jul 2009, Clue Store wrote:

> On A0.1.....
>
> config-subif)#service-policy output Voice
> CBWFQ : Not supported on subinterfaces
>
> On A0
>
> (config-if)#service-policy output Voice
> CBWFQ : Not supported on this interface
>
> It would seem out old ways of QoS have changed  ;)
>
> On Tue, Jul 7, 2009 at 4:06 PM, Siva Valliappan <svalliap at cisco.com> wrote:
>
>> IIRC you need to apply it on the ATM interface
>> e.g.
>>
>> Interface ATM0.1 point-to-point
>> .
>> .
>> pvc 1/100
>>   service-policy output Voice
>>
>> regards
>> .siva
>>
>>
>>
>> On Tue, 7 Jul 2009, Clue Store wrote:
>>
>>   Hi All,
>>>
>>>
>>> I am having a hard time trying to figure how to apply a QoS policy on this
>>> router. I have applied a few typical service-policies on the dialer
>>> interfaces, but a "show policy interface di0" shows packets being matched
>>> but nothing being dropped and the link is saturated. I believe the policy
>>> needs to be applied to the virtual-access interface that comes up when PPP
>>> negotiates, but i'm not quite sure how this would be done since the use of
>>> vpdn-groups are no longer used. Relevent config posted. Any suggestions
>>> are
>>> greatly appreciated. *And yes I know the service-policy is not applied to
>>> the dialer interface...this was due to it not working.
>>>
>>>
>>> class-map match-any VoIP
>>> match ip rtp 16384 16383
>>> match access-group name VoicePorts
>>> !
>>> !
>>> policy-map Voice
>>> class VoIP
>>>  priority 256
>>> !
>>> !
>>> !
>>> !
>>> !
>>> interface Ethernet0
>>> ip address 192.168.10.1 255.255.255.0
>>> ip nat inside
>>> ip virtual-reassembly
>>> !
>>> interface Ethernet2
>>> no ip address
>>> shutdown
>>> hold-queue 100 out
>>> !
>>> interface ATM0
>>> no ip address
>>> load-interval 30
>>> no atm ilmi-keepalive
>>> dsl operating-mode auto
>>> !
>>> interface ATM0.1 point-to-point
>>> pvc 1/100
>>>  encapsulation aal5snap
>>>  pppoe-client dial-pool-number 1
>>> !
>>> !
>>> interface FastEthernet1
>>> duplex auto
>>> speed auto
>>> !
>>> interface FastEthernet2
>>> duplex auto
>>> speed auto
>>> !
>>> interface FastEthernet3
>>> duplex auto
>>> speed auto
>>> !
>>> interface FastEthernet4
>>> duplex auto
>>> speed auto
>>> !
>>> !
>>> interface Dialer0
>>> ip address negotiated
>>> ip mtu 1492
>>> ip nat outside
>>> ip virtual-reassembly
>>> encapsulation ppp
>>> ip tcp adjust-mss 1412
>>> dialer pool 1
>>> no cdp enable
>>> <ppp info ************>
>>> !
>>> ip forward-protocol nd
>>> ip route 0.0.0.0 0.0.0.0 Dialer0
>>> !
>>> ip http server
>>> no ip http secure-server
>>> !
>>> no ip nat service skinny tcp port 2000
>>> no ip nat service sip udp port 5060
>>> ip nat inside source list 10 interface Dialer0 overload
>>> !
>>> !
>>> ip access-list extended VoicePorts
>>> permit udp any host *.*.*.* range 22026 62025
>>> permit udp any host *.*.*.* range 22026 62025
>>> access-list 10 permit 192.168.10.0 0.0.0.255
>>> _______________________________________________
>>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>>
>>>
>

From svalliap at cisco.com  Tue Jul  7 17:32:09 2009
From: svalliap at cisco.com (Siva Valliappan)
Date: Tue, 7 Jul 2009 14:32:09 -0700 (PDT)
Subject: [c-nsp] QoS on 837 using PPPoE
In-Reply-To: <580af3b90907071420y43b8b5d8n56d863d2216a36c1@mail.gmail.com>
References: <580af3b90907071343i2f4cdabble3445111fe9d0466@mail.gmail.com> 
	<Pine.GSO.4.64.0907071404280.8751@sj-cse-717.cisco.com>
	<580af3b90907071420y43b8b5d8n56d863d2216a36c1@mail.gmail.com>
Message-ID: <Pine.GSO.4.64.0907071431540.7822@sj-cse-717.cisco.com>

what does the log messages say?  a show log should tell you why it
didn't accept the commands.

On Tue, 7 Jul 2009, Clue Store wrote:

> It took the command under the pvc section, but after a "sho run" the config
> did not show up. Nor when I did a "show policy-map interface a0.1" did
> anything show up.
>
> I've looked through several docs on the cisco site, but did not come up with
> anything that seem'd to work.
>
> Will try to upgrade the IOS later tonight. Anyone else with any ideas??
>
> On Tue, Jul 7, 2009 at 4:06 PM, Siva Valliappan <svalliap at cisco.com> wrote:
>
>> IIRC you need to apply it on the ATM interface
>> e.g.
>>
>> Interface ATM0.1 point-to-point
>> .
>> .
>> pvc 1/100
>>   service-policy output Voice
>>
>> regards
>> .siva
>>
>>
>>
>> On Tue, 7 Jul 2009, Clue Store wrote:
>>
>>   Hi All,
>>>
>>>
>>> I am having a hard time trying to figure how to apply a QoS policy on this
>>> router. I have applied a few typical service-policies on the dialer
>>> interfaces, but a "show policy interface di0" shows packets being matched
>>> but nothing being dropped and the link is saturated. I believe the policy
>>> needs to be applied to the virtual-access interface that comes up when PPP
>>> negotiates, but i'm not quite sure how this would be done since the use of
>>> vpdn-groups are no longer used. Relevent config posted. Any suggestions
>>> are
>>> greatly appreciated. *And yes I know the service-policy is not applied to
>>> the dialer interface...this was due to it not working.
>>>
>>>
>>> class-map match-any VoIP
>>> match ip rtp 16384 16383
>>> match access-group name VoicePorts
>>> !
>>> !
>>> policy-map Voice
>>> class VoIP
>>>  priority 256
>>> !
>>> !
>>> !
>>> !
>>> !
>>> interface Ethernet0
>>> ip address 192.168.10.1 255.255.255.0
>>> ip nat inside
>>> ip virtual-reassembly
>>> !
>>> interface Ethernet2
>>> no ip address
>>> shutdown
>>> hold-queue 100 out
>>> !
>>> interface ATM0
>>> no ip address
>>> load-interval 30
>>> no atm ilmi-keepalive
>>> dsl operating-mode auto
>>> !
>>> interface ATM0.1 point-to-point
>>> pvc 1/100
>>>  encapsulation aal5snap
>>>  pppoe-client dial-pool-number 1
>>> !
>>> !
>>> interface FastEthernet1
>>> duplex auto
>>> speed auto
>>> !
>>> interface FastEthernet2
>>> duplex auto
>>> speed auto
>>> !
>>> interface FastEthernet3
>>> duplex auto
>>> speed auto
>>> !
>>> interface FastEthernet4
>>> duplex auto
>>> speed auto
>>> !
>>> !
>>> interface Dialer0
>>> ip address negotiated
>>> ip mtu 1492
>>> ip nat outside
>>> ip virtual-reassembly
>>> encapsulation ppp
>>> ip tcp adjust-mss 1412
>>> dialer pool 1
>>> no cdp enable
>>> <ppp info ************>
>>> !
>>> ip forward-protocol nd
>>> ip route 0.0.0.0 0.0.0.0 Dialer0
>>> !
>>> ip http server
>>> no ip http secure-server
>>> !
>>> no ip nat service skinny tcp port 2000
>>> no ip nat service sip udp port 5060
>>> ip nat inside source list 10 interface Dialer0 overload
>>> !
>>> !
>>> ip access-list extended VoicePorts
>>> permit udp any host *.*.*.* range 22026 62025
>>> permit udp any host *.*.*.* range 22026 62025
>>> access-list 10 permit 192.168.10.0 0.0.0.255
>>> _______________________________________________
>>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>>
>>>
>

From rdobbins at arbor.net  Tue Jul  7 17:36:49 2009
From: rdobbins at arbor.net (Roland Dobbins)
Date: Wed, 8 Jul 2009 04:36:49 +0700
Subject: [c-nsp] Baseline CoPP policies?
In-Reply-To: <F3318834F1F89D46857972DD4B411D7011C3D55F@EXCHANGE.thenap.com>
References: <F3318834F1F89D46857972DD4B411D7011C3D55F@EXCHANGE.thenap.com>
Message-ID: <80D59FFA-9954-4019-984F-0A3975114326@arbor.net>


On Jul 8, 2009, at 2:49 AM, Drew Weaver wrote:

> I've seen the Cisco TTL Expiry attack documentation etc, are there  
> any good generalized guidelines Cisco published or not?

CoPP is very situationally specific.  Suggest you use NetFlow,  
classification ACL, etc. to build your policy, then do a permit-only  
policy to see what was missed, then develop your policy from there.

Initial policy should be straight permit/deny via CoPP QoS syntax  
(i.e., emulating a rACL); later, with more data, look at rate-limiting.

Prior to looking at CoPP, however, I strongly recommend iACLs at all  
edges of the network, first.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

         Unfortunately, inefficiency scales really well.

		   -- Kevin Lawton


From cluestore at gmail.com  Tue Jul  7 17:48:20 2009
From: cluestore at gmail.com (Clue Store)
Date: Tue, 7 Jul 2009 16:48:20 -0500
Subject: [c-nsp] QoS on 837 using PPPoE
In-Reply-To: <Pine.GSO.4.64.0907071431540.7822@sj-cse-717.cisco.com>
References: <580af3b90907071343i2f4cdabble3445111fe9d0466@mail.gmail.com>
	<Pine.GSO.4.64.0907071404280.8751@sj-cse-717.cisco.com>
	<580af3b90907071420y43b8b5d8n56d863d2216a36c1@mail.gmail.com>
	<Pine.GSO.4.64.0907071431540.7822@sj-cse-717.cisco.com>
Message-ID: <580af3b90907071448o6615594dh65ce88a2dedfd404@mail.gmail.com>

Hi Siva,

Your suggestions seem to have to have worked. Just so that I understand, the
vbr-nrt shaping is just for the outbound cells and does not affect inbound
traffic correct?? This is a 3m/384k and I do not want to affect their
inbound. I could only reserve 288k in my policy (which is fine since the
upload is only 384k). And the logs did show why it did not take the command
and I was able to adjust my policy as the logs suggested.

I/f ATM0.1 VC 1/100 class VoIP requested bandwidth 320 (kbps), available
only 288 (kbps)

This is now what shows up in the config....

policy-map Voice
 class VoIP
  priority 288

interface ATM0.1 point-to-point
 pvc 1/100
  vbr-nrt 384 384
  encapsulation aal5snap
  service-policy output Voice
  pppoe-client dial-pool-number 1



On Tue, Jul 7, 2009 at 4:32 PM, Siva Valliappan <svalliap at cisco.com> wrote:

> what does the log messages say?  a show log should tell you why it
> didn't accept the commands.
>
>
> On Tue, 7 Jul 2009, Clue Store wrote:
>
> It took the command under the pvc section, but after a "sho run" the config
>> did not show up. Nor when I did a "show policy-map interface a0.1" did
>> anything show up.
>>
>> I've looked through several docs on the cisco site, but did not come up
>> with
>> anything that seem'd to work.
>>
>> Will try to upgrade the IOS later tonight. Anyone else with any ideas??
>>
>> On Tue, Jul 7, 2009 at 4:06 PM, Siva Valliappan <svalliap at cisco.com>
>> wrote:
>>
>> IIRC you need to apply it on the ATM interface
>>> e.g.
>>>
>>> Interface ATM0.1 point-to-point
>>> .
>>> .
>>> pvc 1/100
>>>  service-policy output Voice
>>>
>>> regards
>>> .siva
>>>
>>>
>>>
>>> On Tue, 7 Jul 2009, Clue Store wrote:
>>>
>>>  Hi All,
>>>
>>>>
>>>>
>>>> I am having a hard time trying to figure how to apply a QoS policy on
>>>> this
>>>> router. I have applied a few typical service-policies on the dialer
>>>> interfaces, but a "show policy interface di0" shows packets being
>>>> matched
>>>> but nothing being dropped and the link is saturated. I believe the
>>>> policy
>>>> needs to be applied to the virtual-access interface that comes up when
>>>> PPP
>>>> negotiates, but i'm not quite sure how this would be done since the use
>>>> of
>>>> vpdn-groups are no longer used. Relevent config posted. Any suggestions
>>>> are
>>>> greatly appreciated. *And yes I know the service-policy is not applied
>>>> to
>>>> the dialer interface...this was due to it not working.
>>>>
>>>>
>>>> class-map match-any VoIP
>>>> match ip rtp 16384 16383
>>>> match access-group name VoicePorts
>>>> !
>>>> !
>>>> policy-map Voice
>>>> class VoIP
>>>>  priority 256
>>>> !
>>>> !
>>>> !
>>>> !
>>>> !
>>>> interface Ethernet0
>>>> ip address 192.168.10.1 255.255.255.0
>>>> ip nat inside
>>>> ip virtual-reassembly
>>>> !
>>>> interface Ethernet2
>>>> no ip address
>>>> shutdown
>>>> hold-queue 100 out
>>>> !
>>>> interface ATM0
>>>> no ip address
>>>> load-interval 30
>>>> no atm ilmi-keepalive
>>>> dsl operating-mode auto
>>>> !
>>>> interface ATM0.1 point-to-point
>>>> pvc 1/100
>>>>  encapsulation aal5snap
>>>>  pppoe-client dial-pool-number 1
>>>> !
>>>> !
>>>> interface FastEthernet1
>>>> duplex auto
>>>> speed auto
>>>> !
>>>> interface FastEthernet2
>>>> duplex auto
>>>> speed auto
>>>> !
>>>> interface FastEthernet3
>>>> duplex auto
>>>> speed auto
>>>> !
>>>> interface FastEthernet4
>>>> duplex auto
>>>> speed auto
>>>> !
>>>> !
>>>> interface Dialer0
>>>> ip address negotiated
>>>> ip mtu 1492
>>>> ip nat outside
>>>> ip virtual-reassembly
>>>> encapsulation ppp
>>>> ip tcp adjust-mss 1412
>>>> dialer pool 1
>>>> no cdp enable
>>>> <ppp info ************>
>>>> !
>>>> ip forward-protocol nd
>>>> ip route 0.0.0.0 0.0.0.0 Dialer0
>>>> !
>>>> ip http server
>>>> no ip http secure-server
>>>> !
>>>> no ip nat service skinny tcp port 2000
>>>> no ip nat service sip udp port 5060
>>>> ip nat inside source list 10 interface Dialer0 overload
>>>> !
>>>> !
>>>> ip access-list extended VoicePorts
>>>> permit udp any host *.*.*.* range 22026 62025
>>>> permit udp any host *.*.*.* range 22026 62025
>>>> access-list 10 permit 192.168.10.0 0.0.0.255
>>>> _______________________________________________
>>>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>>>
>>>>
>>>>
>>

From Thomas.Sillaber at nextiraone.de  Tue Jul  7 17:55:53 2009
From: Thomas.Sillaber at nextiraone.de (Thomas.Sillaber at nextiraone.de)
Date: Tue, 7 Jul 2009 23:55:53 +0200
Subject: [c-nsp] QoS on 837 using PPPoE
References: <580af3b90907071343i2f4cdabble3445111fe9d0466@mail.gmail.com>
Message-ID: <D2A12B44A1003D45A7117D0BBB957A0614630C51@BER05101.ebdmail.alcatel.de>

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

Hi Clue,

yes your right. applying the sp to the dialer interface is a bad idea (see IP's ioshints blog) - also IMHO to the virt template (never tried it). To support LLQ and CBWFQ on DSL Interfaces you have to:

   	- change the vc to vbr-nrt
   	- apply the sp on the vc (per vc queueing)
  	[- optionally tune tx-ring on the vc in case of low speed upload]
  	[- optionally change tcp mss on low speed interfaces (dialer) to prevent cell padding - a lot of validation in lab env shows that 	cell padding introduce higher delays than packets matching n x atm cells without padding. In worse situation with very slow upstreams  	using very low mss sizes (IOS min 500) matching cells without padding might help (TCP performance is already bad..)
    	- better use dscp based classification on eth ingress interface.

	
Take care when calculation the needed bandwidth per call with this setup. You have to calc all the overhead introduced by the DSL Interface:

Here's a example of different coders with different coder intervals measured @ the ATM interface (simulated with Chariot):

- ---------------------------------------------------------------------
G.711A(10ms)      30 second offered rate 124000 bps, drop rate 0 bps
G.711A(20ms)  	30 second offered rate 94000 bps, drop rate 0 bps
G.711A(30ms)	30 second offered rate 84000 bps, drop rate 0 bps
- ---------------------------------------------------------------------
G.729A(10ms)	30 second offered rate 69000 bps, drop rate 0 bps
G.729A(20ms)	30 second offered rate 38000 bps, drop rate 0 bps
G.729A(30ms)	30 second offered rate 28000 bps, drop rate 0 bps
- ---------------------------------------------------------------------

==> a little bit higher than expected :-)

Basic Setup
- ----------------
!
policy-map QOS
class RT
   Priority 256
class SIG
   Bandwith x
!
interface ATM0.1 point-to-point
 pvc 1/100
   tx-ring-limit 2			//aggressive - only for slow speed upstreams...
   vbr-nrt <upstream> <upstream>  	//use sh dsl int atm0 to determine the upstream rate or ?
   service-policy output QOS
!
Interface Dialer 0
	Ip tcp adjust-mss 544		// minimum used for slow speed upstream rate (without vpn or other overhead)
!

MSS is calculated like this:

13 ATM Cells x 48 - 80 [Overhead]

Overhead:

AAL5 Header		10	Byte
AAL5 Trailer	8	Byte
PPPOE Header	8	Byte
Ethernet Header	14	Byte
IP Header		20	Byte
TCP Header		20	Byte

==> 80Byte

Hope this helps.
==> Do not forget the downstream! Shaping + HQOS @ BRAS or Central Site is needed!

Brgds

TS

- -----Urspr?ngliche Nachricht-----
Von: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] Im Auftrag von Clue Store
Gesendet: Dienstag, 7. Juli 2009 22:43
An: cisco-nsp at puck.nether.net
Betreff: [c-nsp] QoS on 837 using PPPoE

Hi All,


I am having a hard time trying to figure how to apply a QoS policy on this
router. I have applied a few typical service-policies on the dialer
interfaces, but a "show policy interface di0" shows packets being matched
but nothing being dropped and the link is saturated. I believe the policy
needs to be applied to the virtual-access interface that comes up when PPP
negotiates, but i'm not quite sure how this would be done since the use of
vpdn-groups are no longer used. Relevent config posted. Any suggestions are
greatly appreciated. *And yes I know the service-policy is not applied to
the dialer interface...this was due to it not working.


class-map match-any VoIP
 match ip rtp 16384 16383
 match access-group name VoicePorts
!
!
policy-map Voice
 class VoIP
  priority 256
!
!
!
!
!
interface Ethernet0
 ip address 192.168.10.1 255.255.255.0
 ip nat inside
 ip virtual-reassembly
!
interface Ethernet2
 no ip address
 shutdown
 hold-queue 100 out
!
interface ATM0
 no ip address
 load-interval 30
 no atm ilmi-keepalive
 dsl operating-mode auto
!
interface ATM0.1 point-to-point
 pvc 1/100
  encapsulation aal5snap
  pppoe-client dial-pool-number 1
 !
!
interface FastEthernet1
 duplex auto
 speed auto
!
interface FastEthernet2
 duplex auto
 speed auto
!
interface FastEthernet3
 duplex auto
 speed auto
!
interface FastEthernet4
 duplex auto
 speed auto
!
!
interface Dialer0
 ip address negotiated
 ip mtu 1492
 ip nat outside
 ip virtual-reassembly
 encapsulation ppp
 ip tcp adjust-mss 1412
 dialer pool 1
 no cdp enable
<ppp info ************>
!
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 Dialer0
!
ip http server
no ip http secure-server
!
no ip nat service skinny tcp port 2000
no ip nat service sip udp port 5060
ip nat inside source list 10 interface Dialer0 overload
!
!
ip access-list extended VoicePorts
 permit udp any host *.*.*.* range 22026 62025
 permit udp any host *.*.*.* range 22026 62025
access-list 10 permit 192.168.10.0 0.0.0.255
_______________________________________________
cisco-nsp mailing 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.7 (MingW32)

iQEVAwUBSlPEZ2Z0NRmWJ+KQAQIdzAgAoDtyyfVXkKR43ZI5LlPM/XXakdHeRh07
kB5XjnsY7PB+sog65YGZQaZTwm5B9dHWsNFgmQUD04MdXd/QwVwnKildh7haVvqg
6PPT8GntculzXx010MTzTbJ44dUlWmksSibdKJWgdNx8vBNk0GXOpP0yuCGoc3/s
U6S9qzmv3jhtXn+rbWBP9Hh0g3LJ8SnOAp0YXSc5szSeC4JUlwNp6uq2rQC488m3
ji5JG2wIeZ/JCZ/5y+rCI66dx0iYd5bac27qLo29UIrx7LJpVVK/gwvE1FeJUBiR
2C0WDThjO3/H24cOJz9NRgh3O4kTxKs6jwU56OsVZ/Hu32fuZETAUw==
=KNVj
-----END PGP SIGNATURE-----

From Thomas.Sillaber at nextiraone.de  Tue Jul  7 18:00:22 2009
From: Thomas.Sillaber at nextiraone.de (Thomas.Sillaber at nextiraone.de)
Date: Wed, 8 Jul 2009 00:00:22 +0200
Subject: [c-nsp] QoS on 837 using PPPoE
References: <580af3b90907071343i2f4cdabble3445111fe9d0466@mail.gmail.com><Pine.GSO.4.64.0907071404280.8751@sj-cse-717.cisco.com>
	<580af3b90907071420y43b8b5d8n56d863d2216a36c1@mail.gmail.com>
Message-ID: <D2A12B44A1003D45A7117D0BBB957A0614630C53@BER05101.ebdmail.alcatel.de>

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

You don't need the subif  - use the phy interface.

Brgds

TS

- -----Urspr?ngliche Nachricht-----
Von: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] Im Auftrag von Clue Store
Gesendet: Dienstag, 7. Juli 2009 23:21
An: Siva Valliappan
Cc: cisco-nsp at puck.nether.net
Betreff: Re: [c-nsp] QoS on 837 using PPPoE

It took the command under the pvc section, but after a "sho run" the config
did not show up. Nor when I did a "show policy-map interface a0.1" did
anything show up.

I've looked through several docs on the cisco site, but did not come up with
anything that seem'd to work.

Will try to upgrade the IOS later tonight. Anyone else with any ideas??

On Tue, Jul 7, 2009 at 4:06 PM, Siva Valliappan <svalliap at cisco.com> wrote:

> IIRC you need to apply it on the ATM interface
> e.g.
>
> Interface ATM0.1 point-to-point
> .
> .
> pvc 1/100
>   service-policy output Voice
>
> regards
> .siva
>
>
>
> On Tue, 7 Jul 2009, Clue Store wrote:
>
>   Hi All,
>>
>>
>> I am having a hard time trying to figure how to apply a QoS policy on this
>> router. I have applied a few typical service-policies on the dialer
>> interfaces, but a "show policy interface di0" shows packets being matched
>> but nothing being dropped and the link is saturated. I believe the policy
>> needs to be applied to the virtual-access interface that comes up when PPP
>> negotiates, but i'm not quite sure how this would be done since the use of
>> vpdn-groups are no longer used. Relevent config posted. Any suggestions
>> are
>> greatly appreciated. *And yes I know the service-policy is not applied to
>> the dialer interface...this was due to it not working.
>>
>>
>> class-map match-any VoIP
>> match ip rtp 16384 16383
>> match access-group name VoicePorts
>> !
>> !
>> policy-map Voice
>> class VoIP
>>  priority 256
>> !
>> !
>> !
>> !
>> !
>> interface Ethernet0
>> ip address 192.168.10.1 255.255.255.0
>> ip nat inside
>> ip virtual-reassembly
>> !
>> interface Ethernet2
>> no ip address
>> shutdown
>> hold-queue 100 out
>> !
>> interface ATM0
>> no ip address
>> load-interval 30
>> no atm ilmi-keepalive
>> dsl operating-mode auto
>> !
>> interface ATM0.1 point-to-point
>> pvc 1/100
>>  encapsulation aal5snap
>>  pppoe-client dial-pool-number 1
>> !
>> !
>> interface FastEthernet1
>> duplex auto
>> speed auto
>> !
>> interface FastEthernet2
>> duplex auto
>> speed auto
>> !
>> interface FastEthernet3
>> duplex auto
>> speed auto
>> !
>> interface FastEthernet4
>> duplex auto
>> speed auto
>> !
>> !
>> interface Dialer0
>> ip address negotiated
>> ip mtu 1492
>> ip nat outside
>> ip virtual-reassembly
>> encapsulation ppp
>> ip tcp adjust-mss 1412
>> dialer pool 1
>> no cdp enable
>> <ppp info ************>
>> !
>> ip forward-protocol nd
>> ip route 0.0.0.0 0.0.0.0 Dialer0
>> !
>> ip http server
>> no ip http secure-server
>> !
>> no ip nat service skinny tcp port 2000
>> no ip nat service sip udp port 5060
>> ip nat inside source list 10 interface Dialer0 overload
>> !
>> !
>> ip access-list extended VoicePorts
>> permit udp any host *.*.*.* range 22026 62025
>> permit udp any host *.*.*.* range 22026 62025
>> access-list 10 permit 192.168.10.0 0.0.0.255
>> _______________________________________________
>> cisco-nsp mailing 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/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)

iQEVAwUBSlPFdmZ0NRmWJ+KQAQKTcAf/VeL4qInZ2SNEGqCpC0szRBjaXdr0rAvz
A4EbfABJdKzS3YVfco6AdYMwrsoFkvmL9cAvPTzWzrohfPirbxdm0IleUNqoCiyD
bJGgpiPkZPgEz44XqYx+1KfYlEStuKbQ8/n5jjfPsVS5ZzdCUXXmRqMrN5BwieMu
Ustb/TtH74lmiKaS6LAyMk2dXYlvC1ZrR1osndkngRAcXb8Z5p0SdO/HMcc1QzYn
cIbUtwI1NDtV3chWwQsslcJnZx/IsRikpADpfybjd1HB/lw59bXS9PVo/evRuL11
g+5HTGhptkf0d//YcKN3f4TQtCXTwPSFHb1QRPMyCbkr0YDWui9/Zg==
=XsPc
-----END PGP SIGNATURE-----

From svalliap at cisco.com  Tue Jul  7 17:59:22 2009
From: svalliap at cisco.com (Siva Valliappan)
Date: Tue, 7 Jul 2009 14:59:22 -0700 (PDT)
Subject: [c-nsp] QoS on 837 using PPPoE
In-Reply-To: <580af3b90907071448o6615594dh65ce88a2dedfd404@mail.gmail.com>
References: <580af3b90907071343i2f4cdabble3445111fe9d0466@mail.gmail.com> 
	<Pine.GSO.4.64.0907071404280.8751@sj-cse-717.cisco.com> 
	<580af3b90907071420y43b8b5d8n56d863d2216a36c1@mail.gmail.com> 
	<Pine.GSO.4.64.0907071431540.7822@sj-cse-717.cisco.com>
	<580af3b90907071448o6615594dh65ce88a2dedfd404@mail.gmail.com>
Message-ID: <Pine.GSO.4.64.0907071457410.7822@sj-cse-717.cisco.com>

correct.  vbr-nrt only affects the output not the input.

regards
.siva

On Tue, 7 Jul 2009, Clue Store wrote:

> Hi Siva,
>
> Your suggestions seem to have to have worked. Just so that I understand, the
> vbr-nrt shaping is just for the outbound cells and does not affect inbound
> traffic correct?? This is a 3m/384k and I do not want to affect their
> inbound. I could only reserve 288k in my policy (which is fine since the
> upload is only 384k). And the logs did show why it did not take the command
> and I was able to adjust my policy as the logs suggested.
>
> I/f ATM0.1 VC 1/100 class VoIP requested bandwidth 320 (kbps), available
> only 288 (kbps)
>
> This is now what shows up in the config....
>
> policy-map Voice
> class VoIP
>  priority 288
>
> interface ATM0.1 point-to-point
> pvc 1/100
>  vbr-nrt 384 384
>  encapsulation aal5snap
>  service-policy output Voice
>  pppoe-client dial-pool-number 1
>
>
>
> On Tue, Jul 7, 2009 at 4:32 PM, Siva Valliappan <svalliap at cisco.com> wrote:
>
>> what does the log messages say?  a show log should tell you why it
>> didn't accept the commands.
>>
>>
>> On Tue, 7 Jul 2009, Clue Store wrote:
>>
>> It took the command under the pvc section, but after a "sho run" the config
>>> did not show up. Nor when I did a "show policy-map interface a0.1" did
>>> anything show up.
>>>
>>> I've looked through several docs on the cisco site, but did not come up
>>> with
>>> anything that seem'd to work.
>>>
>>> Will try to upgrade the IOS later tonight. Anyone else with any ideas??
>>>
>>> On Tue, Jul 7, 2009 at 4:06 PM, Siva Valliappan <svalliap at cisco.com>
>>> wrote:
>>>
>>> IIRC you need to apply it on the ATM interface
>>>> e.g.
>>>>
>>>> Interface ATM0.1 point-to-point
>>>> .
>>>> .
>>>> pvc 1/100
>>>>  service-policy output Voice
>>>>
>>>> regards
>>>> .siva
>>>>
>>>>
>>>>
>>>> On Tue, 7 Jul 2009, Clue Store wrote:
>>>>
>>>>  Hi All,
>>>>
>>>>>
>>>>>
>>>>> I am having a hard time trying to figure how to apply a QoS policy on
>>>>> this
>>>>> router. I have applied a few typical service-policies on the dialer
>>>>> interfaces, but a "show policy interface di0" shows packets being
>>>>> matched
>>>>> but nothing being dropped and the link is saturated. I believe the
>>>>> policy
>>>>> needs to be applied to the virtual-access interface that comes up when
>>>>> PPP
>>>>> negotiates, but i'm not quite sure how this would be done since the use
>>>>> of
>>>>> vpdn-groups are no longer used. Relevent config posted. Any suggestions
>>>>> are
>>>>> greatly appreciated. *And yes I know the service-policy is not applied
>>>>> to
>>>>> the dialer interface...this was due to it not working.
>>>>>
>>>>>
>>>>> class-map match-any VoIP
>>>>> match ip rtp 16384 16383
>>>>> match access-group name VoicePorts
>>>>> !
>>>>> !
>>>>> policy-map Voice
>>>>> class VoIP
>>>>>  priority 256
>>>>> !
>>>>> !
>>>>> !
>>>>> !
>>>>> !
>>>>> interface Ethernet0
>>>>> ip address 192.168.10.1 255.255.255.0
>>>>> ip nat inside
>>>>> ip virtual-reassembly
>>>>> !
>>>>> interface Ethernet2
>>>>> no ip address
>>>>> shutdown
>>>>> hold-queue 100 out
>>>>> !
>>>>> interface ATM0
>>>>> no ip address
>>>>> load-interval 30
>>>>> no atm ilmi-keepalive
>>>>> dsl operating-mode auto
>>>>> !
>>>>> interface ATM0.1 point-to-point
>>>>> pvc 1/100
>>>>>  encapsulation aal5snap
>>>>>  pppoe-client dial-pool-number 1
>>>>> !
>>>>> !
>>>>> interface FastEthernet1
>>>>> duplex auto
>>>>> speed auto
>>>>> !
>>>>> interface FastEthernet2
>>>>> duplex auto
>>>>> speed auto
>>>>> !
>>>>> interface FastEthernet3
>>>>> duplex auto
>>>>> speed auto
>>>>> !
>>>>> interface FastEthernet4
>>>>> duplex auto
>>>>> speed auto
>>>>> !
>>>>> !
>>>>> interface Dialer0
>>>>> ip address negotiated
>>>>> ip mtu 1492
>>>>> ip nat outside
>>>>> ip virtual-reassembly
>>>>> encapsulation ppp
>>>>> ip tcp adjust-mss 1412
>>>>> dialer pool 1
>>>>> no cdp enable
>>>>> <ppp info ************>
>>>>> !
>>>>> ip forward-protocol nd
>>>>> ip route 0.0.0.0 0.0.0.0 Dialer0
>>>>> !
>>>>> ip http server
>>>>> no ip http secure-server
>>>>> !
>>>>> no ip nat service skinny tcp port 2000
>>>>> no ip nat service sip udp port 5060
>>>>> ip nat inside source list 10 interface Dialer0 overload
>>>>> !
>>>>> !
>>>>> ip access-list extended VoicePorts
>>>>> permit udp any host *.*.*.* range 22026 62025
>>>>> permit udp any host *.*.*.* range 22026 62025
>>>>> access-list 10 permit 192.168.10.0 0.0.0.255
>>>>> _______________________________________________
>>>>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>>>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>>>>
>>>>>
>>>>>
>>>
>

From cluestore at gmail.com  Tue Jul  7 18:00:53 2009
From: cluestore at gmail.com (Clue Store)
Date: Tue, 7 Jul 2009 17:00:53 -0500
Subject: [c-nsp] QoS on 837 using PPPoE
In-Reply-To: <Pine.GSO.4.64.0907071457410.7822@sj-cse-717.cisco.com>
References: <580af3b90907071343i2f4cdabble3445111fe9d0466@mail.gmail.com>
	<Pine.GSO.4.64.0907071404280.8751@sj-cse-717.cisco.com>
	<580af3b90907071420y43b8b5d8n56d863d2216a36c1@mail.gmail.com>
	<Pine.GSO.4.64.0907071431540.7822@sj-cse-717.cisco.com>
	<580af3b90907071448o6615594dh65ce88a2dedfd404@mail.gmail.com>
	<Pine.GSO.4.64.0907071457410.7822@sj-cse-717.cisco.com>
Message-ID: <580af3b90907071500i448893c7g5be0ba497c7351b@mail.gmail.com>

Awesome. Big thanks to Thomas and Siva for the clue bits. They are greatly
appreciated!!

--
Clue

On Tue, Jul 7, 2009 at 4:59 PM, Siva Valliappan <svalliap at cisco.com> wrote:

> correct.  vbr-nrt only affects the output not the input.
>
>
> regards
> .siva
>
> On Tue, 7 Jul 2009, Clue Store wrote:
>
> Hi Siva,
>>
>> Your suggestions seem to have to have worked. Just so that I understand,
>> the
>> vbr-nrt shaping is just for the outbound cells and does not affect inbound
>> traffic correct?? This is a 3m/384k and I do not want to affect their
>> inbound. I could only reserve 288k in my policy (which is fine since the
>> upload is only 384k). And the logs did show why it did not take the
>> command
>> and I was able to adjust my policy as the logs suggested.
>>
>> I/f ATM0.1 VC 1/100 class VoIP requested bandwidth 320 (kbps), available
>> only 288 (kbps)
>>
>> This is now what shows up in the config....
>>
>> policy-map Voice
>> class VoIP
>>  priority 288
>>
>> interface ATM0.1 point-to-point
>> pvc 1/100
>>  vbr-nrt 384 384
>>  encapsulation aal5snap
>>  service-policy output Voice
>>  pppoe-client dial-pool-number 1
>>
>>
>>
>> On Tue, Jul 7, 2009 at 4:32 PM, Siva Valliappan <svalliap at cisco.com>
>> wrote:
>>
>> what does the log messages say?  a show log should tell you why it
>>> didn't accept the commands.
>>>
>>>
>>> On Tue, 7 Jul 2009, Clue Store wrote:
>>>
>>> It took the command under the pvc section, but after a "sho run" the
>>> config
>>>
>>>> did not show up. Nor when I did a "show policy-map interface a0.1" did
>>>> anything show up.
>>>>
>>>> I've looked through several docs on the cisco site, but did not come up
>>>> with
>>>> anything that seem'd to work.
>>>>
>>>> Will try to upgrade the IOS later tonight. Anyone else with any ideas??
>>>>
>>>> On Tue, Jul 7, 2009 at 4:06 PM, Siva Valliappan <svalliap at cisco.com>
>>>> wrote:
>>>>
>>>> IIRC you need to apply it on the ATM interface
>>>>
>>>>> e.g.
>>>>>
>>>>> Interface ATM0.1 point-to-point
>>>>> .
>>>>> .
>>>>> pvc 1/100
>>>>>  service-policy output Voice
>>>>>
>>>>> regards
>>>>> .siva
>>>>>
>>>>>
>>>>>
>>>>> On Tue, 7 Jul 2009, Clue Store wrote:
>>>>>
>>>>>  Hi All,
>>>>>
>>>>>
>>>>>>
>>>>>> I am having a hard time trying to figure how to apply a QoS policy on
>>>>>> this
>>>>>> router. I have applied a few typical service-policies on the dialer
>>>>>> interfaces, but a "show policy interface di0" shows packets being
>>>>>> matched
>>>>>> but nothing being dropped and the link is saturated. I believe the
>>>>>> policy
>>>>>> needs to be applied to the virtual-access interface that comes up when
>>>>>> PPP
>>>>>> negotiates, but i'm not quite sure how this would be done since the
>>>>>> use
>>>>>> of
>>>>>> vpdn-groups are no longer used. Relevent config posted. Any
>>>>>> suggestions
>>>>>> are
>>>>>> greatly appreciated. *And yes I know the service-policy is not applied
>>>>>> to
>>>>>> the dialer interface...this was due to it not working.
>>>>>>
>>>>>>
>>>>>> class-map match-any VoIP
>>>>>> match ip rtp 16384 16383
>>>>>> match access-group name VoicePorts
>>>>>> !
>>>>>> !
>>>>>> policy-map Voice
>>>>>> class VoIP
>>>>>>  priority 256
>>>>>> !
>>>>>> !
>>>>>> !
>>>>>> !
>>>>>> !
>>>>>> interface Ethernet0
>>>>>> ip address 192.168.10.1 255.255.255.0
>>>>>> ip nat inside
>>>>>> ip virtual-reassembly
>>>>>> !
>>>>>> interface Ethernet2
>>>>>> no ip address
>>>>>> shutdown
>>>>>> hold-queue 100 out
>>>>>> !
>>>>>> interface ATM0
>>>>>> no ip address
>>>>>> load-interval 30
>>>>>> no atm ilmi-keepalive
>>>>>> dsl operating-mode auto
>>>>>> !
>>>>>> interface ATM0.1 point-to-point
>>>>>> pvc 1/100
>>>>>>  encapsulation aal5snap
>>>>>>  pppoe-client dial-pool-number 1
>>>>>> !
>>>>>> !
>>>>>> interface FastEthernet1
>>>>>> duplex auto
>>>>>> speed auto
>>>>>> !
>>>>>> interface FastEthernet2
>>>>>> duplex auto
>>>>>> speed auto
>>>>>> !
>>>>>> interface FastEthernet3
>>>>>> duplex auto
>>>>>> speed auto
>>>>>> !
>>>>>> interface FastEthernet4
>>>>>> duplex auto
>>>>>> speed auto
>>>>>> !
>>>>>> !
>>>>>> interface Dialer0
>>>>>> ip address negotiated
>>>>>> ip mtu 1492
>>>>>> ip nat outside
>>>>>> ip virtual-reassembly
>>>>>> encapsulation ppp
>>>>>> ip tcp adjust-mss 1412
>>>>>> dialer pool 1
>>>>>> no cdp enable
>>>>>> <ppp info ************>
>>>>>> !
>>>>>> ip forward-protocol nd
>>>>>> ip route 0.0.0.0 0.0.0.0 Dialer0
>>>>>> !
>>>>>> ip http server
>>>>>> no ip http secure-server
>>>>>> !
>>>>>> no ip nat service skinny tcp port 2000
>>>>>> no ip nat service sip udp port 5060
>>>>>> ip nat inside source list 10 interface Dialer0 overload
>>>>>> !
>>>>>> !
>>>>>> ip access-list extended VoicePorts
>>>>>> permit udp any host *.*.*.* range 22026 62025
>>>>>> permit udp any host *.*.*.* range 22026 62025
>>>>>> access-list 10 permit 192.168.10.0 0.0.0.255
>>>>>> _______________________________________________
>>>>>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>>>>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>>>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>

From william.mccall at gmail.com  Tue Jul  7 18:03:50 2009
From: william.mccall at gmail.com (William McCall)
Date: Tue, 7 Jul 2009 17:03:50 -0500
Subject: [c-nsp] QoS on 837 using PPPoE
In-Reply-To: <580af3b90907071420y43b8b5d8n56d863d2216a36c1@mail.gmail.com>
References: <580af3b90907071343i2f4cdabble3445111fe9d0466@mail.gmail.com>
	<Pine.GSO.4.64.0907071404280.8751@sj-cse-717.cisco.com>
	<580af3b90907071420y43b8b5d8n56d863d2216a36c1@mail.gmail.com>
Message-ID: <f9a8f300907071503x326b3f08u65b160b9e209de12@mail.gmail.com>

You have to do this under the dialer int.  I've got a similar config
but on 871. In any case, I moved away from 1700 platform due to a
similar issue (but I don't remember the specifics, sorry.)

What version are you running now?

--William McCall

On Tue, Jul 7, 2009 at 4:20 PM, Clue Store<cluestore at gmail.com> wrote:
> It took the command under the pvc section, but after a "sho run" the config
> did not show up. Nor when I did a "show policy-map interface a0.1" did
> anything show up.
>
> I've looked through several docs on the cisco site, but did not come up with
> anything that seem'd to work.
>
> Will try to upgrade the IOS later tonight. Anyone else with any ideas??
>
> On Tue, Jul 7, 2009 at 4:06 PM, Siva Valliappan <svalliap at cisco.com> wrote:
>
>> IIRC you need to apply it on the ATM interface
>> e.g.
>>
>> Interface ATM0.1 point-to-point
>> .
>> .
>> pvc 1/100
>> ? service-policy output Voice
>>
>> regards
>> .siva
>>
>>
>>
>> On Tue, 7 Jul 2009, Clue Store wrote:
>>
>> ? Hi All,
>>>
>>>
>>> I am having a hard time trying to figure how to apply a QoS policy on this
>>> router. I have applied a few typical service-policies on the dialer
>>> interfaces, but a "show policy interface di0" shows packets being matched
>>> but nothing being dropped and the link is saturated. I believe the policy
>>> needs to be applied to the virtual-access interface that comes up when PPP
>>> negotiates, but i'm not quite sure how this would be done since the use of
>>> vpdn-groups are no longer used. Relevent config posted. Any suggestions
>>> are
>>> greatly appreciated. *And yes I know the service-policy is not applied to
>>> the dialer interface...this was due to it not working.
>>>
>>>
>>> class-map match-any VoIP
>>> match ip rtp 16384 16383
>>> match access-group name VoicePorts
>>> !
>>> !
>>> policy-map Voice
>>> class VoIP
>>> ?priority 256
>>> !
>>> !
>>> !
>>> !
>>> !
>>> interface Ethernet0
>>> ip address 192.168.10.1 255.255.255.0
>>> ip nat inside
>>> ip virtual-reassembly
>>> !
>>> interface Ethernet2
>>> no ip address
>>> shutdown
>>> hold-queue 100 out
>>> !
>>> interface ATM0
>>> no ip address
>>> load-interval 30
>>> no atm ilmi-keepalive
>>> dsl operating-mode auto
>>> !
>>> interface ATM0.1 point-to-point
>>> pvc 1/100
>>> ?encapsulation aal5snap
>>> ?pppoe-client dial-pool-number 1
>>> !
>>> !
>>> interface FastEthernet1
>>> duplex auto
>>> speed auto
>>> !
>>> interface FastEthernet2
>>> duplex auto
>>> speed auto
>>> !
>>> interface FastEthernet3
>>> duplex auto
>>> speed auto
>>> !
>>> interface FastEthernet4
>>> duplex auto
>>> speed auto
>>> !
>>> !
>>> interface Dialer0
>>> ip address negotiated
>>> ip mtu 1492
>>> ip nat outside
>>> ip virtual-reassembly
>>> encapsulation ppp
>>> ip tcp adjust-mss 1412
>>> dialer pool 1
>>> no cdp enable
>>> <ppp info ************>
>>> !
>>> ip forward-protocol nd
>>> ip route 0.0.0.0 0.0.0.0 Dialer0
>>> !
>>> ip http server
>>> no ip http secure-server
>>> !
>>> no ip nat service skinny tcp port 2000
>>> no ip nat service sip udp port 5060
>>> ip nat inside source list 10 interface Dialer0 overload
>>> !
>>> !
>>> ip access-list extended VoicePorts
>>> permit udp any host *.*.*.* range 22026 62025
>>> permit udp any host *.*.*.* range 22026 62025
>>> access-list 10 permit 192.168.10.0 0.0.0.255
>>> _______________________________________________
>>> cisco-nsp mailing 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 jean at gervers.com  Tue Jul  7 18:31:16 2009
From: jean at gervers.com (Jean Gervers)
Date: Wed, 8 Jul 2009 00:31:16 +0200
Subject: [c-nsp] CBWFQ with LLQ on Cisco 876
Message-ID: <1818C821-CDCD-4DFA-985E-D51C63EADBD1@gervers.com>

Hi,

does anybody know if the Cisco 876 is supporting LLQ on Dialer  
Interfaces (PPPoE over ATM)?

The Packets are classified correctly by NBAR:

     Class-map: ef (match-all)
       21 packets, 5124 bytes
       5 minute offered rate 1000 bps, drop rate 0 bps
       Match:  dscp ef (46)
       Priority: 33% (304 kbps), burst bytes 7600, b/w exceed drops: 0


and the dialer and corresponding virtual-access interface use Class- 
based queueing as queueing strategy:


Dialer1 is up, line protocol is up (spoofing)
    Interface is bound to Vi1
    Output queue: 0/1000/0 (size/max total/drops)

Virtual-Access1 is up, line protocol is up
   Queueing strategy: Class-based queueing



But I still expiernce a huge Jitter/Delay when I start other high  
volume TCP Connections.


Thanks in advance,

Jean


From jean at gervers.com  Tue Jul  7 19:35:11 2009
From: jean at gervers.com (Jean Gervers)
Date: Wed, 8 Jul 2009 01:35:11 +0200
Subject: [c-nsp] CBWFQ with LLQ on Cisco 876
In-Reply-To: <1818C821-CDCD-4DFA-985E-D51C63EADBD1@gervers.com>
References: <1818C821-CDCD-4DFA-985E-D51C63EADBD1@gervers.com>
Message-ID: <4A06367C-ED83-44FB-BDB8-CA53B7505AAE@gervers.com>

Sorry Guys,

figured it out by myself - "vbr-nrt" is the magic word:

interface ATM0
  no ip address
  no atm ilmi-keepalive
!
interface ATM0.1 point-to-point
  no ip redirects
  no ip unreachables
  no ip proxy-arp
  pvc 1/32
   vbr-nrt 923 923
   tx-ring-limit 2
   encapsulation aal5snap
   service-policy output qos
   pppoe-client dial-pool-number 1

But the vbr-nrt rate depends on the dynamically negotiated DSL line  
speed :-( Is there any trick to change it automatically after a  
reconnect with a different line speed?

Jean


Am 08.07.2009 um 00:31 schrieb Jean Gervers:

> Hi,
>
> does anybody know if the Cisco 876 is supporting LLQ on Dialer  
> Interfaces (PPPoE over ATM)?
>
> The Packets are classified correctly by NBAR:
>
>    Class-map: ef (match-all)
>      21 packets, 5124 bytes
>      5 minute offered rate 1000 bps, drop rate 0 bps
>      Match:  dscp ef (46)
>      Priority: 33% (304 kbps), burst bytes 7600, b/w exceed drops: 0
>
>
> and the dialer and corresponding virtual-access interface use Class- 
> based queueing as queueing strategy:
>
>
> Dialer1 is up, line protocol is up (spoofing)
>   Interface is bound to Vi1
>   Output queue: 0/1000/0 (size/max total/drops)
>
> Virtual-Access1 is up, line protocol is up
>  Queueing strategy: Class-based queueing
>
>
>
> But I still expiernce a huge Jitter/Delay when I start other high  
> volume TCP Connections.
>
>
> Thanks in advance,
>
> Jean
>
> _______________________________________________
> cisco-nsp mailing list  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  Wed Jul  8 01:12:16 2009
From: ip at ioshints.info (Ivan Pepelnjak)
Date: Wed, 8 Jul 2009 07:12:16 +0200
Subject: [c-nsp] CBWFQ with LLQ on Cisco 876
In-Reply-To: <1818C821-CDCD-4DFA-985E-D51C63EADBD1@gervers.com>
References: <1818C821-CDCD-4DFA-985E-D51C63EADBD1@gervers.com>
Message-ID: <002801c9ff8a$aa1396b0$0a00000a@nil.si>

The problem you have is that there's no outbound queue forming on the Dialer
interface (PPPoE is too fast, as it goes over outside Ethernet).

http://blog.ioshints.info/2009/06/adsl-qos-basics.html

You have to apply shaping to force a queue to form. The shaping has to be
configured on the physical interface (outside Ethernet), not on the dialer
...

http://blog.ioshints.info/2009/07/not-all-interfaces-are-created-equal.html

 ... and then you'll hit another jitter problem (see comments in the
previous post)

I'm working on describing the whole problem (and the potential workarounds),
but it will take time.

Ivan
 
http://www.ioshints.info/about
http://blog.ioshints.info/

> -----Original Message-----
> From: Jean Gervers [mailto:jean at gervers.com] 
> Sent: Wednesday, July 08, 2009 12:31 AM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] CBWFQ with LLQ on Cisco 876
> 
> Hi,
> 
> does anybody know if the Cisco 876 is supporting LLQ on 
> Dialer Interfaces (PPPoE over ATM)?
> 
> The Packets are classified correctly by NBAR:
> 
>      Class-map: ef (match-all)
>        21 packets, 5124 bytes
>        5 minute offered rate 1000 bps, drop rate 0 bps
>        Match:  dscp ef (46)
>        Priority: 33% (304 kbps), burst bytes 7600, b/w exceed drops: 0
> 
> 
> and the dialer and corresponding virtual-access interface use 
> Class- based queueing as queueing strategy:
> 
> 
> Dialer1 is up, line protocol is up (spoofing)
>     Interface is bound to Vi1
>     Output queue: 0/1000/0 (size/max total/drops)
> 
> Virtual-Access1 is up, line protocol is up
>    Queueing strategy: Class-based queueing
> 
> 
> 
> But I still expiernce a huge Jitter/Delay when I start other high  
> volume TCP Connections.
> 
> 
> Thanks in advance,
> 
> Jean
> 
> 
> 


From victor.lyapunov at gmail.com  Wed Jul  8 02:39:35 2009
From: victor.lyapunov at gmail.com (Victor Lyapunov)
Date: Wed, 8 Jul 2009 09:39:35 +0300
Subject: [c-nsp] QoS on 837 using PPPoE
Message-ID: <bf19ffb40907072339q299336al954dd844d1375fc0@mail.gmail.com>

Hello I agree with the others, if you have to apply QoS for an ADSL link
(upstream traffic only) you must enforce some sort of queueing / shaping on
a lower layer. The ATM vc that your connection uses is the just right place
for this.

Just that when I tried something similar I could only make CBWFQ
work properly for the ADSL link if instead of vbr-nrt I used cbr for the VC.

This may be dependant on the IOS version but in any case be prepared to
experiment a little bit with the various QoS settings of the ATM VC.

> correct.  vbr-nrt only affects the output not the input.
>
>
> regards
> .siva
>
> On Tue, 7 Jul 2009, Clue Store wrote:
>
> Hi Siva,
>>
>> Your suggestions seem to have to have worked. Just so that I understand,
>> the
>> vbr-nrt shaping is just for the outbound cells and does not affect inbound
>> traffic correct?? This is a 3m/384k and I do not want to affect their
>> inbound. I could only reserve 288k in my policy (which is fine since the
>> upload is only 384k). And the logs did show why it did not take the
>> command
>> and I was able to adjust my policy as the logs suggested.
>>
>> I/f ATM0.1 VC 1/100 class VoIP requested bandwidth 320 (kbps), available
>> only 288 (kbps)
>>
>> This is now what shows up in the config....
>>
>> policy-map Voice
>> class VoIP
>>  priority 288
>>
>> interface ATM0.1 point-to-point
>> pvc 1/100
>>  vbr-nrt 384 384
>>  encapsulation aal5snap
>>  service-policy output Voice
>>  pppoe-client dial-pool-number 1
>>
>>
>>
>> On Tue, Jul 7, 2009 at 4:32 PM, Siva Valliappan <svalliap at cisco.com>
>> wrote:
>>
>> what does the log messages say?  a show log should tell you why it
>>> didn't accept the commands.
>>>
>>>
>>> On Tue, 7 Jul 2009, Clue Store wrote:
>>>
>>> It took the command under the pvc section, but after a "sho run" the
>>> config
>>>
>>>> did not show up. Nor when I did a "show policy-map interface a0.1" did
>>>> anything show up.
>>>>
>>>> I've looked through several docs on the cisco site, but did not come up
>>>> with
>>>> anything that seem'd to work.
>>>>
>>>> Will try to upgrade the IOS later tonight. Anyone else with any ideas??
>>>>
>>>> On Tue, Jul 7, 2009 at 4:06 PM, Siva Valliappan <svalliap at cisco.com>
>>>> wrote:
>>>>
>>>> IIRC you need to apply it on the ATM interface
>>>>
>>>>> e.g.
>>>>>
>>>>> Interface ATM0.1 point-to-point
>>>>> .
>>>>> .
>>>>> pvc 1/100
>>>>>  service-policy output Voice
>>>>>
>>>>> regards
>>>>> .siva
>>>>>
>>>>>
>>>>>
>>>>> On Tue, 7 Jul 2009, Clue Store wrote:
>>>>>
>>>>>  Hi All,
>>>>>
>>>>>
>>>>>>
>>>>>> I am having a hard time trying to figure how to apply a QoS policy on
>>>>>> this
>>>>>> router. I have applied a few typical service-policies on the dialer
>>>>>> interfaces, but a "show policy interface di0" shows packets being
>>>>>> matched
>>>>>> but nothing being dropped and the link is saturated. I believe the
>>>>>> policy
>>>>>> needs to be applied to the virtual-access interface that comes up when
>>>>>> PPP
>>>>>> negotiates, but i'm not quite sure how this would be done since the
>>>>>> use
>>>>>> of
>>>>>> vpdn-groups are no longer used. Relevent config posted. Any
>>>>>> suggestions
>>>>>> are
>>>>>> greatly appreciated. *And yes I know the service-policy is not applied
>>>>>> to
>>>>>> the dialer interface...this was due to it not working.
>>>>>>
>>>>>>
>>>>>> class-map match-any VoIP
>>>>>> match ip rtp 16384 16383
>>>>>> match access-group name VoicePorts
>>>>>> !
>>>>>> !
>>>>>> policy-map Voice
>>>>>> class VoIP
>>>>>>  priority 256
>>>>>> !
>>>>>> !
>>>>>> !
>>>>>> !
>>>>>> !
>>>>>> interface Ethernet0
>>>>>> ip address 192.168.10.1 255.255.255.0
>>>>>> ip nat inside
>>>>>> ip virtual-reassembly
>>>>>> !
>>>>>> interface Ethernet2
>>>>>> no ip address
>>>>>> shutdown
>>>>>> hold-queue 100 out
>>>>>> !
>>>>>> interface ATM0
>>>>>> no ip address
>>>>>> load-interval 30
>>>>>> no atm ilmi-keepalive
>>>>>> dsl operating-mode auto
>>>>>> !
>>>>>> interface ATM0.1 point-to-point
>>>>>> pvc 1/100
>>>>>>  encapsulation aal5snap
>>>>>>  pppoe-client dial-pool-number 1
>>>>>> !
>>>>>> !
>>>>>> interface FastEthernet1
>>>>>> duplex auto
>>>>>> speed auto
>>>>>> !
>>>>>> interface FastEthernet2
>>>>>> duplex auto
>>>>>> speed auto
>>>>>> !
>>>>>> interface FastEthernet3
>>>>>> duplex auto
>>>>>> speed auto
>>>>>> !
>>>>>> interface FastEthernet4
>>>>>> duplex auto
>>>>>> speed auto
>>>>>> !
>>>>>> !
>>>>>> interface Dialer0
>>>>>> ip address negotiated
>>>>>> ip mtu 1492
>>>>>> ip nat outside
>>>>>> ip virtual-reassembly
>>>>>> encapsulation ppp
>>>>>> ip tcp adjust-mss 1412
>>>>>> dialer pool 1
>>>>>> no cdp enable
>>>>>> <ppp info ************>
>>>>>> !
>>>>>> ip forward-protocol nd
>>>>>> ip route 0.0.0.0 0.0.0.0 Dialer0
>>>>>> !
>>>>>> ip http server
>>>>>> no ip http secure-server
>>>>>> !
>>>>>> no ip nat service skinny tcp port 2000
>>>>>> no ip nat service sip udp port 5060
>>>>>> ip nat inside source list 10 interface Dialer0 overload
>>>>>> !
>>>>>> !
>>>>>> ip access-list extended VoicePorts
>>>>>> permit udp any host *.*.*.* range 22026 62025
>>>>>> permit udp any host *.*.*.* range 22026 62025
>>>>>> access-list 10 permit 192.168.10.0 0.0.0.255
>>>>>> _______________________________________________
>>>>>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>>>>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>>>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>

From dean at eatworms.org.uk  Wed Jul  8 03:46:14 2009
From: dean at eatworms.org.uk (Dean Smith)
Date: Wed, 8 Jul 2009 08:46:14 +0100
Subject: [c-nsp] QoS on 837 using PPPoE
References: <580af3b90907071343i2f4cdabble3445111fe9d0466@mail.gmail.com><Pine.GSO.4.64.0907071404280.8751@sj-cse-717.cisco.com><580af3b90907071420y43b8b5d8n56d863d2216a36c1@mail.gmail.com><Pine.GSO.4.64.0907071431540.7822@sj-cse-717.cisco.com><580af3b90907071448o6615594dh65ce88a2dedfd404@mail.gmail.com><Pine.GSO.4.64.0907071457410.7822@sj-cse-717.cisco.com>
	<580af3b90907071500i448893c7g5be0ba497c7351b@mail.gmail.com>
Message-ID: <E9F795AE49DC4F1D866F99CB42DAC2CA@experienbd1776>

In addition when working on QoS on PPPoA we found...

With the SP on the physical vbr-nrt is indeed required. But that breaks the 
automatic tracking of the PVC size to the negotiated upstream rate on rate 
adaptive DSL. So we had to use TCL to track the DSL speed and change the 
VBR-NRT size to match ( we do this hourly in some cases / nightly in others)

Also we usually mark DSCP via the same SP as the policing - but with the SP 
on the ATM interface this was broken. So we have to mark inbound on the LAN 
and shape outbound on the ATM giving 2 policies to maintain.

If you run MLPPP - then you can do everything on one SP on the bundle 
interface but that gave 2 further issues - scaling the head end for MLPPP 
performance and we had random drop outs of the Multilink leaving us with no 
QoS at all.

All in all - not exactly simple and took months and months of lab work to 
get right. Cisco should be taking a long hard look at the architecture for 
future xDSL variants - and some decent doumentation wouldnt go amiss either.


From ip at ioshints.info  Wed Jul  8 04:05:14 2009
From: ip at ioshints.info (Ivan Pepelnjak)
Date: Wed, 8 Jul 2009 10:05:14 +0200
Subject: [c-nsp] IOS XR BFD
In-Reply-To: <383357750907070731g677aa1fdm8638101f1bc0cdb2@mail.gmail.com>
References: <501de4ea0907022344o2d57271cob04635b8f8557b6f@mail.gmail.com>
	<1246613652_586037@mail1.tellurian.net>
	<480dad640907030928g409fb93cle53eca875bae3c31@mail.gmail.com>
	<501de4ea0907032319y60b0ef9ahb0d246bb245ad7f4@mail.gmail.com>
	<77c10e260907041340x5177e348h2eadca6d4928c75c@mail.gmail.com>
	<501de4ea0907042250t64f4514m9350c45e398330b1@mail.gmail.com>
	<77c10e260907050559i4bfd323ch41435b5446efd333@mail.gmail.com>
	<501de4ea0907050902i675d53basfca4350ecabeabfe@mail.gmail.com>
	<70B7A1CCBFA5C649BD562B6D9F7ED7840798ECBA@xmb-ams-333.emea.cisco.com>
	<004301c9fe53$fa010000$0a00000a@nil.si>
	<383357750907070731g677aa1fdm8638101f1bc0cdb2@mail.gmail.com>
Message-ID: <003201c9ffa2$d40482a0$0a00000a@nil.si>

I've been planning to document the shortcomings of "Fast Peering Session
Deactivation" for a long time; thanks for the nudge.

Summary: following an interface loss (on the BGP router) in an OSPF or IS-IS
network, you might lose the route toward your BGP neighbor until SPF is run,
resulting in BGP session loss.

I've written an article in our wiki for those of you who want to know more:

http://wiki.nil.com/Aggressive_BGP_fall-over_behavior

Ivan
 
http://www.ioshints.info/about
http://blog.ioshints.info/

> -----Original Message-----
> From: Mateusz Blaszczyk [mailto:blahu77 at gmail.com] 
> Sent: Tuesday, July 07, 2009 4:31 PM
> To: Ivan Pepelnjak
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] IOS XR BFD
> 
> Ivan,
> 
> >
> > BTW, even the more "traditional" fast convergence 
> techniques (internal 
> > BGP fast fallover) might be too aggressive and do more harm 
> than good.
> >
> 
> Could you elaborate little more on that?
> I thought it would be a good idea (e.g. neighbor X fall-over
> route-map) to drop BGP session with a neighbour that suddenly 
> "dissapeared" from the network.
> In my scenario I am concerned that the scanner doesn't 
> invalidate the routes because I have catch-all aggregate 
> covering all my NHs floating there (I can't have full table 
> so I have 0/0 from upstreams so I need the aggregate for my 
> routes) so in other words it takes 3 minutes to close the 
> broken session.
> 
> Best Regards,
> 
> -mat
> 


From rens at autempspourmoi.be  Wed Jul  8 05:38:56 2009
From: rens at autempspourmoi.be (Rens)
Date: Wed, 8 Jul 2009 11:38:56 +0200
Subject: [c-nsp] round-trip differences towards google
Message-ID: <57025E9B4BCE4F36BD878A875F36C226@EU.corp.clearwire.com>

Hi all,

 

I'm having some difficulties understand some round-trip difference on the
same router just by changing the source interface:

 

Pings are done towards a resolved IP of www.google.be

 

ping 209.85.227.103 repeat 50

 

Type escape sequence to abort.

Sending 50, 100-byte ICMP Echos to 209.85.227.103, timeout is 2 seconds:

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Success rate is 100 percent (50/50), round-trip min/avg/max = 8/9/12 ms

 

ping 209.85.227.103 repeat 50 source AT3/0.102

 

Type escape sequence to abort.

Sending 50, 100-byte ICMP Echos to 209.85.227.103, timeout is 2 seconds:

Packet sent with a source address of xxx

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Success rate is 100 percent (50/50), round-trip min/avg/max = 8/9/12 ms

 

ping 209.85.227.103 repeat 50 source AT3/0.134

 

Type escape sequence to abort.

Sending 50, 100-byte ICMP Echos to 209.85.227.103, timeout is 2 seconds:

Packet sent with a source address of xxx 

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Success rate is 100 percent (50/50), round-trip min/avg/max = 80/83/88 ms

 

ping 209.85.227.103 repeat 50 source lo0 

 

Type escape sequence to abort.

Sending 50, 100-byte ICMP Echos to 209.85.227.103, timeout is 2 seconds:

Packet sent with a source address of xxx 

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Success rate is 100 percent (50/50), round-trip min/avg/max = 80/83/88 ms

 

Is this google magic depending on my source IP address?

 

Regards,

 

Rens


From david.freedman at uk.clara.net  Wed Jul  8 06:20:51 2009
From: david.freedman at uk.clara.net (David Freedman)
Date: Wed, 08 Jul 2009 11:20:51 +0100
Subject: [c-nsp] round-trip differences towards google
In-Reply-To: <57025E9B4BCE4F36BD878A875F36C226@EU.corp.clearwire.com>
References: <57025E9B4BCE4F36BD878A875F36C226@EU.corp.clearwire.com>
Message-ID: <h31ru3$vi9$1@ger.gmane.org>

Rens wrote:
> Hi all,
> 
>  
> 
> I'm having some difficulties understand some round-trip difference on the
> same router just by changing the source interface:
> 
>  
your source address will of course become the destination address which
google's equipment will want to send the ICMP replies back to, google's
return routing will dictate the path latency.

Dave.


From rens at autempspourmoi.be  Wed Jul  8 06:36:55 2009
From: rens at autempspourmoi.be (Rens)
Date: Wed, 8 Jul 2009 12:36:55 +0200
Subject: [c-nsp] round-trip differences towards google
In-Reply-To: <h31ru3$vi9$1@ger.gmane.org>
References: <57025E9B4BCE4F36BD878A875F36C226@EU.corp.clearwire.com>
	<h31ru3$vi9$1@ger.gmane.org>
Message-ID: <8BBA9CAF2CAD42F381333BCD97722C3A@EU.corp.clearwire.com>

I expect the return routing to be the same as for all my IP addresses since
they are all advertised in the same way.

I guess google doesn't handle them the same way?

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of David Freedman
Sent: mercredi 8 juillet 2009 12:21
To: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] round-trip differences towards google

Rens wrote:
> Hi all,
> 
>  
> 
> I'm having some difficulties understand some round-trip difference on the
> same router just by changing the source interface:
> 
>  
your source address will of course become the destination address which
google's equipment will want to send the ICMP replies back to, google's
return routing will dictate the path latency.

Dave.

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


From erik at infopact.nl  Wed Jul  8 06:45:12 2009
From: erik at infopact.nl (E. Versaevel)
Date: Wed, 08 Jul 2009 12:45:12 +0200
Subject: [c-nsp] round-trip differences towards google
In-Reply-To: <8BBA9CAF2CAD42F381333BCD97722C3A@EU.corp.clearwire.com>
References: <57025E9B4BCE4F36BD878A875F36C226@EU.corp.clearwire.com>	<h31ru3$vi9$1@ger.gmane.org>
	<8BBA9CAF2CAD42F381333BCD97722C3A@EU.corp.clearwire.com>
Message-ID: <4A5478B8.2060203@infopact.nl>

Is there a difference when you traceroute with different source ip's ?

Rens schreef:
> I expect the return routing to be the same as for all my IP addresses since
> they are all advertised in the same way.
> 
> I guess google doesn't handle them the same way?
> 
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of David Freedman
> Sent: mercredi 8 juillet 2009 12:21
> To: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] round-trip differences towards google
> 
> Rens wrote:
>> Hi all,
>>
>>  
>>
>> I'm having some difficulties understand some round-trip difference on the
>> same router just by changing the source interface:
>>
>>  
> your source address will of course become the destination address which
> google's equipment will want to send the ICMP replies back to, google's
> return routing will dictate the path latency.
> 
> Dave.
> 
> _______________________________________________
> cisco-nsp mailing 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/



Erik Versaevel

From rens at autempspourmoi.be  Wed Jul  8 08:38:58 2009
From: rens at autempspourmoi.be (Rens)
Date: Wed, 8 Jul 2009 14:38:58 +0200
Subject: [c-nsp] round-trip differences towards google
In-Reply-To: <4A5478B8.2060203@infopact.nl>
References: <57025E9B4BCE4F36BD878A875F36C226@EU.corp.clearwire.com>	<h31ru3$vi9$1@ger.gmane.org>
	<8BBA9CAF2CAD42F381333BCD97722C3A@EU.corp.clearwire.com>
	<4A5478B8.2060203@infopact.nl>
Message-ID: <F0FDA12589DA4BFF9B14916694B2998F@EU.corp.clearwire.com>

They both leave my network via the same IP transit but then afterwards some
hops are different...

-----Original Message-----
From: E. Versaevel [mailto:erik at infopact.nl] 
Sent: mercredi 8 juillet 2009 12:45
To: Rens
Cc: 'David Freedman'; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] round-trip differences towards google

Is there a difference when you traceroute with different source ip's ?

Rens schreef:
> I expect the return routing to be the same as for all my IP addresses
since
> they are all advertised in the same way.
> 
> I guess google doesn't handle them the same way?
> 
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of David Freedman
> Sent: mercredi 8 juillet 2009 12:21
> To: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] round-trip differences towards google
> 
> Rens wrote:
>> Hi all,
>>
>>  
>>
>> I'm having some difficulties understand some round-trip difference on the
>> same router just by changing the source interface:
>>
>>  
> your source address will of course become the destination address which
> google's equipment will want to send the ICMP replies back to, google's
> return routing will dictate the path latency.
> 
> Dave.
> 
> _______________________________________________
> cisco-nsp mailing 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/



Erik Versaevel


From irenna at gmail.com  Wed Jul  8 09:03:36 2009
From: irenna at gmail.com (Irena Nikolova)
Date: Wed, 8 Jul 2009 15:03:36 +0200
Subject: [c-nsp] round-trip differences towards google
In-Reply-To: <F0FDA12589DA4BFF9B14916694B2998F@EU.corp.clearwire.com>
References: <57025E9B4BCE4F36BD878A875F36C226@EU.corp.clearwire.com>
	<h31ru3$vi9$1@ger.gmane.org>
	<8BBA9CAF2CAD42F381333BCD97722C3A@EU.corp.clearwire.com>
	<4A5478B8.2060203@infopact.nl>
	<F0FDA12589DA4BFF9B14916694B2998F@EU.corp.clearwire.com>
Message-ID: <938a20760907080603t133b2d86m705a15af4cac16c9@mail.gmail.com>

Which would explain the differences between the round-trip times. You can
see the latency value on every hop when you do traceroute, where does it
increase?

On Wed, Jul 8, 2009 at 2:38 PM, Rens <rens at autempspourmoi.be> wrote:

> They both leave my network via the same IP transit but then afterwards some
> hops are different...
>
> -----Original Message-----
> From: E. Versaevel [mailto:erik at infopact.nl]
> Sent: mercredi 8 juillet 2009 12:45
> To: Rens
> Cc: 'David Freedman'; cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] round-trip differences towards google
>
> Is there a difference when you traceroute with different source ip's ?
>
> Rens schreef:
> > I expect the return routing to be the same as for all my IP addresses
> since
> > they are all advertised in the same way.
> >
> > I guess google doesn't handle them the same way?
> >
> > -----Original Message-----
> > From: cisco-nsp-bounces at puck.nether.net
> > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of David Freedman
> > Sent: mercredi 8 juillet 2009 12:21
> > To: cisco-nsp at puck.nether.net
> > Subject: Re: [c-nsp] round-trip differences towards google
> >
> > Rens wrote:
> >> Hi all,
> >>
> >>
> >>
> >> I'm having some difficulties understand some round-trip difference on
> the
> >> same router just by changing the source interface:
> >>
> >>
> > your source address will of course become the destination address which
> > google's equipment will want to send the ICMP replies back to, google's
> > return routing will dictate the path latency.
> >
> > Dave.
> >
> > _______________________________________________
> > cisco-nsp mailing 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/
>
>
>
> Erik Versaevel
>

From rens at autempspourmoi.be  Wed Jul  8 09:11:30 2009
From: rens at autempspourmoi.be (Rens)
Date: Wed, 8 Jul 2009 15:11:30 +0200
Subject: [c-nsp] round-trip differences towards google
In-Reply-To: <938a20760907080603t133b2d86m705a15af4cac16c9@mail.gmail.com>
References: <57025E9B4BCE4F36BD878A875F36C226@EU.corp.clearwire.com>
	<h31ru3$vi9$1@ger.gmane.org>
	<8BBA9CAF2CAD42F381333BCD97722C3A@EU.corp.clearwire.com>
	<4A5478B8.2060203@infopact.nl>
	<F0FDA12589DA4BFF9B14916694B2998F@EU.corp.clearwire.com>
	<938a20760907080603t133b2d86m705a15af4cac16c9@mail.gmail.com>
Message-ID: <84974A55BD1B4402BD3C326BD86B4253@EU.corp.clearwire.com>

When it goes from my IP transit provider to google it increases.

 

  _____  

From: Irena Nikolova [mailto:irenna at gmail.com] 
Sent: mercredi 8 juillet 2009 15:04
To: Rens
Cc: E. Versaevel; David Freedman; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] round-trip differences towards google

 

Which would explain the differences between the round-trip times. You can
see the latency value on every hop when you do traceroute, where does it
increase?

On Wed, Jul 8, 2009 at 2:38 PM, Rens <rens at autempspourmoi.be> wrote:

They both leave my network via the same IP transit but then afterwards some
hops are different...


-----Original Message-----
From: E. Versaevel [mailto:erik at infopact.nl]
Sent: mercredi 8 juillet 2009 12:45
To: Rens
Cc: 'David Freedman'; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] round-trip differences towards google

Is there a difference when you traceroute with different source ip's ?

Rens schreef:
> I expect the return routing to be the same as for all my IP addresses
since
> they are all advertised in the same way.
>
> I guess google doesn't handle them the same way?
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of David Freedman
> Sent: mercredi 8 juillet 2009 12:21
> To: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] round-trip differences towards google
>
> Rens wrote:
>> Hi all,
>>
>>
>>
>> I'm having some difficulties understand some round-trip difference on the
>> same router just by changing the source interface:
>>
>>
> your source address will of course become the destination address which
> google's equipment will want to send the ICMP replies back to, google's
> return routing will dictate the path latency.
>
> Dave.
>
> _______________________________________________
> cisco-nsp mailing 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/



Erik Versaevel

 


From rodunn at cisco.com  Wed Jul  8 09:21:32 2009
From: rodunn at cisco.com (Rodney Dunn)
Date: Wed, 8 Jul 2009 09:21:32 -0400
Subject: [c-nsp] round-trip differences towards google
In-Reply-To: <F0FDA12589DA4BFF9B14916694B2998F@EU.corp.clearwire.com>
References: <57025E9B4BCE4F36BD878A875F36C226@EU.corp.clearwire.com>
	<h31ru3$vi9$1@ger.gmane.org>
	<8BBA9CAF2CAD42F381333BCD97722C3A@EU.corp.clearwire.com>
	<4A5478B8.2060203@infopact.nl>
	<F0FDA12589DA4BFF9B14916694B2998F@EU.corp.clearwire.com>
Message-ID: <20090708132132.GA12862@rtp-cse-489.cisco.com>

If it's Cisco in the middle those packets in an equal cost routing
scenario, which is typical in the core for redundancy, will most likely
diverge to a different path due to the src/dst ip hashing.

The traceroute would show you if the paths diverge in the forward direction
but not in the reverse direction.

Rodney

On Wed, Jul 08, 2009 at 02:38:58PM +0200, Rens wrote:
> They both leave my network via the same IP transit but then afterwards some
> hops are different...
> 
> -----Original Message-----
> From: E. Versaevel [mailto:erik at infopact.nl] 
> Sent: mercredi 8 juillet 2009 12:45
> To: Rens
> Cc: 'David Freedman'; cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] round-trip differences towards google
> 
> Is there a difference when you traceroute with different source ip's ?
> 
> Rens schreef:
> > I expect the return routing to be the same as for all my IP addresses
> since
> > they are all advertised in the same way.
> > 
> > I guess google doesn't handle them the same way?
> > 
> > -----Original Message-----
> > From: cisco-nsp-bounces at puck.nether.net
> > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of David Freedman
> > Sent: mercredi 8 juillet 2009 12:21
> > To: cisco-nsp at puck.nether.net
> > Subject: Re: [c-nsp] round-trip differences towards google
> > 
> > Rens wrote:
> >> Hi all,
> >>
> >>  
> >>
> >> I'm having some difficulties understand some round-trip difference on the
> >> same router just by changing the source interface:
> >>
> >>  
> > your source address will of course become the destination address which
> > google's equipment will want to send the ICMP replies back to, google's
> > return routing will dictate the path latency.
> > 
> > Dave.
> > 
> > _______________________________________________
> > cisco-nsp mailing 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/
> 
> 
> 
> Erik Versaevel
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

From b.turnbow at twt.it  Wed Jul  8 08:54:41 2009
From: b.turnbow at twt.it (Brian Turnbow)
Date: Wed, 8 Jul 2009 14:54:41 +0200
Subject: [c-nsp] round-trip differences towards google
In-Reply-To: <57025E9B4BCE4F36BD878A875F36C226@EU.corp.clearwire.com>
References: <57025E9B4BCE4F36BD878A875F36C226@EU.corp.clearwire.com>
Message-ID: <F2207DB22012F94E92D7030F81A26294025A7BD1@twt-exch.milano.twt>

 
As google is not a single server but a cloud of clusters of servers you are getting routed by a "load balancer" of some sort. 
In a nutshell this is what happens, the IP address 209.85.227.103 is a virtual address that gets sent to various real servers.
As the source address changes the load balancer sends to the request to different real servers. 
It is actually much more complicated, if you search for google infrastructure or google network architecture you can find much more detail. 
The video about how google uses containers in their data center is very interesting. 


Regards

Brian

  


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Rens
Sent: mercoled? 8 luglio 2009 11.39
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] round-trip differences towards google

Hi all,

 

I'm having some difficulties understand some round-trip difference on the
same router just by changing the source interface:

 

Pings are done towards a resolved IP of www.google.be

 

ping 209.85.227.103 repeat 50

 

Type escape sequence to abort.

Sending 50, 100-byte ICMP Echos to 209.85.227.103, timeout is 2 seconds:

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Success rate is 100 percent (50/50), round-trip min/avg/max = 8/9/12 ms

 

ping 209.85.227.103 repeat 50 source AT3/0.102

 

Type escape sequence to abort.

Sending 50, 100-byte ICMP Echos to 209.85.227.103, timeout is 2 seconds:

Packet sent with a source address of xxx

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Success rate is 100 percent (50/50), round-trip min/avg/max = 8/9/12 ms

 

ping 209.85.227.103 repeat 50 source AT3/0.134

 

Type escape sequence to abort.

Sending 50, 100-byte ICMP Echos to 209.85.227.103, timeout is 2 seconds:

Packet sent with a source address of xxx 

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Success rate is 100 percent (50/50), round-trip min/avg/max = 80/83/88 ms

 

ping 209.85.227.103 repeat 50 source lo0 

 

Type escape sequence to abort.

Sending 50, 100-byte ICMP Echos to 209.85.227.103, timeout is 2 seconds:

Packet sent with a source address of xxx 

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Success rate is 100 percent (50/50), round-trip min/avg/max = 80/83/88 ms

 

Is this google magic depending on my source IP address?

 

Regards,

 

Rens

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

From tkacprzynski at SpencerStuart.com  Wed Jul  8 10:31:44 2009
From: tkacprzynski at SpencerStuart.com (tkacprzynski at SpencerStuart.com)
Date: Wed, 8 Jul 2009 09:31:44 -0500
Subject: [c-nsp] round-trip differences towards google
In-Reply-To: <F2207DB22012F94E92D7030F81A26294025A7BD1@twt-exch.milano.twt>
References: <57025E9B4BCE4F36BD878A875F36C226@EU.corp.clearwire.com>
	<F2207DB22012F94E92D7030F81A26294025A7BD1@twt-exch.milano.twt>
Message-ID: <A8A11BA006DA57498FAC0A56686865042ABBB2AE@usilwdex04.spencerstuart.com>

This relates to google, does anyone know how they do their global DNS resolution? I am having few issues resolving to the closest google datacenter webserver (i.e. Sydney users resolved to US servers [verified by traceroute])?

Thanks



-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Brian Turnbow
Sent: Wednesday, July 08, 2009 7:55 AM
To: Rens; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] round-trip differences towards google

 
As google is not a single server but a cloud of clusters of servers you are getting routed by a "load balancer" of some sort. 
In a nutshell this is what happens, the IP address 209.85.227.103 is a virtual address that gets sent to various real servers.
As the source address changes the load balancer sends to the request to different real servers. 
It is actually much more complicated, if you search for google infrastructure or google network architecture you can find much more detail. 
The video about how google uses containers in their data center is very interesting. 


Regards

Brian

  


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Rens
Sent: mercoled? 8 luglio 2009 11.39
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] round-trip differences towards google

Hi all,

 

I'm having some difficulties understand some round-trip difference on the
same router just by changing the source interface:

 

Pings are done towards a resolved IP of www.google.be

 

ping 209.85.227.103 repeat 50

 

Type escape sequence to abort.

Sending 50, 100-byte ICMP Echos to 209.85.227.103, timeout is 2 seconds:

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Success rate is 100 percent (50/50), round-trip min/avg/max = 8/9/12 ms

 

ping 209.85.227.103 repeat 50 source AT3/0.102

 

Type escape sequence to abort.

Sending 50, 100-byte ICMP Echos to 209.85.227.103, timeout is 2 seconds:

Packet sent with a source address of xxx

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Success rate is 100 percent (50/50), round-trip min/avg/max = 8/9/12 ms

 

ping 209.85.227.103 repeat 50 source AT3/0.134

 

Type escape sequence to abort.

Sending 50, 100-byte ICMP Echos to 209.85.227.103, timeout is 2 seconds:

Packet sent with a source address of xxx 

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Success rate is 100 percent (50/50), round-trip min/avg/max = 80/83/88 ms

 

ping 209.85.227.103 repeat 50 source lo0 

 

Type escape sequence to abort.

Sending 50, 100-byte ICMP Echos to 209.85.227.103, timeout is 2 seconds:

Packet sent with a source address of xxx 

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Success rate is 100 percent (50/50), round-trip min/avg/max = 80/83/88 ms

 

Is this google magic depending on my source IP address?

 

Regards,

 

Rens

_______________________________________________
cisco-nsp mailing 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 js at jspringer.net  Wed Jul  8 10:04:30 2009
From: js at jspringer.net (J Springer)
Date: Wed, 08 Jul 2009 09:04:30 -0500
Subject: [c-nsp] SAMI Module
Message-ID: <4A54A76E.1010103@jspringer.net>

I am interested in feedback regarding the SAMI module for Q-in-Q termination on 
the 7600 platform.  The preference is to avoid the cost of the ES+ card as other 
configuration options are not needed at this time.

Thanks in advance.

From lists at nexus6.co.za  Wed Jul  8 12:09:20 2009
From: lists at nexus6.co.za (Andy Ashley)
Date: Wed, 08 Jul 2009 18:09:20 +0200
Subject: [c-nsp] Multi-site single AS architecture
Message-ID: <4A54C4B0.70608@nexus6.co.za>

Hi,

Apologies for this long post, I am hoping to explain in full:
(there was a similar thread recently but Im looking for slighly 
different info)

Background:
We currently have a primary site which has two 7206 border routers, each 
has an uplink and ebgp session over that into our primary transit provider.
These border routers are also plugged into our two 6500 core switches 
(3BXL holding the full table).

There is also a metro ethernet circuit which is plugged into one of the 
core switches. This circuit goes to another site (plugged into another 
7206 there) on the other side of the city where we pick up some backup 
transit and peers at an exchange. All routers peer with one another in 
the ibgp mesh, the two seperate sites are in a confederation with 
different private AS numbers and externally are announced as the same 
AS. Presently all prefixes are announced via the primary site (tagged 
statics).

We need to make sure that this secondary site is visible should the 
metro ethernet break or the primary site is unavailable.
What we proposed to do was firstly re-address the second site to use 
seperate prefixes (few smaller /22 and /23 out of a larger aggregate 
announced from the primary site)
Then to put a route in at the secondary site to ensure that the prefix 
in use there would would still be announced via the backup transit 
provider and peers should the primary site or metro link have a problem.

We also need to be able to reach services at the secondary site from the 
primary should the metro link go down. This raises the problem of our 
routers not accepting thier own AS in the AS path.
I would prefer not to use the method of telling the routers to accept 
thier own AS in the path if possible. To get around this, we were 
thinking of using an xconnect tunnel to create a virtual backnet between 
border routers at each site. This should hopefully allow the ibgp 
sessions to stay up over this tunnel via the Internet instread of over 
the usually preferred direct connection.

We are using xconnect statements at the moment to extend some VLAN's 
across the metro link between sites (router loopbacks are the end points).
The MTU is set high at 9216 on the metro link and this works fine.

My questions:
1. Will the xconnect (encapsulation mpls) come up if connecting via the 
Internet instead of over a VLAN on the metro link?
2. What interface would be best to configure the xconnect from and to on 
each end?
3. Should we tell ibgp to peer with this interface instead of the 
loopbacks on each border router?
4. How reliable/recommended is this method? Im wary of imlementing 
something flaky..

Any comments or hints you may have to offer would be most welcome!


Thanks.
Andy.






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


From lists.james.edwards at gmail.com  Wed Jul  8 17:40:48 2009
From: lists.james.edwards at gmail.com (james edwards)
Date: Wed, 8 Jul 2009 15:40:48 -0600
Subject: [c-nsp] Extended demarc
Message-ID: <b7f636a60907081440n2433cc7fqa0071d364a696ef9@mail.gmail.com>

What is a real word limit on how far you can extend the demarc ? This is on
Cat5e cable. I get wildly different figures from Google.


Thanks,

-- 
James H. Edwards
Senior Network Systems Administrator
Judicial Information Division
jedwards at nmcourts.gov

From walter.keen at RainierConnect.net  Wed Jul  8 17:47:49 2009
From: walter.keen at RainierConnect.net (Walter Keen)
Date: Wed, 08 Jul 2009 14:47:49 -0700
Subject: [c-nsp] Extended demarc
In-Reply-To: <b7f636a60907081440n2433cc7fqa0071d364a696ef9@mail.gmail.com>
References: <b7f636a60907081440n2433cc7fqa0071d364a696ef9@mail.gmail.com>
Message-ID: <4A551405.3060300@rainierconnect.net>

You're supposed to be able to go 100meters(roughly 330ft) with ethernet 
over Cat5e, but the longest run we've had to date is approximately 260ft 
with no issues going through a shared vault space very close to power 
lines and have not yet seen any poor performance due to the length or 
interference from power cabling.

james edwards wrote:
> What is a real word limit on how far you can extend the demarc ? This is on
> Cat5e cable. I get wildly different figures from Google.
>
>
> Thanks,
>
>   

-- 


Walter Keen
Network Technician
Rainier Connect
(o) 360-832-4024
(c) 253-302-0194


From lists.james.edwards at gmail.com  Wed Jul  8 17:49:28 2009
From: lists.james.edwards at gmail.com (james edwards)
Date: Wed, 8 Jul 2009 15:49:28 -0600
Subject: [c-nsp] Extended demarc
In-Reply-To: <4A551405.3060300@rainierconnect.net>
References: <b7f636a60907081440n2433cc7fqa0071d364a696ef9@mail.gmail.com>
	<4A551405.3060300@rainierconnect.net>
Message-ID: <b7f636a60907081449y5fe35060k49aafaa7957b65fd@mail.gmail.com>

On Wed, Jul 8, 2009 at 3:47 PM, Walter Keen
<walter.keen at rainierconnect.net>wrote:

> You're supposed to be able to go 100meters(roughly 330ft) with ethernet
> over Cat5e, but the longest run we've had to date is approximately 260ft
> with no issues going through a shared vault space very close to power lines
> and have not yet seen any poor performance due to the length or interference
> from power cabling.
> j
>


Thanks. I failed to mention this is a T-1.

james

From ptimmins at clearrate.com  Wed Jul  8 17:56:01 2009
From: ptimmins at clearrate.com (Paul G. Timmins)
Date: Wed, 8 Jul 2009 17:56:01 -0400
Subject: [c-nsp] Extended demarc
In-Reply-To: <b7f636a60907081440n2433cc7fqa0071d364a696ef9@mail.gmail.com>
References: <b7f636a60907081440n2433cc7fqa0071d364a696ef9@mail.gmail.com>
Message-ID: <B98837F93D40A74D8656EAE7C1F57C5659DB21@EXCHANGE1.corp.clearrate.net>

If you're asking about T1s, we've extended a demarc 23 stories over
Category 0 building pair from the 70s or 80s and the circuit has run
flawlessly. You have to test the cables when they're that old due to
building sway causing shorts and things like that, but it works. T1s are
designed to go several miles without repeaters on cable you'd barely
want to run voice over.

Ethernet IIRC can only go 300 meters or something like that, regardless
of how fancy your cable is due to timing issues and the speed of light.
But I don't extend Ethernet very often so I'm not an expert in that
part.

-Paul

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of james edwards
Sent: Wednesday, July 08, 2009 5:41 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Extended demarc

What is a real word limit on how far you can extend the demarc ? This is
on
Cat5e cable. I get wildly different figures from Google.


Thanks,

-- 
James H. Edwards
Senior Network Systems Administrator
Judicial Information Division
jedwards at nmcourts.gov
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From jay at west.net  Wed Jul  8 18:00:06 2009
From: jay at west.net (Jay Hennigan)
Date: Wed, 08 Jul 2009 15:00:06 -0700
Subject: [c-nsp] Extended demarc
In-Reply-To: <b7f636a60907081440n2433cc7fqa0071d364a696ef9@mail.gmail.com>
References: <b7f636a60907081440n2433cc7fqa0071d364a696ef9@mail.gmail.com>
Message-ID: <4A5516E6.6020700@west.net>

james edwards wrote:
> What is a real word limit on how far you can extend the demarc ? This is on
> Cat5e cable. I get wildly different figures from Google.

What underlying protocol?  Ethernet?  T1?  ADSL?  BRI?

That's why the figures are wildly different.  :-)

--
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 jackson.tim at gmail.com  Wed Jul  8 18:13:53 2009
From: jackson.tim at gmail.com (Tim Jackson)
Date: Wed, 8 Jul 2009 17:13:53 -0500
Subject: [c-nsp] Extended demarc
In-Reply-To: <b7f636a60907081440n2433cc7fqa0071d364a696ef9@mail.gmail.com>
References: <b7f636a60907081440n2433cc7fqa0071d364a696ef9@mail.gmail.com>
Message-ID: <4407932e0907081513o61f6d877h7b184f18b989c147@mail.gmail.com>

655 ft over 22awg, but probably just as fine over 24awg in cat5, too...

You'll need to have the smartjack adjusted to a longer line build out,
as well as your CSU.

--
Tim

On Wed, Jul 8, 2009 at 4:40 PM, james
edwards<lists.james.edwards at gmail.com> wrote:
> What is a real word limit on how far you can extend the demarc ? This is on
> Cat5e cable. I get wildly different figures from Google.
>
>
> Thanks,
>
> --
> James H. Edwards
> Senior Network Systems Administrator
> Judicial Information Division
> jedwards at nmcourts.gov
> _______________________________________________
> cisco-nsp mailing list ?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  Wed Jul  8 18:22:01 2009
From: justin at justinshore.com (Justin Shore)
Date: Wed, 08 Jul 2009 17:22:01 -0500
Subject: [c-nsp] Baseline CoPP policies?
In-Reply-To: <Pine.GSO.4.64.0907071410460.8751@sj-cse-717.cisco.com>
References: <F3318834F1F89D46857972DD4B411D7011C3D55F@EXCHANGE.thenap.com>	<000001c9ff42$b95d1760$2101a8c0@reap>
	<Pine.GSO.4.64.0907071410460.8751@sj-cse-717.cisco.com>
Message-ID: <4A551C09.1070507@justinshore.com>

One thing that the documentation always lacks is sufficient info on 
handling IS-IS with CoPP.  The inability of IOS to match IS-IS traffic 
without using class-default is a major problem.  Of all the people that 
would need CoPP (people with publicly exposed routers like SPs) one 
would think that IS-IS support for CoPP would be a big deal.

Is there a specific dev group within Cisco that I can point my account 
team to that would be the one to consider my feature request.

Justin


Siva Valliappan wrote:
> Hi Drew,
> 
>    have you looked at the following docs:
> 
> http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html
> 
> and
> 
> http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6642/prod_white_paper0900aecd804fa16a.html 

From svalliap at cisco.com  Wed Jul  8 18:43:06 2009
From: svalliap at cisco.com (Siva Valliappan)
Date: Wed, 8 Jul 2009 15:43:06 -0700 (PDT)
Subject: [c-nsp] Baseline CoPP policies?
In-Reply-To: <4A551C09.1070507@justinshore.com>
References: <F3318834F1F89D46857972DD4B411D7011C3D55F@EXCHANGE.thenap.com>
	<000001c9ff42$b95d1760$2101a8c0@reap>
	<Pine.GSO.4.64.0907071410460.8751@sj-cse-717.cisco.com>
	<4A551C09.1070507@justinshore.com>
Message-ID: <Pine.GSO.4.64.0907081542080.16483@sj-cse-717.cisco.com>

the platform team should be able to work with the NSSTG QoS team to
get this to happen.  you might want to direct your account team at your
platform team.  they in turn can work with the QoS team to get the necessary
MQC extensions.

regards
.siva

On Wed, 8 Jul 2009, Justin Shore wrote:

> One thing that the documentation always lacks is sufficient info on handling 
> IS-IS with CoPP.  The inability of IOS to match IS-IS traffic without using 
> class-default is a major problem.  Of all the people that would need CoPP 
> (people with publicly exposed routers like SPs) one would think that IS-IS 
> support for CoPP would be a big deal.
>
> Is there a specific dev group within Cisco that I can point my account team 
> to that would be the one to consider my feature request.
>
> Justin
>
>
> Siva Valliappan wrote:
>> Hi Drew,
>>
>>    have you looked at the following docs:
>> 
>> http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html
>> 
>> and
>> 
>> http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6642/prod_white_paper0900aecd804fa16a.html

From merlyn at Geeks.ORG  Wed Jul  8 18:14:10 2009
From: merlyn at Geeks.ORG (Doug McIntyre)
Date: Wed, 8 Jul 2009 17:14:10 -0500
Subject: [c-nsp] Extended demarc
In-Reply-To: <b7f636a60907081449y5fe35060k49aafaa7957b65fd@mail.gmail.com>
References: <b7f636a60907081440n2433cc7fqa0071d364a696ef9@mail.gmail.com>
	<4A551405.3060300@rainierconnect.net>
	<b7f636a60907081449y5fe35060k49aafaa7957b65fd@mail.gmail.com>
Message-ID: <20090708221410.GB59811@geeks.org>

On Wed, Jul 08, 2009 at 03:49:28PM -0600, james edwards wrote:
> On Wed, Jul 8, 2009 at 3:47 PM, Walter Keen
> <walter.keen at rainierconnect.net>wrote:
> 
> > You're supposed to be able to go 100meters(roughly 330ft) with ethernet
> > over Cat5e, but the longest run we've had to date is approximately 260ft
> > with no issues going through a shared vault space very close to power lines
> > and have not yet seen any poor performance due to the length or interference
> > from power cabling.

> Thanks. I failed to mention this is a T-1.

~205m for T1 on Cat5e/Cat6 +/- some for each DSX/patch panel.
But probably even longer in the real world.


From david at hughes.com.au  Wed Jul  8 19:20:08 2009
From: david at hughes.com.au (David Hughes)
Date: Thu, 9 Jul 2009 09:20:08 +1000
Subject: [c-nsp] Multi-site single AS architecture
In-Reply-To: <4A54C4B0.70608@nexus6.co.za>
References: <4A54C4B0.70608@nexus6.co.za>
Message-ID: <04454248-A93B-4430-B57D-55AC6633418E@hughes.com.au>


Hi

So that you don't pollute the global table all the time you could use  
a conditional advertisement at the remote site and only advertise the  
more specific routes if you don't see your main aggregate in your  
table  (i.e. the aggregate would be there via iBGP if the metro link  
was up).

As for inter-site if the metro fails, I appreciate you have a full  
table but running a default route as well will get you over this.  Or  
you could redist a static for the remote site subnets from your 7200's  
with a lower local-pref.  Various options there.


David
...

On 09/07/2009, at 2:09 AM, Andy Ashley wrote:

> Hi,
>
> Apologies for this long post, I am hoping to explain in full:
> (there was a similar thread recently but Im looking for slighly  
> different info)
>
> Background:
> We currently have a primary site which has two 7206 border routers,  
> each has an uplink and ebgp session over that into our primary  
> transit provider.
> These border routers are also plugged into our two 6500 core  
> switches (3BXL holding the full table).
>
> There is also a metro ethernet circuit which is plugged into one of  
> the core switches. This circuit goes to another site (plugged into  
> another 7206 there) on the other side of the city where we pick up  
> some backup transit and peers at an exchange. All routers peer with  
> one another in the ibgp mesh, the two seperate sites are in a  
> confederation with different private AS numbers and externally are  
> announced as the same AS. Presently all prefixes are announced via  
> the primary site (tagged statics).
>
> We need to make sure that this secondary site is visible should the  
> metro ethernet break or the primary site is unavailable.
> What we proposed to do was firstly re-address the second site to use  
> seperate prefixes (few smaller /22 and /23 out of a larger aggregate  
> announced from the primary site)
> Then to put a route in at the secondary site to ensure that the  
> prefix in use there would would still be announced via the backup  
> transit provider and peers should the primary site or metro link  
> have a problem.
>
> We also need to be able to reach services at the secondary site from  
> the primary should the metro link go down. This raises the problem  
> of our routers not accepting thier own AS in the AS path.
> I would prefer not to use the method of telling the routers to  
> accept thier own AS in the path if possible. To get around this, we  
> were thinking of using an xconnect tunnel to create a virtual  
> backnet between border routers at each site. This should hopefully  
> allow the ibgp sessions to stay up over this tunnel via the Internet  
> instread of over the usually preferred direct connection.
>
> We are using xconnect statements at the moment to extend some VLAN's  
> across the metro link between sites (router loopbacks are the end  
> points).
> The MTU is set high at 9216 on the metro link and this works fine.
>
> My questions:
> 1. Will the xconnect (encapsulation mpls) come up if connecting via  
> the Internet instead of over a VLAN on the metro link?
> 2. What interface would be best to configure the xconnect from and  
> to on each end?
> 3. Should we tell ibgp to peer with this interface instead of the  
> loopbacks on each border router?
> 4. How reliable/recommended is this method? Im wary of imlementing  
> something flaky..
>
> Any comments or hints you may have to offer would be most welcome!
>
>
> Thanks.
> Andy.
>
>
>
>
>
>
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, 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 r.engehausen at gmail.com  Wed Jul  8 18:34:16 2009
From: r.engehausen at gmail.com (Roy)
Date: Wed, 08 Jul 2009 15:34:16 -0700
Subject: [c-nsp] Extended demarc
In-Reply-To: <b7f636a60907081449y5fe35060k49aafaa7957b65fd@mail.gmail.com>
References: <b7f636a60907081440n2433cc7fqa0071d364a696ef9@mail.gmail.com>	<4A551405.3060300@rainierconnect.net>
	<b7f636a60907081449y5fe35060k49aafaa7957b65fd@mail.gmail.com>
Message-ID: <4A551EE8.1040402@gmail.com>

james edwards wrote:
> On Wed, Jul 8, 2009 at 3:47 PM, Walter Keen
> <walter.keen at rainierconnect.net>wrote:
>
>   
>> You're supposed to be able to go 100meters(roughly 330ft) with ethernet
>> over Cat5e, but the longest run we've had to date is approximately 260ft
>> with no issues going through a shared vault space very close to power lines
>> and have not yet seen any poor performance due to the length or interference
>> from power cabling.
>> j
>>
>>     
>
>
> Thanks. I failed to mention this is a T-1.
>
> james
> _______________________________________________
>
>   

You can go several thousand feet from the smart jack to the CSU.  If you 
are moving the smart jack then you are limited by the distance between 
the smart jack and the CO (or repeater).  In this case you have to know 
the underlying carrier (HDSL, HDSL2, or "real" T1).


From jlewis at lewis.org  Wed Jul  8 20:15:22 2009
From: jlewis at lewis.org (Jon Lewis)
Date: Wed, 8 Jul 2009 20:15:22 -0400 (EDT)
Subject: [c-nsp] Extended demarc
In-Reply-To: <B98837F93D40A74D8656EAE7C1F57C5659DB21@EXCHANGE1.corp.clearrate.net>
References: <b7f636a60907081440n2433cc7fqa0071d364a696ef9@mail.gmail.com>
	<B98837F93D40A74D8656EAE7C1F57C5659DB21@EXCHANGE1.corp.clearrate.net>
Message-ID: <Pine.LNX.4.61.0907082010120.6312@soloth.lewis.org>

On Wed, 8 Jul 2009, Paul G. Timmins wrote:

> Ethernet IIRC can only go 300 meters or something like that, regardless
> of how fancy your cable is due to timing issues and the speed of light.
> But I don't extend Ethernet very often so I'm not an expert in that
> part.

AFAIK, the length limit for ethernet is more a function of the CSMA/CD 
timing.  On a full duplex ethernet (no collisions, so no need for 
collision detection), with high quality cabling, you can go beyond 100M (I 
think you were thinking 300ft), as you're only really having to worry 
about signal loss.

----------------------------------------------------------------------
  Jon Lewis                   |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

From clayton at mnsi.net  Wed Jul  8 20:14:06 2009
From: clayton at mnsi.net (Clayton Zekelman)
Date: Wed, 8 Jul 2009 20:14:06 -0400
Subject: [c-nsp] Extended demarc
In-Reply-To: <4A551EE8.1040402@gmail.com>
Message-ID: <PC1870200907082014060079d1f74355@DF9B1081>


Typically DSX-1 signal outputs from the SIJ are limited to 655 feet.



----- Original Message ---------------

Subject: Re: [c-nsp] Extended demarc
   From: Roy <r.engehausen at gmail.com>
   Date: Wed, 08 Jul 2009 15:34:16 -0700
     To: 
     Cc: cisco-nsp at puck.nether.net

>
>You can go several thousand feet from the smart jack to the CSU.  If you 
>are moving the smart jack then you are limited by the distance between 
>the smart jack and the CO (or repeater).  In this case you have to know 
>the underlying carrier (HDSL, HDSL2, or "real" T1).
>
>_______________________________________________
>cisco-nsp mailing list  cisco-nsp at puck.nether.net
>https://puck.nether.net/mailman/listinfo/cisco-nsp
>archive at http://puck.nether.net/pipermail/cisco-nsp/

From daniel.dib at reaper.nu  Thu Jul  9 00:30:43 2009
From: daniel.dib at reaper.nu (Daniel Dib)
Date: Thu, 9 Jul 2009 06:30:43 +0200
Subject: [c-nsp] Baseline CoPP policies?
In-Reply-To: <4A551C09.1070507@justinshore.com>
References: <F3318834F1F89D46857972DD4B411D7011C3D55F@EXCHANGE.thenap.com>	<000001c9ff42$b95d1760$2101a8c0@reap>
	<Pine.GSO.4.64.0907071410460.8751@sj-cse-717.cisco.com>
	<4A551C09.1070507@justinshore.com>
Message-ID: <000301ca004e$06449f10$2101a8c0@reap>

Sorry for toppost. It would be nice to be able to match IS-IS directly but
there are workarounds. Either have a class that matches all IP that is left
after all your other classes, not class-default. The only thing that will be
left after that is IS-IS. Or use mls qos protocol passthrough if you want to
police IS-IS, if there is a meaning policing it.

/Daniel

Justin Shore wrote:

One thing that the documentation always lacks is sufficient info on 
handling IS-IS with CoPP.  The inability of IOS to match IS-IS traffic 
without using class-default is a major problem.  Of all the people that 
would need CoPP (people with publicly exposed routers like SPs) one 
would think that IS-IS support for CoPP would be a big deal.

Is there a specific dev group within Cisco that I can point my account 
team to that would be the one to consider my feature request.

Justin


Siva Valliappan wrote:
> Hi Drew,
> 
>    have you looked at the following docs:
> 
> http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html
> 
> and
> 
>
http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6642/pro
d_white_paper0900aecd804fa16a.html 
 

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 4225 (20090708) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
 


From ip at ioshints.info  Thu Jul  9 01:00:47 2009
From: ip at ioshints.info (Ivan Pepelnjak)
Date: Thu, 9 Jul 2009 07:00:47 +0200
Subject: [c-nsp] Multi-site single AS architecture
In-Reply-To: <4A54C4B0.70608@nexus6.co.za>
References: <4A54C4B0.70608@nexus6.co.za>
Message-ID: <002901ca0052$39fb28c0$0a00000a@nil.si>

Almost identical setup has been discussed on Nanog mailing list in the
beginning of June. Search the archives.

XCONNECT probably won't work over the Internet without MPLS/GRE/IP setup and
then you'll hit the MTU issues.

Ivan
 
http://www.ioshints.info/about
http://blog.ioshints.info/

> -----Original Message-----
> From: Andy Ashley [mailto:lists at nexus6.co.za] 
> Sent: Wednesday, July 08, 2009 6:09 PM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] Multi-site single AS architecture
> 
> Hi,
> 
> Apologies for this long post, I am hoping to explain in full:
> (there was a similar thread recently but Im looking for 
> slighly different info)
> 
> Background:
> We currently have a primary site which has two 7206 border 
> routers, each has an uplink and ebgp session over that into 
> our primary transit provider.
> These border routers are also plugged into our two 6500 core 
> switches (3BXL holding the full table).
> 
> There is also a metro ethernet circuit which is plugged into 
> one of the core switches. This circuit goes to another site 
> (plugged into another
> 7206 there) on the other side of the city where we pick up 
> some backup transit and peers at an exchange. All routers 
> peer with one another in the ibgp mesh, the two seperate 
> sites are in a confederation with different private AS 
> numbers and externally are announced as the same AS. 
> Presently all prefixes are announced via the primary site 
> (tagged statics).
> 
> We need to make sure that this secondary site is visible 
> should the metro ethernet break or the primary site is unavailable.
> What we proposed to do was firstly re-address the second site 
> to use seperate prefixes (few smaller /22 and /23 out of a 
> larger aggregate announced from the primary site) Then to put 
> a route in at the secondary site to ensure that the prefix in 
> use there would would still be announced via the backup 
> transit provider and peers should the primary site or metro 
> link have a problem.
> 
> We also need to be able to reach services at the secondary 
> site from the primary should the metro link go down. This 
> raises the problem of our routers not accepting thier own AS 
> in the AS path.
> I would prefer not to use the method of telling the routers 
> to accept thier own AS in the path if possible. To get around 
> this, we were thinking of using an xconnect tunnel to create 
> a virtual backnet between border routers at each site. This 
> should hopefully allow the ibgp sessions to stay up over this 
> tunnel via the Internet instread of over the usually 
> preferred direct connection.
> 
> We are using xconnect statements at the moment to extend some 
> VLAN's across the metro link between sites (router loopbacks 
> are the end points).
> The MTU is set high at 9216 on the metro link and this works fine.
> 
> My questions:
> 1. Will the xconnect (encapsulation mpls) come up if 
> connecting via the Internet instead of over a VLAN on the metro link?
> 2. What interface would be best to configure the xconnect 
> from and to on each end?
> 3. Should we tell ibgp to peer with this interface instead of 
> the loopbacks on each border router?
> 4. How reliable/recommended is this method? Im wary of 
> imlementing something flaky..
> 
> Any comments or hints you may have to offer would be most welcome!
> 
> 
> Thanks.
> Andy.
> 
> 
> 
> 
> 
> 
> --
> This message has been scanned for viruses and dangerous 
> content by MailScanner, and is believed to be clean.
> 
> 
> 


From 13918252531 at 139.com  Thu Jul  9 04:04:31 2009
From: 13918252531 at 139.com (Vincent Dong)
Date: Thu, 9 Jul 2009 16:04:31 +0800
Subject: [c-nsp] How to get the SN of ESR-HH-1GE&ESR-4OC3ATM-SM card in ESR
	10008 by CLI?
Message-ID: <4A55AC40.012ED2.28096@cmsmtp07.n20svrg.139.com>

How to get the SN of ESR-HH-1GE&ESR-4OC3ATM-SM card in ESR 10008 by CLI?

 

 

 


From achatz at forthnet.gr  Thu Jul  9 04:41:16 2009
From: achatz at forthnet.gr (Tassos Chatzithomaoglou)
Date: Thu, 09 Jul 2009 11:41:16 +0300
Subject: [c-nsp] Cisco's New Software Download Experience
Message-ID: <4A55AD2C.6080806@forthnet.gr>

Has anyone seen the new download "experience"?

http://www.cisco.com/web/tsweb/flash/swc/cisco_support_swc.html

Multiple downloads
Download cart added
Cisco's downloader is (must be?) used


-- 
Tassos

From achatz at forthnet.gr  Thu Jul  9 05:14:38 2009
From: achatz at forthnet.gr (Tassos Chatzithomaoglou)
Date: Thu, 09 Jul 2009 12:14:38 +0300
Subject: [c-nsp] How to get the SN of ESR-HH-1GE&ESR-4OC3ATM-SM card in
 ESR	10008 by CLI?
In-Reply-To: <4A55AC40.012ED2.28096@cmsmtp07.n20svrg.139.com>
References: <4A55AC40.012ED2.28096@cmsmtp07.n20svrg.139.com>
Message-ID: <4A55B4FE.5020504@forthnet.gr>

sh inv raw
sh diag


-- 
Tassos


Vincent Dong wrote on 09/07/2009 11:04:
> How to get the SN of ESR-HH-1GE&ESR-4OC3ATM-SM card in ESR 10008 by CLI?
> 
>  
> 
>  
> 
>  
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 

From jared at puck.nether.net  Thu Jul  9 08:41:11 2009
From: jared at puck.nether.net (Jared Mauch)
Date: Thu, 9 Jul 2009 08:41:11 -0400
Subject: [c-nsp] Cisco's New Software Download Experience
In-Reply-To: <4A55AD2C.6080806@forthnet.gr>
References: <4A55AD2C.6080806@forthnet.gr>
Message-ID: <3E355414-B46A-4172-B680-5C1CBEA06136@puck.nether.net>

If their downloader must be used, I will be unable to download their  
software for our network anymore.

There's no way I'm downloading 250MB+ images just to re-upload them  
over whatever slow internet access I happen to have at my desktop/ 
laptop to our staging system.  The cookie system has worked "OK" for  
me, aside from having to navigate the hellacious website trees to find  
the images desired, or to get a good guess of when they finally  
shipped the image.

If there's a bunch of enterprise folks that can't figure out how to  
download images, they should hire some contractor to stage images for  
them instead of impairing the rest of the networking world.

	- Jared

On Jul 9, 2009, at 4:41 AM, Tassos Chatzithomaoglou wrote:

> Has anyone seen the new download "experience"?
>
> http://www.cisco.com/web/tsweb/flash/swc/cisco_support_swc.html
>
> Multiple downloads
> Download cart added
> Cisco's downloader is (must be?) used
>
>
> -- 
> Tassos
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


From simon at slimey.org  Thu Jul  9 08:48:40 2009
From: simon at slimey.org (Simon Lockhart)
Date: Thu, 9 Jul 2009 13:48:40 +0100
Subject: [c-nsp] Cisco's New Software Download Experience
In-Reply-To: <4A55AD2C.6080806@forthnet.gr>
References: <4A55AD2C.6080806@forthnet.gr>
Message-ID: <20090709124840.GV2898@virtual.bogons.net>

On Thu Jul 09, 2009 at 11:41:16AM +0300, Tassos Chatzithomaoglou wrote:
> Has anyone seen the new download "experience"?
> 
> http://www.cisco.com/web/tsweb/flash/swc/cisco_support_swc.html
> 
> Multiple downloads
> Download cart added
> Cisco's downloader is (must be?) used

I had it foisted on me a week or so back when trying to download an image.
Shortly before CCO just broke, totally.

The "download manager" is a java applet. No java, no downloads (I tried this
when I was getting frustrated with it). After waiting a couple of hours for
an image to download over a slow connection (as I now couldn't download it
straight to the datacentre), their applet said the download was complete.
Except... I couldn't find it. Tried downloading again. Still no sign of it.

I eventually found it... On my linux box, it was a hidden file, called:
".\filename.foo" - yup, it had assumed that I was running windows and had used
\ as a directory seperator.

Next time I tried downloading an image, I wasn't presented with the download
manager, and everything worked smoothly.

Simon
-- 
Simon Lockhart | * Sun Server Colocation * ADSL * Domain Registration *
   Director    |    * Domain & Web Hosting * Internet Consultancy * 
  Bogons Ltd   | * http://www.bogons.net/  *  Email: info at bogons.net  * 

From kgraham at industrial-marshmallow.com  Thu Jul  9 09:46:54 2009
From: kgraham at industrial-marshmallow.com (Kevin Graham)
Date: Thu, 9 Jul 2009 06:46:54 -0700 (PDT)
Subject: [c-nsp] Cisco's New Software Download Experience
In-Reply-To: <3E355414-B46A-4172-B680-5C1CBEA06136@puck.nether.net>
References: <4A55AD2C.6080806@forthnet.gr>
	<3E355414-B46A-4172-B680-5C1CBEA06136@puck.nether.net>
Message-ID: <587067.64570.qm@web1212.biz.mail.gq1.yahoo.com>




> There's no way I'm downloading 250MB+ images just to re-upload them over 
> whatever slow internet access I happen to have at my desktop/laptop to our 
> staging system.  

Also a critical habit for archiving. Finding an interim build that you got 6
months ago and now have to re-use is only successful w/ a designated staging
hosts. (Would love to see how anyone builds meaningful rACL/CoPP w/o this...)

> The cookie system has worked "OK" for me, aside from having to navigate the
> hellacious website trees to find the images desired, or to get a good guess
> of when they finally shipped the image.

s/navigate/poke randomly/ (see my message a few weeks ago looking for c2lc
rommon.

It's incredibly disappointing at this point that a "new feature" on CCO is
pretty much guaranteed to be a poorly executed, sloppy attempt to address
problems that don't exist. If it was done well and clearly targeted to an
audience of network administrators, it /might/ be different but as-is it
honestly makes me angry every time I have to deal w/ most of the crap they've
added in the past ~2 years.

(i.e. post-univercd, it seems searching is the best way to find release notes
and I've yet to discover a predictably located page that rolls up release
notes, config guides, and new feature notes.)

From kron at linkey.ru  Thu Jul  9 09:19:54 2009
From: kron at linkey.ru (Aleksandr Gurbo)
Date: Thu, 9 Jul 2009 17:19:54 +0400
Subject: [c-nsp] IPv6 iBGP Route Reflector
Message-ID: <20090709171954.287883f9.kron@linkey.ru>


How to setup reflected route in route table with correct next-hop?

I have iBGP RR on IPv6 addresses with two rr-clients. All ibgp peers between routers from Loopbacks. For announce ipv6 Loopback addresses used OSPFv3.

My test scheme:
IPv6net1--rtr3---rtr2_RR---rtr4--IPv6net2

rtr2_RR reflect IPv6net1 on rtr4, but the reflected route doesn't install in the route table.

rtr4#show ip bgp ipv6 unicast
BGP table version is 17, local router ID is 192.168.153.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
* i2001:1020:100::2/128
                    2001:1020:100::2
                                             0    100      0 ?
* i2001:1020:100::3/128
                    2001:1020:100::3
                                             0    100      0 ?
*> 2001:1020:100::4/128
                    ::                       0         32768 ?
* i2001:1020:700::/64  <-------------------------------------------my reflected route IPv6net1
                    2001:1020:100::3
                                             0    100      0 ?
*> 2001:1020:800::/64
                    ::                       0         32768 ?
* i2001:1020:7000::/64
                    2001:1020:100::2
                                             0    100      0 ?
* i2001:1020:8000::/64
                    2001:1020:100::2


rtr4#show ip bgp ipv6 unicast 2001:1020:100::3/128
BGP routing table entry for 2001:1020:100::3/128, version 0
Paths: (1 available, no best path)
  Not advertised to any peer
  Local, (received & used)
    2001:1020:100::3 (inaccessible) from 2001:1020:100::2 (10.10.1.14)
      Origin incomplete, metric 0, localpref 100, valid, internal
      Originator: 192.168.150.2, Cluster list: 10.10.1.14
      mpls labels in/out nolabel/19

rtr4#show ipv6 ro 2001:1020:100::3
IPv6 Routing Table - 10 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
       U - Per-user Static route
       I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
       O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
       ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
O   2001:1020:100::3/128 [110/2]
     via FE80::23F:CAFF:FEB1:640, FastEthernet4/0/0 <----- link-local.

-- 
Alexandr Gurbo


From gert at greenie.muc.de  Thu Jul  9 10:10:43 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Thu, 9 Jul 2009 16:10:43 +0200
Subject: [c-nsp] Same-Router VRRP / HSRP
In-Reply-To: <C97F73E15F1F0D48A3AC0C423F8C221A018FD02D@rancor.ad.newedgenetworks.com>
References: <C97F73E15F1F0D48A3AC0C423F8C221A018FD02D@rancor.ad.newedgenetworks.com>
Message-ID: <20090709141043.GS290@greenie.muc.de>

Hi,

On Mon, Jul 06, 2009 at 04:40:39PM -0700, Lasher, Donn wrote:
> LAN on a switch, multiple PC's. .Single router with 1+ Ethernet ports.
> What's the currently recommended method of handing off redundant LAN
> connections on the same physical router? (I looked at but not into GLBP,
> maybe that?) HSRP and VRRP complain about IP overlap when done on the
> same router..

Etherchannel (if the switch infrastructure permits), or "backup interface".

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/20090709/6aac71db/attachment.bin>

From Ian.Mackinnon at lumison.net  Thu Jul  9 10:09:16 2009
From: Ian.Mackinnon at lumison.net (Ian MacKinnon)
Date: Thu, 9 Jul 2009 15:09:16 +0100
Subject: [c-nsp] Cisco's New Software Download Experience
In-Reply-To: <587067.64570.qm@web1212.biz.mail.gq1.yahoo.com>
References: <4A55AD2C.6080806@forthnet.gr>
	<3E355414-B46A-4172-B680-5C1CBEA06136@puck.nether.net>
	<587067.64570.qm@web1212.biz.mail.gq1.yahoo.com>
Message-ID: <B5F945E48C137C49A98BC86DD35939C012DAC82C62@nbg01-exch-01.entlstaff.domain.lumison.net>

I normally manage to find the release notes fairly simply, Support->IOS-> Pick a version -> Release notes are then under General Information.

That's not to say I don't agree with the rest of your comments though :-)


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Kevin Graham
Sent: 09 July 2009 14:47
To: Jared Mauch; Tassos Chatzithomaoglou
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Cisco's New Software Download Experience




> There's no way I'm downloading 250MB+ images just to re-upload them over
> whatever slow internet access I happen to have at my desktop/laptop to our
> staging system.

Also a critical habit for archiving. Finding an interim build that you got 6
months ago and now have to re-use is only successful w/ a designated staging
hosts. (Would love to see how anyone builds meaningful rACL/CoPP w/o this...)

> The cookie system has worked "OK" for me, aside from having to navigate the
> hellacious website trees to find the images desired, or to get a good guess
> of when they finally shipped the image.

s/navigate/poke randomly/ (see my message a few weeks ago looking for c2lc
rommon.

It's incredibly disappointing at this point that a "new feature" on CCO is
pretty much guaranteed to be a poorly executed, sloppy attempt to address
problems that don't exist. If it was done well and clearly targeted to an
audience of network administrators, it /might/ be different but as-is it
honestly makes me angry every time I have to deal w/ most of the crap they've
added in the past ~2 years.

(i.e. post-univercd, it seems searching is the best way to find release notes
and I've yet to discover a predictably located page that rolls up release
notes, config guides, and new feature notes.)
_______________________________________________
cisco-nsp mailing 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.
Finally, the recipient should check this email and any attachments for the
presence of viruses.  Lumison accept no liability for any
damage caused by any virus transmitted by this email.

From Michael.Balasko at cityofhenderson.com  Thu Jul  9 10:46:16 2009
From: Michael.Balasko at cityofhenderson.com (Michael Balasko)
Date: Thu, 9 Jul 2009 07:46:16 -0700
Subject: [c-nsp] DHCP behavior on a link up
In-Reply-To: <20090709171954.287883f9.kron@linkey.ru>
References: <20090709171954.287883f9.kron@linkey.ru>
Message-ID: <9AF22D15085E7D409ED5710CBC779E930AFC817C@COHNTCS09.ci.henderson.nv.us>


Does anyone know of any RFC's that pertain to how a host device should
behave regarding DHCP when the link come up? Newer windows machines and
some flavors of *nix behave like I think they should and that is they
will attempt to renew a DHCP lease on a link up. What we are finding is
that all our Xerox devices and some specialized/ruggedized gizmos do NOT
do this and it wrecks havoc with DHCP Snooping as you can imagine. I was
hoping to beat Xerox with an RFC stick. 

Thanks for any help on this, 


Mike 

From blahu77 at gmail.com  Thu Jul  9 11:13:49 2009
From: blahu77 at gmail.com (Mateusz Blaszczyk)
Date: Thu, 9 Jul 2009 16:13:49 +0100
Subject: [c-nsp] DHCP behavior on a link up
In-Reply-To: <9AF22D15085E7D409ED5710CBC779E930AFC817C@COHNTCS09.ci.henderson.nv.us>
References: <20090709171954.287883f9.kron@linkey.ru>
	<9AF22D15085E7D409ED5710CBC779E930AFC817C@COHNTCS09.ci.henderson.nv.us>
Message-ID: <383357750907090813x5812ea58j3ea4ca3dfb7c0491@mail.gmail.com>

One clue is in RFC2131 [1]

[...]
A client SHOULD use DHCP to reacquire or verify its IP address and
   network parameters whenever the local network parameters may have
   changed; e.g., at system boot time or after a disconnection from the
   local network....
[...]

Still it says SHOULD, not MUST so it is really not so definite.

Best Regards,

-mat


[1] http://tools.ietf.org/html/rfc2131#section-3.7

2009/7/9 Michael Balasko <Michael.Balasko at cityofhenderson.com>:
>
> Does anyone know of any RFC's that pertain to how a host device should
> behave regarding DHCP when the link come up? Newer windows machines and
> some flavors of *nix behave like I think they should and that is they
> will attempt to renew a DHCP lease on a link up. What we are finding is
> that all our Xerox devices and some specialized/ruggedized gizmos do NOT
> do this and it wrecks havoc with DHCP Snooping as you can imagine. I was
> hoping to beat Xerox with an RFC stick.
>
> Thanks for any help on this,
>
>
> 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 sethm at rollernet.us  Thu Jul  9 11:49:23 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Thu, 09 Jul 2009 08:49:23 -0700
Subject: [c-nsp] Cisco's New Software Download Experience
In-Reply-To: <3E355414-B46A-4172-B680-5C1CBEA06136@puck.nether.net>
References: <4A55AD2C.6080806@forthnet.gr>
	<3E355414-B46A-4172-B680-5C1CBEA06136@puck.nether.net>
Message-ID: <4A561183.8010506@rollernet.us>

Jared Mauch wrote:
>
> If there's a bunch of enterprise folks that can't figure out how to
> download images, they should hire some contractor to stage images for
> them instead of impairing the rest of the networking world.
> 

Remember some of the absolutely brain dead questions that used to come
across the list months back? It doesn't surprise me, and I suspect it
will get worse.

~Seth

From steve at ibctech.ca  Thu Jul  9 11:07:23 2009
From: steve at ibctech.ca (Steve Bertrand)
Date: Thu, 09 Jul 2009 11:07:23 -0400
Subject: [c-nsp] IPv6 iBGP Route Reflector
In-Reply-To: <20090709171954.287883f9.kron@linkey.ru>
References: <20090709171954.287883f9.kron@linkey.ru>
Message-ID: <4A5607AB.2060009@ibctech.ca>

Aleksandr Gurbo wrote:
> How to setup reflected route in route table with correct next-hop?
> 
> I have iBGP RR on IPv6 addresses with two rr-clients. All ibgp peers between routers from Loopbacks. For announce ipv6 Loopback addresses used OSPFv3.

> rtr4#show ip bgp ipv6 unicast 2001:1020:100::3/128
> BGP routing table entry for 2001:1020:100::3/128, version 0
> Paths: (1 available, no best path)
>   Not advertised to any peer
>   Local, (received & used)
>     2001:1020:100::3 (inaccessible) from 2001:1020:100::2 (10.10.1.14)
                       ^^^^^^^^^^^^^^

I don't know for sure, but this seems like a reachability problem, not
necessarily a BGP problem.

The next-hop should appear valid and usable, and link-local is a valid
next-hop in your case. eg:

O>* 2607:f118:1::e3/128 [110/2] via fe80::21a:70ff:fe14:568a, em5, 05w2d23h

Can r2 reach r3? Can you provide some relevant BGP and OSPF config snips
from r2 and r4?

I have a network segment that is configured nearly identical to yours,
so I can compare config pieces with you if you'd like.

Steve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3233 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090709/91ebef9e/attachment.bin>

From nicholas.hatch at gmail.com  Thu Jul  9 13:05:09 2009
From: nicholas.hatch at gmail.com (nick hatch)
Date: Thu, 9 Jul 2009 10:05:09 -0700
Subject: [c-nsp] DHCP behavior on a link up
In-Reply-To: <9AF22D15085E7D409ED5710CBC779E930AFC817C@COHNTCS09.ci.henderson.nv.us>
References: <20090709171954.287883f9.kron@linkey.ru>
	<9AF22D15085E7D409ED5710CBC779E930AFC817C@COHNTCS09.ci.henderson.nv.us>
Message-ID: <a71460720907091005k736d6317va2d857162ae597e4@mail.gmail.com>

On Thu, Jul 9, 2009 at 7:46 AM, Michael Balasko <
Michael.Balasko at cityofhenderson.com> wrote:

>
> Does anyone know of any RFC's that pertain to how a host device should
> behave regarding DHCP when the link come up? Newer windows machines and
> some flavors of *nix behave like I think they should and that is they
> will attempt to renew a DHCP lease on a link up.


One thing worth noting for Windows clients (at least for Windows XP), is
that the DHCP client will attempt a renew first; however, the old lease is
not destroyed upon link change. This shouldn't be a problem, but if the
response received is a NAK, the client won't always gracefully fall back and
attempt a new discovery attempt. I've seen WinXP clients bang on the DHCP
server (ISC) for hours: NAK, REQUEST, NAK REQUEST, NAK, REQUEST ...  I saw
this problem on a campus network when laptops would connect to us with a
stale lease for a home RFC1918 network, possibly with an indefinite time
period. Windows isn't always well behaved.

Does it seem like the devices are at least honoring their assigned lease
times? Perhaps these errant devices could be assigned to a DHCP pool with a
very short renewal period. Per the RFC, clients MUST stop using the lease
when it expires.

I've got a similar problem -- thermal printers in public areas where I'd
love to use DHCP snooping/DAI. When purchased, they arrived with
nonfunctional DHCP (NOT as advertised), are the only printers that are
compatible with this system, and were not cheap. When we complained to the
vendor, they told us it was a known problem, to quit whining and static
assign, and that if we tried to RMA them, they would be refused.

If you're looking to beat Xerox with a clue-bat wrapped in an RFC, perhaps a
reminder of what SHOULD means could help:

       This word or the adjective "RECOMMENDED" means that there
        may exist valid reasons in particular circumstances to ignore
        this item, but the full implications should be understood and
        the case carefully weighed before choosing a different course.


Perhaps Xerox support could help you understand the reasoning they went
through when the full implications of deviating from the RFC were carefully
weighed... (Ha!)  You've obviously got a problem which falls under the "full
implications" umbrella.

-Nick

From Michael.Balasko at cityofhenderson.com  Thu Jul  9 13:21:14 2009
From: Michael.Balasko at cityofhenderson.com (Michael Balasko)
Date: Thu, 9 Jul 2009 10:21:14 -0700
Subject: [c-nsp] DHCP behavior on a link up
In-Reply-To: <a71460720907091005k736d6317va2d857162ae597e4@mail.gmail.com>
References: <20090709171954.287883f9.kron@linkey.ru>
	<9AF22D15085E7D409ED5710CBC779E930AFC817C@COHNTCS09.ci.henderson.nv.us>
	<a71460720907091005k736d6317va2d857162ae597e4@mail.gmail.com>
Message-ID: <9AF22D15085E7D409ED5710CBC779E930AFC8579@COHNTCS09.ci.henderson.nv.us>

Here is what I am getting and I have a fix after piles of digging, but
that doesn't excuse the behavior from Xerox. 

 

We use Cisco Network Registrar for DHCP and after chasing this issue we
have decided to turn off "allow-lease-time-override", which If
allow-lease-time-override is enabled for a policy applicable to the
request, the server accepts a shorter lease time from the client,  which
is where the grief is affecting us. 

 

But the lame part is Xerox wants a pretty long lease- 136years and
change which is awfully close to 2^32 J 

 

 

R1017230: ----- RECEIVED -- R1017230 -----                              

R1017227:   ->    packet length = 314                                   

R1017227:   ->      dhcp-message-type = DHCPDISCOVER                    

R1017227:   ->      dhcp-lease-time = 136y10w6h28m15s                   

R1017227:   ->      dhcp-requested-address = 172.21.154.118             

R1017227:   ->      host-name = XRX6C9AB7                               

 

My DHCP server then hands back a 60 minute lease which its configured
to hand back if a client requests a lease time as opposed to the
"standard lease time" we have defined. I've fixed that tooJ

 

Thanks for the help guys!!!

 

Mike  

 

From: nick hatch [mailto:nicholas.hatch at gmail.com] 
Sent: Thursday, July 09, 2009 10:05 AM
To: cisco-nsp at puck.nether.net
Cc: Michael Balasko
Subject: Re: [c-nsp] DHCP behavior on a link up

 

On Thu, Jul 9, 2009 at 7:46 AM, Michael Balasko
<Michael.Balasko at cityofhenderson.com> wrote:


Perhaps Xerox support could help you understand the reasoning they went
through when the full implications of deviating from the RFC were
carefully weighed... (Ha!)  You've obviously got a problem which falls
under the "full implications" umbrella.

-Nick


From kron at linkey.ru  Thu Jul  9 14:17:39 2009
From: kron at linkey.ru (Aleksandr Gurbo)
Date: Thu, 9 Jul 2009 22:17:39 +0400
Subject: [c-nsp] IPv6 iBGP Route Reflector
Message-ID: <20090709221739.60f8e34e.kron@linkey.ru>

> > rtr4#show ip bgp ipv6 unicast 2001:1020:100::3/128
> > BGP routing table entry for 2001:1020:100::3/128, version 0
> > Paths: (1 available, no best path)
> >   Not advertised to any peer
> >   Local, (received & used)
> >     2001:1020:100::3 (inaccessible) from 2001:1020:100::2 (10.10.1.14)
>                        ^^^^^^^^^^^^^^
> 
> I don't know for sure, but this seems like a reachability problem, not
> necessarily a BGP problem.

Yes, you are partially right, but rtr3 can reach rtr4.

rtr3#sh ipv6 route
IPv6 Routing Table - 10 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
       U - Per-user Static route
       I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
       O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
       ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
O   2001:1020:100::2/128 [110/1]
     via FE80::21F:CAFF:FEB3:640, FastEthernet6/1/0
LC  2001:1020:100::3/128 [0/0]
     via ::, Loopback0
O   2001:1020:100::4/128 [110/2]
     via FE80::21F:CAFF:FEB3:640, FastEthernet6/1/0
C   2001:1020:700::/64 [0/0]
     via ::, FastEthernet6/0/0
L   2001:1020:700::1/128 [0/0]
     via ::, FastEthernet6/0/0
C   2001:1020:7000::/64 [0/0]
     via ::, FastEthernet6/1/0
L   2001:1020:7000::1/128 [0/0]
     via ::, FastEthernet6/1/0
O   2001:1020:8000::/64 [110/2]
     via FE80::21F:CAFF:FEB3:640, FastEthernet6/1/0
L   FE80::/10 [0/0]
     via ::, Null0
L   FF00::/8 [0/0]
     via ::, Null0

rtr3#ping 2001:1020:100::4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:1020:100::4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/1/4 ms


> The next-hop should appear valid and usable, and link-local is a valid
> next-hop in your case. eg:
> 
> O>* 2607:f118:1::e3/128 [110/2] via fe80::21a:70ff:fe14:568a, em5, 05w2d23h
> 
> Can r2 reach r3? Can you provide some relevant BGP and OSPF config snips
> from r2 and r4?
> I have a network segment that is configured nearly identical to yours,
> so I can compare config pieces with you if you'd like.


Yes, rtr2_RR can reach rtr3 and rtr4.
rtr2_RR#ping 2001:1020:100::3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:1020:100::3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/0/0 ms

rtr2_RR#sh ipv6 route
IPv6 Routing Table - default - 10 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
LC  2001:1020:100::2/128 [0/0]
     via Loopback12, receive
O   2001:1020:100::3/128 [110/1]
     via FE80::260:2FFF:FE4E:41C8, GigabitEthernet3/24
O   2001:1020:100::4/128 [110/1]
     via FE80::230:96FF:FEC0:A880, GigabitEthernet3/23
B   2001:1020:700::/64 [200/0]
     via 2A00:1020:100::3, indirectly connected
B   2001:1020:800::/64 [200/0]
     via 2A00:1020:100::4, indirectly connected
C   2001:1020:7000::/64 [0/0]
     via GigabitEthernet3/24, directly connected
L   2001:1020:7000::2/128 [0/0]
     via GigabitEthernet3/24, receive
C   2001:1020:8000::/64 [0/0]
     via GigabitEthernet3/23, directly connected
L   2001:1020:8000::2/128 [0/0]
     via GigabitEthernet3/23, receive
L   FF00::/8 [0/0]
     via Null0, receive



configuration rtr2_RR:

interface Loopback12
 no ip address
 ipv6 address 2001:1020:100::2/128
 ipv6 ospf 333 area 0
end

interface GigabitEthernet3/23
 description rtr4
 no ip address
 ipv6 address 2001:1020:8000::2/64
 ipv6 enable
 ipv6 ospf 333 area 0
 mpls ip
end

interface GigabitEthernet3/24
 description rtr3
 no ip address
 ipv6 address 2001:1020:7000::2/64
 ipv6 enable
 ipv6 ospf 333 area 0
 mpls ip
end

router bgp 65000
 template peer-policy rr-clients-v6
  route-reflector-client
  soft-reconfiguration inbound
  send-community both
  send-label
 exit-peer-policy
 !
 bgp router-id 10.10.1.14
 bgp log-neighbor-changes
 neighbor 2001:1020:100::3 remote-as 65000
 neighbor 2001:1020:100::3 ebgp-multihop 10
 neighbor 2001:1020:100::3 update-source Loopback12
 neighbor 2001:1020:100::4 remote-as 65000
 neighbor 2001:1020:100::4 ebgp-multihop 10
 neighbor 2001:1020:100::4 update-source Loopback12
 !
 address-family ipv4
  no synchronization
  neighbor 2001:1020:100::3 activate
  neighbor 2001:1020:100::4 activate
  no auto-summary
 exit-address-family
 !
 address-family ipv6
  redistribute connected
  no synchronization
  neighbor 2001:1020:100::3 activate
  neighbor 2001:1020:100::3 inherit peer-policy rr-clients-v6
  neighbor 2001:1020:100::4 activate
  neighbor 2001:1020:100::4 inherit peer-policy rr-clients-v6
 exit-address-family

ipv6 router ospf 333
 router-id 192.168.201.14
 log-adjacency-changes
 passive-interface default
 no passive-interface GigabitEthernet3/23
 no passive-interface GigabitEthernet3/24
!


configuration rtr4:

interface Loopback0
 no ip address
 ipv6 address 2001:1020:100::4/128
 ipv6 enable
 ipv6 ospf 333 area 0

interface FastEthernet4/0/0
 description rtr2_RR
 no ip address
 full-duplex
 ipv6 address 2001:1020:8000::1/64
 ipv6 enable
 no ipv6 redirects
 ipv6 ospf 333 area 0
 mpls ip

interface FastEthernet5/0/0
 description IPv6net2
 no ip address
 full-duplex
 ipv6 address 2001:1020:800::1/64

router bgp 65000
 bgp log-neighbor-changes
 neighbor 2001:1020:100::2 remote-as 65000
 neighbor 2001:1020:100::2 update-source Loopback0
 !
 address-family ipv4
  neighbor 2001:1020:100::2 activate
  no auto-summary
  no synchronization
 exit-address-family
 !
 address-family ipv6
  neighbor 2001:1020:100::2 activate
  neighbor 2001:1020:100::2 send-community both
  neighbor 2001:1020:100::2 soft-reconfiguration inbound
  neighbor 2001:1020:100::2 send-label
  redistribute connected
  no synchronization
 exit-address-family

ipv6 router ospf 333
 router-id 192.168.153.2
 log-adjacency-changes
 passive-interface default
 no passive-interface FastEthernet4/0/0

Configuration on rtr3 like rtr4.

-- 
Alexandr Gurbo

From tim at selfnet.de  Thu Jul  9 14:20:47 2009
From: tim at selfnet.de (Tim)
Date: Thu, 09 Jul 2009 20:20:47 +0200
Subject: [c-nsp] [c3560g] Not in truth table when modyfing ACL
In-Reply-To: <fwsxxhkws8pa6tj07rUYAxe124vaj_firegpg@mail.gmail.com>
References: <fwsxxhkws8pa6tj07rUYAxe124vaj_firegpg@mail.gmail.com>
Message-ID: <4A5634FF.3060406@selfnet.de>

Mateusz Blaszczyk wrote:
> It seems it's a bug that appeared first in 12.2(50)SE and later releases.
> To be fixed in SE3, scheduled for release on 23th July.

Thanks for the info!

-- 
Tim

From steve at ibctech.ca  Thu Jul  9 14:35:59 2009
From: steve at ibctech.ca (Steve Bertrand)
Date: Thu, 09 Jul 2009 14:35:59 -0400
Subject: [c-nsp] IPv6 iBGP Route Reflector
In-Reply-To: <20090709221739.60f8e34e.kron@linkey.ru>
References: <20090709221739.60f8e34e.kron@linkey.ru>
Message-ID: <4A56388F.6060607@ibctech.ca>

Aleksandr Gurbo wrote:
>>> rtr4#show ip bgp ipv6 unicast 2001:1020:100::3/128
>>> BGP routing table entry for 2001:1020:100::3/128, version 0
>>> Paths: (1 available, no best path)
>>>   Not advertised to any peer
>>>   Local, (received & used)
>>>     2001:1020:100::3 (inaccessible) from 2001:1020:100::2 (10.10.1.14)
>>                        ^^^^^^^^^^^^^^
>>
>> I don't know for sure, but this seems like a reachability problem, not
>> necessarily a BGP problem.
> 
> Yes, you are partially right, but rtr3 can reach rtr4.
> 

ok.

>  bgp log-neighbor-changes
>  neighbor 2001:1020:100::3 remote-as 65000
>  neighbor 2001:1020:100::3 ebgp-multihop 10

It doesn't appear as ebgp-multihop should be used in this case, since it
appears to be an iBGP session.

Also, does setting next-hop-self on rtr4's peering with rtr2 fix the
problem?

Steve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3233 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090709/701671b5/attachment-0001.bin>

From kron at linkey.ru  Fri Jul 10 01:25:48 2009
From: kron at linkey.ru (Aleksandr Gurbo)
Date: Fri, 10 Jul 2009 09:25:48 +0400
Subject: [c-nsp] IPv6 iBGP Route Reflector
In-Reply-To: <4A56388F.6060607@ibctech.ca>
References: <20090709221739.60f8e34e.kron@linkey.ru>
	<4A56388F.6060607@ibctech.ca>
Message-ID: <20090710092548.e7bcd297.kron@linkey.ru>

On Thu, 09 Jul 2009 14:35:59 -0400
Steve Bertrand <steve at ibctech.ca> wrote:

> Aleksandr Gurbo wrote:
> >>> rtr4#show ip bgp ipv6 unicast 2001:1020:100::3/128
> >>> BGP routing table entry for 2001:1020:100::3/128, version 0
> >>> Paths: (1 available, no best path)
> >>>   Not advertised to any peer
> >>>   Local, (received & used)
> >>>     2001:1020:100::3 (inaccessible) from 2001:1020:100::2 (10.10.1.14)
> >>                        ^^^^^^^^^^^^^^
> >>
> >> I don't know for sure, but this seems like a reachability problem, not
> >> necessarily a BGP problem.
> > 
> > Yes, you are partially right, but rtr3 can reach rtr4.
> > 
> 
> ok.
> 
> >  bgp log-neighbor-changes
> >  neighbor 2001:1020:100::3 remote-as 65000
> >  neighbor 2001:1020:100::3 ebgp-multihop 10
> 
> It doesn't appear as ebgp-multihop should be used in this case, since it
> appears to be an iBGP session.
> 
> Also, does setting next-hop-self on rtr4's peering with rtr2 fix the
> problem?

This is iBGP session. I removed settings ebgp-multihop on rtr2_RR and added next-hop-self on rtr4 and rtr3, but problem doesn't solved.
Do you have ideas about change next-hop? May be through route-map?


-- 
Alexandr Gurbo

From p.mayers at imperial.ac.uk  Fri Jul 10 04:50:07 2009
From: p.mayers at imperial.ac.uk (Phil Mayers)
Date: Fri, 10 Jul 2009 09:50:07 +0100
Subject: [c-nsp] DHCP behavior on a link up
In-Reply-To: <a71460720907091005k736d6317va2d857162ae597e4@mail.gmail.com>
References: <20090709171954.287883f9.kron@linkey.ru>
	<9AF22D15085E7D409ED5710CBC779E930AFC817C@COHNTCS09.ci.henderson.nv.us>
	<a71460720907091005k736d6317va2d857162ae597e4@mail.gmail.com>
Message-ID: <20090710085007.GB2610@wildfire.net.ic.ac.uk>

On Thu, Jul 09, 2009 at 06:05:09PM +0100, nick hatch wrote:
>On Thu, Jul 9, 2009 at 7:46 AM, Michael Balasko <
>Michael.Balasko at cityofhenderson.com> wrote:
>
>>
>> Does anyone know of any RFC's that pertain to how a host device should
>> behave regarding DHCP when the link come up? Newer windows machines and
>> some flavors of *nix behave like I think they should and that is they
>> will attempt to renew a DHCP lease on a link up.
>
>
>One thing worth noting for Windows clients (at least for Windows XP), is
>that the DHCP client will attempt a renew first; however, the old lease is

It's also worth noting that, driver-dependent, a brief link loss may not 
be "seen" by the IP stack and trigger a renew.

This is of interest if, like us, you trigger a port restart when kicking 
a machine off, to re-assign their VLAN.

>not destroyed upon link change. This shouldn't be a problem, but if the
>response received is a NAK, the client won't always gracefully fall back and
>attempt a new discovery attempt. I've seen WinXP clients bang on the DHCP
>server (ISC) for hours: NAK, REQUEST, NAK REQUEST, NAK, REQUEST ...  I saw
>this problem on a campus network when laptops would connect to us with a
>stale lease for a home RFC1918 network, possibly with an indefinite time
>period. Windows isn't always well behaved.

Hmm. Interesting. I've not seen that, and we've got a lot of XP clients.  
In my experience, XP is possibly the "best" behaved DHCP client of the 
lot.

Don't get me started on the "great leap forward" that is Vista...  
broadcast DHCP? Yuck...

>
>Does it seem like the devices are at least honoring their assigned lease
>times? Perhaps these errant devices could be assigned to a DHCP pool with a
>very short renewal period. Per the RFC, clients MUST stop using the lease
>when it expires.

Note that many embedded devices (in my experience) do a sort of 
DHCP-lite or BOOTP-plus; they emit DHCP DISCO/REQUEST packets and handle 
DHCP options, but don't implement the "renew" bit of the protocol. HP 
3600 and 20xx printers are particular offenders.

>
>I've got a similar problem -- thermal printers in public areas where I'd
>love to use DHCP snooping/DAI. When purchased, they arrived with
>nonfunctional DHCP (NOT as advertised), are the only printers that are
>compatible with this system, and were not cheap. When we complained to the
>vendor, they told us it was a known problem, to quit whining and static
>assign, and that if we tried to RMA them, they would be refused.

That's... lovely. Sounds like a marvellous company!

We have this with some older kit. If and when we go to DHCP snooping, 
I'm going to handle this with a script that checks the MAC on 
snooping-disabled ports. If it's a known-incapable, fine, else re-enable 
snooping, which should hopefully stop people unplugging the 
photocopiers...

On the plus side, at least on Cisco you can upload an ARP ACL to include 
the exceptions. Some other vendors offer no such method, and exceptions 
have to be tied to the port. Sigh...


From Kiran.Oddiraju at cbre.com  Fri Jul 10 07:27:04 2009
From: Kiran.Oddiraju at cbre.com (Oddiraju, Kiran @ London SMC)
Date: Fri, 10 Jul 2009 12:27:04 +0100
Subject: [c-nsp] Netflow Sampling
Message-ID: <B5CFB919B5EEF345969F51FAFE6360D50AD81A@GBLDCXMB10.emea.cbre.net>

Guys,

 

I am trying to configure Netflow sampling interval on a c1801 router
(IOS version "c180x-broadband-mz.124-15.T6.bin"). I was able to enable
Netflow globally and configured it on the interface as well. But I can't
setup sampling, it doesn't like the commands. What am I doing wrong?

 

Config

 

interface FastEthernet0

 ip address 10.15.255.50 255.255.255.252

 ip flow ingress

 ip route-cache flow

 speed 100

 full-duplex

!

 

ip flow-export source FastEthernet0

ip flow-export version 5

ip flow-export destination 10.13.246.50 2055

ip flow-export destination 10.15.246.66 2055

 

 

Netflow-Test(config-if)#ip route-cache flow sampled

                                            ^

% Invalid input detected at '^' marker.

 

Netflow-Test(config)#ip flow-sampling-mode packet-interval ?

% Unrecognized command

 

Many thanks,

Kiran


CB Richard Ellis Limited, Registered Office: St Martin's Court, 
10 Paternoster Row, London, EC4M 7HP, registered in England and Wales No. 3536032. 
Regulated by the RICS and an appointed representative of CB Richard Ellis 
Indirect Investment Services Limited which is authorised and regulated by the Financial Services Authority.

This communication is from CB Richard Ellis Limited or one of its 
associated/subsidiary companies. This communication contains information 
which is confidential and may be privileged. If you are not the intended recipient, 
please contact the sender immediately. Any use of its contents is strictly prohibited 
and you must not copy, send or disclose it, or rely on its contents in any way whatsoever. 
Reasonable care has been taken to ensure that this communication 
(and any attachments or hyperlinks contained within it) is free from computer viruses. 
No responsibility is accepted by CB Richard Ellis Limited or its associated/subsidiary 
companies and the recipient should carry out any appropriate virus checks.


From asturluismi at gmail.com  Fri Jul 10 08:26:31 2009
From: asturluismi at gmail.com (luismi)
Date: Fri, 10 Jul 2009 14:26:31 +0200
Subject: [c-nsp] QoS Bandwidth Estimation feature in IOS
Message-ID: <1247228791.8733.3.camel@dsba-ipso>

Is anyone here using "QoS Bandwidth Estimation"?
I just ask it because I think it could be useful for our network here
but I don't see clear how it works and I would like to share some dudes
I have.

As far as I understand, if I have this code:


Router(config)# policy-map my-policy
Router(config-pmap)# class my-class
Router(config-pmap-c)# bandwidth percent 20
Router(config-pmap-c)# estimate bandwidth drop-one-in 100 delay-one-in
100 milliseconds 50

Then, "bandwidth percent 20" is is just applied strictly if the
"estimate bandwith" condition is reached just to achieve the
service-level required for that traffice matched.

Is that correct?
In that case this a new way -at least for me- to manage a congestion
situation, is this correct?

Thanks in advance.
Luis


From steve at ibctech.ca  Fri Jul 10 08:28:07 2009
From: steve at ibctech.ca (Steve Bertrand)
Date: Fri, 10 Jul 2009 08:28:07 -0400
Subject: [c-nsp] IPv6 iBGP Route Reflector
In-Reply-To: <20090710092548.e7bcd297.kron@linkey.ru>
References: <20090709221739.60f8e34e.kron@linkey.ru>	<4A56388F.6060607@ibctech.ca>
	<20090710092548.e7bcd297.kron@linkey.ru>
Message-ID: <4A5733D7.7030007@ibctech.ca>

Aleksandr Gurbo wrote:
> On Thu, 09 Jul 2009 14:35:59 -0400
> Steve Bertrand <steve at ibctech.ca> wrote:
> 
>> Aleksandr Gurbo wrote:
>>>>> rtr4#show ip bgp ipv6 unicast 2001:1020:100::3/128
>>>>> BGP routing table entry for 2001:1020:100::3/128, version 0
>>>>> Paths: (1 available, no best path)
>>>>>   Not advertised to any peer
>>>>>   Local, (received & used)
>>>>>     2001:1020:100::3 (inaccessible) from 2001:1020:100::2 (10.10.1.14)
>>>>                        ^^^^^^^^^^^^^^
>>>>
>>>> I don't know for sure, but this seems like a reachability problem, not
>>>> necessarily a BGP problem.
>>> Yes, you are partially right, but rtr3 can reach rtr4.
>>>
>> ok.
>>
>>>  bgp log-neighbor-changes
>>>  neighbor 2001:1020:100::3 remote-as 65000
>>>  neighbor 2001:1020:100::3 ebgp-multihop 10
>> It doesn't appear as ebgp-multihop should be used in this case, since it
>> appears to be an iBGP session.
>>
>> Also, does setting next-hop-self on rtr4's peering with rtr2 fix the
>> problem?
> 
> This is iBGP session. I removed settings ebgp-multihop on rtr2_RR and added next-hop-self on rtr4 and rtr3, but problem doesn't solved.
> Do you have ideas about change next-hop? May be through route-map?

My mistake.

The next-hop-self should be applied on rtr2, not rtr4.

Given your setup r3-r2-r4, tagging next-hop-self on routes reflected by
r2 to r4, and from r2 to r3 (if you are reflecting r2 to r3 as well)
should do what you want. This will then provide r4 with a valid and
accessible next hop.

Let me know if this works, and sorry for the confusion ;)

Steve


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3233 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090710/7685039d/attachment.bin>

From david.freedman at uk.clara.net  Fri Jul 10 09:29:38 2009
From: david.freedman at uk.clara.net (David Freedman)
Date: Fri, 10 Jul 2009 14:29:38 +0100
Subject: [c-nsp] Netflow Sampling
In-Reply-To: <B5CFB919B5EEF345969F51FAFE6360D50AD81A@GBLDCXMB10.emea.cbre.net>
References: <B5CFB919B5EEF345969F51FAFE6360D50AD81A@GBLDCXMB10.emea.cbre.net>
Message-ID: <h37fo2$5vk$1@ger.gmane.org>

I didn't know sampling was available for this platform?
I don't believe it is.

Are you doing this to reduce load / storage on your collector?

David.


Oddiraju, Kiran @ London SMC wrote:
> Guys,
> 
>  
> 
> I am trying to configure Netflow sampling interval on a c1801 router
> (IOS version "c180x-broadband-mz.124-15.T6.bin"). I was able to enable
> Netflow globally and configured it on the interface as well. But I can't
> setup sampling, it doesn't like the commands. What am I doing wrong?
> 
>  
> 
> Config
> 
>  
> 
> interface FastEthernet0
> 
>  ip address 10.15.255.50 255.255.255.252
> 
>  ip flow ingress
> 
>  ip route-cache flow
> 
>  speed 100
> 
>  full-duplex
> 
> !
> 
>  
> 
> ip flow-export source FastEthernet0
> 
> ip flow-export version 5
> 
> ip flow-export destination 10.13.246.50 2055
> 
> ip flow-export destination 10.15.246.66 2055
> 
>  
> 
>  
> 
> Netflow-Test(config-if)#ip route-cache flow sampled
> 
>                                             ^
> 
> % Invalid input detected at '^' marker.
> 
>  
> 
> Netflow-Test(config)#ip flow-sampling-mode packet-interval ?
> 
> % Unrecognized command
> 
>  
> 
> Many thanks,
> 
> Kiran
> 
> 
> CB Richard Ellis Limited, Registered Office: St Martin's Court, 
> 10 Paternoster Row, London, EC4M 7HP, registered in England and Wales No. 3536032. 
> Regulated by the RICS and an appointed representative of CB Richard Ellis 
> Indirect Investment Services Limited which is authorised and regulated by the Financial Services Authority.
> 
> This communication is from CB Richard Ellis Limited or one of its 
> associated/subsidiary companies. This communication contains information 
> which is confidential and may be privileged. If you are not the intended recipient, 
> please contact the sender immediately. Any use of its contents is strictly prohibited 
> and you must not copy, send or disclose it, or rely on its contents in any way whatsoever. 
> Reasonable care has been taken to ensure that this communication 
> (and any attachments or hyperlinks contained within it) is free from computer viruses. 
> No responsibility is accepted by CB Richard Ellis Limited or its associated/subsidiary 
> companies and the recipient should carry out any appropriate virus checks.
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 


From Kiran.Oddiraju at cbre.com  Fri Jul 10 11:26:27 2009
From: Kiran.Oddiraju at cbre.com (Oddiraju, Kiran @ London SMC)
Date: Fri, 10 Jul 2009 16:26:27 +0100
Subject: [c-nsp] Netflow Sampling
In-Reply-To: <h37fo2$5vk$1@ger.gmane.org>
References: <B5CFB919B5EEF345969F51FAFE6360D50AD81A@GBLDCXMB10.emea.cbre.net>
	<h37fo2$5vk$1@ger.gmane.org>
Message-ID: <B5CFB919B5EEF345969F51FAFE6360D50AD84B@GBLDCXMB10.emea.cbre.net>

Actually we want to increase the sampling interval on the collector to
see what's happening on a particular link. I don't know what is the
default sampling interval but we want to change it to something like
every minute.

Thanks David.

Regards,
Kiran

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of David Freedman
Sent: 10 July 2009 14:30
To: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Netflow Sampling

I didn't know sampling was available for this platform?
I don't believe it is.

Are you doing this to reduce load / storage on your collector?

David.


Oddiraju, Kiran @ London SMC wrote:
> Guys,
> 
>  
> 
> I am trying to configure Netflow sampling interval on a c1801 router
> (IOS version "c180x-broadband-mz.124-15.T6.bin"). I was able to enable
> Netflow globally and configured it on the interface as well. But I
can't
> setup sampling, it doesn't like the commands. What am I doing wrong?
> 
>  
> 
> Config
> 
>  
> 
> interface FastEthernet0
> 
>  ip address 10.15.255.50 255.255.255.252
> 
>  ip flow ingress
> 
>  ip route-cache flow
> 
>  speed 100
> 
>  full-duplex
> 
> !
> 
>  
> 
> ip flow-export source FastEthernet0
> 
> ip flow-export version 5
> 
> ip flow-export destination 10.13.246.50 2055
> 
> ip flow-export destination 10.15.246.66 2055
> 
>  
> 
>  
> 
> Netflow-Test(config-if)#ip route-cache flow sampled
> 
>                                             ^
> 
> % Invalid input detected at '^' marker.
> 
>  
> 
> Netflow-Test(config)#ip flow-sampling-mode packet-interval ?
> 
> % Unrecognized command
> 
>  
> 
> Many thanks,
> 
> Kiran
> 
> 
> CB Richard Ellis Limited, Registered Office: St Martin's Court, 
> 10 Paternoster Row, London, EC4M 7HP, registered in England and Wales
No. 3536032. 
> Regulated by the RICS and an appointed representative of CB Richard
Ellis 
> Indirect Investment Services Limited which is authorised and regulated
by the Financial Services Authority.
> 
> This communication is from CB Richard Ellis Limited or one of its 
> associated/subsidiary companies. This communication contains
information 
> which is confidential and may be privileged. If you are not the
intended recipient, 
> please contact the sender immediately. Any use of its contents is
strictly prohibited 
> and you must not copy, send or disclose it, or rely on its contents in
any way whatsoever. 
> Reasonable care has been taken to ensure that this communication 
> (and any attachments or hyperlinks contained within it) is free from
computer viruses. 
> No responsibility is accepted by CB Richard Ellis Limited or its
associated/subsidiary 
> companies and the recipient should carry out any appropriate virus
checks.
> 
> _______________________________________________
> cisco-nsp mailing 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/
CB Richard Ellis Limited, Registered Office: St Martin's Court, 
10 Paternoster Row, London, EC4M 7HP, registered in England and Wales No. 3536032. 
Regulated by the RICS and an appointed representative of CB Richard Ellis 
Indirect Investment Services Limited which is authorised and regulated by the Financial Services Authority.

This communication is from CB Richard Ellis Limited or one of its 
associated/subsidiary companies. This communication contains information 
which is confidential and may be privileged. If you are not the intended recipient, 
please contact the sender immediately. Any use of its contents is strictly prohibited 
and you must not copy, send or disclose it, or rely on its contents in any way whatsoever. 
Reasonable care has been taken to ensure that this communication 
(and any attachments or hyperlinks contained within it) is free from computer viruses. 
No responsibility is accepted by CB Richard Ellis Limited or its associated/subsidiary 
companies and the recipient should carry out any appropriate virus checks.


From david.freedman at uk.clara.net  Fri Jul 10 12:07:36 2009
From: david.freedman at uk.clara.net (David Freedman)
Date: Fri, 10 Jul 2009 17:07:36 +0100
Subject: [c-nsp] Netflow Sampling
In-Reply-To: <B5CFB919B5EEF345969F51FAFE6360D50AD84B@GBLDCXMB10.emea.cbre.net>
References: <B5CFB919B5EEF345969F51FAFE6360D50AD81A@GBLDCXMB10.emea.cbre.net>	<h37fo2$5vk$1@ger.gmane.org>
	<B5CFB919B5EEF345969F51FAFE6360D50AD84B@GBLDCXMB10.emea.cbre.net>
Message-ID: <h37p08$5d4$1@ger.gmane.org>

The default is not to sample.

David.

Oddiraju, Kiran @ London SMC wrote:
> Actually we want to increase the sampling interval on the collector to
> see what's happening on a particular link. I don't know what is the
> default sampling interval but we want to change it to something like
> every minute.
> 
> Thanks David.
> 
> Regards,
> Kiran
> 
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of David Freedman
> Sent: 10 July 2009 14:30
> To: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] Netflow Sampling
> 
> I didn't know sampling was available for this platform?
> I don't believe it is.
> 
> Are you doing this to reduce load / storage on your collector?
> 
> David.
> 
> 
> Oddiraju, Kiran @ London SMC wrote:
>> Guys,
>>
>>  
>>
>> I am trying to configure Netflow sampling interval on a c1801 router
>> (IOS version "c180x-broadband-mz.124-15.T6.bin"). I was able to enable
>> Netflow globally and configured it on the interface as well. But I
> can't
>> setup sampling, it doesn't like the commands. What am I doing wrong?
>>
>>  
>>
>> Config
>>
>>  
>>
>> interface FastEthernet0
>>
>>  ip address 10.15.255.50 255.255.255.252
>>
>>  ip flow ingress
>>
>>  ip route-cache flow
>>
>>  speed 100
>>
>>  full-duplex
>>
>> !
>>
>>  
>>
>> ip flow-export source FastEthernet0
>>
>> ip flow-export version 5
>>
>> ip flow-export destination 10.13.246.50 2055
>>
>> ip flow-export destination 10.15.246.66 2055
>>
>>  
>>
>>  
>>
>> Netflow-Test(config-if)#ip route-cache flow sampled
>>
>>                                             ^
>>
>> % Invalid input detected at '^' marker.
>>
>>  
>>
>> Netflow-Test(config)#ip flow-sampling-mode packet-interval ?
>>
>> % Unrecognized command
>>
>>  
>>
>> Many thanks,
>>
>> Kiran
>>
>>
>> CB Richard Ellis Limited, Registered Office: St Martin's Court, 
>> 10 Paternoster Row, London, EC4M 7HP, registered in England and Wales
> No. 3536032. 
>> Regulated by the RICS and an appointed representative of CB Richard
> Ellis 
>> Indirect Investment Services Limited which is authorised and regulated
> by the Financial Services Authority.
>> This communication is from CB Richard Ellis Limited or one of its 
>> associated/subsidiary companies. This communication contains
> information 
>> which is confidential and may be privileged. If you are not the
> intended recipient, 
>> please contact the sender immediately. Any use of its contents is
> strictly prohibited 
>> and you must not copy, send or disclose it, or rely on its contents in
> any way whatsoever. 
>> Reasonable care has been taken to ensure that this communication 
>> (and any attachments or hyperlinks contained within it) is free from
> computer viruses. 
>> No responsibility is accepted by CB Richard Ellis Limited or its
> associated/subsidiary 
>> companies and the recipient should carry out any appropriate virus
> checks.
>> _______________________________________________
>> cisco-nsp mailing 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/
> CB Richard Ellis Limited, Registered Office: St Martin's Court, 
> 10 Paternoster Row, London, EC4M 7HP, registered in England and Wales No. 3536032. 
> Regulated by the RICS and an appointed representative of CB Richard Ellis 
> Indirect Investment Services Limited which is authorised and regulated by the Financial Services Authority.
> 
> This communication is from CB Richard Ellis Limited or one of its 
> associated/subsidiary companies. This communication contains information 
> which is confidential and may be privileged. If you are not the intended recipient, 
> please contact the sender immediately. Any use of its contents is strictly prohibited 
> and you must not copy, send or disclose it, or rely on its contents in any way whatsoever. 
> Reasonable care has been taken to ensure that this communication 
> (and any attachments or hyperlinks contained within it) is free from computer viruses. 
> No responsibility is accepted by CB Richard Ellis Limited or its associated/subsidiary 
> companies and the recipient should carry out any appropriate virus checks.
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 


From vitya at list.ru  Fri Jul 10 12:12:32 2009
From: vitya at list.ru (victor)
Date: Fri, 10 Jul 2009 20:12:32 +0400
Subject: [c-nsp] IP multicast traffic overwhelms switches
Message-ID: <op.uwu0mxbf2vrlim@localhost.localdomain>

Hi
We are getting ready a residential triple-play network for the launch. As  
part of my job I'm conducting various tests on its performance, delays,  
etc before we go into production. Today was the multicast time and testing  
it I got very discouraging results. Under very moderate load of 15 IPTV  
streams (each approximately 1-1,5Mbps) the cpu gauge on the core C7604  
increased by 15% but on the distribution C4924 hit 50% from zero!  When I  
went on with the test and launched iperf adding one more 50 Mbps stream in  
udp multicact mode to stress-test both even more the cpu utilization on   
C7604 became 60% and on C4924 hit 100%. It even became visible as the  
responses of the telnet console considerable slowed down.
Both switches work as ip multicast routers in sparse-dense mode. The RP is  
C7604. Apparently all the multicast traffic gets process switched, though  
I explicitly entered ?ip mroute-cache? under every interface.
Did someone encounter something similar? Is it expected behavior? Is there  
a way to force cef to do it's job. Specs say that  C4924 can switch/route  
up to 72gbps irrespectively of L2/L3/L4 protocol.

wbr victor



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

From jashton at esnet.com  Fri Jul 10 11:56:40 2009
From: jashton at esnet.com (James Ashton)
Date: Fri, 10 Jul 2009 11:56:40 -0400
Subject: [c-nsp] Mac address flapping..
Message-ID: <490B0AB46362B947A2947D5CB5E7F2A105AE006700@exchange.esnet.com>

Hello all.


I am seeing a log of Mac_Move log entries for one vlan on my 6509s. (I have a pair doing redundant gateways for a DataCenter network)

       %MAC_MOVE-SP-4-NOTIF: Host 00d0.009e.2400 in vlan 42 is flapping between port Po1 and port Gi1/7

I see about 20 of these for this one vlan each minute.
Spanning tree is not reconverging.  It hasn't had a topology change in over 48 hours.
HSRP has not changed state.
I have over 120 vlans set up in this exact manor and this is the only one going this.

I have default timers set on HSRP and Spanning tree.
Gateways are all on SVIs.
Trunks between the 6509s and then a full mesh out to a pair of 4506s doing customer distro.

The above log entries are the only ones I am seeing from all 4 devices.   And they are only coming from    6509-a



I am running out of ideas as to the cause.   If I disconnect the customer from 4506-b or -a  so they only have one link and are no longer part of spanning tree.  It doesn't stop.  So I assume that their switch is not the cause.

Any thoughts??



=================================================
The vlan interface config is:
interface Vlan42
 description Customer1
 ip address xxx.xxx.xxx.xxx 255.255.255.224 secondary
 ip address xxx.xxx.xxx.xxx 255.255.255.224
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 standby 42 ip xxx.xxx.xxx.xxx
 standby 42 ip xxx.xxx.xxx.xxx secondary
 standby 42 priority 110
 standby 42 preempt

On the second 6509 the config is:
interface Vlan42
 description Customer1
 ip address xxx.xxx.xxx.xxx 255.255.255.224 secondary
 ip address xxx.xxx.xxx.xxx 255.255.255.224
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 standby 42 ip xxx.xxx.xxx.xxx
 standby 42 ip xxx.xxx.xxx.xxx secondary
  standby 42 preempt


6509-a:
VLAN0042
  Spanning tree enabled protocol ieee
  Root ID    Priority    24618
             Address     00d0.00a7.f000
             This bridge is the root
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    24618  (priority 24576 sys-id-ext 42)
             Address     00d0.00a7.f000
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
             Aging Time 300

Interface        Role Sts Cost      Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Gi1/7            Desg FWD 4         128.7    P2p 
Gi1/8            Desg FWD 4         128.8    P2p 
Po1              Desg FWD 3         128.1665 P2p


6509-b:
VLAN0042
  Spanning tree enabled protocol ieee
  Root ID    Priority    24618
             Address     00d0.00a7.f000
             Cost        3
             Port        1665 (Port-channel1)
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    28714  (priority 28672 sys-id-ext 42)
             Address     00d0.009e.2400
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
             Aging Time 300

Interface        Role Sts Cost      Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Gi1/7            Desg FWD 4         128.7    P2p 
Gi1/8            Desg FWD 4         128.8    P2p 
Po1              Root FWD 3         128.1665 P2p


4506-a:
VLAN0042
  Spanning tree enabled protocol ieee
  Root ID    Priority    24618
             Address     00d0.00a7.f000
             Cost        3004
             Port        1 (GigabitEthernet1/1)
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    49194  (priority 49152 sys-id-ext 42)
             Address     0013.c405.7dc0
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
             Aging Time 300
  Uplinkfast enabled

Interface        Role Sts Cost      Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Gi1/1            Root FWD 3004      128.1    P2p 
Gi1/2            Altn BLK 3004      128.2    P2p 
Fa3/25           Desg FWD 3019      128.153  P2p




4506-b:
VLAN0042
  Spanning tree enabled protocol ieee
  Root ID    Priority    24618
             Address     00d0.00a7.f000
             Cost        3004
             Port        2 (GigabitEthernet1/2)
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    49194  (priority 49152 sys-id-ext 42)
             Address     0014.6aed.3b80
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
             Aging Time 300
  Uplinkfast enabled

Interface        Role Sts Cost      Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Gi1/1            Altn BLK 3004      128.1    P2p 
Gi1/2            Root FWD 3004      128.2    P2p 
Fa3/25           Desg FWD 3019      128.153  P2p







James P. Ashton
Sr. Network Engineer
E Solutions Corporation
813.301.2642 Direct
813.301.2600 Main
813.301.2699 Fax
813.301.2620 Support



From A.L.M.Buxey at lboro.ac.uk  Fri Jul 10 13:09:33 2009
From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk)
Date: Fri, 10 Jul 2009 18:09:33 +0100
Subject: [c-nsp] Mac address flapping..
In-Reply-To: <490B0AB46362B947A2947D5CB5E7F2A105AE006700@exchange.esnet.com>
References: <490B0AB46362B947A2947D5CB5E7F2A105AE006700@exchange.esnet.com>
Message-ID: <20090710170933.GB31998@lboro.ac.uk>

Hi,

>        %MAC_MOVE-SP-4-NOTIF: Host 00d0.009e.2400 in vlan 42 is flapping between port Po1 and port Gi1/7

ah yes - have you traced the path that these routes take - portchannel goes
to where, Gi1/7 goes where?  could they have introduced a loop locally 
at the edge - eg if portfast was enabled and they've managed to plug switch
into switch?

alan

From jay-ford at uiowa.edu  Fri Jul 10 12:30:19 2009
From: jay-ford at uiowa.edu (Jay Ford)
Date: Fri, 10 Jul 2009 11:30:19 -0500 (CDT)
Subject: [c-nsp] IP multicast traffic overwhelms switches
In-Reply-To: <op.uwu0mxbf2vrlim@localhost.localdomain>
References: <op.uwu0mxbf2vrlim@localhost.localdomain>
Message-ID: <alpine.DEB.2.00.0907101123420.23314@seatpost.its.uiowa.edu>

On Fri, 10 Jul 2009, victor wrote:
> We are getting ready a residential triple-play network for the launch. As 
> part of my job I'm conducting various tests on its performance, delays, 
> etc before we go into production. Today was the multicast time and testing 
> it I got very discouraging results. Under very moderate load of 15 IPTV 
> streams (each approximately 1-1,5Mbps) the cpu gauge on the core C7604 
> increased by 15% but on the distribution C4924 hit 50% from zero!  When I 
> went on with the test and launched iperf adding one more 50 Mbps stream in 
> udp multicact mode to stress-test both even more the cpu utilization on 
> C7604 became 60% and on C4924 hit 100%. It even became visible as the 
> responses of the telnet console considerable slowed down.
> Both switches work as ip multicast routers in sparse-dense mode. The RP is 
> C7604. Apparently all the multicast traffic gets process switched, though 
> I explicitly entered ?ip mroute-cache? under every interface.
> Did someone encounter something similar? Is it expected behavior? Is there 
> a way to force cef to do it's job. Specs say that  C4924 can switch/route 
> up to 72gbps irrespectively of L2/L3/L4 protocol.

I don't think you want ?ip mroute-cache?, at least not on 7600/6500 boxes. 
My guess is that by configuring that you're disabling the hardware-based 
forwarding & forcing it to software-based forwarding.  Get rid of the ?ip 
mroute-cache? & see if things get better on the 7600.

Are the 4900 boxes doing L3 or just L2?  I suspect they'd do much better at 
L2 fan-out of multicast than at L3 fan-out.  You're probably hitting a pps or 
packet replication limit before hitting the bps limit.

________________________________________________________________________
Jay Ford, Network Engineering Group, Information Technology Services
University of Iowa, Iowa City, IA 52242
email: jay-ford at uiowa.edu, phone: 319-335-5555, fax: 319-335-2951

From jashton at esnet.com  Fri Jul 10 13:48:13 2009
From: jashton at esnet.com (James Ashton)
Date: Fri, 10 Jul 2009 13:48:13 -0400
Subject: [c-nsp] Mac address flapping..
In-Reply-To: <490B0AB46362B947A2947D5CB5E7F2A105AE006700@exchange.esnet.com>
References: <490B0AB46362B947A2947D5CB5E7F2A105AE006700@exchange.esnet.com>
Message-ID: <490B0AB46362B947A2947D5CB5E7F2A105AE006704@exchange.esnet.com>

Alan,
 Po1 is the connection from 6509-a to 6509-b.
 G1/7 goes to port G1/1 on 4506-a.
 G1/8 goes to G1/1 on 4506-b.

As for them creating a loop locally, If I disable one of the ports facing them, the errors persist.  Them having a loop in their switch, if it only has a single connection to my network, shouldn't effect me.  Unless I am missing something..

Could their configuration actually effect my spanning tree if I am only running one link to them??


James




-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of James Ashton
Sent: Friday, July 10, 2009 11:57 AM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Mac address flapping..

Hello all.


I am seeing a log of Mac_Move log entries for one vlan on my 6509s. (I have a pair doing redundant gateways for a DataCenter network)

       %MAC_MOVE-SP-4-NOTIF: Host 00d0.009e.2400 in vlan 42 is flapping between port Po1 and port Gi1/7

I see about 20 of these for this one vlan each minute.
Spanning tree is not reconverging.  It hasn't had a topology change in over 48 hours.
HSRP has not changed state.
I have over 120 vlans set up in this exact manor and this is the only one going this.

I have default timers set on HSRP and Spanning tree.
Gateways are all on SVIs.
Trunks between the 6509s and then a full mesh out to a pair of 4506s doing customer distro.

The above log entries are the only ones I am seeing from all 4 devices.   And they are only coming from    6509-a



I am running out of ideas as to the cause.   If I disconnect the customer from 4506-b or -a  so they only have one link and are no longer part of spanning tree.  It doesn't stop.  So I assume that their switch is not the cause.

Any thoughts??



=================================================
The vlan interface config is:
interface Vlan42
 description Customer1
 ip address xxx.xxx.xxx.xxx 255.255.255.224 secondary
 ip address xxx.xxx.xxx.xxx 255.255.255.224
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 standby 42 ip xxx.xxx.xxx.xxx
 standby 42 ip xxx.xxx.xxx.xxx secondary
 standby 42 priority 110
 standby 42 preempt

On the second 6509 the config is:
interface Vlan42
 description Customer1
 ip address xxx.xxx.xxx.xxx 255.255.255.224 secondary
 ip address xxx.xxx.xxx.xxx 255.255.255.224
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 standby 42 ip xxx.xxx.xxx.xxx
 standby 42 ip xxx.xxx.xxx.xxx secondary
  standby 42 preempt


6509-a:
VLAN0042
  Spanning tree enabled protocol ieee
  Root ID    Priority    24618
             Address     00d0.00a7.f000
             This bridge is the root
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    24618  (priority 24576 sys-id-ext 42)
             Address     00d0.00a7.f000
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
             Aging Time 300

Interface        Role Sts Cost      Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Gi1/7            Desg FWD 4         128.7    P2p 
Gi1/8            Desg FWD 4         128.8    P2p 
Po1              Desg FWD 3         128.1665 P2p


6509-b:
VLAN0042
  Spanning tree enabled protocol ieee
  Root ID    Priority    24618
             Address     00d0.00a7.f000
             Cost        3
             Port        1665 (Port-channel1)
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    28714  (priority 28672 sys-id-ext 42)
             Address     00d0.009e.2400
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
             Aging Time 300

Interface        Role Sts Cost      Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Gi1/7            Desg FWD 4         128.7    P2p 
Gi1/8            Desg FWD 4         128.8    P2p 
Po1              Root FWD 3         128.1665 P2p


4506-a:
VLAN0042
  Spanning tree enabled protocol ieee
  Root ID    Priority    24618
             Address     00d0.00a7.f000
             Cost        3004
             Port        1 (GigabitEthernet1/1)
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    49194  (priority 49152 sys-id-ext 42)
             Address     0013.c405.7dc0
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
             Aging Time 300
  Uplinkfast enabled

Interface        Role Sts Cost      Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Gi1/1            Root FWD 3004      128.1    P2p 
Gi1/2            Altn BLK 3004      128.2    P2p 
Fa3/25           Desg FWD 3019      128.153  P2p




4506-b:
VLAN0042
  Spanning tree enabled protocol ieee
  Root ID    Priority    24618
             Address     00d0.00a7.f000
             Cost        3004
             Port        2 (GigabitEthernet1/2)
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    49194  (priority 49152 sys-id-ext 42)
             Address     0014.6aed.3b80
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
             Aging Time 300
  Uplinkfast enabled

Interface        Role Sts Cost      Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Gi1/1            Altn BLK 3004      128.1    P2p 
Gi1/2            Root FWD 3004      128.2    P2p 
Fa3/25           Desg FWD 3019      128.153  P2p







James P. Ashton
Sr. Network Engineer
E Solutions Corporation
813.301.2642 Direct
813.301.2600 Main
813.301.2699 Fax
813.301.2620 Support


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

From listacct at genhex.net  Fri Jul 10 14:02:17 2009
From: listacct at genhex.net (Jeff Crowe)
Date: Fri, 10 Jul 2009 14:02:17 -0400
Subject: [c-nsp] Mac address flapping..
In-Reply-To: <490B0AB46362B947A2947D5CB5E7F2A105AE006704@exchange.esnet.com>
References: <490B0AB46362B947A2947D5CB5E7F2A105AE006700@exchange.esnet.com>
	<490B0AB46362B947A2947D5CB5E7F2A105AE006704@exchange.esnet.com>
Message-ID: <000001ca0188$90314ad0$b093e070$@net>

Hi James,

I have actually recently created this situation when I setup a 2651 router
to bridge vlan's.  Our provider delivers vlans a,b,c,d,e on a trunk port
that I put through a router configured for irb, this caused the mac's on any
vlan to start jumping around on interfaces on their network.

Hope this helps find the cause.

Regards,
Jeff.



-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of James Ashton
Sent: Friday, July 10, 2009 1:48 PM
To: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Mac address flapping..

Alan,
 Po1 is the connection from 6509-a to 6509-b.
 G1/7 goes to port G1/1 on 4506-a.
 G1/8 goes to G1/1 on 4506-b.

As for them creating a loop locally, If I disable one of the ports facing
them, the errors persist.  Them having a loop in their switch, if it only
has a single connection to my network, shouldn't effect me.  Unless I am
missing something..

Could their configuration actually effect my spanning tree if I am only
running one link to them??


James




-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of James Ashton
Sent: Friday, July 10, 2009 11:57 AM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Mac address flapping..

Hello all.


I am seeing a log of Mac_Move log entries for one vlan on my 6509s. (I have
a pair doing redundant gateways for a DataCenter network)

       %MAC_MOVE-SP-4-NOTIF: Host 00d0.009e.2400 in vlan 42 is flapping
between port Po1 and port Gi1/7

I see about 20 of these for this one vlan each minute.
Spanning tree is not reconverging.  It hasn't had a topology change in over
48 hours.
HSRP has not changed state.
I have over 120 vlans set up in this exact manor and this is the only one
going this.

I have default timers set on HSRP and Spanning tree.
Gateways are all on SVIs.
Trunks between the 6509s and then a full mesh out to a pair of 4506s doing
customer distro.

The above log entries are the only ones I am seeing from all 4 devices.
And they are only coming from    6509-a



I am running out of ideas as to the cause.   If I disconnect the customer
from 4506-b or -a  so they only have one link and are no longer part of
spanning tree.  It doesn't stop.  So I assume that their switch is not the
cause.

Any thoughts??



=================================================
The vlan interface config is:
interface Vlan42
 description Customer1
 ip address xxx.xxx.xxx.xxx 255.255.255.224 secondary
 ip address xxx.xxx.xxx.xxx 255.255.255.224
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 standby 42 ip xxx.xxx.xxx.xxx
 standby 42 ip xxx.xxx.xxx.xxx secondary
 standby 42 priority 110
 standby 42 preempt

On the second 6509 the config is:
interface Vlan42
 description Customer1
 ip address xxx.xxx.xxx.xxx 255.255.255.224 secondary
 ip address xxx.xxx.xxx.xxx 255.255.255.224
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 standby 42 ip xxx.xxx.xxx.xxx
 standby 42 ip xxx.xxx.xxx.xxx secondary
  standby 42 preempt


6509-a:
VLAN0042
  Spanning tree enabled protocol ieee
  Root ID    Priority    24618
             Address     00d0.00a7.f000
             This bridge is the root
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    24618  (priority 24576 sys-id-ext 42)
             Address     00d0.00a7.f000
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
             Aging Time 300

Interface        Role Sts Cost      Prio.Nbr Type
---------------- ---- --- --------- --------
--------------------------------
Gi1/7            Desg FWD 4         128.7    P2p 
Gi1/8            Desg FWD 4         128.8    P2p 
Po1              Desg FWD 3         128.1665 P2p


6509-b:
VLAN0042
  Spanning tree enabled protocol ieee
  Root ID    Priority    24618
             Address     00d0.00a7.f000
             Cost        3
             Port        1665 (Port-channel1)
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    28714  (priority 28672 sys-id-ext 42)
             Address     00d0.009e.2400
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
             Aging Time 300

Interface        Role Sts Cost      Prio.Nbr Type
---------------- ---- --- --------- --------
--------------------------------
Gi1/7            Desg FWD 4         128.7    P2p 
Gi1/8            Desg FWD 4         128.8    P2p 
Po1              Root FWD 3         128.1665 P2p


4506-a:
VLAN0042
  Spanning tree enabled protocol ieee
  Root ID    Priority    24618
             Address     00d0.00a7.f000
             Cost        3004
             Port        1 (GigabitEthernet1/1)
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    49194  (priority 49152 sys-id-ext 42)
             Address     0013.c405.7dc0
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
             Aging Time 300
  Uplinkfast enabled

Interface        Role Sts Cost      Prio.Nbr Type
---------------- ---- --- --------- --------
--------------------------------
Gi1/1            Root FWD 3004      128.1    P2p 
Gi1/2            Altn BLK 3004      128.2    P2p 
Fa3/25           Desg FWD 3019      128.153  P2p




4506-b:
VLAN0042
  Spanning tree enabled protocol ieee
  Root ID    Priority    24618
             Address     00d0.00a7.f000
             Cost        3004
             Port        2 (GigabitEthernet1/2)
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    49194  (priority 49152 sys-id-ext 42)
             Address     0014.6aed.3b80
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
             Aging Time 300
  Uplinkfast enabled

Interface        Role Sts Cost      Prio.Nbr Type
---------------- ---- --- --------- --------
--------------------------------
Gi1/1            Altn BLK 3004      128.1    P2p 
Gi1/2            Root FWD 3004      128.2    P2p 
Fa3/25           Desg FWD 3019      128.153  P2p







James P. Ashton
Sr. Network Engineer
E Solutions Corporation
813.301.2642 Direct
813.301.2600 Main
813.301.2699 Fax
813.301.2620 Support


_______________________________________________
cisco-nsp mailing 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  Fri Jul 10 14:38:41 2009
From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk)
Date: Fri, 10 Jul 2009 19:38:41 +0100
Subject: [c-nsp] Mac address flapping..
In-Reply-To: <490B0AB46362B947A2947D5CB5E7F2A105AE006704@exchange.esnet.com>
References: <490B0AB46362B947A2947D5CB5E7F2A105AE006700@exchange.esnet.com>
	<490B0AB46362B947A2947D5CB5E7F2A105AE006704@exchange.esnet.com>
Message-ID: <20090710183841.GA32154@lboro.ac.uk>

Hi,

> Alan,
>  Po1 is the connection from 6509-a to 6509-b.
>  G1/7 goes to port G1/1 on 4506-a.
>  G1/8 goes to G1/1 on 4506-b.

what is the root bridge for vlan 42?

alan

From vitya at list.ru  Fri Jul 10 14:42:03 2009
From: vitya at list.ru (victor)
Date: Fri, 10 Jul 2009 22:42:03 +0400
Subject: [c-nsp] IP multicast traffic overwhelms switches
In-Reply-To: <alpine.DEB.2.00.0907101123420.23314@seatpost.its.uiowa.edu>
References: <op.uwu0mxbf2vrlim@localhost.localdomain>
	<alpine.DEB.2.00.0907101123420.23314@seatpost.its.uiowa.edu>
Message-ID: <op.uwu7kdop2vrlim@localhost.localdomain>

On Fri, 10 Jul 2009 20:30:19 +0400, Jay Ford <jay-ford at uiowa.edu> wrote:

> I don't think you want ?ip mroute-cache?, at least not on 7600/6500  
> boxes.
> My guess is that by configuring that you're disabling the hardware-based
> forwarding & forcing it to software-based forwarding.  Get rid of the ?ip
> mroute-cache? & see if things get better on the 7600.
>
ip mroute-cache is the default mode for interfaces. Are you suggesting to  
do "no ip mroute-cache" to disable cef completely.
> Are the 4900 boxes doing L3 or just L2?  I suspect they'd do much better  
> at
> L2 fan-out of multicast than at L3 fan-out.  You're probably hitting a  
> pps or
> packet replication limit before hitting the bps limit.
I agree that this switch will probably perform better doing L2 exchange  
but then there is another problem: C7604 carry QinQ vlans and C4924  
terminates them giving each tunnel's payload out of a deferent  
dot1q-tunnel access port. If I don't do multicast routing I will need to  
carry the same multicast traffic on every configured outer vlan. This will  
eat up all the bandwidth.


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

From vitya at list.ru  Fri Jul 10 14:49:45 2009
From: vitya at list.ru (victor)
Date: Fri, 10 Jul 2009 22:49:45 +0400
Subject: [c-nsp] IP multicast traffic overwhelms switches
In-Reply-To: <alpine.OSX.1.00.0907100700001.399@cust11794.lava.net>
References: <op.uwu0mxbf2vrlim@localhost.localdomain>
	<alpine.OSX.1.00.0907100700001.399@cust11794.lava.net>
Message-ID: <op.uwu7wu0z2vrlim@localhost.localdomain>

On Fri, 10 Jul 2009 21:04:21 +0400, Antonio Querubin <tony at lava.net> wrote:

> On Fri, 10 Jul 2009, victor wrote:
>
>> udp multicact mode to stress-test both even more the cpu utilization on  
>> C7604 became 60% and on C4924 hit 100%. It even became visible as the  
>> responses of the telnet console considerable slowed down.
>> Both switches work as ip multicast routers in sparse-dense mode. The RP  
>> is C7604. Apparently all the multicast traffic gets process switched,  
>> though
>
> Use sparse mode instead of sparse-dense.
What is your point here? Please, explain. Sparse-dense mode acts as dense  
only when RP is unavailable.
> Have you enabled either IGMP snooping or CGMP between the routers and  
> the switches?
Sure I have. IGMP was on by default. Video traffic from IPTV server is  
received by end users with no questions.


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

From jashton at esnet.com  Fri Jul 10 14:54:22 2009
From: jashton at esnet.com (James Ashton)
Date: Fri, 10 Jul 2009 14:54:22 -0400
Subject: [c-nsp] Mac address flapping..
In-Reply-To: <20090710183841.GA32154@lboro.ac.uk>
References: <490B0AB46362B947A2947D5CB5E7F2A105AE006700@exchange.esnet.com>
	<490B0AB46362B947A2947D5CB5E7F2A105AE006704@exchange.esnet.com>
	<20090710183841.GA32154@lboro.ac.uk>
Message-ID: <490B0AB46362B947A2947D5CB5E7F2A105AE00670E@exchange.esnet.com>

The root bridge is 6509-a.


The one that is showing these log errors.

James

-----Original Message-----
From: A.L.M.Buxey at lboro.ac.uk [mailto:A.L.M.Buxey at lboro.ac.uk] 
Sent: Friday, July 10, 2009 2:39 PM
To: James Ashton
Cc: cisco-nsp at puck.nether.net
Subject: Re: Mac address flapping..

Hi,

> Alan,
>  Po1 is the connection from 6509-a to 6509-b.
>  G1/7 goes to port G1/1 on 4506-a.
>  G1/8 goes to G1/1 on 4506-b.

what is the root bridge for vlan 42?

alan

From kron at linkey.ru  Fri Jul 10 14:54:34 2009
From: kron at linkey.ru (Aleksandr Gurbo)
Date: Fri, 10 Jul 2009 22:54:34 +0400
Subject: [c-nsp] IPv6 iBGP Route Reflector
Message-ID: <20090710225434.dfaa72cb.kron@linkey.ru>

> >> Also, does setting next-hop-self on rtr4's peering with rtr2 fix the
> >> problem?
> > 
> > This is iBGP session. I removed settings ebgp-multihop on rtr2_RR and added next-hop-self on rtr4 and rtr3, but 
> >problem doesn't solved.
> > Do you have ideas about change next-hop? May be through route-map?
> 
> My mistake.
> 
> The next-hop-self should be applied on rtr2, not rtr4.
> 
> Given your setup r3-r2-r4, tagging next-hop-self on routes reflected by
> r2 to r4, and from r2 to r3 (if you are reflecting r2 to r3 as well)
> should do what you want. This will then provide r4 with a valid and
> accessible next hop.
> 
> Let me know if this works, and sorry for the confusion ;)

This scheme also doesn't work. I added next-hop-self on rtr2_RR for both peers with rtr3 and rtr4.

 address-family ipv6
  redistribute connected
  no synchronization
  neighbor 2001:1020:100::3 activate
  neighbor 2001:1020:100::3 inherit peer-policy rr-clients-v6
  neighbor 2001:1020:100::3 next-hop-self
  neighbor 2001:1020:100::4 activate
  neighbor 2001:1020:100::4 inherit peer-policy rr-clients-v6
  neighbor 2001:1020:100::4 next-hop-self
 exit-address-family

I tryed add route-map on out for change next-hop, but it doesn't help.
 neighbor 2001:1020:100::4 route-map NextHopPE4 out
 neighbor 2001:1020:100::3 route-map NextHopPE3 out

route-map NextHopPE3 permit 10
 set ipv6 next-hop 2001:1020:7000::1
route-map NextHopPE4 permit 10
 set ipv6 next-hop 2001:1020:8000::1

I think the problem in link-local address received from OSPFv3.
With ipv4 addresses this scheme work.

-- 
Alexandr Gurbo


From jay-ford at uiowa.edu  Fri Jul 10 15:03:08 2009
From: jay-ford at uiowa.edu (Jay Ford)
Date: Fri, 10 Jul 2009 14:03:08 -0500 (CDT)
Subject: [c-nsp] IP multicast traffic overwhelms switches
In-Reply-To: <op.uwu7kdop2vrlim@localhost.localdomain>
References: <op.uwu0mxbf2vrlim@localhost.localdomain>
	<alpine.DEB.2.00.0907101123420.23314@seatpost.its.uiowa.edu>
	<op.uwu7kdop2vrlim@localhost.localdomain>
Message-ID: <alpine.DEB.2.00.0907101350390.23314@seatpost.its.uiowa.edu>

On Fri, 10 Jul 2009, victor wrote:
> On Fri, 10 Jul 2009 20:30:19 +0400, Jay Ford <jay-ford at uiowa.edu> wrote:
>> I don't think you want ?ip mroute-cache?, at least not on 7600/6500 boxes.
>> My guess is that by configuring that you're disabling the hardware-based
>> forwarding & forcing it to software-based forwarding.  Get rid of the ?ip
>> mroute-cache? & see if things get better on the 7600.
>> 
> ip mroute-cache is the default mode for interfaces. Are you suggesting to do 
> "no ip mroute-cache" to disable cef completely.

In your original message you said:
    I explicitly entered "ip mroute-cache" under every interface
which I took to mean that you were changing the default.

In my experience on 6500 boxes running various 12.2SX versions "ip 
mroute-cache" does not show up by default.

If you do "show ip interface" for your edge-facing interfaces, does
    IP multicast multilayer switching is enabled
appear near the end of the output?

Also, does "show mls ip multicast" show your multicast traffic being hardware 
switched?

>> Are the 4900 boxes doing L3 or just L2?  I suspect they'd do much better at
>> L2 fan-out of multicast than at L3 fan-out.  You're probably hitting a pps 
>> or
>> packet replication limit before hitting the bps limit.
> I agree that this switch will probably perform better doing L2 exchange but 
> then there is another problem: C7604 carry QinQ vlans and C4924 terminates 
> them giving each tunnel's payload out of a deferent dot1q-tunnel access port. 
> If I don't do multicast routing I will need to carry the same multicast 
> traffic on every configured outer vlan. This will eat up all the bandwidth.

Bummer, dude.  I don't have anything to offer about that, other than to 
speculate that the QinQ tunnel stuff might be undermining the ability of 1 or 
both boxes to efficiently deal with multicast traffic.  You might have to 
get your Cisco support people in on this one.

________________________________________________________________________
Jay Ford, Network Engineering Group, Information Technology Services
University of Iowa, Iowa City, IA 52242
email: jay-ford at uiowa.edu, phone: 319-335-5555, fax: 319-335-2951

From MatlockK at exempla.org  Fri Jul 10 15:12:44 2009
From: MatlockK at exempla.org (Matlock, Kenneth L)
Date: Fri, 10 Jul 2009 13:12:44 -0600
Subject: [c-nsp] Mac address flapping..
In-Reply-To: <490B0AB46362B947A2947D5CB5E7F2A105AE00670E@exchange.esnet.com>
References: <490B0AB46362B947A2947D5CB5E7F2A105AE006700@exchange.esnet.com><490B0AB46362B947A2947D5CB5E7F2A105AE006704@exchange.esnet.com><20090710183841.GA32154@lboro.ac.uk>
	<490B0AB46362B947A2947D5CB5E7F2A105AE00670E@exchange.esnet.com>
Message-ID: <4288131ED5E3024C9CD4782CECCAD2C7065D3843@LMC-MAIL2.exempla.org>

I assume the server housing that MAC has 2 NICs, one plugged into
4506-a, and the other in 4506-b?

I've seen it before during a server reboot where it has multiple NICs
that the server guys have configured a virtual MAC, and that MAC bounces
between it's 2 ports a few times during OS startup, causing errors
almost exactly like that. The switch sees the MAC on one port, then the
server uses that MAC on the other port, etc.

I'd see if those error times coincide with reboots of the servers.

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 James Ashton
Sent: Friday, July 10, 2009 12:54 PM
To: A.L.M.Buxey at lboro.ac.uk
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Mac address flapping..

The root bridge is 6509-a.


The one that is showing these log errors.

James

-----Original Message-----
From: A.L.M.Buxey at lboro.ac.uk [mailto:A.L.M.Buxey at lboro.ac.uk] 
Sent: Friday, July 10, 2009 2:39 PM
To: James Ashton
Cc: cisco-nsp at puck.nether.net
Subject: Re: Mac address flapping..

Hi,

> Alan,
>  Po1 is the connection from 6509-a to 6509-b.
>  G1/7 goes to port G1/1 on 4506-a.
>  G1/8 goes to G1/1 on 4506-b.

what is the root bridge for vlan 42?

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 blahu77 at gmail.com  Fri Jul 10 15:19:59 2009
From: blahu77 at gmail.com (Mateusz Blaszczyk)
Date: Fri, 10 Jul 2009 20:19:59 +0100
Subject: [c-nsp] Mac address flapping..
In-Reply-To: <490B0AB46362B947A2947D5CB5E7F2A105AE006700@exchange.esnet.com>
References: <490B0AB46362B947A2947D5CB5E7F2A105AE006700@exchange.esnet.com>
Message-ID: <383357750907101219y6d8051b3g8f0bed7697a1eae7@mail.gmail.com>

James,

. (I have a pair doing redundant gateways for a DataCenter network)
>
> ? ? ? %MAC_MOVE-SP-4-NOTIF: Host 00d0.009e.2400 in vlan 42 is flapping between port Po1 and port Gi1/7
>
> I see about 20 of these for this one vlan each minute.

the mac is 6509-b and pps==20/minute is probably HSRP hello packet
from Vlan42 on 6509-b.
if there are no topo changes in stp there must be a unnoticed L2 loop,
either forgotten portfast or bpdu filtering between 6509-a,-b and
4506-a.

perhaps try to disconnect the customer completely during a maintenance
window and double check all your connections.

Best Regards,

-mat

From vitya at list.ru  Fri Jul 10 15:35:17 2009
From: vitya at list.ru (victor)
Date: Fri, 10 Jul 2009 23:35:17 +0400
Subject: [c-nsp] IP multicast traffic overwhelms switches
In-Reply-To: <alpine.DEB.2.00.0907101350390.23314@seatpost.its.uiowa.edu>
References: <op.uwu0mxbf2vrlim@localhost.localdomain>
	<alpine.DEB.2.00.0907101123420.23314@seatpost.its.uiowa.edu>
	<op.uwu7kdop2vrlim@localhost.localdomain>
	<alpine.DEB.2.00.0907101350390.23314@seatpost.its.uiowa.edu>
Message-ID: <op.uwu903nh2vrlim@localhost.localdomain>

On Fri, 10 Jul 2009 23:03:08 +0400, Jay Ford <jay-ford at uiowa.edu> wrote:

> In your original message you said:
>     I explicitly entered "ip mroute-cache" under every interface
> which I took to mean that you were changing the default.
>
> In my experience on 6500 boxes running various 12.2SX versions "ip
> mroute-cache" does not show up by default.
>
Right. Let me explain. After I configured initial setup I ran a test that  
showed intensive cpu usage. My first thought was about process switching  
and then I entered "ip mroute-cache" for the interfaces. But the command  
do not appear when you do "sho run int" that made me think it is on by  
default.
> If you do "show ip interface" for your edge-facing interfaces, does
>     IP multicast multilayer switching is enabled
> appear near the end of the output?
>
No, couldn't find it
> Also, does "show mls ip multicast" show your multicast traffic being  
> hardware switched?

#sho mls ip m
Multicast hardware switched flows:
Total hardware switched flows : 0

>
>>> Are the 4900 boxes doing L3 or just L2?  I suspect they'd do much  
>>> better at
>>> L2 fan-out of multicast than at L3 fan-out.  You're probably hitting a  
>>> pps
>>> or
>>> packet replication limit before hitting the bps limit.
>> I agree that this switch will probably perform better doing L2 exchange  
>> but
>> then there is another problem: C7604 carry QinQ vlans and C4924  
>> terminates
>> them giving each tunnel's payload out of a deferent dot1q-tunnel access  
>> port.
>> If I don't do multicast routing I will need to carry the same multicast
>> traffic on every configured outer vlan. This will eat up all the  
>> bandwidth.
>
> Bummer, dude.  I don't have anything to offer about that, other than to
> speculate that the QinQ tunnel stuff might be undermining the ability of  
> 1 or
> both boxes to efficiently deal with multicast traffic.  You might have to
> get your Cisco support people in on this one.
>



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

From lukasz at bromirski.net  Fri Jul 10 16:00:00 2009
From: lukasz at bromirski.net (=?UTF-8?B?xYF1a2FzeiBCcm9taXJza2k=?=)
Date: Fri, 10 Jul 2009 22:00:00 +0200
Subject: [c-nsp] IP multicast traffic overwhelms switches
In-Reply-To: <op.uwu0mxbf2vrlim@localhost.localdomain>
References: <op.uwu0mxbf2vrlim@localhost.localdomain>
Message-ID: <4A579DC0.9060100@bromirski.net>

On 2009-07-10 18:12, victor wrote:

> We are getting ready a residential triple-play network for the launch.
> As part of my job I'm conducting various tests on its performance,
> delays, etc before we go into production. Today was the multicast time
> and testing it I got very discouraging results. Under very moderate load
> of 15 IPTV streams (each approximately 1-1,5Mbps) the cpu gauge on the
> core C7604 increased by 15%

What's the software version on the 7604, Sup model and LCs used?

Can you show output of 'show platform hardware capacity' for the
box and 'sh proc cpu sorted'. Also 'sh ip pim int x/y count'
where the ports that multicast traffic is flowing through?

 > but on the distribution C4924 hit 50% from zero!

Clearly there's a problem with moving traffic in hardware.

Can you also drop a 'show ip mroute count' from both boxes?

-- 
"Everything will be okay in the end. |                  ?ukasz Bromirski
  If it's not okay, it's not the end. |       http://lukasz.bromirski.net

From sethm at rollernet.us  Fri Jul 10 21:25:33 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Fri, 10 Jul 2009 18:25:33 -0700
Subject: [c-nsp] Delay BGP peer session
Message-ID: <4A57EA0D.5000804@rollernet.us>

Is there any way to force a delay on a BGP session from establishing
when a link comes up? Say, for example, if a link flaps and
fast-external-fallover takes it down we should wait X minutes before
trying to bring the session back up.

~Seth


From sethm at rollernet.us  Fri Jul 10 22:15:02 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Fri, 10 Jul 2009 19:15:02 -0700
Subject: [c-nsp] Delay BGP peer session
In-Reply-To: <4A57EF6E.5000209@evaristesys.com>
References: <4A57EA0D.5000804@rollernet.us> <4A57EF6E.5000209@evaristesys.com>
Message-ID: <4A57F5A6.5070204@rollernet.us>

Alex Balashov wrote:
> Seth Mattinen wrote:
> 
>> Is there any way to force a delay on a BGP session from establishing
>> when a link comes up? Say, for example, if a link flaps and
>> fast-external-fallover takes it down we should wait X minutes before
>> trying to bring the session back up.
> 
> I would guess that flap dampening would be the proper solution.
> 

I don't think it can dampen the whole table and suppress announcements,
can it? I've never tried that.

~Seth

From jlewis at lewis.org  Fri Jul 10 22:20:36 2009
From: jlewis at lewis.org (Jon Lewis)
Date: Fri, 10 Jul 2009 22:20:36 -0400 (EDT)
Subject: [c-nsp] Delay BGP peer session
In-Reply-To: <4A57F5A6.5070204@rollernet.us>
References: <4A57EA0D.5000804@rollernet.us> <4A57EF6E.5000209@evaristesys.com>
	<4A57F5A6.5070204@rollernet.us>
Message-ID: <Pine.LNX.4.61.0907102219491.6312@soloth.lewis.org>

On Fri, 10 Jul 2009, Seth Mattinen wrote:

> Alex Balashov wrote:
>> Seth Mattinen wrote:
>>
>>> Is there any way to force a delay on a BGP session from establishing
>>> when a link comes up? Say, for example, if a link flaps and
>>> fast-external-fallover takes it down we should wait X minutes before
>>> trying to bring the session back up.
>>
>> I would guess that flap dampening would be the proper solution.
>>
>
> I don't think it can dampen the whole table and suppress announcements,
> can it? I've never tried that.

I believe IP Event Dampening is the knob you seek.

----------------------------------------------------------------------
  Jon Lewis                   |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

From abalashov at evaristesys.com  Fri Jul 10 22:27:40 2009
From: abalashov at evaristesys.com (Alex Balashov)
Date: Fri, 10 Jul 2009 22:27:40 -0400
Subject: [c-nsp] Delay BGP peer session
In-Reply-To: <4A57F5A6.5070204@rollernet.us>
References: <4A57EA0D.5000804@rollernet.us> <4A57EF6E.5000209@evaristesys.com>
	<4A57F5A6.5070204@rollernet.us>
Message-ID: <4A57F89C.8070209@evaristesys.com>

Seth Mattinen wrote:

> Alex Balashov wrote:
>> Seth Mattinen wrote:
>>
>>> Is there any way to force a delay on a BGP session from establishing
>>> when a link comes up? Say, for example, if a link flaps and
>>> fast-external-fallover takes it down we should wait X minutes before
>>> trying to bring the session back up.
>> I would guess that flap dampening would be the proper solution.
>>
> 
> I don't think it can dampen the whole table and suppress announcements,
> can it? I've never tried that.

Looking over the implementational docs from Cisco, you're right - it 
can't.  It's designed to dampen specific announcements from any peer.

-- Alex

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

From abalashov at evaristesys.com  Fri Jul 10 21:48:30 2009
From: abalashov at evaristesys.com (Alex Balashov)
Date: Fri, 10 Jul 2009 21:48:30 -0400
Subject: [c-nsp] Delay BGP peer session
In-Reply-To: <4A57EA0D.5000804@rollernet.us>
References: <4A57EA0D.5000804@rollernet.us>
Message-ID: <4A57EF6E.5000209@evaristesys.com>

Seth Mattinen wrote:

> Is there any way to force a delay on a BGP session from establishing
> when a link comes up? Say, for example, if a link flaps and
> fast-external-fallover takes it down we should wait X minutes before
> trying to bring the session back up.

I would guess that flap dampening would be the proper solution.

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

From MatlockK at exempla.org  Fri Jul 10 23:33:27 2009
From: MatlockK at exempla.org (Matlock, Kenneth L)
Date: Fri, 10 Jul 2009 21:33:27 -0600
Subject: [c-nsp] Delay BGP peer session
References: <4A57EA0D.5000804@rollernet.us> <4A57EF6E.5000209@evaristesys.com>
Message-ID: <4288131ED5E3024C9CD4782CECCAD2C70489E953@LMC-MAIL2.exempla.org>

It's ugly, but you could also use Embedded Event Manager if you're on a platform that supports it. Trigger on link up to wait X time, and then do a 'no neighbor <ip> shut' on the peer, and do a 'neighbor <ip> shut> immediately upon link down...
 
Ken

________________________________

From: cisco-nsp-bounces at puck.nether.net on behalf of Alex Balashov
Sent: Fri 7/10/2009 7:48 PM
To: Seth Mattinen
Cc: cisco-nsp
Subject: Re: [c-nsp] Delay BGP peer session



Seth Mattinen wrote:

> Is there any way to force a delay on a BGP session from establishing
> when a link comes up? Say, for example, if a link flaps and
> fast-external-fallover takes it down we should wait X minutes before
> trying to bring the session back up.

I would guess that flap dampening would be the proper solution.

--
Alex Balashov
Evariste Systems
Web     : http://www.evaristesys.com/
Tel     : (+1) (678) 954-0670
Direct  : (+1) (678) 954-0671
_______________________________________________
cisco-nsp mailing list  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 Jul 11 01:57:14 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Fri, 10 Jul 2009 22:57:14 -0700
Subject: [c-nsp] Delay BGP peer session
In-Reply-To: <Pine.LNX.4.61.0907102219491.6312@soloth.lewis.org>
References: <4A57EA0D.5000804@rollernet.us> <4A57EF6E.5000209@evaristesys.com>
	<4A57F5A6.5070204@rollernet.us>
	<Pine.LNX.4.61.0907102219491.6312@soloth.lewis.org>
Message-ID: <4A5829BA.8060002@rollernet.us>

Jon Lewis wrote:
> On Fri, 10 Jul 2009, Seth Mattinen wrote:
> 
>> Alex Balashov wrote:
>>> Seth Mattinen wrote:
>>>
>>>> Is there any way to force a delay on a BGP session from establishing
>>>> when a link comes up? Say, for example, if a link flaps and
>>>> fast-external-fallover takes it down we should wait X minutes before
>>>> trying to bring the session back up.
>>>
>>> I would guess that flap dampening would be the proper solution.
>>>
>>
>> I don't think it can dampen the whole table and suppress announcements,
>> can it? I've never tried that.
> 
> I believe IP Event Dampening is the knob you seek.
> 

Very interesting. I'll have to play around with that.

~Seth

From ivan.pepelnjak at zaplana.net  Sat Jul 11 03:20:03 2009
From: ivan.pepelnjak at zaplana.net (Ivan Pepelnjak)
Date: Sat, 11 Jul 2009 09:20:03 +0200
Subject: [c-nsp] IPv6 iBGP Route Reflector
In-Reply-To: <20090710225434.dfaa72cb.kron@linkey.ru>
References: <20090710225434.dfaa72cb.kron@linkey.ru>
Message-ID: <00f901ca01f8$02fef160$0a00000a@nil.si>

> This scheme also doesn't work. I added next-hop-self on 
> rtr2_RR for both peers with rtr3 and rtr4.

I haven't been following this thread too closely, but it's worth mentioning
that the next-hop is not changed on reflected routes (even if you configure
next-hop-self on the neighbor). See Notes and Warnings at the end of this
section:

http://wiki.nil.com/BGP_route_reflectors#Route_Reflector_rules

Ivan
 
http://www.ioshints.info/about
http://blog.ioshints.info/

>  address-family ipv6
>   redistribute connected
>   no synchronization
>   neighbor 2001:1020:100::3 activate
>   neighbor 2001:1020:100::3 inherit peer-policy rr-clients-v6
>   neighbor 2001:1020:100::3 next-hop-self
>   neighbor 2001:1020:100::4 activate
>   neighbor 2001:1020:100::4 inherit peer-policy rr-clients-v6
>   neighbor 2001:1020:100::4 next-hop-self  exit-address-family
> 
> I tryed add route-map on out for change next-hop, but it doesn't help.
>  neighbor 2001:1020:100::4 route-map NextHopPE4 out  neighbor 
> 2001:1020:100::3 route-map NextHopPE3 out
> 
> route-map NextHopPE3 permit 10
>  set ipv6 next-hop 2001:1020:7000::1
> route-map NextHopPE4 permit 10
>  set ipv6 next-hop 2001:1020:8000::1
> 
> I think the problem in link-local address received from OSPFv3.
> With ipv4 addresses this scheme work.
> 
> --
> Alexandr Gurbo



From ip at ioshints.info  Sat Jul 11 03:21:33 2009
From: ip at ioshints.info (Ivan Pepelnjak)
Date: Sat, 11 Jul 2009 09:21:33 +0200
Subject: [c-nsp] Delay BGP peer session
In-Reply-To: <4A5829BA.8060002@rollernet.us>
References: <4A57EA0D.5000804@rollernet.us>
	<4A57EF6E.5000209@evaristesys.com><4A57F5A6.5070204@rollernet.us><Pine.LNX.4.61.0907102219491.6312@soloth.lewis.org>
	<4A5829BA.8060002@rollernet.us>
Message-ID: <00fa01ca01f8$38d08fb0$0a00000a@nil.si>

You'll find a lot of information about IP Event Dampening here:

http://www.nil.com/ipcorner/IncreaseStability/

I haven't tried it in the EBGP scenario ... Jon, thanks for the pointer.

Ivan
 
http://www.ioshints.info/about
http://blog.ioshints.info/

> >>>> Is there any way to force a delay on a BGP session from 
> >>>> establishing when a link comes up? Say, for example, if a link 
> >>>> flaps and fast-external-fallover takes it down we should wait X 
> >>>> minutes before trying to bring the session back up.
> >>>
> >>> I would guess that flap dampening would be the proper solution.
> >>>
> >>
> >> I don't think it can dampen the whole table and suppress 
> >> announcements, can it? I've never tried that.
> > 
> > I believe IP Event Dampening is the knob you seek.
> > 
> 
> Very interesting. I'll have to play around with that.
> 
> ~Seth
> 
> 


From jof at thejof.com  Sat Jul 11 05:14:25 2009
From: jof at thejof.com (Jonathan Lassoff)
Date: Sat, 11 Jul 2009 02:14:25 -0700
Subject: [c-nsp] Mac address flapping..
In-Reply-To: <490B0AB46362B947A2947D5CB5E7F2A105AE006704@exchange.esnet.com>
References: <490B0AB46362B947A2947D5CB5E7F2A105AE006700@exchange.esnet.com>
	<490B0AB46362B947A2947D5CB5E7F2A105AE006704@exchange.esnet.com>
Message-ID: <1247303558-sup-6684@sfo.thejof.com>

Excerpts from James Ashton's message of Fri Jul 10 10:48:13 -0700 2009:
> 
> As for them creating a loop locally, If I disable one of the ports facing them,
> the errors persist.  Them having a loop in their switch, if it only has a
> single connection to my network, shouldn't effect me.  Unless I am missing
> something..
> 
> Could their configuration actually effect my spanning tree if I am only running
> one link to them??

I would say it depends on the configuration of the edge port.
What if they hooked up something that starts spewing BPDUs at
a priority lower than your gear?

>From what you described, that doesn't sound like a problem in this case,
but it's something to consider.

From jof at thejof.com  Sat Jul 11 05:12:12 2009
From: jof at thejof.com (Jonathan Lassoff)
Date: Sat, 11 Jul 2009 02:12:12 -0700
Subject: [c-nsp] Mac address flapping..
In-Reply-To: <490B0AB46362B947A2947D5CB5E7F2A105AE006700@exchange.esnet.com>
References: <490B0AB46362B947A2947D5CB5E7F2A105AE006700@exchange.esnet.com>
Message-ID: <1247303141-sup-8493@sfo.thejof.com>

Excerpts from James Ashton's message of Fri Jul 10 08:56:40 -0700 2009:
> 
>        %MAC_MOVE-SP-4-NOTIF: Host 00d0.009e.2400 in vlan 42 is flapping between
> port Po1 and port Gi1/7
> 
> I see about 20 of these for this one vlan each minute.
> Spanning tree is not reconverging.  It hasn't had a topology change in over 48
> hours.
> HSRP has not changed state.
>
> 6509-b:
> VLAN0042
>   Spanning tree enabled protocol ieee
>   Root ID    Priority    24618
>              Address     00d0.00a7.f000
>              Cost        3
>              Port        1665 (Port-channel1)
>              Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
> 
>   Bridge ID  Priority    28714  (priority 28672 sys-id-ext 42)
>              Address     00d0.009e.2400

This is telling -- notice that one of the burned-in addresses on 6509-b
is the one from your log message.

20 times a minute?
HSRP's default hold timer is every 3 seconds -- 20 times a minute.

You also described Gi1/7 as going to 4506-b, right? I would investigate
why spanning tree isn't blocking one of the uplink ports, as it's
causing what sounds like a loop.

Perhaps check that there's something listed from a "show spanning-tree
blockedports".

Cheers,
jonathan

From jloiacon at csc.com  Sat Jul 11 10:33:59 2009
From: jloiacon at csc.com (Joe Loiacono)
Date: Sat, 11 Jul 2009 10:33:59 -0400
Subject: [c-nsp] Netflow Sampling
In-Reply-To: <B5CFB919B5EEF345969F51FAFE6360D50AD84B@GBLDCXMB10.emea.cbre.net>
References: <B5CFB919B5EEF345969F51FAFE6360D50AD81A@GBLDCXMB10.emea.cbre.net>	<h37fo2$5vk$1@ger.gmane.org>
	<B5CFB919B5EEF345969F51FAFE6360D50AD84B@GBLDCXMB10.emea.cbre.net>
Message-ID: <OF738707D9.53BC023B-ON852575F0.004FCD8C-852575F0.00500454@csc.com>

Netflow collectors generally are passive with respect to receiving netflow 
only. They do not poll the devices; The devices export according to their 
export timing parameters which generally winds up producing a steady 
stream of UDP netflow packets to the collector.

Joe.



"Oddiraju, Kiran @ London SMC" <Kiran.Oddiraju at cbre.com> 
Sent by: cisco-nsp-bounces at puck.nether.net
07/10/2009 11:26 AM

To
"David Freedman" <david.freedman at uk.clara.net>, 
<cisco-nsp at puck.nether.net>
cc

Subject
Re: [c-nsp] Netflow Sampling






Actually we want to increase the sampling interval on the collector to
see what's happening on a particular link. I don't know what is the
default sampling interval but we want to change it to something like
every minute.

Thanks David.

Regards,
Kiran

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of David Freedman
Sent: 10 July 2009 14:30
To: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Netflow Sampling

I didn't know sampling was available for this platform?
I don't believe it is.

Are you doing this to reduce load / storage on your collector?

David.


Oddiraju, Kiran @ London SMC wrote:
> Guys,
> 
> 
> 
> I am trying to configure Netflow sampling interval on a c1801 router
> (IOS version "c180x-broadband-mz.124-15.T6.bin"). I was able to enable
> Netflow globally and configured it on the interface as well. But I
can't
> setup sampling, it doesn't like the commands. What am I doing wrong?
> 
> 
> 
> Config
> 
> 
> 
> interface FastEthernet0
> 
>  ip address 10.15.255.50 255.255.255.252
> 
>  ip flow ingress
> 
>  ip route-cache flow
> 
>  speed 100
> 
>  full-duplex
> 
> !
> 
> 
> 
> ip flow-export source FastEthernet0
> 
> ip flow-export version 5
> 
> ip flow-export destination 10.13.246.50 2055
> 
> ip flow-export destination 10.15.246.66 2055
> 
> 
> 
> 
> 
> Netflow-Test(config-if)#ip route-cache flow sampled
> 
>                                             ^
> 
> % Invalid input detected at '^' marker.
> 
> 
> 
> Netflow-Test(config)#ip flow-sampling-mode packet-interval ?
> 
> % Unrecognized command
> 
> 
> 
> Many thanks,
> 
> Kiran
> 
> 
> CB Richard Ellis Limited, Registered Office: St Martin's Court, 
> 10 Paternoster Row, London, EC4M 7HP, registered in England and Wales
No. 3536032. 
> Regulated by the RICS and an appointed representative of CB Richard
Ellis 
> Indirect Investment Services Limited which is authorised and regulated
by the Financial Services Authority.
> 
> This communication is from CB Richard Ellis Limited or one of its 
> associated/subsidiary companies. This communication contains
information 
> which is confidential and may be privileged. If you are not the
intended recipient, 
> please contact the sender immediately. Any use of its contents is
strictly prohibited 
> and you must not copy, send or disclose it, or rely on its contents in
any way whatsoever. 
> Reasonable care has been taken to ensure that this communication 
> (and any attachments or hyperlinks contained within it) is free from
computer viruses. 
> No responsibility is accepted by CB Richard Ellis Limited or its
associated/subsidiary 
> companies and the recipient should carry out any appropriate virus
checks.
> 
> _______________________________________________
> cisco-nsp mailing 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/
CB Richard Ellis Limited, Registered Office: St Martin's Court, 
10 Paternoster Row, London, EC4M 7HP, registered in England and Wales No. 
3536032. 
Regulated by the RICS and an appointed representative of CB Richard Ellis 
Indirect Investment Services Limited which is authorised and regulated by 
the Financial Services Authority.

This communication is from CB Richard Ellis Limited or one of its 
associated/subsidiary companies. This communication contains information 
which is confidential and may be privileged. If you are not the intended 
recipient, 
please contact the sender immediately. Any use of its contents is strictly 
prohibited 
and you must not copy, send or disclose it, or rely on its contents in any 
way whatsoever. 
Reasonable care has been taken to ensure that this communication 
(and any attachments or hyperlinks contained within it) is free from 
computer viruses. 
No responsibility is accepted by CB Richard Ellis Limited or its 
associated/subsidiary 
companies and the recipient should carry out any appropriate virus checks.

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


From sforcejr at yahoo.com  Sat Jul 11 10:24:00 2009
From: sforcejr at yahoo.com (JAR Colmenares)
Date: Sat, 11 Jul 2009 07:24:00 -0700 (PDT)
Subject: [c-nsp] Access Lists -ACLs- for switches
Message-ID: <226185.12399.qm@web110402.mail.gq1.yahoo.com>

CISCO 3750 12.2(25) SEE2Cisco 2950 ?12.1.(22) EA2


We codevelop software with teams from other companies and they come to our site to do this. With these companies we have setup Lan to Lan tunnels. So when they come we allow them to connect to our Guest network. Then they VPN into their companies and connect to a particular host on our end. It does not seem the best way to me.?
I was thinking about letting them connect to our company LAN then configure ACLs in a switch, apply them ?to specific ports ?and allow them access only to an specific host on port 80 and 443.?
If it makes any difference I will throw these 2 scenarios in:
1- destination host and guest users connected physically to ports in the same switch
2- destination host ?and guest users connected in different switches uplinked ?with switches in between . I wonder it if is needed one set of ACLs on both switches or does it matter?
Thanks for your help
JAR?


      

From ml at kenweb.org  Sat Jul 11 13:19:29 2009
From: ml at kenweb.org (ML)
Date: Sat, 11 Jul 2009 13:19:29 -0400
Subject: [c-nsp] uRPF on ME3400
In-Reply-To: <383357750906020048r63eccb30u38b54e2ff1353b61@mail.gmail.com>
References: <4A2475D4.8000006@kenweb.org>
	<383357750906020048r63eccb30u38b54e2ff1353b61@mail.gmail.com>
Message-ID: <4A58C9A1.30009@kenweb.org>

Mateusz Blaszczyk wrote:
> 2009/6/2 ML <ml at kenweb.org>:
>   
>> With the IOS available today it's apparent that uRPF is only available in
>> VRFs on the ME3400.
>>
>> Like some people I've run across, I want uRPF not in a VRF.  Has anyone
>> found a workaround to this limitation?
>>     
>
> if you are running vrf-lite i could create vrf global and put any
> interface in that vrf.
>
> BRs,
>
> -mat
>   

I finally had an opportunity attempt implementing uRPF.  I made my VRF 
applied to interfaces tried to enable uRPF and...

% ip verify configuration not supported on interface Fa0/23
 - verification not supported by hardware


It's clear this feature is a tease from Cisco. I haven't been able to 
find anyone or any real world reference to uRPF on the ME3400.

I'm going to ask the list now.  Has anyone gotten this feature to work? 
If so please reply with any configuration if you can.

Thanks




From adrian.minta at gmail.com  Sat Jul 11 14:28:36 2009
From: adrian.minta at gmail.com (Adrian Minta)
Date: Sat, 11 Jul 2009 21:28:36 +0300
Subject: [c-nsp] IGMP snooping ME6500
Message-ID: <4A58D9D4.8030205@gmail.com>

Hi,
I have a problem with Layer 2 multicast traffic on ME6500. The switch 
floods all redundant links with multicast traffic, much like a dumb 
switch. On all the other small platforms igmp snooping works very good 
out of the box: Cat2950, Cat3550, ME3400.

A friend of mine have the same symptom on 7600. My software version is 
Version 12.2(33)SXH3a, don't know his version.

Has anyone encounter the same problem ? Does anybody know a valid solution ?

-- 
Best regards,
Adrian Minta




From steve at ibctech.ca  Sat Jul 11 19:08:17 2009
From: steve at ibctech.ca (Steve Bertrand)
Date: Sat, 11 Jul 2009 19:08:17 -0400
Subject: [c-nsp] IPv6 iBGP Route Reflector
In-Reply-To: <00f901ca01f8$02fef160$0a00000a@nil.si>
References: <20090710225434.dfaa72cb.kron@linkey.ru>
	<00f901ca01f8$02fef160$0a00000a@nil.si>
Message-ID: <4A591B61.5030604@ibctech.ca>

Ivan Pepelnjak wrote:
>> This scheme also doesn't work. I added next-hop-self on 
>> rtr2_RR for both peers with rtr3 and rtr4.
> 
> I haven't been following this thread too closely, but it's worth mentioning
> that the next-hop is not changed on reflected routes (even if you configure
> next-hop-self on the neighbor). See Notes and Warnings at the end of this
> section:
> 
> http://wiki.nil.com/BGP_route_reflectors#Route_Reflector_rules

...*hanging head*...

I _should_ have known that, but don't utilize RRs very often.

Over the weekend, I'll find out how the OP can fix the routes, and
moreover, why they are broken in the first place.

Steve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3233 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090711/a171bdcc/attachment.bin>

From jashton at esnet.com  Sun Jul 12 01:06:57 2009
From: jashton at esnet.com (James Ashton)
Date: Sun, 12 Jul 2009 01:06:57 -0400
Subject: [c-nsp] Mac address flapping..
In-Reply-To: <1247303141-sup-8493@sfo.thejof.com>
References: <490B0AB46362B947A2947D5CB5E7F2A105AE006700@exchange.esnet.com>,
	<1247303141-sup-8493@sfo.thejof.com>
Message-ID: <490B0AB46362B947A2947D5CB5E7F2A105AE00E79C@exchange.esnet.com>

On both 4506s I see that one of the upl;ink ports is in blocking mode.

On 4506-a is it port g1/2
On 4506-b is it port g1/1

There is no blocking going on for this vlan on the 6509s.  But I wouldnt expect that with the 4506s blocking.


As got the timers for HSRP matching the log frequency..  I agree... But my confusion is that HSRP isnt flipping between routers..   So are the spanning tree Hello packets causing this??   If so, Why on this one vlan out of over 120 configured exactily the same???


This is the physical port config of the 4506s..    All 4506 uplink ports ahve the same config:

interface GigabitEthernet1/1
 description dotiq  trunk to fi1/8 core switch
 switchport trunk encapsulation dot1q
 switchport trunk native vlan 999
 switchport trunk allowed vlan 2-999
 switchport mode trunk
end





This is the same for one of the 6509 ports:

interface GigabitEthernet1/7
 description dot1q trunk to int gig 1/1 on as1
 switchport
 switchport access vlan 999
 switchport trunk encapsulation dot1q
 switchport trunk native vlan 999
 switchport trunk allowed vlan 2-995,998,999
 switchport mode trunk
 no ip address
 hold-queue 3000 in
end



Thanks for the help.  This doesnt appear to be effecting the customer on this vlan..  But it is truly vexing me.



James


________________________________________
From: Jonathan Lassoff [jof at thejof.com]
Sent: Saturday, July 11, 2009 5:12 AM
To: James Ashton
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Mac address flapping..

Excerpts from James Ashton's message of Fri Jul 10 08:56:40 -0700 2009:
>
>        %MAC_MOVE-SP-4-NOTIF: Host 00d0.009e.2400 in vlan 42 is flapping between
> port Po1 and port Gi1/7
>
> I see about 20 of these for this one vlan each minute.
> Spanning tree is not reconverging.  It hasn't had a topology change in over 48
> hours.
> HSRP has not changed state.
>
> 6509-b:
> VLAN0042
>   Spanning tree enabled protocol ieee
>   Root ID    Priority    24618
>              Address     00d0.00a7.f000
>              Cost        3
>              Port        1665 (Port-channel1)
>              Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
>
>   Bridge ID  Priority    28714  (priority 28672 sys-id-ext 42)
>              Address     00d0.009e.2400

This is telling -- notice that one of the burned-in addresses on 6509-b
is the one from your log message.

20 times a minute?
HSRP's default hold timer is every 3 seconds -- 20 times a minute.

You also described Gi1/7 as going to 4506-b, right? I would investigate
why spanning tree isn't blocking one of the uplink ports, as it's
causing what sounds like a loop.

Perhaps check that there's something listed from a "show spanning-tree
blockedports".

Cheers,
jonathan

From jashton at esnet.com  Sun Jul 12 01:07:18 2009
From: jashton at esnet.com (James Ashton)
Date: Sun, 12 Jul 2009 01:07:18 -0400
Subject: [c-nsp] Mac address flapping..
In-Reply-To: <4288131ED5E3024C9CD4782CECCAD2C7065D3843@LMC-MAIL2.exempla.org>
References: <490B0AB46362B947A2947D5CB5E7F2A105AE006700@exchange.esnet.com><490B0AB46362B947A2947D5CB5E7F2A105AE006704@exchange.esnet.com><20090710183841.GA32154@lboro.ac.uk>
	<490B0AB46362B947A2947D5CB5E7F2A105AE00670E@exchange.esnet.com>,
	<4288131ED5E3024C9CD4782CECCAD2C7065D3843@LMC-MAIL2.exempla.org>
Message-ID: <490B0AB46362B947A2947D5CB5E7F2A105AE00E79D@exchange.esnet.com>

Actualy,
 My 2 4506s are plugged into the customers, Flat, Default configed, Cisco 3548-XL-EN switch.

His servers hang off from that switch.



James

________________________________________
From: Matlock, Kenneth L [MatlockK at exempla.org]
Sent: Friday, July 10, 2009 3:12 PM
To: James Ashton; A.L.M.Buxey at lboro.ac.uk
Cc: cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] Mac address flapping..

I assume the server housing that MAC has 2 NICs, one plugged into
4506-a, and the other in 4506-b?

I've seen it before during a server reboot where it has multiple NICs
that the server guys have configured a virtual MAC, and that MAC bounces
between it's 2 ports a few times during OS startup, causing errors
almost exactly like that. The switch sees the MAC on one port, then the
server uses that MAC on the other port, etc.

I'd see if those error times coincide with reboots of the servers.

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 James Ashton
Sent: Friday, July 10, 2009 12:54 PM
To: A.L.M.Buxey at lboro.ac.uk
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Mac address flapping..

The root bridge is 6509-a.


The one that is showing these log errors.

James

-----Original Message-----
From: A.L.M.Buxey at lboro.ac.uk [mailto:A.L.M.Buxey at lboro.ac.uk]
Sent: Friday, July 10, 2009 2:39 PM
To: James Ashton
Cc: cisco-nsp at puck.nether.net
Subject: Re: Mac address flapping..

Hi,

> Alan,
>  Po1 is the connection from 6509-a to 6509-b.
>  G1/7 goes to port G1/1 on 4506-a.
>  G1/8 goes to G1/1 on 4506-b.

what is the root bridge for vlan 42?

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 jashton at esnet.com  Sun Jul 12 01:09:05 2009
From: jashton at esnet.com (James Ashton)
Date: Sun, 12 Jul 2009 01:09:05 -0400
Subject: [c-nsp] Mac address flapping..
In-Reply-To: <383357750907101219y6d8051b3g8f0bed7697a1eae7@mail.gmail.com>
References: <490B0AB46362B947A2947D5CB5E7F2A105AE006700@exchange.esnet.com>,
	<383357750907101219y6d8051b3g8f0bed7697a1eae7@mail.gmail.com>
Message-ID: <490B0AB46362B947A2947D5CB5E7F2A105AE00E79E@exchange.esnet.com>

I have looked at all the port configs in question.    No forgotten stuff that I can see.

I am willing to go with the loop idea..  But I dont get any loop errors.   I dont get any Mac Move errors other than for this HSRP Mac Address, and over 120 other vlans on  these same ports arent having this issue.


But if it were a loop, how would I find it and fix it..   I ahve gone through every method I know of and allt he Cisco troubleshooting docs.   I can feel that I am missing something here, But I just cant think of what.

James

________________________________________
From: Mateusz Blaszczyk [blahu77 at gmail.com]
Sent: Friday, July 10, 2009 3:19 PM
To: James Ashton
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Mac address flapping..

James,

. (I have a pair doing redundant gateways for a DataCenter network)
>
>       %MAC_MOVE-SP-4-NOTIF: Host 00d0.009e.2400 in vlan 42 is flapping between port Po1 and port Gi1/7
>
> I see about 20 of these for this one vlan each minute.

the mac is 6509-b and pps==20/minute is probably HSRP hello packet
from Vlan42 on 6509-b.
if there are no topo changes in stp there must be a unnoticed L2 loop,
either forgotten portfast or bpdu filtering between 6509-a,-b and
4506-a.

perhaps try to disconnect the customer completely during a maintenance
window and double check all your connections.

Best Regards,

-mat

From eng_mssk at hotmail.com  Sun Jul 12 04:28:13 2009
From: eng_mssk at hotmail.com (Mohammad Khalil)
Date: Sun, 12 Jul 2009 11:28:13 +0300
Subject: [c-nsp] backup cpe
Message-ID: <BLU102-W21BFAE89E388EEAA3A85EEFA250@phx.gbl>


hi all 
i have a router with 2 ethernet interfaces
one is connected to a microwave device (Leased Line) and the other is connected to a WiMAX CPE
now if the leased line went down 
how im going to activate the cpe automatically ??
there is no dialing in the CPE it obtain a DHCP ip address from the BS once the LOS is there 

Thanks 

_________________________________________________________________
More than messages?check out the rest of the Windows Live?.
http://www.microsoft.com/windows/windowslive/

From avayner at cisco.com  Sun Jul 12 06:13:10 2009
From: avayner at cisco.com (Arie Vayner (avayner))
Date: Sun, 12 Jul 2009 12:13:10 +0200
Subject: [c-nsp] backup cpe
In-Reply-To: <BLU102-W21BFAE89E388EEAA3A85EEFA250@phx.gbl>
References: <BLU102-W21BFAE89E388EEAA3A85EEFA250@phx.gbl>
Message-ID: <78C984F8939D424697B15E4B1C1BB3D7F2E62E@xmb-ams-331.emea.cisco.com>

Mohammad,

Take a look here:

Enhanced Object Tracking
http://www.cisco.com/en/US/docs/ios/12_2t/12_2t15/feature/guide/fthsrptk
.html

Reliable Static Routing Backup Using Object Tracking
http://www.cisco.com/en/US/docs/ios/12_3/12_3x/12_3xe/feature/guide/dbac
kupx.html

Embedded Event Manager (EEM)
http://www.cisco.com/en/US/products/ps6815/products_ios_protocol_group_h
ome.html


I think this should give you some ideas...

Arie

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Mohammad Khalil
Sent: Sunday, July 12, 2009 11:28
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] backup cpe


hi all 
i have a router with 2 ethernet interfaces
one is connected to a microwave device (Leased Line) and the other is
connected to a WiMAX CPE
now if the leased line went down 
how im going to activate the cpe automatically ??
there is no dialing in the CPE it obtain a DHCP ip address from the BS
once the LOS is there 

Thanks 

_________________________________________________________________
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 A.L.M.Buxey at lboro.ac.uk  Sun Jul 12 06:20:03 2009
From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk)
Date: Sun, 12 Jul 2009 11:20:03 +0100
Subject: [c-nsp] Mac address flapping..
In-Reply-To: <490B0AB46362B947A2947D5CB5E7F2A105AE00E79D@exchange.esnet.com>
References: <4288131ED5E3024C9CD4782CECCAD2C7065D3843@LMC-MAIL2.exempla.org>
	<490B0AB46362B947A2947D5CB5E7F2A105AE00E79D@exchange.esnet.com>
Message-ID: <20090712102003.GA15723@lboro.ac.uk>

Hi,
> Actualy,
>  My 2 4506s are plugged into the customers, Flat, Default configed, Cisco 3548-XL-EN switch.

are they in the same VTP domain or having trunks fed to them?
those switches are very very old and weak in terms of numbers
of VLANs - especially in PVST mode etc

do you handle the VLANs on the 6506 devices (ie they are the routers?)
if so, have you checked the settings for VLAN 42 - esp. with regard to
HRSRP?


alan

From ip at ioshints.info  Sun Jul 12 07:05:53 2009
From: ip at ioshints.info (Ivan Pepelnjak)
Date: Sun, 12 Jul 2009 13:05:53 +0200
Subject: [c-nsp] backup cpe
In-Reply-To: <78C984F8939D424697B15E4B1C1BB3D7F2E62E@xmb-ams-331.emea.cisco.com>
References: <BLU102-W21BFAE89E388EEAA3A85EEFA250@phx.gbl>
	<78C984F8939D424697B15E4B1C1BB3D7F2E62E@xmb-ams-331.emea.cisco.com>
Message-ID: <003301ca02e0$ba1b4680$0a00000a@nil.si>

More specifically ... SOHO multihoming solutions (includes object tracking
and reliable static routing)

http://wiki.nil.com/Small_site_multihoming

More reliable static routing tricks:

http://blog.ioshints.info/search?q=reliable+static

More DHCP-related tricks:

http://blog.ioshints.info/search/label/DHCP

EEM applet that enables/disables an interface (just tie it to a track
object, not a timer):

http://wiki.nil.com/Time-based_wireless_interface_activity

More sample EEM applets:

http://wiki.nil.com/Category:EEM_applet

More EEM usage guidelines and tips:

http://blog.ioshints.info/search/label/EEM

Ufff ... I'm obviously writing too much :)
Ivan
 
http://www.ioshints.info/about
http://blog.ioshints.info/


> -----Original Message-----
> From: Arie Vayner (avayner) [mailto:avayner at cisco.com] 
> Sent: Sunday, July 12, 2009 12:13 PM
> To: Mohammad Khalil; cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] backup cpe
> 
> Mohammad,
> 
> Take a look here:
> 
> Enhanced Object Tracking
> http://www.cisco.com/en/US/docs/ios/12_2t/12_2t15/feature/guid
> e/fthsrptk
> .html
> 
> Reliable Static Routing Backup Using Object Tracking 
> http://www.cisco.com/en/US/docs/ios/12_3/12_3x/12_3xe/feature/
> guide/dbac
> kupx.html
> 
> Embedded Event Manager (EEM)
> http://www.cisco.com/en/US/products/ps6815/products_ios_protoc
> ol_group_h
> ome.html
> 
> 
> I think this should give you some ideas...
> 
> Arie
> 
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of 
> Mohammad Khalil
> Sent: Sunday, July 12, 2009 11:28
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] backup cpe
> 
> 
> hi all
> i have a router with 2 ethernet interfaces one is connected 
> to a microwave device (Leased Line) and the other is 
> connected to a WiMAX CPE now if the leased line went down how 
> im going to activate the cpe automatically ??
> there is no dialing in the CPE it obtain a DHCP ip address 
> from the BS once the LOS is there 
> 
> Thanks 
> 
> _________________________________________________________________
> 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 p.mayers at imperial.ac.uk  Sun Jul 12 10:11:47 2009
From: p.mayers at imperial.ac.uk (Phil Mayers)
Date: Sun, 12 Jul 2009 15:11:47 +0100
Subject: [c-nsp] IGMP snooping ME6500
In-Reply-To: <4A58D9D4.8030205@gmail.com>
References: <4A58D9D4.8030205@gmail.com>
Message-ID: <20090712141147.GA31466@wildfire.net.ic.ac.uk>

On Sat, Jul 11, 2009 at 07:28:36PM +0100, Adrian Minta wrote:
>Hi,
>I have a problem with Layer 2 multicast traffic on ME6500. The switch 
>floods all redundant links with multicast traffic, much like a dumb 
>switch. On all the other small platforms igmp snooping works very good 
>out of the box: Cat2950, Cat3550, ME3400.
>
>A friend of mine have the same symptom on 7600. My software version is 
>Version 12.2(33)SXH3a, don't know his version.
>
>Has anyone encounter the same problem ? Does anybody know a valid solution ?

Config? Software version?

If you don't already have it, try creating an un-numbered SVI e.g.:

vlan 200
  name multicast
int Vlan200
  no ip address

I seem to recall references to this being required for some multicast 
functionality on some versions of 6500/7600 IOS


From p.mayers at imperial.ac.uk  Sun Jul 12 10:16:03 2009
From: p.mayers at imperial.ac.uk (Phil Mayers)
Date: Sun, 12 Jul 2009 15:16:03 +0100
Subject: [c-nsp] Mac address flapping..
In-Reply-To: <490B0AB46362B947A2947D5CB5E7F2A105AE00E79E@exchange.esnet.com>
References: <383357750907101219y6d8051b3g8f0bed7697a1eae7@mail.gmail.com>
	<490B0AB46362B947A2947D5CB5E7F2A105AE00E79E@exchange.esnet.com>
Message-ID: <20090712141603.GB31466@wildfire.net.ic.ac.uk>

On Sun, Jul 12, 2009 at 06:09:05AM +0100, James Ashton wrote:
>I have looked at all the port configs in question.    No forgotten stuff that I can see.
>
>I am willing to go with the loop idea..  But I dont get any loop errors.   I dont get any Mac Move errors other than for this HSRP Mac Address, and over 120 other vlans on  these same ports arent having this issue.
>
>
>But if it were a loop, how would I find it and fix it..   I ahve gone through every method I know of and allt he Cisco troubleshooting docs.   I can feel that I am missing something here, But I just cant think of what.
>

Next step is to SPAN the ports concerned and confirm "for real" what 
packets are causing the mac move notify, and see what else is there that 
shouldn't be

It's possible the loop isn't a "full" one; e.g. if they've looped subnet 
200 to 201, via a firewall that's dropping non-IP packets, then STP 
wouldn't complain, and you wouldn't get a broadcast storm, but you would 
get this kind of problem.

From thomas at habets.pp.se  Sun Jul 12 09:56:12 2009
From: thomas at habets.pp.se (Thomas Habets)
Date: Sun, 12 Jul 2009 15:56:12 +0200 (CEST)
Subject: [c-nsp] Mac address flapping..
In-Reply-To: <490B0AB46362B947A2947D5CB5E7F2A105AE00E79E@exchange.esnet.com>
References: <490B0AB46362B947A2947D5CB5E7F2A105AE006700@exchange.esnet.com>,
	<383357750907101219y6d8051b3g8f0bed7697a1eae7@mail.gmail.com>
	<490B0AB46362B947A2947D5CB5E7F2A105AE00E79E@exchange.esnet.com>
Message-ID: <alpine.DEB.1.10.0907121554090.6687@puck.crap.retrofitta.se>

On Sun, 12 Jul 2009, James Ashton wrote:
> over 120 other vlans on  these same ports arent having this
> issue.

Have you checked that you aren't running into spanning tree limits?

6500/7600 have two limits, virtual ports and active logical ports.

The short story is:
1) check if "show spanning-tree summary total" is more than 10000.
2) check if "show vlan virtual-port" is more than 1800 per slot.

http://blog.habets.pp.se/2009/06/Spanning-tree-limits
http://www.cisco.com/en/US/solutions/ns340/ns394/ns50/net_design_guidance0900aecd806fe4bb.pdf

---------
typedef struct me_s {
   char name[]      = { "Thomas Habets" };
   char email[]     = { "thomas at habets.pp.se" };
   char kernel[]    = { "Linux" };
   char *pgpKey[]   = { "http://www.habets.pp.se/pubkey.txt" };
   char pgp[] = { "A8A3 D1DD 4AE0 8467 7FDE  0945 286A E90A AD48 E854" };
   char coolcmd[]   = { "echo '. ./_&. ./_'>_;. ./_" };
} me_t;

From jashton at esnet.com  Sun Jul 12 11:39:41 2009
From: jashton at esnet.com (James Ashton)
Date: Sun, 12 Jul 2009 11:39:41 -0400
Subject: [c-nsp] Mac address flapping..
In-Reply-To: <20090712102003.GA15723@lboro.ac.uk>
References: <4288131ED5E3024C9CD4782CECCAD2C7065D3843@LMC-MAIL2.exempla.org>
	<490B0AB46362B947A2947D5CB5E7F2A105AE00E79D@exchange.esnet.com>,
	<20090712102003.GA15723@lboro.ac.uk>
Message-ID: <490B0AB46362B947A2947D5CB5E7F2A105AE00E79F@exchange.esnet.com>

Alan,
 The 3548 is not part of the VTP.  And I am not passing it a trunk.  Just the one vlan.


and the 6509s do handle the VLANs.   But there are no tweeks to HSRP.  Just the default settings like all the others.

________________________________________
From: A.L.M.Buxey at lboro.ac.uk [A.L.M.Buxey at lboro.ac.uk]
Sent: Sunday, July 12, 2009 6:20 AM
To: James Ashton
Cc: Matlock, Kenneth L; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Mac address flapping..

Hi,
> Actualy,
>  My 2 4506s are plugged into the customers, Flat, Default configed, Cisco 3548-XL-EN switch.

are they in the same VTP domain or having trunks fed to them?
those switches are very very old and weak in terms of numbers
of VLANs - especially in PVST mode etc

do you handle the VLANs on the 6506 devices (ie they are the routers?)
if so, have you checked the settings for VLAN 42 - esp. with regard to
HRSRP?


alan

From jashton at esnet.com  Sun Jul 12 11:57:01 2009
From: jashton at esnet.com (James Ashton)
Date: Sun, 12 Jul 2009 11:57:01 -0400
Subject: [c-nsp] Mac address flapping..
In-Reply-To: <alpine.DEB.1.10.0907121554090.6687@puck.crap.retrofitta.se>
References: <490B0AB46362B947A2947D5CB5E7F2A105AE006700@exchange.esnet.com>,
	<383357750907101219y6d8051b3g8f0bed7697a1eae7@mail.gmail.com>
	<490B0AB46362B947A2947D5CB5E7F2A105AE00E79E@exchange.esnet.com>,
	<alpine.DEB.1.10.0907121554090.6687@puck.crap.retrofitta.se>
Message-ID: <490B0AB46362B947A2947D5CB5E7F2A105AE00E7A0@exchange.esnet.com>

Thomas
Here is the output.   Doesn't look like I have hit any limits.



>From 6509-a

=============================================
core-tpa001#sh spanning-tree summary totals 
Switch is in pvst mode
Root bridge for: VLAN0002-VLAN0065, VLAN0074, VLAN0084, VLAN0088, VLAN0093
  VLAN0098-VLAN0100, VLAN0996-VLAN0998
EtherChannel misconfig guard is enabled
Extended system ID           is enabled
Portfast Default             is disabled
PortFast BPDU Guard Default  is disabled
Portfast BPDU Filter Default is disabled
Loopguard Default            is enabled
UplinkFast                   is disabled
BackboneFast                 is disabled
Pathcost method used is short
Name                   Blocking Listening Learning Forwarding STP Active
---------------------- -------- --------- -------- ---------- ----------
120 vlans                    2         0        0        592        594




>From 4506-a

core-tpa001#show vlan virtual-port
Slot 1
-------
Total slot virtual ports 710
Slot 3
-------
Total slot virtual ports 357
Slot 5
-------
Total slot virtual ports 1
Total chassis virtual ports 1068 


James

________________________________________
From: Thomas Habets [thomas at habets.pp.se]
Sent: Sunday, July 12, 2009 9:56 AM
To: James Ashton
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Mac address flapping..

On Sun, 12 Jul 2009, James Ashton wrote:
> over 120 other vlans on  these same ports arent having this
> issue.

Have you checked that you aren't running into spanning tree limits?

6500/7600 have two limits, virtual ports and active logical ports.

The short story is:
1) check if "show spanning-tree summary total" is more than 10000.
2) check if "show vlan virtual-port" is more than 1800 per slot.

http://blog.habets.pp.se/2009/06/Spanning-tree-limits
http://www.cisco.com/en/US/solutions/ns340/ns394/ns50/net_design_guidance0900aecd806fe4bb.pdf

---------
typedef struct me_s {
   char name[]      = { "Thomas Habets" };
   char email[]     = { "thomas at habets.pp.se" };
   char kernel[]    = { "Linux" };
   char *pgpKey[]   = { "http://www.habets.pp.se/pubkey.txt" };
   char pgp[] = { "A8A3 D1DD 4AE0 8467 7FDE  0945 286A E90A AD48 E854" };
   char coolcmd[]   = { "echo '. ./_&. ./_'>_;. ./_" };
} me_t;

From adrian.minta at gmail.com  Sun Jul 12 13:46:47 2009
From: adrian.minta at gmail.com (Adrian Minta)
Date: Sun, 12 Jul 2009 20:46:47 +0300
Subject: [c-nsp] IGMP snooping ME6500
In-Reply-To: <20090712141147.GA31466@wildfire.net.ic.ac.uk>
References: <4A58D9D4.8030205@gmail.com>
	<20090712141147.GA31466@wildfire.net.ic.ac.uk>
Message-ID: <4A5A2187.3050303@gmail.com>

Phil Mayers wrote:
>
> Config? Software version?
>
> If you don't already have it, try creating an un-numbered SVI e.g.:
>
> vlan 200
>  name multicast
> int Vlan200
>  no ip address
>
> I seem to recall references to this being required for some multicast 
> functionality on some versions of 6500/7600 IOS
>
>
Seems weird, but I will give it a try !

-- 
Best regards,
Adrian Minta



From tstevens at cisco.com  Sun Jul 12 14:21:16 2009
From: tstevens at cisco.com (Tim Stevenson)
Date: Sun, 12 Jul 2009 11:21:16 -0700
Subject: [c-nsp] IGMP snooping ME6500
In-Reply-To: <4A5A2187.3050303@gmail.com>
References: <4A58D9D4.8030205@gmail.com>
	<20090712141147.GA31466@wildfire.net.ic.ac.uk>
	<4A5A2187.3050303@gmail.com>
Message-ID: <200907121821.n6CILLVV013502@sj-core-1.cisco.com>

That's not really the critical thing, so much as - you need an IGMP 
querier active in the VLAN in order for snooping to work 
correctly/reliably. Some applications may behave fine without; others 
won't. The key is periodic joins from the hosts are required to 
maintain membership state for snooping. The querier ensures that happens.

So what you really need is an SVI *with* an IP address for that vlan, 
and then enable igmp snooping querier for that vlan. The configured 
IP is used to source queries. The SVI in this case can actually be 
shutdown, it doesn't really matter.

The config is like:
int vlan 200
  ip add 10.1.1.1/24
  ip igmp snooping querier
  shut

The other option is to just enable PIM on the (admin up) SVI in the 
vlan, but you may not want to do that, depends on the network design.

int vlan 200
  ip add 10.1.1.1/24
  ip pim sparse
  no shut

HTH,
Tim



At 10:46 AM 7/12/2009, Adrian Minta remarked:

>Phil Mayers wrote:
> >
> > Config? Software version?
> >
> > If you don't already have it, try creating an un-numbered SVI e.g.:
> >
> > vlan 200
> >  name multicast
> > int Vlan200
> >  no ip address
> >
> > I seem to recall references to this being required for some multicast
> > functionality on some versions of 6500/7600 IOS
> >
> >
>Seems weird, but I will give it a try !
>
>--
>Best regards,
>Adrian Minta
>
>
>_______________________________________________
>cisco-nsp mailing list  cisco-nsp at puck.nether.net
><https://puck.nether.net/mailman/listinfo/cisco-nsp>https://puck.nether.net/mailman/listinfo/cisco-nsp
>archive at 
><http://puck.nether.net/pipermail/cisco-nsp/>http://puck.nether.net/pipermail/cisco-nsp/




Tim Stevenson, tstevens at cisco.com
Routing & Switching CCIE #5561
Technical Marketing Engineer, Cisco Nexus 7000
Cisco - http://www.cisco.com
IP Phone: 408-526-6759
********************************************************
The contents of this message may be *Cisco Confidential*
and are intended for the specified recipients only.

From adrian.minta at gmail.com  Sun Jul 12 14:40:51 2009
From: adrian.minta at gmail.com (Adrian Minta)
Date: Sun, 12 Jul 2009 21:40:51 +0300
Subject: [c-nsp] IGMP snooping ME6500
In-Reply-To: <200907121821.n6CILLVV013502@sj-core-1.cisco.com>
References: <4A58D9D4.8030205@gmail.com>
	<20090712141147.GA31466@wildfire.net.ic.ac.uk>
	<4A5A2187.3050303@gmail.com>
	<200907121821.n6CILLVV013502@sj-core-1.cisco.com>
Message-ID: <4A5A2E33.3080902@gmail.com>

Tim Stevenson wrote:
> That's not really the critical thing, so much as - you need an IGMP 
> querier active in the VLAN in order for snooping to work 
> correctly/reliably. Some applications may behave fine without; others 
> won't. The key is periodic joins from the hosts are required to 
> maintain membership state for snooping. The querier ensures that happens.
>
> So what you really need is an SVI *with* an IP address for that vlan, 
> and then enable igmp snooping querier for that vlan. The configured IP 
> is used to source queries. The SVI in this case can actually be 
> shutdown, it doesn't really matter.
>
> The config is like:
> int vlan 200
>  ip add 10.1.1.1/24
>  ip igmp snooping querier
>  shut
>
> The other option is to just enable PIM on the (admin up) SVI in the 
> vlan, but you may not want to do that, depends on the network design.
>
> int vlan 200
>  ip add 10.1.1.1/24
>  ip pim sparse
>  no shut
>
> HTH,
> Tim
>
Creating an unnumbered interface didn't seems to work. Now I am trying 
your solution, the one with "ip igmp snooping querier". I don't want to 
involve the switches in any multicast routing.

-- 
Best regards,
Adrian Minta




From ml at kenweb.org  Sun Jul 12 15:12:46 2009
From: ml at kenweb.org (ML)
Date: Sun, 12 Jul 2009 15:12:46 -0400
Subject: [c-nsp] IGMP snooping ME6500
In-Reply-To: <4A5A2E33.3080902@gmail.com>
References: <4A58D9D4.8030205@gmail.com>	<20090712141147.GA31466@wildfire.net.ic.ac.uk>	<4A5A2187.3050303@gmail.com>	<200907121821.n6CILLVV013502@sj-core-1.cisco.com>
	<4A5A2E33.3080902@gmail.com>
Message-ID: <4A5A35AE.2080801@kenweb.org>

Adrian Minta wrote:
> Tim Stevenson wrote:
>> That's not really the critical thing, so much as - you need an IGMP 
>> querier active in the VLAN in order for snooping to work 
>> correctly/reliably. Some applications may behave fine without; others 
>> won't. The key is periodic joins from the hosts are required to 
>> maintain membership state for snooping. The querier ensures that happens.
>>
>> So what you really need is an SVI *with* an IP address for that vlan, 
>> and then enable igmp snooping querier for that vlan. The configured IP 
>> is used to source queries. The SVI in this case can actually be 
>> shutdown, it doesn't really matter.
>>
>> The config is like:
>> int vlan 200
>>  ip add 10.1.1.1/24
>>  ip igmp snooping querier
>>  shut
>>
>> The other option is to just enable PIM on the (admin up) SVI in the 
>> vlan, but you may not want to do that, depends on the network design.
>>
>> int vlan 200
>>  ip add 10.1.1.1/24
>>  ip pim sparse
>>  no shut
>>
>> HTH,
>> Tim
>>
> Creating an unnumbered interface didn't seems to work. Now I am trying 
> your solution, the one with "ip igmp snooping querier". I don't want to 
> involve the switches in any multicast routing.
> 

Normally I just enable PIM on the SVI and IGMP snooping for the VLAN.
No traffic gets flooded unnecessarily.



From blahu77 at gmail.com  Sun Jul 12 15:43:24 2009
From: blahu77 at gmail.com (Mateusz Blaszczyk)
Date: Sun, 12 Jul 2009 20:43:24 +0100
Subject: [c-nsp] Mac address flapping..
In-Reply-To: <490B0AB46362B947A2947D5CB5E7F2A105AE00E7A0@exchange.esnet.com>
References: <490B0AB46362B947A2947D5CB5E7F2A105AE006700@exchange.esnet.com> 
	<383357750907101219y6d8051b3g8f0bed7697a1eae7@mail.gmail.com> 
	<490B0AB46362B947A2947D5CB5E7F2A105AE00E79E@exchange.esnet.com> 
	<alpine.DEB.1.10.0907121554090.6687@puck.crap.retrofitta.se> 
	<490B0AB46362B947A2947D5CB5E7F2A105AE00E7A0@exchange.esnet.com>
Message-ID: <383357750907121243y39005f24i2a871d9e1d367915@mail.gmail.com>

James,
did you try to clear the arp table to force some broadcast traffic?
or ping broadcast IP for the vlan?
and see if it triggers more mac flapping?
not that it would help at all...

it is buffling.
Another thing... try to reconfigure SVIs... or even use another VLAN

I think we run out of guns here...

Best Regards,

-mat

2009/7/12 James Ashton <jashton at esnet.com>:
> Thomas
> Here is the output. ? Doesn't look like I have hit any limits.
>
>
>
> >From 6509-a
>
> =============================================
> core-tpa001#sh spanning-tree summary totals
> Switch is in pvst mode
> Root bridge for: VLAN0002-VLAN0065, VLAN0074, VLAN0084, VLAN0088, VLAN0093
> ?VLAN0098-VLAN0100, VLAN0996-VLAN0998
> EtherChannel misconfig guard is enabled
> Extended system ID ? ? ? ? ? is enabled
> Portfast Default ? ? ? ? ? ? is disabled
> PortFast BPDU Guard Default ?is disabled
> Portfast BPDU Filter Default is disabled
> Loopguard Default ? ? ? ? ? ?is enabled
> UplinkFast ? ? ? ? ? ? ? ? ? is disabled
> BackboneFast ? ? ? ? ? ? ? ? is disabled
> Pathcost method used is short
> Name ? ? ? ? ? ? ? ? ? Blocking Listening Learning Forwarding STP Active
> ---------------------- -------- --------- -------- ---------- ----------
> 120 vlans ? ? ? ? ? ? ? ? ? ?2 ? ? ? ? 0 ? ? ? ?0 ? ? ? ?592 ? ? ? ?594
>
>
>
>
> >From 4506-a
>
> core-tpa001#show vlan virtual-port
> Slot 1
> -------
> Total slot virtual ports 710
> Slot 3
> -------
> Total slot virtual ports 357
> Slot 5
> -------
> Total slot virtual ports 1
> Total chassis virtual ports 1068
>
>
> James
>
> ________________________________________
> From: Thomas Habets [thomas at habets.pp.se]
> Sent: Sunday, July 12, 2009 9:56 AM
> To: James Ashton
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] Mac address flapping..
>
> On Sun, 12 Jul 2009, James Ashton wrote:
>> over 120 other vlans on ?these same ports arent having this
>> issue.
>
> Have you checked that you aren't running into spanning tree limits?
>
> 6500/7600 have two limits, virtual ports and active logical ports.
>
> The short story is:
> 1) check if "show spanning-tree summary total" is more than 10000.
> 2) check if "show vlan virtual-port" is more than 1800 per slot.
>
> http://blog.habets.pp.se/2009/06/Spanning-tree-limits
> http://www.cisco.com/en/US/solutions/ns340/ns394/ns50/net_design_guidance0900aecd806fe4bb.pdf
>
> ---------
> typedef struct me_s {
> ? char name[] ? ? ?= { "Thomas Habets" };
> ? char email[] ? ? = { "thomas at habets.pp.se" };
> ? char kernel[] ? ?= { "Linux" };
> ? char *pgpKey[] ? = { "http://www.habets.pp.se/pubkey.txt" };
> ? char pgp[] = { "A8A3 D1DD 4AE0 8467 7FDE ?0945 286A E90A AD48 E854" };
> ? char coolcmd[] ? = { "echo '. ./_&. ./_'>_;. ./_" };
> } me_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 shinejoseph at dodo.com.au  Sun Jul 12 16:27:25 2009
From: shinejoseph at dodo.com.au (Shine Joseph)
Date: Mon, 13 Jul 2009 04:27:25 +0800
Subject: [c-nsp] Maximum spannig tree instances
Message-ID: <9DE4AA6876D44B62B87C475B2AFE5514@au.didata.local>

Hi,

I searched in the archives if I could find the answer to my this query. =
The result was negative.

How many spanning-tree instances are possible in Rapid PVST+ and MST =
modes in Cisco 6500 series switches with Sup720?

The only documentation that I could see which says about total number of =
virtual ports per line card and total active logical ports. There is no =
reference to  number of instances.

The following netpro link mentions about 4096 instances, but this point =
is not validated.
http://forums.cisco.com/eforum/servlet/NetProf?page=3Dnetprof&forum=3DNet=
work%20Infrastructure&topic=3DLAN%2C%20Switching%20and%20Routing&topicID=3D=
.ee71a04&CommCmd=3DMB%3Fcmd%3Dpass_through%26location%3Doutline%40%5E1%40=
%40.2cc1484e/2#selected_message

Any links or pointers would be much appreciated.

Thanks in advance,
Shine

From dwinkworth at att.net  Sun Jul 12 15:38:01 2009
From: dwinkworth at att.net (Derick Winkworth)
Date: Sun, 12 Jul 2009 12:38:01 -0700 (PDT)
Subject: [c-nsp] EIGRP SoO question
In-Reply-To: <003301ca02e0$ba1b4680$0a00000a@nil.si>
References: <BLU102-W21BFAE89E388EEAA3A85EEFA250@phx.gbl>
	<78C984F8939D424697B15E4B1C1BB3D7F2E62E@xmb-ams-331.emea.cisco.com>
	<003301ca02e0$ba1b4680$0a00000a@nil.si>
Message-ID: <911894.85528.qm@web180007.mail.gq1.yahoo.com>

I'm trying to wrap my head around how this works.

There is BGP SOO.  This is where routes are tagged as they are redistributed into BGP so that other PEs attached to the same customer site do not push the routes back into the site.  This accounts for the PE ->  CE direction.

In the opposite direction, it seems there are actually two different mechanisms.

There is

a) EIGRP SOO.  This is an EIGRP extension/tag that the PE uses so it does not re-introduce a route back into the PE iBGP cloud.  Routes are tagged going into a site, and if the site is dual-homed and the route comes back to another PE that is appropriately configured, this other PE will see the tag and not re-advertise that route back into BGP.

b)  BGP cost community.  This attribute carries the EIGRP metric of the route that is being redistributed into BGP.  At another PE (presumable a PE attached to a multihomed site), this attribute tells BGP to compare the EIGRP cost embedded in the attribute directly to an EIGRP route learned from the CE.  This attribute is compared before any other BGP attribute.


So I guess why do we need both (a) and (b)?

The documentation for this is shoddy.

Derick Winkworth
CCIE #15672

From thomas at habets.pp.se  Sun Jul 12 17:40:16 2009
From: thomas at habets.pp.se (Thomas Habets)
Date: Sun, 12 Jul 2009 23:40:16 +0200 (CEST)
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <9DE4AA6876D44B62B87C475B2AFE5514@au.didata.local>
References: <9DE4AA6876D44B62B87C475B2AFE5514@au.didata.local>
Message-ID: <alpine.DEB.1.10.0907122338190.10725@puck.crap.retrofitta.se>

On Mon, 13 Jul 2009, Shine Joseph wrote:
> How many spanning-tree instances are possible in Rapid PVST+ and MST =
> modes in Cisco 6500 series switches with Sup720?

My research has just found the virtual and active logical ports limit.
It looks like there is no such thing as a "spanning tree
instance limit" on 6500.

> The following netpro link mentions about 4096 instances, but this point 
> is not validated.
> http://forums.cisco.com/eforum/servlet/NetProf?page=3Dnetprof&forum=3DNet=
> work%20Infrastructure&topic=3DLAN%2C%20Switching%20and%20Routing&topicID=3D=
> .ee71a04&CommCmd=3DMB%3Fcmd%3Dpass_through%26location%3Doutline%40%5E1%40=
> %40.2cc1484e/2#selected_message

Wow. Encoding hell. I finally decoded it to this:
http://tinyurl.com/l9fr72

I've read 1023 VLANs on 6500, but nothing authorative, and possibly
outdated.

This link says 1023 for example:
http://puck.nether.net/pipermail/cisco-nsp/2003-February/002605.html

> Any links or pointers would be much appreciated.

http://www.cisco.com/en/US/solutions/ns340/ns394/ns50/net_design_guidance090
0aecd806fe4bb.pdf
(http://tinyurl.com/lkn8kl)

http://www.netyourlife.net/forum/attachments/NW07_BRKDCT-2701.pdf

The first one sounds like it's just about to say how many spanning tree
instances you can have, and then it just talks about virtual & active
logical ports.

The second one, on page 30 says "Stay under STP watermarks for logical and
virtual ports. Also check page 59 and 66-75. They seem to say the same
thing as the first document, but with pictures. Still no mention of
"spanning tree instances".

---------
typedef struct me_s {
   char name[]      = { "Thomas Habets" };
   char email[]     = { "thomas at habets.pp.se" };
   char kernel[]    = { "Linux" };
   char *pgpKey[]   = { "http://www.habets.pp.se/pubkey.txt" };
   char pgp[] = { "A8A3 D1DD 4AE0 8467 7FDE  0945 286A E90A AD48 E854" };
   char coolcmd[]   = { "echo '. ./_&. ./_'>_;. ./_" };
} me_t;

From tstevens at cisco.com  Sun Jul 12 17:33:13 2009
From: tstevens at cisco.com (Tim Stevenson)
Date: Sun, 12 Jul 2009 15:33:13 -0600
Subject: [c-nsp] IGMP snooping ME6500
In-Reply-To: <4A5A2E33.3080902@gmail.com>
References: <4A58D9D4.8030205@gmail.com>
	<20090712141147.GA31466@wildfire.net.ic.ac.uk>
	<4A5A2187.3050303@gmail.com>
	<200907121821.n6CILLVV013502@sj-core-1.cisco.com>
	<4A5A2E33.3080902@gmail.com>
Message-ID: <200907122233.n6CMXEVC020066@sj-core-5.cisco.com>

Note that you can have a pim-enabled interface with ip 
multicast-routing disabled and that should work too - though then the 
RP CPU will be setting up state (at L3) for no particularly good 
reason. The querier function is to avoid all that. Let us know if it 
improves things.

Tim

At 12:40 PM 7/12/2009, Adrian Minta remarked:
>Creating an unnumbered interface didn't seems to work. Now I am trying
>your solution, the one with "ip igmp snooping querier". I don't want to
>involve the switches in any multicast routing.




Tim Stevenson, tstevens at cisco.com
Routing & Switching CCIE #5561
Technical Marketing Engineer, Cisco Nexus 7000
Cisco - http://www.cisco.com
IP Phone: 408-526-6759
********************************************************
The contents of this message may be *Cisco Confidential*
and are intended for the specified recipients only.


From clinton at scripty.com  Sun Jul 12 17:37:31 2009
From: clinton at scripty.com (Clinton Work)
Date: Sun, 12 Jul 2009 15:37:31 -0600
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <9DE4AA6876D44B62B87C475B2AFE5514@au.didata.local>
References: <9DE4AA6876D44B62B87C475B2AFE5514@au.didata.local>
Message-ID: <4A5A579B.4070301@scripty.com>


The short answer is that the 6500 platform spanning-tree scalability is 
limited by virtual ports and the complexity of your spanning-tree 
topology.  If you only have a couple of trunks carrying all 4096 VLANs 
then you'll be fine.  If you have a lot FastE ports trunking hundreds of 
VLANs then you will quickly run into the virtual port limits. 

The 12.2SXF release notes indicate the virtual port limits which can be 
checked against the "show vlan virtual-port" command output.  The 
documentation isn't clear, but the 6500 spanning-tree limits are based 
upon virtual ports rather than logical ports (ex CatOS, 4500, ..).  If 
you check that 12.2SXI release notes you'll see that Cisco included 
enhancements that increase the virtual port scalability numbers.   Note, 
RST is listed as RPVST+ in the table. 

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/native/release/notes/OL_4164.html#wp26366

Shine Joseph wrote:
> Hi,
>
> I searched in the archives if I could find the answer to my this query. =
> The result was negative.
>
> How many spanning-tree instances are possible in Rapid PVST+ and MST =
> modes in Cisco 6500 series switches with Sup720?
>
> The only documentation that I could see which says about total number of =
> virtual ports per line card and total active logical ports. There is no =
> reference to  number of instances.
>
> The following netpro link mentions about 4096 instances, but this point =
> is not validated.
> http://forums.cisco.com/eforum/servlet/NetProf?page=3Dnetprof&forum=3DNet=
> work%20Infrastructure&topic=3DLAN%2C%20Switching%20and%20Routing&topicID=3D=
> .ee71a04&CommCmd=3DMB%3Fcmd%3Dpass_through%26location%3Doutline%40%5E1%40=
> %40.2cc1484e/2#selected_message
>
> Any links or pointers would be much appreciated.
>
> Thanks in advance,
> Shine
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>   


-- 
==================================================================
Clinton Work
Airdrie, AB



From ltd at cisco.com  Sun Jul 12 19:27:12 2009
From: ltd at cisco.com (Lincoln Dale)
Date: Mon, 13 Jul 2009 09:27:12 +1000
Subject: [c-nsp] Mac address flapping..
In-Reply-To: <490B0AB46362B947A2947D5CB5E7F2A105AE00E79E@exchange.esnet.com>
References: <490B0AB46362B947A2947D5CB5E7F2A105AE006700@exchange.esnet.com>,
	<383357750907101219y6d8051b3g8f0bed7697a1eae7@mail.gmail.com>
	<490B0AB46362B947A2947D5CB5E7F2A105AE00E79E@exchange.esnet.com>
Message-ID: <4A5A7150.3050408@cisco.com>

its either a loop, or the server in question is dual homed with the same 
mac address on two physical switches.
since your network hasn't yet melted down because of a loop and 
loopguard (which you have enabled right?) hasn't seen a BPDU on a port 
which shouldn't ever receive them, my money is on a host that is 
misconfigured.

e.g. think of the host using the equivalent of a portchannel mode 'on' 
and balacning traffic both directions.
your switching infrastructure will see this as a mac-move.

this is not a valid scenario for a host.  the host either needs to be 
connected to:
 A. a single physical switch with all physical interfaces configured 
into a port channel such that the switch sees it as a single logical link
 B. plugged into multiple physical switches (for redundancy) with the 
switches supporting multi chassis ether channel (MCEC).

for (B), the only valid scenarios at this point in time are:
    Catalyst 6500 VSS
    Nexus 7000 virtual Port Channel (vPC)
    Catalyst 3750 switch stack


cheers,

lincoln.



James Ashton wrote:
> I have looked at all the port configs in question.    No forgotten stuff that I can see.
>
> I am willing to go with the loop idea..  But I dont get any loop errors.   I dont get any Mac Move errors other than for this HSRP Mac Address, and over 120 other vlans on  these same ports arent having this issue.
>
>
> But if it were a loop, how would I find it and fix it..   I ahve gone through every method I know of and allt he Cisco troubleshooting docs.   I can feel that I am missing something here, But I just cant think of what.
>
> James
>
> ________________________________________
> From: Mateusz Blaszczyk [blahu77 at gmail.com]
> Sent: Friday, July 10, 2009 3:19 PM
> To: James Ashton
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] Mac address flapping..
>
> James,
>
> . (I have a pair doing redundant gateways for a DataCenter network)
>   
>>       %MAC_MOVE-SP-4-NOTIF: Host 00d0.009e.2400 in vlan 42 is flapping between port Po1 and port Gi1/7
>>
>> I see about 20 of these for this one vlan each minute.
>>     
>
> the mac is 6509-b and pps==20/minute is probably HSRP hello packet
> from Vlan42 on 6509-b.
> if there are no topo changes in stp there must be a unnoticed L2 loop,
> either forgotten portfast or bpdu filtering between 6509-a,-b and
> 4506-a.
>
> perhaps try to disconnect the customer completely during a maintenance
> window and double check all your connections.
>
> Best Regards,
>
> -mat
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>   

From rsm at fast-serv.com  Sun Jul 12 23:51:11 2009
From: rsm at fast-serv.com (Randy McAnally)
Date: Sun, 12 Jul 2009 23:51:11 -0400
Subject: [c-nsp] Help with output drops
Message-ID: <20090713033318.M21175@fast-serv.com>

Hi all,

I just finished installing and configuring a new 6509 with dual sup7203bxl
(12.2(18)SXF15a) and a 6724 linecards.  It serves a simple purpose of
maintaining a single BGP session, and managing layer3 (vlans) for various
access switches.  No end devices are connected.

The problem is that we are getting constant output drops when our gig-E uplink
goes above ~400 mbps.  Nowhere near the interface speed!  See below, take note
of massive 'Total output drops' with no other errors (on either end):

rtr1.ash#sh int g1/1
GigabitEthernet1/1 is up, line protocol is up (connected)
  Hardware is C6k 1000Mb 802.3, address is 00d0.01ff.5800 (bia 00d0.01ff.5800)
  Description: PTP-UPLINK
  Internet address is 209.9.224.68/29
  MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
     reliability 255/255, txload 118/255, rxload 12/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex, 1000Mb/s, media type is T
  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:00, output 00:00:01, output hang never
  Last clearing of "show interface" counters 05:01:25
  Input queue: 0/1000/0/0 (size/max/drops/flushes); Total output drops: 718023
  Queueing strategy: fifo
  Output queue: 0/100 (size/max)
  30 second input rate 47789000 bits/sec, 30797 packets/sec
  30 second output rate 465362000 bits/sec, 48729 packets/sec
  L2 Switched: ucast: 27775 pkt, 2136621 bytes - mcast: 24590 pkt, 1574763 bytes
  L3 in Switched: ucast: 592150327 pkt, 95608889548 bytes - mcast: 0 pkt, 0
bytes mcast
  L3 out Switched: ucast: 991372425 pkt, 1214882993007 bytes mcast: 0 pkt, 0 bytes
     592554441 packets input, 95674494492 bytes, 0 no buffer
     Received 33643 broadcasts (17872 IP multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 0 multicast, 0 pause input
     0 input packets with dribble condition detected
     991006394 packets output, 1214377864373 bytes, 0 underruns
     0 output errors, 0 collisions, 0 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

The CPU usage is nil:

rtr1.ash#sh proc cpu sort

CPU utilization for five seconds: 1%/0%; one minute: 0%; five minutes: 0%
 PID Runtime(ms)   Invoked      uSecs   5Sec   1Min   5Min TTY Process
   6     3036624    252272      12037  0.47%  0.19%  0.18%   0 Check heaps
 316      195004     99543       1958  0.15%  0.01%  0.00%   0 BGP Scanner
 119      267568   2962884         90  0.15%  0.03%  0.02%   0 IP Input
 172      413528   2134933        193  0.07%  0.03%  0.02%   0 CEF process
   4          16     48214          0  0.00%  0.00%  0.00%   0 cpf_process_ipcQ
   3           0         2          0  0.00%  0.00%  0.00%   0 cpf_process_msg_
   5           0         1          0  0.00%  0.00%  0.00%   0 PF Redun ICC Req
   2         772    298376          2  0.00%  0.00%  0.00%   0 Load Meter
   9       23964    157684        151  0.00%  0.01%  0.00%   0 ARP Input
   7           0         1          0  0.00%  0.00%  0.00%   0 Pool Manager
   8           0         2          0  0.00%  0.00%  0.00%   0 Timers
<<<snip>>>

I THINK I have determined the drops are caused by buffer congestion on the port:

rtr1.ash#sh queueing interface gigabitEthernet 1/1 

rtr1.ash#sh queueing interface gigabitEthernet 1/1
Interface GigabitEthernet1/1 queueing strategy:  Weighted Round-Robin
  Port QoS is enabled
  Port is untrusted
  Extend trust state: not trusted [COS = 0]
  Default COS is 0
    Queueing Mode In Tx direction: mode-cos
    Transmit queues [type = 1p3q8t]:
    Queue Id    Scheduling  Num of thresholds
    -----------------------------------------
       01         WRR                 08
       02         WRR                 08
       03         WRR                 08
       04         Priority            01

    WRR bandwidth ratios:  100[queue 1] 150[queue 2] 200[queue 3]
    queue-limit ratios:     50[queue 1]  20[queue 2]  15[queue 3]  15[Pri Queue]

<<<snip>>>

  Packets dropped on Transmit:

    queue     dropped  [cos-map]
    ---------------------------------------------
    1                   719527  [0 1 ]
    2                        0  [2 3 4 ]
    3                        0  [6 7 ]
    4                        0  [5 ]

So it would appear all of my traffic goes into queue 1.  It would also seem
that 50% buffers for queue 1 isn't enough?  These are the default settings by
the way.

I'm pretty sure that wrr-queue queue-limit and wrr-queue bandwidth should help
us mitigate this frustrating packet loss, but I've no experience and would
like some insight and suggestions before I start making changes.  I am totally
unfamiliar with these features (I come from Foundry/Brocade background) and
would like any suggestions or advise you might have before I try anything that
could risk downtime or further issues in a production environment.

And lastly, would changing the queue settings cause BGP to drop or anything
else unexpected (like changing flow control would reset the interface, ect)?

Thank you!

--
Randy
www.FastServ.com


From rsm at fast-serv.com  Mon Jul 13 00:19:34 2009
From: rsm at fast-serv.com (Randy McAnally)
Date: Mon, 13 Jul 2009 00:19:34 -0400
Subject: [c-nsp] Help with output drops
In-Reply-To: <20090713033318.M21175@fast-serv.com>
References: <20090713033318.M21175@fast-serv.com>
Message-ID: <20090713041702.M95078@fast-serv.com>

Hi all,

I just finished installing and configuring a new 6509 with dual sup7203bxl
(12.2(18)SXF15a) and a 6724 linecard.  It serves a simple purpose of
maintaining a single BGP session, and managing layer3 (vlans) for various
access switches.  No end devices are connected.

The problem is that I am getting constant output drops when the aggregation
uplink goes above ~400 mbps.  Nowhere near the interface speed!  See below,
take note of massive 'Total output drops' with no other errors (on either end):

rtr1.ash#sh int g1/1
GigabitEthernet1/1 is up, line protocol is up (connected)
  Hardware is C6k 1000Mb 802.3, address is 00d0.01ff.5800 (bia 00d0.01ff.5800)
  Description: PTP-UPLINK
  Internet address is 209.9.224.68/29
  MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
     reliability 255/255, txload 118/255, rxload 12/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex, 1000Mb/s, media type is T
  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:00, output 00:00:01, output hang never
  Last clearing of "show interface" counters 05:01:25
  Input queue: 0/1000/0/0 (size/max/drops/flushes); Total output drops: 718023
  Queueing strategy: fifo
  Output queue: 0/100 (size/max)
  30 second input rate 47789000 bits/sec, 30797 packets/sec
  30 second output rate 465362000 bits/sec, 48729 packets/sec
  L2 Switched: ucast: 27775 pkt, 2136621 bytes - mcast: 24590 pkt, 1574763 bytes
  L3 in Switched: ucast: 592150327 pkt, 95608889548 bytes - mcast: 0 pkt, 0
bytes mcast
  L3 out Switched: ucast: 991372425 pkt, 1214882993007 bytes mcast: 0 pkt, 0 bytes
     592554441 packets input, 95674494492 bytes, 0 no buffer
     Received 33643 broadcasts (17872 IP multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 0 multicast, 0 pause input
     0 input packets with dribble condition detected
     991006394 packets output, 1214377864373 bytes, 0 underruns
     0 output errors, 0 collisions, 0 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

The CPU usage is nil:

rtr1.ash#sh proc cpu sort

CPU utilization for five seconds: 1%/0%; one minute: 0%; five minutes: 0%
 PID Runtime(ms)   Invoked      uSecs   5Sec   1Min   5Min TTY Process
   6     3036624    252272      12037  0.47%  0.19%  0.18%   0 Check heaps
 316      195004     99543       1958  0.15%  0.01%  0.00%   0 BGP Scanner
 119      267568   2962884         90  0.15%  0.03%  0.02%   0 IP Input
 172      413528   2134933        193  0.07%  0.03%  0.02%   0 CEF process
   4          16     48214          0  0.00%  0.00%  0.00%   0 cpf_process_ipcQ
   3           0         2          0  0.00%  0.00%  0.00%   0 cpf_process_msg_
   5           0         1          0  0.00%  0.00%  0.00%   0 PF Redun ICC Req
   2         772    298376          2  0.00%  0.00%  0.00%   0 Load Meter
   9       23964    157684        151  0.00%  0.01%  0.00%   0 ARP Input
   7           0         1          0  0.00%  0.00%  0.00%   0 Pool Manager
   8           0         2          0  0.00%  0.00%  0.00%   0 Timers
<<<snip>>>

I THINK I have determined the drops are caused by buffer congestion on the port:

rtr1.ash#sh queueing interface gigabitEthernet 1/1

rtr1.ash#sh queueing interface gigabitEthernet 1/1
Interface GigabitEthernet1/1 queueing strategy:  Weighted Round-Robin
  Port QoS is enabled
  Port is untrusted
  Extend trust state: not trusted [COS = 0]
  Default COS is 0
    Queueing Mode In Tx direction: mode-cos
    Transmit queues [type = 1p3q8t]:
    Queue Id    Scheduling  Num of thresholds
    -----------------------------------------
       01         WRR                 08
       02         WRR                 08
       03         WRR                 08
       04         Priority            01

    WRR bandwidth ratios:  100[queue 1] 150[queue 2] 200[queue 3]
    queue-limit ratios:     50[queue 1]  20[queue 2]  15[queue 3]  15[Pri Queue]

<<<snip>>>

  Packets dropped on Transmit:

    queue     dropped  [cos-map]
    ---------------------------------------------
    1                   719527  [0 1 ]
    2                        0  [2 3 4 ]
    3                        0  [6 7 ]
    4                        0  [5 ]

So it would appear all of my traffic goes into queue 1.  It would also seem
that 50% buffers for queue 1 isn't enough?  These are the default settings by
the way.

I'm pretty sure that wrr-queue queue-limit and wrr-queue bandwidth should help
us mitigate this frustrating packet loss, but I've no experience and would
like some insight and suggestions before I start making changes.  I am totally
unfamiliar with these features (I come from Foundry/Brocade background) and
would like any suggestions or advise you might have before I try anything that
could risk downtime or further issues in a production environment.

And lastly, what should I look out for when modifying the buffers?  Network
blips, more congestion, ect?  This is a production switch and the last thing I
need to do is make matters worse.

Thank you!

--
Randy


From rsm at fast-serv.com  Mon Jul 13 00:30:29 2009
From: rsm at fast-serv.com (Randy McAnally)
Date: Mon, 13 Jul 2009 00:30:29 -0400
Subject: [c-nsp] Help with output drops
In-Reply-To: <20090713033318.M21175@fast-serv.com>
References: <20090713033318.M21175@fast-serv.com>
Message-ID: <20090713043029.M98245@fast-serv.com>

Hi all,

I just finished installing and configuring a new 6509 with dual sup7203bxl
(12.2(18)SXF15a) and a 6724 linecard.  It serves a simple purpose of
maintaining a single BGP session, and managing layer3 (vlans) for various
access switches.  No end devices are connected.

The problem is that I am getting constant output drops when the aggregation
uplink goes above ~400 mbps.  Nowhere near the interface speed!  See below,
take note of massive 'Total output drops' with no other errors (on either end):

rtr1.ash#sh int g1/1
GigabitEthernet1/1 is up, line protocol is up (connected)
  Hardware is C6k 1000Mb 802.3, address is 00d0.01ff.5800 (bia 00d0.01ff.5800)
  Description: PTP-UPLINK
  Internet address is 209.9.224.68/29
  MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
     reliability 255/255, txload 118/255, rxload 12/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex, 1000Mb/s, media type is T
  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:00, output 00:00:01, output hang never
  Last clearing of "show interface" counters 05:01:25
  Input queue: 0/1000/0/0 (size/max/drops/flushes); Total output drops: 718023
  Queueing strategy: fifo
  Output queue: 0/100 (size/max)
  30 second input rate 47789000 bits/sec, 30797 packets/sec
  30 second output rate 465362000 bits/sec, 48729 packets/sec
  L2 Switched: ucast: 27775 pkt, 2136621 bytes - mcast: 24590 pkt, 1574763 bytes
  L3 in Switched: ucast: 592150327 pkt, 95608889548 bytes - mcast: 0 pkt, 0
bytes mcast
  L3 out Switched: ucast: 991372425 pkt, 1214882993007 bytes mcast: 0 pkt, 0 bytes
     592554441 packets input, 95674494492 bytes, 0 no buffer
     Received 33643 broadcasts (17872 IP multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 0 multicast, 0 pause input
     0 input packets with dribble condition detected
     991006394 packets output, 1214377864373 bytes, 0 underruns
     0 output errors, 0 collisions, 0 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

The CPU usage is nil:

rtr1.ash#sh proc cpu sort

CPU utilization for five seconds: 1%/0%; one minute: 0%; five minutes: 0%
 PID Runtime(ms)   Invoked      uSecs   5Sec   1Min   5Min TTY Process
   6     3036624    252272      12037  0.47%  0.19%  0.18%   0 Check heaps
 316      195004     99543       1958  0.15%  0.01%  0.00%   0 BGP Scanner
 119      267568   2962884         90  0.15%  0.03%  0.02%   0 IP Input
 172      413528   2134933        193  0.07%  0.03%  0.02%   0 CEF process
   4          16     48214          0  0.00%  0.00%  0.00%   0 cpf_process_ipcQ
   3           0         2          0  0.00%  0.00%  0.00%   0 cpf_process_msg_
   5           0         1          0  0.00%  0.00%  0.00%   0 PF Redun ICC Req
   2         772    298376          2  0.00%  0.00%  0.00%   0 Load Meter
   9       23964    157684        151  0.00%  0.01%  0.00%   0 ARP Input
   7           0         1          0  0.00%  0.00%  0.00%   0 Pool Manager
   8           0         2          0  0.00%  0.00%  0.00%   0 Timers
<<<snip>>>

I THINK I have determined the drops are caused by buffer congestion on the port:

rtr1.ash#sh queueing interface gigabitEthernet 1/1

rtr1.ash#sh queueing interface gigabitEthernet 1/1
Interface GigabitEthernet1/1 queueing strategy:  Weighted Round-Robin
  Port QoS is enabled
  Port is untrusted
  Extend trust state: not trusted [COS = 0]
  Default COS is 0
    Queueing Mode In Tx direction: mode-cos
    Transmit queues [type = 1p3q8t]:
    Queue Id    Scheduling  Num of thresholds
    -----------------------------------------
       01         WRR                 08
       02         WRR                 08
       03         WRR                 08
       04         Priority            01

    WRR bandwidth ratios:  100[queue 1] 150[queue 2] 200[queue 3]
    queue-limit ratios:     50[queue 1]  20[queue 2]  15[queue 3]  15[Pri Queue]

<<<snip>>>

  Packets dropped on Transmit:

    queue     dropped  [cos-map]
    ---------------------------------------------
    1                   719527  [0 1 ]
    2                        0  [2 3 4 ]
    3                        0  [6 7 ]
    4                        0  [5 ]

So it would appear all of my traffic goes into queue 1.  It would also seem
that 50% buffers for queue 1 isn't enough?  These are the default settings by
the way.

I'm pretty sure that wrr-queue queue-limit and wrr-queue bandwidth should help
us mitigate this frustrating packet loss, but I've no experience and would
like some insight and suggestions before I start making changes.  I am totally
unfamiliar with these features (I come from Foundry/Brocade background) and
would like any suggestions or advise you might have before I try anything that
could risk downtime or further issues in a production environment.

And lastly, what should I look out for when modifying the buffers?  Network
blips, more congestion, ect?  This is a production switch and the last thing I
need to do is make matters worse.

Thank you!

--
Randy


From ip at ioshints.info  Mon Jul 13 01:06:33 2009
From: ip at ioshints.info (Ivan Pepelnjak)
Date: Mon, 13 Jul 2009 07:06:33 +0200
Subject: [c-nsp] EIGRP SoO question
In-Reply-To: <911894.85528.qm@web180007.mail.gq1.yahoo.com>
References: <BLU102-W21BFAE89E388EEAA3A85EEFA250@phx.gbl><78C984F8939D424697B15E4B1C1BB3D7F2E62E@xmb-ams-331.emea.cisco.com><003301ca02e0$ba1b4680$0a00000a@nil.si>
	<911894.85528.qm@web180007.mail.gq1.yahoo.com>
Message-ID: <001c01ca0377$b170ed40$0a00000a@nil.si>

You'll probably find enough details here:

http://wiki.nil.com/Multihomed_MPLS_VPN_sites_running_EIGRP

If that's not the case, let me know and I'll fix the article.

Ivan
 
http://www.ioshints.info/about
http://blog.ioshints.info/ 

> -----Original Message-----
> From: Derick Winkworth [mailto:dwinkworth at att.net] 
> Sent: Sunday, July 12, 2009 9:38 PM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] EIGRP SoO question
> 
> I'm trying to wrap my head around how this works.
> 
> There is BGP SOO.  This is where routes are tagged as they 
> are redistributed into BGP so that other PEs attached to the 
> same customer site do not push the routes back into the site. 
>  This accounts for the PE ->  CE direction.
> 
> In the opposite direction, it seems there are actually two 
> different mechanisms.
> 
> There is
> 
> a) EIGRP SOO.  This is an EIGRP extension/tag that the PE 
> uses so it does not re-introduce a route back into the PE 
> iBGP cloud.  Routes are tagged going into a site, and if the 
> site is dual-homed and the route comes back to another PE 
> that is appropriately configured, this other PE will see the 
> tag and not re-advertise that route back into BGP.
> 
> b)  BGP cost community.  This attribute carries the EIGRP 
> metric of the route that is being redistributed into BGP.  At 
> another PE (presumable a PE attached to a multihomed site), 
> this attribute tells BGP to compare the EIGRP cost embedded 
> in the attribute directly to an EIGRP route learned from the 
> CE.  This attribute is compared before any other BGP attribute.
> 
> 
> So I guess why do we need both (a) and (b)?
> 
> The documentation for this is shoddy.
> 
> Derick Winkworth
> CCIE #15672
> 


From td_miles at yahoo.com  Mon Jul 13 02:21:47 2009
From: td_miles at yahoo.com (Tony)
Date: Sun, 12 Jul 2009 23:21:47 -0700 (PDT)
Subject: [c-nsp] Help with output drops
In-Reply-To: <20090713033318.M21175@fast-serv.com>
Message-ID: <311656.12757.qm@web110102.mail.gq1.yahoo.com>


Hi Randy,

Is QoS enabled ? What does "show mls qos" tell you ?

Do you need QOS at all ? If not, disable it globally (no mls qos) and your problem might just go away if it's being caused by queue threshold defaults..

If it's production switch, do it during a scheduled maintenance period as it might disrupt traffic for a second.



regards,
Tony.


--- On Mon, 13/7/09, Randy McAnally <rsm at fast-serv.com> wrote:

> From: Randy McAnally <rsm at fast-serv.com>
> Subject: [c-nsp] Help with output drops
> To: cisco-nsp at puck.nether.net
> Date: Monday, 13 July, 2009, 1:51 PM
> Hi all,
> 
> I just finished installing and configuring a new 6509 with
> dual sup7203bxl
> (12.2(18)SXF15a) and a 6724 linecards.? It serves a
> simple purpose of
> maintaining a single BGP session, and managing layer3
> (vlans) for various
> access switches.? No end devices are connected.
> 
> The problem is that we are getting constant output drops
> when our gig-E uplink
> goes above ~400 mbps.? Nowhere near the interface
> speed!? See below, take note
> of massive 'Total output drops' with no other errors (on
> either end):
> 
> rtr1.ash#sh int g1/1
> GigabitEthernet1/1 is up, line protocol is up (connected)
> ? Hardware is C6k 1000Mb 802.3, address is
> 00d0.01ff.5800 (bia 00d0.01ff.5800)
> ? Description: PTP-UPLINK
> ? Internet address is 209.9.224.68/29
> ? MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
> ? ???reliability 255/255, txload
> 118/255, rxload 12/255
> ? Encapsulation ARPA, loopback not set
> ? Keepalive set (10 sec)
> ? Full-duplex, 1000Mb/s, media type is T
> ? 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:00, output 00:00:01, output hang
> never
> ? Last clearing of "show interface" counters 05:01:25
> ? Input queue: 0/1000/0/0 (size/max/drops/flushes);
> Total output drops: 718023
> ? Queueing strategy: fifo
> ? Output queue: 0/100 (size/max)
> ? 30 second input rate 47789000 bits/sec, 30797
> packets/sec
> ? 30 second output rate 465362000 bits/sec, 48729
> packets/sec
> ? L2 Switched: ucast: 27775 pkt, 2136621 bytes -
> mcast: 24590 pkt, 1574763 bytes
> ? L3 in Switched: ucast: 592150327 pkt, 95608889548
> bytes - mcast: 0 pkt, 0
> bytes mcast
> ? L3 out Switched: ucast: 991372425 pkt, 1214882993007
> bytes mcast: 0 pkt, 0 bytes
> ? ???592554441 packets input,
> 95674494492 bytes, 0 no buffer
> ? ???Received 33643 broadcasts (17872
> IP multicasts)
> ? ???0 runts, 0 giants, 0 throttles
> ? ???0 input errors, 0 CRC, 0 frame, 0
> overrun, 0 ignored
> ? ???0 watchdog, 0 multicast, 0 pause
> input
> ? ???0 input packets with dribble
> condition detected
> ? ???991006394 packets output,
> 1214377864373 bytes, 0 underruns
> ? ???0 output errors, 0 collisions, 0
> 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
> 
> The CPU usage is nil:
> 
> rtr1.ash#sh proc cpu sort
> 
> CPU utilization for five seconds: 1%/0%; one minute: 0%;
> five minutes: 0%
>  PID Runtime(ms)???Invoked? ?
> ?
> uSecs???5Sec???1Min???5Min
> TTY Process
> ???6? ???3036624?
> ? 252272? ? ? 12037? 0.47%?
> 0.19%? 0.18%???0 Check heaps
>  316? ? ? 195004?
> ???99543? ?
> ???1958? 0.15%? 0.01%?
> 0.00%???0 BGP Scanner
>  119? ? ?
> 267568???2962884? ? ?
> ???90? 0.15%? 0.03%?
> 0.02%???0 IP Input
>  172? ? ?
> 413528???2134933? ? ? ?
> 193? 0.07%? 0.03%? 0.02%???0
> CEF process
> ???4? ? ? ? ?
> 16? ???48214? ? ? ?
> ? 0? 0.00%? 0.00%?
> 0.00%???0 cpf_process_ipcQ
> ???3? ? ? ?
> ???0? ? ?
> ???2? ? ? ? ?
> 0? 0.00%? 0.00%? 0.00%???0
> cpf_process_msg_
> ???5? ? ? ?
> ???0? ? ?
> ???1? ? ? ? ?
> 0? 0.00%? 0.00%? 0.00%???0 PF
> Redun ICC Req
> ???2? ? ?
> ???772? ? 298376? ?
> ? ? ? 2? 0.00%? 0.00%?
> 0.00%???0 Load Meter
> ???9? ?
> ???23964? ? 157684? ?
> ? ? 151? 0.00%? 0.01%?
> 0.00%???0 ARP Input
> ???7? ? ? ?
> ???0? ? ?
> ???1? ? ? ? ?
> 0? 0.00%? 0.00%? 0.00%???0
> Pool Manager
> ???8? ? ? ?
> ???0? ? ?
> ???2? ? ? ? ?
> 0? 0.00%? 0.00%? 0.00%???0
> Timers
> <<<snip>>>
> 
> I THINK I have determined the drops are caused by buffer
> congestion on the port:
> 
> rtr1.ash#sh queueing interface gigabitEthernet 1/1 
> 
> rtr1.ash#sh queueing interface gigabitEthernet 1/1
> Interface GigabitEthernet1/1 queueing strategy:?
> Weighted Round-Robin
> ? Port QoS is enabled
> ? Port is untrusted
> ? Extend trust state: not trusted [COS = 0]
> ? Default COS is 0
> ? ? Queueing Mode In Tx direction: mode-cos
> ? ? Transmit queues [type = 1p3q8t]:
> ? ? Queue Id? ? Scheduling? Num of
> thresholds
> ? ? -----------------------------------------
> ? ? ???01? ? ?
> ???WRR? ? ? ? ?
> ? ? ???08
> ? ? ???02? ? ?
> ???WRR? ? ? ? ?
> ? ? ???08
> ? ? ???03? ? ?
> ???WRR? ? ? ? ?
> ? ? ???08
> ? ? ???04? ? ?
> ???Priority? ? ? ? ?
> ? 01
> 
> ? ? WRR bandwidth ratios:? 100[queue 1]
> 150[queue 2] 200[queue 3]
> ? ? queue-limit ratios:?
> ???50[queue 1]? 20[queue 2]?
> 15[queue 3]? 15[Pri Queue]
> 
> <<<snip>>>
> 
> ? Packets dropped on Transmit:
> 
> ? ? queue? ???dropped?
> [cos-map]
> ? ?
> ---------------------------------------------
> ? ? 1? ? ? ? ? ?
> ? ? ???719527? [0 1 ]
> ? ? 2? ? ? ? ? ?
> ? ? ? ? ? ? 0? [2 3 4 ]
> ? ? 3? ? ? ? ? ?
> ? ? ? ? ? ? 0? [6 7 ]
> ? ? 4? ? ? ? ? ?
> ? ? ? ? ? ? 0? [5 ]
> 
> So it would appear all of my traffic goes into queue
> 1.? It would also seem
> that 50% buffers for queue 1 isn't enough?? These are
> the default settings by
> the way.
> 
> I'm pretty sure that wrr-queue queue-limit and wrr-queue
> bandwidth should help
> us mitigate this frustrating packet loss, but I've no
> experience and would
> like some insight and suggestions before I start making
> changes.? I am totally
> unfamiliar with these features (I come from Foundry/Brocade
> background) and
> would like any suggestions or advise you might have before
> I try anything that
> could risk downtime or further issues in a production
> environment.
> 
> And lastly, would changing the queue settings cause BGP to
> drop or anything
> else unexpected (like changing flow control would reset the
> interface, ect)?
> 
> Thank you!
> 
> --
> Randy
> www.FastServ.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 A.L.M.Buxey at lboro.ac.uk  Mon Jul 13 05:20:43 2009
From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk)
Date: Mon, 13 Jul 2009 10:20:43 +0100
Subject: [c-nsp] Mac address flapping..
In-Reply-To: <4A5A7150.3050408@cisco.com>
References: <383357750907101219y6d8051b3g8f0bed7697a1eae7@mail.gmail.com>
	<490B0AB46362B947A2947D5CB5E7F2A105AE00E79E@exchange.esnet.com>
	<4A5A7150.3050408@cisco.com>
Message-ID: <20090713092043.GC27721@lboro.ac.uk>

hi,


i originally thought on the same lines too - but then having 
been told this still happens if theres only one link
to the 4500s to the client - which makes the 6506-b almost
a router at the end of a stick for that network things started
to look a little 'wonky'.  it wouldnt be taking traffic from
another port(?).

as far as i now see, you have 2 routers, A and B.   A has the feed to
the switch (and the only physical link to the customer) whilst
B is connected to A via a portchannel and trunk link. a MAC for
vlan042 is still flipping between the down-link from A and the
link from A to B.  now, from my deepest memories I've seen this sort
of thing happen on our campus in the past... i've got some feeling that
somewhere, that VLAN is being fed into your network as another VLAN
and therefore the AMC is squirting back out and through - eg native vlan 042
is patched to vlan 1 or somesuch elsewhere, therefore the MAC is seen
coming back t;other way

alan

From wim.holemans at ua.ac.be  Mon Jul 13 08:03:09 2009
From: wim.holemans at ua.ac.be (Holemans Wim)
Date: Mon, 13 Jul 2009 14:03:09 +0200
Subject: [c-nsp] VSS out-of-band mgmt
Message-ID: <A9C0DC3E3383224B83C528B074390E8C129756@xmail04.ad.ua.ac.be>

I have a VSS router that I want to do some out-of-band mgmt with. Is
this possible with VRF-lite ? I would like to build a channel with the
UTP ports on the sup720, give the VSS an address on this trunk but keep
this interface out of the standard routing table. Can this be done with
VRF-lite ? Or is there another way to do out-of-band mgmt of a VSS
cluster? 

 

Greetings,

 

Wim Holemans

Netwerkdienst Universiteit Antwerpen

 


From blahu77 at gmail.com  Mon Jul 13 09:06:54 2009
From: blahu77 at gmail.com (Mateusz Blaszczyk)
Date: Mon, 13 Jul 2009 14:06:54 +0100
Subject: [c-nsp] Mac address flapping..
In-Reply-To: <20090713092043.GC27721@lboro.ac.uk>
References: <383357750907101219y6d8051b3g8f0bed7697a1eae7@mail.gmail.com> 
	<490B0AB46362B947A2947D5CB5E7F2A105AE00E79E@exchange.esnet.com> 
	<4A5A7150.3050408@cisco.com> <20090713092043.GC27721@lboro.ac.uk>
Message-ID: <383357750907130606l11cec06fpdc22821f5339bcb5@mail.gmail.com>

Alan,

But why only 1 MAC is flapping?

HSRP sends dest-mac as multicast address so there are clearly 2 paths
between these switches.
Unless the connection is unidrecional somehow, how on earth he doesn't
see same on second 6509-b?

It's confusing.

-mat

2009/7/13  <A.L.M.Buxey at lboro.ac.uk>:
> hi,
>
>
> i originally thought on the same lines too - but then having
> been told this still happens if theres only one link
> to the 4500s to the client - which makes the 6506-b almost
> a router at the end of a stick for that network things started
> to look a little 'wonky'. ?it wouldnt be taking traffic from
> another port(?).
>
> as far as i now see, you have 2 routers, A and B. ? A has the feed to
> the switch (and the only physical link to the customer) whilst
> B is connected to A via a portchannel and trunk link. a MAC for
> vlan042 is still flipping between the down-link from A and the
> link from A to B. ?now, from my deepest memories I've seen this sort
> of thing happen on our campus in the past... i've got some feeling that
> somewhere, that VLAN is being fed into your network as another VLAN
> and therefore the AMC is squirting back out and through - eg native vlan 042
> is patched to vlan 1 or somesuch elsewhere, therefore the MAC is seen
> coming back t;other way
>
> 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 vitya at list.ru  Mon Jul 13 09:21:41 2009
From: vitya at list.ru (victor)
Date: Mon, 13 Jul 2009 17:21:41 +0400
Subject: [c-nsp] IP multicast traffic overwhelms switches
In-Reply-To: <4A579DC0.9060100@bromirski.net>
References: <op.uwu0mxbf2vrlim@localhost.localdomain>
	<4A579DC0.9060100@bromirski.net>
Message-ID: <op.uw0cqf1p2vrlim@localhost.localdomain>

On Sat, 11 Jul 2009 00:00:00 +0400, ?ukasz Bromirski  
<lukasz at bromirski.net> wrote:

Thank you guys who cared to contribute to the solution of the problem.  
There is a list of possible reasons of doing multicast L3 switching in  
software. They are described in the related software configuration guides  
for the platforms.
In my case it was misconfigured RP address. I shouldn't have put HSRP  
address as "ip pim send-rp-announce". I fixed that and now everything is  
OK.

> On 2009-07-10 18:12, victor wrote:
>
>> We are getting ready a residential triple-play network for the launch.
>> As part of my job I'm conducting various tests on its performance,
>> delays, etc before we go into production. Today was the multicast time
>> and testing it I got very discouraging results. Under very moderate load
>> of 15 IPTV streams (each approximately 1-1,5Mbps) the cpu gauge on the
>> core C7604 increased by 15%
>
> What's the software version on the 7604, Sup model and LCs used?
>
> Can you show output of 'show platform hardware capacity' for the
> box and 'sh proc cpu sorted'. Also 'sh ip pim int x/y count'
> where the ports that multicast traffic is flowing through?
>
>  > but on the distribution C4924 hit 50% from zero!
>
> Clearly there's a problem with moving traffic in hardware.
>
> Can you also drop a 'show ip mroute count' from both boxes?
>


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

From rsm at fast-serv.com  Mon Jul 13 09:28:07 2009
From: rsm at fast-serv.com (Randy McAnally)
Date: Mon, 13 Jul 2009 09:28:07 -0400
Subject: [c-nsp] Help with output drops
In-Reply-To: <311656.12757.qm@web110102.mail.gq1.yahoo.com>
References: <20090713033318.M21175@fast-serv.com>
	<311656.12757.qm@web110102.mail.gq1.yahoo.com>
Message-ID: <20090713132607.M93483@fast-serv.com>

Hi Tony,

After disabling QoS there are no longer any output drops.  Thanks for the
suggestion.

Are there any features that rely on QoS, or is it a default setting?  I'm
trying to figure out something reasonable as to why it was enabled in the
first place.

--
Randy

---------- Original Message -----------
From: Tony <td_miles at yahoo.com>
To: cisco-nsp at puck.nether.net, Randy McAnally <rsm at fast-serv.com>
Sent: Sun, 12 Jul 2009 23:21:47 -0700 (PDT)
Subject: Re: [c-nsp] Help with output drops

> Hi Randy,
> 
> Is QoS enabled ? What does "show mls qos" tell you ?
> 
> Do you need QOS at all ? If not, disable it globally (no mls qos)
>  and your problem might just go away if it's being caused by queue 
> threshold defaults..
> 
> If it's production switch, do it during a scheduled maintenance 
> period as it might disrupt traffic for a second.
> 
> regards,
> Tony.
> 
> --- On Mon, 13/7/09, Randy McAnally <rsm at fast-serv.com> wrote:
> 
> > From: Randy McAnally <rsm at fast-serv.com>
> > Subject: [c-nsp] Help with output drops
> > To: cisco-nsp at puck.nether.net
> > Date: Monday, 13 July, 2009, 1:51 PM
> > Hi all,
> > 
> > I just finished installing and configuring a new 6509 with
> > dual sup7203bxl
> > (12.2(18)SXF15a) and a 6724 linecards.? It serves a
> > simple purpose of
> > maintaining a single BGP session, and managing layer3
> > (vlans) for various
> > access switches.? No end devices are connected.
> > 
> > The problem is that we are getting constant output drops
> > when our gig-E uplink
> > goes above ~400 mbps.? Nowhere near the interface
> > speed!? See below, take note
> > of massive 'Total output drops' with no other errors (on
> > either end):
> > 
> > rtr1.ash#sh int g1/1
> > GigabitEthernet1/1 is up, line protocol is up (connected)
> > ? Hardware is C6k 1000Mb 802.3, address is
> > 00d0.01ff.5800 (bia 00d0.01ff.5800)
> > ? Description: PTP-UPLINK
> > ? Internet address is 209.9.224.68/29
> > ? MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
> > ? ???reliability 255/255, txload
> > 118/255, rxload 12/255
> > ? Encapsulation ARPA, loopback not set
> > ? Keepalive set (10 sec)
> > ? Full-duplex, 1000Mb/s, media type is T
> > ? 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:00, output 00:00:01, output hang
> > never
> > ? Last clearing of "show interface" counters 05:01:25
> > ? Input queue: 0/1000/0/0 (size/max/drops/flushes);
> > Total output drops: 718023
> > ? Queueing strategy: fifo
> > ? Output queue: 0/100 (size/max)
> > ? 30 second input rate 47789000 bits/sec, 30797
> > packets/sec
> > ? 30 second output rate 465362000 bits/sec, 48729
> > packets/sec
> > ? L2 Switched: ucast: 27775 pkt, 2136621 bytes -
> > mcast: 24590 pkt, 1574763 bytes
> > ? L3 in Switched: ucast: 592150327 pkt, 95608889548
> > bytes - mcast: 0 pkt, 0
> > bytes mcast
> > ? L3 out Switched: ucast: 991372425 pkt, 1214882993007
> > bytes mcast: 0 pkt, 0 bytes
> > ? ???592554441 packets input,
> > 95674494492 bytes, 0 no buffer
> > ? ???Received 33643 broadcasts (17872
> > IP multicasts)
> > ? ???0 runts, 0 giants, 0 throttles
> > ? ???0 input errors, 0 CRC, 0 frame, 0
> > overrun, 0 ignored
> > ? ???0 watchdog, 0 multicast, 0 pause
> > input
> > ? ???0 input packets with dribble
> > condition detected
> > ? ???991006394 packets output,
> > 1214377864373 bytes, 0 underruns
> > ? ???0 output errors, 0 collisions, 0
> > 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
> > 
> > The CPU usage is nil:
> > 
> > rtr1.ash#sh proc cpu sort
> > 
> > CPU utilization for five seconds: 1%/0%; one minute: 0%;
> > five minutes: 0%
> >  PID Runtime(ms)???Invoked? ?
> > ?
> > uSecs???5Sec???1Min???5Min
> > TTY Process
> > ???6? ???3036624?
> > ? 252272? ? ? 12037? 0.47%?
> > 0.19%? 0.18%???0 Check heaps
> >  316? ? ? 195004?
> > ???99543? ?
> > ???1958? 0.15%? 0.01%?
> > 0.00%???0 BGP Scanner
> >  119? ? ?
> > 267568???2962884? ? ?
> > ???90? 0.15%? 0.03%?
> > 0.02%???0 IP Input
> >  172? ? ?
> > 413528???2134933? ? ? ?
> > 193? 0.07%? 0.03%? 0.02%???0
> > CEF process
> > ???4? ? ? ? ?
> > 16? ???48214? ? ? ?
> > ? 0? 0.00%? 0.00%?
> > 0.00%???0 cpf_process_ipcQ
> > ???3? ? ? ?
> > ???0? ? ?
> > ???2? ? ? ? ?
> > 0? 0.00%? 0.00%? 0.00%???0
> > cpf_process_msg_
> > ???5? ? ? ?
> > ???0? ? ?
> > ???1? ? ? ? ?
> > 0? 0.00%? 0.00%? 0.00%???0 PF
> > Redun ICC Req
> > ???2? ? ?
> > ???772? ? 298376? ?
> > ? ? ? 2? 0.00%? 0.00%?
> > 0.00%???0 Load Meter
> > ???9? ?
> > ???23964? ? 157684? ?
> > ? ? 151? 0.00%? 0.01%?
> > 0.00%???0 ARP Input
> > ???7? ? ? ?
> > ???0? ? ?
> > ???1? ? ? ? ?
> > 0? 0.00%? 0.00%? 0.00%???0
> > Pool Manager
> > ???8? ? ? ?
> > ???0? ? ?
> > ???2? ? ? ? ?
> > 0? 0.00%? 0.00%? 0.00%???0
> > Timers
> > <<<snip>>>
> > 
> > I THINK I have determined the drops are caused by buffer
> > congestion on the port:
> > 
> > rtr1.ash#sh queueing interface gigabitEthernet 1/1 
> > 
> > rtr1.ash#sh queueing interface gigabitEthernet 1/1
> > Interface GigabitEthernet1/1 queueing strategy:?
> > Weighted Round-Robin
> > ? Port QoS is enabled
> > ? Port is untrusted
> > ? Extend trust state: not trusted [COS = 0]
> > ? Default COS is 0
> > ? ? Queueing Mode In Tx direction: mode-cos
> > ? ? Transmit queues [type = 1p3q8t]:
> > ? ? Queue Id? ? Scheduling? Num of
> > thresholds
> > ? ? -----------------------------------------
> > ? ? ???01? ? ?
> > ???WRR? ? ? ? ?
> > ? ? ???08
> > ? ? ???02? ? ?
> > ???WRR? ? ? ? ?
> > ? ? ???08
> > ? ? ???03? ? ?
> > ???WRR? ? ? ? ?
> > ? ? ???08
> > ? ? ???04? ? ?
> > ???Priority? ? ? ? ?
> > ? 01
> > 
> > ? ? WRR bandwidth ratios:? 100[queue 1]
> > 150[queue 2] 200[queue 3]
> > ? ? queue-limit ratios:?
> > ???50[queue 1]? 20[queue 2]?
> > 15[queue 3]? 15[Pri Queue]
> > 
> > <<<snip>>>
> > 
> > ? Packets dropped on Transmit:
> > 
> > ? ? queue? ???dropped?
> > [cos-map]
> > ? ?
> > ---------------------------------------------
> > ? ? 1? ? ? ? ? ?
> > ? ? ???719527? [0 1 ]
> > ? ? 2? ? ? ? ? ?
> > ? ? ? ? ? ? 0? [2 3 4 ]
> > ? ? 3? ? ? ? ? ?
> > ? ? ? ? ? ? 0? [6 7 ]
> > ? ? 4? ? ? ? ? ?
> > ? ? ? ? ? ? 0? [5 ]
> > 
> > So it would appear all of my traffic goes into queue
> > 1.? It would also seem
> > that 50% buffers for queue 1 isn't enough?? These are
> > the default settings by
> > the way.
> > 
> > I'm pretty sure that wrr-queue queue-limit and wrr-queue
> > bandwidth should help
> > us mitigate this frustrating packet loss, but I've no
> > experience and would
> > like some insight and suggestions before I start making
> > changes.? I am totally
> > unfamiliar with these features (I come from Foundry/Brocade
> > background) and
> > would like any suggestions or advise you might have before
> > I try anything that
> > could risk downtime or further issues in a production
> > environment.
> > 
> > And lastly, would changing the queue settings cause BGP to
> > drop or anything
> > else unexpected (like changing flow control would reset the
> > interface, ect)?
> > 
> > Thank you!
> > 
> > --
> > Randy
> > www.FastServ.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/
> >
------- End of Original Message -------


From jashton at esnet.com  Mon Jul 13 09:49:14 2009
From: jashton at esnet.com (James Ashton)
Date: Mon, 13 Jul 2009 09:49:14 -0400
Subject: [c-nsp] Mac address flapping..
In-Reply-To: <383357750907130606l11cec06fpdc22821f5339bcb5@mail.gmail.com>
References: <383357750907101219y6d8051b3g8f0bed7697a1eae7@mail.gmail.com>
	<490B0AB46362B947A2947D5CB5E7F2A105AE00E79E@exchange.esnet.com>
	<4A5A7150.3050408@cisco.com> <20090713092043.GC27721@lboro.ac.uk>
	<383357750907130606l11cec06fpdc22821f5339bcb5@mail.gmail.com>
Message-ID: <490B0AB46362B947A2947D5CB5E7F2A105AE006724@exchange.esnet.com>

The most confusing thing is..   The Mac that is flapping is the Mac address for the vlan interface (VLan 42 of course) from 6509-b.   But I am only seeing the log entries on 6509-a.


I am looking at the entire path of the vlan now.  Maybe it is patched into another vlan at some point that I am not aware of....    
That would make life SOOO much easier...  If its not.  Then I think I am left with IOS bug...


James

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Mateusz Blaszczyk
Sent: Monday, July 13, 2009 9:07 AM
To: A.L.M.Buxey at lboro.ac.uk
Cc: Lincoln Dale; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Mac address flapping..

Alan,

But why only 1 MAC is flapping?

HSRP sends dest-mac as multicast address so there are clearly 2 paths
between these switches.
Unless the connection is unidrecional somehow, how on earth he doesn't
see same on second 6509-b?

It's confusing.

-mat

2009/7/13  <A.L.M.Buxey at lboro.ac.uk>:
> hi,
>
>
> i originally thought on the same lines too - but then having
> been told this still happens if theres only one link
> to the 4500s to the client - which makes the 6506-b almost
> a router at the end of a stick for that network things started
> to look a little 'wonky'. ?it wouldnt be taking traffic from
> another port(?).
>
> as far as i now see, you have 2 routers, A and B. ? A has the feed to
> the switch (and the only physical link to the customer) whilst
> B is connected to A via a portchannel and trunk link. a MAC for
> vlan042 is still flipping between the down-link from A and the
> link from A to B. ?now, from my deepest memories I've seen this sort
> of thing happen on our campus in the past... i've got some feeling that
> somewhere, that VLAN is being fed into your network as another VLAN
> and therefore the AMC is squirting back out and through - eg native vlan 042
> is patched to vlan 1 or somesuch elsewhere, therefore the MAC is seen
> coming back t;other way
>
> 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 jashton at esnet.com  Mon Jul 13 11:14:41 2009
From: jashton at esnet.com (James Ashton)
Date: Mon, 13 Jul 2009 11:14:41 -0400
Subject: [c-nsp] Mac address flapping..
In-Reply-To: <490B0AB46362B947A2947D5CB5E7F2A105AE006724@exchange.esnet.com>
References: <383357750907101219y6d8051b3g8f0bed7697a1eae7@mail.gmail.com>
	<490B0AB46362B947A2947D5CB5E7F2A105AE00E79E@exchange.esnet.com>
	<4A5A7150.3050408@cisco.com> <20090713092043.GC27721@lboro.ac.uk>
	<383357750907130606l11cec06fpdc22821f5339bcb5@mail.gmail.com>
	<490B0AB46362B947A2947D5CB5E7F2A105AE006724@exchange.esnet.com>
Message-ID: <490B0AB46362B947A2947D5CB5E7F2A105AE006728@exchange.esnet.com>

Alan,

You guessed it.   The customer had vlan 42 and another vlan tied together in their switch.  That?s where the errors were coming from.


Thanks for all of the ideas.

James



-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of James Ashton
Sent: Monday, July 13, 2009 9:49 AM
To: Mateusz Blaszczyk
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Mac address flapping..

The most confusing thing is..   The Mac that is flapping is the Mac address for the vlan interface (VLan 42 of course) from 6509-b.   But I am only seeing the log entries on 6509-a.


I am looking at the entire path of the vlan now.  Maybe it is patched into another vlan at some point that I am not aware of....    
That would make life SOOO much easier...  If its not.  Then I think I am left with IOS bug...


James

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Mateusz Blaszczyk
Sent: Monday, July 13, 2009 9:07 AM
To: A.L.M.Buxey at lboro.ac.uk
Cc: Lincoln Dale; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Mac address flapping..

Alan,

But why only 1 MAC is flapping?

HSRP sends dest-mac as multicast address so there are clearly 2 paths
between these switches.
Unless the connection is unidrecional somehow, how on earth he doesn't
see same on second 6509-b?

It's confusing.

-mat

2009/7/13  <A.L.M.Buxey at lboro.ac.uk>:
> hi,
>
>
> i originally thought on the same lines too - but then having
> been told this still happens if theres only one link
> to the 4500s to the client - which makes the 6506-b almost
> a router at the end of a stick for that network things started
> to look a little 'wonky'. ?it wouldnt be taking traffic from
> another port(?).
>
> as far as i now see, you have 2 routers, A and B. ? A has the feed to
> the switch (and the only physical link to the customer) whilst
> B is connected to A via a portchannel and trunk link. a MAC for
> vlan042 is still flipping between the down-link from A and the
> link from A to B. ?now, from my deepest memories I've seen this sort
> of thing happen on our campus in the past... i've got some feeling that
> somewhere, that VLAN is being fed into your network as another VLAN
> and therefore the AMC is squirting back out and through - eg native vlan 042
> is patched to vlan 1 or somesuch elsewhere, therefore the MAC is seen
> coming back t;other way
>
> alan
> _______________________________________________
> cisco-nsp mailing list ?cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From A.L.M.Buxey at lboro.ac.uk  Mon Jul 13 11:39:10 2009
From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk)
Date: Mon, 13 Jul 2009 16:39:10 +0100
Subject: [c-nsp] Mac address flapping..
In-Reply-To: <490B0AB46362B947A2947D5CB5E7F2A105AE006728@exchange.esnet.com>
References: <383357750907101219y6d8051b3g8f0bed7697a1eae7@mail.gmail.com>
	<490B0AB46362B947A2947D5CB5E7F2A105AE00E79E@exchange.esnet.com>
	<4A5A7150.3050408@cisco.com> <20090713092043.GC27721@lboro.ac.uk>
	<383357750907130606l11cec06fpdc22821f5339bcb5@mail.gmail.com>
	<490B0AB46362B947A2947D5CB5E7F2A105AE006724@exchange.esnet.com>
	<490B0AB46362B947A2947D5CB5E7F2A105AE006728@exchange.esnet.com>
Message-ID: <20090713153910.GA7232@lboro.ac.uk>

Hi,

> You guessed it.   The customer had vlan 42 and another vlan tied together in their switch.  That?s where the errors were coming from.
> 
> 
> Thanks for all of the ideas.

yay - I get a +1 NSP score - thats cool you've sorted it anyway.

and anyway - this thread has been VERY useful to me anyway
because of a couple of the URLs that got posted regarding platform
limits

alan

From paul at paulstewart.org  Mon Jul 13 12:19:42 2009
From: paul at paulstewart.org (Paul Stewart)
Date: Mon, 13 Jul 2009 12:19:42 -0400
Subject: [c-nsp] Power Upgrade 7600
Message-ID: <000001ca03d5$c7e6ceb0$57b46c10$@org>

Hey folks..

 

Does anyone know how the 7600 chassis (7606) handles power inbalance?  To
explain a bit more, we have a pair of 2700Watt DC power supplies in a 7606
that needs to be upgraded soon.  To avoid downtime, we are looking at
upgrading one side and then the other.  They are running redundant mode
currently.

 

So, can you install a larger power supply on one side and then the other
without any effect?

 

Thanks in advance,

 

Paul

 

 

 


From petelists at templin.org  Mon Jul 13 11:28:23 2009
From: petelists at templin.org (Pete Templin)
Date: Mon, 13 Jul 2009 10:28:23 -0500
Subject: [c-nsp] Extended demarc
In-Reply-To: <b7f636a60907081440n2433cc7fqa0071d364a696ef9@mail.gmail.com>
References: <b7f636a60907081440n2433cc7fqa0071d364a696ef9@mail.gmail.com>
Message-ID: <4A5B5297.8080804@templin.org>

james edwards wrote:
> What is a real word limit on how far you can extend the demarc ? This is on
> Cat5e cable. I get wildly different figures from Google.

Late to the dance, so blame my vacation...

For T1s, Kentrox had a great white paper showing that you can go 
1000-2000 feet on Cat5 cable.  To go farther, up to about 6000', you'd 
need individually-shielded twisted pair cable (ISTP), to keep the 
transmit-motivated electrons from corrupting the wimpy receive-side 
electrons on the nearby pair.

pt


From swmike at swm.pp.se  Mon Jul 13 12:54:18 2009
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Mon, 13 Jul 2009 18:54:18 +0200 (CEST)
Subject: [c-nsp] Power Upgrade 7600
In-Reply-To: <000001ca03d5$c7e6ceb0$57b46c10$@org>
References: <000001ca03d5$c7e6ceb0$57b46c10$@org>
Message-ID: <alpine.DEB.1.10.0907131853050.18237@uplift.swm.pp.se>

On Mon, 13 Jul 2009, Paul Stewart wrote:

> So, can you install a larger power supply on one side and then the other 
> without any effect?

Yes, but you have to switch it to combined power mode before putting in 
the higher rated one, power it up, check that everything looks ok, take 
out the smaller one, put in the equivalent other bigger one, check that 
everything looks ok, then switch back to redundant mode.

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

From adrian.minta at gmail.com  Mon Jul 13 13:25:10 2009
From: adrian.minta at gmail.com (Adrian Minta)
Date: Mon, 13 Jul 2009 20:25:10 +0300
Subject: [c-nsp] IGMP snooping ME6500
In-Reply-To: <200907122233.n6CMXEVC020066@sj-core-5.cisco.com>
References: <4A58D9D4.8030205@gmail.com>
	<20090712141147.GA31466@wildfire.net.ic.ac.uk>
	<4A5A2187.3050303@gmail.com>
	<200907121821.n6CILLVV013502@sj-core-1.cisco.com>
	<4A5A2E33.3080902@gmail.com>
	<200907122233.n6CMXEVC020066@sj-core-5.cisco.com>
Message-ID: <4A5B6DF6.6080709@gmail.com>

Tim Stevenson wrote:
> Note that you can have a pim-enabled interface with ip 
> multicast-routing disabled and that should work too - though then the 
> RP CPU will be setting up state (at L3) for no particularly good 
> reason. The querier function is to avoid all that. Let us know if it 
> improves things.
>
> Tim
>
No, It didn't do any good :(

Right now this is my config:
!
vlan 200
 name ipTV1
!
vlan 201
 name ipTV2
!
...
!
interface Vlan200
 ip address 10.201.0.2 255.255.255.0
 ip igmp snooping querier
 shutdown
end
!
interface Vlan201
 ip address 10.201.1.2 255.255.255.0
 ip igmp snooping querier
 shutdown
end

A switch linked with ME6500 by a trunk still receive all the active iptv 
traffic, even if the above vlans are not even present on his config.

-- 
Best regards,
Adrian Minta    MA3173-RIPE, MA314-ROTLD, www.minta.ro 




From alasdairm at gmail.com  Mon Jul 13 13:32:28 2009
From: alasdairm at gmail.com (Alasdair McWilliam)
Date: Mon, 13 Jul 2009 18:32:28 +0100
Subject: [c-nsp] VSS out-of-band mgmt
In-Reply-To: <A9C0DC3E3383224B83C528B074390E8C129756@xmail04.ad.ua.ac.be>
References: <A9C0DC3E3383224B83C528B074390E8C129756@xmail04.ad.ua.ac.be>
Message-ID: <D718CB87-D418-4553-8BC1-A4E1E7DFC7CE@gmail.com>

Yes, a "management" VRF will do exactly what you want :-)

Al




On 13 Jul 2009, at 13:03, Holemans Wim wrote:

> I have a VSS router that I want to do some out-of-band mgmt with. Is
> this possible with VRF-lite ? I would like to build a channel with the
> UTP ports on the sup720, give the VSS an address on this trunk but  
> keep
> this interface out of the standard routing table. Can this be done  
> with
> VRF-lite ? Or is there another way to do out-of-band mgmt of a VSS
> cluster?
>
>
>
> Greetings,
>
>
>
> Wim Holemans
>
> Netwerkdienst Universiteit Antwerpen
>
>
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


From tstevens at cisco.com  Mon Jul 13 13:36:34 2009
From: tstevens at cisco.com (Tim Stevenson)
Date: Mon, 13 Jul 2009 11:36:34 -0600
Subject: [c-nsp] IGMP snooping ME6500
In-Reply-To: <4A5B6DF6.6080709@gmail.com>
References: <4A58D9D4.8030205@gmail.com>
	<20090712141147.GA31466@wildfire.net.ic.ac.uk>
	<4A5A2187.3050303@gmail.com>
	<200907121821.n6CILLVV013502@sj-core-1.cisco.com>
	<4A5A2E33.3080902@gmail.com>
	<200907122233.n6CMXEVC020066@sj-core-5.cisco.com>
	<4A5B6DF6.6080709@gmail.com>
Message-ID: <200907131739.n6DHcxex025885@sj-core-1.cisco.com>

Please do a sh ip igmp snooping mrouter - is the trunk being learned 
as a mrouter port? Note that mrouter ports get all multicast traffic 
for all groups.

Tim

At 11:25 AM 7/13/2009, Adrian Minta asserted:

>Tim Stevenson wrote:
> > Note that you can have a pim-enabled interface with ip
> > multicast-routing disabled and that should work too - though then the
> > RP CPU will be setting up state (at L3) for no particularly good
> > reason. The querier function is to avoid all that. Let us know if it
> > improves things.
> >
> > Tim
> >
>No, It didn't do any good :(
>
>Right now this is my config:
>!
>vlan 200
>  name ipTV1
>!
>vlan 201
>  name ipTV2
>!
>...
>!
>interface Vlan200
>  ip address 10.201.0.2 255.255.255.0
>  ip igmp snooping querier
>  shutdown
>end
>!
>interface Vlan201
>  ip address 10.201.1.2 255.255.255.0
>  ip igmp snooping querier
>  shutdown
>end
>
>A switch linked with ME6500 by a trunk still receive all the active iptv
>traffic, even if the above vlans are not even present on his config.
>
>--
>Best regards,
>Adrian Minta    MA3173-RIPE, MA314-ROTLD, www.minta.ro
>
>




Tim Stevenson, tstevens at cisco.com
Routing & Switching CCIE #5561
Technical Marketing Engineer, Cisco Nexus 7000
Cisco - http://www.cisco.com
IP Phone: 408-526-6759
********************************************************
The contents of this message may be *Cisco Confidential*
and are intended for the specified recipients only.

From adrian.minta at gmail.com  Mon Jul 13 14:01:14 2009
From: adrian.minta at gmail.com (Adrian Minta)
Date: Mon, 13 Jul 2009 21:01:14 +0300
Subject: [c-nsp] IGMP snooping ME6500
In-Reply-To: <200907131739.n6DHcxex025885@sj-core-1.cisco.com>
References: <4A58D9D4.8030205@gmail.com>
	<20090712141147.GA31466@wildfire.net.ic.ac.uk>
	<4A5A2187.3050303@gmail.com>
	<200907121821.n6CILLVV013502@sj-core-1.cisco.com>
	<4A5A2E33.3080902@gmail.com>
	<200907122233.n6CMXEVC020066@sj-core-5.cisco.com>
	<4A5B6DF6.6080709@gmail.com>
	<200907131739.n6DHcxex025885@sj-core-1.cisco.com>
Message-ID: <4A5B766A.3040104@gmail.com>

Tim Stevenson wrote:
> Please do a sh ip igmp snooping mrouter - is the trunk being learned 
> as a mrouter port? Note that mrouter ports get all multicast traffic 
> for all groups.
>
> Tim

#sh ip igmp snooping mrouter
vlan            ports
-----+----------------------------------------
 200  Gi1/26
 201  Gi1/26
 202  Gi1/26

IPtv router is on interface Gi1/26. This is good
On Gig 1/29 we have one of the "victim" switches without  200-202 vlans. 
On peak hour more than 250Mbps of traffic flood the victim without going 
out on any port. Luckily it doesn't go to the victim CPU.

-- 
Best regards,
Adrian Minta    MA3173-RIPE, MA314-ROTLD, www.minta.ro 




From gtb at slac.stanford.edu  Mon Jul 13 13:47:39 2009
From: gtb at slac.stanford.edu (Buhrmaster, Gary)
Date: Mon, 13 Jul 2009 10:47:39 -0700
Subject: [c-nsp] VSS out-of-band mgmt
In-Reply-To: <D718CB87-D418-4553-8BC1-A4E1E7DFC7CE@gmail.com>
References: <A9C0DC3E3383224B83C528B074390E8C129756@xmail04.ad.ua.ac.be>
	<D718CB87-D418-4553-8BC1-A4E1E7DFC7CE@gmail.com>
Message-ID: <D0D0330CBD07114D85B70B784E80C2F2022FD332@exch-mail2.win.slac.stanford.edu>

> Yes, a "management" VRF will do exactly what you want :-)

Perhaps things have improved, but at one time for the 6500
platform certain functions could only be performed in the
"native"(? is that the right word) context, and you needed
to place all the rest of your traffic/interfaces in a VRF
leaving the "native" context for management (sort of the
reverse of your proposal, instead have a "Internet" VRF
for everything except for management).

Have the latest IOS versions eliminated those challenges
on the 6500?

Gary

From peter at rathlev.dk  Mon Jul 13 15:32:10 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Mon, 13 Jul 2009 21:32:10 +0200
Subject: [c-nsp] VSS out-of-band mgmt
In-Reply-To: <D0D0330CBD07114D85B70B784E80C2F2022FD332@exch-mail2.win.slac.stanford.edu>
References: <A9C0DC3E3383224B83C528B074390E8C129756@xmail04.ad.ua.ac.be>
	<D718CB87-D418-4553-8BC1-A4E1E7DFC7CE@gmail.com>
	<D0D0330CBD07114D85B70B784E80C2F2022FD332@exch-mail2.win.slac.stanford.edu>
Message-ID: <1247513530.4661.14.camel@abehat.net.rm.dk>

On Mon, 2009-07-13 at 10:47 -0700, Buhrmaster, Gary wrote:
> Perhaps things have improved, but at one time for the 6500
> platform certain functions could only be performed in the
> "native"(? is that the right word) context, and you needed
> to place all the rest of your traffic/interfaces in a VRF
> leaving the "native" context for management (sort of the
> reverse of your proposal, instead have a "Internet" VRF
> for everything except for management).
> 
> Have the latest IOS versions eliminated those challenges
> on the 6500?

Not that I know of. RADIUS og SNMP can take a VRF argument but neither
of syslogging, TACACS or Netflow can AFAICT. It doesn't seem to have
changed between SXF and SXI.

OTOH a serial OOB method couldn't easily transport these protocols
either.

Regards,
Peter



From peter at rathlev.dk  Mon Jul 13 14:31:21 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Mon, 13 Jul 2009 20:31:21 +0200
Subject: [c-nsp] VSS out-of-band mgmt
In-Reply-To: <A9C0DC3E3383224B83C528B074390E8C129756@xmail04.ad.ua.ac.be>
References: <A9C0DC3E3383224B83C528B074390E8C129756@xmail04.ad.ua.ac.be>
Message-ID: <1247509881.4661.5.camel@abehat.net.rm.dk>

On Mon, 2009-07-13 at 14:03 +0200, Holemans Wim wrote:
> I have a VSS router that I want to do some out-of-band mgmt with. Is
> this possible with VRF-lite ? I would like to build a channel with the
> UTP ports on the sup720, give the VSS an address on this trunk but
> keep this interface out of the standard routing table. Can this be
> done with VRF-lite ? Or is there another way to do out-of-band mgmt of
> a VSS cluster? 

Remember that if you want to manage the device from a VRF and use ACLs
on your VTYs, you need the "vrf-also" statement to actually accept
traffic from VRFs at all:

And otherwise yes, just create a VRF without route-target statements and
include only your specific management interface in this VRF, with a
default route pointing out of there. So something along the lines of:

ip vrf management
 rd 64512:1
 exit
!
interface GigabitEthernet5/1
 description OOB Management
 no switchport
 ip vrf forwarding management
 ip address 10.0.0.10 255.255.255.0
 no shutdown
 exit
!
ip route vrf management 0.0.0.0 0.0.0.0 GigabitEthernet5/1 10.0.0.10
!
access-list 99 permit 172.16.0.0 0.0.0.255
!
line vty 0 15
 access-class 99 in vrf-also
 exit
!


Regards,
Peter



From jared at puck.nether.net  Mon Jul 13 15:45:33 2009
From: jared at puck.nether.net (Jared Mauch)
Date: Mon, 13 Jul 2009 15:45:33 -0400
Subject: [c-nsp] "Software Download Area is Unavailable at this time"
Message-ID: <9DE84313-097E-4D4C-A118-084AC527217D@puck.nether.net>

We apologize for any inconvenience. Software Download Area is  
unavailable at this time.


New enhanced features for downloading software have arrived.
Get a sneak preview here.


If you are receiving an Error while downloading software and used a  
home address in your profile, please provide your business address to  
correct the error and gain access to download the software.



-- snip --



Anynone know how Cisco intends to distribute software?  This seems to  
be the lead-in deployment for making software unavailable for me.



	- Jared



From tstevens at cisco.com  Mon Jul 13 15:47:40 2009
From: tstevens at cisco.com (Tim Stevenson)
Date: Mon, 13 Jul 2009 13:47:40 -0600
Subject: [c-nsp] IGMP snooping ME6500
In-Reply-To: <4A5B766A.3040104@gmail.com>
References: <4A58D9D4.8030205@gmail.com>
	<20090712141147.GA31466@wildfire.net.ic.ac.uk>
	<4A5A2187.3050303@gmail.com>
	<200907121821.n6CILLVV013502@sj-core-1.cisco.com>
	<4A5A2E33.3080902@gmail.com>
	<200907122233.n6CMXEVC020066@sj-core-5.cisco.com>
	<4A5B6DF6.6080709@gmail.com>
	<200907131739.n6DHcxex025885@sj-core-1.cisco.com>
	<4A5B766A.3040104@gmail.com>
Message-ID: <200907131947.n6DJlfEq002357@sj-core-5.cisco.com>

Ok - if you have mrouter ports being learned, then the upstream 
router should be sending IGMP queries already & IGMP snooping querier 
is not required.

You may want to check the igmp snooping stats & see what type of 
joins etc are being seen on 1/26. Also what is the downstream switch 
doing from a snooping standpoint?

Probably you should just open a case w/TAC to get to the bottom of this one.
Tim

At 12:01 PM 7/13/2009, Adrian Minta asserted:

>Tim Stevenson wrote:
> > Please do a sh ip igmp snooping mrouter - is the trunk being learned
> > as a mrouter port? Note that mrouter ports get all multicast traffic
> > for all groups.
> >
> > Tim
>
>#sh ip igmp snooping mrouter
>vlan            ports
>-----+----------------------------------------
>  200  Gi1/26
>  201  Gi1/26
>  202  Gi1/26
>
>IPtv router is on interface Gi1/26. This is good
>On Gig 1/29 we have one of the "victim" switches without  200-202 vlans.
>On peak hour more than 250Mbps of traffic flood the victim without going
>out on any port. Luckily it doesn't go to the victim CPU.
>
>--
>Best regards,
>Adrian Minta    MA3173-RIPE, MA314-ROTLD, www.minta.ro
>
>




Tim Stevenson, tstevens at cisco.com
Routing & Switching CCIE #5561
Technical Marketing Engineer, Cisco Nexus 7000
Cisco - http://www.cisco.com
IP Phone: 408-526-6759
********************************************************
The contents of this message may be *Cisco Confidential*
and are intended for the specified recipients only.

From christian at automatick.net  Mon Jul 13 16:18:51 2009
From: christian at automatick.net (Christian Koch)
Date: Mon, 13 Jul 2009 13:18:51 -0700
Subject: [c-nsp] "Software Download Area is Unavailable at this time"
In-Reply-To: <9DE84313-097E-4D4C-A118-084AC527217D@puck.nether.net>
References: <9DE84313-097E-4D4C-A118-084AC527217D@puck.nether.net>
Message-ID: <c4d480f60907131318m279fbbe4l87823b18c8234db2@mail.gmail.com>

I am still able to DL code via FTP , their web UI stinks anyways.. why
bother?

On Mon, Jul 13, 2009 at 12:45 PM, Jared Mauch <jared at puck.nether.net> wrote:

> We apologize for any inconvenience. Software Download Area is unavailable
> at this time.
>
>
> New enhanced features for downloading software have arrived.
> Get a sneak preview here.
>
>
> If you are receiving an Error while downloading software and used a home
> address in your profile, please provide your business address to correct the
> error and gain access to download the software.
>
>
>
> -- snip --
>
>
>
> Anynone know how Cisco intends to distribute software?  This seems to be
> the lead-in deployment for making software unavailable for me.
>
>
>
>        - Jared
>
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From Jeff.Munoz at swinc.com  Mon Jul 13 16:14:41 2009
From: Jeff.Munoz at swinc.com (Munoz, Jeff)
Date: Mon, 13 Jul 2009 15:14:41 -0500
Subject: [c-nsp] ASA IPsec Tunnel Failover
Message-ID: <D6147B25080EEE458FE5BEEE7B280F5D3C5D5B6720@exch01.austin.swinc.com>

Hey guys, I have two main sites (site A and site B) and one remote site (site C).  Sites A and B have a metroethernet connection between them.  Remote site C has an IPsec tunnel back to site A.  I'd like to setup failover so in case site A's ASA is down the remote site C ASA sends the interesting traffic down the site B IPsec tunnel.  Unfortunately, it will always match the tunnel to site A since the phase 2 access lists have the same source/destinations.  Any ideas on how I can do this?

Thanks!

Jeff

From peter at rathlev.dk  Mon Jul 13 17:04:37 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Mon, 13 Jul 2009 23:04:37 +0200
Subject: [c-nsp] "Software Download Area is Unavailable at this time"
In-Reply-To: <9DE84313-097E-4D4C-A118-084AC527217D@puck.nether.net>
References: <9DE84313-097E-4D4C-A118-084AC527217D@puck.nether.net>
Message-ID: <1247519077.4661.46.camel@abehat.net.rm.dk>

On Mon, 2009-07-13 at 15:45 -0400, Jared Mauch wrote:
> We apologize for any inconvenience. Software Download Area is  
> unavailable at this time.

Same here.

> New enhanced features for downloading software have arrived.
> Get a sneak preview here.

That video almost made me puke when I saw it first.

> Anynone know how Cisco intends to distribute software?  This seems to  
> be the lead-in deployment for making software unavailable for me.

I just finished writing a 2500 character rant to our AM asking him to
deliver the message to the relevant people at Cisco. As soon as my boss
accepts the wording I will send it.

Whereas I previously thought "oh a little javascript is no big deal" I
can now clearly see how this will end up making our daily routines near
impossible.

Regards,
Peter



From nrauhauser at gmail.com  Mon Jul 13 17:10:44 2009
From: nrauhauser at gmail.com (neal rauhauser)
Date: Mon, 13 Jul 2009 16:10:44 -0500
Subject: [c-nsp] disable break on boot for IOS??
Message-ID: <9515c62d0907131410o696872b9ya8e927cbd52885f4@mail.gmail.com>

   I have a situation with a former employee who still has legitimate
physical access to a shared space where we have some Cisco equipment. Today
one of our field guys located a UBR924 attached to our cable modem plant
with the cutest little rogue Linux machine attached to its ethernet port.

   I had them recover the router's password as the first step and now I'm
puzzling over this:

http://www.cisco.com/en/US/products/hw/routers/ps133/products_tech_note09186a008022493f.shtml


   I recall that a machine can be set such that the break during boot will
not permit password recovery, but it isn't clear to me how I do it. I'd
really like to get this machine secured so I can dig in to what he is doing.
I'd already isolated this cable plant because I knew intrusion was possible
but I want to see what other mischief he uses our facilities for - a little
spice for the already meaty intrusion case against him this spring.

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

From jared at puck.nether.net  Mon Jul 13 17:11:20 2009
From: jared at puck.nether.net (Jared Mauch)
Date: Mon, 13 Jul 2009 17:11:20 -0400
Subject: [c-nsp] "Software Download Area is Unavailable at this time"
In-Reply-To: <c4d480f60907131318m279fbbe4l87823b18c8234db2@mail.gmail.com>
References: <9DE84313-097E-4D4C-A118-084AC527217D@puck.nether.net>
	<c4d480f60907131318m279fbbe4l87823b18c8234db2@mail.gmail.com>
Message-ID: <D9CCCA31-F015-4357-AE19-A7AAE0E6D458@puck.nether.net>

Crypto software is not available via FTP.

Jared Mauch

On Jul 13, 2009, at 4:18 PM, Christian Koch <christian at automatick.net>  
wrote:

> I am still able to DL code via FTP , their web UI stinks anyways..  
> why bother?
>
> On Mon, Jul 13, 2009 at 12:45 PM, Jared Mauch  
> <jared at puck.nether.net> wrote:
> We apologize for any inconvenience. Software Download Area is  
> unavailable at this time.
>
>
> New enhanced features for downloading software have arrived.
> Get a sneak preview here.
>
>
> If you are receiving an Error while downloading software and used a  
> home address in your profile, please provide your business address  
> to correct the error and gain access to download the software.
>
>
>
> -- snip --
>
>
>
> Anynone know how Cisco intends to distribute software?  This seems  
> to be the lead-in deployment for making software unavailable for me.
>
>
>
>        - Jared
>
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From A.L.M.Buxey at lboro.ac.uk  Mon Jul 13 17:27:24 2009
From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk)
Date: Mon, 13 Jul 2009 22:27:24 +0100
Subject: [c-nsp] disable break on boot for IOS??
In-Reply-To: <9515c62d0907131410o696872b9ya8e927cbd52885f4@mail.gmail.com>
References: <9515c62d0907131410o696872b9ya8e927cbd52885f4@mail.gmail.com>
Message-ID: <20090713212724.GC14413@lboro.ac.uk>

Hi,

>    I have a situation with a former employee who still has legitimate
> physical access to a shared space where we have some Cisco equipment. Today
> one of our field guys located a UBR924 attached to our cable modem plant
> with the cutest little rogue Linux machine attached to its ethernet port.

do you have any proof on the install time of this box?
it could have been a legitimate install done during their time
at your place - and may have been used for eg remote access login
during times of issue - especially if the place has draconian
law about supported/allowed devices. i have several Linux boxes
that have saved my bacon countless times with their serial
interface.
 
>    I recall that a machine can be set such that the break during boot will
> not permit password recovery, but it isn't clear to me how I do it. I'd

disabling password recovery? its a one-way process - once done there is no way
back.... TACACS+ authentication is a way to handle all authentication
via vty/con/etc. if password recovery mech is set there is no way to unset it
without a visit to the factory.

> really like to get this machine secured so I can dig in to what he is doing.

grab the linux box and use many of the boot CD methods to get access.
read the shell history, see the tools present etc.

alan

From mhuff at ox.com  Mon Jul 13 17:31:10 2009
From: mhuff at ox.com (Matthew Huff)
Date: Mon, 13 Jul 2009 17:31:10 -0400
Subject: [c-nsp] disable break on boot for IOS??
In-Reply-To: <9515c62d0907131410o696872b9ya8e927cbd52885f4@mail.gmail.com>
References: <9515c62d0907131410o696872b9ya8e927cbd52885f4@mail.gmail.com>
Message-ID: <483E6B0272B0284BA86D7596C40D29F9D122127F07@PUR-EXCH07.ox.com>

If you are running a newer IOS and newer ROMMON you can disable password-recover (i.e. break during boot) using "no service password-recovery". Make sure to read http://www.cisco.com/en/US/docs/ios/12_3/12_3y/12_3ya8/gtnsvpwd.html completely, you can brick a router otherwise.




----
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 neal rauhauser
> Sent: Monday, July 13, 2009 5:11 PM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] disable break on boot for IOS??
>
>    I have a situation with a former employee who still has legitimate
> physical access to a shared space where we have some Cisco equipment.
> Today
> one of our field guys located a UBR924 attached to our cable modem
> plant
> with the cutest little rogue Linux machine attached to its ethernet
> port.
>
>    I had them recover the router's password as the first step and now
> I'm
> puzzling over this:
>
> http://www.cisco.com/en/US/products/hw/routers/ps133/products_tech_note
> 09186a008022493f.shtml
>
>
>    I recall that a machine can be set such that the break during boot
> will
> not permit password recovery, but it isn't clear to me how I do it. I'd
> really like to get this machine secured so I can dig in to what he is
> doing.
> I'd already isolated this cable plant because I knew intrusion was
> possible
> but I want to see what other mischief he uses our facilities for - a
> little
> spice for the already meaty intrusion case against him this spring.
>
> --
> mailto:Neal at layer3arts.com //
> GoogleTalk: nrauhauser at gmail.com
> IM: nealrauhauser
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

From nicolas.rolans at gmail.com  Mon Jul 13 17:38:20 2009
From: nicolas.rolans at gmail.com (Nicolas Rolans)
Date: Mon, 13 Jul 2009 23:38:20 +0200
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <9DE4AA6876D44B62B87C475B2AFE5514@au.didata.local>
References: <9DE4AA6876D44B62B87C475B2AFE5514@au.didata.local>
Message-ID: <a1873f1f0907131438m3f0b4c70r82a953a29042b6d7@mail.gmail.com>

This supportwiki
article<http://supportwiki.cisco.com/ViewWiki/index.php/The_%22PM-SP-4-LIMITS:%22_or_%22PM-SP-STDBY-4-LIMITS:%22_error_message_is_received_in_Catalyst_switches_that_run_Cisco_IOS_Software>could
be what you're looking for. I confirm the 1800 instances/slot limit.

-Nicolas


2009/7/12 Shine Joseph <shinejoseph at dodo.com.au>

> Hi,
>
> I searched in the archives if I could find the answer to my this query. =
> The result was negative.
>
> How many spanning-tree instances are possible in Rapid PVST+ and MST =
> modes in Cisco 6500 series switches with Sup720?
>
> The only documentation that I could see which says about total number of =
> virtual ports per line card and total active logical ports. There is no =
> reference to  number of instances.
>
> The following netpro link mentions about 4096 instances, but this point =
> is not validated.
> http://forums.cisco.com/eforum/servlet/NetProf?page=3Dnetprof&forum=3DNet=
>
> work%20Infrastructure&topic=3DLAN%2C%20Switching%20and%20Routing&topicID=3D=
> .ee71a04&CommCmd=3DMB%3Fcmd%3Dpass_through%26location%3Doutline%40%5E1%40=<http://forums.cisco.com/eforum/servlet/NetProf?page=3Dnetprof&forum=3DNet=%0Awork%20Infrastructure&topic=3DLAN%2C%20Switching%20and%20Routing&topicID=3D=%0A.ee71a04&CommCmd=3DMB%3Fcmd%3Dpass_through%26location%3Doutline%40%5E1%40=>
> %40.2cc1484e/2#selected_message
>
> Any links or pointers would be much appreciated.
>
> Thanks in advance,
> Shine
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From cordmacleod at gmail.com  Mon Jul 13 18:04:38 2009
From: cordmacleod at gmail.com (Cord MacLeod)
Date: Mon, 13 Jul 2009 15:04:38 -0700
Subject: [c-nsp] multiple vlans on a port
Message-ID: <98E30C61-3FE0-4FF6-8B1D-C11023E0F4C8@gmail.com>

I realize this is impossible, at least I have read it is on an access  
port.  So if I sent up a trunk port with the machine, does the machine  
need to speak 802.1q as well?

interface GigabitEthernet0/15
  switchport access vlan 120
  switchport trunk native vlan 120
  switchport trunk allowed vlan 100,120,231,321
  switchport mode trunk
end

The purpose of this is that the machine in a Linux machine running  
Xen, so the cloud will decide what machines and vlans it needs to spin  
up at what time.  Meaning this port will need access to these vlans.   
This being the case, will I need to configure the Linux machine for  
802.1q trunking as well?  I found this article that seemed to suggest,  
yes, but I wanted a second opinion.  http://www.linuxjournal.com/article/7268

Thanks for your help.

From moua0100 at umn.edu  Mon Jul 13 18:07:37 2009
From: moua0100 at umn.edu (Ge Moua)
Date: Mon, 13 Jul 2009 17:07:37 -0500
Subject: [c-nsp] multiple vlans on a port
In-Reply-To: <98E30C61-3FE0-4FF6-8B1D-C11023E0F4C8@gmail.com>
References: <98E30C61-3FE0-4FF6-8B1D-C11023E0F4C8@gmail.com>
Message-ID: <4A5BB029.7070702@umn.edu>

Yes, I've done this on a few Xen boxes myself; contact me off-line and I 
can send you my install notes.

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

Network Design Engineer
University of Minnesota | Networking & Telecommunications Services



Cord MacLeod wrote:
> I realize this is impossible, at least I have read it is on an access 
> port.  So if I sent up a trunk port with the machine, does the machine 
> need to speak 802.1q as well?
>
> interface GigabitEthernet0/15
>  switchport access vlan 120
>  switchport trunk native vlan 120
>  switchport trunk allowed vlan 100,120,231,321
>  switchport mode trunk
> end
>
> The purpose of this is that the machine in a Linux machine running 
> Xen, so the cloud will decide what machines and vlans it needs to spin 
> up at what time.  Meaning this port will need access to these vlans.  
> This being the case, will I need to configure the Linux machine for 
> 802.1q trunking as well?  I found this article that seemed to suggest, 
> yes, but I wanted a second opinion.  
> http://www.linuxjournal.com/article/7268
>
> Thanks 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 A.L.M.Buxey at lboro.ac.uk  Mon Jul 13 18:09:08 2009
From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk)
Date: Mon, 13 Jul 2009 23:09:08 +0100
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <a1873f1f0907131438m3f0b4c70r82a953a29042b6d7@mail.gmail.com>
References: <9DE4AA6876D44B62B87C475B2AFE5514@au.didata.local>
	<a1873f1f0907131438m3f0b4c70r82a953a29042b6d7@mail.gmail.com>
Message-ID: <20090713220908.GA14587@lboro.ac.uk>

Hi,

> This supportwiki
> article<http://supportwiki.cisco.com/ViewWiki/index.php/The_%22PM-SP-4-LIMITS:%22_or_%22PM-SP-STDBY-4-LIMITS:%22_error_message_is_received_in_Catalyst_switches_that_run_Cisco_IOS_Software>could
> be what you're looking for. I confirm the 1800 instances/slot limit.

...and across the globe, people are reading that wonderful
'migrating to MST' Cisco guide  8-)

alan

From A.L.M.Buxey at lboro.ac.uk  Mon Jul 13 18:14:43 2009
From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk)
Date: Mon, 13 Jul 2009 23:14:43 +0100
Subject: [c-nsp] multiple vlans on a port
In-Reply-To: <98E30C61-3FE0-4FF6-8B1D-C11023E0F4C8@gmail.com>
References: <98E30C61-3FE0-4FF6-8B1D-C11023E0F4C8@gmail.com>
Message-ID: <20090713221443.GB14587@lboro.ac.uk>

Hi,

> I realize this is impossible, at least I have read it is on an access  
> port.  So if I sent up a trunk port with the machine, does the machine  
> need to speak 802.1q as well?
>
> interface GigabitEthernet0/15
>  switchport access vlan 120
>  switchport trunk native vlan 120
>  switchport trunk allowed vlan 100,120,231,321
>  switchport mode trunk
> end
>
> The purpose of this is that the machine in a Linux machine running Xen, 
> so the cloud will decide what machines and vlans it needs to spin up at 
> what time.  Meaning this port will need access to these vlans.  This 
> being the case, will I need to configure the Linux machine for 802.1q 
> trunking as well?  I found this article that seemed to suggest, yes, but 
> I wanted a second opinion.  http://www.linuxjournal.com/article/7268

Linux very happily talks 802.1q.  yes, if you want to feed multiple
networks to the Xen host you need to send it a trunk feed... or invest
in multiple NICs and assign NICs to virtual hosts. our Xen boxes
get trunk feeds and /sbin/ifconfig lists all the pvlanXXX and xenbrXXXX
and xenbrtrunk etc.  VMWare has the virtual switch technology so currently
is _slightly_ ahead of Xen on that point...

alan

From jared at puck.nether.net  Mon Jul 13 18:21:39 2009
From: jared at puck.nether.net (Jared Mauch)
Date: Mon, 13 Jul 2009 18:21:39 -0400
Subject: [c-nsp] "Software Download Area is Unavailable at this time"
In-Reply-To: <9DE84313-097E-4D4C-A118-084AC527217D@puck.nether.net>
References: <9DE84313-097E-4D4C-A118-084AC527217D@puck.nether.net>
Message-ID: <20090713222139.GA78946@puck.nether.net>

	The text on the page has changed to:

   New enhanced features for downloading software coming soon.
   Get a sneak preview here.


	They are now claiming the site is fixed, but I'm asking for a RFO
and what their maint policy is on the website.  If my bank can tell
me when they do maint, I would hope that Cisco can.

	- Jared

On Mon, Jul 13, 2009 at 03:45:33PM -0400, Jared Mauch wrote:
> We apologize for any inconvenience. Software Download Area is
> unavailable at this time.
> 
> 
> New enhanced features for downloading software have arrived.
> Get a sneak preview here.
> 
> 
> If you are receiving an Error while downloading software and used a
> home address in your profile, please provide your business address
> to correct the error and gain access to download the software.
> 
> 
> 
> -- snip --
> 
> 
> 
> Anynone know how Cisco intends to distribute software?  This seems
> to be the lead-in deployment for making software unavailable for me.
> 
> 
> 
> 	- Jared
> 

-- 
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 peter at rathlev.dk  Mon Jul 13 18:32:20 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Tue, 14 Jul 2009 00:32:20 +0200
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <a1873f1f0907131438m3f0b4c70r82a953a29042b6d7@mail.gmail.com>
References: <9DE4AA6876D44B62B87C475B2AFE5514@au.didata.local>
	<a1873f1f0907131438m3f0b4c70r82a953a29042b6d7@mail.gmail.com>
Message-ID: <1247524340.4661.65.camel@abehat.net.rm.dk>

On Mon, 2009-07-13 at 23:38 +0200, Nicolas Rolans wrote:
> This supportwiki article [snip] could be what you're looking for. I
> confirm the 1800 instances/slot limit.

... but it doesn't say anything about the number of STP instances.

I tested it on a Sup720 SXI1 and could create more than 1800 STP
instances with the VLANs split among two modules:

r2(config)#do sh vlan vir


Slot 4
-------
Total slot virtual ports 1799

Slot 5
-------
Total slot virtual ports 1799

Total chassis virtual ports 3598
r2(config)#do sh spann summ tot
Switch is in rapid-pvst mode
Root bridge for: VLAN0100-VLAN0110, VLAN0115-VLAN0118, VLAN0120-VLAN0131
  VLAN0133-VLAN0297, VLAN0500-VLAN0999, VLAN1021-VLAN2281, VLAN2300-VLAN2337
  VLAN2400-VLAN4000
EtherChannel misconfig guard            is enabled
Extended system ID                      is enabled
Portfast Default                        is disabled
Portfast Edge BPDU Guard Default        is disabled
Portfast Edge BPDU Filter Default       is disabled
Loopguard Default                       is enabled
PVST Simulation Default                 is enabled but inactive in rapid-pvst mode
Bridge Assurance                        is enabled
UplinkFast                              is disabled
BackboneFast                            is disabled
Pathcost method used                    is long

Name                   Blocking Listening Learning Forwarding STP Active
---------------------- -------- --------- -------- ---------- ----------
3598 vlans                   0         0        0       3598       3598
r2(config)#

I got this message during the configuration:

%SW_VLAN-SP-4-VTP_SEM_BUSY: VTP semaphore is unavailable for function sw_vlansp_get_4k_vlan_info. Semaphore locked by download info

After deleting the VLANs and trying the same again the message did not
appear, so I guess it's nothing really bad.

It seems that more then 1800 instances are possible. I didn't have more
than a two module (Sup720-10G + 6724-SFP) configuration to test this on
at hand.

My bold guess would be that the system limit for number of STP instances
is 10000/13000 total virtual ports (RPVST/PVST).

Whether having 1800+ STP instances on the same switch is a good idea i
something completely different. :-)

Regards,
Peter



From mhuff at ox.com  Mon Jul 13 18:38:23 2009
From: mhuff at ox.com (Matthew Huff)
Date: Mon, 13 Jul 2009 18:38:23 -0400
Subject: [c-nsp] multiple vlans on a port
In-Reply-To: <20090713221443.GB14587@lboro.ac.uk>
References: <98E30C61-3FE0-4FF6-8B1D-C11023E0F4C8@gmail.com>
	<20090713221443.GB14587@lboro.ac.uk>
Message-ID: <483E6B0272B0284BA86D7596C40D29F9D122127F09@PUR-EXCH07.ox.com>

Yes, the machine will need to speak 802.1q. Most modern OS have no trouble with that. Windows, Linux, Solaris, etc.. work fine with 802.1Q.

One thing more, unless Linux has started speaking Cisco DTP (which I doubt), you want to disable DTP messages from sending to the host. Dynamic Trunking Protocol (or DTP) is used to negotiate trunking protocols (ISL or 802.1q), etc... Since you know you want to do 802.1Q and you want to always trunk, you will want to add "switchport nonegotiate" to the interface. This keep cisco from sending a DTP frame every 30 seconds. Those frames won't hurt anything, but can show up on port statistics as bad packets on the host.

Also, with 802.1q framing, you might run into fragmentation on the non-native VLANs. You may want to adjust the MTU on the virtual machines if Linux doesn't do it automatically.


interface GigabitEthernet0/15
   switchport access vlan 120
   switchport trunk native vlan 120
   switchport trunk allowed vlan 100,120,231,321
   switchport mode trunk
   switchport nonegotiate
end


----
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 A.L.M.Buxey at lboro.ac.uk
Sent: Monday, July 13, 2009 6:15 PM
To: Cord MacLeod
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] multiple vlans on a port

Hi,

> I realize this is impossible, at least I have read it is on an access  
> port.  So if I sent up a trunk port with the machine, does the machine  
> need to speak 802.1q as well?
>
> interface GigabitEthernet0/15
>  switchport access vlan 120
>  switchport trunk native vlan 120
>  switchport trunk allowed vlan 100,120,231,321
>  switchport mode trunk
> end
>
> The purpose of this is that the machine in a Linux machine running Xen, 
> so the cloud will decide what machines and vlans it needs to spin up at 
> what time.  Meaning this port will need access to these vlans.  This 
> being the case, will I need to configure the Linux machine for 802.1q 
> trunking as well?  I found this article that seemed to suggest, yes, but 
> I wanted a second opinion.  http://www.linuxjournal.com/article/7268

Linux very happily talks 802.1q.  yes, if you want to feed multiple
networks to the Xen host you need to send it a trunk feed... or invest
in multiple NICs and assign NICs to virtual hosts. our Xen boxes
get trunk feeds and /sbin/ifconfig lists all the pvlanXXX and xenbrXXXX
and xenbrtrunk etc.  VMWare has the virtual switch technology so currently
is _slightly_ ahead of Xen on that point...

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  Mon Jul 13 18:46:56 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Tue, 14 Jul 2009 00:46:56 +0200
Subject: [c-nsp] "Software Download Area is Unavailable at this time"
In-Reply-To: <023a01ca0400$17a54a60$0808120a@am.thmulti.com>
References: <9DE84313-097E-4D4C-A118-084AC527217D@puck.nether.net>
	<1247519077.4661.46.camel@abehat.net.rm.dk>
	<023a01ca0400$17a54a60$0808120a@am.thmulti.com>
Message-ID: <1247525217.4661.75.camel@abehat.net.rm.dk>

On Mon, 2009-07-13 at 14:22 -0700, Scott Granados wrote:
> Lets face it, there's a trend here.  It's more of this shielding the
> user from the equipment BS which wraps itself in to the company web
> front end as well.
> 
> Try configuring some of the VPN hardware with out pointing and
> clicking. It's extremely sad!  I think Cisco and many other companies
> have lost there way when it comes to good interface design, but that's
> just me.

We're migrating to the ASA platform for VPN (from the Altiga VPN3000
boxes). I can't say anything about the webif/ASDM/whatever as I've never
ever had the pleasure to use it, but I like the CLI configuration on the
ASA.

But yes, there's a trend somehow. And maybe one day it'll all just be
point-and-click, but as long as they (Cisco et al) sell shoddy
constructions (hw/sw) that need us "brainy nerds" to function they
better deliver the relevant tools for us to do our jobs.

Alternatively the clueful people will be attracted to other platforms.

Regards,
Peter



From cordmacleod at gmail.com  Mon Jul 13 18:51:41 2009
From: cordmacleod at gmail.com (Cord MacLeod)
Date: Mon, 13 Jul 2009 15:51:41 -0700
Subject: [c-nsp] multiple vlans on a port
In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9D122127F09@PUR-EXCH07.ox.com>
References: <98E30C61-3FE0-4FF6-8B1D-C11023E0F4C8@gmail.com>
	<20090713221443.GB14587@lboro.ac.uk>
	<483E6B0272B0284BA86D7596C40D29F9D122127F09@PUR-EXCH07.ox.com>
Message-ID: <AD2256CD-3B4D-4387-9E7C-89C3A9602B0A@gmail.com>

Thank you everyone for your replies.  Fantastic information.


On Jul 13, 2009, at 3:38 PM, Matthew Huff wrote:

> Yes, the machine will need to speak 802.1q. Most modern OS have no  
> trouble with that. Windows, Linux, Solaris, etc.. work fine with  
> 802.1Q.
>
> One thing more, unless Linux has started speaking Cisco DTP (which I  
> doubt), you want to disable DTP messages from sending to the host.  
> Dynamic Trunking Protocol (or DTP) is used to negotiate trunking  
> protocols (ISL or 802.1q), etc... Since you know you want to do  
> 802.1Q and you want to always trunk, you will want to add  
> "switchport nonegotiate" to the interface. This keep cisco from  
> sending a DTP frame every 30 seconds. Those frames won't hurt  
> anything, but can show up on port statistics as bad packets on the  
> host.
>
> Also, with 802.1q framing, you might run into fragmentation on the  
> non-native VLANs. You may want to adjust the MTU on the virtual  
> machines if Linux doesn't do it automatically.
>
>
> interface GigabitEthernet0/15
>   switchport access vlan 120
>   switchport trunk native vlan 120
>   switchport trunk allowed vlan 100,120,231,321
>   switchport mode trunk
>   switchport nonegotiate
> end
>
>
> ----
> 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 A.L.M.Buxey at lboro.ac.uk
> Sent: Monday, July 13, 2009 6:15 PM
> To: Cord MacLeod
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] multiple vlans on a port
>
> Hi,
>
>> I realize this is impossible, at least I have read it is on an access
>> port.  So if I sent up a trunk port with the machine, does the  
>> machine
>> need to speak 802.1q as well?
>>
>> interface GigabitEthernet0/15
>> switchport access vlan 120
>> switchport trunk native vlan 120
>> switchport trunk allowed vlan 100,120,231,321
>> switchport mode trunk
>> end
>>
>> The purpose of this is that the machine in a Linux machine running  
>> Xen,
>> so the cloud will decide what machines and vlans it needs to spin  
>> up at
>> what time.  Meaning this port will need access to these vlans.  This
>> being the case, will I need to configure the Linux machine for 802.1q
>> trunking as well?  I found this article that seemed to suggest,  
>> yes, but
>> I wanted a second opinion.  http://www.linuxjournal.com/article/7268
>
> Linux very happily talks 802.1q.  yes, if you want to feed multiple
> networks to the Xen host you need to send it a trunk feed... or invest
> in multiple NICs and assign NICs to virtual hosts. our Xen boxes
> get trunk feeds and /sbin/ifconfig lists all the pvlanXXX and  
> xenbrXXXX
> and xenbrtrunk etc.  VMWare has the virtual switch technology so  
> currently
> is _slightly_ ahead of Xen on that point...
>
> 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 td_miles at yahoo.com  Mon Jul 13 18:17:00 2009
From: td_miles at yahoo.com (Tony)
Date: Mon, 13 Jul 2009 15:17:00 -0700 (PDT)
Subject: [c-nsp] Help with output drops
In-Reply-To: <20090713132607.M93483@fast-serv.com>
Message-ID: <925612.94949.qm@web110107.mail.gq1.yahoo.com>


Hi Randy,

I can't answer why it was enabled either, the default on this platform is for QOS to be disabled until you manually enable it with the "mls qos" command. The problem you came across is why it is disabled by default so you don't have performance issues "out of the box".

When I originally replied, I was looking for the reference in the Cisco doco that tells you not to enable QOS globally if you're not going to use it, as it will degrade performance. I finally found it, so here it is for the archives (the second "Note" point is the one you want to read):
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/qos.html#wp1750716
http://tinyurl.com/mbe65n

If you can't find the relevent section, search the above document for the string "Do not enable PFC QoS globally" and start reading from there.

QOS is used to give different treatment to different types of traffic. The classic example is that you want VoIP packets to be queued and sent before all other traffic so that your audio calls don't suffer when someone is downloading a large file which is lower priority and non real-time traffic.

AFAIK disabling mls qos globally only affects your ability to use the qos queueing/policing features and doesn't stop anything else from working. I couldn't give you a guarantee that it won't break anything else, but it is a fairly targeted command to just enable/disable qos.



regards,
Tony.

--- On Mon, 13/7/09, Randy McAnally <rsm at fast-serv.com> wrote:

> From: Randy McAnally <rsm at fast-serv.com>
> Subject: Re: [c-nsp] Help with output drops
> To: "Tony" <td_miles at yahoo.com>, cisco-nsp at puck.nether.net
> Date: Monday, 13 July, 2009, 11:28 PM
> Hi Tony,
> 
> After disabling QoS there are no longer any output
> drops.? Thanks for the
> suggestion.
> 
> Are there any features that rely on QoS, or is it a default
> setting?? I'm
> trying to figure out something reasonable as to why it was
> enabled in the
> first place.
> 
> --
> Randy
> 
> ---------- Original Message -----------
> From: Tony <td_miles at yahoo.com>
> To: cisco-nsp at puck.nether.net,
> Randy McAnally <rsm at fast-serv.com>
> Sent: Sun, 12 Jul 2009 23:21:47 -0700 (PDT)
> Subject: Re: [c-nsp] Help with output drops
> 
> > Hi Randy,
> > 
> > Is QoS enabled ? What does "show mls qos" tell you ?
> > 
> > Do you need QOS at all ? If not, disable it globally
> (no mls qos)
> >? and your problem might just go away if it's
> being caused by queue 
> > threshold defaults..
> > 
> > If it's production switch, do it during a scheduled
> maintenance 
> > period as it might disrupt traffic for a second.
> > 
> > regards,
> > Tony.
> > 
> > --- On Mon, 13/7/09, Randy McAnally <rsm at fast-serv.com>
> wrote:
> > 
> > > From: Randy McAnally <rsm at fast-serv.com>
> > > Subject: [c-nsp] Help with output drops
> > > To: cisco-nsp at puck.nether.net
> > > Date: Monday, 13 July, 2009, 1:51 PM
> > > Hi all,
> > > 
> > > I just finished installing and configuring a new
> 6509 with
> > > dual sup7203bxl
> > > (12.2(18)SXF15a) and a 6724 linecards.? It
> serves a
> > > simple purpose of
> > > maintaining a single BGP session, and managing
> layer3
> > > (vlans) for various
> > > access switches..? No end devices are connected.
> > > 
> > > The problem is that we are getting constant
> output drops
> > > when our gig-E uplink
> > > goes above ~400 mbps.? Nowhere near the
> interface
> > > speed!? See below, take note
> > > of massive 'Total output drops' with no other
> errors (on
> > > either end):
> > > 
> > > rtr1.ash#sh int g1/1
> > > GigabitEthernet1/1 is up, line protocol is up
> (connected)
> > > ? Hardware is C6k 1000Mb 802.3, address is
> > > 00d0.01ff.5800 (bia 00d0.01ff.5800)
> > > ? Description: PTP-UPLINK
> > > ? Internet address is 209.9.224.68/29
> > > ? MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
> > > ? ???reliability 255/255, txload
> > > 118/255, rxload 12/255
> > > ? Encapsulation ARPA, loopback not set
> > > ? Keepalive set (10 sec)
> > > ? Full-duplex, 1000Mb/s, media type is T
> > > ? 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:00, output 00:00:01, output
> hang
> > > never
> > > ? Last clearing of "show interface" counters
> 05:01:25
> > > ? Input queue: 0/1000/0/0
> (size/max/drops/flushes);
> > > Total output drops: 718023
> > > ? Queueing strategy: fifo
> > > ? Output queue: 0/100 (size/max)
> > > ? 30 second input rate 47789000 bits/sec, 30797
> > > packets/sec
> > > ? 30 second output rate 465362000 bits/sec,
> 48729
> > > packets/sec
> > > ? L2 Switched: ucast: 27775 pkt, 2136621 bytes
> -
> > > mcast: 24590 pkt, 1574763 bytes
> > > ? L3 in Switched: ucast: 592150327 pkt,
> 95608889548
> > > bytes - mcast: 0 pkt, 0
> > > bytes mcast
> > > ? L3 out Switched: ucast: 991372425 pkt,
> 1214882993007
> > > bytes mcast: 0 pkt, 0 bytes
> > > ? ???592554441 packets input,
> > > 95674494492 bytes, 0 no buffer
> > > ? ???Received 33643 broadcasts (17872
> > > IP multicasts)
> > > ? ???0 runts, 0 giants, 0 throttles
> > > ? ???0 input errors, 0 CRC, 0 frame, 0
> > > overrun, 0 ignored
> > > ? ???0 watchdog, 0 multicast, 0 pause
> > > input
> > > ? ???0 input packets with dribble
> > > condition detected
> > > ? ???991006394 packets output,
> > > 1214377864373 bytes, 0 underruns
> > > ? ???0 output errors, 0 collisions, 0
> > > 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
> > > 
> > > The CPU usage is nil:
> > > 
> > > rtr1..ash#sh proc cpu sort
> > > 
> > > CPU utilization for five seconds: 1%/0%; one
> minute: 0%;
> > > five minutes: 0%
> > >? PID Runtime(ms)???Invoked? ?
> > > ?
> > > uSecs???5Sec???1Min???5Min
> > > TTY Process
> > > ???6? ???3036624?
> > > ? 252272? ? ? 12037? 0.47%?
> > > 0.19%? 0.18%???0 Check heaps
> > >? 316? ? ? 195004?
> > > ???99543? ?
> > > ???1958? 0.15%? 0.01%?
> > > 0.00%???0 BGP Scanner
> > >? 119? ? ?
> > > 267568???2962884? ? ?
> > > ???90? 0.15%? 0.03%?
> > > 0.02%???0 IP Input
> > >? 172? ? ?
> > > 413528???2134933? ? ? ?
> > > 193? 0.07%? 0.03%? 0.02%???0
> > > CEF process
> > > ???4? ? ? ? ?
> > > 16? ???48214? ? ? ?
> > > ? 0? 0.00%? 0.00%?
> > > 0.00%???0 cpf_process_ipcQ
> > > ???3? ? ? ?
> > > ???0? ? ?
> > > ???2? ? ? ? ?
> > > 0? 0.00%? 0.00%? 0.00%???0
> > > cpf_process_msg_
> > > ???5? ? ? ?
> > > ???0? ? ?
> > > ???1? ? ? ? ?
> > > 0? 0.00%? 0.00%? 0.00%???0 PF
> > > Redun ICC Req
> > > ???2? ? ?
> > > ???772? ? 298376? ?
> > > ? ? ? 2? 0.00%? 0.00%?
> > > 0.00%???0 Load Meter
> > > ???9? ?
> > > ???23964? ? 157684? ?
> > > ? ? 151? 0.00%? 0.01%?
> > > 0.00%???0 ARP Input
> > > ???7? ? ? ?
> > > ???0? ? ?
> > > ???1? ? ? ? ?
> > > 0? 0.00%? 0.00%? 0.00%???0
> > > Pool Manager
> > > ???8? ? ? ?
> > > ???0? ? ?
> > > ???2? ? ? ? ?
> > > 0? 0.00%? 0.00%? 0.00%???0
> > > Timers
> > > <<<snip>>>
> > > 
> > > I THINK I have determined the drops are caused by
> buffer
> > > congestion on the port:
> > > 
> > > rtr1.ash#sh queueing interface gigabitEthernet
> 1/1 
> > > 
> > > rtr1.ash#sh queueing interface gigabitEthernet
> 1/1
> > > Interface GigabitEthernet1/1 queueing
> strategy:?
> > > Weighted Round-Robin
> > > ? Port QoS is enabled
> > > ? Port is untrusted
> > > ? Extend trust state: not trusted [COS = 0]
> > > ? Default COS is 0
> > > ? ? Queueing Mode In Tx direction: mode-cos
> > > ? ? Transmit queues [type = 1p3q8t]:
> > > ? ? Queue Id? ? Scheduling? Num of
> > > thresholds
> > > ? ? -----------------------------------------
> > > ? ? ???01? ? ?
> > > ???WRR? ? ? ? ?
> > > ? ? ???08
> > > ? ? ???02? ? ?
> > > ???WRR? ? ? ? ?
> > > ? ? ???08
> > > ? ? ???03? ? ?
> > > ???WRR? ? ? ? ?
> > > ? ? ???08
> > > ? ? ???04? ? ?
> > > ???Priority? ? ? ? ?
> > > ? 01
> > > 
> > > ? ? WRR bandwidth ratios:? 100[queue 1]
> > > 150[queue 2] 200[queue 3]
> > > ? ? queue-limit ratios:?
> > > ???50[queue 1]? 20[queue 2]?
> > > 15[queue 3]? 15[Pri Queue]
> > > 
> > > <<<snip>>>
> > > 
> > > ? Packets dropped on Transmit:
> > > 
> > > ? ? queue? ???dropped?
> > > [cos-map]
> > > ? ?
> > > ---------------------------------------------
> > > ? ? 1? ? ? ? ? ?
> > > ? ? ???719527? [0 1 ]
> > > ? ? 2? ? ? ? ? ?
> > > ? ? ? ? ? ? 0? [2 3 4 ]
> > > ? ? 3? ? ? ? ? ?
> > > ? ? ? ? ? ? 0? [6 7 ]
> > > ? ? 4? ? ? ? ? ?
> > > ? ? ? ? ? ? 0? [5 ]
> > > 
> > > So it would appear all of my traffic goes into
> queue
> > > 1.? It would also seem
> > > that 50% buffers for queue 1 isn't enough??
> These are
> > > the default settings by
> > > the way.
> > > 
> > > I'm pretty sure that wrr-queue queue-limit and
> wrr-queue
> > > bandwidth should help
> > > us mitigate this frustrating packet loss, but
> I've no
> > > experience and would
> > > like some insight and suggestions before I start
> making
> > > changes.? I am totally
> > > unfamiliar with these features (I come from
> Foundry/Brocade
> > > background) and
> > > would like any suggestions or advise you might
> have before
> > > I try anything that
> > > could risk downtime or further issues in a
> production
> > > environment.
> > > 
> > > And lastly, would changing the queue settings
> cause BGP to
> > > drop or anything
> > > else unexpected (like changing flow control would
> reset the
> > > interface, ect)?
> > > 
> > > Thank you!
> > > 
> > > --
> > > Randy
> > > www.FastServ..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/
> > >
> ------- End of Original Message -------
> 
> 


      


From pgurumu at gmail.com  Mon Jul 13 19:33:32 2009
From: pgurumu at gmail.com (Prabhu Gurumurthy)
Date: Mon, 13 Jul 2009 16:33:32 -0700
Subject: [c-nsp] ASA IPsec Tunnel Failover
In-Reply-To: <D6147B25080EEE458FE5BEEE7B280F5D3C5D5B6720@exch01.austin.swinc.com>
References: <D6147B25080EEE458FE5BEEE7B280F5D3C5D5B6720@exch01.austin.swinc.com>
Message-ID: <743A3BD3-B0BE-4E5C-B63E-566BC3750964@gmail.com>

Answer is: BGP

On Jul 13, 2009, at 1:14 PM, Munoz, Jeff wrote:

> Hey guys, I have two main sites (site A and site B) and one remote  
> site (site C).  Sites A and B have a metroethernet connection  
> between them.  Remote site C has an IPsec tunnel back to site A.   
> I'd like to setup failover so in case site A's ASA is down the  
> remote site C ASA sends the interesting traffic down the site B  
> IPsec tunnel.  Unfortunately, it will always match the tunnel to  
> site A since the phase 2 access lists have the same source/ 
> destinations.  Any ideas on how I can do this?
>
> Thanks!
>
> 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 nrauhauser at gmail.com  Mon Jul 13 21:26:49 2009
From: nrauhauser at gmail.com (neal rauhauser)
Date: Mon, 13 Jul 2009 20:26:49 -0500
Subject: [c-nsp] disable break on boot for IOS??
In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9D122127F07@PUR-EXCH07.ox.com>
References: <9515c62d0907131410o696872b9ya8e927cbd52885f4@mail.gmail.com>
	<483E6B0272B0284BA86D7596C40D29F9D122127F07@PUR-EXCH07.ox.com>
Message-ID: <9515c62d0907131826o7baca8d6l11acc3c42b37e052@mail.gmail.com>

   This is good advice for newer machines but I've got a UBR 924 with 12.1T
code on it - 'no service password-recover' isn't an option for me. Which
config-register setting will do what I need? Seems like maybe 0x8102 would
do it, but I'm in no mood to experiment across twenty miles, especially when
I'm monitoring activity for law enforcement. This guy, he is a giant pain
where I sit and has been since I started at the first of the year.


On Mon, Jul 13, 2009 at 4:31 PM, Matthew Huff <mhuff at ox.com> wrote:

> If you are running a newer IOS and newer ROMMON you can disable
> password-recover (i.e. break during boot) using "no service
> password-recovery". Make sure to read
> http://www.cisco.com/en/US/docs/ios/12_3/12_3y/12_3ya8/gtnsvpwd.htmlcompletely, you can brick a router otherwise.
>
>
>
>
> ----
> 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 neal rauhauser
> > Sent: Monday, July 13, 2009 5:11 PM
> > To: cisco-nsp at puck.nether.net
> > Subject: [c-nsp] disable break on boot for IOS??
> >
> >    I have a situation with a former employee who still has legitimate
> > physical access to a shared space where we have some Cisco equipment.
> > Today
> > one of our field guys located a UBR924 attached to our cable modem
> > plant
> > with the cutest little rogue Linux machine attached to its ethernet
> > port.
> >
> >    I had them recover the router's password as the first step and now
> > I'm
> > puzzling over this:
> >
> > http://www.cisco.com/en/US/products/hw/routers/ps133/products_tech_note
> > 09186a008022493f.shtml
> >
> >
> >    I recall that a machine can be set such that the break during boot
> > will
> > not permit password recovery, but it isn't clear to me how I do it. I'd
> > really like to get this machine secured so I can dig in to what he is
> > doing.
> > I'd already isolated this cable plant because I knew intrusion was
> > possible
> > but I want to see what other mischief he uses our facilities for - a
> > little
> > spice for the already meaty intrusion case against him this spring.
> >
> > --
> > mailto:Neal at layer3arts.com //
> > GoogleTalk: nrauhauser at gmail.com
> > IM: nealrauhauser
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
>



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

From ip at ioshints.info  Tue Jul 14 01:43:08 2009
From: ip at ioshints.info (Ivan Pepelnjak)
Date: Tue, 14 Jul 2009 07:43:08 +0200
Subject: [c-nsp] disable break on boot for IOS??
In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9D122127F07@PUR-EXCH07.ox.com>
References: <9515c62d0907131410o696872b9ya8e927cbd52885f4@mail.gmail.com>
	<483E6B0272B0284BA86D7596C40D29F9D122127F07@PUR-EXCH07.ox.com>
Message-ID: <005301ca0445$f86343f0$0a00000a@nil.si>

Just make sure you test the feature (for each ROMMON release you're using)
with a known enable password first. It's somewhat impossible to break into
some ROMMON versions.

http://blog.ioshints.info/2007/12/recovering-from-disabled-password.html

Ivan
 
http://www.ioshints.info/about
http://blog.ioshints.info/

> -----Original Message-----
> From: Matthew Huff [mailto:mhuff at ox.com] 
> Sent: Monday, July 13, 2009 11:31 PM
> To: 'neal rauhauser'; 'cisco-nsp at puck.nether.net'
> Subject: Re: [c-nsp] disable break on boot for IOS??
> 
> If you are running a newer IOS and newer ROMMON you can 
> disable password-recover (i.e. break during boot) using "no 
> service password-recovery". Make sure to read 
> http://www.cisco.com/en/US/docs/ios/12_3/12_3y/12_3ya8/gtnsvpw
> d.html completely, you can brick a router otherwise.
> 
> 
> 
> 
> ----
> 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 neal rauhauser
> > Sent: Monday, July 13, 2009 5:11 PM
> > To: cisco-nsp at puck.nether.net
> > Subject: [c-nsp] disable break on boot for IOS??
> >
> >    I have a situation with a former employee who still has 
> legitimate 
> > physical access to a shared space where we have some Cisco 
> equipment.
> > Today
> > one of our field guys located a UBR924 attached to our cable modem 
> > plant with the cutest little rogue Linux machine attached to its 
> > ethernet port.
> >
> >    I had them recover the router's password as the first 
> step and now 
> > I'm puzzling over this:
> >
> > 
> http://www.cisco.com/en/US/products/hw/routers/ps133/products_tech_not
> > e
> > 09186a008022493f.shtml
> >
> >
> >    I recall that a machine can be set such that the break 
> during boot 
> > will not permit password recovery, but it isn't clear to me 
> how I do 
> > it. I'd really like to get this machine secured so I can dig in to 
> > what he is doing.
> > I'd already isolated this cable plant because I knew intrusion was 
> > possible but I want to see what other mischief he uses our 
> facilities 
> > for - a little spice for the already meaty intrusion case 
> against him 
> > this spring.
> >
> > --
> > mailto:Neal at layer3arts.com //
> > GoogleTalk: nrauhauser at gmail.com
> > IM: nealrauhauser
> > _______________________________________________
> > cisco-nsp mailing list  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  Tue Jul 14 01:47:59 2009
From: ip at ioshints.info (Ivan Pepelnjak)
Date: Tue, 14 Jul 2009 07:47:59 +0200
Subject: [c-nsp] disable break on boot for IOS??
In-Reply-To: <9515c62d0907131826o7baca8d6l11acc3c42b37e052@mail.gmail.com>
References: <9515c62d0907131410o696872b9ya8e927cbd52885f4@mail.gmail.com><483E6B0272B0284BA86D7596C40D29F9D122127F07@PUR-EXCH07.ox.com>
	<9515c62d0907131826o7baca8d6l11acc3c42b37e052@mail.gmail.com>
Message-ID: <005401ca0446$a63392a0$0a00000a@nil.si>

>    This is good advice for newer machines but I've got a UBR 
> 924 with 12.1T code on it - 'no service password-recover' 
> isn't an option for me. Which config-register setting will do 
> what I need?

None. You cannot disable break during the first minute (or so) with a config
register.

> Seems like maybe 0x8102 would do it

The "disable break" 0x0100 disables break after the initial one-minute (or
so) window.

Ivan


From mb at adv.gcomm.com.au  Tue Jul 14 00:57:52 2009
From: mb at adv.gcomm.com.au (mb at adv.gcomm.com.au)
Date: Tue, 14 Jul 2009 14:57:52 +1000
Subject: [c-nsp] MST config on single 3560
Message-ID: <20090714145752.qwkjhv749hwswwo0@webmail.datafx.com.au>

Hi,

We have existing 3560's with multiple trunk ports to clients+upstreams 
- We will go very close to hitting the 128 STP instance limit, 
therefore MST looks to be like an option(Without upgrading the 
switches).

The 3560's also have a trunk port to 7200's(For dot1q subints), for 
clients that require L3 connectivity.

I'm just a little unsure how to group vlans into seperate instances(Or 
if it is entirely necessary?)

i.e. GE0/1 (From Provider A) has:

interface GigabitEthernet0/1
description GIGE_ICAP_INTERNETCONNECT_TO_PROVIDER_A
switchport trunk allowed vlan 112,172,208,211,240,309,315,385,537,547,550-552
switchport trunk allowed vlan add 554,623,635,687,690,694,696,697,867,879,980
switchport mode trunk

These vlan's are allocated by provider and represent individual 
services - These vlans are then either presented on client trunk ports 
for L2 services, or added to trunk port to 7200 for L3 services.

So as you can see, there is no "standard" for how the individual vlan's 
are treated, nor which trunk port they may be presented on.....hoping 
someone can provide guideance on how best to manage this?

Thanks in advance.

-------------------------------------------------------------------------
This e-mail was sent via GCOMM WebMail http://www.gcomm.com.au/



From kron at linkey.ru  Tue Jul 14 02:10:44 2009
From: kron at linkey.ru (Aleksandr Gurbo)
Date: Tue, 14 Jul 2009 10:10:44 +0400
Subject: [c-nsp] IPv6 iBGP Route Reflector
In-Reply-To: <4A56388F.6060607@ibctech.ca>
References: <20090709221739.60f8e34e.kron@linkey.ru>
	<4A56388F.6060607@ibctech.ca>
Message-ID: <20090714101044.69c76dbf.kron@linkey.ru>

On Sat, 11 Jul 2009 19:08:17 -0400
Steve Bertrand <steve at ibctech.ca> wrote:

> Over the weekend, I'll find out how the OP can fix the routes, and
> moreover, why they are broken in the first place.
>
> Steve

Have you any ideas how to fix reflected routes?


-- 
Alexandr Gurbo


From rwest at zyedge.com  Tue Jul 14 02:22:53 2009
From: rwest at zyedge.com (Ryan West)
Date: Tue, 14 Jul 2009 02:22:53 -0400
Subject: [c-nsp] ASA IPsec Tunnel Failover
In-Reply-To: <743A3BD3-B0BE-4E5C-B63E-566BC3750964@gmail.com>
References: <D6147B25080EEE458FE5BEEE7B280F5D3C5D5B6720@exch01.austin.swinc.com>
	<743A3BD3-B0BE-4E5C-B63E-566BC3750964@gmail.com>
Message-ID: <6E21B2BDEF6E714EA0B5BA8D5D0E140124835C605C@zy-ex1.zyedge.local>

Jeff, 

Give this a shot:

http://www.cisco.com/en/US/partner/docs/security/asa/asa82/configuration/guide/ike.html#wp1121157

You can enable multiple peers inside a single crypto map.

-ryan

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Prabhu Gurumurthy
Sent: Monday, July 13, 2009 4:34 PM
To: Munoz, Jeff
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] ASA IPsec Tunnel Failover

Answer is: BGP

On Jul 13, 2009, at 1:14 PM, Munoz, Jeff wrote:

> Hey guys, I have two main sites (site A and site B) and one remote  
> site (site C).  Sites A and B have a metroethernet connection  
> between them.  Remote site C has an IPsec tunnel back to site A.   
> I'd like to setup failover so in case site A's ASA is down the  
> remote site C ASA sends the interesting traffic down the site B  
> IPsec tunnel.  Unfortunately, it will always match the tunnel to  
> site A since the phase 2 access lists have the same source/ 
> destinations.  Any ideas on how I can do this?
>
> Thanks!
>
> 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/

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

From sf at lists.esoteric.ca  Tue Jul 14 01:46:27 2009
From: sf at lists.esoteric.ca (Stephen Fulton)
Date: Tue, 14 Jul 2009 01:46:27 -0400
Subject: [c-nsp] Stability of 12.2(33)SRD?
Message-ID: <4A5C1BB3.8030506@lists.esoteric.ca>

Hi all,

I'm looking for thoughts on the stability of 12.2(33)SRD releases (latest is 
SRD2) in general, as well as any experiences running it on the 7600/RSP720 
series.  I'm connecting a SIP400/SPA-5x1GEv2 to a CWDM network, and only SRD 
supports the CWDM SFP's on the SIP400.  Yay.

Thanks,

-- Stephen

From gert at greenie.muc.de  Tue Jul 14 02:33:08 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Tue, 14 Jul 2009 08:33:08 +0200
Subject: [c-nsp] "Software Download Area is Unavailable at this time"
In-Reply-To: <20090713222139.GA78946@puck.nether.net>
References: <9DE84313-097E-4D4C-A118-084AC527217D@puck.nether.net>
	<20090713222139.GA78946@puck.nether.net>
Message-ID: <20090714063307.GB290@greenie.muc.de>

Hi,

On Mon, Jul 13, 2009 at 06:21:39PM -0400, Jared Mauch wrote:
> 	They are now claiming the site is fixed, but I'm asking for a RFO
> and what their maint policy is on the website.  If my bank can tell
> me when they do maint, I would hope that Cisco can.

Where are you asking for the RFO?  I have not found a way to contact the
folks responsible for breaking^Wrunning the WWW and FTP servers yet.

(And I have serious doubts that you'll get an answer...)

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/20090714/89db12b5/attachment.bin>

From p.mayers at imperial.ac.uk  Tue Jul 14 04:16:23 2009
From: p.mayers at imperial.ac.uk (Phil Mayers)
Date: Tue, 14 Jul 2009 09:16:23 +0100
Subject: [c-nsp] "Software Download Area is Unavailable at this time"
In-Reply-To: <20090714063307.GB290@greenie.muc.de>
References: <9DE84313-097E-4D4C-A118-084AC527217D@puck.nether.net>	<20090713222139.GA78946@puck.nether.net>
	<20090714063307.GB290@greenie.muc.de>
Message-ID: <4A5C3ED7.6070704@imperial.ac.uk>

Gert Doering wrote:
> Hi,
> 
> On Mon, Jul 13, 2009 at 06:21:39PM -0400, Jared Mauch wrote:
>> 	They are now claiming the site is fixed, but I'm asking for a RFO
>> and what their maint policy is on the website.  If my bank can tell
>> me when they do maint, I would hope that Cisco can.
> 
> Where are you asking for the RFO?  I have not found a way to contact the
> folks responsible for breaking^Wrunning the WWW and FTP servers yet.
> 
> (And I have serious doubts that you'll get an answer...)

Agreed. The Cisco web team are obviously extremely clueless, and I doubt 
anything that individual users can do will persuade them to roll back 
these changes. The people on this list are, I suspect, too small a 
percentage of the customer base to overrule the "click and gawp" crowd.

(Unless there's someone from AOL or one of the major internet exchanges 
lurking here who can apply some pressure ;o)

But can I just make a recommendation to everyone here: next time you go 
out to competitive tender, specify the nature of docs & software 
availability. List "HTTP downloads without client software or plugins" 
as a mandatory requirement.

Those of you speaking to Cisco now, tell them that you're going to be 
doing that, and that they *WILL LOSE* the next competitive tender if 
they can't fulfil that requirement.

We did so, and I'm planning on smacking Cisco around the head with that 
document shortly. Doubtless it'll be futile, but it's worth a shot...

From benny+usenet at amorsen.dk  Tue Jul 14 03:50:52 2009
From: benny+usenet at amorsen.dk (Benny Amorsen)
Date: Tue, 14 Jul 2009 09:50:52 +0200
Subject: [c-nsp] multiple vlans on a port
In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9D122127F09@PUR-EXCH07.ox.com>
	(Matthew Huff's message of "Mon\, 13 Jul 2009 18\:38\:23 -0400")
References: <98E30C61-3FE0-4FF6-8B1D-C11023E0F4C8@gmail.com>
	<20090713221443.GB14587@lboro.ac.uk>
	<483E6B0272B0284BA86D7596C40D29F9D122127F09@PUR-EXCH07.ox.com>
Message-ID: <m3k52b4s9v.fsf@ursa.amorsen.dk>

Matthew Huff <mhuff at ox.com> writes:

> Also, with 802.1q framing, you might run into fragmentation on the
> non-native VLANs. You may want to adjust the MTU on the virtual
> machines if Linux doesn't do it automatically.

Linux, with reasonably modern kernels, automatically allows an extra 4
bytes for the 802.1q tag. You're ok, as long as the switch allows them
too.

This logic seems to break down when doing q-in-q, where you may have to
adjust the MTU to 1508 for the "untagged" device. This may be fixed in
the last few kernels; I haven't tried lately.


/Benny


From A.L.M.Buxey at lboro.ac.uk  Tue Jul 14 04:45:03 2009
From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk)
Date: Tue, 14 Jul 2009 09:45:03 +0100
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <1247524340.4661.65.camel@abehat.net.rm.dk>
References: <9DE4AA6876D44B62B87C475B2AFE5514@au.didata.local>
	<a1873f1f0907131438m3f0b4c70r82a953a29042b6d7@mail.gmail.com>
	<1247524340.4661.65.camel@abehat.net.rm.dk>
Message-ID: <20090714084503.GA15753@lboro.ac.uk>

Hi,

> ... but it doesn't say anything about the number of STP instances.

things go wonky when you have more than 1800 virtualports per slot
(which you didnt quite reach) (1200 on older eg 100mbit blades)
with 13,000 in total (PVST+), 10,000 in total (RPVST+) 

however, with MST, you can have 6000 virtual ports per blade and 50,000
in total (yay!)

however, this is all about logical interfaces. you want to know the
STP instance? 

regarding maximum STP instances... I believe theres a platform limit
of 1024 because of the MAC to VLAN bridge mapping on the platform -
but, from the values above, you can see that virtual ports would
hit you quite quickly without appropriate control of the VLANs

alan

From gert at greenie.muc.de  Tue Jul 14 04:56:48 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Tue, 14 Jul 2009 10:56:48 +0200
Subject: [c-nsp] "Software Download Area is Unavailable at this time"
In-Reply-To: <4A5C3ED7.6070704@imperial.ac.uk>
References: <9DE84313-097E-4D4C-A118-084AC527217D@puck.nether.net>
	<20090713222139.GA78946@puck.nether.net>
	<20090714063307.GB290@greenie.muc.de>
	<4A5C3ED7.6070704@imperial.ac.uk>
Message-ID: <20090714085648.GD290@greenie.muc.de>

Hi,

On Tue, Jul 14, 2009 at 09:16:23AM +0100, Phil Mayers wrote:
> But can I just make a recommendation to everyone here: next time you go 
> out to competitive tender, specify the nature of docs & software 
> availability. List "HTTP downloads without client software or plugins" 
> as a mandatory requirement.

While this is a nice idea to cause some pressure, I can't see it as
overly realistic - if I have a router A that will fulfill everything
that we need, and a router B that will only do 80% and at the same
time costs 20% more, but has a better company web interface, I think it's
very unlikely that their web download thingie will be change our
decision.

(Besides, most competitors web sites and software download processes are 
even worse)

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/20090714/13933a94/attachment.bin>

From eng_mssk at hotmail.com  Tue Jul 14 05:48:52 2009
From: eng_mssk at hotmail.com (Mohammad Khalil)
Date: Tue, 14 Jul 2009 12:48:52 +0300
Subject: [c-nsp] Block URL ACCESS LIST
Message-ID: <BLU102-W20D319D228A429D7F5B1F9FA230@phx.gbl>


how can i block url using access-list ?

_________________________________________________________________
Drag n? drop?Get easy photo sharing with Windows Live? Photos.

http://www.microsoft.com/windows/windowslive/products/photos.aspx

From gert at greenie.muc.de  Tue Jul 14 05:49:11 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Tue, 14 Jul 2009 11:49:11 +0200
Subject: [c-nsp] multiple vlans on a port
In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9D122127F09@PUR-EXCH07.ox.com>
References: <98E30C61-3FE0-4FF6-8B1D-C11023E0F4C8@gmail.com>
	<20090713221443.GB14587@lboro.ac.uk>
	<483E6B0272B0284BA86D7596C40D29F9D122127F09@PUR-EXCH07.ox.com>
Message-ID: <20090714094911.GH290@greenie.muc.de>

Hi,

On Mon, Jul 13, 2009 at 06:38:23PM -0400, Matthew Huff wrote:
> Also, with 802.1q framing, you might run into fragmentation on
> the non-native VLANs. You may want to adjust the MTU on the virtual
> machines if Linux doesn't do it automatically.

There are a few broken NIC cards on the Linux side that have issues
with "baby-jumbo" packets (1500 + 4 byte for 802.1q header).  Decent
gear - and that's what you want to use on a *server* - doesn't have
any issues there.

And, just to clarify: *If* you have MTU problems due to 802.1q headers,
you will not see "fragmentation".  You'll see black-holing, because the
stack will not know about the MTU issue, and thus won't even think
about fragmentation.  (Fragmentation happens if there is a link on
the path that has smaller L3 MTU than the packet's sender - but in this
scenario, the L3 endpoints assume 1500, while the L2 link cannot handle
this.  Black hole).

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/20090714/6dc45508/attachment.bin>

From masood at nexlinx.net.pk  Tue Jul 14 07:13:52 2009
From: masood at nexlinx.net.pk (masood at nexlinx.net.pk)
Date: Tue, 14 Jul 2009 16:13:52 +0500 (PKT)
Subject: [c-nsp] Block URL ACCESS LIST
In-Reply-To: <BLU102-W20D319D228A429D7F5B1F9FA230@phx.gbl>
References: <BLU102-W20D319D228A429D7F5B1F9FA230@phx.gbl>
Message-ID: <24754.196.46.241.57.1247570032.squirrel@nexmail1.nexlinx.net.pk>


Please go to the following URL to begin:

http://weblogs.com.pk/jahil/archive/2008/11/15/how-nbar-actually-classifies-the-traffic-flows.aspx

Regards,
Masood

>
> how can i block url using access-list ?
>
> _________________________________________________________________
> 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/



From steve at ibctech.ca  Tue Jul 14 08:23:09 2009
From: steve at ibctech.ca (Steve Bertrand)
Date: Tue, 14 Jul 2009 08:23:09 -0400
Subject: [c-nsp] IPv6 iBGP Route Reflector
In-Reply-To: <20090714101044.69c76dbf.kron@linkey.ru>
References: <20090709221739.60f8e34e.kron@linkey.ru>	<4A56388F.6060607@ibctech.ca>
	<20090714101044.69c76dbf.kron@linkey.ru>
Message-ID: <4A5C78AD.5050006@ibctech.ca>

Aleksandr Gurbo wrote:
> On Sat, 11 Jul 2009 19:08:17 -0400
> Steve Bertrand <steve at ibctech.ca> wrote:
> 
>> Over the weekend, I'll find out how the OP can fix the routes, and
>> moreover, why they are broken in the first place.
>>
>> Steve
> 
> Have you any ideas how to fix reflected routes?

I will be working on this specific issue today, as I need to make some
changes in preparation of adding a new router later this week.

I'll keep you posted if I find anything specific as I go.

Steve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3233 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090714/efe1560f/attachment.bin>

From michael.forrest at abdn.ac.uk  Tue Jul 14 07:50:35 2009
From: michael.forrest at abdn.ac.uk (Forrest, Michael E.)
Date: Tue, 14 Jul 2009 12:50:35 +0100
Subject: [c-nsp] ASA IPsec Tunnel Failover
In-Reply-To: <743A3BD3-B0BE-4E5C-B63E-566BC3750964@gmail.com>
References: <D6147B25080EEE458FE5BEEE7B280F5D3C5D5B6720@exch01.austin.swinc.com>
	<743A3BD3-B0BE-4E5C-B63E-566BC3750964@gmail.com>
Message-ID: <D2BEF91BFE51C743854D7AB86BA35A354984F7EC25@VMAILA.uoa.abdn.ac.uk>

I was under the impression that there was no BGP support in the ASA platform, unless someone knows otherwise?

Michael.

> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> bounces at puck.nether.net] On Behalf Of Prabhu Gurumurthy
> Sent: 14 July 2009 00:34
> To: Munoz, Jeff
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] ASA IPsec Tunnel Failover
>
> Answer is: BGP
>
> On Jul 13, 2009, at 1:14 PM, Munoz, Jeff wrote:
>
> > Hey guys, I have two main sites (site A and site B) and one remote
> > site (site C).  Sites A and B have a metroethernet connection
> > between them.  Remote site C has an IPsec tunnel back to site A.
> > I'd like to setup failover so in case site A's ASA is down the
> > remote site C ASA sends the interesting traffic down the site B
> > IPsec tunnel.  Unfortunately, it will always match the tunnel to
> > site A since the phase 2 access lists have the same source/
> > destinations.  Any ideas on how I can do this?
> >
> > Thanks!
> >
> > 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/
>
> _______________________________________________
> cisco-nsp mailing 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 University of Aberdeen is a charity registered in Scotland, No SC013683.

From A.L.M.Buxey at lboro.ac.uk  Tue Jul 14 09:03:24 2009
From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk)
Date: Tue, 14 Jul 2009 14:03:24 +0100
Subject: [c-nsp] ASA IPsec Tunnel Failover
In-Reply-To: <D2BEF91BFE51C743854D7AB86BA35A354984F7EC25@VMAILA.uoa.abdn.ac.uk>
References: <D6147B25080EEE458FE5BEEE7B280F5D3C5D5B6720@exch01.austin.swinc.com>
	<743A3BD3-B0BE-4E5C-B63E-566BC3750964@gmail.com>
	<D2BEF91BFE51C743854D7AB86BA35A354984F7EC25@VMAILA.uoa.abdn.ac.uk>
Message-ID: <20090714130324.GA16535@lboro.ac.uk>

Hi,
> I was under the impression that there was no BGP support in the ASA platform, unless someone knows otherwise?

ah, ASAs and dynamic routing protocols...and you'll be wanting
those in multi-context mode too?  ;-)

alan


From geoff at pendery.net  Tue Jul 14 09:21:53 2009
From: geoff at pendery.net (Geoffrey Pendery)
Date: Tue, 14 Jul 2009 08:21:53 -0500
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <20090714084503.GA15753@lboro.ac.uk>
References: <9DE4AA6876D44B62B87C475B2AFE5514@au.didata.local>
	<a1873f1f0907131438m3f0b4c70r82a953a29042b6d7@mail.gmail.com>
	<1247524340.4661.65.camel@abehat.net.rm.dk>
	<20090714084503.GA15753@lboro.ac.uk>
Message-ID: <d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>

Yes, but he also mentions MST, which has a much more restrictive limit.
As far as I've seen, 802.1s itself only allows 64 instances (see
http://en.wikipedia.org/wiki/Spanning_tree_protocol , or search for
the proper RFC docs)
But all the Cisco docs I've found this morning say they only support 16:
for example:
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/native/configuration/guide/spantree.html#wp1064097

I could have sworn I found stuff saying that our gear would support 64
of them, and we've been contemplating more than 40 in recent designs,
but I guess I'll have to validate in the lab whether it's actually 16
or 64 for our chassis and code.

So keep in mind that if you're moving from RPVST to MST, you're
talking about fewer instances, by necessity.


-Geoff


On Tue, Jul 14, 2009 at 3:45 AM, <A.L.M.Buxey at lboro.ac.uk> wrote:
> Hi,
>
>> ... but it doesn't say anything about the number of STP instances.
>
> things go wonky when you have more than 1800 virtualports per slot
> (which you didnt quite reach) (1200 on older eg 100mbit blades)
> with 13,000 in total (PVST+), 10,000 in total (RPVST+)
>
> however, with MST, you can have 6000 virtual ports per blade and 50,000
> in total (yay!)
>
> however, this is all about logical interfaces. you want to know the
> STP instance?
>
> regarding maximum STP instances... I believe theres a platform limit
> of 1024 because of the MAC to VLAN bridge mapping on the platform -
> but, from the values above, you can see that virtual ports would
> hit you quite quickly without appropriate control of the VLANs
>
> 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 jlewis at lewis.org  Tue Jul 14 09:26:13 2009
From: jlewis at lewis.org (Jon Lewis)
Date: Tue, 14 Jul 2009 09:26:13 -0400 (EDT)
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>
References: <9DE4AA6876D44B62B87C475B2AFE5514@au.didata.local>
	<a1873f1f0907131438m3f0b4c70r82a953a29042b6d7@mail.gmail.com>
	<1247524340.4661.65.camel@abehat.net.rm.dk>
	<20090714084503.GA15753@lboro.ac.uk>
	<d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>
Message-ID: <Pine.LNX.4.61.0907140924470.6312@soloth.lewis.org>

On Tue, 14 Jul 2009, Geoffrey Pendery wrote:

> So keep in mind that if you're moving from RPVST to MST, you're
> talking about fewer instances, by necessity.

But isn't that the whole point of MST?  Most of what I've read about it 
talks about doing setups where you only have 2 or 3 instances, with all 
your vlans in the 2nd and or 3rd instance.

----------------------------------------------------------------------
  Jon Lewis                   |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

From Jonathan.Brashear at hq.speakeasy.net  Tue Jul 14 09:38:14 2009
From: Jonathan.Brashear at hq.speakeasy.net (Jonathan Brashear)
Date: Tue, 14 Jul 2009 06:38:14 -0700
Subject: [c-nsp] ASA IPsec Tunnel Failover
In-Reply-To: <D2BEF91BFE51C743854D7AB86BA35A354984F7EC25@VMAILA.uoa.abdn.ac.uk>
References: <D6147B25080EEE458FE5BEEE7B280F5D3C5D5B6720@exch01.austin.swinc.com>
	<743A3BD3-B0BE-4E5C-B63E-566BC3750964@gmail.com>
	<D2BEF91BFE51C743854D7AB86BA35A354984F7EC25@VMAILA.uoa.abdn.ac.uk>
Message-ID: <725755F5E728EE4086DAAF1A54DACF4F153BBD99@sea5exbe1.speakeasy.hq>

There's not as of yet.  OSPF, RIP, EIGRP, yes, BGP no. 


Network Engineer, JNCIS-M
> 214-981-1954 (office) 
> 214-642-4075 (cell)
> jbrashear at hq.speakeasy.net 
http://www.speakeasy.net
-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Forrest, Michael E.
Sent: Tuesday, July 14, 2009 6:51 AM
To: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] ASA IPsec Tunnel Failover

I was under the impression that there was no BGP support in the ASA platform, unless someone knows otherwise?

Michael.

> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> bounces at puck.nether.net] On Behalf Of Prabhu Gurumurthy
> Sent: 14 July 2009 00:34
> To: Munoz, Jeff
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] ASA IPsec Tunnel Failover
>
> Answer is: BGP
>
> On Jul 13, 2009, at 1:14 PM, Munoz, Jeff wrote:
>
> > Hey guys, I have two main sites (site A and site B) and one remote
> > site (site C).  Sites A and B have a metroethernet connection
> > between them.  Remote site C has an IPsec tunnel back to site A.
> > I'd like to setup failover so in case site A's ASA is down the
> > remote site C ASA sends the interesting traffic down the site B
> > IPsec tunnel.  Unfortunately, it will always match the tunnel to
> > site A since the phase 2 access lists have the same source/
> > destinations.  Any ideas on how I can do this?
> >
> > Thanks!
> >
> > 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/
>
> _______________________________________________
> cisco-nsp mailing 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 University of Aberdeen is a charity registered in Scotland, No SC013683.
_______________________________________________
cisco-nsp mailing list  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  Tue Jul 14 10:05:34 2009
From: Jonathan.Brashear at hq.speakeasy.net (Jonathan Brashear)
Date: Tue, 14 Jul 2009 07:05:34 -0700
Subject: [c-nsp] ASA ssh difficulties
Message-ID: <725755F5E728EE4086DAAF1A54DACF4F153BBDA5@sea5exbe1.speakeasy.hq>

I'm a bit stumped on an issue I'm having with a particular 5505.  Originally it was inaccessible via ASDM or SSH, but after a reboot it began to allow access via ASDM.  However, SSH is still not working.  I've verified that the username/pass is correct(it works through the ASDM) and that SSH access is allowed from the relevant IP range(I get to a password prompt), but it refuses to accept known good passwords from multiple accounts.  It thinks the password is bad, but only when done via SSH.  I haven't run into this issue with other ASAs that are configured identically and I can login to the other ASAs from the same terminal window so it shouldn't be something to do with my terminal emulation.  Any thoughts on why this may be happening?

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

From nick.jon.griffin at gmail.com  Tue Jul 14 10:15:42 2009
From: nick.jon.griffin at gmail.com (Nick Griffin)
Date: Tue, 14 Jul 2009 09:15:42 -0500
Subject: [c-nsp] ASA ssh difficulties
In-Reply-To: <725755F5E728EE4086DAAF1A54DACF4F153BBDA5@sea5exbe1.speakeasy.hq>
References: <725755F5E728EE4086DAAF1A54DACF4F153BBDA5@sea5exbe1.speakeasy.hq>
Message-ID: <a2b352c40907140715ob0c0901tcc0f287005c7002d@mail.gmail.com>

Make sure ssh is setup for location authentication and possibly regenerate
your ssh keys:
this is what I usually do:

crypto key generate rsa general modul 2048

aaa authentication telnet console LOCAL

aaa authentication ssh console LOCAL

aaa authentication http console LOCAL

aaa authentication serial console LOCAL



Nick Griffin, CCIE #17381
Systems Consultant Alexander Open Systems
Direct 479.899.6830 ext 2609
AOS Scheduling - 417.888.2675

On Tue, Jul 14, 2009 at 9:05 AM, Jonathan Brashear <
Jonathan.Brashear at hq.speakeasy.net> wrote:

> I'm a bit stumped on an issue I'm having with a particular 5505.
>  Originally it was inaccessible via ASDM or SSH, but after a reboot it began
> to allow access via ASDM.  However, SSH is still not working.  I've verified
> that the username/pass is correct(it works through the ASDM) and that SSH
> access is allowed from the relevant IP range(I get to a password prompt),
> but it refuses to accept known good passwords from multiple accounts.  It
> thinks the password is bad, but only when done via SSH.  I haven't run into
> this issue with other ASAs that are configured identically and I can login
> to the other ASAs from the same terminal window so it shouldn't be something
> to do with my terminal emulation.  Any thoughts on why this may be
> happening?
>
> 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/
>

From gert at greenie.muc.de  Tue Jul 14 10:15:29 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Tue, 14 Jul 2009 16:15:29 +0200
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <Pine.LNX.4.61.0907140924470.6312@soloth.lewis.org>
References: <9DE4AA6876D44B62B87C475B2AFE5514@au.didata.local>
	<a1873f1f0907131438m3f0b4c70r82a953a29042b6d7@mail.gmail.com>
	<1247524340.4661.65.camel@abehat.net.rm.dk>
	<20090714084503.GA15753@lboro.ac.uk>
	<d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>
	<Pine.LNX.4.61.0907140924470.6312@soloth.lewis.org>
Message-ID: <20090714141529.GN290@greenie.muc.de>

Hi,

On Tue, Jul 14, 2009 at 09:26:13AM -0400, Jon Lewis wrote:
> But isn't that the whole point of MST?  

We have found MST to be mostly pointless...

"Too much hassle, too little gain"

But then, we're a service provider environment, and there are hardly
two VLANs that share the same topology - which maps very poorly to MST
instances.  At the same time, there is a fairly high dynamic in adding
and removing VLANs, which is *quite* painful with MST instance 
mappings...

I just wish more vendors would see the light and implement rapid-PVSTP.

Or at least PVSTP, instead of "yes, we have VLANs, and a big global single
STP" (which is really useless).

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/20090714/0c7c5fae/attachment.bin>

From nick.jon.griffin at gmail.com  Tue Jul 14 10:16:10 2009
From: nick.jon.griffin at gmail.com (Nick Griffin)
Date: Tue, 14 Jul 2009 09:16:10 -0500
Subject: [c-nsp] ASA ssh difficulties
In-Reply-To: <a2b352c40907140715ob0c0901tcc0f287005c7002d@mail.gmail.com>
References: <725755F5E728EE4086DAAF1A54DACF4F153BBDA5@sea5exbe1.speakeasy.hq>
	<a2b352c40907140715ob0c0901tcc0f287005c7002d@mail.gmail.com>
Message-ID: <a2b352c40907140716l4b4332ecmb9b1104c833921d3@mail.gmail.com>

sorry, location = local :)

On Tue, Jul 14, 2009 at 9:15 AM, Nick Griffin <nick.jon.griffin at gmail.com>wrote:

> Make sure ssh is setup for location authentication and possibly regenerate
> your ssh keys:
> this is what I usually do:
>
> crypto key generate rsa general modul 2048
>
> aaa authentication telnet console LOCAL
>
> aaa authentication ssh console LOCAL
>
> aaa authentication http console LOCAL
>
> aaa authentication serial console LOCAL
>
>
>
> Nick Griffin, CCIE #17381
> Systems Consultant Alexander Open Systems
> Direct 479.899.6830 ext 2609
> AOS Scheduling - 417.888.2675
>
> On Tue, Jul 14, 2009 at 9:05 AM, Jonathan Brashear <
> Jonathan.Brashear at hq.speakeasy.net> wrote:
>
>> I'm a bit stumped on an issue I'm having with a particular 5505.
>>  Originally it was inaccessible via ASDM or SSH, but after a reboot it began
>> to allow access via ASDM.  However, SSH is still not working.  I've verified
>> that the username/pass is correct(it works through the ASDM) and that SSH
>> access is allowed from the relevant IP range(I get to a password prompt),
>> but it refuses to accept known good passwords from multiple accounts.  It
>> thinks the password is bad, but only when done via SSH.  I haven't run into
>> this issue with other ASAs that are configured identically and I can login
>> to the other ASAs from the same terminal window so it shouldn't be something
>> to do with my terminal emulation.  Any thoughts on why this may be
>> happening?
>>
>> 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/
>>
>
>

From jkrejci at usinternet.com  Tue Jul 14 10:17:40 2009
From: jkrejci at usinternet.com (Justin Krejci)
Date: Tue, 14 Jul 2009 09:17:40 -0500
Subject: [c-nsp] ASA ssh difficulties
In-Reply-To: <725755F5E728EE4086DAAF1A54DACF4F153BBDA5@sea5exbe1.speakeasy.hq>
References: <725755F5E728EE4086DAAF1A54DACF4F153BBDA5@sea5exbe1.speakeasy.hq>
Message-ID: <BA8054B32C554B248FCDA621E476E571@usicorp.usinternet.com>

If you provide your aaa configuration we might be able to assist like the
output from these commands (assuming you have console access)

show run aaa
show run aaa-server

I am not very familiar with ASDM so I don't know where the aaa config lives
in ASDM but certainly you'll want to look around in that part.

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Jonathan Brashear
Sent: Tuesday, July 14, 2009 9:06 AM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] ASA ssh difficulties

I'm a bit stumped on an issue I'm having with a particular 5505.  Originally
it was inaccessible via ASDM or SSH, but after a reboot it began to allow
access via ASDM.  However, SSH is still not working.  I've verified that the
username/pass is correct(it works through the ASDM) and that SSH access is
allowed from the relevant IP range(I get to a password prompt), but it
refuses to accept known good passwords from multiple accounts.  It thinks
the password is bad, but only when done via SSH.  I haven't run into this
issue with other ASAs that are configured identically and I can login to the
other ASAs from the same terminal window so it shouldn't be something to do
with my terminal emulation.  Any thoughts on why this may be happening?

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/


From geoff at pendery.net  Tue Jul 14 10:24:56 2009
From: geoff at pendery.net (Geoffrey Pendery)
Date: Tue, 14 Jul 2009 09:24:56 -0500
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <Pine.LNX.4.61.0907140924470.6312@soloth.lewis.org>
References: <9DE4AA6876D44B62B87C475B2AFE5514@au.didata.local>
	<a1873f1f0907131438m3f0b4c70r82a953a29042b6d7@mail.gmail.com>
	<1247524340.4661.65.camel@abehat.net.rm.dk>
	<20090714084503.GA15753@lboro.ac.uk>
	<d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>
	<Pine.LNX.4.61.0907140924470.6312@soloth.lewis.org>
Message-ID: <d6966e4b0907140724n61be11f5ra851690ceaabbd93@mail.gmail.com>

Indeed, but the original question asked was about the instance
limitations, and all the responses thrown out are in the 1000-4000
range, discussing virtual interfaces and RPVST.  Nobody seems to have
answered the fairly simple initial question.  I think that answer is
"either 16 or 64, depending on your code".

The separate question of "do you really need all 1000 of those
instances" is a design debate which could be had at length, and would
likely come out different depending on the underlying network design
and requirements.

At least in the case of the enterprise where I work, the "whole point
of MST" is that it's a proper open standard, rather than one of those
super scary Cisco Proprietary Protocols.


-Geoff


On Tue, Jul 14, 2009 at 8:26 AM, Jon Lewis<jlewis at lewis.org> wrote:
> On Tue, 14 Jul 2009, Geoffrey Pendery wrote:
>
>> So keep in mind that if you're moving from RPVST to MST, you're
>> talking about fewer instances, by necessity.
>
> But isn't that the whole point of MST? ?Most of what I've read about it
> talks about doing setups where you only have 2 or 3 instances, with all your
> vlans in the 2nd and or 3rd instance.
>
> ----------------------------------------------------------------------
> ?Jon Lewis ? ? ? ? ? ? ? ? ? | ?I route
> ?Senior Network Engineer ? ? | ?therefore you are
> ?Atlantic Net ? ? ? ? ? ? ? ?|
> _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
>

From digambar.giri at gmail.com  Tue Jul 14 10:29:24 2009
From: digambar.giri at gmail.com (Digambar. Giri)
Date: Tue, 14 Jul 2009 19:59:24 +0530
Subject: [c-nsp] cisco-nsp Digest, Vol 80, Issue 49
In-Reply-To: <mailman.3892.1247577796.2287.cisco-nsp@puck.nether.net>
References: <mailman.3892.1247577796.2287.cisco-nsp@puck.nether.net>
Message-ID: <e45309330907140729p240910c9y870a864a934e5c2e@mail.gmail.com>

Dear friends
please provide IPswitch Whatsup gold 11 serial key NMs...


On 7/14/09, cisco-nsp-request at puck.nether.net <
cisco-nsp-request at puck.nether.net> wrote:
>
> Send cisco-nsp mailing list submissions to
>        cisco-nsp at puck.nether.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://puck.nether.net/mailman/listinfo/cisco-nsp
> or, via email, send a message with subject or body 'help' to
>        cisco-nsp-request at puck.nether.net
>
> You can rDAr each 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: "Software Download Area is Unavailable at this time"
>      (Gert Doering)
>   2. Block URL ACCESS LIST (Mohammad Khalil)
>   3. Re: multiple vlans on a port (Gert Doering)
>   4. Re: Block URL ACCESS LIST (masood at nexlinx.net.pk)
>   5. Re: IPv6 iBGP Route Reflector (Steve Bertrand)
>   6. Re: ASA IPsec Tunnel Failover (Forrest, Michael E.)
>   7. Re: ASA IPsec Tunnel Failover (A.L.M.Buxey at lboro.ac.uk)
>   8. Re: Maximum spannig tree instances (Geoffrey Pendery)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 14 Jul 2009 10:56:48 +0200
> From: Gert Doering <gert at greenie.muc.de>
> To: Phil Mayers <p.mayers at imperial.ac.uk>
> Cc: Gert Doering <gert at greenie.muc.de>, "cisco-nsp at puck.nether.net"
>        <cisco-nsp at puck.nether.net>,    Jared Mauch <jared at puck.nether.net>
> Subject: Re: [c-nsp] "Software Download Area is Unavailable at this
>        time"
> Message-ID: <20090714085648.GD290 at greenie.muc.de>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi,
>
> On Tue, Jul 14, 2009 at 09:16:23AM +0100, Phil Mayers wrote:
> > But can I just make a recommendation to everyone here: next time you go
> > out to competitive tender, specify the nature of docs & software
> > availability. List "HTTP downloads without client software or plugins"
> > as a mandatory requirement.
>
> While this is a nice idea to cause some pressure, I can't see it as
> overly realistic - if I have a router A that will fulfill everything
> that we need, and a router B that will only do 80% and at the same
> time costs 20% more, but has a better company web interface, I think it's
> very unlikely that their web download thingie will be change our
> decision.
>
> (Besides, most competitors web sites and software download processes are
> even worse)
>
> 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/20090714/13933a94/attachment-0001.bin
> >
>
> ------------------------------
>
> Message: 2
> Date: Tue, 14 Jul 2009 12:48:52 +0300
> From: Mohammad Khalil <eng_mssk at hotmail.com>
> To: <cisco-nsp at puck.nether.net>
> Subject: [c-nsp] Block URL ACCESS LIST
> Message-ID: <BLU102-W20D319D228A429D7F5B1F9FA230 at phx.gbl>
> Content-Type: text/plain; charset="windows-1256"
>
>
> how can i block url using access-list ?
>
> _________________________________________________________________
> Drag n? drop?Get easy photo sharing with Windows Live? Photos.
>
> http://www.microsoft.com/windows/windowslive/products/photos.aspx
>
> ------------------------------
>
> Message: 3
> Date: Tue, 14 Jul 2009 11:49:11 +0200
> From: Gert Doering <gert at greenie.muc.de>
> To: Matthew Huff <mhuff at ox.com>
> Cc: "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>
> Subject: Re: [c-nsp] multiple vlans on a port
> Message-ID: <20090714094911.GH290 at greenie.muc.de>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi,
>
> On Mon, Jul 13, 2009 at 06:38:23PM -0400, Matthew Huff wrote:
> > Also, with 802.1q framing, you might run into fragmentation on
> > the non-native VLANs. You may want to adjust the MTU on the virtual
> > machines if Linux doesn't do it automatically.
>
> There are a few broken NIC cards on the Linux side that have issues
> with "baby-jumbo" packets (1500 + 4 byte for 802.1q header).  Decent
> gear - and that's what you want to use on a *server* - doesn't have
> any issues there.
>
> And, just to clarify: *If* you have MTU problems due to 802.1q headers,
> you will not see "fragmentation".  You'll see black-holing, because the
> stack will not know about the MTU issue, and thus won't even think
> about fragmentation.  (Fragmentation happens if there is a link on
> the path that has smaller L3 MTU than the packet's sender - but in this
> scenario, the L3 endpoints assume 1500, while the L2 link cannot handle
> this.  Black hole).
>
> 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/20090714/6dc45508/attachment-0001.bin
> >
>
> ------------------------------
>
> Message: 4
> Date: Tue, 14 Jul 2009 16:13:52 +0500 (PKT)
> From: masood at nexlinx.net.pk
> To: "Mohammad Khalil" <eng_mssk at hotmail.com>
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] Block URL ACCESS LIST
> Message-ID:
>        <24754.196.46.241.57.1247570032.squirrel at nexmail1.nexlinx.net.pk>
> Content-Type: text/plain;charset=iso-8859-1
>
>
> Please go to the following URL to begin:
>
>
> http://weblogs.com.pk/jahil/archive/2008/11/15/how-nbar-actually-classifies-the-traffic-flows.aspx
>
> Regards,
> Masood
>
> >
> > how can i block url using access-list ?
> >
> > _________________________________________________________________
> > 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/
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 14 Jul 2009 08:23:09 -0400
> From: Steve Bertrand <steve at ibctech.ca>
> To: Aleksandr Gurbo <kron at linkey.ru>
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] IPv6 iBGP Route Reflector
> Message-ID: <4A5C78AD.5050006 at ibctech.ca>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Aleksandr Gurbo wrote:
> > On Sat, 11 Jul 2009 19:08:17 -0400
> > Steve Bertrand <steve at ibctech.ca> wrote:
> >
> >> Over the weekend, I'll find out how the OP can fix the routes, and
> >> moreover, why they are broken in the first place.
> >>
> >> Steve
> >
> > Have you any ideas how to fix reflected routes?
>
> I will be working on this specific issue today, as I need to make some
> changes in preparation of adding a new router later this week.
>
> I'll keep you posted if I find anything specific as I go.
>
> Steve
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: smime.p7s
> Type: application/x-pkcs7-signature
> Size: 3233 bytes
> Desc: S/MIME Cryptographic Signature
> URL: <
> https://puck.nether.net/pipermail/cisco-nsp/attachments/20090714/efe1560f/attachment-0001.bin
> >
>
> ------------------------------
>
> Message: 6
> Date: Tue, 14 Jul 2009 12:50:35 +0100
> From: "Forrest, Michael E." <michael.forrest at abdn.ac.uk>
> To: "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>
> Subject: Re: [c-nsp] ASA IPsec Tunnel Failover
> Message-ID:
>        <D2BEF91BFE51C743854D7AB86BA35A354984F7EC25 at VMAILA.uoa.abdn.ac.uk>
> Content-Type: text/plain; charset="us-ascii"
>
> I was under the impression that there was no BGP support in the ASA
> platform, unless someone knows otherwise?
>
> Michael.
>
> > -----Original Message-----
> > From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> > bounces at puck.nether.net] On Behalf Of Prabhu Gurumurthy
> > Sent: 14 July 2009 00:34
> > To: Munoz, Jeff
> > Cc: cisco-nsp at puck.nether.net
> > Subject: Re: [c-nsp] ASA IPsec Tunnel Failover
> >
> > Answer is: BGP
> >
> > On Jul 13, 2009, at 1:14 PM, Munoz, Jeff wrote:
> >
> > > Hey guys, I have two main sites (site A and site B) and one remote
> > > site (site C).  Sites A and B have a metroethernet connection
> > > between them.  Remote site C has an IPsec tunnel back to site A.
> > > I'd like to setup failover so in case site A's ASA is down the
> > > remote site C ASA sends the interesting traffic down the site B
> > > IPsec tunnel.  Unfortunately, it will always match the tunnel to
> > > site A since the phase 2 access lists have the same source/
> > > destinations.  Any ideas on how I can do this?
> > >
> > > Thanks!
> > >
> > > 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/
> >
> > _______________________________________________
> > cisco-nsp mailing 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 University of Aberdeen is a charity registered in Scotland, No
> SC013683.
>
>
> ------------------------------
>
> Message: 7
> Date: Tue, 14 Jul 2009 14:03:24 +0100
> From: A.L.M.Buxey at lboro.ac.uk
> To: "Forrest, Michael E." <michael.forrest at abdn.ac.uk>
> Cc: "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>
> Subject: Re: [c-nsp] ASA IPsec Tunnel Failover
> Message-ID: <20090714130324.GA16535 at lboro.ac.uk>
> Content-Type: text/plain; charset=us-ascii
>
> Hi,
> > I was under the impression that there was no BGP support in the ASA
> platform, unless someone knows otherwise?
>
> ah, ASAs and dynamic routing protocols...and you'll be wanting
> those in multi-context mode too?  ;-)
>
> alan
>
>
>
> ------------------------------
>
> Message: 8
> Date: Tue, 14 Jul 2009 08:21:53 -0500
> From: Geoffrey Pendery <geoff at pendery.net>
> To: A.L.M.Buxey at lboro.ac.uk
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] Maximum spannig tree instances
> Message-ID:
>        <d6966e4b0907140621s504dea4aq120b1f2440f76f1d at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Yes, but he also mentions MST, which has a much more restrictive limit.
> As far as I've seen, 802.1s itself only allows 64 instances (see
> http://en.wikipedia.org/wiki/Spanning_tree_protocol , or search for
> the proper RFC docs)
> But all the Cisco docs I've found this morning say they only support 16:
> for example:
>
> http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/native/configuration/guide/spantree.html#wp1064097
>
> I could have sworn I found stuff saying that our gear would support 64
> of them, and we've been contemplating more than 40 in recent designs,
> but I guess I'll have to validate in the lab whether it's actually 16
> or 64 for our chassis and code.
>
> So keep in mind that if you're moving from RPVST to MST, you're
> talking about fewer instances, by necessity.
>
>
> -Geoff
>
>
> On Tue, Jul 14, 2009 at 3:45 AM, <A.L.M.Buxey at lboro.ac.uk> wrote:
> > Hi,
> >
> >> ... but it doesn't say anything about the number of STP instances.
> >
> > things go wonky when you have more than 1800 virtualports per slot
> > (which you didnt quite reach) (1200 on older eg 100mbit blades)
> > with 13,000 in total (PVST+), 10,000 in total (RPVST+)
> >
> > however, with MST, you can have 6000 virtual ports per blade and 50,000
> > in total (yay!)
> >
> > however, this is all about logical interfaces. you want to know the
> > STP instance?
> >
> > regarding maximum STP instances... I believe theres a platform limit
> > of 1024 because of the MAC to VLAN bridge mapping on the platform -
> > but, from the values above, you can see that virtual ports would
> > hit you quite quickly without appropriate control of the VLANs
> >
> > 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
>
> End of cisco-nsp Digest, Vol 80, Issue 49
> *****************************************
>



-- 
-- 
Regards,
Digambar Giri
+91- 9975776368

From jeremyparr at gmail.com  Tue Jul 14 10:42:51 2009
From: jeremyparr at gmail.com (Jeremy Parr)
Date: Tue, 14 Jul 2009 10:42:51 -0400
Subject: [c-nsp] High CPU Usage
Message-ID: <91dee5fc0907140742o3cc279a1n445cf07e68b2dc88@mail.gmail.com>

I have a 2600 doing some GRE tunnel aggregation with IPSEC and a
AIM-VPN. The CPU is consistently at 95%+, but none of the running
processes are using nearly that much CPU. Is there some other place I
should be looking?

#sh processes cpu sorted
CPU utilization for five seconds: 99%/61%; one minute: 99%; five minutes: 98%
 PID Runtime(ms)   Invoked      uSecs   5Sec   1Min   5Min TTY Process
  70   163085876  24727077       6595 15.31% 16.49% 14.22%   0 IP Input
 146    42276796   9771758       4326  8.24%  8.66%  7.46%   0 Crypto Support
 169    38417520   7286822       5272  5.22%  4.94%  5.12%   0 Crypto PAS Proc
   6    21018268   2714504       7742  4.05%  4.99%  4.24%   0 Pool Manager
  54       65680      2206      29773  2.20%  0.71%  1.20%  66 SSH Process
 190     5281352   6682003        790  0.48%  0.47%  0.45%   0 IP-EIGRP: HELLO
 121     1163120   7759419        149  0.24%  0.16%  0.13%   0 RBSCP Background
  95      709328   1161174        610  0.16%  0.07%  0.06%   0 CEF process

From tsuther at i3businesssolutions.com  Tue Jul 14 10:47:54 2009
From: tsuther at i3businesssolutions.com (Tom Sutherland)
Date: Tue, 14 Jul 2009 10:47:54 -0400
Subject: [c-nsp] ASA ssh difficulties
In-Reply-To: <725755F5E728EE4086DAAF1A54DACF4F153BBDA5@sea5exbe1.speakeasy.hq>
References: <725755F5E728EE4086DAAF1A54DACF4F153BBDA5@sea5exbe1.speakeasy.hq>
Message-ID: <1247582874.31970.6.camel@angry-butler09>

If you're trying to connect to the outside interface, be certain that
you aren't NAT'ing the ASA's public address to some inside host. The
one-to-one mapping overrides the ssh/http servers IIRC.

On Tue, 2009-07-14 at 10:05 -0400, Jonathan Brashear wrote:
> I'm a bit stumped on an issue I'm having with a particular 5505.  Originally it was inaccessible via ASDM or SSH, but after a reboot it began to allow access via ASDM.  However, SSH is still not working.  I've verified that the username/pass is correct(it works through the ASDM) and that SSH access is allowed from the relevant IP range(I get to a password prompt), but it refuses to accept known good passwords from multiple accounts.  It thinks the password is bad, but only when done via SSH.  I haven't run into this issue with other ASAs that are configured identically and I can login to the other ASAs from the same terminal window so it shouldn't be something to do with my terminal emulation.  Any thoughts on why this may be happening?
> 
> 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/


From jared at puck.nether.net  Tue Jul 14 10:49:19 2009
From: jared at puck.nether.net (Jared Mauch)
Date: Tue, 14 Jul 2009 10:49:19 -0400
Subject: [c-nsp] "Software Download Area is Unavailable at this time"
In-Reply-To: <20090714063307.GB290@greenie.muc.de>
References: <9DE84313-097E-4D4C-A118-084AC527217D@puck.nether.net>
	<20090713222139.GA78946@puck.nether.net>
	<20090714063307.GB290@greenie.muc.de>
Message-ID: <A3A093A3-9EA7-4498-9205-CB272AF6A45B@puck.nether.net>

Via a tac case and my account team.

Jared Mauch

On Jul 14, 2009, at 2:33 AM, Gert Doering <gert at greenie.muc.de> wrote:

> Hi,
>
> On Mon, Jul 13, 2009 at 06:21:39PM -0400, Jared Mauch wrote:
>>    They are now claiming the site is fixed, but I'm asking for a RFO
>> and what their maint policy is on the website.  If my bank can tell
>> me when they do maint, I would hope that Cisco can.
>
> Where are you asking for the RFO?  I have not found a way to contact  
> the
> folks responsible for breaking^Wrunning the WWW and FTP servers yet.
>
> (And I have serious doubts that you'll get an answer...)
>
> 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 MatlockK at exempla.org  Tue Jul 14 10:57:05 2009
From: MatlockK at exempla.org (Matlock, Kenneth L)
Date: Tue, 14 Jul 2009 08:57:05 -0600
Subject: [c-nsp] cisco-nsp Digest, Vol 80, Issue 49
In-Reply-To: <e45309330907140729p240910c9y870a864a934e5c2e@mail.gmail.com>
References: <mailman.3892.1247577796.2287.cisco-nsp@puck.nether.net>
	<e45309330907140729p240910c9y870a864a934e5c2e@mail.gmail.com>
Message-ID: <4288131ED5E3024C9CD4782CECCAD2C7065D3851@LMC-MAIL2.exempla.org>

The serial numbers can be found here:

http://www.whatsupgold.com/


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 Digambar. Giri
Sent: Tuesday, July 14, 2009 8:29 AM
To: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] cisco-nsp Digest, Vol 80, Issue 49

Dear friends
please provide IPswitch Whatsup gold 11 serial key NMs...


On 7/14/09, cisco-nsp-request at puck.nether.net <
cisco-nsp-request at puck.nether.net> wrote:
>
> Send cisco-nsp mailing list submissions to
>        cisco-nsp at puck.nether.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://puck.nether.net/mailman/listinfo/cisco-nsp
> or, via email, send a message with subject or body 'help' to
>        cisco-nsp-request at puck.nether.net
>
> You can rDAr each 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: "Software Download Area is Unavailable at this time"
>      (Gert Doering)
>   2. Block URL ACCESS LIST (Mohammad Khalil)
>   3. Re: multiple vlans on a port (Gert Doering)
>   4. Re: Block URL ACCESS LIST (masood at nexlinx.net.pk)
>   5. Re: IPv6 iBGP Route Reflector (Steve Bertrand)
>   6. Re: ASA IPsec Tunnel Failover (Forrest, Michael E.)
>   7. Re: ASA IPsec Tunnel Failover (A.L.M.Buxey at lboro.ac.uk)
>   8. Re: Maximum spannig tree instances (Geoffrey Pendery)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 14 Jul 2009 10:56:48 +0200
> From: Gert Doering <gert at greenie.muc.de>
> To: Phil Mayers <p.mayers at imperial.ac.uk>
> Cc: Gert Doering <gert at greenie.muc.de>, "cisco-nsp at puck.nether.net"
>        <cisco-nsp at puck.nether.net>,    Jared Mauch
<jared at puck.nether.net>
> Subject: Re: [c-nsp] "Software Download Area is Unavailable at this
>        time"
> Message-ID: <20090714085648.GD290 at greenie.muc.de>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi,
>
> On Tue, Jul 14, 2009 at 09:16:23AM +0100, Phil Mayers wrote:
> > But can I just make a recommendation to everyone here: next time you
go
> > out to competitive tender, specify the nature of docs & software
> > availability. List "HTTP downloads without client software or
plugins"
> > as a mandatory requirement.
>
> While this is a nice idea to cause some pressure, I can't see it as
> overly realistic - if I have a router A that will fulfill everything
> that we need, and a router B that will only do 80% and at the same
> time costs 20% more, but has a better company web interface, I think
it's
> very unlikely that their web download thingie will be change our
> decision.
>
> (Besides, most competitors web sites and software download processes
are
> even worse)
>
> 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/20090714/13933a9
4/attachment-0001.bin
> >
>
> ------------------------------
>
> Message: 2
> Date: Tue, 14 Jul 2009 12:48:52 +0300
> From: Mohammad Khalil <eng_mssk at hotmail.com>
> To: <cisco-nsp at puck.nether.net>
> Subject: [c-nsp] Block URL ACCESS LIST
> Message-ID: <BLU102-W20D319D228A429D7F5B1F9FA230 at phx.gbl>
> Content-Type: text/plain; charset="windows-1256"
>
>
> how can i block url using access-list ?
>
> _________________________________________________________________
> Drag n? drop?Get easy photo sharing with Windows Live? Photos.
>
> http://www.microsoft.com/windows/windowslive/products/photos.aspx
>
> ------------------------------
>
> Message: 3
> Date: Tue, 14 Jul 2009 11:49:11 +0200
> From: Gert Doering <gert at greenie.muc.de>
> To: Matthew Huff <mhuff at ox.com>
> Cc: "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>
> Subject: Re: [c-nsp] multiple vlans on a port
> Message-ID: <20090714094911.GH290 at greenie.muc.de>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi,
>
> On Mon, Jul 13, 2009 at 06:38:23PM -0400, Matthew Huff wrote:
> > Also, with 802.1q framing, you might run into fragmentation on
> > the non-native VLANs. You may want to adjust the MTU on the virtual
> > machines if Linux doesn't do it automatically.
>
> There are a few broken NIC cards on the Linux side that have issues
> with "baby-jumbo" packets (1500 + 4 byte for 802.1q header).  Decent
> gear - and that's what you want to use on a *server* - doesn't have
> any issues there.
>
> And, just to clarify: *If* you have MTU problems due to 802.1q
headers,
> you will not see "fragmentation".  You'll see black-holing, because
the
> stack will not know about the MTU issue, and thus won't even think
> about fragmentation.  (Fragmentation happens if there is a link on
> the path that has smaller L3 MTU than the packet's sender - but in
this
> scenario, the L3 endpoints assume 1500, while the L2 link cannot
handle
> this.  Black hole).
>
> 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/20090714/6dc4550
8/attachment-0001.bin
> >
>
> ------------------------------
>
> Message: 4
> Date: Tue, 14 Jul 2009 16:13:52 +0500 (PKT)
> From: masood at nexlinx.net.pk
> To: "Mohammad Khalil" <eng_mssk at hotmail.com>
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] Block URL ACCESS LIST
> Message-ID:
>
<24754.196.46.241.57.1247570032.squirrel at nexmail1.nexlinx.net.pk>
> Content-Type: text/plain;charset=iso-8859-1
>
>
> Please go to the following URL to begin:
>
>
>
http://weblogs.com.pk/jahil/archive/2008/11/15/how-nbar-actually-classif
ies-the-traffic-flows.aspx
>
> Regards,
> Masood
>
> >
> > how can i block url using access-list ?
> >
> > _________________________________________________________________
> > 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/
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 14 Jul 2009 08:23:09 -0400
> From: Steve Bertrand <steve at ibctech.ca>
> To: Aleksandr Gurbo <kron at linkey.ru>
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] IPv6 iBGP Route Reflector
> Message-ID: <4A5C78AD.5050006 at ibctech.ca>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Aleksandr Gurbo wrote:
> > On Sat, 11 Jul 2009 19:08:17 -0400
> > Steve Bertrand <steve at ibctech.ca> wrote:
> >
> >> Over the weekend, I'll find out how the OP can fix the routes, and
> >> moreover, why they are broken in the first place.
> >>
> >> Steve
> >
> > Have you any ideas how to fix reflected routes?
>
> I will be working on this specific issue today, as I need to make some
> changes in preparation of adding a new router later this week.
>
> I'll keep you posted if I find anything specific as I go.
>
> Steve
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: smime.p7s
> Type: application/x-pkcs7-signature
> Size: 3233 bytes
> Desc: S/MIME Cryptographic Signature
> URL: <
>
https://puck.nether.net/pipermail/cisco-nsp/attachments/20090714/efe1560
f/attachment-0001.bin
> >
>
> ------------------------------
>
> Message: 6
> Date: Tue, 14 Jul 2009 12:50:35 +0100
> From: "Forrest, Michael E." <michael.forrest at abdn.ac.uk>
> To: "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>
> Subject: Re: [c-nsp] ASA IPsec Tunnel Failover
> Message-ID:
>
<D2BEF91BFE51C743854D7AB86BA35A354984F7EC25 at VMAILA.uoa.abdn.ac.uk>
> Content-Type: text/plain; charset="us-ascii"
>
> I was under the impression that there was no BGP support in the ASA
> platform, unless someone knows otherwise?
>
> Michael.
>
> > -----Original Message-----
> > From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> > bounces at puck.nether.net] On Behalf Of Prabhu Gurumurthy
> > Sent: 14 July 2009 00:34
> > To: Munoz, Jeff
> > Cc: cisco-nsp at puck.nether.net
> > Subject: Re: [c-nsp] ASA IPsec Tunnel Failover
> >
> > Answer is: BGP
> >
> > On Jul 13, 2009, at 1:14 PM, Munoz, Jeff wrote:
> >
> > > Hey guys, I have two main sites (site A and site B) and one remote
> > > site (site C).  Sites A and B have a metroethernet connection
> > > between them.  Remote site C has an IPsec tunnel back to site A.
> > > I'd like to setup failover so in case site A's ASA is down the
> > > remote site C ASA sends the interesting traffic down the site B
> > > IPsec tunnel.  Unfortunately, it will always match the tunnel to
> > > site A since the phase 2 access lists have the same source/
> > > destinations.  Any ideas on how I can do this?
> > >
> > > Thanks!
> > >
> > > 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/
> >
> > _______________________________________________
> > cisco-nsp mailing 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 University of Aberdeen is a charity registered in Scotland, No
> SC013683.
>
>
> ------------------------------
>
> Message: 7
> Date: Tue, 14 Jul 2009 14:03:24 +0100
> From: A.L.M.Buxey at lboro.ac.uk
> To: "Forrest, Michael E." <michael.forrest at abdn.ac.uk>
> Cc: "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>
> Subject: Re: [c-nsp] ASA IPsec Tunnel Failover
> Message-ID: <20090714130324.GA16535 at lboro.ac.uk>
> Content-Type: text/plain; charset=us-ascii
>
> Hi,
> > I was under the impression that there was no BGP support in the ASA
> platform, unless someone knows otherwise?
>
> ah, ASAs and dynamic routing protocols...and you'll be wanting
> those in multi-context mode too?  ;-)
>
> alan
>
>
>
> ------------------------------
>
> Message: 8
> Date: Tue, 14 Jul 2009 08:21:53 -0500
> From: Geoffrey Pendery <geoff at pendery.net>
> To: A.L.M.Buxey at lboro.ac.uk
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] Maximum spannig tree instances
> Message-ID:
>        <d6966e4b0907140621s504dea4aq120b1f2440f76f1d at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Yes, but he also mentions MST, which has a much more restrictive
limit.
> As far as I've seen, 802.1s itself only allows 64 instances (see
> http://en.wikipedia.org/wiki/Spanning_tree_protocol , or search for
> the proper RFC docs)
> But all the Cisco docs I've found this morning say they only support
16:
> for example:
>
>
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/na
tive/configuration/guide/spantree.html#wp1064097
>
> I could have sworn I found stuff saying that our gear would support 64
> of them, and we've been contemplating more than 40 in recent designs,
> but I guess I'll have to validate in the lab whether it's actually 16
> or 64 for our chassis and code.
>
> So keep in mind that if you're moving from RPVST to MST, you're
> talking about fewer instances, by necessity.
>
>
> -Geoff
>
>
> On Tue, Jul 14, 2009 at 3:45 AM, <A.L.M.Buxey at lboro.ac.uk> wrote:
> > Hi,
> >
> >> ... but it doesn't say anything about the number of STP instances.
> >
> > things go wonky when you have more than 1800 virtualports per slot
> > (which you didnt quite reach) (1200 on older eg 100mbit blades)
> > with 13,000 in total (PVST+), 10,000 in total (RPVST+)
> >
> > however, with MST, you can have 6000 virtual ports per blade and
50,000
> > in total (yay!)
> >
> > however, this is all about logical interfaces. you want to know the
> > STP instance?
> >
> > regarding maximum STP instances... I believe theres a platform limit
> > of 1024 because of the MAC to VLAN bridge mapping on the platform -
> > but, from the values above, you can see that virtual ports would
> > hit you quite quickly without appropriate control of the VLANs
> >
> > 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
>
> End of cisco-nsp Digest, Vol 80, Issue 49
> *****************************************
>



-- 
-- 
Regards,
Digambar Giri
+91- 9975776368
_______________________________________________
cisco-nsp mailing list  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 Jul 14 11:00:36 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Tue, 14 Jul 2009 17:00:36 +0200
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <d6966e4b0907140724n61be11f5ra851690ceaabbd93@mail.gmail.com>
References: <9DE4AA6876D44B62B87C475B2AFE5514@au.didata.local>
	<a1873f1f0907131438m3f0b4c70r82a953a29042b6d7@mail.gmail.com>
	<1247524340.4661.65.camel@abehat.net.rm.dk>
	<20090714084503.GA15753@lboro.ac.uk>
	<d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>
	<Pine.LNX.4.61.0907140924470.6312@soloth.lewis.org>
	<d6966e4b0907140724n61be11f5ra851690ceaabbd93@mail.gmail.com>
Message-ID: <20090714150036.GP290@greenie.muc.de>

Hi,

On Tue, Jul 14, 2009 at 09:24:56AM -0500, Geoffrey Pendery wrote:
> At least in the case of the enterprise where I work, the "whole point
> of MST" is that it's a proper open standard, rather than one of those
> super scary Cisco Proprietary Protocols.

Nothing in (rapid) PVSTP is "super scary cisco proprietary".

It's just logical thinking - you have VLANs, you have STP, you need to
combine them to make it work in a useful way.  Result: PVSTP.  

I was more than astonished to find that other vendors still ship boxes 
with single-STP, and sell this as a "feature".

<rant>
MST is what comes out if vendor committees get together, and agree to
implement the least common determinator in the most complicated way.
</rant>

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/20090714/1c2c2f5d/attachment.bin>

From sthaug at nethelp.no  Tue Jul 14 11:03:44 2009
From: sthaug at nethelp.no (sthaug at nethelp.no)
Date: Tue, 14 Jul 2009 17:03:44 +0200 (CEST)
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <20090714141529.GN290@greenie.muc.de>
References: <d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>
	<Pine.LNX.4.61.0907140924470.6312@soloth.lewis.org>
	<20090714141529.GN290@greenie.muc.de>
Message-ID: <20090714.170344.41681444.sthaug@nethelp.no>

> We have found MST to be mostly pointless...
> 
> "Too much hassle, too little gain"
> 
> But then, we're a service provider environment, and there are hardly
> two VLANs that share the same topology - which maps very poorly to MST
> instances.  At the same time, there is a fairly high dynamic in adding
> and removing VLANs, which is *quite* painful with MST instance 
> mappings...

Depends on how you build your networks. If you build ring structures, I
can see how MST would be useful. We build ring structures but have chosen
the EAPS route instead.

> I just wish more vendors would see the light and implement rapid-PVSTP.

Rapid per VLAN spanning tree has scaling limitations in many environments.
Which is why some people go with MST instead.

Steinar Haug, Nethelp consulting, sthaug at nethelp.no

From Ian.Mackinnon at lumison.net  Tue Jul 14 11:03:45 2009
From: Ian.Mackinnon at lumison.net (Ian MacKinnon)
Date: Tue, 14 Jul 2009 16:03:45 +0100
Subject: [c-nsp] High CPU Usage
In-Reply-To: <91dee5fc0907140742o3cc279a1n445cf07e68b2dc88@mail.gmail.com>
References: <91dee5fc0907140742o3cc279a1n445cf07e68b2dc88@mail.gmail.com>
Message-ID: <B5F945E48C137C49A98BC86DD35939C012DB00A254@nbg01-exch-01.entlstaff.domain.lumison.net>

I haven't used a 2600 for a while, but I seem to remember they don't have a lot of grunt.

Your sh proc cpu shows 61% interrupt, there is a good guide for tracking down causes on the Cisco site somewhere <fx: googles) http://www.cisco.com/en/US/products/hw/routers/ps133/products_tech_note09186a00800a70f2.shtml


Check your interfaces for promiscuous mode, as that means every packet generates an interrupt.

Don't know if your IPSEC will be generating an interrupt when a packet hits the outgoing interface in order to do the encapsulation.

Ian



-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Jeremy Parr
Sent: 14 July 2009 15:43
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] High CPU Usage

I have a 2600 doing some GRE tunnel aggregation with IPSEC and a
AIM-VPN. The CPU is consistently at 95%+, but none of the running
processes are using nearly that much CPU. Is there some other place I
should be looking?

#sh processes cpu sorted
CPU utilization for five seconds: 99%/61%; one minute: 99%; five minutes: 98%
 PID Runtime(ms)   Invoked      uSecs   5Sec   1Min   5Min TTY Process
  70   163085876  24727077       6595 15.31% 16.49% 14.22%   0 IP Input
 146    42276796   9771758       4326  8.24%  8.66%  7.46%   0 Crypto Support
 169    38417520   7286822       5272  5.22%  4.94%  5.12%   0 Crypto PAS Proc
   6    21018268   2714504       7742  4.05%  4.99%  4.24%   0 Pool Manager
  54       65680      2206      29773  2.20%  0.71%  1.20%  66 SSH Process
 190     5281352   6682003        790  0.48%  0.47%  0.45%   0 IP-EIGRP: HELLO
 121     1163120   7759419        149  0.24%  0.16%  0.13%   0 RBSCP Background
  95      709328   1161174        610  0.16%  0.07%  0.06%   0 CEF process
_______________________________________________
cisco-nsp mailing 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.
Finally, the recipient should check this email and any attachments for the
presence of viruses.  Lumison accept no liability for any
damage caused by any virus transmitted by this email.

From rdobbins at arbor.net  Tue Jul 14 11:13:43 2009
From: rdobbins at arbor.net (Roland Dobbins)
Date: Tue, 14 Jul 2009 22:13:43 +0700
Subject: [c-nsp] High CPU Usage
In-Reply-To: <91dee5fc0907140742o3cc279a1n445cf07e68b2dc88@mail.gmail.com>
References: <91dee5fc0907140742o3cc279a1n445cf07e68b2dc88@mail.gmail.com>
Message-ID: <1ABBED82-9DFA-438E-A5FB-396AED12DF8B@arbor.net>


On Jul 14, 2009, at 9:42 PM, Jeremy Parr wrote:

> CPU utilization for five seconds: 99%/61%; one minute: 99%; five  
> minutes: 98%

It's the 61%, which indicates interrupt-driven CPU (corresponds with  
the high IP Input process %).

Packets being punted at a relatively high pps rate; do you have  
NetFlow enabled in order to characterize your traffic?  Is the AIM in  
fact handling your GRE tunnels, or is the GRE traffic being handed in  
software on the CPU?

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

         Unfortunately, inefficiency scales really well.

		   -- Kevin Lawton


From gert at greenie.muc.de  Tue Jul 14 11:12:04 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Tue, 14 Jul 2009 17:12:04 +0200
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <20090714.170344.41681444.sthaug@nethelp.no>
References: <d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>
	<Pine.LNX.4.61.0907140924470.6312@soloth.lewis.org>
	<20090714141529.GN290@greenie.muc.de>
	<20090714.170344.41681444.sthaug@nethelp.no>
Message-ID: <20090714151204.GQ290@greenie.muc.de>

Hi,

On Tue, Jul 14, 2009 at 05:03:44PM +0200, sthaug at nethelp.no wrote:
> > I just wish more vendors would see the light and implement rapid-PVSTP.
> 
> Rapid per VLAN spanning tree has scaling limitations in many environments.
> Which is why some people go with MST instead.

Usually they claim "it's Cisco proprietary, MST is a proper standard!!!!"
instead.

We have lots of customer setups with ~ 3-4 VLANs each, two of these connecting
to our gear (management network and external/production network) and the 
rest spread across a wild mix of different switch vendors, some of them 
not even getting MST right.  Fun to debug.  NOT.

MST seems too complex for an average coder to get right...  (it's definitely
too complex for your average network admin).

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/20090714/a24e8f51/attachment.bin>

From rodunn at cisco.com  Tue Jul 14 11:15:02 2009
From: rodunn at cisco.com (Rodney Dunn)
Date: Tue, 14 Jul 2009 11:15:02 -0400
Subject: [c-nsp] High CPU Usage
In-Reply-To: <91dee5fc0907140742o3cc279a1n445cf07e68b2dc88@mail.gmail.com>
References: <91dee5fc0907140742o3cc279a1n445cf07e68b2dc88@mail.gmail.com>
Message-ID: <20090714151502.GJ9418@rtp-cse-489.cisco.com>

'sh ip traffic' and look for fragmentation issues.

The #1 cause of high ip input CPU in tunnel environments.

http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml

Rodney

On Tue, Jul 14, 2009 at 10:42:51AM -0400, Jeremy Parr wrote:
> I have a 2600 doing some GRE tunnel aggregation with IPSEC and a
> AIM-VPN. The CPU is consistently at 95%+, but none of the running
> processes are using nearly that much CPU. Is there some other place I
> should be looking?
> 
> #sh processes cpu sorted
> CPU utilization for five seconds: 99%/61%; one minute: 99%; five minutes: 98%
>  PID Runtime(ms)   Invoked      uSecs   5Sec   1Min   5Min TTY Process
>   70   163085876  24727077       6595 15.31% 16.49% 14.22%   0 IP Input
>  146    42276796   9771758       4326  8.24%  8.66%  7.46%   0 Crypto Support
>  169    38417520   7286822       5272  5.22%  4.94%  5.12%   0 Crypto PAS Proc
>    6    21018268   2714504       7742  4.05%  4.99%  4.24%   0 Pool Manager
>   54       65680      2206      29773  2.20%  0.71%  1.20%  66 SSH Process
>  190     5281352   6682003        790  0.48%  0.47%  0.45%   0 IP-EIGRP: HELLO
>  121     1163120   7759419        149  0.24%  0.16%  0.13%   0 RBSCP Background
>   95      709328   1161174        610  0.16%  0.07%  0.06%   0 CEF process
> _______________________________________________
> cisco-nsp mailing list  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  Tue Jul 14 11:16:57 2009
From: jlewis at lewis.org (Jon Lewis)
Date: Tue, 14 Jul 2009 11:16:57 -0400 (EDT)
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <20090714141529.GN290@greenie.muc.de>
References: <9DE4AA6876D44B62B87C475B2AFE5514@au.didata.local>
	<a1873f1f0907131438m3f0b4c70r82a953a29042b6d7@mail.gmail.com>
	<1247524340.4661.65.camel@abehat.net.rm.dk>
	<20090714084503.GA15753@lboro.ac.uk>
	<d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>
	<Pine.LNX.4.61.0907140924470.6312@soloth.lewis.org>
	<20090714141529.GN290@greenie.muc.de>
Message-ID: <Pine.LNX.4.61.0907141101240.6312@soloth.lewis.org>

On Tue, 14 Jul 2009, Gert Doering wrote:

> On Tue, Jul 14, 2009 at 09:26:13AM -0400, Jon Lewis wrote:
>> But isn't that the whole point of MST?
>
> We have found MST to be mostly pointless...
>
> "Too much hassle, too little gain"

So do you just do rapid-pvst and limit which VLANs are allowed on all 
trunk ports?  I know you're not a fan of VTP, and I suppose this may be 
another reason.  Even with the trunks limiting which VLANs get through, 
VTP still creates all the vlans on all the switches, and in a PVST setup, 
they run a spanning tree instance for each VLAN, even if they aren't 
really participating in the VLAN.

> two VLANs that share the same topology - which maps very poorly to MST
> instances.  At the same time, there is a fairly high dynamic in adding
> and removing VLANs, which is *quite* painful with MST instance
> mappings...

I've wondered about that...if we were to move to MST, we're going to have 
to assign every VLAN to an MST instance, which could get messy.

Maybe it is time to just turn off VTP and manually create VLANs only where 
they're needed, in which case we'll only have to worry about the number of 
PVST instances on the central 6509s, as there's no way we'd run up to 128 
VLANs on a 3550.  We've actually never done VTP on the 6500s...only on the 
3550s.  I figured if VTP ever did blow up, I didn't want it blowing on the 
central switches...just the edges.


----------------------------------------------------------------------
  Jon Lewis                   |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

From masood at nexlinx.net.pk  Tue Jul 14 12:22:04 2009
From: masood at nexlinx.net.pk (masood at nexlinx.net.pk)
Date: Tue, 14 Jul 2009 21:22:04 +0500 (PKT)
Subject: [c-nsp] High CPU Usage
In-Reply-To: <91dee5fc0907140742o3cc279a1n445cf07e68b2dc88@mail.gmail.com>
References: <91dee5fc0907140742o3cc279a1n445cf07e68b2dc88@mail.gmail.com>
Message-ID: <42769.196.46.241.57.1247588524.squirrel@nexmail1.nexlinx.net.pk>

because it's interrupt level work the CPU is doing. you can try
profiling the CPU and see what it says.

can u get a couple of sh stacks and look at the interrupt level calls and
see which one is going up the most.

Regards,
Masood

> I have a 2600 doing some GRE tunnel aggregation with IPSEC and a
> AIM-VPN. The CPU is consistently at 95%+, but none of the running
> processes are using nearly that much CPU. Is there some other place I
> should be looking?
>
> #sh processes cpu sorted
> CPU utilization for five seconds: 99%/61%; one minute: 99%; five minutes:
> 98%
>  PID Runtime(ms)   Invoked      uSecs   5Sec   1Min   5Min TTY Process
>   70   163085876  24727077       6595 15.31% 16.49% 14.22%   0 IP Input
>  146    42276796   9771758       4326  8.24%  8.66%  7.46%   0 Crypto
> Support
>  169    38417520   7286822       5272  5.22%  4.94%  5.12%   0 Crypto PAS
> Proc
>    6    21018268   2714504       7742  4.05%  4.99%  4.24%   0 Pool
> Manager
>   54       65680      2206      29773  2.20%  0.71%  1.20%  66 SSH Process
>  190     5281352   6682003        790  0.48%  0.47%  0.45%   0 IP-EIGRP:
> HELLO
>  121     1163120   7759419        149  0.24%  0.16%  0.13%   0 RBSCP
> Background
>   95      709328   1161174        610  0.16%  0.07%  0.06%   0 CEF process
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>



From geoff at pendery.net  Tue Jul 14 11:35:33 2009
From: geoff at pendery.net (Geoffrey Pendery)
Date: Tue, 14 Jul 2009 10:35:33 -0500
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <Pine.LNX.4.61.0907141101240.6312@soloth.lewis.org>
References: <9DE4AA6876D44B62B87C475B2AFE5514@au.didata.local>
	<a1873f1f0907131438m3f0b4c70r82a953a29042b6d7@mail.gmail.com>
	<1247524340.4661.65.camel@abehat.net.rm.dk>
	<20090714084503.GA15753@lboro.ac.uk>
	<d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>
	<Pine.LNX.4.61.0907140924470.6312@soloth.lewis.org>
	<20090714141529.GN290@greenie.muc.de>
	<Pine.LNX.4.61.0907141101240.6312@soloth.lewis.org>
Message-ID: <d6966e4b0907140835u597c7ae3l3991ba636ae93bcf@mail.gmail.com>

Like Gert, I much prefer to have the system running "un-needed"
instances as the tradeoff for not having to design and manage instance
topology, and couple VLANs together, causing TCNs/blocking on VLANs
which haven't experienced any disruption.

"I've wondered about that...if we were to move to MST, we're going to
have to assign every VLAN to an MST instance, which could get messy."

That's exactly why I was warning about the 16/64 instance limit.  This
was my mindset when moving from PVST to MST, and I suspect there are
many others out there thinking this way.  But if you have more than 64
VLANs, you can't do that.  You'll have to look at their topology and
try to map them into a limited number of instances.  Most of the IOS
docs I've found say 16, not 64, but I have yet to test that out in the
lab.

Gert,

I think we mostly agree, and my sarcasm about the "scary proprietary"
bit didn't come across.
It's our management/architects here who are vehemently against the
Cisco Proprietary stuff; I just live with their edicts.
But then again, your statement that RPVST isn't proprietary is wrong,
and the statement that it's not scary tells me you've never tried to
plug it into an Enterasys core...
; )



-Geoff



On Tue, Jul 14, 2009 at 10:16 AM, Jon Lewis<jlewis at lewis.org> wrote:
> On Tue, 14 Jul 2009, Gert Doering wrote:
>
>> On Tue, Jul 14, 2009 at 09:26:13AM -0400, Jon Lewis wrote:
>>>
>>> But isn't that the whole point of MST?
>>
>> We have found MST to be mostly pointless...
>>
>> "Too much hassle, too little gain"
>
> So do you just do rapid-pvst and limit which VLANs are allowed on all trunk
> ports? ?I know you're not a fan of VTP, and I suppose this may be another
> reason. ?Even with the trunks limiting which VLANs get through, VTP still
> creates all the vlans on all the switches, and in a PVST setup, they run a
> spanning tree instance for each VLAN, even if they aren't really
> participating in the VLAN.
>
>> two VLANs that share the same topology - which maps very poorly to MST
>> instances. ?At the same time, there is a fairly high dynamic in adding
>> and removing VLANs, which is *quite* painful with MST instance
>> mappings...
>
> I've wondered about that...if we were to move to MST, we're going to have to
> assign every VLAN to an MST instance, which could get messy.
>
> Maybe it is time to just turn off VTP and manually create VLANs only where
> they're needed, in which case we'll only have to worry about the number of
> PVST instances on the central 6509s, as there's no way we'd run up to 128
> VLANs on a 3550. ?We've actually never done VTP on the 6500s...only on the
> 3550s. ?I figured if VTP ever did blow up, I didn't want it blowing on the
> central switches...just the edges.
>
>
> ----------------------------------------------------------------------
> ?Jon Lewis ? ? ? ? ? ? ? ? ? | ?I route
> ?Senior Network Engineer ? ? | ?therefore you are
> ?Atlantic Net ? ? ? ? ? ? ? ?|
> _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
>

From steve.tillinger at sourcemedia.com  Tue Jul 14 10:35:12 2009
From: steve.tillinger at sourcemedia.com (Tillinger, Steve)
Date: Tue, 14 Jul 2009 10:35:12 -0400
Subject: [c-nsp] ASA ssh difficulties
References: <725755F5E728EE4086DAAF1A54DACF4F153BBDA5@sea5exbe1.speakeasy.hq><a2b352c40907140715ob0c0901tcc0f287005c7002d@mail.gmail.com>
	<a2b352c40907140716l4b4332ecmb9b1104c833921d3@mail.gmail.com>
Message-ID: <B72B2A74B96CAB468FE8F11992B211D98198@nycex01.corp.int>

Have you tried 'pix' as the username?


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Nick Griffin
Sent: Tuesday, July 14, 2009 10:16 AM
To: Jonathan Brashear
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] ASA ssh difficulties

sorry, location = local :)

On Tue, Jul 14, 2009 at 9:15 AM, Nick Griffin
<nick.jon.griffin at gmail.com>wrote:

> Make sure ssh is setup for location authentication and possibly 
> regenerate your ssh keys:
> this is what I usually do:
>
> crypto key generate rsa general modul 2048
>
> aaa authentication telnet console LOCAL
>
> aaa authentication ssh console LOCAL
>
> aaa authentication http console LOCAL
>
> aaa authentication serial console LOCAL
>
>
>
> Nick Griffin, CCIE #17381
> Systems Consultant Alexander Open Systems Direct 479.899.6830 ext 2609

> AOS Scheduling - 417.888.2675
>
> On Tue, Jul 14, 2009 at 9:05 AM, Jonathan Brashear < 
> Jonathan.Brashear at hq.speakeasy.net> wrote:
>
>> I'm a bit stumped on an issue I'm having with a particular 5505.
>>  Originally it was inaccessible via ASDM or SSH, but after a reboot 
>> it began to allow access via ASDM.  However, SSH is still not 
>> working.  I've verified that the username/pass is correct(it works 
>> through the ASDM) and that SSH access is allowed from the relevant IP

>> range(I get to a password prompt), but it refuses to accept known 
>> good passwords from multiple accounts.  It thinks the password is 
>> bad, but only when done via SSH.  I haven't run into this issue with 
>> other ASAs that are configured identically and I can login to the 
>> other ASAs from the same terminal window so it shouldn't be something

>> to do with my terminal emulation.  Any thoughts on why this may be
happening?
>>
>> 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/
>>
>
>
_______________________________________________
cisco-nsp mailing 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 communication is intended solely for the addressee and is confidential and not for third party unauthorized distribution"

From sthaug at nethelp.no  Tue Jul 14 11:41:38 2009
From: sthaug at nethelp.no (sthaug at nethelp.no)
Date: Tue, 14 Jul 2009 17:41:38 +0200 (CEST)
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <20090714150036.GP290@greenie.muc.de>
References: <Pine.LNX.4.61.0907140924470.6312@soloth.lewis.org>
	<d6966e4b0907140724n61be11f5ra851690ceaabbd93@mail.gmail.com>
	<20090714150036.GP290@greenie.muc.de>
Message-ID: <20090714.174138.71136866.sthaug@nethelp.no>

> MST is what comes out if vendor committees get together, and agree to
> implement the least common determinator in the most complicated way.

Which is part of the attraction of something like EAPS: It may have its
warts, but compared to MST it's extremely simple. I assume REP would
offer the same simplicity...

Steinar Haug, Nethelp consulting, sthaug at nethelp.no

From jlewis at lewis.org  Tue Jul 14 11:43:24 2009
From: jlewis at lewis.org (Jon Lewis)
Date: Tue, 14 Jul 2009 11:43:24 -0400 (EDT)
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <d6966e4b0907140835u597c7ae3l3991ba636ae93bcf@mail.gmail.com>
References: <9DE4AA6876D44B62B87C475B2AFE5514@au.didata.local> 
	<a1873f1f0907131438m3f0b4c70r82a953a29042b6d7@mail.gmail.com> 
	<1247524340.4661.65.camel@abehat.net.rm.dk>
	<20090714084503.GA15753@lboro.ac.uk>
	<d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com> 
	<Pine.LNX.4.61.0907140924470.6312@soloth.lewis.org>
	<20090714141529.GN290@greenie.muc.de>
	<Pine.LNX.4.61.0907141101240.6312@soloth.lewis.org>
	<d6966e4b0907140835u597c7ae3l3991ba636ae93bcf@mail.gmail.com>
Message-ID: <Pine.LNX.4.61.0907141139180.6312@soloth.lewis.org>

On Tue, 14 Jul 2009, Geoffrey Pendery wrote:

> "I've wondered about that...if we were to move to MST, we're going to
> have to assign every VLAN to an MST instance, which could get messy."
>
> That's exactly why I was warning about the 16/64 instance limit.  This
> was my mindset when moving from PVST to MST, and I suspect there are
> many others out there thinking this way.  But if you have more than 64
> VLANs, you can't do that.  You'll have to look at their topology and

That's not what I meant.  I just meant we'd have to decide which instance 
(of likely just a few of them) to assign every VLAN to...as every VLAN has 
to be assigned to some instance.  I should setup a lab of switches again 
and play around with MST.  IIRC, the docs I've read about MST on cisco.com 
generally split up the VLANs between MST instances 2 and 3.

----------------------------------------------------------------------
  Jon Lewis                   |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

From gert at greenie.muc.de  Tue Jul 14 11:46:50 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Tue, 14 Jul 2009 17:46:50 +0200
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <Pine.LNX.4.61.0907141101240.6312@soloth.lewis.org>
References: <9DE4AA6876D44B62B87C475B2AFE5514@au.didata.local>
	<a1873f1f0907131438m3f0b4c70r82a953a29042b6d7@mail.gmail.com>
	<1247524340.4661.65.camel@abehat.net.rm.dk>
	<20090714084503.GA15753@lboro.ac.uk>
	<d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>
	<Pine.LNX.4.61.0907140924470.6312@soloth.lewis.org>
	<20090714141529.GN290@greenie.muc.de>
	<Pine.LNX.4.61.0907141101240.6312@soloth.lewis.org>
Message-ID: <20090714154649.GR290@greenie.muc.de>

Hi,

On Tue, Jul 14, 2009 at 11:16:57AM -0400, Jon Lewis wrote:
> On Tue, 14 Jul 2009, Gert Doering wrote:
> >On Tue, Jul 14, 2009 at 09:26:13AM -0400, Jon Lewis wrote:
> >>But isn't that the whole point of MST?
> >
> >We have found MST to be mostly pointless...
> >
> >"Too much hassle, too little gain"
> 
> So do you just do rapid-pvst and limit which VLANs are allowed on all 
> trunk ports?  

Yes.

Most of our VLANs are actually quite "short reach", that is, they
are distributed like this

 ISP Router A (6500) == ISP Switch A (6500) -- CustomerX Switch A -- Hosts
     ||                        ||                     |
 ISP Router B (6500) == ISP Switch B (3550) -- CustomerX Switch B -- Hosts

(leave off row "B" for non-VRRP customers.  Double lines are trunks,
single lines are single-VLAN access ports)

There's an insane amount of switches and trunks, but most VLANs really
span only 3 (standard case) or 6 (HSRP/VRRP) devices.


The trunks between "ISP Router" and "ISP Switch" are pre-configured,
the links between "ISP Switch" and "customer switch" get configured
on-demand (from the VLAN range designated to "ISP Switch A")


> I know you're not a fan of VTP, and I suppose this may be 
> another reason.  Even with the trunks limiting which VLANs get through, 
> VTP still creates all the vlans on all the switches, and in a PVST setup, 
> they run a spanning tree instance for each VLAN, even if they aren't 
> really participating in the VLAN.

Yes, this would kill us immediately.  "ISP Switch A" could, theoretically,
have about 350 active VLANs (one VLAN per port, 7 blades x 48 ports),
while "ISP Switch B" would choke on more than 64...

"ISP Router A" is linked to 4 different 6500 distribution switches, and
could end up with more than 1000 active VLANs (in reality it doesn't, 
due to physical space constraints in this building :) ).


> >two VLANs that share the same topology - which maps very poorly to MST
> >instances.  At the same time, there is a fairly high dynamic in adding
> >and removing VLANs, which is *quite* painful with MST instance
> >mappings...
> 
> I've wondered about that...if we were to move to MST, we're going to have 
> to assign every VLAN to an MST instance, which could get messy.
> 
> Maybe it is time to just turn off VTP and manually create VLANs only where 
> they're needed, in which case we'll only have to worry about the number of 
> PVST instances on the central 6509s, as there's no way we'd run up to 128 
> VLANs on a 3550.  

Yep, this is what we do.  VLANs are really only created where they are
needed (some ranges are pre-created, others on-demand).

"switchport trunk allowed vlan *ADD* 1234"

is one of our favourites, tho... :-)

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/20090714/e7e8b9e5/attachment.bin>

From jlewis at lewis.org  Tue Jul 14 11:51:26 2009
From: jlewis at lewis.org (Jon Lewis)
Date: Tue, 14 Jul 2009 11:51:26 -0400 (EDT)
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <20090714154649.GR290@greenie.muc.de>
References: <9DE4AA6876D44B62B87C475B2AFE5514@au.didata.local>
	<a1873f1f0907131438m3f0b4c70r82a953a29042b6d7@mail.gmail.com>
	<1247524340.4661.65.camel@abehat.net.rm.dk>
	<20090714084503.GA15753@lboro.ac.uk>
	<d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>
	<Pine.LNX.4.61.0907140924470.6312@soloth.lewis.org>
	<20090714141529.GN290@greenie.muc.de>
	<Pine.LNX.4.61.0907141101240.6312@soloth.lewis.org>
	<20090714154649.GR290@greenie.muc.de>
Message-ID: <Pine.LNX.4.61.0907141149560.6312@soloth.lewis.org>

On Tue, 14 Jul 2009, Gert Doering wrote:

> Yep, this is what we do.  VLANs are really only created where they are
> needed (some ranges are pre-created, others on-demand).
>
> "switchport trunk allowed vlan *ADD* 1234"
>
> is one of our favourites, tho... :-)

I've been reluctant to roll that out on all the trunks due to the damage 
that could be caused if someone got careless and dropped the 'add' while 
adding a new VLAN to a trunk.

----------------------------------------------------------------------
  Jon Lewis                   |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

From andrea.montefusco at kyneste.com  Tue Jul 14 11:26:09 2009
From: andrea.montefusco at kyneste.com (Andrea Montefusco)
Date: Tue, 14 Jul 2009 17:26:09 +0200
Subject: [c-nsp] High CPU Usage
In-Reply-To: <91dee5fc0907140742o3cc279a1n445cf07e68b2dc88@mail.gmail.com>
References: <91dee5fc0907140742o3cc279a1n445cf07e68b2dc88@mail.gmail.com>
Message-ID: <4A5CA391.7070107@kyneste.com>

Jeremy Parr wrote:
> I have a 2600 doing some GRE tunnel aggregation with IPSEC and a
> AIM-VPN. The CPU is consistently at 95%+, but none of the running
> processes are using nearly that much CPU. Is there some other place I
> should be looking?

If you have ethernet interface(s) in trunk, check that (on the switch side)
only the right VLAN are enabled on switch ports.
In Catalyst you should have, under the trunk port, an instruction like

switchport trunk allowed vlan x,y,z

where x,y,z are the VLAN id defined/usefule in the router side.
Otherwise all the broadcast traffic of every VLAN
hits anyway the router and the CPU climbs.

   *am*


From gert at greenie.muc.de  Tue Jul 14 12:05:26 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Tue, 14 Jul 2009 18:05:26 +0200
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <Pine.LNX.4.61.0907141149560.6312@soloth.lewis.org>
References: <9DE4AA6876D44B62B87C475B2AFE5514@au.didata.local>
	<a1873f1f0907131438m3f0b4c70r82a953a29042b6d7@mail.gmail.com>
	<1247524340.4661.65.camel@abehat.net.rm.dk>
	<20090714084503.GA15753@lboro.ac.uk>
	<d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>
	<Pine.LNX.4.61.0907140924470.6312@soloth.lewis.org>
	<20090714141529.GN290@greenie.muc.de>
	<Pine.LNX.4.61.0907141101240.6312@soloth.lewis.org>
	<20090714154649.GR290@greenie.muc.de>
	<Pine.LNX.4.61.0907141149560.6312@soloth.lewis.org>
Message-ID: <20090714160526.GS290@greenie.muc.de>

Hi,

On Tue, Jul 14, 2009 at 11:51:26AM -0400, Jon Lewis wrote:
> On Tue, 14 Jul 2009, Gert Doering wrote:
> 
> >Yep, this is what we do.  VLANs are really only created where they are
> >needed (some ranges are pre-created, others on-demand).
> >
> >"switchport trunk allowed vlan *ADD* 1234"
> >
> >is one of our favourites, tho... :-)
> 
> I've been reluctant to roll that out on all the trunks due to the damage 
> that could be caused if someone got careless and dropped the 'add' while 
> adding a new VLAN to a trunk.

Yes :(

For most trunks, we use pre-configured ranges ("vlan 100-999 go to 
dist switch 1, 1000-1499 to dist switch 2, 1500-1999 to dist switch 3"),
but occasionally we need to do an odd one - and indeed, mistakes happen.

Mmmmh.  If one does TACACS command authentication, one could investigate
whether disallowing the "without-add/-delete" form of the command via
TACACS works...

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/20090714/bb809426/attachment.bin>

From A.L.M.Buxey at lboro.ac.uk  Tue Jul 14 12:21:32 2009
From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk)
Date: Tue, 14 Jul 2009 17:21:32 +0100
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <20090714.170344.41681444.sthaug@nethelp.no>
References: <d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>
	<Pine.LNX.4.61.0907140924470.6312@soloth.lewis.org>
	<20090714141529.GN290@greenie.muc.de>
	<20090714.170344.41681444.sthaug@nethelp.no>
Message-ID: <20090714162132.GB16671@lboro.ac.uk>

Hi,

> Rapid per VLAN spanning tree has scaling limitations in many environments.
> Which is why some people go with MST instead.

we hit the PVST limits so moved to RPVST..once we
hit those limits we're sure to be going to MST ;-)

alan

From A.L.M.Buxey at lboro.ac.uk  Tue Jul 14 12:24:28 2009
From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk)
Date: Tue, 14 Jul 2009 17:24:28 +0100
Subject: [c-nsp] ASA IPsec Tunnel Failover
In-Reply-To: <725755F5E728EE4086DAAF1A54DACF4F153BBD99@sea5exbe1.speakeasy.hq>
References: <D6147B25080EEE458FE5BEEE7B280F5D3C5D5B6720@exch01.austin.swinc.com>
	<743A3BD3-B0BE-4E5C-B63E-566BC3750964@gmail.com>
	<D2BEF91BFE51C743854D7AB86BA35A354984F7EC25@VMAILA.uoa.abdn.ac.uk>
	<725755F5E728EE4086DAAF1A54DACF4F153BBD99@sea5exbe1.speakeasy.hq>
Message-ID: <20090714162428.GC16671@lboro.ac.uk>

Hi,
> There's not as of yet.  OSPF, RIP, EIGRP, yes, BGP no. 

ISIS  ? stares blankly at the development team.

alan

From david.freedman at uk.clara.net  Tue Jul 14 12:34:06 2009
From: david.freedman at uk.clara.net (David Freedman)
Date: Tue, 14 Jul 2009 17:34:06 +0100
Subject: [c-nsp] c877 and ntp oddness
Message-ID: <h3ic1u$crf$1@ger.gmane.org>

Have a bizarre NTP issue with 877 routers running 12.4(T) train.

Have a simple network setup such:


   [HUB]---[S2 NTPD]-->[S1 NTPD]
  /  |  \
[S] [S] [S]


A private hub/spoke network where hub is 7200 and spokes are the 877
routers in question.

Connected to the hub router is a freebsd box running latest build ntpd
(recently upgraded) which is happily serving other clients as a stratum
2 box.

A large percentage of the 87x routers will sync happily with the S2 box
and stay in sync with it for their lifetimes.

a small percentage sync initially but then lose sync after 10 minutes.

On the happy boxes:


#sh ntp assoc

address         ref clock     st  when  poll reach  delay  offset   disp
*~<S2>           <S1>         2    28   512  377     8.5    0.13     7.5


on the sad boxes:

#sh ntp assoc

address    ref clock       st   when   poll reach  delay  offset   disp
~<S2>       <S1>            2     43     64   377  0.000 134559. 1938.5


#sh ntp assoc det
<S2> configured, insane, invalid, stratum 2
ref ID <S1>  , time CE071C7B.D722D2EE (16:02:19.840 BST Tue Jul 14 2009)
our mode client, peer mode server, our poll intvl 64, peer poll intvl 64
root delay 0.00 msec, root disp 15.53, reach 377, sync dist 2.38
delay 0.00 msec, offset 134559.7237 msec, dispersion 1938.59
precision 2**18, version 4
org time CE071F24.C3B751E7 (16:13:40.764 BST Tue Jul 14 2009)
rec time CE071E9D.B07AD5A3 (16:11:25.689 BST Tue Jul 14 2009)
xmt time CE071E9D.A8FD405C (16:11:25.660 BST Tue Jul 14 2009)
filtdelay =     0.02    0.05    0.02    0.00    0.00    0.00    0.00    0.00
filtoffset =  135.08  134.81  134.55    0.00    0.00    0.00    0.00    0.00
filterror =     0.00    0.00    0.00   16.00   16.00   16.00   16.00   16.00
minpoll = 6, maxpoll = 10


*Jul 14 15:45:47.737: NTP recv pkt on v4 socket, pak = 0x83E79C78.
*Jul 14 15:45:47.737: NTP message received from <S2> on interface 'Dialer0':
*Jul 14 15:45:47.737:
 NTP Header:
   Leap = 00, Version = 4, Mode = 4,
   Stratum = 2,
   Poll Interval = 6,
   Precision = -18,
   Root Delay = 0.82,
   Root Dispersion = 0.1755,
   refid = <S1>,
   Last update reftime = 3456574670.3602360983,
   Originated time = 3456575147.3064944142,
   Received time = 3456575152.3162200771,
   Transmit time = 3456575152.3162396127.



To get it back, I simply remove the "clock-period" and reconfigure the
ntp server and I get another 10 mins of working ntp.


This is only happening to a very small percentage of routers from a new
batch recently purchased, I'm wondering if the "clock-period"
calculation is wrong?

Stuff that is the same between working/nonworking routers

- clock/timezone config
- latency and network quality between router and S2 server
- receipt of NTP packets (debug ntp pack shows *all* are being received
and processed so not an acl/filtering issue)

bugtool seems to be broken when searching for keyword "NTP" in all
12.4(T) train, I've reported this (just gives me blank screen in
multiple browsers), release notes do not show anything of interest.

Anybody with good NTP foo able to look at this and immediately
spot something obvious? or could it be there is a hardware problem in
this batch?

Footnotes:

- Upgraded to 12.4(22)T where clock-period is no longer configurable by
operator, same problem occurs.

- Only seems to affect a small percentage of 877 routers,
878s, 1800s , 2800s seem to be fine


Dave.


From harbor235 at gmail.com  Tue Jul 14 12:50:42 2009
From: harbor235 at gmail.com (harbor235)
Date: Tue, 14 Jul 2009 12:50:42 -0400
Subject: [c-nsp] CE routes
Message-ID: <836bf1f90907140950w4d6e25cfh29fb15816e5bc48d@mail.gmail.com>

I was just reading best practices for MPLS implementations regarding CE to
CE connectivity issues,
specifically, CE to CE pings. The document stated that redistributing
connected PE routes into BGP was
the preferred method to ensure CE to CE ping success as well as other
connectivity issues. This will inject
the route for the PE to CE interface into BGP.I am not sure I agree,  why
not explicitly define which networks to advertise
in the IGP, an IGP in MPLS networks is supposed to hold all infrastructure
routes anyway. Are these interfaces considered
infrstructure or customer interfaces? One reason may be to reduce the number
of infrastructure routes in the IGP because of the
potential for many CE to PE interfaces, let BGP handle the large number of
routes?

I am curious which method is employed in the wild, also I am not sure all
connected routes
should be advertised from the PE, e.g. management/infrastructure interfaces
etc ...

What are your thoughts and how is it being done?

mike

From tdurack at gmail.com  Tue Jul 14 13:01:23 2009
From: tdurack at gmail.com (Tim Durack)
Date: Tue, 14 Jul 2009 13:01:23 -0400
Subject: [c-nsp] WAAS and minimum latency
Message-ID: <9e246b4d0907141001w66aeba1dy68255bdc780e82e0@mail.gmail.com>

Anyone got figures on the *minimum* latency the various WAN accelerators can
improve on?

I ask as I have a customer with a couple of sites connected via GigE. RTT
for SiteA -> SiteB is around 3ms. Migrating services between sites has
reduced performance for some users (appears that SMB/CIFS is most affected.)

I'm looking to see if I can "fix" things with WAAS, just not sure they are
really designed for this scenario (I'm not a fan of WAAS, but if it fixes a
problem...)

Thanks,

Tim:>

From Jonathan.Brashear at hq.speakeasy.net  Tue Jul 14 13:18:51 2009
From: Jonathan.Brashear at hq.speakeasy.net (Jonathan Brashear)
Date: Tue, 14 Jul 2009 10:18:51 -0700
Subject: [c-nsp] ASA ssh difficulties
In-Reply-To: <a2b352c40907140715ob0c0901tcc0f287005c7002d@mail.gmail.com>
References: <725755F5E728EE4086DAAF1A54DACF4F153BBDA5@sea5exbe1.speakeasy.hq>
	<a2b352c40907140715ob0c0901tcc0f287005c7002d@mail.gmail.com>
Message-ID: <725755F5E728EE4086DAAF1A54DACF4F153BBE5A@sea5exbe1.speakeasy.hq>

Nick nailed it, thanks. :)  The tech that built this firewall missed this line:
aaa authentication ssh console LOCAL 


Network Engineer, JNCIS-M
> 214-981-1954 (office) 
> 214-642-4075 (cell)
> jbrashear at hq.speakeasy.net 
http://www.speakeasy.net
-----Original Message-----
From: Nick Griffin [mailto:nick.jon.griffin at gmail.com] 
Sent: Tuesday, July 14, 2009 9:16 AM
To: Jonathan Brashear
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] ASA ssh difficulties

Make sure ssh is setup for location authentication and possibly regenerate your ssh keys:

this is what I usually do:


crypto key generate rsa general modul 2048

aaa authentication telnet console LOCAL

aaa authentication ssh console LOCAL

aaa authentication http console LOCAL

aaa authentication serial console LOCAL






Nick Griffin, CCIE #17381 
Systems Consultant Alexander Open Systems
Direct 479.899.6830 ext 2609 
AOS Scheduling - 417.888.2675

On Tue, Jul 14, 2009 at 9:05 AM, Jonathan Brashear <Jonathan.Brashear at hq.speakeasy.net> wrote:


	I'm a bit stumped on an issue I'm having with a particular 5505.  Originally it was inaccessible via ASDM or SSH, but after a reboot it began to allow access via ASDM.  However, SSH is still not working.  I've verified that the username/pass is correct(it works through the ASDM) and that SSH access is allowed from the relevant IP range(I get to a password prompt), but it refuses to accept known good passwords from multiple accounts.  It thinks the password is bad, but only when done via SSH.  I haven't run into this issue with other ASAs that are configured identically and I can login to the other ASAs from the same terminal window so it shouldn't be something to do with my terminal emulation.  Any thoughts on why this may be happening?
	
	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/
	



From tdurack at gmail.com  Tue Jul 14 13:20:53 2009
From: tdurack at gmail.com (Tim Durack)
Date: Tue, 14 Jul 2009 13:20:53 -0400
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <Pine.LNX.4.61.0907141139180.6312@soloth.lewis.org>
References: <9DE4AA6876D44B62B87C475B2AFE5514@au.didata.local>
	<a1873f1f0907131438m3f0b4c70r82a953a29042b6d7@mail.gmail.com>
	<1247524340.4661.65.camel@abehat.net.rm.dk>
	<20090714084503.GA15753@lboro.ac.uk>
	<d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>
	<Pine.LNX.4.61.0907140924470.6312@soloth.lewis.org>
	<20090714141529.GN290@greenie.muc.de>
	<Pine.LNX.4.61.0907141101240.6312@soloth.lewis.org>
	<d6966e4b0907140835u597c7ae3l3991ba636ae93bcf@mail.gmail.com>
	<Pine.LNX.4.61.0907141139180.6312@soloth.lewis.org>
Message-ID: <9e246b4d0907141020v4189c867mcb5e8208454fbc4d@mail.gmail.com>

On Tue, Jul 14, 2009 at 11:43 AM, Jon Lewis <jlewis at lewis.org> wrote:

> On Tue, 14 Jul 2009, Geoffrey Pendery wrote:
>
>  "I've wondered about that...if we were to move to MST, we're going to
>> have to assign every VLAN to an MST instance, which could get messy."
>>
>> That's exactly why I was warning about the 16/64 instance limit.  This
>> was my mindset when moving from PVST to MST, and I suspect there are
>> many others out there thinking this way.  But if you have more than 64
>> VLANs, you can't do that.  You'll have to look at their topology and
>>
>
> That's not what I meant.  I just meant we'd have to decide which instance
> (of likely just a few of them) to assign every VLAN to...as every VLAN has
> to be assigned to some instance.  I should setup a lab of switches again and
> play around with MST.  IIRC, the docs I've read about MST on cisco.comgenerally split up the VLANs between MST instances 2 and 3.
>
>
We left everything in MST0, and pull a few VLANs into MST2 for
load-balancing reasons. Core-1 is root for MST0, Core-2 is root for MST2.
Works for a simple topology, where every switch has redundant links back to
a couple of core switches. Not sure it would be so great for the kind of
topologies being discussed here.

However, as soon as I want to add another VLAN to MST2, I have touch *every*
switch in the MST region. And during the process MST is inconsistent -
either I adjust the two core switches first, and every edge switch flips
over to MST0, or I do every edge switch first, core last. Either way it's a
lot of STP fun.

I'm going to guess the standards body that came up with MST doesn't do too
much network configuration work...

Tim:>

From alasdairm at gmail.com  Tue Jul 14 13:33:01 2009
From: alasdairm at gmail.com (Alasdair McWilliam)
Date: Tue, 14 Jul 2009 18:33:01 +0100
Subject: [c-nsp] VSS out-of-band mgmt
In-Reply-To: <D0D0330CBD07114D85B70B784E80C2F2022FD332@exch-mail2.win.slac.stanford.edu>
References: <A9C0DC3E3383224B83C528B074390E8C129756@xmail04.ad.ua.ac.be>
	<D718CB87-D418-4553-8BC1-A4E1E7DFC7CE@gmail.com>
	<D0D0330CBD07114D85B70B784E80C2F2022FD332@exch-mail2.win.slac.stanford.edu>
Message-ID: <C87612BC-6220-4DF2-B577-6CD999F8687E@gmail.com>

We have VSS deployed and it's management interface is on a mgmt-vrf.  
So far everything that needs a source interface seems to work,  
although I've not actually configured syslog yet, TACACS is now vrf  
aware. You have to define a specific AAA server group. Eg:

tacacs-server host 1.1.1.1 key myacskey
tacacs-server directed-broadcast
ip tacacs source-interface VlanXYZ

Then:

aaa group server tacacs+ ACS-GROUP-NAME
   server 1.1.1.1
   ip vrf forwarding mgmt-vrf
!

aaa authentication login default group ACS-GROUP-NAME local-case

I will note that you have to define each server with the tacacs-server  
command before you add it to the group otherwise it throws an error.


Al


On 13 Jul 2009, at 18:47, Buhrmaster, Gary wrote:

>> Yes, a "management" VRF will do exactly what you want :-)
>
> Perhaps things have improved, but at one time for the 6500
> platform certain functions could only be performed in the
> "native"(? is that the right word) context, and you needed
> to place all the rest of your traffic/interfaces in a VRF
> leaving the "native" context for management (sort of the
> reverse of your proposal, instead have a "Internet" VRF
> for everything except for management).
>
> Have the latest IOS versions eliminated those challenges
> on the 6500?
>
> Gary


From sthaug at nethelp.no  Tue Jul 14 13:37:27 2009
From: sthaug at nethelp.no (sthaug at nethelp.no)
Date: Tue, 14 Jul 2009 19:37:27 +0200 (CEST)
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <Pine.LNX.4.61.0907141149560.6312@soloth.lewis.org>
References: <Pine.LNX.4.61.0907141101240.6312@soloth.lewis.org>
	<20090714154649.GR290@greenie.muc.de>
	<Pine.LNX.4.61.0907141149560.6312@soloth.lewis.org>
Message-ID: <20090714.193727.74678762.sthaug@nethelp.no>

> > "switchport trunk allowed vlan *ADD* 1234"
> >
> > is one of our favourites, tho... :-)
> 
> I've been reluctant to roll that out on all the trunks due to the damage 
> that could be caused if someone got careless and dropped the 'add' while 
> adding a new VLAN to a trunk.

With suitable TACACS verification of commands you can make *only*
the following available:

switchport trunk allowed vlan none
switchport trunk allowed vlan add ...
switchport trunk allowed vlan remove ...

which takes care of forgetting the add keyword. Done at the company
we're in the process of merging with, works great.

Steinar Haug, Nethelp consulting, sthaug at nethelp.no

From wim.holemans at ua.ac.be  Tue Jul 14 13:48:27 2009
From: wim.holemans at ua.ac.be (Holemans Wim)
Date: Tue, 14 Jul 2009 19:48:27 +0200
Subject: [c-nsp] VSS out-of-band mgmt
In-Reply-To: <C87612BC-6220-4DF2-B577-6CD999F8687E@gmail.com>
References: <A9C0DC3E3383224B83C528B074390E8C129756@xmail04.ad.ua.ac.be>
	<D718CB87-D418-4553-8BC1-A4E1E7DFC7CE@gmail.com>
	<D0D0330CBD07114D85B70B784E80C2F2022FD332@exch-mail2.win.slac.stanford.edu>
	<C87612BC-6220-4DF2-B577-6CD999F8687E@gmail.com>
Message-ID: <A9C0DC3E3383224B83C528B074390E8C129760@xmail04.ad.ua.ac.be>

Just implemented it based on an example I received yesterday ; we don't
deploy tacacs, so no problem there. Syslog doesn't work anymore for the
moment but I didn't check yet if it is vrf aware. 

Thanks for everyone who answered my question. If I tried out the syslog
config, I'll share the result on this list.

Wim Holemans


-----Original Message-----
From: Alasdair McWilliam [mailto:alasdairm at gmail.com] 
Sent: dinsdag 14 juli 2009 19:33
To: Buhrmaster, Gary
Cc: Holemans Wim; Cisco NSP
Subject: Re: [c-nsp] VSS out-of-band mgmt

We have VSS deployed and it's management interface is on a mgmt-vrf.  
So far everything that needs a source interface seems to work,  
although I've not actually configured syslog yet, TACACS is now vrf  
aware. You have to define a specific AAA server group. Eg:

tacacs-server host 1.1.1.1 key myacskey
tacacs-server directed-broadcast
ip tacacs source-interface VlanXYZ

Then:

aaa group server tacacs+ ACS-GROUP-NAME
   server 1.1.1.1
   ip vrf forwarding mgmt-vrf
!

aaa authentication login default group ACS-GROUP-NAME local-case

I will note that you have to define each server with the tacacs-server  
command before you add it to the group otherwise it throws an error.


Al


On 13 Jul 2009, at 18:47, Buhrmaster, Gary wrote:

>> Yes, a "management" VRF will do exactly what you want :-)
>
> Perhaps things have improved, but at one time for the 6500
> platform certain functions could only be performed in the
> "native"(? is that the right word) context, and you needed
> to place all the rest of your traffic/interfaces in a VRF
> leaving the "native" context for management (sort of the
> reverse of your proposal, instead have a "Internet" VRF
> for everything except for management).
>
> Have the latest IOS versions eliminated those challenges
> on the 6500?
>
> Gary


From wim.holemans at ua.ac.be  Tue Jul 14 13:55:36 2009
From: wim.holemans at ua.ac.be (Holemans Wim)
Date: Tue, 14 Jul 2009 19:55:36 +0200
Subject: [c-nsp] VSS out-of-band mgmt
In-Reply-To: <C87612BC-6220-4DF2-B577-6CD999F8687E@gmail.com>
References: <A9C0DC3E3383224B83C528B074390E8C129756@xmail04.ad.ua.ac.be>
	<D718CB87-D418-4553-8BC1-A4E1E7DFC7CE@gmail.com>
	<D0D0330CBD07114D85B70B784E80C2F2022FD332@exch-mail2.win.slac.stanford.edu>
	<C87612BC-6220-4DF2-B577-6CD999F8687E@gmail.com>
Message-ID: <A9C0DC3E3383224B83C528B074390E8C129761@xmail04.ad.ua.ac.be>

Tried syslog vrf awareness and yes :
logging host 143.169.x.y vrf management
did the trick

we are running 122-33.SXI1  on this VSS cluster.

Wim Holemans


-----Original Message-----
From: Alasdair McWilliam [mailto:alasdairm at gmail.com] 
Sent: dinsdag 14 juli 2009 19:33
To: Buhrmaster, Gary
Cc: Holemans Wim; Cisco NSP
Subject: Re: [c-nsp] VSS out-of-band mgmt

We have VSS deployed and it's management interface is on a mgmt-vrf.  
So far everything that needs a source interface seems to work,  
although I've not actually configured syslog yet, TACACS is now vrf  
aware. You have to define a specific AAA server group. Eg:

tacacs-server host 1.1.1.1 key myacskey
tacacs-server directed-broadcast
ip tacacs source-interface VlanXYZ

Then:

aaa group server tacacs+ ACS-GROUP-NAME
   server 1.1.1.1
   ip vrf forwarding mgmt-vrf
!

aaa authentication login default group ACS-GROUP-NAME local-case

I will note that you have to define each server with the tacacs-server  
command before you add it to the group otherwise it throws an error.


Al


On 13 Jul 2009, at 18:47, Buhrmaster, Gary wrote:

>> Yes, a "management" VRF will do exactly what you want :-)
>
> Perhaps things have improved, but at one time for the 6500
> platform certain functions could only be performed in the
> "native"(? is that the right word) context, and you needed
> to place all the rest of your traffic/interfaces in a VRF
> leaving the "native" context for management (sort of the
> reverse of your proposal, instead have a "Internet" VRF
> for everything except for management).
>
> Have the latest IOS versions eliminated those challenges
> on the 6500?
>
> Gary


From jlewis at lewis.org  Tue Jul 14 14:01:50 2009
From: jlewis at lewis.org (Jon Lewis)
Date: Tue, 14 Jul 2009 14:01:50 -0400 (EDT)
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <9e246b4d0907141020v4189c867mcb5e8208454fbc4d@mail.gmail.com>
References: <9DE4AA6876D44B62B87C475B2AFE5514@au.didata.local> 
	<a1873f1f0907131438m3f0b4c70r82a953a29042b6d7@mail.gmail.com> 
	<1247524340.4661.65.camel@abehat.net.rm.dk>
	<20090714084503.GA15753@lboro.ac.uk>
	<d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com> 
	<Pine.LNX.4.61.0907140924470.6312@soloth.lewis.org>
	<20090714141529.GN290@greenie.muc.de>
	<Pine.LNX.4.61.0907141101240.6312@soloth.lewis.org> 
	<d6966e4b0907140835u597c7ae3l3991ba636ae93bcf@mail.gmail.com> 
	<Pine.LNX.4.61.0907141139180.6312@soloth.lewis.org>
	<9e246b4d0907141020v4189c867mcb5e8208454fbc4d@mail.gmail.com>
Message-ID: <Pine.LNX.4.61.0907141355280.6312@soloth.lewis.org>

On Tue, 14 Jul 2009, Tim Durack wrote:

> We left everything in MST0, and pull a few VLANs into MST2 for
> load-balancing reasons. Core-1 is root for MST0, Core-2 is root for MST2.
> Works for a simple topology, where every switch has redundant links back to
> a couple of core switches. Not sure it would be so great for the kind of
> topologies being discussed here.

The cisco examples I saw say to leave MST0 empty and use MST1 and MST2 for 
VLANs.

This concerns me though:

  Complete any MST configuration involving a large number of either
  existing or new logical VLAN ports during a maintenance window because
  the complete MST database gets reinitialized for any incremental change
  (such as adding new VLANs to instances or moving VLANs across instances).

Will adding new VLANs to an MST instance disrupt traffic flow for other 
VLANs in that MST instance?

The topology I have is actually 2 core switches with a bunch of edge 
switches redundantly uplinked to both cores.

> However, as soon as I want to add another VLAN to MST2, I have touch *every*
> switch in the MST region. And during the process MST is inconsistent -
> either I adjust the two core switches first, and every edge switch flips
> over to MST0, or I do every edge switch first, core last. Either way it's a
> lot of STP fun.

That sounds like another argument for rPVST and turning off VTP to avoid 
hitting the PVST instance limit on the less capable switches.

----------------------------------------------------------------------
  Jon Lewis                   |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

From nick.jon.griffin at gmail.com  Tue Jul 14 14:21:05 2009
From: nick.jon.griffin at gmail.com (Nick Griffin)
Date: Tue, 14 Jul 2009 13:21:05 -0500
Subject: [c-nsp] ASA IPsec Tunnel Failover
In-Reply-To: <D6147B25080EEE458FE5BEEE7B280F5D3C5D5B6720@exch01.austin.swinc.com>
References: <D6147B25080EEE458FE5BEEE7B280F5D3C5D5B6720@exch01.austin.swinc.com>
Message-ID: <a2b352c40907141121hc722ad1vca7cf0ccb99ead46@mail.gmail.com>

Do you have any routers/layer 3 devices on the inside of the firewalls, the
weighted GRE tunnels always work well for this.

On Mon, Jul 13, 2009 at 3:14 PM, Munoz, Jeff <Jeff.Munoz at swinc.com> wrote:

> Hey guys, I have two main sites (site A and site B) and one remote site
> (site C).  Sites A and B have a metroethernet connection between them.
>  Remote site C has an IPsec tunnel back to site A.  I'd like to setup
> failover so in case site A's ASA is down the remote site C ASA sends the
> interesting traffic down the site B IPsec tunnel.  Unfortunately, it will
> always match the tunnel to site A since the phase 2 access lists have the
> same source/destinations.  Any ideas on how I can do this?
>
> Thanks!
>
> 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 geoff at pendery.net  Tue Jul 14 14:22:11 2009
From: geoff at pendery.net (Geoffrey Pendery)
Date: Tue, 14 Jul 2009 13:22:11 -0500
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <Pine.LNX.4.61.0907141355280.6312@soloth.lewis.org>
References: <9DE4AA6876D44B62B87C475B2AFE5514@au.didata.local>
	<20090714084503.GA15753@lboro.ac.uk>
	<d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>
	<Pine.LNX.4.61.0907140924470.6312@soloth.lewis.org>
	<20090714141529.GN290@greenie.muc.de>
	<Pine.LNX.4.61.0907141101240.6312@soloth.lewis.org>
	<d6966e4b0907140835u597c7ae3l3991ba636ae93bcf@mail.gmail.com>
	<Pine.LNX.4.61.0907141139180.6312@soloth.lewis.org>
	<9e246b4d0907141020v4189c867mcb5e8208454fbc4d@mail.gmail.com>
	<Pine.LNX.4.61.0907141355280.6312@soloth.lewis.org>
Message-ID: <d6966e4b0907141122g714a3e8bwfbee02edca4a80a8@mail.gmail.com>

> Will adding new VLANs to an MST instance disrupt traffic flow for other
> VLANs in that MST instance?

Yes.  We've verified this.
A trunk port carrying only VLAN 30, or even an access port carrying
only VLAN 30.
VLAN 30 is in instance 2.  You go into config mode and add VLAN 50 to
instance 2 (or remove it from instance 2)
The port, be it access or trunk, goes to blocking, learning, forwarding.


-Geoff

From peter at rathlev.dk  Tue Jul 14 14:26:31 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Tue, 14 Jul 2009 20:26:31 +0200
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <alpine.DEB.1.10.0907141752360.4415@puck.crap.retrofitta.se>
References: <9DE4AA6876D44B62B87C475B2AFE5514@au.didata.local>
	<a1873f1f0907131438m3f0b4c70r82a953a29042b6d7@mail.gmail.com>
	<1247524340.4661.65.camel@abehat.net.rm.dk>
	<alpine.DEB.1.10.0907141752360.4415@puck.crap.retrofitta.se>
Message-ID: <1247595990.2812.3.camel@abehat.net.rm.dk>

On Tue, 2009-07-14 at 17:56 +0200, Thomas Habets wrote:
> On Tue, 14 Jul 2009, Peter Rathlev wrote:
> > My bold guess would be that the system limit for number of STP
> > instances is 10000/13000 total virtual ports (RPVST/PVST).
> 
> 10'000 is what the documentation said, yes
> http://www.cisco.com/en/US/solutions/ns340/ns394/ns50/net_design_guidance0900aecd806fe4bb.pdf
> 
> > Whether having 1800+ STP instances on the same switch is a good idea
> > i something completely different. :-)
> 
> Not STP instances. 48 ports of aggregation with 50 VLANs will get you
> well over the virtual port limit. It's not "STP on 1800+ VLANs", and
> not unheard of.

That's for virtual ports yes. But that's not the same as STP instances.

As my lab test shows you can easily exceed 1800 RSTP instances. I kept
each of two modules on 1799 virtual ports, but with different VLANs on
each. Having more STP instances than VLANs would of course be difficuly,
so i guess the limit is around 4000 instances.

That's for RSTP. I'm afraid I don't know much about MST.

Regards,
Peter


From tdurack at gmail.com  Tue Jul 14 14:37:24 2009
From: tdurack at gmail.com (Tim Durack)
Date: Tue, 14 Jul 2009 14:37:24 -0400
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <d6966e4b0907141122g714a3e8bwfbee02edca4a80a8@mail.gmail.com>
References: <9DE4AA6876D44B62B87C475B2AFE5514@au.didata.local>
	<d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>
	<Pine.LNX.4.61.0907140924470.6312@soloth.lewis.org>
	<20090714141529.GN290@greenie.muc.de>
	<Pine.LNX.4.61.0907141101240.6312@soloth.lewis.org>
	<d6966e4b0907140835u597c7ae3l3991ba636ae93bcf@mail.gmail.com>
	<Pine.LNX.4.61.0907141139180.6312@soloth.lewis.org>
	<9e246b4d0907141020v4189c867mcb5e8208454fbc4d@mail.gmail.com>
	<Pine.LNX.4.61.0907141355280.6312@soloth.lewis.org>
	<d6966e4b0907141122g714a3e8bwfbee02edca4a80a8@mail.gmail.com>
Message-ID: <9e246b4d0907141137v3653261n53b452b98236971d@mail.gmail.com>

On Tue, Jul 14, 2009 at 2:22 PM, Geoffrey Pendery <geoff at pendery.net> wrote:

> > Will adding new VLANs to an MST instance disrupt traffic flow for other
> > VLANs in that MST instance?
>
> Yes.  We've verified this.
> A trunk port carrying only VLAN 30, or even an access port carrying
> only VLAN 30.
> VLAN 30 is in instance 2.  You go into config mode and add VLAN 50 to
> instance 2 (or remove it from instance 2)
> The port, be it access or trunk, goes to blocking, learning, forwarding.
>

...and if that doesn't make you nervous, you probably shouldn't be running
spanning-tree...

Tim:>

From peter at rathlev.dk  Tue Jul 14 14:40:17 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Tue, 14 Jul 2009 20:40:17 +0200
Subject: [c-nsp] Disallowing "sw tru all vlan X" w/o "add" or "remove" (was:
 Maximum spannig tree instances)
Message-ID: <1247596817.2812.13.camel@abehat.net.rm.dk>

On Tue, 2009-07-14 at 18:05 +0200, Gert Doering wrote:
> Mmmmh.  If one does TACACS command authentication, one could
> investigate whether disallowing the "without-add/-delete" form of the
> command via TACACS works...

It does indeed. We use something similar to the configuration below for
"operators" who can do simple maintenance chores.

group = operator {
	default service = deny
	login = PAM
	service = exec {
		priv-lvl = 15
	}
	...
	cmd = switchport {
		permit "^trunk allowed vlan add 1[0-9][0-9] <cr>$"
		permit "^trunk allowed vlan remove 1[0-9][0-9] <cr>$"
		...
	}
	...
}

Regards,
Peter



From clinton at scripty.com  Tue Jul 14 14:42:40 2009
From: clinton at scripty.com (Clinton Work)
Date: Tue, 14 Jul 2009 12:42:40 -0600
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <20090714084503.GA15753@lboro.ac.uk>
References: <9DE4AA6876D44B62B87C475B2AFE5514@au.didata.local>	<a1873f1f0907131438m3f0b4c70r82a953a29042b6d7@mail.gmail.com>	<1247524340.4661.65.camel@abehat.net.rm.dk>
	<20090714084503.GA15753@lboro.ac.uk>
Message-ID: <4A5CD1A0.70509@scripty.com>


You need to enable MAC reduction (extended vlan range) if you want to 
support all 4096 STP instances on a 6500.  I have personally seen over 
3000+ STP instances running using PVST+ with MAC reduction enabled.  MAC 
reduction will steal bits from the bridge priority in order create 4096 
unique bridge IDs.  The CPU load with PVST+ compared with MST is  vary 
dramatic.  As long as you stay away from the older 10/100 Ethernet cards 
PVST/ RPVST should scale fairly well.  I have seen PVST+ start to fail 
when you reach 75,000 virtual ports and MST can easily handle over 
100,000 virtual ports.

Clinton. 

A.L.M.Buxey at lboro.ac.uk wrote:
> regarding maximum STP instances... I believe theres a platform limit
> of 1024 because of the MAC to VLAN bridge mapping on the platform -
> but, from the values above, you can see that virtual ports would
> hit you quite quickly without appropriate control of the VLANs
>
> 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/
>   


-- 
==================================================================
Clinton Work
Airdrie, AB



From gert at greenie.muc.de  Tue Jul 14 14:50:05 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Tue, 14 Jul 2009 20:50:05 +0200
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <9e246b4d0907141020v4189c867mcb5e8208454fbc4d@mail.gmail.com>
References: <a1873f1f0907131438m3f0b4c70r82a953a29042b6d7@mail.gmail.com>
	<1247524340.4661.65.camel@abehat.net.rm.dk>
	<20090714084503.GA15753@lboro.ac.uk>
	<d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>
	<Pine.LNX.4.61.0907140924470.6312@soloth.lewis.org>
	<20090714141529.GN290@greenie.muc.de>
	<Pine.LNX.4.61.0907141101240.6312@soloth.lewis.org>
	<d6966e4b0907140835u597c7ae3l3991ba636ae93bcf@mail.gmail.com>
	<Pine.LNX.4.61.0907141139180.6312@soloth.lewis.org>
	<9e246b4d0907141020v4189c867mcb5e8208454fbc4d@mail.gmail.com>
Message-ID: <20090714185004.GT290@greenie.muc.de>

Hi,

On Tue, Jul 14, 2009 at 01:20:53PM -0400, Tim Durack wrote:
> I'm going to guess the standards body that came up with MST doesn't do too
> much network configuration work...

Real Networks[tm] have Maintenance Windows[tm].

Dunno whether anybody else remembers bay networks routers that had to
be rebooted(!) to accept configuration changes.  At my university, monday
morning was "network maintenance", that is "apply all config changes that
have piled up during the week, reboot, pray"...

(Did I mention that I don't like MST? :) )

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/20090714/0793fdbf/attachment.bin>

From jlewis at lewis.org  Tue Jul 14 14:52:23 2009
From: jlewis at lewis.org (Jon Lewis)
Date: Tue, 14 Jul 2009 14:52:23 -0400 (EDT)
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <d6966e4b0907141122g714a3e8bwfbee02edca4a80a8@mail.gmail.com>
References: <9DE4AA6876D44B62B87C475B2AFE5514@au.didata.local> 
	<20090714084503.GA15753@lboro.ac.uk>
	<d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>
	<Pine.LNX.4.61.0907140924470.6312@soloth.lewis.org>
	<20090714141529.GN290@greenie.muc.de>
	<Pine.LNX.4.61.0907141101240.6312@soloth.lewis.org> 
	<d6966e4b0907140835u597c7ae3l3991ba636ae93bcf@mail.gmail.com> 
	<Pine.LNX.4.61.0907141139180.6312@soloth.lewis.org> 
	<9e246b4d0907141020v4189c867mcb5e8208454fbc4d@mail.gmail.com> 
	<Pine.LNX.4.61.0907141355280.6312@soloth.lewis.org>
	<d6966e4b0907141122g714a3e8bwfbee02edca4a80a8@mail.gmail.com>
Message-ID: <Pine.LNX.4.61.0907141451100.6312@soloth.lewis.org>

On Tue, 14 Jul 2009, Geoffrey Pendery wrote:

> Yes.  We've verified this.
> A trunk port carrying only VLAN 30, or even an access port carrying
> only VLAN 30.
> VLAN 30 is in instance 2.  You go into config mode and add VLAN 50 to
> instance 2 (or remove it from instance 2)
> The port, be it access or trunk, goes to blocking, learning, forwarding.

Well...screw that.  That would mean only making MST changes during 
maintenance windows.  I guess it's time to turn off VTP and stick with 
pvst.

----------------------------------------------------------------------
  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  Tue Jul 14 14:55:15 2009
From: justin at justinshore.com (Justin Shore)
Date: Tue, 14 Jul 2009 13:55:15 -0500
Subject: [c-nsp] Give Cisco your feedback on the new download experience at
 tacwebsurvey@cisco.com (was: several heart-felt flames regarding the mess
 that is the Cisco.com download experience)
In-Reply-To: <A3A093A3-9EA7-4498-9205-CB272AF6A45B@puck.nether.net>
References: <9DE84313-097E-4D4C-A118-084AC527217D@puck.nether.net>	<20090713222139.GA78946@puck.nether.net>	<20090714063307.GB290@greenie.muc.de>
	<A3A093A3-9EA7-4498-9205-CB272AF6A45B@puck.nether.net>
Message-ID: <4A5CD493.70202@justinshore.com>

I received this message from Cisco yesterday.  I found the timing to be 
rather ironic.  I've munged the survey URL; I'm going to fill that out. 
  I would encourage EVERYONE to participate in this process by sending a 
letter to tacwebsurvey at cisco.com to let them know how they really feel 
about the "quality" of download experience that can be had on cisco.com.

Justin



"Dear Justin,

Last Friday, you visited Cisco Systems' on-line Technical Support & 
Documentation Website. Our records show that you accessed the following:

tools.cisco.com/support/downloads/go/DownloadImage.x

Customer loyalty is Cisco's top priority. To ensure that we continually 
measure our performance in meeting your needs, we have partnered with 
Walker Information to conduct a survey regarding our Technical Support & 
Documentation Website on Cisco.com: http://www.cisco.com/techsupport.

Please accept my invitation to participate in this survey by visiting 
this URL http://survey.walkerinfo.com/####################

If you are unable to click on the link, it can be copied and pasted into 
your browser.

This is a newly updated short survey that takes about 3 minutes to 
complete. I ask that you provide honest feedback, not only on our 
performance to date, but also on how we can better meet your needs going 
forward. Your valuable input will help establish continued improvement 
of the Technical Support & Documentation Website.

If you have any questions about this study, please feel free to email 
your comments or requests to tacwebsurvey at cisco.com . If you have any 
difficulties gaining access to the survey, please contact 
support at walkerinfo.com for technical assistance.

On behalf of Cisco Systems, thank you for being our customer and for 
participating in this survey.

Sincerely,


Julie Larsen
Sr. Director, Technical Support Website Team Cisco Systems, Inc.


To remove #################### from all future surveys conducted by 
Walker Information, follow this link:
http://survey.walkerinfo.com/remove.cfm?code=####################

If you have any questions, please send an email to support at walkerinfo.com.

Walker Information, Inc.
301 Pennsylvania Parkway
Indianapolis, IN 46280
United States"

From jared at puck.nether.net  Tue Jul 14 14:57:12 2009
From: jared at puck.nether.net (Jared Mauch)
Date: Tue, 14 Jul 2009 14:57:12 -0400
Subject: [c-nsp] Give Cisco your feedback on the new download experience
	at tacwebsurvey@cisco.com (was: several heart-felt flames
	regarding the mess that is the Cisco.com download experience)
In-Reply-To: <4A5CD493.70202@justinshore.com>
References: <9DE84313-097E-4D4C-A118-084AC527217D@puck.nether.net>	<20090713222139.GA78946@puck.nether.net>	<20090714063307.GB290@greenie.muc.de>
	<A3A093A3-9EA7-4498-9205-CB272AF6A45B@puck.nether.net>
	<4A5CD493.70202@justinshore.com>
Message-ID: <2454679F-A68A-483D-B116-1BAC7A0D3F1B@puck.nether.net>

I'm having a call with some people in a few minutes, I will share what  
is feasible to share once it's completed.

	- Jared

On Jul 14, 2009, at 2:55 PM, Justin Shore wrote:

> I received this message from Cisco yesterday.  I found the timing to  
> be rather ironic.  I've munged the survey URL; I'm going to fill  
> that out.  I would encourage EVERYONE to participate in this process  
> by sending a letter to tacwebsurvey at cisco.com to let them know how  
> they really feel about the "quality" of download experience that can  
> be had on cisco.com.
>
> Justin
>
>
>
> "Dear Justin,
>
> Last Friday, you visited Cisco Systems' on-line Technical Support &  
> Documentation Website. Our records show that you accessed the  
> following:
>
> tools.cisco.com/support/downloads/go/DownloadImage.x
>
> Customer loyalty is Cisco's top priority. To ensure that we  
> continually measure our performance in meeting your needs, we have  
> partnered with Walker Information to conduct a survey regarding our  
> Technical Support & Documentation Website on Cisco.com: http://www.cisco.com/techsupport 
> .
>
> Please accept my invitation to participate in this survey by  
> visiting this URL http://survey.walkerinfo.com/####################
>
> If you are unable to click on the link, it can be copied and pasted  
> into your browser.
>
> This is a newly updated short survey that takes about 3 minutes to  
> complete. I ask that you provide honest feedback, not only on our  
> performance to date, but also on how we can better meet your needs  
> going forward. Your valuable input will help establish continued  
> improvement of the Technical Support & Documentation Website.
>
> If you have any questions about this study, please feel free to  
> email your comments or requests to tacwebsurvey at cisco.com . If you  
> have any difficulties gaining access to the survey, please contact support at walkerinfo.com 
>  for technical assistance.
>
> On behalf of Cisco Systems, thank you for being our customer and for  
> participating in this survey.
>
> Sincerely,
>
>
> Julie Larsen
> Sr. Director, Technical Support Website Team Cisco Systems, Inc.
>
>
> To remove #################### from all future surveys conducted by  
> Walker Information, follow this link:
> http://survey.walkerinfo.com/remove.cfm?code=####################
>
> If you have any questions, please send an email to support at walkerinfo.com 
> .
>
> Walker Information, Inc.
> 301 Pennsylvania Parkway
> Indianapolis, IN 46280
> United States"


From jlewis at lewis.org  Tue Jul 14 14:59:37 2009
From: jlewis at lewis.org (Jon Lewis)
Date: Tue, 14 Jul 2009 14:59:37 -0400 (EDT)
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <20090714185004.GT290@greenie.muc.de>
References: <a1873f1f0907131438m3f0b4c70r82a953a29042b6d7@mail.gmail.com>
	<1247524340.4661.65.camel@abehat.net.rm.dk>
	<20090714084503.GA15753@lboro.ac.uk>
	<d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>
	<Pine.LNX.4.61.0907140924470.6312@soloth.lewis.org>
	<20090714141529.GN290@greenie.muc.de>
	<Pine.LNX.4.61.0907141101240.6312@soloth.lewis.org>
	<d6966e4b0907140835u597c7ae3l3991ba636ae93bcf@mail.gmail.com>
	<Pine.LNX.4.61.0907141139180.6312@soloth.lewis.org>
	<9e246b4d0907141020v4189c867mcb5e8208454fbc4d@mail.gmail.com>
	<20090714185004.GT290@greenie.muc.de>
Message-ID: <Pine.LNX.4.61.0907141457570.6312@soloth.lewis.org>

On Tue, 14 Jul 2009, Gert Doering wrote:

> Real Networks[tm] have Maintenance Windows[tm].

Yeah...but those should be for actual maintenance...software upgrades, 
major config changes, cable grooming, etc.  Not for basic tasks like 
turning up a new customer.  "Sorry, we can't provision your connection 
until next Tuesday's scheduled maintenance window."

----------------------------------------------------------------------
  Jon Lewis                   |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

From ip at ioshints.info  Tue Jul 14 15:02:09 2009
From: ip at ioshints.info (Ivan Pepelnjak)
Date: Tue, 14 Jul 2009 21:02:09 +0200
Subject: [c-nsp] CE routes
In-Reply-To: <836bf1f90907140950w4d6e25cfh29fb15816e5bc48d@mail.gmail.com>
References: <836bf1f90907140950w4d6e25cfh29fb15816e5bc48d@mail.gmail.com>
Message-ID: <00fa01ca04b5$979a1650$0a00000a@nil.si>

CE-PE subnets are part of VRF and thus cannot be inserted into the core IGP,
only in MP-BGP. It's way easier (and more scalable) to redistribute them
than to list them in the per-VRF BGP configuration.

Ivan
 
http://www.ioshints.info/about
http://blog.ioshints.info/ 

> -----Original Message-----
> From: harbor235 [mailto:harbor235 at gmail.com] 
> Sent: Tuesday, July 14, 2009 6:51 PM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] CE routes
> 
> I was just reading best practices for MPLS implementations 
> regarding CE to CE connectivity issues, specifically, CE to 
> CE pings. The document stated that redistributing connected 
> PE routes into BGP was the preferred method to ensure CE to 
> CE ping success as well as other connectivity issues. This 
> will inject the route for the PE to CE interface into BGP.I 
> am not sure I agree,  why not explicitly define which 
> networks to advertise in the IGP, an IGP in MPLS networks is 
> supposed to hold all infrastructure routes anyway. Are these 
> interfaces considered infrstructure or customer interfaces? 
> One reason may be to reduce the number of infrastructure 
> routes in the IGP because of the potential for many CE to PE 
> interfaces, let BGP handle the large number of routes?
> 
> I am curious which method is employed in the wild, also I am 
> not sure all connected routes should be advertised from the 
> PE, e.g. management/infrastructure interfaces etc ...
> 
> What are your thoughts and how is it being done?
> 
> mike
> 
> 


From justin at justinshore.com  Tue Jul 14 15:09:42 2009
From: justin at justinshore.com (Justin Shore)
Date: Tue, 14 Jul 2009 14:09:42 -0500
Subject: [c-nsp] Give Cisco your feedback on the new download experience
	at tacwebsurvey@cisco.com
In-Reply-To: <2454679F-A68A-483D-B116-1BAC7A0D3F1B@puck.nether.net>
References: <9DE84313-097E-4D4C-A118-084AC527217D@puck.nether.net>	<20090713222139.GA78946@puck.nether.net>	<20090714063307.GB290@greenie.muc.de>
	<A3A093A3-9EA7-4498-9205-CB272AF6A45B@puck.nether.net>
	<4A5CD493.70202@justinshore.com>
	<2454679F-A68A-483D-B116-1BAC7A0D3F1B@puck.nether.net>
Message-ID: <4A5CD7F6.8080902@justinshore.com>

You might Google for a list of negative adjectives to keep on hand for 
the call.  If you can't find a list online I'm sure you know some people 
who can help contribute to one just for this occasion.

Justin


Jared Mauch wrote:
> I'm having a call with some people in a few minutes, I will share what 
> is feasible to share once it's completed.
> 
>     - Jared


From dcp at dcptech.com  Tue Jul 14 16:17:36 2009
From: dcp at dcptech.com (David Prall)
Date: Tue, 14 Jul 2009 16:17:36 -0400
Subject: [c-nsp] ASA IPsec Tunnel Failover
In-Reply-To: <a2b352c40907141121hc722ad1vca7cf0ccb99ead46@mail.gmail.com>
References: <D6147B25080EEE458FE5BEEE7B280F5D3C5D5B6720@exch01.austin.swinc.com>
	<a2b352c40907141121hc722ad1vca7cf0ccb99ead46@mail.gmail.com>
Message-ID: <011301ca04c0$32eceba0$98c6c2e0$@com>

IKE Keepalives and Reverse Route Injection are typical solutions for routers
with IPSec tunnels. I see that both are supported on the ASA. With RRI, the
route is installed only when the IPSec tunnel is up. I think IKE Keepalives
and using two peer's within a single crypto-map will handle this correctly.
When the first peer fails, the second peer will be established and the route
will be installed to use the second peer address via RRI.

David

--
http://dcp.dcptech.com
 

> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> bounces at puck.nether.net] On Behalf Of Nick Griffin
> Sent: Tuesday, July 14, 2009 2:21 PM
> To: Munoz, Jeff
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] ASA IPsec Tunnel Failover
> 
> Do you have any routers/layer 3 devices on the inside of the firewalls,
> the
> weighted GRE tunnels always work well for this.
> 
> On Mon, Jul 13, 2009 at 3:14 PM, Munoz, Jeff <Jeff.Munoz at swinc.com>
> wrote:
> 
> > Hey guys, I have two main sites (site A and site B) and one remote
> site
> > (site C).  Sites A and B have a metroethernet connection between
> them.
> >  Remote site C has an IPsec tunnel back to site A.  I'd like to setup
> > failover so in case site A's ASA is down the remote site C ASA sends
> the
> > interesting traffic down the site B IPsec tunnel.  Unfortunately, it
> will
> > always match the tunnel to site A since the phase 2 access lists have
> the
> > same source/destinations.  Any ideas on how I can do this?
> >
> > Thanks!
> >
> > 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/
> >
> _______________________________________________
> cisco-nsp mailing list  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 Jul 14 16:33:26 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Tue, 14 Jul 2009 22:33:26 +0200
Subject: [c-nsp] Disallowing "sw tru all vlan X" w/o "add" or "remove"
	(was: Maximum spannig tree instances)
In-Reply-To: <1247596817.2812.13.camel@abehat.net.rm.dk>
References: <1247596817.2812.13.camel@abehat.net.rm.dk>
Message-ID: <20090714203326.GX290@greenie.muc.de>

Hi,

On Tue, Jul 14, 2009 at 08:40:17PM +0200, Peter Rathlev wrote:
> On Tue, 2009-07-14 at 18:05 +0200, Gert Doering wrote:
> > Mmmmh.  If one does TACACS command authentication, one could
> > investigate whether disallowing the "without-add/-delete" form of the
> > command via TACACS works...
> 
> It does indeed. We use something similar to the configuration below for
> "operators" who can do simple maintenance chores.

Cool.

We're currently not doing TACACS command authorization, but I might
be tempted to introduce that :-)

Now: what happens if the TACACS server is unavailable?  The way we 
currently run the shop is "there is a local username configured as 
fallback if TACACS doesn't respond" - and people know that they get 
slapped if they use this user without good reason.

How would command authorization work in that case?

... it's not unheard-of that router configuration is direly needed to
repair a broken network connection *to* the TACACS Server, so this
problem must be known to other folks as well :-)

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/20090714/09909885/attachment.bin>

From drais at icantclick.org  Tue Jul 14 16:53:51 2009
From: drais at icantclick.org (david raistrick)
Date: Tue, 14 Jul 2009 16:53:51 -0400 (EDT)
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <Pine.LNX.4.61.0907141457570.6312@soloth.lewis.org>
References: <a1873f1f0907131438m3f0b4c70r82a953a29042b6d7@mail.gmail.com>
	<1247524340.4661.65.camel@abehat.net.rm.dk>
	<20090714084503.GA15753@lboro.ac.uk>
	<d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>
	<Pine.LNX.4.61.0907140924470.6312@soloth.lewis.org>
	<20090714141529.GN290@greenie.muc.de>
	<Pine.LNX.4.61.0907141101240.6312@soloth.lewis.org>
	<d6966e4b0907140835u597c7ae3l3991ba636ae93bcf@mail.gmail.com>
	<Pine.LNX.4.61.0907141139180.6312@soloth.lewis.org>
	<9e246b4d0907141020v4189c867mcb5e8208454fbc4d@mail.gmail.com>
	<20090714185004.GT290@greenie.muc.de>
	<Pine.LNX.4.61.0907141457570.6312@soloth.lewis.org>
Message-ID: <alpine.BSF.2.00.0907141651390.40527@murf.icantclick.org>

On Tue, 14 Jul 2009, Jon Lewis wrote:

>> Real Networks[tm] have Maintenance Windows[tm].
>
> new customer.  "Sorry, we can't provision your connection until next 
> Tuesday's scheduled maintenance window."


Not to mention that customers even of Real Networks don't like facility 
wide traffic blips every single week.   What would happen is that my 
(former) bosses would put the contract on the table and say "you WILL 
postpone your maintenance until it fits into our schedule 6 weeks from 
now."



--
david raistrick        http://www.netmeister.org/news/learn2quote.html
drais at icantclick.org             http://www.expita.com/nomime.html


From gsgranados at comcast.net  Tue Jul 14 17:13:08 2009
From: gsgranados at comcast.net (Scott Granados)
Date: Tue, 14 Jul 2009 14:13:08 -0700
Subject: [c-nsp] Give Cisco your feedback on the new download
	experienceat tacwebsurvey@cisco.com
References: <9DE84313-097E-4D4C-A118-084AC527217D@puck.nether.net>	<20090713222139.GA78946@puck.nether.net>	<20090714063307.GB290@greenie.muc.de><A3A093A3-9EA7-4498-9205-CB272AF6A45B@puck.nether.net><4A5CD493.70202@justinshore.com><2454679F-A68A-483D-B116-1BAC7A0D3F1B@puck.nether.net>
	<4A5CD7F6.8080902@justinshore.com>
Message-ID: <012101ca04c7$ebeb7480$0202fea9@am.thmulti.com>

Right now we need a special character that shows someone flipping the bird!


:)

----- Original Message ----- 
From: "Justin Shore" <justin at justinshore.com>
To: "Jared Mauch" <jared at puck.nether.net>
Cc: "Gert Doering" <gert at greenie.muc.de>; <christian at automatick.net>; 
<cisco-nsp at puck.nether.net>
Sent: Tuesday, July 14, 2009 12:09 PM
Subject: Re: [c-nsp] Give Cisco your feedback on the new download 
experienceat tacwebsurvey at cisco.com


> You might Google for a list of negative adjectives to keep on hand for the 
> call.  If you can't find a list online I'm sure you know some people who 
> can help contribute to one just for this occasion.
>
> Justin
>
>
> Jared Mauch wrote:
>> I'm having a call with some people in a few minutes, I will share what is 
>> feasible to share once it's completed.
>>
>>     - Jared
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/ 


From andrew at routeip.net  Tue Jul 14 17:31:07 2009
From: andrew at routeip.net (Andrew Yerofyeyev)
Date: Tue, 14 Jul 2009 17:31:07 -0400
Subject: [c-nsp] AIR-LAP1131AG-E-K9 and AIR-WLC2106-K9
Message-ID: <d407c38c0907141431j651bb01cj97ecdd21567c09f4@mail.gmail.com>

Hello,

We have a difficulties connecting AIR-LAP1131AG-E-K9 to AIR-WLC2106-K9 ,
probably becouse of " ETSI CNFG" of AP. What do you think , is it possible
to configure AP in the way to behave as "FCC CNFG" ?

Some "debug capwap error" from controller and AP

controller:
*Jul 14 21:28:15.497: 00:1d:71:e1:76:90 Received an unsupported channel 36
for slot 1 from AP 00:1D:71:E1:76:90
*Jul 14 21:28:15.497: 00:1d:71:e1:76:90 Received an unsupported channel 40
for slot 1 from AP 00:1D:71:E1:76:90
*Jul 14 21:28:15.497: 00:1d:71:e1:76:90 Received an unsupported channel 44
for slot 1 from AP 00:1D:71:E1:76:90
*Jul 14 21:28:15.497: 00:1d:71:e1:76:90 Received an unsupported channel 48
for slot 1 from AP 00:1D:71:E1:76:90
*Jul 14 21:28:15.497: 00:1d:71:e1:76:90 Received an unsupported channel 52
for slot 1 from AP 00:1D:71:E1:76:90
*Jul 14 21:28:15.497: 00:1d:71:e1:76:90 Received an unsupported channel 56
for slot 1 from AP 00:1D:71:E1:76:90
*Jul 14 21:28:15.497: 00:1d:71:e1:76:90 Received an unsupported channel 60
for slot 1 from AP 00:1D:71:E1:76:90
*Jul 14 21:28:15.497: 00:1d:71:e1:76:90 Received an unsupported channel 64
for slot 1 from AP 00:1D:71:E1:76:90
*Jul 14 21:28:15.497: 00:1d:71:e1:76:90 Received an unsupported channel 100
for slot 1 from AP 00:1D:71:E1:76:90
*Jul 14 21:28:15.497: 00:1d:71:e1:76:90 Received an unsupported channel 104
for slot 1 from AP 00:1D:71:E1:76:90
*Jul 14 21:28:15.497: 00:1d:71:e1:76:90 Received an unsupported channel 108
for slot 1 from AP 00:1D:71:E1:76:90
*Jul 14 21:28:15.497: 00:1d:71:e1:76:90 Received an unsupported channel 112
for slot 1 from AP 00:1D:71:E1:76:90
*Jul 14 21:28:15.497: 00:1d:71:e1:76:90 Received an unsupported channel 116
for slot 1 from AP 00:1D:71:E1:76:90
*Jul 14 21:28:15.500: 00:1d:71:e1:76:90 Received an unsupported channel 132
for slot 1 from AP 00:1D:71:E1:76:90
*Jul 14 21:28:15.500: 00:1d:71:e1:76:90 Received an unsupported channel 136
for slot 1 from AP 00:1D:71:E1:76:90
*Jul 14 21:28:15.500: 00:1d:71:e1:76:90 Received an unsupported channel 140
for slot 1 from AP 00:1D:71:E1:76:90


ap:
*Jul 14 21:28:28.789: %CAPWAP-5-CHANGED: CAPWAP changed state to DISCOVERY
*Jul 14 21:28:28.790: %CAPWAP-5-CHANGED: CAPWAP changed state to DISCOVERY
*Jul 14 21:28:28.802: %LINK-5-CHANGED: Interface Dot11Radio0, changed state
to administratively down
*Jul 14 21:28:28.814: %LINK-3-UPDOWN: Interface Dot11Radio0, changed state
to up
*Jul 14 21:28:28.814: %LINK-3-UPDOWN: Interface Dot11Radio1, changed state
to up
*Jul 14 21:28:28.815: %LINK-3-UPDOWN: Interface Dot11Radio0, changed state
to down
*Jul 14 21:28:28.816: CAPWAP_DETAIL: Vendor specific payload validated.
*Jul 14 21:28:28.816: CAPWAP_DETAIL: Vendor specific payload validated.
*Jul 14 21:28:28.848: %LINK-3-UPDOWN: Interface Dot11Radio0, changed state
to up
*Jul 14 21:28:28.876: %LINK-3-UPDOWN: Interface Dot11Radio1, changed state
to up
*Jul 14 21:28:28.907: %LINK-3-UPDOWN: Interface Dot11Radio0, changed state
to up
*Jul 14 21:28:38.830: %CAPWAP-3-ERRORLOG: Go join a capwap controller
*Jul 14 21:28:39.000: %CAPWAP-5-DTLSREQSEND: DTLS connection request sent
peer_ip: 172.16.3.2 peer_port: 5246
*Jul 14 21:28:39.001: %CAPWAP-5-CHANGED: CAPWAP changed state to
*Jul 14 21:28:40.650: CAPWAP_DETAIL: Dtls Event = 39 Capwap State = 3.
*Jul 14 21:28:40.650: %CAPWAP-5-DTLSREQSUCC: DTLS connection created
sucessfully peer_ip: 172.16.3.2 peer_port: 5246
*Jul 14 21:28:40.652: %CAPWAP-5-SENDJOIN: sending Join Request to 172.16.3.2
*Jul 14 21:28:40.652: %CAPWAP-5-CHANGED: CAPWAP changed state to JOIN
*Jul 14 21:28:40.658: CAPWAP_DETAIL: Vendor specific payload validated.
*Jul 14 21:28:40.734: %CAPWAP-5-CHANGED: CAPWAP changed state to CFG
*Jul 14 21:28:40.734: %CAPWAP-3-ERRORLOG: Starting config timer
*Jul 14 21:28:40.741: %DTLS-5-ALERT: Received WARNING : Close notify alert
from 172.16.3.2
*Jul 14 21:28:40.741: %DTLS-5-PEER_DISCONNECT: Peer 172.16.3.2 has closed
connection.
*Jul 14 21:28:40.742: %DTLS-5-SEND_ALERT: Send WARNING : Close notify Alert
to 172.16.3.2:5246
*Jul 14 21:28:40.742: CAPWAP_DETAIL: Dtls Event = 38 Capwap State = 8.



-- 
Best Regards,

From jwininger at indianafiber.net  Tue Jul 14 16:58:39 2009
From: jwininger at indianafiber.net (James M. Wininger)
Date: Tue, 14 Jul 2009 16:58:39 -0400
Subject: [c-nsp] Cisco 12000 series routers and IOS XR.
In-Reply-To: <4A5B766A.3040104@gmail.com>
Message-ID: <C68269BF.11D40%jwininger@indianafiber.net>

Is anyone on the list running the Cisco 12000 Series routers with XR? We
have a couple of these in our network and are having a few issues with them.

Specifically the line cards will reboot for some unknown reason
(12000-SIP-501). We recently replaced one of the cards and the new hardware
(<6mo old) is doing the same thing.

Anyone have issues with these routers?
-- 
Jim Wininger


From david.freedman at uk.clara.net  Tue Jul 14 17:42:32 2009
From: david.freedman at uk.clara.net (David Freedman)
Date: Tue, 14 Jul 2009 22:42:32 +0100
Subject: [c-nsp] CE routes
Message-ID: <7B8B0D6F623C3A40A0D0A80A66756E2B0D7DBE@EXVS01.claranet.local>

>CE-PE subnets are part of VRF and thus cannot be inserted into the core IGP,
>only in MP-BGP. It's way easier (and more scalable) to redistribute them
>than to list them in the per-VRF BGP configuration.

On this note, does a MP-BGP redist [static|connected] instruction incur an extra RIB walk 
as you scale in terms of VRFs on a PE? or is there a single walk and RDs are included/excluded
based on the redist commands?

Dave.

------------------------------------------------
David Freedman
Group Network Engineering 
Claranet Limited
http://www.clara.net


From p.mayers at imperial.ac.uk  Tue Jul 14 18:02:02 2009
From: p.mayers at imperial.ac.uk (Phil Mayers)
Date: Tue, 14 Jul 2009 23:02:02 +0100
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <Pine.LNX.4.61.0907141451100.6312@soloth.lewis.org>
References: <9DE4AA6876D44B62B87C475B2AFE5514@au.didata.local>
	<20090714084503.GA15753@lboro.ac.uk>	<d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>	<Pine.LNX.4.61.0907140924470.6312@soloth.lewis.org>	<20090714141529.GN290@greenie.muc.de>	<Pine.LNX.4.61.0907141101240.6312@soloth.lewis.org>
	<d6966e4b0907140835u597c7ae3l3991ba636ae93bcf@mail.gmail.com>
	<Pine.LNX.4.61.0907141139180.6312@soloth.lewis.org>
	<9e246b4d0907141020v4189c867mcb5e8208454fbc4d@mail.gmail.com>
	<Pine.LNX.4.61.0907141355280.6312@soloth.lewis.org>	<d6966e4b0907141122g714a3e8bwfbee02edca4a80a8@mail.gmail.com>
	<Pine.LNX.4.61.0907141451100.6312@soloth.lewis.org>
Message-ID: <4A5D005A.5030303@imperial.ac.uk>

Jon Lewis wrote:
> On Tue, 14 Jul 2009, Geoffrey Pendery wrote:
> 
>> Yes.  We've verified this.
>> A trunk port carrying only VLAN 30, or even an access port carrying
>> only VLAN 30.
>> VLAN 30 is in instance 2.  You go into config mode and add VLAN 50 to
>> instance 2 (or remove it from instance 2)
>> The port, be it access or trunk, goes to blocking, learning, forwarding.
> 
> Well...screw that.  That would mean only making MST changes during 
> maintenance windows.  I guess it's time to turn off VTP and stick with 
> pvst.

Good choice.

MST is a junk standard. They missed a serious opportunity with it. But 
then it's the IEEE - frankly I'm amazed it didn't have a whacking great 
security hole in it.

R-PVST + manual VLAN management works like a charm here.

From justin at justinshore.com  Tue Jul 14 18:06:13 2009
From: justin at justinshore.com (Justin Shore)
Date: Tue, 14 Jul 2009 17:06:13 -0500
Subject: [c-nsp] Disallowing "sw tru all vlan X" w/o "add" or "remove"
 (was: Maximum spannig tree instances)
In-Reply-To: <20090714203326.GX290@greenie.muc.de>
References: <1247596817.2812.13.camel@abehat.net.rm.dk>
	<20090714203326.GX290@greenie.muc.de>
Message-ID: <4A5D0155.9060900@justinshore.com>

Gert Doering wrote:
> Now: what happens if the TACACS server is unavailable?  The way we 
> currently run the shop is "there is a local username configured as 
> fallback if TACACS doesn't respond" - and people know that they get 
> slapped if they use this user without good reason.
> 
> How would command authorization work in that case?

I think it would once again require the mighty hand of the Gert to slap 
his underling back into line.

I believe you can create an authorization list locally that simply 
permits all commands.  Then set that list as the backup to tacacs in the 
AAA config.  Like you said before, this is the backup plan in case the 
world is coming to an end.

I don't do AAA authorization yet but I do use TACACS and I fall back to 
a local user for authentication.  It's very handy.  That userid & passwd 
don't stray far from my hands.  I wouldn't make it something that's 
known to everyone though.  It would be a very select list.

Justin


From paul at paulstewart.org  Tue Jul 14 18:54:47 2009
From: paul at paulstewart.org (Paul Stewart)
Date: Tue, 14 Jul 2009 18:54:47 -0400
Subject: [c-nsp] 7206VXR BGP Sessions
Message-ID: <001901ca04d6$16d23db0$4476b910$@org>

Hi there.

 

I need to move several hundred BGP sessions (low traffic peers, about 500
Mb/s combined) over to another box - have a 7206VXR with NPE1G and a 7206VXR
with NPE2G sitting spare at moment.  

 

How many sessions/traffic should the 1G and the 2G be able to handle
approximately?

 

Thanks,

 

Paul

 

 

 


From p.mayers at imperial.ac.uk  Tue Jul 14 19:22:14 2009
From: p.mayers at imperial.ac.uk (Phil Mayers)
Date: Wed, 15 Jul 2009 00:22:14 +0100
Subject: [c-nsp] Disallowing "sw tru all vlan X" w/o "add" or "remove"
 (was: Maximum spannig tree instances)
In-Reply-To: <4A5D0155.9060900@justinshore.com>
References: <1247596817.2812.13.camel@abehat.net.rm.dk>	<20090714203326.GX290@greenie.muc.de>
	<4A5D0155.9060900@justinshore.com>
Message-ID: <4A5D1326.9040500@imperial.ac.uk>

Justin Shore wrote:
> Gert Doering wrote:
>> Now: what happens if the TACACS server is unavailable?  The way we 
>> currently run the shop is "there is a local username configured as 
>> fallback if TACACS doesn't respond" - and people know that they get 
>> slapped if they use this user without good reason.
>>
>> How would command authorization work in that case?
> 
> I think it would once again require the mighty hand of the Gert to slap 
> his underling back into line.
> 
> I believe you can create an authorization list locally that simply 
> permits all commands.  Then set that list as the backup to tacacs in the 
> AAA config.  Like you said before, this is the backup plan in case the 
> world is coming to an end.
> 
> I don't do AAA authorization yet but I do use TACACS and I fall back to 
> a local user for authentication.  It's very handy.  That userid & passwd 
> don't stray far from my hands.  I wouldn't make it something that's 
> known to everyone though.  It would be a very select list.

That might work in some places, and our auditors certainly seem to think 
there should only be 1 person with the router enable password (wtf?!) 
but we adopted a slightly more low-tech solution. It's not as sexy as 
running a TACACS server:

alias interface tagvlan switchport trunk allowed vlan add
alias interface detagvlan switchport trunk allowed vlan remove

...then:

conf t
int g1/1
   tagvlan 100,101
   detagvlan 200

...and just don't use the more dangerous commands.

I imagine something even more sophisticated could be done with the new 
EEM cli commands interface.

Does anyone know if this can be done without TACACS? Using CLI views or 
similar?

From jason at lixfeld.ca  Tue Jul 14 20:04:51 2009
From: jason at lixfeld.ca (Jason Lixfeld)
Date: Tue, 14 Jul 2009 20:04:51 -0400
Subject: [c-nsp] Ethernet Loopback plug on an ME3400
Message-ID: <448EC3F5-E64D-4361-A9D1-0F58BD6E7DDC@lixfeld.ca>

Is there anything special one needs to do in order to get an ethernet  
loopback plug to bring a port on an ME3400 up/up?  In a 3550 it works  
fine, but on an ME, no joy.  Does the port need to be in any specific  
mode (UNI/NNI) or some other voodoo?  I can't imagine that the MEs  
would just detect it and kill it.

From peter at rathlev.dk  Tue Jul 14 20:09:17 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Wed, 15 Jul 2009 02:09:17 +0200
Subject: [c-nsp] Disallowing "sw tru all vlan X" w/o "add" or "remove"
In-Reply-To: <20090714203326.GX290@greenie.muc.de>
References: <1247596817.2812.13.camel@abehat.net.rm.dk>
	<20090714203326.GX290@greenie.muc.de>
Message-ID: <1247616558.7264.7.camel@abehat.net.rm.dk>

On Tue, 2009-07-14 at 22:33 +0200, Gert Doering wrote:
> Now: what happens if the TACACS server is unavailable?  The way we 
> currently run the shop is "there is a local username configured as 
> fallback if TACACS doesn't respond" - and people know that they get 
> slapped if they use this user without good reason.
> 
> How would command authorization work in that case?

You can have "if-authenticated" as fall back mechanism. Kind of like a
local "permit any" authorization list.

aaa authorization exec METHOD group tacacs+ if-authenticated 
aaa authorization commands 0 METHOD group tacacs+ if-authenticated 
aaa authorization commands 15 METHOD group tacacs+ if-authenticated 

Currently we only allow "if-authenticated" on the console port. After a
few funny situations the past year I'm seriously considering just
enabling it for VTYs also. I'm not exactly sure why I haven't done this
yet, but there's something inside my head telling me that there's some
security aspect here. I just can think of it. :-)

Regards,
Peter



From ibrahim.abozaid at gmail.com  Tue Jul 14 20:47:13 2009
From: ibrahim.abozaid at gmail.com (Ibrahim Abo Zaid)
Date: Wed, 15 Jul 2009 03:47:13 +0300
Subject: [c-nsp] ISIS Mesh group question
Message-ID: <a48927f70907141747y4300a4a6sa149172911d2b0c5@mail.gmail.com>

Hi All

I have a question about ISIS mesh groups which is used to reduce LSP
flooding in full-mesh p2p enviroments , that means we lose redudacny for
sake of LSP flooding reducation hence it affects forwarding and traffic is
forced to inactive or interfaces in different groups only .

is that right ?

best regards
--Ibrahim

From Kris.Amy at EIP.net.au  Tue Jul 14 22:32:58 2009
From: Kris.Amy at EIP.net.au (Kris Amy)
Date: Wed, 15 Jul 2009 12:32:58 +1000
Subject: [c-nsp] SA-VAM & NPE-200
Message-ID: <BF3145D4759F9846A1214E628425C3C201622F62B5@ZEUS.RGCOLO.local>

Hi,

Just wondering if this combination works. The documentation says a NPE225 is required however i'm wondering if that is just a warning or an actual requirement...

--
Kind Regards,
Kris Amy
Enterprise IP
Phone:     07 3123 5510
National: 1300 347 287
Fax:         1300 347 329
Direct:     07 3123 5511
Email:      kris.amy at eip.net.au<outbind://2-00000000FC347F44727AD040BF1A93E9A3DC68310700065EB17B7262634485BBBA18AFE92E3E0007A2A2A7EE0000065EB17B7262634485BBBA18AFE92E3E0007D22B10350000/kris.amy at eip.net.au>


From clinton at scripty.com  Tue Jul 14 23:36:42 2009
From: clinton at scripty.com (Clinton Work)
Date: Tue, 14 Jul 2009 21:36:42 -0600
Subject: [c-nsp] Ethernet Loopback plug on an ME3400
In-Reply-To: <448EC3F5-E64D-4361-A9D1-0F58BD6E7DDC@lixfeld.ca>
References: <448EC3F5-E64D-4361-A9D1-0F58BD6E7DDC@lixfeld.ca>
Message-ID: <4A5D4ECA.5000402@scripty.com>


Maybe you need to disable MDX on the FastE port which is preventing the 
port from coming up.  
*http://tinyurl.com/npuuwt

*
Jason Lixfeld wrote:
> Is there anything special one needs to do in order to get an ethernet 
> loopback plug to bring a port on an ME3400 up/up?  In a 3550 it works 
> fine, but on an ME, no joy.  Does the port need to be in any specific 
> mode (UNI/NNI) or some other voodoo?  I can't imagine that the MEs 
> would just detect it and kill it.
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


-- 
==================================================================
Clinton Work
Airdrie, AB



From pgurumu at gmail.com  Wed Jul 15 00:45:03 2009
From: pgurumu at gmail.com (Prabhu Gurumurthy)
Date: Tue, 14 Jul 2009 21:45:03 -0700
Subject: [c-nsp] ASA IPsec Tunnel Failover
In-Reply-To: <D6147B25080EEE458FE5BEEE7B280F5D3C5D5B6720@exch01.austin.swinc.com>
References: <D6147B25080EEE458FE5BEEE7B280F5D3C5D5B6720@exch01.austin.swinc.com>
Message-ID: <EBB73BA5-06D8-4C45-8FD6-E1AD38CF3978@gmail.com>

Oh I mean use BGP over IPsec, with BGP behind the ASA firewalls and  
yes, ASA supports OSPF and RIP only AFAIK.


On Jul 13, 2009, at 1:14 PM, Munoz, Jeff wrote:

> Hey guys, I have two main sites (site A and site B) and one remote  
> site (site C).  Sites A and B have a metroethernet connection  
> between them.  Remote site C has an IPsec tunnel back to site A.   
> I'd like to setup failover so in case site A's ASA is down the  
> remote site C ASA sends the interesting traffic down the site B  
> IPsec tunnel.  Unfortunately, it will always match the tunnel to  
> site A since the phase 2 access lists have the same source/ 
> destinations.  Any ideas on how I can do this?
>
> Thanks!
>
> 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 chris.brown at acsalaska.net  Wed Jul 15 00:58:53 2009
From: chris.brown at acsalaska.net (Christopher E. Brown)
Date: Tue, 14 Jul 2009 20:58:53 -0800
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <9e246b4d0907141137v3653261n53b452b98236971d@mail.gmail.com>
References: <9DE4AA6876D44B62B87C475B2AFE5514@au.didata.local>	<d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>	<Pine.LNX.4.61.0907140924470.6312@soloth.lewis.org>	<20090714141529.GN290@greenie.muc.de>	<Pine.LNX.4.61.0907141101240.6312@soloth.lewis.org>	<d6966e4b0907140835u597c7ae3l3991ba636ae93bcf@mail.gmail.com>	<Pine.LNX.4.61.0907141139180.6312@soloth.lewis.org>	<9e246b4d0907141020v4189c867mcb5e8208454fbc4d@mail.gmail.com>	<Pine.LNX.4.61.0907141355280.6312@soloth.lewis.org>	<d6966e4b0907141122g714a3e8bwfbee02edca4a80a8@mail.gmail.com>
	<9e246b4d0907141137v3653261n53b452b98236971d@mail.gmail.com>
Message-ID: <4A5D620D.6090606@acsalaska.net>

Tim Durack wrote:
> On Tue, Jul 14, 2009 at 2:22 PM, Geoffrey Pendery <geoff at pendery.net> wrote:
> 
>>> Will adding new VLANs to an MST instance disrupt traffic flow for other
>>> VLANs in that MST instance?
>> Yes.  We've verified this.
>> A trunk port carrying only VLAN 30, or even an access port carrying
>> only VLAN 30.
>> VLAN 30 is in instance 2.  You go into config mode and add VLAN 50 to
>> instance 2 (or remove it from instance 2)
>> The port, be it access or trunk, goes to blocking, learning, forwarding.
>>
> 
> ...and if that doesn't make you nervous, you probably shouldn't be running
> spanning-tree...
> 
> 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/


Come on guys, study the proto a little before going off.



In order for MST to work all members of an MST domain *MUST* agree on
the VLAN -> MST group mapping.


If you change the mapping it must update across all members of the domain.

YOU ARE REDEFINING THE STP TOPOLOGY


_Pick a topology_


MST group pre-assign...


0	VLAN 1
1	VLAN 2-999
2	VLAN 1000-1999
3	VLAN 2000-2999
4	VLAN 3000-3999
5	VLAN 4000-4094


Or whatever grouping youl want, even/odd, by hundreds, whatever.



You are now free to pick a different root and set link costs for each of
the groups independent of the others, just like pvst but by group.


If you *cannot* manage vlans by group, then stick with a rapid per vlan
variant.


If you need to move vlans in bulk across the core, and can afford to
pre-assign membership in the group then MST can be lower overhead.


The only real rules here

Leave group zero for vlan one *only*

If you have to change the base MST config more than once a year you are
not planning correctly, or you should not be using MST.




From gert at greenie.muc.de  Wed Jul 15 02:18:23 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Wed, 15 Jul 2009 08:18:23 +0200
Subject: [c-nsp] Disallowing "sw tru all vlan X" w/o "add" or "remove"
In-Reply-To: <1247616558.7264.7.camel@abehat.net.rm.dk>
References: <1247596817.2812.13.camel@abehat.net.rm.dk>
	<20090714203326.GX290@greenie.muc.de>
	<1247616558.7264.7.camel@abehat.net.rm.dk>
Message-ID: <20090715061823.GZ290@greenie.muc.de>

Hi,

On Wed, Jul 15, 2009 at 02:09:17AM +0200, Peter Rathlev wrote:
> Currently we only allow "if-authenticated" on the console port. After a
> few funny situations the past year I'm seriously considering just
> enabling it for VTYs also. I'm not exactly sure why I haven't done this
> yet, but there's something inside my head telling me that there's some
> security aspect here. I just can think of it. :-)

Well, one angle of attack could be...

 - null-route the TACACS server IP
 - instant "full" access

Of course the "null-route" command would be visible in TACACS command
accounting, so you know whom to slap :-)

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/20090715/3969c258/attachment.bin>

From gert at greenie.muc.de  Wed Jul 15 02:22:33 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Wed, 15 Jul 2009 08:22:33 +0200
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <4A5D620D.6090606@acsalaska.net>
References: <Pine.LNX.4.61.0907140924470.6312@soloth.lewis.org>
	<20090714141529.GN290@greenie.muc.de>
	<Pine.LNX.4.61.0907141101240.6312@soloth.lewis.org>
	<d6966e4b0907140835u597c7ae3l3991ba636ae93bcf@mail.gmail.com>
	<Pine.LNX.4.61.0907141139180.6312@soloth.lewis.org>
	<9e246b4d0907141020v4189c867mcb5e8208454fbc4d@mail.gmail.com>
	<Pine.LNX.4.61.0907141355280.6312@soloth.lewis.org>
	<d6966e4b0907141122g714a3e8bwfbee02edca4a80a8@mail.gmail.com>
	<9e246b4d0907141137v3653261n53b452b98236971d@mail.gmail.com>
	<4A5D620D.6090606@acsalaska.net>
Message-ID: <20090715062233.GA290@greenie.muc.de>

Hi,

On Tue, Jul 14, 2009 at 08:58:53PM -0800, Christopher E. Brown wrote:
> Come on guys, study the proto a little before going off.

We did...

> In order for MST to work all members of an MST domain *MUST* agree on
> the VLAN -> MST group mapping.
> 
> If you change the mapping it must update across all members of the domain.
> 
> YOU ARE REDEFINING THE STP TOPOLOGY

... and that's just not workable for Real Networks that undergo daily 
changes, and have wildly differing VLAN topologies.  Especially the latter
one ("due to traffic reasons, we have to move the STP active link for
VLAN 714 to *this* trunk").

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/20090715/bb7d7e51/attachment.bin>

From saku at ytti.fi  Wed Jul 15 02:31:15 2009
From: saku at ytti.fi (Saku Ytti)
Date: Wed, 15 Jul 2009 09:31:15 +0300
Subject: [c-nsp] Give Cisco your feedback on the new download experience
 at tacwebsurvey@cisco.com (was: several heart-felt flames regarding the
 mess that is the Cisco.com download experience)
In-Reply-To: <2454679F-A68A-483D-B116-1BAC7A0D3F1B@puck.nether.net>
References: <9DE84313-097E-4D4C-A118-084AC527217D@puck.nether.net>
	<20090713222139.GA78946@puck.nether.net>
	<20090714063307.GB290@greenie.muc.de>
	<A3A093A3-9EA7-4498-9205-CB272AF6A45B@puck.nether.net>
	<4A5CD493.70202@justinshore.com>
	<2454679F-A68A-483D-B116-1BAC7A0D3F1B@puck.nether.net>
Message-ID: <20090715063115.GA6483@mx.ytti.net>

On (2009-07-14 14:57 -0400), Jared Mauch wrote:

> I'm having a call with some people in a few minutes, I will share
> what is feasible to share once it's completed.

While I subscribe to the download manager hate, it doesn't bother me
nearly as much as unusable bugtool since the last upgrade two years
ago. Prior to the upgrade, I could solve maybe 1/3 of my cases, without
involving TAC. At that time, I thought bugtool was incredibly poorly
implemented, little did I know that it could get worse, much worse.
Why bugtool bothers me more is that I have software defects more often
than I need to upgrade boxes (new IOS maybe 3-4 times a year, but defects
several per week, as I open case for everything out of ordinary), and
worse come worse I can always email my SE to fetch me latest IOS,
but sucky bugtool is seriously hurting time it takes for me to solve an
issue.

I don't think the bugtool can carry that large amount of data, that it
can't be indexed with modern machine in acceptable time, delivering
instant searches without any qualifiers. The forced qualifying they now
have is annoying, as the bugs are tagged so poorly it makes you miss
them, even choosing just the main train, can lead you off (after you've
waited 20min to get the results).
Also how on earth can the bugs be tagged so poorly, I don't think it
would be large change process or DE effort when fixing a bug, to
give commitID for fix and commitID for the change which caused the
bug, allowing software to give perfect list of affected, non-affected
and fixed IOS'.

So if people are making some stand to CSCO about download manager,
it would be nice to include bugtool in the cry also.

Thanks,
-- 
  ++ytti

From jr at xor.at  Wed Jul 15 02:39:40 2009
From: jr at xor.at (Johannes Resch)
Date: Wed, 15 Jul 2009 08:39:40 +0200 (CEST)
Subject: [c-nsp] Stability of 12.2(33)SRD?
In-Reply-To: <4A5C1BB3.8030506@lists.esoteric.ca>
References: <4A5C1BB3.8030506@lists.esoteric.ca>
Message-ID: <b30bb12ddbc8fc6c56897cc287ba6f2c.squirrel@and.xor.at>

On Tue, July 14, 2009 07:46, Stephen Fulton wrote:
> I'm looking for thoughts on the stability of 12.2(33)SRD releases (latest
> is
> SRD2) in general, as well as any experiences running it on the 7600/RSP720
> series.  I'm connecting a SIP400/SPA-5x1GEv2 to a CWDM network, and only
> SRD
> supports the CWDM SFP's on the SIP400.  Yay.

For proper CWDM SFP support on that platform, you might want to wait for
SRD2a (due Jul 20th) or SRD3, which include a fix for an annoying issue
where original CWDM SFPs from Cisco (recently produced ones starting from
a particular serial number) are not recognised properly and don't work  -
CSCsv79583.

-jr

From hank at efes.iucc.ac.il  Wed Jul 15 03:13:36 2009
From: hank at efes.iucc.ac.il (Hank Nussbacher)
Date: Wed, 15 Jul 2009 10:13:36 +0300 (IDT)
Subject: [c-nsp] Give Cisco your feedback on the new download experience
 at tacwebsurvey@cisco.com (was: several heart-felt flames regarding the
 mess that is the Cisco.com download experience)
In-Reply-To: <20090715063115.GA6483@mx.ytti.net>
References: <9DE84313-097E-4D4C-A118-084AC527217D@puck.nether.net>
	<20090713222139.GA78946@puck.nether.net>
	<20090714063307.GB290@greenie.muc.de>
	<A3A093A3-9EA7-4498-9205-CB272AF6A45B@puck.nether.net>
	<4A5CD493.70202@justinshore.com>
	<2454679F-A68A-483D-B116-1BAC7A0D3F1B@puck.nether.net>
	<20090715063115.GA6483@mx.ytti.net>
Message-ID: <Pine.LNX.4.64.0907151009290.7796@efes.iucc.ac.il>

On Wed, 15 Jul 2009, Saku Ytti wrote:

> While I subscribe to the download manager hate, it doesn't bother me
> nearly as much as unusable bugtool since the last upgrade two years
> ago. Prior to the upgrade, I could solve maybe 1/3 of my cases, without
> involving TAC. At that time, I thought bugtool was incredibly poorly
> implemented, little did I know that it could get worse, much worse.
> Why bugtool bothers me more is that I have software defects more often
> than I need to upgrade boxes (new IOS maybe 3-4 times a year, but defects
> several per week, as I open case for everything out of ordinary), and
> worse come worse I can always email my SE to fetch me latest IOS,
> but sucky bugtool is seriously hurting time it takes for me to solve an
> issue.
>
> I don't think the bugtool can carry that large amount of data, that it
> can't be indexed with modern machine in acceptable time, delivering
> instant searches without any qualifiers. The forced qualifying they now
> have is annoying, as the bugs are tagged so poorly it makes you miss
> them, even choosing just the main train, can lead you off (after you've
> waited 20min to get the results).
> Also how on earth can the bugs be tagged so poorly, I don't think it
> would be large change process or DE effort when fixing a bug, to
> give commitID for fix and commitID for the change which caused the
> bug, allowing software to give perfect list of affected, non-affected
> and fixed IOS'.
>
> So if people are making some stand to CSCO about download manager,
> it would be nice to include bugtool in the cry also.

I guess cisco-nsp has become a soapbox for catharsis in regards to Cisco - 
but everyone should realize that is about all it is.  Cisco has no 
interest in fixing their download or bugtool problems.  It is a simple 
matter of cost cutting and budgets and taking the cheapest offer or hiring 
the cheapest labor.

So keep filling out those feedback forms and calling your Cisco bigwig 
friends.  If that makes you feel any better, go for it.  Me - I've moved 
on as many others have.

Regards,
Hank

From chris.brown at acsalaska.net  Wed Jul 15 03:17:34 2009
From: chris.brown at acsalaska.net (Christopher E. Brown)
Date: Tue, 14 Jul 2009 23:17:34 -0800
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <20090715062233.GA290@greenie.muc.de>
References: <Pine.LNX.4.61.0907140924470.6312@soloth.lewis.org>
	<20090714141529.GN290@greenie.muc.de>
	<Pine.LNX.4.61.0907141101240.6312@soloth.lewis.org>
	<d6966e4b0907140835u597c7ae3l3991ba636ae93bcf@mail.gmail.com>
	<Pine.LNX.4.61.0907141139180.6312@soloth.lewis.org>
	<9e246b4d0907141020v4189c867mcb5e8208454fbc4d@mail.gmail.com>
	<Pine.LNX.4.61.0907141355280.6312@soloth.lewis.org>
	<d6966e4b0907141122g714a3e8bwfbee02edca4a80a8@mail.gmail.com>
	<9e246b4d0907141137v3653261n53b452b98236971d@mail.gmail.com>
	<4A5D620D.6090606@acsalaska.net>
	<20090715062233.GA290@greenie.muc.de>
Message-ID: <4A5D828E.7030508@acsalaska.net>

Gert Doering wrote:
> Hi,
> 
> On Tue, Jul 14, 2009 at 08:58:53PM -0800, Christopher E. Brown wrote:
>> Come on guys, study the proto a little before going off.
> 
> We did...
> 
>> In order for MST to work all members of an MST domain *MUST* agree on
>> the VLAN -> MST group mapping.
>>
>> If you change the mapping it must update across all members of the domain.
>>
>> YOU ARE REDEFINING THE STP TOPOLOGY
> 
> ... and that's just not workable for Real Networks that undergo daily 
> changes, and have wildly differing VLAN topologies.  Especially the latter
> one ("due to traffic reasons, we have to move the STP active link for
> VLAN 714 to *this* trunk").
> 
> gert

Exactly, MST only applies when you can group the vlans _long term_, and
this only happens when individual VLANs are a small percentage of
traffic.  The traffic routing ability is linited to the _group_.


If this does not apply, the a per vlan variant is needed.


I use both, complex large flow per vlan is rapid per vlan, bulk
distribution domains are MST with pre-assigned use per group.

From digambar.giri at gmail.com  Wed Jul 15 03:24:00 2009
From: digambar.giri at gmail.com (Digambar. Giri)
Date: Wed, 15 Jul 2009 12:54:00 +0530
Subject: [c-nsp] cisco-nsp Digest, Vol 80, Issue 49
In-Reply-To: <4288131ED5E3024C9CD4782CECCAD2C7065D3851@LMC-MAIL2.exempla.org>
References: <mailman.3892.1247577796.2287.cisco-nsp@puck.nether.net>
	<e45309330907140729p240910c9y870a864a934e5c2e@mail.gmail.com>
	<4288131ED5E3024C9CD4782CECCAD2C7065D3851@LMC-MAIL2.exempla.org>
Message-ID: <e45309330907150024l60ce2a0ckf90fe832a2ac2ff0@mail.gmail.com>

DEar frend

i need a crak....... IPswitch Whatsup gold 11

On Tue, Jul 14, 2009 at 8:27 PM, Matlock, Kenneth L <MatlockK at exempla.org>wrote:

> The serial numbers can be found here:
>
> http://www.whatsupgold.com/
>
>
> 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 Digambar. Giri
> Sent: Tuesday, July 14, 2009 8:29 AM
> To: cisco-nsp at puck.nether.net
>  Subject: Re: [c-nsp] cisco-nsp Digest, Vol 80, Issue 49
>
> Dear friends
> please provide IPswitch Whatsup gold 11 serial key NMs...
>
>
> On 7/14/09, cisco-nsp-request at puck.nether.net <
> cisco-nsp-request at puck.nether.net> wrote:
> >
> > Send cisco-nsp mailing list submissions to
> >        cisco-nsp at puck.nether.net
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> >        https://puck.nether.net/mailman/listinfo/cisco-nsp
> > or, via email, send a message with subject or body 'help' to
> >        cisco-nsp-request at puck.nether.net
> >
> > You can rDAr each 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: "Software Download Area is Unavailable at this time"
> >      (Gert Doering)
> >   2. Block URL ACCESS LIST (Mohammad Khalil)
> >   3. Re: multiple vlans on a port (Gert Doering)
> >   4. Re: Block URL ACCESS LIST (masood at nexlinx.net.pk)
> >   5. Re: IPv6 iBGP Route Reflector (Steve Bertrand)
> >   6. Re: ASA IPsec Tunnel Failover (Forrest, Michael E.)
> >   7. Re: ASA IPsec Tunnel Failover (A.L.M.Buxey at lboro.ac.uk)
> >   8. Re: Maximum spannig tree instances (Geoffrey Pendery)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Tue, 14 Jul 2009 10:56:48 +0200
> > From: Gert Doering <gert at greenie.muc.de>
> > To: Phil Mayers <p.mayers at imperial.ac.uk>
> > Cc: Gert Doering <gert at greenie.muc.de>, "cisco-nsp at puck.nether.net"
> >        <cisco-nsp at puck.nether.net>,    Jared Mauch
> <jared at puck.nether.net>
> > Subject: Re: [c-nsp] "Software Download Area is Unavailable at this
> >        time"
> > Message-ID: <20090714085648.GD290 at greenie.muc.de>
> > Content-Type: text/plain; charset="us-ascii"
> >
> > Hi,
> >
> > On Tue, Jul 14, 2009 at 09:16:23AM +0100, Phil Mayers wrote:
> > > But can I just make a recommendation to everyone here: next time you
> go
> > > out to competitive tender, specify the nature of docs & software
> > > availability. List "HTTP downloads without client software or
> plugins"
> > > as a mandatory requirement.
> >
> > While this is a nice idea to cause some pressure, I can't see it as
> > overly realistic - if I have a router A that will fulfill everything
> > that we need, and a router B that will only do 80% and at the same
> > time costs 20% more, but has a better company web interface, I think
> it's
> > very unlikely that their web download thingie will be change our
> > decision.
> >
> > (Besides, most competitors web sites and software download processes
> are
> > even worse)
> >
> > 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/20090714/13933a9
> 4/attachment-0001.bin
> > >
> >
> > ------------------------------
> >
> > Message: 2
> > Date: Tue, 14 Jul 2009 12:48:52 +0300
> > From: Mohammad Khalil <eng_mssk at hotmail.com>
> > To: <cisco-nsp at puck.nether.net>
> > Subject: [c-nsp] Block URL ACCESS LIST
> > Message-ID: <BLU102-W20D319D228A429D7F5B1F9FA230 at phx.gbl>
> > Content-Type: text/plain; charset="windows-1256"
> >
> >
> > how can i block url using access-list ?
> >
> > _________________________________________________________________
> > Drag n? drop?Get easy photo sharing with Windows Live? Photos.
> >
> > http://www.microsoft.com/windows/windowslive/products/photos.aspx
> >
> > ------------------------------
> >
> > Message: 3
> > Date: Tue, 14 Jul 2009 11:49:11 +0200
> > From: Gert Doering <gert at greenie.muc.de>
> > To: Matthew Huff <mhuff at ox.com>
> > Cc: "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>
> > Subject: Re: [c-nsp] multiple vlans on a port
> > Message-ID: <20090714094911.GH290 at greenie.muc.de>
> > Content-Type: text/plain; charset="us-ascii"
> >
> > Hi,
> >
> > On Mon, Jul 13, 2009 at 06:38:23PM -0400, Matthew Huff wrote:
> > > Also, with 802.1q framing, you might run into fragmentation on
> > > the non-native VLANs. You may want to adjust the MTU on the virtual
> > > machines if Linux doesn't do it automatically.
> >
> > There are a few broken NIC cards on the Linux side that have issues
> > with "baby-jumbo" packets (1500 + 4 byte for 802.1q header).  Decent
> > gear - and that's what you want to use on a *server* - doesn't have
> > any issues there.
> >
> > And, just to clarify: *If* you have MTU problems due to 802.1q
> headers,
> > you will not see "fragmentation".  You'll see black-holing, because
> the
> > stack will not know about the MTU issue, and thus won't even think
> > about fragmentation.  (Fragmentation happens if there is a link on
> > the path that has smaller L3 MTU than the packet's sender - but in
> this
> > scenario, the L3 endpoints assume 1500, while the L2 link cannot
> handle
> > this.  Black hole).
> >
> > 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/20090714/6dc4550
> 8/attachment-0001.bin
> > >
> >
> > ------------------------------
> >
> > Message: 4
> > Date: Tue, 14 Jul 2009 16:13:52 +0500 (PKT)
> > From: masood at nexlinx.net.pk
> > To: "Mohammad Khalil" <eng_mssk at hotmail.com>
> > Cc: cisco-nsp at puck.nether.net
> > Subject: Re: [c-nsp] Block URL ACCESS LIST
> > Message-ID:
> >
> <24754.196.46.241.57.1247570032.squirrel at nexmail1.nexlinx.net.pk>
> > Content-Type: text/plain;charset=iso-8859-1
> >
> >
> > Please go to the following URL to begin:
> >
> >
> >
> http://weblogs.com.pk/jahil/archive/2008/11/15/how-nbar-actually-classif
> ies-the-traffic-flows.aspx
> >
> > Regards,
> > Masood
> >
> > >
> > > how can i block url using access-list ?
> > >
> > > _________________________________________________________________
> > > 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/
> >
> >
> >
> >
> > ------------------------------
> >
> > Message: 5
> > Date: Tue, 14 Jul 2009 08:23:09 -0400
> > From: Steve Bertrand <steve at ibctech.ca>
> > To: Aleksandr Gurbo <kron at linkey.ru>
> > Cc: cisco-nsp at puck.nether.net
> > Subject: Re: [c-nsp] IPv6 iBGP Route Reflector
> > Message-ID: <4A5C78AD.5050006 at ibctech.ca>
> > Content-Type: text/plain; charset="iso-8859-1"
> >
> > Aleksandr Gurbo wrote:
> > > On Sat, 11 Jul 2009 19:08:17 -0400
> > > Steve Bertrand <steve at ibctech.ca> wrote:
> > >
> > >> Over the weekend, I'll find out how the OP can fix the routes, and
> > >> moreover, why they are broken in the first place.
> > >>
> > >> Steve
> > >
> > > Have you any ideas how to fix reflected routes?
> >
> > I will be working on this specific issue today, as I need to make some
> > changes in preparation of adding a new router later this week.
> >
> > I'll keep you posted if I find anything specific as I go.
> >
> > Steve
> > -------------- next part --------------
> > A non-text attachment was scrubbed...
> > Name: smime.p7s
> > Type: application/x-pkcs7-signature
> > Size: 3233 bytes
> > Desc: S/MIME Cryptographic Signature
> > URL: <
> >
> https://puck.nether.net/pipermail/cisco-nsp/attachments/20090714/efe1560
> f/attachment-0001.bin
> > >
> >
> > ------------------------------
> >
> > Message: 6
> > Date: Tue, 14 Jul 2009 12:50:35 +0100
> > From: "Forrest, Michael E." <michael.forrest at abdn.ac.uk>
> > To: "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>
> > Subject: Re: [c-nsp] ASA IPsec Tunnel Failover
> > Message-ID:
> >
> <D2BEF91BFE51C743854D7AB86BA35A354984F7EC25 at VMAILA.uoa.abdn.ac.uk>
> > Content-Type: text/plain; charset="us-ascii"
> >
> > I was under the impression that there was no BGP support in the ASA
> > platform, unless someone knows otherwise?
> >
> > Michael.
> >
> > > -----Original Message-----
> > > From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> > > bounces at puck.nether.net] On Behalf Of Prabhu Gurumurthy
> > > Sent: 14 July 2009 00:34
> > > To: Munoz, Jeff
> > > Cc: cisco-nsp at puck.nether.net
> > > Subject: Re: [c-nsp] ASA IPsec Tunnel Failover
> > >
> > > Answer is: BGP
> > >
> > > On Jul 13, 2009, at 1:14 PM, Munoz, Jeff wrote:
> > >
> > > > Hey guys, I have two main sites (site A and site B) and one remote
> > > > site (site C).  Sites A and B have a metroethernet connection
> > > > between them.  Remote site C has an IPsec tunnel back to site A.
> > > > I'd like to setup failover so in case site A's ASA is down the
> > > > remote site C ASA sends the interesting traffic down the site B
> > > > IPsec tunnel.  Unfortunately, it will always match the tunnel to
> > > > site A since the phase 2 access lists have the same source/
> > > > destinations.  Any ideas on how I can do this?
> > > >
> > > > Thanks!
> > > >
> > > > 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/
> > >
> > > _______________________________________________
> > > cisco-nsp mailing 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 University of Aberdeen is a charity registered in Scotland, No
> > SC013683.
> >
> >
> > ------------------------------
> >
> > Message: 7
> > Date: Tue, 14 Jul 2009 14:03:24 +0100
> > From: A.L.M.Buxey at lboro.ac.uk
> > To: "Forrest, Michael E." <michael.forrest at abdn.ac.uk>
> > Cc: "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>
> > Subject: Re: [c-nsp] ASA IPsec Tunnel Failover
> > Message-ID: <20090714130324.GA16535 at lboro.ac.uk>
> > Content-Type: text/plain; charset=us-ascii
> >
> > Hi,
> > > I was under the impression that there was no BGP support in the ASA
> > platform, unless someone knows otherwise?
> >
> > ah, ASAs and dynamic routing protocols...and you'll be wanting
> > those in multi-context mode too?  ;-)
> >
> > alan
> >
> >
> >
> > ------------------------------
> >
> > Message: 8
> > Date: Tue, 14 Jul 2009 08:21:53 -0500
> > From: Geoffrey Pendery <geoff at pendery.net>
> > To: A.L.M.Buxey at lboro.ac.uk
> > Cc: cisco-nsp at puck.nether.net
> > Subject: Re: [c-nsp] Maximum spannig tree instances
> > Message-ID:
> >        <d6966e4b0907140621s504dea4aq120b1f2440f76f1d at mail.gmail.com>
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > Yes, but he also mentions MST, which has a much more restrictive
> limit.
> > As far as I've seen, 802.1s itself only allows 64 instances (see
> > http://en.wikipedia.org/wiki/Spanning_tree_protocol , or search for
> > the proper RFC docs)
> > But all the Cisco docs I've found this morning say they only support
> 16:
> > for example:
> >
> >
> http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/na
> tive/configuration/guide/spantree.html#wp1064097
> >
> > I could have sworn I found stuff saying that our gear would support 64
> > of them, and we've been contemplating more than 40 in recent designs,
> > but I guess I'll have to validate in the lab whether it's actually 16
> > or 64 for our chassis and code.
> >
> > So keep in mind that if you're moving from RPVST to MST, you're
> > talking about fewer instances, by necessity.
> >
> >
> > -Geoff
> >
> >
> > On Tue, Jul 14, 2009 at 3:45 AM, <A.L.M.Buxey at lboro.ac.uk> wrote:
> > > Hi,
> > >
> > >> ... but it doesn't say anything about the number of STP instances.
> > >
> > > things go wonky when you have more than 1800 virtualports per slot
> > > (which you didnt quite reach) (1200 on older eg 100mbit blades)
> > > with 13,000 in total (PVST+), 10,000 in total (RPVST+)
> > >
> > > however, with MST, you can have 6000 virtual ports per blade and
> 50,000
> > > in total (yay!)
> > >
> > > however, this is all about logical interfaces. you want to know the
> > > STP instance?
> > >
> > > regarding maximum STP instances... I believe theres a platform limit
> > > of 1024 because of the MAC to VLAN bridge mapping on the platform -
> > > but, from the values above, you can see that virtual ports would
> > > hit you quite quickly without appropriate control of the VLANs
> > >
> > > 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
> >
> > End of cisco-nsp Digest, Vol 80, Issue 49
> > *****************************************
> >
>
>
>
> --
> --
> Regards,
> Digambar Giri
> +91- 9975776368
> _______________________________________________
> cisco-nsp mailing 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,
Digambar Giri
+91- 9975776368

From christian at zengl.net  Wed Jul 15 03:30:18 2009
From: christian at zengl.net (Christian Zeng)
Date: Wed, 15 Jul 2009 09:30:18 +0200
Subject: [c-nsp] c877 and ntp oddness
In-Reply-To: <h3ic1u$crf$1@ger.gmane.org>
References: <h3ic1u$crf$1@ger.gmane.org>
Message-ID: <20090715073018.GF6613@zengl.net>

Hi,

* David Freedman <david.freedman at uk.clara.net> wrote:
>Have a bizarre NTP issue with 877 routers running 12.4(T) train.
>
>- Only seems to affect a small percentage of 877 routers,
>878s, 1800s , 2800s seem to be fine

A coworker reported the exact same behavior a couple of weeks ago. They
got 87x routers with a new hardware revision, these routers do not sync
with ntp anymore. TAC case is open, but nothing concrete so far.


Christian

From eng_mssk at hotmail.com  Wed Jul 15 03:44:25 2009
From: eng_mssk at hotmail.com (Mohammad Khalil)
Date: Wed, 15 Jul 2009 10:44:25 +0300
Subject: [c-nsp] Block https
Message-ID: <BLU102-W210525BA34AB08CB543CB2FA200@phx.gbl>




I want to block the url https://www.facebook.com


Without using NBAR 

Using access-lists ??

And if I want to block based on the IP address it has a lot
of IP addresses ( i dont want to block a whole class)


And the cache only blocks based on HTTP port 80


_________________________________________________________________
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 K.J.Barrass at leeds.ac.uk  Wed Jul 15 03:58:33 2009
From: K.J.Barrass at leeds.ac.uk (Kevin Barrass)
Date: Wed, 15 Jul 2009 08:58:33 +0100
Subject: [c-nsp] Block https
In-Reply-To: <BLU102-W210525BA34AB08CB543CB2FA200@phx.gbl>
References: <BLU102-W210525BA34AB08CB543CB2FA200@phx.gbl>
Message-ID: <3335DB7CB6183F4DB80A450F75FB083E2F2468F51F@HERMES7.ds.leeds.ac.uk>

Hi

One I used a while ago to test was the below

ip urlfilter allow-mode on
ip urlfilter exclusive-domain deny www.theregister.co.uk

is a while since ive used this but you can check the Cisco Docs for the ip urlfilter feature, if you want to block based on IP just use access lists as normal to block traffic to that IP.

Regards
Kev

[]----------------------------------------------------------------------------[]
  Kev Barrass                      			|  YHMAN Operations Team
[]------------------------------------------------------------[www.yhman.net.uk]
-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Mohammad Khalil
Sent: 15 July 2009 08:44
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Block https




I want to block the url https://www.facebook.com


Without using NBAR 

Using access-lists ??

And if I want to block based on the IP address it has a lot
of IP addresses ( i dont want to block a whole class)


And the cache only blocks based on HTTP port 80


_________________________________________________________________
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
_______________________________________________
cisco-nsp mailing list  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 Jul 15 04:15:14 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Wed, 15 Jul 2009 10:15:14 +0200
Subject: [c-nsp] Where to buy What's Up Gold
In-Reply-To: <e45309330907150024l60ce2a0ckf90fe832a2ac2ff0@mail.gmail.com>
References: <mailman.3892.1247577796.2287.cisco-nsp@puck.nether.net>
	<e45309330907140729p240910c9y870a864a934e5c2e@mail.gmail.com>
	<4288131ED5E3024C9CD4782CECCAD2C7065D3851@LMC-MAIL2.exempla.org>
	<e45309330907150024l60ce2a0ckf90fe832a2ac2ff0@mail.gmail.com>
Message-ID: <1247645714.3869.10.camel@abehat.net.rm.dk>

Maybe not crack, but it might work: http://www.clubsmokey.nl/.

Listen kid, your question is clearly not on topic here even though it
does have some entertainment value. You make yourself look like a stupid
11 year old kid. If you really want to use What's Up Gold then go to
http://www.whatsupgold.com/online-shop/ and see if you can figure out
how it works.

You should also seriously consider the consequences of posting questions
like these to a public mailing list with your real name. It is standard
practice for potential employers to e.g. google your name before hiring
you.

Regards,
Peter


On Wed, 2009-07-15 at 12:54 +0530, Digambar. Giri wrote:
> DEar frend
> 
> i need a crak....... IPswitch Whatsup gold 11
> 
> On Tue, Jul 14, 2009 at 8:27 PM, Matlock, Kenneth L <MatlockK at exempla.org>wrote:
> 
> > The serial numbers can be found here:
> >
> > http://www.whatsupgold.com/
> >
> >
> > 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 Digambar. Giri
> > Sent: Tuesday, July 14, 2009 8:29 AM
> > To: cisco-nsp at puck.nether.net
> >  Subject: Re: [c-nsp] cisco-nsp Digest, Vol 80, Issue 49
> >
> > Dear friends
> > please provide IPswitch Whatsup gold 11 serial key NMs...
> >
> >
...
> > --
> > Regards,
> > Digambar Giri
> > +91- 9975776368



From linux.yahoo at gmail.com  Wed Jul 15 04:30:47 2009
From: linux.yahoo at gmail.com (Manu Chao)
Date: Wed, 15 Jul 2009 10:30:47 +0200
Subject: [c-nsp] MST config on single 3560
In-Reply-To: <20090714145752.qwkjhv749hwswwo0@webmail.datafx.com.au>
References: <20090714145752.qwkjhv749hwswwo0@webmail.datafx.com.au>
Message-ID: <7100ed370907150130x5609e29aqf61300e8f98f75ac@mail.gmail.com>

the standard is ieee 802.1s

don't change anything to your interface config
mst instance and vlan association is a global config

if you planned to migrate to mst on your side, make sure you will migrate to
mst with your client ;)

On Tue, Jul 14, 2009 at 6:57 AM, <mb at adv.gcomm.com.au> wrote:

> Hi,
>
> We have existing 3560's with multiple trunk ports to clients+upstreams - We
> will go very close to hitting the 128 STP instance limit, therefore MST
> looks to be like an option(Without upgrading the switches).
>
> The 3560's also have a trunk port to 7200's(For dot1q subints), for clients
> that require L3 connectivity.
>
> I'm just a little unsure how to group vlans into seperate instances(Or if
> it is entirely necessary?)
>
> i.e. GE0/1 (From Provider A) has:
>
> interface GigabitEthernet0/1
> description GIGE_ICAP_INTERNETCONNECT_TO_PROVIDER_A
> switchport trunk allowed vlan
> 112,172,208,211,240,309,315,385,537,547,550-552
> switchport trunk allowed vlan add
> 554,623,635,687,690,694,696,697,867,879,980
> switchport mode trunk
>
> These vlan's are allocated by provider and represent individual services -
> These vlans are then either presented on client trunk ports for L2 services,
> or added to trunk port to 7200 for L3 services.
>
> So as you can see, there is no "standard" for how the individual vlan's are
> treated, nor which trunk port they may be presented on.....hoping someone
> can provide guideance on how best to manage this?
>
> Thanks in advance.
>
> -------------------------------------------------------------------------
> This e-mail was sent via GCOMM WebMail http://www.gcomm.com.au/
>
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From eng_mssk at hotmail.com  Wed Jul 15 04:43:07 2009
From: eng_mssk at hotmail.com (Mohammad Khalil)
Date: Wed, 15 Jul 2009 11:43:07 +0300
Subject: [c-nsp] Siemens
Message-ID: <BLU102-W255A6C6354919C8F10C7C1FA200@phx.gbl>


i have siemens wimax cpe (gigaset SX682)

i cannot access the web interface using the default password admin

always prompted its incorrect 

and i need a user manual 

can anyone help
_________________________________________________________________
Windows Live?: Keep your life in sync. Check it out!
http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_012009

From masood at nexlinx.net.pk  Wed Jul 15 07:02:38 2009
From: masood at nexlinx.net.pk (masood at nexlinx.net.pk)
Date: Wed, 15 Jul 2009 16:02:38 +0500 (PKT)
Subject: [c-nsp] Block https
In-Reply-To: <3335DB7CB6183F4DB80A450F75FB083E2F2468F51F@HERMES7.ds.leeds.ac.uk>
References: <BLU102-W210525BA34AB08CB543CB2FA200@phx.gbl>
	<3335DB7CB6183F4DB80A450F75FB083E2F2468F51F@HERMES7.ds.leeds.ac.uk>
Message-ID: <7424.196.46.241.57.1247655758.squirrel@nexmail1.nexlinx.net.pk>

Man, thts pretty straightforward. all u needed is

http://www.cisco.com/en/US/products/ps5855/products_configuration_example09186a0080ab4ddb.shtml

if i am remembering correctly, you can block https using proxy/cache
server; If it is Squid thn i can help you.

Regards,
Masood

> Hi
>
> One I used a while ago to test was the below
>
> ip urlfilter allow-mode on
> ip urlfilter exclusive-domain deny www.theregister.co.uk
>
> is a while since ive used this but you can check the Cisco Docs for the ip
> urlfilter feature, if you want to block based on IP just use access lists
> as normal to block traffic to that IP.
>
> Regards
> Kev
>
> []----------------------------------------------------------------------------[]
>   Kev Barrass                      			|  YHMAN Operations Team
> []------------------------------------------------------------[www.yhman.net.uk]
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Mohammad Khalil
> Sent: 15 July 2009 08:44
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] Block https
>
>
>
>
> I want to block the url https://www.facebook.com
>
>
> Without using NBAR
>
> Using access-lists ??
>
> And if I want to block based on the IP address it has a lot
> of IP addresses ( i dont want to block a whole class)
>
>
> And the cache only blocks based on HTTP port 80
>
>
> _________________________________________________________________
> 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
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>



From david.freedman at uk.clara.net  Wed Jul 15 07:26:10 2009
From: david.freedman at uk.clara.net (David Freedman)
Date: Wed, 15 Jul 2009 12:26:10 +0100
Subject: [c-nsp] c877 and ntp oddness
In-Reply-To: <20090715073018.GF6613@zengl.net>
References: <h3ic1u$crf$1@ger.gmane.org> <20090715073018.GF6613@zengl.net>
Message-ID: <h3keci$piu$1@ger.gmane.org>

Would you mind sharing the tac SR with me? about to open my own and
would help me lots if my request is in sync (pun intended) with yours.

David.

Christian Zeng wrote:
> Hi,
> 
> * David Freedman <david.freedman at uk.clara.net> wrote:
>> Have a bizarre NTP issue with 877 routers running 12.4(T) train.
>>
>> - Only seems to affect a small percentage of 877 routers,
>> 878s, 1800s , 2800s seem to be fine
> 
> A coworker reported the exact same behavior a couple of weeks ago. They
> got 87x routers with a new hardware revision, these routers do not sync
> with ntp anymore. TAC case is open, but nothing concrete so far.
> 
> 
> Christian
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 


From MatlockK at exempla.org  Wed Jul 15 08:17:50 2009
From: MatlockK at exempla.org (Matlock, Kenneth L)
Date: Wed, 15 Jul 2009 06:17:50 -0600
Subject: [c-nsp] cisco-nsp Digest, Vol 80, Issue 49
References: <mailman.3892.1247577796.2287.cisco-nsp@puck.nether.net><e45309330907140729p240910c9y870a864a934e5c2e@mail.gmail.com><4288131ED5E3024C9CD4782CECCAD2C7065D3851@LMC-MAIL2.exempla.org>
	<e45309330907150024l60ce2a0ckf90fe832a2ac2ff0@mail.gmail.com>
Message-ID: <4288131ED5E3024C9CD4782CECCAD2C70489E95A@LMC-MAIL2.exempla.org>

A few things.
 
1) I'm not your 'friend'. My friends actually PAY for what they use, not try outright theft (and advertise it on a public forum!)
2) This has nothing to do with Cisco equipment
3) If you want a monitoring package, I'd suggest either paying for it, or using one of the many open-source packages out there. Look through the archives and you'll find plenty of dicsussions about them.
 
Some people's kids.....
 
Ken Matlock
Network Analyst
Exempla Healthcare
(303) 467-4671
matlockk at exempla.org

________________________________

From: Digambar. Giri [mailto:digambar.giri at gmail.com]
Sent: Wed 7/15/2009 1:24 AM
To: Matlock, Kenneth L
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] cisco-nsp Digest, Vol 80, Issue 49


DEar frend
 
i need a crak....... IPswitch Whatsup gold 11 


On Tue, Jul 14, 2009 at 8:27 PM, Matlock, Kenneth L <MatlockK at exempla.org> wrote:


	The serial numbers can be found here:
	
	http://www.whatsupgold.com/
	
	
	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 Digambar. Giri
	Sent: Tuesday, July 14, 2009 8:29 AM
	To: cisco-nsp at puck.nether.net
	
	Subject: Re: [c-nsp] cisco-nsp Digest, Vol 80, Issue 49
	
	Dear friends
	please provide IPswitch Whatsup gold 11 serial key NMs...
	
	
	On 7/14/09, cisco-nsp-request at puck.nether.net <
	cisco-nsp-request at puck.nether.net> wrote:
	>
	> Send cisco-nsp mailing list submissions to
	>        cisco-nsp at puck.nether.net
	>
	> To subscribe or unsubscribe via the World Wide Web, visit
	>        https://puck.nether.net/mailman/listinfo/cisco-nsp
	> or, via email, send a message with subject or body 'help' to
	>        cisco-nsp-request at puck.nether.net
	>
	> You can rDAr each 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: "Software Download Area is Unavailable at this time"
	>      (Gert Doering)
	>   2. Block URL ACCESS LIST (Mohammad Khalil)
	>   3. Re: multiple vlans on a port (Gert Doering)
	>   4. Re: Block URL ACCESS LIST (masood at nexlinx.net.pk)
	>   5. Re: IPv6 iBGP Route Reflector (Steve Bertrand)
	>   6. Re: ASA IPsec Tunnel Failover (Forrest, Michael E.)
	>   7. Re: ASA IPsec Tunnel Failover (A.L.M.Buxey at lboro.ac.uk)
	>   8. Re: Maximum spannig tree instances (Geoffrey Pendery)
	>
	>
	> ----------------------------------------------------------------------
	>
	> Message: 1
	> Date: Tue, 14 Jul 2009 10:56:48 +0200
	> From: Gert Doering <gert at greenie.muc.de>
	> To: Phil Mayers <p.mayers at imperial.ac.uk>
	> Cc: Gert Doering <gert at greenie.muc.de>, "cisco-nsp at puck.nether.net"
	>        <cisco-nsp at puck.nether.net>,    Jared Mauch
	<jared at puck.nether.net>
	> Subject: Re: [c-nsp] "Software Download Area is Unavailable at this
	>        time"
	> Message-ID: <20090714085648.GD290 at greenie.muc.de>
	> Content-Type: text/plain; charset="us-ascii"
	>
	> Hi,
	>
	> On Tue, Jul 14, 2009 at 09:16:23AM +0100, Phil Mayers wrote:
	> > But can I just make a recommendation to everyone here: next time you
	go
	> > out to competitive tender, specify the nature of docs & software
	> > availability. List "HTTP downloads without client software or
	plugins"
	> > as a mandatory requirement.
	>
	> While this is a nice idea to cause some pressure, I can't see it as
	> overly realistic - if I have a router A that will fulfill everything
	> that we need, and a router B that will only do 80% and at the same
	> time costs 20% more, but has a better company web interface, I think
	it's
	> very unlikely that their web download thingie will be change our
	> decision.
	>
	> (Besides, most competitors web sites and software download processes
	are
	> even worse)
	>
	> 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/20090714/13933a9
	4/attachment-0001.bin <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090714/13933a94/attachment-0001.bin> 
	> >
	>
	> ------------------------------
	>
	> Message: 2
	> Date: Tue, 14 Jul 2009 12:48:52 +0300
	> From: Mohammad Khalil <eng_mssk at hotmail.com>
	> To: <cisco-nsp at puck.nether.net>
	> Subject: [c-nsp] Block URL ACCESS LIST
	> Message-ID: <BLU102-W20D319D228A429D7F5B1F9FA230 at phx.gbl>
	> Content-Type: text/plain; charset="windows-1256"
	>
	>
	> how can i block url using access-list ?
	>
	> _________________________________________________________________
	> Drag n? drop?Get easy photo sharing with Windows Live? Photos.
	>
	> http://www.microsoft.com/windows/windowslive/products/photos.aspx
	>
	> ------------------------------
	>
	> Message: 3
	> Date: Tue, 14 Jul 2009 11:49:11 +0200
	> From: Gert Doering <gert at greenie.muc.de>
	> To: Matthew Huff <mhuff at ox.com>
	> Cc: "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>
	> Subject: Re: [c-nsp] multiple vlans on a port
	> Message-ID: <20090714094911.GH290 at greenie.muc.de>
	> Content-Type: text/plain; charset="us-ascii"
	>
	> Hi,
	>
	> On Mon, Jul 13, 2009 at 06:38:23PM -0400, Matthew Huff wrote:
	> > Also, with 802.1q framing, you might run into fragmentation on
	> > the non-native VLANs. You may want to adjust the MTU on the virtual
	> > machines if Linux doesn't do it automatically.
	>
	> There are a few broken NIC cards on the Linux side that have issues
	> with "baby-jumbo" packets (1500 + 4 byte for 802.1q header).  Decent
	> gear - and that's what you want to use on a *server* - doesn't have
	> any issues there.
	>
	> And, just to clarify: *If* you have MTU problems due to 802.1q
	headers,
	> you will not see "fragmentation".  You'll see black-holing, because
	the
	> stack will not know about the MTU issue, and thus won't even think
	> about fragmentation.  (Fragmentation happens if there is a link on
	> the path that has smaller L3 MTU than the packet's sender - but in
	this
	> scenario, the L3 endpoints assume 1500, while the L2 link cannot
	handle
	> this.  Black hole).
	>
	> 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/20090714/6dc4550
	8/attachment-0001.bin <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090714/6dc45508/attachment-0001.bin> 
	> >
	>
	> ------------------------------
	>
	> Message: 4
	> Date: Tue, 14 Jul 2009 16:13:52 +0500 (PKT)
	> From: masood at nexlinx.net.pk
	> To: "Mohammad Khalil" <eng_mssk at hotmail.com>
	> Cc: cisco-nsp at puck.nether.net
	> Subject: Re: [c-nsp] Block URL ACCESS LIST
	> Message-ID:
	>
	<24754.196.46.241.57.1247570032.squirrel at nexmail1.nexlinx.net.pk>
	> Content-Type: text/plain;charset=iso-8859-1
	>
	>
	> Please go to the following URL to begin:
	>
	>
	>
	http://weblogs.com.pk/jahil/archive/2008/11/15/how-nbar-actually-classif
	ies-the-traffic-flows.aspx <http://weblogs.com.pk/jahil/archive/2008/11/15/how-nbar-actually-classifies-the-traffic-flows.aspx> 
	>
	> Regards,
	> Masood
	>
	> >
	> > how can i block url using access-list ?
	> >
	> > _________________________________________________________________
	> > 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/
	>
	>
	>
	>
	> ------------------------------
	>
	> Message: 5
	> Date: Tue, 14 Jul 2009 08:23:09 -0400
	> From: Steve Bertrand <steve at ibctech.ca>
	> To: Aleksandr Gurbo <kron at linkey.ru>
	> Cc: cisco-nsp at puck.nether.net
	> Subject: Re: [c-nsp] IPv6 iBGP Route Reflector
	> Message-ID: <4A5C78AD.5050006 at ibctech.ca>
	> Content-Type: text/plain; charset="iso-8859-1"
	>
	> Aleksandr Gurbo wrote:
	> > On Sat, 11 Jul 2009 19:08:17 -0400
	> > Steve Bertrand <steve at ibctech.ca> wrote:
	> >
	> >> Over the weekend, I'll find out how the OP can fix the routes, and
	> >> moreover, why they are broken in the first place.
	> >>
	> >> Steve
	> >
	> > Have you any ideas how to fix reflected routes?
	>
	> I will be working on this specific issue today, as I need to make some
	> changes in preparation of adding a new router later this week.
	>
	> I'll keep you posted if I find anything specific as I go.
	>
	> Steve
	> -------------- next part --------------
	> A non-text attachment was scrubbed...
	> Name: smime.p7s
	> Type: application/x-pkcs7-signature
	> Size: 3233 bytes
	> Desc: S/MIME Cryptographic Signature
	> URL: <
	>
	https://puck.nether.net/pipermail/cisco-nsp/attachments/20090714/efe1560
	f/attachment-0001.bin <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090714/efe1560f/attachment-0001.bin> 
	> >
	>
	> ------------------------------
	>
	> Message: 6
	> Date: Tue, 14 Jul 2009 12:50:35 +0100
	> From: "Forrest, Michael E." <michael.forrest at abdn.ac.uk>
	> To: "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>
	> Subject: Re: [c-nsp] ASA IPsec Tunnel Failover
	> Message-ID:
	>
	<D2BEF91BFE51C743854D7AB86BA35A354984F7EC25 at VMAILA.uoa.abdn.ac.uk>
	> Content-Type: text/plain; charset="us-ascii"
	>
	> I was under the impression that there was no BGP support in the ASA
	> platform, unless someone knows otherwise?
	>
	> Michael.
	>
	> > -----Original Message-----
	> > From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
	> > bounces at puck.nether.net] On Behalf Of Prabhu Gurumurthy
	> > Sent: 14 July 2009 00:34
	> > To: Munoz, Jeff
	> > Cc: cisco-nsp at puck.nether.net
	> > Subject: Re: [c-nsp] ASA IPsec Tunnel Failover
	> >
	> > Answer is: BGP
	> >
	> > On Jul 13, 2009, at 1:14 PM, Munoz, Jeff wrote:
	> >
	> > > Hey guys, I have two main sites (site A and site B) and one remote
	> > > site (site C).  Sites A and B have a metroethernet connection
	> > > between them.  Remote site C has an IPsec tunnel back to site A.
	> > > I'd like to setup failover so in case site A's ASA is down the
	> > > remote site C ASA sends the interesting traffic down the site B
	> > > IPsec tunnel.  Unfortunately, it will always match the tunnel to
	> > > site A since the phase 2 access lists have the same source/
	> > > destinations.  Any ideas on how I can do this?
	> > >
	> > > Thanks!
	> > >
	> > > 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/
	> >
	> > _______________________________________________
	> > cisco-nsp mailing 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 University of Aberdeen is a charity registered in Scotland, No
	> SC013683.
	>
	>
	> ------------------------------
	>
	> Message: 7
	> Date: Tue, 14 Jul 2009 14:03:24 +0100
	> From: A.L.M.Buxey at lboro.ac.uk
	> To: "Forrest, Michael E." <michael.forrest at abdn.ac.uk>
	> Cc: "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>
	> Subject: Re: [c-nsp] ASA IPsec Tunnel Failover
	> Message-ID: <20090714130324.GA16535 at lboro.ac.uk>
	> Content-Type: text/plain; charset=us-ascii
	>
	> Hi,
	> > I was under the impression that there was no BGP support in the ASA
	> platform, unless someone knows otherwise?
	>
	> ah, ASAs and dynamic routing protocols...and you'll be wanting
	> those in multi-context mode too?  ;-)
	>
	> alan
	>
	>
	>
	> ------------------------------
	>
	> Message: 8
	> Date: Tue, 14 Jul 2009 08:21:53 -0500
	> From: Geoffrey Pendery <geoff at pendery.net>
	> To: A.L.M.Buxey at lboro.ac.uk
	> Cc: cisco-nsp at puck.nether.net
	> Subject: Re: [c-nsp] Maximum spannig tree instances
	> Message-ID:
	>        <d6966e4b0907140621s504dea4aq120b1f2440f76f1d at mail.gmail.com>
	> Content-Type: text/plain; charset=ISO-8859-1
	>
	> Yes, but he also mentions MST, which has a much more restrictive
	limit.
	> As far as I've seen, 802.1s itself only allows 64 instances (see
	> http://en.wikipedia.org/wiki/Spanning_tree_protocol , or search for
	> the proper RFC docs)
	> But all the Cisco docs I've found this morning say they only support
	16:
	> for example:
	>
	>
	http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/na
	tive/configuration/guide/spantree.html#wp1064097 <http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/native/configuration/guide/spantree.html#wp1064097> 
	>
	> I could have sworn I found stuff saying that our gear would support 64
	> of them, and we've been contemplating more than 40 in recent designs,
	> but I guess I'll have to validate in the lab whether it's actually 16
	> or 64 for our chassis and code.
	>
	> So keep in mind that if you're moving from RPVST to MST, you're
	> talking about fewer instances, by necessity.
	>
	>
	> -Geoff
	>
	>
	> On Tue, Jul 14, 2009 at 3:45 AM, <A.L.M.Buxey at lboro.ac.uk> wrote:
	> > Hi,
	> >
	> >> ... but it doesn't say anything about the number of STP instances.
	> >
	> > things go wonky when you have more than 1800 virtualports per slot
	> > (which you didnt quite reach) (1200 on older eg 100mbit blades)
	> > with 13,000 in total (PVST+), 10,000 in total (RPVST+)
	> >
	> > however, with MST, you can have 6000 virtual ports per blade and
	50,000
	> > in total (yay!)
	> >
	> > however, this is all about logical interfaces. you want to know the
	> > STP instance?
	> >
	> > regarding maximum STP instances... I believe theres a platform limit
	> > of 1024 because of the MAC to VLAN bridge mapping on the platform -
	> > but, from the values above, you can see that virtual ports would
	> > hit you quite quickly without appropriate control of the VLANs
	> >
	> > 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
	>
	> End of cisco-nsp Digest, Vol 80, Issue 49
	> *****************************************
	>
	
	
	
	--
	--
	Regards,
	Digambar Giri
	+91- 9975776368
	_______________________________________________
	cisco-nsp mailing 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,
Digambar Giri
+91- 9975776368 



From geoff at pendery.net  Wed Jul 15 09:01:13 2009
From: geoff at pendery.net (Geoffrey Pendery)
Date: Wed, 15 Jul 2009 08:01:13 -0500
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <4A5D620D.6090606@acsalaska.net>
References: <9DE4AA6876D44B62B87C475B2AFE5514@au.didata.local>
	<20090714141529.GN290@greenie.muc.de>
	<Pine.LNX.4.61.0907141101240.6312@soloth.lewis.org>
	<d6966e4b0907140835u597c7ae3l3991ba636ae93bcf@mail.gmail.com>
	<Pine.LNX.4.61.0907141139180.6312@soloth.lewis.org>
	<9e246b4d0907141020v4189c867mcb5e8208454fbc4d@mail.gmail.com>
	<Pine.LNX.4.61.0907141355280.6312@soloth.lewis.org>
	<d6966e4b0907141122g714a3e8bwfbee02edca4a80a8@mail.gmail.com>
	<9e246b4d0907141137v3653261n53b452b98236971d@mail.gmail.com>
	<4A5D620D.6090606@acsalaska.net>
Message-ID: <d6966e4b0907150601k2b841de3nf4f11fa8fd7f5faa@mail.gmail.com>

Well sure, I'm aware of the logic behind the behavior - I'm not saying
it's a bug.  But the result is that it is a good choice protocol for a
very specific scenario, while RPVST is a much superior choice for
certain other scenarios.

So having been provided with a lovely open standard car and a
proprietary boat, we're understandably vexed to be told we must cross
the ocean in cars - since they're open standard.


-Geoff


On Tue, Jul 14, 2009 at 11:58 PM, Christopher E.
Brown<chris.brown at acsalaska.net> wrote:
> Tim Durack wrote:
>> On Tue, Jul 14, 2009 at 2:22 PM, Geoffrey Pendery <geoff at pendery.net> wrote:
>>
>>>> Will adding new VLANs to an MST instance disrupt traffic flow for other
>>>> VLANs in that MST instance?
>>> Yes. ?We've verified this.
>>> A trunk port carrying only VLAN 30, or even an access port carrying
>>> only VLAN 30.
>>> VLAN 30 is in instance 2. ?You go into config mode and add VLAN 50 to
>>> instance 2 (or remove it from instance 2)
>>> The port, be it access or trunk, goes to blocking, learning, forwarding.
>>>
>>
>> ...and if that doesn't make you nervous, you probably shouldn't be running
>> spanning-tree...
>>
>> 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/
>
>
> Come on guys, study the proto a little before going off.
>
>
>
> In order for MST to work all members of an MST domain *MUST* agree on
> the VLAN -> MST group mapping.
>
>
> If you change the mapping it must update across all members of the domain.
>
> YOU ARE REDEFINING THE STP TOPOLOGY
>
>
> _Pick a topology_
>
>
> MST group pre-assign...
>
>
> 0 ? ? ? VLAN 1
> 1 ? ? ? VLAN 2-999
> 2 ? ? ? VLAN 1000-1999
> 3 ? ? ? VLAN 2000-2999
> 4 ? ? ? VLAN 3000-3999
> 5 ? ? ? VLAN 4000-4094
>
>
> Or whatever grouping youl want, even/odd, by hundreds, whatever.
>
>
>
> You are now free to pick a different root and set link costs for each of
> the groups independent of the others, just like pvst but by group.
>
>
> If you *cannot* manage vlans by group, then stick with a rapid per vlan
> variant.
>
>
> If you need to move vlans in bulk across the core, and can afford to
> pre-assign membership in the group then MST can be lower overhead.
>
>
> The only real rules here
>
> Leave group zero for vlan one *only*
>
> If you have to change the base MST config more than once a year you are
> not planning correctly, or you should not be using MST.
>
>
>
>

From ip at ioshints.info  Wed Jul 15 09:27:49 2009
From: ip at ioshints.info (Ivan Pepelnjak)
Date: Wed, 15 Jul 2009 15:27:49 +0200
Subject: [c-nsp] Block https
In-Reply-To: <7424.196.46.241.57.1247655758.squirrel@nexmail1.nexlinx.net.pk>
References: <BLU102-W210525BA34AB08CB543CB2FA200@phx.gbl><3335DB7CB6183F4DB80A450F75FB083E2F2468F51F@HERMES7.ds.leeds.ac.uk>
	<7424.196.46.241.57.1247655758.squirrel@nexmail1.nexlinx.net.pk>
Message-ID: <001901ca0550$0d529940$0a00000a@nil.si>

You cannot block HTTPS on the router with anything but the IP-based access
lists because (by definition) the HTTP request (which the URL filter,
content filter or NBAR recognizing HTTP uses) is encrypted.

If you want to block HTTPS requests for particular hosts, you need a HTTP
proxy which intercepts the CONNECT requests and allows/denies them. You
could force the users to go through a proxy by blocking direct Internet
access for ports 80 through 443.

However, to block HTTPS access to Facebook, the easiest thing to do is this:

* do a DNS lookup for www.facebook.com
* do a WHOIS query for the IP address
* at the moment facebook does not use distributed CDN, so the IP address is
within the IP address range allocated to Facebook Inc.
* block the whole address range assigned to them.

... And keep in mind that this is a whack-a-mole game ;)
Ivan
 
http://www.ioshints.info/about
http://blog.ioshints.info/

> -----Original Message-----
> From: masood at nexlinx.net.pk [mailto:masood at nexlinx.net.pk] 
> Sent: Wednesday, July 15, 2009 1:03 PM
> To: Kevin Barrass
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] Block https
> 
> Man, thts pretty straightforward. all u needed is
> 
> http://www.cisco.com/en/US/products/ps5855/products_configurat
> ion_example09186a0080ab4ddb.shtml
> 
> if i am remembering correctly, you can block https using 
> proxy/cache server; If it is Squid thn i can help you.
> 
> Regards,
> Masood
> 
> > Hi
> >
> > One I used a while ago to test was the below
> >
> > ip urlfilter allow-mode on
> > ip urlfilter exclusive-domain deny www.theregister.co.uk
> >
> > is a while since ive used this but you can check the Cisco Docs for 
> > the ip urlfilter feature, if you want to block based on IP just use 
> > access lists as normal to block traffic to that IP.
> >
> > Regards
> > Kev
> >
> > 
> []------------------------------------------------------------
> ----------------[]
> >   Kev Barrass                      			|  
> YHMAN Operations Team
> > 
> []------------------------------------------------------------[www.yhm
> > an.net.uk]
> > -----Original Message-----
> > From: cisco-nsp-bounces at puck.nether.net 
> > [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Mohammad 
> > Khalil
> > Sent: 15 July 2009 08:44
> > To: cisco-nsp at puck.nether.net
> > Subject: [c-nsp] Block https
> >
> >
> >
> >
> > I want to block the url https://www.facebook.com
> >
> >
> > Without using NBAR
> >
> > Using access-lists ??
> >
> > And if I want to block based on the IP address it has a lot of IP 
> > addresses ( i dont want to block a whole class)
> >
> >
> > And the cache only blocks based on HTTP port 80
> >
> >
> > _________________________________________________________________
> > 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 _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net 
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net 
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> >
> 
> 
> 
> 


From tomas at soitron.com  Wed Jul 15 09:30:45 2009
From: tomas at soitron.com (Tomas Daniska)
Date: Wed, 15 Jul 2009 15:30:45 +0200
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>
References: <9DE4AA6876D44B62B87C475B2AFE5514@au.didata.local><a1873f1f0907131438m3f0b4c70r82a953a29042b6d7@mail.gmail.com><1247524340.4661.65.camel@abehat.net.rm.dk><20090714084503.GA15753@lboro.ac.uk>
	<d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>
Message-ID: <6B43981C32F8464CB24CEE209DA32BD302350ADD@kenya.tronet.as>


> 
> On Tue, Jul 14, 2009 at 3:45 AM, <A.L.M.Buxey at lboro.ac.uk> wrote:
> > Hi,
> >
> >> ... but it doesn't say anything about the number of STP instances.
> >
> > things go wonky when you have more than 1800 virtualports per slot
> > (which you didnt quite reach) (1200 on older eg 100mbit blades)
> > with 13,000 in total (PVST+), 10,000 in total (RPVST+)
> >

As a matter of coincidence, I've been in talks recently with our local
Cisco SEs for some 6k5/3750E design, mostly discussing RSTP vs MST. I
have asked about the 1800 virtual ports per blade limit and they say
this only applies to 61xx and 63xx cards - the 65xx and 67xx have no
such limit. There is a ddts that a message errorneously warning of
exceeding 1800 virtual ports on a 67xx is removed since SXI (or SXI1 it
was).



Re MST vs RSTP... the worst case in MST for us is that once you get any
tiny irregularity on a port, it gets to interoperability mode, which
means the port is calculated against CIST (MST0). And then, any issue or
TCN you have, everything gets propagated to all remaining instances,
causing MAC table flushes and other nice stuff for the *whole*
infrastructure.

We had an idea of having two independent MST domains interconnected by a
(VSS/Multichassis Etherchannel) trunk, so we could have STP events
contained within a single physical location. But with respect to
abovewritten the trunk would be in the interop mode, amplyfing all
events instead of separating the domains. We could have had BPDU filter
to solve this on the trunk, but obviously would lose loop prevention
because of that.

And not speaking of MST experience we had building a large-scale Metro
Ethernet network, with many access rings. We have repeatedly seen BPDUs
transported via EoMPLS pseudowires in 3750ME based rings causing NNI
trunks (running MST) get into P2P Edge mode and thus bringing the whole
ring down. Yes, this is more due to the pretty weird MPLS implementation
on the 3750ME, but nicely showing MST weaknesses...


So far, MST hase become a no-go for us unless there's a *very* strong
scaling requirement.


--

deejay
 

__________ Informacia od ESET NOD32 Antivirus, verzia databazy 4240
(20090713) __________

Tuto spravu preveril ESET NOD32 Antivirus.

http://www.eset.sk
 

From rodunn at cisco.com  Wed Jul 15 10:19:21 2009
From: rodunn at cisco.com (Rodney Dunn)
Date: Wed, 15 Jul 2009 10:19:21 -0400
Subject: [c-nsp] 7206VXR BGP Sessions
In-Reply-To: <001901ca04d6$16d23db0$4476b910$@org>
References: <001901ca04d6$16d23db0$4476b910$@org>
Message-ID: <20090715141921.GI20186@rtp-cse-489.cisco.com>

Default timers...several hundred will be ok.

You get in trouble when you try to bring the timers down less than say 20/60.

We introduced a new scheduler to handle hellos for the peers that allows
them to work at smaller intervals but it can't guarantee no false positives.

Rodney

On Tue, Jul 14, 2009 at 06:54:47PM -0400, Paul Stewart wrote:
> Hi there.
> 
>  
> 
> I need to move several hundred BGP sessions (low traffic peers, about 500
> Mb/s combined) over to another box - have a 7206VXR with NPE1G and a 7206VXR
> with NPE2G sitting spare at moment.  
> 
>  
> 
> How many sessions/traffic should the 1G and the 2G be able to handle
> approximately?
> 
>  
> 
> Thanks,
> 
>  
> 
> Paul
> 
>  
> 
>  
> 
>  
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

From jmkeller at houseofzen.org  Wed Jul 15 10:40:33 2009
From: jmkeller at houseofzen.org (James Michael Keller)
Date: Wed, 15 Jul 2009 10:40:33 -0400
Subject: [c-nsp] WAAS and minimum latency
In-Reply-To: <9e246b4d0907141001w66aeba1dy68255bdc780e82e0@mail.gmail.com>
References: <9e246b4d0907141001w66aeba1dy68255bdc780e82e0@mail.gmail.com>
Message-ID: <4A5DEA61.90804@houseofzen.org>

Tim,

I doubt you will see improvement over 3ms for general latency reduction 
(assuming a OCX P-t-P link?).  However it will improve CIFS performance 
if the files are being accessed and changed a lot by the users at the 
site remote from the CIFS server.   The WAE on the server side of the 
link will cache operations locally.   So say you move a file between 
CIFS shares, normally that comes back through the client and back down 
to another share.    With the WAE unit it will proxy that operation and 
the operation completes at local LAN speed instead of WAN speed through 
the remote client and back to the other server.   While WAE's will 
fiddle with TCP settings to improve some performance, the main function 
in the current release code is the data reduction features.  Either the 
raw DRE caches or application level proxies (CIFS/MAPI,NFS, etc).   
Latency may not improve, but effective speed and bandwidth will go up.

For our MPLS connected sites in the 50ms+ range, there is some 
improvement of the RTT of around 40% on average across all the sites.    
Traffic reduction runs an average of 30% with Content and version 
management protocols and CIFS/MAPI making up the bulk of the traffic 
reduction (all above 50%) .  The main non-optimized traffic is internet 
bound in our case, as we centrally route internet out a data center from 
the MPLS connected sites.

---
James Michael Keller



Tim Durack wrote:
> Anyone got figures on the *minimum* latency the various WAN accelerators can
> improve on?
>
> I ask as I have a customer with a couple of sites connected via GigE. RTT
> for SiteA -> SiteB is around 3ms. Migrating services between sites has
> reduced performance for some users (appears that SMB/CIFS is most affected.)
>
> I'm looking to see if I can "fix" things with WAAS, just not sure they are
> really designed for this scenario (I'm not a fan of WAAS, but if it fixes a
> problem...)
>
> Thanks,
>
> Tim:>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>   

From tvarriale at comcast.net  Wed Jul 15 11:01:24 2009
From: tvarriale at comcast.net (Tony Varriale)
Date: Wed, 15 Jul 2009 10:01:24 -0500
Subject: [c-nsp] Give Cisco your feedback on the new download experience
	at tacwebsurvey@cisco.com (was: several heart-felt flames
	regarding the mess that is the Cisco.com download experience)
References: <9DE84313-097E-4D4C-A118-084AC527217D@puck.nether.net><20090713222139.GA78946@puck.nether.net><20090714063307.GB290@greenie.muc.de><A3A093A3-9EA7-4498-9205-CB272AF6A45B@puck.nether.net><4A5CD493.70202@justinshore.com><2454679F-A68A-483D-B116-1BAC7A0D3F1B@puck.nether.net><20090715063115.GA6483@mx.ytti.net>
	<Pine.LNX.4.64.0907151009290.7796@efes.iucc.ac.il>
Message-ID: <9026D740614941E7AB7E3F918C9ED6BD@flamdt01>

Interesting comment.

I stopped giving feedback a long time ago when they did the first major 
trainwreck of cisco.com.

tv
----- Original Message ----- 
From: "Hank Nussbacher" <hank at efes.iucc.ac.il>
To: "Saku Ytti" <saku at ytti.fi>
Cc: <cisco-nsp at puck.nether.net>
Sent: Wednesday, July 15, 2009 2:13 AM
Subject: Re: [c-nsp] Give Cisco your feedback on the new download experience 
at tacwebsurvey at cisco.com (was: several heart-felt flames regarding the mess 
that is the Cisco.com download experience)


> I guess cisco-nsp has become a soapbox for catharsis in regards to Cisco - 
> but everyone should realize that is about all it is.  Cisco has no 
> interest in fixing their download or bugtool problems.  It is a simple 
> matter of cost cutting and budgets and taking the cheapest offer or hiring 
> the cheapest labor.
>
> So keep filling out those feedback forms and calling your Cisco bigwig 
> friends.  If that makes you feel any better, go for it.  Me - I've moved 
> on as many others have.
>
> Regards,
> Hank
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/ 


From moua0100 at umn.edu  Wed Jul 15 11:07:10 2009
From: moua0100 at umn.edu (Ge Moua)
Date: Wed, 15 Jul 2009 10:07:10 -0500
Subject: [c-nsp] SA-VAM & NPE-200
In-Reply-To: <BF3145D4759F9846A1214E628425C3C201622F62B5@ZEUS.RGCOLO.local>
References: <BF3145D4759F9846A1214E628425C3C201622F62B5@ZEUS.RGCOLO.local>
Message-ID: <4A5DF09E.1000604@umn.edu>

I've done this before; this will work but Cisco will not give you 
support if there are issues;also the VAM combo with this router engine 
results in very llittle throughput; not worth it IMHO.

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

Network Design Engineer
University of Minnesota | Networking & Telecommunications Services




Kris Amy wrote:
> Hi,
>
> Just wondering if this combination works. The documentation says a NPE225 is required however i'm wondering if that is just a warning or an actual requirement...
>
> --
> Kind Regards,
> Kris Amy
> Enterprise IP
> Phone:     07 3123 5510
> National: 1300 347 287
> Fax:         1300 347 329
> Direct:     07 3123 5511
> Email:      kris.amy at eip.net.au<outbind://2-00000000FC347F44727AD040BF1A93E9A3DC68310700065EB17B7262634485BBBA18AFE92E3E0007A2A2A7EE0000065EB17B7262634485BBBA18AFE92E3E0007D22B10350000/kris.amy at eip.net.au>
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>   

From djweis at internetsolver.com  Wed Jul 15 11:07:24 2009
From: djweis at internetsolver.com (Dave Weis)
Date: Wed, 15 Jul 2009 10:07:24 -0500 (CDT)
Subject: [c-nsp] MLPPP throughput
Message-ID: <Pine.LNX.4.63.0907150959150.28268@charmed.internetsolver.com>


I'm bringing up a MLPPP PPPoA bundle with 4 7-meg DSL lines. It had worked 
fine with only 2 lines in the bundle and provided the full expected speed. 
Adding the next two lines didn't provide an increase in speed, it actually 
might have decreased a bit. It tops out at around 10 megabits with 4 links 
in the bundle.

The hardware on the customer side is a 3745 running 12.4(4)T1. It has 4 
WIC-1ADSL's installed. The config on the ADSL interfaces are all 
identical:

interface ATM0/0
  no ip address
  no atm ilmi-keepalive
  dsl operating-mode auto
  hold-queue 224 in
  pvc 0/32
   encapsulation aal5mux ppp dialer
   dialer pool-member 1
  !

interface Dialer0
  ip address negotiated
  no ip proxy-arp
  encapsulation ppp
  dialer pool 1
  dialer vpdn
  dialer-group 1
  ppp pap sent-username <removed>
  ppp link reorders
  ppp multilink
  ppp multilink fragment disable
!

We've tried it with and without the reorders and fragment changes in the 
config.

The server side is a 7206 with an NPE-G1. We're not topping out the 
processor on either side during transfers.

The multilink bundle shows a lot of discards and reorders. This is after a 
reset and downloading less than a gig of data on the client:

Virtual-Access3, bundle name is isprouter
   Endpoint discriminator is isprouter
   Bundle up for 01:15:43, total bandwidth 400000, load 1/255
   Receive buffer limit 48768 bytes, frag timeout 1000 ms
   Using relaxed lost fragment detection algorithm.
   Dialer interface is Dialer0
     0/0 fragments/bytes in reassembly list
     242 lost fragments, 1237543 reordered
     29169/15194784 discarded fragments/bytes, 16700 lost received
     0x1F9178 received sequence, 0x6A517 sent sequence
   Member links: 4 (max not set, min not set)
     Vi4, since 01:15:43, unsequenced
     PPPoATM link, ATM PVC 0/32 on ATM0/0
     Packets in ATM PVC Holdq: 0, Particles in ATM PVC Tx Ring: 0
     Vi6, since 01:15:43, unsequenced
     PPPoATM link, ATM PVC 0/32 on ATM1/0
     Packets in ATM PVC Holdq: 0, Particles in ATM PVC Tx Ring: 0
     Vi5, since 01:15:43, unsequenced
     PPPoATM link, ATM PVC 0/32 on ATM0/2
     Packets in ATM PVC Holdq: 0, Particles in ATM PVC Tx Ring: 0
     Vi2, since 01:15:43, unsequenced
     PPPoATM link, ATM PVC 0/32 on ATM0/1
     Packets in ATM PVC Holdq: 0, Particles in ATM PVC Tx Ring: 0
No inactive multilink interfaces


Any ideas to get this closer to 20+ megs?

THanks
dave




-- 
Dave Weis
djweis at internetsolver.com
http://www.internetsolver.com/


From egirard at focustsi.com  Wed Jul 15 11:50:41 2009
From: egirard at focustsi.com (Eric Girard)
Date: Wed, 15 Jul 2009 11:50:41 -0400
Subject: [c-nsp] WAAS and minimum latency
In-Reply-To: <4A5DEA61.90804@houseofzen.org>
References: <9e246b4d0907141001w66aeba1dy68255bdc780e82e0@mail.gmail.com>
	<4A5DEA61.90804@houseofzen.org>
Message-ID: <DA808D312B7C6447AD0EB2CFC581C38405798B2D28@FOCUS-EXMS1.focustsi.com>

Tim,
        While in theory you should still see some improvement from CIFS with a setup like this, I've done a PoC/trial with a near identical setup, 1G/3-4ms latency, and the performance improvements where minimal at best.  The one caveat was the CIFS shares were being used by a questionable financial application and the average filesize was small, but in the end, the price/performance was impossible to justify given the size of WAE needed to handle that much traffic.
        In the more 'traditional' WAAS space above ~20ms of latency I've had great results every time.

Eric Girard

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of James Michael Keller
Sent: Wednesday, July 15, 2009 10:41 AM
To: Tim Durack
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] WAAS and minimum latency

Tim,

I doubt you will see improvement over 3ms for general latency reduction
(assuming a OCX P-t-P link?).  However it will improve CIFS performance
if the files are being accessed and changed a lot by the users at the
site remote from the CIFS server.   The WAE on the server side of the
link will cache operations locally.   So say you move a file between
CIFS shares, normally that comes back through the client and back down
to another share.    With the WAE unit it will proxy that operation and
the operation completes at local LAN speed instead of WAN speed through
the remote client and back to the other server.   While WAE's will
fiddle with TCP settings to improve some performance, the main function
in the current release code is the data reduction features.  Either the
raw DRE caches or application level proxies (CIFS/MAPI,NFS, etc).
Latency may not improve, but effective speed and bandwidth will go up.

For our MPLS connected sites in the 50ms+ range, there is some
improvement of the RTT of around 40% on average across all the sites.
Traffic reduction runs an average of 30% with Content and version
management protocols and CIFS/MAPI making up the bulk of the traffic
reduction (all above 50%) .  The main non-optimized traffic is internet
bound in our case, as we centrally route internet out a data center from
the MPLS connected sites.

---
James Michael Keller



Tim Durack wrote:
> Anyone got figures on the *minimum* latency the various WAN accelerators can
> improve on?
>
> I ask as I have a customer with a couple of sites connected via GigE. RTT
> for SiteA -> SiteB is around 3ms. Migrating services between sites has
> reduced performance for some users (appears that SMB/CIFS is most affected.)
>
> I'm looking to see if I can "fix" things with WAAS, just not sure they are
> really designed for this scenario (I'm not a fan of WAAS, but if it fixes a
> problem...)
>
> Thanks,
>
> Tim:>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From SPfister at dps.k12.oh.us  Wed Jul 15 12:28:14 2009
From: SPfister at dps.k12.oh.us (Steven Pfister)
Date: Wed, 15 Jul 2009 12:28:14 -0400
Subject: [c-nsp] Question on h.323 video calls through a PIX 525 with NAT
Message-ID: <4A5DCB56.9E6F.00B8.0@dps.k12.oh.us>

I'm having some trouble with h.323 (video) calls through a PIX 525 using NAT. We can get incoming calls fine, but not outgoing calls for some reason. My question has to do with 'inspect h323' vs 'fixup protocol h323'. What's the difference between them? The video conferencing unit in question has a NAT transversal option where I can supply an address and mask.I'm wondering if I'm having a NAT transversal problem anyway. Which one would handle the NAT transversal, inspect or fixup? Currently, the PIX config has:

  inspect h323 h225
  inspect h323 ras

do I need:

 fixup protocol h323 h225 1718-1720
 fixup protocol h323 h225 1720
 fixup protocol h323 ras 1718-1719

instead of the inspect commands? In addition to them?

Thanks!


Steve Pfister
Technical Coordinator, 
The Office of Information Technology
Dayton Public Schools
115 S. Ludlow St. 
Dayton, OH 45402
 
Office (937) 542-3149
Cell (937) 673-6779
Direct Connect: 137*131747*8
Email spfister at dps.k12.oh.us



From psirt at cisco.com  Wed Jul 15 13:04:23 2009
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Wed, 15 Jul 2009 13:04:23 -0400
Subject: [c-nsp] Cisco Security Advisory: Vulnerabilities in Unified Contact
	Center Express Administration Pages
Message-ID: <200907151305.uccx@psirt.cisco.com>

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

Cisco Security Advisory: Vulnerabilities in Unified Contact Center
Express Administration Pages

Advisory ID: cisco-sa-20090715-uccx

http://www.cisco.com/warp/public/707/cisco-sa-20090715-uccx.shtml

Revision 1.0

For Public Release 2009 July 15 1600 UTC (GMT)

Summary
=======

Cisco Unified Contact Center Express (Cisco Unified CCX) server contains
both a directory traversal vulnerability and a script injection
vulnerability in the administration pages of the Customer Response
Solutions (CRS) and Cisco Unified IP Interactive Voice Response (Cisco
Unified IP IVR) products. Exploitation of these vulnerabilities could
result in a denial of service condition, information disclosure, or a
privilege escalation attack.

Cisco has released free software updates that address these two
vulnerabilities in the latest version of Cisco Unified CCX software.

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

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

The Cisco Unified Contact Center Express (Cisco Unified CCX) is
a single-server, integrated "contact center in a box" for use in
deployments with up to 300 agents.

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

All versions of Cisco Unified CCX server running the following software
may be affected by these vulnerabilities, to include:

  * Cisco Customer Response Solution (CRS) versions 3.x, 4.x, 5.x,
    6.x, and 7.x
  * Cisco Unified IP Interactive Voice Response (Cisco Unified IP
    IVR) versions 3.x, 4.x, 5.x, 6.x, and 7.x
  * Cisco Unified CCX 4.x, 5.x, 6.x, and 7.x
  * Cisco Unified IP Contact Center Express versions 3.x, 5.x, 6.x,
    and 7.x
  * Cisco Customer Response Applications versions 3.x
  * Cisco IP Queue Manager (IP QM) versions 3.x

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

No other Cisco products are currently known to be affected by these
vulnerabilities.

Details
=======

Cisco Unified Contact Center Express (Cisco Unified CCX) servers may
be affected by both a directory traversal vulnerability and a script
injection vulnerability.

The directory traversal vulnerability may allow authenticated users to
view, modify, or delete any file on the server through the Customer
Response Solutions (CRS) Administration interface. This vulnerability
is documented in Cisco Bug ID CSCsw76644 and has been assigned Common
Vulnerability and Exposures (CVE) ID CVE-2009-2047.

The script injection vulnerability may allow authenticated users to
enter JavaScript into the Cisco Unified CCX database. The stored script
could be executed in the browser of the next authenticated user. This
vulnerability is documented in Cisco Bug ID CSCsw76649 and has been
assigned CVE ID CVE-2009-2048.

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.

* Incomplete input validation allows modification of OS
files/directories (CSCsw76644)

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 - 8.7
    Exploitability -           Functional
    Remediation Level -        Official-Fix
    Report Confidence -        Confirmed

* script injection vulnerability in admin interface pages (CSCsw76649)

CVSS Base Score - 5.5
    Access Vector -            Network
    Access Complexity -        Low
    Authentication -           Single
    Confidentiality Impact -   None
    Integrity Impact -         Partial
    Availability Impact -      Partial

CVSS Temporal Score - 4.5
    Exploitability -           Functional
    Remediation Level -        Official-Fix
    Report Confidence -        Confirmed


Impact
======

Successful exploitation of the directory traversal vulnerability may
result in read and write access to files on the underlying operating
system.

Successful exploitation of the script injection vulnerability may result
in the execution of JavaScript of authenticated users and prevent server
pages from displaying properly.

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

The fixes for these vulnerabilities are included in CRS version
7.0(1)SR2 and are available as a hotfix for customers running versions
5.x and 6.x. The hotfixes are crs5.0.2sr2es09 and crs6.0.1sr1es05.

The latest version of Cisco Unified Contact Center Express is
available at the following link:

http://tools.cisco.com/support/downloads/go/ImageList.x?relVer=7.0%281%29_SR2&mdfid=270569179&sftType=Cisco+Customer+Response+Solution+Software+Releases&optPlat=&nodecount=11&edesignator=null&modelName=Cisco+Unified+Contact+Center+Express&treeMdfId=2788752.

Information about how to obtain the hotfixes can be found in the release
notes enclosures of the bugs at: CSCsw76644 and CSCsw76649.

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
===========

There are no workarounds for these vulnerabilities.

The script injection attacks that are described in this advisory are
a specific classification of stored cross-site scripting attacks. A
description and mitigation technique can be found in the applied
mitigation bulletin available at the following link:

http://www.cisco.com/en/US/products/products_applied_mitigation_bulletin09186a008073f7b3.html

These vulnerabilities can be detected and mitigated with IDS signatures
3216-0 and 19001-0.

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 vulnerabilities described in this advisory.

These vulnerabilities were reported to Cisco by National Australia
Bank's Security Assurance team.

Cisco would like to thank the National Australia Bank's Security
Assurance team for the discovery and reporting of these vulnerabilities.

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-20090715-uccx.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 1.0  | 2009-July-15  | Initial 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.

+--------------------------------------------------------------------
Copyright 2008-2009 Cisco Systems, Inc. All rights reserved.
+--------------------------------------------------------------------

Updated: Jul 15, 2009                             Document ID: 110307
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkpeCwIACgkQ86n/Gc8U/uCRVACfQ16BguNxTclUmslEdX/l/W8Y
6DcAoJ3WjD6cV2PJ5LPVei8F9mMDyXLj
=wNQ1
-----END PGP SIGNATURE-----

From adrian.minta at gmail.com  Wed Jul 15 13:31:31 2009
From: adrian.minta at gmail.com (Adrian Minta)
Date: Wed, 15 Jul 2009 20:31:31 +0300
Subject: [c-nsp] IGMP snooping ME6500
In-Reply-To: <200907131947.n6DJlfEq002357@sj-core-5.cisco.com>
References: <4A58D9D4.8030205@gmail.com>
	<20090712141147.GA31466@wildfire.net.ic.ac.uk>
	<4A5A2187.3050303@gmail.com>
	<200907121821.n6CILLVV013502@sj-core-1.cisco.com>
	<4A5A2E33.3080902@gmail.com>
	<200907122233.n6CMXEVC020066@sj-core-5.cisco.com>
	<4A5B6DF6.6080709@gmail.com>
	<200907131739.n6DHcxex025885@sj-core-1.cisco.com>
	<4A5B766A.3040104@gmail.com>
	<200907131947.n6DJlfEq002357@sj-core-5.cisco.com>
Message-ID: <4A5E1273.3020307@gmail.com>

Tim Stevenson wrote:
> Ok - if you have mrouter ports being learned, then the upstream router 
> should be sending IGMP queries already & IGMP snooping querier is not 
> required.
>
> You may want to check the igmp snooping stats & see what type of joins 
> etc are being seen on 1/26. Also what is the downstream switch doing 
> from a snooping standpoint?
>
> Probably you should just open a case w/TAC to get to the bottom of 
> this one.
> Tim
>
> At 12:01 PM 7/13/2009, Adrian Minta asserted:
>
>
Thank you all ! I think I will start this process.

-- 
Best regards,
Adrian Minta



From jcartier at acs.on.ca  Wed Jul 15 13:49:06 2009
From: jcartier at acs.on.ca (Jeff Cartier)
Date: Wed, 15 Jul 2009 13:49:06 -0400
Subject: [c-nsp] BGP router-id - Chaos?
Message-ID: <BCD3E762F1767C42A5226BBACDE49BFBED8AA7@loki.acs.local>

Just checking something that I haven't been able to verify online...

 

Changing the bgp router-id manually will require you to clear the bgp
sessions?  Correct?

 

Thanks!!!


From lists at motorcitynet.com  Wed Jul 15 14:01:00 2009
From: lists at motorcitynet.com (M Callahan)
Date: Wed, 15 Jul 2009 14:01:00 -0400
Subject: [c-nsp] Free NMS Tools
In-Reply-To: <461308.822.qm@web76301.mail.sg1.yahoo.com>
References: <461308.822.qm@web76301.mail.sg1.yahoo.com>
Message-ID: <50797b9b0907151101y5b943eadncd0440bf1e724a4b@mail.gmail.com>

We're currently using Cacti, Nagios, and RANCID in an ISP environment.
Nagios is a bit bulky when it comes to the management side of things but I
highly recomend both RANCID and Cacti.  Depending on your knowledge level
with *nix systems, CactiEZ is also available.  The EZ version is a
CentOS-based pre-loaded iso.

Mike

From skoost at skoost.com  Wed Jul 15 13:35:01 2009
From: skoost at skoost.com (Ram Krishna Pariyar)
Date: 15 Jul 2009 17:35:01 +0000
Subject: [c-nsp] A little gift - Ram
Message-ID: <20090715173340.D334EF8003@skoismta09.skoost.com>

Ram Krishna Pariyar belongs to Skoost and sent you a little gift.

Click below to collect your gift:
http://uk.skoost.com/fun?cisco%2Dnsp%40puck%2Enether%2Enet/21588610/8

P.S. This is a safe and innocent gift that Ram Krishna Pariyar
sent from Skoost, the free goodies website.

This e-mail was sent to cisco-nsp at puck.nether.net on 7/15/2009 6:33:39 PM
on behalf of Ram Krishna Pariyar (rkitsolution at yahoo.com)

From ptimmins at clearrate.com  Wed Jul 15 14:06:22 2009
From: ptimmins at clearrate.com (Paul G. Timmins)
Date: Wed, 15 Jul 2009 14:06:22 -0400
Subject: [c-nsp] BGP router-id - Chaos?
In-Reply-To: <BCD3E762F1767C42A5226BBACDE49BFBED8AA7@loki.acs.local>
References: <BCD3E762F1767C42A5226BBACDE49BFBED8AA7@loki.acs.local>
Message-ID: <B98837F93D40A74D8656EAE7C1F57C5659DB5D@EXCHANGE1.corp.clearrate.net>

As far as I know, changing the router ID will take care of clearing the
BGP tables for you. :) It should reset all sessions.

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Jeff Cartier
Sent: Wednesday, July 15, 2009 1:49 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] BGP router-id - Chaos?

Just checking something that I haven't been able to verify online...

 

Changing the bgp router-id manually will require you to clear the bgp
sessions?  Correct?

 

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 ayourtch at gmail.com  Wed Jul 15 14:07:43 2009
From: ayourtch at gmail.com (Andrew Yourtchenko)
Date: Wed, 15 Jul 2009 20:07:43 +0200
Subject: [c-nsp] Question on h.323 video calls through a PIX 525 with NAT
In-Reply-To: <4A5DCB56.9E6F.00B8.0@dps.k12.oh.us>
References: <4A5DCB56.9E6F.00B8.0@dps.k12.oh.us>
Message-ID: <530c5af60907151107v52055d1dm86fbe5a0fc962828@mail.gmail.com>

Hi Steven,

On Wed, Jul 15, 2009 at 6:28 PM, Steven Pfister<SPfister at dps.k12.oh.us> wrote:
> I'm having some trouble with h.323 (video) calls through a PIX 525 using NAT. We can get incoming calls fine, but not outgoing calls for some reason. My question has to do with 'inspect h323' vs 'fixup protocol h323'. What's the difference between them? The video conferencing unit in question has a NAT transversal option where I can supply an address and mask.I'm wondering if I'm having a NAT transversal problem anyway. Which one would handle the NAT transversal, inspect or fixup? Currently, the PIX config has:
>
>  inspect h323 h225
>  inspect h323 ras
>
> do I need:
>
>  fixup protocol h323 h225 1718-1720
>  fixup protocol h323 h225 1720
>  fixup protocol h323 ras 1718-1719
>
> instead of the inspect commands? In addition to them?
>

"inspect" is the name of the "fixup" from 7.0 onwards - obviously as
time went, some more enhancements were added.

you can enter the "fixup" commands, but they will be autoconverted
into the respective "inspect" under "magic" default policy.

You mention that the inbound call works - so a nice way to debug would
be to grab the pcap on inside+ pcap on the outside and study them in
wireshark for both failing and working scenarios and see what is
different.

The first cutover point is whether you see the tcp/1720 in the
outbound direction or not - if not, or if it is going to the wrong
address, would mean there is an issue related to RAS signaling - else
it's something with the call signaling.

The above can be tested much easier if you are able to make the direct
calls by IP address and the other party can accept such calls without
involving RAS at all - this could be an easy shortcut instead of
staring at the sniffer traces :-) - if the direct call using IP
address works, then you can further investigate RAS. If the inbound
calls to you work, most probably it is going to be the case, but worth
doublechecking.

The inspect in the default configuration normally should be able to
tweak all the embedded IPs both for RAS and call setup, so the
endpoints would not need to have any NAT awareness nor do any special
efforts to detect/traverse the NAT.

Also might be quite useful to have a quick test with another h323
stack if you can - openh323 had a very tweakable client, and ekiga can
do h323 video as well. If those work, again you get one more baseline
to compare the sniffer traces with.

cheers,
andrew

From jcartier at acs.on.ca  Wed Jul 15 14:07:15 2009
From: jcartier at acs.on.ca (Jeff Cartier)
Date: Wed, 15 Jul 2009 14:07:15 -0400
Subject: [c-nsp] BGP router-id - Chaos?
In-Reply-To: <B98837F93D40A74D8656EAE7C1F57C5659DB5D@EXCHANGE1.corp.clearrate.net>
References: <BCD3E762F1767C42A5226BBACDE49BFBED8AA7@loki.acs.local>
	<B98837F93D40A74D8656EAE7C1F57C5659DB5D@EXCHANGE1.corp.clearrate.net>
Message-ID: <BCD3E762F1767C42A5226BBACDE49BFBED8ABA@loki.acs.local>

Oh that's lovely :)  Thanks for the heads up all!

-----Original Message-----
From: Paul G. Timmins [mailto:ptimmins at clearrate.com] 
Sent: Wednesday, July 15, 2009 2:06 PM
To: Jeff Cartier; cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] BGP router-id - Chaos?

As far as I know, changing the router ID will take care of clearing the
BGP tables for you. :) It should reset all sessions.

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Jeff Cartier
Sent: Wednesday, July 15, 2009 1:49 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] BGP router-id - Chaos?

Just checking something that I haven't been able to verify online...

 

Changing the bgp router-id manually will require you to clear the bgp
sessions?  Correct?

 

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 networking.stuff at googlemail.com  Wed Jul 15 14:08:06 2009
From: networking.stuff at googlemail.com (Chintan Shah)
Date: Wed, 15 Jul 2009 23:38:06 +0530
Subject: [c-nsp] IPV6 to IPV4
Message-ID: <1e7e04890907151108q19482badq55cea32b28279761@mail.gmail.com>

Hi,

The IPV6 host has to communicate to some IPV4 on Internet, I can use NAT-PT
one but I see that it is now no more recommended.

So, what is best translation mechanism achieve this when I being ISP provide
IPV6 Internet service to my customer?

 Regards,

CS

From harbor235 at gmail.com  Wed Jul 15 14:09:47 2009
From: harbor235 at gmail.com (harbor235)
Date: Wed, 15 Jul 2009 14:09:47 -0400
Subject: [c-nsp] CE routes
In-Reply-To: <00fa01ca04b5$979a1650$0a00000a@nil.si>
References: <836bf1f90907140950w4d6e25cfh29fb15816e5bc48d@mail.gmail.com>
	<00fa01ca04b5$979a1650$0a00000a@nil.si>
Message-ID: <836bf1f90907151109x309b5ffn263cbba3d5b0de68@mail.gmail.com>

I see, PE to CE routing protocols are segmented from PE to P routing
protocols. So for PE to PE traffic,
the ingress LSR only needs to know how to route to the egress PE router via
IGP label, once there the VPN label   forwards traffic to the proper VRF.
The next -hop for the desination route comes into play once at the egress
PE?

Mike



On Tue, Jul 14, 2009 at 3:02 PM, Ivan Pepelnjak <ip at ioshints.info> wrote:

> CE-PE subnets are part of VRF and thus cannot be inserted into the core
> IGP,
> only in MP-BGP. It's way easier (and more scalable) to redistribute them
> than to list them in the per-VRF BGP configuration.
>
> Ivan
>
> http://www.ioshints.info/about
> http://blog.ioshints.info/
>
> > -----Original Message-----
> > From: harbor235 [mailto:harbor235 at gmail.com]
> > Sent: Tuesday, July 14, 2009 6:51 PM
> > To: cisco-nsp at puck.nether.net
> > Subject: [c-nsp] CE routes
> >
> > I was just reading best practices for MPLS implementations
> > regarding CE to CE connectivity issues, specifically, CE to
> > CE pings. The document stated that redistributing connected
> > PE routes into BGP was the preferred method to ensure CE to
> > CE ping success as well as other connectivity issues. This
> > will inject the route for the PE to CE interface into BGP.I
> > am not sure I agree,  why not explicitly define which
> > networks to advertise in the IGP, an IGP in MPLS networks is
> > supposed to hold all infrastructure routes anyway. Are these
> > interfaces considered infrstructure or customer interfaces?
> > One reason may be to reduce the number of infrastructure
> > routes in the IGP because of the potential for many CE to PE
> > interfaces, let BGP handle the large number of routes?
> >
> > I am curious which method is employed in the wild, also I am
> > not sure all connected routes should be advertised from the
> > PE, e.g. management/infrastructure interfaces etc ...
> >
> > What are your thoughts and how is it being done?
> >
> > mike
> >
> >
>
>

From Andy.Litzinger at theplatform.com  Wed Jul 15 13:14:21 2009
From: Andy.Litzinger at theplatform.com (Andy Litzinger)
Date: Wed, 15 Jul 2009 10:14:21 -0700
Subject: [c-nsp] Question on h.323 video calls through a PIX 525 with NAT
In-Reply-To: <4A5DCB56.9E6F.00B8.0@dps.k12.oh.us>
References: <4A5DCB56.9E6F.00B8.0@dps.k12.oh.us>
Message-ID: <52AAD98E43AFC64AA04AF3AC4B8B64F70123D4FD68@tpmail03.corp.theplatform.com>

I don't think you can have the inspect and fixup in the same config.  I believe the inspection policies replace the fixup commands in the 7.x+ code.

either one pretty much does the same thing- its going into the packet and rewriting the IP in the h323 data payload (if necessary).

we had some issues with this behaviour and ended up disabling the h323 inspection and turning on the NAT traversal option of the device and things worked great for us.  YMMV.  Obviously you'll want to make sure you don't have any other h323 device traffic that would be affected by this change.

-andy

________________________________________
From: cisco-nsp-bounces at puck.nether.net [cisco-nsp-bounces at puck.nether.net] On Behalf Of Steven Pfister [SPfister at dps.k12.oh.us]
Sent: Wednesday, July 15, 2009 9:28 AM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Question on h.323 video calls through a PIX 525 with NAT

I'm having some trouble with h.323 (video) calls through a PIX 525 using NAT. We can get incoming calls fine, but not outgoing calls for some reason. My question has to do with 'inspect h323' vs 'fixup protocol h323'. What's the difference between them? The video conferencing unit in question has a NAT transversal option where I can supply an address and mask.I'm wondering if I'm having a NAT transversal problem anyway. Which one would handle the NAT transversal, inspect or fixup? Currently, the PIX config has:

  inspect h323 h225
  inspect h323 ras

do I need:

 fixup protocol h323 h225 1718-1720
 fixup protocol h323 h225 1720
 fixup protocol h323 ras 1718-1719

instead of the inspect commands? In addition to them?

Thanks!


Steve Pfister
Technical Coordinator,
The Office of Information Technology
Dayton Public Schools
115 S. Ludlow St.
Dayton, OH 45402

Office (937) 542-3149
Cell (937) 673-6779
Direct Connect: 137*131747*8
Email spfister at dps.k12.oh.us


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

From shimshah at cisco.com  Wed Jul 15 14:15:03 2009
From: shimshah at cisco.com (Shimol Shah ( Cisco ))
Date: Wed, 15 Jul 2009 14:15:03 -0400
Subject: [c-nsp] BGP router-id - Chaos?
In-Reply-To: <BCD3E762F1767C42A5226BBACDE49BFBED8AA7@loki.acs.local>
References: <BCD3E762F1767C42A5226BBACDE49BFBED8AA7@loki.acs.local>
Message-ID: <4A5E1CA7.7050205@cisco.com>

I tried in my lab with two boxes

28xx-----76xx

28xx is running 12.4(15)T9
76xx is running 12.2(33)SRB6
eBGP between the boxes.

I changed the route-id manually on 28xx
========================================

2800#sh ip bgp sum
BGP router identifier 10.10.10.1, local AS number 1020
BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down 
State/PfxRcd
2.2.2.2         4  1021      14      16        1    0    0 00:01:46        0
10.10.10.2      4  1021      14      16        1    0    0 00:01:34        0
2800#
2800#
2800#sh run | s bgp
router bgp 1020
  no synchronization
  bgp router-id 10.10.10.1
  bgp log-neighbor-changes
  neighbor 2.2.2.2 remote-as 1021
  neighbor 2.2.2.2 ebgp-multihop 10
  neighbor 2.2.2.2 update-source Loopback0
  neighbor 10.10.10.2 remote-as 1021
  no auto-summary
2800#
2800#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
2800(config)#
2800(config)#router bgp 1020
2800(config-router)#bgp rout
2800(config-router)#bgp router-id 1.1.1.1
2800(config-router)#end
2800#
*Jul 15 14:11:21.199 EST: %BGP-5-ADJCHANGE: neighbor 2.2.2.2 Down Router 
ID changed
*Jul 15 14:11:21.199 EST: %BGP-5-ADJCHANGE: neighbor 10.10.10.2 Down 
Router ID changed
*Jul 15 14:11:21.211 EST: %SYS-5-CONFIG_I: Configured from console by 
console
*Jul 15 14:11:21.239 EST: %BGP-5-ADJCHANGE: neighbor 2.2.2.2 Up
*Jul 15 14:11:21.251 EST: %BGP-5-ADJCHANGE: neighbor 10.10.10.2 Up
2800#

0#
2800#sh ip bgp sum
BGP router identifier 1.1.1.1, local AS number 1020
BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down 
State/PfxRcd
2.2.2.2         4  1021      17      21        1    0    0 00:00:28        0
10.10.10.2      4  1021      17      21        1    0    0 00:00:28        0
2800#


I then tried in on 7600
========================


7600#sh ip bgp sum
Load for five secs: 0%/0%; one minute: 3%; five minutes: 2%
Time source is hardware calendar, *18:13:06.279 EST Wed Jul 15 2009
BGP router identifier 10.10.10.2, local AS number 1021
BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down 
State/PfxRcd
1.1.1.1         4  1020       4       3        1    0    0 00:00:06        0
10.10.10.1      4  1020       4       3        1    0    0 00:00:06        0
7600#
7600#
7600#sh run | b router bgp
router bgp 1021
  no synchronization
  bgp router-id 10.10.10.2
  bgp log-neighbor-changes
  neighbor 1.1.1.1 remote-as 1020
  neighbor 1.1.1.1 ebgp-multihop 10
  neighbor 1.1.1.1 update-source Loopback0
  neighbor 10.10.10.1 remote-as 1020
  no auto-summary
!
7600#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
7600(config)#router bgp 1021
7600(config-router)#bgp route
7600(config-router)#bgp router-id 2.2.2.2
7600(config-router)#end
7600#
*Jul 15 18:13:34.819: %BGP-5-ADJCHANGE: neighbor 1.1.1.1 Down Router ID 
changed
*Jul 15 18:13:34.819: %BGP-5-ADJCHANGE: neighbor 10.10.10.1 Down Router 
ID changed
*Jul 15 18:13:35.475: %SYS-5-CONFIG_I: Configured from console by console
7600#
7600#
7600#
*Jul 15 18:13:50.159: %BGP-5-ADJCHANGE: neighbor 10.10.10.1 Up
7600#
*Jul 15 18:13:53.287: %BGP-5-ADJCHANGE: neighbor 1.1.1.1 Up
7600#
7600#sh ip bgp sum
Load for five secs: 1%/0%; one minute: 2%; five minutes: 2%
Time source is hardware calendar, *18:13:57.819 EST Wed Jul 15 2009
BGP router identifier 2.2.2.2, local AS number 1021
BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down 
State/PfxRcd
1.1.1.1         4  1020       4       3        1    0    0 00:00:04        0
10.10.10.1      4  1020       4       3        1    0    0 00:00:07        0
7600#



Hope that helps.

Shimol




Jeff Cartier wrote:
> Just checking something that I haven't been able to verify online...
> 
>  
> 
> Changing the bgp router-id manually will require you to clear the bgp
> sessions?  Correct?
> 
>  
> 
> 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 SPfister at dps.k12.oh.us  Wed Jul 15 14:58:45 2009
From: SPfister at dps.k12.oh.us (Steven Pfister)
Date: Wed, 15 Jul 2009 14:58:45 -0400
Subject: [c-nsp] Question on h.323 video calls through a PIX 525	with NAT
In-Reply-To: <530c5af60907151107v52055d1dm86fbe5a0fc962828@mail.gmail.com>
References: <4A5DCB56.9E6F.00B8.0@dps.k12.oh.us>
	<530c5af60907151107v52055d1dm86fbe5a0fc962828@mail.gmail.com>
Message-ID: <4A5DEE9D.9E6F.00B8.0@dps.k12.oh.us>

Yes, tcp/1720 seems to be going to the correct address. The thing I'm wondering now is this... I did the capture on the PIX itself on the outside interface. I've found at least one spot where the internal address for the unit on our side appears. I would have thought the NAT transversal setting on the unit itself would have taken care of this before hitting the PIX. And the capture being on the outside interface... would it be showing the packets before or after inspect has gotten to them. We've got one unit in the same building  as the firewall... hopefully I can duplicated the problem on that.

When I first started getting involved with the video conferencing units here, we weren't able to dial out until I turned the NAT transversal setting on. Then I found out about inspect/fixup and never understood why that setting on the unit would be needed if those commands were on the firewall config. Maybe we should try it without the inspect? No other h.323 traffic normally goes in or out of our network.

Steve Pfister
Technical Coordinator, 
The Office of Information Technology
Dayton Public Schools
115 S. Ludlow St. 
Dayton, OH 45402
 
Office (937) 542-3149
Cell (937) 673-6779
Direct Connect: 137*131747*8
Email spfister at dps.k12.oh.us


>>> Andrew Yourtchenko <ayourtch at gmail.com> 7/15/2009 2:07 PM >>>
Hi Steven,

On Wed, Jul 15, 2009 at 6:28 PM, Steven Pfister<SPfister at dps.k12.oh.us> wrote:
> I'm having some trouble with h.323 (video) calls through a PIX 525 using NAT. We can get incoming calls fine, but not outgoing calls for some reason. My question has to do with 'inspect h323' vs 'fixup protocol h323'. What's the difference between them? The video conferencing unit in question has a NAT transversal option where I can supply an address and mask.I'm wondering if I'm having a NAT transversal problem anyway. Which one would handle the NAT transversal, inspect or fixup? Currently, the PIX config has:
>
>  inspect h323 h225
>  inspect h323 ras
>
> do I need:
>
>  fixup protocol h323 h225 1718-1720
>  fixup protocol h323 h225 1720
>  fixup protocol h323 ras 1718-1719
>
> instead of the inspect commands? In addition to them?
>

"inspect" is the name of the "fixup" from 7.0 onwards - obviously as
time went, some more enhancements were added.

you can enter the "fixup" commands, but they will be autoconverted
into the respective "inspect" under "magic" default policy.

You mention that the inbound call works - so a nice way to debug would
be to grab the pcap on inside+ pcap on the outside and study them in
wireshark for both failing and working scenarios and see what is
different.

The first cutover point is whether you see the tcp/1720 in the
outbound direction or not - if not, or if it is going to the wrong
address, would mean there is an issue related to RAS signaling - else
it's something with the call signaling.

The above can be tested much easier if you are able to make the direct
calls by IP address and the other party can accept such calls without
involving RAS at all - this could be an easy shortcut instead of
staring at the sniffer traces :-) - if the direct call using IP
address works, then you can further investigate RAS. If the inbound
calls to you work, most probably it is going to be the case, but worth
doublechecking.

The inspect in the default configuration normally should be able to
tweak all the embedded IPs both for RAS and call setup, so the
endpoints would not need to have any NAT awareness nor do any special
efforts to detect/traverse the NAT.

Also might be quite useful to have a quick test with another h323
stack if you can - openh323 had a very tweakable client, and ekiga can
do h323 video as well. If those work, again you get one more baseline
to compare the sniffer traces with.

cheers,
andrew


From frnkblk at iname.com  Wed Jul 15 15:00:15 2009
From: frnkblk at iname.com (Frank Bulk)
Date: Wed, 15 Jul 2009 14:00:15 -0500
Subject: [c-nsp] Management interface on 2950T-24 appears to be dead
Message-ID: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAD7DyDYAOXOSqwBGKYalE/EAQAAAAA=@iname.com>

Out of the blue the other day I received a NAGIOS alert about a 2950T-24
being down.  I was off-site, so I called over to the onsite tech who
confirmed that traffic was flowing just fine.  When I checked later, I
couldn't ping or telnet to it.  I went onsite today had no response at the
console port, and even when I pressed the mode button on the left to cycle
through speed, duplex, etc, there was no change.  It's like the management
interface totally died.

 

The unit runs off an inverter, so power should not be an issue.

 

Has anyone seen this before?  Can we trust this box anymore?

 

We plan to power-cycle this evening during a maintenance window.  

 

Frank


From ptimmins at clearrate.com  Wed Jul 15 15:15:27 2009
From: ptimmins at clearrate.com (Paul G. Timmins)
Date: Wed, 15 Jul 2009 15:15:27 -0400
Subject: [c-nsp] IPV6 to IPV4
In-Reply-To: <1e7e04890907151108q19482badq55cea32b28279761@mail.gmail.com>
References: <1e7e04890907151108q19482badq55cea32b28279761@mail.gmail.com>
Message-ID: <B98837F93D40A74D8656EAE7C1F57C5659DB5F@EXCHANGE1.corp.clearrate.net>

Dual Stack.

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Chintan Shah
Sent: Wednesday, July 15, 2009 2:08 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] IPV6 to IPV4

Hi,

The IPV6 host has to communicate to some IPV4 on Internet, I can use
NAT-PT
one but I see that it is now no more recommended.

So, what is best translation mechanism achieve this when I being ISP
provide
IPV6 Internet service to my customer?

 Regards,

CS
_______________________________________________
cisco-nsp mailing list  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  Wed Jul 15 15:24:38 2009
From: oboehmer at cisco.com (Oliver Boehmer (oboehmer))
Date: Wed, 15 Jul 2009 21:24:38 +0200
Subject: [c-nsp] ISIS Mesh group question
In-Reply-To: <a48927f70907141747y4300a4a6sa149172911d2b0c5@mail.gmail.com>
References: <a48927f70907141747y4300a4a6sa149172911d2b0c5@mail.gmail.com>
Message-ID: <70B7A1CCBFA5C649BD562B6D9F7ED78407A7B339@xmb-ams-333.emea.cisco.com>

Ibrahim Abo Zaid <> wrote on Wednesday, July 15, 2009 02:47:

> Hi All
> 
> I have a question about ISIS mesh groups which is used to reduce LSP
> flooding in full-mesh p2p enviroments , that means we lose redudacny
> for sake of LSP flooding reducation hence it affects forwarding and
> traffic is forced to inactive or interfaces in different groups only .
> 
> is that right ?

no, doesn't sound right. mesh-groups only affect LSP flooding within the
area, they don't have an effect of the links when it comes to
SPF/topology, so the final routing table will look the same, whether you
used mesh-groups or not.

	oli

P.S: I've never worked with them and haven't looked at it in detail..

From jmaimon at ttec.com  Wed Jul 15 15:29:16 2009
From: jmaimon at ttec.com (Joe Maimon)
Date: Wed, 15 Jul 2009 15:29:16 -0400
Subject: [c-nsp] ip per-packet load-sharing on single interface
Message-ID: <4A5E2E0C.5050208@ttec.com>

ip per-packet load-sharing on single ethernet interface with multiple 
iBGP routes installed to different nodes on that ethernet interface.

Software router, 12.3

Does not seem to be balancing. Is this supposed to work?


From avayner at cisco.com  Wed Jul 15 16:33:34 2009
From: avayner at cisco.com (Arie Vayner (avayner))
Date: Wed, 15 Jul 2009 22:33:34 +0200
Subject: [c-nsp] ip per-packet load-sharing on single interface
In-Reply-To: <4A5E2E0C.5050208@ttec.com>
References: <4A5E2E0C.5050208@ttec.com>
Message-ID: <78C984F8939D424697B15E4B1C1BB3D7F94EBB@xmb-ams-331.emea.cisco.com>

Joe,

Which platform is it?
Can you share "show ip route" and "show ip cef internal"?

Arie

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Joe Maimon
Sent: Wednesday, July 15, 2009 22:29
To: cisco-nsp
Subject: [c-nsp] ip per-packet load-sharing on single interface

ip per-packet load-sharing on single ethernet interface with multiple 
iBGP routes installed to different nodes on that ethernet interface.

Software router, 12.3

Does not seem to be balancing. Is this supposed to 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 avayner at cisco.com  Wed Jul 15 16:33:34 2009
From: avayner at cisco.com (Arie Vayner (avayner))
Date: Wed, 15 Jul 2009 22:33:34 +0200
Subject: [c-nsp] ip per-packet load-sharing on single interface
In-Reply-To: <4A5E2E0C.5050208@ttec.com>
References: <4A5E2E0C.5050208@ttec.com>
Message-ID: <78C984F8939D424697B15E4B1C1BB3D7F94EBD@xmb-ams-331.emea.cisco.com>

Joe,

Which platform is it?
Can you share "show ip route" and "show ip cef internal"?

Arie

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Joe Maimon
Sent: Wednesday, July 15, 2009 22:29
To: cisco-nsp
Subject: [c-nsp] ip per-packet load-sharing on single interface

ip per-packet load-sharing on single ethernet interface with multiple 
iBGP routes installed to different nodes on that ethernet interface.

Software router, 12.3

Does not seem to be balancing. Is this supposed to 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 jmaimon at ttec.com  Wed Jul 15 16:52:34 2009
From: jmaimon at ttec.com (Joe Maimon)
Date: Wed, 15 Jul 2009 16:52:34 -0400
Subject: [c-nsp] ip per-packet load-sharing on single interface
In-Reply-To: <78C984F8939D424697B15E4B1C1BB3D7F94EBB@xmb-ams-331.emea.cisco.com>
References: <4A5E2E0C.5050208@ttec.com>
	<78C984F8939D424697B15E4B1C1BB3D7F94EBB@xmb-ams-331.emea.cisco.com>
Message-ID: <4A5E4192.2010409@ttec.com>

c7100-jk9o3s-mz.123-12e.bin

Raw output sent direct.

Arie Vayner (avayner) wrote:
> Joe,
> 
> Which platform is it?
> Can you share "show ip route" and "show ip cef internal"?
> 
> Arie
> 
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Joe Maimon
> Sent: Wednesday, July 15, 2009 22:29
> To: cisco-nsp
> Subject: [c-nsp] ip per-packet load-sharing on single interface
> 
> ip per-packet load-sharing on single ethernet interface with multiple 
> iBGP routes installed to different nodes on that ethernet interface.
> 
> Software router, 12.3
> 
> Does not seem to be balancing. Is this supposed to 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 ayourtch at gmail.com  Wed Jul 15 17:01:29 2009
From: ayourtch at gmail.com (Andrew Yourtchenko)
Date: Wed, 15 Jul 2009 23:01:29 +0200
Subject: [c-nsp] Question on h.323 video calls through a PIX 525 with NAT
In-Reply-To: <4A5DEE9D.9E6F.00B8.0@dps.k12.oh.us>
References: <4A5DCB56.9E6F.00B8.0@dps.k12.oh.us>
	<530c5af60907151107v52055d1dm86fbe5a0fc962828@mail.gmail.com>
	<4A5DEE9D.9E6F.00B8.0@dps.k12.oh.us>
Message-ID: <530c5af60907151401w1c024e86td1fff67f84507e20@mail.gmail.com>

On Wed, Jul 15, 2009 at 8:58 PM, Steven Pfister<SPfister at dps.k12.oh.us> wrote:
> Yes, tcp/1720 seems to be going to the correct address. The thing I'm wondering now is this... I did the capture on the PIX itself on the outside interface. I've found at least one spot where the internal address for the unit on our side appears.

If the rfc1918 address is seen on the outside (presumably in one of
the openLogicalChannel/openLogicalChannelAck exchanges?) - then it
would be a very good reason for the media streams to not reach you
from the remote end.

>I would have thought the NAT transversal setting on the unit itself would have taken care of this before hitting the PIX. And the capture being on the outside interface... would it be showing the packets before or after inspect has gotten to them.

capture is in the packet path shortly before putting the packet onto
the low-level driver for transmission. So, it's after all the inspect
work is already don (if we're talking of the inside->outside). For the
outside->inside, it's indeed the opposite - very early in the packet
processing, so before the inspect.

>We've got one unit in the same building  as the firewall... hopefully I can >duplicated the problem on that.

ok. this indeed could be useful too.

>
> When I first started getting involved with the video conferencing units here, we >weren't able to dial out until I turned the NAT transversal setting on. Then I

hmm I thought it was indeed the outbound calls that had difficulties
now ? Or those are two different failures of a different degree ?

Anyway, normally inspect should take care of the translating the
embedded addresses.

>found out about inspect/fixup and never understood why that setting on the unit >would be needed if those commands were on the firewall config. Maybe we >should try it without the inspect? No other h.323 traffic normally goes in or out >of our network.

Yes - it's either/or, so if you don't have any other H.323 traffic,
then indeed give nat traversal a shot without the h323 inspects
enabled on the PIX.

cheers,
andrew

>
> Steve Pfister
> Technical Coordinator,
> The Office of Information Technology
> Dayton Public Schools
> 115 S. Ludlow St.
> Dayton, OH 45402
>
> Office (937) 542-3149
> Cell (937) 673-6779
> Direct Connect: 137*131747*8
> Email spfister at dps.k12.oh.us
>
>
>>>> Andrew Yourtchenko <ayourtch at gmail.com> 7/15/2009 2:07 PM >>>
> Hi Steven,
>
> On Wed, Jul 15, 2009 at 6:28 PM, Steven Pfister<SPfister at dps.k12.oh.us> wrote:
>> I'm having some trouble with h.323 (video) calls through a PIX 525 using NAT. We can get incoming calls fine, but not outgoing calls for some reason. My question has to do with 'inspect h323' vs 'fixup protocol h323'. What's the difference between them? The video conferencing unit in question has a NAT transversal option where I can supply an address and mask.I'm wondering if I'm having a NAT transversal problem anyway. Which one would handle the NAT transversal, inspect or fixup? Currently, the PIX config has:
>>
>>  inspect h323 h225
>>  inspect h323 ras
>>
>> do I need:
>>
>>  fixup protocol h323 h225 1718-1720
>>  fixup protocol h323 h225 1720
>>  fixup protocol h323 ras 1718-1719
>>
>> instead of the inspect commands? In addition to them?
>>
>
> "inspect" is the name of the "fixup" from 7.0 onwards - obviously as
> time went, some more enhancements were added.
>
> you can enter the "fixup" commands, but they will be autoconverted
> into the respective "inspect" under "magic" default policy.
>
> You mention that the inbound call works - so a nice way to debug would
> be to grab the pcap on inside+ pcap on the outside and study them in
> wireshark for both failing and working scenarios and see what is
> different.
>
> The first cutover point is whether you see the tcp/1720 in the
> outbound direction or not - if not, or if it is going to the wrong
> address, would mean there is an issue related to RAS signaling - else
> it's something with the call signaling.
>
> The above can be tested much easier if you are able to make the direct
> calls by IP address and the other party can accept such calls without
> involving RAS at all - this could be an easy shortcut instead of
> staring at the sniffer traces :-) - if the direct call using IP
> address works, then you can further investigate RAS. If the inbound
> calls to you work, most probably it is going to be the case, but worth
> doublechecking.
>
> The inspect in the default configuration normally should be able to
> tweak all the embedded IPs both for RAS and call setup, so the
> endpoints would not need to have any NAT awareness nor do any special
> efforts to detect/traverse the NAT.
>
> Also might be quite useful to have a quick test with another h323
> stack if you can - openh323 had a very tweakable client, and ekiga can
> do h323 video as well. If those work, again you get one more baseline
> to compare the sniffer traces with.
>
> cheers,
> andrew
>
>

From gsgranados at comcast.net  Wed Jul 15 17:52:30 2009
From: gsgranados at comcast.net (Scott Granados)
Date: Wed, 15 Jul 2009 14:52:30 -0700
Subject: [c-nsp] adding a port forward on a Cisco Pix
Message-ID: <061101ca0596$91984830$0808120a@am.thmulti.com>

Hi, so I've started working with the Pix and am trying to forward port 80 
and 443 in from an outside facing address to a 10.x space inside.  I have 
two basic interfaces (outside and inside) and am running Pix 6.3 for 
firmware.

I was thinking the following line would work but wasn't sure if I formatted 
it correctly.

static (outside,inside) tcp general-internet-rtr-svc-nat 80 inside-ip-object 
80 netmask 255.255.255.255 0 0

general-internet-rtr-svc-nat is an object group name that contains a 
network-object-host with the outside static IP defined.

Is this more or less correct?  Should I invert the address objects or are 
they in the proper order?  Any basic pointers or pointers to good examples 
would be appreciated.

Thank you
Scott


From rodunn at cisco.com  Wed Jul 15 17:53:43 2009
From: rodunn at cisco.com (Rodney Dunn)
Date: Wed, 15 Jul 2009 17:53:43 -0400
Subject: [c-nsp] ip per-packet load-sharing on single interface
In-Reply-To: <78C984F8939D424697B15E4B1C1BB3D7F94EBD@xmb-ams-331.emea.cisco.com>
References: <4A5E2E0C.5050208@ttec.com>
	<78C984F8939D424697B15E4B1C1BB3D7F94EBD@xmb-ams-331.emea.cisco.com>
Message-ID: <20090715215343.GB25797@rtp-cse-489.cisco.com>

Turn on 'ip cef account load per pre'
and send the 'sh ip cef internal' for the prefix you are going towards.

On Wed, Jul 15, 2009 at 10:33:34PM +0200, Arie Vayner (avayner) wrote:
> Joe,
> 
> Which platform is it?
> Can you share "show ip route" and "show ip cef internal"?
> 
> Arie
> 
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Joe Maimon
> Sent: Wednesday, July 15, 2009 22:29
> To: cisco-nsp
> Subject: [c-nsp] ip per-packet load-sharing on single interface
> 
> ip per-packet load-sharing on single ethernet interface with multiple 
> iBGP routes installed to different nodes on that ethernet interface.
> 
> Software router, 12.3
> 
> Does not seem to be balancing. Is this supposed to 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 David at hughes.com.au  Wed Jul 15 18:14:30 2009
From: David at hughes.com.au (David Hughes)
Date: Thu, 16 Jul 2009 08:14:30 +1000
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <Pine.LNX.4.61.0907140924470.6312@soloth.lewis.org>
References: <9DE4AA6876D44B62B87C475B2AFE5514@au.didata.local>
	<a1873f1f0907131438m3f0b4c70r82a953a29042b6d7@mail.gmail.com>
	<1247524340.4661.65.camel@abehat.net.rm.dk>
	<20090714084503.GA15753@lboro.ac.uk>
	<d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>
	<Pine.LNX.4.61.0907140924470.6312@soloth.lewis.org>
Message-ID: <CCFD3967-7802-4F58-ACAA-40A6DF0E6E43@Hughes.com.au>


On 14/07/2009, at 11:26 PM, Jon Lewis wrote:

>>
>
> But isn't that the whole point of MST?  Most of what I've read about  
> it talks about doing setups where you only have 2 or 3 instances,  
> with all your vlans in the 2nd and or 3rd instance.

Yup.  In a DC / Hosting environment it's a must.  Particularly if you  
have large VMWare type clusters where there can be 100's of unique  
vlans that need to be presented to all cluster nodes.  Can't do that  
with any form of Per Vlan STP on top-of-rack or blade-chassis  
switches.  In a classic "dual attached L2 access layer" there are only  
2 possible paths so 2 MST instances does the job.  Having more STP  
instances than paths to the root bridge adds no value at all.


David
...


From david at hughes.com.au  Wed Jul 15 18:33:28 2009
From: david at hughes.com.au (David Hughes)
Date: Thu, 16 Jul 2009 08:33:28 +1000
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <Pine.LNX.4.61.0907141355280.6312@soloth.lewis.org>
References: <9DE4AA6876D44B62B87C475B2AFE5514@au.didata.local>
	<a1873f1f0907131438m3f0b4c70r82a953a29042b6d7@mail.gmail.com>
	<1247524340.4661.65.camel@abehat.net.rm.dk>
	<20090714084503.GA15753@lboro.ac.uk>
	<d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>
	<Pine.LNX.4.61.0907140924470.6312@soloth.lewis.org>
	<20090714141529.GN290@greenie.muc.de>
	<Pine.LNX.4.61.0907141101240.6312@soloth.lewis.org>
	<d6966e4b0907140835u597c7ae3l3991ba636ae93bcf@mail.gmail.com>
	<Pine.LNX.4.61.0907141139180.6312@soloth.lewis.org>
	<9e246b4d0907141020v4189c867mcb5e8208454fbc4d@mail.gmail.com>
	<Pine.LNX.4.61.0907141355280.6312@soloth.lewis.org>
Message-ID: <A85280AE-4C62-4F53-B404-D616837307C8@hughes.com.au>


On 15/07/2009, at 4:01 AM, Jon Lewis wrote:

> The cisco examples I saw say to leave MST0 empty and use MST1 and  
> MST2 for VLANs.

Good option.  Only non-MST speakers will end up in instance 0.  Spread  
your vlans over instance 1 and 2 (and root those instances  
appropriately) and all will be good.  We use blocks of 50 vlans for  
the "load sharing" which gives us what we need and keeps the config  
small.

> Will adding new VLANs to an MST instance disrupt traffic flow for  
> other VLANs in that MST instance?
>
> The topology I have is actually 2 core switches with a bunch of edge  
> switches redundantly uplinked to both cores.

Not sure.  We pre-configure the MST vlan mappings (see below) and just  
prune vlans on the trunks.  We run the same MST config on every switch  
in the network and will worry about changing the vlan mappings when we  
have more than 2000 vlans in a single layer 2 domain.  I can't see  
that being a problem for any of the L2's at any of our datacentres for  
a while.  For us, once we got MST in place it's been set-and-forget.   
It's worked flawlessly.

---
spanning-tree mst configuration
instance 1 vlan 1-49, 100-149, 200-249, 300-349, 400-449, 500-549,  
600-649
instance 1 vlan 700-749, 800-849, 900-949, 1000-1049, 1100-1149,  
1200-1249
instance 1 vlan 1300-1349, 1400-1449, 1500-1549, 1600-1649, 1700-1749
instance 1 vlan 1800-1849, 1900-1949
instance 2 vlan 50-99, 150-199, 250-299, 350-399, 450-499, 550-599,  
650-699
instance 2 vlan 750-799, 850-899, 950-999, 1050-1099, 1150-1199,  
1250-1299
instance 2 vlan 1350-1399, 1450-1499, 1550-1599, 1650-1699, 1750-1799
instance 2 vlan 1850-1899, 1950-1999
!
spanning-tree mst 0-1 priority 8192
spanning-tree mst 2 priority 16384
---


Thanks

David
...

From David at hughes.com.au  Wed Jul 15 18:28:33 2009
From: David at hughes.com.au (David Hughes)
Date: Thu, 16 Jul 2009 08:28:33 +1000
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <d6966e4b0907141122g714a3e8bwfbee02edca4a80a8@mail.gmail.com>
References: <9DE4AA6876D44B62B87C475B2AFE5514@au.didata.local>
	<20090714084503.GA15753@lboro.ac.uk>
	<d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>
	<Pine.LNX.4.61.0907140924470.6312@soloth.lewis.org>
	<20090714141529.GN290@greenie.muc.de>
	<Pine.LNX.4.61.0907141101240.6312@soloth.lewis.org>
	<d6966e4b0907140835u597c7ae3l3991ba636ae93bcf@mail.gmail.com>
	<Pine.LNX.4.61.0907141139180.6312@soloth.lewis.org>
	<9e246b4d0907141020v4189c867mcb5e8208454fbc4d@mail.gmail.com>
	<Pine.LNX.4.61.0907141355280.6312@soloth.lewis.org>
	<d6966e4b0907141122g714a3e8bwfbee02edca4a80a8@mail.gmail.com>
Message-ID: <50CE408B-F192-4F42-B7E9-2048B50CD9F0@Hughes.com.au>


On 15/07/2009, at 4:22 AM, Geoffrey Pendery wrote:

>> Will adding new VLANs to an MST instance disrupt traffic flow for  
>> other
>> VLANs in that MST instance?
>
> Yes.  We've verified this.
> A trunk port carrying only VLAN 30, or even an access port carrying
> only VLAN 30.
> VLAN 30 is in instance 2.  You go into config mode and add VLAN 50 to
> instance 2 (or remove it from instance 2)
> The port, be it access or trunk, goes to blocking, learning,  
> forwarding.

But MST implements Rapid-STP in each instance (except 0 naturally) so  
even if the config change did recalc the tree it'll be sub-second.   
Not that any STP recalc is a good thing but at least it'll be over and  
done with quickly.


David
...

From David at Hughes.com.au  Wed Jul 15 19:16:35 2009
From: David at Hughes.com.au (David Hughes)
Date: Thu, 16 Jul 2009 09:16:35 +1000
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <4A5D005A.5030303@imperial.ac.uk>
References: <9DE4AA6876D44B62B87C475B2AFE5514@au.didata.local>
	<20090714084503.GA15753@lboro.ac.uk>	<d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>	<Pine.LNX.4.61.0907140924470.6312@soloth.lewis.org>	<20090714141529.GN290@greenie.muc.de>	<Pine.LNX.4.61.0907141101240.6312@soloth.lewis.org>
	<d6966e4b0907140835u597c7ae3l3991ba636ae93bcf@mail.gmail.com>
	<Pine.LNX.4.61.0907141139180.6312@soloth.lewis.org>
	<9e246b4d0907141020v4189c867mcb5e8208454fbc4d@mail.gmail.com>
	<Pine.LNX.4.61.0907141355280.6312@soloth.lewis.org>	<d6966e4b0907141122g714a3e8bwfbee02edca4a80a8@mail.gmail.com>
	<Pine.LNX.4.61.0907141451100.6312@soloth.lewis.org>
	<4A5D005A.5030303@imperial.ac.uk>
Message-ID: <EA1C4140-2931-4CD4-A3AA-3DE6C07FD78D@Hughes.com.au>


On 15/07/2009, at 8:02 AM, Phil Mayers wrote:

> R-PVST + manual VLAN management works like a charm here.

..... works like a charm until it doesn't.   Any PV based STP will not  
work in a dense server virtualisation environment.  So these days  
that's basically any hosting provider.  MST is your only choice and if  
you pre-provision your vlan/instance mappings it works fine.  Been  
running it without a single issue for ages.


David
...

From mb at adv.gcomm.com.au  Wed Jul 15 21:28:06 2009
From: mb at adv.gcomm.com.au (mb at adv.gcomm.com.au)
Date: Thu, 16 Jul 2009 11:28:06 +1000
Subject: [c-nsp] MST config on single 3560
In-Reply-To: <7100ed370907150130x5609e29aqf61300e8f98f75ac@mail.gmail.com>
References: <20090714145752.qwkjhv749hwswwo0@webmail.datafx.com.au>
	<7100ed370907150130x5609e29aqf61300e8f98f75ac@mail.gmail.com>
Message-ID: <20090716112806.09vy5bynubac80k4@webmail.datafx.com.au>

Quoting Manu Chao <linux.yahoo at gmail.com>:

> the standard is ieee 802.1s
>
> don't change anything to your interface config
> mst instance and vlan association is a global config
>
> if you planned to migrate to mst on your side, make sure you will migrate to
> mst with your client ;)
>

Thanks for the reply.

As we have single 3560's that do not participate in VTP (vtp mode 
transparent), would I be able to have a config similar to this(On each 
3560 in each POP):

spanning-tree mode mst
spanning-tree mst configuration
name LOC_A
revision 10
instance 0 : Vlan 1-4094
spanning-tree mst 0 root primary

And maintain the existing port configs?

If we are getting close to reaching port capacity on each 3560, we will 
be upgrading to 4500's.




-------------------------------------------------------------------------
This e-mail was sent via GCOMM WebMail http://www.gcomm.com.au/



From td_miles at yahoo.com  Wed Jul 15 21:52:46 2009
From: td_miles at yahoo.com (Tony)
Date: Wed, 15 Jul 2009 18:52:46 -0700 (PDT)
Subject: [c-nsp] adding a port forward on a Cisco Pix
In-Reply-To: <061101ca0596$91984830$0808120a@am.thmulti.com>
Message-ID: <961068.90710.qm@web110101.mail.gq1.yahoo.com>


Hi Scott,

For your NAT to work you need to things:
1. static command
2. Access-list

> static (outside,inside) tcp general-internet-rtr-svc-nat 80 inside-ip-object 80 netmask 255.255.255.255 0 0

You have it round the wrong way, you would need:

  static (inside,outside) tcp outside_ip outside_port inside_ip inside_port

It's confusing but the bit in brackets (for the interfaces) has inside first and outside second and then when you specify the IP addresses and ports you have outside first, then inside second.

And then you would need an ACL like this:

  access-list 101 permit tcp any host outside_ip outside_port

And then you need to apply the ACL to inbound traffic on the outside interface:

  access-group 101 in interface outside


I don't know about using object groups to specify the IP addresses, it should work as long as you've got it correct. I would try with putting the actual IP addresses in the commands and then once you know it works you can change them to objects.

You can find a list of PIX configuration examples here:
http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/prod_configuration_examples_list.html
http://tinyurl.com/3o7gk

One specifically for NAT is:
http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a0080094aad.shtml
http://tinyurl.com/yqeap

Make sure you follow which parts are for earlier PIX versions and your version. The earlier versions use the "conduit" command instead of an access list.


regards,
Tony

--- On Thu, 16/7/09, Scott Granados <gsgranados at comcast.net> wrote:

> From: Scott Granados <gsgranados at comcast.net>
> Subject: [c-nsp] adding a port forward on a Cisco Pix
> To: cisco-nsp at puck.nether.net
> Date: Thursday, 16 July, 2009, 7:52 AM
> Hi, so I've started working with the
> Pix and am trying to forward port 80 and 443 in from an
> outside facing address to a 10.x space inside.? I have
> two basic interfaces (outside and inside) and am running Pix
> 6.3 for firmware.
> 
> I was thinking the following line would work but wasn't
> sure if I formatted it correctly.
> 
> static (outside,inside) tcp general-internet-rtr-svc-nat 80
> inside-ip-object 80 netmask 255.255.255.255 0 0
> 
> general-internet-rtr-svc-nat is an object group name that
> contains a network-object-host with the outside static IP
> defined.
> 
> Is this more or less correct?? Should I invert the
> address objects or are they in the proper order?? Any
> basic pointers or pointers to good examples would be
> appreciated.
> 
> Thank you
> Scott
> 
>


      


From rodunn at cisco.com  Wed Jul 15 21:59:04 2009
From: rodunn at cisco.com (Rodney Dunn)
Date: Wed, 15 Jul 2009 21:59:04 -0400
Subject: [c-nsp] MLPPP throughput
In-Reply-To: <Pine.LNX.4.63.0907150959150.28268@charmed.internetsolver.com>
References: <Pine.LNX.4.63.0907150959150.28268@charmed.internetsolver.com>
Message-ID: <20090716015904.GD27087@rtp-cse-489.cisco.com>

I bet your out of order is getting so bad you are dropping the packets.

I'm not a PPPox expert...but could you create 7 dialers and do CEF
per packet over them?

On Wed, Jul 15, 2009 at 10:07:24AM -0500, Dave Weis wrote:
> 
> I'm bringing up a MLPPP PPPoA bundle with 4 7-meg DSL lines. It had worked 
> fine with only 2 lines in the bundle and provided the full expected speed. 
> Adding the next two lines didn't provide an increase in speed, it actually 
> might have decreased a bit. It tops out at around 10 megabits with 4 links 
> in the bundle.
> 
> The hardware on the customer side is a 3745 running 12.4(4)T1. It has 4 
> WIC-1ADSL's installed. The config on the ADSL interfaces are all 
> identical:
> 
> interface ATM0/0
>  no ip address
>  no atm ilmi-keepalive
>  dsl operating-mode auto
>  hold-queue 224 in
>  pvc 0/32
>   encapsulation aal5mux ppp dialer
>   dialer pool-member 1
>  !
> 
> interface Dialer0
>  ip address negotiated
>  no ip proxy-arp
>  encapsulation ppp
>  dialer pool 1
>  dialer vpdn
>  dialer-group 1
>  ppp pap sent-username <removed>
>  ppp link reorders
>  ppp multilink
>  ppp multilink fragment disable
> !
> 
> We've tried it with and without the reorders and fragment changes in the 
> config.
> 
> The server side is a 7206 with an NPE-G1. We're not topping out the 
> processor on either side during transfers.
> 
> The multilink bundle shows a lot of discards and reorders. This is after a 
> reset and downloading less than a gig of data on the client:
> 
> Virtual-Access3, bundle name is isprouter
>   Endpoint discriminator is isprouter
>   Bundle up for 01:15:43, total bandwidth 400000, load 1/255
>   Receive buffer limit 48768 bytes, frag timeout 1000 ms
>   Using relaxed lost fragment detection algorithm.
>   Dialer interface is Dialer0
>     0/0 fragments/bytes in reassembly list
>     242 lost fragments, 1237543 reordered
>     29169/15194784 discarded fragments/bytes, 16700 lost received
>     0x1F9178 received sequence, 0x6A517 sent sequence
>   Member links: 4 (max not set, min not set)
>     Vi4, since 01:15:43, unsequenced
>     PPPoATM link, ATM PVC 0/32 on ATM0/0
>     Packets in ATM PVC Holdq: 0, Particles in ATM PVC Tx Ring: 0
>     Vi6, since 01:15:43, unsequenced
>     PPPoATM link, ATM PVC 0/32 on ATM1/0
>     Packets in ATM PVC Holdq: 0, Particles in ATM PVC Tx Ring: 0
>     Vi5, since 01:15:43, unsequenced
>     PPPoATM link, ATM PVC 0/32 on ATM0/2
>     Packets in ATM PVC Holdq: 0, Particles in ATM PVC Tx Ring: 0
>     Vi2, since 01:15:43, unsequenced
>     PPPoATM link, ATM PVC 0/32 on ATM0/1
>     Packets in ATM PVC Holdq: 0, Particles in ATM PVC Tx Ring: 0
> No inactive multilink interfaces
> 
> 
> Any ideas to get this closer to 20+ megs?
> 
> THanks
> dave
> 
> 
> 
> 
> -- 
> Dave Weis
> djweis at internetsolver.com
> http://www.internetsolver.com/
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

From rodunn at cisco.com  Wed Jul 15 22:19:55 2009
From: rodunn at cisco.com (Rodney Dunn)
Date: Wed, 15 Jul 2009 22:19:55 -0400
Subject: [c-nsp] MLPPP throughput
In-Reply-To: <20090716015904.GD27087@rtp-cse-489.cisco.com>
References: <Pine.LNX.4.63.0907150959150.28268@charmed.internetsolver.com>
	<20090716015904.GD27087@rtp-cse-489.cisco.com>
Message-ID: <20090716021955.GI27087@rtp-cse-489.cisco.com>

Depending on your apps ability to handle out of order frames on the end
stations of course.

On Wed, Jul 15, 2009 at 09:59:04PM -0400, Rodney Dunn wrote:
> I bet your out of order is getting so bad you are dropping the packets.
> 
> I'm not a PPPox expert...but could you create 7 dialers and do CEF
> per packet over them?
> 
> On Wed, Jul 15, 2009 at 10:07:24AM -0500, Dave Weis wrote:
> > 
> > I'm bringing up a MLPPP PPPoA bundle with 4 7-meg DSL lines. It had worked 
> > fine with only 2 lines in the bundle and provided the full expected speed. 
> > Adding the next two lines didn't provide an increase in speed, it actually 
> > might have decreased a bit. It tops out at around 10 megabits with 4 links 
> > in the bundle.
> > 
> > The hardware on the customer side is a 3745 running 12.4(4)T1. It has 4 
> > WIC-1ADSL's installed. The config on the ADSL interfaces are all 
> > identical:
> > 
> > interface ATM0/0
> >  no ip address
> >  no atm ilmi-keepalive
> >  dsl operating-mode auto
> >  hold-queue 224 in
> >  pvc 0/32
> >   encapsulation aal5mux ppp dialer
> >   dialer pool-member 1
> >  !
> > 
> > interface Dialer0
> >  ip address negotiated
> >  no ip proxy-arp
> >  encapsulation ppp
> >  dialer pool 1
> >  dialer vpdn
> >  dialer-group 1
> >  ppp pap sent-username <removed>
> >  ppp link reorders
> >  ppp multilink
> >  ppp multilink fragment disable
> > !
> > 
> > We've tried it with and without the reorders and fragment changes in the 
> > config.
> > 
> > The server side is a 7206 with an NPE-G1. We're not topping out the 
> > processor on either side during transfers.
> > 
> > The multilink bundle shows a lot of discards and reorders. This is after a 
> > reset and downloading less than a gig of data on the client:
> > 
> > Virtual-Access3, bundle name is isprouter
> >   Endpoint discriminator is isprouter
> >   Bundle up for 01:15:43, total bandwidth 400000, load 1/255
> >   Receive buffer limit 48768 bytes, frag timeout 1000 ms
> >   Using relaxed lost fragment detection algorithm.
> >   Dialer interface is Dialer0
> >     0/0 fragments/bytes in reassembly list
> >     242 lost fragments, 1237543 reordered
> >     29169/15194784 discarded fragments/bytes, 16700 lost received
> >     0x1F9178 received sequence, 0x6A517 sent sequence
> >   Member links: 4 (max not set, min not set)
> >     Vi4, since 01:15:43, unsequenced
> >     PPPoATM link, ATM PVC 0/32 on ATM0/0
> >     Packets in ATM PVC Holdq: 0, Particles in ATM PVC Tx Ring: 0
> >     Vi6, since 01:15:43, unsequenced
> >     PPPoATM link, ATM PVC 0/32 on ATM1/0
> >     Packets in ATM PVC Holdq: 0, Particles in ATM PVC Tx Ring: 0
> >     Vi5, since 01:15:43, unsequenced
> >     PPPoATM link, ATM PVC 0/32 on ATM0/2
> >     Packets in ATM PVC Holdq: 0, Particles in ATM PVC Tx Ring: 0
> >     Vi2, since 01:15:43, unsequenced
> >     PPPoATM link, ATM PVC 0/32 on ATM0/1
> >     Packets in ATM PVC Holdq: 0, Particles in ATM PVC Tx Ring: 0
> > No inactive multilink interfaces
> > 
> > 
> > Any ideas to get this closer to 20+ megs?
> > 
> > THanks
> > dave
> > 
> > 
> > 
> > 
> > -- 
> > Dave Weis
> > djweis at internetsolver.com
> > http://www.internetsolver.com/
> > 
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

From ross at kallisti.us  Wed Jul 15 23:27:12 2009
From: ross at kallisti.us (Ross Vandegrift)
Date: Wed, 15 Jul 2009 23:27:12 -0400
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <20090714150036.GP290@greenie.muc.de>
References: <9DE4AA6876D44B62B87C475B2AFE5514@au.didata.local>
	<a1873f1f0907131438m3f0b4c70r82a953a29042b6d7@mail.gmail.com>
	<1247524340.4661.65.camel@abehat.net.rm.dk>
	<20090714084503.GA15753@lboro.ac.uk>
	<d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>
	<Pine.LNX.4.61.0907140924470.6312@soloth.lewis.org>
	<d6966e4b0907140724n61be11f5ra851690ceaabbd93@mail.gmail.com>
	<20090714150036.GP290@greenie.muc.de>
Message-ID: <20090716032712.GA2111@kallisti.us>

On Tue, Jul 14, 2009 at 05:00:36PM +0200, Gert Doering wrote:
> <rant>
> MST is what comes out if vendor committees get together, and agree to
> implement the least common determinator in the most complicated way.
> </rant>

I completely disagree - it's what comes out of solving problems
related to the LAN - the LOCAL area network.  In virtualized LANs,
there's typically only a few possible physical topologies that can
exist.  MST seeks to exploit this to lower the amount of processing
power that is required.

My employer is a datacenter service provider and this holds in our
scenario - there's only ever two possible physical topologies.  Two
distribution routers each have a connection to hundreds of access
switches.  We started out by mapping what VLANs went to which physical
topology and we're done forever.  It's great -  we get redundancy
everywhere and mostly even load balancing.

If your network doesn't behave like this, then you need a better
control plane than MST can provide.  But don't complain about standards
bodies just because they solved a problem that doesn't concern you.

-- 
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 giles.woolston at paradise.net.nz  Thu Jul 16 00:18:58 2009
From: giles.woolston at paradise.net.nz (Giles Woolston)
Date: Thu, 16 Jul 2009 16:18:58 +1200
Subject: [c-nsp] Logging event link-status 6509
Message-ID: <4A5EAA32.70303@paradise.net.nz>

Hi Guys,

I'm seeing an issue on some of our 6509's where no matter what I do I 
can't disable the event link status up/down appearing in the logs. 'no 
logging event link-status' appears in the interface config but does 
nothing. 6509 with sup 720 and s72033-pk9sv-mz.122-18.SXD6.bin as the 
image. Any commands you know of that might conflict with these settings?

Any other suggestions?

Thanks,

Giles


__________ Information from ESET NOD32 Antivirus, version of virus signature database 4248 (20090716) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com



From jof at thejof.com  Thu Jul 16 00:30:08 2009
From: jof at thejof.com (Jonathan Lassoff)
Date: Wed, 15 Jul 2009 21:30:08 -0700
Subject: [c-nsp] Logging event link-status 6509
In-Reply-To: <4A5EAA32.70303@paradise.net.nz>
References: <4A5EAA32.70303@paradise.net.nz>
Message-ID: <1247718462-sup-3180@sfo.thejof.com>

Excerpts from Giles Woolston's message of Wed Jul 15 21:18:58 -0700 2009:
> I'm seeing an issue on some of our 6509's where no matter what I do I 
> can't disable the event link status up/down appearing in the logs. 'no 
> logging event link-status' appears in the interface config but does 
> nothing. 6509 with sup 720 and s72033-pk9sv-mz.122-18.SXD6.bin as the 
> image. Any commands you know of that might conflict with these settings?
> 
> Any other suggestions?

There's also a global "logging event link-status [ boot | default ]"
option.

Cheers,
jonathan

From giles.woolston at paradise.net.nz  Thu Jul 16 01:35:51 2009
From: giles.woolston at paradise.net.nz (Giles Woolston)
Date: Thu, 16 Jul 2009 17:35:51 +1200
Subject: [c-nsp] Logging event link-status 6509
In-Reply-To: <1247718462-sup-3180@sfo.thejof.com>
References: <4A5EAA32.70303@paradise.net.nz>
	<1247718462-sup-3180@sfo.thejof.com>
Message-ID: <4A5EBC37.6010606@paradise.net.nz>

Yea, as I understand that makes the default value enabled, but you 
should still be able to disable on a per interface basis. Which I can do 
on other 6500's but not these ones. The boot option suppresses link 
state messages during a reload/bootup but I need to disable logging for 
specific interfaces permanently.

Appreciate the suggestion though.

Giles

Jonathan Lassoff wrote:
> Excerpts from Giles Woolston's message of Wed Jul 15 21:18:58 -0700 2009:
>   
>> I'm seeing an issue on some of our 6509's where no matter what I do I 
>> can't disable the event link status up/down appearing in the logs. 'no 
>> logging event link-status' appears in the interface config but does 
>> nothing. 6509 with sup 720 and s72033-pk9sv-mz.122-18.SXD6.bin as the 
>> image. Any commands you know of that might conflict with these settings?
>>
>> Any other suggestions?
>>     
>
> There's also a global "logging event link-status [ boot | default ]"
> option.
>
> Cheers,
> jonathan
>
> __________ Information from ESET NOD32 Antivirus, version of virus signature database 4248 (20090716) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>
>
>   



__________ Information from ESET NOD32 Antivirus, version of virus signature database 4248 (20090716) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com



From gert at greenie.muc.de  Thu Jul 16 02:48:56 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Thu, 16 Jul 2009 08:48:56 +0200
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <EA1C4140-2931-4CD4-A3AA-3DE6C07FD78D@Hughes.com.au>
References: <20090714141529.GN290@greenie.muc.de>
	<Pine.LNX.4.61.0907141101240.6312@soloth.lewis.org>
	<d6966e4b0907140835u597c7ae3l3991ba636ae93bcf@mail.gmail.com>
	<Pine.LNX.4.61.0907141139180.6312@soloth.lewis.org>
	<9e246b4d0907141020v4189c867mcb5e8208454fbc4d@mail.gmail.com>
	<Pine.LNX.4.61.0907141355280.6312@soloth.lewis.org>
	<d6966e4b0907141122g714a3e8bwfbee02edca4a80a8@mail.gmail.com>
	<Pine.LNX.4.61.0907141451100.6312@soloth.lewis.org>
	<4A5D005A.5030303@imperial.ac.uk>
	<EA1C4140-2931-4CD4-A3AA-3DE6C07FD78D@Hughes.com.au>
Message-ID: <20090716064856.GE290@greenie.muc.de>

Hi,

On Thu, Jul 16, 2009 at 09:16:35AM +1000, David Hughes wrote:
> On 15/07/2009, at 8:02 AM, Phil Mayers wrote:
> 
> >R-PVST + manual VLAN management works like a charm here.
> 
> ..... works like a charm until it doesn't.   Any PV based STP will not  
> work in a dense server virtualisation environment.  So these days  
> that's basically any hosting provider.  

Please don't tell that to our hosting people.  Otherwise our PVSTP will
be scared and break.

Well, of course it won't work if you use a switch that has a 64-instance
limit.  So don't...

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/20090716/4503f5cc/attachment.bin>

From gert at greenie.muc.de  Thu Jul 16 02:51:47 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Thu, 16 Jul 2009 08:51:47 +0200
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <20090716032712.GA2111@kallisti.us>
References: <9DE4AA6876D44B62B87C475B2AFE5514@au.didata.local>
	<a1873f1f0907131438m3f0b4c70r82a953a29042b6d7@mail.gmail.com>
	<1247524340.4661.65.camel@abehat.net.rm.dk>
	<20090714084503.GA15753@lboro.ac.uk>
	<d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>
	<Pine.LNX.4.61.0907140924470.6312@soloth.lewis.org>
	<d6966e4b0907140724n61be11f5ra851690ceaabbd93@mail.gmail.com>
	<20090714150036.GP290@greenie.muc.de>
	<20090716032712.GA2111@kallisti.us>
Message-ID: <20090716065147.GF290@greenie.muc.de>

Hi,

On Wed, Jul 15, 2009 at 11:27:12PM -0400, Ross Vandegrift wrote:
> On Tue, Jul 14, 2009 at 05:00:36PM +0200, Gert Doering wrote:
> > <rant>
> > MST is what comes out if vendor committees get together, and agree to
> > implement the least common determinator in the most complicated way.
> > </rant>
> 
> I completely disagree - it's what comes out of solving problems
> related to the LAN - the LOCAL area network.  In virtualized LANs,
> there's typically only a few possible physical topologies that can
> exist.  MST seeks to exploit this to lower the amount of processing
> power that is required.

Since MST was standardized long before the "virtualized LAN" environments
were common, this is a nice after-the-fact explanation - but the fact
that *years after protocol design*, networks have emerged that make MST
actually work doesn't make it a better protocol.

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/20090716/71a2bae3/attachment.bin>

From ygauteron at gmail.com  Thu Jul 16 03:41:31 2009
From: ygauteron at gmail.com (Yann Gauteron)
Date: Thu, 16 Jul 2009 09:41:31 +0200
Subject: [c-nsp] Management interface on 2950T-24 appears to be dead
In-Reply-To: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAD7DyDYAOXOSqwBGKYalE/EAQAAAAA=@iname.com>
References: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAD7DyDYAOXOSqwBGKYalE/EAQAAAAA=@iname.com>
Message-ID: <8097baf0907160041m16ee50deqb09103b65defb7e8@mail.gmail.com>

Hi Frank,

Do you monitor the switch resources (CPU, memory) ?

It is very likely that you have a memory leak in a process and no free
memory to allocate for your management process. This is at least the same
behavior that I got once with another Catalyst switch (IOS, don't remember
the version) because of a memory leak in SSH process. So when the switch
went out of free memory, it were impossible to get any administrative access
(neither SSH, nor console) to it. A reboot solved the problem. At console,
we got a message stating there were no memory free anymore. I did not play
with the mode button, so I don't know if it were working or not.

Let us know if the power cycle solved your issue, or not!

Rgs,
Y.

From A.L.M.Buxey at lboro.ac.uk  Thu Jul 16 04:36:07 2009
From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk)
Date: Thu, 16 Jul 2009 09:36:07 +0100
Subject: [c-nsp] Management interface on 2950T-24 appears to be dead
In-Reply-To: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAD7DyDYAOXOSqwBGKYalE/EAQAAAAA=@iname.com>
References: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAD7DyDYAOXOSqwBGKYalE/EAQAAAAA=@iname.com>
Message-ID: <20090716083607.GF21803@lboro.ac.uk>

hi,

had 2 similar issues with a 2950 and a 2960 recently.
in one case, no console access but switch passing
user traffic fine, in the other case, console
access but still no mgmt access out/in.  that second
one we could clearly see the the mgmt VLAN was just 'dead'
on the switch... a reboot out of hours and it was happy back 
to life. keeping an eye on both devices but sometimes
these crazy things seem to happen

alan

From linux.yahoo at gmail.com  Thu Jul 16 04:40:12 2009
From: linux.yahoo at gmail.com (Manu Chao)
Date: Thu, 16 Jul 2009 10:40:12 +0200
Subject: [c-nsp] MST config on single 3560
In-Reply-To: <20090716112806.09vy5bynubac80k4@webmail.datafx.com.au>
References: <20090714145752.qwkjhv749hwswwo0@webmail.datafx.com.au>
	<7100ed370907150130x5609e29aqf61300e8f98f75ac@mail.gmail.com>
	<20090716112806.09vy5bynubac80k4@webmail.datafx.com.au>
Message-ID: <7100ed370907160140j59317896w1d972933d40e0f9b@mail.gmail.com>

 For two or more switches to be in the same MST region, they must have the
same VLAN-to-instance map, the same configuration revision number, and the
same name

VTP propagation of the MST configuration is not (yet) supported

On Thu, Jul 16, 2009 at 3:28 AM, <mb at adv.gcomm.com.au> wrote:

> Quoting Manu Chao <linux.yahoo at gmail.com>:
>
> the standard is ieee 802.1s
>>
>> don't change anything to your interface config
>> mst instance and vlan association is a global config
>>
>> if you planned to migrate to mst on your side, make sure you will migrate
>> to
>> mst with your client ;)
>>
>>
> Thanks for the reply.
>
> As we have single 3560's that do not participate in VTP (vtp mode
> transparent), would I be able to have a config similar to this(On each 3560
> in each POP):
>
> spanning-tree mode mst
> spanning-tree mst configuration
> name LOC_A
> revision 10
> instance 0 : Vlan 1-4094
> spanning-tree mst 0 root primary
>
> And maintain the existing port configs?
>
> If we are getting close to reaching port capacity on each 3560, we will be
> upgrading to 4500's.
>
>
>
>
>
> -------------------------------------------------------------------------
> This e-mail was sent via GCOMM WebMail http://www.gcomm.com.au/
>
>
>

From linux.yahoo at gmail.com  Thu Jul 16 05:12:30 2009
From: linux.yahoo at gmail.com (Manu Chao)
Date: Thu, 16 Jul 2009 11:12:30 +0200
Subject: [c-nsp] MLPPP throughput
In-Reply-To: <20090716021955.GI27087@rtp-cse-489.cisco.com>
References: <Pine.LNX.4.63.0907150959150.28268@charmed.internetsolver.com>
	<20090716015904.GD27087@rtp-cse-489.cisco.com>
	<20090716021955.GI27087@rtp-cse-489.cisco.com>
Message-ID: <7100ed370907160212s5ecf34e6y755485b59513a76a@mail.gmail.com>

can you please display same reorder stats on customer side?

On Thu, Jul 16, 2009 at 4:19 AM, Rodney Dunn <rodunn at cisco.com> wrote:

> Depending on your apps ability to handle out of order frames on the end
> stations of course.
>
> On Wed, Jul 15, 2009 at 09:59:04PM -0400, Rodney Dunn wrote:
> > I bet your out of order is getting so bad you are dropping the packets.
> >
> > I'm not a PPPox expert...but could you create 7 dialers and do CEF
> > per packet over them?
> >
> > On Wed, Jul 15, 2009 at 10:07:24AM -0500, Dave Weis wrote:
> > >
> > > I'm bringing up a MLPPP PPPoA bundle with 4 7-meg DSL lines. It had
> worked
> > > fine with only 2 lines in the bundle and provided the full expected
> speed.
> > > Adding the next two lines didn't provide an increase in speed, it
> actually
> > > might have decreased a bit. It tops out at around 10 megabits with 4
> links
> > > in the bundle.
> > >
> > > The hardware on the customer side is a 3745 running 12.4(4)T1. It has 4
> > > WIC-1ADSL's installed. The config on the ADSL interfaces are all
> > > identical:
> > >
> > > interface ATM0/0
> > >  no ip address
> > >  no atm ilmi-keepalive
> > >  dsl operating-mode auto
> > >  hold-queue 224 in
> > >  pvc 0/32
> > >   encapsulation aal5mux ppp dialer
> > >   dialer pool-member 1
> > >  !
> > >
> > > interface Dialer0
> > >  ip address negotiated
> > >  no ip proxy-arp
> > >  encapsulation ppp
> > >  dialer pool 1
> > >  dialer vpdn
> > >  dialer-group 1
> > >  ppp pap sent-username <removed>
> > >  ppp link reorders
> > >  ppp multilink
> > >  ppp multilink fragment disable
> > > !
> > >
> > > We've tried it with and without the reorders and fragment changes in
> the
> > > config.
> > >
> > > The server side is a 7206 with an NPE-G1. We're not topping out the
> > > processor on either side during transfers.
> > >
> > > The multilink bundle shows a lot of discards and reorders. This is
> after a
> > > reset and downloading less than a gig of data on the client:
> > >
> > > Virtual-Access3, bundle name is isprouter
> > >   Endpoint discriminator is isprouter
> > >   Bundle up for 01:15:43, total bandwidth 400000, load 1/255
> > >   Receive buffer limit 48768 bytes, frag timeout 1000 ms
> > >   Using relaxed lost fragment detection algorithm.
> > >   Dialer interface is Dialer0
> > >     0/0 fragments/bytes in reassembly list
> > >     242 lost fragments, 1237543 reordered
> > >     29169/15194784 discarded fragments/bytes, 16700 lost received
> > >     0x1F9178 received sequence, 0x6A517 sent sequence
> > >   Member links: 4 (max not set, min not set)
> > >     Vi4, since 01:15:43, unsequenced
> > >     PPPoATM link, ATM PVC 0/32 on ATM0/0
> > >     Packets in ATM PVC Holdq: 0, Particles in ATM PVC Tx Ring: 0
> > >     Vi6, since 01:15:43, unsequenced
> > >     PPPoATM link, ATM PVC 0/32 on ATM1/0
> > >     Packets in ATM PVC Holdq: 0, Particles in ATM PVC Tx Ring: 0
> > >     Vi5, since 01:15:43, unsequenced
> > >     PPPoATM link, ATM PVC 0/32 on ATM0/2
> > >     Packets in ATM PVC Holdq: 0, Particles in ATM PVC Tx Ring: 0
> > >     Vi2, since 01:15:43, unsequenced
> > >     PPPoATM link, ATM PVC 0/32 on ATM0/1
> > >     Packets in ATM PVC Holdq: 0, Particles in ATM PVC Tx Ring: 0
> > > No inactive multilink interfaces
> > >
> > >
> > > Any ideas to get this closer to 20+ megs?
> > >
> > > THanks
> > > dave
> > >
> > >
> > >
> > >
> > > --
> > > Dave Weis
> > > djweis at internetsolver.com
> > > http://www.internetsolver.com/
> > >
> > > _______________________________________________
> > > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > > archive at http://puck.nether.net/pipermail/cisco-nsp/
> > _______________________________________________
> > cisco-nsp mailing 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 p.mayers at imperial.ac.uk  Thu Jul 16 05:23:01 2009
From: p.mayers at imperial.ac.uk (Phil Mayers)
Date: Thu, 16 Jul 2009 10:23:01 +0100
Subject: [c-nsp] per-LSP packet loss / FIB corruption?
Message-ID: <4A5EF175.5060707@imperial.ac.uk>

All,

We had a very odd problem yesterday.

Our network (which is all 6500/sup720 running 12.2(33)SXI) runs MPLS 
layer3 VPNs for network segmentation, and there seemed to be packet loss 
between subnets on a pair of routers. Other subnets on those routers in 
different VPNs seemed fine.

The relevant topology is:

siteX --(10gig)-- coreB ==(2x10gig)== coreA --(10gig)-- datacentre

coreA and coreB are similarly configured, with a (fairly recently 
commissioned) 6716 in slot 1, and a 6704 in slot 2. The port channel 
between them has one member on the 6704, one on the 6716. The link from 
coreA -> datacentre is on the 6716 as is our firewall and some other 
intra-core links.

The loss was on packets going datacentre->siteX, and appeared to be 
"inside" coreA - according to a SPAN session (on coreA itself), 15 
packets would arrive at coreA, but only 13 would leave (for example). 
This was pretty consistent, though reports indicate the loss may have 
been higher earlier.

Other traffic from datacentre -> siteX, on different LSPs (i.e. in 
different VPNs) was fine, as far as we could tell.

However, investigating the problem we shutdown various links elsewhere 
in the network, and it seemed to "move" the problem around - it would 
manifest on other LSPs, and start working on the original one. However, 
it seems the problem was confined to coreA.

The loss persisted if we shutdown alternate members of the coreA -> 
coreB port-channel.

There appear to be no physical layer errors anywhere.



Given that coreA is definitely dropping packets, I'm inclined to think 
the problem lies there - but the question is, what might it be? I first 
considered FIB corruption, but it's hard to see how that can give the 
symptoms.

In the end we power-cycled the 6716 linecard, on the rationale that it 
was "new" and it seemed to solve the problem, but since it caused a 
routing change it may of course just have "moved it" around again, to 
LSPs carrying little traffic.

The 6716 passed a full set of GOLD diagnostics when it was delivered, so 
I'm not inclined to easily believe it's faulty.

Could it be the slot? If so, why would it manifest only on a single, or 
a small number of LSPs?

Baffling...

From p.mayers at imperial.ac.uk  Thu Jul 16 05:30:10 2009
From: p.mayers at imperial.ac.uk (Phil Mayers)
Date: Thu, 16 Jul 2009 10:30:10 +0100
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <EA1C4140-2931-4CD4-A3AA-3DE6C07FD78D@Hughes.com.au>
References: <9DE4AA6876D44B62B87C475B2AFE5514@au.didata.local>
	<20090714084503.GA15753@lboro.ac.uk>	<d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>	<Pine.LNX.4.61.0907140924470.6312@soloth.lewis.org>	<20090714141529.GN290@greenie.muc.de>	<Pine.LNX.4.61.0907141101240.6312@soloth.lewis.org>
	<d6966e4b0907140835u597c7ae3l3991ba636ae93bcf@mail.gmail.com>
	<Pine.LNX.4.61.0907141139180.6312@soloth.lewis.org>
	<9e246b4d0907141020v4189c867mcb5e8208454fbc4d@mail.gmail.com>
	<Pine.LNX.4.61.0907141355280.6312@soloth.lewis.org>	<d6966e4b0907141122g714a3e8bwfbee02edca4a80a8@mail.gmail.com>
	<Pine.LNX.4.61.0907141451100.6312@soloth.lewis.org>
	<4A5D005A.5030303@imperial.ac.uk>
	<EA1C4140-2931-4CD4-A3AA-3DE6C07FD78D@Hughes.com.au>
Message-ID: <4A5EF322.2010006@imperial.ac.uk>

David Hughes wrote:
> On 15/07/2009, at 8:02 AM, Phil Mayers wrote:
> 
>> R-PVST + manual VLAN management works like a charm here.
> 
> ..... works like a charm until it doesn't.   Any PV based STP will not  
> work in a dense server virtualisation environment.  So these days  

I'm glad it works for you, I really am. But I'm definitely not 
interested in getting into a food fight about which STP protocol is 
"better" ;o)

In all seriousness, both MST and PVST are an appropriate tool for some 
jobs, and not for others. Few of the jobs I've personally come across 
were suited to MST, hence I have a better opinion of PVST, but it's just 
that - an opinion. There's no absolute right or wrong here.

Hopefully the info presented in the thread will help the OP choose which 
is appropriate for them.

The point that lower-end switches have serious instance limitations is a 
good one though - especially (as you later describe) when doing 
top-of-rack switching and hundreds of VLANs.

From benny+usenet at amorsen.dk  Thu Jul 16 06:13:40 2009
From: benny+usenet at amorsen.dk (Benny Amorsen)
Date: Thu, 16 Jul 2009 12:13:40 +0200
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <EA1C4140-2931-4CD4-A3AA-3DE6C07FD78D@Hughes.com.au> (David
	Hughes's message of "Thu\, 16 Jul 2009 09\:16\:35 +1000")
References: <9DE4AA6876D44B62B87C475B2AFE5514@au.didata.local>
	<20090714084503.GA15753@lboro.ac.uk>
	<d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>
	<Pine.LNX.4.61.0907140924470.6312@soloth.lewis.org>
	<20090714141529.GN290@greenie.muc.de>
	<Pine.LNX.4.61.0907141101240.6312@soloth.lewis.org>
	<d6966e4b0907140835u597c7ae3l3991ba636ae93bcf@mail.gmail.com>
	<Pine.LNX.4.61.0907141139180.6312@soloth.lewis.org>
	<9e246b4d0907141020v4189c867mcb5e8208454fbc4d@mail.gmail.com>
	<Pine.LNX.4.61.0907141355280.6312@soloth.lewis.org>
	<d6966e4b0907141122g714a3e8bwfbee02edca4a80a8@mail.gmail.com>
	<Pine.LNX.4.61.0907141451100.6312@soloth.lewis.org>
	<4A5D005A.5030303@imperial.ac.uk>
	<EA1C4140-2931-4CD4-A3AA-3DE6C07FD78D@Hughes.com.au>
Message-ID: <m38wiplyuj.fsf@ursa.amorsen.dk>

David Hughes <David at hughes.com.au> writes:

> ..... works like a charm until it doesn't.   Any PV based STP will not
> work in a dense server virtualisation environment.  So these days
> that's basically any hosting provider.  MST is your only choice and if
> you pre-provision your vlan/instance mappings it works fine.  Been
> running it without a single issue for ages.

The other option is to do dot1q tunneling, so the switches have no idea
which traffic they're carrying. It makes configurations a lot simpler,
but obviously gives less control over which VLAN's are available on
which ports.

Getting *STP right in a q-in-q environment is not without its own
challenges of course.


/Benny

From david at hughes.com.au  Thu Jul 16 06:18:57 2009
From: david at hughes.com.au (David Hughes)
Date: Thu, 16 Jul 2009 20:18:57 +1000
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <20090716064856.GE290@greenie.muc.de>
References: <20090714141529.GN290@greenie.muc.de>
	<Pine.LNX.4.61.0907141101240.6312@soloth.lewis.org>
	<d6966e4b0907140835u597c7ae3l3991ba636ae93bcf@mail.gmail.com>
	<Pine.LNX.4.61.0907141139180.6312@soloth.lewis.org>
	<9e246b4d0907141020v4189c867mcb5e8208454fbc4d@mail.gmail.com>
	<Pine.LNX.4.61.0907141355280.6312@soloth.lewis.org>
	<d6966e4b0907141122g714a3e8bwfbee02edca4a80a8@mail.gmail.com>
	<Pine.LNX.4.61.0907141451100.6312@soloth.lewis.org>
	<4A5D005A.5030303@imperial.ac.uk>
	<EA1C4140-2931-4CD4-A3AA-3DE6C07FD78D@Hughes.com.au>
	<20090716064856.GE290@greenie.muc.de>
Message-ID: <8494FC38-8A8C-4DA9-BE73-F63712046BCB@hughes.com.au>



On 16/07/2009, at 4:48 PM, Gert Doering wrote:

> Well, of course it won't work if you use a switch that has a 64- 
> instance
> limit.  So don't...

Well, when we broke the 128 instance limit on our access layer we  
moved to MST :)  We have hundreds of vlans trunked to our ESX clusters  
so there's no access class switch from Cisco that can handle that with  
PVST.  Also, if you use blade chassis with embedded switch modules  
(IBM H-class with Cisco switches for example) you run out of STP  
instances pretty quickly. For smaller virtualisation clusters you  
could get away with *PVST but it doesn't work in our hosting  
environment.


Thanks

David
...

From saku at ytti.fi  Thu Jul 16 06:28:38 2009
From: saku at ytti.fi (Saku Ytti)
Date: Thu, 16 Jul 2009 13:28:38 +0300
Subject: [c-nsp] per-LSP packet loss / FIB corruption?
In-Reply-To: <4A5EF175.5060707@imperial.ac.uk>
References: <4A5EF175.5060707@imperial.ac.uk>
Message-ID: <20090716102838.GA14803@mx.ytti.net>

On (2009-07-16 10:23 +0100), Phil Mayers wrote:

Hey,

> Could it be the slot? If so, why would it manifest only on a single,
> or a small number of LSPs?

I've had various of packet loss issues  affecting just single prefix
in PFC3x boxes, typical cause is invalid programming in hardware,
but correct in software, causing hardware to punt traffic
rate-limited to software and software forwarding correctly.

Best way to debug when you've eliminated config errors and
physical link issues is to use ELAM to capture DBUS/RBUS
headers, which will tell you, what the platform is going
to do to the frame.
If interrupt load is something different than 0-1, most
likely something is wrong, however punted amount of 
traffic may be so low that something is wrong even though
interrupt load is 0-1.

-- 
  ++ytti

From rens at autempspourmoi.be  Thu Jul 16 07:33:17 2009
From: rens at autempspourmoi.be (Rens)
Date: Thu, 16 Jul 2009 13:33:17 +0200
Subject: [c-nsp] edge router BGP
Message-ID: <C3412C29D7544726BA3D12A8F1C62FAB@EU.corp.clearwire.com>

Hi all,

 

I'm looking into replacing a 7206VXR NPE-G1 as edge router.

Will be used for our own IP transit but also to serve full BGP tables
towards our customers, directly or multihop

 

Should be able to do 1Gbps speeds.

 

Any propositions?

 

Regards,

 

Rens


From rsm at fast-serv.com  Thu Jul 16 08:06:16 2009
From: rsm at fast-serv.com (Randy McAnally)
Date: Thu, 16 Jul 2009 08:06:16 -0400
Subject: [c-nsp] edge router BGP
In-Reply-To: <C3412C29D7544726BA3D12A8F1C62FAB@EU.corp.clearwire.com>
References: <C3412C29D7544726BA3D12A8F1C62FAB@EU.corp.clearwire.com>
Message-ID: <20090716120511.M53115@fast-serv.com>

Having similar requirements, we just upgraded to a 6500 series with
SUP720-3bxl.  All you will need to do is choose the line cards.  Fits the bill
perfectly.

--
Randy
www.FastServ.com

---------- Original Message -----------
From: "Rens" <rens at autempspourmoi.be>
To: <cisco-nsp at puck.nether.net>
Sent: Thu, 16 Jul 2009 13:33:17 +0200
Subject: [c-nsp] edge router BGP

> Hi all,
> 
> I'm looking into replacing a 7206VXR NPE-G1 as edge router.
> 
> Will be used for our own IP transit but also to serve full BGP tables
> towards our customers, directly or multihop
> 
> Should be able to do 1Gbps speeds.
> 
> Any propositions?
> 
> Regards,
> 
> Rens
> 
> _______________________________________________
> cisco-nsp mailing 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 elmi at 4ever.de  Thu Jul 16 07:49:14 2009
From: elmi at 4ever.de (Elmar K. Bins)
Date: Thu, 16 Jul 2009 13:49:14 +0200
Subject: [c-nsp] edge router BGP
In-Reply-To: <C3412C29D7544726BA3D12A8F1C62FAB@EU.corp.clearwire.com>
References: <C3412C29D7544726BA3D12A8F1C62FAB@EU.corp.clearwire.com>
Message-ID: <20090716114914.GE20732@ronin.4ever.de>

rens at autempspourmoi.be (Rens) wrote:

> I'm looking into replacing a 7206VXR NPE-G1 as edge router.
> 
> Will be used for our own IP transit but also to serve full BGP tables
> towards our customers, directly or multihop
> 
> Should be able to do 1Gbps speeds.
> 
> Any propositions?

If it needs to be Cisco

  - normal to big packet sizes: 72xx with NPE-G2  (e.g., 7201)
  - any packet size: ASR1K (e.g., ASR-1002)

Elmar.

From djweis at internetsolver.com  Thu Jul 16 08:55:57 2009
From: djweis at internetsolver.com (Dave Weis)
Date: Thu, 16 Jul 2009 07:55:57 -0500
Subject: [c-nsp] MLPPP throughput
In-Reply-To: <20090716021955.GI27087@rtp-cse-489.cisco.com>
References: <Pine.LNX.4.63.0907150959150.28268@charmed.internetsolver.com>
	<20090716015904.GD27087@rtp-cse-489.cisco.com>
	<20090716021955.GI27087@rtp-cse-489.cisco.com>
Message-ID: <4A5F235D.1080104@internetsolver.com>


Rodney Dunn wrote:
> Depending on your apps ability to handle out of order frames on the end
> stations of course.
> 
> On Wed, Jul 15, 2009 at 09:59:04PM -0400, Rodney Dunn wrote:
>> I bet your out of order is getting so bad you are dropping the packets.
>>
>> I'm not a PPPox expert...but could you create 7 dialers and do CEF
>> per packet over them?

The traffic is primarily browsing and general internet access, I don't 
believe there will be any voice over the circuit.

dave



-- 
Dave Weis
515-224-9229
djweis at internetsolver.com
http://www.internetsolver.com/

From djweis at internetsolver.com  Thu Jul 16 08:56:41 2009
From: djweis at internetsolver.com (Dave Weis)
Date: Thu, 16 Jul 2009 07:56:41 -0500
Subject: [c-nsp] MLPPP throughput
In-Reply-To: <7100ed370907160212s5ecf34e6y755485b59513a76a@mail.gmail.com>
References: <Pine.LNX.4.63.0907150959150.28268@charmed.internetsolver.com>	<20090716015904.GD27087@rtp-cse-489.cisco.com>	<20090716021955.GI27087@rtp-cse-489.cisco.com>
	<7100ed370907160212s5ecf34e6y755485b59513a76a@mail.gmail.com>
Message-ID: <4A5F2389.1070700@internetsolver.com>

Manu Chao wrote:
> can you please display same reorder stats on customer side?

Other than this one?

>>>>
>>>> The multilink bundle shows a lot of discards and reorders. This is
>> after a
>>>> reset and downloading less than a gig of data on the client:
>>>>
>>>> Virtual-Access3, bundle name is isprouter
>>>>   Endpoint discriminator is isprouter
>>>>   Bundle up for 01:15:43, total bandwidth 400000, load 1/255
>>>>   Receive buffer limit 48768 bytes, frag timeout 1000 ms
>>>>   Using relaxed lost fragment detection algorithm.
>>>>   Dialer interface is Dialer0
>>>>     0/0 fragments/bytes in reassembly list
>>>>     242 lost fragments, 1237543 reordered
>>>>     29169/15194784 discarded fragments/bytes, 16700 lost received
>>>>     0x1F9178 received sequence, 0x6A517 sent sequence
>>>>   Member links: 4 (max not set, min not set)
>>>>     Vi4, since 01:15:43, unsequenced
>>>>     PPPoATM link, ATM PVC 0/32 on ATM0/0
>>>>     Packets in ATM PVC Holdq: 0, Particles in ATM PVC Tx Ring: 0
>>>>     Vi6, since 01:15:43, unsequenced
>>>>     PPPoATM link, ATM PVC 0/32 on ATM1/0
>>>>     Packets in ATM PVC Holdq: 0, Particles in ATM PVC Tx Ring: 0
>>>>     Vi5, since 01:15:43, unsequenced
>>>>     PPPoATM link, ATM PVC 0/32 on ATM0/2
>>>>     Packets in ATM PVC Holdq: 0, Particles in ATM PVC Tx Ring: 0
>>>>     Vi2, since 01:15:43, unsequenced
>>>>     PPPoATM link, ATM PVC 0/32 on ATM0/1
>>>>     Packets in ATM PVC Holdq: 0, Particles in ATM PVC Tx Ring: 0
>>>> No inactive multilink interfaces




-- 
Dave Weis
515-224-9229
djweis at internetsolver.com
http://www.internetsolver.com/

From mtinka at globaltransit.net  Thu Jul 16 08:29:30 2009
From: mtinka at globaltransit.net (Mark Tinka)
Date: Thu, 16 Jul 2009 20:29:30 +0800
Subject: [c-nsp] edge router BGP
In-Reply-To: <20090716120511.M53115@fast-serv.com>
References: <C3412C29D7544726BA3D12A8F1C62FAB@EU.corp.clearwire.com>
	<20090716120511.M53115@fast-serv.com>
Message-ID: <200907162029.31896.mtinka@globaltransit.net>

On Thursday 16 July 2009 08:06:16 pm Randy McAnally wrote:

> Having similar requirements, we just upgraded to a 6500
> series with SUP720-3bxl.  All you will need to do is
> choose the line cards.  Fits the bill perfectly.

Not sure if that's too large (and depending on future 
requirements, whether the whole 6500/7600 drama will come 
back to bite the OP).

I was thinking more, ASR1000 series. Will do wire rate, has 
a large enough control plane to handle multiple full tables 
to customers, is the natural progression from the 7200-VXR 
platform, e.t.c.

side note: we have pushed an NPE-G2 as an edge router, i.e.,
	   ACL's, uRPF, BGP, IS-IS, BFD, all that good stuff, to
	   about 950Mbps with a couple of BGP feeds to customers;
  	   granted, CPU hovered about 90%, but no packet loss,
	   e.t.c.

	   I'm, in no way, recommending you do this (we tend to
	   do things a little differently sometimes), but thought
	   you might like this horror story :-).

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/20090716/39ccaa8c/attachment.bin>

From p.mayers at imperial.ac.uk  Thu Jul 16 09:14:40 2009
From: p.mayers at imperial.ac.uk (Phil Mayers)
Date: Thu, 16 Jul 2009 14:14:40 +0100
Subject: [c-nsp] per-LSP packet loss / FIB corruption?
In-Reply-To: <20090716102838.GA14803@mx.ytti.net>
References: <4A5EF175.5060707@imperial.ac.uk>
	<20090716102838.GA14803@mx.ytti.net>
Message-ID: <4A5F27C0.9040201@imperial.ac.uk>

Saku Ytti wrote:
> On (2009-07-16 10:23 +0100), Phil Mayers wrote:
> 
> Hey,
> 
>> Could it be the slot? If so, why would it manifest only on a single,
>> or a small number of LSPs?
> 
> I've had various of packet loss issues  affecting just single prefix
> in PFC3x boxes, typical cause is invalid programming in hardware,
> but correct in software, causing hardware to punt traffic
> rate-limited to software and software forwarding correctly.

Ah; and we've got quite aggressive CoPP and punt rate limiters. Would 
that mean the traffic would be dropped quite aggressively as it was punted?

> 
> Best way to debug when you've eliminated config errors and
> physical link issues is to use ELAM to capture DBUS/RBUS
> headers, which will tell you, what the platform is going
> to do to the frame.

Interesting; ELAM is not something I've ever used before. I see there's 
a doc on Cluepon - I'll have to take a look.

> If interrupt load is something different than 0-1, most
> likely something is wrong, however punted amount of 
> traffic may be so low that something is wrong even though
> interrupt load is 0-1.
> 

Interesting.

As I said, in this case we rebooted the linecard and the problem seems 
to have gone. Are there other routes that will reliably reprogram the 
hardware? The "mls cef" inconsistency checker seemed to think all was well.

Thanks very much for the suggestion; it fits the symptoms extremely well.

From rodunn at cisco.com  Thu Jul 16 09:32:47 2009
From: rodunn at cisco.com (Rodney Dunn)
Date: Thu, 16 Jul 2009 09:32:47 -0400
Subject: [c-nsp] MLPPP throughput
In-Reply-To: <4A5F235D.1080104@internetsolver.com>
References: <Pine.LNX.4.63.0907150959150.28268@charmed.internetsolver.com>
	<20090716015904.GD27087@rtp-cse-489.cisco.com>
	<20090716021955.GI27087@rtp-cse-489.cisco.com>
	<4A5F235D.1080104@internetsolver.com>
Message-ID: <20090716133247.GB1679@rtp-cse-489.cisco.com>

Then if you can get the equal cost paths with CEF PPLB you would probably
be ok.

Is that possible?

On Thu, Jul 16, 2009 at 07:55:57AM -0500, Dave Weis wrote:
> 
> Rodney Dunn wrote:
> >Depending on your apps ability to handle out of order frames on the end
> >stations of course.
> >
> >On Wed, Jul 15, 2009 at 09:59:04PM -0400, Rodney Dunn wrote:
> >>I bet your out of order is getting so bad you are dropping the packets.
> >>
> >>I'm not a PPPox expert...but could you create 7 dialers and do CEF
> >>per packet over them?
> 
> The traffic is primarily browsing and general internet access, I don't 
> believe there will be any voice over the circuit.
> 
> dave
> 
> 
> 
> -- 
> Dave Weis
> 515-224-9229
> djweis at internetsolver.com
> http://www.internetsolver.com/

From rodunn at cisco.com  Thu Jul 16 09:33:31 2009
From: rodunn at cisco.com (Rodney Dunn)
Date: Thu, 16 Jul 2009 09:33:31 -0400
Subject: [c-nsp] MLPPP throughput
In-Reply-To: <4A5F2389.1070700@internetsolver.com>
References: <Pine.LNX.4.63.0907150959150.28268@charmed.internetsolver.com>
	<20090716015904.GD27087@rtp-cse-489.cisco.com>
	<20090716021955.GI27087@rtp-cse-489.cisco.com>
	<7100ed370907160212s5ecf34e6y755485b59513a76a@mail.gmail.com>
	<4A5F2389.1070700@internetsolver.com>
Message-ID: <20090716133331.GC1679@rtp-cse-489.cisco.com>

Yeah...a lot of discarded fragments and the reorders are pretty high
implying there is a lot of differential delay along the paths.

On Thu, Jul 16, 2009 at 07:56:41AM -0500, Dave Weis wrote:
> Manu Chao wrote:
> >can you please display same reorder stats on customer side?
> 
> Other than this one?
> 
> >>>>
> >>>>The multilink bundle shows a lot of discards and reorders. This is
> >>after a
> >>>>reset and downloading less than a gig of data on the client:
> >>>>
> >>>>Virtual-Access3, bundle name is isprouter
> >>>>  Endpoint discriminator is isprouter
> >>>>  Bundle up for 01:15:43, total bandwidth 400000, load 1/255
> >>>>  Receive buffer limit 48768 bytes, frag timeout 1000 ms
> >>>>  Using relaxed lost fragment detection algorithm.
> >>>>  Dialer interface is Dialer0
> >>>>    0/0 fragments/bytes in reassembly list
> >>>>    242 lost fragments, 1237543 reordered
> >>>>    29169/15194784 discarded fragments/bytes, 16700 lost received
> >>>>    0x1F9178 received sequence, 0x6A517 sent sequence
> >>>>  Member links: 4 (max not set, min not set)
> >>>>    Vi4, since 01:15:43, unsequenced
> >>>>    PPPoATM link, ATM PVC 0/32 on ATM0/0
> >>>>    Packets in ATM PVC Holdq: 0, Particles in ATM PVC Tx Ring: 0
> >>>>    Vi6, since 01:15:43, unsequenced
> >>>>    PPPoATM link, ATM PVC 0/32 on ATM1/0
> >>>>    Packets in ATM PVC Holdq: 0, Particles in ATM PVC Tx Ring: 0
> >>>>    Vi5, since 01:15:43, unsequenced
> >>>>    PPPoATM link, ATM PVC 0/32 on ATM0/2
> >>>>    Packets in ATM PVC Holdq: 0, Particles in ATM PVC Tx Ring: 0
> >>>>    Vi2, since 01:15:43, unsequenced
> >>>>    PPPoATM link, ATM PVC 0/32 on ATM0/1
> >>>>    Packets in ATM PVC Holdq: 0, Particles in ATM PVC Tx Ring: 0
> >>>>No inactive multilink interfaces
> 
> 
> 
> 
> -- 
> Dave Weis
> 515-224-9229
> djweis at internetsolver.com
> http://www.internetsolver.com/

From djweis at internetsolver.com  Thu Jul 16 09:37:40 2009
From: djweis at internetsolver.com (Dave Weis)
Date: Thu, 16 Jul 2009 08:37:40 -0500
Subject: [c-nsp] MLPPP throughput
In-Reply-To: <20090716133331.GC1679@rtp-cse-489.cisco.com>
References: <Pine.LNX.4.63.0907150959150.28268@charmed.internetsolver.com>
	<20090716015904.GD27087@rtp-cse-489.cisco.com>
	<20090716021955.GI27087@rtp-cse-489.cisco.com>
	<7100ed370907160212s5ecf34e6y755485b59513a76a@mail.gmail.com>
	<4A5F2389.1070700@internetsolver.com>
	<20090716133331.GC1679@rtp-cse-489.cisco.com>
Message-ID: <4A5F2D24.9070509@internetsolver.com>

Rodney Dunn wrote:
> Yeah...a lot of discarded fragments and the reorders are pretty high
> implying there is a lot of differential delay along the paths.

That's surprising that they would be that different, it's 4 ILEC DSL 
circuits from a relatively small office terminating to me over a DS3 
with relatively low usage. The only thing I can think of is the link 
from the small town is congested.

Would the problem be related to congestion? I can see if they will try 
pulling some traffic during off hours if that's the case.

Thanks!

dave


-- 
Dave Weis
515-224-9229
djweis at internetsolver.com
http://www.internetsolver.com/

From frnkblk at iname.com  Thu Jul 16 10:04:18 2009
From: frnkblk at iname.com (Frank Bulk)
Date: Thu, 16 Jul 2009 09:04:18 -0500
Subject: [c-nsp] Management interface on 2950T-24 appears to be dead
In-Reply-To: <8097baf0907160041m16ee50deqb09103b65defb7e8@mail.gmail.com>
References: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAD7DyDYAOXOSqwBGKYalE/EAQAAAAA=@iname.com>
	<8097baf0907160041m16ee50deqb09103b65defb7e8@mail.gmail.com>
Message-ID: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAAMOjq9F/DfSrgu3mVrWOk3AQAAAAA=@iname.com>

We monitor just CPU on that switch and it floats between 1 and 3%.  

 

We don't run SSH on that box, so I doubt it could be that.  The mgmt
interface is in our private network and not operating on VLAN 1, so it's
unlikely that it was being exploited.

 

We power-cycled the switch at 8:15 pm and by 11:20 pm it was in the same
state again.  In the meantime I did look at that switch and there was no
crashlog or anything I could see that indicated what had happened.

 

I plan to perform another reboot and upgrade it from EA11 to EA13 tonight.

 

Thanks,

 

Frank

 

From: Yann Gauteron [mailto:ygauteron at gmail.com] 
Sent: Thursday, July 16, 2009 2:42 AM
To: frnkblk at iname.com
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Management interface on 2950T-24 appears to be dead

 

Hi Frank,

Do you monitor the switch resources (CPU, memory) ?

It is very likely that you have a memory leak in a process and no free
memory to allocate for your management process. This is at least the same
behavior that I got once with another Catalyst switch (IOS, don't remember
the version) because of a memory leak in SSH process. So when the switch
went out of free memory, it were impossible to get any administrative access
(neither SSH, nor console) to it. A reboot solved the problem. At console,
we got a message stating there were no memory free anymore. I did not play
with the mode button, so I don't know if it were working or not.

Let us know if the power cycle solved your issue, or not!

Rgs,
Y.


From saku at ytti.fi  Thu Jul 16 10:10:18 2009
From: saku at ytti.fi (Saku Ytti)
Date: Thu, 16 Jul 2009 17:10:18 +0300
Subject: [c-nsp] per-LSP packet loss / FIB corruption?
In-Reply-To: <4A5F27C0.9040201@imperial.ac.uk>
References: <4A5EF175.5060707@imperial.ac.uk>
	<20090716102838.GA14803@mx.ytti.net>
	<4A5F27C0.9040201@imperial.ac.uk>
Message-ID: <20090716141018.GA18736@mx.ytti.net>

On (2009-07-16 14:14 +0100), Phil Mayers wrote:

> Ah; and we've got quite aggressive CoPP and punt rate limiters.
> Would that mean the traffic would be dropped quite aggressively as
> it was punted?

If you're using MLS rate-limiters, I've often seen prefix
programmed in ELAM as TTL or MTU rate-limiter index,
0x0380 is MTU failure, 0x7F0A unicast ip error, 0x7FFF
ttl failure. These are typically shared with many
type of drops, so it's not 100% certain.
But unless you see real interface index or 0x7FFA
which is recirculate in my experience, it's likely wrong.

> As I said, in this case we rebooted the linecard and the problem
> seems to have gone. Are there other routes that will reliably
> reprogram the hardware? The "mls cef" inconsistency checker seemed
> to think all was well.

Yeah I guess most reload and thus don't see these issues.

-- 
  ++ytti

From jmaimon at ttec.com  Thu Jul 16 10:12:08 2009
From: jmaimon at ttec.com (Joe Maimon)
Date: Thu, 16 Jul 2009 10:12:08 -0400
Subject: [c-nsp] ip per-packet load-sharing on single interface
In-Reply-To: <20090715215343.GB25797@rtp-cse-489.cisco.com>
References: <4A5E2E0C.5050208@ttec.com>
	<78C984F8939D424697B15E4B1C1BB3D7F94EBD@xmb-ams-331.emea.cisco.com>
	<20090715215343.GB25797@rtp-cse-489.cisco.com>
Message-ID: <4A5F3538.1010106@ttec.com>

If I read those numbers right, the router seems to think it is doing per 
packet load balancing.

Perhaps the problems is elsewhere. I have sent the output direct.

Thanks for your help.

Joe

Rodney Dunn wrote:
> Turn on 'ip cef account load per pre'
> and send the 'sh ip cef internal' for the prefix you are going towards.
> 
> On Wed, Jul 15, 2009 at 10:33:34PM +0200, Arie Vayner (avayner) wrote:
>> Joe,
>>
>> Which platform is it?
>> Can you share "show ip route" and "show ip cef internal"?
>>
>> Arie
>>
>> -----Original Message-----
>> From: cisco-nsp-bounces at puck.nether.net
>> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Joe Maimon
>> Sent: Wednesday, July 15, 2009 22:29
>> To: cisco-nsp
>> Subject: [c-nsp] ip per-packet load-sharing on single interface
>>
>> ip per-packet load-sharing on single ethernet interface with multiple 
>> iBGP routes installed to different nodes on that ethernet interface.
>>
>> Software router, 12.3
>>
>> Does not seem to be balancing. Is this supposed to 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 linux.yahoo at gmail.com  Thu Jul 16 10:14:27 2009
From: linux.yahoo at gmail.com (Manu Chao)
Date: Thu, 16 Jul 2009 16:14:27 +0200
Subject: [c-nsp] MLPPP throughput
In-Reply-To: <4A5F2D24.9070509@internetsolver.com>
References: <Pine.LNX.4.63.0907150959150.28268@charmed.internetsolver.com>
	<20090716015904.GD27087@rtp-cse-489.cisco.com>
	<20090716021955.GI27087@rtp-cse-489.cisco.com>
	<7100ed370907160212s5ecf34e6y755485b59513a76a@mail.gmail.com>
	<4A5F2389.1070700@internetsolver.com>
	<20090716133331.GC1679@rtp-cse-489.cisco.com>
	<4A5F2D24.9070509@internetsolver.com>
Message-ID: <7100ed370907160714v10d19903l38793a4a1b591f0f@mail.gmail.com>

why not first check latency & througput on your new individual adsl link?

On Thu, Jul 16, 2009 at 3:37 PM, Dave Weis <djweis at internetsolver.com>wrote:

> Rodney Dunn wrote:
>
>> Yeah...a lot of discarded fragments and the reorders are pretty high
>> implying there is a lot of differential delay along the paths.
>>
>
> That's surprising that they would be that different, it's 4 ILEC DSL
> circuits from a relatively small office terminating to me over a DS3 with
> relatively low usage. The only thing I can think of is the link from the
> small town is congested.
>
> Would the problem be related to congestion? I can see if they will try
> pulling some traffic during off hours if that's the case.
>
> Thanks!
>
> dave
>
>
>
> --
> Dave Weis
> 515-224-9229
> djweis at internetsolver.com
> http://www.internetsolver.com/
>

From SPfister at dps.k12.oh.us  Thu Jul 16 10:34:18 2009
From: SPfister at dps.k12.oh.us (Steven Pfister)
Date: Thu, 16 Jul 2009 10:34:18 -0400
Subject: [c-nsp] Question on h.323 video calls through a PIX 525	with NAT
In-Reply-To: <530c5af60907151107v52055d1dm86fbe5a0fc962828@mail.gmail.com>
References: <4A5DCB56.9E6F.00B8.0@dps.k12.oh.us>
	<530c5af60907151107v52055d1dm86fbe5a0fc962828@mail.gmail.com>
Message-ID: <4A5F021F.9E6F.00B8.0@dps.k12.oh.us>

I tried doing a capture on a call to the address that worked previously, but it's not working now, so I don't have a working/non-working setup to compare to.

I did get a packet capture of a failed call from outside the firewall. I notice that our side, in doing an openLogicalChannel, is showing the internal address in the H.245 section in Wireshark. This is a problem, isn't it? It would explain why audio and video get sent out from here, but nothing ever comes back from the other side.

Since the NAT transversal option is on at the video conferencing end on our side, and the inspect statements are in effect on the PIX, I'm not sure why this is happening. Is one fixing it and one breaking it again? Should I try without the inspect on the PIX?

Steve Pfister
Technical Coordinator, 
The Office of Information Technology
Dayton Public Schools
115 S. Ludlow St. 
Dayton, OH 45402
 
Office (937) 542-3149
Cell (937) 673-6779
Direct Connect: 137*131747*8
Email spfister at dps.k12.oh.us


>>> Andrew Yourtchenko <ayourtch at gmail.com> 7/15/2009 2:07 PM >>>
Hi Steven,

On Wed, Jul 15, 2009 at 6:28 PM, Steven Pfister<SPfister at dps.k12.oh.us> wrote:
> I'm having some trouble with h.323 (video) calls through a PIX 525 using NAT. We can get incoming calls fine, but not outgoing calls for some reason. My question has to do with 'inspect h323' vs 'fixup protocol h323'. What's the difference between them? The video conferencing unit in question has a NAT transversal option where I can supply an address and mask.I'm wondering if I'm having a NAT transversal problem anyway. Which one would handle the NAT transversal, inspect or fixup? Currently, the PIX config has:
>
>  inspect h323 h225
>  inspect h323 ras
>
> do I need:
>
>  fixup protocol h323 h225 1718-1720
>  fixup protocol h323 h225 1720
>  fixup protocol h323 ras 1718-1719
>
> instead of the inspect commands? In addition to them?
>

"inspect" is the name of the "fixup" from 7.0 onwards - obviously as
time went, some more enhancements were added.

you can enter the "fixup" commands, but they will be autoconverted
into the respective "inspect" under "magic" default policy.

You mention that the inbound call works - so a nice way to debug would
be to grab the pcap on inside+ pcap on the outside and study them in
wireshark for both failing and working scenarios and see what is
different.

The first cutover point is whether you see the tcp/1720 in the
outbound direction or not - if not, or if it is going to the wrong
address, would mean there is an issue related to RAS signaling - else
it's something with the call signaling.

The above can be tested much easier if you are able to make the direct
calls by IP address and the other party can accept such calls without
involving RAS at all - this could be an easy shortcut instead of
staring at the sniffer traces :-) - if the direct call using IP
address works, then you can further investigate RAS. If the inbound
calls to you work, most probably it is going to be the case, but worth
doublechecking.

The inspect in the default configuration normally should be able to
tweak all the embedded IPs both for RAS and call setup, so the
endpoints would not need to have any NAT awareness nor do any special
efforts to detect/traverse the NAT.

Also might be quite useful to have a quick test with another h323
stack if you can - openh323 had a very tweakable client, and ekiga can
do h323 video as well. If those work, again you get one more baseline
to compare the sniffer traces with.

cheers,
andrew


From rsm at fast-serv.com  Thu Jul 16 10:43:32 2009
From: rsm at fast-serv.com (Randy McAnally)
Date: Thu, 16 Jul 2009 10:43:32 -0400
Subject: [c-nsp] edge router BGP
In-Reply-To: <200907162029.31896.mtinka@globaltransit.net>
References: <C3412C29D7544726BA3D12A8F1C62FAB@EU.corp.clearwire.com>
	<20090716120511.M53115@fast-serv.com>
	<200907162029.31896.mtinka@globaltransit.net>
Message-ID: <20090716144243.M24674@fast-serv.com>

Could you please expand on or give me a link to information I can find about
the 6500/7600 issues you mentioned?  Thanks!

--
Randy
www.FastServ.com

---------- Original Message -----------
From: Mark Tinka <mtinka at globaltransit.net>
To: cisco-nsp at puck.nether.net
Cc: "Randy McAnally" <rsm at fast-serv.com>, "Rens" <rens at autempspourmoi.be>
Sent: Thu, 16 Jul 2009 20:29:30 +0800
Subject: Re: [c-nsp] edge router BGP

> On Thursday 16 July 2009 08:06:16 pm Randy McAnally wrote:
> 
> > Having similar requirements, we just upgraded to a 6500
> > series with SUP720-3bxl.  All you will need to do is
> > choose the line cards.  Fits the bill perfectly.
> 
> Not sure if that's too large (and depending on future 
> requirements, whether the whole 6500/7600 drama will come 
> back to bite the OP).
> 
> I was thinking more, ASR1000 series. Will do wire rate, has 
> a large enough control plane to handle multiple full tables 
> to customers, is the natural progression from the 7200-VXR 
> platform, e.t.c.
> 
> side note: we have pushed an NPE-G2 as an edge router, i.e.,
> 	   ACL's, uRPF, BGP, IS-IS, BFD, all that good stuff, to
> 	   about 950Mbps with a couple of BGP feeds to customers;
>   	   granted, CPU hovered about 90%, but no packet loss,
> 	   e.t.c.
> 
> 	   I'm, in no way, recommending you do this (we tend to
> 	   do things a little differently sometimes), but thought
> 	   you might like this horror story :-).
> 
> Cheers,
> 
> Mark.
------- End of Original Message -------


From rodunn at cisco.com  Thu Jul 16 11:29:31 2009
From: rodunn at cisco.com (Rodney Dunn)
Date: Thu, 16 Jul 2009 11:29:31 -0400
Subject: [c-nsp] MLPPP throughput
In-Reply-To: <4A5F2D24.9070509@internetsolver.com>
References: <Pine.LNX.4.63.0907150959150.28268@charmed.internetsolver.com>
	<20090716015904.GD27087@rtp-cse-489.cisco.com>
	<20090716021955.GI27087@rtp-cse-489.cisco.com>
	<7100ed370907160212s5ecf34e6y755485b59513a76a@mail.gmail.com>
	<4A5F2389.1070700@internetsolver.com>
	<20090716133331.GC1679@rtp-cse-489.cisco.com>
	<4A5F2D24.9070509@internetsolver.com>
Message-ID: <20090716152931.GJ1679@rtp-cse-489.cisco.com>

On Thu, Jul 16, 2009 at 08:37:40AM -0500, Dave Weis wrote:
> Rodney Dunn wrote:
> >Yeah...a lot of discarded fragments and the reorders are pretty high
> >implying there is a lot of differential delay along the paths.
> 
> That's surprising that they would be that different, it's 4 ILEC DSL 
> circuits from a relatively small office terminating to me over a DS3 
> with relatively low usage. The only thing I can think of is the link 
> from the small town is congested.
> 
> Would the problem be related to congestion? I can see if they will try 
> pulling some traffic during off hours if that's the case.

Could be.

> 
> Thanks!
> 
> dave
> 
> 
> -- 
> Dave Weis
> 515-224-9229
> djweis at internetsolver.com
> http://www.internetsolver.com/

From walter.keen at RainierConnect.net  Thu Jul 16 11:38:36 2009
From: walter.keen at RainierConnect.net (Walter Keen)
Date: Thu, 16 Jul 2009 08:38:36 -0700
Subject: [c-nsp] NAT, rpr-plus and dCEF on 7500
Message-ID: <4A5F497C.8040807@rainierconnect.net>


We have a 7500 with RSP8's, terminating ATM DS3 circuits with bridging and pppoa.  Unfortunately we are forced to do NAT on some of these, but during testing, if we turn dCEF on, performance (and console responsiveness) slow to a crawl and throughput is roughly 2mbit.  If we leave CEF enabled but disable dCEF, we get 50+mbit of throughput with roughly a 10-20% cpu load.  IOS is rsp-jsv-mz.124-8.bin and redundancy mode is set to rpr-plus. system also has 3 vip4-80's with 256mb ram.


I'm also seeing this on most configuration changes, is this possibly an issue with rpr-plus, or this ios image?


04:43:00: %SYS-5-CONFIG_I: Configured from console by wkeen on vty1 (x.x.x.x)
04:43:25: %HA-2-IPC_ERROR: Fail to send RPC to peer. timeout                      
04:43:25: %HA-3-SYNC_ERROR: Config sync failed.                                   
04:43:25: %HA-5-SYNC_RETRY: Reloading standby and retrying sync operation (retry 1).
04:43:25: %SYS-5-CONFIG_I: Configured from console by wkeen on vty1 (x.x.x.x)  
04:43:40: %RSP-3-SLAVECHANGE: Slave changed state from Slave to Non-participant     
04:43:40: %HA-5-MODE: Operating mode is hsa, configured mode is rpr-plus.           
04:43:43: %RSP-3-SLAVECHANGE: Slave changed state from Non-participant to Slave     
04:43:48: %RSP-3-SLAVECHANGE: Slave changed state from Slave to Non-participant     
04:43:51: %RSP-3-SLAVECHANGE: Slave changed state from Non-participant to Slave     
04:43:56: %RSP-3-SLAVECHANGE: Slave changed state from Slave to Non-participant     
04:43:58: %RSP-3-SLAVECHANGE: Slave changed state from Non-participant to Slave
04:44:04: %SYS-5-CONFIG_I: Configured from console by wkeen on vty1 (x.x.x.x)
04:44:32: %SYS-5-CONFIG_I: Configured from console by wkeen on vty1 (x.x.x.x)
04:44:42: %HA-5-NOTICE: Standby (slave) configured to run HA image "disk0:rsp-jsv-mz.124-8.bin"
04:44:43: %HA-5-NOTICE: Loading standby (slave) image: "disk0:rsp-jsv-mz.124-8.bin"
sea-agg-1(config)#
04:45:51: %HA-5-MODE: Operating mode is hsa, configured mode is rpr-plus.
04:45:51: %HA-5-SYNC_NOTICE: Bulk sync started.
04:45:51: %HA-5-SYNC_NOTICE: Bulk sync completed.
04:46:29: %HA-5-SYNC_NOTICE: Config sync started.
04:46:56: %HA-5-SYNC_NOTICE: Config sync completed.
04:47:01: %HA-5-SYNC_NOTICE: Standby has restarted.
04:47:02: %HA-5-MODE: Operating mode is rpr-plus, configured mode is rpr-plus.
04:47:22: %HA-2-IPC_ERROR: Fail to send RPC to peer. timeout
04:47:23: %HA-3-SYNC_ERROR: Config sync failed.
04:47:23: %HA-5-SYNC_RETRY: Reloading standby and retrying sync operation (retry 1).
04:47:23: %SYS-5-CONFIG_I: Configured from console by wkeen on vty1 (x.x.x.x)
04:47:38: %RSP-3-SLAVECHANGE: Slave changed state from Slave to Non-participant
04:47:38: %HA-5-MODE: Operating mode is hsa, configured mode is rpr-plus.
04:47:40: %RSP-3-SLAVECHANGE: Slave changed state from Non-participant to Slave
04:47:46: %RSP-3-SLAVECHANGE: Slave changed state from Slave to Non-participant
04:47:48: %RSP-3-SLAVECHANGE: Slave changed state from Non-participant to Slave
04:47:53: %RSP-3-SLAVECHANGE: Slave changed state from Slave to Non-participant
04:47:56: %RSP-3-SLAVECHANGE: Slave changed state from Non-participant to Slave
04:48:39: %HA-5-NOTICE: Standby (slave) configured to run HA image "disk0:rsp-jsv-mz.124-8.bin"
04:48:40: %HA-5-NOTICE: Loading standby (slave) image: "disk0:rsp-jsv-mz.124-8.bin"
04:49:48: %HA-5-MODE: Operating mode is hsa, configured mode is rpr-plus.
04:49:48: %HA-5-SYNC_NOTICE: Bulk sync started.
04:49:48: %HA-5-SYNC_NOTICE: Bulk sync completed.
04:50:27: %HA-5-SYNC_NOTICE: Config sync started.
04:52:52: %HA-5-SYNC_NOTICE: Config sync completed.
04:52:58: %HA-5-SYNC_NOTICE: Standby has restarted.
04:52:58: %HA-5-MODE: Operating mode is rpr-plus, configured mode is rpr-plus.



From alasdairm at gmail.com  Thu Jul 16 11:49:50 2009
From: alasdairm at gmail.com (Alasdair McWilliam)
Date: Thu, 16 Jul 2009 16:49:50 +0100
Subject: [c-nsp] edge router BGP
In-Reply-To: <20090716114914.GE20732@ronin.4ever.de>
References: <C3412C29D7544726BA3D12A8F1C62FAB@EU.corp.clearwire.com>
	<20090716114914.GE20732@ronin.4ever.de>
Message-ID: <ce2d38bb0907160849x496c4960v928b8b8ccb9a0f61@mail.gmail.com>

We've recently deployed ASR 1002 boxes with ESP5 cards and I'm very
happy with them. We only run 3 full BGP feeds on each ASR, with other
EIGRP peers, and while the CPU of our other boxes (7200vxr's) is
linear with load, the ASR seems to twiddle its thumbs somewhat even
under load.

It seems the 6500/7600's debate has come up on this list a few times
so I won't mention that ;-) I just know that specifically with the
6500s, even with an XL sup, I wouldn't be comfortable loading full BGP
feeds into it, given it's limitation will always be hardware (amount
of registers available to store routes in hardware).  I've no
experience with 7600s so can't say if it's the same limitation here.






On Thu, Jul 16, 2009 at 12:49 PM, Elmar K. Bins<elmi at 4ever.de> wrote:
> rens at autempspourmoi.be (Rens) wrote:
>
>> I'm looking into replacing a 7206VXR NPE-G1 as edge router.
>>
>> Will be used for our own IP transit but also to serve full BGP tables
>> towards our customers, directly or multihop
>>
>> Should be able to do 1Gbps speeds.
>>
>> Any propositions?
>
> If it needs to be Cisco
>
> ?- normal to big packet sizes: 72xx with NPE-G2 ?(e.g., 7201)
> ?- any packet size: ASR1K (e.g., ASR-1002)
>
> Elmar.
> _______________________________________________
> cisco-nsp mailing list ?cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From dan at opensys.ro  Thu Jul 16 11:30:29 2009
From: dan at opensys.ro (Dan Mosneanu)
Date: Thu, 16 Jul 2009 18:30:29 +0300
Subject: [c-nsp] %CPU_MONITOR
Message-ID: <003b01ca062a$59a7c240$0cf746c0$@ro>

Hi all,

 

We have a 6009 equipped with:

Mod Ports Card Type                              Model              Serial
No.

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

  1    2  Cat 6k sup 1 Enhanced QoS (Active)     WS-X6K-SUP1A-2GE
SAL0539CB5W

  3   16  16 port 1000mb GBIC ethernet           WS-X6416-GBIC
SAD041406KY

  7   48  48 port 10/100 mb RJ-45 ethernet       WS-X6248-RJ-45
SAD040806EC

  9   48  48 port 10/100 mb RJ45                 WS-X6348-RJ-45
SAL0437156A

With PFC and MSFC 2 daughterboard 

 

Lately we have some problems with our box. Here are some lines from its log:

 

Jul 16 12:14:19: %CPU_MONITOR-6-NOT_HEARD: CPU_MONITOR messages have not
been heard for 30 seconds [1/1]

Jul 16 12:15:32: %CPU_MONITOR-6-NOT_HEARD: CPU_MONITOR messages have not
been heard for 30 seconds [1/1]

*Jul 16 12:14:19: %CPU_MONITOR-SP-2-NOT_RUNNING: CPU_MONITOR messages have
not been sent for 30 seconds [Spanning Tree 99%/99% (00:00:32.552 100%/99%)]
[Spanning Tree 00:00:29.624] [Compute load avgs 00:00:29.736] [PM Callback
00:00:29.780]

*Jul 16 12:14:19: %CPU_MONITOR-SP-2-NOT_RUNNING_TB: CPU_MONITOR traceback:
602B11A0 6061E05C 6061F08C 60620174 602487E0 6020E728 6021263C 0

*Jul 16 12:14:40: %CPU_MONITOR-SP-6-NOT_HEARD: CPU_MONITOR messages have not
been heard for 51 seconds [1/2]

*Jul 16 12:15:32: %CPU_MONITOR-SP-2-NOT_RUNNING: CPU_MONITOR messages have
not been sent for 30 seconds [Spanning Tree 100%/99% (00:00:32.708
100%/99%)] [Spanning Tree 00:00:29.128] [Compute load avgs 00:00:29.308] [PM
Callback 00:00:29.376]

*Jul 16 12:15:32: %CPU_MONITOR-SP-2-NOT_RUNNING_TB: CPU_MONITOR traceback:
602A91B8 6020E658 6021263C 0 0 0 0 0

*Jul 16 12:15:33: %CPU_MONITOR-SP-6-NOT_HEARD: CPU_MONITOR messages have not
been heard for 31 seconds [1/2]

 

Does "[Spanning Tree 99%/99% (00:00:32.552 100%/99%)]" means that the
Spanning Tree process is using al the CPU of the SUP and that is why
"CPU_MONITOR messages have not been sent" ? There are 34 vlans. STP is
running in rstp mode. The switch is the root for STP

After we reestablish the connectivity to the switch output of the show proc
cpu shows 0.00% utilization for spanning tree process. Overall CPU:
utilization for five seconds: 26%/20%; one minute: 20%; five minutes: 20%

 

Has anyone seen this before?

 

Regards, 

    Dan Mosneanu

 

 


From gsgranados at comcast.net  Thu Jul 16 12:15:17 2009
From: gsgranados at comcast.net (Scott Granados)
Date: Thu, 16 Jul 2009 09:15:17 -0700
Subject: [c-nsp] adding a port forward on a Cisco Pix
References: <961068.90710.qm@web110101.mail.gq1.yahoo.com>
Message-ID: <00b801ca0630$a17a8ac0$0202fea9@am.thmulti.com>

Tony, this is perfect thank you.


Huge help!

----- Original Message ----- 
From: "Tony" <td_miles at yahoo.com>
To: <cisco-nsp at puck.nether.net>; "Scott Granados" <gsgranados at comcast.net>
Sent: Wednesday, July 15, 2009 6:52 PM
Subject: Re: [c-nsp] adding a port forward on a Cisco Pix



Hi Scott,

For your NAT to work you need to things:
1. static command
2. Access-list

> static (outside,inside) tcp general-internet-rtr-svc-nat 80 
> inside-ip-object 80 netmask 255.255.255.255 0 0

You have it round the wrong way, you would need:

  static (inside,outside) tcp outside_ip outside_port inside_ip inside_port

It's confusing but the bit in brackets (for the interfaces) has inside first 
and outside second and then when you specify the IP addresses and ports you 
have outside first, then inside second.

And then you would need an ACL like this:

  access-list 101 permit tcp any host outside_ip outside_port

And then you need to apply the ACL to inbound traffic on the outside 
interface:

  access-group 101 in interface outside


I don't know about using object groups to specify the IP addresses, it 
should work as long as you've got it correct. I would try with putting the 
actual IP addresses in the commands and then once you know it works you can 
change them to objects.

You can find a list of PIX configuration examples here:
http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/prod_configuration_examples_list.html
http://tinyurl.com/3o7gk

One specifically for NAT is:
http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a0080094aad.shtml
http://tinyurl.com/yqeap

Make sure you follow which parts are for earlier PIX versions and your 
version. The earlier versions use the "conduit" command instead of an access 
list.


regards,
Tony

--- On Thu, 16/7/09, Scott Granados <gsgranados at comcast.net> wrote:

> From: Scott Granados <gsgranados at comcast.net>
> Subject: [c-nsp] adding a port forward on a Cisco Pix
> To: cisco-nsp at puck.nether.net
> Date: Thursday, 16 July, 2009, 7:52 AM
> Hi, so I've started working with the
> Pix and am trying to forward port 80 and 443 in from an
> outside facing address to a 10.x space inside. I have
> two basic interfaces (outside and inside) and am running Pix
> 6.3 for firmware.
>
> I was thinking the following line would work but wasn't
> sure if I formatted it correctly.
>
> static (outside,inside) tcp general-internet-rtr-svc-nat 80
> inside-ip-object 80 netmask 255.255.255.255 0 0
>
> general-internet-rtr-svc-nat is an object group name that
> contains a network-object-host with the outside static IP
> defined.
>
> Is this more or less correct? Should I invert the
> address objects or are they in the proper order? Any
> basic pointers or pointers to good examples would be
> appreciated.
>
> Thank you
> Scott
>
>





From saku at ytti.fi  Thu Jul 16 12:30:15 2009
From: saku at ytti.fi (Saku Ytti)
Date: Thu, 16 Jul 2009 19:30:15 +0300
Subject: [c-nsp] edge router BGP
In-Reply-To: <ce2d38bb0907160849x496c4960v928b8b8ccb9a0f61@mail.gmail.com>
References: <C3412C29D7544726BA3D12A8F1C62FAB@EU.corp.clearwire.com>
	<20090716114914.GE20732@ronin.4ever.de>
	<ce2d38bb0907160849x496c4960v928b8b8ccb9a0f61@mail.gmail.com>
Message-ID: <20090716163015.GA19067@mx.ytti.net>

On (2009-07-16 16:49 +0100), Alasdair McWilliam wrote:
 
> 6500s, even with an XL sup, I wouldn't be comfortable loading full BGP
> feeds into it, given it's limitation will always be hardware (amount
> of registers available to store routes in hardware).  I've no

XL has TCAM for 512k IPv4 routes on default carving, configurable to 1M.
ASR1k scales up-to 1M IPv4 routes.

Thanks,
-- 
  ++ytti

From mtinka at globaltransit.net  Thu Jul 16 12:20:03 2009
From: mtinka at globaltransit.net (Mark Tinka)
Date: Fri, 17 Jul 2009 00:20:03 +0800
Subject: [c-nsp] edge router BGP
In-Reply-To: <20090716144243.M24674@fast-serv.com>
References: <C3412C29D7544726BA3D12A8F1C62FAB@EU.corp.clearwire.com>
	<200907162029.31896.mtinka@globaltransit.net>
	<20090716144243.M24674@fast-serv.com>
Message-ID: <200907170020.11857.mtinka@globaltransit.net>

On Thursday 16 July 2009 10:43:32 pm Randy McAnally wrote:

> Could you please expand on or give me a link to
> information I can find about the 6500/7600 issues you
> mentioned?  Thanks!

Gert's been in a good mood giving us his insight on STP 
experiences; I really wouldn't want to "wake" him with this 
6500/7600 stuff :-).

That said, this list is riddled with endless pages of 
useful, operator input on these two platforms. Below would 
be a good place to start:

http://tinyurl.com/m8v87t
http://tinyurl.com/mu6eej

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/20090717/2cd75aa8/attachment.bin>

From lists at motorcitynet.com  Thu Jul 16 13:45:21 2009
From: lists at motorcitynet.com (M Callahan)
Date: Thu, 16 Jul 2009 13:45:21 -0400
Subject: [c-nsp] x6148 vs. x6548
In-Reply-To: <277682.36796.qm@web1209.biz.mail.gq1.yahoo.com>
References: <6069A203FD01884885C037F81DD7508016CE1890E4@wsc-mail-01.intra.nwresd.k12.or.us>
	<d6966e4b0906120636w6d772f9cv49b4dd03e9199419@mail.gmail.com>
	<4A327576.4040004@templin.org>
	<200906121246.01415.mulitskiy@acedsl.com>
	<200906121822.n5CIM8vC018410@sj-core-2.cisco.com>
	<552214.4458.qm@web1216.biz.mail.gq1.yahoo.com>
	<200906221746.n5MHk1xD007539@sj-core-2.cisco.com>
	<277682.36796.qm@web1209.biz.mail.gq1.yahoo.com>
Message-ID: <50797b9b0907161045m22ef5340w9bfe880d738968df@mail.gmail.com>

We have several 3560G switches deployed as access switches in a small data
center environment.  With the increased use of Gig at the access layer, the
notion of using EtherChannel to get increased uplink bandwidth back to a
WS-X6548-GE is something we've been discussing recently too.  As has been
discussed, this won't work the way we'd like it to due to the over
subscription design of the X6548. That said, would an EtherChannel setup
between the SFP ports on the 3560G and a X6516-GBIC card in the 6509 have
any similar type of limitation, or would it work to acheive the increased
uplink bandwidth?

Also, is the only difference between the WS-X6516-GBIC and the
WS-X6516A-GBIC the per port buffer size?


Thanks,

Mike

From leonardo.souza at nec.com.br  Thu Jul 16 13:51:16 2009
From: leonardo.souza at nec.com.br (Leonardo Gama Souza)
Date: Thu, 16 Jul 2009 14:51:16 -0300
Subject: [c-nsp] RES:  per-LSP packet loss / FIB corruption?
In-Reply-To: <4A5F27C0.9040201@imperial.ac.uk>
References: <4A5EF175.5060707@imperial.ac.uk><20090716102838.GA14803@mx.ytti.net>
	<4A5F27C0.9040201@imperial.ac.uk>
Message-ID: <9E07F8717FE8BC4FBAE6860F61EA6C1D027357AA@spsrvmail03.nec.br>

Hi,

> 
> Best way to debug when you've eliminated config errors and
> physical link issues is to use ELAM to capture DBUS/RBUS
> headers, which will tell you, what the platform is going
> to do to the frame.

> Interesting; ELAM is not something I've ever used before. I see
there's 
> a doc on Cluepon - I'll have to take a look.

Some time ago Rodney shared the procedure to do that:

http://puck.nether.net/pipermail/cisco-nsp/2008-September/054801.html


[]s

From justin at justinshore.com  Thu Jul 16 17:20:50 2009
From: justin at justinshore.com (Justin Shore)
Date: Thu, 16 Jul 2009 16:20:50 -0500
Subject: [c-nsp] edge router BGP
In-Reply-To: <200907162029.31896.mtinka@globaltransit.net>
References: <C3412C29D7544726BA3D12A8F1C62FAB@EU.corp.clearwire.com>	<20090716120511.M53115@fast-serv.com>
	<200907162029.31896.mtinka@globaltransit.net>
Message-ID: <4A5F99B2.90602@justinshore.com>

Mark Tinka wrote:
> I was thinking more, ASR1000 series. Will do wire rate, has 
> a large enough control plane to handle multiple full tables 
> to customers, is the natural progression from the 7200-VXR 
> platform, e.t.c.

I second (third?) the ASR 1002 suggestion.  @ list price the 5Gbps ASR 
1002 is only a few $k more than the 7206VXR w/ the NPE-G2 or the 7201. 
It has 5x the backplane to boot plus it's hardware forwarding.  The only 
real downside IMHO is that the unit uses SPAs which require SmartNets 
per SPA (per license and per a lot of other things for that matter too). 
  Still it's a much better box for a little bit more up front.  I plan 
on replacing my 7206 border routers with ASR 1002 or 1004s when the time 
comes.

Justin



From geoff at pendery.net  Thu Jul 16 17:39:13 2009
From: geoff at pendery.net (Geoffrey Pendery)
Date: Thu, 16 Jul 2009 16:39:13 -0500
Subject: [c-nsp] edge router BGP
In-Reply-To: <4A5F99B2.90602@justinshore.com>
References: <C3412C29D7544726BA3D12A8F1C62FAB@EU.corp.clearwire.com>
	<20090716120511.M53115@fast-serv.com>
	<200907162029.31896.mtinka@globaltransit.net>
	<4A5F99B2.90602@justinshore.com>
Message-ID: <d6966e4b0907161439y120c95e6xfa1d14dbdc9d71e9@mail.gmail.com>

As Justin mentioned it's hardware forwarding.  This is mostly a good
thing, and the QFP's will do lots of stuff in hardware, but at least
so far they won't do NBAR HTTP URLs.  Probably not a feature you use
or care about, but there might be another such stray gotcha.  Just
double-check that each of your current software features are supported
in the ASR hardware...


-Geoff


On Thu, Jul 16, 2009 at 4:20 PM, Justin Shore<justin at justinshore.com> wrote:
> Mark Tinka wrote:
>>
>> I was thinking more, ASR1000 series. Will do wire rate, has a large enough
>> control plane to handle multiple full tables to customers, is the natural
>> progression from the 7200-VXR platform, e.t.c.
>
> I second (third?) the ASR 1002 suggestion. ?@ list price the 5Gbps ASR 1002
> is only a few $k more than the 7206VXR w/ the NPE-G2 or the 7201. It has 5x
> the backplane to boot plus it's hardware forwarding. ?The only real downside
> IMHO is that the unit uses SPAs which require SmartNets per SPA (per license
> and per a lot of other things for that matter too). ?Still it's a much
> better box for a little bit more up front. ?I plan on replacing my 7206
> border routers with ASR 1002 or 1004s when the time comes.
>
> 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 Jul 16 18:20:14 2009
From: justin at justinshore.com (Justin Shore)
Date: Thu, 16 Jul 2009 17:20:14 -0500
Subject: [c-nsp] SNMP OID to see if a Tn interface is looped up?
Message-ID: <4A5FA79E.8050807@justinshore.com>

Does anyone happen to know if there's an SNMP OID that one can query to 
see if a standalone T1, T1 channelized inside of a T3 or OC3, or a 
high-capacity TDM interfaces like a T3 is looped up at the CSU?  I've 
had an occasion where a T1 was left looped up by the local-loop provider 
that I didn't discover until troubleshooting the downed circuit the next 
day.  I'd like that type of event to be a warning-level event in Nagios 
(that gets made critical after a handful of hours in that state).  All I 
have to work with right now is down-when-looped which makes the NMS 
report that there's a full blown problem when in fact the interface is 
merely looped up for testing.  This data is reachable via show commands 
but I haven't had any luck with SNMP OIDs at this point.  It would take 
a hefty script to pull out loopback data from the controllers I imagine.

My Google-fu is failing me on this one.  Anyone have any SNMP 
suggestions?  Perhaps I can generate a SNMP trap for such an event.  I'm 
sure I'm not the only one worried about this or who's already faced it. 
  I don't want to be the one who accidentally forgot to loop down a CSU 
when my testing was complete.  This isn't really limited to TDM circuits 
now that there is support for Ethernet loopbacks as well (though I'd 
like to think that it would be harder to forget about Ethernet loopbacks 
than remotely-requested TDM loopbacks).

Thanks
  Justin




From tstevens at cisco.com  Thu Jul 16 18:22:18 2009
From: tstevens at cisco.com (Tim Stevenson)
Date: Thu, 16 Jul 2009 15:22:18 -0700
Subject: [c-nsp] x6148 vs. x6548
In-Reply-To: <50797b9b0907161045m22ef5340w9bfe880d738968df@mail.gmail.co
 m>
References: <6069A203FD01884885C037F81DD7508016CE1890E4@wsc-mail-01.intra.nwresd.k12.or.us>
	<d6966e4b0906120636w6d772f9cv49b4dd03e9199419@mail.gmail.com>
	<4A327576.4040004@templin.org>
	<200906121246.01415.mulitskiy@acedsl.com>
	<200906121822.n5CIM8vC018410@sj-core-2.cisco.com>
	<552214.4458.qm@web1216.biz.mail.gq1.yahoo.com>
	<200906221746.n5MHk1xD007539@sj-core-2.cisco.com>
	<277682.36796.qm@web1209.biz.mail.gq1.yahoo.com>
	<50797b9b0907161045m22ef5340w9bfe880d738968df@mail.gmail.com>
Message-ID: <200907162222.n6GMMMZD017830@sj-core-2.cisco.com>

Mike, please see inline below:

At 10:45 AM 7/16/2009, M Callahan opined:
>We have several 3560G switches deployed as access switches in a 
>small data center environment.  With the increased use of Gig at the 
>access layer, the notion of using EtherChannel to get increased 
>uplink bandwidth back to a WS-X6548-GE is something we've been 
>discussing recently too.  As has been discussed, this won't work the 
>way we'd like it to due to the over subscription design of the 
>X6548. That said, would an EtherChannel setup between the SFP ports 
>on the 3560G and a X6516-GBIC card in the 6509 have any similar type 
>of limitation, or would it work to acheive the increased uplink bandwidth?

6516 is basically 16 1G ports feeding into a single 8G fabric 
channel, so 2:1 oversubscribed if all ports are pumping. But it's not 
port level oversubscription, so you could definitely use this card & 
it is very typically used in this manner.

You just need to engineer it such that enough uplink b/w and agg 
layer capacity exists to support the access layer, based on the 
environment. Oversubscription ratios are very application/environment 
specific, anywhere from 1:1 all the way to 20:1 or more, so some 
baselining etc might be in order.

>
>
>Also, is the only difference between the WS-X6516-GBIC and the 
>WS-X6516A-GBIC the per port buffer size?

Of the top of my head, that, and the replacement of Titan/Medusa 
chips with the Hyperion ASIC for multicast replication & fabric 
interface. Hyperion permits the use of egress replication with the A 
version of the card.

HTH,
Tim




>Thanks,
>
>Mike




Tim Stevenson, tstevens at cisco.com
Routing & Switching CCIE #5561
Technical Marketing Engineer, Cisco Nexus 7000
Cisco - http://www.cisco.com
IP Phone: 408-526-6759
********************************************************
The contents of this message may be *Cisco Confidential*
and are intended for the specified recipients only.


From rwest at zyedge.com  Thu Jul 16 18:44:31 2009
From: rwest at zyedge.com (Ryan West)
Date: Thu, 16 Jul 2009 18:44:31 -0400
Subject: [c-nsp] SNMP OID to see if a Tn interface is looped up?
In-Reply-To: <4A5FA79E.8050807@justinshore.com>
References: <4A5FA79E.8050807@justinshore.com>
Message-ID: <6E21B2BDEF6E714EA0B5BA8D5D0E1401248380AD28@zy-ex1.zyedge.local>

Justin,

Give this a shot:

http://tools.cisco.com/Support/SNMP/do/BrowseMIB.do?local=en&step=2&mibName=CISCO-ICSUDSU-MIB

That MIB contains values for different loop codes.

-ryan

-----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, July 16, 2009 6:20 PM
To: 'Cisco-nsp'
Subject: [c-nsp] SNMP OID to see if a Tn interface is looped up?

Does anyone happen to know if there's an SNMP OID that one can query to 
see if a standalone T1, T1 channelized inside of a T3 or OC3, or a 
high-capacity TDM interfaces like a T3 is looped up at the CSU?  I've 
had an occasion where a T1 was left looped up by the local-loop provider 
that I didn't discover until troubleshooting the downed circuit the next 
day.  I'd like that type of event to be a warning-level event in Nagios 
(that gets made critical after a handful of hours in that state).  All I 
have to work with right now is down-when-looped which makes the NMS 
report that there's a full blown problem when in fact the interface is 
merely looped up for testing.  This data is reachable via show commands 
but I haven't had any luck with SNMP OIDs at this point.  It would take 
a hefty script to pull out loopback data from the controllers I imagine.

My Google-fu is failing me on this one.  Anyone have any SNMP 
suggestions?  Perhaps I can generate a SNMP trap for such an event.  I'm 
sure I'm not the only one worried about this or who's already faced it. 
  I don't want to be the one who accidentally forgot to loop down a CSU 
when my testing was complete.  This isn't really limited to TDM circuits 
now that there is support for Ethernet loopbacks as well (though I'd 
like to think that it would be harder to forget about Ethernet loopbacks 
than remotely-requested TDM loopbacks).

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 Jul 16 19:20:27 2009
From: justin at justinshore.com (Justin Shore)
Date: Thu, 16 Jul 2009 18:20:27 -0500
Subject: [c-nsp] SNMP OID to see if a Tn interface is looped up?
In-Reply-To: <6E21B2BDEF6E714EA0B5BA8D5D0E1401248380AD28@zy-ex1.zyedge.local>
References: <4A5FA79E.8050807@justinshore.com>
	<6E21B2BDEF6E714EA0B5BA8D5D0E1401248380AD28@zy-ex1.zyedge.local>
Message-ID: <4A5FB5BB.4080206@justinshore.com>

Ryan West wrote:
> Justin,
> 
> Give this a shot:
> 
> http://tools.cisco.com/Support/SNMP/do/BrowseMIB.do?local=en&step=2&mibName=CISCO-ICSUDSU-MIB
> 
> That MIB contains values for different loop codes.

Ryan,

That looks like a very useful MIB.  I'll give that a try.

I looked at the source of the check_snmp_int.pl script for Nagios as 
well and noticed that it was built to handle 3 response codes:  up, down 
and testing.  On a hunch I looped up an unused T1 on a T3 controller and 
hit it with a snmpwalk.  Sure enough it listed the looped interface as 
"testing":

IF-MIB::ifOperStatus.28 = INTEGER: testing(3)

check_snmp_int.pl also correctly detected the situation:

Serial1/0/10:0:TESTING: 1 int NOK : CRITICAL

So it looks like that plugin will do what I need if I can figure out how 
to make it only give a warning if the interface is in testing and not a 
critical alarm (warning for say 1hr; then escalate it send our alerts). 
  I want it to warn with no email for about an hour.  Then escalate it 
and send our the alerts.  Should be doable.

Thanks
  Justin






From rwest at zyedge.com  Thu Jul 16 19:26:34 2009
From: rwest at zyedge.com (Ryan West)
Date: Thu, 16 Jul 2009 19:26:34 -0400
Subject: [c-nsp] SNMP OID to see if a Tn interface is looped up?
In-Reply-To: <4A5FB5BB.4080206@justinshore.com>
References: <4A5FA79E.8050807@justinshore.com>
	<6E21B2BDEF6E714EA0B5BA8D5D0E1401248380AD28@zy-ex1.zyedge.local>
	<4A5FB5BB.4080206@justinshore.com>
Message-ID: <6E21B2BDEF6E714EA0B5BA8D5D0E1401248380AD29@zy-ex1.zyedge.local>

Good find.  I was pretty sure that the operstatus MIB had more than 2 values.  We use something similar with Zabbix.  FYI, here are the integer values:

ifOperStatus OBJECT-TYPE
    SYNTAX  INTEGER {
                up(1),        -- ready to pass packets
                down(2),
                testing(3),   -- in some test mode
                unknown(4),   -- status can not be determined
                              -- for some reason.
                dormant(5),
                notPresent(6),    -- some component is missing
                lowerLayerDown(7) -- down due to state of
                                  -- lower-layer interface(s)
            }

-ryan

-----Original Message-----
From: Justin Shore [mailto:justin at justinshore.com] 
Sent: Thursday, July 16, 2009 7:20 PM
To: Ryan West
Cc: 'Cisco-nsp'
Subject: Re: [c-nsp] SNMP OID to see if a Tn interface is looped up?

Ryan West wrote:
> Justin,
> 
> Give this a shot:
> 
> http://tools.cisco.com/Support/SNMP/do/BrowseMIB.do?local=en&step=2&mibName=CISCO-ICSUDSU-MIB
> 
> That MIB contains values for different loop codes.

Ryan,

That looks like a very useful MIB.  I'll give that a try.

I looked at the source of the check_snmp_int.pl script for Nagios as 
well and noticed that it was built to handle 3 response codes:  up, down 
and testing.  On a hunch I looped up an unused T1 on a T3 controller and 
hit it with a snmpwalk.  Sure enough it listed the looped interface as 
"testing":

IF-MIB::ifOperStatus.28 = INTEGER: testing(3)

check_snmp_int.pl also correctly detected the situation:

Serial1/0/10:0:TESTING: 1 int NOK : CRITICAL

So it looks like that plugin will do what I need if I can figure out how 
to make it only give a warning if the interface is in testing and not a 
critical alarm (warning for say 1hr; then escalate it send our alerts). 
  I want it to warn with no email for about an hour.  Then escalate it 
and send our the alerts.  Should be doable.

Thanks
  Justin






From matt at overloaded.net  Thu Jul 16 23:51:27 2009
From: matt at overloaded.net (Matt Buford)
Date: Thu, 16 Jul 2009 22:51:27 -0500
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <6B43981C32F8464CB24CEE209DA32BD302350ADD@kenya.tronet.as>
References: <9DE4AA6876D44B62B87C475B2AFE5514@au.didata.local>
	<a1873f1f0907131438m3f0b4c70r82a953a29042b6d7@mail.gmail.com>
	<1247524340.4661.65.camel@abehat.net.rm.dk>
	<20090714084503.GA15753@lboro.ac.uk>
	<d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>
	<6B43981C32F8464CB24CEE209DA32BD302350ADD@kenya.tronet.as>
Message-ID: <8e157ab40907162051t4d32d6cbudc1dacca82790ed1@mail.gmail.com>

On Wed, Jul 15, 2009 at 8:30 AM, Tomas Daniska <tomas at soitron.com> wrote:

> > On Tue, Jul 14, 2009 at 3:45 AM, <A.L.M.Buxey at lboro.ac.uk> wrote:
> > > things go wonky when you have more than 1800 virtualports per slot
> > > (which you didnt quite reach) (1200 on older eg 100mbit blades)
> > > with 13,000 in total (PVST+), 10,000 in total (RPVST+)
> > >
>
> As a matter of coincidence, I've been in talks recently with our local
> Cisco SEs for some 6k5/3750E design, mostly discussing RSTP vs MST. I
> have asked about the 1800 virtual ports per blade limit and they say
> this only applies to 61xx and 63xx cards - the 65xx and 67xx have no
> such limit. There is a ddts that a message errorneously warning of
> exceeding 1800 virtual ports on a 67xx is removed since SXI (or SXI1 it
> was).
>

Strange, as I have had a number of discussions with my SEs about this issue
and they have never mentioned the limit not applying to certain cards.  This
is the number 1 hardware limitation that affects my design and hardware
purchasing.  The docs seem to clearly state that the limits are per-slot and
do not mention model numbers. However, I can confirm that I have greatly
exceeded this specification for years now without serious wonkyness.  I
have WS-X6516A-GBIC cards running as high as 6,400 virtual port instances.
 I do notice RSTP isn't quite as rapid as it used to be though.  If all STP
instances reconverge at the same time, it might take a second or two.  If
only one VLAN reconverges, it is still sub-second.

Of course, I don't want to just let it grow because I certainly don't want
unexpected future wonkyness to show up.  So, I have capped the size.

These days, my network is chopped up into small VLAN regions where any VLAN
within the region is present on all switches within the region, but is not
available outside of the region.  My data center people would prefer to be
able to physically put servers anywhere in the data center and have all
VLANs available throughout the data center (only requiring them to worry
about putting it in the correct building).  I could do this for them, if not
for the virtual port slot limitations.  Instead, they have to live with
VLANs only being available within the "region" that is capped to a max of a
certain number of racks (usually we attempt to map VLAN regions to physical
rooms).

My Cisco team suggested the Nexus as a potential way to alleviate my 6500
virtual port limitation pain.  I asked for specifics on the STP limits of
the Nexus, and they are significantly lower than the 6500.  Oops.

From saku at ytti.fi  Fri Jul 17 03:01:40 2009
From: saku at ytti.fi (Saku Ytti)
Date: Fri, 17 Jul 2009 10:01:40 +0300
Subject: [c-nsp] Free NMS Tools
In-Reply-To: <4f890e580907030600y3f8e6c15qfa6c4b4db539fec@mail.gmail.com>
References: <F1755DA0C92B4B0F8EEA558869BD8D1B@experienbd1776>
	<4f890e580907030600y3f8e6c15qfa6c4b4db539fec@mail.gmail.com>
Message-ID: <20090717070140.GA22208@mx.ytti.net>

On (2009-07-03 14:00 +0100), Mario Spinthiras wrote:

Hey,

> I would say Zenoss is looking good because of the inventory management you
> can do and because of the logical structure it puts everything in. I wrote
> 
> Everything else just seems inadequate or poor.

I recently spent few moments evaluating zenoss and was not impressed. To me
all OSS NMS solutions out seem like they are made by coder-in-server-admin
not coder-in-network-admin, and as such seem to have much more integration
with servers than with network, zenoss seems like no exception.

My main grief with NMS I've looked at is virtually no integration with network
devices out of the box. Why don't they ship with MIBs or just specific OIDs
for few top vendors important traps etc? Adding appropriate reaction
classification. Networking is comparatively homogeneous environment, unlike
server admins who have high variance in OS and applications, network
operators out there have very similar requirements, allowing very advanced
integration out-of-the-box. People want NMS to automatically monitor BGP,
OSPF, IS-IS, LDP, status of some other CPU/memory than just control-plane
pending few minutes thinking it would be easy to add lot of really common
things here, that would be desired by very many network operators.

Other thing that annoys me is how SNMP pollers are implemented, they're
blocking, giving sucky performance on misbehaving or down nodes. And
even still puzzlingly slow. While having SNMP poller poll 140k OID
per second on 386 class PC is rather trivial, using two process strategy,
where single process spews packets outs, and another listens what comes
back, completely asynchronous, agnostic to any problem host may have.
I've also only seen alarms based on absolute values of different counters,
like CPU, memory, iface error counters etc. While I'd like automatic
trending alarms, so if my memory use for past 5 months was relatively
static, then for few consecutive days has increased steadily, it is
likely memory leak, and I want to know about it, even if I have GB's of
free memory. This type of 'trending' module should be relatively 
easy, and could be reused by any counter values.

I demoed zenoss with 27 routers and it froze trying to poll their
interface (granted there are very many interfaces). (2.3GHz Intel,
with 2GB of memory), turning performance graphs off helped, of course.
Trying to use zenpacks to add (3rd party provided) Cisco MIBs took
hours and failed due to exhausted disk space, not sure which device
it was, as it didn't tell, but smallest is /tmp with 186MB free.

I'd be happy to pay zenoss enteprise costs, if it would have
basics integration with network, but value it actually delivers
to me, is actually so modest, you can pick up any other 
NMS there or hack something on your own. Since most time would
be committed anyhow adding basic functionality.

Thanks,
-- 
  ++ytti

From nick at inex.ie  Fri Jul 17 06:12:19 2009
From: nick at inex.ie (Nick Hilliard)
Date: Fri, 17 Jul 2009 11:12:19 +0100
Subject: [c-nsp] Free NMS Tools
In-Reply-To: <20090717070140.GA22208@mx.ytti.net>
References: <F1755DA0C92B4B0F8EEA558869BD8D1B@experienbd1776>	<4f890e580907030600y3f8e6c15qfa6c4b4db539fec@mail.gmail.com>
	<20090717070140.GA22208@mx.ytti.net>
Message-ID: <4A604E83.8000403@inex.ie>

On 17/07/2009 08:01, Saku Ytti wrote:
> My main grief with NMS I've looked at is virtually no integration with network
> devices out of the box.

Saku,

you've got it all wrong.  Networks run on servers and desktops running 
windows.  That is all.

What is this BGP thing you talk about anyway?  And why would anyone want to 
use it in the Real World?

Nick

From masood at nexlinx.net.pk  Fri Jul 17 09:14:14 2009
From: masood at nexlinx.net.pk (masood at nexlinx.net.pk)
Date: Fri, 17 Jul 2009 18:14:14 +0500 (PKT)
Subject: [c-nsp] Free NMS Tools
In-Reply-To: <4A604E83.8000403@inex.ie>
References: <F1755DA0C92B4B0F8EEA558869BD8D1B@experienbd1776>
	<4f890e580907030600y3f8e6c15qfa6c4b4db539fec@mail.gmail.com>
	<20090717070140.GA22208@mx.ytti.net> <4A604E83.8000403@inex.ie>
Message-ID: <2605.196.46.241.57.1247836454.squirrel@nexmail1.nexlinx.net.pk>




Nick,
Network, Networking, Services, Desktop etc terms you need to
understnd. you can use google uncle to help you. 

(you've got it all wrong. Networks run on servers and desktops running
windows. That is all.)

"Networks run on servers" who said that? in fact networks
does not run on servers, services run on servers (http,ftp,dns,dhcp etc).
Networks run on switches/routers.

understanding of network/networking will definitely help you to
understand BGP :) You are connected to internet because of BGP.. lols


Regards,
Masood


9 08:01, Saku Ytti
wrote: 
>> My main grief with NMS I've looked at is virtually
no integration with 
>> network 
>> devices out of
the box. 
> 
> Saku, 
> 
> you've got it
all wrong. Networks run on servers and desktops running 
>
windows. That is all. 
> 
> What is this BGP thing you
talk about anyway? And why would anyone want 
> to 
> use
it in the Real World? 
> 
> Nick 
>
_______________________________________________ 
> cisco-nsp
mailing list cisco-nsp at puck.nether.net 
>
https://puck.nether.net/mailman/listinfo/cisco-nsp 
> archive at
http://puck.nether.net/pipermail/cisco-nsp/ 
> 




From nick at inex.ie  Fri Jul 17 08:42:43 2009
From: nick at inex.ie (Nick Hilliard)
Date: Fri, 17 Jul 2009 13:42:43 +0100
Subject: [c-nsp] Free NMS Tools
In-Reply-To: <9DD755A6-1E78-48AB-8FB5-7E04C46016D6@jonnynet.net>
References: <F1755DA0C92B4B0F8EEA558869BD8D1B@experienbd1776>
	<4f890e580907030600y3f8e6c15qfa6c4b4db539fec@mail.gmail.com>
	<20090717070140.GA22208@mx.ytti.net> <4A604E83.8000403@inex.ie>
	<2605.196.46.241.57.1247836454.squirrel@nexmail1.nexlinx.net.pk>
	<9DD755A6-1E78-48AB-8FB5-7E04C46016D6@jonnynet.net>
Message-ID: <4A6071C3.7050706@inex.ie>

On 17/07/2009 13:18, Jonny Martin wrote:
> I think there was a touch of sarcasm in his original post. Nick's email
> domain suggests he is familiar with the use of BGP :).

I admit to using BGP now and then.

In fact, it's not just the tools that cause real problems.  We still don't 
even have a multiprotocol bgp-aware SNMP MIB.  It's good that 
draft-ietf-idr-bgp4-mibv2 is in progress, but at the moment, unless you're 
talking about quagga and want to run Jeffrey Haas's reference patches for 
this MIB, you're out of luck.

I am really tired of screen-scraping the output of "show ipv6 bgp blah" or, 
heaven help us, similar commands for inspecting vrfs.  Are we not living in 
2009, and has ipv6 not been on the table for the last 12 years?  Or did I 
miss something?

But with reference to Saku's post, I sympathise completely.  Other tools 
are little different: OpenNMS, JFFNMS (which still requires 
"register_globals" to be enabled - serious!), Hyperic, Zabbix, etc.  They 
are all very server oriented, and don't really do the sort of things I want 
them to do.

Nick

From ross at kallisti.us  Fri Jul 17 09:05:57 2009
From: ross at kallisti.us (Ross Vandegrift)
Date: Fri, 17 Jul 2009 09:05:57 -0400
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <20090716065147.GF290@greenie.muc.de>
References: <9DE4AA6876D44B62B87C475B2AFE5514@au.didata.local>
	<a1873f1f0907131438m3f0b4c70r82a953a29042b6d7@mail.gmail.com>
	<1247524340.4661.65.camel@abehat.net.rm.dk>
	<20090714084503.GA15753@lboro.ac.uk>
	<d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>
	<Pine.LNX.4.61.0907140924470.6312@soloth.lewis.org>
	<d6966e4b0907140724n61be11f5ra851690ceaabbd93@mail.gmail.com>
	<20090714150036.GP290@greenie.muc.de>
	<20090716032712.GA2111@kallisti.us>
	<20090716065147.GF290@greenie.muc.de>
Message-ID: <20090717130557.GA14202@kallisti.us>

On Thu, Jul 16, 2009 at 08:51:47AM +0200, Gert Doering wrote:
> On Wed, Jul 15, 2009 at 11:27:12PM -0400, Ross Vandegrift wrote:
> > On Tue, Jul 14, 2009 at 05:00:36PM +0200, Gert Doering wrote:
> > > <rant>
> > > MST is what comes out if vendor committees get together, and agree to
> > > implement the least common determinator in the most complicated way.
> > > </rant>
> > 
> > I completely disagree - it's what comes out of solving problems
> > related to the LAN - the LOCAL area network.  In virtualized LANs,
> > there's typically only a few possible physical topologies that can
> > exist.  MST seeks to exploit this to lower the amount of processing
> > power that is required.
> 
> Since MST was standardized long before the "virtualized LAN" environments
> were common, this is a nice after-the-fact explanation - but the fact
> that *years after protocol design*, networks have emerged that make MST
> actually work doesn't make it a better protocol.

I think you've misunderstood me - by "virtualized LAN" I meant VLAN,
not VPLS.  It didn't take years for these designs to come up - the
datacenter we run is a bog-standard, utterly uninteresting case of a few
thousand servers, in a few thousands VLANs, with a pair of HSRP
routers.

The point of MST is to realize that there's never going to be more
than two possible forwarding topologies, and computing more is a total
waste.  It's a perfectly fine protocol at acheiving that goal.  I
realize you might not care about that goal, and that's okay.

I'll go a step further - I doubt that there's a substantially more
optimal way to compute only the valid topologies.

-- 
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 geoff at pendery.net  Fri Jul 17 09:38:26 2009
From: geoff at pendery.net (Geoffrey Pendery)
Date: Fri, 17 Jul 2009 08:38:26 -0500
Subject: [c-nsp] x6148 vs. x6548
In-Reply-To: <200907162222.n6GMMMZD017830@sj-core-2.cisco.com>
References: <6069A203FD01884885C037F81DD7508016CE1890E4@wsc-mail-01.intra.nwresd.k12.or.us>
	<d6966e4b0906120636w6d772f9cv49b4dd03e9199419@mail.gmail.com>
	<4A327576.4040004@templin.org>
	<200906121246.01415.mulitskiy@acedsl.com>
	<200906121822.n5CIM8vC018410@sj-core-2.cisco.com>
	<552214.4458.qm@web1216.biz.mail.gq1.yahoo.com>
	<200906221746.n5MHk1xD007539@sj-core-2.cisco.com>
	<277682.36796.qm@web1209.biz.mail.gq1.yahoo.com>
	<50797b9b0907161045m22ef5340w9bfe880d738968df@mail.gmail.com>
	<200907162222.n6GMMMZD017830@sj-core-2.cisco.com>
Message-ID: <d6966e4b0907170638h3c1175beqe0a2d64c1cab44c@mail.gmail.com>

Excellent information, thanks for that.  In my case, we're looking at
using the 6516A cards with Sup32's, so instead of the 8G fabric we're
looking at sharing the 32G bus.  In theory, if this was the only line
card in the whole chassis (unlikely, and it's not, but just for the
sake of argument) would this actually yield no oversubscription?  Or
even with two 6516A cards?  Or is there an additional bottleneck I'm
missing?


-Geoff


On Thu, Jul 16, 2009 at 5:22 PM, Tim Stevenson<tstevens at cisco.com> wrote:
> Mike, please see inline below:
>
> At 10:45 AM 7/16/2009, M Callahan opined:
>>
>> We have several 3560G switches deployed as access switches in a small data
>> center environment. ?With the increased use of Gig at the access layer, the
>> notion of using EtherChannel to get increased uplink bandwidth back to a
>> WS-X6548-GE is something we've been discussing recently too. ?As has been
>> discussed, this won't work the way we'd like it to due to the over
>> subscription design of the X6548. That said, would an EtherChannel setup
>> between the SFP ports on the 3560G and a X6516-GBIC card in the 6509 have
>> any similar type of limitation, or would it work to acheive the increased
>> uplink bandwidth?
>
> 6516 is basically 16 1G ports feeding into a single 8G fabric channel, so
> 2:1 oversubscribed if all ports are pumping. But it's not port level
> oversubscription, so you could definitely use this card & it is very
> typically used in this manner.
>
> You just need to engineer it such that enough uplink b/w and agg layer
> capacity exists to support the access layer, based on the environment.
> Oversubscription ratios are very application/environment specific, anywhere
> from 1:1 all the way to 20:1 or more, so some baselining etc might be in
> order.
>
>>
>>
>> Also, is the only difference between the WS-X6516-GBIC and the
>> WS-X6516A-GBIC the per port buffer size?
>
> Of the top of my head, that, and the replacement of Titan/Medusa chips with
> the Hyperion ASIC for multicast replication & fabric interface. Hyperion
> permits the use of egress replication with the A version of the card.
>
> HTH,
> Tim
>
>
>
>
>> Thanks,
>>
>> Mike
>
>
>
>
> Tim Stevenson, tstevens at cisco.com
> Routing & Switching CCIE #5561
> Technical Marketing Engineer, Cisco Nexus 7000
> Cisco - http://www.cisco.com
> IP Phone: 408-526-6759
> ********************************************************
> The contents of this message may be *Cisco Confidential*
> and are intended for the specified recipients only.
>
> _______________________________________________
> cisco-nsp mailing list ?cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From ak at gaaga.org  Fri Jul 17 09:48:41 2009
From: ak at gaaga.org (Andrey Kozlov)
Date: Fri, 17 Jul 2009 16:48:41 +0300
Subject: [c-nsp] QoS & sub-interfaces
Message-ID: <001b01ca06e5$4d163960$e742ac20$@org>

Hi, evereone!

We have to share our summary bandwidth in equal parts between 5 customers.
Network contains border router (br, 7206VXR) and 3 backbone switches (bbsw,
3750).


Could you please clarify are any limitations exists to configure QoS
features (shaping/policing) on dot1q sub-interfaces?
And, according to best practice, where is the write place to shape a traffic
- on br or bbsws?

Cheers.
Andrey.


From bergonz at labs.it  Fri Jul 17 09:26:28 2009
From: bergonz at labs.it (Michele Bergonzoni)
Date: Fri, 17 Jul 2009 15:26:28 +0200
Subject: [c-nsp] Free NMS Tools
In-Reply-To: <mailman.4289.1247832681.2287.cisco-nsp@puck.nether.net>
References: <mailman.4289.1247832681.2287.cisco-nsp@puck.nether.net>
Message-ID: <4A607C04.6080500@labs.it>

Saku Ytti <saku at ytti.fi> said:

> To me all OSS NMS solutions out seem like they are made by 
> coder-in-server-admin not coder-in-network-admin, and as such seem to
>  have much more integration with servers than with network

This is one of the reasons why over the years we developed sanet, the
other being that many NMSs are very chatty and tend to keep you up all 
night when relayed on pagers and SMS.

Sanet is OSS but in prerelease, meaning that we use it and it works, but
its documentation is not quite complete and it is not easy to install.
If you are willing to setup many python packages by hand and to explore
funcionalities without a concise HOWTO, or if you are just interested in
the OIDs, you can find it at sanet.sf.net, the SVN version being much
better (expecially for maps and reports) than the downloadable version.

We use it mainly in multivendor corporate networks, but we have one case 
of cisco MPLS carrier network.

> Why don't they ship with MIBs or just specific OIDs for few top
> vendors important traps etc?

sanet has a a library of checks for common cisco, HP, fortigate and 
other vendor's OIDs. Sorry we don't collect traps nor syslog in the 
sanet DB, we usually transform traps to syslog (net-snmp snmptrapd) and 
collect syslog (we are accustomed to grepping the results).

> Adding appropriate reaction classification.

Sanet does not react. You can trivially achieve that by binding scripts
to emails, etc., but we are quite scared of this kind of triggering and
we don't do it (yet).

> People want NMS to automatically monitor BGP

In the library there is the check for the BGP neighborship state:

"1.3.6.1.2.1.15.3.1.2.$peer_ip:$community@$node == 6"

it is not "automatic" because in sanet you have to decide all the
monitoring that you want it to do.

> OSPF

We have the OSPF neighborship state check:

"1.3.6.1.2.1.14.10.1.6.byRegexpUnique(1.3.6.1.2.1.4.20.1.2,^$ifindex$).0:$linked_community@$linked_node
== 8"

but it works only for point-to-point links. I'm sure we can make it better.

> IS-IS

Sorry no IS-IS here, but of course you can define your own if you know
the OIDs. Please contribute it back if you do.

> LDP

We have an LDP neighborship check:

"1.3.6.1.2.1.10.166.4.1.3.2.1.2.byBinaryIP(1.3.6.1.2.1.10.166.4.1.3.2.1.5:$community@$node,$peer_ip):$community@$node
== 2"

> status of some other CPU/memory than just control-plane

Well, for IOS we usually check processor memory and IO memory. OIDs and
suggestions are very, very welcome.

> Other thing that annoys me is how SNMP pollers are implemented, 
> they're blocking

You are definitely right. Our poller is multithreaded but each thread is
blocking, with adjustable timeouts.

> While having SNMP poller poll 140k OID per second on 386 class PC is
> rather trivial, using two process strategy, where single process
> spews packets outs, and another listens what comes back, completely
> asynchronous

It was not so trivial for us, so we made it synchronous. The tricky part
is to collect all the SNMP vars used to form an expression in the same
moment (of course with some approximation), remembering what you asked
for at each poll cycle. It is trivial if you just check variables
against ranges, but we build complex expressions with current and past
variables.

Anyway, patches are welcome...

> I've also only seen alarms based on absolute values of different
> counters

sanet can combine current and past (last poll cycle) vars, like this
expression for a threshold on broadcast packets received:

"((1.3.6.1.2.1.2.2.1.12.$ifindex:$community@$node -
1.3.6.1.2.1.2.2.1.12.$ifindex#$node) / $delta) < $threshold"

($delta is the time in second since last poll)

> This type of 'trending' module should be relatively easy, and could
> be reused by any counter values.

This is a good idea, I will try to think about how this can fit into our
existing software or if a new check type is needed for that.

> I demoed zenoss with 27 routers and it froze trying to poll their 
> interface (granted there are very many interfaces)

We measure installations from the number of targets (yes/no checks) and
measures (graphs). One of our big ones is:

root at XXXXXX:~# sanet-cli
Benvenuti in SANET 2 su XXXXX

sanet# sh ver
...
Configuration defines 831 interfaces, 523 nodes, 409 links, 9868
targets, 2089 measures.
Targets summary: 9 down, 1 failing, 38 uncheckable, 0 out of time, 9820 up
Measures summary: 2042 updated in last 2 mins, 2089 in last 5 mins, 2089
in last 30 mins

(this is running on a XEN VM, I/O being the bottleneck)

I'm sure people on this list will appreciate the configuration via CLI 
(web is used for displaying the status), which is shamelessly copied 
from IOS. This was "sh ver", and in order to configure monitoring you 
start with "conf t". You will probably appreciate physical maps (a /30 
is a line, not a line with a cloud in between), NTP checks, IPv4/IPv6 
pings with adjustable payload length, iface designation by name, MAC, 
IP, CDP neighbor, route, IOS description, etc (no ifindex blues).

Hope this helps,
					Bergonz


-- 
Ing. Michele Bergonzoni - Laboratori Guglielmo Marconi S.p.a.
Phone:+39-051-4392826 Fax:+39-051-6153683 e-mail: bergonz at labs.it
alt.advanced.networks.design.configure.operate

From geoff at pendery.net  Fri Jul 17 10:09:30 2009
From: geoff at pendery.net (Geoffrey Pendery)
Date: Fri, 17 Jul 2009 09:09:30 -0500
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <20090717130557.GA14202@kallisti.us>
References: <9DE4AA6876D44B62B87C475B2AFE5514@au.didata.local>
	<1247524340.4661.65.camel@abehat.net.rm.dk>
	<20090714084503.GA15753@lboro.ac.uk>
	<d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>
	<Pine.LNX.4.61.0907140924470.6312@soloth.lewis.org>
	<d6966e4b0907140724n61be11f5ra851690ceaabbd93@mail.gmail.com>
	<20090714150036.GP290@greenie.muc.de>
	<20090716032712.GA2111@kallisti.us>
	<20090716065147.GF290@greenie.muc.de>
	<20090717130557.GA14202@kallisti.us>
Message-ID: <d6966e4b0907170709h27e8d6e4v7d38e386d92b7ffc@mail.gmail.com>

"The point of MST is to realize that there's never going to be more
than two possible forwarding topologies, and computing more is a total
waste."

But that statement is specific to your network design and your
topology.  Surely you're not claiming that it's never possible to
build a network with more than two topologies?  Surely you mean to say
that "the place where MST is useful is in scenarios where there's
never going to be more than two possible forwarding topologies, and
computing more is a total waste."

I believe the consensus here is that yes, MST works just great, for a
certain specific scenario.  I called it a car vs a boat earlier, but
we can go to a toolbox metaphor if that works better.  MST is a lovely
hammer, but when I've got screws to screw in, I don't want a hammer.
Nor do I want the screwdriver when it comes time to drive in nails.  I
want both tools in my toolbox, and I'll use the appropriate one at the
appropriate time.

I'm not trying to say "MST is never useful and always terrible", but rather:
"MST doesn't fit all scenarios.  For many scenarios, RPVST is much
better, and it's a shame that we've only got an open standard MST,
rather than two open standards to cover both scenarios."

When you're given the mandate/requirement/strong-preference of using
open standard protocols rather than Cisco proprietary ones (not an
unreasonable goal) it leads to great frustration, because you end up
having to hammer in screws.  This frustration apparently leads to some
ranting on email lists.


-Geoff


On Fri, Jul 17, 2009 at 8:05 AM, Ross Vandegrift<ross at kallisti.us> wrote:
> On Thu, Jul 16, 2009 at 08:51:47AM +0200, Gert Doering wrote:
>> On Wed, Jul 15, 2009 at 11:27:12PM -0400, Ross Vandegrift wrote:
>> > On Tue, Jul 14, 2009 at 05:00:36PM +0200, Gert Doering wrote:
>> > > <rant>
>> > > MST is what comes out if vendor committees get together, and agree to
>> > > implement the least common determinator in the most complicated way.
>> > > </rant>
>> >
>> > I completely disagree - it's what comes out of solving problems
>> > related to the LAN - the LOCAL area network. ?In virtualized LANs,
>> > there's typically only a few possible physical topologies that can
>> > exist. ?MST seeks to exploit this to lower the amount of processing
>> > power that is required.
>>
>> Since MST was standardized long before the "virtualized LAN" environments
>> were common, this is a nice after-the-fact explanation - but the fact
>> that *years after protocol design*, networks have emerged that make MST
>> actually work doesn't make it a better protocol.
>
> I think you've misunderstood me - by "virtualized LAN" I meant VLAN,
> not VPLS. ?It didn't take years for these designs to come up - the
> datacenter we run is a bog-standard, utterly uninteresting case of a few
> thousand servers, in a few thousands VLANs, with a pair of HSRP
> routers.
>
> The point of MST is to realize that there's never going to be more
> than two possible forwarding topologies, and computing more is a total
> waste. ?It's a perfectly fine protocol at acheiving that goal. ?I
> realize you might not care about that goal, and that's okay.
>
> I'll go a step further - I doubt that there's a substantially more
> optimal way to compute only the valid topologies.
>
> --
> 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
> _______________________________________________
> cisco-nsp mailing list ?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 at ytti.fi  Fri Jul 17 10:35:14 2009
From: saku at ytti.fi (Saku Ytti)
Date: Fri, 17 Jul 2009 17:35:14 +0300
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <d6966e4b0907170709h27e8d6e4v7d38e386d92b7ffc@mail.gmail.com>
References: <1247524340.4661.65.camel@abehat.net.rm.dk>
	<20090714084503.GA15753@lboro.ac.uk>
	<d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>
	<Pine.LNX.4.61.0907140924470.6312@soloth.lewis.org>
	<d6966e4b0907140724n61be11f5ra851690ceaabbd93@mail.gmail.com>
	<20090714150036.GP290@greenie.muc.de>
	<20090716032712.GA2111@kallisti.us>
	<20090716065147.GF290@greenie.muc.de>
	<20090717130557.GA14202@kallisti.us>
	<d6966e4b0907170709h27e8d6e4v7d38e386d92b7ffc@mail.gmail.com>
Message-ID: <20090717143514.GA24138@mx.ytti.net>

On (2009-07-17 09:09 -0500), Geoffrey Pendery wrote:
 
> I'm not trying to say "MST is never useful and always terrible", but rather:
> "MST doesn't fit all scenarios.  For many scenarios, RPVST is much
> better, and it's a shame that we've only got an open standard MST,
> rather than two open standards to cover both scenarios."

Not arguing against, but would you happen to have example where
MST does not fit? All my respect to the person who decidedly
engineers L2 network with more then 65 planned and documented
topologies[0], and succeeds to deliver higher SLA than what is possible
with fewer.

[0] 2960 can handle 65 MST instances, http://www.cisco.com/en/US/docs/switches/lan/catalyst2960/software/release/12.2_46_se/configuration/guide/swmstp.html#wp1034497

-- 
  ++ytti

From saku at ytti.fi  Fri Jul 17 10:50:21 2009
From: saku at ytti.fi (Saku Ytti)
Date: Fri, 17 Jul 2009 17:50:21 +0300
Subject: [c-nsp] Free NMS Tools
In-Reply-To: <4A607C04.6080500@labs.it>
References: <mailman.4289.1247832681.2287.cisco-nsp@puck.nether.net>
	<4A607C04.6080500@labs.it>
Message-ID: <20090717145021.GB24138@mx.ytti.net>

On (2009-07-17 15:26 +0200), Michele Bergonzoni wrote:

First thank you for your reply Michele, SANET sounds interesting,
and I'll definitely take a look at it.

> >People want NMS to automatically monitor BGP
> In the library there is the check for the BGP neighborship state:
> "1.3.6.1.2.1.15.3.1.2.$peer_ip:$community@$node == 6"
> 
> it is not "automatic" because in sanet you have to decide all the
> monitoring that you want it to do.

My view for defaults is, if users device has BGP neighbours, vastly larger
amount of users want them to be monitored than not, so my sane default
would then to have feature default on.

Also monitoring BGP is not just up/down, but also amount of prefixes
received, of course amount of people care about this, is lot smaller than
those who care about up/down, but SP's care.

> >IS-IS
> Sorry no IS-IS here, but of course you can define your own if you know
> the OIDs. Please contribute it back if you do.

As you explained that at the moment is is rather chore to setup the
program, I guess I'll wait for the more official launch. But I'll
definitely take a look at it, and will commit something back, if I'll use
it. Thanks.

> >This type of 'trending' module should be relatively easy, and could
> This is a good idea, I will try to think about how this can fit into our
> existing software or if a new check type is needed for that.

One way could be, that you project current number with average change from
last n hours|days|weeks|months and see if projected number hits limit
within n hours|days|weeks|months.

> We measure installations from the number of targets (yes/no checks) and
> measures (graphs). One of our big ones is:
> 
> root at XXXXXX:~# sanet-cli
> Configuration defines 831 interfaces, 523 nodes, 409 links, 9868

One of the boxes in my zenoss quick demo had more interfaces, and the 20
boxes were just few I chose for the demo. I have no trouble buying more
boxes to handle all the devices I'd need to, but I'd hope single server
could cope with bit higher number than 20 boxes.

-- 
  ++ytti

From p.mayers at imperial.ac.uk  Fri Jul 17 10:55:06 2009
From: p.mayers at imperial.ac.uk (Phil Mayers)
Date: Fri, 17 Jul 2009 15:55:06 +0100
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <20090717143514.GA24138@mx.ytti.net>
References: <1247524340.4661.65.camel@abehat.net.rm.dk>	<20090714084503.GA15753@lboro.ac.uk>	<d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>	<Pine.LNX.4.61.0907140924470.6312@soloth.lewis.org>	<d6966e4b0907140724n61be11f5ra851690ceaabbd93@mail.gmail.com>	<20090714150036.GP290@greenie.muc.de>	<20090716032712.GA2111@kallisti.us>	<20090716065147.GF290@greenie.muc.de>	<20090717130557.GA14202@kallisti.us>	<d6966e4b0907170709h27e8d6e4v7d38e386d92b7ffc@mail.gmail.com>
	<20090717143514.GA24138@mx.ytti.net>
Message-ID: <4A6090CA.7090702@imperial.ac.uk>

Saku Ytti wrote:
> On (2009-07-17 09:09 -0500), Geoffrey Pendery wrote:
>  
>> I'm not trying to say "MST is never useful and always terrible", but rather:
>> "MST doesn't fit all scenarios.  For many scenarios, RPVST is much
>> better, and it's a shame that we've only got an open standard MST,
>> rather than two open standards to cover both scenarios."
> 
> Not arguing against, but would you happen to have example where
> MST does not fit? All my respect to the person who decidedly
> engineers L2 network with more then 65 planned and documented
> topologies[0], and succeeds to deliver higher SLA than what is possible
> with fewer.

"Does not fit" need not be limited solely to the number of available 
topologies.

Personally I find the (lack of) graceful change control the big killer. 
Our network is simply *NOT* capable of "defining the mappings ahead of 
time and never changing them" because of inherited legacy. I cannot 
tolerate the outages we'd need to incur every time a VLAN was added or 
removed, and I'm certainly not prepared to spend the many man-months 
re-numbering every vlan tag on campus into some arbitrary grouping just 
so I can run MST, when PVST works *now*.

I probably *could* run MST, after a lot of work, but why would I want to?

In addition, I have serious concerns about the scope of instance 0, 
particularly in the topology we run (a collapsed core/distribution 
triangle).

When I tried it on the bench, I could not come up with an MST setup that 
worked.

From jlewis at lewis.org  Fri Jul 17 11:03:50 2009
From: jlewis at lewis.org (Jon Lewis)
Date: Fri, 17 Jul 2009 11:03:50 -0400 (EDT)
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <20090717143514.GA24138@mx.ytti.net>
References: <1247524340.4661.65.camel@abehat.net.rm.dk>
	<20090714084503.GA15753@lboro.ac.uk>
	<d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>
	<Pine.LNX.4.61.0907140924470.6312@soloth.lewis.org>
	<d6966e4b0907140724n61be11f5ra851690ceaabbd93@mail.gmail.com>
	<20090714150036.GP290@greenie.muc.de>
	<20090716032712.GA2111@kallisti.us>
	<20090716065147.GF290@greenie.muc.de>
	<20090717130557.GA14202@kallisti.us>
	<d6966e4b0907170709h27e8d6e4v7d38e386d92b7ffc@mail.gmail.com>
	<20090717143514.GA24138@mx.ytti.net>
Message-ID: <Pine.LNX.4.61.0907171054340.6312@soloth.lewis.org>

On Fri, 17 Jul 2009, Saku Ytti wrote:

> On (2009-07-17 09:09 -0500), Geoffrey Pendery wrote:
>
>> I'm not trying to say "MST is never useful and always terrible", but rather:
>> "MST doesn't fit all scenarios.  For many scenarios, RPVST is much
>> better, and it's a shame that we've only got an open standard MST,
>> rather than two open standards to cover both scenarios."
>
> Not arguing against, but would you happen to have example where
> MST does not fit? All my respect to the person who decidedly
> engineers L2 network with more then 65 planned and documented
> topologies[0], and succeeds to deliver higher SLA than what is possible
> with fewer.

What about a setup where you have a dual router/switch (6500s) core and 
lots of redundantly uplinked smaller switches with customer servers 
connected.  This seems like a perfect case for MST.  But, suppose you add 
a few trunks (perhaps even redundant) to the core switches from metro 
ethernet providers who bring you metro ethernet customer connections, each 
as their own vlan.  Now you have switches participating in STP that you 
don't control.

In cisco's PVST -> MST migration document, they say MST can interact with 
PVST, but that you should make sure the MST bridge is the root for all 
VLANs allowed on the trunk to a PVST bridge.  They don't say what happens 
if the PVST bridge becomes the root for the CST, but they make it sound 
like you don't want to find out.

http://l.pr/a4183/PVST-MST-Migration

----------------------------------------------------------------------
  Jon Lewis                   |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

From saku at ytti.fi  Fri Jul 17 11:10:22 2009
From: saku at ytti.fi (Saku Ytti)
Date: Fri, 17 Jul 2009 18:10:22 +0300
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <4A6090CA.7090702@imperial.ac.uk>
References: <d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>
	<Pine.LNX.4.61.0907140924470.6312@soloth.lewis.org>
	<d6966e4b0907140724n61be11f5ra851690ceaabbd93@mail.gmail.com>
	<20090714150036.GP290@greenie.muc.de>
	<20090716032712.GA2111@kallisti.us>
	<20090716065147.GF290@greenie.muc.de>
	<20090717130557.GA14202@kallisti.us>
	<d6966e4b0907170709h27e8d6e4v7d38e386d92b7ffc@mail.gmail.com>
	<20090717143514.GA24138@mx.ytti.net>
	<4A6090CA.7090702@imperial.ac.uk>
Message-ID: <20090717151022.GA24159@mx.ytti.net>

On (2009-07-17 15:55 +0100), Phil Mayers wrote:

> In addition, I have serious concerns about the scope of instance 0,
> particularly in the topology we run (a collapsed core/distribution
> triangle).
> 
> When I tried it on the bench, I could not come up with an MST setup
> that worked.

If working is setup where each host in L2 has connection to other hosts
in the L2, then MST really should work in any topology where classical
STP would work. So assuming you'd dump all VLANs to single user
MST instance, it would be like classical STP, but with faster
convergency.

MST/PVST boundary operation can cause lot of damage, unless carefully
planned. But as always, legacy networks and migrations are the hardest.
I'd have juicy example what can happen when you have PVST and MST access
networks and you start selling EoMPLS.
L2 ethernet is so wonderful way to break lot fast.


-- 
  ++ytti

From BBlackford at nwresd.k12.or.us  Fri Jul 17 11:17:57 2009
From: BBlackford at nwresd.k12.or.us (Bill Blackford)
Date: Fri, 17 Jul 2009 08:17:57 -0700
Subject: [c-nsp] Software versioning on SUP720s
Message-ID: <6069A203FD01884885C037F81DD7508016CF7450DA@wsc-mail-01.intra.nwresd.k12.or.us>

I recently installed these sups and the 6748. I'm noticing that the active sup lists the IOS I'm booting up from the CF card and the in-active sup lists the IOS on sup-bootflash. The 6748 lists the newer IOS as well. 

1. Is this a problem?
2. If #1 = yes, then how must one fix the problem?

Thank you


Mod Ports Card Type                              Model              Serial No.
--- ----- -------------------------------------- ------------------ -----------
  1   48  48 port 10/100 mb RJ45                 WS-X6348-RJ-45     SAL
  2   48  CEF720 48 port 10/100/1000mb Ethernet  WS-X6748-GE-TX     SAL
  3    8  8 port 1000mb GBIC Enhanced QoS        WS-X6408A-GBIC     SAD
  4   16  16 port 1000mb GBIC ethernet           WS-X6416-GBIC      SAL
  5    2  Supervisor Engine 720 (Active)         WS-SUP720-3BXL     SAL
  6    2  Supervisor Engine 720 (Cold)           WS-SUP720-3BXL     SAL

Mod MAC addresses                       Hw    Fw           Sw           Status
--- ---------------------------------- ------ ------------ ------------ -------
  1  0004.2861.2750 to 0004.2861.277f   2.2   5.4(2)       8.7(0.22)BUB Ok
  2  0025.840c.9310 to 0025.840c.933f   3.0   12.2(18r)S1  12.2(33)SXH5 Ok
  3  0002.fc25.0984 to 0002.fc25.098b   1.3   5.4(2)       8.7(0.22)BUB Ok
  4  0008.a4f6.1784 to 0008.a4f6.1793   2.2   5.4(2)       8.7(0.22)BUB Ok
  5  001f.6c77.13b0 to 001f.6c77.13b3   5.8   8.5(3)       12.2(33)SXH5 Ok
  6  001f.6c77.13c8 to 001f.6c77.13cb   5.8   8.5(3)       12.2(18)SXF1 Ok

Mod  Sub-Module                  Model              Serial       Hw     Status
---- --------------------------- ------------------ ----------- ------- -------
  2  Centralized Forwarding Card WS-F6700-CFC       SAL          4.1    Ok
  5  Policy Feature Card 3       WS-F6K-PFC3BXL     SAL          1.10   Ok
  5  MSFC3 Daughterboard         WS-SUP720          SAL          3.3    Ok
  6  Policy Feature Card 3       WS-F6K-PFC3BXL     SAL          1.10   Ok
  6  MSFC3 Daughterboard         WS-SUP720          SAL          3.3    Ok

Mod  Online Diag Status
---- -------------------
  1  Pass
  2  Pass
  3  Pass
  4  Pass
  5  Pass
  6  Pass



-b

--
Bill Blackford                     
Senior Network Engineer            
Northwest Regional ESD             

my /home away from home



From saku at ytti.fi  Fri Jul 17 11:29:21 2009
From: saku at ytti.fi (Saku Ytti)
Date: Fri, 17 Jul 2009 18:29:21 +0300
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <Pine.LNX.4.61.0907171054340.6312@soloth.lewis.org>
References: <d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>
	<Pine.LNX.4.61.0907140924470.6312@soloth.lewis.org>
	<d6966e4b0907140724n61be11f5ra851690ceaabbd93@mail.gmail.com>
	<20090714150036.GP290@greenie.muc.de>
	<20090716032712.GA2111@kallisti.us>
	<20090716065147.GF290@greenie.muc.de>
	<20090717130557.GA14202@kallisti.us>
	<d6966e4b0907170709h27e8d6e4v7d38e386d92b7ffc@mail.gmail.com>
	<20090717143514.GA24138@mx.ytti.net>
	<Pine.LNX.4.61.0907171054340.6312@soloth.lewis.org>
Message-ID: <20090717152921.GB24159@mx.ytti.net>

On (2009-07-17 11:03 -0400), Jon Lewis wrote:
 
> What about a setup where you have a dual router/switch (6500s) core
> and lots of redundantly uplinked smaller switches with customer
> servers connected.  This seems like a perfect case for MST.  But,
> suppose you add a few trunks (perhaps even redundant) to the core
> switches from metro ethernet providers who bring you metro ethernet
> customer connections, each as their own vlan.  Now you have switches
> participating in STP that you don't control.

Well I wouldn't talk STP to my customers, but would use pseudowire
with STP tunneling. Even if you have PVST it is big risk to talk
STP to customers, as they can make your STPd so busy, it stop
sending BPDU's, and neighbour will open link, forming loop
and wonderful broadcast storm.
Having said that, how would it be different to PVST, if you'd
have MST with core instance and customer instances? 

> In cisco's PVST -> MST migration document, they say MST can interact
> with PVST, but that you should make sure the MST bridge is the root
> for all VLANs allowed on the trunk to a PVST bridge.  They don't say
> what happens if the PVST bridge becomes the root for the CST, but
> they make it sound like you don't want to find out.
> 
> http://l.pr/a4183/PVST-MST-Migration

I guess I have to explain the situation I mentioned in the previous 
email, hopefully I can explain it, without pen and paper somewhat
coherently

Assume MPLS network, where you have various PE boxes and several
separate L2 access rings connected to those PE boxes.
Assume EoMPLS services, what is mostly sold from several PE to couple few
PE's (so few PE's have NNI, to which EoMPLS are terminated from majority of
the PE's).

Now you configure one more EoMPLS tunnel, business as usual.  Via this
EoMPLS tunnel inferior PVST BPDU is send to one of the the 'EoMPLS HUB PE',
the HUB PE sends it towards access switch, which is MST. As it notices
inferior PVST BPDU it starts generating superior PVST BPDU's in every VLAN
every 2s towards the HUB PE.

Now as the HUB PE has many EoMPLS's, these superior PVST BPDU's travel to
many many PE's in the network. And from these PE's they are sent towards
that PE's access network. Here's the kicker some PE's view it as superior
BPDU, and go to root guard, others who do not view it as superior, continue
propagating it in all VLANs.

So now I have several PE boxes not connected to access network at all, as
switchport is in root guard. Of course all this happened within second,
things just blew up all around. Rolling back the originally added new
EoMPLS has no effect, as there are now many ports in network in PVST/MST
boundary mode, generating BPDU's in every VLAN.

Setting metroring priority to 0 wouldn't fix anything, we'd just move the
superior/inferior decision to MAC address, and again some ports would be
root guarded some in boundary spewing superior BPDU's.

Only way to fix your network in above situation is to shutdown all the
ports in boundary mode, make sure they're removed from boundary operation
and bring them back up when you're sure they are not receiving PVST's
anymore. Even one box left, will propagate error again throughout the
network.

After this, we added bpdufilter between PE<->Switch, which in retrospect
we should have done, the day we started deploying EoMPLS. But what
I'd really hope would be that PVST/MST boundary would generate PVST
BPDU only for the VLAN where it has received PVST BPDU, not for
every VLAN, then the problem wouldn't propagate uncontrollably.


-- 
  ++ytti

From mhuff at ox.com  Fri Jul 17 11:37:34 2009
From: mhuff at ox.com (Matthew Huff)
Date: Fri, 17 Jul 2009 11:37:34 -0400
Subject: [c-nsp] Software versioning on SUP720s
In-Reply-To: <6069A203FD01884885C037F81DD7508016CF7450DA@wsc-mail-01.intra.nwresd.k12.or.us>
References: <6069A203FD01884885C037F81DD7508016CF7450DA@wsc-mail-01.intra.nwresd.k12.or.us>
Message-ID: <483E6B0272B0284BA86D7596C40D29F9D122127F98@PUR-EXCH07.ox.com>

Yes, it's a problem.

do a "show run | include boot system" to see what the boot string says.

also do a 'show boot' and 'show redundancy'.

I bet you are missing the image on the redundant sup. Do a "dir disk0:" and
a "dir slavedisk0:" or "disk1" depending on the boot string



----
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 Bill Blackford
> Sent: Friday, July 17, 2009 11:18 AM
> To: cisco-nsp mailing list
> Subject: [c-nsp] Software versioning on SUP720s
> 
> I recently installed these sups and the 6748. I'm noticing that the
> active sup lists the IOS I'm booting up from the CF card and the in-
> active sup lists the IOS on sup-bootflash. The 6748 lists the newer IOS
> as well.
> 
> 1. Is this a problem?
> 2. If #1 = yes, then how must one fix the problem?
> 
> Thank you
> 
> 
> Mod Ports Card Type                              Model
> Serial No.
> --- ----- -------------------------------------- ------------------ ---
> --------
>   1   48  48 port 10/100 mb RJ45                 WS-X6348-RJ-45     SAL
>   2   48  CEF720 48 port 10/100/1000mb Ethernet  WS-X6748-GE-TX     SAL
>   3    8  8 port 1000mb GBIC Enhanced QoS        WS-X6408A-GBIC     SAD
>   4   16  16 port 1000mb GBIC ethernet           WS-X6416-GBIC      SAL
>   5    2  Supervisor Engine 720 (Active)         WS-SUP720-3BXL     SAL
>   6    2  Supervisor Engine 720 (Cold)           WS-SUP720-3BXL     SAL
> 
> Mod MAC addresses                       Hw    Fw           Sw
> Status
> --- ---------------------------------- ------ ------------ ------------
> -------
>   1  0004.2861.2750 to 0004.2861.277f   2.2   5.4(2)       8.7(0.22)BUB
> Ok
>   2  0025.840c.9310 to 0025.840c.933f   3.0   12.2(18r)S1  12.2(33)SXH5
> Ok
>   3  0002.fc25.0984 to 0002.fc25.098b   1.3   5.4(2)       8.7(0.22)BUB
> Ok
>   4  0008.a4f6.1784 to 0008.a4f6.1793   2.2   5.4(2)       8.7(0.22)BUB
> Ok
>   5  001f.6c77.13b0 to 001f.6c77.13b3   5.8   8.5(3)       12.2(33)SXH5
> Ok
>   6  001f.6c77.13c8 to 001f.6c77.13cb   5.8   8.5(3)       12.2(18)SXF1
> Ok
> 
> Mod  Sub-Module                  Model              Serial       Hw
> Status
> ---- --------------------------- ------------------ ----------- -------
> -------
>   2  Centralized Forwarding Card WS-F6700-CFC       SAL          4.1
> Ok
>   5  Policy Feature Card 3       WS-F6K-PFC3BXL     SAL          1.10
> Ok
>   5  MSFC3 Daughterboard         WS-SUP720          SAL          3.3
> Ok
>   6  Policy Feature Card 3       WS-F6K-PFC3BXL     SAL          1.10
> Ok
>   6  MSFC3 Daughterboard         WS-SUP720          SAL          3.3
> Ok
> 
> Mod  Online Diag Status
> ---- -------------------
>   1  Pass
>   2  Pass
>   3  Pass
>   4  Pass
>   5  Pass
>   6  Pass
> 
> 
> 
> -b
> 
> --
> Bill Blackford
> Senior Network Engineer
> Northwest Regional ESD
> 
> my /home away from home
> 
> 
> _______________________________________________
> cisco-nsp mailing 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: 4229 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090717/0f4a33e2/attachment-0001.bin>

From geoff at pendery.net  Fri Jul 17 12:20:55 2009
From: geoff at pendery.net (Geoffrey Pendery)
Date: Fri, 17 Jul 2009 11:20:55 -0500
Subject: [c-nsp] Software versioning on SUP720s
In-Reply-To: <6069A203FD01884885C037F81DD7508016CF7450DA@wsc-mail-01.intra.nwresd.k12.or.us>
References: <6069A203FD01884885C037F81DD7508016CF7450DA@wsc-mail-01.intra.nwresd.k12.or.us>
Message-ID: <d6966e4b0907170920h42b13c15ue6e6e29bb854dac9@mail.gmail.com>

If your goal is to intentionally run different code on your two
supervisors, with a cold standby to take over in case some bug in SXH5
causes a supervisor crash, then no it's not a problem you've got it
operating as planned.

But few people do it that way, I assume you want the whole system to
be running SXH5, and have a Hot standby who will take over quickly in
the event of hardware failure.  If that's the case, then like Matthew
said, you need to get the SXH5 code on your standby sup, and reboot it
on that code ("redundancy reload peer" IIRC).  They should show up
with the same IOS in the "show module" command, and should be Standby
Hot, not Standby Cold.

You mention booting off a CF card.  If that's your desired method, you
need a second CF card plugged into the second supervisor, with the
same code on it.  Otherwise you can boot from the sup-bootdisk, but
you still need a copy on both supervisors.  Any filesystem (disk0,
bootflash, sup-bootdisk, etc) can be reached on the backup Supervisor
by calling it slave[name of filesystem], like slavedisk0: or
slavebootflash:


-Geoff


On Fri, Jul 17, 2009 at 10:17 AM, Bill
Blackford<BBlackford at nwresd.k12.or.us> wrote:
> I recently installed these sups and the 6748. I'm noticing that the active sup lists the IOS I'm booting up from the CF card and the in-active sup lists the IOS on sup-bootflash. The 6748 lists the newer IOS as well.
>
> 1. Is this a problem?
> 2. If #1 = yes, then how must one fix the problem?
>
> Thank you
>
>
> Mod Ports Card Type ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Model ? ? ? ? ? ? ?Serial No.
> --- ----- -------------------------------------- ------------------ -----------
> ?1 ? 48 ?48 port 10/100 mb RJ45 ? ? ? ? ? ? ? ? WS-X6348-RJ-45 ? ? SAL
> ?2 ? 48 ?CEF720 48 port 10/100/1000mb Ethernet ?WS-X6748-GE-TX ? ? SAL
> ?3 ? ?8 ?8 port 1000mb GBIC Enhanced QoS ? ? ? ?WS-X6408A-GBIC ? ? SAD
> ?4 ? 16 ?16 port 1000mb GBIC ethernet ? ? ? ? ? WS-X6416-GBIC ? ? ?SAL
> ?5 ? ?2 ?Supervisor Engine 720 (Active) ? ? ? ? WS-SUP720-3BXL ? ? SAL
> ?6 ? ?2 ?Supervisor Engine 720 (Cold) ? ? ? ? ? WS-SUP720-3BXL ? ? SAL
>
> Mod MAC addresses ? ? ? ? ? ? ? ? ? ? ? Hw ? ?Fw ? ? ? ? ? Sw ? ? ? ? ? Status
> --- ---------------------------------- ------ ------------ ------------ -------
> ?1 ?0004.2861.2750 to 0004.2861.277f ? 2.2 ? 5.4(2) ? ? ? 8.7(0.22)BUB Ok
> ?2 ?0025.840c.9310 to 0025.840c.933f ? 3.0 ? 12.2(18r)S1 ?12.2(33)SXH5 Ok
> ?3 ?0002.fc25.0984 to 0002.fc25.098b ? 1.3 ? 5.4(2) ? ? ? 8.7(0.22)BUB Ok
> ?4 ?0008.a4f6.1784 to 0008.a4f6.1793 ? 2.2 ? 5.4(2) ? ? ? 8.7(0.22)BUB Ok
> ?5 ?001f.6c77.13b0 to 001f.6c77.13b3 ? 5.8 ? 8.5(3) ? ? ? 12.2(33)SXH5 Ok
> ?6 ?001f.6c77.13c8 to 001f.6c77.13cb ? 5.8 ? 8.5(3) ? ? ? 12.2(18)SXF1 Ok
>
> Mod ?Sub-Module ? ? ? ? ? ? ? ? ?Model ? ? ? ? ? ? ?Serial ? ? ? Hw ? ? Status
> ---- --------------------------- ------------------ ----------- ------- -------
> ?2 ?Centralized Forwarding Card WS-F6700-CFC ? ? ? SAL ? ? ? ? ?4.1 ? ?Ok
> ?5 ?Policy Feature Card 3 ? ? ? WS-F6K-PFC3BXL ? ? SAL ? ? ? ? ?1.10 ? Ok
> ?5 ?MSFC3 Daughterboard ? ? ? ? WS-SUP720 ? ? ? ? ?SAL ? ? ? ? ?3.3 ? ?Ok
> ?6 ?Policy Feature Card 3 ? ? ? WS-F6K-PFC3BXL ? ? SAL ? ? ? ? ?1.10 ? Ok
> ?6 ?MSFC3 Daughterboard ? ? ? ? WS-SUP720 ? ? ? ? ?SAL ? ? ? ? ?3.3 ? ?Ok
>
> Mod ?Online Diag Status
> ---- -------------------
> ?1 ?Pass
> ?2 ?Pass
> ?3 ?Pass
> ?4 ?Pass
> ?5 ?Pass
> ?6 ?Pass
>
>
>
> -b
>
> --
> Bill Blackford
> Senior Network Engineer
> Northwest Regional ESD
>
> my /home away from home
>
>
> _______________________________________________
> cisco-nsp mailing list ?cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From cluestore at gmail.com  Fri Jul 17 12:46:51 2009
From: cluestore at gmail.com (Clue Store)
Date: Fri, 17 Jul 2009 11:46:51 -0500
Subject: [c-nsp]  ASA Static Translations / DNS Doctoring
Message-ID: <580af3b90907170946x57b63250lfa2937fc6fa64dec@mail.gmail.com>

Hi All,

I'm trying to do DNS doctoring on an asa and for specific reasons I need to
map several different (public) outside IP's the one inside ip as shown
below.

*static (inside,outside) 208.x.x.25 192.168.100.10 netmask 255.255.255.255
dns*
*static (inside,outside) 208.x.x.26 192.168.100.10 netmask 255.255.255.255
dns*
**
However, upon entering the second rule, the asa says "ERROR: duplicate of
existing static". I realize this is for a one to one translation. As I am
not an expert with the ASA, does anyone know how I can accomplish this in a
different manor??

My only other option is to point all of my domains to the same (public)
outside IP, but this is my LAST option as it breaks alot more things that
would take alot more time to fix. Any help is appeciated.

Thanks,
Clue

From brandon at burn.net  Fri Jul 17 12:21:48 2009
From: brandon at burn.net (Brandon Applegate)
Date: Fri, 17 Jul 2009 12:21:48 -0400 (EDT)
Subject: [c-nsp] L3 Etherchannel on ASR / IOS-XE
Message-ID: <Pine.LNX.4.64.0907171219420.1986@orbital.burn.net>

Is anyone doing it ?  I don't have many options for config on the ASR 
side.  On the other side (7609-S) I'm using channel mode 'on'.  It's just 
not passing traffic.  Searched CCO, IOS-XE config guide etc.  If there is 
a magic formula to make it work, I'd love to know.  Thanks in advance.


From elmi at 4ever.de  Fri Jul 17 13:21:40 2009
From: elmi at 4ever.de (Elmar K. Bins)
Date: Fri, 17 Jul 2009 19:21:40 +0200
Subject: [c-nsp] L3 Etherchannel on ASR / IOS-XE
In-Reply-To: <Pine.LNX.4.64.0907171219420.1986@orbital.burn.net>
References: <Pine.LNX.4.64.0907171219420.1986@orbital.burn.net>
Message-ID: <20090717172139.GF20732@ronin.4ever.de>

Re Brandon,

brandon at burn.net (Brandon Applegate) wrote:

> Is anyone doing it ?  I don't have many options for config on the ASR 
> side.  On the other side (7609-S) I'm using channel mode 'on'.  It's just 
> not passing traffic.  Searched CCO, IOS-XE config guide etc.  If there is 
> a magic formula to make it work, I'd love to know.  Thanks in advance.

I'm using L2 etherchannel out of the box (if you can call
that L2...), and I discovered that you need the very very
latest IOS to get that going.

asr1000rp1-adventerprisek9.02.04.00.122-33.XND.bin is the image I'm
using in the test setup. Everything else did just not work.

HTH,
	Elmar.

From luan at netcraftsmen.net  Fri Jul 17 13:49:55 2009
From: luan at netcraftsmen.net (Luan Nguyen)
Date: Fri, 17 Jul 2009 13:49:55 -0400
Subject: [c-nsp] ASA Static Translations / DNS Doctoring
In-Reply-To: <580af3b90907170946x57b63250lfa2937fc6fa64dec@mail.gmail.com>
References: <580af3b90907170946x57b63250lfa2937fc6fa64dec@mail.gmail.com>
Message-ID: <03d201ca0706$fec37120$fc4a5360$@net>

Static mapping means one to one.  You could do port mapping.

I have an internal web server that need to be accessible from the public
internet so I would do *static (inside,outside) 208.x.x.25 192.168.100.10
netmask 255.255.255.255 dns*.
What do you need to do?

Regards,

-------------------------------
Luan Nguyen
Chesapeake NetCraftsmen, LLC.
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 Clue Store
Sent: Friday, July 17, 2009 12:47 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] ASA Static Translations / DNS Doctoring

Hi All,

I'm trying to do DNS doctoring on an asa and for specific reasons I need to
map several different (public) outside IP's the one inside ip as shown
below.

*static (inside,outside) 208.x.x.25 192.168.100.10 netmask 255.255.255.255
dns*
*static (inside,outside) 208.x.x.26 192.168.100.10 netmask 255.255.255.255
dns*
**
However, upon entering the second rule, the asa says "ERROR: duplicate of
existing static". I realize this is for a one to one translation. As I am
not an expert with the ASA, does anyone know how I can accomplish this in a
different manor??

My only other option is to point all of my domains to the same (public)
outside IP, but this is my LAST option as it breaks alot more things that
would take alot more time to fix. Any help is appeciated.

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


From cklam at ias.edu  Fri Jul 17 14:00:54 2009
From: cklam at ias.edu (Christina Klam)
Date: Fri, 17 Jul 2009 14:00:54 -0400
Subject: [c-nsp] Module provisioning for a 6500
Message-ID: <9E9636B2F6649243B154AB4E53BD53000B0A9189@Hecto.itg.ias.edu>

In know on a 3750, I can use "switch [] provision" to manually assign a physical switch any switch number I want.  Is there a way to virtually assign a module a different slot id on a 6513?  What I want is to make "gig 1/1" really be on the physical interface "gig 9/1".

Thanks in advance for you help,
Chris



From cluestore at gmail.com  Fri Jul 17 14:08:50 2009
From: cluestore at gmail.com (Clue Store)
Date: Fri, 17 Jul 2009 13:08:50 -0500
Subject: [c-nsp] ASA Static Translations / DNS Doctoring
In-Reply-To: <03d201ca0706$fec37120$fc4a5360$@net>
References: <580af3b90907170946x57b63250lfa2937fc6fa64dec@mail.gmail.com>
	<03d201ca0706$fec37120$fc4a5360$@net>
Message-ID: <580af3b90907171108x7a936362p4b1348bc33db5d38@mail.gmail.com>

Sorry, let me expand a little more. I have several domains pointed various
ip's in a /27 (public block). I have one internal webserver inside of my
network. I would like to be able to map the several outside IP's to one
inside IP of my web server and perform DNS doctoring via the ASA so my
inside hosts can use a DNS server outside of my network and still be able to
get to the domains, but that seems to be only available with the static
command unless i've missed something. Hence the "DNS" at the end of the
below command.

static (inside,outside) 208.x.x.26 192.168.100.10 netmask 255.255.255.255
dns




On Fri, Jul 17, 2009 at 12:49 PM, Luan Nguyen <luan at netcraftsmen.net> wrote:

> Static mapping means one to one.  You could do port mapping.
>
> I have an internal web server that need to be accessible from the public
> internet so I would do *static (inside,outside) 208.x.x.25 192.168.100.10
> netmask 255.255.255.255 dns*.
> What do you need to do?
>
> Regards,
>
> -------------------------------
> Luan Nguyen
> Chesapeake NetCraftsmen, LLC.
> 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 Clue Store
> Sent: Friday, July 17, 2009 12:47 PM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] ASA Static Translations / DNS Doctoring
>
> Hi All,
>
> I'm trying to do DNS doctoring on an asa and for specific reasons I need to
> map several different (public) outside IP's the one inside ip as shown
> below.
>
> *static (inside,outside) 208.x.x.25 192.168.100.10 netmask 255.255.255.255
> dns*
> *static (inside,outside) 208.x.x.26 192.168.100.10 netmask 255.255.255.255
> dns*
> **
> However, upon entering the second rule, the asa says "ERROR: duplicate of
> existing static". I realize this is for a one to one translation. As I am
> not an expert with the ASA, does anyone know how I can accomplish this in a
> different manor??
>
> My only other option is to point all of my domains to the same (public)
> outside IP, but this is my LAST option as it breaks alot more things that
> would take alot more time to fix. Any help is appeciated.
>
> Thanks,
> Clue
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>

From brandon at burn.net  Fri Jul 17 14:14:19 2009
From: brandon at burn.net (Brandon Applegate)
Date: Fri, 17 Jul 2009 14:14:19 -0400 (EDT)
Subject: [c-nsp] L3 Etherchannel on ASR / IOS-XE
In-Reply-To: <20090717172139.GF20732@ronin.4ever.de>
References: <Pine.LNX.4.64.0907171219420.1986@orbital.burn.net>
	<20090717172139.GF20732@ronin.4ever.de>
Message-ID: <Pine.LNX.4.64.0907171412140.1986@orbital.burn.net>

On Fri, 17 Jul 2009, Elmar K. Bins wrote:

> Re Brandon,
>
> brandon at burn.net (Brandon Applegate) wrote:
>
>> Is anyone doing it ?  I don't have many options for config on the ASR
>> side.  On the other side (7609-S) I'm using channel mode 'on'.  It's just
>> not passing traffic.  Searched CCO, IOS-XE config guide etc.  If there is
>> a magic formula to make it work, I'd love to know.  Thanks in advance.
>
> I'm using L2 etherchannel out of the box (if you can call
> that L2...), and I discovered that you need the very very
> latest IOS to get that going.
>
> asr1000rp1-adventerprisek9.02.04.00.122-33.XND.bin is the image I'm
> using in the test setup. Everything else did just not work.
>
> HTH,
> 	Elmar.
>

Thanks for the push.  Upgrading IOS to latest avail (exact same thing you 
are running) made a world of difference.  Looks like I have the option of 
doing LACP now (didn't before).  I've tried both LACP and plain 
Etherchannel (mode 'on', my personal preference) and both seem to work.

--
Brandon Applegate - CCIE 10273
PGP Key fingerprint:
7407 DC86 AA7B A57F 62D1 A715 3C63 66A1 181E 6996
"SH1-0151.  This is the serial number, of our orbital gun."




From ayourtch at cisco.com  Fri Jul 17 14:27:54 2009
From: ayourtch at cisco.com (Andrew Yourtchenko)
Date: Fri, 17 Jul 2009 20:27:54 +0200 (CEST)
Subject: [c-nsp] ASA Static Translations / DNS Doctoring
In-Reply-To: <580af3b90907170946x57b63250lfa2937fc6fa64dec@mail.gmail.com>
References: <580af3b90907170946x57b63250lfa2937fc6fa64dec@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.0907172006540.4425@zippy.stdio.be>

On Fri, 17 Jul 2009, Clue Store wrote:

> Hi All,
>
> I'm trying to do DNS doctoring on an asa and for specific reasons I need to
> map several different (public) outside IP's the one inside ip as shown
> below.
>
> *static (inside,outside) 208.x.x.25 192.168.100.10 netmask 255.255.255.255
> dns*
> *static (inside,outside) 208.x.x.26 192.168.100.10 netmask 255.255.255.255
> dns*

With "static (inside,outside) AddrPublic AddrPrivate netmask 
255.255.255.255 dns" in the config,

you're saying:

1) when anyone tries to talk to AddrPublic from the outside, they will get to AddrPrivate on the inside
2) when AddrPrivate tries to talk to anyone on the outside, it will be seen there as AddrPublic
3) the DNS response containing AddrPrivate or AddrPublic, depending on 
where it is arriving, will have this address translated accordingly. (so 
the DNS server on the outside replying AddrPublic to someone on inside, 
will have this translated to AddrPrivate; and inside DNS server which 
replies the AddrPrivate to the outside, will have it translated to 
AddrPublic.)

The (3) is what the "dns" keyword turns on when it is present.

The symmetry of the behaviour prevents having 'many to one' behaviour 
that you are looking for - because then it would encounter the conflict or 
unpredictability when going outbound.

The simplest way around is to grab a few secondary 
rfc1918 addresses and assign them to the host and do the mapping between 
those and the public addresses.

For your /27 case, having 30 secondaries does not look terribly exciting, 
but assuming the host can survive that, it should do the trick.

cheers,
andrew


From luan at netcraftsmen.net  Fri Jul 17 14:35:43 2009
From: luan at netcraftsmen.net (Luan Nguyen)
Date: Fri, 17 Jul 2009 14:35:43 -0400
Subject: [c-nsp] ASA Static Translations / DNS Doctoring
In-Reply-To: <Pine.LNX.4.64.0907172006540.4425@zippy.stdio.be>
References: <580af3b90907170946x57b63250lfa2937fc6fa64dec@mail.gmail.com>
	<Pine.LNX.4.64.0907172006540.4425@zippy.stdio.be>
Message-ID: <03d601ca070d$648f4280$2dadc780$@net>

Very creative use of secondary addresses! :)

Regards,

------------------------------------
Luan Nguyen
Chesapeake NetCraftsmen, LLC.
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 Andrew Yourtchenko
Sent: Friday, July 17, 2009 2:28 PM
To: Clue Store
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] ASA Static Translations / DNS Doctoring

On Fri, 17 Jul 2009, Clue Store wrote:

> Hi All,
>
> I'm trying to do DNS doctoring on an asa and for specific reasons I need
to
> map several different (public) outside IP's the one inside ip as shown
> below.
>
> *static (inside,outside) 208.x.x.25 192.168.100.10 netmask 255.255.255.255
> dns*
> *static (inside,outside) 208.x.x.26 192.168.100.10 netmask 255.255.255.255
> dns*

With "static (inside,outside) AddrPublic AddrPrivate netmask 
255.255.255.255 dns" in the config,

you're saying:

1) when anyone tries to talk to AddrPublic from the outside, they will get
to AddrPrivate on the inside
2) when AddrPrivate tries to talk to anyone on the outside, it will be seen
there as AddrPublic
3) the DNS response containing AddrPrivate or AddrPublic, depending on 
where it is arriving, will have this address translated accordingly. (so 
the DNS server on the outside replying AddrPublic to someone on inside, 
will have this translated to AddrPrivate; and inside DNS server which 
replies the AddrPrivate to the outside, will have it translated to 
AddrPublic.)

The (3) is what the "dns" keyword turns on when it is present.

The symmetry of the behaviour prevents having 'many to one' behaviour 
that you are looking for - because then it would encounter the conflict or 
unpredictability when going outbound.

The simplest way around is to grab a few secondary 
rfc1918 addresses and assign them to the host and do the mapping between 
those and the public addresses.

For your /27 case, having 30 secondaries does not look terribly exciting, 
but assuming the host can survive that, it should do the trick.

cheers,
andrew

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


From rdobbins at arbor.net  Fri Jul 17 14:45:43 2009
From: rdobbins at arbor.net (Roland Dobbins)
Date: Sat, 18 Jul 2009 01:45:43 +0700
Subject: [c-nsp] ASA Static Translations / DNS Doctoring
In-Reply-To: <580af3b90907171108x7a936362p4b1348bc33db5d38@mail.gmail.com>
References: <580af3b90907170946x57b63250lfa2937fc6fa64dec@mail.gmail.com>
	<03d201ca0706$fec37120$fc4a5360$@net>
	<580af3b90907171108x7a936362p4b1348bc33db5d38@mail.gmail.com>
Message-ID: <4702DC16-63A3-4B77-B949-ED0B2F0D44CD@arbor.net>


On Jul 18, 2009, at 1:08 AM, Clue Store wrote:

> I have several domains pointed various
> ip's in a /27 (public block). I have one internal webserver inside  
> of my
> network. I would like to be able to map the several outside IP's to  
> one
> inside IP of my web server and perform DNS doctoring via the ASA so my
> inside hosts can use a DNS server outside of my network and still be  
> able to
> get to the domains

Not a good idea - an attacker can breathe on it, and it'll fall over,  
instant DoS.  Sticking servers behind firewalls, and NATting them, to  
boot, is extremely poor security practice.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

         Unfortunately, inefficiency scales really well.

		   -- Kevin Lawton


From cluestore at gmail.com  Fri Jul 17 15:01:57 2009
From: cluestore at gmail.com (Clue Store)
Date: Fri, 17 Jul 2009 14:01:57 -0500
Subject: [c-nsp] ASA Static Translations / DNS Doctoring
In-Reply-To: <Pine.LNX.4.64.0907172006540.4425@zippy.stdio.be>
References: <580af3b90907170946x57b63250lfa2937fc6fa64dec@mail.gmail.com>
	<Pine.LNX.4.64.0907172006540.4425@zippy.stdio.be>
Message-ID: <580af3b90907171201o572f06ebm1c2eb649f10351ba@mail.gmail.com>

Hi Andrew,

Thanks for the reply. I understand the static function which was why I was
asking if there was a to do DNS doctoring via another method instead of the
static command. I take it that the answer is no. I also have the option of
mapping all domains to one public, but this at the administrators request
that it be done like this, so I do not have many options.

Anyways, I think your idea of using some secondary addresses might be my
easiest path. I just have to make sure I have enough on the inside to pull
it off.
Thanks,
Clue
On Fri, Jul 17, 2009 at 1:27 PM, Andrew Yourtchenko <ayourtch at cisco.com>wrote:

> On Fri, 17 Jul 2009, Clue Store wrote:
>
>  Hi All,
>>
>> I'm trying to do DNS doctoring on an asa and for specific reasons I need
>> to
>> map several different (public) outside IP's the one inside ip as shown
>> below.
>>
>> *static (inside,outside) 208.x.x.25 192.168.100.10 netmask 255.255.255.255
>> dns*
>> *static (inside,outside) 208.x.x.26 192.168.100.10 netmask 255.255.255.255
>> dns*
>>
>
> With "static (inside,outside) AddrPublic AddrPrivate netmask
> 255.255.255.255 dns" in the config,
>
> you're saying:
>
> 1) when anyone tries to talk to AddrPublic from the outside, they will get
> to AddrPrivate on the inside
> 2) when AddrPrivate tries to talk to anyone on the outside, it will be seen
> there as AddrPublic
> 3) the DNS response containing AddrPrivate or AddrPublic, depending on
> where it is arriving, will have this address translated accordingly. (so the
> DNS server on the outside replying AddrPublic to someone on inside, will
> have this translated to AddrPrivate; and inside DNS server which replies the
> AddrPrivate to the outside, will have it translated to AddrPublic.)
>
> The (3) is what the "dns" keyword turns on when it is present.
>
> The symmetry of the behaviour prevents having 'many to one' behaviour that
> you are looking for - because then it would encounter the conflict or
> unpredictability when going outbound.
>
> The simplest way around is to grab a few secondary rfc1918 addresses and
> assign them to the host and do the mapping between those and the public
> addresses.
>
> For your /27 case, having 30 secondaries does not look terribly exciting,
> but assuming the host can survive that, it should do the trick.
>
> cheers,
> andrew
>
>

From cluestore at gmail.com  Fri Jul 17 15:05:54 2009
From: cluestore at gmail.com (Clue Store)
Date: Fri, 17 Jul 2009 14:05:54 -0500
Subject: [c-nsp] ASA Static Translations / DNS Doctoring
In-Reply-To: <4702DC16-63A3-4B77-B949-ED0B2F0D44CD@arbor.net>
References: <580af3b90907170946x57b63250lfa2937fc6fa64dec@mail.gmail.com>
	<03d201ca0706$fec37120$fc4a5360$@net>
	<580af3b90907171108x7a936362p4b1348bc33db5d38@mail.gmail.com>
	<4702DC16-63A3-4B77-B949-ED0B2F0D44CD@arbor.net>
Message-ID: <580af3b90907171205o610d8622hcf79244f3f7a91ac@mail.gmail.com>

Hi Roland,

I agree that this is not a good idea, solution, or practice, but when one is
requested to perform a task a particular way and that task is what generates
my revenue, best practice does not apply. Had this been my own shop, there
would have been some different engineering for this project.

Clue

On Fri, Jul 17, 2009 at 1:45 PM, Roland Dobbins <rdobbins at arbor.net> wrote:

>
> On Jul 18, 2009, at 1:08 AM, Clue Store wrote:
>
> I have several domains pointed various
>> ip's in a /27 (public block). I have one internal webserver inside of my
>> network. I would like to be able to map the several outside IP's to one
>> inside IP of my web server and perform DNS doctoring via the ASA so my
>> inside hosts can use a DNS server outside of my network and still be able
>> to
>> get to the domains
>>
>
> Not a good idea - an attacker can breathe on it, and it'll fall over,
> instant DoS.  Sticking servers behind firewalls, and NATting them, to boot,
> is extremely poor security practice.
>
> -----------------------------------------------------------------------
> Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>
>
>        Unfortunately, inefficiency scales really well.
>
>                   -- Kevin Lawton
>
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From rdobbins at arbor.net  Fri Jul 17 15:11:43 2009
From: rdobbins at arbor.net (Roland Dobbins)
Date: Sat, 18 Jul 2009 02:11:43 +0700
Subject: [c-nsp] ASA Static Translations / DNS Doctoring
In-Reply-To: <580af3b90907171205o610d8622hcf79244f3f7a91ac@mail.gmail.com>
References: <580af3b90907170946x57b63250lfa2937fc6fa64dec@mail.gmail.com>
	<03d201ca0706$fec37120$fc4a5360$@net>
	<580af3b90907171108x7a936362p4b1348bc33db5d38@mail.gmail.com>
	<4702DC16-63A3-4B77-B949-ED0B2F0D44CD@arbor.net>
	<580af3b90907171205o610d8622hcf79244f3f7a91ac@mail.gmail.com>
Message-ID: <BFF87A6A-6AAB-4B25-929A-2E9D3A7A3F3A@arbor.net>


On Jul 18, 2009, at 2:05 AM, Clue Store wrote:

> I agree that this is not a good idea, solution, or practice, but  
> when one is
> requested to perform a task a particular way and that task is what  
> generates
> my revenue, best practice does not apply.

For myself, I'd refuse to do the work due to the potential for  
liability; as you're going ahead with it, I strongly suggest you get  
your customer's acknowledgement in writing that you've warned him  
about the dangers of this setup and that he's insisting upon it,  
anyways, so that when it eventually falls over, you're in the clear.

;>

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

         Unfortunately, inefficiency scales really well.

		   -- Kevin Lawton


From gert at greenie.muc.de  Fri Jul 17 17:20:31 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Fri, 17 Jul 2009 23:20:31 +0200
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <20090717130557.GA14202@kallisti.us>
References: <a1873f1f0907131438m3f0b4c70r82a953a29042b6d7@mail.gmail.com>
	<1247524340.4661.65.camel@abehat.net.rm.dk>
	<20090714084503.GA15753@lboro.ac.uk>
	<d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>
	<Pine.LNX.4.61.0907140924470.6312@soloth.lewis.org>
	<d6966e4b0907140724n61be11f5ra851690ceaabbd93@mail.gmail.com>
	<20090714150036.GP290@greenie.muc.de>
	<20090716032712.GA2111@kallisti.us>
	<20090716065147.GF290@greenie.muc.de>
	<20090717130557.GA14202@kallisti.us>
Message-ID: <20090717212031.GN290@greenie.muc.de>

Hi,

On Fri, Jul 17, 2009 at 09:05:57AM -0400, Ross Vandegrift wrote:
> > > I completely disagree - it's what comes out of solving problems
> > > related to the LAN - the LOCAL area network.  In virtualized LANs,
> > > there's typically only a few possible physical topologies that can
> > > exist.  MST seeks to exploit this to lower the amount of processing
> > > power that is required.
[..]
> I think you've misunderstood me - by "virtualized LAN" I meant VLAN,
> not VPLS.  It didn't take years for these designs to come up - the
> datacenter we run is a bog-standard, utterly uninteresting case of a few
> thousand servers, in a few thousands VLANs, with a pair of HSRP
> routers.

See my e-mail with the description of our topology.  VLAN usage doesn't
mean "trivial topology".

[..]
> I'll go a step further - I doubt that there's a substantially more
> optimal way to compute only the valid topologies.

Computers in the year 2009 shouldn't require humans to bow for them to
make life easy for the computer.

MST with automatic vlan->instance assignment, auto-creating a new instance
for every distinct VLAN topology encountered, would be a *good* protocol.
Save redundant computing effort, while providing maximum flexibility.

(Another nuisance of MST is that if you are forced to interoperate PVSTP
and MST boxes, there seems to be no way to tell the MST cloud "no, you are 
not the root of the STP", which brings great pain if all you want to do 
is "hook a management link from one of your switches into a customer setup 
that needs to run MST".  I can see that this makes sense if there is more
than one switch in the MST cloud, or topological diversity, but for
"there is a single port in this VLAN, only used for managment access to
the switch itself", this is just pain)

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/20090717/bf0ce5bc/attachment.bin>

From gert at greenie.muc.de  Fri Jul 17 17:23:06 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Fri, 17 Jul 2009 23:23:06 +0200
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <20090717143514.GA24138@mx.ytti.net>
References: <20090714084503.GA15753@lboro.ac.uk>
	<d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>
	<Pine.LNX.4.61.0907140924470.6312@soloth.lewis.org>
	<d6966e4b0907140724n61be11f5ra851690ceaabbd93@mail.gmail.com>
	<20090714150036.GP290@greenie.muc.de>
	<20090716032712.GA2111@kallisti.us>
	<20090716065147.GF290@greenie.muc.de>
	<20090717130557.GA14202@kallisti.us>
	<d6966e4b0907170709h27e8d6e4v7d38e386d92b7ffc@mail.gmail.com>
	<20090717143514.GA24138@mx.ytti.net>
Message-ID: <20090717212306.GO290@greenie.muc.de>

Hi,

On Fri, Jul 17, 2009 at 05:35:14PM +0300, Saku Ytti wrote:
> On (2009-07-17 09:09 -0500), Geoffrey Pendery wrote:
>  
> > I'm not trying to say "MST is never useful and always terrible", but rather:
> > "MST doesn't fit all scenarios.  For many scenarios, RPVST is much
> > better, and it's a shame that we've only got an open standard MST,
> > rather than two open standards to cover both scenarios."
> 
> Not arguing against, but would you happen to have example where
> MST does not fit? All my respect to the person who decidedly
> engineers L2 network with more then 65 planned and documented
> topologies[0], and succeeds to deliver higher SLA than what is possible
> with fewer.

See my description on how our datacenter setup looks like.  Every customer
has their own VLAN, and usually the customers have more than one single
device, so the customer brings in their own switch(es).  Customers with
redundant connections have exactly that: redundant connections, multiple
switches, multiple L2 paths, RSTP.

For about every single VLAN, there is a different topology.

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/20090717/8335715d/attachment.bin>

From jwininger at indianafiber.net  Fri Jul 17 17:40:30 2009
From: jwininger at indianafiber.net (Jim Wininger)
Date: Fri, 17 Jul 2009 17:40:30 -0400
Subject: [c-nsp] Cisco 7600 (7609) as core BGP router.
In-Reply-To: <20090717212306.GO290@greenie.muc.de>
Message-ID: <C686680E.12148%jwininger@indianafiber.net>

I have an opportuniy to put two 7609s into the core of my network.

Currently we have 3 upstream providers, taking full BGP routes. (2 in one
router and one in another). We have 17 BGP peers/customers (peering to each
router), and adding about one new BGP peer every 2-3 months. It is a modest
network by most standards. We are running OSPF and BGP between the existing
routers.

Not rocket science, nothing special (no MPLS, no VRF etc), very simple
network.

Does anyone have any recommendations on the 7600's as a core BGP router?
Good or bad? Have they been a stable platform in a core/BGP environment?
-- 
Jim Wininger







(


From ross at kallisti.us  Fri Jul 17 18:23:58 2009
From: ross at kallisti.us (Ross Vandegrift)
Date: Fri, 17 Jul 2009 18:23:58 -0400
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <20090717212031.GN290@greenie.muc.de>
References: <1247524340.4661.65.camel@abehat.net.rm.dk>
	<20090714084503.GA15753@lboro.ac.uk>
	<d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>
	<Pine.LNX.4.61.0907140924470.6312@soloth.lewis.org>
	<d6966e4b0907140724n61be11f5ra851690ceaabbd93@mail.gmail.com>
	<20090714150036.GP290@greenie.muc.de>
	<20090716032712.GA2111@kallisti.us>
	<20090716065147.GF290@greenie.muc.de>
	<20090717130557.GA14202@kallisti.us>
	<20090717212031.GN290@greenie.muc.de>
Message-ID: <20090717222358.GA16581@kallisti.us>

On Fri, Jul 17, 2009 at 11:20:31PM +0200, Gert Doering wrote:
> See my e-mail with the description of our topology.  VLAN usage doesn't
> mean "trivial topology".

Yes, you're absolutely correct, and I didn't mean to indicate that
VLAN usage and topology decisions were linked in any manner.

> > I'll go a step further - I doubt that there's a substantially more
> > optimal way to compute only the valid topologies.
> 
> Computers in the year 2009 shouldn't require humans to bow for them to
> make life easy for the computer.

I agree with you, in principle - even five years ago.  Unfortunately,
my 6500s feel every ounce of everything that gets asked of them.

> MST with automatic vlan->instance assignment, auto-creating a new instance
> for every distinct VLAN topology encountered, would be a *good* protocol.
> Save redundant computing effort, while providing maximum flexibility.

Part of the issue is that no bridge ever can have a view on what the
complete forwrding topology is, and so no bridge could know when to
create a new topology.  Which is why I like MST - it lets me tell my
gear "hey - you send this stuff here, because it turns out, I can
promise this will be your active forwarding topology".

The idea of a protocol that could build what VLAN forwarding
topologies existed based on what various trunk links carried is
interesting, but requires far more complete cooperation between
bridges than STP assumes.
 
> (Another nuisance of MST is that if you are forced to interoperate PVSTP
> and MST boxes, there seems to be no way to tell the MST cloud "no, you are 
> not the root of the STP", which brings great pain if all you want to do 
> is "hook a management link from one of your switches into a customer setup 
> that needs to run MST".

I'm not familiar with the MST-PVST interaction, but if it's MST-RST,
you should be able to acheive this.  Make sure all of your MST bridges
have non-minimal priority and have one (or more) RST bridges, outside
of the MST region, have minimal priority.  All of your MST bridges
should compute instance, internal, and common root paths.  The common
spanning-tree roots should appear as the RST bridges.

This is undoubtedly complicated by having customer-facing ports speak
spanning-tree, and that very well may limit your flexability.  We have
the luxury of running bpdu-guard on all customer-facing switchports
because no one is permitted to have a downstream topology that we
don't manage.

-- 
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  Fri Jul 17 18:28:52 2009
From: ross at kallisti.us (Ross Vandegrift)
Date: Fri, 17 Jul 2009 18:28:52 -0400
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <d6966e4b0907170709h27e8d6e4v7d38e386d92b7ffc@mail.gmail.com>
References: <1247524340.4661.65.camel@abehat.net.rm.dk>
	<20090714084503.GA15753@lboro.ac.uk>
	<d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>
	<Pine.LNX.4.61.0907140924470.6312@soloth.lewis.org>
	<d6966e4b0907140724n61be11f5ra851690ceaabbd93@mail.gmail.com>
	<20090714150036.GP290@greenie.muc.de>
	<20090716032712.GA2111@kallisti.us>
	<20090716065147.GF290@greenie.muc.de>
	<20090717130557.GA14202@kallisti.us>
	<d6966e4b0907170709h27e8d6e4v7d38e386d92b7ffc@mail.gmail.com>
Message-ID: <20090717222852.GB16581@kallisti.us>

On Fri, Jul 17, 2009 at 09:09:30AM -0500, Geoffrey Pendery wrote:
> "The point of MST is to realize that there's never going to be more
> than two possible forwarding topologies, and computing more is a total
> waste."
> 
> But that statement is specific to your network design and your
> topology.  Surely you're not claiming that it's never possible to
> build a network with more than two topologies?

No, absolutely not.  I was answering the assertion that there is
something fundamentally wrong with MST in terms of the protocol or the
design goal.  It's design goal is sensible, and it's execution
acheives that goal.

If that goal is a hammer and you have screws, by all means, use a
screwdriver!

> When you're given the mandate/requirement/strong-preference of using
> open standard protocols rather than Cisco proprietary ones (not an
> unreasonable goal) it leads to great frustration, because you end up
> having to hammer in screws.  This frustration apparently leads to some
> ranting on email lists.

Indeed - especially with MST, as various vendors have historically
done a poor job in implementation.  You're left with a working Cisco
protocol on one hand, and an IEEE protocol that's sometimes only 90%
there.

-- 
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  Fri Jul 17 19:26:39 2009
From: ross at kallisti.us (Ross Vandegrift)
Date: Fri, 17 Jul 2009 19:26:39 -0400
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <4A6090CA.7090702@imperial.ac.uk>
References: <d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>
	<Pine.LNX.4.61.0907140924470.6312@soloth.lewis.org>
	<d6966e4b0907140724n61be11f5ra851690ceaabbd93@mail.gmail.com>
	<20090714150036.GP290@greenie.muc.de>
	<20090716032712.GA2111@kallisti.us>
	<20090716065147.GF290@greenie.muc.de>
	<20090717130557.GA14202@kallisti.us>
	<d6966e4b0907170709h27e8d6e4v7d38e386d92b7ffc@mail.gmail.com>
	<20090717143514.GA24138@mx.ytti.net>
	<4A6090CA.7090702@imperial.ac.uk>
Message-ID: <20090717232639.GC16581@kallisti.us>

On Fri, Jul 17, 2009 at 03:55:06PM +0100, Phil Mayers wrote:
> Personally I find the (lack of) graceful change control the big killer.  
> Our network is simply *NOT* capable of "defining the mappings ahead of  
> time and never changing them" because of inherited legacy. I cannot  
> tolerate the outages we'd need to incur every time a VLAN was added or  
> removed, and I'm certainly not prepared to spend the many man-months  
> re-numbering every vlan tag on campus into some arbitrary grouping just  
> so I can run MST, when PVST works *now*.

If you can't know your forwarding topologies ahead of time, or you
can't devise a scheme in which to map them, then MST isn't for you.
Itt could introduce an unacceptable amount of management overhead.

But I'm skeptical you really have that many active topologies in a
single switched ethernet - do people really run networks like the
example diagrams in 802.1Q?

> I probably *could* run MST, after a lot of work, but why would I want to?

The only reason would be to reduce CPU impact due to reconvergence.
Again, if you aren't running into issues here, then you absolutely
shouldn't touch it.

> In addition, I have serious concerns about the scope of instance 0,  
> particularly in the topology we run (a collapsed core/distribution  
> triangle).

What's the concern?  Instance 0 is just the usual RST domain.  Some
people I've talked to have been concerned becuase they've assumed that
instances are somehow isolated - which is not the case.

Typical wisdom is to never leave anything mapped to instance 0, but
this comes from a Cisco whitepaper [1] that not only fails to provide
adequate technical reasoning, but justifies the configuration on a
faulty description of instances.

("IST Instance is Active on All Ports" is a fundamental
misunderstanding of the protocol - it's an application of PVST logic
to MST.

Instances aren't the kind of thing that are active per-port.  They are
just the various topologies a bridge may compute best-path to root
for.  If a bridge has a VLAN mapped to instance x, then instance x
must have a computed topology.  Paths for instance 0 are always
computed by every bridge.)

[1] http://www.cisco.com/en/US/tech/tk389/tk621/technologies_white_paper09186a0080094cfc.shtml

> When I tried it on the bench, I could not come up with an MST setup that  
> worked.

We also run collapsed core/distribution switching triangles.  You may
have been bitten by certain IOS versions that look to support MST but
are actually pre-standard.  The correct name in feature navigator is
something charming like "MST standards compliance".

Our configuration has three instances - a management instance, an odd
instance, and an even instance.  All VLANs less than 100 are reserved
for management and mapped to instance 3.  All odd VLANs starting at
101 are mapped to instance 1.  All even VLANs starting at 100 are
mapped to instance 2.  Switch1 is root bridge for the odd VLANs (and
HSRP primary) and Switch2 is root bridge for the even VLANs (and HSRP
primary).

But don't get me wrong - if I had a working network that wasn't setup
in this fashion, I wouldn't touch it without a good reason - I had the
luxury of starting from scratch.

--
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 mtinka at globaltransit.net  Fri Jul 17 22:35:02 2009
From: mtinka at globaltransit.net (Mark Tinka)
Date: Sat, 18 Jul 2009 10:35:02 +0800
Subject: [c-nsp] Cisco 7600 (7609) as core BGP router.
In-Reply-To: <C686680E.12148%jwininger@indianafiber.net>
References: <C686680E.12148%jwininger@indianafiber.net>
Message-ID: <200907181035.19568.mtinka@globaltransit.net>

On Saturday 18 July 2009 05:40:30 am Jim Wininger wrote:

> Does anyone have any recommendations on the 7600's as a
> core BGP router? Good or bad? Have they been a stable
> platform in a core/BGP environment?

I believe it should work well as a core router, i.e., it has 
the grunt to haul lots of traffic around (assuming you're 
going for the RSP720 supervisor engine), minimal feature 
configuration as most core routers would have, e.t.c.

The only trick with this platform as a core router (well, in 
our case, at least) is that it's optimized for Ethernet, 
really. So unless all your links to your other PoP's (which 
generally terminate into your core) are Ethernet, it might 
start to get pretty expensive sticking SIP's/SPA's into this 
platform to support SONET/SDH and the like for your external 
PoP links, particularly if you're on the lower end of 
things, e.g., OC-3/STM-1, OC-12/STM-4, e.t.c.

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/20090718/93b53bcb/attachment.bin>

From tstevens at cisco.com  Sat Jul 18 00:55:33 2009
From: tstevens at cisco.com (Tim Stevenson)
Date: Fri, 17 Jul 2009 21:55:33 -0700
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <8e157ab40907162051t4d32d6cbudc1dacca82790ed1@mail.gmail.co
 m>
References: <9DE4AA6876D44B62B87C475B2AFE5514@au.didata.local>
	<a1873f1f0907131438m3f0b4c70r82a953a29042b6d7@mail.gmail.com>
	<1247524340.4661.65.camel@abehat.net.rm.dk>
	<20090714084503.GA15753@lboro.ac.uk>
	<d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>
	<6B43981C32F8464CB24CEE209DA32BD302350ADD@kenya.tronet.as>
	<8e157ab40907162051t4d32d6cbudc1dacca82790ed1@mail.gmail.com>
Message-ID: <200907180455.n6I4tmr8016738@sj-core-2.cisco.com>

Hi Matt,

The 6500/sup720 on 33SXI supports 100K logical ports in MST, and 12K 
in RPVST. That's up from 50K/10K in every prior release.

N7K supports 75K in MST & 16K in RPVST today. There are no per-module 
limitations on N7K.

Those numbers are based on the requirements we expressed to QA/system 
test prior to FCS. The original numbers were confirmed prior to 33SXI 
was released. Since then, we have not had a customer 
requirement/request to support more, so frankly we have not felt 
compelled to go and requalifify for anything greater. Would be 
curious to know how many logical ports you are running today & in 
what protocol?

Thanks,
Tim


At 08:51 PM 7/16/2009, Matt Buford opined:
>My Cisco team suggested the Nexus as a potential way to alleviate my 6500
>virtual port limitation pain.  I asked for specifics on the STP limits of
>the Nexus, and they are significantly lower than the 6500.  Oops.




Tim Stevenson, tstevens at cisco.com
Routing & Switching CCIE #5561
Technical Marketing Engineer, Cisco Nexus 7000
Cisco - http://www.cisco.com
IP Phone: 408-526-6759
********************************************************
The contents of this message may be *Cisco Confidential*
and are intended for the specified recipients only.


From peter at rathlev.dk  Sat Jul 18 11:25:53 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Sat, 18 Jul 2009 17:25:53 +0200
Subject: [c-nsp] OT: Network documentation tool
Message-ID: <1247930754.5386.5.camel@abehat.net.rm.dk>

Kind of OT, but hopefully someone has an opinion anyway. :-)

I'm looking for the perfect documentation tool for network
documentation. We already have tools to map out the network and lots of
management tools, but what I'm looking for is something like a
repository to store and update all the written documentation, like
procedures and so on.

We've been looking at different Wikis, among others the Mediawiki suite,
and it looks promising but in my eyes seem a little much when we could
cope with somthing much simpler. We've also looked at document
repositories like Owl. We've even looked at Sharepoint. None of these
tools seem to be just right though.

What do people use to store documentation? Currently we use a CIFS share
but this seems clumsy at best.

Any input is appreciated. :-)

Regards,
Peter



From abalashov at evaristesys.com  Sat Jul 18 11:44:05 2009
From: abalashov at evaristesys.com (Alex Balashov)
Date: Sat, 18 Jul 2009 11:44:05 -0400
Subject: [c-nsp] OT: Network documentation tool
In-Reply-To: <1247930754.5386.5.camel@abehat.net.rm.dk>
References: <1247930754.5386.5.camel@abehat.net.rm.dk>
Message-ID: <4A61EDC5.6040201@evaristesys.com>

I've always used TWiki for this since my ISP days, turned onto it by a 
colleague.

It's a little difficult to wrap one's head around at first, since it's 
one of those wikis where administering it involves editing parts of 
certain pages (metawiki!).  But I have found that it's the best wiki for 
business purposes.  There's a great plugin ecosystem, including my 
favourite - a plugin to generate PDFs (branded cover sheets, tables of 
contents, etc.) from the pages, and all sorts of other neat stuff.  Lets 
me create and produce stylish, professional-looking network information 
sheets for turn-ups and installs for customers in a few minutes or less, 
since the underlying content is just some lines of simple wiki markup. 
There are also quite a few WYSIWYG editing plugins for documents, so if 
you want, you don't even have to learn wiki markup -- including a nice 
one to edit tables in a spreadsheet-like way, which is uniquely handy 
for managing IP address space information and other tabular data common 
in the network world in a shared way.

It's very good for managing changes and collaboration, and includes 
e-mail notification and summary of changes to all applicable parties. 
The content architecture is also modular; it allows you to set up "webs" 
(essentially, sub-wikis) that have their own distinct cosmetic styles, 
permissions, global preferences, etc., so it's a handy way to easily 
contain multiple wikis for different departments and/or levels of 
administrative and managerial privilege.  We have a management wiki that 
regular employees don't have access to that contains contracts/financial 
information/sensitive customer data/etc. and another wiki for everyone 
else, and all this was quite simple to do.

Just my 2 cents.

Peter Rathlev wrote:

> Kind of OT, but hopefully someone has an opinion anyway. :-)
> 
> I'm looking for the perfect documentation tool for network
> documentation. We already have tools to map out the network and lots of
> management tools, but what I'm looking for is something like a
> repository to store and update all the written documentation, like
> procedures and so on.
> 
> We've been looking at different Wikis, among others the Mediawiki suite,
> and it looks promising but in my eyes seem a little much when we could
> cope with somthing much simpler. We've also looked at document
> repositories like Owl. We've even looked at Sharepoint. None of these
> tools seem to be just right though.
> 
> What do people use to store documentation? Currently we use a CIFS share
> but this seems clumsy at best.
> 
> Any input is appreciated. :-)
> 
> 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/


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

From A.L.M.Buxey at lboro.ac.uk  Sat Jul 18 12:18:22 2009
From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk)
Date: Sat, 18 Jul 2009 17:18:22 +0100
Subject: [c-nsp] OT: Network documentation tool
In-Reply-To: <1247930754.5386.5.camel@abehat.net.rm.dk>
References: <1247930754.5386.5.camel@abehat.net.rm.dk>
Message-ID: <20090718161822.GA16658@lboro.ac.uk>

Hi,

> I'm looking for the perfect documentation tool for network

the obvious answer is the one that works for you and
your organisation. you say you've got a CIFS share right
now - but, used correctly, that might be the best way.
certainly easy to backup ;-)

we used some basic WIKI - qwikiwiki and then moved onto Drupal
which is currently in place. whilst good at providing content
it still suffers the curse of any written stuff (elec or print)
and that is that the network can quite easily make the docs look 
outdated - I would be very careful about what gets documented
and detailed - something like configs are (or should be!) already
being stored in usually a much better way - eg RANCID or another
RCS/SVN repository.  when things go wrong you dont want
to be digging through docs and a changelog system to try to map what
is and what was - you want to query your configs for anything
changed in the last eg 3 hours - thats what a proper config
store can tell you.  the docs should be higher level like
how the system is architectured...why you have what options
on VLANs and links etc.  thats my $0.01

(we also try to self-document as much as we can in places -
eg config files for DHCP and DNS can be veyr verbose...likewise
ACLs on routers/switches - use those remark commands! :-)

alan

From gert at greenie.muc.de  Sat Jul 18 15:36:53 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Sat, 18 Jul 2009 21:36:53 +0200
Subject: [c-nsp] edge router BGP
In-Reply-To: <4A5F99B2.90602@justinshore.com>
References: <C3412C29D7544726BA3D12A8F1C62FAB@EU.corp.clearwire.com>
	<20090716120511.M53115@fast-serv.com>
	<200907162029.31896.mtinka@globaltransit.net>
	<4A5F99B2.90602@justinshore.com>
Message-ID: <20090718193653.GP290@greenie.muc.de>

Hi,

On Thu, Jul 16, 2009 at 04:20:50PM -0500, Justin Shore wrote:
> It has 5x the backplane to boot plus it's hardware forwarding.  The only 
> real downside IMHO is that the unit uses SPAs which require SmartNets 
> per SPA (per license and per a lot of other things for that matter too). 

Uh.  Could you elaborate on that?  Especially the "per-license and a lot
of other things" bit?

We have no ASR1k yet, but if something like the ES20 "extra license for
IPv6 *per ES20 card*" is going to come back, this would be a strong reason
to finally go to the Vendor J camp.

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/20090718/097f175a/attachment.bin>

From pavel.skovajsa at gmail.com  Sat Jul 18 15:53:21 2009
From: pavel.skovajsa at gmail.com (Pavel Skovajsa)
Date: Sat, 18 Jul 2009 21:53:21 +0200
Subject: [c-nsp] OT: Network documentation tool
In-Reply-To: <20090718161822.GA16658@lboro.ac.uk>
References: <1247930754.5386.5.camel@abehat.net.rm.dk>
	<20090718161822.GA16658@lboro.ac.uk>
Message-ID: <323aca890907181253y3e5afdbav5909d5b22c77c7c5@mail.gmail.com>

Hi,

I believe the way the networks you manage is documented is one of the
main factors of the quality of everyday delivery. The reason for that
is that the network is "supported/operated" by different people that
actually built it, at least on the "early" levels of support.

The corrolary is, that as network-builder you need to perform a
knowledge tranfer to the support organization, therefore you need to
provide some kind of meaningful documentation. After that all you need
to do, is to find an efficient way for the support organization to
orientate in the vasts amount of documented information, to be able to
find the necessary info in timely fashion.

Having said this, it is obvious that no documenting system that allows
free unstructured placement of information is the correct answer.
Therefore I believe that no "free unstructured" documenting system
like Sharepoint, Wiki or CIFS is ideal for this job.

The need is for "strict&structured" documenting system that holds that
information about the entities on your network and their relationship.
The nature of network information that we want to document is indeed
structured therefore easily modeled by traditional decomposition
techniques. To give you an example:

1. basic entity is a device that has number of attributes - name, IP,
serial number, location etc.
2. devices have number of interfaces, each with attributes like name,
technology, speed etc. Interfaces link devices together and can be
monitored or not via our monitoring system.
3. devices belong to sites, which have subnets, visual maps, real post
addresses and people contacts
4. sites are connected by WAN links (on device interfaces) into
regions that have management contacts etc.

etc. etc.

This information can be then used more that for documentation
purposes, for example, billing, reporting etc. etc. whatever you think
about - for example devices can be linked with CVSView output from
RANCID.

No I do not know any open-source system that would have all of this,
that is why most big companies usually find some budget in order to
get something like above written from scratch.


-Pavel



On Sat, Jul 18, 2009 at 6:18 PM, <A.L.M.Buxey at lboro.ac.uk> wrote:
> Hi,
>
>> I'm looking for the perfect documentation tool for network
>
> the obvious answer is the one that works for you and
> your organisation. you say you've got a CIFS share right
> now - but, used correctly, that might be the best way.
> certainly easy to backup ;-)
>
> we used some basic WIKI - qwikiwiki and then moved onto Drupal
> which is currently in place. whilst good at providing content
> it still suffers the curse of any written stuff (elec or print)
> and that is that the network can quite easily make the docs look
> outdated - I would be very careful about what gets documented
> and detailed - something like configs are (or should be!) already
> being stored in usually a much better way - eg RANCID or another
> RCS/SVN repository. ?when things go wrong you dont want
> to be digging through docs and a changelog system to try to map what
> is and what was - you want to query your configs for anything
> changed in the last eg 3 hours - thats what a proper config
> store can tell you. ?the docs should be higher level like
> how the system is architectured...why you have what options
> on VLANs and links etc. ?thats my $0.01
>
> (we also try to self-document as much as we can in places -
> eg config files for DHCP and DNS can be veyr verbose...likewise
> ACLs on routers/switches - use those remark commands! :-)
>
> 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 saku at ytti.fi  Sat Jul 18 15:56:54 2009
From: saku at ytti.fi (Saku Ytti)
Date: Sat, 18 Jul 2009 22:56:54 +0300
Subject: [c-nsp] edge router BGP
In-Reply-To: <20090718193653.GP290@greenie.muc.de>
References: <C3412C29D7544726BA3D12A8F1C62FAB@EU.corp.clearwire.com>
	<20090716120511.M53115@fast-serv.com>
	<200907162029.31896.mtinka@globaltransit.net>
	<4A5F99B2.90602@justinshore.com>
	<20090718193653.GP290@greenie.muc.de>
Message-ID: <20090718195654.GA31389@mx.ytti.net>

On (2009-07-18 21:36 +0200), Gert Doering wrote:
 
> We have no ASR1k yet, but if something like the ES20 "extra license for
> IPv6 *per ES20 card*" is going to come back, this would be a strong reason
> to finally go to the Vendor J camp.

Strictly speaking, it's AFI agnostically for VPN. So IPv6 in global table
and you're good to go without extra 40kUSD GPL.

-- 
  ++ytti

From matt at overloaded.net  Sat Jul 18 16:06:31 2009
From: matt at overloaded.net (Matt Buford)
Date: Sat, 18 Jul 2009 15:06:31 -0500
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <200907180455.n6I4tmr8016738@sj-core-2.cisco.com>
References: <9DE4AA6876D44B62B87C475B2AFE5514@au.didata.local>
	<a1873f1f0907131438m3f0b4c70r82a953a29042b6d7@mail.gmail.com>
	<1247524340.4661.65.camel@abehat.net.rm.dk>
	<20090714084503.GA15753@lboro.ac.uk>
	<d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>
	<6B43981C32F8464CB24CEE209DA32BD302350ADD@kenya.tronet.as>
	<8e157ab40907162051t4d32d6cbudc1dacca82790ed1@mail.gmail.com>
	<200907180455.n6I4tmr8016738@sj-core-2.cisco.com>
Message-ID: <8e157ab40907181306h87f6e8bv2838d248050c65b@mail.gmail.com>

On Fri, Jul 17, 2009 at 11:55 PM, Tim Stevenson <tstevens at cisco.com> wrote:

> The 6500/sup720 on 33SXI supports 100K logical ports in MST, and 12K in
> RPVST. That's up from 50K/10K in every prior release.
>

Did the per-slot limitation change too?

N7K supports 75K in MST & 16K in RPVST today. There are no per-module
> limitations on N7K.
>
> Those numbers are based on the requirements we expressed to QA/system test
> prior to FCS. The original numbers were confirmed prior to 33SXI was
> released. Since then, we have not had a customer requirement/request to
> support more, so frankly we have not felt compelled to go and requalifify
> for anything greater. Would be curious to know how many logical ports you
> are running today & in what protocol?
>

First, I'm sorry for not being clear.  While the virtual port per-slot
limitation is an issue with our distribution switches, when we discussed a
Nexus based solution with Cisco the big sticking point was actually with
using the 5000 series as access switches for customer servers to plug into
in the data center.  There were 2 major issues:

1.  Wiring is a huge issue for us, especially as we migrate to all gigabit
and lose RJ21 support on the switches.  Cisco's suggestion was that we could
use the Nexus and have only a single network cable to every server (just tag
all the networks you want, plus FCoE).  However, we use private vlans for
the backup network, and sometimes for other things.  We can't tag a pvlan to
a customer, and the switch has no way to present what needs to effectively
be a pvlan host port as a tag to a customer.  Cisco did say that a feature
to deal with this might be coming.

2.  Nexus 5000 only supported 256 VLANs at the time, with support for 512
coming soon.  I have ~550 VLANs today, and the number is only that low
because I artificially chopped my largest data center into 2 smaller
networks because of STP hardware limitations in Cisco's switches.
 Additionally, when I asked about the virtual port limitations, I was told
there is no per-slot limit, but there is a 3000 logical port limitation on
the chassis as a whole, which again doesn't even come close to meeting my
needs.  This discussion was about 6 months ago, and really focused on the
Nexus 5000 series as an option to replace both our distribution and
access/edge switches.  I can't really remember if the 7000 series was
discussed at all.  It may have been skipped over for price reasons.

I am running rapid-PVSTP, and my switches are running various SXF code.
 Below is the busiest switch I could find.  This is an "old" network whose
growth has been capped because of STP hardware limitations.  We don't allow
any new customers on this network, and built a 2nd network in the same
building for new customers.   The VLAN count on this switch does still
slowly rise though as existing customers on the old network continue to
expand.

#sh vlan vir

Slot 1
-------
Total slot virtual ports 6448

Slot 2
-------
Total slot virtual ports 1636

Total chassis virtual ports 8084

#sh mod
Mod Ports Card Type                              Model              Serial
No.
--- ----- -------------------------------------- ------------------
-----------
  1   16  SFM-capable 16 port 1000mb GBIC        WS-X6516A-GBIC
  2    4  CEF720 4 port 10-Gigabit Ethernet      WS-X6704-10GE
  5    2  Supervisor Engine 720 (Active)         WS-SUP720-3B


It's pretty much always the 6516-GBIC cards that lead downstream to access
switches that have the high virtual port counts.

In the end, one of the biggest hassles this creates is the physical server
placement problems after chopping things up into smaller networks.  We might
start out saying we'll cap network growth to roughly room-sized.  Room 1 is
network 1.  When that gets mostly full, we start putting new customers on
network 2 in room 2.  At some point in the future, both room 1 and room 2
become nearly full and we start network 3 in room 3.  Room 1 and 2 continue
to grow slowly due to existing customer expansion, and at some point they
become 100% full and those customers still want to add servers.  Then we end
up with network 1 being extended to row 1 of room 3, network 2 in row 2 of
room 3, and then rows 3 and higher in room 3 are network 3.  Wait, the
building is 100% full now, so we need to expand the 3 old networks to a few
rows in a new building down the street?  Building 1 network 1 will be
present in building 2 room 1 row 1 too, etc....  This is all great fun to
try to keep straight.  :)

From pavel.skovajsa at gmail.com  Sat Jul 18 16:15:51 2009
From: pavel.skovajsa at gmail.com (Pavel Skovajsa)
Date: Sat, 18 Jul 2009 22:15:51 +0200
Subject: [c-nsp] Free NMS Tools
In-Reply-To: <20090717070140.GA22208@mx.ytti.net>
References: <F1755DA0C92B4B0F8EEA558869BD8D1B@experienbd1776>
	<4f890e580907030600y3f8e6c15qfa6c4b4db539fec@mail.gmail.com>
	<20090717070140.GA22208@mx.ytti.net>
Message-ID: <323aca890907181315k325c45e6t97814af27f8f33db@mail.gmail.com>

Hi Saku,

I fully symphatetize with everything you said. The problem is that
there is NO system on the world with all of below, none of the
Nagios/OpenNMS etc. system do automatically what you have decribed
below. Most of them reduce their default activity to "let's ping it
and see what happens".

I am sure that some of those systems are open and prepared enough to
have this configured in some complicated manual way, and trigger
alarms based on this. Maybe also (dreaming) automatically logging onto
the device and getting necessary command output and possibly fixing a
simple situation (dreaming and smoking too much).

A good example of a beginning of such automatic expert system is Cisco
Output Interpreter.

Therefore all of this manual activity needs to be performed on per
device basis, which is time&effort consuming, which in our everyday
reality turns into people not doing it at all and stick with the old
''let's ping it and see what happens"

-Pavel


On Fri, Jul 17, 2009 at 9:01 AM, Saku Ytti<saku at ytti.fi> wrote:
> On (2009-07-03 14:00 +0100), Mario Spinthiras wrote:
>
> Hey,
>
>> I would say Zenoss is looking good because of the inventory management you
>> can do and because of the logical structure it puts everything in. I wrote
>>
>> Everything else just seems inadequate or poor.
>
> I recently spent few moments evaluating zenoss and was not impressed. To me
> all OSS NMS solutions out seem like they are made by coder-in-server-admin
> not coder-in-network-admin, and as such seem to have much more integration
> with servers than with network, zenoss seems like no exception.
>
> My main grief with NMS I've looked at is virtually no integration with network
> devices out of the box. Why don't they ship with MIBs or just specific OIDs
> for few top vendors important traps etc? Adding appropriate reaction
> classification. Networking is comparatively homogeneous environment, unlike
> server admins who have high variance in OS and applications, network
> operators out there have very similar requirements, allowing very advanced
> integration out-of-the-box. People want NMS to automatically monitor BGP,
> OSPF, IS-IS, LDP, status of some other CPU/memory than just control-plane
> pending few minutes thinking it would be easy to add lot of really common
> things here, that would be desired by very many network operators.
>
> Other thing that annoys me is how SNMP pollers are implemented, they're
> blocking, giving sucky performance on misbehaving or down nodes. And
> even still puzzlingly slow. While having SNMP poller poll 140k OID
> per second on 386 class PC is rather trivial, using two process strategy,
> where single process spews packets outs, and another listens what comes
> back, completely asynchronous, agnostic to any problem host may have.
> I've also only seen alarms based on absolute values of different counters,
> like CPU, memory, iface error counters etc. While I'd like automatic
> trending alarms, so if my memory use for past 5 months was relatively
> static, then for few consecutive days has increased steadily, it is
> likely memory leak, and I want to know about it, even if I have GB's of
> free memory. This type of 'trending' module should be relatively
> easy, and could be reused by any counter values.
>
> I demoed zenoss with 27 routers and it froze trying to poll their
> interface (granted there are very many interfaces). (2.3GHz Intel,
> with 2GB of memory), turning performance graphs off helped, of course.
> Trying to use zenpacks to add (3rd party provided) Cisco MIBs took
> hours and failed due to exhausted disk space, not sure which device
> it was, as it didn't tell, but smallest is /tmp with 186MB free.
>
> I'd be happy to pay zenoss enteprise costs, if it would have
> basics integration with network, but value it actually delivers
> to me, is actually so modest, you can pick up any other
> NMS there or hack something on your own. Since most time would
> be committed anyhow adding basic functionality.
>
> Thanks,
> --
> ?++ytti
> _______________________________________________
> cisco-nsp mailing list ?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  Sat Jul 18 18:19:54 2009
From: tdurack at gmail.com (Tim Durack)
Date: Sat, 18 Jul 2009 18:19:54 -0400
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <8e157ab40907181306h87f6e8bv2838d248050c65b@mail.gmail.com>
References: <9DE4AA6876D44B62B87C475B2AFE5514@au.didata.local>
	<a1873f1f0907131438m3f0b4c70r82a953a29042b6d7@mail.gmail.com>
	<1247524340.4661.65.camel@abehat.net.rm.dk>
	<20090714084503.GA15753@lboro.ac.uk>
	<d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>
	<6B43981C32F8464CB24CEE209DA32BD302350ADD@kenya.tronet.as>
	<8e157ab40907162051t4d32d6cbudc1dacca82790ed1@mail.gmail.com>
	<200907180455.n6I4tmr8016738@sj-core-2.cisco.com>
	<8e157ab40907181306h87f6e8bv2838d248050c65b@mail.gmail.com>
Message-ID: <9e246b4d0907181519k388a22ecs2a05afe7209e630b@mail.gmail.com>

On Sat, Jul 18, 2009 at 4:06 PM, Matt Buford <matt at overloaded.net> wrote:

> On Fri, Jul 17, 2009 at 11:55 PM, Tim Stevenson <tstevens at cisco.com>
> wrote:
>
> > The 6500/sup720 on 33SXI supports 100K logical ports in MST, and 12K in
> > RPVST. That's up from 50K/10K in every prior release.
> >
>
> Did the per-slot limitation change too?
>
> N7K supports 75K in MST & 16K in RPVST today. There are no per-module
> > limitations on N7K.
> >
> > Those numbers are based on the requirements we expressed to QA/system
> test
> > prior to FCS. The original numbers were confirmed prior to 33SXI was
> > released. Since then, we have not had a customer requirement/request to
> > support more, so frankly we have not felt compelled to go and requalifify
> > for anything greater. Would be curious to know how many logical ports you
> > are running today & in what protocol?
> >
>

Whilst we are sort-of happy with MST in our environment, I think what this
discussion shows is that STP is past it's sell-by date. It works, but is
somewhat brittle.

It will be interesting to see what the various L2MP/TRILL initiatives
produce. Googling around for "Cisco Overlay Transport Virtualization" turns
up an interesting looking patent. I doubt we'll have hardware that supports
this anytime soon (maybe Nexus.)

Tim:>

From kgraham at industrial-marshmallow.com  Sat Jul 18 23:24:39 2009
From: kgraham at industrial-marshmallow.com (Kevin Graham)
Date: Sat, 18 Jul 2009 20:24:39 -0700 (PDT)
Subject: [c-nsp] c877 and ntp oddness
In-Reply-To: <h3keci$piu$1@ger.gmane.org>
References: <h3ic1u$crf$1@ger.gmane.org> <20090715073018.GF6613@zengl.net>
	<h3keci$piu$1@ger.gmane.org>
Message-ID: <43532.88404.qm@web1212.biz.mail.gq1.yahoo.com>


> >> Have a bizarre NTP issue with 877 routers running 12.4(T) train.

> >>
> >> - Only seems to affect a small percentage of 877 routers,
> >> 878s, 1800s , 2800s seem to be fine
> > 
> > A coworker reported the exact same behavior a couple of weeks ago. They
> > got 87x routers with a new hardware revision, these routers do not sync
> > with ntp anymore. TAC case is open, but nothing concrete so far.

Are you sure its hardware related and release-specific? With the
introduction of NTPv4 in (22)T it appears NTP access-groups are broken,
requiring them to be removed or everything given 'peer' access. (Covered in
CSCsw79186, though the problem is much more widespread than release notes
there indicate).

From david.freedman at uk.clara.net  Sun Jul 19 08:04:53 2009
From: david.freedman at uk.clara.net (David Freedman)
Date: Sun, 19 Jul 2009 13:04:53 +0100
Subject: [c-nsp] c877 and ntp oddness
References: <h3ic1u$crf$1@ger.gmane.org> <20090715073018.GF6613@zengl.net>
	<h3keci$piu$1@ger.gmane.org>
	<43532.88404.qm@web1212.biz.mail.gq1.yahoo.com>
Message-ID: <7B8B0D6F623C3A40A0D0A80A66756E2B0D7DFD@EXVS01.claranet.local>

Well, 

1. the problem is apparent in both 15T and 22T
2. No access groups are configured
3. NTPv3, 2 and 1 were tried.
4. Peer syncs and after about 10 mins is declared "insane" and relationship is lost,
removal of the "clock-period" (in 15T) fixes the issue which points to incorrect calculation
of the clock-period (hardware offset), since this persists between versions
would suggest a hardware issue to me?

Dave.

------------------------------------------------
David Freedman
Group Network Engineering 
Claranet Limited
http://www.clara.net



-----Original Message-----
From: Kevin Graham [mailto:kgraham at industrial-marshmallow.com]
Sent: Sun 7/19/2009 04:24
To: David Freedman; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] c877 and ntp oddness
 

> >> Have a bizarre NTP issue with 877 routers running 12.4(T) train.

> >>
> >> - Only seems to affect a small percentage of 877 routers,
> >> 878s, 1800s , 2800s seem to be fine
> > 
> > A coworker reported the exact same behavior a couple of weeks ago. They
> > got 87x routers with a new hardware revision, these routers do not sync
> > with ntp anymore. TAC case is open, but nothing concrete so far.

Are you sure its hardware related and release-specific? With the
introduction of NTPv4 in (22)T it appears NTP access-groups are broken,
requiring them to be removed or everything given 'peer' access. (Covered in
CSCsw79186, though the problem is much more widespread than release notes
there indicate).


From cluestore at gmail.com  Sun Jul 19 14:13:39 2009
From: cluestore at gmail.com (Clue Store)
Date: Sun, 19 Jul 2009 13:13:39 -0500
Subject: [c-nsp]  ASA Multiple Context Mode
Message-ID: <580af3b90907191113rfe9cf2fj77dee3f1832eca0d@mail.gmail.com>

Hi All,


As I understand that the ASA in multiple context mode does not support
"VPN's", does this also inclue SSL VPN's?? Someone has mentioned that it
turns off IPSEC engine in this mode, but I have not been able to find
anywhere where it says SSL VPN's are not supported. If it doesn't support
SSL VPN, what are other folks doing for VPN's in this situation where
multiple contexts are being used??

TIA,
Clue

From rwest at zyedge.com  Sun Jul 19 14:33:04 2009
From: rwest at zyedge.com (Ryan West)
Date: Sun, 19 Jul 2009 14:33:04 -0400
Subject: [c-nsp] ASA Multiple Context Mode
In-Reply-To: <580af3b90907191113rfe9cf2fj77dee3f1832eca0d@mail.gmail.com>
References: <580af3b90907191113rfe9cf2fj77dee3f1832eca0d@mail.gmail.com>
Message-ID: <6E21B2BDEF6E714EA0B5BA8D5D0E1401248380ADEA@zy-ex1.zyedge.local>

Clue,

I am pretty sure that it doesn't support SSL VPN's either.  All NetPro discussions show the same results.  Assuming you are support multiple customers and want to give them access to their firewall, or whatever you reason for choosing multiple context may be, you should use another ASA pair in Active/Standby to provide VPN termination services.  You may have to mess around with RRI, but you should be able to pull off customer segregation using VLANs.

-ryan

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Clue Store
Sent: Sunday, July 19, 2009 2:14 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] ASA Multiple Context Mode

Hi All,


As I understand that the ASA in multiple context mode does not support
"VPN's", does this also inclue SSL VPN's?? Someone has mentioned that it
turns off IPSEC engine in this mode, but I have not been able to find
anywhere where it says SSL VPN's are not supported. If it doesn't support
SSL VPN, what are other folks doing for VPN's in this situation where
multiple contexts are being used??

TIA,
Clue
_______________________________________________
cisco-nsp mailing list  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  Sun Jul 19 15:26:49 2009
From: moua0100 at umn.edu (Ge Moua)
Date: Sun, 19 Jul 2009 14:26:49 -0500
Subject: [c-nsp] ASA Multiple Context Mode
In-Reply-To: <6E21B2BDEF6E714EA0B5BA8D5D0E1401248380ADEA@zy-ex1.zyedge.local>
References: <580af3b90907191113rfe9cf2fj77dee3f1832eca0d@mail.gmail.com>
	<6E21B2BDEF6E714EA0B5BA8D5D0E1401248380ADEA@zy-ex1.zyedge.local>
Message-ID: <4A637379.3000201@umn.edu>

I've done IOS based WebVPN with multiple VRFs (vrf-lite in this case); 
this is somewhat analogous to the ASA w/ multiple context; I know you 
mentioned how to do this on the ASA which I don't believe is possible.

Our Cisco Acct SE mentioned vlan mapping where you terminate the 
webvpn/ipsec tunnel on one interface but then funnel the designated 
traffic per customer to different downstream vlan or interfaces; 
essentially this allows you to have multiple customer group in one 
context; i've seen docs on cisco cco that mentions this as well; good luck.


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

Network Design Engineer
University of Minnesota | Networking & Telecommunications Services



Ryan West wrote:
> Clue,
>
> I am pretty sure that it doesn't support SSL VPN's either.  All NetPro discussions show the same results.  Assuming you are support multiple customers and want to give them access to their firewall, or whatever you reason for choosing multiple context may be, you should use another ASA pair in Active/Standby to provide VPN termination services.  You may have to mess around with RRI, but you should be able to pull off customer segregation using VLANs.
>
> -ryan
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Clue Store
> Sent: Sunday, July 19, 2009 2:14 PM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] ASA Multiple Context Mode
>
> Hi All,
>
>
> As I understand that the ASA in multiple context mode does not support
> "VPN's", does this also inclue SSL VPN's?? Someone has mentioned that it
> turns off IPSEC engine in this mode, but I have not been able to find
> anywhere where it says SSL VPN's are not supported. If it doesn't support
> SSL VPN, what are other folks doing for VPN's in this situation where
> multiple contexts are being used??
>
> TIA,
> Clue
> _______________________________________________
> cisco-nsp mailing 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 rwest at zyedge.com  Sun Jul 19 15:28:36 2009
From: rwest at zyedge.com (Ryan West)
Date: Sun, 19 Jul 2009 15:28:36 -0400
Subject: [c-nsp] ASA Multiple Context Mode
In-Reply-To: <4A637379.3000201@umn.edu>
References: <580af3b90907191113rfe9cf2fj77dee3f1832eca0d@mail.gmail.com>
	<6E21B2BDEF6E714EA0B5BA8D5D0E1401248380ADEA@zy-ex1.zyedge.local>
	<4A637379.3000201@umn.edu>
Message-ID: <6E21B2BDEF6E714EA0B5BA8D5D0E1401248380ADEB@zy-ex1.zyedge.local>

Ge,

That's exactly what I was referring to, 2 pairs, one for the multiple context and one for the VPN terminations.  Then the group-policy mappings contain the VLAN mapping for each customer.

-ryan

-----Original Message-----
From: Ge Moua [mailto:moua0100 at umn.edu] 
Sent: Sunday, July 19, 2009 3:27 PM
To: Ryan West
Cc: Clue Store; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] ASA Multiple Context Mode

I've done IOS based WebVPN with multiple VRFs (vrf-lite in this case); 
this is somewhat analogous to the ASA w/ multiple context; I know you 
mentioned how to do this on the ASA which I don't believe is possible.

Our Cisco Acct SE mentioned vlan mapping where you terminate the 
webvpn/ipsec tunnel on one interface but then funnel the designated 
traffic per customer to different downstream vlan or interfaces; 
essentially this allows you to have multiple customer group in one 
context; i've seen docs on cisco cco that mentions this as well; good luck.


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

Network Design Engineer
University of Minnesota | Networking & Telecommunications Services



Ryan West wrote:
> Clue,
>
> I am pretty sure that it doesn't support SSL VPN's either.  All NetPro discussions show the same results.  Assuming you are support multiple customers and want to give them access to their firewall, or whatever you reason for choosing multiple context may be, you should use another ASA pair in Active/Standby to provide VPN termination services.  You may have to mess around with RRI, but you should be able to pull off customer segregation using VLANs.
>
> -ryan
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Clue Store
> Sent: Sunday, July 19, 2009 2:14 PM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] ASA Multiple Context Mode
>
> Hi All,
>
>
> As I understand that the ASA in multiple context mode does not support
> "VPN's", does this also inclue SSL VPN's?? Someone has mentioned that it
> turns off IPSEC engine in this mode, but I have not been able to find
> anywhere where it says SSL VPN's are not supported. If it doesn't support
> SSL VPN, what are other folks doing for VPN's in this situation where
> multiple contexts are being used??
>
> TIA,
> Clue
> _______________________________________________
> cisco-nsp mailing 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 steve at ibctech.ca  Sun Jul 19 17:08:34 2009
From: steve at ibctech.ca (Steve Bertrand)
Date: Sun, 19 Jul 2009 17:08:34 -0400
Subject: [c-nsp] Splicing a roll-over cable
Message-ID: <4A638B52.7070107@ibctech.ca>

Hi all,

I've finally got some new routers in that I'll be using for testing (the
IPv6 BGP route-reflector situation is on the top of the list).

The lab area is very close to my workstation. Before I have the devices
connected to a network, I prefer to use my workstation to copy config
snips et-al to the devices.

Oftentimes, I'll use a lab pc to do similar jobs, so I unplug the
console cable from the device from my workstation serial port and
connect to a lab pc serial port.

I don't know much (ie. anything) about the electrical properties of a
serial pc interface, so I thought I'd ask whether it would do any harm
to 'splice' into a roll-over cable so the input/output from the console
can be used simultaneously from multiple command stations, without
having to do the physical unplug/replug.

Essentially, I'd like keystrokes to be seen on one monitor that is
connected to the console that is typed on another device connected to
the same console port.

Steve

ps. I'll be testing this on a 26xx tomorrow if this hasn't been tried ;)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3233 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090719/fa4db84c/attachment.bin>

From jay at west.net  Sun Jul 19 17:29:03 2009
From: jay at west.net (Jay Hennigan)
Date: Sun, 19 Jul 2009 14:29:03 -0700
Subject: [c-nsp] Splicing a roll-over cable
In-Reply-To: <4A638B52.7070107@ibctech.ca>
References: <4A638B52.7070107@ibctech.ca>
Message-ID: <4A63901F.70906@west.net>

Steve Bertrand wrote:
> Hi all,
> 
> I've finally got some new routers in that I'll be using for testing (the
> IPv6 BGP route-reflector situation is on the top of the list).
> 
> The lab area is very close to my workstation. Before I have the devices
> connected to a network, I prefer to use my workstation to copy config
> snips et-al to the devices.
> 
> Oftentimes, I'll use a lab pc to do similar jobs, so I unplug the
> console cable from the device from my workstation serial port and
> connect to a lab pc serial port.
> 
> I don't know much (ie. anything) about the electrical properties of a
> serial pc interface, so I thought I'd ask whether it would do any harm
> to 'splice' into a roll-over cable so the input/output from the console
> can be used simultaneously from multiple command stations, without
> having to do the physical unplug/replug.
> 
> Essentially, I'd like keystrokes to be seen on one monitor that is
> connected to the console that is typed on another device connected to
> the same console port.

RS-232 drivers should have sufficient current to drive two receivers, 
but two drivers in parallel will tend to pull the line in opposite 
directions.

In other words, if you connect the router's send line and ground to both 
monitors, the output can be displayed on both simultaneously.  You 
probably won't see the command input on the second one, however.

Two keyboards driving the router isn't going to work well, probably not 
at all.

VNC on the PCs might be a better choice to solve this problem.

--
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 David at hughes.com.au  Sun Jul 19 17:39:48 2009
From: David at hughes.com.au (David Hughes)
Date: Mon, 20 Jul 2009 07:39:48 +1000
Subject: [c-nsp] ASA Multiple Context Mode
In-Reply-To: <580af3b90907191113rfe9cf2fj77dee3f1832eca0d@mail.gmail.com>
References: <580af3b90907191113rfe9cf2fj77dee3f1832eca0d@mail.gmail.com>
Message-ID: <DA05CE02-7951-444A-9FD1-34C82B3C9DD1@Hughes.com.au>


On 20/07/2009, at 4:13 AM, Clue Store wrote:

>  If it doesn't support
> SSL VPN, what are other folks doing for VPN's in this situation where
> multiple contexts are being used??

Hi


We use a router running vrf-aware ipsec to drop users from each  
customer into a vlan on their ASA context.  Works pretty well.



David
...

From cluestore at gmail.com  Sun Jul 19 20:01:14 2009
From: cluestore at gmail.com (Clue Store)
Date: Sun, 19 Jul 2009 19:01:14 -0500
Subject: [c-nsp] ASA Multiple Context Mode
In-Reply-To: <DA05CE02-7951-444A-9FD1-34C82B3C9DD1@Hughes.com.au>
References: <580af3b90907191113rfe9cf2fj77dee3f1832eca0d@mail.gmail.com>
	<DA05CE02-7951-444A-9FD1-34C82B3C9DD1@Hughes.com.au>
Message-ID: <580af3b90907191701k3ad2c1bfrd06eb5128a777e9e@mail.gmail.com>

Hi David,

Does this mean you're terminating the ipsec tunnel on a router inside the
vrf through the context?? I was thinking about this but wasn't sure what
nastyness would come out of it. MTU issues, etc...

On Sun, Jul 19, 2009 at 4:39 PM, David Hughes <David at hughes.com.au> wrote:

>
> On 20/07/2009, at 4:13 AM, Clue Store wrote:
>
>  If it doesn't support
>> SSL VPN, what are other folks doing for VPN's in this situation where
>> multiple contexts are being used??
>>
>
> Hi
>
>
> We use a router running vrf-aware ipsec to drop users from each customer
> into a vlan on their ASA context.  Works pretty well.
>
>
>
> David
> ...
>

From cluestore at gmail.com  Sun Jul 19 20:08:10 2009
From: cluestore at gmail.com (Clue Store)
Date: Sun, 19 Jul 2009 19:08:10 -0500
Subject: [c-nsp] ASA Multiple Context Mode
In-Reply-To: <580af3b90907191701k3ad2c1bfrd06eb5128a777e9e@mail.gmail.com>
References: <580af3b90907191113rfe9cf2fj77dee3f1832eca0d@mail.gmail.com>
	<DA05CE02-7951-444A-9FD1-34C82B3C9DD1@Hughes.com.au>
	<580af3b90907191701k3ad2c1bfrd06eb5128a777e9e@mail.gmail.com>
Message-ID: <580af3b90907191708g669a6b47ud74f6bc31a3241a2@mail.gmail.com>

I think I read your post wrong the first time around. You're terminating the
tunnel on a router thats vrf aware and dropping the traffic on the inside of
the tunnel on a vlan that's in the same vlan as their context. Correct??

On Sun, Jul 19, 2009 at 7:01 PM, Clue Store <cluestore at gmail.com> wrote:

> Hi David,
>
> Does this mean you're terminating the ipsec tunnel on a router inside the
> vrf through the context?? I was thinking about this but wasn't sure what
> nastyness would come out of it. MTU issues, etc...
>
>   On Sun, Jul 19, 2009 at 4:39 PM, David Hughes <David at hughes.com.au>wrote:
>
>>
>> On 20/07/2009, at 4:13 AM, Clue Store wrote:
>>
>>  If it doesn't support
>>> SSL VPN, what are other folks doing for VPN's in this situation where
>>> multiple contexts are being used??
>>>
>>
>> Hi
>>
>>
>> We use a router running vrf-aware ipsec to drop users from each customer
>> into a vlan on their ASA context.  Works pretty well.
>>
>>
>>
>> David
>> ...
>>
>
>

From steve at ibctech.ca  Sun Jul 19 20:37:40 2009
From: steve at ibctech.ca (Steve Bertrand)
Date: Sun, 19 Jul 2009 20:37:40 -0400
Subject: [c-nsp] Splicing a roll-over cable
In-Reply-To: <4A63901F.70906@west.net>
References: <4A638B52.7070107@ibctech.ca> <4A63901F.70906@west.net>
Message-ID: <4A63BC54.5030407@ibctech.ca>

Jay Hennigan wrote:

[..huge snip..]

> VNC on the PCs might be a better choice to solve this problem.

I'm used to FreeBSD... instead of:

# ssh -l myname lab.box
# sudo cu -l /dev/cuad0

... I was hoping for something a little more closer to the device itself
(if possible).

The lab pc boxen are not connected to any network (including the network
my workstation belongs to).

I was hoping to communicate with the defunct and way-too-old devices
without having to use IP based communication.

Because my knowledge and experience is being forced upon playing with
the likes of 2691-type hardware, I figured that I might try frying a
couple during testing...

..instead of using a remote control software, I was hoping that rs232
would solve this, just for playing around.

Steve

ps: For the love of God...does anyone have 1 or 10 g lab hardware that a
semi-skilled engineer can look at, and get familiar with it's convention
?! ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3233 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090719/9afad4d3/attachment.bin>

From David at Hughes.com.au  Sun Jul 19 20:46:14 2009
From: David at Hughes.com.au (David Hughes)
Date: Mon, 20 Jul 2009 10:46:14 +1000
Subject: [c-nsp] OT: Network documentation tool
In-Reply-To: <1247930754.5386.5.camel@abehat.net.rm.dk>
References: <1247930754.5386.5.camel@abehat.net.rm.dk>
Message-ID: <6BC96C97-017C-44D7-AE49-0AE57E6CC3B8@Hughes.com.au>


On 19/07/2009, at 1:25 AM, Peter Rathlev wrote:
> What do people use to store documentation? Currently we use a CIFS  
> share
> but this seems clumsy at best.

Hi

We use a Subversion repository and store all documents in there (word,  
pdf, text, etc etc).  Our reasoning for using this rather than the  
corporate sharepoint installation or a Wiki is that using a solution  
that requires a functioning network just to access your documentation  
is fundamentally flawed IMHO.  I wanted my team to have access to all  
network doc's on their notebook any time they needed them (i.e. during  
a network outage etc).

There are Mac, Windows and *nix clients.  It's worked very well over  
the years.


David
...

From David at hughes.com.au  Sun Jul 19 20:49:56 2009
From: David at hughes.com.au (David Hughes)
Date: Mon, 20 Jul 2009 10:49:56 +1000
Subject: [c-nsp] ASA Multiple Context Mode
In-Reply-To: <580af3b90907191701k3ad2c1bfrd06eb5128a777e9e@mail.gmail.com>
References: <580af3b90907191113rfe9cf2fj77dee3f1832eca0d@mail.gmail.com>
	<DA05CE02-7951-444A-9FD1-34C82B3C9DD1@Hughes.com.au>
	<580af3b90907191701k3ad2c1bfrd06eb5128a777e9e@mail.gmail.com>
Message-ID: <CF5A4DE6-5CA9-4ABC-8529-2A0D79ED2672@hughes.com.au>


Hi

No, the outside of the router is outside the firewall.   The tunnel  
terminates on that device and we drop the client traffic through the  
vrf and a sub-int onto a vlan that's presented as a DMZ to the  
firewall context.  Any security policy can then be applied to it via  
the ASA.


David
...

On 20/07/2009, at 10:01 AM, Clue Store wrote:

> Hi David,
>
> Does this mean you're terminating the ipsec tunnel on a router  
> inside the
> vrf through the context?? I was thinking about this but wasn't sure  
> what
> nastyness would come out of it. MTU issues, etc...
>
> On Sun, Jul 19, 2009 at 4:39 PM, David Hughes <David at hughes.com.au>  
> wrote:
>
>>
>> On 20/07/2009, at 4:13 AM, Clue Store wrote:
>>
>> If it doesn't support
>>> SSL VPN, what are other folks doing for VPN's in this situation  
>>> where
>>> multiple contexts are being used??
>>>
>>
>> Hi
>>
>>
>> We use a router running vrf-aware ipsec to drop users from each  
>> customer
>> into a vlan on their ASA context.  Works pretty well.
>>
>>
>>
>> David
>> ...
>>


From cluestore at gmail.com  Sun Jul 19 20:56:11 2009
From: cluestore at gmail.com (Clue Store)
Date: Sun, 19 Jul 2009 19:56:11 -0500
Subject: [c-nsp] ASA Multiple Context Mode
In-Reply-To: <CF5A4DE6-5CA9-4ABC-8529-2A0D79ED2672@hughes.com.au>
References: <580af3b90907191113rfe9cf2fj77dee3f1832eca0d@mail.gmail.com>
	<DA05CE02-7951-444A-9FD1-34C82B3C9DD1@Hughes.com.au>
	<580af3b90907191701k3ad2c1bfrd06eb5128a777e9e@mail.gmail.com>
	<CF5A4DE6-5CA9-4ABC-8529-2A0D79ED2672@hughes.com.au>
Message-ID: <580af3b90907191756g484661fr63ac5a465514aefe@mail.gmail.com>

Gotcha, after I re-read your post, that's when it hit me as to what you were
doing. This seems much more ecominical than buying another active/failover
pair of ASA's just to terminate tunnels. I have a couple of 7200's on the
shelf that would be perfect for this as we are almost at our budget limit
for this project.

Great solution, thanks.
Clue

On Sun, Jul 19, 2009 at 7:49 PM, David Hughes <David at hughes.com.au> wrote:

>
> Hi
>
> No, the outside of the router is outside the firewall.   The tunnel
> terminates on that device and we drop the client traffic through the vrf and
> a sub-int onto a vlan that's presented as a DMZ to the firewall context.
>  Any security policy can then be applied to it via the ASA.
>
>
> David
> ...
>
>
> On 20/07/2009, at 10:01 AM, Clue Store wrote:
>
> Hi David,
>>
>> Does this mean you're terminating the ipsec tunnel on a router inside the
>> vrf through the context?? I was thinking about this but wasn't sure what
>> nastyness would come out of it. MTU issues, etc...
>>
>> On Sun, Jul 19, 2009 at 4:39 PM, David Hughes <David at hughes.com.au>
>> wrote:
>>
>>
>>> On 20/07/2009, at 4:13 AM, Clue Store wrote:
>>>
>>> If it doesn't support
>>>
>>>> SSL VPN, what are other folks doing for VPN's in this situation where
>>>> multiple contexts are being used??
>>>>
>>>>
>>> Hi
>>>
>>>
>>> We use a router running vrf-aware ipsec to drop users from each customer
>>> into a vlan on their ASA context.  Works pretty well.
>>>
>>>
>>>
>>> David
>>> ...
>>>
>>>
>

From td_miles at yahoo.com  Sun Jul 19 21:17:46 2009
From: td_miles at yahoo.com (Tony)
Date: Sun, 19 Jul 2009 18:17:46 -0700 (PDT)
Subject: [c-nsp] Splicing a roll-over cable
Message-ID: <253798.35523.qm@web110108.mail.gq1.yahoo.com>


What about something from Black Box. I'm not sure if the link below is exactly what you need, but they have all sorts of devices for converting, extending and sharing serial connections. Not as cheap as splicing your own serial/console cable, but potentially more chance of success (and you can return it if it doesn't work). There's also probably someone making something similar in a no-name product that does the same thing if you look around.


http://www.blackbox.com/Store/Detail.aspx/Modem-Splitter-3-Port-MS-3/TL073A-R4



regards,
Tony.

--- On Mon, 20/7/09, Steve Bertrand <steve at ibctech.ca> wrote:

> From: Steve Bertrand <steve at ibctech.ca>
> Subject: Re: [c-nsp] Splicing a roll-over cable
> To: "Jay Hennigan" <jay at west.net>
> Cc: "Cisco-NSP Mailing List" <cisco-nsp at puck.nether.net>
> Date: Monday, 20 July, 2009, 10:37 AM
> Jay Hennigan wrote:
> 
> [..huge snip..]
> 
> > VNC on the PCs might be a better choice to solve this
> problem.
> 
> I'm used to FreeBSD... instead of:
> 
> # ssh -l myname lab.box
> # sudo cu -l /dev/cuad0
> 
> ... I was hoping for something a little more closer to the
> device itself
> (if possible).
> 
> The lab pc boxen are not connected to any network
> (including the network
> my workstation belongs to).
> 
> I was hoping to communicate with the defunct and
> way-too-old devices
> without having to use IP based communication.
> 
> Because my knowledge and experience is being forced upon
> playing with
> the likes of 2691-type hardware, I figured that I might try
> frying a
> couple during testing...
> 
> ..instead of using a remote control software, I was hoping
> that rs232
> would solve this, just for playing around.
> 
> Steve
> 
> ps: For the love of God...does anyone have 1 or 10 g lab
> hardware that a
> semi-skilled engineer can look at, and get familiar with
> it's convention
> ?! ;)
> 
>



      


From stuart at tech.org  Sun Jul 19 22:16:16 2009
From: stuart at tech.org (Stephen Stuart)
Date: Mon, 20 Jul 2009 02:16:16 +0000
Subject: [c-nsp] Splicing a roll-over cable
In-Reply-To: Your message of "Sun, 19 Jul 2009 17:08:34 -0400."
	<4A638B52.7070107@ibctech.ca> 
Message-ID: <200907200216.n6K2GGR6012571@nb.tech.org>

> Essentially, I'd like keystrokes to be seen on one monitor that is
> connected to the console that is typed on another device connected to
> the same console port.

rtty (you can find it in /usr/ports/sysutils/rtty in the FreeBSD ports
collection, source is at http://ftp.isc.org/isc/rtty/) does exactly
what you want.

Stephen

From swmike at swm.pp.se  Sun Jul 19 22:53:14 2009
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Mon, 20 Jul 2009 04:53:14 +0200 (CEST)
Subject: [c-nsp] Splicing a roll-over cable
In-Reply-To: <4A63BC54.5030407@ibctech.ca>
References: <4A638B52.7070107@ibctech.ca> <4A63901F.70906@west.net>
	<4A63BC54.5030407@ibctech.ca>
Message-ID: <alpine.DEB.1.10.0907200450220.4558@uplift.swm.pp.se>

On Sun, 19 Jul 2009, Steve Bertrand wrote:

> I was hoping to communicate with the defunct and way-too-old devices
> without having to use IP based communication.

Then I guess you could serial console into the lab PC box from your PC, 
and run screen -x on it (if you want multiple sources talking to it at the 
same time). Remember that 19200 serial only goes 10-20 meters in standard 
form (very approximate, depends on serial hardware etc) 
<http://www.connectworld.net/interface-troubleshooting.html> says even 
less (20 feet).

screen -x is a wonderful "collaboration tool".

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

From justin at justinshore.com  Mon Jul 20 00:12:18 2009
From: justin at justinshore.com (Justin Shore)
Date: Sun, 19 Jul 2009 23:12:18 -0500
Subject: [c-nsp] edge router BGP
In-Reply-To: <20090718193653.GP290@greenie.muc.de>
References: <C3412C29D7544726BA3D12A8F1C62FAB@EU.corp.clearwire.com>
	<20090716120511.M53115@fast-serv.com>
	<200907162029.31896.mtinka@globaltransit.net>
	<4A5F99B2.90602@justinshore.com>
	<20090718193653.GP290@greenie.muc.de>
Message-ID: <4A63EEA2.2000403@justinshore.com>

Gert Doering wrote:
> Hi,
> 
> On Thu, Jul 16, 2009 at 04:20:50PM -0500, Justin Shore wrote:
>> It has 5x the backplane to boot plus it's hardware forwarding.  The only 
>> real downside IMHO is that the unit uses SPAs which require SmartNets 
>> per SPA (per license and per a lot of other things for that matter too). 
> 
> Uh.  Could you elaborate on that?  Especially the "per-license and a lot
> of other things" bit?
> 
> We have no ASR1k yet, but if something like the ES20 "extra license for
> IPv6 *per ES20 card*" is going to come back, this would be a strong reason
> to finally go to the Vendor J camp.

You can see the prices in the Dynamic Config Tool on cisco.com when you 
build an ASR.  I just built a 1002 in the DCT as an example.  I added a 
couple SPAs and licenses.  On the summary page there are SmartNet line 
items for:

ESP
Chassis
IOS SW Redundancy Right-to-Use License
Crypto Right-to-Use License
Each SPA
And the IOS itself

So for a $95k chassis @ list I have $5800 in SmartNets (8x5xNBD) @ list 
per year.

Fire away...
  Justin




From gert at greenie.muc.de  Mon Jul 20 02:29:24 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Mon, 20 Jul 2009 08:29:24 +0200
Subject: [c-nsp] edge router BGP
In-Reply-To: <4A63EEA2.2000403@justinshore.com>
References: <C3412C29D7544726BA3D12A8F1C62FAB@EU.corp.clearwire.com>
	<20090716120511.M53115@fast-serv.com>
	<200907162029.31896.mtinka@globaltransit.net>
	<4A5F99B2.90602@justinshore.com>
	<20090718193653.GP290@greenie.muc.de>
	<4A63EEA2.2000403@justinshore.com>
Message-ID: <20090720062924.GV290@greenie.muc.de>

Hi,

On Sun, Jul 19, 2009 at 11:12:18PM -0500, Justin Shore wrote:
> >We have no ASR1k yet, but if something like the ES20 "extra license for
> >IPv6 *per ES20 card*" is going to come back, this would be a strong reason
> >to finally go to the Vendor J camp.
> 
> You can see the prices in the Dynamic Config Tool on cisco.com when you 
> build an ASR.  I just built a 1002 in the DCT as an example.  I added a 
> couple SPAs and licenses.  On the summary page there are SmartNet line 
> items for:
[..]
> So for a $95k chassis @ list I have $5800 in SmartNets (8x5xNBD) @ list 
> per year.

Mmmmh.  Comparing the numbers, the overall SmartNet is not *that* expensive
(if I remember correctly, we've paid similar amount for boxes with $60k list
prices).  So it might actually be more fair to do it that way.

OTOH the added maintenance overhead ("how much time will it take me to
figure out exactly what SmartNet contract to order for a given router that
has had modules and software licenses added to it over time") doesn't make
anything that's coupled to "exchangable parts" (SPA, ESP) much fun in
the long run.

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/20090720/181136fc/attachment.bin>

From gert at greenie.muc.de  Mon Jul 20 02:42:05 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Mon, 20 Jul 2009 08:42:05 +0200
Subject: [c-nsp] Splicing a roll-over cable
In-Reply-To: <4A638B52.7070107@ibctech.ca>
References: <4A638B52.7070107@ibctech.ca>
Message-ID: <20090720064205.GW290@greenie.muc.de>

Hi,

On Sun, Jul 19, 2009 at 05:08:34PM -0400, Steve Bertrand wrote:
> Essentially, I'd like keystrokes to be seen on one monitor that is
> connected to the console that is typed on another device connected to
> the same console port.

This direction should work (having two "receivers" on one "sending" line),
if the cable is not too long.

The other way ("typing on both machines will end up on the router") is
not going to work due to the signalling used on RS232 - there would be
two transmitters fighting each other.

As a corrollary, you can't just "splice all 8 wires", but you'd have to
extract RXD (as seen from the host) and GND.

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/20090720/a3b229ff/attachment.bin>

From andy.saykao at staff.netspace.net.au  Mon Jul 20 03:48:36 2009
From: andy.saykao at staff.netspace.net.au (Andy Saykao)
Date: Mon, 20 Jul 2009 17:48:36 +1000
Subject: [c-nsp] Strange NAT and DHCP Problem
Message-ID: <56F211C5E3F24F47B103EA1B253822BE044AAA82@vic-cr-ex1.staff.netspace.net.au>

Hi All,
 
Just a few questions about DHCP and some strange NAT entries.
 
1/ What can cause this strange NAT entry where there's no protocol,
outside local/global defined??? I'm always seeing it in the NAT able.
 
core2#sh ip nat trans
Pro Inside global         Inside local          Outside local
Outside global
--- 210.15.240.8          172.16.75.111         ---
---
 
Seems to be giving me a warning message whenever it can't use the inside
global IP when there are active translations in place:
 
%IPNAT-4-ADDR_ALLOC_FAILURE: Address allocation failed for
172.16.75.111, pool NAT-POOL might be exhausted
 
2/ How is it possible that a DHCP client (172.16.75.113) has been able
to have their lease expiration time set to "infinite" when I haven't set
any lease time within the DHCP config so it should default to 1 day (see
below). 
 
3/ Any reasons why a DHCP client might prefer to send their own
Client-ID (0065) instead of their MAC address as shown for
172.16.75.111? (see below).
 
core2#sh ip dhcp binding
IP address       Client-ID/              Lease expiration        Type
                 Hardware address
172.16.75.111    0065                    Jul 21 2009 05:34 PM
Automatic
172.16.75.113    0021.e9a0.777c          Infinite
Automatic
 
The DHCP config is pretty straight forward:
 
ip dhcp pool Wireless-512b
   network 172.16.75.0 255.255.255.0
   domain-name netspace.net.au
   default-router 172.16.75.1
   dns-server 210.15.254.240 210.15.254.241
 
Running on Cisco 7606 with IOS 12.2(18)SXF11.
 
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
<blocked::mailto:andy.saykao at staff.netspace.net.au> 
 

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 A.L.M.Buxey at lboro.ac.uk  Mon Jul 20 04:30:18 2009
From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk)
Date: Mon, 20 Jul 2009 09:30:18 +0100
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <8e157ab40907181306h87f6e8bv2838d248050c65b@mail.gmail.com>
References: <9DE4AA6876D44B62B87C475B2AFE5514@au.didata.local>
	<a1873f1f0907131438m3f0b4c70r82a953a29042b6d7@mail.gmail.com>
	<1247524340.4661.65.camel@abehat.net.rm.dk>
	<20090714084503.GA15753@lboro.ac.uk>
	<d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>
	<6B43981C32F8464CB24CEE209DA32BD302350ADD@kenya.tronet.as>
	<8e157ab40907162051t4d32d6cbudc1dacca82790ed1@mail.gmail.com>
	<200907180455.n6I4tmr8016738@sj-core-2.cisco.com>
	<8e157ab40907181306h87f6e8bv2838d248050c65b@mail.gmail.com>
Message-ID: <20090720083018.GC8544@lboro.ac.uk>

Hi,

> #sh vlan vir
> 
> Slot 1
> -------
> Total slot virtual ports 6448
> 
> Slot 2
> -------
> Total slot virtual ports 1636
> 
> Total chassis virtual ports 8084
> 
> #sh mod
> Mod Ports Card Type                              Model              Serial
> No.
> --- ----- -------------------------------------- ------------------
> -----------
>   1   16  SFM-capable 16 port 1000mb GBIC        WS-X6516A-GBIC
>   2    4  CEF720 4 port 10-Gigabit Ethernet      WS-X6704-10GE
>   5    2  Supervisor Engine 720 (Active)         WS-SUP720-3B
> 
> 
> It's pretty much always the 6516-GBIC cards that lead downstream to access
> switches that have the high virtual port counts.

yep - which is where you limit the VLANs that go down so that match what is needed
- switchport trunk allowed vlan x,y,z,666,999,blah,blah.   you are over the 1800 limit
on that blade - but are you seeing the platform exceeded in your system logs?

alan

From A.L.M.Buxey at lboro.ac.uk  Mon Jul 20 05:06:44 2009
From: A.L.M.Buxey at lboro.ac.uk (A.L.M.Buxey at lboro.ac.uk)
Date: Mon, 20 Jul 2009 10:06:44 +0100
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <8e157ab40907162051t4d32d6cbudc1dacca82790ed1@mail.gmail.com>
References: <9DE4AA6876D44B62B87C475B2AFE5514@au.didata.local>
	<a1873f1f0907131438m3f0b4c70r82a953a29042b6d7@mail.gmail.com>
	<1247524340.4661.65.camel@abehat.net.rm.dk>
	<20090714084503.GA15753@lboro.ac.uk>
	<d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>
	<6B43981C32F8464CB24CEE209DA32BD302350ADD@kenya.tronet.as>
	<8e157ab40907162051t4d32d6cbudc1dacca82790ed1@mail.gmail.com>
Message-ID: <20090720090644.GA8828@lboro.ac.uk>

Hi,

> purchasing.  The docs seem to clearly state that the limits are per-slot and
> do not mention model numbers. However, I can confirm that I have greatly
> exceeded this specification for years now without serious wonkyness.  I
> have WS-X6516A-GBIC cards running as high as 6,400 virtual port instances.
>  I do notice RSTP isn't quite as rapid as it used to be though.  If all STP
> instances reconverge at the same time, it might take a second or two.  If
> only one VLAN reconverges, it is still sub-second.

I have come across a couple of docs now that suggest that the 67xx are
not tied to this limit....but then they dont specify what the new limit
is and there must be one.. ;-) - nothing so clear for the 65xx line cards.
however, i came across more resources which suggest limiting and their
best practice docs also state you should limit what goes down the trunks.
suffice to say - rather than leaving the network 'exposed' to such
random limits and risks I feel its best to go along with more control
over the core<->aggregation layer.  (limiting right out to the distribution layer
seems to be a much larger resource step both for deployment and day to day ops)

alan

From tomas at soitron.com  Mon Jul 20 05:19:54 2009
From: tomas at soitron.com (Tomas Daniska)
Date: Mon, 20 Jul 2009 11:19:54 +0200
Subject: [c-nsp] Splicing a roll-over cable
In-Reply-To: <20090720064205.GW290@greenie.muc.de>
References: <4A638B52.7070107@ibctech.ca> <20090720064205.GW290@greenie.muc.de>
Message-ID: <6B43981C32F8464CB24CEE209DA32BD302350E28@kenya.tronet.as>


> On Sun, Jul 19, 2009 at 05:08:34PM -0400, Steve Bertrand wrote:
> > Essentially, I'd like keystrokes to be seen on one monitor that is
> > connected to the console that is typed on another device connected
to
> > the same console port.
> 
> This direction should work (having two "receivers" on one "sending"
> line), if the cable is not too long.

Take care to avoid overloading the tx circuitry. Two receivers over a
short distance should be ok. When slightly overloaded, the port may fail
after a longer time (e.g., using a long cable run without line
conditioning circuitry).
 
> The other way ("typing on both machines will end up on the router") is
> not going to work due to the signalling used on RS232 - there would be
> two transmitters fighting each other.

I see no reason why splicing with diodes wouldn't work here, provided
that you avoid sending from both terminals simultaneously. RS232 has
pretty vague voltage levels, so the voltage drop should not be an issue.
The HW flowcontrol signals can spliced this way as well, IMO. Or you can
use an electrical switch to choose which of the two terminals has the
active keyboard.

Even without the diode protection the TX circuits should not fry each
other if connected directly and could work. You try at your own risk ;-)
Cisco console ports used to be tough to burn in older HW (I wouldn't say
this about other Cisco async ports).

> As a corrollary, you can't just "splice all 8 wires", but you'd have
to
> extract RXD (as seen from the host) and GND.

--

deejay
 

__________ Informacia od ESET NOD32 Antivirus, verzia databazy 4259
(20090719) __________

Tuto spravu preveril ESET NOD32 Antivirus.

http://www.eset.sk
 

From linux.yahoo at gmail.com  Mon Jul 20 05:32:47 2009
From: linux.yahoo at gmail.com (Manu Chao)
Date: Mon, 20 Jul 2009 11:32:47 +0200
Subject: [c-nsp] Strange NAT and DHCP Problem
In-Reply-To: <56F211C5E3F24F47B103EA1B253822BE044AAA82@vic-cr-ex1.staff.netspace.net.au>
References: <56F211C5E3F24F47B103EA1B253822BE044AAA82@vic-cr-ex1.staff.netspace.net.au>
Message-ID: <7100ed370907200232t750eddeew1202506b59df4446@mail.gmail.com>

3/ MAC and/or Client ID depend on your hosts network setting

By default, DHCP implementations typically employ the client's MAC address
but you can add Client ID option if you want specific DHCP reply for hosts
with different Client IDs or host without

On Mon, Jul 20, 2009 at 9:48 AM, Andy Saykao <
andy.saykao at staff.netspace.net.au> wrote:

> Hi All,
>
> Just a few questions about DHCP and some strange NAT entries.
>
> 1/ What can cause this strange NAT entry where there's no protocol,
> outside local/global defined??? I'm always seeing it in the NAT able.
>
> core2#sh ip nat trans
> Pro Inside global         Inside local          Outside local
> Outside global
> --- 210.15.240.8          172.16.75.111         ---
> ---
>
> Seems to be giving me a warning message whenever it can't use the inside
> global IP when there are active translations in place:
>
> %IPNAT-4-ADDR_ALLOC_FAILURE: Address allocation failed for
> 172.16.75.111, pool NAT-POOL might be exhausted
>
> 2/ How is it possible that a DHCP client (172.16.75.113) has been able
> to have their lease expiration time set to "infinite" when I haven't set
> any lease time within the DHCP config so it should default to 1 day (see
> below).
>
> 3/ Any reasons why a DHCP client might prefer to send their own
> Client-ID (0065) instead of their MAC address as shown for
> 172.16.75.111? (see below).
>
> core2#sh ip dhcp binding
> IP address       Client-ID/              Lease expiration        Type
>                 Hardware address
> 172.16.75.111    0065                    Jul 21 2009 05:34 PM
> Automatic
> 172.16.75.113    0021.e9a0.777c          Infinite
> Automatic
>
> The DHCP config is pretty straight forward:
>
> ip dhcp pool Wireless-512b
>   network 172.16.75.0 255.255.255.0
>   domain-name netspace.net.au
>   default-router 172.16.75.1
>   dns-server 210.15.254.240 210.15.254.241
>
> Running on Cisco 7606 with IOS 12.2(18)SXF11.
>
> 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
> <blocked::mailto:andy.saykao at staff.netspace.net.au>
>
>
> 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 linux.yahoo at gmail.com  Mon Jul 20 05:59:04 2009
From: linux.yahoo at gmail.com (Manu Chao)
Date: Mon, 20 Jul 2009 11:59:04 +0200
Subject: [c-nsp] Module provisioning for a 6500
In-Reply-To: <9E9636B2F6649243B154AB4E53BD53000B0A9189@Hecto.itg.ias.edu>
References: <9E9636B2F6649243B154AB4E53BD53000B0A9189@Hecto.itg.ias.edu>
Message-ID: <7100ed370907200259t6682a76dqc7d326fc9ed85ff7@mail.gmail.com>

no

On Fri, Jul 17, 2009 at 8:00 PM, Christina Klam <cklam at ias.edu> wrote:

> In know on a 3750, I can use "switch [] provision" to manually assign a
> physical switch any switch number I want.  Is there a way to virtually
> assign a module a different slot id on a 6513?  What I want is to make "gig
> 1/1" really be on the physical interface "gig 9/1".
>
> Thanks in advance for you help,
> 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 david.freedman at uk.clara.net  Mon Jul 20 06:43:21 2009
From: david.freedman at uk.clara.net (David Freedman)
Date: Mon, 20 Jul 2009 11:43:21 +0100
Subject: [c-nsp] CSCsj19555 (vpdn vaccess leak in 12.2SR) anybody hit this?
Message-ID: <h41ho9$dd0$1@ger.gmane.org>

Think I am,

doing vpdn/l2tp on SRC1/2/3/4 and SRD1/2, vaccess not being freed up,
debug sss says:

Jul 20 11:28:11 BST: SSS LTERM [uid:589]: Vi2.4877 is still in use by
LTERM data-plane


and interface conceeds:


#sh int virtual-access 2.4877 | in status
  Vaccess status 0x200, free pending L2X switching completion


This is a problem as you can see:

#sh vpdn sess | in essions
L2TP Session Information Total tunnels 2 sessions 1369

#sh vtempla | in pend
Current free pending: 8100 (and counting)

#sh idb | in Max
Maximum number of Software IDBs 32000.  In use 9487.


Contextual SSS dump:

#sh log | in uid:589
Jul 20 11:28:11 BST: SSS MGR [uid:589]: Sending a Unset the session
key(s) ID Mgr request
Jul 20 11:28:11 BST: SSS MGR [uid:589]: Removing the following data from
ID Mgr:
Jul 20 11:28:11 BST: SSS MGR [uid:589]: ID Mgr returned status:
'updated' for Unset the session key(s)
Jul 20 11:28:11 BST: SSS LTERM [uid:589]: Vi2.4877 is still in use by
LTERM data-plane
Jul 20 11:28:11 BST: SSS MGR [uid:589]: No child sessions attached
Jul 20 11:28:11 BST: SSS MGR [uid:589]: Processing a client disconnect
Jul 20 11:28:11 BST: SSS MGR [uid:589]: Handling Send Service Disconnect
action
Jul 20 11:28:11 BST: SSS MGR [uid:589]: Failed to send aaa event
Jul 20 11:28:11 BST: SSS LTERM [uid:589]: Switching session unprovisioned
Jul 20 11:28:11 BST: SSS LTERM [uid:589]: Uninstalled Vi2 process path
switching vector
Jul 20 11:28:11 BST: SSS LTERM [uid:589]: Uninstalled Vi2 fastsend path
switching vector
Jul 20 11:28:11 BST: SSS MGR [uid:589]: Handling Disconnecting, Network
Service Feature Clean action
Jul 20 11:28:11 BST: SSS MGR [uid:589]: Sending a Session End ID Mgr request
Jul 20 11:28:11 BST: SSS MGR [uid:589]: ID Mgr returned status:
'deleted' for Session End
Jul 20 11:28:11 BST: SSS MGR [uid:589]: Freeing vaccess interface
Vi2.4877, 69EAA23C


claims to be fixed if I downgrade to SRC, don't quite believe this,
nothing new appear to be fixed in , which is annoying (SRC itself too
buggy to use here)

have noticed that the leak slows down when enabling "vpdn multihop"
(even though not used anywhere in any radius attributes)

just going through all the SSS features it claims are disabled and
enabling them in order to slow the leak down (next on my list is SGBP)

Would appreciate anybody who has experienced this coming forward, I have
a TAC case open in which I've mentioned I believe it is this bug but
case is running at a snail's pace :(


Dave.


From david.freedman at uk.clara.net  Mon Jul 20 07:36:27 2009
From: david.freedman at uk.clara.net (David Freedman)
Date: Mon, 20 Jul 2009 12:36:27 +0100
Subject: [c-nsp] CSCsj19555 (vpdn vaccess leak in 12.2SR) anybody hit
 this?
In-Reply-To: <h41ho9$dd0$1@ger.gmane.org>
References: <h41ho9$dd0$1@ger.gmane.org>
Message-ID: <h41krr$m64$1@ger.gmane.org>

Thanks to all those who replied off-list, seems the master bug is
CSCsj19555 which is on target for fix SRC5 or SRD3.

David.

David Freedman wrote:
> Think I am,
> 
> doing vpdn/l2tp on SRC1/2/3/4 and SRD1/2, vaccess not being freed up,
> debug sss says:
> 
> Jul 20 11:28:11 BST: SSS LTERM [uid:589]: Vi2.4877 is still in use by
> LTERM data-plane
> 
> 
> and interface conceeds:
> 
> 
> #sh int virtual-access 2.4877 | in status
>   Vaccess status 0x200, free pending L2X switching completion
> 
> 
> This is a problem as you can see:
> 
> #sh vpdn sess | in essions
> L2TP Session Information Total tunnels 2 sessions 1369
> 
> #sh vtempla | in pend
> Current free pending: 8100 (and counting)
> 
> #sh idb | in Max
> Maximum number of Software IDBs 32000.  In use 9487.
> 
> 
> Contextual SSS dump:
> 
> #sh log | in uid:589
> Jul 20 11:28:11 BST: SSS MGR [uid:589]: Sending a Unset the session
> key(s) ID Mgr request
> Jul 20 11:28:11 BST: SSS MGR [uid:589]: Removing the following data from
> ID Mgr:
> Jul 20 11:28:11 BST: SSS MGR [uid:589]: ID Mgr returned status:
> 'updated' for Unset the session key(s)
> Jul 20 11:28:11 BST: SSS LTERM [uid:589]: Vi2.4877 is still in use by
> LTERM data-plane
> Jul 20 11:28:11 BST: SSS MGR [uid:589]: No child sessions attached
> Jul 20 11:28:11 BST: SSS MGR [uid:589]: Processing a client disconnect
> Jul 20 11:28:11 BST: SSS MGR [uid:589]: Handling Send Service Disconnect
> action
> Jul 20 11:28:11 BST: SSS MGR [uid:589]: Failed to send aaa event
> Jul 20 11:28:11 BST: SSS LTERM [uid:589]: Switching session unprovisioned
> Jul 20 11:28:11 BST: SSS LTERM [uid:589]: Uninstalled Vi2 process path
> switching vector
> Jul 20 11:28:11 BST: SSS LTERM [uid:589]: Uninstalled Vi2 fastsend path
> switching vector
> Jul 20 11:28:11 BST: SSS MGR [uid:589]: Handling Disconnecting, Network
> Service Feature Clean action
> Jul 20 11:28:11 BST: SSS MGR [uid:589]: Sending a Session End ID Mgr request
> Jul 20 11:28:11 BST: SSS MGR [uid:589]: ID Mgr returned status:
> 'deleted' for Session End
> Jul 20 11:28:11 BST: SSS MGR [uid:589]: Freeing vaccess interface
> Vi2.4877, 69EAA23C
> 
> 
> claims to be fixed if I downgrade to SRC, don't quite believe this,
> nothing new appear to be fixed in , which is annoying (SRC itself too
> buggy to use here)
> 
> have noticed that the leak slows down when enabling "vpdn multihop"
> (even though not used anywhere in any radius attributes)
> 
> just going through all the SSS features it claims are disabled and
> enabling them in order to slow the leak down (next on my list is SGBP)
> 
> Would appreciate anybody who has experienced this coming forward, I have
> a TAC case open in which I've mentioned I believe it is this bug but
> case is running at a snail's pace :(
> 
> 
> Dave.
> 
> _______________________________________________
> cisco-nsp mailing list  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  Mon Jul 20 08:12:02 2009
From: cchurc05 at harris.com (Church, Charles)
Date: Mon, 20 Jul 2009 07:12:02 -0500
Subject: [c-nsp] Strange NAT and DHCP Problem
In-Reply-To: <56F211C5E3F24F47B103EA1B253822BE044AAA82@vic-cr-ex1.staff.netspace.net.au>
References: <56F211C5E3F24F47B103EA1B253822BE044AAA82@vic-cr-ex1.staff.netspace.net.au>
Message-ID: <FA1BA229357DB640B944218F3585FECA027659A6@mspe2k1.cs.myharris.net>

The infinite DHCP entry is probably a BOOTP client, which doesn't have
the concept of a lease.  There are knobs (ip dhcp bootp ignore) that can
turn off bootp, and only allow DHCP.  I think by default, it'll service
both.

Chuck

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Andy Saykao
Sent: Monday, July 20, 2009 3:49 AM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Strange NAT and DHCP Problem


Hi All,
 
Just a few questions about DHCP and some strange NAT entries.
 
1/ What can cause this strange NAT entry where there's no protocol,
outside local/global defined??? I'm always seeing it in the NAT able.
 
core2#sh ip nat trans
Pro Inside global         Inside local          Outside local
Outside global
--- 210.15.240.8          172.16.75.111         ---
---
 
Seems to be giving me a warning message whenever it can't use the inside
global IP when there are active translations in place:
 
%IPNAT-4-ADDR_ALLOC_FAILURE: Address allocation failed for
172.16.75.111, pool NAT-POOL might be exhausted
 
2/ How is it possible that a DHCP client (172.16.75.113) has been able
to have their lease expiration time set to "infinite" when I haven't set
any lease time within the DHCP config so it should default to 1 day (see
below). 
 
3/ Any reasons why a DHCP client might prefer to send their own
Client-ID (0065) instead of their MAC address as shown for
172.16.75.111? (see below).
 
core2#sh ip dhcp binding
IP address       Client-ID/              Lease expiration        Type
                 Hardware address
172.16.75.111    0065                    Jul 21 2009 05:34 PM
Automatic
172.16.75.113    0021.e9a0.777c          Infinite
Automatic
 
The DHCP config is pretty straight forward:
 
ip dhcp pool Wireless-512b
   network 172.16.75.0 255.255.255.0
   domain-name netspace.net.au
   default-router 172.16.75.1
   dns-server 210.15.254.240 210.15.254.241
 
Running on Cisco 7606 with IOS 12.2(18)SXF11.
 
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
<blocked::mailto:andy.saykao at staff.netspace.net.au> 
 

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 moua0100 at umn.edu  Mon Jul 20 09:03:08 2009
From: moua0100 at umn.edu (Ge Moua)
Date: Mon, 20 Jul 2009 08:03:08 -0500
Subject: [c-nsp] ASA Multiple Context Mode
In-Reply-To: <6E21B2BDEF6E714EA0B5BA8D5D0E1401248380ADEC@zy-ex1.zyedge.local>
References: <580af3b90907191113rfe9cf2fj77dee3f1832eca0d@mail.gmail.com>
	<6E21B2BDEF6E714EA0B5BA8D5D0E1401248380ADEA@zy-ex1.zyedge.local>
	<4A637379.3000201@umn.edu>
	<6E21B2BDEF6E714EA0B5BA8D5D0E1401248380ADEC@zy-ex1.zyedge.local>
Message-ID: <4A646B0C.6090708@umn.edu>

VPN termination and vlan-mapping all on the ASA.

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

Network Design Engineer
University of Minnesota | Networking & Telecommunications Services



Ryan West wrote:
> Think I misread what you originally wrote, were you still implying another device for the VPN termination?
>
> -----Original Message-----
> From: Ge Moua [mailto:moua0100 at umn.edu] 
> Sent: Sunday, July 19, 2009 3:27 PM
> To: Ryan West
> Cc: Clue Store; cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] ASA Multiple Context Mode
>
> I've done IOS based WebVPN with multiple VRFs (vrf-lite in this case); 
> this is somewhat analogous to the ASA w/ multiple context; I know you 
> mentioned how to do this on the ASA which I don't believe is possible.
>
> Our Cisco Acct SE mentioned vlan mapping where you terminate the 
> webvpn/ipsec tunnel on one interface but then funnel the designated 
> traffic per customer to different downstream vlan or interfaces; 
> essentially this allows you to have multiple customer group in one 
> context; i've seen docs on cisco cco that mentions this as well; good luck.
>
>
> Regards,
> Ge Moua | Email: moua0100 at umn.edu
>
> Network Design Engineer
> University of Minnesota | Networking & Telecommunications Services
>
>
>
> Ryan West wrote:
>   
>> Clue,
>>
>> I am pretty sure that it doesn't support SSL VPN's either.  All NetPro discussions show the same results.  Assuming you are support multiple customers and want to give them access to their firewall, or whatever you reason for choosing multiple context may be, you should use another ASA pair in Active/Standby to provide VPN termination services.  You may have to mess around with RRI, but you should be able to pull off customer segregation using VLANs.
>>
>> -ryan
>>
>> -----Original Message-----
>> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Clue Store
>> Sent: Sunday, July 19, 2009 2:14 PM
>> To: cisco-nsp at puck.nether.net
>> Subject: [c-nsp] ASA Multiple Context Mode
>>
>> Hi All,
>>
>>
>> As I understand that the ASA in multiple context mode does not support
>> "VPN's", does this also inclue SSL VPN's?? Someone has mentioned that it
>> turns off IPSEC engine in this mode, but I have not been able to find
>> anywhere where it says SSL VPN's are not supported. If it doesn't support
>> SSL VPN, what are other folks doing for VPN's in this situation where
>> multiple contexts are being used??
>>
>> TIA,
>> Clue
>> _______________________________________________
>> cisco-nsp mailing 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 daryl at introspect.net  Mon Jul 20 12:20:17 2009
From: daryl at introspect.net (Daryl G. Jurbala)
Date: Mon, 20 Jul 2009 12:20:17 -0400
Subject: [c-nsp] PPTP devices
Message-ID: <8523A296-97C9-4670-86E3-99D8B206827F@introspect.net>

I'm in the unfortunate position of having to support a bunch (100 or  
so now, 300 or so very soon) PPTP connections.

Right now I'm using a 3825, and based on CPU performance it looks like  
I'll be lucky to get 200 on this thing with my typical end use usage  
patterns.

Cisco seems to be pretty poor with rating PPTP performance on their  
devices, and would rather talk about L2TP (I don't blame them - it  
appears that pptp support has been dropped from the ASAs entirely).

Does anyone have any idea what would be a good box for 300 to 500 (or  
even more) PPTP connections?  The old VPN3000s seem to support this,  
but I can't get any real numbers on how many connections I can  
realistically support.  I was thinking of just finding some powerful  
CPU IOS boxes and calling it a day on this one.  Any better ideas?

Thanks,
Daryl

From p.mayers at imperial.ac.uk  Mon Jul 20 12:47:58 2009
From: p.mayers at imperial.ac.uk (Phil Mayers)
Date: Mon, 20 Jul 2009 17:47:58 +0100
Subject: [c-nsp] PPTP devices
In-Reply-To: <8523A296-97C9-4670-86E3-99D8B206827F@introspect.net>
References: <8523A296-97C9-4670-86E3-99D8B206827F@introspect.net>
Message-ID: <4A649FBE.6070407@imperial.ac.uk>

Daryl G. Jurbala wrote:
> I'm in the unfortunate position of having to support a bunch (100 or  
> so now, 300 or so very soon) PPTP connections.
> 
> Right now I'm using a 3825, and based on CPU performance it looks like  
> I'll be lucky to get 200 on this thing with my typical end use usage  
> patterns.
> 
> Cisco seems to be pretty poor with rating PPTP performance on their  
> devices, and would rather talk about L2TP (I don't blame them - it  
> appears that pptp support has been dropped from the ASAs entirely).
> 
> Does anyone have any idea what would be a good box for 300 to 500 (or  
> even more) PPTP connections?  The old VPN3000s seem to support this,  
> but I can't get any real numbers on how many connections I can  
> realistically support.  I was thinking of just finding some powerful  
> CPU IOS boxes and calling it a day on this one.  Any better ideas?

Depending on what exactly you need to do, you might consider Linux + 
Poptop. We run it for our remote access VPN, and it serves many hundreds 
of users at pretty high traffic rates with no real problem.

Obviously getting a beefy intel machine is a lot cheaper than a beefy 
cisco CPU router (and probably a lot faster too)

From masood at nexlinx.net.pk  Mon Jul 20 14:00:08 2009
From: masood at nexlinx.net.pk (masood at nexlinx.net.pk)
Date: Mon, 20 Jul 2009 23:00:08 +0500 (PKT)
Subject: [c-nsp] PPTP devices
In-Reply-To: <8523A296-97C9-4670-86E3-99D8B206827F@introspect.net>
References: <8523A296-97C9-4670-86E3-99D8B206827F@introspect.net>
Message-ID: <10039.196.46.241.57.1248112808.squirrel@nexmail1.nexlinx.net.pk>

since all the pptp traffic gets process switched, Cisco would not meet the
feasibility condition on Router; if i were you i will use a linux (Intel
Core 2 Duo,4 Gig Mem) box running poptop (http://www.poptop.org/) for such
a huge and increasing number of pptp users.

Regards,
Masood
Blog: http://weblogs.com.pk/jahil/


> I'm in the unfortunate position of having to support a bunch (100 or
> so now, 300 or so very soon) PPTP connections.
>
> Right now I'm using a 3825, and based on CPU performance it looks like
> I'll be lucky to get 200 on this thing with my typical end use usage
> patterns.
>
> Cisco seems to be pretty poor with rating PPTP performance on their
> devices, and would rather talk about L2TP (I don't blame them - it
> appears that pptp support has been dropped from the ASAs entirely).
>
> Does anyone have any idea what would be a good box for 300 to 500 (or
> even more) PPTP connections?  The old VPN3000s seem to support this,
> but I can't get any real numbers on how many connections I can
> realistically support.  I was thinking of just finding some powerful
> CPU IOS boxes and calling it a day on this one.  Any better ideas?
>
> Thanks,
> Daryl
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>



From elmonomario69 at gmail.com  Mon Jul 20 12:58:53 2009
From: elmonomario69 at gmail.com (.....::::[Gardener] ::::.....)
Date: Mon, 20 Jul 2009 13:58:53 -0300
Subject: [c-nsp] TCLsh + Ping TOS
Message-ID: <cf70832e0907200958o62ef7a71w3b8a51463c64201a@mail.gmail.com>

Hi to everyone.

Please i need some advice to create a little script to make Ping with TOS

i found on several webpages, things like this.

R1#tclsh
R1(tcl)#foreach address {
+>(tcl)#172.12.23.2
+>(tcl)#172.12.23.3
+>(tcl)#172.12.23.4
+>(tcl)#172.12.23.6
+>(tcl)#172.12.23.7
+>(tcl)#} { ping $address re 10 si 1500
+>(tcl)#}

This is my problem, i can not make the complete command on ONE line (becouse
i don't have TOS ).
 I need to create script to execute things like this.

R1#ping
Protocol [ip]:
Target IP address: 172.16.123.1
Repeat count [5]: 1000
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: loopback0
Type of service [0]: 96
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:



The other impossibility that i have i can not create or bring from other
place the file.tcl, all this script has to be applied on-line on the router.

Thank you.
 Andres P. Spano

From jcartier at acs.on.ca  Mon Jul 20 14:26:53 2009
From: jcartier at acs.on.ca (Jeff Cartier)
Date: Mon, 20 Jul 2009 14:26:53 -0400
Subject: [c-nsp] Cisco Certified Academy Instructor...anyone? [off-topic]
Message-ID: <BCD3E762F1767C42A5226BBACDE49BFBED8DD5@loki.acs.local>

Greetings All!

 

I recently have the opportunity/privilege to attempt the Cisco Certified
Academy Instructor (CCAI) certification.  Due to time restrictions I'm
being sent down the "Instructor Fast Track" (IFT) route; which to my
knowledge contains a Skills-Based Assessment.  After being able to find
no outline or related information, combined with being told that the
exam is "not for the faint of heart" I am a little bit disturbed.

 

I was wondering if anyone out there is a CCAI, or has attempted
(successfully or unsuccessfully) the Instructor Fast Track exam?

 

More or less I'd like to get a feeling for what I'm up against.

 

Cheers!!

 

PS.

 

Sorry for the off-topic related post.


From matt at overloaded.net  Mon Jul 20 15:34:41 2009
From: matt at overloaded.net (Matt Buford)
Date: Mon, 20 Jul 2009 14:34:41 -0500
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <20090720083018.GC8544@lboro.ac.uk>
References: <9DE4AA6876D44B62B87C475B2AFE5514@au.didata.local>
	<a1873f1f0907131438m3f0b4c70r82a953a29042b6d7@mail.gmail.com>
	<1247524340.4661.65.camel@abehat.net.rm.dk>
	<20090714084503.GA15753@lboro.ac.uk>
	<d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>
	<6B43981C32F8464CB24CEE209DA32BD302350ADD@kenya.tronet.as>
	<8e157ab40907162051t4d32d6cbudc1dacca82790ed1@mail.gmail.com>
	<200907180455.n6I4tmr8016738@sj-core-2.cisco.com>
	<8e157ab40907181306h87f6e8bv2838d248050c65b@mail.gmail.com>
	<20090720083018.GC8544@lboro.ac.uk>
Message-ID: <8e157ab40907201234h47b5052fh20ceb1fb2533da52@mail.gmail.com>

On Mon, Jul 20, 2009 at 3:30 AM, <A.L.M.Buxey at lboro.ac.uk> wrote:

> > It's pretty much always the 6516-GBIC cards that lead downstream to
> access
> > switches that have the high virtual port counts.
>
> yep - which is where you limit the VLANs that go down so that match what is
> needed
> - switchport trunk allowed vlan x,y,z,666,999,blah,blah.   you are over the
> 1800 limit
> on that blade - but are you seeing the platform exceeded in your system
> logs?
>

I believe so, however I think that message only shows up as your cross that
limit.  I've been above the limit forever, so I don't exactly see the log
message very often.

I agree with your suggested solution, and this is what I suggested
internally as a possible fix.  However, this is one of those things that
sounds easy enough in theory, but in a dynamic datacenter where many servers
are constantly changing, it is more complex.

First, a quick search for SNMP support makes me think that we won't be doing
any changes to this over SNMP.  You have to read the bitmask, edit it, and
then rewrite it with your changes.  This means if 2 people attempt to edit
the allowed VLANs on the same port at the same time, they'll overwrite each
other's changes.  So now, our web based port-VLAN form (which is already a
little slow due to lots of SNMP tables to walk) will also have to also SSH
to the 2 upstream switches to issue the "add" commands.  We're already
headed down a rough road here...

Second, there is the question of removing VLANs from this list.  When a tech
goes to the web form to set the VLAN for a port, we need to go through all
ports on the switch and see if anyone else is using the old VLAN that the
port used to be on.  Don't forget to check for it being used on tagged
ports!  If no one remains using that VLAN on the access switch, then it can
be pruned from the uplinks.  Then there's the (unlikely, but possible) case
where someone added a port to that VLAN in between the time you started
walking the table and when you deleted the VLAN from the ACL.  Oops.
 Overall, I think this part sounds dangerous and I'd probably just avoid any
automated cleanup (I'd have scripts only add VLANs to the ACL), and then
just settle for an occasional audit to trim down the lists.  Even with only
an occasional cleanup, this would probably significantly reduce the virtual
port usage.

Third, perhaps it's not really a big deal, but adding a steady flow of
topology changes throughout the business day to spanning tree for production
VLANs (just because a server got added to a VLAN) makes me a little
uncomfortable.  It's something I'd prefer to avoid.  Those pesky "100%
network uptime" SLAs require being pretty conservative about this kind of
thing.

Finally, there is cost associated with the development work and
administrative hassle that this VLAN pruning requires.  I'd prefer to spend
that money on hardware that Just Works, as opposed to having my own staff of
software developers and network engineers maintain this system of ACLs.  One
time fees for hardware to make my problems disappear forever and my network
configuration less complex are appreciated.  :)

Anyway, I don't mean to make this sound impossible.  It is a workable
solution.  Depending on how dynamic a data center is, it might not even be a
big deal to do this manually.  In my case, VLANs change continually all day,
and that makes this a potentially workable, but undesirable solution.  For
now, the pain of dividing my data centers up into 2 or 3 smaller networks
(VLAN domains) is less than my estimation of the pain involved in
implementing and running VLAN allowed ACLs.  Of course, higher hardware
limitations would be ideal.

From jhary at unsane.co.uk  Mon Jul 20 15:41:53 2009
From: jhary at unsane.co.uk (Vincent Hoffman)
Date: Mon, 20 Jul 2009 20:41:53 +0100
Subject: [c-nsp] PPTP devices
In-Reply-To: <10039.196.46.241.57.1248112808.squirrel@nexmail1.nexlinx.net.pk>
References: <8523A296-97C9-4670-86E3-99D8B206827F@introspect.net>
	<10039.196.46.241.57.1248112808.squirrel@nexmail1.nexlinx.net.pk>
Message-ID: <4A64C881.2090704@unsane.co.uk>

masood at nexlinx.net.pk wrote:
> since all the pptp traffic gets process switched, Cisco would not meet the
> feasibility condition on Router; if i were you i will use a linux (Intel
> Core 2 Duo,4 Gig Mem) box running poptop (http://www.poptop.org/) for such
> a huge and increasing number of pptp users.
> 
Or if your more of a FreeBSD person, MPD is also a very good solution
(http://mpd.sourceforge.net/)

Vince
> Regards,
> Masood
> Blog: http://weblogs.com.pk/jahil/
> 
> 
>> I'm in the unfortunate position of having to support a bunch (100 or
>> so now, 300 or so very soon) PPTP connections.
>>
>> Right now I'm using a 3825, and based on CPU performance it looks like
>> I'll be lucky to get 200 on this thing with my typical end use usage
>> patterns.
>>
>> Cisco seems to be pretty poor with rating PPTP performance on their
>> devices, and would rather talk about L2TP (I don't blame them - it
>> appears that pptp support has been dropped from the ASAs entirely).
>>
>> Does anyone have any idea what would be a good box for 300 to 500 (or
>> even more) PPTP connections?  The old VPN3000s seem to support this,
>> but I can't get any real numbers on how many connections I can
>> realistically support.  I was thinking of just finding some powerful
>> CPU IOS boxes and calling it a day on this one.  Any better ideas?
>>
>> Thanks,
>> Daryl
>> _______________________________________________
>> cisco-nsp mailing 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 tstevens at cisco.com  Mon Jul 20 16:44:10 2009
From: tstevens at cisco.com (Tim Stevenson)
Date: Mon, 20 Jul 2009 13:44:10 -0700
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <8e157ab40907181306h87f6e8bv2838d248050c65b@mail.gmail.com>
References: <9DE4AA6876D44B62B87C475B2AFE5514@au.didata.local>
	<a1873f1f0907131438m3f0b4c70r82a953a29042b6d7@mail.gmail.com>
	<1247524340.4661.65.camel@abehat.net.rm.dk>
	<20090714084503.GA15753@lboro.ac.uk>
	<d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>
	<6B43981C32F8464CB24CEE209DA32BD302350ADD@kenya.tronet.as>
	<8e157ab40907162051t4d32d6cbudc1dacca82790ed1@mail.gmail.com>
	<200907180455.n6I4tmr8016738@sj-core-2.cisco.com>
	<8e157ab40907181306h87f6e8bv2838d248050c65b@mail.gmail.com>
Message-ID: <200907202044.n6KKiJwv021020@sj-core-3.cisco.com>

At 01:06 PM 7/18/2009, Matt Buford opined:
>On Fri, Jul 17, 2009 at 11:55 PM, Tim Stevenson 
><<mailto:tstevens at cisco.com>tstevens at cisco.com> wrote:
>The 6500/sup720 on 33SXI supports 100K logical ports in MST, and 12K 
>in RPVST. That's up from 50K/10K in every prior release.
>
>
>Did the per-slot limitation change too?

According to the release notes, which is the official point of 
documentation for the VP limits:
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/release/notes/ol_14271.html#wp26366

There is no change in the per slot numbers, and the per slot limits 
do not apply to 67xx & 65xx modules (there is a bug about the limit 
syslog still appearing for these module types, which should not).



>N7K supports 75K in MST & 16K in RPVST today. There are no 
>per-module limitations on N7K.
>
>Those numbers are based on the requirements we expressed to 
>QA/system test prior to FCS. The original numbers were confirmed 
>prior to 33SXI was released. Since then, we have not had a customer 
>requirement/request to support more, so frankly we have not felt 
>compelled to go and requalifify for anything greater. Would be 
>curious to know how many logical ports you are running today & in 
>what protocol?
>
>
>First, I'm sorry for not being clear.  While the virtual port 
>per-slot limitation is an issue with our distribution switches, when 
>we discussed a Nexus based solution with Cisco the big sticking 
>point was actually with using the 5000 series as access switches for 
>customer servers to plug into in the data center.

I see, that makes more sense.


Thanks,
Tim



Tim Stevenson, tstevens at cisco.com
Routing & Switching CCIE #5561
Technical Marketing Engineer, Cisco Nexus 7000
Cisco - http://www.cisco.com
IP Phone: 408-526-6759
********************************************************
The contents of this message may be *Cisco Confidential*
and are intended for the specified recipients only.

From avayner at cisco.com  Mon Jul 20 17:06:57 2009
From: avayner at cisco.com (Arie Vayner (avayner))
Date: Mon, 20 Jul 2009 23:06:57 +0200
Subject: [c-nsp] PPTP devices
In-Reply-To: <10039.196.46.241.57.1248112808.squirrel@nexmail1.nexlinx.net.pk>
References: <8523A296-97C9-4670-86E3-99D8B206827F@introspect.net>
	<10039.196.46.241.57.1248112808.squirrel@nexmail1.nexlinx.net.pk>
Message-ID: <78C984F8939D424697B15E4B1C1BB3D7FF3C81@xmb-ams-331.emea.cisco.com>

Actually, this is not true... PPTP is not process switched on IOS, and
is it treated in a very similar way to L2TP on software based routers.

The CPU load would be still related to the amount of traffic, and not
really to the number of sessions, as software based routers still have
to spend cycles to switch packets.
If your 3825 router is having a hard time taking care of the load, I
would recommend you look at a 7201 (or at an older 7301).

7301 is basically a 1RU version of 7200 with NPE-G1, while 7201 is a 1RU
version of 7200 with NPE-G2.
Both of them should be able to handle about 200-300Mbps of PPTP traffic
with no trouble (NPE-G2 should be more or less double than NPE-G1).

Arie

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of
masood at nexlinx.net.pk
Sent: Monday, July 20, 2009 21:00
To: Daryl G. Jurbala
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] PPTP devices

since all the pptp traffic gets process switched, Cisco would not meet
the
feasibility condition on Router; if i were you i will use a linux (Intel
Core 2 Duo,4 Gig Mem) box running poptop (http://www.poptop.org/) for
such
a huge and increasing number of pptp users.

Regards,
Masood
Blog: http://weblogs.com.pk/jahil/


> I'm in the unfortunate position of having to support a bunch (100 or
> so now, 300 or so very soon) PPTP connections.
>
> Right now I'm using a 3825, and based on CPU performance it looks like
> I'll be lucky to get 200 on this thing with my typical end use usage
> patterns.
>
> Cisco seems to be pretty poor with rating PPTP performance on their
> devices, and would rather talk about L2TP (I don't blame them - it
> appears that pptp support has been dropped from the ASAs entirely).
>
> Does anyone have any idea what would be a good box for 300 to 500 (or
> even more) PPTP connections?  The old VPN3000s seem to support this,
> but I can't get any real numbers on how many connections I can
> realistically support.  I was thinking of just finding some powerful
> CPU IOS boxes and calling it a day on this one.  Any better ideas?
>
> Thanks,
> Daryl
> _______________________________________________
> cisco-nsp mailing 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 maillist at webjogger.net  Mon Jul 20 16:37:11 2009
From: maillist at webjogger.net (Adam Greene)
Date: Mon, 20 Jul 2009 16:37:11 -0400
Subject: [c-nsp] persistent debug
Message-ID: <9BA7244859D14DA8AC1E7F22267BF5EE@GINKGO>

Hi,

I like to leave "debug ip bgp updates" running on customer edge routers with 
whom I do eBGP peering, to track outage events.

However, the debugging command always goes away after the customer router 
reboots. Any way to make this persistent? (i.e. when router reboots, bgp 
update debugging gets automatically enabled?)

Thanks,
adam
 



From berni at birkenwald.de  Mon Jul 20 17:47:21 2009
From: berni at birkenwald.de (Bernhard Schmidt)
Date: Mon, 20 Jul 2009 21:47:21 +0000 (UTC)
Subject: [c-nsp] 2960G + RPS-2300 - how to get back on internal PS
Message-ID: <h42ol9$ee8$1@ger.gmane.org>

Hi,

first of all, I'm well aware of the limitations of 2960 series with
external RPS, they are only used here to have the very small advantage
to choose when the outage will be.

2* 2960G with RPS-2300 and dual powersupply. 2960 is on external power
feed. Is there any way to get back on the internal AC from remote? I
know it is going to reboot and I can live with that, but so far only
disconnecting the RPS from the switch or disabling the RPS port with the
buttons in front worked. Both of course require on-site staff. A reload
from the CLI did not work.

Have I missed any obvious way or is this just not possible?

Bernhard


From shimshah at cisco.com  Mon Jul 20 17:50:19 2009
From: shimshah at cisco.com (Shimol Shah ( Cisco ))
Date: Mon, 20 Jul 2009 17:50:19 -0400
Subject: [c-nsp] persistent debug
In-Reply-To: <9BA7244859D14DA8AC1E7F22267BF5EE@GINKGO>
References: <9BA7244859D14DA8AC1E7F22267BF5EE@GINKGO>
Message-ID: <4A64E69B.8080805@cisco.com>

Not tried it myself but below has two solutions:

http://blog.ioshints.info/2007/06/re-enable-debugging-on-router-reload.html


HTH

Adam Greene wrote:
> Hi,
> 
> I like to leave "debug ip bgp updates" running on customer edge routers 
> with whom I do eBGP peering, to track outage events.
> 
> However, the debugging command always goes away after the customer 
> router reboots. Any way to make this persistent? (i.e. when router 
> reboots, bgp update debugging gets automatically enabled?)
> 
> Thanks,
> adam
> 
> 
> 
> _______________________________________________
> cisco-nsp mailing list  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 Jul 20 18:04:51 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Mon, 20 Jul 2009 15:04:51 -0700
Subject: [c-nsp] 2960G + RPS-2300 - how to get back on internal PS
In-Reply-To: <h42ol9$ee8$1@ger.gmane.org>
References: <h42ol9$ee8$1@ger.gmane.org>
Message-ID: <4A64EA03.6050702@rollernet.us>

Bernhard Schmidt wrote:
> Hi,
> 
> first of all, I'm well aware of the limitations of 2960 series with
> external RPS, they are only used here to have the very small advantage
> to choose when the outage will be.
> 
> 2* 2960G with RPS-2300 and dual powersupply. 2960 is on external power
> feed. Is there any way to get back on the internal AC from remote? I
> know it is going to reboot and I can live with that, but so far only
> disconnecting the RPS from the switch or disabling the RPS port with the
> buttons in front worked. Both of course require on-site staff. A reload
> from the CLI did not work.
> 
> Have I missed any obvious way or is this just not possible?
> 

There is no way to do it from the CLI that I'm aware of. I'd suggest a
remote control power strip to cycle the inputs if you must have remote
manipulation.

As an aside, I accidentally discovered that the 2800 series with an
AC-IP power supply will revert to internal power without rebooting.

~Seth

From mulitskiy at acedsl.com  Tue Jul 21 00:29:47 2009
From: mulitskiy at acedsl.com (Michael Ulitskiy)
Date: Tue, 21 Jul 2009 00:29:47 -0400
Subject: [c-nsp] Assiging tag to AAA per-user route
Message-ID: <200907210029.47287.mulitskiy@acedsl.com>

Hello,

I have a situation when I want to assign different route tags to per-user routes received from radius by L2TP LNS.
I know that I can use cisco VSA "ip:route=<network> <subnet> <gateway> tag XXX". 
The problem with it is that I have to supply next-hop ip in that VSA, which means that I also have to do per-user static 
ip assignment, i.e. my radius profile would look like this:

user Password=mypass
  Service-Type = Framed
  Framed-Protocol = PPP
  Framed-IP-Addres = 192.168.15.5
  Cisco-Avpair = "ip:route 10.10.10.0 255.255.255.0 192.168.15.5 tag 10"

I'd really prefer to avoid per-user static ip assignment and let peer ip to be dynamically assigned by LNS local pool.
Unfortunately if I'm to specify a tag in that Cisco-Avpair then specifying next-hop ip is required, otherwise router gives me an 
error saying "parser is unable to parse ip route" during aaa authorization.
Experimenting I found out that if I'm specify next-hop ip as 0.0.0.0 then it does what I need, i.e. it installs per-user
static route pointing to dynamically assigned peer ip and it applies specified route tag to it. Tested with 12.4(19b).
Here's radius profile that achieve what I need:

user Password=mypass
  Service-Type = Framed
  Framed-Protocol = PPP
  Cisco-Avpair = "ip:route 10.10.10.0 255.255.255.0 0.0.0.0 tag 10"

So I guess my question is if it's supported configuration and if anybody else doing something like this? Or may be there's a better
way to accomplish this and I'm doing something stupid? Don't want to deploy this and then get beaten when it stops working
with the next IOS upgrade because it was never supposed to work that way. So I thought I'd ask community for the advice.
Thanks in advance,

Michael

From andy.saykao at staff.netspace.net.au  Tue Jul 21 00:44:34 2009
From: andy.saykao at staff.netspace.net.au (Andy Saykao)
Date: Tue, 21 Jul 2009 14:44:34 +1000
Subject: [c-nsp] Strange NAT and DHCP Problem
References: <56F211C5E3F24F47B103EA1B253822BE044AAA82@vic-cr-ex1.staff.netspace.net.au>
	<FA1BA229357DB640B944218F3585FECA027659A6@mspe2k1.cs.myharris.net>
Message-ID: <56F211C5E3F24F47B103EA1B253822BE044AAA89@vic-cr-ex1.staff.netspace.net.au>

 
Hi Charles,

Tried what you suggested but no go.

no ip bootp server
clear ip dhcp binding <IP>

Client has obtained an "infinite" lease again.

172.16.75.119    0021.e9a0.777c          Infinite
Automatic

Cheers.

Andy

-----Original Message-----
From: Church, Charles [mailto:cchurc05 at harris.com] 
Sent: Monday, 20 July 2009 10:12 PM
To: Andy Saykao; cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] Strange NAT and DHCP Problem

The infinite DHCP entry is probably a BOOTP client, which doesn't have
the concept of a lease.  There are knobs (ip dhcp bootp ignore) that can
turn off bootp, and only allow DHCP.  I think by default, it'll service
both.

Chuck

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 andy.saykao at staff.netspace.net.au  Tue Jul 21 01:47:10 2009
From: andy.saykao at staff.netspace.net.au (Andy Saykao)
Date: Tue, 21 Jul 2009 15:47:10 +1000
Subject: [c-nsp] Strange NAT and DHCP Problem
References: <56F211C5E3F24F47B103EA1B253822BE044AAA82@vic-cr-ex1.staff.netspace.net.au>
	<FA1BA229357DB640B944218F3585FECA027659A6@mspe2k1.cs.myharris.net>
	<56F211C5E3F24F47B103EA1B253822BE044AAA89@vic-cr-ex1.staff.netspace.net.au>
Message-ID: <56F211C5E3F24F47B103EA1B253822BE044AAA8A@vic-cr-ex1.staff.netspace.net.au>

Found a similar post on NSP in Feb 2009.

http://www.gossamer-threads.com/lists/cisco/nsp/103408

Need the command "ip dhcp bootp ignore" but this isn't supported on the
7600.

http://www.cisco.com/en/US/docs/ios/12_2t/12_2t8/feature/guide/ftdbootp.
html#wp1026678

Cheers.

Andy

-----Original Message-----
From: Andy Saykao 
Sent: Tuesday, 21 July 2009 2:45 PM
To: 'Church, Charles'; cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] Strange NAT and DHCP Problem

 
Hi Charles,

Tried what you suggested but no go.

no ip bootp server
clear ip dhcp binding <IP>

Client has obtained an "infinite" lease again.

172.16.75.119    0021.e9a0.777c          Infinite
Automatic

Cheers.

Andy

-----Original Message-----
From: Church, Charles [mailto:cchurc05 at harris.com]
Sent: Monday, 20 July 2009 10:12 PM
To: Andy Saykao; cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] Strange NAT and DHCP Problem

The infinite DHCP entry is probably a BOOTP client, which doesn't have
the concept of a lease.  There are knobs (ip dhcp bootp ignore) that can
turn off bootp, and only allow DHCP.  I think by default, it'll service
both.

Chuck

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 zivl at gilat.net  Tue Jul 21 02:51:10 2009
From: zivl at gilat.net (Ziv Leyes)
Date: Tue, 21 Jul 2009 09:51:10 +0300
Subject: [c-nsp] TCLsh + Ping TOS
In-Reply-To: <cf70832e0907200958o62ef7a71w3b8a51463c64201a@mail.gmail.com>
References: <cf70832e0907200958o62ef7a71w3b8a51463c64201a@mail.gmail.com>
Message-ID: <EC993E87D960A541A66BF21D62AA42A6230163B08B@exch2k7.gilat.local>

That's interesting indeed, the one line ping command seems to not be able to include the extended commands, so I wonder, does the tcsh support "expect"
Because that could be a solution for this kind of need.

Regarding the command running from other place you could use an alias exec, e.g.
alias exec multiping tclsh disk2:file.tcl

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 .....::::[Gardener] ::::.....
Sent: Monday, July 20, 2009 7:59 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] TCLsh + Ping TOS

Hi to everyone.

Please i need some advice to create a little script to make Ping with TOS

i found on several webpages, things like this.

R1#tclsh
R1(tcl)#foreach address {
+>(tcl)#172.12.23.2
+>(tcl)#172.12.23.3
+>(tcl)#172.12.23.4
+>(tcl)#172.12.23.6
+>(tcl)#172.12.23.7
+>(tcl)#} { ping $address re 10 si 1500
+>(tcl)#}

This is my problem, i can not make the complete command on ONE line (becouse
i don't have TOS ).
 I need to create script to execute things like this.

R1#ping
Protocol [ip]:
Target IP address: 172.16.123.1
Repeat count [5]: 1000
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: loopback0
Type of service [0]: 96
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:



The other impossibility that i have i can not create or bring from other
place the file.tcl, all this script has to be applied on-line on the router.

Thank you.
 Andres P. Spano
_______________________________________________
cisco-nsp mailing 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 ben at cuckoo.org  Tue Jul 21 03:11:31 2009
From: ben at cuckoo.org (Ben White)
Date: Tue, 21 Jul 2009 08:11:31 +0100
Subject: [c-nsp] MLPPP throughput
In-Reply-To: <20090716152931.GJ1679@rtp-cse-489.cisco.com>
References: <Pine.LNX.4.63.0907150959150.28268@charmed.internetsolver.com>
	<20090716015904.GD27087@rtp-cse-489.cisco.com>
	<20090716021955.GI27087@rtp-cse-489.cisco.com>
	<7100ed370907160212s5ecf34e6y755485b59513a76a@mail.gmail.com>
	<4A5F2389.1070700@internetsolver.com>
	<20090716133331.GC1679@rtp-cse-489.cisco.com>
	<4A5F2D24.9070509@internetsolver.com>
	<20090716152931.GJ1679@rtp-cse-489.cisco.com>
Message-ID: <b4a117b30907210011n5b951d77y52f41804b6566786@mail.gmail.com>

I'd check on the show dsl int output, check to see whether 2 lines
have appeared in interleaved mode as opposed to fast mode.  That could
explain packet reordering if the lines are provisioned slightly
differently and would introduce additional latency on the interleaved
lines.

2009/7/16 Rodney Dunn <rodunn at cisco.com>:
> On Thu, Jul 16, 2009 at 08:37:40AM -0500, Dave Weis wrote:
>> Rodney Dunn wrote:
>> >Yeah...a lot of discarded fragments and the reorders are pretty high
>> >implying there is a lot of differential delay along the paths.
>>
>> That's surprising that they would be that different, it's 4 ILEC DSL
>> circuits from a relatively small office terminating to me over a DS3
>> with relatively low usage. The only thing I can think of is the link
>> from the small town is congested.
>>
>> Would the problem be related to congestion? I can see if they will try
>> pulling some traffic during off hours if that's the case.
>
> Could be.
>
>>
>> Thanks!
>>
>> dave
>>
>>
>> --
>> Dave Weis
>> 515-224-9229
>> djweis at internetsolver.com
>> http://www.internetsolver.com/
> _______________________________________________
> cisco-nsp mailing list ?cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>



-- 
Ben

From p.mayers at imperial.ac.uk  Tue Jul 21 04:33:27 2009
From: p.mayers at imperial.ac.uk (Phil Mayers)
Date: Tue, 21 Jul 2009 09:33:27 +0100
Subject: [c-nsp] 6500 & broadcast-storm control
Message-ID: <4A657D57.2000403@imperial.ac.uk>

All,

We're running an (otherwise excellent) non-Cisco stackable switch at the 
edge. We're having some stability problems, resulting in individual 
units crashing. When this happens, it seems to cause a broadcast storm.

Out architecture is:

coreA === coreB
  |          |
  \- switch -/

The problem is that the broadcast storm seems to flood the coreA->coreB 
link too, causing STP drop-outs and flapping.

Obviously one thing to look at is broadcast storm control on the 6500s. 
However, from what I can make it it's rather primitive; the rate of 
broadcast traffic is capped only in 1-second windows and doesn't take 
account of packet-size? Does anyone have any experience of it? Does it 
work well.

The second thing I'm a bit confused about is how the flood interrupts 
STP packets. My understanding was that the box generally prioritised 
control plane traffic for transmission over data-plane. Is that not the 
case for STP? In any event, the coreA<->coreB links is 2x10G whereas the 
core->switch links are only 1G, so it's hard to see how 1G could swamp 20G.

Is it more subtle, and the SP is being overwhelmed by the punt? We run 
CoPP but obviously that's layer3. I don't have any layer2 MLS 
rate-limiters enabled, and since they're per-box rather than per-port I 
doubt they'd help.

Advice appreciated.

From cchurc05 at harris.com  Tue Jul 21 04:29:47 2009
From: cchurc05 at harris.com (Church, Charles)
Date: Tue, 21 Jul 2009 03:29:47 -0500
Subject: [c-nsp] Strange NAT and DHCP Problem
In-Reply-To: <56F211C5E3F24F47B103EA1B253822BE044AAA89@vic-cr-ex1.staff.netspace.net.au>
References: <56F211C5E3F24F47B103EA1B253822BE044AAA82@vic-cr-ex1.staff.netspace.net.au>
	<FA1BA229357DB640B944218F3585FECA027659A6@mspe2k1.cs.myharris.net>
	<56F211C5E3F24F47B103EA1B253822BE044AAA89@vic-cr-ex1.staff.netspace.net.au>
Message-ID: <FA1BA229357DB640B944218F3585FECA027CA28D@mspe2k1.cs.myharris.net>

Did you try " ip dhcp bootp ignore"?  

Chuck

-----Original Message-----
From: Andy Saykao [mailto:andy.saykao at staff.netspace.net.au] 
Sent: Tuesday, July 21, 2009 12:45 AM
To: Church, Charles; cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] Strange NAT and DHCP Problem


 
Hi Charles,

Tried what you suggested but no go.

no ip bootp server
clear ip dhcp binding <IP>

Client has obtained an "infinite" lease again.

172.16.75.119    0021.e9a0.777c          Infinite
Automatic

Cheers.

Andy

-----Original Message-----
From: Church, Charles [mailto:cchurc05 at harris.com] 
Sent: Monday, 20 July 2009 10:12 PM
To: Andy Saykao; cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] Strange NAT and DHCP Problem

The infinite DHCP entry is probably a BOOTP client, which doesn't have
the concept of a lease.  There are knobs (ip dhcp bootp ignore) that can
turn off bootp, and only allow DHCP.  I think by default, it'll service
both.

Chuck

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 cchurc05 at harris.com  Tue Jul 21 04:33:46 2009
From: cchurc05 at harris.com (Church, Charles)
Date: Tue, 21 Jul 2009 03:33:46 -0500
Subject: [c-nsp] Strange NAT and DHCP Problem
In-Reply-To: <56F211C5E3F24F47B103EA1B253822BE044AAA8A@vic-cr-ex1.staff.netspace.net.au>
References: <56F211C5E3F24F47B103EA1B253822BE044AAA82@vic-cr-ex1.staff.netspace.net.au>
	<FA1BA229357DB640B944218F3585FECA027659A6@mspe2k1.cs.myharris.net>
	<56F211C5E3F24F47B103EA1B253822BE044AAA89@vic-cr-ex1.staff.netspace.net.au>
	<56F211C5E3F24F47B103EA1B253822BE044AAA8A@vic-cr-ex1.staff.netspace.net.au>
Message-ID: <FA1BA229357DB640B944218F3585FECA027CA28E@mspe2k1.cs.myharris.net>

Sorry, replied too quickly.  Can't think of any other workaround then.

Chuck


-----Original Message-----
From: Andy Saykao [mailto:andy.saykao at staff.netspace.net.au] 
Sent: Tuesday, July 21, 2009 1:47 AM
To: Church, Charles; cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] Strange NAT and DHCP Problem


Found a similar post on NSP in Feb 2009.

http://www.gossamer-threads.com/lists/cisco/nsp/103408

Need the command "ip dhcp bootp ignore" but this isn't supported on the
7600.

http://www.cisco.com/en/US/docs/ios/12_2t/12_2t8/feature/guide/ftdbootp.
html#wp1026678

Cheers.

Andy

-----Original Message-----
From: Andy Saykao 
Sent: Tuesday, 21 July 2009 2:45 PM
To: 'Church, Charles'; cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] Strange NAT and DHCP Problem

 
Hi Charles,

Tried what you suggested but no go.

no ip bootp server
clear ip dhcp binding <IP>

Client has obtained an "infinite" lease again.

172.16.75.119    0021.e9a0.777c          Infinite
Automatic

Cheers.

Andy

-----Original Message-----
From: Church, Charles [mailto:cchurc05 at harris.com]
Sent: Monday, 20 July 2009 10:12 PM
To: Andy Saykao; cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] Strange NAT and DHCP Problem

The infinite DHCP entry is probably a BOOTP client, which doesn't have
the concept of a lease.  There are knobs (ip dhcp bootp ignore) that can
turn off bootp, and only allow DHCP.  I think by default, it'll service
both.

Chuck

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 saku at ytti.fi  Tue Jul 21 04:53:15 2009
From: saku at ytti.fi (Saku Ytti)
Date: Tue, 21 Jul 2009 11:53:15 +0300
Subject: [c-nsp] 6500 & broadcast-storm control
In-Reply-To: <4A657D57.2000403@imperial.ac.uk>
References: <4A657D57.2000403@imperial.ac.uk>
Message-ID: <20090721085315.GA26874@mx.ytti.net>

On (2009-07-21 09:33 +0100), Phil Mayers wrote:

Hey,

> Obviously one thing to look at is broadcast storm control on the
> 6500s. However, from what I can make it it's rather primitive; the
> rate of broadcast traffic is capped only in 1-second windows and
> doesn't take account of packet-size? Does anyone have any experience
> of it? Does it work well.

storm-control works just fine. But unfortunately for WS-X6704-10GE minimum
amount of 0.34% which is too much for the box to handle without starting to
flap BGP/LDP/IS-IS etc.

Even if you could limit them to acceptable level, you'll still be looping
unknown unicast, unless you've explicitly stopped forwarding them (which
implies you must have only 1 switch or you've synchronized ARP timeout with
MAC timeout).

> Is it more subtle, and the SP is being overwhelmed by the punt? We
> run CoPP but obviously that's layer3. I don't have any layer2 MLS
> rate-limiters enabled, and since they're per-box rather than
> per-port I doubt they'd help.

My guess would be this also, that you simply overloaded the SUP. Maybe if
you can recreate it in controlled environment, you could see what the
software is doing and maybe even find way to protect yourself.

-- 
  ++ytti

From ip at ioshints.info  Tue Jul 21 06:39:31 2009
From: ip at ioshints.info (Ivan Pepelnjak)
Date: Tue, 21 Jul 2009 12:39:31 +0200
Subject: [c-nsp] TCLsh + Ping TOS
In-Reply-To: <EC993E87D960A541A66BF21D62AA42A6230163B08B@exch2k7.gilat.local>
References: <cf70832e0907200958o62ef7a71w3b8a51463c64201a@mail.gmail.com>
	<EC993E87D960A541A66BF21D62AA42A6230163B08B@exch2k7.gilat.local>
Message-ID: <000001ca09ef$89578b10$0a00000a@nil.si>

Tcl doesn't have "expect" but it does have "typeahead" which you can
probably use to feed the input to Ping command.

http://wiki.nil.com/Insert_responses_to_command_prompts_in_Tclsh
http://wiki.nil.com/Tclsh_on_Cisco_IOS_tutorial

Ivan
 
http://www.ioshints.info/about
http://blog.ioshints.info/ 

> -----Original Message-----
> From: Ziv Leyes [mailto:zivl at gilat.net] 
> Sent: Tuesday, July 21, 2009 8:51 AM
> To: .....::::[Gardener] ::::.....; cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] TCLsh + Ping TOS
> 
> That's interesting indeed, the one line ping command seems to 
> not be able to include the extended commands, so I wonder, 
> does the tcsh support "expect"
> Because that could be a solution for this kind of need.
> 
> Regarding the command running from other place you could use 
> an alias exec, e.g.
> alias exec multiping tclsh disk2:file.tcl
> 
> 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 
> .....::::[Gardener] ::::.....
> Sent: Monday, July 20, 2009 7:59 PM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] TCLsh + Ping TOS
> 
> Hi to everyone.
> 
> Please i need some advice to create a little script to make 
> Ping with TOS
> 
> i found on several webpages, things like this.
> 
> R1#tclsh
> R1(tcl)#foreach address {
> +>(tcl)#172.12.23.2
> +>(tcl)#172.12.23.3
> +>(tcl)#172.12.23.4
> +>(tcl)#172.12.23.6
> +>(tcl)#172.12.23.7
> +>(tcl)#} { ping $address re 10 si 1500
> +>(tcl)#}
> 
> This is my problem, i can not make the complete command on 
> ONE line (becouse i don't have TOS ).
>  I need to create script to execute things like this.
> 
> R1#ping
> Protocol [ip]:
> Target IP address: 172.16.123.1
> Repeat count [5]: 1000
> Datagram size [100]:
> Timeout in seconds [2]:
> Extended commands [n]: y
> Source address or interface: loopback0
> Type of service [0]: 96
> Set DF bit in IP header? [no]:
> Validate reply data? [no]:
> Data pattern [0xABCD]:
> Loose, Strict, Record, Timestamp, Verbose[none]:
> Sweep range of sizes [n]:
> 
> 
> 
> The other impossibility that i have i can not create or bring 
> from other place the file.tcl, all this script has to be 
> applied on-line on the router.
> 
> Thank you.
>  Andres P. Spano
> _______________________________________________
> cisco-nsp mailing 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 gulerozgur at yahoo.co.uk  Tue Jul 21 07:14:10 2009
From: gulerozgur at yahoo.co.uk (Ozgur Guler)
Date: Tue, 21 Jul 2009 11:14:10 +0000 (GMT)
Subject: [c-nsp] Cisco Route Manager
Message-ID: <517642.34165.qm@web25503.mail.ukl.yahoo.com>



Hi All, 

Does anybody have any experience with  "Cisco Route Manager"? 

http://www.cisco.com/en/US/customer/prod/collateral/netmgtsw/ps6504/ps6335/ps6336/product_data_sheet0900aecd80284181.html


Thanks,
-Ozgur



      


From p.mayers at imperial.ac.uk  Tue Jul 21 08:03:13 2009
From: p.mayers at imperial.ac.uk (Phil Mayers)
Date: Tue, 21 Jul 2009 13:03:13 +0100
Subject: [c-nsp] 6500 & broadcast-storm control
In-Reply-To: <20090721085315.GA26874@mx.ytti.net>
References: <4A657D57.2000403@imperial.ac.uk>
	<20090721085315.GA26874@mx.ytti.net>
Message-ID: <4A65AE81.2000301@imperial.ac.uk>

Saku Ytti wrote:
> On (2009-07-21 09:33 +0100), Phil Mayers wrote:
> 
> Hey,
> 
>> Obviously one thing to look at is broadcast storm control on the
>> 6500s. However, from what I can make it it's rather primitive; the
>> rate of broadcast traffic is capped only in 1-second windows and
>> doesn't take account of packet-size? Does anyone have any experience
>> of it? Does it work well.
> 
> storm-control works just fine. But unfortunately for WS-X6704-10GE minimum
> amount of 0.34% which is too much for the box to handle without starting to
> flap BGP/LDP/IS-IS etc.

Well, these are 6748-SFP, which I see can go down much lower, though it 
talks about "100 meg" ports (on an -SFP linecard!)

Can the mls qos be used to rate-limit this on ingress? I doubt it; IIRC 
the ingress policing is limited to CoS only.

> 
> Even if you could limit them to acceptable level, you'll still be looping
> unknown unicast, unless you've explicitly stopped forwarding them (which
> implies you must have only 1 switch or you've synchronized ARP timeout with
> MAC timeout).

We haven't done that. The storms are of very short duration (<10 
seconds, but longer than 3x STP PDU timeouts) so I'm hoping that unknown 
unicast will not be as big a problem.

> 
>> Is it more subtle, and the SP is being overwhelmed by the punt? We
>> run CoPP but obviously that's layer3. I don't have any layer2 MLS
>> rate-limiters enabled, and since they're per-box rather than
>> per-port I doubt they'd help.
> 
> My guess would be this also, that you simply overloaded the SUP. Maybe if
> you can recreate it in controlled environment, you could see what the
> software is doing and maybe even find way to protect yourself.
> 

I'm investigating another solution on the edge switches themselves; they 
support fairly granular output metering based on ACL match terms, so I 
might be able to match on destination MAC and limit to something small 
like 128kbit/sec, but it's hacky - I'd like to avoid it, and such 
protection really ought to be on the core switch, in case it gets missed 
or mis-configured on the edge.

From djweis at internetsolver.com  Tue Jul 21 08:09:46 2009
From: djweis at internetsolver.com (Dave Weis)
Date: Tue, 21 Jul 2009 07:09:46 -0500
Subject: [c-nsp] MLPPP throughput
In-Reply-To: <b4a117b30907210011n5b951d77y52f41804b6566786@mail.gmail.com>
References: <Pine.LNX.4.63.0907150959150.28268@charmed.internetsolver.com>	<20090716015904.GD27087@rtp-cse-489.cisco.com>	<20090716021955.GI27087@rtp-cse-489.cisco.com>	<7100ed370907160212s5ecf34e6y755485b59513a76a@mail.gmail.com>	<4A5F2389.1070700@internetsolver.com>	<20090716133331.GC1679@rtp-cse-489.cisco.com>	<4A5F2D24.9070509@internetsolver.com>	<20090716152931.GJ1679@rtp-cse-489.cisco.com>
	<b4a117b30907210011n5b951d77y52f41804b6566786@mail.gmail.com>
Message-ID: <4A65B00A.1080109@internetsolver.com>

Ben White wrote:
> I'd check on the show dsl int output, check to see whether 2 lines
> have appeared in interleaved mode as opposed to fast mode.  That could
> explain packet reordering if the lines are provisioned slightly
> differently and would introduce additional latency on the interleaved
> lines.

The stats and configuration is identical on all of the lines. The only 
difference might be that a couple of them seem to go through a different 
DSLAM guessing from the vendor of the ATU-C chipset being different on 
some of the lines. We've put them in various combinations with no 
changes to the speed.

We did some speed tests in the off hours and didn't see any change so I 
don't believe it's due to network congestion anywhere.

dave



-- 
Dave Weis
Internet Solver
Your Technology Partner
515-224-9229
www.internetsolver.com

From p.mayers at imperial.ac.uk  Tue Jul 21 09:09:41 2009
From: p.mayers at imperial.ac.uk (Phil Mayers)
Date: Tue, 21 Jul 2009 14:09:41 +0100
Subject: [c-nsp] QoS for broadcast storms (was 6500 & broadcast-storm
	control)
In-Reply-To: <4A65AE81.2000301@imperial.ac.uk>
References: <4A657D57.2000403@imperial.ac.uk>
	<20090721085315.GA26874@mx.ytti.net>
	<4A65AE81.2000301@imperial.ac.uk>
Message-ID: <4A65BE15.6030502@imperial.ac.uk>

Phil Mayers wrote:

>> storm-control works just fine. But unfortunately for WS-X6704-10GE minimum
>> amount of 0.34% which is too much for the box to handle without starting to
>> flap BGP/LDP/IS-IS etc.
> 
> Well, these are 6748-SFP, which I see can go down much lower, though it 
> talks about "100 meg" ports (on an -SFP linecard!)
> 
> Can the mls qos be used to rate-limit this on ingress? I doubt it; IIRC 
> the ingress policing is limited to CoS only.

Hmm. I don't seem to be able to match on MAC address, but I can match on IP:

object-group ip address BROADCAST
  host-info 10.2.11.255
  host-info 10.2.15.255
  host-info 10.2.19.255
  ...
  host-info 255.255.255.255
ip access-list extended BROADCAST
  permit ip any addrgroup BROADCAST
class-map match-all BROADCAST
   match access-group name BROADCAST
policy-map EDGE
   class BROADCAST
    police 128k 4096 conform transmit exceed drop violate drop
int GiX/Y
   service-policy input EDGE

...which seems to work. I guess the problem there is, it does nothing to 
ensure that STP makes it down to / back from the edge switch.

From linux.yahoo at gmail.com  Tue Jul 21 09:39:11 2009
From: linux.yahoo at gmail.com (Manu Chao)
Date: Tue, 21 Jul 2009 15:39:11 +0200
Subject: [c-nsp] 2960G + RPS-2300 - how to get back on internal PS
In-Reply-To: <4A64EA03.6050702@rollernet.us>
References: <h42ol9$ee8$1@ger.gmane.org> <4A64EA03.6050702@rollernet.us>
Message-ID: <7100ed370907210639r71b9dd46iabd9e1df96d4d103@mail.gmail.com>

What you can manage if your RPS 2300 is connected to Cisco Catalyst
3750-E/3560-E


? The ability to remotely place the RPS (and all six DC ports) in active or
standby mode.

? The ability to report if one or two RPS power supply modules are present
in the Cisco RPS 2300, as well as their status.

? The ability to report a list of connected switches and their power
requirements.

? The ability to report which switches are being supplied power from the
Cisco RPS 2300.

? The ability to configure switch priority.

On Tue, Jul 21, 2009 at 12:04 AM, Seth Mattinen <sethm at rollernet.us> wrote:

> Bernhard Schmidt wrote:
> > Hi,
> >
> > first of all, I'm well aware of the limitations of 2960 series with
> > external RPS, they are only used here to have the very small advantage
> > to choose when the outage will be.
> >
> > 2* 2960G with RPS-2300 and dual powersupply. 2960 is on external power
> > feed. Is there any way to get back on the internal AC from remote? I
> > know it is going to reboot and I can live with that, but so far only
> > disconnecting the RPS from the switch or disabling the RPS port with the
> > buttons in front worked. Both of course require on-site staff. A reload
> > from the CLI did not work.
> >
> > Have I missed any obvious way or is this just not possible?
> >
>
> There is no way to do it from the CLI that I'm aware of. I'd suggest a
> remote control power strip to cycle the inputs if you must have remote
> manipulation.
>
> As an aside, I accidentally discovered that the 2800 series with an
> AC-IP power supply will revert to internal power without rebooting.
>
> ~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 costellm at lafayette.edu  Tue Jul 21 09:55:11 2009
From: costellm at lafayette.edu (Michael Costello)
Date: Tue, 21 Jul 2009 09:55:11 -0400
Subject: [c-nsp] persistent debug
In-Reply-To: <9BA7244859D14DA8AC1E7F22267BF5EE@GINKGO>
References: <9BA7244859D14DA8AC1E7F22267BF5EE@GINKGO>
Message-ID: <4A65C8BF.7010205@lafayette.edu>

Adam Greene said the following:
> Hi,
> 
> I like to leave "debug ip bgp updates" running on customer edge routers 
> with whom I do eBGP peering, to track outage events.

Why not just use `bgp log-neighbor-changes` and syslog?



From ross at kallisti.us  Tue Jul 21 10:06:30 2009
From: ross at kallisti.us (Ross Vandegrift)
Date: Tue, 21 Jul 2009 10:06:30 -0400
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <8e157ab40907201234h47b5052fh20ceb1fb2533da52@mail.gmail.com>
References: <a1873f1f0907131438m3f0b4c70r82a953a29042b6d7@mail.gmail.com>
	<1247524340.4661.65.camel@abehat.net.rm.dk>
	<20090714084503.GA15753@lboro.ac.uk>
	<d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>
	<6B43981C32F8464CB24CEE209DA32BD302350ADD@kenya.tronet.as>
	<8e157ab40907162051t4d32d6cbudc1dacca82790ed1@mail.gmail.com>
	<200907180455.n6I4tmr8016738@sj-core-2.cisco.com>
	<8e157ab40907181306h87f6e8bv2838d248050c65b@mail.gmail.com>
	<20090720083018.GC8544@lboro.ac.uk>
	<8e157ab40907201234h47b5052fh20ceb1fb2533da52@mail.gmail.com>
Message-ID: <20090721140630.GA32724@kallisti.us>

On Mon, Jul 20, 2009 at 02:34:41PM -0500, Matt Buford wrote:
> First, a quick search for SNMP support makes me think that we won't be doing
> any changes to this over SNMP.  You have to read the bitmask, edit it, and
> then rewrite it with your changes.  This means if 2 people attempt to edit
> the allowed VLANs on the same port at the same time, they'll overwrite each
> other's changes.  So now, our web based port-VLAN form (which is already a
> little slow due to lots of SNMP tables to walk) will also have to also SSH
> to the 2 upstream switches to issue the "add" commands.  We're already
> headed down a rough road here...

You can avoid these issues, and it's not too terrible.  BUT, I've
recently rewritten all of my software to merge config via TFTP instead
of using the VTP-MIB.  Write operations are very, very racy.  I've
uncovered dozens of crashes in SXF on our production gear.  I know of
one that affects up through SXI.  Having the switch merge config via
TFTP from SNMP is not bad at all for a web app.

If you're brave, here's two approaches to consistently managing VLAN
bitmasks:

1) Always blindly set the bitmask to the set of VLANs that are
required by the downstream device.  So long as you first add the VLAN
to the downstream device, you'll always come back with a set including
both VLANs set by two conflicting users.

2) CISCO-VTP-MIB::vlanTrunkPortSetSerialNo is an advisory lock that
apps can use to coordinate their changes:
	a) Read the vlanTrunkPortSetSerilNo.ifIndex, save the result.
	b) Compute whatever VLAN changes you need to make
	c) In one SNMP write, set the new bitmasks and set
vlanTrunkPortSetSerialNo to the value read in a.  If it doesn't match,
the switch will reject all writes.

> Second, there is the question of removing VLANs from this list.  When a tech
> goes to the web form to set the VLAN for a port, we need to go through all
> ports on the switch and see if anyone else is using the old VLAN that the
> port used to be on.  Don't forget to check for it being used on tagged
> ports!  If no one remains using that VLAN on the access switch, then it can
> be pruned from the uplinks.  Then there's the (unlikely, but possible) case
> where someone added a port to that VLAN in between the time you started
> walking the table and when you deleted the VLAN from the ACL.  Oops.

Having implemented this, it isn't as difficult as it sounds.  Just
takes a bit of care to record what your switching topology looks like.
I don't split the operation into add and remove - every update always
sets the trunks to their fully-pruned set of VLANs:

1) For each pair of connected switches, I store the interfaces that
are inter-connected.

2) Starting at the leaf device, I setup the required VLAN changes
locally.

3) Then, walking backwards from that device, collect the set of
required VLANs and change the trunks that connect that device.

4) Stop when you get to whatever the root of your switching domain is.
If you have a ring topology, you'll need some way to break the loop.

> Finally, there is cost associated with the development work and
> administrative hassle that this VLAN pruning requires.  I'd prefer to spend
> that money on hardware that Just Works, as opposed to having my own staff of
> software developers and network engineers maintain this system of ACLs.  One
> time fees for hardware to make my problems disappear forever and my network
> configuration less complex are appreciated.  :)

Fair enough - I'd love to provide you my software, but I'm not sure
that my employer would be okay with it.

-- 
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 awain567 at yahoo.com  Tue Jul 21 11:12:15 2009
From: awain567 at yahoo.com (Alex Wa)
Date: Tue, 21 Jul 2009 08:12:15 -0700 (PDT)
Subject: [c-nsp] no keepalive in eth interface
Message-ID: <427443.54409.qm@web58008.mail.re3.yahoo.com>

Hi guys,
?
I disabled keepalives in an FastEthernet interface (3750 24P), but the interface is still showing down/down status. Is there other things to take into account to show up/up with the no keepalive?
?
thanks in advance
Alejandro Wainshtok


      

From rick at woofpaws.com  Tue Jul 21 13:29:34 2009
From: rick at woofpaws.com (Rick Ernst)
Date: Tue, 21 Jul 2009 10:29:34 -0700
Subject: [c-nsp] Policing on Catalyst 4948, leaky-bucket, burst, and memory
Message-ID: <d066472f0907211029g1b1be90ajaf0a737cd64d0828@mail.gmail.com>

As a sanity-check for observed behavior; the burst buffer in a policing
policy does not actually consume memory?

For testing/eval I had a 750Mbs policy with a 19MB burst and there was no
change to reported system memory.  I'm assuming that the burst size is just
added to an internal formula that just uses interface counters to determine
conform/drop action?

What is the impact/affect of making the burst buffer too small/big?

Thanks,


-----
policy-map BW_750M
 class class-default
    police 750 mbps 18.75 mbyte conform-action transmit exceed-action drop

From rodunn at cisco.com  Tue Jul 21 13:31:39 2009
From: rodunn at cisco.com (Rodney Dunn)
Date: Tue, 21 Jul 2009 13:31:39 -0400
Subject: [c-nsp] no keepalive in eth interface
In-Reply-To: <427443.54409.qm@web58008.mail.re3.yahoo.com>
References: <427443.54409.qm@web58008.mail.re3.yahoo.com>
Message-ID: <4A65FB7B.4090705@cisco.com>

Some device drivers will not honor no keeps as a signal if the line 
isn't connected.

Loopback cable should work.

Rodney



Alex Wa wrote:
> Hi guys,
>  
> I disabled keepalives in an FastEthernet interface (3750 24P), but the interface is still showing down/down status. Is there other things to take into account to show up/up with the no keepalive?
>  
> thanks in advance
> Alejandro Wainshtok
> 
> 
>       
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

From Kiran.Oddiraju at cbre.com  Tue Jul 21 14:08:30 2009
From: Kiran.Oddiraju at cbre.com (Oddiraju, Kiran @ London SMC)
Date: Tue, 21 Jul 2009 19:08:30 +0100
Subject: [c-nsp] NAT and PAT on ASA
Message-ID: <B5CFB919B5EEF345969F51FAFE6360D50ADC90@GBLDCXMB10.emea.cbre.net>

Guys,

 

I am new to the ASA world, I have a bunch of external IP's from the ISP
and I have an inside host that I want to access externally. How do I
translate an inside ip (192.168.0.100) to an outside address
(58.66.76.88) on the ASA? I should be able to ping and www from outside
world to my inside host. Please let me know how to accomplish this.

 

Many thanks,

K


CB Richard Ellis Limited, Registered Office: St Martin's Court, 
10 Paternoster Row, London, EC4M 7HP, registered in England and Wales No. 3536032. 
Regulated by the RICS and an appointed representative of CB Richard Ellis 
Indirect Investment Services Limited which is authorised and regulated by the Financial Services Authority.

This communication is from CB Richard Ellis Limited or one of its 
associated/subsidiary companies. This communication contains information 
which is confidential and may be privileged. If you are not the intended recipient, 
please contact the sender immediately. Any use of its contents is strictly prohibited 
and you must not copy, send or disclose it, or rely on its contents in any way whatsoever. 
Reasonable care has been taken to ensure that this communication 
(and any attachments or hyperlinks contained within it) is free from computer viruses. 
No responsibility is accepted by CB Richard Ellis Limited or its associated/subsidiary 
companies and the recipient should carry out any appropriate virus checks.


From clane1875 at gmail.com  Tue Jul 21 14:34:33 2009
From: clane1875 at gmail.com (Chris Lane)
Date: Tue, 21 Jul 2009 14:34:33 -0400
Subject: [c-nsp] GSR 12008 GRP ISSUES
Message-ID: <2e1cd850907211134t76ad2950u991688ac7d2cc921@mail.gmail.com>

All,
I have a GSR 12008 with 2 GRP-B route processors. Running
gsr-k4p-mz.120-32.S11.bin

My GRP failed over about 45 minutes ago to the backup in Slot1 from Slot0.
I keep getting this in my logs.
SEC  0:00:00:06: %MBUS-6-FIA_CONFIG: Switch Cards 0x1F (bit mask); Primary
Clock CSC_1
SEC  0:00:00:07: %FIA-3-HALT: To Fabric
SEC  0:00:00:07: %FIA-3-PARITYERR: To Fabric parity error was detected.
Request parity error interrupt = 0x4.
SEC  0:00:00:07: %FIA-3-HALT: To Fabric
SEC  0:00:00:07: %FIA-3-HALT: To Fabric
SEC  0:00:00:07: %RP-3-FABRIC_UNI: Unicast send timed out  (1)
SEC  0:00:00:13: %RP-3-FABRIC_UNI: Unicast send timed out  (1)
SEC  0:00:00:23: %RP-3-FABRIC_UNI: Unicast send timed out  (1)
SEC  0:00:00:37: %IPC-5-REGPORTFAIL: Registering Control Port Id=0x1000003
timeout=0x6
-Traceback= 501F6650 505A3B90 505A3F4C 505A40D8 5059FCCC 502A02D8 502A02C4
SEC  0:00:00:44: %RP-3-FABRIC_UNI: Unicast send timed out  (1)
SEC  0:00:01:08: %IPC-5-REGPORTFAIL: Registering Control Port Id=0x1000003
timeout=0x6
-Traceback= 501F6650 505A3B90 505A3BD8 502A02D8 502A02C4
SEC  0:00:01:15: %RP-3-FABRIC_UNI: Unicast send timed out  (1)
SEC  0:00:01:39: %IPC-5-REGPORTFAIL: Registering Control Port Id=0x1000003
timeout=0x6
-Traceback= 501F6650 505A3B90 505A3BD8 502A02D8 502A02C4
SEC  0:00:01:56: %RP-3-FABRIC_UNI: Unicast send timed out  (1)
SEC  0:00:02:10: %IPC-5-REGPORTFAIL: Registering Control Port Id=0x1000003
timeout=0x6
-Traceback= 501F6650 505A3B90 505A3BD8 502A02D8 502A02C4
SEC  0:00:02:41: %IPC-5-REGPORTFAIL: Registering Control Port Id=0x1000003
timeout=0x6
-Traceback= 501F6650 505A3B90 505A3BD8 502A02D8 502A02C4
SEC  0:00:02:48: %RP-3-FABRIC_UNI: Unicast send timed out  (1)
SEC  0:00:03:12: %IPC-5-REGPORTFAIL: Registering Control Port Id=0x1000003
timeout=0x6
-Traceback= 501F6650 505A3B90 505A3BD8 502A02D8 502A02C4
SEC  0:00:03:43: %IPC-5-REGPORTFAIL: Registering Control Port Id=0x1000003
timeout=0x6
-Traceback= 501F6650 505A3B90 505A3BD8 502A02D8 502A02C4
SEC  0:00:03:50: %RP-3-FABRIC_UNI: Unicast send timed out  (1)
SEC  0:00:04:14: %IPC-5-REGPORTFAIL: Registering Control Port Id=0x1000003
timeout=0x6
-Traceback= 501F6650 505A3B90 505A3BD8 502A02D8 502A02C4
SEC  0:00:04:45: %IPC-5-REGPORTFAIL: Registering Control Port Id=0x1000003
timeout=0x6
-Traceback= 501F6650 505A3B90 505A3BD8 502A02D8 502A02C4
SEC  0:00:05:02: %RP-3-FABRIC_UNI: Unicast send timed out  (1)
Jul 21 12:27:01.258 EDT: %RP-3-ERROR: Timed out while initializing IPC to
standby RP in slot 0
Jul 21 12:28:02.070 EDT: %MBUS-6-DEADSCDY: Standby RP in slot 0 timed out,
reset


Is this because SLOT0 is hung, trying to become primary again yet not
communicating with SLOT1 the active RP?
SLOT 0  (RP/LC 0 ): Route Processor
  MAIN: type 19,  800-2427-03 rev F0
        Deviation:  D070866
        HW config: 0x00    SW key: 00-00-00
  PCA:  73-2170-08 rev E0 ver 5
        Design Release 1.5  S/N SAD0745027R
  MBUS: MBUS Agent (1)  73-2146-07 rev B0 dev 0
        HW version 1.2  S/N CAT073504X3
        Test hist: 0x00    RMA#: 00-00-00    RMA hist: 0x00
  DIAG: Test count: 0x00000000    Test results: 0x00000000
  FRU:  Linecard/Module: GRP-B=
        Route Memory: MEM-GRP-512=
  MBUS Agent Software version 2.68 (RAM) (ROM version is 3.47)
  ROM Monitor version 2.2
  Primary clock is CSC 1
  Board State is Route Processor Powered ( RP  RDY )    ********* SHOULDN'T
THIS SAY STANDBY (STBY  RP )
  Insertion time: 42w1d (00:56:55 ago)
  DRAM size: 536870912 bytes


SLOT 1  (RP/LC 1 ): Route Processor
  MAIN: type 19,  800-2427-03 rev F0
        Deviation: 0
        HW config: 0x00    SW key: 00-00-00
  PCA:  73-2170-08 rev E0 ver 5
        Design Release 1.5  S/N SAD072000C3
  MBUS: MBUS Agent (1)  73-2146-07 rev B0 dev 0
        HW version 1.2  S/N CAT07100SFN
        Test hist: 0x00    RMA#: 00-00-00    RMA hist: 0x00
  DIAG: Test count: 0x00000000    Test results: 0x00000000
  FRU:  Linecard/Module: GRP-B=
        Route Memory: MEM-GRP-512=
  MBUS Agent Software version 2.68 (RAM) (ROM version is 3.47)
  ROM Monitor version 2.2
  Primary clock is CSC 1
  Board State is IOS Running  ACTIVE (ACTV  RP )
  Insertion time: 42w1d (00:56:55 ago)
  DRAM size: 536870912 bytes



Any help, suggestions greatly appreciated

Chris

-- 
//CL

From raa at opusnet.com  Tue Jul 21 13:54:06 2009
From: raa at opusnet.com (Ruben Alvarez)
Date: Tue, 21 Jul 2009 10:54:06 -0700
Subject: [c-nsp] OSPF NSSA question
Message-ID: <000001ca0a2c$3eacef00$bc06cd00$@com>

Hello,

I have a question.  I have recently setup a second OSPF area.  The ABR has
three routers connected to it (area 1) in a hub and spoke configuration.
The routers get a default route to the ABR via default information
originate.  Now the ABR has all the N2 routes for the three routers.  But so
do all three routers, which isn't needed.  They only have one interface and
a default route.  Is there a way I can ignore all routes in the area except
the default route coming from the ABR? 



From rwest at zyedge.com  Tue Jul 21 14:48:24 2009
From: rwest at zyedge.com (Ryan West)
Date: Tue, 21 Jul 2009 14:48:24 -0400
Subject: [c-nsp] NAT and PAT on ASA
In-Reply-To: <B5CFB919B5EEF345969F51FAFE6360D50ADC90@GBLDCXMB10.emea.cbre.net>
References: <B5CFB919B5EEF345969F51FAFE6360D50ADC90@GBLDCXMB10.emea.cbre.net>
Message-ID: <6E21B2BDEF6E714EA0B5BA8D5D0E1401248380AF40@zy-ex1.zyedge.local>

static (inside,outside) 58.66.76.88 192.168.0.100
show run access-group
take note of the acl to the outside interface, ACLs are on the ASA are inbound.
access-list <myaccesslist> ext permit icmp any host 58.66.76.88 echo
access-list <myaccesslist> ext permit tcp any host 58.66.76.88 eq www

-ryan

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Oddiraju, Kiran @ London SMC
Sent: Tuesday, July 21, 2009 2:09 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] NAT and PAT on ASA

Guys,

 

I am new to the ASA world, I have a bunch of external IP's from the ISP
and I have an inside host that I want to access externally. How do I
translate an inside ip (192.168.0.100) to an outside address
(58.66.76.88) on the ASA? I should be able to ping and www from outside
world to my inside host. Please let me know how to accomplish this.

 

Many thanks,

K


CB Richard Ellis Limited, Registered Office: St Martin's Court, 
10 Paternoster Row, London, EC4M 7HP, registered in England and Wales No. 3536032. 
Regulated by the RICS and an appointed representative of CB Richard Ellis 
Indirect Investment Services Limited which is authorised and regulated by the Financial Services Authority.

This communication is from CB Richard Ellis Limited or one of its 
associated/subsidiary companies. This communication contains information 
which is confidential and may be privileged. If you are not the intended recipient, 
please contact the sender immediately. Any use of its contents is strictly prohibited 
and you must not copy, send or disclose it, or rely on its contents in any way whatsoever. 
Reasonable care has been taken to ensure that this communication 
(and any attachments or hyperlinks contained within it) is free from computer viruses. 
No responsibility is accepted by CB Richard Ellis Limited or its associated/subsidiary 
companies and the recipient should carry out any appropriate virus checks.

_______________________________________________
cisco-nsp mailing list  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  Tue Jul 21 14:49:29 2009
From: walter.keen at RainierConnect.net (Walter Keen)
Date: Tue, 21 Jul 2009 11:49:29 -0700
Subject: [c-nsp] OSPF NSSA question
In-Reply-To: <000001ca0a2c$3eacef00$bc06cd00$@com>
References: <000001ca0a2c$3eacef00$bc06cd00$@com>
Message-ID: <4A660DB9.80003@rainierconnect.net>

Are you sure you want to use NSSA areas instead of totally stubby areas?

http://packetlife.net/blog/2008/jun/24/ospf-area-types/

Ruben Alvarez wrote:
> Hello,
>
> I have a question.  I have recently setup a second OSPF area.  The ABR has
> three routers connected to it (area 1) in a hub and spoke configuration.
> The routers get a default route to the ABR via default information
> originate.  Now the ABR has all the N2 routes for the three routers.  But so
> do all three routers, which isn't needed.  They only have one interface and
> a default route.  Is there a way I can ignore all routes in the area except
> the default route coming from the ABR? 
>
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>   

-- 


Walter Keen
Network Technician
Rainier Connect
(o) 360-832-4024
(c) 253-302-0194


From blahu77 at gmail.com  Tue Jul 21 15:34:19 2009
From: blahu77 at gmail.com (Mateusz Blaszczyk)
Date: Tue, 21 Jul 2009 20:34:19 +0100
Subject: [c-nsp] OSPF NSSA question
In-Reply-To: <000001ca0a2c$3eacef00$bc06cd00$@com>
References: <000001ca0a2c$3eacef00$bc06cd00$@com>
Message-ID: <383357750907211234m147cf35ak8689bed0759acab7@mail.gmail.com>

Ruben,

All routers in an OSPF area have to have the same OSPF topology database.
So unless you put each router in its own area there is no really a
good way around it.

Best Regards,

-mat

2009/7/21 Ruben Alvarez <raa at opusnet.com>:
> Hello,
>
> I have a question. ?I have recently setup a second OSPF area. ?The ABR has
> three routers connected to it (area 1) in a hub and spoke configuration.
> The routers get a default route to the ABR via default information
> originate. ?Now the ABR has all the N2 routes for the three routers. ?But so
> do all three routers, which isn't needed. ?They only have one interface and
> a default route. ?Is there a way I can ignore all routes in the area except
> the default route coming from the ABR?
>
>
> _______________________________________________
> cisco-nsp mailing list ?cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From j4bles at gmail.com  Tue Jul 21 15:36:28 2009
From: j4bles at gmail.com (jack b)
Date: Tue, 21 Jul 2009 12:36:28 -0700
Subject: [c-nsp] going from collapsed core to separate core/distribution
	layers
Message-ID: <622e99f30907211236r4613d243i1ed086d1882ad4cb@mail.gmail.com>

We currently have two 6509's with Sup720-3BXL's setup in a collapsed core.
Each of the 6509's has two 10gig uplinks to our primary providers as well as
a few 1gig links to secondary providers. Off of the 6509's we have access
switches with 300+ internet facing servers and are currently doing 3-4gbps
out of this site. We are looking to break the collapsed core into a separate
core and distribution layer leaving the 6509's in the distribution layer and
getting a new platform for the core where we would move our transit
providers.

I have seen a lot of talk about the ASR1K and was looking into that as an
option but thought I would ask the list to see if anyone had any other
suggestions.

From sethm at rollernet.us  Tue Jul 21 16:02:45 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Tue, 21 Jul 2009 13:02:45 -0700
Subject: [c-nsp] going from collapsed core to separate core/distribution
 layers
In-Reply-To: <622e99f30907211236r4613d243i1ed086d1882ad4cb@mail.gmail.com>
References: <622e99f30907211236r4613d243i1ed086d1882ad4cb@mail.gmail.com>
Message-ID: <4A661EE5.9000801@rollernet.us>

jack b wrote:
> We currently have two 6509's with Sup720-3BXL's setup in a collapsed core.
> Each of the 6509's has two 10gig uplinks to our primary providers as well as
> a few 1gig links to secondary providers. Off of the 6509's we have access
> switches with 300+ internet facing servers and are currently doing 3-4gbps
> out of this site. We are looking to break the collapsed core into a separate
> core and distribution layer leaving the 6509's in the distribution layer and
> getting a new platform for the core where we would move our transit
> providers.
> 
> I have seen a lot of talk about the ASR1K and was looking into that as an
> option but thought I would ask the list to see if anyone had any other
> suggestions.

If you're looking at 10 gig I'd say the ASR1000 is your best bet.

~Seth

From dan at beanfield.com  Tue Jul 21 15:07:01 2009
From: dan at beanfield.com (Dan Armstrong)
Date: Tue, 21 Jul 2009 15:07:01 -0400
Subject: [c-nsp] OSPF NSSA question
In-Reply-To: <4A660DB9.80003@rainierconnect.net>
References: <000001ca0a2c$3eacef00$bc06cd00$@com>
	<4A660DB9.80003@rainierconnect.net>
Message-ID: <599363BF-E2A7-45BB-973C-5272D818A8D1@beanfield.com>

But then, I believe, you cannot redistribute C and S routes from  
inside the are out, that's why NSSA Exist.

What we need is a totally stubby not so stubby area, no?




On 21-Jul-09, at 2:49 PM, Walter Keen wrote:

> Are you sure you want to use NSSA areas instead of totally stubby  
> areas?
>
> http://packetlife.net/blog/2008/jun/24/ospf-area-types/
>
> Ruben Alvarez wrote:
>> Hello,
>>
>> I have a question.  I have recently setup a second OSPF area.  The  
>> ABR has
>> three routers connected to it (area 1) in a hub and spoke  
>> configuration.
>> The routers get a default route to the ABR via default information
>> originate.  Now the ABR has all the N2 routes for the three  
>> routers.  But so
>> do all three routers, which isn't needed.  They only have one  
>> interface and
>> a default route.  Is there a way I can ignore all routes in the  
>> area except
>> the default route coming from the ABR?
>>
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>
> -- 
>
>
> Walter Keen
> Network Technician
> Rainier Connect
> (o) 360-832-4024
> (c) 253-302-0194
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


From raa at opusnet.com  Tue Jul 21 16:36:47 2009
From: raa at opusnet.com (Ruben Alvarez)
Date: Tue, 21 Jul 2009 13:36:47 -0700
Subject: [c-nsp] OSPF NSSA question
In-Reply-To: <383357750907211234m147cf35ak8689bed0759acab7@mail.gmail.com>
References: <000001ca0a2c$3eacef00$bc06cd00$@com>
	<383357750907211234m147cf35ak8689bed0759acab7@mail.gmail.com>
Message-ID: <000101ca0a42$f8f0f260$ead2d720$@com>

Ok thanks.  that answers my question.  It's not a big deal, I just was wondering.

As for the one who suggested totally stubby or stub, I understood a stub area can only have one OSPF router.

-----Original Message-----
From: Mateusz Blaszczyk [mailto:blahu77 at gmail.com] 
Sent: Tuesday, July 21, 2009 12:34 PM
To: Ruben Alvarez
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] OSPF NSSA question

Ruben,

All routers in an OSPF area have to have the same OSPF topology database.
So unless you put each router in its own area there is no really a
good way around it.

Best Regards,

-mat

2009/7/21 Ruben Alvarez <raa at opusnet.com>:
> Hello,
>
> I have a question.  I have recently setup a second OSPF area.  The ABR has
> three routers connected to it (area 1) in a hub and spoke configuration.
> The routers get a default route to the ABR via default information
> originate.  Now the ABR has all the N2 routes for the three routers.  But so
> do all three routers, which isn't needed.  They only have one interface and
> a default route.  Is there a way I can ignore all routes in the area except
> the default route coming from the ABR?
>
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>


From dudepron at gmail.com  Tue Jul 21 17:07:16 2009
From: dudepron at gmail.com (Aaron)
Date: Tue, 21 Jul 2009 17:07:16 -0400
Subject: [c-nsp] GSR 12008 GRP ISSUES
In-Reply-To: <2e1cd850907211134t76ad2950u991688ac7d2cc921@mail.gmail.com>
References: <2e1cd850907211134t76ad2950u991688ac7d2cc921@mail.gmail.com>
Message-ID: <480dad640907211407i6bf3f3e7k7e4199322a8fca64@mail.gmail.com>

Looks like a fabric problem.


On Tue, Jul 21, 2009 at 14:34, Chris Lane <clane1875 at gmail.com> wrote:

> All,
> I have a GSR 12008 with 2 GRP-B route processors. Running
> gsr-k4p-mz.120-32.S11.bin
>
> My GRP failed over about 45 minutes ago to the backup in Slot1 from Slot0.
> I keep getting this in my logs.
> SEC  0:00:00:06: %MBUS-6-FIA_CONFIG: Switch Cards 0x1F (bit mask); Primary
> Clock CSC_1
> SEC  0:00:00:07: %FIA-3-HALT: To Fabric
> SEC  0:00:00:07: %FIA-3-PARITYERR: To Fabric parity error was detected.
> Request parity error interrupt = 0x4.
> SEC  0:00:00:07: %FIA-3-HALT: To Fabric
> SEC  0:00:00:07: %FIA-3-HALT: To Fabric
> SEC  0:00:00:07: %RP-3-FABRIC_UNI: Unicast send timed out  (1)
> SEC  0:00:00:13: %RP-3-FABRIC_UNI: Unicast send timed out  (1)
> SEC  0:00:00:23: %RP-3-FABRIC_UNI: Unicast send timed out  (1)
> SEC  0:00:00:37: %IPC-5-REGPORTFAIL: Registering Control Port Id=0x1000003
> timeout=0x6
> -Traceback= 501F6650 505A3B90 505A3F4C 505A40D8 5059FCCC 502A02D8 502A02C4
> SEC  0:00:00:44: %RP-3-FABRIC_UNI: Unicast send timed out  (1)
> SEC  0:00:01:08: %IPC-5-REGPORTFAIL: Registering Control Port Id=0x1000003
> timeout=0x6
> -Traceback= 501F6650 505A3B90 505A3BD8 502A02D8 502A02C4
> SEC  0:00:01:15: %RP-3-FABRIC_UNI: Unicast send timed out  (1)
> SEC  0:00:01:39: %IPC-5-REGPORTFAIL: Registering Control Port Id=0x1000003
> timeout=0x6
> -Traceback= 501F6650 505A3B90 505A3BD8 502A02D8 502A02C4
> SEC  0:00:01:56: %RP-3-FABRIC_UNI: Unicast send timed out  (1)
> SEC  0:00:02:10: %IPC-5-REGPORTFAIL: Registering Control Port Id=0x1000003
> timeout=0x6
> -Traceback= 501F6650 505A3B90 505A3BD8 502A02D8 502A02C4
> SEC  0:00:02:41: %IPC-5-REGPORTFAIL: Registering Control Port Id=0x1000003
> timeout=0x6
> -Traceback= 501F6650 505A3B90 505A3BD8 502A02D8 502A02C4
> SEC  0:00:02:48: %RP-3-FABRIC_UNI: Unicast send timed out  (1)
> SEC  0:00:03:12: %IPC-5-REGPORTFAIL: Registering Control Port Id=0x1000003
> timeout=0x6
> -Traceback= 501F6650 505A3B90 505A3BD8 502A02D8 502A02C4
> SEC  0:00:03:43: %IPC-5-REGPORTFAIL: Registering Control Port Id=0x1000003
> timeout=0x6
> -Traceback= 501F6650 505A3B90 505A3BD8 502A02D8 502A02C4
> SEC  0:00:03:50: %RP-3-FABRIC_UNI: Unicast send timed out  (1)
> SEC  0:00:04:14: %IPC-5-REGPORTFAIL: Registering Control Port Id=0x1000003
> timeout=0x6
> -Traceback= 501F6650 505A3B90 505A3BD8 502A02D8 502A02C4
> SEC  0:00:04:45: %IPC-5-REGPORTFAIL: Registering Control Port Id=0x1000003
> timeout=0x6
> -Traceback= 501F6650 505A3B90 505A3BD8 502A02D8 502A02C4
> SEC  0:00:05:02: %RP-3-FABRIC_UNI: Unicast send timed out  (1)
> Jul 21 12:27:01.258 EDT: %RP-3-ERROR: Timed out while initializing IPC to
> standby RP in slot 0
> Jul 21 12:28:02.070 EDT: %MBUS-6-DEADSCDY: Standby RP in slot 0 timed out,
> reset
>
>
> Is this because SLOT0 is hung, trying to become primary again yet not
> communicating with SLOT1 the active RP?
> SLOT 0  (RP/LC 0 ): Route Processor
>  MAIN: type 19,  800-2427-03 rev F0
>        Deviation:  D070866
>        HW config: 0x00    SW key: 00-00-00
>  PCA:  73-2170-08 rev E0 ver 5
>        Design Release 1.5  S/N SAD0745027R
>  MBUS: MBUS Agent (1)  73-2146-07 rev B0 dev 0
>        HW version 1.2  S/N CAT073504X3
>        Test hist: 0x00    RMA#: 00-00-00    RMA hist: 0x00
>  DIAG: Test count: 0x00000000    Test results: 0x00000000
>  FRU:  Linecard/Module: GRP-B=
>        Route Memory: MEM-GRP-512=
>  MBUS Agent Software version 2.68 (RAM) (ROM version is 3.47)
>  ROM Monitor version 2.2
>  Primary clock is CSC 1
>  Board State is Route Processor Powered ( RP  RDY )    ********* SHOULDN'T
> THIS SAY STANDBY (STBY  RP )
>  Insertion time: 42w1d (00:56:55 ago)
>  DRAM size: 536870912 bytes
>
>
> SLOT 1  (RP/LC 1 ): Route Processor
>  MAIN: type 19,  800-2427-03 rev F0
>        Deviation: 0
>        HW config: 0x00    SW key: 00-00-00
>  PCA:  73-2170-08 rev E0 ver 5
>        Design Release 1.5  S/N SAD072000C3
>  MBUS: MBUS Agent (1)  73-2146-07 rev B0 dev 0
>        HW version 1.2  S/N CAT07100SFN
>        Test hist: 0x00    RMA#: 00-00-00    RMA hist: 0x00
>  DIAG: Test count: 0x00000000    Test results: 0x00000000
>  FRU:  Linecard/Module: GRP-B=
>        Route Memory: MEM-GRP-512=
>  MBUS Agent Software version 2.68 (RAM) (ROM version is 3.47)
>  ROM Monitor version 2.2
>  Primary clock is CSC 1
>  Board State is IOS Running  ACTIVE (ACTV  RP )
>  Insertion time: 42w1d (00:56:55 ago)
>  DRAM size: 536870912 bytes
>
>
>
> Any help, suggestions greatly appreciated
>
> Chris
>
> --
> //CL
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From clane1875 at gmail.com  Tue Jul 21 17:12:46 2009
From: clane1875 at gmail.com (Chris Lane)
Date: Tue, 21 Jul 2009 17:12:46 -0400
Subject: [c-nsp] GSR 12008 GRP ISSUES
In-Reply-To: <480dad640907211407i6bf3f3e7k7e4199322a8fca64@mail.gmail.com>
References: <2e1cd850907211134t76ad2950u991688ac7d2cc921@mail.gmail.com>
	<480dad640907211407i6bf3f3e7k7e4199322a8fca64@mail.gmail.com>
Message-ID: <2e1cd850907211412y3ae80581yde7861bf139831df@mail.gmail.com>

Slot0 we think has a defective GRP, we removed and errors are gone. I have a
new GRP being shipped for tomorrow.
Thanks

On Tue, Jul 21, 2009 at 5:07 PM, Aaron <dudepron at gmail.com> wrote:

> Looks like a fabric problem.
>
>
> On Tue, Jul 21, 2009 at 14:34, Chris Lane <clane1875 at gmail.com> wrote:
>
>> All,
>> I have a GSR 12008 with 2 GRP-B route processors. Running
>> gsr-k4p-mz.120-32.S11.bin
>>
>> My GRP failed over about 45 minutes ago to the backup in Slot1 from Slot0.
>> I keep getting this in my logs.
>> SEC  0:00:00:06: %MBUS-6-FIA_CONFIG: Switch Cards 0x1F (bit mask); Primary
>> Clock CSC_1
>> SEC  0:00:00:07: %FIA-3-HALT: To Fabric
>> SEC  0:00:00:07: %FIA-3-PARITYERR: To Fabric parity error was detected.
>> Request parity error interrupt = 0x4.
>> SEC  0:00:00:07: %FIA-3-HALT: To Fabric
>> SEC  0:00:00:07: %FIA-3-HALT: To Fabric
>> SEC  0:00:00:07: %RP-3-FABRIC_UNI: Unicast send timed out  (1)
>> SEC  0:00:00:13: %RP-3-FABRIC_UNI: Unicast send timed out  (1)
>> SEC  0:00:00:23: %RP-3-FABRIC_UNI: Unicast send timed out  (1)
>> SEC  0:00:00:37: %IPC-5-REGPORTFAIL: Registering Control Port Id=0x1000003
>> timeout=0x6
>> -Traceback= 501F6650 505A3B90 505A3F4C 505A40D8 5059FCCC 502A02D8 502A02C4
>> SEC  0:00:00:44: %RP-3-FABRIC_UNI: Unicast send timed out  (1)
>> SEC  0:00:01:08: %IPC-5-REGPORTFAIL: Registering Control Port Id=0x1000003
>> timeout=0x6
>> -Traceback= 501F6650 505A3B90 505A3BD8 502A02D8 502A02C4
>> SEC  0:00:01:15: %RP-3-FABRIC_UNI: Unicast send timed out  (1)
>> SEC  0:00:01:39: %IPC-5-REGPORTFAIL: Registering Control Port Id=0x1000003
>> timeout=0x6
>> -Traceback= 501F6650 505A3B90 505A3BD8 502A02D8 502A02C4
>> SEC  0:00:01:56: %RP-3-FABRIC_UNI: Unicast send timed out  (1)
>> SEC  0:00:02:10: %IPC-5-REGPORTFAIL: Registering Control Port Id=0x1000003
>> timeout=0x6
>> -Traceback= 501F6650 505A3B90 505A3BD8 502A02D8 502A02C4
>> SEC  0:00:02:41: %IPC-5-REGPORTFAIL: Registering Control Port Id=0x1000003
>> timeout=0x6
>> -Traceback= 501F6650 505A3B90 505A3BD8 502A02D8 502A02C4
>> SEC  0:00:02:48: %RP-3-FABRIC_UNI: Unicast send timed out  (1)
>> SEC  0:00:03:12: %IPC-5-REGPORTFAIL: Registering Control Port Id=0x1000003
>> timeout=0x6
>> -Traceback= 501F6650 505A3B90 505A3BD8 502A02D8 502A02C4
>> SEC  0:00:03:43: %IPC-5-REGPORTFAIL: Registering Control Port Id=0x1000003
>> timeout=0x6
>> -Traceback= 501F6650 505A3B90 505A3BD8 502A02D8 502A02C4
>> SEC  0:00:03:50: %RP-3-FABRIC_UNI: Unicast send timed out  (1)
>> SEC  0:00:04:14: %IPC-5-REGPORTFAIL: Registering Control Port Id=0x1000003
>> timeout=0x6
>> -Traceback= 501F6650 505A3B90 505A3BD8 502A02D8 502A02C4
>> SEC  0:00:04:45: %IPC-5-REGPORTFAIL: Registering Control Port Id=0x1000003
>> timeout=0x6
>> -Traceback= 501F6650 505A3B90 505A3BD8 502A02D8 502A02C4
>> SEC  0:00:05:02: %RP-3-FABRIC_UNI: Unicast send timed out  (1)
>> Jul 21 12:27:01.258 EDT: %RP-3-ERROR: Timed out while initializing IPC to
>> standby RP in slot 0
>> Jul 21 12:28:02.070 EDT: %MBUS-6-DEADSCDY: Standby RP in slot 0 timed out,
>> reset
>>
>>
>> Is this because SLOT0 is hung, trying to become primary again yet not
>> communicating with SLOT1 the active RP?
>> SLOT 0  (RP/LC 0 ): Route Processor
>>  MAIN: type 19,  800-2427-03 rev F0
>>        Deviation:  D070866
>>        HW config: 0x00    SW key: 00-00-00
>>  PCA:  73-2170-08 rev E0 ver 5
>>        Design Release 1.5  S/N SAD0745027R
>>  MBUS: MBUS Agent (1)  73-2146-07 rev B0 dev 0
>>        HW version 1.2  S/N CAT073504X3
>>        Test hist: 0x00    RMA#: 00-00-00    RMA hist: 0x00
>>  DIAG: Test count: 0x00000000    Test results: 0x00000000
>>  FRU:  Linecard/Module: GRP-B=
>>        Route Memory: MEM-GRP-512=
>>  MBUS Agent Software version 2.68 (RAM) (ROM version is 3.47)
>>  ROM Monitor version 2.2
>>  Primary clock is CSC 1
>>  Board State is Route Processor Powered ( RP  RDY )    ********* SHOULDN'T
>> THIS SAY STANDBY (STBY  RP )
>>  Insertion time: 42w1d (00:56:55 ago)
>>  DRAM size: 536870912 bytes
>>
>>
>> SLOT 1  (RP/LC 1 ): Route Processor
>>  MAIN: type 19,  800-2427-03 rev F0
>>        Deviation: 0
>>        HW config: 0x00    SW key: 00-00-00
>>  PCA:  73-2170-08 rev E0 ver 5
>>        Design Release 1.5  S/N SAD072000C3
>>  MBUS: MBUS Agent (1)  73-2146-07 rev B0 dev 0
>>        HW version 1.2  S/N CAT07100SFN
>>        Test hist: 0x00    RMA#: 00-00-00    RMA hist: 0x00
>>  DIAG: Test count: 0x00000000    Test results: 0x00000000
>>  FRU:  Linecard/Module: GRP-B=
>>        Route Memory: MEM-GRP-512=
>>  MBUS Agent Software version 2.68 (RAM) (ROM version is 3.47)
>>  ROM Monitor version 2.2
>>  Primary clock is CSC 1
>>  Board State is IOS Running  ACTIVE (ACTV  RP )
>>  Insertion time: 42w1d (00:56:55 ago)
>>  DRAM size: 536870912 bytes
>>
>>
>>
>> Any help, suggestions greatly appreciated
>>
>> Chris
>>
>> --
>> //CL
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>
>


-- 
//CL

From clinton at scripty.com  Tue Jul 21 17:33:19 2009
From: clinton at scripty.com (Clinton Work)
Date: Tue, 21 Jul 2009 15:33:19 -0600
Subject: [c-nsp] Maximum spannig tree instances
In-Reply-To: <200907180455.n6I4tmr8016738@sj-core-2.cisco.com>
References: <9DE4AA6876D44B62B87C475B2AFE5514@au.didata.local>	<a1873f1f0907131438m3f0b4c70r82a953a29042b6d7@mail.gmail.com>	<1247524340.4661.65.camel@abehat.net.rm.dk>	<20090714084503.GA15753@lboro.ac.uk>	<d6966e4b0907140621s504dea4aq120b1f2440f76f1d@mail.gmail.com>	<6B43981C32F8464CB24CEE209DA32BD302350ADD@kenya.tronet.as>	<8e157ab40907162051t4d32d6cbudc1dacca82790ed1@mail.gmail.com>
	<200907180455.n6I4tmr8016738@sj-core-2.cisco.com>
Message-ID: <4A66341F.3020400@scripty.com>


The Cisco 7600/sup720 12.2SR releases only supports the original 50K/10K 
limit in 12.2SXF. 

I have 6500/sup720 and 7600/sup720 running much higher virtual-port 
loads under 12.2SXF using MST.  I tried to get the BUs to re-test the 
STP capacity limits via our account team, but there wasn't a lot of 
interest. The 7600 BU may decide to add the 12.2SXI STP scalability 
enhancements to a 12.2SR release at a later date. 

show vlan virtual-port

Slot 1
-------
Total slot virtual ports 7482

Slot 2
-------
Total slot virtual ports 5418

Slot 3
-------
Total slot virtual ports 8260

Slot 4
-------
Total slot virtual ports 16526

Slot 5
-------
Total slot virtual ports 1

Slot 7
-------
Total slot virtual ports 22704

Slot 8
-------
Total slot virtual ports 10320

Slot 9
-------
Total slot virtual ports 6201

Total chassis virtual ports 76912



Tim Stevenson wrote:
> Hi Matt,
>
> The 6500/sup720 on 33SXI supports 100K logical ports in MST, and 12K 
> in RPVST. That's up from 50K/10K in every prior release.
>
> N7K supports 75K in MST & 16K in RPVST today. There are no per-module 
> limitations on N7K.
>
> Those numbers are based on the requirements we expressed to QA/system 
> test prior to FCS. The original numbers were confirmed prior to 33SXI 
> was released. Since then, we have not had a customer 
> requirement/request to support more, so frankly we have not felt 
> compelled to go and requalifify for anything greater. Would be curious 
> to know how many logical ports you are running today & in what protocol?
>
> Thanks,
> Tim


From tvarriale at comcast.net  Tue Jul 21 22:42:28 2009
From: tvarriale at comcast.net (Tony Varriale)
Date: Tue, 21 Jul 2009 21:42:28 -0500
Subject: [c-nsp] NAT and PAT on ASA
References: <B5CFB919B5EEF345969F51FAFE6360D50ADC90@GBLDCXMB10.emea.cbre.net>
	<6E21B2BDEF6E714EA0B5BA8D5D0E1401248380AF40@zy-ex1.zyedge.local>
Message-ID: <3841B0226AC74CADA928D92BA02C7860@flamdt01>

Ryan,

I would recommend completing your static with the appropriate netmask.

Also, ACLs can be applied in and out on an interface on ASA and PIX since 
7.0.

tv
----- Original Message ----- 
From: "Ryan West" <rwest at zyedge.com>
To: "Oddiraju, Kiran @ London SMC" <Kiran.Oddiraju at cbre.com>; 
<cisco-nsp at puck.nether.net>
Sent: Tuesday, July 21, 2009 1:48 PM
Subject: Re: [c-nsp] NAT and PAT on ASA


> static (inside,outside) 58.66.76.88 192.168.0.100
> show run access-group
> take note of the acl to the outside interface, ACLs are on the ASA are 
> inbound.
> access-list <myaccesslist> ext permit icmp any host 58.66.76.88 echo
> access-list <myaccesslist> ext permit tcp any host 58.66.76.88 eq www
>
> -ryan
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net 
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Oddiraju, Kiran @ 
> London SMC
> Sent: Tuesday, July 21, 2009 2:09 PM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] NAT and PAT on ASA
>
> Guys,
>
>
>
> I am new to the ASA world, I have a bunch of external IP's from the ISP
> and I have an inside host that I want to access externally. How do I
> translate an inside ip (192.168.0.100) to an outside address
> (58.66.76.88) on the ASA? I should be able to ping and www from outside
> world to my inside host. Please let me know how to accomplish this.
>
>
>
> Many thanks,
>
> K
>
>
> CB Richard Ellis Limited, Registered Office: St Martin's Court,
> 10 Paternoster Row, London, EC4M 7HP, registered in England and Wales No. 
> 3536032.
> Regulated by the RICS and an appointed representative of CB Richard Ellis
> Indirect Investment Services Limited which is authorised and regulated by 
> the Financial Services Authority.
>
> This communication is from CB Richard Ellis Limited or one of its
> associated/subsidiary companies. This communication contains information
> which is confidential and may be privileged. If you are not the intended 
> recipient,
> please contact the sender immediately. Any use of its contents is strictly 
> prohibited
> and you must not copy, send or disclose it, or rely on its contents in any 
> way whatsoever.
> Reasonable care has been taken to ensure that this communication
> (and any attachments or hyperlinks contained within it) is free from 
> computer viruses.
> No responsibility is accepted by CB Richard Ellis Limited or its 
> associated/subsidiary
> companies and the recipient should carry out any appropriate virus checks.
>
> _______________________________________________
> cisco-nsp mailing 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 binh.l.phan at gmail.com  Wed Jul 22 00:10:25 2009
From: binh.l.phan at gmail.com (Binh Phan)
Date: Tue, 21 Jul 2009 21:10:25 -0700
Subject: [c-nsp] NAT and PAT on ASA
In-Reply-To: <3841B0226AC74CADA928D92BA02C7860@flamdt01>
References: <B5CFB919B5EEF345969F51FAFE6360D50ADC90@GBLDCXMB10.emea.cbre.net>
	<6E21B2BDEF6E714EA0B5BA8D5D0E1401248380AF40@zy-ex1.zyedge.local>
	<3841B0226AC74CADA928D92BA02C7860@flamdt01>
Message-ID: <7CFD3224-7B54-4978-AA5C-1C745B98E6F7@gmail.com>


On Jul 21, 2009, at 7:42 PM, Tony Varriale wrote:

> I would recommend completing your static with the appropriate netmask.
 >>You do not need to specify netmask in this case since it's a /32  
and will be auto-completed when you enter the command in CLI.


From tvarriale at comcast.net  Wed Jul 22 00:18:51 2009
From: tvarriale at comcast.net (Tony Varriale)
Date: Tue, 21 Jul 2009 23:18:51 -0500
Subject: [c-nsp] NAT and PAT on ASA
References: <B5CFB919B5EEF345969F51FAFE6360D50ADC90@GBLDCXMB10.emea.cbre.net>
	<6E21B2BDEF6E714EA0B5BA8D5D0E1401248380AF40@zy-ex1.zyedge.local>
	<3841B0226AC74CADA928D92BA02C7860@flamdt01>
	<7CFD3224-7B54-4978-AA5C-1C745B98E6F7@gmail.com>
Message-ID: <4A5876385A1F47DC99764359DF44E94F@flamdt01>

If you haven't been around Cisco long enough to know not to assume, then be 
my guest.

But, that's poor advice to offer a person that is somewhat new (or new) to 
Cisco.  That's how bad habits start.

tv
----- Original Message ----- 
From: "Binh Phan" <binh.l.phan at gmail.com>
To: "Tony Varriale" <tvarriale at comcast.net>
Cc: <cisco-nsp at puck.nether.net>
Sent: Tuesday, July 21, 2009 11:10 PM
Subject: Re: [c-nsp] NAT and PAT on ASA


>
> On Jul 21, 2009, at 7:42 PM, Tony Varriale wrote:
>
>> I would recommend completing your static with the appropriate netmask.
> >>You do not need to specify netmask in this case since it's a /32
> and will be auto-completed when you enter the command in CLI.
> 


From ip at ioshints.info  Wed Jul 22 00:24:16 2009
From: ip at ioshints.info (Ivan Pepelnjak)
Date: Wed, 22 Jul 2009 06:24:16 +0200
Subject: [c-nsp] OSPF NSSA question
In-Reply-To: <000101ca0a42$f8f0f260$ead2d720$@com>
References: <000001ca0a2c$3eacef00$bc06cd00$@com><383357750907211234m147cf35ak8689bed0759acab7@mail.gmail.com>
	<000101ca0a42$f8f0f260$ead2d720$@com>
Message-ID: <002101ca0a84$47c00d90$0a00000a@nil.si>

You're probably looking for the "ip ospf database-filter all out" command.

And there can be more than one router in the OSPF stub area.

Ivan
 
http://www.ioshints.info/about
http://blog.ioshints.info/

> Ok thanks.  that answers my question.  It's not a big deal, I 
> just was wondering.
> 
> As for the one who suggested totally stubby or stub, I 
> understood a stub area can only have one OSPF router.
> 
> -----Original Message-----
> From: Mateusz Blaszczyk [mailto:blahu77 at gmail.com]
> Sent: Tuesday, July 21, 2009 12:34 PM
> To: Ruben Alvarez
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] OSPF NSSA question
> 
> Ruben,
> 
> All routers in an OSPF area have to have the same OSPF 
> topology database.
> So unless you put each router in its own area there is no 
> really a good way around it.
> 
> Best Regards,
> 
> -mat
> 
> 2009/7/21 Ruben Alvarez <raa at opusnet.com>:
> > Hello,
> >
> > I have a question.  I have recently setup a second OSPF 
> area.  The ABR 
> > has three routers connected to it (area 1) in a hub and 
> spoke configuration.
> > The routers get a default route to the ABR via default information 
> > originate.  Now the ABR has all the N2 routes for the three 
> routers.  
> > But so do all three routers, which isn't needed.  They only 
> have one 
> > interface and a default route.  Is there a way I can ignore 
> all routes 
> > in the area except the default route coming from the ABR?
> >
> >
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net 
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> >
> 
> 
> 


From binh.l.phan at gmail.com  Wed Jul 22 00:26:43 2009
From: binh.l.phan at gmail.com (Binh Phan)
Date: Tue, 21 Jul 2009 21:26:43 -0700
Subject: [c-nsp] NAT and PAT on ASA
In-Reply-To: <4A5876385A1F47DC99764359DF44E94F@flamdt01>
References: <B5CFB919B5EEF345969F51FAFE6360D50ADC90@GBLDCXMB10.emea.cbre.net>
	<6E21B2BDEF6E714EA0B5BA8D5D0E1401248380AF40@zy-ex1.zyedge.local>
	<3841B0226AC74CADA928D92BA02C7860@flamdt01>
	<7CFD3224-7B54-4978-AA5C-1C745B98E6F7@gmail.com>
	<4A5876385A1F47DC99764359DF44E94F@flamdt01>
Message-ID: <4FCEBB7F-9732-4CB4-B52F-A8C5022F809E@gmail.com>

Wow! Arrogance at its best ;-)
Sure been around Cisco long enough and infact been _IN_ Cisco long  
enough..
but I simply wanted to point out the fact that it was uneccessary what  
you pointed out. No offense!!
On Jul 21, 2009, at 9:18 PM, Tony Varriale wrote:

> If you haven't been around Cisco long enough to know not to assume,  
> then be my guest.
>
> But, that's poor advice to offer a person that is somewhat new (or  
> new) to Cisco.  That's how bad habits start.
>
> tv
> ----- Original Message ----- From: "Binh Phan" <binh.l.phan at gmail.com>
> To: "Tony Varriale" <tvarriale at comcast.net>
> Cc: <cisco-nsp at puck.nether.net>
> Sent: Tuesday, July 21, 2009 11:10 PM
> Subject: Re: [c-nsp] NAT and PAT on ASA
>
>
>>
>> On Jul 21, 2009, at 7:42 PM, Tony Varriale wrote:
>>
>>> I would recommend completing your static with the appropriate  
>>> netmask.
>> >>You do not need to specify netmask in this case since it's a /32
>> and will be auto-completed when you enter the command in CLI.
>
> _______________________________________________
> cisco-nsp mailing list  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  Wed Jul 22 00:37:57 2009
From: tvarriale at comcast.net (Tony Varriale)
Date: Tue, 21 Jul 2009 23:37:57 -0500
Subject: [c-nsp] NAT and PAT on ASA
References: <B5CFB919B5EEF345969F51FAFE6360D50ADC90@GBLDCXMB10.emea.cbre.net>
	<6E21B2BDEF6E714EA0B5BA8D5D0E1401248380AF40@zy-ex1.zyedge.local>
	<3841B0226AC74CADA928D92BA02C7860@flamdt01>
	<7CFD3224-7B54-4978-AA5C-1C745B98E6F7@gmail.com>
	<4A5876385A1F47DC99764359DF44E94F@flamdt01>
	<4FCEBB7F-9732-4CB4-B52F-A8C5022F809E@gmail.com>
Message-ID: <70A27A38279041758C3D86C520880ABE@flamdt01>

You pointed out, to me, on how to complete a command.  I don't need 
assistance with that.

I pointed out that it is best to offer people that are newer to Cisco and/or 
a specific platform best practices (for many reasons).

Here's an example from my home ASA on why best practices...are best 
practices:

homepix(config)# static (inside,outside) 58.66.76.88 192.168.0.100
homepix(config)# sh run static
static (inside,outside) 58.66.76.88 192.168.0.100 netmask 255.255.255.255
homepix(config)# static (inside,outside) 172.16.0.0 172.16.0.0
homepix(config)# sh run static
static (inside,outside) 58.66.76.88 192.168.0.100 netmask 255.255.255.255
static (inside,outside) 172.16.0.0 172.16.0.0 netmask 255.255.0.0

If you think that's arrogance, that's your opinion.

tv
----- Original Message ----- 
From: "Binh Phan" <binh.l.phan at gmail.com>
To: "Tony Varriale" <tvarriale at comcast.net>
Cc: <cisco-nsp at puck.nether.net>
Sent: Tuesday, July 21, 2009 11:26 PM
Subject: Re: [c-nsp] NAT and PAT on ASA


> Wow! Arrogance at its best ;-)
> Sure been around Cisco long enough and infact been _IN_ Cisco long 
> enough..
> but I simply wanted to point out the fact that it was uneccessary what 
> you pointed out. No offense!!
> On Jul 21, 2009, at 9:18 PM, Tony Varriale wrote:
>
>> If you haven't been around Cisco long enough to know not to assume,  then 
>> be my guest.
>>
>> But, that's poor advice to offer a person that is somewhat new (or  new) 
>> to Cisco.  That's how bad habits start.
>>
>> tv
>> ----- Original Message ----- From: "Binh Phan" <binh.l.phan at gmail.com>
>> To: "Tony Varriale" <tvarriale at comcast.net>
>> Cc: <cisco-nsp at puck.nether.net>
>> Sent: Tuesday, July 21, 2009 11:10 PM
>> Subject: Re: [c-nsp] NAT and PAT on ASA
>>
>>
>>>
>>> On Jul 21, 2009, at 7:42 PM, Tony Varriale wrote:
>>>
>>>> I would recommend completing your static with the appropriate  netmask.
>>> >>You do not need to specify netmask in this case since it's a /32
>>> and will be auto-completed when you enter the command in CLI.
>>
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 


From binh.l.phan at gmail.com  Wed Jul 22 00:49:04 2009
From: binh.l.phan at gmail.com (Binh Phan)
Date: Tue, 21 Jul 2009 21:49:04 -0700
Subject: [c-nsp] NAT and PAT on ASA
In-Reply-To: <70A27A38279041758C3D86C520880ABE@flamdt01>
References: <B5CFB919B5EEF345969F51FAFE6360D50ADC90@GBLDCXMB10.emea.cbre.net>
	<6E21B2BDEF6E714EA0B5BA8D5D0E1401248380AF40@zy-ex1.zyedge.local>
	<3841B0226AC74CADA928D92BA02C7860@flamdt01>
	<7CFD3224-7B54-4978-AA5C-1C745B98E6F7@gmail.com>
	<4A5876385A1F47DC99764359DF44E94F@flamdt01>
	<4FCEBB7F-9732-4CB4-B52F-A8C5022F809E@gmail.com>
	<70A27A38279041758C3D86C520880ABE@flamdt01>
Message-ID: <18CD6E42-403E-49B9-9B50-CE4F4D0CA233@gmail.com>

The original user was asking for assistance on what would be the right  
configuration specific to his scenario which was a host static NAT and  
Ryan simply provided that.
I simply saw what you stated was not adding any value to the  
discussion other than what seemed to be fault finding, as adding  
netmask in this case, OR NOT makes absolutely no difference. Maybe I  
read it wrong and if so I apologize.
Agree, best practices are important but it's irrelevant in this  
context or discussion, IMO.
--Binh
On Jul 21, 2009, at 9:37 PM, Tony Varriale wrote:

> You pointed out, to me, on how to complete a command.  I don't need  
> assistance with that.
>
> I pointed out that it is best to offer people that are newer to  
> Cisco and/or a specific platform best practices (for many reasons).
>
> Here's an example from my home ASA on why best practices...are best  
> practices:
>
> homepix(config)# static (inside,outside) 58.66.76.88 192.168.0.100
> homepix(config)# sh run static
> static (inside,outside) 58.66.76.88 192.168.0.100 netmask  
> 255.255.255.255
> homepix(config)# static (inside,outside) 172.16.0.0 172.16.0.0
> homepix(config)# sh run static
> static (inside,outside) 58.66.76.88 192.168.0.100 netmask  
> 255.255.255.255
> static (inside,outside) 172.16.0.0 172.16.0.0 netmask 255.255.0.0
>
> If you think that's arrogance, that's your opinion.
>
> tv
> ----- Original Message ----- From: "Binh Phan" <binh.l.phan at gmail.com>
> To: "Tony Varriale" <tvarriale at comcast.net>
> Cc: <cisco-nsp at puck.nether.net>
> Sent: Tuesday, July 21, 2009 11:26 PM
> Subject: Re: [c-nsp] NAT and PAT on ASA
>
>
>> Wow! Arrogance at its best ;-)
>> Sure been around Cisco long enough and infact been _IN_ Cisco long  
>> enough..
>> but I simply wanted to point out the fact that it was uneccessary  
>> what you pointed out. No offense!!
>> On Jul 21, 2009, at 9:18 PM, Tony Varriale wrote:
>>
>>> If you haven't been around Cisco long enough to know not to  
>>> assume,  then be my guest.
>>>
>>> But, that's poor advice to offer a person that is somewhat new  
>>> (or  new) to Cisco.  That's how bad habits start.
>>>
>>> tv
>>> ----- Original Message ----- From: "Binh Phan" <binh.l.phan at gmail.com 
>>> >
>>> To: "Tony Varriale" <tvarriale at comcast.net>
>>> Cc: <cisco-nsp at puck.nether.net>
>>> Sent: Tuesday, July 21, 2009 11:10 PM
>>> Subject: Re: [c-nsp] NAT and PAT on ASA
>>>
>>>
>>>>
>>>> On Jul 21, 2009, at 7:42 PM, Tony Varriale wrote:
>>>>
>>>>> I would recommend completing your static with the appropriate   
>>>>> netmask.
>>>> >>You do not need to specify netmask in this case since it's a /32
>>>> and will be auto-completed when you enter the command in CLI.
>>>
>>> _______________________________________________
>>> cisco-nsp mailing 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 rwest at zyedge.com  Wed Jul 22 03:52:21 2009
From: rwest at zyedge.com (Ryan West)
Date: Wed, 22 Jul 2009 03:52:21 -0400
Subject: [c-nsp] NAT and PAT on ASA
In-Reply-To: <3841B0226AC74CADA928D92BA02C7860@flamdt01>
References: <B5CFB919B5EEF345969F51FAFE6360D50ADC90@GBLDCXMB10.emea.cbre.net>
	<6E21B2BDEF6E714EA0B5BA8D5D0E1401248380AF40@zy-ex1.zyedge.local>
	<3841B0226AC74CADA928D92BA02C7860@flamdt01>
Message-ID: <6E21B2BDEF6E714EA0B5BA8D5D0E1401248380B078@zy-ex1.zyedge.local>

Tony,

I agree that I chose the wrong wording here. It should have read, the ACL you're concerned with is inbound on the outside interface.  Otherwise, the configlet is fine.

I find the netmask option to be irrelevant, unless you're falling on obvious bit boundaries within the same class or doing NAT shifting.  I guess I'm a creature of habit and go with the path of least keystrokes.  When you're creating isakmp keys, do you type:

tunnel-group 169.254.50.50 type ipsec-l2l
tunnel-group 169.254.50.50 ipsec-attributes
 pre-shared-key BestPractices

or

isakmp key BestPractices address 169.254.50.50

They both produce the same results.  I guess the BU gave up on calling it a deprecated command, it hasn't seemed to complain since 7.2.

-ryan

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Tony Varriale
Sent: Tuesday, July 21, 2009 10:42 PM
To: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] NAT and PAT on ASA

Ryan,

I would recommend completing your static with the appropriate netmask.

Also, ACLs can be applied in and out on an interface on ASA and PIX since 
7.0.

tv
----- Original Message ----- 
From: "Ryan West" <rwest at zyedge.com>
To: "Oddiraju, Kiran @ London SMC" <Kiran.Oddiraju at cbre.com>; 
<cisco-nsp at puck.nether.net>
Sent: Tuesday, July 21, 2009 1:48 PM
Subject: Re: [c-nsp] NAT and PAT on ASA


> static (inside,outside) 58.66.76.88 192.168.0.100
> show run access-group
> take note of the acl to the outside interface, ACLs are on the ASA are 
> inbound.
> access-list <myaccesslist> ext permit icmp any host 58.66.76.88 echo
> access-list <myaccesslist> ext permit tcp any host 58.66.76.88 eq www
>
> -ryan
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net 
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Oddiraju, Kiran @ 
> London SMC
> Sent: Tuesday, July 21, 2009 2:09 PM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] NAT and PAT on ASA
>
> Guys,
>
>
>
> I am new to the ASA world, I have a bunch of external IP's from the ISP
> and I have an inside host that I want to access externally. How do I
> translate an inside ip (192.168.0.100) to an outside address
> (58.66.76.88) on the ASA? I should be able to ping and www from outside
> world to my inside host. Please let me know how to accomplish this.
>
>
>
> Many thanks,
>
> K
>
>
> CB Richard Ellis Limited, Registered Office: St Martin's Court,
> 10 Paternoster Row, London, EC4M 7HP, registered in England and Wales No. 
> 3536032.
> Regulated by the RICS and an appointed representative of CB Richard Ellis
> Indirect Investment Services Limited which is authorised and regulated by 
> the Financial Services Authority.
>
> This communication is from CB Richard Ellis Limited or one of its
> associated/subsidiary companies. This communication contains information
> which is confidential and may be privileged. If you are not the intended 
> recipient,
> please contact the sender immediately. Any use of its contents is strictly 
> prohibited
> and you must not copy, send or disclose it, or rely on its contents in any 
> way whatsoever.
> Reasonable care has been taken to ensure that this communication
> (and any attachments or hyperlinks contained within it) is free from 
> computer viruses.
> No responsibility is accepted by CB Richard Ellis Limited or its 
> associated/subsidiary
> companies and the recipient should carry out any appropriate virus checks.
>
> _______________________________________________
> cisco-nsp mailing 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 blahu77 at gmail.com  Wed Jul 22 04:09:56 2009
From: blahu77 at gmail.com (Mateusz Blaszczyk)
Date: Wed, 22 Jul 2009 09:09:56 +0100
Subject: [c-nsp] OSPF NSSA question
In-Reply-To: <002101ca0a84$47c00d90$0a00000a@nil.si>
References: <000001ca0a2c$3eacef00$bc06cd00$@com>
	<383357750907211234m147cf35ak8689bed0759acab7@mail.gmail.com> 
	<000101ca0a42$f8f0f260$ead2d720$@com>
	<002101ca0a84$47c00d90$0a00000a@nil.si>
Message-ID: <383357750907220109v10fe3d11y2f03d5428b7dc70a@mail.gmail.com>

2009/7/22 Ivan Pepelnjak <ip at ioshints.info>:
> You're probably looking for the "ip ospf database-filter all out" command.

And how the summary LSA with 0/0 would get to the spoke router if that
is filtered out?
(assuming nssa scenario in OP's hub n'spoke topology)

Best Regards,

-mat

From Kiran.Oddiraju at cbre.com  Wed Jul 22 04:37:55 2009
From: Kiran.Oddiraju at cbre.com (Oddiraju, Kiran @ London SMC)
Date: Wed, 22 Jul 2009 09:37:55 +0100
Subject: [c-nsp] NAT and PAT on ASA
In-Reply-To: <6E21B2BDEF6E714EA0B5BA8D5D0E1401248380AF40@zy-ex1.zyedge.local>
References: <B5CFB919B5EEF345969F51FAFE6360D50ADC90@GBLDCXMB10.emea.cbre.net>
	<6E21B2BDEF6E714EA0B5BA8D5D0E1401248380AF40@zy-ex1.zyedge.local>
Message-ID: <B5CFB919B5EEF345969F51FAFE6360D50ADC93@GBLDCXMB10.emea.cbre.net>

Hey Ryan,

That seems to be working, thanks. So if I want to allow more ports we do
it the same way right?

access-list myaccesslist ext permit tcp any host 58.66.76.88 eq SIP
access-list myaccesslist ext permit upd any host 58.66.76.88 eq SIP

Thanks,
Kiran


-----Original Message-----
From: Ryan West [mailto:rwest at zyedge.com] 
Sent: 21 July 2009 19:48
To: Oddiraju, Kiran @ London SMC; cisco-nsp at puck.nether.net
Subject: RE: NAT and PAT on ASA

static (inside,outside) 58.66.76.88 192.168.0.100
show run access-group
take note of the acl to the outside interface, ACLs are on the ASA are
inbound.
access-list <myaccesslist> ext permit icmp any host 58.66.76.88 echo
access-list <myaccesslist> ext permit tcp any host 58.66.76.88 eq www

-ryan

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Oddiraju, Kiran
@ London SMC
Sent: Tuesday, July 21, 2009 2:09 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] NAT and PAT on ASA

Guys,

 

I am new to the ASA world, I have a bunch of external IP's from the ISP
and I have an inside host that I want to access externally. How do I
translate an inside ip (192.168.0.100) to an outside address
(58.66.76.88) on the ASA? I should be able to ping and www from outside
world to my inside host. Please let me know how to accomplish this.

 

Many thanks,

K


CB Richard Ellis Limited, Registered Office: St Martin's Court, 
10 Paternoster Row, London, EC4M 7HP, registered in England and Wales
No. 3536032. 
Regulated by the RICS and an appointed representative of CB Richard
Ellis 
Indirect Investment Services Limited which is authorised and regulated
by the Financial Services Authority.

This communication is from CB Richard Ellis Limited or one of its 
associated/subsidiary companies. This communication contains information

which is confidential and may be privileged. If you are not the intended
recipient, 
please contact the sender immediately. Any use of its contents is
strictly prohibited 
and you must not copy, send or disclose it, or rely on its contents in
any way whatsoever. 
Reasonable care has been taken to ensure that this communication 
(and any attachments or hyperlinks contained within it) is free from
computer viruses. 
No responsibility is accepted by CB Richard Ellis Limited or its
associated/subsidiary 
companies and the recipient should carry out any appropriate virus
checks.

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
CB Richard Ellis Limited, Registered Office: St Martin's Court, 
10 Paternoster Row, London, EC4M 7HP, registered in England and Wales No. 3536032. 
Regulated by the RICS and an appointed representative of CB Richard Ellis 
Indirect Investment Services Limited which is authorised and regulated by the Financial Services Authority.

This communication is from CB Richard Ellis Limited or one of its 
associated/subsidiary companies. This communication contains information 
which is confidential and may be privileged. If you are not the intended recipient, 
please contact the sender immediately. Any use of its contents is strictly prohibited 
and you must not copy, send or disclose it, or rely on its contents in any way whatsoever. 
Reasonable care has been taken to ensure that this communication 
(and any attachments or hyperlinks contained within it) is free from computer viruses. 
No responsibility is accepted by CB Richard Ellis Limited or its associated/subsidiary 
companies and the recipient should carry out any appropriate virus checks.


From rwest at zyedge.com  Wed Jul 22 04:46:43 2009
From: rwest at zyedge.com (Ryan West)
Date: Wed, 22 Jul 2009 04:46:43 -0400
Subject: [c-nsp] NAT and PAT on ASA
In-Reply-To: <B5CFB919B5EEF345969F51FAFE6360D50ADC93@GBLDCXMB10.emea.cbre.net>
References: <B5CFB919B5EEF345969F51FAFE6360D50ADC90@GBLDCXMB10.emea.cbre.net>
	<6E21B2BDEF6E714EA0B5BA8D5D0E1401248380AF40@zy-ex1.zyedge.local>
	<B5CFB919B5EEF345969F51FAFE6360D50ADC93@GBLDCXMB10.emea.cbre.net>
Message-ID: <6E21B2BDEF6E714EA0B5BA8D5D0E1401248380B07D@zy-ex1.zyedge.local>

Kiran,

That's right.  If you run into issues trying to pass SIP through your firewall, you may need to look at the default service policy.  There are some protocol inspection rules enabled by default that might affect the passing of SIP traffic.

-ryan

-----Original Message-----
From: Oddiraju, Kiran @ London SMC [mailto:Kiran.Oddiraju at cbre.com] 
Sent: Wednesday, July 22, 2009 4:38 AM
To: Ryan West
Cc: cisco-nsp at puck.nether.net
Subject: RE: NAT and PAT on ASA

Hey Ryan,

That seems to be working, thanks. So if I want to allow more ports we do
it the same way right?

access-list myaccesslist ext permit tcp any host 58.66.76.88 eq SIP
access-list myaccesslist ext permit upd any host 58.66.76.88 eq SIP

Thanks,
Kiran


-----Original Message-----
From: Ryan West [mailto:rwest at zyedge.com] 
Sent: 21 July 2009 19:48
To: Oddiraju, Kiran @ London SMC; cisco-nsp at puck.nether.net
Subject: RE: NAT and PAT on ASA

static (inside,outside) 58.66.76.88 192.168.0.100
show run access-group
take note of the acl to the outside interface, ACLs are on the ASA are
inbound.
access-list <myaccesslist> ext permit icmp any host 58.66.76.88 echo
access-list <myaccesslist> ext permit tcp any host 58.66.76.88 eq www

-ryan

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Oddiraju, Kiran
@ London SMC
Sent: Tuesday, July 21, 2009 2:09 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] NAT and PAT on ASA

Guys,

 

I am new to the ASA world, I have a bunch of external IP's from the ISP
and I have an inside host that I want to access externally. How do I
translate an inside ip (192.168.0.100) to an outside address
(58.66.76.88) on the ASA? I should be able to ping and www from outside
world to my inside host. Please let me know how to accomplish this.

 

Many thanks,

K


CB Richard Ellis Limited, Registered Office: St Martin's Court, 
10 Paternoster Row, London, EC4M 7HP, registered in England and Wales
No. 3536032. 
Regulated by the RICS and an appointed representative of CB Richard
Ellis 
Indirect Investment Services Limited which is authorised and regulated
by the Financial Services Authority.

This communication is from CB Richard Ellis Limited or one of its 
associated/subsidiary companies. This communication contains information

which is confidential and may be privileged. If you are not the intended
recipient, 
please contact the sender immediately. Any use of its contents is
strictly prohibited 
and you must not copy, send or disclose it, or rely on its contents in
any way whatsoever. 
Reasonable care has been taken to ensure that this communication 
(and any attachments or hyperlinks contained within it) is free from
computer viruses. 
No responsibility is accepted by CB Richard Ellis Limited or its
associated/subsidiary 
companies and the recipient should carry out any appropriate virus
checks.

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
CB Richard Ellis Limited, Registered Office: St Martin's Court, 
10 Paternoster Row, London, EC4M 7HP, registered in England and Wales No. 3536032. 
Regulated by the RICS and an appointed representative of CB Richard Ellis 
Indirect Investment Services Limited which is authorised and regulated by the Financial Services Authority.

This communication is from CB Richard Ellis Limited or one of its 
associated/subsidiary companies. This communication contains information 
which is confidential and may be privileged. If you are not the intended recipient, 
please contact the sender immediately. Any use of its contents is strictly prohibited 
and you must not copy, send or disclose it, or rely on its contents in any way whatsoever. 
Reasonable care has been taken to ensure that this communication 
(and any attachments or hyperlinks contained within it) is free from computer viruses. 
No responsibility is accepted by CB Richard Ellis Limited or its associated/subsidiary 
companies and the recipient should carry out any appropriate virus checks.



From zivl at gilat.net  Wed Jul 22 05:09:06 2009
From: zivl at gilat.net (Ziv Leyes)
Date: Wed, 22 Jul 2009 12:09:06 +0300
Subject: [c-nsp] NAT and PAT on ASA
In-Reply-To: <6E21B2BDEF6E714EA0B5BA8D5D0E1401248380B078@zy-ex1.zyedge.local>
References: <B5CFB919B5EEF345969F51FAFE6360D50ADC90@GBLDCXMB10.emea.cbre.net>
	<6E21B2BDEF6E714EA0B5BA8D5D0E1401248380AF40@zy-ex1.zyedge.local>
	<3841B0226AC74CADA928D92BA02C7860@flamdt01>
	<6E21B2BDEF6E714EA0B5BA8D5D0E1401248380B078@zy-ex1.zyedge.local>
Message-ID: <EC993E87D960A541A66BF21D62AA42A6230163B453@exch2k7.gilat.local>

I think both of you have a point here, no need to fight...

I also tend to adopt habits that make me type less, but not before I make sure to get the desired result and not some awkward cisco bad interpretation to what I mean...

I prefer to not use the "proper" way to save configurations
copy running-config startup-config
copy running config tftp
when I can simple do
wr
wr net
and get exactly the same results

What is curious is why do the IOS keep telling me that the "wr net" command will be deprecated and keeps working, for ten years already?

So, as I said, you're both right, type as less as you can, but always keep in mind the consequences that this might have.

Ziv


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Ryan West
Sent: Wednesday, July 22, 2009 10:52 AM
To: Tony Varriale; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] NAT and PAT on ASA

Tony,

I agree that I chose the wrong wording here. It should have read, the ACL you're concerned with is inbound on the outside interface.  Otherwise, the configlet is fine.

I find the netmask option to be irrelevant, unless you're falling on obvious bit boundaries within the same class or doing NAT shifting.  I guess I'm a creature of habit and go with the path of least keystrokes.  When you're creating isakmp keys, do you type:

tunnel-group 169.254.50.50 type ipsec-l2l
tunnel-group 169.254.50.50 ipsec-attributes
 pre-shared-key BestPractices

or

isakmp key BestPractices address 169.254.50.50

They both produce the same results.  I guess the BU gave up on calling it a deprecated command, it hasn't seemed to complain since 7.2.

-ryan

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Tony Varriale
Sent: Tuesday, July 21, 2009 10:42 PM
To: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] NAT and PAT on ASA

Ryan,

I would recommend completing your static with the appropriate netmask.

Also, ACLs can be applied in and out on an interface on ASA and PIX since 
7.0.

tv
----- Original Message ----- 
From: "Ryan West" <rwest at zyedge.com>
To: "Oddiraju, Kiran @ London SMC" <Kiran.Oddiraju at cbre.com>; 
<cisco-nsp at puck.nether.net>
Sent: Tuesday, July 21, 2009 1:48 PM
Subject: Re: [c-nsp] NAT and PAT on ASA


> static (inside,outside) 58.66.76.88 192.168.0.100
> show run access-group
> take note of the acl to the outside interface, ACLs are on the ASA are 
> inbound.
> access-list <myaccesslist> ext permit icmp any host 58.66.76.88 echo
> access-list <myaccesslist> ext permit tcp any host 58.66.76.88 eq www
>
> -ryan
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net 
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Oddiraju, Kiran @ 
> London SMC
> Sent: Tuesday, July 21, 2009 2:09 PM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] NAT and PAT on ASA
>
> Guys,
>
>
>
> I am new to the ASA world, I have a bunch of external IP's from the ISP
> and I have an inside host that I want to access externally. How do I
> translate an inside ip (192.168.0.100) to an outside address
> (58.66.76.88) on the ASA? I should be able to ping and www from outside
> world to my inside host. Please let me know how to accomplish this.
>
>
>
> Many thanks,
>
> K
>
>
> CB Richard Ellis Limited, Registered Office: St Martin's Court,
> 10 Paternoster Row, London, EC4M 7HP, registered in England and Wales No. 
> 3536032.
> Regulated by the RICS and an appointed representative of CB Richard Ellis
> Indirect Investment Services Limited which is authorised and regulated by 
> the Financial Services Authority.
>
> This communication is from CB Richard Ellis Limited or one of its
> associated/subsidiary companies. This communication contains information
> which is confidential and may be privileged. If you are not the intended 
> recipient,
> please contact the sender immediately. Any use of its contents is strictly 
> prohibited
> and you must not copy, send or disclose it, or rely on its contents in any 
> way whatsoever.
> Reasonable care has been taken to ensure that this communication
> (and any attachments or hyperlinks contained within it) is free from 
> computer viruses.
> No responsibility is accepted by CB Richard Ellis Limited or its 
> associated/subsidiary
> companies and the recipient should carry out any appropriate virus checks.
>
> _______________________________________________
> cisco-nsp mailing 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/

 
 
************************************************************************************
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 eninja at gmail.com  Wed Jul 22 05:12:00 2009
From: eninja at gmail.com (Eninja)
Date: Wed, 22 Jul 2009 10:12:00 +0100
Subject: [c-nsp] GSR 12008 GRP ISSUES
In-Reply-To: <2e1cd850907211412y3ae80581yde7861bf139831df@mail.gmail.com>
References: <2e1cd850907211134t76ad2950u991688ac7d2cc921@mail.gmail.com>
	<480dad640907211407i6bf3f3e7k7e4199322a8fca64@mail.gmail.com>
	<2e1cd850907211412y3ae80581yde7861bf139831df@mail.gmail.com>
Message-ID: <5DE69C2A-0DDE-48DE-B5A8-82B8D044288B@gmail.com>

Chris,

Quick walk through... The Secondary RP ToFab FIA reports that it is  
having difficulty accessing the fabric and thus IPC fails (since it  
travels via the fabric), secondary is unable to therefore initiate and  
respond to active-secondary keepalives, Active RP unsuccessfully  
attempts to reset it via the MBUS and then marks it dead via the  
MBUS-6-DEADSCDY.

You should reinsert it to see if a reseat clears the problem before an  
RMA.

Eninja



On Jul 21, 2009, at 10:12 PM, Chris Lane <clane1875 at gmail.com> wrote:

> Slot0 we think has a defective GRP, we removed and errors are gone.  
> I have a
> new GRP being shipped for tomorrow.
> Thanks
>
> On Tue, Jul 21, 2009 at 5:07 PM, Aaron <dudepron at gmail.com> wrote:
>
>> Looks like a fabric problem.
>>
>>
>> On Tue, Jul 21, 2009 at 14:34, Chris Lane <clane1875 at gmail.com>  
>> wrote:
>>
>>> All,
>>> I have a GSR 12008 with 2 GRP-B route processors. Running
>>> gsr-k4p-mz.120-32.S11.bin
>>>
>>> My GRP failed over about 45 minutes ago to the backup in Slot1  
>>> from Slot0.
>>> I keep getting this in my logs.
>>> SEC  0:00:00:06: %MBUS-6-FIA_CONFIG: Switch Cards 0x1F (bit mask);  
>>> Primary
>>> Clock CSC_1
>>> SEC  0:00:00:07: %FIA-3-HALT: To Fabric
>>> SEC  0:00:00:07: %FIA-3-PARITYERR: To Fabric parity error was  
>>> detected.
>>> Request parity error interrupt = 0x4.
>>> SEC  0:00:00:07: %FIA-3-HALT: To Fabric
>>> SEC  0:00:00:07: %FIA-3-HALT: To Fabric
>>> SEC  0:00:00:07: %RP-3-FABRIC_UNI: Unicast send timed out  (1)
>>> SEC  0:00:00:13: %RP-3-FABRIC_UNI: Unicast send timed out  (1)
>>> SEC  0:00:00:23: %RP-3-FABRIC_UNI: Unicast send timed out  (1)
>>> SEC  0:00:00:37: %IPC-5-REGPORTFAIL: Registering Control Port  
>>> Id=0x1000003
>>> timeout=0x6
>>> -Traceback= 501F6650 505A3B90 505A3F4C 505A40D8 5059FCCC 502A02D8  
>>> 502A02C4
>>> SEC  0:00:00:44: %RP-3-FABRIC_UNI: Unicast send timed out  (1)
>>> SEC  0:00:01:08: %IPC-5-REGPORTFAIL: Registering Control Port  
>>> Id=0x1000003
>>> timeout=0x6
>>> -Traceback= 501F6650 505A3B90 505A3BD8 502A02D8 502A02C4
>>> SEC  0:00:01:15: %RP-3-FABRIC_UNI: Unicast send timed out  (1)
>>> SEC  0:00:01:39: %IPC-5-REGPORTFAIL: Registering Control Port  
>>> Id=0x1000003
>>> timeout=0x6
>>> -Traceback= 501F6650 505A3B90 505A3BD8 502A02D8 502A02C4
>>> SEC  0:00:01:56: %RP-3-FABRIC_UNI: Unicast send timed out  (1)
>>> SEC  0:00:02:10: %IPC-5-REGPORTFAIL: Registering Control Port  
>>> Id=0x1000003
>>> timeout=0x6
>>> -Traceback= 501F6650 505A3B90 505A3BD8 502A02D8 502A02C4
>>> SEC  0:00:02:41: %IPC-5-REGPORTFAIL: Registering Control Port  
>>> Id=0x1000003
>>> timeout=0x6
>>> -Traceback= 501F6650 505A3B90 505A3BD8 502A02D8 502A02C4
>>> SEC  0:00:02:48: %RP-3-FABRIC_UNI: Unicast send timed out  (1)
>>> SEC  0:00:03:12: %IPC-5-REGPORTFAIL: Registering Control Port  
>>> Id=0x1000003
>>> timeout=0x6
>>> -Traceback= 501F6650 505A3B90 505A3BD8 502A02D8 502A02C4
>>> SEC  0:00:03:43: %IPC-5-REGPORTFAIL: Registering Control Port  
>>> Id=0x1000003
>>> timeout=0x6
>>> -Traceback= 501F6650 505A3B90 505A3BD8 502A02D8 502A02C4
>>> SEC  0:00:03:50: %RP-3-FABRIC_UNI: Unicast send timed out  (1)
>>> SEC  0:00:04:14: %IPC-5-REGPORTFAIL: Registering Control Port  
>>> Id=0x1000003
>>> timeout=0x6
>>> -Traceback= 501F6650 505A3B90 505A3BD8 502A02D8 502A02C4
>>> SEC  0:00:04:45: %IPC-5-REGPORTFAIL: Registering Control Port  
>>> Id=0x1000003
>>> timeout=0x6
>>> -Traceback= 501F6650 505A3B90 505A3BD8 502A02D8 502A02C4
>>> SEC  0:00:05:02: %RP-3-FABRIC_UNI: Unicast send timed out  (1)
>>> Jul 21 12:27:01.258 EDT: %RP-3-ERROR: Timed out while initializing  
>>> IPC to
>>> standby RP in slot 0
>>> Jul 21 12:28:02.070 EDT: %MBUS-6-DEADSCDY: Standby RP in slot 0  
>>> timed out,
>>> reset
>>>
>>>
>>> Is this because SLOT0 is hung, trying to become primary again yet  
>>> not
>>> communicating with SLOT1 the active RP?
>>> SLOT 0  (RP/LC 0 ): Route Processor
>>> MAIN: type 19,  800-2427-03 rev F0
>>>       Deviation:  D070866
>>>       HW config: 0x00    SW key: 00-00-00
>>> PCA:  73-2170-08 rev E0 ver 5
>>>       Design Release 1.5  S/N SAD0745027R
>>> MBUS: MBUS Agent (1)  73-2146-07 rev B0 dev 0
>>>       HW version 1.2  S/N CAT073504X3
>>>       Test hist: 0x00    RMA#: 00-00-00    RMA hist: 0x00
>>> DIAG: Test count: 0x00000000    Test results: 0x00000000
>>> FRU:  Linecard/Module: GRP-B=
>>>       Route Memory: MEM-GRP-512=
>>> MBUS Agent Software version 2.68 (RAM) (ROM version is 3.47)
>>> ROM Monitor version 2.2
>>> Primary clock is CSC 1
>>> Board State is Route Processor Powered ( RP  RDY )    *********  
>>> SHOULDN'T
>>> THIS SAY STANDBY (STBY  RP )
>>> Insertion time: 42w1d (00:56:55 ago)
>>> DRAM size: 536870912 bytes
>>>
>>>
>>> SLOT 1  (RP/LC 1 ): Route Processor
>>> MAIN: type 19,  800-2427-03 rev F0
>>>       Deviation: 0
>>>       HW config: 0x00    SW key: 00-00-00
>>> PCA:  73-2170-08 rev E0 ver 5
>>>       Design Release 1.5  S/N SAD072000C3
>>> MBUS: MBUS Agent (1)  73-2146-07 rev B0 dev 0
>>>       HW version 1.2  S/N CAT07100SFN
>>>       Test hist: 0x00    RMA#: 00-00-00    RMA hist: 0x00
>>> DIAG: Test count: 0x00000000    Test results: 0x00000000
>>> FRU:  Linecard/Module: GRP-B=
>>>       Route Memory: MEM-GRP-512=
>>> MBUS Agent Software version 2.68 (RAM) (ROM version is 3.47)
>>> ROM Monitor version 2.2
>>> Primary clock is CSC 1
>>> Board State is IOS Running  ACTIVE (ACTV  RP )
>>> Insertion time: 42w1d (00:56:55 ago)
>>> DRAM size: 536870912 bytes
>>>
>>>
>>>
>>> Any help, suggestions greatly appreciated
>>>
>>> Chris
>>>
>>> --
>>> //CL
>>> _______________________________________________
>>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>>
>>
>>
>
>
> -- 
> //CL
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

From Kiran.Oddiraju at cbre.com  Wed Jul 22 07:24:30 2009
From: Kiran.Oddiraju at cbre.com (Oddiraju, Kiran @ London SMC)
Date: Wed, 22 Jul 2009 12:24:30 +0100
Subject: [c-nsp] NAT and PAT on ASA
In-Reply-To: <6E21B2BDEF6E714EA0B5BA8D5D0E1401248380B07D@zy-ex1.zyedge.local>
References: <B5CFB919B5EEF345969F51FAFE6360D50ADC90@GBLDCXMB10.emea.cbre.net>
	<6E21B2BDEF6E714EA0B5BA8D5D0E1401248380AF40@zy-ex1.zyedge.local>
	<B5CFB919B5EEF345969F51FAFE6360D50ADC93@GBLDCXMB10.emea.cbre.net>
	<6E21B2BDEF6E714EA0B5BA8D5D0E1401248380B07D@zy-ex1.zyedge.local>
Message-ID: <B5CFB919B5EEF345969F51FAFE6360D50ADCC2@GBLDCXMB10.emea.cbre.net>

Hi Ryan,

I have the below config in the protocol inspection rules, do you think
this is enough?

class-map inspection_default
 match default-inspection-traffic
!
!
policy-map type inspect dns preset_dns_map
 parameters
  message-length maximum 512
policy-map global_policy
 class inspection_default
  inspect dns preset_dns_map
  inspect ftp
  inspect h323 h225
  inspect h323 ras
  inspect rsh
  inspect rtsp
  inspect esmtp
  inspect sqlnet
  inspect skinny
  inspect sunrpc
  inspect xdmcp
  inspect sip
  inspect netbios
  inspect tftp
  inspect icmp
!


Many thanks,
Kiran

-----Original Message-----
From: Ryan West [mailto:rwest at zyedge.com] 
Sent: 22 July 2009 09:47
To: Oddiraju, Kiran @ London SMC
Cc: cisco-nsp at puck.nether.net
Subject: RE: NAT and PAT on ASA

Kiran,

That's right.  If you run into issues trying to pass SIP through your
firewall, you may need to look at the default service policy.  There are
some protocol inspection rules enabled by default that might affect the
passing of SIP traffic.

-ryan

-----Original Message-----
From: Oddiraju, Kiran @ London SMC [mailto:Kiran.Oddiraju at cbre.com] 
Sent: Wednesday, July 22, 2009 4:38 AM
To: Ryan West
Cc: cisco-nsp at puck.nether.net
Subject: RE: NAT and PAT on ASA

Hey Ryan,

That seems to be working, thanks. So if I want to allow more ports we do
it the same way right?

access-list myaccesslist ext permit tcp any host 58.66.76.88 eq SIP
access-list myaccesslist ext permit upd any host 58.66.76.88 eq SIP

Thanks,
Kiran


-----Original Message-----
From: Ryan West [mailto:rwest at zyedge.com] 
Sent: 21 July 2009 19:48
To: Oddiraju, Kiran @ London SMC; cisco-nsp at puck.nether.net
Subject: RE: NAT and PAT on ASA

static (inside,outside) 58.66.76.88 192.168.0.100
show run access-group
take note of the acl to the outside interface, ACLs are on the ASA are
inbound.
access-list <myaccesslist> ext permit icmp any host 58.66.76.88 echo
access-list <myaccesslist> ext permit tcp any host 58.66.76.88 eq www

-ryan

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Oddiraju, Kiran
@ London SMC
Sent: Tuesday, July 21, 2009 2:09 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] NAT and PAT on ASA

Guys,

 

I am new to the ASA world, I have a bunch of external IP's from the ISP
and I have an inside host that I want to access externally. How do I
translate an inside ip (192.168.0.100) to an outside address
(58.66.76.88) on the ASA? I should be able to ping and www from outside
world to my inside host. Please let me know how to accomplish this.

 

Many thanks,

K


CB Richard Ellis Limited, Registered Office: St Martin's Court, 
10 Paternoster Row, London, EC4M 7HP, registered in England and Wales
No. 3536032. 
Regulated by the RICS and an appointed representative of CB Richard
Ellis 
Indirect Investment Services Limited which is authorised and regulated
by the Financial Services Authority.

This communication is from CB Richard Ellis Limited or one of its 
associated/subsidiary companies. This communication contains information

which is confidential and may be privileged. If you are not the intended
recipient, 
please contact the sender immediately. Any use of its contents is
strictly prohibited 
and you must not copy, send or disclose it, or rely on its contents in
any way whatsoever. 
Reasonable care has been taken to ensure that this communication 
(and any attachments or hyperlinks contained within it) is free from
computer viruses. 
No responsibility is accepted by CB Richard Ellis Limited or its
associated/subsidiary 
companies and the recipient should carry out any appropriate virus
checks.

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
CB Richard Ellis Limited, Registered Office: St Martin's Court, 
10 Paternoster Row, London, EC4M 7HP, registered in England and Wales
No. 3536032. 
Regulated by the RICS and an appointed representative of CB Richard
Ellis 
Indirect Investment Services Limited which is authorised and regulated
by the Financial Services Authority.

This communication is from CB Richard Ellis Limited or one of its 
associated/subsidiary companies. This communication contains information

which is confidential and may be privileged. If you are not the intended
recipient, 
please contact the sender immediately. Any use of its contents is
strictly prohibited 
and you must not copy, send or disclose it, or rely on its contents in
any way whatsoever. 
Reasonable care has been taken to ensure that this communication 
(and any attachments or hyperlinks contained within it) is free from
computer viruses. 
No responsibility is accepted by CB Richard Ellis Limited or its
associated/subsidiary 
companies and the recipient should carry out any appropriate virus
checks.


CB Richard Ellis Limited, Registered Office: St Martin's Court, 
10 Paternoster Row, London, EC4M 7HP, registered in England and Wales No. 3536032. 
Regulated by the RICS and an appointed representative of CB Richard Ellis 
Indirect Investment Services Limited which is authorised and regulated by the Financial Services Authority.

This communication is from CB Richard Ellis Limited or one of its 
associated/subsidiary companies. This communication contains information 
which is confidential and may be privileged. If you are not the intended recipient, 
please contact the sender immediately. Any use of its contents is strictly prohibited 
and you must not copy, send or disclose it, or rely on its contents in any way whatsoever. 
Reasonable care has been taken to ensure that this communication 
(and any attachments or hyperlinks contained within it) is free from computer viruses. 
No responsibility is accepted by CB Richard Ellis Limited or its associated/subsidiary 
companies and the recipient should carry out any appropriate virus checks.


From rwest at zyedge.com  Wed Jul 22 08:26:03 2009
From: rwest at zyedge.com (Ryan West)
Date: Wed, 22 Jul 2009 08:26:03 -0400
Subject: [c-nsp] NAT and PAT on ASA
In-Reply-To: <B5CFB919B5EEF345969F51FAFE6360D50ADCC2@GBLDCXMB10.emea.cbre.net>
References: <B5CFB919B5EEF345969F51FAFE6360D50ADC90@GBLDCXMB10.emea.cbre.net>
	<6E21B2BDEF6E714EA0B5BA8D5D0E1401248380AF40@zy-ex1.zyedge.local>
	<B5CFB919B5EEF345969F51FAFE6360D50ADC93@GBLDCXMB10.emea.cbre.net>
	<6E21B2BDEF6E714EA0B5BA8D5D0E1401248380B07D@zy-ex1.zyedge.local>
	<B5CFB919B5EEF345969F51FAFE6360D50ADCC2@GBLDCXMB10.emea.cbre.net>
Message-ID: <6E21B2BDEF6E714EA0B5BA8D5D0E1401248380B083@zy-ex1.zyedge.local>

Kirian, 

That looks like the default.  You had mentioned SIP in your ACL, so that's why I brought this up.  If you're doing PAT based sip, you may have to disable the SIP inspection, depending on who your SIP provider is.

Otherwise, you should be good to go.

-ryan

-----Original Message-----
From: Oddiraju, Kiran @ London SMC [mailto:Kiran.Oddiraju at cbre.com] 
Sent: Wednesday, July 22, 2009 7:25 AM
To: Ryan West
Cc: cisco-nsp at puck.nether.net
Subject: RE: NAT and PAT on ASA

Hi Ryan,

I have the below config in the protocol inspection rules, do you think
this is enough?

class-map inspection_default
 match default-inspection-traffic
!
!
policy-map type inspect dns preset_dns_map
 parameters
  message-length maximum 512
policy-map global_policy
 class inspection_default
  inspect dns preset_dns_map
  inspect ftp
  inspect h323 h225
  inspect h323 ras
  inspect rsh
  inspect rtsp
  inspect esmtp
  inspect sqlnet
  inspect skinny
  inspect sunrpc
  inspect xdmcp
  inspect sip
  inspect netbios
  inspect tftp
  inspect icmp
!


Many thanks,
Kiran

-----Original Message-----
From: Ryan West [mailto:rwest at zyedge.com] 
Sent: 22 July 2009 09:47
To: Oddiraju, Kiran @ London SMC
Cc: cisco-nsp at puck.nether.net
Subject: RE: NAT and PAT on ASA

Kiran,

That's right.  If you run into issues trying to pass SIP through your
firewall, you may need to look at the default service policy.  There are
some protocol inspection rules enabled by default that might affect the
passing of SIP traffic.

-ryan

-----Original Message-----
From: Oddiraju, Kiran @ London SMC [mailto:Kiran.Oddiraju at cbre.com] 
Sent: Wednesday, July 22, 2009 4:38 AM
To: Ryan West
Cc: cisco-nsp at puck.nether.net
Subject: RE: NAT and PAT on ASA

Hey Ryan,

That seems to be working, thanks. So if I want to allow more ports we do
it the same way right?

access-list myaccesslist ext permit tcp any host 58.66.76.88 eq SIP
access-list myaccesslist ext permit upd any host 58.66.76.88 eq SIP

Thanks,
Kiran


-----Original Message-----
From: Ryan West [mailto:rwest at zyedge.com] 
Sent: 21 July 2009 19:48
To: Oddiraju, Kiran @ London SMC; cisco-nsp at puck.nether.net
Subject: RE: NAT and PAT on ASA

static (inside,outside) 58.66.76.88 192.168.0.100
show run access-group
take note of the acl to the outside interface, ACLs are on the ASA are
inbound.
access-list <myaccesslist> ext permit icmp any host 58.66.76.88 echo
access-list <myaccesslist> ext permit tcp any host 58.66.76.88 eq www

-ryan

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Oddiraju, Kiran
@ London SMC
Sent: Tuesday, July 21, 2009 2:09 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] NAT and PAT on ASA

Guys,

 

I am new to the ASA world, I have a bunch of external IP's from the ISP
and I have an inside host that I want to access externally. How do I
translate an inside ip (192.168.0.100) to an outside address
(58.66.76.88) on the ASA? I should be able to ping and www from outside
world to my inside host. Please let me know how to accomplish this.

 

Many thanks,

K


CB Richard Ellis Limited, Registered Office: St Martin's Court, 
10 Paternoster Row, London, EC4M 7HP, registered in England and Wales
No. 3536032. 
Regulated by the RICS and an appointed representative of CB Richard
Ellis 
Indirect Investment Services Limited which is authorised and regulated
by the Financial Services Authority.

This communication is from CB Richard Ellis Limited or one of its 
associated/subsidiary companies. This communication contains information

which is confidential and may be privileged. If you are not the intended
recipient, 
please contact the sender immediately. Any use of its contents is
strictly prohibited 
and you must not copy, send or disclose it, or rely on its contents in
any way whatsoever. 
Reasonable care has been taken to ensure that this communication 
(and any attachments or hyperlinks contained within it) is free from
computer viruses. 
No responsibility is accepted by CB Richard Ellis Limited or its
associated/subsidiary 
companies and the recipient should carry out any appropriate virus
checks.

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
CB Richard Ellis Limited, Registered Office: St Martin's Court, 
10 Paternoster Row, London, EC4M 7HP, registered in England and Wales
No. 3536032. 
Regulated by the RICS and an appointed representative of CB Richard
Ellis 
Indirect Investment Services Limited which is authorised and regulated
by the Financial Services Authority.

This communication is from CB Richard Ellis Limited or one of its 
associated/subsidiary companies. This communication contains information

which is confidential and may be privileged. If you are not the intended
recipient, 
please contact the sender immediately. Any use of its contents is
strictly prohibited 
and you must not copy, send or disclose it, or rely on its contents in
any way whatsoever. 
Reasonable care has been taken to ensure that this communication 
(and any attachments or hyperlinks contained within it) is free from
computer viruses. 
No responsibility is accepted by CB Richard Ellis Limited or its
associated/subsidiary 
companies and the recipient should carry out any appropriate virus
checks.


CB Richard Ellis Limited, Registered Office: St Martin's Court, 
10 Paternoster Row, London, EC4M 7HP, registered in England and Wales No. 3536032. 
Regulated by the RICS and an appointed representative of CB Richard Ellis 
Indirect Investment Services Limited which is authorised and regulated by the Financial Services Authority.

This communication is from CB Richard Ellis Limited or one of its 
associated/subsidiary companies. This communication contains information 
which is confidential and may be privileged. If you are not the intended recipient, 
please contact the sender immediately. Any use of its contents is strictly prohibited 
and you must not copy, send or disclose it, or rely on its contents in any way whatsoever. 
Reasonable care has been taken to ensure that this communication 
(and any attachments or hyperlinks contained within it) is free from computer viruses. 
No responsibility is accepted by CB Richard Ellis Limited or its associated/subsidiary 
companies and the recipient should carry out any appropriate virus checks.



From sam.avi9009 at hotmail.com  Wed Jul 22 09:26:45 2009
From: sam.avi9009 at hotmail.com (sam avi)
Date: Wed, 22 Jul 2009 23:56:45 +1030
Subject: [c-nsp] testing physical links between production and
 non-production switches
In-Reply-To: <6E21B2BDEF6E714EA0B5BA8D5D0E1401248380B083@zy-ex1.zyedge.local>
References: <B5CFB919B5EEF345969F51FAFE6360D50ADC90@GBLDCXMB10.emea.cbre.net>
	<6E21B2BDEF6E714EA0B5BA8D5D0E1401248380AF40@zy-ex1.zyedge.local>
	<B5CFB919B5EEF345969F51FAFE6360D50ADC93@GBLDCXMB10.emea.cbre.net>
	<6E21B2BDEF6E714EA0B5BA8D5D0E1401248380B07D@zy-ex1.zyedge.local>
	<B5CFB919B5EEF345969F51FAFE6360D50ADCC2@GBLDCXMB10.emea.cbre.net> 
	<6E21B2BDEF6E714EA0B5BA8D5D0E1401248380B083@zy-ex1.zyedge.local> 
Message-ID: <BAY108-W52B06D5B0F33E416AEEDF7E01B0@phx.gbl>








Hi, 

I have a set of access switches (3750s), which are purely in a layer 2 setup, i.e. connect uplink to core 6509s, which are setup as root and backup spanning-tree roots. 

I need to connect another set of switches to the above 3750s in a migration, but would like to be able to test the physical layer before-hand to avoid surprises on the migration day. 

One "safe" way I thought I could do this interim step was to make the switch ports into routed ports, i.e "no switchport". This should clear off any spanning-tree hiccups when I'm doing a physical level test. Once this goes ahead ok, then I plan to shut down the ports and later configure them as standard L2 ports. 

Any comments? Is there any other way I can do such an interim test in a "safe" way, i.e without affecting other production traffic on the 3750s?


---sam

_________________________________________________________________
What goes online, stays online Check the daily blob for the latest on what's happening around the web
http://windowslive.ninemsn.com.au/blog.aspx

From maillist at webjogger.net  Wed Jul 22 09:32:23 2009
From: maillist at webjogger.net (Adam Greene)
Date: Wed, 22 Jul 2009 09:32:23 -0400
Subject: [c-nsp] persistent debug
References: <9BA7244859D14DA8AC1E7F22267BF5EE@GINKGO>
	<4A65C8BF.7010205@lafayette.edu>
Message-ID: <135A0795FF65431C82624D0307F57D68@GINKGO>

I need more information that just if the peer went up or down ... we're 
doing conditional BGP advertisements and I need to track the timing of the 
advertisements related to the drop of the peer ... thanks for the suggestion 
though!

----- Original Message ----- 
From: "Michael Costello" <costellm at lafayette.edu>
To: <cisco-nsp at puck.nether.net>
Sent: Tuesday, July 21, 2009 9:55 AM
Subject: Re: [c-nsp] persistent debug


> Adam Greene said the following:
>> Hi,
>>
>> I like to leave "debug ip bgp updates" running on customer edge routers 
>> with whom I do eBGP peering, to track outage events.
>
> Why not just use `bgp log-neighbor-changes` and syslog?
>
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
> 



From maillist at webjogger.net  Wed Jul 22 09:32:41 2009
From: maillist at webjogger.net (Adam Greene)
Date: Wed, 22 Jul 2009 09:32:41 -0400
Subject: [c-nsp] persistent debug
References: <9BA7244859D14DA8AC1E7F22267BF5EE@GINKGO>
	<4A64E69B.8080805@cisco.com>
Message-ID: <AAAC97BE252D490E8D914FB0529316AD@GINKGO>

Will give it a try, Shimol. Thanks!

----- Original Message ----- 
From: "Shimol Shah ( Cisco )" <shimshah at cisco.com>
To: "Adam Greene" <maillist at webjogger.net>
Cc: <cisco-nsp at puck.nether.net>
Sent: Monday, July 20, 2009 5:50 PM
Subject: Re: [c-nsp] persistent debug


> Not tried it myself but below has two solutions:
>
> http://blog.ioshints.info/2007/06/re-enable-debugging-on-router-reload.html
>
>
> HTH
>
> Adam Greene wrote:
>> Hi,
>>
>> I like to leave "debug ip bgp updates" running on customer edge routers 
>> with whom I do eBGP peering, to track outage events.
>>
>> However, the debugging command always goes away after the customer router 
>> reboots. Any way to make this persistent? (i.e. when router reboots, bgp 
>> update debugging gets automatically enabled?)
>>
>> Thanks,
>> adam
>>
>>
>>
>> _______________________________________________
>> cisco-nsp mailing list  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 Jul 22 09:59:46 2009
From: eng_mssk at hotmail.com (Mohammad Khalil)
Date: Wed, 22 Jul 2009 16:59:46 +0300
Subject: [c-nsp] SMS Server
Message-ID: <BLU102-W578C0B5BEDB958F39A039FA1B0@phx.gbl>


what i need to setup SMS server ??
for example in case of any event (critical one obtained through log) i want SMS to be sent from a server to a certain list of mobile numbers 

Thanks

_________________________________________________________________
With Windows Live, you can organize, edit, and share your photos.
http://www.microsoft.com/middleeast/windows/windowslive/products/photo-gallery-edit.aspx

From nick at inex.ie  Wed Jul 22 10:16:29 2009
From: nick at inex.ie (Nick Hilliard)
Date: Wed, 22 Jul 2009 15:16:29 +0100
Subject: [c-nsp] SMS Server
In-Reply-To: <BLU102-W578C0B5BEDB958F39A039FA1B0@phx.gbl>
References: <BLU102-W578C0B5BEDB958F39A039FA1B0@phx.gbl>
Message-ID: <4A671F3D.5030303@inex.ie>

On 22/07/2009 14:59, Mohammad Khalil wrote:
> what i need to setup SMS server ??
> for example in case of any event (critical one obtained through log) i want SMS to be sent from a server to a certain list of mobile numbers

You need an SMS capable terminal and some software to drive it from your 
monitoring box.  I rather like the Siemens MC35i units with the external 
antenna.  They are very solid and reliable little boxes, with a serial 
interface and a magnetic antenna which holds very well to cabinets.

In terms of driver software, this will depend on your choice of operating 
system and monitoring system.

Nick


From raa at opusnet.com  Wed Jul 22 11:17:22 2009
From: raa at opusnet.com (Ruben Alvarez)
Date: Wed, 22 Jul 2009 08:17:22 -0700
Subject: [c-nsp] OSPF NSSA question
In-Reply-To: <383357750907220109v10fe3d11y2f03d5428b7dc70a@mail.gmail.com>
References: <000001ca0a2c$3eacef00$bc06cd00$@com>
	<383357750907211234m147cf35ak8689bed0759acab7@mail.gmail.com>
	<000101ca0a42$f8f0f260$ead2d720$@com>
	<002101ca0a84$47c00d90$0a00000a@nil.si>
	<383357750907220109v10fe3d11y2f03d5428b7dc70a@mail.gmail.com>
Message-ID: <000201ca0adf$84323c70$8c96b550$@com>

I'm not sure filtering 'out' would work.  Three routers all have one interface, each connecting to the ABR (which has four interfaces, three to the routers in area 1 and one in area 0.)  If I'm filtering out, The ABR wouldn't know which routes are on each of the three routers.  Right?  The three routers have thousands of single host routes spread out over each router.  The ABR knows which router has each host and summarizes to area 0.

-----Original Message-----
From: Mateusz Blaszczyk [mailto:blahu77 at gmail.com] 
Sent: Wednesday, July 22, 2009 1:10 AM
To: Ivan Pepelnjak
Cc: Ruben Alvarez; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] OSPF NSSA question

2009/7/22 Ivan Pepelnjak <ip at ioshints.info>:
> You're probably looking for the "ip ospf database-filter all out" command.

And how the summary LSA with 0/0 would get to the spoke router if that
is filtered out?
(assuming nssa scenario in OP's hub n'spoke topology)

Best Regards,

-mat


From tvarriale at comcast.net  Wed Jul 22 11:20:23 2009
From: tvarriale at comcast.net (Tony Varriale)
Date: Wed, 22 Jul 2009 10:20:23 -0500
Subject: [c-nsp] NAT and PAT on ASA
References: <B5CFB919B5EEF345969F51FAFE6360D50ADC90@GBLDCXMB10.emea.cbre.net><6E21B2BDEF6E714EA0B5BA8D5D0E1401248380AF40@zy-ex1.zyedge.local>
	<3841B0226AC74CADA928D92BA02C7860@flamdt01>
	<6E21B2BDEF6E714EA0B5BA8D5D0E1401248380B078@zy-ex1.zyedge.local>
Message-ID: <DEBDE4C176684C89B1A2BF021CB4EBB8@flamdt01>

I still use the old command sometimes...hehe.

The mask is important in the PIX/ASA as I've demonstrated....especially for 
a person that is new to the area.

Another great example is you put a host mask on a 1 to 1 static but you use 
the block mask for a global pool.  I've seen tons of people get confused 
with that.

tv
----- Original Message ----- 
From: "Ryan West" <rwest at zyedge.com>
To: "Tony Varriale" <tvarriale at comcast.net>; <cisco-nsp at puck.nether.net>
Sent: Wednesday, July 22, 2009 2:52 AM
Subject: RE: [c-nsp] NAT and PAT on ASA


Tony,

I agree that I chose the wrong wording here. It should have read, the ACL 
you're concerned with is inbound on the outside interface.  Otherwise, the 
configlet is fine.

I find the netmask option to be irrelevant, unless you're falling on obvious 
bit boundaries within the same class or doing NAT shifting.  I guess I'm a 
creature of habit and go with the path of least keystrokes.  When you're 
creating isakmp keys, do you type:

tunnel-group 169.254.50.50 type ipsec-l2l
tunnel-group 169.254.50.50 ipsec-attributes
 pre-shared-key BestPractices

or

isakmp key BestPractices address 169.254.50.50

They both produce the same results.  I guess the BU gave up on calling it a 
deprecated command, it hasn't seemed to complain since 7.2.

-ryan

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net 
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Tony Varriale
Sent: Tuesday, July 21, 2009 10:42 PM
To: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] NAT and PAT on ASA

Ryan,

I would recommend completing your static with the appropriate netmask.

Also, ACLs can be applied in and out on an interface on ASA and PIX since
7.0.

tv
----- Original Message ----- 
From: "Ryan West" <rwest at zyedge.com>
To: "Oddiraju, Kiran @ London SMC" <Kiran.Oddiraju at cbre.com>;
<cisco-nsp at puck.nether.net>
Sent: Tuesday, July 21, 2009 1:48 PM
Subject: Re: [c-nsp] NAT and PAT on ASA


> static (inside,outside) 58.66.76.88 192.168.0.100
> show run access-group
> take note of the acl to the outside interface, ACLs are on the ASA are
> inbound.
> access-list <myaccesslist> ext permit icmp any host 58.66.76.88 echo
> access-list <myaccesslist> ext permit tcp any host 58.66.76.88 eq www
>
> -ryan
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Oddiraju, Kiran @
> London SMC
> Sent: Tuesday, July 21, 2009 2:09 PM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] NAT and PAT on ASA
>
> Guys,
>
>
>
> I am new to the ASA world, I have a bunch of external IP's from the ISP
> and I have an inside host that I want to access externally. How do I
> translate an inside ip (192.168.0.100) to an outside address
> (58.66.76.88) on the ASA? I should be able to ping and www from outside
> world to my inside host. Please let me know how to accomplish this.
>
>
>
> Many thanks,
>
> K
>
>
> CB Richard Ellis Limited, Registered Office: St Martin's Court,
> 10 Paternoster Row, London, EC4M 7HP, registered in England and Wales No.
> 3536032.
> Regulated by the RICS and an appointed representative of CB Richard Ellis
> Indirect Investment Services Limited which is authorised and regulated by
> the Financial Services Authority.
>
> This communication is from CB Richard Ellis Limited or one of its
> associated/subsidiary companies. This communication contains information
> which is confidential and may be privileged. If you are not the intended
> recipient,
> please contact the sender immediately. Any use of its contents is strictly
> prohibited
> and you must not copy, send or disclose it, or rely on its contents in any
> way whatsoever.
> Reasonable care has been taken to ensure that this communication
> (and any attachments or hyperlinks contained within it) is free from
> computer viruses.
> No responsibility is accepted by CB Richard Ellis Limited or its
> associated/subsidiary
> companies and the recipient should carry out any appropriate virus checks.
>
> _______________________________________________
> cisco-nsp mailing 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  Wed Jul 22 11:28:26 2009
From: tvarriale at comcast.net (Tony Varriale)
Date: Wed, 22 Jul 2009 10:28:26 -0500
Subject: [c-nsp] NAT and PAT on ASA
References: <B5CFB919B5EEF345969F51FAFE6360D50ADC90@GBLDCXMB10.emea.cbre.net>
	<6E21B2BDEF6E714EA0B5BA8D5D0E1401248380AF40@zy-ex1.zyedge.local>
	<3841B0226AC74CADA928D92BA02C7860@flamdt01>
	<7CFD3224-7B54-4978-AA5C-1C745B98E6F7@gmail.com>
	<4A5876385A1F47DC99764359DF44E94F@flamdt01>
	<4FCEBB7F-9732-4CB4-B52F-A8C5022F809E@gmail.com>
	<70A27A38279041758C3D86C520880ABE@flamdt01>
	<18CD6E42-403E-49B9-9B50-CE4F4D0CA233@gmail.com>
Message-ID: <936BF6B74F40473BBA20DC7E4E25B646@flamdt01>

Your inability to see any value is...again...your opinion.  In fact, it's 
sort of ironic.

Best practices should be taught correctly especially to people with little 
or no experience (the original poster, not Ryan).  Once they understand how 
Cisco implements features and the gotchas, then they can continue on how 
they would like.

I gave Ryan an FYI about the ACL directions since I do not a) know Ryan b) 
know his skill/knowledge level c) make any assumptions.

Reread my original response.  You'll see words like "recommend".

If offering a little insight/assistance on a public list/forum isn't value, 
I'm not sure what you think it is.

tv
----- Original Message ----- 
From: "Binh Phan" <binh.l.phan at gmail.com>
To: "Tony Varriale" <tvarriale at comcast.net>
Cc: <cisco-nsp at puck.nether.net>
Sent: Tuesday, July 21, 2009 11:49 PM
Subject: Re: [c-nsp] NAT and PAT on ASA


> The original user was asking for assistance on what would be the right 
> configuration specific to his scenario which was a host static NAT and 
> Ryan simply provided that.
> I simply saw what you stated was not adding any value to the  discussion 
> other than what seemed to be fault finding, as adding  netmask in this 
> case, OR NOT makes absolutely no difference. Maybe I  read it wrong and if 
> so I apologize.
> Agree, best practices are important but it's irrelevant in this  context 
> or discussion, IMO.
> --Binh
> On Jul 21, 2009, at 9:37 PM, Tony Varriale wrote:
>
>> You pointed out, to me, on how to complete a command.  I don't need 
>> assistance with that.
>>
>> I pointed out that it is best to offer people that are newer to  Cisco 
>> and/or a specific platform best practices (for many reasons).
>>
>> Here's an example from my home ASA on why best practices...are best 
>> practices:
>>
>> homepix(config)# static (inside,outside) 58.66.76.88 192.168.0.100
>> homepix(config)# sh run static
>> static (inside,outside) 58.66.76.88 192.168.0.100 netmask 
>> 255.255.255.255
>> homepix(config)# static (inside,outside) 172.16.0.0 172.16.0.0
>> homepix(config)# sh run static
>> static (inside,outside) 58.66.76.88 192.168.0.100 netmask 
>> 255.255.255.255
>> static (inside,outside) 172.16.0.0 172.16.0.0 netmask 255.255.0.0
>>
>> If you think that's arrogance, that's your opinion.
>>
>> tv
>> ----- Original Message ----- From: "Binh Phan" <binh.l.phan at gmail.com>
>> To: "Tony Varriale" <tvarriale at comcast.net>
>> Cc: <cisco-nsp at puck.nether.net>
>> Sent: Tuesday, July 21, 2009 11:26 PM
>> Subject: Re: [c-nsp] NAT and PAT on ASA
>>
>>
>>> Wow! Arrogance at its best ;-)
>>> Sure been around Cisco long enough and infact been _IN_ Cisco long 
>>> enough..
>>> but I simply wanted to point out the fact that it was uneccessary  what 
>>> you pointed out. No offense!!
>>> On Jul 21, 2009, at 9:18 PM, Tony Varriale wrote:
>>>
>>>> If you haven't been around Cisco long enough to know not to  assume, 
>>>> then be my guest.
>>>>
>>>> But, that's poor advice to offer a person that is somewhat new  (or 
>>>> new) to Cisco.  That's how bad habits start.
>>>>
>>>> tv
>>>> ----- Original Message ----- From: "Binh Phan" <binh.l.phan at gmail.com
>>>> >
>>>> To: "Tony Varriale" <tvarriale at comcast.net>
>>>> Cc: <cisco-nsp at puck.nether.net>
>>>> Sent: Tuesday, July 21, 2009 11:10 PM
>>>> Subject: Re: [c-nsp] NAT and PAT on ASA
>>>>
>>>>
>>>>>
>>>>> On Jul 21, 2009, at 7:42 PM, Tony Varriale wrote:
>>>>>
>>>>>> I would recommend completing your static with the appropriate 
>>>>>> netmask.
>>>>> >>You do not need to specify netmask in this case since it's a /32
>>>>> and will be auto-completed when you enter the command in CLI.
>>>>
>>>> _______________________________________________
>>>> cisco-nsp mailing 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  Wed Jul 22 12:16:41 2009
From: justin at justinshore.com (Justin Shore)
Date: Wed, 22 Jul 2009 11:16:41 -0500
Subject: [c-nsp] 7206 NPE-G2 crash caused by a bouncing DS1
Message-ID: <4A673B69.9060902@justinshore.com>

Has anyone out there experienced any 7206 crashes when they have a 
bouncing DS1 on a PA-MC-2T3-EC?  We've had 2 crashes in about 3 weeks 
time.  They've both generated crashinfo files.  The first auto-rebooted 
itself.  Yesterday's did not.

System returned to ROM by error - a SegV exception, PC 0x349404 at 
16:27:25 UTC Tue Jul 21 2009

The G2 is running 12.4(24)T.  I'm working with TAC who's escalated it to 
the developers.  They're thinking that it's an IOS bug that's being set 
off when a DS1 flaps (though not every time of course).  I don't know if 
severe and lengthy flapping is necessary or if a single instance could 
happen at just the right time to make it crash.  Both times though a DS1 
was bouncing every second or two and had been for days.  Both DS1s were 
members of MLPPP bundles at the time too.

Has anyone else experiences similar issues?

Thanks
  Justin


From lgeyer at gmail.com  Wed Jul 22 12:35:08 2009
From: lgeyer at gmail.com (Laurent Geyer)
Date: Wed, 22 Jul 2009 12:35:08 -0400
Subject: [c-nsp] OSPF NSSA question
In-Reply-To: <000001ca0a2c$3eacef00$bc06cd00$@com>
References: <000001ca0a2c$3eacef00$bc06cd00$@com>
Message-ID: <39647f4d0907220935g4797e4f7m854158a9e65460d0@mail.gmail.com>

On Tue, Jul 21, 2009 at 1:54 PM, Ruben Alvarez<raa at opusnet.com> wrote:
>
>?Now the ABR has all the N2 routes for the three routers. ?But so
> do all three routers, which isn't needed. ?They only have one interface and
> a default route. ?Is there a way I can ignore all routes in the area except
> the default route coming from the ABR?

If you're set on keeping the routers in a NSSA you could simply
disable redistribution into the NSSA area by adding
'no-redistribution' to the area config.

This will effectively keep type 5 LSAs from being advertised into the NSSA.

Realistically it makes more sense to turn the areas into totally
stubby areas. I don't see what benefit you gain from keeping the
routers in a NSSA.

- Laurent

From brhedlun at cisco.com  Wed Jul 22 12:41:26 2009
From: brhedlun at cisco.com (Brad Hedlund)
Date: Wed, 22 Jul 2009 11:41:26 -0500
Subject: [c-nsp] 7206 NPE-G2 crash caused by a bouncing DS1
In-Reply-To: <4A673B69.9060902@justinshore.com>
Message-ID: <C68CAB66.3986B%brhedlun@cisco.com>

Justin,

Just curious, was the DS1 participating in a routing protocol, and if so did
you have IP event dampening and/or BGP dampening configured?


Cheers,

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



On 7/22/09 11:16 AM, "Justin Shore" <justin at justinshore.com> wrote:

> Has anyone out there experienced any 7206 crashes when they have a
> bouncing DS1 on a PA-MC-2T3-EC?  We've had 2 crashes in about 3 weeks
> time.  They've both generated crashinfo files.  The first auto-rebooted
> itself.  Yesterday's did not.
> 
> System returned to ROM by error - a SegV exception, PC 0x349404 at
> 16:27:25 UTC Tue Jul 21 2009
> 
> The G2 is running 12.4(24)T.  I'm working with TAC who's escalated it to
> the developers.  They're thinking that it's an IOS bug that's being set
> off when a DS1 flaps (though not every time of course).  I don't know if
> severe and lengthy flapping is necessary or if a single instance could
> happen at just the right time to make it crash.  Both times though a DS1
> was bouncing every second or two and had been for days.  Both DS1s were
> members of MLPPP bundles at the time too.
> 
> Has anyone else experiences similar issues?
> 
> 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 jlewis at lewis.org  Wed Jul 22 13:43:36 2009
From: jlewis at lewis.org (Jon Lewis)
Date: Wed, 22 Jul 2009 13:43:36 -0400 (EDT)
Subject: [c-nsp] OSPF NSSA question
In-Reply-To: <39647f4d0907220935g4797e4f7m854158a9e65460d0@mail.gmail.com>
References: <000001ca0a2c$3eacef00$bc06cd00$@com>
	<39647f4d0907220935g4797e4f7m854158a9e65460d0@mail.gmail.com>
Message-ID: <Pine.LNX.4.61.0907221338390.4187@soloth.lewis.org>

On Wed, 22 Jul 2009, Laurent Geyer wrote:

> If you're set on keeping the routers in a NSSA you could simply
> disable redistribution into the NSSA area by adding
> 'no-redistribution' to the area config.
>
> This will effectively keep type 5 LSAs from being advertised into the NSSA.
>
> Realistically it makes more sense to turn the areas into totally
> stubby areas. I don't see what benefit you gain from keeping the
> routers in a NSSA.

Simpler configuration?  I'm going to assume the routers in the NSSA are 
exporting (probably static and or connected) routes into OSPF and can't do 
this in a regular stub area.

I have an NSSA for some layer 3 switches doing this.  The switches can 
handle a limited number of routes and really don't gain anything by 
carrying our full internal routes.

----------------------------------------------------------------------
  Jon Lewis                   |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

From brandon at burn.net  Wed Jul 22 14:16:29 2009
From: brandon at burn.net (Brandon Applegate)
Date: Wed, 22 Jul 2009 14:16:29 -0400 (EDT)
Subject: [c-nsp] MPLS MTU / Jumbo frames etc.
Message-ID: <Pine.LNX.4.64.0907221400360.1986@orbital.burn.net>

I know this has been covered, at least in part on this list before, and I 
have read those posts.  However, I'm still trying to wrap my head around 
what is happening internally (or rather on the wire) in the various 
scenarios.

Scenario #1
===========
10 gig interface (ES20 CXL based) - default mtu 1500
MPLS turned on, no 'mpls mtu' command

Default, packets have one label, I get icmp 3,4 frag needed back telling 
me to go to 1496 for 1500 byte (linux ping -M do -s 1472)

Scenario #2
===========
10 gig interface (ES20 CXL based) - default mtu 1500
MPLS turned on - 'mpls mtu override 1508' added

Default, packets have one label, packet is '1504', no icmp frag
Interface can do up to 9216 mtu, so 1500+N labels == not a big deal (??)

Scenario #3
===========
10 gig interface (ES20 CXL based) - mtu changed to 9216
MPLS turned on - mpls mtu == interface mtu by default (does not show up in 
config)

One label packet, with 9216 size (linux ping -M do -s 9188) goes through, 
with no icmp frag needed.

So I'm confused on what's happening in one scenario vs. another.  It seems 
that in scenario 1, the 'outer' MTU is 'signalling' down and kicking off a 
icmp frag needed.

Scenario 2 goes through because we are telling the router it's allowed to 
send a 'baby-giant' (i hate that term).

Scenario 3 really gets me though.  Why doesnt it complain and tell me icmp 
frag to 9212 or something ?  Isnt the frame 9220 when it's all said and 
done ?  Is the router fragmenting this in software at the 'mpls level' and 
just not telling me ?  Should I set mtu down to 9212 or something to make 
sure that the router NEVER frags frames ?

I guess a fireaxe solution would be for us to simply define 'jumbo frames' 
in our network as 9000 bytes, period.  But I'd like to actually understand 
why this behaviour seems to change as I slide the MTU around.  I want to 
make sure that our $$$ isnt being wasted by killing the CPU with 
fragmentation (if thats whats happening, again scenario 3 is really 
puzzling me).

Apologizes ahead of time if all this info is out there somewhere, again 
I've read Ivan's page on this, CCO docs, archives etc.  Thanks in advance.

--
Brandon Applegate - CCIE 10273
PGP Key fingerprint:
7407 DC86 AA7B A57F 62D1 A715 3C63 66A1 181E 6996
"SH1-0151.  This is the serial number, of our orbital gun."


From gert at greenie.muc.de  Wed Jul 22 14:27:30 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Wed, 22 Jul 2009 20:27:30 +0200
Subject: [c-nsp] MPLS MTU / Jumbo frames etc.
In-Reply-To: <Pine.LNX.4.64.0907221400360.1986@orbital.burn.net>
References: <Pine.LNX.4.64.0907221400360.1986@orbital.burn.net>
Message-ID: <20090722182730.GQ290@greenie.muc.de>

Hi,

On Wed, Jul 22, 2009 at 02:16:29PM -0400, Brandon Applegate wrote:
> Scenario 3 really gets me though.  Why doesnt it complain and tell me icmp 
> frag to 9212 or something ?  Isnt the frame 9220 when it's all said and 
> done ?  Is the router fragmenting this in software at the 'mpls level' and 
> just not telling me ?  Should I set mtu down to 9212 or something to make 
> sure that the router NEVER frags frames ?

I'd bet that the linux box is not sending full-sized 9220 packets, but
fragmenting inside.

Unless the linux box has 10GE to the router, and is allowed to use full
9220 MTU (via ifconfig and/or "ip route"), it will send 1500 byte fragments.

So the router will never have to worry on whether or not the linux packet
+ MPLS overhead will fit into its MTU...

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/20090722/57406661/attachment.bin>

From jeff-kell at utc.edu  Wed Jul 22 14:31:21 2009
From: jeff-kell at utc.edu (Jeff Kell)
Date: Wed, 22 Jul 2009 14:31:21 -0400
Subject: [c-nsp] FWSM access permissions confusion between interfaces
Message-ID: <4A675AF9.9000404@utc.edu>

Greetings.  I have an unusual (perhaps) FWSM application that is not
quite working out as expected, and after several variations from
different angles, still not producing quite the desired result.

I have a 6509 doing VRFs for different campus communities, and since
many of our services / applications are shared, have separate VRFs for
groups of end-users as well as groups of applications /servers.

I had hoped that using the FWSM NAT controls on the interfaces would
provide the first level of granularity with respect to access controls,
defining "which user VRFs" could see "which server VRFs" without
providing a full head-on mesh of everything together.

To try to simplify the setup, here are three user groups and three
service groups, along with a "common" body of services shared by all:

   red -- vlan100        vlan700 -- orange
yellow -- vlan200        vlan800 -- green
  blue -- vlan300        vlan900 -- purple

              white -- vlan1000

All vlans should have access to vlan1000 (inbound)
red and yellow users should have access to orange services.
yellow and blue users should have access to green services.
red and blue users should have access to purple services.

There is no IP address overlap, so there is really no "NAT" required;
but you have to have some definition to allow connections to take place.

If I use "NAT exemption" it seems to let everybody see everyone else,
regardless of the security level assigned to the interface.

This "can" be accomplished by some very complicated ACLs on each
interface, but I would end up with a "long" list of permitted source
networks for each service to permit (and there are many such services
and destination servers).

I would like to restrict access to just the desired subnets (first) with
the appropriate NAT controls, if that is possible, so that the ACLs
would be concerned primarily with just the service/port details.

The documentation implies this is possible (defining NAT rules for
specific source/destination interface pairs) but I can't quite seem to
get the right configuration to work, or properly orient this diagram to
fit the traditional "inside/outside" paradigm the FWSM dialogue expects.

Anyone been there / done that / can offer any suggestions?

Many thanks in advance,

Jeff

From brandon at burn.net  Wed Jul 22 14:37:16 2009
From: brandon at burn.net (Brandon Applegate)
Date: Wed, 22 Jul 2009 14:37:16 -0400 (EDT)
Subject: [c-nsp] MPLS MTU / Jumbo frames etc.
In-Reply-To: <20090722182730.GQ290@greenie.muc.de>
References: <Pine.LNX.4.64.0907221400360.1986@orbital.burn.net>
	<20090722182730.GQ290@greenie.muc.de>
Message-ID: <Pine.LNX.4.64.0907221434460.1986@orbital.burn.net>

On Wed, 22 Jul 2009, Gert Doering wrote:

> Hi,
>
> On Wed, Jul 22, 2009 at 02:16:29PM -0400, Brandon Applegate wrote:
>> Scenario 3 really gets me though.  Why doesnt it complain and tell me icmp
>> frag to 9212 or something ?  Isnt the frame 9220 when it's all said and
>> done ?  Is the router fragmenting this in software at the 'mpls level' and
>> just not telling me ?  Should I set mtu down to 9212 or something to make
>> sure that the router NEVER frags frames ?
>
> I'd bet that the linux box is not sending full-sized 9220 packets, but
> fragmenting inside.

I'm sending full 9216 packets.  Confirmed with tcpdump as I'm sending. 
The 9220 number is what the frame looks like after 1 MPLS label.  Hence my 
confusion as to how scenario 3 is working without icmp unreachables etc 
(ala scenario 1).

>
> Unless the linux box has 10GE to the router, and is allowed to use full
> 9220 MTU (via ifconfig and/or "ip route"), it will send 1500 byte fragments.

Yes I have my MTU cranked up in linux and am doing all of this 
intentionally as a test.  Unless tcpdump is lying to me, these are 
unfragmented 9216-byte frames leaving and coming back with no 'complaints' 
in sceneraio 3.

--
Brandon Applegate - CCIE 10273
PGP Key fingerprint:
7407 DC86 AA7B A57F 62D1 A715 3C63 66A1 181E 6996
"SH1-0151.  This is the serial number, of our orbital gun."




From gert at greenie.muc.de  Wed Jul 22 14:47:48 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Wed, 22 Jul 2009 20:47:48 +0200
Subject: [c-nsp] MPLS MTU / Jumbo frames etc.
In-Reply-To: <Pine.LNX.4.64.0907221434460.1986@orbital.burn.net>
References: <Pine.LNX.4.64.0907221400360.1986@orbital.burn.net>
	<20090722182730.GQ290@greenie.muc.de>
	<Pine.LNX.4.64.0907221434460.1986@orbital.burn.net>
Message-ID: <20090722184748.GR290@greenie.muc.de>

Hi,

On Wed, Jul 22, 2009 at 02:37:16PM -0400, Brandon Applegate wrote:
> >I'd bet that the linux box is not sending full-sized 9220 packets, but
> >fragmenting inside.
[..]
> Yes I have my MTU cranked up in linux and am doing all of this 
> intentionally as a test.  Unless tcpdump is lying to me, these are 
> unfragmented 9216-byte frames leaving and coming back with no 'complaints' 
> in sceneraio 3.

In that case, I don't know either.  You *should* indeed see ICMPs (or 
black holing) then.

I've just stumbled across the "I want to diagnose something in the network
and the test host is fragmenting behind my back" problem too often, so it
seemed quite likely...

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/20090722/1833a8d5/attachment-0001.bin>

From justin at justinshore.com  Wed Jul 22 15:10:28 2009
From: justin at justinshore.com (Justin Shore)
Date: Wed, 22 Jul 2009 14:10:28 -0500
Subject: [c-nsp] 7206 NPE-G2 crash caused by a bouncing DS1
In-Reply-To: <C68CAB66.3986B%brhedlun@cisco.com>
References: <C68CAB66.3986B%brhedlun@cisco.com>
Message-ID: <4A676424.3080306@justinshore.com>

The MLPPP interface was part of a VRF, had an IP and had uRPF 
configured.  Other than that no L3 IGPs.  I do use BGP dampening but I'm 
distributing this route into iBGP.  MP-BGP to carry the MPLS/VPN vpnv4 
routes but not using BGP for ip4 address-family routes.  I should also 
mention that there are 2 DS1 in the bundle and that the other DS1 did 
not go down (until the crash) to the best of my knowledge.  So the 
bundle should have stayed up even though one DS1 was flapping in the breeze.


Justin


Brad Hedlund wrote:
> Justin,
> 
> Just curious, was the DS1 participating in a routing protocol, and if so did
> you have IP event dampening and/or BGP dampening configured?


From tvarriale at comcast.net  Wed Jul 22 15:18:37 2009
From: tvarriale at comcast.net (Tony Varriale)
Date: Wed, 22 Jul 2009 14:18:37 -0500
Subject: [c-nsp] FWSM access permissions confusion between interfaces
References: <4A675AF9.9000404@utc.edu>
Message-ID: <8BBCA5A800DF41AAAE7FE9803F5F863F@flamdt01>

Have you tried policy static NATs?  Aka if source and destination match ACL 
perform static for specified interfaces.

tv
----- Original Message ----- 
From: "Jeff Kell" <jeff-kell at utc.edu>
To: "cisco-nsp" <cisco-nsp at puck.nether.net>
Sent: Wednesday, July 22, 2009 1:31 PM
Subject: [c-nsp] FWSM access permissions confusion between interfaces


> Greetings.  I have an unusual (perhaps) FWSM application that is not
> quite working out as expected, and after several variations from
> different angles, still not producing quite the desired result.
>
> I have a 6509 doing VRFs for different campus communities, and since
> many of our services / applications are shared, have separate VRFs for
> groups of end-users as well as groups of applications /servers.
>
> I had hoped that using the FWSM NAT controls on the interfaces would
> provide the first level of granularity with respect to access controls,
> defining "which user VRFs" could see "which server VRFs" without
> providing a full head-on mesh of everything together.
>
> To try to simplify the setup, here are three user groups and three
> service groups, along with a "common" body of services shared by all:
>
>   red -- vlan100        vlan700 -- orange
> yellow -- vlan200        vlan800 -- green
>  blue -- vlan300        vlan900 -- purple
>
>              white -- vlan1000
>
> All vlans should have access to vlan1000 (inbound)
> red and yellow users should have access to orange services.
> yellow and blue users should have access to green services.
> red and blue users should have access to purple services.
>
> There is no IP address overlap, so there is really no "NAT" required;
> but you have to have some definition to allow connections to take place.
>
> If I use "NAT exemption" it seems to let everybody see everyone else,
> regardless of the security level assigned to the interface.
>
> This "can" be accomplished by some very complicated ACLs on each
> interface, but I would end up with a "long" list of permitted source
> networks for each service to permit (and there are many such services
> and destination servers).
>
> I would like to restrict access to just the desired subnets (first) with
> the appropriate NAT controls, if that is possible, so that the ACLs
> would be concerned primarily with just the service/port details.
>
> The documentation implies this is possible (defining NAT rules for
> specific source/destination interface pairs) but I can't quite seem to
> get the right configuration to work, or properly orient this diagram to
> fit the traditional "inside/outside" paradigm the FWSM dialogue expects.
>
> Anyone been there / done that / can offer any suggestions?
>
> Many thanks in advance,
>
> 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 jeff-kell at utc.edu  Wed Jul 22 16:13:50 2009
From: jeff-kell at utc.edu (Jeff Kell)
Date: Wed, 22 Jul 2009 16:13:50 -0400
Subject: [c-nsp] quick 3750 question...
Message-ID: <4A6772FE.3080407@utc.edu>

Are the stack members "hot swappable" ?

Or is it power-cycle time when changing the stack cable configurations?

[Wanting to add a new member...]

Jeff

From raa at opusnet.com  Wed Jul 22 16:13:41 2009
From: raa at opusnet.com (Ruben Alvarez)
Date: Wed, 22 Jul 2009 13:13:41 -0700
Subject: [c-nsp] OSPF NSSA question
In-Reply-To: <Pine.LNX.4.61.0907221338390.4187@soloth.lewis.org>
References: <000001ca0a2c$3eacef00$bc06cd00$@com>	<39647f4d0907220935g4797e4f7m854158a9e65460d0@mail.gmail.com>
	<Pine.LNX.4.61.0907221338390.4187@soloth.lewis.org>
Message-ID: <001801ca0b08$eb410030$c1c30090$@com>

Yes the routers in area 1 are set to redistribute connected and static.
They do DSL aggregation and if you can imagine I need some flexibility with
those addresses (approx /20.)  I'll move IP pools and /30 -/29 networks from
router to router as customers come and go.

I like how it's setup now because area 0 gets a few summarized routes and
have the flexibility to let the ABR dynamically do the routing for the
aggregation routers.  Only downside is the aggregation routers get all the
N2 routes when a default route is sufficient.  I'm reading about the "area 1
no-redistribution" command.  It reads external routes will not be flooded
into the NSSA.  So I read that as a router will advertise its routes and not
the routes it receives from other routers.  But wouldn't aggregationrouter1
still receive routes from aggregationrouter2?  It just wouldn't re-advertise
them.

I'm thinking the best plan would be to have each router in its own area.  As
far as what I read about stub, I can't redistribute static or connected
routes into OSPF which is the whole reason why I'm doing this.  Someone said
a stub area can have multiple routers.  Wikipedia says it can't.  

" A stub area is an area which does not receive external route
advertisements. It may be configured to reduce many route advertisements
into an area when the routing table consists of mostly external routes.
Instead of the external routes, a default route is advertised to the stub
area. A stub area has only one OSPF router, cannot contain an AS boundary
router (ASBR) and routes cannot be distributed from other protocols into the
stub area."

Can someone confirm that?

Thanks all.



-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Jon Lewis
Sent: Wednesday, July 22, 2009 10:44 AM
To: Laurent Geyer
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] OSPF NSSA question

On Wed, 22 Jul 2009, Laurent Geyer wrote:

> If you're set on keeping the routers in a NSSA you could simply
> disable redistribution into the NSSA area by adding
> 'no-redistribution' to the area config.
>
> This will effectively keep type 5 LSAs from being advertised into the
NSSA.
>
> Realistically it makes more sense to turn the areas into totally
> stubby areas. I don't see what benefit you gain from keeping the
> routers in a NSSA.

Simpler configuration?  I'm going to assume the routers in the NSSA are 
exporting (probably static and or connected) routes into OSPF and can't do 
this in a regular stub area.

I have an NSSA for some layer 3 switches doing this.  The switches can 
handle a limited number of routes and really don't gain anything by 
carrying our full internal routes.

----------------------------------------------------------------------
  Jon Lewis                   |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


From brandon at burn.net  Wed Jul 22 16:13:51 2009
From: brandon at burn.net (Brandon Applegate)
Date: Wed, 22 Jul 2009 16:13:51 -0400 (EDT)
Subject: [c-nsp] MPLS MTU / Jumbo frames etc.
In-Reply-To: <Pine.LNX.4.64.0907221400360.1986@orbital.burn.net>
References: <Pine.LNX.4.64.0907221400360.1986@orbital.burn.net>
Message-ID: <Pine.LNX.4.64.0907221611420.1986@orbital.burn.net>

On Wed, 22 Jul 2009, Brandon Applegate wrote:

> I know this has been covered, at least in part on this list before, and I 
> have read those posts.  However, I'm still trying to wrap my head around what 
> is happening internally (or rather on the wire) in the various scenarios.
>
> Scenario #3
> ===========
> 10 gig interface (ES20 CXL based) - mtu changed to 9216
> MPLS turned on - mpls mtu == interface mtu by default (does not show up in 
> config)
>
> One label packet, with 9216 size (linux ping -M do -s 9188) goes through, 
> with no icmp frag needed.
>
> So I'm confused on what's happening in one scenario vs. another.  It seems 
> that in scenario 1, the 'outer' MTU is 'signalling' down and kicking off a 
> icmp frag needed.
>
> Scenario 2 goes through because we are telling the router it's allowed to 
> send a 'baby-giant' (i hate that term).
>
> Scenario 3 really gets me though.  Why doesnt it complain and tell me icmp 
> frag to 9212 or something ?  Isnt the frame 9220 when it's all said and done 
> ?  Is the router fragmenting this in software at the 'mpls level' and just 
> not telling me ?  Should I set mtu down to 9212 or something to make sure 
> that the router NEVER frags frames ?
>
> I guess a fireaxe solution would be for us to simply define 'jumbo frames' in 
> our network as 9000 bytes, period.  But I'd like to actually understand why 
> this behaviour seems to change as I slide the MTU around.  I want to make 
> sure that our $$$ isnt being wasted by killing the CPU with fragmentation (if 
> thats whats happening, again scenario 3 is really puzzling me).
>

I think I figured (part of) this out.  Packets to the router != packets 
through the router.  Trying to ping something on the far side with packet 
size of 9188/9216 gets me the expected icmp frag @ 9212.  I still think 
I'm going to proclaim that jumbo == 9000 to make it easier for server / 
storage guys to remember anyway :)

--
Brandon Applegate - CCIE 10273
PGP Key fingerprint:
7407 DC86 AA7B A57F 62D1 A715 3C63 66A1 181E 6996
"SH1-0151.  This is the serial number, of our orbital gun."




From rwest at zyedge.com  Wed Jul 22 16:22:36 2009
From: rwest at zyedge.com (Ryan West)
Date: Wed, 22 Jul 2009 16:22:36 -0400
Subject: [c-nsp] quick 3750 question...
In-Reply-To: <4A6772FE.3080407@utc.edu>
References: <4A6772FE.3080407@utc.edu>
Message-ID: <6E21B2BDEF6E714EA0B5BA8D5D0E1401248380B118@zy-ex1.zyedge.local>

You can add a new member with little to worry about.  A new, unconfigured switch should join the stack automatically.

-ryan

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Jeff Kell
Sent: Wednesday, July 22, 2009 4:14 PM
To: cisco-nsp
Subject: [c-nsp] quick 3750 question...

Are the stack members "hot swappable" ?

Or is it power-cycle time when changing the stack cable configurations?

[Wanting to add a new member...]

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 Jeff.Wojciechowski at midlandpaper.com  Wed Jul 22 16:29:07 2009
From: Jeff.Wojciechowski at midlandpaper.com (Jeff Wojciechowski)
Date: Wed, 22 Jul 2009 15:29:07 -0500
Subject: [c-nsp] quick 3750 question...
In-Reply-To: <4A6772FE.3080407@utc.edu>
References: <4A6772FE.3080407@utc.edu>
Message-ID: <6B8401A83219DF499C34DEAEE9A599921256118570@XBOX.midlandpaper.com>

Technically I think they are - however, if your existing stack is in production I would prefer to do the following:

1) Manually update the IOS of the new switch to match the IOS of the existing members (got hung up here once because the flash didn't have room to hold both the existing IOS image and the image running image of the stack)
2) *****Add the member at a time that you are not in production JUST IN CASE the stack reboots. I prefer to err on the side of caution!
3) Make sure you set stack master, etc. I think if don't there is a chance ports might get renumbered...

Just my 2 cents and someone please correct me if I am wrong... :o)


-Jeff


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Jeff Kell
Sent: Wednesday, July 22, 2009 3:14 PM
To: cisco-nsp
Subject: [c-nsp] quick 3750 question...

Are the stack members "hot swappable" ?

Or is it power-cycle time when changing the stack cable configurations?

[Wanting to add a new member...]

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 raa at opusnet.com  Wed Jul 22 16:32:05 2009
From: raa at opusnet.com (Ruben Alvarez)
Date: Wed, 22 Jul 2009 13:32:05 -0700
Subject: [c-nsp] OSPF NSSA question
In-Reply-To: <dd3e48e0907221202y19c87412pb141389dcdd065e@mail.gmail.com>
References: <000001ca0a2c$3eacef00$bc06cd00$@com>
	<dd3e48e0907221202y19c87412pb141389dcdd065e@mail.gmail.com>
Message-ID: <001901ca0b0b$7b6da710$7248f530$@com>

Thanks.  that's sounds like what I want, but it says:

 

"Configure this command on NSSA ABRs only. After you define the NSSA totally
stub area, Area 1 has these characteristics in addition to the NSSA
characteristics:

 

      -No type 3 or 4 summary LSAs are allowed in Area 1. This means no
inter-area routes are allowed in Area 1.

 

      -A default route is injected into the NSSA totally stub area as a type
3 summary LSA."

 

So no IA routes are allowed in area 1.  But I have N2 routes?

 

From: samuel vuillaume [mailto:vuillaumes at gmail.com] 
Sent: Wednesday, July 22, 2009 12:02 PM
To: Ruben Alvarez
Subject: Re: [c-nsp] OSPF NSSA question

 

Hi there,

you should take a peak to
http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094a88
.shtml#definestub

NSSA totally Stubby area.... 

On Tue, Jul 21, 2009 at 1:54 PM, Ruben Alvarez <raa at opusnet.com> wrote:

Hello,

I have a question.  I have recently setup a second OSPF area.  The ABR has
three routers connected to it (area 1) in a hub and spoke configuration.
The routers get a default route to the ABR via default information
originate.  Now the ABR has all the N2 routes for the three routers.  But so
do all three routers, which isn't needed.  They only have one interface and
a default route.  Is there a way I can ignore all routes in the area except
the default route coming from the ABR?


_______________________________________________
cisco-nsp mailing list  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  Wed Jul 22 16:54:35 2009
From: tvarriale at comcast.net (Tony Varriale)
Date: Wed, 22 Jul 2009 15:54:35 -0500
Subject: [c-nsp] quick 3750 question...
References: <4A6772FE.3080407@utc.edu>
Message-ID: <F7D5F9C0080A457A8BDEC4F7CE5F6260@flamdt01>

Yes they are.  The biggy to watch out for is when you remove a member.  Make 
sure the member you want to remove is powered off before removing the stack 
cables.

A minor item is to make sure when removing the stack cables to insert the 
new switch, make sure you don't isolate one of the in-use switches...hehe.

You can upgrade the code previous to insertion or after you get it to join. 
I normally do it before as it's smoother.  Also don't forget to provision 
the imcoming switch on the existing stack.

tv
----- Original Message ----- 
From: "Jeff Kell" <jeff-kell at utc.edu>
To: "cisco-nsp" <cisco-nsp at puck.nether.net>
Sent: Wednesday, July 22, 2009 3:13 PM
Subject: [c-nsp] quick 3750 question...


> Are the stack members "hot swappable" ?
>
> Or is it power-cycle time when changing the stack cable configurations?
>
> [Wanting to add a new member...]
>
> 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 walter.keen at RainierConnect.net  Wed Jul 22 18:04:11 2009
From: walter.keen at RainierConnect.net (Walter Keen)
Date: Wed, 22 Jul 2009 15:04:11 -0700
Subject: [c-nsp] Cisco 7600 rate limiting
Message-ID: <4A678CDB.3040607@rainierconnect.net>

Any suggestions on this?

I'm trying to rate-limit a vlan at X mbit (4 in this case) and seeing 
rate-limiting working downstream to the customer but not when traffic is 
originating from the customer.

Customer access is via a dot1q trunk (with a switch at the cust. site 
handing off untagged traffic for that vlan)

7600 hardware is a 7606-s, rsp720-3cxl, running 12.2(33)SRC2, with a 
single ws-6724sfp card.  Both the dot1q trunk bringing in customer 
connections and the routed port it's destined for exist on the same card.

class-map match-any RATELIMIT-4mbit
  match any
policy-map TEST-4mbit
 description TESTING-ONLY
  class RATELIMIT-4mbit
   police cir 4000000
    conform-action transmit
    exceed-action drop
    violate-action drop
interface Vlan1060
 ip address 69.10.218.9 255.255.255.248
 service-policy input TEST-4mbit
 service-policy output TEST-4mbit
!


From lgeyer at gmail.com  Wed Jul 22 18:15:48 2009
From: lgeyer at gmail.com (Laurent Geyer)
Date: Wed, 22 Jul 2009 18:15:48 -0400
Subject: [c-nsp] OSPF NSSA question
In-Reply-To: <001801ca0b08$eb410030$c1c30090$@com>
References: <000001ca0a2c$3eacef00$bc06cd00$@com>
	<39647f4d0907220935g4797e4f7m854158a9e65460d0@mail.gmail.com>
	<Pine.LNX.4.61.0907221338390.4187@soloth.lewis.org>
	<001801ca0b08$eb410030$c1c30090$@com>
Message-ID: <39647f4d0907221515q68a601canb3f116a61db3e606@mail.gmail.com>

On Wed, Jul 22, 2009 at 4:13 PM, Ruben Alvarez<raa at opusnet.com> wrote:
>
> " A stub area is an area which does not receive external route
> advertisements. It may be configured to reduce many route advertisements
> into an area when the routing table consists of mostly external routes.
> Instead of the external routes, a default route is advertised to the stub
> area. A stub area has only one OSPF router, cannot contain an AS boundary
> router (ASBR) and routes cannot be distributed from other protocols into the
> stub area."
>
> Can someone confirm that?
>
> Thanks all.

Like Jon mentioned, you cannot redistribute connected and statics into
OSPF from a totally stubby area.

If your main concern with your NSSA right now are the external routes
that are being advertised into your NSSA from the ABR, you can
eliminate those advertisements by disabling redistribution.

On the ABR:

router ospf <process>
  area 1 nssa no-redistribution no-summary

- Laurent

From jp at saucer.midcoast.com  Wed Jul 22 18:02:39 2009
From: jp at saucer.midcoast.com (jp)
Date: Wed, 22 Jul 2009 18:02:39 -0400
Subject: [c-nsp] OT: Network documentation tool
In-Reply-To: <1247930754.5386.5.camel@abehat.net.rm.dk>
References: <1247930754.5386.5.camel@abehat.net.rm.dk>
Message-ID: <20090722220239.GA22975@saucer.midcoast.com>

We use Mediawiki. It's easy to customize if you don't like the left 
frame. I like the easy editing of wikis, searching, history management, 
web based access, etc... With the prevalence of wikipedia and lots of 
software projects adopting wikis for documentation, most technical 
people should not consider them difficult.

Lists of sites, important information about the sites, (local contact 
info, power outage reporting info, alarm codes, combo lock codes, and so 
on). We've also been known to write down when things were installed or 
upgraded for warranty or maintenance purposes.

We also have written instructions for various procedures for different 
parts of the organization, so if someone goes on vacation or gets hit by 
a bus, other people can fill in. 

We also have a gallery. (using gallery 1.6 or jallery), so we can have 
photos of the sites. It is good for guiding someone over the phone who 
is onsite and you are not familiar with what they are looking at. We 
also use it to verify line of site for wireless things with rooftop or 
towertop panoramas from each site.

On Sat, Jul 18, 2009 at 05:25:53PM +0200, Peter Rathlev wrote:
> Kind of OT, but hopefully someone has an opinion anyway. :-)
> 
> I'm looking for the perfect documentation tool for network
> documentation. We already have tools to map out the network and lots of
> management tools, but what I'm looking for is something like a
> repository to store and update all the written documentation, like
> procedures and so on.
> 
> We've been looking at different Wikis, among others the Mediawiki suite,
> and it looks promising but in my eyes seem a little much when we could
> cope with somthing much simpler. We've also looked at document
> repositories like Owl. We've even looked at Sharepoint. None of these
> tools seem to be just right though.
> 
> What do people use to store documentation? Currently we use a CIFS share
> but this seems clumsy at best.
> 
> Any input is appreciated. :-)
> 
> 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/

-- 
/*
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 mumetahh at yahoo.co.id  Wed Jul 22 19:20:33 2009
From: mumetahh at yahoo.co.id (==N==)
Date: Thu, 23 Jul 2009 07:20:33 +0800 (SGT)
Subject: [c-nsp] Free NMS Tools
In-Reply-To: <323aca890907181315k325c45e6t97814af27f8f33db@mail.gmail.com>
Message-ID: <969145.20435.qm@web76312.mail.sg1.yahoo.com>

Dear Friends ,

I thank you for the suggesstion for NMS tools, base on the suggestion I would PoC some t of them before implemented in real network. to see the feature.


Regards,



==? suryantofang ==
http://suryantofang.wordpress.com

--- Pada Sab, 18/7/09, Pavel Skovajsa <pavel.skovajsa at gmail.com> menulis:

Dari: Pavel Skovajsa <pavel.skovajsa at gmail.com>
Judul: Re: [c-nsp] Free NMS Tools
Kepada: "Saku Ytti" <saku at ytti.fi>, cisco-nsp at puck.nether.net
Tanggal: Sabtu, 18 Juli, 2009, 10:15 PM

Hi Saku,

I fully symphatetize with everything you said. The problem is that
there is NO system on the world with all of below, none of the
Nagios/OpenNMS etc. system do automatically what you have decribed
below. Most of them reduce their default activity to "let's ping it
and see what happens".

I am sure that some of those systems are open and prepared enough to
have this configured in some complicated manual way, and trigger
alarms based on this. Maybe also (dreaming) automatically logging onto
the device and getting necessary command output and possibly fixing a
simple situation (dreaming and smoking too much).

A good example of a beginning of such automatic expert system is Cisco
Output Interpreter.

Therefore all of this manual activity needs to be performed on per
device basis, which is time&effort consuming, which in our everyday
reality turns into people not doing it at all and stick with the old
''let's ping it and see what happens"

-Pavel


On Fri, Jul 17, 2009 at 9:01 AM, Saku Ytti<saku at ytti.fi> wrote:
> On (2009-07-03 14:00 +0100), Mario Spinthiras wrote:
>
> Hey,
>
>> I would say Zenoss is looking good because of the inventory management you
>> can do and because of the logical structure it puts everything in. I wrote
>>
>> Everything else just seems inadequate or poor.
>
> I recently spent few moments evaluating zenoss and was not impressed. To me
> all OSS NMS solutions out seem like they are made by coder-in-server-admin
> not coder-in-network-admin, and as such seem to have much more integration
> with servers than with network, zenoss seems like no exception.
>
> My main grief with NMS I've looked at is virtually no integration with network
> devices out of the box. Why don't they ship with MIBs or just specific OIDs
> for few top vendors important traps etc? Adding appropriate reaction
> classification. Networking is comparatively homogeneous environment, unlike
> server admins who have high variance in OS and applications, network
> operators out there have very similar requirements, allowing very advanced
> integration out-of-the-box. People want NMS to automatically monitor BGP,
> OSPF, IS-IS, LDP, status of some other CPU/memory than just control-plane
> pending few minutes thinking it would be easy to add lot of really common
> things here, that would be desired by very many network operators.
>
> Other thing that annoys me is how SNMP pollers are implemented, they're
> blocking, giving sucky performance on misbehaving or down nodes. And
> even still puzzlingly slow. While having SNMP poller poll 140k OID
> per second on 386 class PC is rather trivial, using two process strategy,
> where single process spews packets outs, and another listens what comes
> back, completely asynchronous, agnostic to any problem host may have.
> I've also only seen alarms based on absolute values of different counters,
> like CPU, memory, iface error counters etc. While I'd like automatic
> trending alarms, so if my memory use for past 5 months was relatively
> static, then for few consecutive days has increased steadily, it is
> likely memory leak, and I want to know about it, even if I have GB's of
> free memory. This type of 'trending' module should be relatively
> easy, and could be reused by any counter values.
>
> I demoed zenoss with 27 routers and it froze trying to poll their
> interface (granted there are very many interfaces). (2.3GHz Intel,
> with 2GB of memory), turning performance graphs off helped, of course.
> Trying to use zenpacks to add (3rd party provided) Cisco MIBs took
> hours and failed due to exhausted disk space, not sure which device
> it was, as it didn't tell, but smallest is /tmp with 186MB free.
>
> I'd be happy to pay zenoss enteprise costs, if it would have
> basics integration with network, but value it actually delivers
> to me, is actually so modest, you can pick up any other
> NMS there or hack something on your own. Since most time would
> be committed anyhow adding basic functionality.
>
> Thanks,
> --
> ?++ytti
> _______________________________________________
> cisco-nsp mailing 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/



      Berselancar lebih cepat. Internet Explorer 8 yang dioptimalkan untuk Yahoo! otomatis membuka 2 halaman favorit Anda setiap kali Anda membuka browser. Dapatkan IE8 di sini! 
http://downloads.yahoo.com/id/internetexplorer

From frnkblk at iname.com  Wed Jul 22 20:30:31 2009
From: frnkblk at iname.com (Frank Bulk)
Date: Wed, 22 Jul 2009 19:30:31 -0500
Subject: [c-nsp] Cisco 7600 rate limiting
In-Reply-To: <4A678CDB.3040607@rainierconnect.net>
References: <4A678CDB.3040607@rainierconnect.net>
Message-ID: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAABCFw404dHwTrua5UBrnFiVAQAAAAA=@iname.com>

Try this, it's been working for us (after much head bashing)

==========================================
mls qos

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 4000000    conform-action transmit     exceed-action drop
violate-action drop

interface Vlan203
 description CUSTOMER
 ip address x.x.x.x x.x.x.x
 mls qos bridged
 service-policy input customer-policer
 service-policy output customer-policer
end

interface GigabitEthernet1/14
 description TRUNK PORT
 switchport
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 1,203
 switchport mode trunk
 speed 100
 duplex full
 mls qos vlan-based
!
==========================================

Regards,

Frank

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Walter Keen
Sent: Wednesday, July 22, 2009 5:04 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Cisco 7600 rate limiting

Any suggestions on this?

I'm trying to rate-limit a vlan at X mbit (4 in this case) and seeing 
rate-limiting working downstream to the customer but not when traffic is 
originating from the customer.

Customer access is via a dot1q trunk (with a switch at the cust. site 
handing off untagged traffic for that vlan)

7600 hardware is a 7606-s, rsp720-3cxl, running 12.2(33)SRC2, with a 
single ws-6724sfp card.  Both the dot1q trunk bringing in customer 
connections and the routed port it's destined for exist on the same card.

class-map match-any RATELIMIT-4mbit
  match any
policy-map TEST-4mbit
 description TESTING-ONLY
  class RATELIMIT-4mbit
   police cir 4000000
    conform-action transmit
    exceed-action drop
    violate-action drop
interface Vlan1060
 ip address 69.10.218.9 255.255.255.248
 service-policy input TEST-4mbit
 service-policy output TEST-4mbit
!

_______________________________________________
cisco-nsp mailing list  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  Wed Jul 22 20:51:07 2009
From: justin at justinshore.com (Justin Shore)
Date: Wed, 22 Jul 2009 19:51:07 -0500
Subject: [c-nsp] MPLS MTU / Jumbo frames etc.
In-Reply-To: <Pine.LNX.4.64.0907221611420.1986@orbital.burn.net>
References: <Pine.LNX.4.64.0907221400360.1986@orbital.burn.net>
	<Pine.LNX.4.64.0907221611420.1986@orbital.burn.net>
Message-ID: <4A67B3FB.8000900@justinshore.com>

Brandon Applegate wrote:
> I think I figured (part of) this out.  Packets to the router != packets 
> through the router.  Trying to ping something on the far side with 
> packet size of 9188/9216 gets me the expected icmp frag @ 9212.  I still 
> think I'm going to proclaim that jumbo == 9000 to make it easier for 
> server / storage guys to remember anyway :)

I used to use 9216 across my network until I ran into some devices that 
couldn't do 9216.  I forget what they were but I ended up lowering it 
all to 9000 after that.  I don't expect to ever send frames that large 
anyhow but I wanted to lay the groundwork for it early.

Justin


From eninja at gmail.com  Wed Jul 22 22:28:12 2009
From: eninja at gmail.com (e ninja)
Date: Wed, 22 Jul 2009 19:28:12 -0700
Subject: [c-nsp] 7206 NPE-G2 crash caused by a bouncing DS1
In-Reply-To: <4A673B69.9060902@justinshore.com>
References: <4A673B69.9060902@justinshore.com>
Message-ID: <e8590f60907221928x134a214dy7c382025a73060f@mail.gmail.com>

Justin,

There are way too many bugs in IOS for anyone to try to guess the cause of
this crash - especially without your attaching the crashinfo files.

Either way, SegV crashes are _always_ caused by software bugs and the TAC
engineer should have decoded your tracebacks and if need be disassemble the
the functions to reveal the errand function/s and action prior to the crash,
rather than still be "thinking"

Demand your free bug fix - http://resources.multiven.com/dossier-3

Eninja


On Wed, Jul 22, 2009 at 9:16 AM, Justin Shore <justin at justinshore.com>wrote:

> Has anyone out there experienced any 7206 crashes when they have a bouncing
> DS1 on a PA-MC-2T3-EC?  We've had 2 crashes in about 3 weeks time.  They've
> both generated crashinfo files.  The first auto-rebooted itself.
>  Yesterday's did not.
>
> System returned to ROM by error - a SegV exception, PC 0x349404 at 16:27:25
> UTC Tue Jul 21 2009
>
> The G2 is running 12.4(24)T.  I'm working with TAC who's escalated it to
> the developers.  They're thinking that it's an IOS bug that's being set off
> when a DS1 flaps (though not every time of course).  I don't know if severe
> and lengthy flapping is necessary or if a single instance could happen at
> just the right time to make it crash.  Both times though a DS1 was bouncing
> every second or two and had been for days.  Both DS1s were members of MLPPP
> bundles at the time too.
>
> Has anyone else experiences similar issues?
>
> 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 mtinka at globaltransit.net  Wed Jul 22 23:50:31 2009
From: mtinka at globaltransit.net (Mark Tinka)
Date: Thu, 23 Jul 2009 11:50:31 +0800
Subject: [c-nsp] MPLS MTU / Jumbo frames etc.
In-Reply-To: <Pine.LNX.4.64.0907221611420.1986@orbital.burn.net>
References: <Pine.LNX.4.64.0907221400360.1986@orbital.burn.net>
	<Pine.LNX.4.64.0907221611420.1986@orbital.burn.net>
Message-ID: <200907231150.31820.mtinka@globaltransit.net>

On Thursday 23 July 2009 04:13:51 am Brandon Applegate 
wrote:

> I still think I'm
> going to proclaim that jumbo == 9000 to make it easier
> for server / storage guys to remember anyway :)

We've standardized on 9,000 bytes on all our switches and 
routers, especially so because we are both a C & J house.

Different line cards that support different values, 
different switch models within C that support different 
values, are fixed at 9,000 bytes, e.t.c., means that 9,000 
bytes is safe.

Most customers that require large MTU support need more than 
1,500 bytes, but hardly ever need the full 9,000 bytes. So 
even with a couple 10 or 100 bytes shy of 9,000 bytes, those 
customers that need it have been happy.

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/20090723/82a3ab23/attachment.bin>

From mtinka at globaltransit.net  Wed Jul 22 23:40:17 2009
From: mtinka at globaltransit.net (Mark Tinka)
Date: Thu, 23 Jul 2009 11:40:17 +0800
Subject: [c-nsp] going from collapsed core to separate core/distribution
	layers
In-Reply-To: <622e99f30907211236r4613d243i1ed086d1882ad4cb@mail.gmail.com>
References: <622e99f30907211236r4613d243i1ed086d1882ad4cb@mail.gmail.com>
Message-ID: <200907231140.59364.mtinka@globaltransit.net>

On Wednesday 22 July 2009 03:36:28 am jack b wrote:

> We are looking
> to break the collapsed core into a separate core and
> distribution layer leaving the 6509's in the distribution
> layer and getting a new platform for the core where we
> would move our transit providers.

So your new platform would double as a core and 
peering/transit router, making it a collapsed 
core/border/peering device.

I think the ASR1000 would be good - it's got decent support 
for both Ethernet and SDH/SONET line cards, a fairly good 
software feature set for both core and peering functions, 
and with the right ESP, should haul a good amount of traffic 
around.

But since you're collapsing these functions into a single 
platform (and depending on how many PoP's and transit 
providers/peering partners you intend to connect [to]), 
you'll need to ensure you have a reasonably-sized model of 
this router that fits your needs.

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/20090723/506ea073/attachment.bin>

From dan at orb.cz  Thu Jul 23 03:11:33 2009
From: dan at orb.cz (=?ISO-8859-2?Q?Daniel_Stan=ECk?=)
Date: Thu, 23 Jul 2009 09:11:33 +0200
Subject: [c-nsp] asa internal hosts limit
Message-ID: <4A680D25.3060606@orb.cz>

Hello,

we are experiencing problem with ASA 5505. There is limit to 50 internal 
hosts due to the licence and the limit is always reached in short time 
after reboot even if the number of internal hosts is below apx 10.

the "sh local" output is:

Detected interface 'outside' as the Internet interface. Host limit 
applies to all other interfaces.
Current host count: 50, towards licensed host limit of: 50

and in the local hosts list we see records like:

local host: <213.149.x.x>,
    TCP flow count/limit = 1/unlimited
    TCP embryonic count to host = 0
    TCP intercept watermark = unlimited
    UDP flow count/limit = 0/unlimited

  Conn:
    TCP out 213.149.x.x:443 in 10.x.x.x:4267 idle 0:00:00 bytes 360 
flags UIO


so there is public host 213.149.x.x marked as local host even if exists 
outside of the network (therefore the local host limit s reached very 
fast as there is enough sessions). Communication for this session is 
enabled by acl and dynamycaly translated to the pool of outside address.

global (outside) 1 x.x.x.x
nat (inside) 1 access-list server_nat

access-list server_nat extended permit ip host 10.x.x.x any 


sw version is:
Cisco Adaptive Security Appliance Software Version 8.0(3)6


Does anybody know where the problem may be?

Daniel


From koug at intracom.gr  Thu Jul 23 03:32:59 2009
From: koug at intracom.gr (John Kougoulos)
Date: Thu, 23 Jul 2009 10:32:59 +0300 (GTB Daylight Time)
Subject: [c-nsp] FWSM access permissions confusion between interfaces
In-Reply-To: <4A675AF9.9000404@utc.edu>
References: <4A675AF9.9000404@utc.edu>
Message-ID: <alpine.WNT.2.00.0907231018120.1440@pckoug1.intranet.gr>

Hello,

I had once tried to use the NAT controls on the interfaces on a PIX and I 
was dissappointed because things didn't work as expected, but I don't 
remember the exact details. What I remember is that if you want to be 
safe, you must put access-list everywhere. So I use now "no nat-control" 
and try to have correct ACLs in place.

At least now you have the option to use outbound ACLs....

You can create object-groups etc to simplify the ACLs needed.

Regards,
John



On Wed, 22 Jul 2009, Jeff Kell wrote:

> I had hoped that using the FWSM NAT controls on the interfaces would
> provide the first level of granularity with respect to access controls,
> defining "which user VRFs" could see "which server VRFs" without
> providing a full head-on mesh of everything together.
>
> All vlans should have access to vlan1000 (inbound)
> red and yellow users should have access to orange services.
> yellow and blue users should have access to green services.
> red and blue users should have access to purple services.
>
> There is no IP address overlap, so there is really no "NAT" required;
> but you have to have some definition to allow connections to take place.
>
> If I use "NAT exemption" it seems to let everybody see everyone else,
> regardless of the security level assigned to the interface.
>
> This "can" be accomplished by some very complicated ACLs on each
> interface, but I would end up with a "long" list of permitted source
> networks for each service to permit (and there are many such services
> and destination servers).
>
> I would like to restrict access to just the desired subnets (first) with
> the appropriate NAT controls, if that is possible, so that the ACLs
> would be concerned primarily with just the service/port details.
>
> The documentation implies this is possible (defining NAT rules for
> specific source/destination interface pairs) but I can't quite seem to
> get the right configuration to work, or properly orient this diagram to
> fit the traditional "inside/outside" paradigm the FWSM dialogue expects.
>
> Anyone been there / done that / can offer any suggestions?
>
> Many thanks in advance,
>
> 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 peter at rathlev.dk  Thu Jul 23 08:27:18 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Thu, 23 Jul 2009 14:27:18 +0200
Subject: [c-nsp] MPLS MTU / Jumbo frames etc.
In-Reply-To: <200907231150.31820.mtinka@globaltransit.net>
References: <Pine.LNX.4.64.0907221400360.1986@orbital.burn.net>
	<Pine.LNX.4.64.0907221611420.1986@orbital.burn.net>
	<200907231150.31820.mtinka@globaltransit.net>
Message-ID: <1248352038.2795.6.camel@abehat.net.rm.dk>

On Thu, 2009-07-23 at 11:50 +0800, Mark Tinka wrote:
> We've standardized on 9,000 bytes on all our switches and routers,
> especially so because we are both a C & J house.
> 
> Different line cards that support different values, different switch
> models within C that support different values, are fixed at 9,000
> bytes, e.t.c., means that 9,000 bytes is safe.

Two small notes:

For people having traffic traversing a FWSM beware that at least v3.1
seems to only accept up to 8500 bytes MTU.

Also the 3560/3750 series support jumbo frames up to "only" 9000 bytes.

Regards,
Peter



From ray at oneunified.net  Thu Jul 23 08:38:17 2009
From: ray at oneunified.net (Ray Burkholder)
Date: Thu, 23 Jul 2009 09:38:17 -0300
Subject: [c-nsp] MPLS MTU / Jumbo frames etc.
In-Reply-To: <1248352038.2795.6.camel@abehat.net.rm.dk>
References: <Pine.LNX.4.64.0907221400360.1986@orbital.burn.net>	<Pine.LNX.4.64.0907221611420.1986@orbital.burn.net>	<200907231150.31820.mtinka@globaltransit.net>
	<1248352038.2795.6.camel@abehat.net.rm.dk>
Message-ID: <16dc01ca0b92$74fe6400$5efb2c00$@net>


> Also the 3560/3750 series support jumbo frames up to "only" 9000 bytes.

When people define these MTU sizes, what does this size include?   The
payload?  The ip header?  Layer 2 header?  Some documentation seems murky on
this issue.  

When working with MTU changes necessary for MPLS operation, things get
somewhat confusing.  For example in this document, somehow MPLS can have an
MTU setting greater than what is allowed on the interface itself.

http://www.cisco.com/en/US/docs/ios/12_2sb/feature/guide/newmtu.html

Ray


-- 
Scanned for viruses and dangerous content at 
http://www.oneunified.net and is believed to be clean.


From drew.weaver at thenap.com  Thu Jul 23 08:45:03 2009
From: drew.weaver at thenap.com (Drew Weaver)
Date: Thu, 23 Jul 2009 08:45:03 -0400
Subject: [c-nsp] Netflow export groups?
Message-ID: <F3318834F1F89D46857972DD4B411D7011C3DA88@EXCHANGE.thenap.com>

We need to split the netflow data coming off of a router to two different destinations based on the port.

I.e.

We need to export Pos1/0 and G6/1 to destination 1
and
everything to destination 2.

Is it possible to do this? or do I need to send all of the data through a software collector and have the collector then send it out to the two destinations?

If not, it would be cool if you could add interfaces to groups and those groups would export to the appropriate dst.

thanks,
-Drew

From maillist at webjogger.net  Wed Jul 22 19:54:56 2009
From: maillist at webjogger.net (Adam Greene)
Date: Wed, 22 Jul 2009 19:54:56 -0400
Subject: [c-nsp] BGP failover for two traffic types
Message-ID: <479E7073E55C4CFD83C670BCEC0CFDD6@GINKGO>

Hi,

I have a CE router doing eBGP peering with two of my PE routers over 
distinct WAN circuits. The CE router services two netblocks on its LAN 
interface: one is for VOICE, the other (secondary IP address) is for DATA.

I want the customer's DATA traffic to flow to/from PE1 by default, and voice 
traffic to flow to/from PE2 by default. In the event of an outage on one of 
the circuits, I want all traffic to flow over the circuit that's still up.

I already know how to manipulate the traffic inbound to the CE router in 
this way, using conditional BGP advertisements. However, I can't figure out 
how to make the customer's outbound traffic prefer one link or another 
depending on whether it's DATA or VOICE, except by using route-maps, and 
those don't play nice as far as failing over to a backup link if the primary 
link is down.

I've toyed with the idea of trying to use VRF for this application, but I'm 
pretty new to it and don't know if it's really a viable approach.

Interested in ideas ... should I attempt a solution based on VRF? Or maybe 
there is a simpler solution ....

thanks,
Adam 



From jcartier at acs.on.ca  Thu Jul 23 09:04:40 2009
From: jcartier at acs.on.ca (Jeff Cartier)
Date: Thu, 23 Jul 2009 09:04:40 -0400
Subject: [c-nsp] Questions about upgrading and image of a Modular IOS
Message-ID: <BCD3E762F1767C42A5226BBACDE49BFBED906F@loki.acs.local>

This will be my first experience with the new Cisco Modular IOS.  I am
tasked with upgrading the IOS (which is already modular) of a 6500.

 

The current image is already installed on disk0:/sys...

 

Just for peace of mind, and a good nights sleep :-)...I was hoping for
some confirmation from the group if this is the correct way to upgrade
the IOS (the boss is against patching the IOS).  So here are my steps...

 

1)       copy the new IOS to disk0:

2)       'install file disk0:<IOS image> disk0:/newsys

3)       'install bind disk0:/newsys'

4)       Change the boot statements within the configuration to set the
new IOS to first boot, setting the old IOS to send boot...just in case
:-).

5)       Reload

 

 

 

My questions are on steps 3 and 5.

 

Step 3 - Am I supposed to be installing the file into a different
directory than the current (ie. /sys vs /newsys).  It is my
understanding that if I try to install the new IOS into the current
directory it will ask to overwrite the image, which I don't want, as I
would like to keep the 'known good' image as a backup.

 

Step 5 - Am I just being old school, or do I need to reload the chassis?
Is their a more time effective method, or is this just for patching.

 

Thanks to All!!! 


From rodunn at cisco.com  Thu Jul 23 09:09:46 2009
From: rodunn at cisco.com (Rodney Dunn)
Date: Thu, 23 Jul 2009 09:09:46 -0400
Subject: [c-nsp] BGP failover for two traffic types
In-Reply-To: <479E7073E55C4CFD83C670BCEC0CFDD6@GINKGO>
References: <479E7073E55C4CFD83C670BCEC0CFDD6@GINKGO>
Message-ID: <4A68611A.4080108@cisco.com>

Look in to PBR with either router tracking or one of the other IP SLA 
event types to monitor for the link going down.

Rodney



Adam Greene wrote:
> Hi,
> 
> I have a CE router doing eBGP peering with two of my PE routers over 
> distinct WAN circuits. The CE router services two netblocks on its LAN 
> interface: one is for VOICE, the other (secondary IP address) is for DATA.
> 
> I want the customer's DATA traffic to flow to/from PE1 by default, and 
> voice traffic to flow to/from PE2 by default. In the event of an outage 
> on one of the circuits, I want all traffic to flow over the circuit 
> that's still up.
> 
> I already know how to manipulate the traffic inbound to the CE router in 
> this way, using conditional BGP advertisements. However, I can't figure 
> out how to make the customer's outbound traffic prefer one link or 
> another depending on whether it's DATA or VOICE, except by using 
> route-maps, and those don't play nice as far as failing over to a backup 
> link if the primary link is down.
> 
> I've toyed with the idea of trying to use VRF for this application, but 
> I'm pretty new to it and don't know if it's really a viable approach.
> 
> Interested in ideas ... should I attempt a solution based on VRF? Or 
> maybe there is a simpler solution ....
> 
> thanks,
> Adam
> 
> _______________________________________________
> cisco-nsp mailing list  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 at ytti.fi  Thu Jul 23 09:10:53 2009
From: saku at ytti.fi (Saku Ytti)
Date: Thu, 23 Jul 2009 16:10:53 +0300
Subject: [c-nsp] BGP failover for two traffic types
In-Reply-To: <479E7073E55C4CFD83C670BCEC0CFDD6@GINKGO>
References: <479E7073E55C4CFD83C670BCEC0CFDD6@GINKGO>
Message-ID: <20090723131053.GA19901@mx.ytti.net>

On (2009-07-22 19:54 -0400), Adam Greene wrote:
 
> I've toyed with the idea of trying to use VRF for this application,
> but I'm pretty new to it and don't know if it's really a viable
> approach.

MTR[0], Multi-topology routing is intended for for establishing separate
topologies based on DSCP/prec, so may be suited for your requirements.
Personally, I'd just buy enough VoIP quality capacity. General wisdom
is that VoIP has really strict requirements for network quality, personally
I think VoIP is very lenient on network quality, and if VoIP won't fly 
over circuit, I'd be unhappy ssh user over it also.

[0]?http://www.cisco.com/en/US/docs/ios/12_2sr/12_2srb/feature/guide/srmtrdoc.html

-- 
  ++ytti

From swmike at swm.pp.se  Thu Jul 23 09:29:38 2009
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Thu, 23 Jul 2009 15:29:38 +0200 (CEST)
Subject: [c-nsp] MPLS MTU / Jumbo frames etc.
In-Reply-To: <16dc01ca0b92$74fe6400$5efb2c00$@net>
References: <Pine.LNX.4.64.0907221400360.1986@orbital.burn.net>
	<Pine.LNX.4.64.0907221611420.1986@orbital.burn.net>
	<200907231150.31820.mtinka@globaltransit.net>
	<1248352038.2795.6.camel@abehat.net.rm.dk>
	<16dc01ca0b92$74fe6400$5efb2c00$@net>
Message-ID: <alpine.DEB.1.10.0907231525090.4558@uplift.swm.pp.se>

On Thu, 23 Jul 2009, Ray Burkholder wrote:

> When people define these MTU sizes, what does this size include?  The 
> payload?  The ip header?  Layer 2 header?  Some documentation seems 
> murky on this issue.

Depends on the platform. Several networks I have been working on has been 
standardised to 4470 IP MTU because this is a well known figure that most 
platforms and protocols support. This means that platforms which set L2 
MTU is set to 4484 for ethernet and 4474 for HDLC.

> When working with MTU changes necessary for MPLS operation, things get
> somewhat confusing.  For example in this document, somehow MPLS can have an
> MTU setting greater than what is allowed on the interface itself.

Several platforms do not do IP themselves well with jumboframes, but they 
can forward frames, and there is the interaction with L2 switches 
which is administrated thru the dist lan.

For these I recommend:

mtu 1546 (or something else)
ip mtu 1500
clns mtu 1497 (if you run isis).

For a 7200 with FE ports this translates into:

mpls mtu 1546

Please see discussion regarding this from ~1 year back.

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

From rdobbins at arbor.net  Thu Jul 23 09:46:15 2009
From: rdobbins at arbor.net (Roland Dobbins)
Date: Thu, 23 Jul 2009 20:46:15 +0700
Subject: [c-nsp] Netflow export groups?
In-Reply-To: <F3318834F1F89D46857972DD4B411D7011C3DA88@EXCHANGE.thenap.com>
References: <F3318834F1F89D46857972DD4B411D7011C3DA88@EXCHANGE.thenap.com>
Message-ID: <8D46ED73-70D8-48C2-9B78-AE9778A7B418@arbor.net>


On Jul 23, 2009, at 7:45 PM, Drew Weaver wrote:

> Is it possible to do this?

If it's a Cisco router running an image which supports Flexible  
NetFlow, yes.  I don't know about Juniper routers.

One can also send all the NetFlow telemetry to two destinations on  
many Cisco platforms/trains, though this will result in the NDE taking  
more resources on the exporting routers.

Otherwise, sending it to a software collector and then replicating it  
would be best.

Out of curiosity, what's the rationale behind doing this?

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

         Unfortunately, inefficiency scales really well.

		   -- Kevin Lawton


From elmonomario69 at gmail.com  Thu Jul 23 09:45:40 2009
From: elmonomario69 at gmail.com (.....::::[Gardener] ::::.....)
Date: Thu, 23 Jul 2009 10:45:40 -0300
Subject: [c-nsp] TCLsh + Ping TOS
In-Reply-To: <000001ca09ef$89578b10$0a00000a@nil.si>
References: <cf70832e0907200958o62ef7a71w3b8a51463c64201a@mail.gmail.com> 
	<EC993E87D960A541A66BF21D62AA42A6230163B08B@exch2k7.gilat.local> 
	<000001ca09ef$89578b10$0a00000a@nil.si>
Message-ID: <cf70832e0907230645l30454791vf545f9d70f9e8a9b@mail.gmail.com>

thank you very much guys,

I will try to create this script and will give you.

See ya


----------------------
NO STREES
ECO ATTITUD :D


On Tue, Jul 21, 2009 at 7:39 AM, Ivan Pepelnjak <ip at ioshints.info> wrote:

> Tcl doesn't have "expect" but it does have "typeahead" which you can
> probably use to feed the input to Ping command.
>
> http://wiki.nil.com/Insert_responses_to_command_prompts_in_Tclsh
> http://wiki.nil.com/Tclsh_on_Cisco_IOS_tutorial
>
> Ivan
>
> http://www.ioshints.info/about
> http://blog.ioshints.info/
>
> > -----Original Message-----
> > From: Ziv Leyes [mailto:zivl at gilat.net]
> > Sent: Tuesday, July 21, 2009 8:51 AM
> > To: .....::::[Gardener] ::::.....; cisco-nsp at puck.nether.net
> > Subject: Re: [c-nsp] TCLsh + Ping TOS
> >
> > That's interesting indeed, the one line ping command seems to
> > not be able to include the extended commands, so I wonder,
> > does the tcsh support "expect"
> > Because that could be a solution for this kind of need.
> >
> > Regarding the command running from other place you could use
> > an alias exec, e.g.
> > alias exec multiping tclsh disk2:file.tcl
> >
> > 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
> > .....::::[Gardener] ::::.....
> > Sent: Monday, July 20, 2009 7:59 PM
> > To: cisco-nsp at puck.nether.net
> > Subject: [c-nsp] TCLsh + Ping TOS
> >
> > Hi to everyone.
> >
> > Please i need some advice to create a little script to make
> > Ping with TOS
> >
> > i found on several webpages, things like this.
> >
> > R1#tclsh
> > R1(tcl)#foreach address {
> > +>(tcl)#172.12.23.2
> > +>(tcl)#172.12.23.3
> > +>(tcl)#172.12.23.4
> > +>(tcl)#172.12.23.6
> > +>(tcl)#172.12.23.7
> > +>(tcl)#} { ping $address re 10 si 1500
> > +>(tcl)#}
> >
> > This is my problem, i can not make the complete command on
> > ONE line (becouse i don't have TOS ).
> >  I need to create script to execute things like this.
> >
> > R1#ping
> > Protocol [ip]:
> > Target IP address: 172.16.123.1
> > Repeat count [5]: 1000
> > Datagram size [100]:
> > Timeout in seconds [2]:
> > Extended commands [n]: y
> > Source address or interface: loopback0
> > Type of service [0]: 96
> > Set DF bit in IP header? [no]:
> > Validate reply data? [no]:
> > Data pattern [0xABCD]:
> > Loose, Strict, Record, Timestamp, Verbose[none]:
> > Sweep range of sizes [n]:
> >
> >
> >
> > The other impossibility that i have i can not create or bring
> > from other place the file.tcl, all this script has to be
> > applied on-line on the router.
> >
> > Thank you.
> >  Andres P. Spano
> > _______________________________________________
> > cisco-nsp mailing 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 frnkblk at iname.com  Thu Jul 23 10:03:41 2009
From: frnkblk at iname.com (Frank Bulk)
Date: Thu, 23 Jul 2009 09:03:41 -0500
Subject: [c-nsp] Monitoring BGP with NAGIOS
Message-ID: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAACgBVX1McEWTr789Gz1sQh4AQAAAAA=@iname.com>

We're a small shop and our group's upstream is single-homed in terms of
providers but dual-homed in terms of physical connectivity, with a private
ASN.

 

Occasionally there's BGP events and I would like to be remotely notified --
NAGIOS can do that and I prefer SNMP polling.  We're not doing an SNMP TRAP
or syslog processing at this time - that would be an obvious next step for
us.

 

Currently the NAGIOS plugin I'm developing polls the bgpPeerState,
bgpPeerIn/OutUpdates and bgpPeerIn/OutTotalMessages and alerts me if there's
a change.  Since a BGP session could be re-established in a short amount of
time, I would like to trigger an alert if the number of In/Out Updates or
Messages exceeds the regular value (I'm presuming that when the BGP session
re-establishes, these counters climb more quickly than during times of
stability).  But I'm not sure if Updates/Messages are normally sent every 30
or 60 seconds (I've seen 60 on a wiki page, but "sh ip bgp neighbors" says
that the "keepalive interval is 30 seconds" and "Default minimum time
between advertisement runs is 30 seconds".  I'm guessing this knob can be
adjusted in IOS, so ideally I would like the NAGIOS plugin to accommodate
for that, such that if the counters move '5' in 5 minutes that's OK with a
60 second period, but if it's a 30 second period, then those counts should
move 10 times.  But keep-alive/scan interval doesn't seem to be listed in
the MIB.

 

Also, there's a lot more information available at the Cisco CLI when
executing "sh ip bgp summary", specifically:

.         BGP table version

.         # of network entries

.         # of path entries

.         # of prefixes

.         # of paths

.         Up/Down times

Is any of that available via SNMP, because my walking isn't showing that at
all?

 

If you think I'm going about this the wrong way, please feel free to tell
me. =)

 

Regards,

 

Frank


From Ian.Mackinnon at lumison.net  Thu Jul 23 10:15:07 2009
From: Ian.Mackinnon at lumison.net (Ian MacKinnon)
Date: Thu, 23 Jul 2009 15:15:07 +0100
Subject: [c-nsp] Monitoring BGP with NAGIOS
In-Reply-To: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAACgBVX1McEWTr789Gz1sQh4AQAAAAA=@iname.com>
References: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAACgBVX1McEWTr789Gz1sQh4AQAAAAA=@iname.com>
Message-ID: <B5F945E48C137C49A98BC86DD35939C012DDE2A36B@nbg01-exch-01.entlstaff.domain.lumison.net>

Hi Frank,

You say maybe traps is the next step.....
You can get an snmp trap when a peer changes state, you can then get nagios to respond to the traps using traphandler

Some info at http://www.cisco.com/en/US/docs/ios/12_3t/12_3t7/feature/guide/gt_bmibe.html


We are using nagios and traphandlers to respond to thinks link link up/down

I guess if you poll often enough you can be sure to catch a peer in a bad state, but do you actually care at 3 in the morning that a peer was down for 30s and is now back?

Ian


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Frank Bulk
Sent: 23 July 2009 15:04
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Monitoring BGP with NAGIOS

We're a small shop and our group's upstream is single-homed in terms of
providers but dual-homed in terms of physical connectivity, with a private
ASN.



Occasionally there's BGP events and I would like to be remotely notified --
NAGIOS can do that and I prefer SNMP polling.  We're not doing an SNMP TRAP
or syslog processing at this time - that would be an obvious next step for
us.



Currently the NAGIOS plugin I'm developing polls the bgpPeerState,
bgpPeerIn/OutUpdates and bgpPeerIn/OutTotalMessages and alerts me if there's
a change.  Since a BGP session could be re-established in a short amount of
time, I would like to trigger an alert if the number of In/Out Updates or
Messages exceeds the regular value (I'm presuming that when the BGP session
re-establishes, these counters climb more quickly than during times of
stability).  But I'm not sure if Updates/Messages are normally sent every 30
or 60 seconds (I've seen 60 on a wiki page, but "sh ip bgp neighbors" says
that the "keepalive interval is 30 seconds" and "Default minimum time
between advertisement runs is 30 seconds".  I'm guessing this knob can be
adjusted in IOS, so ideally I would like the NAGIOS plugin to accommodate
for that, such that if the counters move '5' in 5 minutes that's OK with a
60 second period, but if it's a 30 second period, then those counts should
move 10 times.  But keep-alive/scan interval doesn't seem to be listed in
the MIB.



Also, there's a lot more information available at the Cisco CLI when
executing "sh ip bgp summary", specifically:

.         BGP table version

.         # of network entries

.         # of path entries

.         # of prefixes

.         # of paths

.         Up/Down times

Is any of that available via SNMP, because my walking isn't showing that at
all?



If you think I'm going about this the wrong way, please feel free to tell
me. =)



Regards,



Frank

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

Checked by AVG - www.avg.com
Version: 8.5.392 / Virus Database: 270.13.20/2249 - Release Date: 07/21/09 18:02:00

--

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

From nils.kolstein at sscplus.nl  Thu Jul 23 09:53:29 2009
From: nils.kolstein at sscplus.nl (Nils Kolstein)
Date: Thu, 23 Jul 2009 15:53:29 +0200 (CEST)
Subject: [c-nsp] Netflow export groups?
In-Reply-To: <8D46ED73-70D8-48C2-9B78-AE9778A7B418@arbor.net>
Message-ID: <10261455.58981248357209756.JavaMail.root@webmail>

> If it's a Cisco router running an image which supports Flexible  
> NetFlow, yes.  I don't know about Juniper routers.

Juniper supports this also on several main relases.

Nils Kolstein

From bacon at walleyesoftware.com  Thu Jul 23 10:38:51 2009
From: bacon at walleyesoftware.com (Jeff Bacon)
Date: Thu, 23 Jul 2009 09:38:51 -0500
Subject: [c-nsp] ip multicast boundary and IGMP?
Message-ID: <5A69C25361FED34F83ABF05F5047524505CD82E2@wally.walleyetrading.net>

According to the documentation:

* IP multicast boundaries filter data and control plane traffic
including IGMP, PIM, and AutoRP messages. PIM Register messages are sent
using unicast and will not be filtered.


However, I have multiple multicast boundaries set up on various SVIs and
PIs, and IGMP appears to work just fine - "show ip igmp group vlan X"
reports state, multicast comes and goes, etc etc. 

In addition, I am running EIGRP across a link which has a multicast
boundary configured, which is using multicast of course, and it works
just fine. 

It does however block PIM and AutoRP, which I have to explicitly permit
in order for it to work. 


Is this just a flaw in the documentation? A flaw in the SX train? Am I
missing something?

This is on cat6500/sup720s, 12.2.33SXH4. 

Thanks,
-bacon


General traffic:

interface Vlan103
 ip address 10.201.64.34 255.255.255.224
 ip access-group mcast-subnets-in in
 ip access-group ISE-mcast-subnet-out out
 ip pim neighbor-filter deny-any
 ip pim sparse-dense-mode
 ip multicast boundary ISE-mcast-B-groups
 load-interval 60
 hold-queue 80 out
Standard IP access list ISE-mcast-B-groups
    10 permit 233.104.73.64, wildcard bits 0.0.0.63 (576170 matches)
    20 permit 233.104.73.128, wildcard bits 0.0.0.63 (13419 matches)

interface Vlan300
 description --- VLAN 300 -> nj-vendorsw00 main
 ip address 10.201.192.146 255.255.255.252
 ip pim sparse-dense-mode
 ip multicast boundary from-mcast-nj
 load-interval 60
 hold-queue 2000 in
Standard IP access list from-mcast-nj
    10 permit 233.54.12.119
    20 permit 233.54.12.120 (59448 matches)
    30 permit 224.0.1.39 (62277 matches)
    40 permit 224.0.1.40 (80379 matches)
    50 permit 233.54.12.10
    60 permit 224.0.0.13
    70 permit 224.0.58.0, wildcard bits 0.0.0.255
    80 permit 233.75.215.168, wildcard bits 0.0.0.1
    90 permit 233.75.215.40, wildcard bits 0.0.0.1
    100 permit 224.0.5.220, wildcard bits 0.0.0.3
    110 permit 224.0.5.224, wildcard bits 0.0.0.3


From alexmoya at bellsouth.net  Thu Jul 23 09:42:19 2009
From: alexmoya at bellsouth.net (Alex Moya)
Date: Thu, 23 Jul 2009 06:42:19 -0700 (PDT)
Subject: [c-nsp] Default route from ospf to bgp
Message-ID: <521090.45154.qm@web180704.mail.sp1.yahoo.com>


I need to redistribute my default route from my ospf process to my bgp.do I use a route map to just allow my default ? 

Sent from my iPhone 

From Kiran.Oddiraju at cbre.com  Thu Jul 23 11:39:49 2009
From: Kiran.Oddiraju at cbre.com (Oddiraju, Kiran @ London SMC)
Date: Thu, 23 Jul 2009 16:39:49 +0100
Subject: [c-nsp] NAT and PAT on ASA
In-Reply-To: <B5CFB919B5EEF345969F51FAFE6360D50ADCC2@GBLDCXMB10.emea.cbre.net>
References: <B5CFB919B5EEF345969F51FAFE6360D50ADC90@GBLDCXMB10.emea.cbre.net><6E21B2BDEF6E714EA0B5BA8D5D0E1401248380AF40@zy-ex1.zyedge.local><B5CFB919B5EEF345969F51FAFE6360D50ADC93@GBLDCXMB10.emea.cbre.net><6E21B2BDEF6E714EA0B5BA8D5D0E1401248380B07D@zy-ex1.zyedge.local>
	<B5CFB919B5EEF345969F51FAFE6360D50ADCC2@GBLDCXMB10.emea.cbre.net>
Message-ID: <B5CFB919B5EEF345969F51FAFE6360D50ADDAC@GBLDCXMB10.emea.cbre.net>

Hi Guys,

With your help I was able to register my SIP phones with Cisco
CallManager but I have a problem here. When the externally registered
SIP phone calls an internal phone and when I press the answer button the
call immediately gets disconnected. I have the below config on my ASA
5505:

access-list outside_access_in extended permit icmp any any echo-reply
access-list outside_access_in extended permit icmp any any
access-list outside_access_in extended permit ip any any
access-list outside_access_in extended permit icmp any host
80.90.100.116 echo
access-list outside_access_in extended permit tcp any host 80.90.100.116
eq www
access-list outside_access_in extended permit tcp any host 80.90.100.116
eq https
access-list outside_access_in extended permit tcp any host 80.90.100.116
eq sip
access-list outside_access_in extended permit icmp any host
80.90.100.115 echo
access-list outside_access_in extended permit tcp any host 80.90.100.115
eq www
access-list outside_access_in extended permit tcp any host 80.90.100.115
eq https
access-list outside_access_in extended permit tcp any host 80.90.100.115
eq sip
access-list outside_access_in extended permit tcp any host 80.90.100.115
eq 2749
access-list outside_access_in extended permit tcp any host 80.90.100.114
eq ldap
access-list outside_access_in extended permit icmp any host
80.90.100.114 echo
access-list outside_access_in extended permit udp any host 80.90.100.116
eq sip
access-list outside_access_in extended permit udp any host 80.90.100.115
eq sip
access-list outside_access_in extended permit udp any host 80.90.100.115
eq tftp
access-list outside_access_in extended permit tcp any host 80.90.100.115
eq 69
access-list outside_access_in extended permit tcp any host 80.90.100.115
eq ctiqbe
access-list outside_access_in extended permit tcp any host 80.90.100.116
eq 5061
access-list outside_access_in extended permit tcp any host 80.90.100.116
eq 5062
access-list outside_access_in extended permit tcp any host 80.90.100.116
eq 5070
access-list outside_access_in extended permit tcp any host 80.90.100.115
eq 5070
access-list outside_access_in extended permit tcp any host 80.90.100.115
eq 5061
access-list outside_access_in extended permit tcp any host 80.90.100.115
eq 5062
access-list outside_access_in extended permit udp any host 80.90.100.115
eq 5062
access-list outside_access_in extended permit udp any host 80.90.100.116
eq 5062
access-list outside_access_in extended permit udp any host 80.90.100.116
eq 5061
access-list outside_access_in extended permit udp any host 80.90.100.115
eq 5061
access-list inside_access_in extended permit ip any any

global (outside) 2 interface
global (outside) 1 80.90.100.116
nat (inside) 1 192.168.0.130 255.255.255.255
nat (inside) 2 0.0.0.0 0.0.0.0

static (inside,outside) 80.90.100.116 192.168.0.130 netmask
255.255.255.255
static (inside,outside) 80.90.100.115 192.168.0.125 netmask
255.255.255.255
static (inside,outside) 80.90.100.114 192.168.0.250 netmask
255.255.255.255
access-group outside_access_in in interface outside
access-group inside_access_in in interface inside
route outside 0.0.0.0 0.0.0.0 80.90.100.118 1

threat-detection basic-threat
threat-detection statistics access-list
!
class-map inspection_default
 match default-inspection-traffic
!
!
policy-map type inspect dns preset_dns_map
 parameters
  message-length maximum 512
policy-map global_policy
 class inspection_default
  inspect dns preset_dns_map
  inspect ftp
  inspect h323 h225
  inspect h323 ras
  inspect rsh
  inspect rtsp
  inspect esmtp
  inspect sqlnet
  inspect skinny
  inspect sunrpc
  inspect xdmcp
  inspect sip
  inspect netbios
  inspect tftp
  inspect icmp
!
service-policy global_policy global
prompt hostname context
Cryptochecksum:0e1ff8af778c5350ccc07a401427687c
: end

Thanks,
Kiran

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Oddiraju, Kiran
@ London SMC
Sent: 22 July 2009 12:24
To: Ryan West
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] NAT and PAT on ASA

Hi Ryan,

I have the below config in the protocol inspection rules, do you think
this is enough?

class-map inspection_default
 match default-inspection-traffic
!
!
policy-map type inspect dns preset_dns_map
 parameters
  message-length maximum 512
policy-map global_policy
 class inspection_default
  inspect dns preset_dns_map
  inspect ftp
  inspect h323 h225
  inspect h323 ras
  inspect rsh
  inspect rtsp
  inspect esmtp
  inspect sqlnet
  inspect skinny
  inspect sunrpc
  inspect xdmcp
  inspect sip
  inspect netbios
  inspect tftp
  inspect icmp
!


Many thanks,
Kiran

-----Original Message-----
From: Ryan West [mailto:rwest at zyedge.com] 
Sent: 22 July 2009 09:47
To: Oddiraju, Kiran @ London SMC
Cc: cisco-nsp at puck.nether.net
Subject: RE: NAT and PAT on ASA

Kiran,

That's right.  If you run into issues trying to pass SIP through your
firewall, you may need to look at the default service policy.  There are
some protocol inspection rules enabled by default that might affect the
passing of SIP traffic.

-ryan

-----Original Message-----
From: Oddiraju, Kiran @ London SMC [mailto:Kiran.Oddiraju at cbre.com] 
Sent: Wednesday, July 22, 2009 4:38 AM
To: Ryan West
Cc: cisco-nsp at puck.nether.net
Subject: RE: NAT and PAT on ASA

Hey Ryan,

That seems to be working, thanks. So if I want to allow more ports we do
it the same way right?

access-list myaccesslist ext permit tcp any host 58.66.76.88 eq SIP
access-list myaccesslist ext permit upd any host 58.66.76.88 eq SIP

Thanks,
Kiran


-----Original Message-----
From: Ryan West [mailto:rwest at zyedge.com] 
Sent: 21 July 2009 19:48
To: Oddiraju, Kiran @ London SMC; cisco-nsp at puck.nether.net
Subject: RE: NAT and PAT on ASA

static (inside,outside) 58.66.76.88 192.168.0.100
show run access-group
take note of the acl to the outside interface, ACLs are on the ASA are
inbound.
access-list <myaccesslist> ext permit icmp any host 58.66.76.88 echo
access-list <myaccesslist> ext permit tcp any host 58.66.76.88 eq www

-ryan

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Oddiraju, Kiran
@ London SMC
Sent: Tuesday, July 21, 2009 2:09 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] NAT and PAT on ASA

Guys,

 

I am new to the ASA world, I have a bunch of external IP's from the ISP
and I have an inside host that I want to access externally. How do I
translate an inside ip (192.168.0.100) to an outside address
(58.66.76.88) on the ASA? I should be able to ping and www from outside
world to my inside host. Please let me know how to accomplish this.

 

Many thanks,

K


CB Richard Ellis Limited, Registered Office: St Martin's Court, 
10 Paternoster Row, London, EC4M 7HP, registered in England and Wales
No. 3536032. 
Regulated by the RICS and an appointed representative of CB Richard
Ellis 
Indirect Investment Services Limited which is authorised and regulated
by the Financial Services Authority.

This communication is from CB Richard Ellis Limited or one of its 
associated/subsidiary companies. This communication contains information

which is confidential and may be privileged. If you are not the intended
recipient, 
please contact the sender immediately. Any use of its contents is
strictly prohibited 
and you must not copy, send or disclose it, or rely on its contents in
any way whatsoever. 
Reasonable care has been taken to ensure that this communication 
(and any attachments or hyperlinks contained within it) is free from
computer viruses. 
No responsibility is accepted by CB Richard Ellis Limited or its
associated/subsidiary 
companies and the recipient should carry out any appropriate virus
checks.

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
CB Richard Ellis Limited, Registered Office: St Martin's Court, 
10 Paternoster Row, London, EC4M 7HP, registered in England and Wales
No. 3536032. 
Regulated by the RICS and an appointed representative of CB Richard
Ellis 
Indirect Investment Services Limited which is authorised and regulated
by the Financial Services Authority.

This communication is from CB Richard Ellis Limited or one of its 
associated/subsidiary companies. This communication contains information

which is confidential and may be privileged. If you are not the intended
recipient, 
please contact the sender immediately. Any use of its contents is
strictly prohibited 
and you must not copy, send or disclose it, or rely on its contents in
any way whatsoever. 
Reasonable care has been taken to ensure that this communication 
(and any attachments or hyperlinks contained within it) is free from
computer viruses. 
No responsibility is accepted by CB Richard Ellis Limited or its
associated/subsidiary 
companies and the recipient should carry out any appropriate virus
checks.


CB Richard Ellis Limited, Registered Office: St Martin's Court, 
10 Paternoster Row, London, EC4M 7HP, registered in England and Wales
No. 3536032. 
Regulated by the RICS and an appointed representative of CB Richard
Ellis 
Indirect Investment Services Limited which is authorised and regulated
by the Financial Services Authority.

This communication is from CB Richard Ellis Limited or one of its 
associated/subsidiary companies. This communication contains information

which is confidential and may be privileged. If you are not the intended
recipient, 
please contact the sender immediately. Any use of its contents is
strictly prohibited 
and you must not copy, send or disclose it, or rely on its contents in
any way whatsoever. 
Reasonable care has been taken to ensure that this communication 
(and any attachments or hyperlinks contained within it) is free from
computer viruses. 
No responsibility is accepted by CB Richard Ellis Limited or its
associated/subsidiary 
companies and the recipient should carry out any appropriate virus
checks.

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
CB Richard Ellis Limited, Registered Office: St Martin's Court, 
10 Paternoster Row, London, EC4M 7HP, registered in England and Wales No. 3536032. 
Regulated by the RICS and an appointed representative of CB Richard Ellis 
Indirect Investment Services Limited which is authorised and regulated by the Financial Services Authority.

This communication is from CB Richard Ellis Limited or one of its 
associated/subsidiary companies. This communication contains information 
which is confidential and may be privileged. If you are not the intended recipient, 
please contact the sender immediately. Any use of its contents is strictly prohibited 
and you must not copy, send or disclose it, or rely on its contents in any way whatsoever. 
Reasonable care has been taken to ensure that this communication 
(and any attachments or hyperlinks contained within it) is free from computer viruses. 
No responsibility is accepted by CB Richard Ellis Limited or its associated/subsidiary 
companies and the recipient should carry out any appropriate virus checks.


From ip at ioshints.info  Thu Jul 23 11:45:02 2009
From: ip at ioshints.info (Ivan Pepelnjak)
Date: Thu, 23 Jul 2009 17:45:02 +0200
Subject: [c-nsp] BGP failover for two traffic types
In-Reply-To: <479E7073E55C4CFD83C670BCEC0CFDD6@GINKGO>
References: <479E7073E55C4CFD83C670BCEC0CFDD6@GINKGO>
Message-ID: <005701ca0bac$8bd6c8b0$0a00000a@nil.si>

Are the VOICE and DATA traffic going to distinct servers? If that's the
case, you can tweak the BGP route selection policy on the CE router. See
this article for an example (not too far off from what you're looking for):

http://www.nil.com/ipcorner/ScalablePolicyRouting/

If you cannot distinguish VOICE and DATA based on destination addresses,
policy routing is the next obvious option (we all love to hate). OER might
also work, but I haven't worked with it enough to have an informed opinion
(another technology way too long on my to-do list).

Ivan
 
http://www.ioshints.info/about
http://blog.ioshints.info/

> -----Original Message-----
> From: Adam Greene [mailto:maillist at webjogger.net] 
> Sent: Thursday, July 23, 2009 1:55 AM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] BGP failover for two traffic types
> 
> Hi,
> 
> I have a CE router doing eBGP peering with two of my PE 
> routers over distinct WAN circuits. The CE router services 
> two netblocks on its LAN
> interface: one is for VOICE, the other (secondary IP address) 
> is for DATA.
> 
> I want the customer's DATA traffic to flow to/from PE1 by 
> default, and voice traffic to flow to/from PE2 by default. In 
> the event of an outage on one of the circuits, I want all 
> traffic to flow over the circuit that's still up.
> 
> I already know how to manipulate the traffic inbound to the 
> CE router in this way, using conditional BGP advertisements. 
> However, I can't figure out how to make the customer's 
> outbound traffic prefer one link or another depending on 
> whether it's DATA or VOICE, except by using route-maps, and 
> those don't play nice as far as failing over to a backup link 
> if the primary link is down.
> 
> I've toyed with the idea of trying to use VRF for this 
> application, but I'm pretty new to it and don't know if it's 
> really a viable approach.
> 
> Interested in ideas ... should I attempt a solution based on 
> VRF? Or maybe there is a simpler solution ....
> 
> thanks,
> Adam 
> 
> 
> 
> 


From peter at rathlev.dk  Thu Jul 23 12:06:47 2009
From: peter at rathlev.dk (Peter Rathlev)
Date: Thu, 23 Jul 2009 18:06:47 +0200
Subject: [c-nsp] OT: Network documentation tool
In-Reply-To: <20090722220239.GA22975@saucer.midcoast.com>
References: <1247930754.5386.5.camel@abehat.net.rm.dk>
	<20090722220239.GA22975@saucer.midcoast.com>
Message-ID: <1248365207.2765.35.camel@abehat.net.rm.dk>

Thanks to all who replied. I think we're going further with trying out
Mediawiki. The most important thing is of course that the written
documentation is up to date as much as possible. Easy editing is
paramount to achieving this.

Regards,
Peter

On Wed, 2009-07-22 at 18:02 -0400, jp wrote:
> We use Mediawiki. It's easy to customize if you don't like the left 
> frame. I like the easy editing of wikis, searching, history management, 
> web based access, etc... With the prevalence of wikipedia and lots of 
> software projects adopting wikis for documentation, most technical 
> people should not consider them difficult.
> 
> Lists of sites, important information about the sites, (local contact 
> info, power outage reporting info, alarm codes, combo lock codes, and so 
> on). We've also been known to write down when things were installed or 
> upgraded for warranty or maintenance purposes.
> 
> We also have written instructions for various procedures for different 
> parts of the organization, so if someone goes on vacation or gets hit by 
> a bus, other people can fill in. 
> 
> We also have a gallery. (using gallery 1.6 or jallery), so we can have 
> photos of the sites. It is good for guiding someone over the phone who 
> is onsite and you are not familiar with what they are looking at. We 
> also use it to verify line of site for wireless things with rooftop or 
> towertop panoramas from each site.
> 
> On Sat, Jul 18, 2009 at 05:25:53PM +0200, Peter Rathlev wrote:
> > Kind of OT, but hopefully someone has an opinion anyway. :-)
> > 
> > I'm looking for the perfect documentation tool for network
> > documentation. We already have tools to map out the network and lots of
> > management tools, but what I'm looking for is something like a
> > repository to store and update all the written documentation, like
> > procedures and so on.
> > 
> > We've been looking at different Wikis, among others the Mediawiki suite,
> > and it looks promising but in my eyes seem a little much when we could
> > cope with somthing much simpler. We've also looked at document
> > repositories like Owl. We've even looked at Sharepoint. None of these
> > tools seem to be just right though.
> > 
> > What do people use to store documentation? Currently we use a CIFS share
> > but this seems clumsy at best.
> > 
> > Any input is appreciated. :-)
> > 
> > Regards,
> > Peter



From nicotine at warningg.com  Thu Jul 23 12:10:10 2009
From: nicotine at warningg.com (Brandon Ewing)
Date: Thu, 23 Jul 2009 11:10:10 -0500
Subject: [c-nsp] Monitoring BGP with NAGIOS
In-Reply-To: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAACgBVX1McEWTr789Gz1sQh4AQAAAAA=@iname.com>
References: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAACgBVX1McEWTr789Gz1sQh4AQAAAAA=@iname.com>
Message-ID: <20090723161010.GA553@radiological.warningg.com>

On Thu, Jul 23, 2009 at 09:03:41AM -0500, Frank Bulk wrote:
> 
> Currently the NAGIOS plugin I'm developing polls the bgpPeerState,
> bgpPeerIn/OutUpdates and bgpPeerIn/OutTotalMessages and alerts me if there's
> a change.  Since a BGP session could be re-established in a short amount of
> time, I would like to trigger an alert if the number of In/Out Updates or
> Messages exceeds the regular value (I'm presuming that when the BGP session
> re-establishes, these counters climb more quickly than during times of
> stability).  But I'm not sure if Updates/Messages are normally sent every 30
> or 60 seconds (I've seen 60 on a wiki page, but "sh ip bgp neighbors" says
> that the "keepalive interval is 30 seconds" and "Default minimum time
> between advertisement runs is 30 seconds".  I'm guessing this knob can be
> adjusted in IOS, so ideally I would like the NAGIOS plugin to accommodate
> for that, such that if the counters move '5' in 5 minutes that's OK with a
> 60 second period, but if it's a 30 second period, then those counts should
> move 10 times.  But keep-alive/scan interval doesn't seem to be listed in
> the MIB.
> 

BGP4-MIB::bgpPeerHoldTime ( .1.3.6.1.2.1.15.3.1.18 )
BGP4-MIB::bgpPeerKeepAlive ( .1.3.6.1.2.1.15.3.1.19 )

Hold time is 3x keepalive by default
Updates are sent as they are processed
There are also OIDs for the locally configured hold and keepalive timers, as
you will use your peer's configured timers if they are lower.


> 
> Also, there's a lot more information available at the Cisco CLI when
> executing "sh ip bgp summary", specifically:
> 
> .         Up/Down times

BGP4-MIB::bgpPeerInUpdateElapsedTime ( .1.3.6.1.2.1.15.3.1.24 )
BGP4-MIB::bgpPeerLastError ( .1.3.6.1.2.1.15.3.1.14 )

>  
> 
> If you think I'm going about this the wrong way, please feel free to tell
> me. =)
> 

Have you looked at the following plugins in the Nagios Exchange?
http://exchange.nagios.org/directory/Plugins/Uncategorized/Software/SNMP/check_bgp_neighbors/details
http://exchange.nagios.org/directory/Plugins/Uncategorized/Software/SNMP/check_bgp/details

Cisco's MIB Browser also has a wealth of information regarding BGP SNMP
http://tools.cisco.com/Support/SNMP/do/BrowseMIB.do?local=en&step=2&mibName=BGP4-MIB

-- 
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/20090723/c785fe19/attachment.bin>

From masood at nexlinx.net.pk  Thu Jul 23 13:15:50 2009
From: masood at nexlinx.net.pk (masood at nexlinx.net.pk)
Date: Thu, 23 Jul 2009 22:15:50 +0500 (PKT)
Subject: [c-nsp] Default route from ospf to bgp
In-Reply-To: <521090.45154.qm@web180704.mail.sp1.yahoo.com>
References: <521090.45154.qm@web180704.mail.sp1.yahoo.com>
Message-ID: <58771.196.46.241.57.1248369350.squirrel@nexmail1.nexlinx.net.pk>



To advertise a BGP default route to a BGP neighbor, use the neighbor 
default-originate router configuration command.?

/>Regards,
Masood

> 
> I need to
redistribute 
my default route from my ospf process to my bgp.do 
> I use a 
route map to just allow my default ? 
> 
> Sent from my 
iPhone 
>
_______________________________________________ 
/>> cisco-nsp
mailing list cisco-nsp at puck.nether.net 
> 
https://puck.nether.net/mailman/listinfo/cisco-nsp 
> archive at

http://puck.nether.net/pipermail/cisco-nsp/ 
> 


From vinzoda.hitesh at gmail.com  Thu Jul 23 12:11:35 2009
From: vinzoda.hitesh at gmail.com (Hitesh Vinzoda)
Date: Thu, 23 Jul 2009 21:41:35 +0530
Subject: [c-nsp] High Memory Usage due to NAT
Message-ID: <c04fd4f90907230911j5ab685d5l4100187405006a22@mail.gmail.com>

I m facing a strange issue regarding the NAT. The problem statement is as
below

NAT configured on 3845 with 12.4.24 T ADV ENT SERVICES


   - Have got 64 /25 inside subnets to do the nat with 64 Live IP's. one
   each for /25 inside subnet.
   - I checked the processes and memory on freshly loaded router which comes
   out to be 49 MB of free memory.
   - started the NAT on router with 8 of /25 inside ip pool with policy NAT
   to 8 live IP's. The router withing 3 hours hanged due to no availability of
   free memory. Rebooted it and removed the NAT.
   - Checked Cisco website for NAT it says 312 bytes per translation that
   gives us around 3 MB for 10000 translations. Checked the logs and found peak
   translation only to be 15000.
   - Found that problem was NAT ACL with any statement in destination
   portion ( extended one). Changed it with standard ACL with no any statement.
   - Reviewed and resumed the NAT on router. it works now but it uses around
   20 MB of memory for just 10000 translation entries.
   - Checked the UDP, TCP and ICMP timeout .... Limited UDP to 4 Mins. TCP
   to 25 Mins and ICMP- 5 Mins. was able to free only 2 MB of so from 20 MB.
   - Changed the IOS from ADV ent services to IP base to get rid of unwanted
   processess and services as main AIM of this router is to run NAT.
   - Freshly loaded router gave me 120 MB of free space and was happy now to
   test out the things.
   - Againg started the NAT for 8 pools of /25 inside subnet with 8 live
   IP's ( Policy nat ).
   - At 25000 translations it eats up memory of around 24 MB.
   - Turned of Virtual Reassembly as it was reaching to thresold very often.
   - Migrated another 8 pools of /25 which comes to total of 16 /25 Inside
   subnets and free memory left to 64 MB. with the peak translation upto 42000
   and active translation to 15000 on an average.
   - It often gives the I/O memory errors too ( with only 16 /25 Pools
   configured on it).
   - All this stuff works fine with Netscreen firewall overloaded with only
   4 IP's for all 64 /25 pools. ..... ( Is netscreen had an edge over cisco
   when it comes to NAT ...._?? ) I wonder..!

If Cisco says that only 312 bytes are required for storing a single
translation Why i m not able to free my DRAM memory. Tried my luck with
everything. Need some expert advice on this to figure out the High Memory
usage of NAT....

NOTE : Only default router and no other services are used on router apart
from Netflow

Thanks in Advance

Regards

Ronnie

From rwest at zyedge.com  Thu Jul 23 12:23:40 2009
From: rwest at zyedge.com (Ryan West)
Date: Thu, 23 Jul 2009 12:23:40 -0400
Subject: [c-nsp] NAT and PAT on ASA
In-Reply-To: <B5CFB919B5EEF345969F51FAFE6360D50ADDAC@GBLDCXMB10.emea.cbre.net>
References: <B5CFB919B5EEF345969F51FAFE6360D50ADC90@GBLDCXMB10.emea.cbre.net><6E21B2BDEF6E714EA0B5BA8D5D0E1401248380AF40@zy-ex1.zyedge.local><B5CFB919B5EEF345969F51FAFE6360D50ADC93@GBLDCXMB10.emea.cbre.net><6E21B2BDEF6E714EA0B5BA8D5D0E1401248380B07D@zy-ex1.zyedge.local>
	<B5CFB919B5EEF345969F51FAFE6360D50ADCC2@GBLDCXMB10.emea.cbre.net>
	<B5CFB919B5EEF345969F51FAFE6360D50ADDAC@GBLDCXMB10.emea.cbre.net>
Message-ID: <6E21B2BDEF6E714EA0B5BA8D5D0E1401248380B17D@zy-ex1.zyedge.local>

Kiran,

SIP inspection doesn't always work as it should.  Take a look at 'show service-policy inspect sip' and see if you're getting drops.  If you are, you may need to remove it from the default global policy:

policy-map global_policy
 class inspection_default
  no inspect sip

-ryan





From jctx09 at yahoo.com  Thu Jul 23 12:18:43 2009
From: jctx09 at yahoo.com (jacob c)
Date: Thu, 23 Jul 2009 09:18:43 -0700 (PDT)
Subject: [c-nsp] LACP questions
Message-ID: <404885.6827.qm@web54011.mail.re2.yahoo.com>

I need some clarification with some general LACP principles. 

I have a cisco switch talking to a load balancer (F5). both sides are in active mode. There are four links making up the bundle and the F5 LTM load balancer is the Actor. What happens when I administrataively shutdown link 1?

a) The Cisco device sends a LACP packet across one of the other links with the collecting bit set to disabled. The LB device responds with the collecting bit disabled.

b) The Cisco device does not send any notifications about the link being down and leaves the notifications to the? Actor (load balancer) in this situation.

c) other

Any help would be greatly appreciated.

Thank you,



      

From nick at inex.ie  Thu Jul 23 13:23:03 2009
From: nick at inex.ie (Nick Hilliard)
Date: Thu, 23 Jul 2009 18:23:03 +0100
Subject: [c-nsp] Monitoring BGP with NAGIOS
In-Reply-To: <20090723161010.GA553@radiological.warningg.com>
References: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAACgBVX1McEWTr789Gz1sQh4AQAAAAA=@iname.com>
	<20090723161010.GA553@radiological.warningg.com>
Message-ID: <4A689C77.3020206@inex.ie>

On 23/07/2009 17:10, Brandon Ewing wrote:
> Have you looked at the following plugins in the Nagios Exchange?
> http://exchange.nagios.org/directory/Plugins/Uncategorized/Software/SNMP/check_bgp_neighbors/details
> http://exchange.nagios.org/directory/Plugins/Uncategorized/Software/SNMP/check_bgp/details

check_bgp is very useful.  However, it would be a lot more useful if there 
were vendor support for BGP4-MIBv2.  If you are talking to your vendor 
about what sort of features you'd like to see in future releases, this is 
an important one to have, as it allows you to monitor bgp sessions which 
aren't just the default vrf ipv4.

Nick

From sfischer1967 at gmail.com  Thu Jul 23 13:34:01 2009
From: sfischer1967 at gmail.com (Steven Fischer)
Date: Thu, 23 Jul 2009 13:34:01 -0400
Subject: [c-nsp] MST spanning-tree
Message-ID: <500ffb690907231034w2671525fo536bdf05936be90c@mail.gmail.com>

When we relocated our data center, we opted to deploy MST as the
spanning-tree protocol, given that our data center is almost exclusively
layer 2, we have a lot of vlans, and that number is only going to grow.  We
have two spanning-tree MST instances, 1 and 2, and each contains the vlans
that are either odd (instance 1), or even (instance 2).

It seems that we can create VLANs with no issue, and by default, those VLANs
are placed in the default instance, instance 0.  This really isn't a
problem, but when we move the VLAN into its proper instance, a spanning-tree
recalc appears to occur, the duration of which is long enough to interrupt
data transfers that may be going on at the time.  Other than returning to
PVST/PVST+, is there a way to avoid this recalc taking out half the VLANs in
the data center for 30 seconds when adding it to the proper instance?  Will
our planned migration to VSS mitigate this to any degree, and if so, how
much?

-- 
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 rodunn at cisco.com  Thu Jul 23 13:40:36 2009
From: rodunn at cisco.com (Rodney Dunn)
Date: Thu, 23 Jul 2009 13:40:36 -0400
Subject: [c-nsp] High Memory Usage due to NAT
In-Reply-To: <c04fd4f90907230911j5ab685d5l4100187405006a22@mail.gmail.com>
References: <c04fd4f90907230911j5ab685d5l4100187405006a22@mail.gmail.com>
Message-ID: <4A68A094.1080706@cisco.com>

Honestly if you are looking that scale of NAT you should look at the 
ASR1002. It does all NAT in the hardware path and it scales way above
what IOS can do in software.

If you were talking 5-10k translations that's one thing.

Rodney



Hitesh Vinzoda wrote:
> I m facing a strange issue regarding the NAT. The problem statement is as
> below
> 
> NAT configured on 3845 with 12.4.24 T ADV ENT SERVICES
> 
> 
>    - Have got 64 /25 inside subnets to do the nat with 64 Live IP's. one
>    each for /25 inside subnet.
>    - I checked the processes and memory on freshly loaded router which comes
>    out to be 49 MB of free memory.
>    - started the NAT on router with 8 of /25 inside ip pool with policy NAT
>    to 8 live IP's. The router withing 3 hours hanged due to no availability of
>    free memory. Rebooted it and removed the NAT.
>    - Checked Cisco website for NAT it says 312 bytes per translation that
>    gives us around 3 MB for 10000 translations. Checked the logs and found peak
>    translation only to be 15000.
>    - Found that problem was NAT ACL with any statement in destination
>    portion ( extended one). Changed it with standard ACL with no any statement.
>    - Reviewed and resumed the NAT on router. it works now but it uses around
>    20 MB of memory for just 10000 translation entries.
>    - Checked the UDP, TCP and ICMP timeout .... Limited UDP to 4 Mins. TCP
>    to 25 Mins and ICMP- 5 Mins. was able to free only 2 MB of so from 20 MB.
>    - Changed the IOS from ADV ent services to IP base to get rid of unwanted
>    processess and services as main AIM of this router is to run NAT.
>    - Freshly loaded router gave me 120 MB of free space and was happy now to
>    test out the things.
>    - Againg started the NAT for 8 pools of /25 inside subnet with 8 live
>    IP's ( Policy nat ).
>    - At 25000 translations it eats up memory of around 24 MB.
>    - Turned of Virtual Reassembly as it was reaching to thresold very often.
>    - Migrated another 8 pools of /25 which comes to total of 16 /25 Inside
>    subnets and free memory left to 64 MB. with the peak translation upto 42000
>    and active translation to 15000 on an average.
>    - It often gives the I/O memory errors too ( with only 16 /25 Pools
>    configured on it).
>    - All this stuff works fine with Netscreen firewall overloaded with only
>    4 IP's for all 64 /25 pools. ..... ( Is netscreen had an edge over cisco
>    when it comes to NAT ...._?? ) I wonder..!
> 
> If Cisco says that only 312 bytes are required for storing a single
> translation Why i m not able to free my DRAM memory. Tried my luck with
> everything. Need some expert advice on this to figure out the High Memory
> usage of NAT....
> 
> NOTE : Only default router and no other services are used on router apart
> from Netflow
> 
> Thanks in Advance
> 
> Regards
> 
> Ronnie
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

From SHughes at GREnergy.com  Thu Jul 23 13:15:12 2009
From: SHughes at GREnergy.com (Hughes, Scott GRE/MG)
Date: Thu, 23 Jul 2009 12:15:12 -0500
Subject: [c-nsp] Questions about upgrading and image of a Modular IOS
In-Reply-To: <BCD3E762F1767C42A5226BBACDE49BFBED906F@loki.acs.local>
References: <BCD3E762F1767C42A5226BBACDE49BFBED906F@loki.acs.local>
Message-ID: <D72AC2E49DA8AB4195DF356ED05663DD60B194C171@MNCMS01.intra.grenergy.com>

Yes, you need to install to a different (non-existing) directory for the new image.

The 'install bind' *should* do the work of adding the proper boot commands.

If you have dual-supervisors, you can simply force a switchover instead of a full reload for decreased downtime. If you have dual-supervisors, be sure to do the "install file" step for both disk0: and slavedisk0:

If you don't have dual-sups, you'll have to reload the chassis.

Scott


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Jeff Cartier
Sent: Thursday, July 23, 2009 8:05 AM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Questions about upgrading and image of a Modular IOS

This will be my first experience with the new Cisco Modular IOS.  I am
tasked with upgrading the IOS (which is already modular) of a 6500.

 

The current image is already installed on disk0:/sys...

 

Just for peace of mind, and a good nights sleep :-)...I was hoping for
some confirmation from the group if this is the correct way to upgrade
the IOS (the boss is against patching the IOS).  So here are my steps...

 

1)       copy the new IOS to disk0:

2)       'install file disk0:<IOS image> disk0:/newsys

3)       'install bind disk0:/newsys'

4)       Change the boot statements within the configuration to set the
new IOS to first boot, setting the old IOS to send boot...just in case
:-).

5)       Reload

 

 

 

My questions are on steps 3 and 5.

 

Step 3 - Am I supposed to be installing the file into a different
directory than the current (ie. /sys vs /newsys).  It is my
understanding that if I try to install the new IOS into the current
directory it will ask to overwrite the image, which I don't want, as I
would like to keep the 'known good' image as a backup.

 

Step 5 - Am I just being old school, or do I need to reload the chassis?
Is their a more time effective method, or is this just for patching.

 

Thanks to All!!! 

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
NOTICE TO RECIPIENT: The information contained in this message from
Great River Energy and any attachments are confidential and intended
only for the named recipient(s). If you have received this message in 
error, you are prohibited from copying, distributing or using the
information. Please contact the sender immediately by return email and
delete the original message.


 


From ross at kallisti.us  Thu Jul 23 13:54:29 2009
From: ross at kallisti.us (Ross Vandegrift)
Date: Thu, 23 Jul 2009 13:54:29 -0400
Subject: [c-nsp] MST spanning-tree
In-Reply-To: <500ffb690907231034w2671525fo536bdf05936be90c@mail.gmail.com>
References: <500ffb690907231034w2671525fo536bdf05936be90c@mail.gmail.com>
Message-ID: <20090723175429.GA17318@kallisti.us>

On Thu, Jul 23, 2009 at 01:34:01PM -0400, Steven Fischer wrote:
> It seems that we can create VLANs with no issue, and by default, those VLANs
> are placed in the default instance, instance 0.  This really isn't a
> problem, but when we move the VLAN into its proper instance, a spanning-tree
> recalc appears to occur, the duration of which is long enough to interrupt
> data transfers that may be going on at the time.  Other than returning to
> PVST/PVST+, is there a way to avoid this recalc taking out half the VLANs in
> the data center for 30 seconds when adding it to the proper instance?  Will
> our planned migration to VSS mitigate this to any degree, and if so, how
> much?

You need to pre-configure your VLAN mappings so that when you add a
VLAN to a switch, it's already mapped to the instance it's going to
end up in.  For MST to work the way you want it, the mapping has to
match on every device in the extended LAN.  (right now, you might as
well be running RSTP, since each switch has probably formed its own
region).

Once you get the full map rolled out to all of the switches (make sure
you load it via TFTP - pasting it in is a bear, assuming you're
configuring all 4094 VLANs), the switches will form one region with
two active forwarding topologies.

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 harbor235 at gmail.com  Thu Jul 23 14:04:05 2009
From: harbor235 at gmail.com (harbor235)
Date: Thu, 23 Jul 2009 14:04:05 -0400
Subject: [c-nsp] MST spanning-tree
In-Reply-To: <500ffb690907231034w2671525fo536bdf05936be90c@mail.gmail.com>
References: <500ffb690907231034w2671525fo536bdf05936be90c@mail.gmail.com>
Message-ID: <836bf1f90907231104oef806c7rc31d9642ebbaffee@mail.gmail.com>

When adding ports to a spanning-tree instance, spanning-tree discovers and
eliminates
loops in the topology. What your are experiencing is an "as designed"
feature of spanning tree.

You can segment your layer2 domain via PVST/PVST+ or you can segment your
layer 2 domain
using MST via customer spanning-tree instances, infrastructure spanning-tree
instances, MST regions,
etc ... I believe the max MST SPT instances per device is 65, the answer is
to segement where possible and to group vlans onto a region or MST SPT
instance to minimizes downtime. So one device, or pair of devices,
could support upto 65 seperate MST SPT instances (65 customers).

Mike



On Thu, Jul 23, 2009 at 1:34 PM, Steven Fischer <sfischer1967 at gmail.com>wrote:

> When we relocated our data center, we opted to deploy MST as the
> spanning-tree protocol, given that our data center is almost exclusively
> layer 2, we have a lot of vlans, and that number is only going to grow.  We
> have two spanning-tree MST instances, 1 and 2, and each contains the vlans
> that are either odd (instance 1), or even (instance 2).
>
> It seems that we can create VLANs with no issue, and by default, those
> VLANs
> are placed in the default instance, instance 0.  This really isn't a
> problem, but when we move the VLAN into its proper instance, a
> spanning-tree
> recalc appears to occur, the duration of which is long enough to interrupt
> data transfers that may be going on at the time.  Other than returning to
> PVST/PVST+, is there a way to avoid this recalc taking out half the VLANs
> in
> the data center for 30 seconds when adding it to the proper instance?  Will
> our planned migration to VSS mitigate this to any degree, and if so, how
> much?
>
> --
> 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 ip at ioshints.info  Thu Jul 23 14:49:38 2009
From: ip at ioshints.info (Ivan Pepelnjak)
Date: Thu, 23 Jul 2009 20:49:38 +0200
Subject: [c-nsp] OSPF NSSA question
In-Reply-To: <000201ca0adf$84323c70$8c96b550$@com>
References: <000001ca0a2c$3eacef00$bc06cd00$@com>
	<383357750907211234m147cf35ak8689bed0759acab7@mail.gmail.com>
	<000101ca0a42$f8f0f260$ead2d720$@com>
	<002101ca0a84$47c00d90$0a00000a@nil.si>
	<383357750907220109v10fe3d11y2f03d5428b7dc70a@mail.gmail.com>
	<000201ca0adf$84323c70$8c96b550$@com>
Message-ID: <007301ca0bc6$5cba3de0$0a00000a@nil.si>

Hi!

You gave me a good reason to finally test this command and document what it
does and how it's used in a hub-and-spoke environment:

http://wiki.nil.com/OSPF_flooding_filters_in_hub-and-spoke_environment

It's exactly what's needed to solve the original problem (but of course you
need a static default route on the spoke routers as they lose all OSPF
information).

Best regards
Ivan
 
http://www.ioshints.info/about
http://blog.ioshints.info/ 

> -----Original Message-----
> From: Ruben Alvarez [mailto:raa at opusnet.com] 
> Sent: Wednesday, July 22, 2009 5:17 PM
> To: 'Mateusz Blaszczyk'; 'Ivan Pepelnjak'
> Cc: cisco-nsp at puck.nether.net
> Subject: RE: [c-nsp] OSPF NSSA question
> 
> I'm not sure filtering 'out' would work.  Three routers all 
> have one interface, each connecting to the ABR (which has 
> four interfaces, three to the routers in area 1 and one in 
> area 0.)  If I'm filtering out, The ABR wouldn't know which 
> routes are on each of the three routers.  Right?  The three 
> routers have thousands of single host routes spread out over 
> each router.  The ABR knows which router has each host and 
> summarizes to area 0.
> 
> -----Original Message-----
> From: Mateusz Blaszczyk [mailto:blahu77 at gmail.com]
> Sent: Wednesday, July 22, 2009 1:10 AM
> To: Ivan Pepelnjak
> Cc: Ruben Alvarez; cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] OSPF NSSA question
> 
> 2009/7/22 Ivan Pepelnjak <ip at ioshints.info>:
> > You're probably looking for the "ip ospf database-filter 
> all out" command.
> 
> And how the summary LSA with 0/0 would get to the spoke 
> router if that is filtered out?
> (assuming nssa scenario in OP's hub n'spoke topology)
> 
> Best Regards,
> 
> -mat
> 
> 


From ip at ioshints.info  Thu Jul 23 14:49:38 2009
From: ip at ioshints.info (Ivan Pepelnjak)
Date: Thu, 23 Jul 2009 20:49:38 +0200
Subject: [c-nsp] Default route from ospf to bgp
In-Reply-To: <521090.45154.qm@web180704.mail.sp1.yahoo.com>
References: <521090.45154.qm@web180704.mail.sp1.yahoo.com>
Message-ID: <007401ca0bc6$5dfe7db0$0a00000a@nil.si>

Just configure "network 0.0.0.0 0.0.0.0" in your BGP process. Whenever
there's a default route in the IP routing table, BGP will advertise it. More
details in:

http://wiki.nil.com/BGP_default_route
http://blog.ioshints.info/2007/11/bgp-default-route.html

Ivan
 
http://www.ioshints.info/about
http://blog.ioshints.info/ 

> -----Original Message-----
> From: Alex Moya [mailto:alexmoya at bellsouth.net] 
> Sent: Thursday, July 23, 2009 3:42 PM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] Default route from ospf to bgp
> 
> 
> I need to redistribute my default route from my ospf process 
> to my bgp.do I use a route map to just allow my default ? 
> 
> Sent from my iPhone 
> 
> 


From jlewis at lewis.org  Thu Jul 23 15:04:28 2009
From: jlewis at lewis.org (Jon Lewis)
Date: Thu, 23 Jul 2009 15:04:28 -0400 (EDT)
Subject: [c-nsp] OSPF NSSA question
In-Reply-To: <001801ca0b08$eb410030$c1c30090$@com>
References: <000001ca0a2c$3eacef00$bc06cd00$@com>
	<39647f4d0907220935g4797e4f7m854158a9e65460d0@mail.gmail.com>
	<Pine.LNX.4.61.0907221338390.4187@soloth.lewis.org>
	<001801ca0b08$eb410030$c1c30090$@com>
Message-ID: <Pine.LNX.4.61.0907231500070.4187@soloth.lewis.org>

On Wed, 22 Jul 2009, Ruben Alvarez wrote:

> Yes the routers in area 1 are set to redistribute connected and static.
> They do DSL aggregation and if you can imagine I need some flexibility with
> those addresses (approx /20.)  I'll move IP pools and /30 -/29 networks from
> router to router as customers come and go.

OSPF really doesn't deal well with route filtering.  I kind of wonder if 
iBGP and (if needed) careful redistribution of iBGP into OSPF would be a 
better solution.

Take the router that would have been the gateway between areas 0 and 1 
(I'll call it R1), and make it a route reflector for the "area 1" routers. 
On R1, don't send the RR clients any routes except for those with next 
hops of other "area 1" routers.  This should be reasonably easily done 
with some route-maps and community marking of received routes on R1.

----------------------------------------------------------------------
  Jon Lewis                   |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

From alexmoya at bellsouth.net  Thu Jul 23 15:48:28 2009
From: alexmoya at bellsouth.net (Alex Moya)
Date: Thu, 23 Jul 2009 12:48:28 -0700 (PDT)
Subject: [c-nsp] Default route from ospf to bgp
Message-ID: <219879.1099.qm@web180703.mail.sp1.yahoo.com>


Got that in there already I think it was my prefix list

Sent from my iPhone

On Jul 23, 2009, at 1:15 PM, masood at nexlinx.net.pk wrote:



To advertise a BGP default route to a BGP neighbor, use the neighbor 
default-originate router configuration command. 

/>Regards,
Masood


I need to
redistribute 
my default route from my ospf process to my bgp.do 
I use a 
route map to just allow my default ? 

Sent from my 
iPhone 

_______________________________________________ 
/>> cisco-nsp
mailing 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 densen.randy at gmail.com  Thu Jul 23 16:58:10 2009
From: densen.randy at gmail.com (Randy Densen)
Date: Thu, 23 Jul 2009 16:58:10 -0400
Subject: [c-nsp] vrf-lite vs. MPLS vrf
Message-ID: <5e2a87260907231358q680848a1l7c6b82ac73318ca3@mail.gmail.com>

This is my first post.
I have 2 questions:

1) does The cisco-nsp Archives have a search function to look for posts that
may have already been addressed and/or answered?

2)  What criteria would you use to determine whether a Metro Ethernet
network should move forward with VRF-Lite or use MPLS vrf's?  Personally, I
would like to have a layer 2 network (ethernet relay service, similar to
what a large telco would do, then overlay a Layer 3 Internet and VPN service
for granularity and flexibility).
Pros? Cons? Preference?

thanks

From BBlackford at nwresd.k12.or.us  Thu Jul 23 17:04:33 2009
From: BBlackford at nwresd.k12.or.us (Bill Blackford)
Date: Thu, 23 Jul 2009 14:04:33 -0700
Subject: [c-nsp] SNMP ENGINE consuming CPU
Message-ID: <6069A203FD01884885C037F81DD7508016CF7453E3@wsc-mail-01.intra.nwresd.k12.or.us>

Currently I have a 7606 RSP720 hitting 94% CPU. 
A 'sh proc cpu sorted' indicates that SNMP ENGINE is the source.

Any thoughts on this?

Thanks

-b

--
Bill Blackford                     
Senior Network Engineer            
Technology Systems Group           
Northwest Regional ESD             

my /home away from home



From jeff-kell at utc.edu  Thu Jul 23 17:11:33 2009
From: jeff-kell at utc.edu (Jeff Kell)
Date: Thu, 23 Jul 2009 17:11:33 -0400
Subject: [c-nsp] SNMP ENGINE consuming CPU
In-Reply-To: <6069A203FD01884885C037F81DD7508016CF7453E3@wsc-mail-01.intra.nwresd.k12.or.us>
References: <6069A203FD01884885C037F81DD7508016CF7453E3@wsc-mail-01.intra.nwresd.k12.or.us>
Message-ID: <4A68D205.4080500@utc.edu>

Bill Blackford wrote:
> Currently I have a 7606 RSP720 hitting 94% CPU. 
> A 'sh proc cpu sorted' indicates that SNMP ENGINE is the source.
>
> Any thoughts on this?

It lays to rest the old "A watched pot never boils" adage...   :-)

Jeff

From BBlackford at nwresd.k12.or.us  Thu Jul 23 17:10:44 2009
From: BBlackford at nwresd.k12.or.us (Bill Blackford)
Date: Thu, 23 Jul 2009 14:10:44 -0700
Subject: [c-nsp] SNMP ENGINE consuming CPU
In-Reply-To: <6069A203FD01884885C037F81DD7508016CF7453E3@wsc-mail-01.intra.nwresd.k12.or.us>
References: <6069A203FD01884885C037F81DD7508016CF7453E3@wsc-mail-01.intra.nwresd.k12.or.us>
Message-ID: <6069A203FD01884885C037F81DD7508016CF7453E5@wsc-mail-01.intra.nwresd.k12.or.us>

A 'sh proc cpu his' shows the pegging starting about 8 hours ago.

-b


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Bill Blackford
Sent: Thursday, July 23, 2009 2:05 PM
To: cisco-nsp mailing list
Subject: [c-nsp] SNMP ENGINE consuming CPU

Currently I have a 7606 RSP720 hitting 94% CPU. 
A 'sh proc cpu sorted' indicates that SNMP ENGINE is the source.

Any thoughts on this?

Thanks

-b

--
Bill Blackford                     
Senior Network Engineer            
Technology Systems Group           
Northwest Regional ESD             

my /home away from home


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

From BBlackford at nwresd.k12.or.us  Thu Jul 23 17:17:30 2009
From: BBlackford at nwresd.k12.or.us (Bill Blackford)
Date: Thu, 23 Jul 2009 14:17:30 -0700
Subject: [c-nsp] SNMP ENGINE consuming CPU
In-Reply-To: <6069A203FD01884885C037F81DD7508016CF7453E5@wsc-mail-01.intra.nwresd.k12.or.us>
References: <6069A203FD01884885C037F81DD7508016CF7453E3@wsc-mail-01.intra.nwresd.k12.or.us>
	<6069A203FD01884885C037F81DD7508016CF7453E5@wsc-mail-01.intra.nwresd.k12.or.us>
Message-ID: <6069A203FD01884885C037F81DD7508016CF7453E7@wsc-mail-01.intra.nwresd.k12.or.us>

Oops. Meant for another list.
My apologies to the group.

Meanwhile,
My 5 second utilization shows 94%/0  does this indicate that it's all process switched vs. CEF switched?

-b


-----Original Message-----
From: Bill Blackford 
Sent: Thursday, July 23, 2009 2:11 PM
To: Bill Blackford; cisco-nsp mailing list
Subject: RE: SNMP ENGINE consuming CPU

A 'sh proc cpu his' shows the pegging starting about 8 hours ago.

-b


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Bill Blackford
Sent: Thursday, July 23, 2009 2:05 PM
To: cisco-nsp mailing list
Subject: [c-nsp] SNMP ENGINE consuming CPU

Currently I have a 7606 RSP720 hitting 94% CPU. 
A 'sh proc cpu sorted' indicates that SNMP ENGINE is the source.

Any thoughts on this?

Thanks

-b

--
Bill Blackford                     
Senior Network Engineer            
Technology Systems Group           
Northwest Regional ESD             

my /home away from home


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

From BBlackford at nwresd.k12.or.us  Thu Jul 23 17:34:22 2009
From: BBlackford at nwresd.k12.or.us (Bill Blackford)
Date: Thu, 23 Jul 2009 14:34:22 -0700
Subject: [c-nsp] SNMP ENGINE consuming CPU
In-Reply-To: <6069A203FD01884885C037F81DD7508016CF7453E7@wsc-mail-01.intra.nwresd.k12.or.us>
References: <6069A203FD01884885C037F81DD7508016CF7453E3@wsc-mail-01.intra.nwresd.k12.or.us>
	<6069A203FD01884885C037F81DD7508016CF7453E5@wsc-mail-01.intra.nwresd.k12.or.us>
	<6069A203FD01884885C037F81DD7508016CF7453E7@wsc-mail-01.intra.nwresd.k12.or.us>
Message-ID: <6069A203FD01884885C037F81DD7508016CF7453F5@wsc-mail-01.intra.nwresd.k12.or.us>

Another question on this same concept.

On this platform, are ip prefix-lists punted to the CPU?

-b


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Bill Blackford
Sent: Thursday, July 23, 2009 2:18 PM
To: cisco-nsp mailing list
Subject: Re: [c-nsp] SNMP ENGINE consuming CPU

Oops. Meant for another list.
My apologies to the group.

Meanwhile,
My 5 second utilization shows 94%/0  does this indicate that it's all process switched vs. CEF switched?

-b


-----Original Message-----
From: Bill Blackford 
Sent: Thursday, July 23, 2009 2:11 PM
To: Bill Blackford; cisco-nsp mailing list
Subject: RE: SNMP ENGINE consuming CPU

A 'sh proc cpu his' shows the pegging starting about 8 hours ago.

-b


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Bill Blackford
Sent: Thursday, July 23, 2009 2:05 PM
To: cisco-nsp mailing list
Subject: [c-nsp] SNMP ENGINE consuming CPU

Currently I have a 7606 RSP720 hitting 94% CPU. 
A 'sh proc cpu sorted' indicates that SNMP ENGINE is the source.

Any thoughts on this?

Thanks

-b

--
Bill Blackford                     
Senior Network Engineer            
Technology Systems Group           
Northwest Regional ESD             

my /home away from home


_______________________________________________
cisco-nsp mailing 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 kilobit at gmail.com  Thu Jul 23 17:53:58 2009
From: kilobit at gmail.com (bas)
Date: Thu, 23 Jul 2009 23:53:58 +0200
Subject: [c-nsp] performance problems / overruns on a 6500/sup720/dfc's
Message-ID: <ba6c08fd0907231453y1b23e434kca78338492179c08@mail.gmail.com>

Hello All,

I hope you guys can help me with the following issue.

It started a couple of weeks ago when one customer reported degraded
performance.
The customer has ~30 servers on a WS-C3750E-48TD, which in turn has a
single 10GE link to the 6500 in question.
The 10GE link on the 6500 has a service policy configured to limit IP
traffic to 8Gbps. (via an aggregate-policer)
Before the problems started the customer was able to push 8Gbps on the
link for 16 hours a day, the remaining time the customer has less
visitors to their service.
The issue arises every day at a time the router starts to forward 7.5
- 8Mpps. (approx 50Gbps)
When that moment comes the interface facing the customer drops down to
5 - 6 Gbps.

In the interface counters we can see the number of overruns increases very fast.
This continues till about 23:00PM when the total traffic forwarded
drops below 8mpps.

mod1: WS-X6708-10GE
mod2: WS-X6748-SFP
mod3: WS-X6704-10GE
mod4: WS-X6748-GE-TX
mod5: WS-X6748-GE-TX
mod6: WS-SUP720-3BXL

Initially running 12.2(18)SXF15a
Currently running 12.2(33)SXI1

The customer was connected to Te1/7 and currently 3/2

Things we have investigated or changed. (all have not resolved the issue)
- We saw through "sh plat hard cap fab" that some of the fabric
channels were (nearly) congested.
We swapped around a couple of TenG interfaces between channels and
slots 1 and 3.

- We suspected possible relation to Cisco bugs CSCeh08451 or
CSCsl70634. Even though both are resolved in SXF12 we upgraded to SXI1
- Possibly hitting some bottleneck in PFC/fabric, so we upgraded
modules 2 and 3 (the heaviest utilized modules) with DFC-3BXL.
- Tried different hold-queue's in and out
- Several fabric buffer-reserve settings
- Disabling all netflow
- removing the policy-map(s)
- enabling/disabling send/receive flowcontrol on several ports and
also on the customer 3750.

More customers are noticing degraded performance. Lower speeds and 5 -
20% packetloss.

The router has enough memory available, SP and RP cpu's are always below 30%

Below sh int output of the first customer that reported issues.

TenGigabitEthernet3/2 is up, line protocol is up (connected)
  Hardware is C6k 10000Mb 802.3, address is 000f.35bb.0b40 (bia 000f.35bb.0b40)
  Description: XXX001 - MO08
  Internet address is xx.xx.240.126/26
  MTU 1500 bytes, BW 10000000 Kbit, DLY 10 usec,
     reliability 255/255, txload 6/255, rxload 202/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex, 10Gb/s, media type is 10Gbase-LR
  input flow-control is off, output flow-control is off
  ARP type: ARPA, ARP Timeout 00:30:00
  Last input 00:00:00, output 00:00:00, output hang never
  Last clearing of "show interface" counters 00:56:37
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  30 second input rate 7935497000 bits/sec, 665152 packets/sec
  30 second output rate 239985000 bits/sec, 438880 packets/sec
  L2 Switched: ucast: 32 pkt, 2048 bytes - mcast: 1052 pkt, 318283 bytes
  L3 in Switched: ucast: 2016175646 pkt, 2998867098833 bytes - mcast:
0 pkt, 0 bytes mcast
  L3 out Switched: ucast: 1483531972 pkt, 115723597149 bytes mcast: 0
pkt, 0 bytes
     2228491744 packets input, 3314752535506 bytes, 0 no buffer
     Received 3005 broadcasts (0 IP multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 206532318 overrun, 0 ignored
     0 watchdog, 0 multicast, 0 pause input
     0 input packets with dribble condition detected
     1482844739 packets output, 115625721402 bytes, 0 underruns
     0 output errors, 0 collisions, 0 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

As you can see no problems reported other than overruns (approx 10%)

sh plat hard cap for output:
     Forwarding engine load:
                     Module       pps   peak-pps                     peak-time
                     1        2852591    4416215  18:21:12 CEST Thu Jul 23 2009
                     2        1422180    1645505  22:42:03 CEST Thu Jul 23 2009
                     3         903195    1018577  11:28:05 CEST Wed Jul 22 2009
                     6        1756281    8244268  01:36:29 CEST Sat Jul 18 2009


We're pretty much stuck.
Thanks for reading if you've gotten this far.

Any help would be very appreciated.

Kind regards,

Bas

p.s. the box peaks at approx 35Mbps IPv6 traffic, that shouldn't
affect IPv4 forwarding performance right?

From dean at eatworms.org.uk  Thu Jul 23 16:54:06 2009
From: dean at eatworms.org.uk (Dean Smith)
Date: Thu, 23 Jul 2009 21:54:06 +0100
Subject: [c-nsp] Route Reflectors & Multipath
Message-ID: <004e01ca0bd7$b8199940$284ccbc0$@org.uk>

Is there any tweak, trick or feature that enables a route-reflector to pass
on multiple iBGP paths to clients ?

 

This is for a straightforward iBGP ipv4 setup (no multiprotocol bgp or MPLS,
so no unique VRF ids etc).

 

(7200 running 12.2SB or later)

 

Thanks


Dean


From Tony at bobbroadband.com  Thu Jul 23 17:33:15 2009
From: Tony at bobbroadband.com (Tony Baade)
Date: Thu, 23 Jul 2009 16:33:15 -0500
Subject: [c-nsp] OSPF question
Message-ID: <F8B9DDB2AF9FE8439B9DE9721341266787306FB4E1@WNSE07BE01.wnsclients.com>

We experienced an issue on our network where we have a link between 2 cisco ME6524s.  There was packet loss across the link, but the interfaces on either side never actually dropped.  The packet loss however was severe enough to cause problems w/ our OSPF (the neighbor session kept dropping up and down) and as a result this caused our iBGP hellos to timeout, causing an outage affecting several routers.

My question is there some way to dampen a flapping neighbor in OSPF?  So if the interface doesn't actually go down, but there is X amount of packet loss in Y amount of time (or if the neighbor goes up and down a certain number of times) the switch will recognize this issue and stop using that link? We are already using IP Event Dampening, which didn't kick in because the interfaces never actually went down.

If there's no way in OSPF to do this, is there support for this in another IGP, or is there any other workaround for this kind of situation?

Any advice is appreciated, thanks in advance,

t. baade


From ray at oneunified.net  Thu Jul 23 18:33:29 2009
From: ray at oneunified.net (Ray Burkholder)
Date: Thu, 23 Jul 2009 19:33:29 -0300
Subject: [c-nsp] OSPF question
In-Reply-To: <F8B9DDB2AF9FE8439B9DE9721341266787306FB4E1@WNSE07BE01.wnsclients.com>
References: <F8B9DDB2AF9FE8439B9DE9721341266787306FB4E1@WNSE07BE01.wnsclients.com>
Message-ID: <9D2A3771F8A84D75A64714D707BFF88B@oneunified.local>

> 
> We experienced an issue on our network where we have a link 
> between 2 cisco ME6524s.  There was packet loss across the 
> link, but the interfaces on either side never actually 
> dropped.  The packet loss however was severe enough to cause 
> problems w/ our OSPF (the neighbor session kept dropping up 
> and down) and as a result this caused our iBGP hellos to 
> timeout, causing an outage affecting several routers.
> 

Was packet loss due to congestion or to bad link quality?

If due to congestion, you can use MQOS to give the CS6 traffic dedicated
bandwidth, thus in congesion, your routing protocols won't drop.


-- 
Scanned for viruses and dangerous content at 
http://www.oneunified.net and is believed to be clean.


From rodunn at cisco.com  Thu Jul 23 22:33:27 2009
From: rodunn at cisco.com (Rodney Dunn)
Date: Thu, 23 Jul 2009 22:33:27 -0400
Subject: [c-nsp] OSPF question
In-Reply-To: <F8B9DDB2AF9FE8439B9DE9721341266787306FB4E1@WNSE07BE01.wnsclients.com>
References: <F8B9DDB2AF9FE8439B9DE9721341266787306FB4E1@WNSE07BE01.wnsclients.com>
Message-ID: <4A691D77.5090207@cisco.com>



Tony Baade wrote:
> We experienced an issue on our network where we have a link between 2 cisco ME6524s.  There was packet loss across the link, but the interfaces on either side never actually dropped.  The packet loss however was severe enough to cause problems w/ our OSPF (the neighbor session kept dropping up and down) and as a result this caused our iBGP hellos to timeout, causing an outage affecting several routers.
> 
> My question is there some way to dampen a flapping neighbor in OSPF? 

Not natively. I tried to get that in a few years ago but couldn't make 
it happen. If you wanted it bad enough you could code it up with EEM and 
a TCL script to watch for a neighbor flap and passive that interface for 
some time.

Interface event dampening covers the link flap but just for the OSPF 
transport we don't do it.

The enhancement request to track it was:

CSCsi29746    Routing protocol neighbor dampening request


  So if the interface doesn't actually go down, but there is X amount of 
packet loss in Y amount of time (or if the neighbor goes up and down a 
certain number of times) the switch will recognize this issue and stop 
using that link? We are already using IP Event Dampening, which didn't 
kick in because the interfaces never actually went down.
> 
> If there's no way in OSPF to do this, is there support for this in another IGP, or is there any other workaround for this kind of situation?
> 
> Any advice is appreciated, thanks in advance,
> 
> t. baade
> 
> _______________________________________________
> cisco-nsp mailing list  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  Fri Jul 24 00:21:46 2009
From: andy.saykao at staff.netspace.net.au (Andy Saykao)
Date: Fri, 24 Jul 2009 14:21:46 +1000
Subject: [c-nsp] vrf-lite vs. MPLS vrf
References: <mailman.5102.1248383192.2287.cisco-nsp@puck.nether.net>
Message-ID: <56F211C5E3F24F47B103EA1B253822BE044AAAA1@vic-cr-ex1.staff.netspace.net.au>

Hi Randy,

I use this web page to search for past nsp posts.

http://markmail.org/search/?q=cisco%20nsp#query:cisco%20nsp%20list%3Anet
.nether.puck.cisco-nsp+page:1+state:facets

Cheers.

Andy


This email and any files transmitted with it are confidential and intended
 solely for the use of the individual or entity to whom they are addressed. 
Please notify the sender immediately by email if you have received this 
email by mistake and delete this email from your system. Please note that
 any views or opinions presented in this email are solely those of the
 author and do not necessarily represent those of the organisation. 
Finally, the recipient should check this email and any attachments for 
the presence of viruses. The organisation accepts no liability for any 
damage caused by any virus transmitted by this email.


From gert at greenie.muc.de  Fri Jul 24 03:26:59 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Fri, 24 Jul 2009 09:26:59 +0200
Subject: [c-nsp] Questions about upgrading and image of a Modular IOS
In-Reply-To: <BCD3E762F1767C42A5226BBACDE49BFBED906F@loki.acs.local>
References: <BCD3E762F1767C42A5226BBACDE49BFBED906F@loki.acs.local>
Message-ID: <20090724072659.GZ290@greenie.muc.de>

Hi,

On Thu, Jul 23, 2009 at 09:04:40AM -0400, Jeff Cartier wrote:
> Just for peace of mind, and a good nights sleep :-)...I was hoping for
> some confirmation from the group if this is the correct way to upgrade
> the IOS (the boss is against patching the IOS).  So here are my steps...

How does Cisco currently deal with "modular IOS" upgrades and patches?

Are there patches available at all (and yes, where to find them)?  If yes,
can these patches be used to upgrade from, say, SXI1 to SXI2, or will they
only fix gaping security holes?  Are the rules for "what will be in a
patch and what not" documented somewhere?

We're in the process of upgrading a few boxes from SXI1 to SXI2 due to
BGP memory leaks.  Currently, this is "non-modular" code, but I wonder
if modular+patches would bring me the fixed BGPD without having to do
a full reload...

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/20090724/6725bec7/attachment.bin>

From Ian.Mackinnon at lumison.net  Fri Jul 24 04:13:35 2009
From: Ian.Mackinnon at lumison.net (Ian MacKinnon)
Date: Fri, 24 Jul 2009 09:13:35 +0100
Subject: [c-nsp] Questions about upgrading and image of a Modular IOS
In-Reply-To: <20090724072659.GZ290@greenie.muc.de>
References: <BCD3E762F1767C42A5226BBACDE49BFBED906F@loki.acs.local>
	<20090724072659.GZ290@greenie.muc.de>
Message-ID: <B5F945E48C137C49A98BC86DD35939C012DDE2A419@nbg01-exch-01.entlstaff.domain.lumison.net>

Hi Gert,

We looked into modular some time ago, but I don't imagine much has changed.

Patches were for as you say gaping security holes, not upgrades even of a point release.


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Gert Doering
Sent: 24 July 2009 08:27
To: Jeff Cartier
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Questions about upgrading and image of a Modular IOS

Hi,

On Thu, Jul 23, 2009 at 09:04:40AM -0400, Jeff Cartier wrote:
> Just for peace of mind, and a good nights sleep :-)...I was hoping for
> some confirmation from the group if this is the correct way to upgrade
> the IOS (the boss is against patching the IOS).  So here are my steps...

How does Cisco currently deal with "modular IOS" upgrades and patches?

Are there patches available at all (and yes, where to find them)?  If yes, can these patches be used to upgrade from, say, SXI1 to SXI2, or will they only fix gaping security holes?  Are the rules for "what will be in a patch and what not" documented somewhere?

We're in the process of upgrading a few boxes from SXI1 to SXI2 due to BGP memory leaks.  Currently, this is "non-modular" code, but I wonder if modular+patches would bring me the fixed BGPD without having to do a full reload...

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

Checked by AVG - www.avg.com
Version: 8.5.392 / Virus Database: 270.13.20/2249 - Release Date: 07/21/09 18:02:00

--

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

From bdikici at gmail.com  Fri Jul 24 04:26:31 2009
From: bdikici at gmail.com (Burak Dikici)
Date: Fri, 24 Jul 2009 11:26:31 +0300
Subject: [c-nsp] Cisco Network Registrar - TFTP redundancy
Message-ID: <d9281f5c0907240126v2ae7acccs8b153c0b21a6577b@mail.gmail.com>

 Hello ,

I am using CNR as a DNS , DHCP and TFTP server. I am planning to use DHCP ,
DNS and TFTP failover. I am thinking that , the CNR doesn't support failover
functionality for TFTP service. I can not configure multiple TFTP addresses
in the CNR's DHCP policies menu. But , i think i have found a workaround , i
can configure multiple tftp addresses in the one line with ; ( for example
192.168.1.1 ; 192.168.1.2   in the value field )
Is it possible to use multiple tftp addresses like this ?

Kind Regards...

Burak

From kilobit at gmail.com  Fri Jul 24 05:15:14 2009
From: kilobit at gmail.com (bas)
Date: Fri, 24 Jul 2009 11:15:14 +0200
Subject: [c-nsp] clear platform hardware capacity fabric counters?
Message-ID: <ba6c08fd0907240215o7e6fd26ay404a3472ef1ae3d0@mail.gmail.com>

Hello,

I haven't been able to find the command for clearing "platform
hardware capacity fabric / forwarding" counters.
Or isn't it possible? and should I reboot?

Kind regards,

Bas

From Michael.Robson at manchester.ac.uk  Fri Jul 24 05:31:55 2009
From: Michael.Robson at manchester.ac.uk (Michael Robson)
Date: Fri, 24 Jul 2009 10:31:55 +0100
Subject: [c-nsp] MTU wierdness
Message-ID: <8B081603-97F2-432C-892F-F97940220082@manchester.ac.uk>

I have a 6509 (with Sup720-3B) that contains 2 x WS-X6704-10GE blades  
where I am trying to set the MTU to be 1504 on each of these  
interfaces. On one blade it will only allow me to set the MTU to 9216  
if the interface is a switchport, the 1504 MTU size only becomes an  
option when it is changed to a routed port. Since this is not the case  
on other 6509s we have, anyone have an idea why this might be  
happening (it maybe worth noting that, at present, one of the other  
ports is a routed port with MTU of 9216)?

Thanks,


Michael
-- 






From avayner at cisco.com  Fri Jul 24 05:43:02 2009
From: avayner at cisco.com (Arie Vayner (avayner))
Date: Fri, 24 Jul 2009 11:43:02 +0200
Subject: [c-nsp] MTU wierdness
In-Reply-To: <8B081603-97F2-432C-892F-F97940220082@manchester.ac.uk>
References: <8B081603-97F2-432C-892F-F97940220082@manchester.ac.uk>
Message-ID: <78C984F8939D424697B15E4B1C1BB3D7010AA7BC@xmb-ams-331.emea.cisco.com>

Michael,

Check:
http://www.cisco.com/en/US/partner/docs/switches/lan/catalyst6500/ios/12
.2SX/configuration/guide/intrface.html#wp1041111

http://www.cisco.com/en/US/partner/docs/ios/interface/command/reference/
ir_l2.html#wp1030775
http://www.cisco.com/en/US/partner/docs/ios/fundamentals/command/referen
ce/cf_s3.html#wp1019645

I think it should be in there.

Arie

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Michael Robson
Sent: Friday, July 24, 2009 12:32
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] MTU wierdness

I have a 6509 (with Sup720-3B) that contains 2 x WS-X6704-10GE blades  
where I am trying to set the MTU to be 1504 on each of these  
interfaces. On one blade it will only allow me to set the MTU to 9216  
if the interface is a switchport, the 1504 MTU size only becomes an  
option when it is changed to a routed port. Since this is not the case  
on other 6509s we have, anyone have an idea why this might be  
happening (it maybe worth noting that, at present, one of the other  
ports is a routed port with MTU of 9216)?

Thanks,


Michael
-- 





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

From pl+list at pmacct.net  Fri Jul 24 05:12:49 2009
From: pl+list at pmacct.net (Paolo Lucente)
Date: Fri, 24 Jul 2009 10:12:49 +0100
Subject: [c-nsp] SNMP ENGINE consuming CPU
In-Reply-To: <6069A203FD01884885C037F81DD7508016CF7453E3@wsc-mail-01.intra.nwresd.k12.or.us>
References: <6069A203FD01884885C037F81DD7508016CF7453E3@wsc-mail-01.intra.nwresd.k12.or.us>
Message-ID: <20090724091249.GA21785@london.pmacct.net>

Hi Bill,

Often this is symptom that one or more NMS tools are freely walking
through the MIBs. Also, if you are running a recent 12.2SR train
image (not a recent SRD), you might be hitting the CSCsv80014 bug. 
Btw, which IOS version are you running?

A good (not specific to the 7600 platform) Cisco document about SNMP
causing high CPU load is at the following URL:

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

It simply suggests to put in place a view to cut down some pieces of
the available MIBs which can easily become rather big (ie. ARP table,
routing table). If any of the suggested solutions work, it could be
a good starting point to pin-point the issue. A more final solution,
viable only if you are somehow in control of the SNMP pollers that
regularly access your routers, is to double-check who is doing what
and why. The tricky corner case is indeed that your SNMP poller(s)
are intentionally making use of some large MIB for something.

Cheers,
Paolo


On Thu, Jul 23, 2009 at 02:04:33PM -0700, Bill Blackford wrote:

> Currently I have a 7606 RSP720 hitting 94% CPU. 
> A 'sh proc cpu sorted' indicates that SNMP ENGINE is the source.
> 
> Any thoughts on this?
> 
> Thanks
> 
> -b
> 
> --
> Bill Blackford                     
> Senior Network Engineer            
> Technology Systems Group           
> Northwest Regional ESD             
> 
> my /home away from home

From david.freedman at uk.clara.net  Fri Jul 24 07:48:24 2009
From: david.freedman at uk.clara.net (David Freedman)
Date: Fri, 24 Jul 2009 12:48:24 +0100
Subject: [c-nsp] MPLS MTU / Jumbo frames etc.
In-Reply-To: <alpine.DEB.1.10.0907231525090.4558@uplift.swm.pp.se>
References: <Pine.LNX.4.64.0907221400360.1986@orbital.burn.net>	<Pine.LNX.4.64.0907221611420.1986@orbital.burn.net>	<200907231150.31820.mtinka@globaltransit.net>	<1248352038.2795.6.camel@abehat.net.rm.dk>	<16dc01ca0b92$74fe6400$5efb2c00$@net>
	<alpine.DEB.1.10.0907231525090.4558@uplift.swm.pp.se>
Message-ID: <4A699F88.8040706@uk.clara.net>


> 
> For a 7200 with FE ports this translates into:
> 
> mpls mtu 1546

But not PA-(2)FE-TX(-ISL) or IO-(2)FE because they have an inbuilt 1530B
"on the wire" limitation


> 
> Please see discussion regarding this from ~1 year back.
> 


From david.freedman at uk.clara.net  Fri Jul 24 07:48:24 2009
From: david.freedman at uk.clara.net (David Freedman)
Date: Fri, 24 Jul 2009 12:48:24 +0100
Subject: [c-nsp] MPLS MTU / Jumbo frames etc.
In-Reply-To: <alpine.DEB.1.10.0907231525090.4558@uplift.swm.pp.se>
References: <Pine.LNX.4.64.0907221400360.1986@orbital.burn.net>	<Pine.LNX.4.64.0907221611420.1986@orbital.burn.net>	<200907231150.31820.mtinka@globaltransit.net>	<1248352038.2795.6.camel@abehat.net.rm.dk>	<16dc01ca0b92$74fe6400$5efb2c00$@net>
	<alpine.DEB.1.10.0907231525090.4558@uplift.swm.pp.se>
Message-ID: <4A699F88.8040706@uk.clara.net>


> 
> For a 7200 with FE ports this translates into:
> 
> mpls mtu 1546

But not PA-(2)FE-TX(-ISL) or IO-(2)FE because they have an inbuilt 1530B
"on the wire" limitation


> 
> Please see discussion regarding this from ~1 year back.
> 


From leonardo.souza at nec.com.br  Fri Jul 24 07:49:36 2009
From: leonardo.souza at nec.com.br (Leonardo Gama Souza)
Date: Fri, 24 Jul 2009 08:49:36 -0300
Subject: [c-nsp] RES:  vrf-lite vs. MPLS vrf
In-Reply-To: <5e2a87260907231358q680848a1l7c6b82ac73318ca3@mail.gmail.com>
References: <5e2a87260907231358q680848a1l7c6b82ac73318ca3@mail.gmail.com>
Message-ID: <9E07F8717FE8BC4FBAE6860F61EA6C1D027B0DA4@spsrvmail03.nec.br>

Hi,

> -----Mensagem original-----
> De: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] > Em nome de Randy Densen
> Enviada em: quinta-feira, 23 de julho de 2009 17:58
> Para: cisco-nsp at puck.nether.net
> Assunto: [c-nsp] vrf-lite vs. MPLS vrf
>
> This is my first post.
> I have 2 questions:
>
> 1) does The cisco-nsp Archives have a search function to look for
posts that
> may have already been addressed and/or answered?
>

You can use Google search:
site:puck.nether.net c-nsp <blablabla>

From aaron.millisor at cniteam.com  Fri Jul 24 09:08:25 2009
From: aaron.millisor at cniteam.com (Aaron Millisor)
Date: Fri, 24 Jul 2009 09:08:25 -0400
Subject: [c-nsp] MTU wierdness
In-Reply-To: <8B081603-97F2-432C-892F-F97940220082@manchester.ac.uk>
References: <8B081603-97F2-432C-892F-F97940220082@manchester.ac.uk>
Message-ID: <4A69B249.5070207@cniteam.com>

It is likely that you have configured an SVI or a VLAN on the 6509 for 
9216 already.

If any VLAN that crosses the switchport is 9216, then you can't adjust 
the MTU of the port to a value below 9216.

Do a 'show vlan' and also check all the SVI's for an MTU higher than 
1504, then either reduce the MTU in those locations or I think you could 
also restrict the large VLAN from being sent on the trunk

--
Aaron Millisor



Michael Robson wrote:
> I have a 6509 (with Sup720-3B) that contains 2 x WS-X6704-10GE blades 
> where I am trying to set the MTU to be 1504 on each of these interfaces. 
> On one blade it will only allow me to set the MTU to 9216 if the 
> interface is a switchport, the 1504 MTU size only becomes an option when 
> it is changed to a routed port. Since this is not the case on other 
> 6509s we have, anyone have an idea why this might be happening (it maybe 
> worth noting that, at present, one of the other ports is a routed port 
> with MTU of 9216)?
> 
> Thanks,
> 
> 
> Michael

From BBlackford at nwresd.k12.or.us  Fri Jul 24 09:49:01 2009
From: BBlackford at nwresd.k12.or.us (Bill Blackford)
Date: Fri, 24 Jul 2009 06:49:01 -0700
Subject: [c-nsp] SNMP ENGINE consuming CPU
In-Reply-To: <20090724091249.GA21785@london.pmacct.net>
References: <6069A203FD01884885C037F81DD7508016CF7453E3@wsc-mail-01.intra.nwresd.k12.or.us>
	<20090724091249.GA21785@london.pmacct.net>
Message-ID: <6069A203FD01884885C037F81DD7508016CF745430@wsc-mail-01.intra.nwresd.k12.or.us>

You hit on the issue. I had a NMS client polling the route table. This box has two full feeds and 12 other bilateral peers. Apparently, the cat7.6k/rsp720 doesn't do well in this scenario. I would imagine the GSR's or perhaps even the shiny new ASR's implement this in hardware, but I am speculating since I have no stick time on those platforms. I know this wouldn't be an issue on J, but that's a topic for another list.

Yes, my IOS version needs updating. I'm on 12.2(33)SRB1. Any recommendations?

Thank you for your feedback.

-b

-----Original Message-----
From: Paolo Lucente [mailto:pl+list at pmacct.net] 
Sent: Friday, July 24, 2009 2:13 AM
To: Bill Blackford
Cc: cisco-nsp mailing list
Subject: Re: [c-nsp] SNMP ENGINE consuming CPU

Hi Bill,

Often this is symptom that one or more NMS tools are freely walking
through the MIBs. Also, if you are running a recent 12.2SR train
image (not a recent SRD), you might be hitting the CSCsv80014 bug. 
Btw, which IOS version are you running?

A good (not specific to the 7600 platform) Cisco document about SNMP
causing high CPU load is at the following URL:

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

It simply suggests to put in place a view to cut down some pieces of
the available MIBs which can easily become rather big (ie. ARP table,
routing table). If any of the suggested solutions work, it could be
a good starting point to pin-point the issue. A more final solution,
viable only if you are somehow in control of the SNMP pollers that
regularly access your routers, is to double-check who is doing what
and why. The tricky corner case is indeed that your SNMP poller(s)
are intentionally making use of some large MIB for something.

Cheers,
Paolo


On Thu, Jul 23, 2009 at 02:04:33PM -0700, Bill Blackford wrote:

> Currently I have a 7606 RSP720 hitting 94% CPU. 
> A 'sh proc cpu sorted' indicates that SNMP ENGINE is the source.
> 
> Any thoughts on this?
> 
> Thanks
> 
> -b
> 
> --
> Bill Blackford                     
> Senior Network Engineer            
> Technology Systems Group           
> Northwest Regional ESD             
> 
> my /home away from home

From jfitz at Princeton.EDU  Fri Jul 24 10:45:46 2009
From: jfitz at Princeton.EDU (Jeff Fitzwater)
Date: Fri, 24 Jul 2009 10:45:46 -0400
Subject: [c-nsp] SNMP ENGINE consuming CPU
In-Reply-To: <6069A203FD01884885C037F81DD7508016CF745430@wsc-mail-01.intra.nwresd.k12.or.us>
References: <6069A203FD01884885C037F81DD7508016CF7453E3@wsc-mail-01.intra.nwresd.k12.or.us>
	<20090724091249.GA21785@london.pmacct.net>
	<6069A203FD01884885C037F81DD7508016CF745430@wsc-mail-01.intra.nwresd.k12.or.us>
Message-ID: <D5F45FC3-6686-4844-B330-6F4694C7DB36@princeton.edu>

Hello Bill,

	How large is the ARP table?   "sho ip arp summ"   If it is around 15k  
then the issue is the ARP or BRIDGE table conversion that the route  
processor must do to go from hashed format to lexigraphical  format  
which SNMP queries require.    SNMP queries the RIP table for these  
MIBS which are in HASHED format and the FIB table is in LEX format.    
There are ways around the issue if you don't need to query those MIBS.

	I have had this issue with our sup-720-CXL running SXI or any earlier  
version only on our 6500 that has a 15k arp table (not sure where the  
actual boundary that s causes the problem is).   I currently have a  
case open with CISCO to see if there is a fix for this.   For us there  
is no workaround since our NMS must pole the ARP and BRIGDE tables via  
SNMP in order to do its job.   This is extremely frustrating for us  
since we rely on the NMS   (HP NNMi ) to build our layer 2 topo based  
on those MIBS,  and also TRAP correlation which uses the L2 topo to  
isolate the problem.


Jeff Fitzwater
OIT Network & Communications Systems
Princeton University


On Jul 24, 2009, at 9:49 AM, Bill Blackford wrote:

> You hit on the issue. I had a NMS client polling the route table.  
> This box has two full feeds and 12 other bilateral peers.  
> Apparently, the cat7.6k/rsp720 doesn't do well in this scenario. I  
> would imagine the GSR's or perhaps even the shiny new ASR's  
> implement this in hardware, but I am speculating since I have no  
> stick time on those platforms. I know this wouldn't be an issue on  
> J, but that's a topic for another list.
>
> Yes, my IOS version needs updating. I'm on 12.2(33)SRB1. Any  
> recommendations?
>
> Thank you for your feedback.
>
> -b
>
> -----Original Message-----
> From: Paolo Lucente [mailto:pl+list at pmacct.net]
> Sent: Friday, July 24, 2009 2:13 AM
> To: Bill Blackford
> Cc: cisco-nsp mailing list
> Subject: Re: [c-nsp] SNMP ENGINE consuming CPU
>
> Hi Bill,
>
> Often this is symptom that one or more NMS tools are freely walking
> through the MIBs. Also, if you are running a recent 12.2SR train
> image (not a recent SRD), you might be hitting the CSCsv80014 bug.
> Btw, which IOS version are you running?
>
> A good (not specific to the 7600 platform) Cisco document about SNMP
> causing high CPU load is at the following URL:
>
> http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a00800948e6.shtml
>
> It simply suggests to put in place a view to cut down some pieces of
> the available MIBs which can easily become rather big (ie. ARP table,
> routing table). If any of the suggested solutions work, it could be
> a good starting point to pin-point the issue. A more final solution,
> viable only if you are somehow in control of the SNMP pollers that
> regularly access your routers, is to double-check who is doing what
> and why. The tricky corner case is indeed that your SNMP poller(s)
> are intentionally making use of some large MIB for something.
>
> Cheers,
> Paolo
>
>
> On Thu, Jul 23, 2009 at 02:04:33PM -0700, Bill Blackford wrote:
>
>> Currently I have a 7606 RSP720 hitting 94% CPU.
>> A 'sh proc cpu sorted' indicates that SNMP ENGINE is the source.
>>
>> Any thoughts on this?
>>
>> Thanks
>>
>> -b
>>
>> --
>> Bill Blackford
>> Senior Network Engineer
>> Technology Systems Group
>> Northwest Regional ESD
>>
>> my /home away from home
> _______________________________________________
> cisco-nsp mailing list  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 Jul 24 11:00:30 2009
From: jfitz at Princeton.EDU (Jeff Fitzwater)
Date: Fri, 24 Jul 2009 11:00:30 -0400
Subject: [c-nsp] MTU wierdness
In-Reply-To: <4A69B249.5070207@cniteam.com>
References: <8B081603-97F2-432C-892F-F97940220082@manchester.ac.uk>
	<4A69B249.5070207@cniteam.com>
Message-ID: <22D238F2-CD0B-4A8F-A047-442C3F539C8B@princeton.edu>

	Once you define the L2 MTU, packets on that VLAN can traverse any  
ports on that VLAN up to that MTU, but if you need to route them and  
retain the L2 MTU then the L3 SVI must have the same MTU.  You can  
have the SVI different, say 1500, as long as you understand that the  
packets will be fragged if larger than 1500, or dropped if the DF bit  
is set.   If you have defined an SVI to a 9k+ MTU, that will force the  
L2 interfaces on that vlan to be the same since they must carry that  
size packets.


Well its sounds good anyway, but nobody knows everything ;~)



Jeff Fitzwater
OIT Networking & Communications Systems
Princeton University

On Jul 24, 2009, at 9:08 AM, Aaron Millisor wrote:

> It is likely that you have configured an SVI or a VLAN on the 6509  
> for 9216 already.
>
> If any VLAN that crosses the switchport is 9216, then you can't  
> adjust the MTU of the port to a value below 9216.
>
> Do a 'show vlan' and also check all the SVI's for an MTU higher than  
> 1504, then either reduce the MTU in those locations or I think you  
> could also restrict the large VLAN from being sent on the trunk
>
> --
> Aaron Millisor
>
>
>
> Michael Robson wrote:
>> I have a 6509 (with Sup720-3B) that contains 2 x WS-X6704-10GE  
>> blades where I am trying to set the MTU to be 1504 on each of these  
>> interfaces. On one blade it will only allow me to set the MTU to  
>> 9216 if the interface is a switchport, the 1504 MTU size only  
>> becomes an option when it is changed to a routed port. Since this  
>> is not the case on other 6509s we have, anyone have an idea why  
>> this might be happening (it maybe worth noting that, at present,  
>> one of the other ports is a routed port with MTU of 9216)?
>> Thanks,
>> Michael
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


From Tony at bobbroadband.com  Fri Jul 24 11:54:30 2009
From: Tony at bobbroadband.com (Tony Baade)
Date: Fri, 24 Jul 2009 10:54:30 -0500
Subject: [c-nsp] OSPF question
In-Reply-To: <9D2A3771F8A84D75A64714D707BFF88B@oneunified.local>
Message-ID: <F8B9DDB2AF9FE8439B9DE9721341266787306FB555@WNSE07BE01.wnsclients.com>

The packet loss was caused poor link quality.



-----Original Message-----
From: Ray Burkholder [mailto:ray at oneunified.net] 
Sent: Thursday, July 23, 2009 5:33 PM
To: Tony Baade; cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] OSPF question

> 
> We experienced an issue on our network where we have a link 
> between 2 cisco ME6524s.  There was packet loss across the 
> link, but the interfaces on either side never actually 
> dropped.  The packet loss however was severe enough to cause 
> problems w/ our OSPF (the neighbor session kept dropping up 
> and down) and as a result this caused our iBGP hellos to 
> timeout, causing an outage affecting several routers.
> 

Was packet loss due to congestion or to bad link quality?

If due to congestion, you can use MQOS to give the CS6 traffic dedicated
bandwidth, thus in congesion, your routing protocols won't drop.


-- 
Scanned for viruses and dangerous content at 
http://www.oneunified.net and is believed to be clean.


From koug at intracom.gr  Fri Jul 24 11:54:46 2009
From: koug at intracom.gr (John Kougoulos)
Date: Fri, 24 Jul 2009 18:54:46 +0300 (GTB Daylight Time)
Subject: [c-nsp] SNMP ENGINE consuming CPU
In-Reply-To: <D5F45FC3-6686-4844-B330-6F4694C7DB36@princeton.edu>
References: <6069A203FD01884885C037F81DD7508016CF7453E3@wsc-mail-01.intra.nwresd.k12.or.us>
	<20090724091249.GA21785@london.pmacct.net>
	<6069A203FD01884885C037F81DD7508016CF745430@wsc-mail-01.intra.nwresd.k12.or.us>
	<D5F45FC3-6686-4844-B330-6F4694C7DB36@princeton.edu>
Message-ID: <alpine.WNT.2.00.0907241850040.3448@pckoug1.intranet.gr>

Hello,

I remember cisco boxes having CPU problems with retrieving arp / route 
table entries via SNMP more than ten years ago. Maybe someone must create 
some kind of snmp proxy that retrieves those tables from cli....

Regards,
John

On Fri, 24 Jul 2009, Jeff Fitzwater wrote:

> Hello Bill,
>
> 	How large is the ARP table?   "sho ip arp summ"   If it is around 15k 
> then the issue is the ARP or BRIDGE table conversion that the route processor 
> must do to go from hashed format to lexigraphical  format which SNMP queries 
> require.    SNMP queries the RIP table for these MIBS which are in HASHED 
> format and the FIB table is in LEX format.   There are ways around the issue 
> if you don't need to query those MIBS.
>
> 	I have had this issue with our sup-720-CXL running SXI or any earlier 
> version only on our 6500 that has a 15k arp table (not sure where the actual 
> boundary that s causes the problem is).   I currently have a case open with 
> CISCO to see if there is a fix for this.   For us there is no workaround 
> since our NMS must pole the ARP and BRIGDE tables via SNMP in order to do its 
> job.   This is extremely frustrating for us since we rely on the NMS   (HP 
> NNMi ) to build our layer 2 topo based on those MIBS,  and also TRAP 
> correlation which uses the L2 topo to isolate the problem.
>
>
> Jeff Fitzwater
> OIT Network & Communications Systems
> Princeton University
>
>
> On Jul 24, 2009, at 9:49 AM, Bill Blackford wrote:
>
>> You hit on the issue. I had a NMS client polling the route table. This box 
>> has two full feeds and 12 other bilateral peers. Apparently, the 
>> cat7.6k/rsp720 doesn't do well in this scenario. I would imagine the GSR's 
>> or perhaps even the shiny new ASR's implement this in hardware, but I am 
>> speculating since I have no stick time on those platforms. I know this 
>> wouldn't be an issue on J, but that's a topic for another list.
>> 
>> Yes, my IOS version needs updating. I'm on 12.2(33)SRB1. Any 
>> recommendations?
>> 
>> Thank you for your feedback.
>> 
>> -b
>> 
>> -----Original Message-----
>> From: Paolo Lucente [mailto:pl+list at pmacct.net]
>> Sent: Friday, July 24, 2009 2:13 AM
>> To: Bill Blackford
>> Cc: cisco-nsp mailing list
>> Subject: Re: [c-nsp] SNMP ENGINE consuming CPU
>> 
>> Hi Bill,
>> 
>> Often this is symptom that one or more NMS tools are freely walking
>> through the MIBs. Also, if you are running a recent 12.2SR train
>> image (not a recent SRD), you might be hitting the CSCsv80014 bug.
>> Btw, which IOS version are you running?
>> 
>> A good (not specific to the 7600 platform) Cisco document about SNMP
>> causing high CPU load is at the following URL:
>> 
>> http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a00800948e6.shtml
>> 
>> It simply suggests to put in place a view to cut down some pieces of
>> the available MIBs which can easily become rather big (ie. ARP table,
>> routing table). If any of the suggested solutions work, it could be
>> a good starting point to pin-point the issue. A more final solution,
>> viable only if you are somehow in control of the SNMP pollers that
>> regularly access your routers, is to double-check who is doing what
>> and why. The tricky corner case is indeed that your SNMP poller(s)
>> are intentionally making use of some large MIB for something.
>> 
>> Cheers,
>> Paolo
>> 
>> 
>> On Thu, Jul 23, 2009 at 02:04:33PM -0700, Bill Blackford wrote:
>> 
>>> Currently I have a 7606 RSP720 hitting 94% CPU.
>>> A 'sh proc cpu sorted' indicates that SNMP ENGINE is the source.
>>> 
>>> Any thoughts on this?
>>> 
>>> Thanks
>>> 
>>> -b
>>> 
>>> --
>>> Bill Blackford
>>> Senior Network Engineer
>>> Technology Systems Group
>>> Northwest Regional ESD
>>> 
>>> my /home away from home
>> _______________________________________________
>> cisco-nsp mailing 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 Tony at bobbroadband.com  Fri Jul 24 12:01:13 2009
From: Tony at bobbroadband.com (Tony Baade)
Date: Fri, 24 Jul 2009 11:01:13 -0500
Subject: [c-nsp] OSPF question
In-Reply-To: <4A691D77.5090207@cisco.com>
Message-ID: <F8B9DDB2AF9FE8439B9DE9721341266787306FB556@WNSE07BE01.wnsclients.com>

Does anyone know if it's available in another IGP?

Or does anyone have any sample scripts I might able to try out?



Anthony J Baade
Network Engineer
Business Only Broadband, LLC
O (630) 590-6011
C (630) 340-0696
tony at bobbroadband.com
www.bobbroadband.com
 

-----Original Message-----
From: Rodney Dunn [mailto:rodunn at cisco.com] 
Sent: Thursday, July 23, 2009 9:33 PM
To: Tony Baade
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] OSPF question



Tony Baade wrote:
> We experienced an issue on our network where we have a link between 2 cisco ME6524s.  There was packet loss across the link, but the interfaces on either side never actually dropped.  The packet loss however was severe enough to cause problems w/ our OSPF (the neighbor session kept dropping up and down) and as a result this caused our iBGP hellos to timeout, causing an outage affecting several routers.
> 
> My question is there some way to dampen a flapping neighbor in OSPF? 

Not natively. I tried to get that in a few years ago but couldn't make 
it happen. If you wanted it bad enough you could code it up with EEM and 
a TCL script to watch for a neighbor flap and passive that interface for 
some time.

Interface event dampening covers the link flap but just for the OSPF 
transport we don't do it.

The enhancement request to track it was:

CSCsi29746    Routing protocol neighbor dampening request


  So if the interface doesn't actually go down, but there is X amount of 
packet loss in Y amount of time (or if the neighbor goes up and down a 
certain number of times) the switch will recognize this issue and stop 
using that link? We are already using IP Event Dampening, which didn't 
kick in because the interfaces never actually went down.
> 
> If there's no way in OSPF to do this, is there support for this in another IGP, or is there any other workaround for this kind of situation?
> 
> Any advice is appreciated, thanks in advance,
> 
> t. baade
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

From raa at opusnet.com  Fri Jul 24 11:59:56 2009
From: raa at opusnet.com (Ruben Alvarez)
Date: Fri, 24 Jul 2009 08:59:56 -0700
Subject: [c-nsp] OSPF NSSA question
In-Reply-To: <007301ca0bc6$5cba3de0$0a00000a@nil.si>
References: <000001ca0a2c$3eacef00$bc06cd00$@com>
	<383357750907211234m147cf35ak8689bed0759acab7@mail.gmail.com>
	<000101ca0a42$f8f0f260$ead2d720$@com>
	<002101ca0a84$47c00d90$0a00000a@nil.si>
	<383357750907220109v10fe3d11y2f03d5428b7dc70a@mail.gmail.com>
	<000201ca0adf$84323c70$8c96b550$@com>
	<007301ca0bc6$5cba3de0$0a00000a@nil.si>
Message-ID: <003e01ca0c77$cbc3f8a0$634be9e0$@com>

That does look like it would work for me.  Thanks for all the input.  



-----Original Message-----
From: Ivan Pepelnjak [mailto:ip at ioshints.info] 
Sent: Thursday, July 23, 2009 11:50 AM
To: 'Ruben Alvarez'; 'Mateusz Blaszczyk'
Cc: cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] OSPF NSSA question

Hi!

You gave me a good reason to finally test this command and document what it
does and how it's used in a hub-and-spoke environment:

http://wiki.nil.com/OSPF_flooding_filters_in_hub-and-spoke_environment

It's exactly what's needed to solve the original problem (but of course you
need a static default route on the spoke routers as they lose all OSPF
information).

Best regards
Ivan
 
http://www.ioshints.info/about
http://blog.ioshints.info/ 

> -----Original Message-----
> From: Ruben Alvarez [mailto:raa at opusnet.com] 
> Sent: Wednesday, July 22, 2009 5:17 PM
> To: 'Mateusz Blaszczyk'; 'Ivan Pepelnjak'
> Cc: cisco-nsp at puck.nether.net
> Subject: RE: [c-nsp] OSPF NSSA question
> 
> I'm not sure filtering 'out' would work.  Three routers all 
> have one interface, each connecting to the ABR (which has 
> four interfaces, three to the routers in area 1 and one in 
> area 0.)  If I'm filtering out, The ABR wouldn't know which 
> routes are on each of the three routers.  Right?  The three 
> routers have thousands of single host routes spread out over 
> each router.  The ABR knows which router has each host and 
> summarizes to area 0.
> 
> -----Original Message-----
> From: Mateusz Blaszczyk [mailto:blahu77 at gmail.com]
> Sent: Wednesday, July 22, 2009 1:10 AM
> To: Ivan Pepelnjak
> Cc: Ruben Alvarez; cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] OSPF NSSA question
> 
> 2009/7/22 Ivan Pepelnjak <ip at ioshints.info>:
> > You're probably looking for the "ip ospf database-filter 
> all out" command.
> 
> And how the summary LSA with 0/0 would get to the spoke 
> router if that is filtered out?
> (assuming nssa scenario in OP's hub n'spoke topology)
> 
> Best Regards,
> 
> -mat
> 
> 



From ip at ioshints.info  Fri Jul 24 12:55:16 2009
From: ip at ioshints.info (Ivan Pepelnjak)
Date: Fri, 24 Jul 2009 18:55:16 +0200
Subject: [c-nsp] OSPF question
In-Reply-To: <F8B9DDB2AF9FE8439B9DE9721341266787306FB556@WNSE07BE01.wnsclients.com>
References: <4A691D77.5090207@cisco.com>
	<F8B9DDB2AF9FE8439B9DE9721341266787306FB556@WNSE07BE01.wnsclients.com>
Message-ID: <003901ca0c7f$862ff430$0a00000a@nil.si>

It's actually quite simple: you need an EEM applet that triggers on X
occurences of a well-known SYSLOG message (OSPF neighbor going down) within
Y seconds, modifies the configuration (to insert "passive-interface X" into
the "router ospf Y") and alerts the operators via an e-mail.

You'll find a few similar applets in my blog and my wiki:

http://wiki.nil.com/Category:EEM_applet
http://blog.ioshints.info/search/label/EEM

Ivan
 
http://www.ioshints.info/about
http://blog.ioshints.info/


> -----Original Message-----
> From: Tony Baade [mailto:Tony at bobbroadband.com] 
> Sent: Friday, July 24, 2009 6:01 PM
> To: Rodney Dunn
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] OSPF question
> 
> Does anyone know if it's available in another IGP?
> 
> Or does anyone have any sample scripts I might able to try out?
> 
> 
> 
> Anthony J Baade
> Network Engineer
> Business Only Broadband, LLC
> O (630) 590-6011
> C (630) 340-0696
> tony at bobbroadband.com
> www.bobbroadband.com
>  
> 
> -----Original Message-----
> From: Rodney Dunn [mailto:rodunn at cisco.com]
> Sent: Thursday, July 23, 2009 9:33 PM
> To: Tony Baade
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] OSPF question
> 
> 
> 
> Tony Baade wrote:
> > We experienced an issue on our network where we have a link 
> between 2 cisco ME6524s.  There was packet loss across the 
> link, but the interfaces on either side never actually 
> dropped.  The packet loss however was severe enough to cause 
> problems w/ our OSPF (the neighbor session kept dropping up 
> and down) and as a result this caused our iBGP hellos to 
> timeout, causing an outage affecting several routers.
> > 
> > My question is there some way to dampen a flapping neighbor 
> in OSPF? 
> 
> Not natively. I tried to get that in a few years ago but 
> couldn't make 
> it happen. If you wanted it bad enough you could code it up 
> with EEM and 
> a TCL script to watch for a neighbor flap and passive that 
> interface for 
> some time.
> 
> Interface event dampening covers the link flap but just for the OSPF 
> transport we don't do it.
> 
> The enhancement request to track it was:
> 
> CSCsi29746    Routing protocol neighbor dampening request
> 
> 
>   So if the interface doesn't actually go down, but there is 
> X amount of 
> packet loss in Y amount of time (or if the neighbor goes up 
> and down a 
> certain number of times) the switch will recognize this issue 
> and stop 
> using that link? We are already using IP Event Dampening, 
> which didn't 
> kick in because the interfaces never actually went down.
> > 
> > If there's no way in OSPF to do this, is there support for 
> this in another IGP, or is there any other workaround for 
> this kind of situation?
> > 
> > Any advice is appreciated, thanks in advance,
> > 
> > t. baade
> > 
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> 
> 


From daryl at introspect.net  Fri Jul 24 14:04:25 2009
From: daryl at introspect.net (Daryl G. Jurbala)
Date: Fri, 24 Jul 2009 14:04:25 -0400
Subject: [c-nsp] PPTP devices
In-Reply-To: <78C984F8939D424697B15E4B1C1BB3D7FF3C81@xmb-ams-331.emea.cisco.com>
References: <8523A296-97C9-4670-86E3-99D8B206827F@introspect.net>
	<10039.196.46.241.57.1248112808.squirrel@nexmail1.nexlinx.net.pk>
	<78C984F8939D424697B15E4B1C1BB3D7FF3C81@xmb-ams-331.emea.cisco.com>
Message-ID: <8426E4E1-2A61-4340-8C79-1C628FE2082C@introspect.net>


On Jul 20, 2009, at 5:06 PM, Arie Vayner (avayner) wrote:

> If your 3825 router is having a hard time taking care of the load, I
> would recommend you look at a 7201 (or at an older 7301).


I appreciate the responses from all.  I am testing Poptop, but am  
having some interoperability issues with my devices (even though it  
works fine when connecting to it from Windows, Linux, OS X, etc.).

I actually happen to have a 7206 VXR with an NPE-G1 in it sitting on a  
shelf.  I'm going to ship it out to the colo and see how it does.

If anyone else has any pointers to some sanely laid out chart from  
Cisco that indicated actual CPU performance across devices, I'd  
greatly appreciate it.

Thanks,
Daryl

From SHughes at GREnergy.com  Fri Jul 24 16:06:03 2009
From: SHughes at GREnergy.com (Hughes, Scott GRE/MG)
Date: Fri, 24 Jul 2009 15:06:03 -0500
Subject: [c-nsp] VRF-aware Circuit emulation?
Message-ID: <D72AC2E49DA8AB4195DF356ED05663DD60B194C2D4@MNCMS01.intra.grenergy.com>

Does anyone know if Circuit emulation using NM-CEM-4TE1 cards supports the xconnects inside a VRF?

Scott
NOTICE TO RECIPIENT: The information contained in this message from
Great River Energy and any attachments are confidential and intended
only for the named recipient(s). If you have received this message in 
error, you are prohibited from copying, distributing or using the
information. Please contact the sender immediately by return email and
delete the original message.


 

From abidin.kahraman at gmail.com  Fri Jul 24 16:06:50 2009
From: abidin.kahraman at gmail.com (Abidin Kahraman)
Date: Fri, 24 Jul 2009 21:06:50 +0100
Subject: [c-nsp] clear platform hardware capacity fabric counters?
In-Reply-To: <ba6c08fd0907240215o7e6fd26ay404a3472ef1ae3d0@mail.gmail.com>
References: <ba6c08fd0907240215o7e6fd26ay404a3472ef1ae3d0@mail.gmail.com>
Message-ID: <60761215-C244-427D-91A6-01D17BCE2D48@gmail.com>

Hello Bas,

Have you tried "clear fab peak" ?

Abidin

On 24 Jul 2009, at 10:15, bas wrote:

> Hello,
>
> I haven't been able to find the command for clearing "platform
> hardware capacity fabric / forwarding" counters.
> Or isn't it possible? and should I reboot?
>
> Kind regards,
>
> Bas
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


From tomas.hlavacek at elfove.cz  Fri Jul 24 15:15:45 2009
From: tomas.hlavacek at elfove.cz (Tomas Hlavacek)
Date: Fri, 24 Jul 2009 21:15:45 +0200
Subject: [c-nsp] L2TP pseudowire initiation from VRF
Message-ID: <4A6A0861.7080102@elfove.cz>

Greetings!

I have a question if it is possible to initiate L2TP client (not true 
LAC in fact, see config below) to use other VRF than global for L2TP 
encapsulated packets?

I have this lab scenario: LNS (Cisco 1721, 
c1700-advsecurityk9-mz.124-12.bin)

vpdn enable
!
vpdn-group 1
 accept-dialin
  protocol l2tp
  virtual-template 1
 terminate-from hostname client
 l2tp tunnel password 7 ...
!
...
interface Virtual-Template1 
 ip unnumbered Loopback0
 ip mtu 1492
 no ip mroute-cache
 peer default ip address pool l2tp-pool
 ppp authentication chap
!
...
ip local pool l2tp-pool 192.168.98.10 192.168.98.254


And on client (Cisco 1841, c1841-advipservicesk9-mz.124-23.bin) I have:

vpdn enable
!
l2tp-class l2tpclass1
 authentication
 hostname client
 password 7 ...
!
....
pseudowire-class pwclass1
 encapsulation l2tpv2
 protocol l2tpv2 l2tpclass1
 ip local interface FastEthernet0/0
 ip pmtu
!
interface Virtual-PPP1
 ip address negotiated
 no cdp enable
 ppp authentication chap
 pseudowire <ip-address-of-LNS> 10 encapsulation l2tpv2 pw-class pwclass1
!
interface FastEthernet0/0
 ip address dhcp
 duplex auto
 speed auto
!

And that works fine so far. Now I would like to do this:

ip vrf upstream1
 rd 10:20
!
interface FastEthernet0/0
 ip vrf forward upsetram1
 ip address dhcp
 duplex auto
 speed auto
!

The problem is, that VPDN can not establish L2TP session, debug says:

*Jul 24 15:54:01.332: L2X: l2tun session [1665122560], event [client request], old state [open], new state [open]
*Jul 24 15:54:01.332: L2X: L2TP: Received L2TUN message <Connect>
*Jul 24 15:54:01.332:  Tnl/Sn 20429/454 L2TP: Session state change from idle to wait-for-tunnel
*Jul 24 15:54:01.332: uid:281 Tnl/Sn 20429/454 L2TP: Create session
*Jul 24 15:54:01.332:  Tnl 20429 L2TP: SM State idle
*Jul 24 15:54:01.332: L2X: Cannot use source-ip 80.219.148.183 of tableid 0 vrf  which is not one of our addresses
*Jul 24 15:54:01.332:  Tnl 20429 L2TP: O SCCRQ 
*Jul 24 15:54:01.332:  Tnl 20429 L2TP: Parse  AVP 0, len 8, flag 0x8000 (M)
*Jul 24 15:54:01.332:  Tnl 20429 L2TP: Parse SCCRQ
*Jul 24 15:54:01.332:  Tnl 20429 L2TP: Parse  AVP 2, len 8, flag 0x8000 (M)
*Jul 24 15:54:01.332:  Tnl 20429 L2TP: Protocol Version 1
*Jul 24 15:54:01.332:  Tnl 20429 L2TP: Parse  AVP 6, len 8, flag 0x0 
*Jul 24 15:54:01.332:  Tnl 20429 L2TP: Firmware Ver 0x1130
*Jul 24 15:54:01.336:  Tnl 20429 L2TP: Parse  AVP 7, len 19, flag 0x8000 (M)
*Jul 24 15:54:01.336:  Tnl 20429 L2TP: Hostname TRENKA-office
*Jul 24 15:54:01.336:  Tnl 20429 L2TP: Parse  AVP 8, len 25, flag 0x0 
*Jul 24 15:54:01.336:  Tnl 20429 L2TP: Vendor Name Cisco Systems, Inc.
*Jul 24 15:54:01.336:  Tnl 20429 L2TP: Parse  AVP 10, len 8, flag 0x8000 (M)
*Jul 24 15:54:01.336:  Tnl 20429 L2TP: Rx Window Size 1200
*Jul 24 15:54:01.336:  Tnl 20429 L2TP: Parse  AVP 11, len 22, flag 0x8000 (M)
*Jul 24 15:54:01.336:  Tnl 20429 L2TP: Chlng  
         54 BD 4A 71 8E A0 EB 7F 67 66 A5 CC 03 75 B0 87
*Jul 24 15:54:01.336:  Tnl 20429 L2TP: Parse  AVP 9, len 8, flag 0x8000 (M)
*Jul 24 15:54:01.336:  Tnl 20429 L2TP: Assigned Tunnel ID 20429
*Jul 24 15:54:01.336:  Tnl 20429 L2TP: Parse  AVP 3, len 10, flag 0x8000 (M)
*Jul 24 15:54:01.336:  Tnl 20429 L2TP: Framing Cap 0x3
*Jul 24 15:54:01.336:  Tnl 20429 L2TP: Parse  AVP 4, len 10, flag 0x8000 (M)
*Jul 24 15:54:01.336:  Tnl 20429 L2TP: Bearer Cap 0x3
*Jul 24 15:54:01.336:  Tnl 20429 L2TP: Parse Cisco AVP 110, len 6, flag 
TRENKA-office#0x0 
*Jul 24 15:54:01.336:  Tnl 20429 L2TP: PPPoE Relay Forward Capable
*Jul 24 15:54:01.336:  Tnl 20429 L2TP: O SCCRQ, flg TLS, ver 2, len 144, tnl 0, ns 0, nr 0
         C8 02 00 90 00 00 00 00 00 00 00 00 80 08 00 00
         00 00 00 01 80 08 00 00 00 02 01 00 00 08 00 00
         00 06 11 30 80 13 00 00 00 07 54 52 45 4E 4B 41
         2D 6F 66 66 69 63 65 00 19 00 00 00 08 43 69 73
         63 6F 20 53 79 73 74 ...
*Jul 24 15:54:01.336:  Tnl 20429 L2TP: Control channel retransmit delay set to 1 seconds
*Jul 24 15:54:01.340:  Tnl 20429 L2TP: Tunnel state change from idle to wait-ctl-reply
*Jul 24 15:54:01.340:  Tnl 20429 L2TP: SM State wait-ctl-reply
*Jul 24 15:54:02.340:  Tnl 20429 L2TP: O Resend SCCRQ, flg TLS, ver 2, len 144, tnl 0, ns 0, nr 0
*Jul 24 15:54:02.340:  Tnl 20429 L2TP: Control channel retransmit delay set to 2 seconds


Is there any possibility to setup L2TP tunnel via the Fa0/0 inside VRF?

Any help would be appreciated. Thanks in advance,
Tomas

-- 
Tom?? Hlav??ek <tomas.hlavacek at elfove.cz>


From cchurc05 at harris.com  Fri Jul 24 16:28:52 2009
From: cchurc05 at harris.com (Church, Charles)
Date: Fri, 24 Jul 2009 15:28:52 -0500
Subject: [c-nsp] High Memory Usage due to NAT
In-Reply-To: <c04fd4f90907230911j5ab685d5l4100187405006a22@mail.gmail.com>
References: <c04fd4f90907230911j5ab685d5l4100187405006a22@mail.gmail.com>
Message-ID: <FA1BA229357DB640B944218F3585FECA027CAB6E@mspe2k1.cs.myharris.net>

Those are still pretty long timeouts.  Can you reduce those, a minute
for ICMP should be plenty.  2 minutes should be good for the other two.
Machines infected with stuff could certainly be opening sessions that
could be killed off quickly.

Chuck

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Hitesh Vinzoda
Sent: Thursday, July 23, 2009 12:12 PM
To: Cisco Mailing list
Subject: [c-nsp] High Memory Usage due to NAT


I m facing a strange issue regarding the NAT. The problem statement is
as
below

NAT configured on 3845 with 12.4.24 T ADV ENT SERVICES


   - Have got 64 /25 inside subnets to do the nat with 64 Live IP's. one
   each for /25 inside subnet.
   - I checked the processes and memory on freshly loaded router which
comes
   out to be 49 MB of free memory.
   - started the NAT on router with 8 of /25 inside ip pool with policy
NAT
   to 8 live IP's. The router withing 3 hours hanged due to no
availability of
   free memory. Rebooted it and removed the NAT.
   - Checked Cisco website for NAT it says 312 bytes per translation
that
   gives us around 3 MB for 10000 translations. Checked the logs and
found peak
   translation only to be 15000.
   - Found that problem was NAT ACL with any statement in destination
   portion ( extended one). Changed it with standard ACL with no any
statement.
   - Reviewed and resumed the NAT on router. it works now but it uses
around
   20 MB of memory for just 10000 translation entries.
   - Checked the UDP, TCP and ICMP timeout .... Limited UDP to 4 Mins.
TCP
   to 25 Mins and ICMP- 5 Mins. was able to free only 2 MB of so from 20
MB.
   - Changed the IOS from ADV ent services to IP base to get rid of
unwanted
   processess and services as main AIM of this router is to run NAT.
   - Freshly loaded router gave me 120 MB of free space and was happy
now to
   test out the things.
   - Againg started the NAT for 8 pools of /25 inside subnet with 8 live
   IP's ( Policy nat ).
   - At 25000 translations it eats up memory of around 24 MB.
   - Turned of Virtual Reassembly as it was reaching to thresold very
often.
   - Migrated another 8 pools of /25 which comes to total of 16 /25
Inside
   subnets and free memory left to 64 MB. with the peak translation upto
42000
   and active translation to 15000 on an average.
   - It often gives the I/O memory errors too ( with only 16 /25 Pools
   configured on it).
   - All this stuff works fine with Netscreen firewall overloaded with
only
   4 IP's for all 64 /25 pools. ..... ( Is netscreen had an edge over
cisco
   when it comes to NAT ...._?? ) I wonder..!

If Cisco says that only 312 bytes are required for storing a single
translation Why i m not able to free my DRAM memory. Tried my luck with
everything. Need some expert advice on this to figure out the High
Memory
usage of NAT....

NOTE : Only default router and no other services are used on router
apart
from Netflow

Thanks in Advance

Regards

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

From SHughes at GREnergy.com  Fri Jul 24 17:08:49 2009
From: SHughes at GREnergy.com (Hughes, Scott GRE/MG)
Date: Fri, 24 Jul 2009 16:08:49 -0500
Subject: [c-nsp] VRF-aware Circuit emulation?
In-Reply-To: <44417CD2F19FEA4F885088340A71D332020DF197@mail.office.dansketelecom.com>
References: <D72AC2E49DA8AB4195DF356ED05663DD60B194C2D4@MNCMS01.intra.grenergy.com>
	<44417CD2F19FEA4F885088340A71D332020DF197@mail.office.dansketelecom.com>
Message-ID: <D72AC2E49DA8AB4195DF356ED05663DD60B194C2E6@MNCMS01.intra.grenergy.com>

This is for an enterprise disaster-recovery scenario. The configuration is simplistic -- http://scotthughes.org/cem-failover

To clarify, I'm talking about Circuit Emulation on ISR routers. I want to emulate analog circuits using a SONET-protected Ethernet VLAN as IP backhaul. The ISR routers are used for various other (different) purposes at all 3 sites (head-end, remote, disaster recovery) and intermixing the routing tables or using route-maps and access-lists would be inconvenient. Running a VRF on a dot1q-tagged interface into the SONET would be a nice way to keep layer-3 separation for the CEM services. I would also prioritize traffic on that VLAN at the SONET level to ensure QoS.

I'm open to suggestions about alternate ways to approach this. Obviously, hanging a separate router on a VLAN solely for this purpose is inefficient (and what I'm trying to avoid)

-----Original Message-----
From: Lars Lystrup Christensen [mailto:llc at dansketelecom.com] 
Sent: Friday, July 24, 2009 3:36 PM
To: Hughes, Scott GRE/MG; cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] VRF-aware Circuit emulation?

Hi Scott,

To some degree, this would be rather odd to do as CES is a point-to-point solution and is used to transport TDM traffic. 

Please clarify why you would do this?

______________________________________

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 Hughes, Scott GRE/MG
Sent: 24. juli 2009 22:06
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] VRF-aware Circuit emulation?

Does anyone know if Circuit emulation using NM-CEM-4TE1 cards supports the xconnects inside a VRF?

Scott
NOTICE TO RECIPIENT: The information contained in this message from
Great River Energy and any attachments are confidential and intended
only for the named recipient(s). If you have received this message in 
error, you are prohibited from copying, distributing or using the
information. Please contact the sender immediately by return email and
delete the original message.


 
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
NOTICE TO RECIPIENT: The information contained in this message from
Great River Energy and any attachments are confidential and intended
only for the named recipient(s). If you have received this message in 
error, you are prohibited from copying, distributing or using the
information. Please contact the sender immediately by return email and
delete the original message.


 


From llc at dansketelecom.com  Fri Jul 24 16:36:19 2009
From: llc at dansketelecom.com (Lars Lystrup Christensen)
Date: Fri, 24 Jul 2009 22:36:19 +0200
Subject: [c-nsp] VRF-aware Circuit emulation?
In-Reply-To: <D72AC2E49DA8AB4195DF356ED05663DD60B194C2D4@MNCMS01.intra.grenergy.com>
References: <D72AC2E49DA8AB4195DF356ED05663DD60B194C2D4@MNCMS01.intra.grenergy.com>
Message-ID: <44417CD2F19FEA4F885088340A71D332020DF197@mail.office.dansketelecom.com>

Hi Scott,

To some degree, this would be rather odd to do as CES is a point-to-point solution and is used to transport TDM traffic. 

Please clarify why you would do this?

______________________________________

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 Hughes, Scott GRE/MG
Sent: 24. juli 2009 22:06
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] VRF-aware Circuit emulation?

Does anyone know if Circuit emulation using NM-CEM-4TE1 cards supports the xconnects inside a VRF?

Scott
NOTICE TO RECIPIENT: The information contained in this message from
Great River Energy and any attachments are confidential and intended
only for the named recipient(s). If you have received this message in 
error, you are prohibited from copying, distributing or using the
information. Please contact the sender immediately by return email and
delete the original message.


 
_______________________________________________
cisco-nsp mailing list  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  Fri Jul 24 19:54:53 2009
From: kilobit at gmail.com (bas)
Date: Sat, 25 Jul 2009 01:54:53 +0200
Subject: [c-nsp] clear platform hardware capacity fabric counters?
In-Reply-To: <60761215-C244-427D-91A6-01D17BCE2D48@gmail.com>
References: <ba6c08fd0907240215o7e6fd26ay404a3472ef1ae3d0@mail.gmail.com>
	<60761215-C244-427D-91A6-01D17BCE2D48@gmail.com>
Message-ID: <ba6c08fd0907241654u4c44a2a8ufa623929f5df4b98@mail.gmail.com>

Hello Abidin,

On Fri, Jul 24, 2009 at 10:06 PM, Abidin
Kahraman<abidin.kahraman at gmail.com> wrote:
> Hello Bas,
>
> Have you tried "clear fab peak" ?

Thank you, that did the trick.

I dont know how I missed that.

Do you also know how to clear the peak-pps counters in :
show platform hardware capacity forwarding

Thanks,

Bas

From bitkraft at gmail.com  Fri Jul 24 22:21:17 2009
From: bitkraft at gmail.com (Brian Spade)
Date: Fri, 24 Jul 2009 19:21:17 -0700
Subject: [c-nsp] Free NMS Tools
In-Reply-To: <20090717070140.GA22208@mx.ytti.net>
References: <F1755DA0C92B4B0F8EEA558869BD8D1B@experienbd1776>
	<4f890e580907030600y3f8e6c15qfa6c4b4db539fec@mail.gmail.com>
	<20090717070140.GA22208@mx.ytti.net>
Message-ID: <505b616c0907241921j18188f6fl51c1be48297720e8@mail.gmail.com>

Hi Saku,

On Fri, Jul 17, 2009 at 12:01 AM, Saku Ytti <saku at ytti.fi> wrote:

> On (2009-07-03 14:00 +0100), Mario Spinthiras wrote:
>
> Hey,
>
> > I would say Zenoss is looking good because of the inventory management
> you
> > can do and because of the logical structure it puts everything in. I
> wrote
> >
> > Everything else just seems inadequate or poor.
>
> I recently spent few moments evaluating zenoss and was not impressed. To me
> all OSS NMS solutions out seem like they are made by coder-in-server-admin
> not coder-in-network-admin, and as such seem to have much more integration
> with servers than with network, zenoss seems like no exception.
>

I strongly agree with you that the OSS tools seem geared towards servers and
not network.  Have you or anyone discovered a OSS solution that is more
network oriented?

Regards,
Brian

From abidin.kahraman at gmail.com  Sat Jul 25 05:22:09 2009
From: abidin.kahraman at gmail.com (Abidin Kahraman)
Date: Sat, 25 Jul 2009 10:22:09 +0100
Subject: [c-nsp] clear platform hardware capacity fabric counters?
In-Reply-To: <ba6c08fd0907241654u4c44a2a8ufa623929f5df4b98@mail.gmail.com>
References: <ba6c08fd0907240215o7e6fd26ay404a3472ef1ae3d0@mail.gmail.com>
	<60761215-C244-427D-91A6-01D17BCE2D48@gmail.com>
	<ba6c08fd0907241654u4c44a2a8ufa623929f5df4b98@mail.gmail.com>
Message-ID: <7866B61A-86A4-489F-84C5-F01356C12E40@gmail.com>

You may try "clear mls stat" but not quite sure..

Abidin

On 25 Jul 2009, at 00:54, bas wrote:

> Hello Abidin,
>
> On Fri, Jul 24, 2009 at 10:06 PM, Abidin
> Kahraman<abidin.kahraman at gmail.com> wrote:
>> Hello Bas,
>>
>> Have you tried "clear fab peak" ?
>
> Thank you, that did the trick.
>
> I dont know how I missed that.
>
> Do you also know how to clear the peak-pps counters in :
> show platform hardware capacity forwarding
>
> Thanks,
>
> Bas


From nasir.shaikh at bt.com  Sat Jul 25 08:54:43 2009
From: nasir.shaikh at bt.com (nasir.shaikh at bt.com)
Date: Sat, 25 Jul 2009 13:54:43 +0100
Subject: [c-nsp] Baseline CoPP policies?
In-Reply-To: <000301ca004e$06449f10$2101a8c0@reap>
Message-ID: <D312CD05C8083447B01F57DCDECCF60001C210FE@E03MVZ4-UKDY.domain1.systemhost.net>

Hi,
I had a MAN running on 12 6504Es and I have had to connect one of the
boxes directly to an ISP switch to deliver Internet to a remote FW.

As the MAN was fairly protected I had not implemented CoPP but now it is
mandatory and needs to be implemented fast.
Does anyone have a template that I can build on? Preferably in
conjuction with the special-cases rate-limiters.

I am running BGP, IS-IS, EIGRP, MPLS, BFD, HSRP, EoMPLS on the box
connecting to the ISP. However, on the interface connecting to the ISP
there is nothing except HSRP and the only traffic that I expect from
that interface is transit traffic to the remote FW. So I am thinking
that an iACL on the interface should also be sufficient till I have had
the time to develop and test the CoPP config.

I am running 12.2(18)SXF16 adv ip on the 6504-E.

Any ideas?

Nasir Shaikh 


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Daniel Dib
Sent: 09 July 2009 06:31
To: 'Justin Shore'; 'Siva Valliappan'
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Baseline CoPP policies?

Sorry for toppost. It would be nice to be able to match IS-IS directly
but
there are workarounds. Either have a class that matches all IP that is
left
after all your other classes, not class-default. The only thing that
will be
left after that is IS-IS. Or use mls qos protocol passthrough if you
want to
police IS-IS, if there is a meaning policing it.

/Daniel

Justin Shore wrote:

One thing that the documentation always lacks is sufficient info on 
handling IS-IS with CoPP.  The inability of IOS to match IS-IS traffic 
without using class-default is a major problem.  Of all the people that 
would need CoPP (people with publicly exposed routers like SPs) one 
would think that IS-IS support for CoPP would be a big deal.

Is there a specific dev group within Cisco that I can point my account 
team to that would be the one to consider my feature request.

Justin


Siva Valliappan wrote:
> Hi Drew,
> 
>    have you looked at the following docs:
> 
> http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html
> 
> and
> 
>
http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6642
/pro
d_white_paper0900aecd804fa16a.html 
 

__________ Information from ESET NOD32 Antivirus, version of virus
signature
database 4225 (20090708) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.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 maillist at webjogger.net  Sat Jul 25 09:14:21 2009
From: maillist at webjogger.net (Adam Greene)
Date: Sat, 25 Jul 2009 09:14:21 -0400
Subject: [c-nsp] BGP failover for two traffic types
References: <479E7073E55C4CFD83C670BCEC0CFDD6@GINKGO>
	<005701ca0bac$8bd6c8b0$0a00000a@nil.si>
Message-ID: <86F3B9B3DDD146D8AEB72ABDDC84951A@GINKGO>

All who replied to this thread ... thanks much for the valuable food for 
thought! Much appreciated.

Adam 



From rdobbins at arbor.net  Sat Jul 25 10:25:01 2009
From: rdobbins at arbor.net (Roland Dobbins)
Date: Sat, 25 Jul 2009 21:25:01 +0700
Subject: [c-nsp] Baseline CoPP policies?
In-Reply-To: <D312CD05C8083447B01F57DCDECCF60001C210FE@E03MVZ4-UKDY.domain1.systemhost.net>
References: <D312CD05C8083447B01F57DCDECCF60001C210FE@E03MVZ4-UKDY.domain1.systemhost.net>
Message-ID: <97822D43-73BB-41E1-9512-A1BEF213EB8C@arbor.net>


On Jul 25, 2009, at 7:54 PM, <nasir.shaikh at bt.com>  
<nasir.shaikh at bt.com> wrote:

> So I am thinking that an iACL on the interface should also be  
> sufficient till I have had
> the time to develop and test the CoPP config.


Correct - and if you're running a Sup720, so that ACL counters work,  
you can put in some permits prior to your denies so that the iACL  
serves as a classification ACL for CoPP.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

         Unfortunately, inefficiency scales really well.

		   -- Kevin Lawton


From secadmin at netsecdesign.com  Sat Jul 25 14:20:54 2009
From: secadmin at netsecdesign.com (Security Admin (NetSec))
Date: Sat, 25 Jul 2009 11:20:54 -0700
Subject: [c-nsp] Dumb question of the day (on vlans)
Message-ID: <8D870AB38C30EC4C848A11A3F83D20D8D5017D839D@exchange2007.mmicmanhomenet.local>

If this is the wrong question for this newsgroup my apologies

Been having trouble setting up vlans on a Cisco 2950 switch.  I add one using the typical method via CLI:

Int vlan x
Ip address 192.xxx.yyy.zzz 255.255.255.240
No ip route-cache
No shut

The CLI screen notes that the vlan is up. As soon as I add another vlan (vlan y) vlan y will come up but vlan x will administratively go down.  This process is repeated each time I add a vlan so that only one vlan is up at any one time, which is the last vlan created.  Please note that I have vlan 1 shutdown and it is not used.

Question is how do I keep all my vlans up simultaneously?

Thanks in advance...

From marco at linuxgoeroe.dhs.org  Sat Jul 25 14:27:50 2009
From: marco at linuxgoeroe.dhs.org (Marco van den Bovenkamp)
Date: Sat, 25 Jul 2009 20:27:50 +0200
Subject: [c-nsp] Dumb question of the day (on vlans)
In-Reply-To: <8D870AB38C30EC4C848A11A3F83D20D8D5017D839D@exchange2007.mmicmanhomenet.local>
References: <8D870AB38C30EC4C848A11A3F83D20D8D5017D839D@exchange2007.mmicmanhomenet.local>
Message-ID: <4A6B4EA6.3080001@linuxgoeroe.dhs.org>

Security Admin (NetSec) wrote:

> Been having trouble setting up vlans on a Cisco 2950 switch.  I add one using the typical method via CLI:
> 
> Int vlan x
> Ip address 192.xxx.yyy.zzz 255.255.255.240
> No ip route-cache
> No shut
> 
> The CLI screen notes that the vlan is up. As soon as I add another vlan (vlan y) vlan y will come up but vlan x will administratively go down.  This process is repeated each time I add a vlan so that only one vlan is up at any one time, which is the last vlan created.  Please note that I have vlan 1 shutdown and it is not used.
> 
> Question is how do I keep all my vlans up simultaneously?

You don't, at least not like that. A 2950 is a pure L2 switch, and it 
can have only one IP address at the same time, purely for management 
purposes. So as soon as you assign an IP adress to a VLAN interface (the 
'int vlan xxx' command), the other one will go admin down.

You create L2 VLANs with the 'vlan xxx' command.

		Regards,

			Marco.

From rwest at zyedge.com  Sat Jul 25 14:31:45 2009
From: rwest at zyedge.com (Ryan West)
Date: Sat, 25 Jul 2009 14:31:45 -0400
Subject: [c-nsp] Dumb question of the day (on vlans)
In-Reply-To: <8D870AB38C30EC4C848A11A3F83D20D8D5017D839D@exchange2007.mmicmanhomenet.local>
References: <8D870AB38C30EC4C848A11A3F83D20D8D5017D839D@exchange2007.mmicmanhomenet.local>
Message-ID: <6E21B2BDEF6E714EA0B5BA8D5D0E1401248380B2C8@zy-ex1.zyedge.local>

Hi.  The 2950 does not do inter-vlan routing, therefore you can only have a single management VLAN with an IP address at any one time.

HTH

-ryan

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Security Admin (NetSec)
Sent: Saturday, July 25, 2009 2:21 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Dumb question of the day (on vlans)

If this is the wrong question for this newsgroup my apologies

Been having trouble setting up vlans on a Cisco 2950 switch.  I add one using the typical method via CLI:

Int vlan x
Ip address 192.xxx.yyy.zzz 255.255.255.240
No ip route-cache
No shut

The CLI screen notes that the vlan is up. As soon as I add another vlan (vlan y) vlan y will come up but vlan x will administratively go down.  This process is repeated each time I add a vlan so that only one vlan is up at any one time, which is the last vlan created.  Please note that I have vlan 1 shutdown and it is not used.

Question is how do I keep all my vlans up simultaneously?

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 jeff-kell at utc.edu  Sat Jul 25 14:34:44 2009
From: jeff-kell at utc.edu (Jeff Kell)
Date: Sat, 25 Jul 2009 14:34:44 -0400
Subject: [c-nsp] Dumb question of the day (on vlans)
In-Reply-To: <8D870AB38C30EC4C848A11A3F83D20D8D5017D839D@exchange2007.mmicmanhomenet.local>
References: <8D870AB38C30EC4C848A11A3F83D20D8D5017D839D@exchange2007.mmicmanhomenet.local>
Message-ID: <4A6B5044.5030205@utc.edu>

You have a layer-2 2950 switch, and you're trying to add multiple SVIs 
to it.  A layer-2 switch can only have one active SVI which corresponds 
to the management vlan/address.  Consequently, you can only have one 
active at a time, and it will keep the others shutdown.

To add vlans to the switch, just use the "vlan" commands.  You don't 
need SVIs for layer-2 vlans.  If you DO want to route multiple vlans, 
you'll need a layer-3 switch (e.g., a 3550).

Jeff

Security Admin (NetSec) wrote:
> If this is the wrong question for this newsgroup my apologies
>
> Been having trouble setting up vlans on a Cisco 2950 switch.  I add one using the typical method via CLI:
>
> Int vlan x
> Ip address 192.xxx.yyy.zzz 255.255.255.240
> No ip route-cache
> No shut
>
> The CLI screen notes that the vlan is up. As soon as I add another vlan (vlan y) vlan y will come up but vlan x will administratively go down.  This process is repeated each time I add a vlan so that only one vlan is up at any one time, which is the last vlan created.  Please note that I have vlan 1 shutdown and it is not used.
>
> Question is how do I keep all my vlans up simultaneously?


From elmonomario69 at gmail.com  Sat Jul 25 14:41:50 2009
From: elmonomario69 at gmail.com (.....::::[Gardener] ::::.....)
Date: Sat, 25 Jul 2009 16:41:50 -0200
Subject: [c-nsp] TCLsh + Ping TOS
In-Reply-To: <b5da8bca0907230659n2cb6d745kf506cb540e6071ac@mail.gmail.com>
References: <cf70832e0907200958o62ef7a71w3b8a51463c64201a@mail.gmail.com> 
	<b5da8bca0907230659n2cb6d745kf506cb540e6071ac@mail.gmail.com>
Message-ID: <cf70832e0907251141v4e0c8d4cqdc3e62db7264a16a@mail.gmail.com>

OK, guys.

Let me share with you my script of TCL to make a lot of test over a CE
router.

Thanks to all for the information.


Router#Tclsh tftp://xxx.xxx.xxx.xxx/anything.tcl *Next-hop* *interface **
ipaddress*
** Variable **Next-hop*
** Variable interface*
** Variable ipaddress

**BOF

**set nexthop [lindex $argv 0]
set interface [lindex $argv 1]
set ipaddress [lindex $argv 2]

exec "terminal length 0"
puts "############################################"
puts "#####         SHOW VERSION          ####"
puts "############################################"
puts [show version]
puts "############################################"
puts "#####         SHOW INVENTORY          ####"
puts "############################################"
puts [show inventory]
puts "############################################"
puts "#####         SHOW INTERFACE        ####"
puts "############################################"
puts [show interface]
puts "############################################"
puts "#####     SHOW PROCESSES CPU HISTORY    ####"
puts "############################################"
puts [show processes cpu history]
puts "############################################"
puts "##### SHOW PROCESSES CPU SORTED 5 MIN.  ####"
puts "############################################"
puts [show processes cpu sorted | e 0.00%  0.00%  0.00%]
puts "############################################"
puts "#####         SHOW RUNNING-CONFIG   ####"
puts "############################################"
puts [show running-config]
puts "############################################"
puts "#####         SHOW IP ROUTE          ####"
puts "############################################"
puts [show ip route]
puts "############################################"
puts "#####         SHOW IP BGP          ####"
puts "############################################"
puts [show ip bgp]
puts "############################################"
puts "#####         SHOW IP BGP SUMMARY   ####"
puts "############################################"
puts [show ip bgp summary]
puts "############################################\n"
puts "#####     SHOW IP BGP ADVERTISED-ROUTES ####\n"
puts "############################################\n"
puts [show ip bgp neighbor $nexthop advertised-route]

puts
"##################################################################################\n"
puts
"##################################################################################\n"
puts "############################################\n"
puts "##### CONFIGURANDO CALIDADES DE PRUEBA  ####\n"
puts "############################################\n"
puts [conf t]
puts [class-map match-any rpvm_voz_P]
puts [match ip dscp 24]
puts [match ip dscp 40]
puts [match ip dscp 46]
puts [class-map match-any rpvm_video_P]
puts [match ip dscp 34]
puts [match ip dscp 36]
puts [match ip dscp 38]
puts [class-map match-any rpvm_datos_criticos_P]
puts [match ip dscp 16]
puts [match ip dscp 26]
puts [match ip dscp 28]
puts [match ip dscp 30]
puts [class-map match-any rpvm_business_P]
puts [match ip dscp 8]
puts [match ip dscp 18]
puts [match ip dscp 20]
puts [match ip dscp 22]
puts [exit]
puts [policy-map prueba]
puts [class rpvm_voz_P]
puts [class rpvm_video_P]
puts [class rpvm_datos_criticos_P]
puts [class rpvm_business_P]
puts [exit]
puts [interface $interface]
puts [service-policy input prueba]
puts [exit]
puts [exit]




puts "############################################"
puts "#####          PING CON SWEEP            ####"
puts "############################################"
typeahead "$ipaddress\n\n\n\n\y\n\n\n\n\n\n\V\n\n\y\n100\n1500\n100\n"
puts [ping ip]

puts "############################################"
puts "#####  PING 80 PAQUETES CON TOS 96      ####"
puts "############################################"
typeahead "$ipaddress\n80\n\n\n\y\n\n96\n\n\n\n\n\n\n"
puts [ping ip]
typeahead "\n"
puts "############################################"
puts "#####  SHOW POLICY-MAP INTERFACE INPUT  ####"
puts "############################################"
puts [show policy-map interface $interface input]

puts "############################################"
puts "#####                FIN                ####"
puts "############################################"
tclquit

*
*EOF

***
I know, there are sure are plenty of script better of this.. But i think,
it's good enough for me.

See Ya

Andres P. Spano


----------------------
NO STREES
ECO ATTITUD :D

From jarod125 at gmail.com  Sat Jul 25 17:29:24 2009
From: jarod125 at gmail.com (Gabriel)
Date: Sun, 26 Jul 2009 00:29:24 +0300
Subject: [c-nsp] 7206VXRG2 performance question
Message-ID: <4cd59bf50907251429p2d695ebdme4e1d9ebcb02531c@mail.gmail.com>

Hi all,

the company I work for is involved in a WAN redesing process, so we
got in touch with a few Cisco partners to help us. We're considering a
dual-hub and spoke topology (about 100 spokes, more in the future)
with both hubs active (half of the spokes will connect to one hub, the
other half to the other).

As I said, we contacted some Cisco partners (as we don't have the
necessary expertise to do this on our own) and one of them recommended
that, besides using the 7206 (with NPE-G2 and VSA) as the hub router,
we should also get a SCE1010 box to handle the QoS.

One of the aspects I'd like your feedback on is whether this SCE box
is required or not (from the docs and design guides I read, it was
only present in SP networks). I'll try to give more details (please
let me know if they are relevant or not and what others have I
missed):

- DMVPN (although one tunnel/branch was also suggested) over IPSec
- spokes connect to hubs via two providers (with per-flow load-balancing)
- hub bandwith will probably not exceed 10 mbit/provider
- spoke bandwith will be 256kbps/provider for roughly half of the
spokes and 128kbps/provider for the other half
- EIGRP as routing protocol
- no VoIP at the moment, but it could appear sometime in the future

Traffic is not latency-sensitive (as I said, no VoIP yet) and will be
split into four QoS classes (in the future, others might appear).

So, based on the above, can you comment on the capabilities of the
7206 alone to handle everything without issues?

Thanks,
Gabriel

From secadmin at netsecdesign.com  Sat Jul 25 18:04:32 2009
From: secadmin at netsecdesign.com (Security Admin (NetSec))
Date: Sat, 25 Jul 2009 15:04:32 -0700
Subject: [c-nsp] Dumb question of the day (on vlans)
Message-ID: <8D870AB38C30EC4C848A11A3F83D20D8D5017D839F@exchange2007.mmicmanhomenet.local>

Doh!  Forgot it was a L2 switch.  Management is not the major issue on multiple vlans, just need vlans to separate out different functional internet facing servers (i.e. DNS, HTTP, SMTP).  I had them on a 3560 but the switch had internal vlan networks on it and for security reasons wanted to put them on a separate switch.



Thanks!


From frnkblk at iname.com  Sat Jul 25 21:21:29 2009
From: frnkblk at iname.com (Frank Bulk)
Date: Sat, 25 Jul 2009 20:21:29 -0500
Subject: [c-nsp] Dumb question of the day (on vlans)
In-Reply-To: <4A6B4EA6.3080001@linuxgoeroe.dhs.org>
References: <8D870AB38C30EC4C848A11A3F83D20D8D5017D839D@exchange2007.mmicmanhomenet.local>
	<4A6B4EA6.3080001@linuxgoeroe.dhs.org>
Message-ID: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAD5aX3AfetPSIT8PVYM4M5wAQAAAAA=@iname.com>

I believe that each VLAN on the 2950 (active or not) can have multiple IP
addresses, by making them secondary.  

Frank

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Marco van den
Bovenkamp
Sent: Saturday, July 25, 2009 1:28 PM
To: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Dumb question of the day (on vlans)

Security Admin (NetSec) wrote:

> Been having trouble setting up vlans on a Cisco 2950 switch.  I add one
using the typical method via CLI:
> 
> Int vlan x
> Ip address 192.xxx.yyy.zzz 255.255.255.240
> No ip route-cache
> No shut
> 
> The CLI screen notes that the vlan is up. As soon as I add another vlan
(vlan y) vlan y will come up but vlan x will administratively go down.  This
process is repeated each time I add a vlan so that only one vlan is up at
any one time, which is the last vlan created.  Please note that I have vlan
1 shutdown and it is not used.
> 
> Question is how do I keep all my vlans up simultaneously?

You don't, at least not like that. A 2950 is a pure L2 switch, and it 
can have only one IP address at the same time, purely for management 
purposes. So as soon as you assign an IP adress to a VLAN interface (the 
'int vlan xxx' command), the other one will go admin down.

You create L2 VLANs with the 'vlan xxx' command.

		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/


From bacon at walleyesoftware.com  Sat Jul 25 23:12:16 2009
From: bacon at walleyesoftware.com (Jeff Bacon)
Date: Sat, 25 Jul 2009 22:12:16 -0500
Subject: [c-nsp] VRF-lite to do L3 passthru
Message-ID: <5A69C25361FED34F83ABF05F5047524505CD833C@wally.walleyetrading.net>

So, I have this dot1q trunk on which I receive a bunch of vlans, each of
which is its own P-T-P circuit to <somewhere>. It's connected to a
6500/sup720. 

Currently I bring it in as a dot1q trunk on a switchport, map the VLANs,
and then use SVIs to handle layer-3. 

However, I would really like to pass off some of the circuits to other
devices, without the 6500's global RIB being involved. (The 6500 is one
of my edge devices that I use to connect to a bunch of other vendors,
and it along with its twin do lots of stuff. But then there's other
activities - imagine, say, I want to run an internal WAN link over the
trunk. I don't want to have to clutter the 6500's global RIB with my
internal routes just to pass the link through it.) 

This seems like what VRF-lite is meant to do. Only the docs appear all
sort of skewed towards MPLS VPN implementations and BGP, and I'm not
doing MPLS tag switching here, or BGP. I guess I just want mini virtual
router instances running EIGRP to tie <this incoming dot1q VLAN> to
<this other port> so I can spin off some of the incoming VLANs/ckts to
the other devices they're meant for. 

(This is about cost - I can have each ckt be its own port off the
provider's equipment and thus have every ckt go to the device intended,
but that's an additional $150-300/mo xconnect charge from my co-lo
provider plus I get bulk discounts from the provider by bringing
everything in on a gig trunk - they don't have to chew up as many ports
on their equipment.)

I think I get the basic idea - 

vrf fred
  rd 1:2
router eigrp 20
  network 20.0.0.0
  address-family fred
     network 10.0.0.0
     no auto-summary
int g2/1
   desc dot1q trunk from provider
int g2/1.2000
   desc incoming ckt I need to go somewhere else
   encap dot1q 2000 
   ip vrf fred 
   ip address 10.5.5.2 255.255.255.252
int g2/1.3000
   desc incoming ckt that the 6500 should deal with
   encap dot1q 3000
   ip address 20.1.1.1 255.255.255.252
   other normal stuff 
int g4/3
   desc port to some-other-router
   ip vrf fred
   ip address 10.4.4.2 255.255.255.252 

is it really that simple? Will VRF-lite work without actually using BGP
or MPLS? Are there docs somewhere in the Cisco spiderweb which are
clearer on the topic than the ones which are part of the SX doc train?

Thanks,
-bacon


From rodunn at cisco.com  Sat Jul 25 23:17:05 2009
From: rodunn at cisco.com (Rodney Dunn)
Date: Sat, 25 Jul 2009 23:17:05 -0400
Subject: [c-nsp] 7206VXRG2 performance question
In-Reply-To: <4cd59bf50907251429p2d695ebdme4e1d9ebcb02531c@mail.gmail.com>
References: <4cd59bf50907251429p2d695ebdme4e1d9ebcb02531c@mail.gmail.com>
Message-ID: <4A6BCAB1.60304@cisco.com>

For those low rates a 7206VXR with a NPE-G2 would be a plenty.

You should look at dynamic VTI's I think it is to get "per spoke" QOS.

You don't need an external box especially if your link speeds at the 
spokes are static.

There are different ways to do "per spoke" QOS but it's a bit more 
complex with dmvpn.

http://www.cisco.com/en/US/docs/ios/security/configuration/guide/sec_per_tunnel_qos.html

Rodney



Gabriel wrote:
> Hi all,
> 
> the company I work for is involved in a WAN redesing process, so we
> got in touch with a few Cisco partners to help us. We're considering a
> dual-hub and spoke topology (about 100 spokes, more in the future)
> with both hubs active (half of the spokes will connect to one hub, the
> other half to the other).
> 
> As I said, we contacted some Cisco partners (as we don't have the
> necessary expertise to do this on our own) and one of them recommended
> that, besides using the 7206 (with NPE-G2 and VSA) as the hub router,
> we should also get a SCE1010 box to handle the QoS.
> 
> One of the aspects I'd like your feedback on is whether this SCE box
> is required or not (from the docs and design guides I read, it was
> only present in SP networks). I'll try to give more details (please
> let me know if they are relevant or not and what others have I
> missed):
> 
> - DMVPN (although one tunnel/branch was also suggested) over IPSec
> - spokes connect to hubs via two providers (with per-flow load-balancing)
> - hub bandwith will probably not exceed 10 mbit/provider
> - spoke bandwith will be 256kbps/provider for roughly half of the
> spokes and 128kbps/provider for the other half
> - EIGRP as routing protocol
> - no VoIP at the moment, but it could appear sometime in the future
> 
> Traffic is not latency-sensitive (as I said, no VoIP yet) and will be
> split into four QoS classes (in the future, others might appear).
> 
> So, based on the above, can you comment on the capabilities of the
> 7206 alone to handle everything without issues?
> 
> Thanks,
> Gabriel
> _______________________________________________
> cisco-nsp mailing list  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  Sun Jul 26 00:18:05 2009
From: rodunn at cisco.com (Rodney Dunn)
Date: Sun, 26 Jul 2009 00:18:05 -0400
Subject: [c-nsp] VRF-lite to do L3 passthru
In-Reply-To: <5A69C25361FED34F83ABF05F5047524505CD833C@wally.walleyetrading.net>
References: <5A69C25361FED34F83ABF05F5047524505CD833C@wally.walleyetrading.net>
Message-ID: <4A6BD8FD.7080204@cisco.com>

It's just that simple. ;)

The problem comes if you want the routing table separation at multiple 
hops in a network. It usually doesn't scale to do VRF lite on every hop 
because it would be a configuration challenge.

But if it's just to differential the RIB on one box what you have will 
do it.

Or depending on where you want to dump the vlan out at you may look at a 
L2tpv3 xconnect (you have to get the hardware to support it though) and 
carry it L2 all the way through the ip network. I'd say EoMPLS but you 
need MPLS for that.

Rodney



Jeff Bacon wrote:
> So, I have this dot1q trunk on which I receive a bunch of vlans, each of
> which is its own P-T-P circuit to <somewhere>. It's connected to a
> 6500/sup720. 
> 
> Currently I bring it in as a dot1q trunk on a switchport, map the VLANs,
> and then use SVIs to handle layer-3. 
> 
> However, I would really like to pass off some of the circuits to other
> devices, without the 6500's global RIB being involved. (The 6500 is one
> of my edge devices that I use to connect to a bunch of other vendors,
> and it along with its twin do lots of stuff. But then there's other
> activities - imagine, say, I want to run an internal WAN link over the
> trunk. I don't want to have to clutter the 6500's global RIB with my
> internal routes just to pass the link through it.) 
> 
> This seems like what VRF-lite is meant to do. Only the docs appear all
> sort of skewed towards MPLS VPN implementations and BGP, and I'm not
> doing MPLS tag switching here, or BGP. I guess I just want mini virtual
> router instances running EIGRP to tie <this incoming dot1q VLAN> to
> <this other port> so I can spin off some of the incoming VLANs/ckts to
> the other devices they're meant for. 
> 
> (This is about cost - I can have each ckt be its own port off the
> provider's equipment and thus have every ckt go to the device intended,
> but that's an additional $150-300/mo xconnect charge from my co-lo
> provider plus I get bulk discounts from the provider by bringing
> everything in on a gig trunk - they don't have to chew up as many ports
> on their equipment.)
> 
> I think I get the basic idea - 
> 
> vrf fred
>   rd 1:2
> router eigrp 20
>   network 20.0.0.0
>   address-family fred
>      network 10.0.0.0
>      no auto-summary
> int g2/1
>    desc dot1q trunk from provider
> int g2/1.2000
>    desc incoming ckt I need to go somewhere else
>    encap dot1q 2000 
>    ip vrf fred 
>    ip address 10.5.5.2 255.255.255.252
> int g2/1.3000
>    desc incoming ckt that the 6500 should deal with
>    encap dot1q 3000
>    ip address 20.1.1.1 255.255.255.252
>    other normal stuff 
> int g4/3
>    desc port to some-other-router
>    ip vrf fred
>    ip address 10.4.4.2 255.255.255.252 
> 
> is it really that simple? Will VRF-lite work without actually using BGP
> or MPLS? Are there docs somewhere in the Cisco spiderweb which are
> clearer on the topic than the ones which are part of the SX doc train?
> 
> Thanks,
> -bacon
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

From shanawaz at gmail.com  Sun Jul 26 01:05:08 2009
From: shanawaz at gmail.com (Shanawaz)
Date: Sun, 26 Jul 2009 15:05:08 +1000
Subject: [c-nsp] Question on h.323 video calls through a PIX 525 with NAT
In-Reply-To: <338c6fe20907252203w7ee07c74o32d191230ffce8d0@mail.gmail.com>
References: <338c6fe20907252203w7ee07c74o32d191230ffce8d0@mail.gmail.com>
Message-ID: <338c6fe20907252205i65f23463w9e1314ff08254ecb@mail.gmail.com>

 Hi,

We used to have lots of similar issues (one way video) when we ran H323
through PIX/ASA.

Static 1-1 Nat fixed a few issues. (I hope you are not running PAT). The
other issue we had was in regards to the nat time out. We found that when we
make calls in quick succession, we had to manually clear the translations to
avoid some of those issues.

I dont do a lot of work with video. Do let us know if you find something

Regards,
Shanawaz

From zivl at gilat.net  Sun Jul 26 03:14:05 2009
From: zivl at gilat.net (Ziv Leyes)
Date: Sun, 26 Jul 2009 10:14:05 +0300
Subject: [c-nsp] Baseline CoPP policies?
In-Reply-To: <97822D43-73BB-41E1-9512-A1BEF213EB8C@arbor.net>
References: <D312CD05C8083447B01F57DCDECCF60001C210FE@E03MVZ4-UKDY.domain1.systemhost.net>
	<97822D43-73BB-41E1-9512-A1BEF213EB8C@arbor.net>
Message-ID: <EC993E87D960A541A66BF21D62AA42A623016E9971@exch2k7.gilat.local>

Here are a couple of links that helped me out when I needed it the first time

This one contains some info about CoPP, thought it's quite an old document, it's still relevant
http://aharp.ittns.northwestern.edu/papers/copp.html

You may also consider securing the device all around, not only by CoPP, here's some useful info about Cisco security, this one is maintained and updated regularly.
http://www.cymru.com/Documents/secure-ios-template.html

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 Roland Dobbins
Sent: Saturday, July 25, 2009 5:25 PM
To: Cisco-nsp
Subject: Re: [c-nsp] Baseline CoPP policies?


On Jul 25, 2009, at 7:54 PM, <nasir.shaikh at bt.com>  
<nasir.shaikh at bt.com> wrote:

> So I am thinking that an iACL on the interface should also be  
> sufficient till I have had
> the time to develop and test the CoPP config.


Correct - and if you're running a Sup720, so that ACL counters work,  
you can put in some permits prior to your denies so that the iACL  
serves as a classification ACL for CoPP.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

         Unfortunately, inefficiency scales really well.

		   -- Kevin Lawton

_______________________________________________
cisco-nsp mailing 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 arutz at pocsmadar.hu  Sun Jul 26 10:33:24 2009
From: arutz at pocsmadar.hu (Antal Rutz)
Date: Sun, 26 Jul 2009 16:33:24 +0200
Subject: [c-nsp] X.25 performance problem
Message-ID: <4A6C6934.6090203@pocsmadar.hu>

Hi,

Does anyone have information about X.25 packet switching performance on 
ISRs?

Problem:
One of our customers reported about very high CPU load (mainly causing 
by the "IP input" process) on our 2811s. The 2811 routes X.25 packets 
arriving on its serial interfaces to the server sitting on the LAN over XOT.
There are 30 SVCs simultaneously on the router and the CPU runs 98% 
which affects the console response time, too.
Unfortunately I'm not near the console to investigate it right now but 
for me it seems that the router got stucked in process switching.

Two questions:
1. Does anyone know the limits of parallel X.25 SVCs on a router (namely 
2800 and 3800)?
2. If that's all what a 2811 can, how can I fine-tune the X.25 to limit 
the load on the CPU?

Thanks

Antal

From ip at ioshints.info  Sun Jul 26 12:10:07 2009
From: ip at ioshints.info (Ivan Pepelnjak)
Date: Sun, 26 Jul 2009 18:10:07 +0200
Subject: [c-nsp] VRF-lite to do L3 passthru
In-Reply-To: <5A69C25361FED34F83ABF05F5047524505CD833C@wally.walleyetrading.net>
References: <5A69C25361FED34F83ABF05F5047524505CD833C@wally.walleyetrading.net>
Message-ID: <000601ca0e0b$8c621df0$0a00000a@nil.si>

> is it really that simple? Will VRF-lite work without actually 
> using BGP or MPLS? Are there docs somewhere in the Cisco 
> spiderweb which are clearer on the topic than the ones which 
> are part of the SX doc train?

Yes, it's that simple. You don't need MP-BGP or MPLS for VRF lite to work.
You need MP-BGP only if you want to leak routes between VRFs (as the leaking
is based on route targets and has to go through MP-BGP). Just make sure CEF
is enabled (which is not an issue on a 6500).

(Warning: self-promotion in the next sentence) You'll find very good
coverage of the VRF lite topic in the "MPLS VPN Architectures, Volume II".

Best regards
Ivan
 
http://www.ioshints.info/about
http://blog.ioshints.info/


From jeff-kell at utc.edu  Sun Jul 26 12:33:56 2009
From: jeff-kell at utc.edu (Jeff Kell)
Date: Sun, 26 Jul 2009 12:33:56 -0400
Subject: [c-nsp] VRF-lite to do L3 passthru
In-Reply-To: <5A69C25361FED34F83ABF05F5047524505CD833C@wally.walleyetrading.net>
References: <5A69C25361FED34F83ABF05F5047524505CD833C@wally.walleyetrading.net>
Message-ID: <4A6C8574.3080507@utc.edu>

Jeff Bacon wrote:
> is it really that simple? Will VRF-lite work without actually using BGP
> or MPLS? Are there docs somewhere in the Cisco spiderweb which are
> clearer on the topic than the ones which are part of the SX doc train?

As others have pointed out, yes, it really is that simple.   But there 
are a few "show-stoppers" you may experience...

* You own the transport... so you can trunk the VRF from point A to 
point B,
* The transport doesn't depend on your existing L3 mesh (else you have 
to tunnel),
* You don't need any "leakage" between

Doing "leakage" requires BGP, if only a local instance where you do 
inter-vrf routing.  This is (my opinion) the missing bit of the 
documentation.  The VRF definitions with the "import/export 
route-target" declarations only work if BGP is up and running on the 
same node.

Jeff

From David at hughes.com.au  Sun Jul 26 17:56:39 2009
From: David at hughes.com.au (David Hughes)
Date: Mon, 27 Jul 2009 07:56:39 +1000
Subject: [c-nsp] MST spanning-tree
In-Reply-To: <500ffb690907231034w2671525fo536bdf05936be90c@mail.gmail.com>
References: <500ffb690907231034w2671525fo536bdf05936be90c@mail.gmail.com>
Message-ID: <2550507A-8A1D-4E85-A1EC-7E384D2216C8@Hughes.com.au>


Hi

You'll need to pre-configure your vlan mappings.  This was discussed  
on this list only last week.  When we moved from RPVST to MST we went  
from odds-and-evens mapping to "blocks of 50 vlans" mapping.  It makes  
the config a whole lot smaller :)

All in all it's working well and when there are hundreds of vlans in  
use the traffic distribution over both paths is acceptable.


Thanks

David
...

On 24/07/2009, at 3:34 AM, Steven Fischer wrote:

> It seems that we can create VLANs with no issue, and by default,  
> those VLANs
> are placed in the default instance, instance 0.  This really isn't a
> problem, but when we move the VLAN into its proper instance, a  
> spanning-tree
> recalc appears to occur, the duration of which is long enough to  
> interrupt
> data transfers that may be going on at the time.

From chris.garzon at gmail.com  Mon Jul 27 03:35:01 2009
From: chris.garzon at gmail.com (Dracul)
Date: Mon, 27 Jul 2009 15:35:01 +0800
Subject: [c-nsp] Cisco Catalyst 2960PD-8TT-L
Message-ID: <876789290907270035l2d666d4aoedcb161a98dd0ed0@mail.gmail.com>

Hi All,

I can't seem to find more information of this model in the datasheets. Can
anyone confirm if this switch (Cisco Catalyst 2960PD-8TT-L)
has CLI and SNMP?

regards,
chris

From ariemer at wesenergy.com.au  Mon Jul 27 03:38:33 2009
From: ariemer at wesenergy.com.au (Aaron Riemer)
Date: Mon, 27 Jul 2009 15:38:33 +0800
Subject: [c-nsp] Cisco Catalyst 2960PD-8TT-L
In-Reply-To: <876789290907270035l2d666d4aoedcb161a98dd0ed0@mail.gmail.com>
References: <876789290907270035l2d666d4aoedcb161a98dd0ed0@mail.gmail.com>
Message-ID: <0867622C64B50C4B878AB45C95F43F1106EFD471@MAILWA01.wesenergy.local>

Yes and yes.

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Dracul
Sent: Monday, 27 July 2009 3:35 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Cisco Catalyst 2960PD-8TT-L

Hi All,

I can't seem to find more information of this model in the datasheets.
Can
anyone confirm if this switch (Cisco Catalyst 2960PD-8TT-L)
has CLI and SNMP?

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

LEGAL DISCLAIMER: This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

From zivl at gilat.net  Mon Jul 27 04:14:44 2009
From: zivl at gilat.net (Ziv Leyes)
Date: Mon, 27 Jul 2009 11:14:44 +0300
Subject: [c-nsp] L2TPv3 Tunnel bandwidth and QoS
Message-ID: <EC993E87D960A541A66BF21D62AA42A623016E9CC7@exch2k7.gilat.local>

Hi all,
I'd like to know if there is a feasible way to guarantee QoS for an L2TPv3 tunnel
My customer has a 13Mb uplink to the internet and we've set a tunnel between customer's router and one of our routers, we want to perform some settings on his side that will assure the L2TP tunnel gets always 2Mb
I know that some settings will not only guarantee but also limit it to 2M, and it's ok for us.
My question is what shall I set as a matching setting? The remote tunnel IP? The inside IPs?
TIA,

Ziv


 
 
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************




From pwu828 at gmail.com  Mon Jul 27 04:27:16 2009
From: pwu828 at gmail.com (PW)
Date: Mon, 27 Jul 2009 18:27:16 +1000
Subject: [c-nsp] 6500 ARPing behaviour
Message-ID: <a7c61c610907270127n2de51383h2a16a51301c398aa@mail.gmail.com>

Hi All,

Recently we are seeing some unusual behaviour with one of our 6500 switches,
where it is broadcasting ARPs for every IP address sequentially within the
subnet of one of the SVIs every now and then.

There are two streams of sequential broadcasts that I can see, with one
starts a few minutes later than the other. Not all IPs in the subnet can be
resolved as those IPs are not used.

I have captured the ARP traffic for an actual host within the subnet, and
apart from an ARP response from the host back to the 6500 switch, there is
really nothing else happening after that.

Any one have an idea of why the switch is behaving this way? I initially
thought some external hosts is trying to ping every address on the subnet,
but after I found out apart from the ARP traffic there's nothing else, I'm
not so sure.

Thanks in advance!

cheers,
Patrick

From alasdairm at gmail.com  Mon Jul 27 06:30:54 2009
From: alasdairm at gmail.com (Alasdair McWilliam)
Date: Mon, 27 Jul 2009 11:30:54 +0100
Subject: [c-nsp] C6K VSS outage after forced SSO switchover
Message-ID: <ce2d38bb0907270330t50d382bewa4f98a4030e7d19b@mail.gmail.com>

Hello all,

We've got a Cisco 6509 VSS deployment at a new data centre running
12.2(33)SXI1. The DC itself isn't live yet so we were doing some final
resilience testing, which involved forcing a node fail over to record
what traffic loss if any we were to experience if a node fails.

We had various pings going to pieces of kit during the test, and as
soon as the 'redundancy force-switchover' command was entered, latency
started to increase and pings started to drop out. Within 15-20
seconds, access to the VSS was lost and all our management VPNs sent
offline.

We had an engineer on site who was able to pull some logs, and our
EIGRP sessions to a pair of ASR1k boxes were cycling constantly (time
outs, peer terminations). The CPU of the newly active node was 90%:

CPU utilization for five seconds: 74%/67%; one minute: 87%; five minutes: 90%

I've gone through every process on the MSFC and at best can account
for 5% utilisation from the ARP Input process. Everything else was
less than 0%. I will note that we didn't get the CPU info for the SP
but instinct suggests this was an STP issue because the VSS itself was
OK. The failed node itself came back OK and assumed Standby role, and
interfaces came back online. I could tell this from the ASR1k boxes as
the interfaces went up/up and I could see the VSS in CDP.

The failed node was reporting this via the active MSFC.

%FABRIC-SW2_SPSTBY-6-TIMEOUT_ERR: Fabric in slot 5 detected excessive
flow-control on channel 18 (Module 5, fabric connection 0)

The VSS itself never recovered and in the end we just had to ask our
engineer to physically power down both boxes. The VSS then came back
up as normal.

Has anyone else experienced this, or a similar issue, with a VSS?

I've found bug ID CSCsx27836 on the Cisco bug tracker which in summary
advises that a VSS can get stuck in an L2 loop and high CPU
utilisation after a node fail over, however it does specifically
stipulate that the issue is when the standby node is failed. We failed
the active node. I've raised a query via our account team and will
probably request a TAC case to be opened via our partner.

Any info would be appreciated!

Regards
Alasdair

From Kiran.Oddiraju at cbre.com  Mon Jul 27 08:33:11 2009
From: Kiran.Oddiraju at cbre.com (Oddiraju, Kiran @ London SMC)
Date: Mon, 27 Jul 2009 13:33:11 +0100
Subject: [c-nsp] VPN clients on Cisco ASA
Message-ID: <B5CFB919B5EEF345969F51FAFE6360D50ADE6A@GBLDCXMB10.emea.cbre.net>

Hi List,

 

Cisco ASA 5505

Cisco VPN Client 5.0

ASA External IP: 80.90.100.117 /29

Internal range: 192.168.0.0 /24

 

I am new to Cisco ASA world and have been struggling to configure my
5505 to accept VPN connections from external hosts. I want to allocate
IP address dynamically, allow access to certain subnets and allow
internet access thru their local connection. Can someone please post me
a sample ASA config?

 

Thanks guys

 

Regards,

Kiran


CB Richard Ellis Limited, Registered Office: St Martin's Court, 
10 Paternoster Row, London, EC4M 7HP, registered in England and Wales No. 3536032. 
Regulated by the RICS and an appointed representative of CB Richard Ellis 
Indirect Investment Services Limited which is authorised and regulated by the Financial Services Authority.

This communication is from CB Richard Ellis Limited or one of its 
associated/subsidiary companies. This communication contains information 
which is confidential and may be privileged. If you are not the intended recipient, 
please contact the sender immediately. Any use of its contents is strictly prohibited 
and you must not copy, send or disclose it, or rely on its contents in any way whatsoever. 
Reasonable care has been taken to ensure that this communication 
(and any attachments or hyperlinks contained within it) is free from computer viruses. 
No responsibility is accepted by CB Richard Ellis Limited or its associated/subsidiary 
companies and the recipient should carry out any appropriate virus checks.


From A.L.M.Buxey at lboro.ac.uk  Mon Jul 27 08:55:18 2009
From: A.L.M.Buxey at lboro.ac.uk (Alan Buxey)
Date: Mon, 27 Jul 2009 13:55:18 +0100
Subject: [c-nsp] VPN clients on Cisco ASA
In-Reply-To: <B5CFB919B5EEF345969F51FAFE6360D50ADE6A@GBLDCXMB10.emea.cbre.net>
References: <B5CFB919B5EEF345969F51FAFE6360D50ADE6A@GBLDCXMB10.emea.cbre.net>
Message-ID: <20090727125518.GA6419@lboro.ac.uk>

Hi,

> I am new to Cisco ASA world and have been struggling to configure my
> 5505 to accept VPN connections from external hosts. I want to allocate
> IP address dynamically, allow access to certain subnets and allow
> internet access thru their local connection. Can someone please post me
> a sample ASA config?

the ASA installation guide is fairly open and straightforward -
and has the relevant commands for your requirements.  are you
using CLI only - if not familiar with the platform I'd recommend
using the ADSM and then looking at the resulting configuration

alan

From jfitz at Princeton.EDU  Mon Jul 27 08:56:38 2009
From: jfitz at Princeton.EDU (Jeff Fitzwater)
Date: Mon, 27 Jul 2009 08:56:38 -0400
Subject: [c-nsp] 6500 ARPing behaviour
In-Reply-To: <a7c61c610907270127n2de51383h2a16a51301c398aa@mail.gmail.com>
References: <a7c61c610907270127n2de51383h2a16a51301c398aa@mail.gmail.com>
Message-ID: <73D375DE-3417-405A-9D54-669FA4C5C0E8@princeton.edu>

Make sure you don't have "local proxy-arp " enabled on the SVI.

Jeff Fitzwater
OIT Network Systems
Princeton University
On Jul 27, 2009, at 4:27 AM, PW wrote:

> Hi All,
>
> Recently we are seeing some unusual behaviour with one of our 6500  
> switches,
> where it is broadcasting ARPs for every IP address sequentially  
> within the
> subnet of one of the SVIs every now and then.
>
> There are two streams of sequential broadcasts that I can see, with  
> one
> starts a few minutes later than the other. Not all IPs in the subnet  
> can be
> resolved as those IPs are not used.
>
> I have captured the ARP traffic for an actual host within the  
> subnet, and
> apart from an ARP response from the host back to the 6500 switch,  
> there is
> really nothing else happening after that.
>
> Any one have an idea of why the switch is behaving this way? I  
> initially
> thought some external hosts is trying to ping every address on the  
> subnet,
> but after I found out apart from the ARP traffic there's nothing  
> else, I'm
> not so sure.
>
> Thanks in advance!
>
> cheers,
> Patrick
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


From rwest at zyedge.com  Mon Jul 27 08:57:01 2009
From: rwest at zyedge.com (Ryan West)
Date: Mon, 27 Jul 2009 08:57:01 -0400
Subject: [c-nsp] VPN clients on Cisco ASA
In-Reply-To: <B5CFB919B5EEF345969F51FAFE6360D50ADE6A@GBLDCXMB10.emea.cbre.net>
References: <B5CFB919B5EEF345969F51FAFE6360D50ADE6A@GBLDCXMB10.emea.cbre.net>
Message-ID: <6E21B2BDEF6E714EA0B5BA8D5D0E1401248380B2EB@zy-ex1.zyedge.local>

Hello again Kiran,

I think you should take a quick read through the following link.  You can use the ASDM Remote Access VPN wizard to configure most of the settings and if you're interested in doing it via CLI, that's also an option.

http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a008060f25c.shtml

In particular, the options you have asked are all covered in the doc except for split-tunneling, at least the associated output in CLI.  You'll want to configure that inside the group policy you create from the link above.  Here is an example:

group-policy mygrouppolicyname attributes
 split-tunnel-policy tunnelspecified
 split-tunnel-network-list value <ACL Here>

Let me know how it works out for you.

-ryan

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Oddiraju, Kiran @ London SMC
Sent: Monday, July 27, 2009 8:33 AM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] VPN clients on Cisco ASA

Hi List,

 

Cisco ASA 5505

Cisco VPN Client 5.0

ASA External IP: 80.90.100.117 /29

Internal range: 192.168.0.0 /24

 

I am new to Cisco ASA world and have been struggling to configure my
5505 to accept VPN connections from external hosts. I want to allocate
IP address dynamically, allow access to certain subnets and allow
internet access thru their local connection. Can someone please post me
a sample ASA config?

 

Thanks guys

 

Regards,

Kiran


CB Richard Ellis Limited, Registered Office: St Martin's Court, 
10 Paternoster Row, London, EC4M 7HP, registered in England and Wales No. 3536032. 
Regulated by the RICS and an appointed representative of CB Richard Ellis 
Indirect Investment Services Limited which is authorised and regulated by the Financial Services Authority.

This communication is from CB Richard Ellis Limited or one of its 
associated/subsidiary companies. This communication contains information 
which is confidential and may be privileged. If you are not the intended recipient, 
please contact the sender immediately. Any use of its contents is strictly prohibited 
and you must not copy, send or disclose it, or rely on its contents in any way whatsoever. 
Reasonable care has been taken to ensure that this communication 
(and any attachments or hyperlinks contained within it) is free from computer viruses. 
No responsibility is accepted by CB Richard Ellis Limited or its associated/subsidiary 
companies and the recipient should carry out any appropriate virus checks.

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

From avayner at cisco.com  Mon Jul 27 11:12:10 2009
From: avayner at cisco.com (Arie Vayner (avayner))
Date: Mon, 27 Jul 2009 17:12:10 +0200
Subject: [c-nsp] L2TPv3 Tunnel bandwidth and QoS
In-Reply-To: <EC993E87D960A541A66BF21D62AA42A623016E9CC7@exch2k7.gilat.local>
References: <EC993E87D960A541A66BF21D62AA42A623016E9CC7@exch2k7.gilat.local>
Message-ID: <78C984F8939D424697B15E4B1C1BB3D7010AB06A@xmb-ams-331.emea.cisco.com>

Ziv,

You should be able to match the tunnel by matching it's IP endpoints.
If you could share more info about your QOS requirements, I could assist
with building the policy.

Arie

-----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, July 27, 2009 11:15
To: Cisco-nsp
Subject: [c-nsp] L2TPv3 Tunnel bandwidth and QoS

Hi all,
I'd like to know if there is a feasible way to guarantee QoS for an
L2TPv3 tunnel
My customer has a 13Mb uplink to the internet and we've set a tunnel
between customer's router and one of our routers, we want to perform
some settings on his side that will assure the L2TP tunnel gets always
2Mb
I know that some settings will not only guarantee but also limit it to
2M, and it's ok for us.
My question is what shall I set as a matching setting? The remote tunnel
IP? The inside IPs?
TIA,

Ziv


 
 
************************************************************************
************
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 justin at justinshore.com  Mon Jul 27 12:39:21 2009
From: justin at justinshore.com (Justin Shore)
Date: Mon, 27 Jul 2009 11:39:21 -0500
Subject: [c-nsp] Cisco Catalyst 2960PD-8TT-L
In-Reply-To: <876789290907270035l2d666d4aoedcb161a98dd0ed0@mail.gmail.com>
References: <876789290907270035l2d666d4aoedcb161a98dd0ed0@mail.gmail.com>
Message-ID: <4A6DD839.1000806@justinshore.com>

Dracul wrote:
> Hi All,
> 
> I can't seem to find more information of this model in the datasheets. Can
> anyone confirm if this switch (Cisco Catalyst 2960PD-8TT-L)
> has CLI and SNMP?

The only Cisco-branded switches in the product line that won't have have 
a CLI are the Express switches.  This of course means that the LinkSys 
switches won't have a Cisco CLI (if they have one at all which I doubt). 
  The Cat Express switches are now EoL (EoL the day before the 
announcement was made; nice, eh?).  The replacements are either the 
Linksys Business switches, or for the larger Express switches, a 2960.

Justin




From psirt at cisco.com  Mon Jul 27 12:35:00 2009
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Mon, 27 Jul 2009 16:35:00 -0000
Subject: [c-nsp] Cisco Security Advisory: Multiple Vulnerabilities in Cisco
	Wireless LAN Controllers
Message-ID: <20090727.wlc@psirt.cisco.com>

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


Cisco Security Advisory: Multiple Vulnerabilities in Cisco Wireless LAN Controllers

Advisory ID: cisco-sa-20090727-wlc

http://www.cisco.com/warp/public/707/cisco-sa-20090727-wlc.shtml

Revision 1.0

For Public Release 2009 July 27 1600 UTC (GMT)

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

Summary

Multiple vulnerabilities exist in the Cisco Wireless LAN Controller
(WLC) platforms. This security advisory outlines the details of the
following vulnerabilities:

  * Malformed HTTP or HTTPS authentication response denial of service
    vulnerability
  * SSH connections denial of service vulnerability
  * Crafted HTTP or HTTPS request denial of service vulnerability
  * Crafted HTTP or HTTPS request unauthorized configuration
    modification vulnerability

Cisco has released free software updates that address these
vulnerabilities.

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

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

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

Cisco 1500 Series, 2000 Series, 2100 Series, 4400 Series, 4100
Series, 4200 Series, Wireless Services Modules (WiSM), WLC Modules
for Integrated Services Routers, and Cisco Catalyst 3750G Integrated
Wireless LAN Controllers are affected by one or more of the following
vulnerabilities:

  * The malformed HTTP or HTTPS authentication response denial of
    service vulnerability affects software versions 4.2 and later.
  * The SSH connections denial of service vulnerability affects
    software versions 4.1 and later.
  * The crafted HTTP or HTTPS request denial of service vulnerability
    affects software versions 4.1 and later.
  * The crafted HTTP or HTTPS request unauthorized configuration
    modification vulnerability affects software versions 4.1 and
    later.

Determination of Software Versions
+---------------------------------

To determine the WLC version that is running in a given environment,
use one of the following methods:

  * In the web interface, choose the Monitor tab, click Summary in
    the left pane, and note the Software Version field.
   
    Note:  Customers who use a WLC Module in an Integrated Services
    Router (ISR) will need to issue the service-module
    wlan-controller 1/0 session command prior to performing the next
    step on the command line. Customers who use a Cisco Catalyst
    3750G Switch with an integrated WLC Module will need to issue the
    session <Stack-Member-Number> processor 1 session command prior
    to performing the next step on the command line.
   
  * From the command-line interface, type show sysinfo and note the 
    Product Version field, as shown in the following example:

    (Cisco Controller) >show sysinfo 
    
    Manufacturer's Name.. Cisco Systems Inc.
    Product Name......... Cisco Controller
    Product Version...... 5.1.151.0
    RTOS Version......... Linux-2.6.10_mvl401
    Bootloader Version... 4.0.207.0
    Build Type........... DATA + WPS
    <output suppressed>
    

Use the show wism module <module number> controller 1 status command
on a Cisco Catalyst 6500 Series/7600 Series Switch if you are using a
WiSM. Note the software version as demonstrated in the following
example, which shows version 5.1.151.0.

    Router#show wism module 3 controller 1 status
    
    WiSM Controller 1 in Slot 3
    Operational Status of the Controller    
       : Oper-Up
    Service VLAN                            
       : 192   
    Service Port                            
       : 10    
    Service Port Mac Address                
       : 0011.92ff.8742
    Service IP Address                      
       : 192.168.10.1
    Management IP Address                   
       : 192.168.1.123
    Software Version                        
       : 5.1.151.0
    Port Channel Number                     
       : 288   
    Allowed vlan list                       
       : 30,40 
    Native VLAN ID                          
       : 40    
    WCP Keep Alive Missed                   
       : 0
    

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

The Cisco Wireless Controller 5500 Series is not affected by these
vulnerabilities.

Details
=======

Cisco Wireless LAN Controllers (WLCs) are responsible for system-wide
wireless LAN functions, such as security policies, intrusion
prevention, RF management, quality of service (QoS), and mobility.

These devices communicate with controller-based access points over
any Layer 2 (Ethernet) or Layer 3 (IP) infrastructure using the
Lightweight Access Point Protocol (LWAPP).

This security advisory describes multiple distinct vulnerabilities in
the WLC family of devices.

  * Malformed HTTP or HTTPS authentication response denial of service
    vulnerability
    An attacker with access to the administrative web interface via
    HTTP or HTTPS may cause the device to reload by providing a
    malformed response to an authentication request.
   
    Note:  The vulnerability can be exploited only via the
    administrative web-based interface; Web Authentication features
    are not affected.
   
   
    This vulnerability is documented in Cisco Bug ID CSCsx03715 and
    has been assigned Common Vulnerabilities and Exposures (CVE) ID
    CVE-2009-1164.

  * SSH connections denial of service vulnerability
    Affected devices may be susceptible to a memory leak when they
    handle SSH management connections. An attacker could use this
    behavior to cause an affected device to crash and reload.
   
    Note:  A three-way handshake is not required to exploit this
    vulnerability.
   
    This vulnerability is documented in Cisco Bug ID CSCsw40789 and
    has been assigned CVE ID CVE-2009-1165.

  * Crafted HTTP or HTTPS request denial of service vulnerability
    An attacker with the ability to send a malicious HTTP request to
    an affected WLC could cause the device to crash and reload.
   
    Note:  The vulnerability can be exploited only via the
    administrative web-based interface; Web Authentication features
    are not affected.
   
    This vulnerability is documented in Cisco Bug ID CSCsy27708 and
    has been assigned CVE ID CVE-2009-1166.

  * Crafted HTTP or HTTPS request unauthorized configuration
    modification vulnerability
    An unauthorized configuration modification vulnerability exists
    in all software versions prior to the first fixed release. A
    remote, unauthenticated attacker who can submit HTTP or HTTPS
    requests to the WLC directly could gain full control of the
    affected device.
   
    Note:  The vulnerability can be exploited only by submitting such
    a request to an IP address that is bound to an administrative
    interface or VLAN.
   
   
    The vulnerability is documented by Cisco Bug ID CSCsy44672 and has
    been assigned CVE ID CVE-2009-1167.

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

CSCsx03715 - Malformed HTTP or HTTPS authentication response denial of service 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

CSCsw40789 - SSH connections denial of service 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

CSCsy27708 - Crafted HTTP or HTTPS request denial of service 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

CSCsy44672 - Crafted HTTP or HTTPS request unauthorized configuration modification vulnerability
+-----------------------------------------------------

CVSS Base Score - 10

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

CVSS Temporal Score - 6.4

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

Impact
=====

Successful exploitation of the denial of service (DoS)
vulnerabilities may cause the affected device to reload. Repeated
exploitation could result in a sustained DoS condition.

An unauthenticated, remote attacker may be able to use the
unauthorized configuration modification vulnerability to gain full
control over the Wireless LAN Controller if the attacker is able to
submit a crafted request directly to an administrative interface of
the affected device.

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

When considering software upgrades, also consult
http://www.cisco.comw/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.

+------------------------------------------------------+
| Vulnerability/ | Affected | First      | Recommended |
| Bug ID         | Release  | Fixed      | Release     |
|                |          | Version    |             |
|----------------+----------+------------+-------------|
|                | 4.1      | Not        | Not         |
|                |          | Vulnerable | Vulnerable  |
|                |----------+------------+-------------|
|                | 4.1M     | Not        | Not         |
|                |          | Vulnerable | Vulnerable  |
|                |----------+------------+-------------|
|                | 4.2      | 4.2.205.0  | 4.2.207.0   |
|                |----------+------------+-------------|
| Malformed HTTP | 4.2M     | Not        | Not         |
| or HTTPS       |          | Vulnerable | Vulnerable  |
|authentication  |----------+------------+-------------|
| response       |          | Migrate to | 5.2.193.0   |
| denial of      | 5.0      | 5.2 or 6.0 | or          |
| service        |          |            | 6.0.182.0   |
|vulnerability   |----------+------------+-------------|
| (CSCsx03715)   |          | Migrate to | 5.2.193.0   |
|                | 5.1      | 5.2 or 6.0 | or          |
|                |          |            | 6.0.182.0   |
|                |----------+------------+-------------|
|                |          |            | 5.2.193.0   |
|                | 5.2      | 5.2.178.0  | or          |
|                |          |            | 6.0.182.0   |
|                |----------+------------+-------------|
|                | 6.0      | Not        | Not         |
|                |          | Vulnerable | Vulnerable  |
|----------------+----------+------------+-------------|
|                | 4.1      | Migrate to | 4.2.205.0   |
|                |          | 4.2        |             |
|                |----------+------------+-------------|
|                |          |            | 5.2.193.0,  |
|                |          | Migrate to | 6.0.182.0   |
|                | 4.1M     | 5.2, 6.0,  | or          |
|                |          | or 4.2M    | 4.2.176.51  |
|                |          |            | Mesh        |
|                |----------+------------+-------------|
|                | 4.2      | 4.2.205.0  | 4.2.207.0   |
|                |----------+------------+-------------|
| SSH            | 4.2M     | Not        | Not         |
| connections    |          | Vulnerable | Vulnerable  |
|denial of       |----------+------------+-------------|
| service        |          | Migrate to | 5.2.193.0   |
| vulnerability  | 5.0      | 5.2 or 6.0 | or          |
| (CSCsw40789)   |          |            | 6.0.182.0   |
|                |----------+------------+-------------|
|                |          |            | 5.2.193.0   |
|                | 5.1      | 5.1.163.0  | or          |
|                |          |            | 6.0.182.0   |
|                |----------+------------+-------------|
|                |          |            | 5.2.193.0   |
|                | 5.2      | 5.2.178.0  | or          |
|                |          |            | 6.0.182.0   |
|                |----------+------------+-------------|
|                | 6.0      | Not        | Not         |
|                |          | Vulnerable | Vulnerable  |
|----------------+----------+------------+-------------|
|                | 4.1      | Migrate to | 4.2.205.0   |
|                |          | 4.2        |             |
|                |----------+------------+-------------|
|                |          |            | 5.2.193.0,  |
|                |          | Migrate to | 6.0.182.0   |
|                | 4.1 M    | 5.2, 6.0,  | or          |
|                |          | or 4.2M    | 4.2.176.51  |
|                |          |            | Mesh        |
|                |----------+------------+-------------|
|                | 4.2      | 4.2.205.0  | 4.2.207.0   |
|                |----------+------------+-------------|
| Crafted HTTP   | 4.2M     | Not        | Not         |
| request may    |          | Vulnerable | Vulnerable  |
|cause the WLC   |----------+------------+-------------|
| to crash       |          | Migrate to | 5.2.193.0   |
| (CSCsy27708)   | 5.0      | 5.2 or 6.0 | or          |
|                |          |            | 6.0.182.0   |
|                |----------+------------+-------------|
|                |          | Migrate to | 5.2.193.0   |
|                | 5.1      | 5.2 or 6.0 | or          |
|                |          |            | 6.0.182.0   |
|                |----------+------------+-------------|
|                |          |            | 5.2.193.0   |
|                | 5.2      | 5.2.191.0  | or          |
|                |          |            | 6.0.182.0   |
|                |----------+------------+-------------|
|                | 6.0      | Not        | Not         |
|                |          | Vulnerable | Vulnerable  |
|----------------+----------+------------+-------------|
|                | 4.1      | Migrate to | 4.2.205.0   |
|                |          | 4.2        |             |
|                |----------+------------+-------------|
|                |          |            | 5.2.193.0,  |
|                |          | Migrate to | 6.0.182.0   |
|                | 4.1M     | 5.2, 6.0,  | or          |
|                |          | or 4.2M    | 4.2.176.51  |
|                |          |            | Mesh        |
|                |----------+------------+-------------|
| Crafted HTTP   | 4.2      | 4.2.205.0  | 4.2.207.0   |
|or HTTPS        |----------+------------+-------------|
| request        | 4.2M     | Not        | Not         |
| unauthorized   |          | Vulnerable | Vulnerable  |
|configuration   |----------+------------+-------------|
| modification   | 5.0      | Migrate to | 5.2.193.0,  |
| vulnerability  |          | 5.2 or 6.0 | 6.0.182.0   |
|(CSCsy44672)    |----------+------------+-------------|
|                |          | Migrate to | 5.2.193.0   |
|                | 5.1      | 5.2 or 6.0 | or          |
|                |          |            | 6.0.182.0   |
|                |----------+------------+-------------|
|                |          |            | 5.2.193.0   |
|                | 5.2      | 5.2.191.0  | or          |
|                |          |            | 6.0.182.0   |
|                |----------+------------+-------------|
|                | 6.0      | Not        | Not         |
|                |          | Vulnerable | Vulnerable  |
+------------------------------------------------------+

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

The SSH connections denial of service vulnerability identified by
Cisco Bug ID CSCsw40789 may be remediated by disabling SSH on the
affected device. This workaround requires subsequent management of
the device to be performed using the HTTP/HTTPS web management
interface or the serial console of the device.

Additional mitigations that can be deployed on Cisco devices in the
network are available in the Cisco Applied Mitigation Bulletin
companion document for this advisory, which is available at the
following link:
http://www.cisco.com/warp/public/707/cisco-amb-20090727-wlc.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 vulnerabilities described in this advisory at the time of
release.

The DoS vulnerability documented by CSCsw40789 was discovered during
the resolution of customer support cases.

The unauthorized configuration modification vulnerability documented
by CSCsy44672 was found during internal testing.

The DoS vulnerability documented by CSCsx03715 was discovered by
Christoph Bott of SySS GmbH.

The DoS vulnerability documented by CSCsy27708 was discovered by IBM
Research.

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-20090727-wlc.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-July-27 | 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

? 2008 - 2009 Cisco Systems, Inc. All rights reserved.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFKbdU786n/Gc8U/uARAkG6AKCKI8yrbakylICPezA8Up2E1t372QCePJmj
RTTknUlr0VuKxVZLT0f8+gQ=
=x8Ly
-----END PGP SIGNATURE-----

From nick at inex.ie  Mon Jul 27 12:55:49 2009
From: nick at inex.ie (Nick Hilliard)
Date: Mon, 27 Jul 2009 17:55:49 +0100
Subject: [c-nsp] Cisco Catalyst 2960PD-8TT-L
In-Reply-To: <4A6DD839.1000806@justinshore.com>
References: <876789290907270035l2d666d4aoedcb161a98dd0ed0@mail.gmail.com>
	<4A6DD839.1000806@justinshore.com>
Message-ID: <4A6DDC15.30800@inex.ie>

On 27/07/2009 17:39, Justin Shore wrote:
> The only Cisco-branded switches in the product line that won't have
> have a CLI are the Express switches.  This of course means that the
> LinkSys switches won't have a Cisco CLI (if they have one at all which
> I doubt).

http://lcli.wikidot.com/

Nick

From rodunn at cisco.com  Mon Jul 27 13:05:42 2009
From: rodunn at cisco.com (Rodney Dunn)
Date: Mon, 27 Jul 2009 13:05:42 -0400
Subject: [c-nsp] 6500 ARPing behaviour
In-Reply-To: <a7c61c610907270127n2de51383h2a16a51301c398aa@mail.gmail.com>
References: <a7c61c610907270127n2de51383h2a16a51301c398aa@mail.gmail.com>
Message-ID: <4A6DDE66.3040405@cisco.com>



PW wrote:
> Hi All,
> 
> Recently we are seeing some unusual behaviour with one of our 6500 switches,
> where it is broadcasting ARPs for every IP address sequentially within the
> subnet of one of the SVIs every now and then.
> 
> There are two streams of sequential broadcasts that I can see, with one
> starts a few minutes later than the other. Not all IPs in the subnet can be
> resolved as those IPs are not used.

Do you see arps go out for machines that have a valid arp already.
If so, those are unicast refreshes probably.

If it's the ones that are not existing them most likely it's a traffic 
sweep and we punt one packet to trigger the arp to go out.


> 
> I have captured the ARP traffic for an actual host within the subnet, and
> apart from an ARP response from the host back to the 6500 switch, there is
> really nothing else happening after that.

Probably not if it's a one packet per host sweep. You'd never see it on 
the lan if the traffic came in another port on the device.


> 
> Any one have an idea of why the switch is behaving this way? I initially
> thought some external hosts is trying to ping every address on the subnet,
> but after I found out apart from the ARP traffic there's nothing else, I'm
> not so sure.
> 

Try getting a trace of the port 15/1 I thin it is going to the RP when 
the event happens to see if you can catch the punt traffic.

Or look at 'sh ip cache flow' with "ip route-cache flow" enabled on all 
interfaces in the box.

Rodney


> Thanks in advance!
> 
> cheers,
> Patrick
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

From UCS_RLW at shsu.edu  Mon Jul 27 13:10:42 2009
From: UCS_RLW at shsu.edu (Whitlock, Ronnie)
Date: Mon, 27 Jul 2009 12:10:42 -0500
Subject: [c-nsp] 6500 ARPing behaviour
Message-ID: <8FAC1E47484E43469AA28DBF35C955E4A497329E43@EXMBX.SHSU.EDU>

Patrick,

Do you happen to have a route pointing to this SVI interface?  Like
x.x.x.x x.x.x.x vlan 10.  If so this will cause the behavior that you are seeing.


Ronnie


________________________________________
Date: Mon, 27 Jul 2009 18:27:16 +1000
From: PW <pwu828 at gmail.com>
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] 6500 ARPing behaviour
Message-ID:
        <a7c61c610907270127n2de51383h2a16a51301c398aa at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Hi All,

Recently we are seeing some unusual behaviour with one of our 6500 switches,
where it is broadcasting ARPs for every IP address sequentially within the
subnet of one of the SVIs every now and then.

There are two streams of sequential broadcasts that I can see, with one
starts a few minutes later than the other. Not all IPs in the subnet can be
resolved as those IPs are not used.

I have captured the ARP traffic for an actual host within the subnet, and
apart from an ARP response from the host back to the 6500 switch, there is
really nothing else happening after that.

Any one have an idea of why the switch is behaving this way? I initially
thought some external hosts is trying to ping every address on the subnet,
but after I found out apart from the ARP traffic there's nothing else, I'm
not so sure.

Thanks in advance!

cheers,
Patrick

From bacon at walleyesoftware.com  Mon Jul 27 14:14:39 2009
From: bacon at walleyesoftware.com (Jeff Bacon)
Date: Mon, 27 Jul 2009 13:14:39 -0500
Subject: [c-nsp] mapping CPU IDs to reality
Message-ID: <5A69C25361FED34F83ABF05F5047524505CD8357@wally.walleyetrading.net>

Hi folks - 

I don't have fancy Ciscoware, I'm just using RTG to poll my 6500s. 

Snmpwalk reports 4 different CPUs, indexes 1001, 2017, 2001, 3001. 

Box has: 
Slot 1: Sup720-3B
Slot 2: sup720-3B
Slot 3: 6816A, DFC3B

I am *guessing* that index x001 is the switch processor, and x017 is the
route processor. 
Strangely, the first digit doesn't line up with the slot/module # - CPU
1001 is clearly the DFC (continuous 80% CPU, all in "lcp scheduler" -
seems weird but that's life), CPU 2001's usage profile best matches the
primary SP, and 3001 matches the secondary. 

My Google-fu is not up to snuff on this. 

Is there _any_ logic to CPU identification on this platform?


Thanks,
-bacon 


From frnkblk at iname.com  Mon Jul 27 14:16:25 2009
From: frnkblk at iname.com (Frank Bulk - iName.com)
Date: Mon, 27 Jul 2009 13:16:25 -0500
Subject: [c-nsp] Monitoring BGP with NAGIOS
In-Reply-To: <B5F945E48C137C49A98BC86DD35939C012DDE2A36B@nbg01-exch-01.entlstaff.domain.lumison.net>
References: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAACgBVX1McEWTr789Gz1sQh4AQAAAAA=@iname.com>
	<B5F945E48C137C49A98BC86DD35939C012DDE2A36B@nbg01-exch-01.entlstaff.domain.lumison.net>
Message-ID: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAABLgVBe+sy3Tb2VAkyJ6IqeAQAAAAA=@iname.com>

Ian:

Thanks for your input.  I agree, snmptraps are the next obvious step.  The
URL you provided was the one I refered to when looking through the results
of my walk through Cisco's BGP MIB. =)

Since my upstream monitors our edge routers, including BGP, the monitoring
is more to document that something happened.  I won't have it page me at 3
in the morning, but when my upstream tells me that they're doing
maintenance, I'll know when I wake up if it did impact BGP.  It's also
another input into my event correlation system (me) -- if a customer tells
me that they've lost internet access, or if I've asked for another netblock
to be advertised, I'll know immediately to look at a routing issue.

Frank

-----Original Message-----
From: Ian MacKinnon [mailto:Ian.Mackinnon at lumison.net] 
Sent: Thursday, July 23, 2009 9:15 AM
To: frnkblk at iname.com; cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] Monitoring BGP with NAGIOS

Hi Frank,

You say maybe traps is the next step.....
You can get an snmp trap when a peer changes state, you can then get nagios
to respond to the traps using traphandler

Some info at
http://www.cisco.com/en/US/docs/ios/12_3t/12_3t7/feature/guide/gt_bmibe.html

We are using nagios and traphandlers to respond to things like link up/down

I guess if you poll often enough you can be sure to catch a peer in a bad
state, but do you actually care at 3 in the morning that a peer was down for
30s and is now back?

Ian

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Frank Bulk
Sent: 23 July 2009 15:04
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Monitoring BGP with NAGIOS

We're a small shop and our group's upstream is single-homed in terms of
providers but dual-homed in terms of physical connectivity, with a private
ASN.



Occasionally there's BGP events and I would like to be remotely notified --
NAGIOS can do that and I prefer SNMP polling.  We're not doing an SNMP TRAP
or syslog processing at this time - that would be an obvious next step for
us.



Currently the NAGIOS plugin I'm developing polls the bgpPeerState,
bgpPeerIn/OutUpdates and bgpPeerIn/OutTotalMessages and alerts me if there's
a change.  Since a BGP session could be re-established in a short amount of
time, I would like to trigger an alert if the number of In/Out Updates or
Messages exceeds the regular value (I'm presuming that when the BGP session
re-establishes, these counters climb more quickly than during times of
stability).  But I'm not sure if Updates/Messages are normally sent every 30
or 60 seconds (I've seen 60 on a wiki page, but "sh ip bgp neighbors" says
that the "keepalive interval is 30 seconds" and "Default minimum time
between advertisement runs is 30 seconds".  I'm guessing this knob can be
adjusted in IOS, so ideally I would like the NAGIOS plugin to accommodate
for that, such that if the counters move '5' in 5 minutes that's OK with a
60 second period, but if it's a 30 second period, then those counts should
move 10 times.  But keep-alive/scan interval doesn't seem to be listed in
the MIB.



Also, there's a lot more information available at the Cisco CLI when
executing "sh ip bgp summary", specifically:

.         BGP table version

.         # of network entries

.         # of path entries

.         # of prefixes

.         # of paths

.         Up/Down times

Is any of that available via SNMP, because my walking isn't showing that at
all?



If you think I'm going about this the wrong way, please feel free to tell
me. =)



Regards,



Frank

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

Checked by AVG - www.avg.com
Version: 8.5.392 / Virus Database: 270.13.20/2249 - Release Date: 07/21/09
18:02:00

--

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


From jfitz at Princeton.EDU  Mon Jul 27 14:27:51 2009
From: jfitz at Princeton.EDU (Jeff Fitzwater)
Date: Mon, 27 Jul 2009 14:27:51 -0400
Subject: [c-nsp] mapping CPU IDs to reality
In-Reply-To: <5A69C25361FED34F83ABF05F5047524505CD8357@wally.walleyetrading.net>
References: <5A69C25361FED34F83ABF05F5047524505CD8357@wally.walleyetrading.net>
Message-ID: <227E84F1-850A-477D-9327-09ED2329BAF1@princeton.edu>

Use the Entity MIB to map physical to index.



Jeff Fitzwater
OIT Network Systems
Princeton University
On Jul 27, 2009, at 2:14 PM, Jeff Bacon wrote:

> Hi folks -
>
> I don't have fancy Ciscoware, I'm just using RTG to poll my 6500s.
>
> Snmpwalk reports 4 different CPUs, indexes 1001, 2017, 2001, 3001.
>
> Box has:
> Slot 1: Sup720-3B
> Slot 2: sup720-3B
> Slot 3: 6816A, DFC3B
>
> I am *guessing* that index x001 is the switch processor, and x017 is  
> the
> route processor.
> Strangely, the first digit doesn't line up with the slot/module # -  
> CPU
> 1001 is clearly the DFC (continuous 80% CPU, all in "lcp scheduler" -
> seems weird but that's life), CPU 2001's usage profile best matches  
> the
> primary SP, and 3001 matches the secondary.
>
> My Google-fu is not up to snuff on this.
>
> Is there _any_ logic to CPU identification on this platform?
>
>
> Thanks,
> -bacon
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


From nicotine at warningg.com  Mon Jul 27 14:30:29 2009
From: nicotine at warningg.com (Brandon Ewing)
Date: Mon, 27 Jul 2009 13:30:29 -0500
Subject: [c-nsp] mapping CPU IDs to reality
In-Reply-To: <5A69C25361FED34F83ABF05F5047524505CD8357@wally.walleyetrading.net>
References: <5A69C25361FED34F83ABF05F5047524505CD8357@wally.walleyetrading.net>
Message-ID: <20090727183029.GA12276@radiological.warningg.com>

On Mon, Jul 27, 2009 at 01:14:39PM -0500, Jeff Bacon wrote:
> 
> I am *guessing* that index x001 is the switch processor, and x017 is the
> route processor. 
> Strangely, the first digit doesn't line up with the slot/module # - CPU
> 1001 is clearly the DFC (continuous 80% CPU, all in "lcp scheduler" -
> seems weird but that's life), CPU 2001's usage profile best matches the
> primary SP, and 3001 matches the secondary. 
> 
> My Google-fu is not up to snuff on this. 
> 
> Is there _any_ logic to CPU identification on this platform?
> 

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

ENTITY-MIB::entPhysicalTable will map a processor to an entity ID
CISCO-PROCESS-MIB::cpmCPUTotalPhysicalIndex maps the entity ID to a
processor index.
CISCO-PROCESS-MIB::cpmCPUTotalTable lists processor utilization by procesor
index.

-- 
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/20090727/5cdb9a7f/attachment.bin>

From rwest at zyedge.com  Mon Jul 27 14:33:57 2009
From: rwest at zyedge.com (Ryan West)
Date: Mon, 27 Jul 2009 14:33:57 -0400
Subject: [c-nsp] mapping CPU IDs to reality
In-Reply-To: <5A69C25361FED34F83ABF05F5047524505CD8357@wally.walleyetrading.net>
References: <5A69C25361FED34F83ABF05F5047524505CD8357@wally.walleyetrading.net>
Message-ID: <6E21B2BDEF6E714EA0B5BA8D5D0E1401248380B3A1@zy-ex1.zyedge.local>

Jeff,

You might try walking these MIBs:

$oid = array (
        array ("cpuIndex", ".1.3.6.1.4.1.9.9.109.1.1.1.1.2"),
        array ("cpuDescr", ".1.3.6.1.2.1.47.1.1.1.1.7"),
        array ("cpu_1min", ".1.3.6.1.4.1.9.9.109.1.1.1.1.7"),
        array ("cpu_5min", ".1.3.6.1.4.1.9.9.109.1.1.1.1.8"));

This is from a cisco_cpu script for Cacti.

-ryan

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Jeff Bacon
Sent: Monday, July 27, 2009 2:15 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] mapping CPU IDs to reality

Hi folks - 

I don't have fancy Ciscoware, I'm just using RTG to poll my 6500s. 

Snmpwalk reports 4 different CPUs, indexes 1001, 2017, 2001, 3001. 

Box has: 
Slot 1: Sup720-3B
Slot 2: sup720-3B
Slot 3: 6816A, DFC3B

I am *guessing* that index x001 is the switch processor, and x017 is the
route processor. 
Strangely, the first digit doesn't line up with the slot/module # - CPU
1001 is clearly the DFC (continuous 80% CPU, all in "lcp scheduler" -
seems weird but that's life), CPU 2001's usage profile best matches the
primary SP, and 3001 matches the secondary. 

My Google-fu is not up to snuff on this. 

Is there _any_ logic to CPU identification on this platform?


Thanks,
-bacon 

_______________________________________________
cisco-nsp mailing list  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 Jul 27 14:34:10 2009
From: frnkblk at iname.com (Frank Bulk - iName.com)
Date: Mon, 27 Jul 2009 13:34:10 -0500
Subject: [c-nsp] Monitoring BGP with NAGIOS
In-Reply-To: <20090723161010.GA553@radiological.warningg.com>
References: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAACgBVX1McEWTr789Gz1sQh4AQAAAAA=@iname.com>
	<20090723161010.GA553@radiological.warningg.com>
Message-ID: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAABMV4CD/werT7NLCDeYdSKnAQAAAAA=@iname.com>

Thanks.  I had compiled RFC1213-MIB into my MIB browser, but not BGP4-MIB.
Once I did, it was all there....

The stuff at NAGIOS exchange left me wanting, which is why I'm fleshing out
my own.

Frank

-----Original Message-----
From: nicotine at radiological.warningg.com
[mailto:nicotine at radiological.warningg.com] On Behalf Of Brandon Ewing
Sent: Thursday, July 23, 2009 11:10 AM
To: Frank Bulk
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Monitoring BGP with NAGIOS

<snip>

BGP4-MIB::bgpPeerHoldTime ( .1.3.6.1.2.1.15.3.1.18 )
BGP4-MIB::bgpPeerKeepAlive ( .1.3.6.1.2.1.15.3.1.19 )

Hold time is 3x keepalive by default
Updates are sent as they are processed
There are also OIDs for the locally configured hold and keepalive timers, as
you will use your peer's configured timers if they are lower.


> 
> Also, there's a lot more information available at the Cisco CLI when
> executing "sh ip bgp summary", specifically:
> 
> .         Up/Down times

BGP4-MIB::bgpPeerInUpdateElapsedTime ( .1.3.6.1.2.1.15.3.1.24 )
BGP4-MIB::bgpPeerLastError ( .1.3.6.1.2.1.15.3.1.14 )

>  
> 
> If you think I'm going about this the wrong way, please feel free to tell
> me. =)
> 

Have you looked at the following plugins in the Nagios Exchange?
http://exchange.nagios.org/directory/Plugins/Uncategorized/Software/SNMP/che
ck_bgp_neighbors/details
http://exchange.nagios.org/directory/Plugins/Uncategorized/Software/SNMP/che
ck_bgp/details

Cisco's MIB Browser also has a wealth of information regarding BGP SNMP
http://tools.cisco.com/Support/SNMP/do/BrowseMIB.do?local=en&step=2&mibName=
BGP4-MIB

-- 
Brandon Ewing                                        (nicotine at warningg.com)


From justin at justinshore.com  Mon Jul 27 14:57:29 2009
From: justin at justinshore.com (Justin Shore)
Date: Mon, 27 Jul 2009 13:57:29 -0500
Subject: [c-nsp] Cisco Catalyst 2960PD-8TT-L
In-Reply-To: <4A6DDC15.30800@inex.ie>
References: <876789290907270035l2d666d4aoedcb161a98dd0ed0@mail.gmail.com>
	<4A6DD839.1000806@justinshore.com> <4A6DDC15.30800@inex.ie>
Message-ID: <4A6DF899.5060906@justinshore.com>

Nick Hilliard wrote:
> On 27/07/2009 17:39, Justin Shore wrote:
>> The only Cisco-branded switches in the product line that won't have
>> have a CLI are the Express switches.  This of course means that the
>> LinkSys switches won't have a Cisco CLI (if they have one at all which
>> I doubt).
> 
> http://lcli.wikidot.com/

Interesting.  So they don't have a Cisco CLI but they have an otherwise 
limited CLI if you know the tricks to get into it.  I don't think that 
will be helpful in RANCID though.  I don't think I can make it jump 
through all the hoops necessary to get logged in or pass meta control 
characters.  Interesting nonetheless though.

Thanks
  Justin


From nicotine at warningg.com  Mon Jul 27 15:07:06 2009
From: nicotine at warningg.com (Brandon Ewing)
Date: Mon, 27 Jul 2009 14:07:06 -0500
Subject: [c-nsp] Cisco Catalyst 2960PD-8TT-L
In-Reply-To: <4A6DF899.5060906@justinshore.com>
References: <876789290907270035l2d666d4aoedcb161a98dd0ed0@mail.gmail.com>
	<4A6DD839.1000806@justinshore.com> <4A6DDC15.30800@inex.ie>
	<4A6DF899.5060906@justinshore.com>
Message-ID: <20090727190706.GB12276@radiological.warningg.com>

On Mon, Jul 27, 2009 at 01:57:29PM -0500, Justin Shore wrote:
> Nick Hilliard wrote:
>> On 27/07/2009 17:39, Justin Shore wrote:
>>> The only Cisco-branded switches in the product line that won't have
>>> have a CLI are the Express switches.  This of course means that the
>>> LinkSys switches won't have a Cisco CLI (if they have one at all which
>>> I doubt).
>> http://lcli.wikidot.com/
>
> Interesting.  So they don't have a Cisco CLI but they have an otherwise 
> limited CLI if you know the tricks to get into it.  I don't think that will 
> be helpful in RANCID though.  I don't think I can make it jump through all 
> the hoops necessary to get logged in or pass meta control characters.  
> Interesting nonetheless though.
>
> Thanks
>  Justin

Given the partial commands they gave, it looks VERY similar to the CLI used
in Dell Powerconnect 5xxx line.  I believe there is a dlogin/drancid that
works to archive configurations of those devices.

If you can't find them, you can also just use clogin with a custom string to
set term length (terminal datadump\r), and match the default login banner
(User Name instead of Username).  Then you can copy the default rancid to
drancid, and change the @commandtable to only do show version, show vlan,
and show running-config.

-- 
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/20090727/28055766/attachment.bin>

From nick at inex.ie  Mon Jul 27 16:16:10 2009
From: nick at inex.ie (Nick Hilliard)
Date: Mon, 27 Jul 2009 21:16:10 +0100
Subject: [c-nsp] Cisco Catalyst 2960PD-8TT-L
In-Reply-To: <4A6DF899.5060906@justinshore.com>
References: <876789290907270035l2d666d4aoedcb161a98dd0ed0@mail.gmail.com>
	<4A6DD839.1000806@justinshore.com> <4A6DDC15.30800@inex.ie>
	<4A6DF899.5060906@justinshore.com>
Message-ID: <4A6E0B0A.5060402@inex.ie>

On 27/07/2009 19:57, Justin Shore wrote:
> Interesting. So they don't have a Cisco CLI but they have an otherwise
> limited CLI if you know the tricks to get into it. I don't think that
> will be helpful in RANCID though. I don't think I can make it jump
> through all the hoops necessary to get logged in or pass meta control
> characters. Interesting nonetheless though.

Well, they do have a limited Cisco CLI, which is enough for them to store 
the complete switch configuration in a cisco-style configuration file.  You 
can see this file if you boot into the bootprom (press either ESC or CTRL-U 
on bootup on the serial console).  In theory you can also tftp this file up 
to a tftp server, but from an automation point of view, the problem in 
practice turns out to be getting past the stupid curses based interface and 
dealing with the various models.

The SRW224, for example, doesn't support lcli at all, although at least it 
supports browsers other than IE6/IE7.  I don't think the SLM series 
supports lcli either - which is a pain, given that they are newer boxes and 
support cisco style configuration files (the SRW224 config files are binary).

On a "delenda est carthago" note, whoever in Linksys made the dysfunctional 
decision only to support IE6/IE7 seriously needs to be kicked up the ass.

Nick

From ross at kallisti.us  Mon Jul 27 16:25:37 2009
From: ross at kallisti.us (Ross Vandegrift)
Date: Mon, 27 Jul 2009 16:25:37 -0400
Subject: [c-nsp] CISCO-IETF-IP-FORWARD-MIB on SXF
Message-ID: <20090727202537.GA11042@kallisti.us>

Hey all,

Everytime I need to programmatically lookup prefixes in the routing
table on our 6500s, I try to find a better MIB than I use today.

Today, I discovered CISCO-IETF-IP-FORWARD-MIB - a pre-standard
IP-FORWARD-MIB that lives under ciscoExperimental.  It's listed in
Cisco IOS MIB Locator as supported by my image.

Unfortunately, this seems to count as an implementation:
$ snmpbulkwalk -v 2c -c public lab-6506 CISCO-IETF-IP-FORWARD-MIB::ciscoIetfIpForward
CISCO-IETF-IP-FORWARD-MIB::cInetCidrRouteNumber.0 = Gauge32: 0

Any way to get this MIB populated?

-- 
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 p.mayers at imperial.ac.uk  Mon Jul 27 18:45:24 2009
From: p.mayers at imperial.ac.uk (Phil Mayers)
Date: Mon, 27 Jul 2009 23:45:24 +0100
Subject: [c-nsp] CISCO-IETF-IP-FORWARD-MIB on SXF
In-Reply-To: <20090727202537.GA11042@kallisti.us>
References: <20090727202537.GA11042@kallisti.us>
Message-ID: <20090727224524.GB10623@wildfire.net.ic.ac.uk>

On Mon, Jul 27, 2009 at 09:25:37PM +0100, Ross Vandegrift wrote:
>Hey all,
>
>Everytime I need to programmatically lookup prefixes in the routing
>table on our 6500s, I try to find a better MIB than I use today.
>
>Today, I discovered CISCO-IETF-IP-FORWARD-MIB - a pre-standard
>IP-FORWARD-MIB that lives under ciscoExperimental.  It's listed in
>Cisco IOS MIB Locator as supported by my image.
>
>Unfortunately, this seems to count as an implementation:
>$ snmpbulkwalk -v 2c -c public lab-6506 CISCO-IETF-IP-FORWARD-MIB::ciscoIetfIpForward
>CISCO-IETF-IP-FORWARD-MIB::cInetCidrRouteNumber.0 = Gauge32: 0
>
>Any way to get this MIB populated?

AFAIK it only contains IPv6 entries at the current time.

Unfortunately I'm not sure there's a good way to easily lookup routes in 
a cisco via SNMP.


>
>-- 
>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
>_______________________________________________
>cisco-nsp mailing list  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 Jul 27 20:11:43 2009
From: david at hughes.com.au (David Hughes)
Date: Tue, 28 Jul 2009 10:11:43 +1000
Subject: [c-nsp] BGP Multipath and unequal IGP metrics
Message-ID: <073E0C99-024C-4D1B-8B1B-347F5CD8302F@hughes.com.au>

Hi

I have a situation that looks like a problem in the making.  In a  
subset of our network there's a pair of well connected datacentres (eg  
dual 10GE paths etc).  One of our upstreams will shortly be presenting  
a transit path at both of these 2 locations.  No problems I think to  
myself - we'll just multi-path from our core and load share over both  
paths.

Problem.  Seeing as the 2 border routers in question are at different  
locations, the core routers see different IGP metrics to the nexthop  
of the BGP table entry.  As a result they are excluded from use with  
BGP multipath and I'm left with the core routers at each DC only using  
the paths to the border router at the local site.

I don't want to mess around with tweaking the OSPF metrics as I'm sure  
that's just a disaster waiting to happen for some poor network  
engineer in a year or two.  I thought I'd found a nice clean solution  
with Cisco's "multipath unequal-cost" feature but for some reason I  
can't even start to understand you can only use it in a VRF, not in  
the default table.

So the only solution I can see is to reconfigure the core devices and  
move all interfaces and routing processes into a VRF so that I can  
effectively get this feature on our entire table.

What am I missing here?  Surely I'm not Robinson Crusoe - someone must  
have done this before.  Platform is Cat6k / Sup720.


Thanks

David
...

From ml at kenweb.org  Mon Jul 27 20:12:30 2009
From: ml at kenweb.org (ML)
Date: Mon, 27 Jul 2009 20:12:30 -0400
Subject: [c-nsp] PBR on ME3400
Message-ID: <4A6E426E.40002@kenweb.org>

Has anyone on the list tried to perform PBR on the ME3400 while setting 
next hop to an IP at the far end of a GRE tunnel?

I was attempting this today and the ME3400 seemed to ignore my PBR 
wishes.  If the next hop was an IP off a routed port everything was ok.

I had "sdm prefer default" IOS is: 12.2(44)SE2 IPACCESS


From pwu828 at gmail.com  Mon Jul 27 20:52:37 2009
From: pwu828 at gmail.com (PW)
Date: Tue, 28 Jul 2009 10:52:37 +1000
Subject: [c-nsp] 6500 ARPing behaviour
In-Reply-To: <8FAC1E47484E43469AA28DBF35C955E4A497329E43@EXMBX.SHSU.EDU>
References: <8FAC1E47484E43469AA28DBF35C955E4A497329E43@EXMBX.SHSU.EDU>
Message-ID: <a7c61c610907271752v3e111b77ief6d35a1c4b7eaf0@mail.gmail.com>

Thank you all,

I have checked the captured traffic (not just ARP traffic) on the host, but
nothing relevant except the ARP response...

I will proceed to check the cache flows the next time it happens, but last
time I checked there's nothing really stands out, but then I didn't have all
the interfaces cache flows turned on...

And yes, there are some hosts that have a default route to that SVI. Local
proxy-arp is off by default I believe and I have not change that...

The issue only happens once a day for the last few days at random time each
day. The configuration worked fine before, and there were no major changes
in the infrastructure configuration of the switch except for adding a few
vlans and IPs, so the issue might be originated from those networks...

Now just need to wait for the next iteration of the issue...

Thanks again!

Patrick

On Tue, Jul 28, 2009 at 3:10 AM, Whitlock, Ronnie <UCS_RLW at shsu.edu> wrote:

> Patrick,
>
> Do you happen to have a route pointing to this SVI interface?  Like
> x.x.x.x x.x.x.x vlan 10.  If so this will cause the behavior that you are
> seeing.
>
>
> Ronnie
>
>
> ________________________________________
> Date: Mon, 27 Jul 2009 18:27:16 +1000
> From: PW <pwu828 at gmail.com>
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] 6500 ARPing behaviour
> Message-ID:
>        <a7c61c610907270127n2de51383h2a16a51301c398aa at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi All,
>
> Recently we are seeing some unusual behaviour with one of our 6500
> switches,
> where it is broadcasting ARPs for every IP address sequentially within the
> subnet of one of the SVIs every now and then.
>
> There are two streams of sequential broadcasts that I can see, with one
> starts a few minutes later than the other. Not all IPs in the subnet can be
> resolved as those IPs are not used.
>
> I have captured the ARP traffic for an actual host within the subnet, and
> apart from an ARP response from the host back to the 6500 switch, there is
> really nothing else happening after that.
>
> Any one have an idea of why the switch is behaving this way? I initially
> thought some external hosts is trying to ping every address on the subnet,
> but after I found out apart from the ARP traffic there's nothing else, I'm
> not so sure.
>
>  Thanks in advance!
>
> cheers,
> Patrick
> _______________________________________________
> cisco-nsp mailing list  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  Mon Jul 27 20:58:31 2009
From: rubensk at gmail.com (Rubens Kuhl)
Date: Mon, 27 Jul 2009 21:58:31 -0300
Subject: [c-nsp] PBR on ME3400
In-Reply-To: <4A6E426E.40002@kenweb.org>
References: <4A6E426E.40002@kenweb.org>
Message-ID: <6bb5f5b10907271758s5079f250g3982466ff02f602d@mail.gmail.com>

My guess is it would require "set ip next-hop recursive" to work even
on an hypothetical platform that support such thing.


Rubens



On Mon, Jul 27, 2009 at 9:12 PM, ML<ml at kenweb.org> wrote:
> Has anyone on the list tried to perform PBR on the ME3400 while setting next
> hop to an IP at the far end of a GRE tunnel?
>
> I was attempting this today and the ME3400 seemed to ignore my PBR wishes.
> ?If the next hop was an IP off a routed port everything was ok.
>
> I had "sdm prefer default" IOS is: 12.2(44)SE2 IPACCESS
>
> _______________________________________________
> cisco-nsp mailing list ?cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From rsm at fast-serv.com  Mon Jul 27 21:53:25 2009
From: rsm at fast-serv.com (Randy McAnally)
Date: Mon, 27 Jul 2009 21:53:25 -0400
Subject: [c-nsp] 6500 ARPing behaviour
In-Reply-To: <a7c61c610907271752v3e111b77ief6d35a1c4b7eaf0@mail.gmail.com>
References: <8FAC1E47484E43469AA28DBF35C955E4A497329E43@EXMBX.SHSU.EDU>
	<a7c61c610907271752v3e111b77ief6d35a1c4b7eaf0@mail.gmail.com>
Message-ID: <20090728015236.M88019@fast-serv.com>

Sounds like maybe a line card resetting itself.  Enable as much logging as
possible and examine them.

--
Randy
\\\\\

---------- Original Message -----------
From: PW <pwu828 at gmail.com>
To: "Whitlock, Ronnie" <UCS_RLW at shsu.edu>
Cc: "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>
Sent: Tue, 28 Jul 2009 10:52:37 +1000
Subject: Re: [c-nsp] 6500 ARPing behaviour

> Thank you all,
> 
> I have checked the captured traffic (not just ARP traffic) on the 
> host, but nothing relevant except the ARP response...
> 
> I will proceed to check the cache flows the next time it happens,
>  but last time I checked there's nothing really stands out, but then 
> I didn't have all the interfaces cache flows turned on...
> 
> And yes, there are some hosts that have a default route to that SVI. 
> Local proxy-arp is off by default I believe and I have not change that...
> 
> The issue only happens once a day for the last few days at random 
> time each day. The configuration worked fine before, and there were 
> no major changes in the infrastructure configuration of the switch 
> except for adding a few vlans and IPs, so the issue might be 
> originated from those networks...
> 
> Now just need to wait for the next iteration of the issue...
> 
> Thanks again!
> 
> Patrick
> 
> On Tue, Jul 28, 2009 at 3:10 AM, Whitlock, Ronnie <UCS_RLW at shsu.edu> 
> wrote:
> 
> > Patrick,
> >
> > Do you happen to have a route pointing to this SVI interface?  Like
> > x.x.x.x x.x.x.x vlan 10.  If so this will cause the behavior that you are
> > seeing.
> >
> >
> > Ronnie
> >
> >
> > ________________________________________
> > Date: Mon, 27 Jul 2009 18:27:16 +1000
> > From: PW <pwu828 at gmail.com>
> > To: cisco-nsp at puck.nether.net
> > Subject: [c-nsp] 6500 ARPing behaviour
> > Message-ID:
> >        <a7c61c610907270127n2de51383h2a16a51301c398aa at mail.gmail.com>
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > Hi All,
> >
> > Recently we are seeing some unusual behaviour with one of our 6500
> > switches,
> > where it is broadcasting ARPs for every IP address sequentially within the
> > subnet of one of the SVIs every now and then.
> >
> > There are two streams of sequential broadcasts that I can see, with one
> > starts a few minutes later than the other. Not all IPs in the subnet can be
> > resolved as those IPs are not used.
> >
> > I have captured the ARP traffic for an actual host within the subnet, and
> > apart from an ARP response from the host back to the 6500 switch, there is
> > really nothing else happening after that.
> >
> > Any one have an idea of why the switch is behaving this way? I initially
> > thought some external hosts is trying to ping every address on the subnet,
> > but after I found out apart from the ARP traffic there's nothing else, I'm
> > not so sure.
> >
> >  Thanks in advance!
> >
> > cheers,
> > Patrick
> > _______________________________________________
> > cisco-nsp mailing 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 td_miles at yahoo.com  Tue Jul 28 02:45:18 2009
From: td_miles at yahoo.com (Tony)
Date: Mon, 27 Jul 2009 23:45:18 -0700 (PDT)
Subject: [c-nsp] 7600 QoS policing
Message-ID: <334114.93279.qm@web110103.mail.gq1.yahoo.com>

Hi all,

I'm hoping that someone might be able to help with some suggestions for how to configure QoS for the following setup. I've read a whole lot of documentation and can't find anything that helps me.

Device: 7609 sup720-3b running 12.2(33)SRD1. GigE card = WS-X6516-GE-TX

Site 1 = 40Mbps, two VLANs, connected to Gi7/5
Site 2 = 10Mbps, two VLANs (21 & 22), connected to Gig7/4
Site 3 = 4Mbps, two VLANs (31 & 32), connected to Gig7/4
Site 4 = 4Mbps, two VLANs (41 & 42), connected to Gig7/4

All of the links are provided by external carriers (two different ones) and it is assumed that they rate limit to the agreed purchased bandwidth non-discriminantly (ie. they chuck out whatever exceeds the configured rate).

If you're wondering how 40Mbps in from one site is ever going to work going out to other sites that only have an aggregate of 18Mbps, that's because there are other sites connected via MPLS, I'm just interested in the ones that are local to this PE for now.

What I want to achieve is that for each of site 2, 3 & 4 I prioritise voice traffic. This voice traffic is allowed to have up to 3Mbps of the link to itself if required, the rest is available for general data traffic. The voice traffic will always be in ONE of the VLANs to each site. The voice VLAN is attached to a seperate VRF than the data VLAN, but no MPLS on the site links, the traffic is L3 seperated by being on different VLANs, with each VLAN connecting to different gear at the CPE.

I have been looking at PFC QoS and my first thought was to police based on the VLANs using a hierarchical model like this (assuming hierarchical qos is supported on PFC3B, which I think it is ?):

class-map c1
   match any

class-map s2
!site 2
   match vlan 21, 22

class-map s3
!site 3
   match vlan 31, 32

class-map s4
!site 4
   match vlan 41, 42

policy p_gig7-4
   class c1
      police 18000000
      service-policy p_vlan

policy p_vlan
  class s2
     police 10000000
  class s2
     police 4000000
  class s2
     police 4000000
     
I'm well aware that the above isn't a valid config, consider it pseudocode for what I'm trying to achieve which is to limit all of the vlans together to 18Mbps, with each site limited to it's own specific bandwidth within a child policy below that.

This seems like a reasonable place to start (provided it could actually be implemented). I don't think I can match on vlan attribute, but I can probably get around that by matching on either destination address or something else. The main problem I can see is that the policer won't discriminate between the different vlan's so if the data vlan is using too much, then I'm probably going to lose voice packets when both vlans get policed (which I don't want, I want to chuck data packets first). The voice packets are marked DSCP-EF (COS-5), so will the policer favour throwing out the lower DSCP packets first to keep within the policed values ? I can't see anything that says it will and I can't see why it would as it's just a plain policer.

I could police the data vlan for each site so that there is always 3Mbps left for the voice (ie. site2 - police to 7Mbps, site3&4 police to 1Mbps), but this means that I am enforcing that limit regardless of whether there is voice traffic or not and so not getting most efficient use of bandwidth available.

My understanding from the documentation & flowcharts that I've read is that policing is done by PFC BEFORE interface queueing, so that if I want to police to a certain rate, it needs to be done before the traffic gets to the egress queues (ie. Q1, Q2 & PQ for my particular card). Once it gets to the egress queues I can't rate-limit and it will try to send at the interface speed (ie. Gbps) to the provider, who will most likely accept the traffic at Gbps rate and then drop at a later stage somewhere in their network if it exceeds link speed to the site in question.

So how can I police to a certain rate with preference given to dropping lower priority packets up to the policed rate ? I'd like to be able to specify a policing situation so that for each pair of VLANs per site I have 4Mbps of bandwidth with up to 3Mbps committed to voice traffic. Ideally I could also speficy others too, so up to 3Mbps for COS-5, up to 1Mbps guaranteed for COS-4 (after COS-5 had been served) and then whatever is left for everything else. Am I missing something simple here ?

I haven't really said anything about Site 1, but it needs to have a similar config so that traffic over the configured rate will be dropped with lower priority packets being dropped first.

I'm not looking for someone to give me the entire answer with config included, I'm happy to be pointed in the right direction. Any workarounds will be actively entertained.

If you've read this far, thanks for sticking with me.


regards,
Tony.




      


From zivl at gilat.net  Tue Jul 28 03:02:13 2009
From: zivl at gilat.net (Ziv Leyes)
Date: Tue, 28 Jul 2009 10:02:13 +0300
Subject: [c-nsp] Cisco Catalyst 2960PD-8TT-L
In-Reply-To: <4A6E0B0A.5060402@inex.ie>
References: <876789290907270035l2d666d4aoedcb161a98dd0ed0@mail.gmail.com>
	<4A6DD839.1000806@justinshore.com> <4A6DDC15.30800@inex.ie>
	<4A6DF899.5060906@justinshore.com> <4A6E0B0A.5060402@inex.ie>
Message-ID: <EC993E87D960A541A66BF21D62AA42A623016E9EB1@exch2k7.gilat.local>

You mean "_Carthago delenda est_"



-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Nick Hilliard
Sent: Monday, July 27, 2009 11:16 PM
To: Justin Shore
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Cisco Catalyst 2960PD-8TT-L

On 27/07/2009 19:57, Justin Shore wrote:
> Interesting. So they don't have a Cisco CLI but they have an otherwise
> limited CLI if you know the tricks to get into it. I don't think that
> will be helpful in RANCID though. I don't think I can make it jump
> through all the hoops necessary to get logged in or pass meta control
> characters. Interesting nonetheless though.

Well, they do have a limited Cisco CLI, which is enough for them to store 
the complete switch configuration in a cisco-style configuration file.  You 
can see this file if you boot into the bootprom (press either ESC or CTRL-U 
on bootup on the serial console).  In theory you can also tftp this file up 
to a tftp server, but from an automation point of view, the problem in 
practice turns out to be getting past the stupid curses based interface and 
dealing with the various models.

The SRW224, for example, doesn't support lcli at all, although at least it 
supports browsers other than IE6/IE7.  I don't think the SLM series 
supports lcli either - which is a pain, given that they are newer boxes and 
support cisco style configuration files (the SRW224 config files are binary).

On a "delenda est carthago" note, whoever in Linksys made the dysfunctional 
decision only to support IE6/IE7 seriously needs to be kicked up the ass.

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

 
 
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************




 
 
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************




From zivl at gilat.net  Tue Jul 28 03:11:03 2009
From: zivl at gilat.net (Ziv Leyes)
Date: Tue, 28 Jul 2009 10:11:03 +0300
Subject: [c-nsp] L2TPv3 Tunnel bandwidth and QoS
In-Reply-To: <78C984F8939D424697B15E4B1C1BB3D7010AB06A@xmb-ams-331.emea.cisco.com>
References: <EC993E87D960A541A66BF21D62AA42A623016E9CC7@exch2k7.gilat.local>
	<78C984F8939D424697B15E4B1C1BB3D7010AB06A@xmb-ams-331.emea.cisco.com>
Message-ID: <EC993E87D960A541A66BF21D62AA42A623016E9EC1@exch2k7.gilat.local>

Thanks,
After looking deeper into the scenario and router configs I kinda managed to come up with it.
I still didn't implement it and if we're talking I'd better show you so you can confirm it will do what I need it to do.
The customer has a 13Mb internet link and I need to set 2Mb for the tunnel, this is what I've set:

ip access-list standard CUSTOMER
 ! this is the customer's rtr - xconnect destination ip:
 permit 12.34.56.78
!
class-map match-all CUSTOMER
 match access-group name CUSTOMER
!
!
policy-map CUSTOMER-L2TPV3
 class CUSTOMER
  priority 2000
  police rate 2000000
!

Ziv

-----Original Message-----
From: Arie Vayner (avayner) [mailto:avayner at cisco.com] 
Sent: Monday, July 27, 2009 6:12 PM
To: Ziv Leyes; Cisco-nsp
Subject: RE: [c-nsp] L2TPv3 Tunnel bandwidth and QoS

Ziv,

You should be able to match the tunnel by matching it's IP endpoints.
If you could share more info about your QOS requirements, I could assist
with building the policy.

Arie

-----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, July 27, 2009 11:15
To: Cisco-nsp
Subject: [c-nsp] L2TPv3 Tunnel bandwidth and QoS

Hi all,
I'd like to know if there is a feasible way to guarantee QoS for an
L2TPv3 tunnel
My customer has a 13Mb uplink to the internet and we've set a tunnel
between customer's router and one of our routers, we want to perform
some settings on his side that will assure the L2TP tunnel gets always
2Mb
I know that some settings will not only guarantee but also limit it to
2M, and it's ok for us.
My question is what shall I set as a matching setting? The remote tunnel
IP? The inside IPs?
TIA,

Ziv


 
 
************************************************************************
************
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 arievayner at gmail.com  Tue Jul 28 03:42:39 2009
From: arievayner at gmail.com (Arie Vayner)
Date: Tue, 28 Jul 2009 10:42:39 +0300
Subject: [c-nsp] L2TPv3 Tunnel bandwidth and QoS
In-Reply-To: <EC993E87D960A541A66BF21D62AA42A623016E9EC1@exch2k7.gilat.local>
References: <EC993E87D960A541A66BF21D62AA42A623016E9CC7@exch2k7.gilat.local> 
	<78C984F8939D424697B15E4B1C1BB3D7010AB06A@xmb-ams-331.emea.cisco.com>
	<EC993E87D960A541A66BF21D62AA42A623016E9EC1@exch2k7.gilat.local>
Message-ID: <20b13c6b0907280042u3a1016f0wb3515e6310e1b32e@mail.gmail.com>

Ziv,

You need to apply a nested policy...
The parent policy should do shaping to the real link rate, or else the
router does not have any way to know how much bandwidth is really out there.
The child policy should have the policy you want for the different classes.

Are you sure you want to put the tunnel in the priority queue?
You could assign it to a regular class, and just assign "bandwidth" to it.
This would allow the tunnel to burst to more than 2M if the BW is available.

Arie

On Tue, Jul 28, 2009 at 10:11 AM, Ziv Leyes <zivl at gilat.net> wrote:

> Thanks,
> After looking deeper into the scenario and router configs I kinda managed
> to come up with it.
> I still didn't implement it and if we're talking I'd better show you so you
> can confirm it will do what I need it to do.
> The customer has a 13Mb internet link and I need to set 2Mb for the tunnel,
> this is what I've set:
>
> ip access-list standard CUSTOMER
>  ! this is the customer's rtr - xconnect destination ip:
>  permit 12.34.56.78
> !
> class-map match-all CUSTOMER
>  match access-group name CUSTOMER
> !
> !
> policy-map CUSTOMER-L2TPV3
>  class CUSTOMER
>  priority 2000
>  police rate 2000000
> !
>
> Ziv
>
> -----Original Message-----
> From: Arie Vayner (avayner) [mailto:avayner at cisco.com]
> Sent: Monday, July 27, 2009 6:12 PM
> To: Ziv Leyes; Cisco-nsp
> Subject: RE: [c-nsp] L2TPv3 Tunnel bandwidth and QoS
>
> Ziv,
>
> You should be able to match the tunnel by matching it's IP endpoints.
> If you could share more info about your QOS requirements, I could assist
> with building the policy.
>
> Arie
>
> -----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, July 27, 2009 11:15
> To: Cisco-nsp
> Subject: [c-nsp] L2TPv3 Tunnel bandwidth and QoS
>
> Hi all,
> I'd like to know if there is a feasible way to guarantee QoS for an
> L2TPv3 tunnel
> My customer has a 13Mb uplink to the internet and we've set a tunnel
> between customer's router and one of our routers, we want to perform
> some settings on his side that will assure the L2TP tunnel gets always
> 2Mb
> I know that some settings will not only guarantee but also limit it to
> 2M, and it's ok for us.
> My question is what shall I set as a matching setting? The remote tunnel
> IP? The inside IPs?
> TIA,
>
> Ziv
>
>
>
>
> ************************************************************************
> ************
> 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.
>
> ************************************************************************************
>
>
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From hank at efes.iucc.ac.il  Tue Jul 28 03:50:11 2009
From: hank at efes.iucc.ac.il (Hank Nussbacher)
Date: Tue, 28 Jul 2009 10:50:11 +0300
Subject: [c-nsp] Humor: Cisco announces end of BGP
Message-ID: <5.1.0.14.2.20090728104929.051778f8@efes.iucc.ac.il>

I just got this product alert from Cisco:

>From: CiscoNotificationService at cisco.com
>To: hank at efes.iucc.ac.il
>Subject: Cisco Notification Alert -Alerts_Daily-07/28/2009 07:38 GMT
> 
>
>Cisco Notification Service Alert:
>
>Cisco Notification Alert -Alerts_Daily-07/28/2009 07:38 GMT
>
>End-of-Sale and End-of-Life Announcements-Border Gateway Protocol 
>(BGP)-07/27/2009 08:44 GMT-07/28/2009 07:35 GMT

What exactly does Cisco have planned as a replacement?  :-)

-Hank



From nick at inex.ie  Tue Jul 28 04:30:15 2009
From: nick at inex.ie (Nick Hilliard)
Date: Tue, 28 Jul 2009 09:30:15 +0100
Subject: [c-nsp] Cisco Catalyst 2960PD-8TT-L
In-Reply-To: <EC993E87D960A541A66BF21D62AA42A623016E9EB1@exch2k7.gilat.local>
References: <876789290907270035l2d666d4aoedcb161a98dd0ed0@mail.gmail.com>	<4A6DD839.1000806@justinshore.com>
	<4A6DDC15.30800@inex.ie>	<4A6DF899.5060906@justinshore.com>
	<4A6E0B0A.5060402@inex.ie>
	<EC993E87D960A541A66BF21D62AA42A623016E9EB1@exch2k7.gilat.local>
Message-ID: <4A6EB717.5090606@inex.ie>

On 28/07/2009 08:02, Ziv Leyes wrote:
> delenda est carthago

This is ridiculously off-topic, but the original wording as Cato used in 
his speeches is long lost.

The primary reference for this phrase comes from Plutarch who wrote in one 
of his Lives: "...??? ? ????????? ?????? ?? ???????????" ("...and it is 
fitting that Carthage be destroyed").  The Latin "delenda est carthago" is 
usually used, but "carthago delenda est" is occasionally quoted and means 
the same thing - latin is pretty insensitive about the location of words, 
and it unambiguously means the same thing.

Anyway, the point of all this is that Linksys need to realise that not 
everyone has internet explorer on their computer, and depending on its 
presence to be able to configure your switch is something which pegs my 
suck-o-meter.

Nick

From paul at gtcomm.net  Tue Jul 28 03:38:52 2009
From: paul at gtcomm.net (Paul)
Date: Tue, 28 Jul 2009 03:38:52 -0400
Subject: [c-nsp] DAI (arp inspection) Issue on 6500 [SXH2a,SUP720-3b]
Message-ID: <4A6EAB0C.7070101@gtcomm.net>

I am attempting to use statically configured arp inspection on a vlan on 
our 6500.
Here's an example, we have , say, vlan500, vlan 500 is assigned to ports 
gi11/1-48
The configuration on the ports are as follows:
 switchport
 switchport access vlan 500
 switchport mode access
 switchport block unicast
 switchport port-security
 switchport port-security maximum 4
 switchport port-security aging time 60
 switchport port-security violation restrict
 switchport port-security aging type inactivity
 switchport port-security mac-address sticky
 ip arp inspection limit rate 25 burst interval 5
 storm-control broadcast level 0.50
 storm-control multicast level 0.50
 no cdp enable
 spanning-tree bpduguard enable

I created, arp access-list vlan500 and then i did ip arp inspection 
filter vlan500 vlan 500
I made the arp access-list simply permit ip any mac any so it should 
allow everything.

The problem is, none of the machines on vlan 500 can talk to each 
other.  They can talk to the gateway address which is on interface vlan 500
interface Vlan500
 ip address 10.0.0.1 255.255.255.192
 ip helper-address 10.10.10.10
 no ip redirects
 no ip unreachables
 ip sticky-arp
 no ip proxy-arp
 arp timeout 3200

So what am I doing wrong that nothing on this vlan can send arp requests 
to each other?? If i disable arp inspection they can send/receive arp 
responses
fine.. say 10.0.0.5 can arp 10.0.0.6 (10.0.0.5 would be on say gi11/5 
and 10.0.0.6 be on gi11/6) but when i enable it,   arps don't make it.

Cisco IOS Software, s72033_rp Software (s72033_rp-IPSERVICESK9_WAN-M), 
Version 12.2(33)SXH2a, RELEASE SOFTWARE (fc2)
cisco WS-C6513 (R7000) processor (revision 1.0) with 458720K/65536K 
bytes of memory.
This is SUP720-3B

My understanding is that this should work, so I am thinking this is a 
bug in the code? I tried this on two 6500's both with the same code. I 
will try it on
a test in the lab with SXH5. If anoyne has any idea feel free to chime 
in and cc my email in the reply.

Thanks!!

-- 
GloboTech Communications
Phone: 1-514-907-0050 x 215
Toll Free: 1-(888)-GTCOMM1
Fax: 1-(514)-907-0750
paul at gtcomm.net
http://www.gtcomm.net 


From eng_mssk at hotmail.com  Tue Jul 28 04:48:30 2009
From: eng_mssk at hotmail.com (Mohammad Khalil)
Date: Tue, 28 Jul 2009 11:48:30 +0300
Subject: [c-nsp] IP Sla
Message-ID: <BLU102-W3FAB313F7220E5929D569FA150@phx.gbl>


hi all

i configured the following on my router 

ip sla 200
 icmp-echo 4.2.2.2
 threshold 50
 frequency 5
ip sla schedule 200 life forever start-time now

event manager applet FILE 
 event snmp oid "1.3.6.1.4.1.9.9.42.1.2.9.1.7.200" get-type exact entry-op eq entry-val "1" exit-op eq exit-val "2" poll-interval 5
 action 1.0 syslog msg "RTT"
 action 1.1 mail server "x.x.x.x" to "x at x.com" from "y at x.com" subject "test"

now the average RTT value to 4.2.2.2 is about 90ms
i configured the threshold to be 50 so that the sla will count continously

but i received one mail and didnt receive another mail after that ?
any ideas how to keep sending that mail ?

thanks in advnace




_________________________________________________________________
Share your memories online with anyone you want.
http://www.microsoft.com/middleeast/windows/windowslive/products/photos-share.aspx?tab=1

From zivl at gilat.net  Tue Jul 28 05:34:35 2009
From: zivl at gilat.net (Ziv Leyes)
Date: Tue, 28 Jul 2009 12:34:35 +0300
Subject: [c-nsp] L2TPv3 Tunnel bandwidth and QoS
In-Reply-To: <20b13c6b0907280042u3a1016f0wb3515e6310e1b32e@mail.gmail.com>
References: <EC993E87D960A541A66BF21D62AA42A623016E9CC7@exch2k7.gilat.local>
	<78C984F8939D424697B15E4B1C1BB3D7010AB06A@xmb-ams-331.emea.cisco.com>
	<EC993E87D960A541A66BF21D62AA42A623016E9EC1@exch2k7.gilat.local>
	<20b13c6b0907280042u3a1016f0wb3515e6310e1b32e@mail.gmail.com>
Message-ID: <EC993E87D960A541A66BF21D62AA42A623016E9F9A@exch2k7.gilat.local>

Would you give an example for the nested policy?
I do want to put it in the priority queue, the link that ends the xconnect is an interface connected to a Metro-E service that is physically limited to 2Mb so it won't be able to exceed it anyway, that's why I want to limit it on the router too, while also guaranteeing its priority.
Thanks,
Ziv

From: Arie Vayner [mailto:arievayner at gmail.com]
Sent: Tuesday, July 28, 2009 10:43 AM
To: Ziv Leyes
Cc: Arie Vayner (avayner); Cisco-nsp
Subject: Re: [c-nsp] L2TPv3 Tunnel bandwidth and QoS

Ziv,

You need to apply a nested policy...
The parent policy should do shaping to the real link rate, or else the router does not have any way to know how much bandwidth is really out there.
The child policy should have the policy you want for the different classes.

Are you sure you want to put the tunnel in the priority queue?
You could assign it to a regular class, and just assign "bandwidth" to it.
This would allow the tunnel to burst to more than 2M if the BW is available.

Arie
On Tue, Jul 28, 2009 at 10:11 AM, Ziv Leyes <zivl at gilat.net<mailto:zivl at gilat.net>> wrote:
Thanks,
After looking deeper into the scenario and router configs I kinda managed to come up with it.
I still didn't implement it and if we're talking I'd better show you so you can confirm it will do what I need it to do.
The customer has a 13Mb internet link and I need to set 2Mb for the tunnel, this is what I've set:

ip access-list standard CUSTOMER
 ! this is the customer's rtr - xconnect destination ip:
 permit 12.34.56.78
!
class-map match-all CUSTOMER
 match access-group name CUSTOMER
!
!
policy-map CUSTOMER-L2TPV3
 class CUSTOMER
 priority 2000
 police rate 2000000
!

Ziv

-----Original Message-----
From: Arie Vayner (avayner) [mailto:avayner at cisco.com<mailto:avayner at cisco.com>]
Sent: Monday, July 27, 2009 6:12 PM
To: Ziv Leyes; Cisco-nsp
Subject: RE: [c-nsp] L2TPv3 Tunnel bandwidth and QoS

Ziv,

You should be able to match the tunnel by matching it's IP endpoints.
If you could share more info about your QOS requirements, I could assist
with building the policy.

Arie

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net<mailto:cisco-nsp-bounces at puck.nether.net>
[mailto:cisco-nsp-bounces at puck.nether.net<mailto:cisco-nsp-bounces at puck.nether.net>] On Behalf Of Ziv Leyes
Sent: Monday, July 27, 2009 11:15
To: Cisco-nsp
Subject: [c-nsp] L2TPv3 Tunnel bandwidth and QoS

Hi all,
I'd like to know if there is a feasible way to guarantee QoS for an
L2TPv3 tunnel
My customer has a 13Mb uplink to the internet and we've set a tunnel
between customer's router and one of our routers, we want to perform
some settings on his side that will assure the L2TP tunnel gets always
2Mb
I know that some settings will not only guarantee but also limit it to
2M, and it's ok for us.
My question is what shall I set as a matching setting? The remote tunnel
IP? The inside IPs?
TIA,

Ziv




************************************************************************
************
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<mailto: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<mailto: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 avayner at cisco.com  Tue Jul 28 06:13:25 2009
From: avayner at cisco.com (Arie Vayner (avayner))
Date: Tue, 28 Jul 2009 12:13:25 +0200
Subject: [c-nsp] L2TPv3 Tunnel bandwidth and QoS
In-Reply-To: <EC993E87D960A541A66BF21D62AA42A623016E9F9A@exch2k7.gilat.local>
References: <EC993E87D960A541A66BF21D62AA42A623016E9CC7@exch2k7.gilat.local><78C984F8939D424697B15E4B1C1BB3D7010AB06A@xmb-ams-331.emea.cisco.com><EC993E87D960A541A66BF21D62AA42A623016E9EC1@exch2k7.gilat.local><20b13c6b0907280042u3a1016f0wb3515e6310e1b32e@mail.gmail.com>
	<EC993E87D960A541A66BF21D62AA42A623016E9F9A@exch2k7.gilat.local>
Message-ID: <78C984F8939D424697B15E4B1C1BB3D7010AB313@xmb-ams-331.emea.cisco.com>

Ziv,

 

Take a look here:

http://www.cisco.com/en/US/partner/docs/ios/qos/configuration/guide/qos_
mqc.html#wp1060197

 

Arie

 

From: Ziv Leyes [mailto:zivl at gilat.net] 
Sent: Tuesday, July 28, 2009 12:35
To: Arie Vayner
Cc: Arie Vayner (avayner); Cisco-nsp
Subject: RE: [c-nsp] L2TPv3 Tunnel bandwidth and QoS

 

Would you give an example for the nested policy?

I do want to put it in the priority queue, the link that ends the
xconnect is an interface connected to a Metro-E service that is
physically limited to 2Mb so it won't be able to exceed it anyway,
that's why I want to limit it on the router too, while also guaranteeing
its priority.

Thanks,

Ziv

 

From: Arie Vayner [mailto:arievayner at gmail.com] 
Sent: Tuesday, July 28, 2009 10:43 AM
To: Ziv Leyes
Cc: Arie Vayner (avayner); Cisco-nsp
Subject: Re: [c-nsp] L2TPv3 Tunnel bandwidth and QoS

 

Ziv,

You need to apply a nested policy...
The parent policy should do shaping to the real link rate, or else the
router does not have any way to know how much bandwidth is really out
there.
The child policy should have the policy you want for the different
classes.

Are you sure you want to put the tunnel in the priority queue?
You could assign it to a regular class, and just assign "bandwidth" to
it.
This would allow the tunnel to burst to more than 2M if the BW is
available.

Arie

On Tue, Jul 28, 2009 at 10:11 AM, Ziv Leyes <zivl at gilat.net> wrote:

Thanks,
After looking deeper into the scenario and router configs I kinda
managed to come up with it.
I still didn't implement it and if we're talking I'd better show you so
you can confirm it will do what I need it to do.
The customer has a 13Mb internet link and I need to set 2Mb for the
tunnel, this is what I've set:

ip access-list standard CUSTOMER
 ! this is the customer's rtr - xconnect destination ip:
 permit 12.34.56.78
!
class-map match-all CUSTOMER
 match access-group name CUSTOMER
!
!
policy-map CUSTOMER-L2TPV3
 class CUSTOMER
 priority 2000
 police rate 2000000
!

Ziv


-----Original Message-----
From: Arie Vayner (avayner) [mailto:avayner at cisco.com]
Sent: Monday, July 27, 2009 6:12 PM
To: Ziv Leyes; Cisco-nsp
Subject: RE: [c-nsp] L2TPv3 Tunnel bandwidth and QoS

Ziv,

You should be able to match the tunnel by matching it's IP endpoints.
If you could share more info about your QOS requirements, I could assist
with building the policy.

Arie

-----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, July 27, 2009 11:15
To: Cisco-nsp
Subject: [c-nsp] L2TPv3 Tunnel bandwidth and QoS

Hi all,
I'd like to know if there is a feasible way to guarantee QoS for an
L2TPv3 tunnel
My customer has a 13Mb uplink to the internet and we've set a tunnel
between customer's router and one of our routers, we want to perform
some settings on his side that will assure the L2TP tunnel gets always
2Mb
I know that some settings will not only guarantee but also limit it to
2M, and it's ok for us.
My question is what shall I set as a matching setting? The remote tunnel
IP? The inside IPs?
TIA,

Ziv




************************************************************************
************
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.
************************************************************************
************



_______________________________________________
cisco-nsp mailing 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 avayner at cisco.com  Tue Jul 28 06:15:36 2009
From: avayner at cisco.com (Arie Vayner (avayner))
Date: Tue, 28 Jul 2009 12:15:36 +0200
Subject: [c-nsp] IP Sla
In-Reply-To: <BLU102-W3FAB313F7220E5929D569FA150@phx.gbl>
References: <BLU102-W3FAB313F7220E5929D569FA150@phx.gbl>
Message-ID: <78C984F8939D424697B15E4B1C1BB3D7010AB318@xmb-ams-331.emea.cisco.com>

Mohammad,

The way it works is that the "entry-val" would trigger an event once
("enter into the state") and until you do not hit the "exit-val", you
would not get another event.

This is done basically to generate a single alarm instead of getting a
repeating one.

Arie

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Mohammad Khalil
Sent: Tuesday, July 28, 2009 11:49
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] IP Sla


hi all

i configured the following on my router 

ip sla 200
 icmp-echo 4.2.2.2
 threshold 50
 frequency 5
ip sla schedule 200 life forever start-time now

event manager applet FILE 
 event snmp oid "1.3.6.1.4.1.9.9.42.1.2.9.1.7.200" get-type exact
entry-op eq entry-val "1" exit-op eq exit-val "2" poll-interval 5
 action 1.0 syslog msg "RTT"
 action 1.1 mail server "x.x.x.x" to "x at x.com" from "y at x.com" subject
"test"

now the average RTT value to 4.2.2.2 is about 90ms
i configured the threshold to be 50 so that the sla will count
continously

but i received one mail and didnt receive another mail after that ?
any ideas how to keep sending that mail ?

thanks in advnace




_________________________________________________________________
Share your memories online with anyone you want.
http://www.microsoft.com/middleeast/windows/windowslive/products/photos-
share.aspx?tab=1
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

From osamaslam at hotmail.com  Tue Jul 28 06:45:08 2009
From: osamaslam at hotmail.com (Osama Osama)
Date: Tue, 28 Jul 2009 10:45:08 +0000
Subject: [c-nsp] osamaslam@hotmail.com
Message-ID: <BAY113-W1F71A4DF45098F3E1D3A9AD150@phx.gbl>


 

osamaslam at hotmail.com

_________________________________________________________________
Windows Live? Hotmail?: Celebrate the moment with your favorite sports pics. Check it out.
http://www.windowslive.com/Online/Hotmail/Campaign/QuickAdd?ocid=TXT_TAGLM_WL_QA_HM_sports_photos_072009&cat=sports

From gararda at gmail.com  Tue Jul 28 07:22:20 2009
From: gararda at gmail.com (Daniel Garrido)
Date: Tue, 28 Jul 2009 13:22:20 +0200
Subject: [c-nsp] STP state of MSFC internal ports
Message-ID: <e0f801b70907280422t5a6a6b8ch370bac8300271ee5@mail.gmail.com>

Hi,

I have two 6500 in a LAN connected at layer 2.
Each of them have a SVI with an IP and HSRP working without problems.
When I configure "Fallback Bridging" in the SVI in both switches, HSRP stop
working,
so I think the problem can be related to a segmented L2 network topology.

I found the following link:
http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a00800a7af6.shtml

The questions is: How can I check the STP state of the ports connecting to
the MSFC?

The configuration in both switches is like the following:

interface VlanXX
 ip address X.X.X.X 255.255.255.0
 standby 28 ip X.X.X.Y
 bridge-group 1

bridge 1 protocol vlan-bridge
bridge 1 priority 20000

Best regards.

-- 
Daniel

From thegameiam at yahoo.com  Tue Jul 28 07:48:37 2009
From: thegameiam at yahoo.com (David Barak)
Date: Tue, 28 Jul 2009 04:48:37 -0700 (PDT)
Subject: [c-nsp] Humor: Cisco announces end of BGP
In-Reply-To: <5.1.0.14.2.20090728104929.051778f8@efes.iucc.ac.il>
Message-ID: <788817.40505.qm@web31811.mail.mud.yahoo.com>

ODR perhaps?  Or maybe OER (that&#39;s one letter higher anyway...)

;)

-David

Hank Nussbacher wrote: 
> I just got this product alert from Cisco:
>>From: CiscoNotificationService at cisco.com
>>To: hank at efes.iucc.ac.il
>>Subject: Cisco Notification Alert -Alerts_Daily-07/28/2009 07:38 GMT
>> 
>>
>>Cisco Notification Service Alert:
>>
>>Cisco Notification Alert -Alerts_Daily-07/28/2009 07:38 GMT
>>
>>End-of-Sale and End-of-Life Announcements-Border Gateway Protocol 
>>(BGP)-07/27/2009 08:44 GMT-07/28/2009 07:35 GMT
> What exactly does Cisco have planned as a replacement?  :-)
> -Hank
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/



      

From willay at gmail.com  Tue Jul 28 09:00:26 2009
From: willay at gmail.com (William)
Date: Tue, 28 Jul 2009 14:00:26 +0100
Subject: [c-nsp] ASA v8 , VPN, and time-range access-lists
Message-ID: <a24358fb0907280600s74d29a60va6faa8350ad85d28@mail.gmail.com>

Hi chaps,

I want to have my VPN Client users bound to time ranges so they can
only connect during a certain period of time on week days.Typically my
remote guys will connect at the start of the day and stay connected
till the very end of it or not disconnect at all.

I've been experimenting with access-hours settings on the group policy
and time-range access lists, from what I have worked out if a user is
connected before the access-hours kicks in (i.e. when they aren't
allowed to connect) they will remain connected until they disconnect
by hand or if I boot them off manually.

I decided to try out the time range access-lists on the outside
interface to block their connection attempts once they have logged in
via VPN and start up their application, this seems to work for when
I've connected out of the allowed time but if I am connected before
the time-range kicks in my connection stays active (I was running a
simple ping -t host). Although I did notice after a certain period of
time (around 30 minutes) my ping's stopped replying and the
access-list worked.

Am I doing something wrong hence why the time range access-lists
aren't working properly? The time on the FW is always correct and
sync'd to NTP and I'd appreciate any help!

Cheers,

W

From linux.yahoo at gmail.com  Tue Jul 28 09:09:40 2009
From: linux.yahoo at gmail.com (Manu Chao)
Date: Tue, 28 Jul 2009 15:09:40 +0200
Subject: [c-nsp] STP state of MSFC internal ports
In-Reply-To: <e0f801b70907280422t5a6a6b8ch370bac8300271ee5@mail.gmail.com>
References: <e0f801b70907280422t5a6a6b8ch370bac8300271ee5@mail.gmail.com>
Message-ID: <7100ed370907280609y1aab7d4amc0bf00c70d305780@mail.gmail.com>

show bridge group

On Tue, Jul 28, 2009 at 1:22 PM, Daniel Garrido <gararda at gmail.com> wrote:

> Hi,
>
> I have two 6500 in a LAN connected at layer 2.
> Each of them have a SVI with an IP and HSRP working without problems.
> When I configure "Fallback Bridging" in the SVI in both switches, HSRP stop
> working,
> so I think the problem can be related to a segmented L2 network topology.
>
> I found the following link:
>
> http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a00800a7af6.shtml
>
> The questions is: How can I check the STP state of the ports connecting to
> the MSFC?
>
> The configuration in both switches is like the following:
>
> interface VlanXX
>  ip address X.X.X.X 255.255.255.0
>  standby 28 ip X.X.X.Y
>  bridge-group 1
>
> bridge 1 protocol vlan-bridge
> bridge 1 priority 20000
>
> Best regards.
>
> --
> Daniel
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From koug at intracom.gr  Tue Jul 28 09:38:48 2009
From: koug at intracom.gr (John Kougoulos)
Date: Tue, 28 Jul 2009 16:38:48 +0300 (GTB Daylight Time)
Subject: [c-nsp] ASA v8 , VPN, and time-range access-lists
In-Reply-To: <a24358fb0907280600s74d29a60va6faa8350ad85d28@mail.gmail.com>
References: <a24358fb0907280600s74d29a60va6faa8350ad85d28@mail.gmail.com>
Message-ID: <alpine.WNT.2.00.0907281632300.4068@pckoug1.intranet.gr>

Hello,

The standard approach is to send at authentication via a eg. radius 
attribute a session timeout calculated to the end of the work-day. ACLs 
may not work because the sessions are already established. You could 
experiment with stateless ACLs on a router somewhere "above" your ASA, but 
I would go with the Radius approach.

Regards,
John

On Tue, 28 Jul 2009, William wrote:

> Hi chaps,
>
> I want to have my VPN Client users bound to time ranges so they can
> only connect during a certain period of time on week days.Typically my
> remote guys will connect at the start of the day and stay connected
> till the very end of it or not disconnect at all.
>
> I've been experimenting with access-hours settings on the group policy
> and time-range access lists, from what I have worked out if a user is
> connected before the access-hours kicks in (i.e. when they aren't
> allowed to connect) they will remain connected until they disconnect
> by hand or if I boot them off manually.
>
> I decided to try out the time range access-lists on the outside
> interface to block their connection attempts once they have logged in
> via VPN and start up their application, this seems to work for when
> I've connected out of the allowed time but if I am connected before
> the time-range kicks in my connection stays active (I was running a
> simple ping -t host). Although I did notice after a certain period of
> time (around 30 minutes) my ping's stopped replying and the
> access-list worked.
>
> Am I doing something wrong hence why the time range access-lists
> aren't working properly? The time on the FW is always correct and
> sync'd to NTP and I'd appreciate any help!
>
> Cheers,
>
> W
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From rwest at zyedge.com  Tue Jul 28 09:59:50 2009
From: rwest at zyedge.com (Ryan West)
Date: Tue, 28 Jul 2009 09:59:50 -0400
Subject: [c-nsp] ASA v8 , VPN, and time-range access-lists
In-Reply-To: <a24358fb0907280600s74d29a60va6faa8350ad85d28@mail.gmail.com>
References: <a24358fb0907280600s74d29a60va6faa8350ad85d28@mail.gmail.com>
Message-ID: <6E21B2BDEF6E714EA0B5BA8D5D0E1401248380B42E@zy-ex1.zyedge.local>

William,

This was discussed another list as well, but it seems the router time-based ACLs are absolute and that the ASA waits for active sessions to time out at least when used with vpn-filter.  I believe the vpn-filter is only called once when the user first connects, if you have to make changes to that ACL, it requires a user re-auth.  It would be nice if something like kron existed for the ASA, you could just force a re-auth at 5:00PM.  Have you looked at using 'vpn-access-hours' under the group-policy?

I noticed John mentioned using Radius for the access-hours, but I've been using LDAP a lot of authorization, although I guess that function of Radius would be under authentication.

-ryan

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of William
Sent: Tuesday, July 28, 2009 9:00 AM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] ASA v8 , VPN, and time-range access-lists

Hi chaps,

I want to have my VPN Client users bound to time ranges so they can
only connect during a certain period of time on week days.Typically my
remote guys will connect at the start of the day and stay connected
till the very end of it or not disconnect at all.

I've been experimenting with access-hours settings on the group policy
and time-range access lists, from what I have worked out if a user is
connected before the access-hours kicks in (i.e. when they aren't
allowed to connect) they will remain connected until they disconnect
by hand or if I boot them off manually.

I decided to try out the time range access-lists on the outside
interface to block their connection attempts once they have logged in
via VPN and start up their application, this seems to work for when
I've connected out of the allowed time but if I am connected before
the time-range kicks in my connection stays active (I was running a
simple ping -t host). Although I did notice after a certain period of
time (around 30 minutes) my ping's stopped replying and the
access-list worked.

Am I doing something wrong hence why the time range access-lists
aren't working properly? The time on the FW is always correct and
sync'd to NTP and I'd appreciate any help!

Cheers,

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

From Kiran.Oddiraju at cbre.com  Tue Jul 28 10:01:27 2009
From: Kiran.Oddiraju at cbre.com (Oddiraju, Kiran @ London SMC)
Date: Tue, 28 Jul 2009 15:01:27 +0100
Subject: [c-nsp] VPN clients on Cisco ASA
Message-ID: <B5CFB919B5EEF345969F51FAFE6360D50ADF31@GBLDCXMB10.emea.cbre.net>

Hi Guys,

Appreciate your help on this. Have tried the VPN Wizard and the CLI
config from the below link but still no luck. The Cisco VPN client tries
to connect and after for a few seconds shows Not Connected. I think it
is an ACL issue but I am not 100% sure. I have attached the running
config, could someone please take a look?

Many thanks,
Kiran

-----Original Message-----
From: Ryan West [mailto:rwest at zyedge.com]
Sent: 27 July 2009 13:57
To: Oddiraju, Kiran @ London SMC; cisco-nsp at puck.nether.net
Subject: RE: VPN clients on Cisco ASA

Hello again Kiran,

I think you should take a quick read through the following link.  You
can use the ASDM Remote Access VPN wizard to configure most of the
settings and if you're interested in doing it via CLI, that's also an
option.

http://www.cisco.com/en/US/products/ps6120/products_configuration_exampl
e09186a008060f25c.shtml

In particular, the options you have asked are all covered in the doc
except for split-tunneling, at least the associated output in CLI.
You'll want to configure that inside the group policy you create from
the link above.  Here is an example:

group-policy mygrouppolicyname attributes  split-tunnel-policy
tunnelspecified  split-tunnel-network-list value <ACL Here>

Let me know how it works out for you.

-ryan

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Oddiraju, Kiran
@ London SMC
Sent: Monday, July 27, 2009 8:33 AM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] VPN clients on Cisco ASA

Hi List,

 

Cisco ASA 5505

Cisco VPN Client 5.0

ASA External IP: 80.90.100.117 /29

Internal range: 192.168.0.0 /24

 

I am new to Cisco ASA world and have been struggling to configure my
5505 to accept VPN connections from external hosts. I want to allocate
IP address dynamically, allow access to certain subnets and allow
internet access thru their local connection. Can someone please post me
a sample ASA config?

 

Thanks guys

 

Regards,

Kiran


CB Richard Ellis Limited, Registered Office: St Martin's Court, 10
Paternoster Row, London, EC4M 7HP, registered in England and Wales No.
3536032. 
Regulated by the RICS and an appointed representative of CB Richard
Ellis Indirect Investment Services Limited which is authorised and
regulated by the Financial Services Authority.

This communication is from CB Richard Ellis Limited or one of its
associated/subsidiary companies. This communication contains information
which is confidential and may be privileged. If you are not the intended
recipient, please contact the sender immediately. Any use of its
contents is strictly prohibited and you must not copy, send or disclose
it, or rely on its contents in any way whatsoever. 
Reasonable care has been taken to ensure that this communication (and
any attachments or hyperlinks contained within it) is free from computer
viruses. 
No responsibility is accepted by CB Richard Ellis Limited or its
associated/subsidiary companies and the recipient should carry out any
appropriate virus checks.

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

CB Richard Ellis Limited, Registered Office: St Martin's Court, 
10 Paternoster Row, London, EC4M 7HP, registered in England and Wales No. 3536032. 
Regulated by the RICS and an appointed representative of CB Richard Ellis 
Indirect Investment Services Limited which is authorised and regulated by the Financial Services Authority.

This communication is from CB Richard Ellis Limited or one of its 
associated/subsidiary companies. This communication contains information 
which is confidential and may be privileged. If you are not the intended recipient, 
please contact the sender immediately. Any use of its contents is strictly prohibited 
and you must not copy, send or disclose it, or rely on its contents in any way whatsoever. 
Reasonable care has been taken to ensure that this communication 
(and any attachments or hyperlinks contained within it) is free from computer viruses. 
No responsibility is accepted by CB Richard Ellis Limited or its associated/subsidiary 
companies and the recipient should carry out any appropriate virus checks.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: CUCMASA config.txt
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090728/ebec8be8/attachment-0001.txt>

From rwest at zyedge.com  Tue Jul 28 10:18:30 2009
From: rwest at zyedge.com (Ryan West)
Date: Tue, 28 Jul 2009 10:18:30 -0400
Subject: [c-nsp] VPN clients on Cisco ASA
In-Reply-To: <B5CFB919B5EEF345969F51FAFE6360D50ADF31@GBLDCXMB10.emea.cbre.net>
References: <B5CFB919B5EEF345969F51FAFE6360D50ADF31@GBLDCXMB10.emea.cbre.net>
Message-ID: <6E21B2BDEF6E714EA0B5BA8D5D0E1401248380B434@zy-ex1.zyedge.local>

Kiran,

You'll want to get Xauth configured for your RA-VPN.  Do you have an internal auth server you can query?  You can query AD directly through LDAP / NT protocol / Kerberos or use IAS through RADIUS.  Once you establish those servers, you'll want to call them in your tunnel-group Kir-VPN gen attributes.  You probably also want to set your default-group-policy to Kiran-CUCM-VPN in the same section.  Since you are most likely failing IKE negotiations, you can run a 'debug cry isa 2' and gather more information.

I would recommend following this guide and leveraging IAS, it's more of the traditional method, but I think it would be a good fit for your needs.

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a00806de37e.shtml

You should try to sanitize your configs in the future, just put in x.x.x.x when posting public IPs.

-ryan


-----Original Message-----
From: Oddiraju, Kiran @ London SMC [mailto:Kiran.Oddiraju at cbre.com] 
Sent: Tuesday, July 28, 2009 10:01 AM
To: Ryan West
Cc: cisco-nsp at puck.nether.net
Subject: Re: VPN clients on Cisco ASA

Hi Guys,

Appreciate your help on this. Have tried the VPN Wizard and the CLI config from the below link but still no luck. The Cisco VPN client tries to connect and after for a few seconds shows Not Connected. I think it is an ACL issue but I am not 100% sure. I have attached the running config, could someone please take a look?

Many thanks,
Kiran

-----Original Message-----
From: Ryan West [mailto:rwest at zyedge.com]
Sent: 27 July 2009 13:57
To: Oddiraju, Kiran @ London SMC; cisco-nsp at puck.nether.net
Subject: RE: VPN clients on Cisco ASA

Hello again Kiran,

I think you should take a quick read through the following link.  You can use the ASDM Remote Access VPN wizard to configure most of the settings and if you're interested in doing it via CLI, that's also an option.

http://www.cisco.com/en/US/products/ps6120/products_configuration_exampl
e09186a008060f25c.shtml

In particular, the options you have asked are all covered in the doc except for split-tunneling, at least the associated output in CLI.
You'll want to configure that inside the group policy you create from the link above.  Here is an example:

group-policy mygrouppolicyname attributes  split-tunnel-policy tunnelspecified  split-tunnel-network-list value <ACL Here>

Let me know how it works out for you.

-ryan

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Oddiraju, Kiran @ London SMC
Sent: Monday, July 27, 2009 8:33 AM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] VPN clients on Cisco ASA

Hi List,

 

Cisco ASA 5505

Cisco VPN Client 5.0

ASA External IP: 80.90.100.117 /29

Internal range: 192.168.0.0 /24

 

I am new to Cisco ASA world and have been struggling to configure my
5505 to accept VPN connections from external hosts. I want to allocate IP address dynamically, allow access to certain subnets and allow internet access thru their local connection. Can someone please post me a sample ASA config?

 

Thanks guys

 

Regards,

Kiran


CB Richard Ellis Limited, Registered Office: St Martin's Court, 10 Paternoster Row, London, EC4M 7HP, registered in England and Wales No.
3536032. 
Regulated by the RICS and an appointed representative of CB Richard Ellis Indirect Investment Services Limited which is authorised and regulated by the Financial Services Authority.

This communication is from CB Richard Ellis Limited or one of its associated/subsidiary companies. This communication contains information which is confidential and may be privileged. If you are not the intended recipient, please contact the sender immediately. Any use of its contents is strictly prohibited and you must not copy, send or disclose it, or rely on its contents in any way whatsoever. 
Reasonable care has been taken to ensure that this communication (and any attachments or hyperlinks contained within it) is free from computer viruses. 
No responsibility is accepted by CB Richard Ellis Limited or its associated/subsidiary companies and the recipient should carry out any appropriate virus checks.

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

CB Richard Ellis Limited, Registered Office: St Martin's Court, 10 Paternoster Row, London, EC4M 7HP, registered in England and Wales No. 3536032. 
Regulated by the RICS and an appointed representative of CB Richard Ellis Indirect Investment Services Limited which is authorised and regulated by the Financial Services Authority.

This communication is from CB Richard Ellis Limited or one of its associated/subsidiary companies. This communication contains information which is confidential and may be privileged. If you are not the intended recipient, please contact the sender immediately. Any use of its contents is strictly prohibited and you must not copy, send or disclose it, or rely on its contents in any way whatsoever. 
Reasonable care has been taken to ensure that this communication (and any attachments or hyperlinks contained within it) is free from computer viruses. 
No responsibility is accepted by CB Richard Ellis Limited or its associated/subsidiary companies and the recipient should carry out any appropriate virus checks.


From Michael.Robson at manchester.ac.uk  Tue Jul 28 10:30:21 2009
From: Michael.Robson at manchester.ac.uk (Michael Robson)
Date: Tue, 28 Jul 2009 15:30:21 +0100
Subject: [c-nsp] MTU wierdness
In-Reply-To: <78C984F8939D424697B15E4B1C1BB3D7010AA7BC@xmb-ams-331.emea.cisco.com>
References: <8B081603-97F2-432C-892F-F97940220082@manchester.ac.uk>
	<78C984F8939D424697B15E4B1C1BB3D7010AA7BC@xmb-ams-331.emea.cisco.com>
Message-ID: <73BADEC3-95BF-41A1-AC89-C86F7A951F07@manchester.ac.uk>


> Michael,
>
> Check:
> http://www.cisco.com/en/US/partner/docs/switches/lan/catalyst6500/ios/12
> .2SX/configuration/guide/intrface.html#wp1041111
>
> http://www.cisco.com/en/US/partner/docs/ios/interface/command/reference/
> ir_l2.html#wp1030775
> http://www.cisco.com/en/US/partner/docs/ios/fundamentals/command/referen
> ce/cf_s3.html#wp1019645
>
> I think it should be in there.
>
I couldn't get to any of these, even taking into account the wrapped  
lines.


> It is likely that you have configured an SVI or a VLAN on the 6509  
> for 9216 already.
>
> If any VLAN that crosses the switchport is 9216, then you can't  
> adjust the MTU of the port to a value below 9216.
>
> Do a 'show vlan' and also check all the SVI's for an MTU higher than  
> 1504, then either reduce the MTU in those locations or I think you  
> could also restrict the large VLAN from being sent on the trunk



> 	Once you define the L2 MTU, packets on that VLAN can traverse any  
> ports on that VLAN up to that MTU, but if you need to route them and  
> retain the L2 MTU then the L3 SVI must have the same MTU.  You can  
> have the SVI different, say 1500, as long as you understand that the  
> packets will be fragged if larger than 1500, or dropped if the DF  
> bit is set.   If you have defined an SVI to a 9k+ MTU, that will  
> force the L2 interfaces on that vlan to be the same since they must  
> carry that size packets.


I finally sorted this out: If I was setting the MTU on a routed  
interface, then I could set the MTU to anything up to 9216B (using the  
mtu interface command), however, if I was trying to set the MTU an a  
switchported interface, then the mtu command would only allow me to  
change the MTU to the value defined in the global "system jumbmtu"  
command - this is a feature not a bug.


Thanks,

Michael
-- 

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






From p.mayers at imperial.ac.uk  Tue Jul 28 11:21:22 2009
From: p.mayers at imperial.ac.uk (Phil Mayers)
Date: Tue, 28 Jul 2009 16:21:22 +0100
Subject: [c-nsp] MTU wierdness
In-Reply-To: <73BADEC3-95BF-41A1-AC89-C86F7A951F07@manchester.ac.uk>
References: <8B081603-97F2-432C-892F-F97940220082@manchester.ac.uk>	<78C984F8939D424697B15E4B1C1BB3D7010AA7BC@xmb-ams-331.emea.cisco.com>
	<73BADEC3-95BF-41A1-AC89-C86F7A951F07@manchester.ac.uk>
Message-ID: <4A6F1772.80607@imperial.ac.uk>

Michael Robson wrote:
>> Michael,
>>
>> Check:
>> http://www.cisco.com/en/US/partner/docs/switches/lan/catalyst6500/ios/12
>> .2SX/configuration/guide/intrface.html#wp1041111
>>
>> http://www.cisco.com/en/US/partner/docs/ios/interface/command/reference/
>> ir_l2.html#wp1030775
>> http://www.cisco.com/en/US/partner/docs/ios/fundamentals/command/referen
>> ce/cf_s3.html#wp1019645
>>
>> I think it should be in there.
>>
> I couldn't get to any of these, even taking into account the wrapped  
> lines.

Replace "/partner/" with "/customer/"

From justin at justinshore.com  Tue Jul 28 12:56:48 2009
From: justin at justinshore.com (Justin Shore)
Date: Tue, 28 Jul 2009 11:56:48 -0500
Subject: [c-nsp] Humor: Cisco announces end of BGP
In-Reply-To: <5.1.0.14.2.20090728104929.051778f8@efes.iucc.ac.il>
References: <5.1.0.14.2.20090728104929.051778f8@efes.iucc.ac.il>
Message-ID: <4A6F2DD0.1060608@justinshore.com>

Hank Nussbacher wrote:
> I just got this product alert from Cisco:
> 
>> From: CiscoNotificationService at cisco.com
>> To: hank at efes.iucc.ac.il
>> Subject: Cisco Notification Alert -Alerts_Daily-07/28/2009 07:38 GMT
>>
>>
>> Cisco Notification Service Alert:
>>
>> Cisco Notification Alert -Alerts_Daily-07/28/2009 07:38 GMT
>>
>> End-of-Sale and End-of-Life Announcements-Border Gateway Protocol 
>> (BGP)-07/27/2009 08:44 GMT-07/28/2009 07:35 GMT
> 
> What exactly does Cisco have planned as a replacement?  :-)
> 
> -Hank

Full tables in IS-IS of course!


From mcgrath at fas.harvard.edu  Tue Jul 28 13:04:05 2009
From: mcgrath at fas.harvard.edu (Scott McGrath)
Date: Tue, 28 Jul 2009 13:04:05 -0400
Subject: [c-nsp] Humor: Cisco announces end of BGP
In-Reply-To: <4A6F2DD0.1060608@justinshore.com>
References: <5.1.0.14.2.20090728104929.051778f8@efes.iucc.ac.il>
	<4A6F2DD0.1060608@justinshore.com>
Message-ID: <4A6F2F85.4010705@fas.harvard.edu>

EIGRP...

Ducks and runs for cover

Justin Shore wrote:
> Hank Nussbacher wrote:
>   
>> I just got this product alert from Cisco:
>>
>>     
>>> From: CiscoNotificationService at cisco.com
>>> To: hank at efes.iucc.ac.il
>>> Subject: Cisco Notification Alert -Alerts_Daily-07/28/2009 07:38 GMT
>>>
>>>
>>> Cisco Notification Service Alert:
>>>
>>> Cisco Notification Alert -Alerts_Daily-07/28/2009 07:38 GMT
>>>
>>> End-of-Sale and End-of-Life Announcements-Border Gateway Protocol 
>>> (BGP)-07/27/2009 08:44 GMT-07/28/2009 07:35 GMT
>>>       
>> What exactly does Cisco have planned as a replacement?  :-)
>>
>> -Hank
>>     
>
> Full tables in IS-IS of course!
>
> _______________________________________________
> cisco-nsp mailing list  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  Tue Jul 28 14:20:39 2009
From: A.L.M.Buxey at lboro.ac.uk (Alan Buxey)
Date: Tue, 28 Jul 2009 19:20:39 +0100
Subject: [c-nsp] VPN clients on Cisco ASA
In-Reply-To: <B5CFB919B5EEF345969F51FAFE6360D50ADF31@GBLDCXMB10.emea.cbre.net>
References: <B5CFB919B5EEF345969F51FAFE6360D50ADF31@GBLDCXMB10.emea.cbre.net>
Message-ID: <20090728182039.GA10204@lboro.ac.uk>

Hi,

> Appreciate your help on this. Have tried the VPN Wizard and the CLI
> config from the below link but still no luck. The Cisco VPN client tries
> to connect and after for a few seconds shows Not Connected. I think it
> is an ACL issue but I am not 100% sure. I have attached the running
> config, could someone please take a look?

I'd stick a network sniffer outside the interface to see if your remote
client is getting as far as the ASA. the ACL on the outside interface looks
a little severe... I'd try it a little more 'open' to start with

alan

From psirt at cisco.com  Tue Jul 28 15:15:00 2009
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Tue, 28 Jul 2009 19:15:00 -0000
Subject: [c-nsp] Cisco Security Advisory: Active Template Library (ATL)
	Vulnerability
Message-ID: <20090728.atl@psirt.cisco.com>

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

Cisco Security Advisory: Active Template Library (ATL) Vulnerability

Advisory ID: cisco-sa-20090728-activex

http://www.cisco.com/warp/public/707/cisco-sa-20090728-activex.shtml

Revision 1.0

For Public Release 2009 July 28 1800 UTC (GMT)

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

Summary
=======

Certain Cisco products that use Microsoft Active Template Libraries
(ATL) and headers may be vulnerable to remote code execution. In some
instances, the vulnerability may be exploited against Microsoft
Internet Explorer to perform kill bit bypass. In order to exploit this
vulnerability, an attacker must convince a user to visit a malicious
web site.

Cisco will release free software updates for products that are
affected by this vulnerability. Workarounds that mitigate this
vulnerability are available.

This advisory is posted at

http://www.cisco.com/warp/public/707/cisco-sa-20090728-activex.shtml

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

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

The following products are affected by this vulnerability:

  * Cisco Unity 4.x, 5x., and 7.x

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

The following Cisco products are not known to be affected by this
vulnerability:

  * Cisco AnyConnect VPN Client
  * Cisco Adaptive Security Device Manager (ASDM)
  * Cisco Building Broadband Service Manager (BBSM)
  * Cisco Catalyst Operating System (Catalyst OS)
  * Cisco Computer Telephony Integration Object Server (CTI)
  * Cisco IOS Software
  * Cisco IP/TV
  * Cisco Meetingplace
  * Cisco Mobile Wireless Fault Mediator (MWFM)
  * Cisco NAC Appliance (formerly Cisco Clean Access)
  * Cisco Secure Access Control Server (ACS)
  * Cisco Secure Desktop
  * Cisco Security Agent
  * Cisco Security Monitoring, Analysis and Response System (MARS)
  * Cisco SSL VPN Client (SVC)
  * Cisco Unified Contact Center Express (Unified CCX)
  * Cisco Video Surveillance Media Server (VSMS)
  * CiscoWorks LAN Management Solution (LMS)
  * WebEx

Details
=======

Microsoft has identified vulnerabilities in the Active Template
Library (ATL) headers that are shipped with the Software Development
Kit (SDK) for Microsoft Windows systems and used in Cisco products.
In general, this vulnerability, if exposed by an ActiveX control,
could lead to remote code execution on a client's system.

For complete details, please review the Microsoft Security Bulletin
at: http://www.microsoft.com/technet/security/Bulletin/MS09-035.mspx

The following Bug IDs have been filed for Cisco Products affected by
this vulnerability:

  * CSCta71728 ( registered customers only)

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

CSCta71728 - Vulnerability in the ActiveX headers used in Unity
+-----------------------------------------------------

CVSS Base Score - 9.3

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

CVSS Temporal Score - 8.4

        Exploitability           - Proof-of-Concept
        Remediation Level        - Unavailable
        Report Confidence        - Confirmed

Impact
======

Successful exploitation of the vulnerability may result in remote
code execution.

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.

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

General information on ActiveX attacks and mitigation techniques can
be found at the following link:

http://www.cisco.com/web/about/security/intelligence/actX-ALPI_amiddleton.html

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

Cisco will release 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 malicious use of the
vulnerability described in this advisory against any Cisco product.

Status of this Notice: INTERIM
==============================

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. CISCO EXPECTS TO UPDATE THIS DOCUMENT AS NEW
INFORMATION BECOMES AVAILABLE.

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-20090728-activex.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-July-28 | 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.

? 2008 - 2009 Cisco Systems, Inc. All rights reserved. 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFKb0cs86n/Gc8U/uARAiXHAJ9v3nVQitvH82EmPF78gwPP3QsLXACfZN3V
T1SANu4iTjiY8frbP7xZZJw=
=U3UB
-----END PGP SIGNATURE-----

From Max.Pierson at mycallis.com  Tue Jul 28 15:13:19 2009
From: Max.Pierson at mycallis.com (Max Pierson)
Date: Tue, 28 Jul 2009 14:13:19 -0500
Subject: [c-nsp]  PBR + NAT route-map issue
Message-ID: <790983A074292148A785C514F2FAC26D932FAB@mailhost.myallpage.com>

Hi All,

Im kinda new to the list and hope someone can help me an issue. I'm
trying to do some PBR with nat and am having an issue understanding how
the route-maps apply in combination with the nat process. I would like
to send my Phone based vlan traffic out of the T1 and the Data traffic
out of the DSL. IF possible, I'd like them to failover for each other
(which makes the config even more confusing). I have the ability to
route a few/30's to this router over the dsl or the t1. Any help with
the nat statements and route-maps would be greatly appreciated. Relevent
config so far is posted. The 64.x.x.x and 208.x.x.x are my phone
servers. Thanks for any help!!!

2651-XM 
12.4.(23)


ip dhcp excluded-address 172.16.0.1 172.16.0.99
ip dhcp excluded-address 192.168.1.1 192.168.1.100
ip dhcp excluded-address 192.168.1.113
!
ip dhcp pool PHONES
   network 172.16.0.0 255.255.255.0
   default-router 172.16.0.1
   dns-server 208.66.61.109 208.66.61.110
   option 150 ip 208.83.93.113
   lease 3
!
ip dhcp pool Computers
   network 192.168.1.0 255.255.255.0
   default-router 192.168.1.1
   dns-server 208.66.61.109 208.66.61.110
   lease 3
!
!

!
track 1 interface Dialer0 ip routing
 delay up 15
!
interface FastEthernet0/0
 no ip address
 duplex auto
 speed auto
!
interface FastEthernet0/0.150
 description To Phones
 encapsulation dot1Q 150
 ip address 172.16.0.1 255.255.255.0
 ip nat inside
!
interface FastEthernet0/0.200
 description Computers
 encapsulation dot1Q 200
 ip address 192.168.1.1 255.255.255.0
 ip nat inside
!
interface Serial0/0
 ip address 74.113.88.62 255.255.255.252
 ip nat outside
 priority-group 1
!
interface ATM0/1
 no ip address
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 ip route-cache flow
 shutdown
 no atm ilmi-keepalive
 dsl operating-mode auto
!
interface ATM0/1.1 point-to-point
 pvc 1/100
  pppoe-client dial-pool-number 1
 !
!
interface FastEthernet0/1
 no ip address
 shutdown
 duplex auto
 speed auto
!
interface Dialer0
 ip address negotiated
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 ip nat outside
 encapsulation ppp
 ip route-cache flow
 ip tcp adjust-mss 1412
 dialer pool 1
 dialer-group 1
 no cdp enable
 ppp authentication chap pap callin
 ppp chap hostname rubenstein at authcall.net
 ppp chap password 0 xxxxxxxx
 ppp pap sent-username rubenstein at authcall.net password 0 xxxxxxxxx
!
ip route 0.0.0.0 0.0.0.0 Dialer0 track 1
ip route 0.0.0.0 0.0.0.0 74.113.88.61 254
ip route 64.193.113.0 255.255.255.0 74.113.88.61 101
ip route 64.193.113.0 255.255.255.0 Dialer0 120
ip route 208.83.93.0 255.255.252.0 74.113.88.61 101
ip route 208.83.93.0 255.255.252.0 Dialer0 120
!


no ip http server

ip nat inside source list 10 interface Serial0/0 overload

access-list 10 permit 192.168.1.0 0.0.0.255
access-list 10 permit 172.16.0.0 0.0.0.255

From jarod125 at gmail.com  Tue Jul 28 16:17:00 2009
From: jarod125 at gmail.com (Gabriel)
Date: Tue, 28 Jul 2009 23:17:00 +0300
Subject: [c-nsp] 7206VXRG2 performance question
In-Reply-To: <4A6BCAB1.60304@cisco.com>
References: <4cd59bf50907251429p2d695ebdme4e1d9ebcb02531c@mail.gmail.com>
	<4A6BCAB1.60304@cisco.com>
Message-ID: <4cd59bf50907281317q4910f77drcbb1e6053b8e7ff8@mail.gmail.com>

I'll try to provide more details regarding the desired setup (opinions
in favour/against it are welcomed).

As I said, roughly half of the spokes will connect to hub1 while the
other half will connect to hub2. As all servers are in hub1, spokes
connecting to hub2 will reach the servers via a dedicated link between
hub1 and hub2. Hub2 is also a DR site, so this link will also be used
for replicating some of hub1's content there.

Regarding connectivity, spokes will connect to the hubs via two
providers (P1 an P2). The connections will use the provider's internal
network, not over the Internet. So, a spoke will have one tunnel (T1)
to hub1 via P1, one tunnel (T2) to hub1 via P2, one tunnel (T3) to
hub2 via P1 and one tunnel (T4) to hub2 via P2. Depending on which hub
the spoke will connect to, either T1 and T2 will be used (per flow
load balancing) or T3 and T4. Should a hub become unavailable, the
spokes connected to it will failover to the other one, so either hub
must be able to handle all spokes simultaneously.

Regarding bandwidth, I doubt it will exceed 10 mbit/s per provider in
the hubs. Spokes will probably have 128kbps and 256kbps per provider.

I read a bit about VTIs and the most appropriate setup seems to be
with static VTIs on the spokes and dynamic VTIs on the hubs. However,
there are some notes in the document[1] saying that routing with DVTIs
is not supported and SVTI remote to DVTI interfaces are not supported
(I dont know what this means).

Spokes will indeed have static link speeds (values mentioned above are
CIR). If I understand correctly the link you gave, I would need two
nhrp groups (one for 128kbps and the other one for 256kbps) which I
will further divide as required. Besides that, we'll also need shaping
to limit the outgoing physical interface to 10 mbps (or whatever we'll
get from the provider). The spokes would then be configured with the
proper nhrp-group.

So, as I said in the original message, my main concern is whether or
not the 7206 will be able to handle this, but, from the replies I got,
I understand it shouldn't be a problem.

Gabriel

[1] http://www.cisco.com/en/US/docs/ios/security/configuration/guide/sec_ipsec_virt_tunnl.html#wp1110852

On Sun, Jul 26, 2009 at 6:17 AM, Rodney Dunn<rodunn at cisco.com> wrote:
> For those low rates a 7206VXR with a NPE-G2 would be a plenty.
>
> You should look at dynamic VTI's I think it is to get "per spoke" QOS.
>
> You don't need an external box especially if your link speeds at the spokes
> are static.
>
> There are different ways to do "per spoke" QOS but it's a bit more complex
> with dmvpn.
>
> http://www.cisco.com/en/US/docs/ios/security/configuration/guide/sec_per_tunnel_qos.html
>
> Rodney
>
>
>
> Gabriel wrote:
>>
>> Hi all,
>>
>> the company I work for is involved in a WAN redesing process, so we
>> got in touch with a few Cisco partners to help us. We're considering a
>> dual-hub and spoke topology (about 100 spokes, more in the future)
>> with both hubs active (half of the spokes will connect to one hub, the
>> other half to the other).
>>
>> As I said, we contacted some Cisco partners (as we don't have the
>> necessary expertise to do this on our own) and one of them recommended
>> that, besides using the 7206 (with NPE-G2 and VSA) as the hub router,
>> we should also get a SCE1010 box to handle the QoS.
>>
>> One of the aspects I'd like your feedback on is whether this SCE box
>> is required or not (from the docs and design guides I read, it was
>> only present in SP networks). I'll try to give more details (please
>> let me know if they are relevant or not and what others have I
>> missed):
>>
>> - DMVPN (although one tunnel/branch was also suggested) over IPSec
>> - spokes connect to hubs via two providers (with per-flow load-balancing)
>> - hub bandwith will probably not exceed 10 mbit/provider
>> - spoke bandwith will be 256kbps/provider for roughly half of the
>> spokes and 128kbps/provider for the other half
>> - EIGRP as routing protocol
>> - no VoIP at the moment, but it could appear sometime in the future
>>
>> Traffic is not latency-sensitive (as I said, no VoIP yet) and will be
>> split into four QoS classes (in the future, others might appear).
>>
>> So, based on the above, can you comment on the capabilities of the
>> 7206 alone to handle everything without issues?
>>
>> Thanks,
>> Gabriel
>> _______________________________________________
>> cisco-nsp mailing list ?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  Tue Jul 28 16:32:48 2009
From: ip at ioshints.info (Ivan Pepelnjak)
Date: Tue, 28 Jul 2009 22:32:48 +0200
Subject: [c-nsp] Humor: Cisco announces end of BGP
In-Reply-To: <4A6F2DD0.1060608@justinshore.com>
References: <5.1.0.14.2.20090728104929.051778f8@efes.iucc.ac.il>
	<4A6F2DD0.1060608@justinshore.com>
Message-ID: <005901ca0fc2$939d6bc0$0a00000a@nil.si>

Gentlemen, you forgot about IDRP (http://www.javvin.com/protocolIDRP.html).
You can already transport IPv4 and IPv6 over CLNS, this is the next logical
step :D 

> -----Original Message-----
> From: Justin Shore [mailto:justin at justinshore.com] 
> Sent: Tuesday, July 28, 2009 6:57 PM
> To: Hank Nussbacher
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] Humor: Cisco announces end of BGP
> 
> Hank Nussbacher wrote:
> > I just got this product alert from Cisco:
> > 
> >> From: CiscoNotificationService at cisco.com
> >> To: hank at efes.iucc.ac.il
> >> Subject: Cisco Notification Alert -Alerts_Daily-07/28/2009 
> 07:38 GMT
> >>
> >>
> >> Cisco Notification Service Alert:
> >>
> >> Cisco Notification Alert -Alerts_Daily-07/28/2009 07:38 GMT
> >>
> >> End-of-Sale and End-of-Life Announcements-Border Gateway Protocol
> >> (BGP)-07/27/2009 08:44 GMT-07/28/2009 07:35 GMT
> > 
> > What exactly does Cisco have planned as a replacement?  :-)
> > 
> > -Hank
> 
> Full tables in IS-IS of course!
> 
> 
> 


From gustavo at nexthop.com.br  Tue Jul 28 16:47:36 2009
From: gustavo at nexthop.com.br (Gustavo Rodrigues Ramos)
Date: Tue, 28 Jul 2009 17:47:36 -0300
Subject: [c-nsp] PBR + NAT route-map issue
In-Reply-To: <790983A074292148A785C514F2FAC26D932FAB@mailhost.myallpage.com>
References: <790983A074292148A785C514F2FAC26D932FAB@mailhost.myallpage.com>
Message-ID: <73d1f88a0907281347x76da333bx95f1c6714af5a1d9@mail.gmail.com>

Hi Max,

You might want to combine pbr with object tracking (and add some nat
statements to this mix). To make a long story short, you can configure
ip sla and object tracking to monitor your gateway(s) availability and
use a route-map with the "verify-availability" statement to select the
preferred/available route. I've described it in my blog [1] a couple
of months ago. Sorry, it's still in portuguese only :( ...  Well,
since the configs have been written in a universal language (aka ios
commands) there should be no problem trying to figure out the
portuguese part (or use the google translator to do the trick). :)

[1] http://blog.nexthop.com.br/2009/02/um-roteador-dois-provedores-e-alguma.html

Gustavo.


On Tue, Jul 28, 2009 at 4:13 PM, Max Pierson<Max.Pierson at mycallis.com> wrote:
> Hi All,
>
> Im kinda new to the list and hope someone can help me an issue. I'm
> trying to do some PBR with nat and am having an issue understanding how
> the route-maps apply in combination with the nat process. I would like
> to send my Phone based vlan traffic out of the T1 and the Data traffic
> out of the DSL. IF possible, I'd like them to failover for each other
> (which makes the config even more confusing). I have the ability to
> route a few/30's to this router over the dsl or the t1. Any help with
> the nat statements and route-maps would be greatly appreciated. Relevent
> config so far is posted. The 64.x.x.x and 208.x.x.x are my phone
> servers. Thanks for any help!!!
>
> 2651-XM
> 12.4.(23)
>
>
> ip dhcp excluded-address 172.16.0.1 172.16.0.99
> ip dhcp excluded-address 192.168.1.1 192.168.1.100
> ip dhcp excluded-address 192.168.1.113
> !
> ip dhcp pool PHONES
> ? network 172.16.0.0 255.255.255.0
> ? default-router 172.16.0.1
> ? dns-server 208.66.61.109 208.66.61.110
> ? option 150 ip 208.83.93.113
> ? lease 3
> !
> ip dhcp pool Computers
> ? network 192.168.1.0 255.255.255.0
> ? default-router 192.168.1.1
> ? dns-server 208.66.61.109 208.66.61.110
> ? lease 3
> !
> !
>
> !
> track 1 interface Dialer0 ip routing
> ?delay up 15
> !
> interface FastEthernet0/0
> ?no ip address
> ?duplex auto
> ?speed auto
> !
> interface FastEthernet0/0.150
> ?description To Phones
> ?encapsulation dot1Q 150
> ?ip address 172.16.0.1 255.255.255.0
> ?ip nat inside
> !
> interface FastEthernet0/0.200
> ?description Computers
> ?encapsulation dot1Q 200
> ?ip address 192.168.1.1 255.255.255.0
> ?ip nat inside
> !
> interface Serial0/0
> ?ip address 74.113.88.62 255.255.255.252
> ?ip nat outside
> ?priority-group 1
> !
> interface ATM0/1
> ?no ip address
> ?no ip redirects
> ?no ip unreachables
> ?no ip proxy-arp
> ?ip route-cache flow
> ?shutdown
> ?no atm ilmi-keepalive
> ?dsl operating-mode auto
> !
> interface ATM0/1.1 point-to-point
> ?pvc 1/100
> ?pppoe-client dial-pool-number 1
> ?!
> !
> interface FastEthernet0/1
> ?no ip address
> ?shutdown
> ?duplex auto
> ?speed auto
> !
> interface Dialer0
> ?ip address negotiated
> ?no ip redirects
> ?no ip unreachables
> ?no ip proxy-arp
> ?ip nat outside
> ?encapsulation ppp
> ?ip route-cache flow
> ?ip tcp adjust-mss 1412
> ?dialer pool 1
> ?dialer-group 1
> ?no cdp enable
> ?ppp authentication chap pap callin
> ?ppp chap hostname rubenstein at authcall.net
> ?ppp chap password 0 xxxxxxxx
> ?ppp pap sent-username rubenstein at authcall.net password 0 xxxxxxxxx
> !
> ip route 0.0.0.0 0.0.0.0 Dialer0 track 1
> ip route 0.0.0.0 0.0.0.0 74.113.88.61 254
> ip route 64.193.113.0 255.255.255.0 74.113.88.61 101
> ip route 64.193.113.0 255.255.255.0 Dialer0 120
> ip route 208.83.93.0 255.255.252.0 74.113.88.61 101
> ip route 208.83.93.0 255.255.252.0 Dialer0 120
> !
>
>
> no ip http server
>
> ip nat inside source list 10 interface Serial0/0 overload
>
> access-list 10 permit 192.168.1.0 0.0.0.255
> access-list 10 permit 172.16.0.0 0.0.0.255
> _______________________________________________
> cisco-nsp mailing list ?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 Jul 28 16:50:50 2009
From: luan at netcraftsmen.net (Luan Nguyen)
Date: Tue, 28 Jul 2009 16:50:50 -0400
Subject: [c-nsp] 7206VXRG2 performance question
In-Reply-To: <4cd59bf50907281317q4910f77drcbb1e6053b8e7ff8@mail.gmail.com>
References: <4cd59bf50907251429p2d695ebdme4e1d9ebcb02531c@mail.gmail.com>	<4A6BCAB1.60304@cisco.com>
	<4cd59bf50907281317q4910f77drcbb1e6053b8e7ff8@mail.gmail.com>
Message-ID: <054701ca0fc5$17643ea0$462cbbe0$@net>

NPEG2 and VAM+ could do 60Mbps VPN throughput.
NPEG2 and VSA could do 160Mbps VPN throughput.  
These are with 500 bytes packet.
If you need more throughput, might want to go with the ASR1002.  Not that
much more expensive than the 7206VXR NPEG2/VSA combo.
Regarding design, you should go with DMVPN/EIGRP.  You could do direct
spoke-spoke communication as well.

Regards,

-------------------------------------
Luan Nguyen
Chesapeake NetCraftsmen, LLC.
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 Gabriel
Sent: Tuesday, July 28, 2009 4:17 PM
To: rodunn at cisco.com
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] 7206VXRG2 performance question

I'll try to provide more details regarding the desired setup (opinions
in favour/against it are welcomed).

As I said, roughly half of the spokes will connect to hub1 while the
other half will connect to hub2. As all servers are in hub1, spokes
connecting to hub2 will reach the servers via a dedicated link between
hub1 and hub2. Hub2 is also a DR site, so this link will also be used
for replicating some of hub1's content there.

Regarding connectivity, spokes will connect to the hubs via two
providers (P1 an P2). The connections will use the provider's internal
network, not over the Internet. So, a spoke will have one tunnel (T1)
to hub1 via P1, one tunnel (T2) to hub1 via P2, one tunnel (T3) to
hub2 via P1 and one tunnel (T4) to hub2 via P2. Depending on which hub
the spoke will connect to, either T1 and T2 will be used (per flow
load balancing) or T3 and T4. Should a hub become unavailable, the
spokes connected to it will failover to the other one, so either hub
must be able to handle all spokes simultaneously.

Regarding bandwidth, I doubt it will exceed 10 mbit/s per provider in
the hubs. Spokes will probably have 128kbps and 256kbps per provider.

I read a bit about VTIs and the most appropriate setup seems to be
with static VTIs on the spokes and dynamic VTIs on the hubs. However,
there are some notes in the document[1] saying that routing with DVTIs
is not supported and SVTI remote to DVTI interfaces are not supported
(I dont know what this means).

Spokes will indeed have static link speeds (values mentioned above are
CIR). If I understand correctly the link you gave, I would need two
nhrp groups (one for 128kbps and the other one for 256kbps) which I
will further divide as required. Besides that, we'll also need shaping
to limit the outgoing physical interface to 10 mbps (or whatever we'll
get from the provider). The spokes would then be configured with the
proper nhrp-group.

So, as I said in the original message, my main concern is whether or
not the 7206 will be able to handle this, but, from the replies I got,
I understand it shouldn't be a problem.

Gabriel

[1]
http://www.cisco.com/en/US/docs/ios/security/configuration/guide/sec_ipsec_v
irt_tunnl.html#wp1110852

On Sun, Jul 26, 2009 at 6:17 AM, Rodney Dunn<rodunn at cisco.com> wrote:
> For those low rates a 7206VXR with a NPE-G2 would be a plenty.
>
> You should look at dynamic VTI's I think it is to get "per spoke" QOS.
>
> You don't need an external box especially if your link speeds at the
spokes
> are static.
>
> There are different ways to do "per spoke" QOS but it's a bit more complex
> with dmvpn.
>
>
http://www.cisco.com/en/US/docs/ios/security/configuration/guide/sec_per_tun
nel_qos.html
>
> Rodney
>
>
>
> Gabriel wrote:
>>
>> Hi all,
>>
>> the company I work for is involved in a WAN redesing process, so we
>> got in touch with a few Cisco partners to help us. We're considering a
>> dual-hub and spoke topology (about 100 spokes, more in the future)
>> with both hubs active (half of the spokes will connect to one hub, the
>> other half to the other).
>>
>> As I said, we contacted some Cisco partners (as we don't have the
>> necessary expertise to do this on our own) and one of them recommended
>> that, besides using the 7206 (with NPE-G2 and VSA) as the hub router,
>> we should also get a SCE1010 box to handle the QoS.
>>
>> One of the aspects I'd like your feedback on is whether this SCE box
>> is required or not (from the docs and design guides I read, it was
>> only present in SP networks). I'll try to give more details (please
>> let me know if they are relevant or not and what others have I
>> missed):
>>
>> - DMVPN (although one tunnel/branch was also suggested) over IPSec
>> - spokes connect to hubs via two providers (with per-flow load-balancing)
>> - hub bandwith will probably not exceed 10 mbit/provider
>> - spoke bandwith will be 256kbps/provider for roughly half of the
>> spokes and 128kbps/provider for the other half
>> - EIGRP as routing protocol
>> - no VoIP at the moment, but it could appear sometime in the future
>>
>> Traffic is not latency-sensitive (as I said, no VoIP yet) and will be
>> split into four QoS classes (in the future, others might appear).
>>
>> So, based on the above, can you comment on the capabilities of the
>> 7206 alone to handle everything without issues?
>>
>> Thanks,
>> Gabriel
>> _______________________________________________
>> cisco-nsp mailing 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  Tue Jul 28 16:59:46 2009
From: justin at justinshore.com (Justin Shore)
Date: Tue, 28 Jul 2009 15:59:46 -0500
Subject: [c-nsp] Humor: Cisco announces end of BGP
In-Reply-To: <005901ca0fc2$939d6bc0$0a00000a@nil.si>
References: <5.1.0.14.2.20090728104929.051778f8@efes.iucc.ac.il>
	<4A6F2DD0.1060608@justinshore.com>
	<005901ca0fc2$939d6bc0$0a00000a@nil.si>
Message-ID: <4A6F66C2.1080400@justinshore.com>

According to a Pannaway SE who visited us a few years ago, he'd seen SPs 
many times our size who used static routes for everything.  He said we 
weren't big enough to need a routing protocol.  Of course he also said 
that our pipes weren't saturated so we didn't need QoS and that IPv6 was 
just a fad and would never be adopted in the US.

*sigh*


Ivan Pepelnjak wrote:
> Gentlemen, you forgot about IDRP (http://www.javvin.com/protocolIDRP.html).
> You can already transport IPv4 and IPv6 over CLNS, this is the next logical
> step :D 


From jeff-kell at utc.edu  Tue Jul 28 17:14:29 2009
From: jeff-kell at utc.edu (Jeff Kell)
Date: Tue, 28 Jul 2009 17:14:29 -0400
Subject: [c-nsp] Humor: Cisco announces end of BGP
In-Reply-To: <4A6F66C2.1080400@justinshore.com>
References: <5.1.0.14.2.20090728104929.051778f8@efes.iucc.ac.il>	<4A6F2DD0.1060608@justinshore.com>	<005901ca0fc2$939d6bc0$0a00000a@nil.si>
	<4A6F66C2.1080400@justinshore.com>
Message-ID: <4A6F6A35.2070504@utc.edu>

Justin Shore wrote:
> According to a Pannaway SE who visited us a few years ago, he'd seen
> SPs many times our size who used static routes for everything.  

We could encapsulate it all in IPX, and yank those Netware servers out
of surplus to handle the routing.  Bring back RIPs and SAPs...

Or we could encode the AS numbers into Appletalk cable-ranges.  Yeah,
that's the ticket...

Jeff  :-)

From mcgrath at fas.harvard.edu  Tue Jul 28 17:20:17 2009
From: mcgrath at fas.harvard.edu (Scott McGrath)
Date: Tue, 28 Jul 2009 17:20:17 -0400
Subject: [c-nsp] Humor: Cisco announces end of BGP
In-Reply-To: <4A6F6A35.2070504@utc.edu>
References: <5.1.0.14.2.20090728104929.051778f8@efes.iucc.ac.il>	<4A6F2DD0.1060608@justinshore.com>	<005901ca0fc2$939d6bc0$0a00000a@nil.si>	<4A6F66C2.1080400@justinshore.com>
	<4A6F6A35.2070504@utc.edu>
Message-ID: <4A6F6B91.6080102@fas.harvard.edu>

You are forgetting NLSP (Novell Link State Protocol) designed to 
eliminate RIP/SAP adverts But IPX had a lot of advantages large address 
space,  local network autoconfiguration, anti-spoofing, service 
autolocation



Jeff Kell wrote:
> Justin Shore wrote:
>   
>> According to a Pannaway SE who visited us a few years ago, he'd seen
>> SPs many times our size who used static routes for everything.  
>>     
>
> We could encapsulate it all in IPX, and yank those Netware servers out
> of surplus to handle the routing.  Bring back RIPs and SAPs...
>
> Or we could encode the AS numbers into Appletalk cable-ranges.  Yeah,
> that's the ticket...
>
> 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 Grzegorz at Janoszka.pl  Tue Jul 28 17:15:21 2009
From: Grzegorz at Janoszka.pl (Grzegorz Janoszka)
Date: Tue, 28 Jul 2009 23:15:21 +0200
Subject: [c-nsp] Freezing counters at 6500
In-Reply-To: <4A6F6A2D.40101@Janoszka.pl>
References: <4A6F6A2D.40101@Janoszka.pl>
Message-ID: <4A6F6A69.9080902@Janoszka.pl>

Grzegorz Janoszka wrote:
> We have several 6500's, some of them heavily loaded. We use snmp to 
> graph traffic on all interfaces - just the simplest solution. Since some 
> time we have had an issue with the interface counters. When the CPU box 
> is really loaded (usually synchronization of BGP sessions), the counters 
> just freeze. The important thing is that only the displaying freezes, 
> the counters are still counting. Both snmp and 'show interface' data is 
> frozen and does not update for various time - from 30 seconds to 3-4 
> minutes. As the result we have spikes on graphs - there is always spike 
> down, when snmp gives frozen data from the past, and after that spike 
> up, when the counters unlock and start displaying correct data.

Just forgot to add - we have this issue with SXF14, 15, 16 and SXI1.

-- 
Grzegorz Janoszka

From Grzegorz at Janoszka.pl  Tue Jul 28 17:14:21 2009
From: Grzegorz at Janoszka.pl (Grzegorz Janoszka)
Date: Tue, 28 Jul 2009 23:14:21 +0200
Subject: [c-nsp] Freezing counters at 6500
Message-ID: <4A6F6A2D.40101@Janoszka.pl>


Hi,

We have several 6500's, some of them heavily loaded. We use snmp to 
graph traffic on all interfaces - just the simplest solution. Since some 
time we have had an issue with the interface counters. When the CPU box 
is really loaded (usually synchronization of BGP sessions), the counters 
just freeze. The important thing is that only the displaying freezes, 
the counters are still counting. Both snmp and 'show interface' data is 
frozen and does not update for various time - from 30 seconds to 3-4 
minutes. As the result we have spikes on graphs - there is always spike 
down, when snmp gives frozen data from the past, and after that spike 
up, when the counters unlock and start displaying correct data.

Have you had similar problems? It is not the big issue, only the graphs 
look not so nice with the rows of spikes down/up. If there is a simple 
solution to the problem we would like to know it.

Kind regards,

-- 
Grzegorz Janoszka

From randy_94108 at yahoo.com  Tue Jul 28 17:12:31 2009
From: randy_94108 at yahoo.com (Randy)
Date: Tue, 28 Jul 2009 14:12:31 -0700 (PDT)
Subject: [c-nsp] VPN clients on Cisco ASA
Message-ID: <23002.1477.qm@web80502.mail.mud.yahoo.com>

Hello Kiran,
1) you are using upper-case and lower case "o" in your crypto map -can't do that.
relevant changes (within parentheses)below-
?
crypto dynamic-map outside_dyn_map 10 set transform-set ESP-3DES-SHA
crypto dynamic-map outside_dyn_map 10 set security-association lifetime seconds 288000
crypto dynamic-map O(o)utside_dyn_map 10 set reverse-route
crypto dynamic-map SYSTEM_DEFAULT_CRYPTO_MAP 65535 set pfs
crypto dynamic-map SYSTEM_DEFAULT_CRYPTO_MAP 65535 set transform-set ESP-AES-128-SHA ESP-AES-128-MD5 ESP-AES-192-SHA ESP-AES-192-MD5 ESP-AES-256-SHA ESP-AES-256-MD5 ESP-3DES-SHA ESP-3DES-MD5 ESP-DES-SHA ESP-DES-MD5
crypto map O(o)utside_map 10 ipsec-isakmp dynamic O(o)utside_dyn_map
crypto map outside_map 65535 ipsec-isakmp dynamic SYSTEM_DEFAULT_CRYPTO_MAP
crypto map outside_map interface outside
crypto isakmp enable outside
?
2) keyword "any" in split-tunnel acl effectively disables split-tunneling. Instead, specify subnets for which traffic needs to be encrypted.
?
3) crypto isakmp policy 1
?authentication pre-share
?encryption 3des
?hash sha
?group 2 (make sure the vpn client supports D-H group 2)
?lifetime 43200
?
4) make sure isakmp identity is not 'hostname' use 'address' instead. Also disable DPD(no isakmp keepalive. NAT-T should be enabled. If you are using udp/tcp wrappers, ensure udp/tcp ports match on both ends.
?
5) the outside acl is wide-open(with permit ip any any) Recommend locking it down. for vpn, allow tcp 50 and udp 500 to the outside int from any unless sysopt conn ipsec permit is enabled.
?
6) Probable would be a good idea to replace ip's with x.x.x.x when posting configs on a public site.
?
regards,
./Randy
?
?
?
?
?
?
?
?
?
?
?
?
--- On Tue, 7/28/09, Oddiraju, Kiran @ London SMC <Kiran.Oddiraju at cbre.com> wrote:


From: Oddiraju, Kiran @ London SMC <Kiran.Oddiraju at cbre.com>
Subject: Re: [c-nsp] VPN clients on Cisco ASA
To: "Ryan West" <rwest at zyedge.com>
Cc: cisco-nsp at puck.nether.net
Date: Tuesday, July 28, 2009, 7:01 AM


Hi Guys,

Appreciate your help on this. Have tried the VPN Wizard and the CLI
config from the below link but still no luck. The Cisco VPN client tries
to connect and after for a few seconds shows Not Connected. I think it
is an ACL issue but I am not 100% sure. I have attached the running
config, could someone please take a look?

Many thanks,
Kiran

-----Original Message-----
From: Ryan West [mailto:rwest at zyedge.com]
Sent: 27 July 2009 13:57
To: Oddiraju, Kiran @ London SMC; cisco-nsp at puck.nether.net
Subject: RE: VPN clients on Cisco ASA

Hello again Kiran,

I think you should take a quick read through the following link.? You
can use the ASDM Remote Access VPN wizard to configure most of the
settings and if you're interested in doing it via CLI, that's also an
option.

http://www.cisco.com/en/US/products/ps6120/products_configuration_exampl
e09186a008060f25c.shtml

In particular, the options you have asked are all covered in the doc
except for split-tunneling, at least the associated output in CLI.
You'll want to configure that inside the group policy you create from
the link above.? Here is an example:

group-policy mygrouppolicyname attributes? split-tunnel-policy
tunnelspecified? split-tunnel-network-list value <ACL Here>

Let me know how it works out for you.

-ryan

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Oddiraju, Kiran
@ London SMC
Sent: Monday, July 27, 2009 8:33 AM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] VPN clients on Cisco ASA

Hi List,



Cisco ASA 5505

Cisco VPN Client 5.0

ASA External IP: 80.90.100.117 /29

Internal range: 192.168.0.0 /24



I am new to Cisco ASA world and have been struggling to configure my
5505 to accept VPN connections from external hosts. I want to allocate
IP address dynamically, allow access to certain subnets and allow
internet access thru their local connection. Can someone please post me
a sample ASA config?



Thanks guys



Regards,

Kiran


CB Richard Ellis Limited, Registered Office: St Martin's Court, 10
Paternoster Row, London, EC4M 7HP, registered in England and Wales No.
3536032. 
Regulated by the RICS and an appointed representative of CB Richard
Ellis Indirect Investment Services Limited which is authorised and
regulated by the Financial Services Authority.

This communication is from CB Richard Ellis Limited or one of its
associated/subsidiary companies. This communication contains information
which is confidential and may be privileged. If you are not the intended
recipient, please contact the sender immediately. Any use of its
contents is strictly prohibited and you must not copy, send or disclose
it, or rely on its contents in any way whatsoever. 
Reasonable care has been taken to ensure that this communication (and
any attachments or hyperlinks contained within it) is free from computer
viruses. 
No responsibility is accepted by CB Richard Ellis Limited or its
associated/subsidiary companies and the recipient should carry out any
appropriate virus checks.

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

CB Richard Ellis Limited, Registered Office: St Martin's Court, 
10 Paternoster Row, London, EC4M 7HP, registered in England and Wales No. 3536032. 
Regulated by the RICS and an appointed representative of CB Richard Ellis 
Indirect Investment Services Limited which is authorised and regulated by the Financial Services Authority.

This communication is from CB Richard Ellis Limited or one of its 
associated/subsidiary companies. This communication contains information 
which is confidential and may be privileged. If you are not the intended recipient, 
please contact the sender immediately. Any use of its contents is strictly prohibited 
and you must not copy, send or disclose it, or rely on its contents in any way whatsoever. 
Reasonable care has been taken to ensure that this communication 
(and any attachments or hyperlinks contained within it) is free from computer viruses. 
No responsibility is accepted by CB Richard Ellis Limited or its associated/subsidiary 
companies and the recipient should carry out any appropriate virus checks.

-----Inline Attachment Follows-----


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

From td_miles at yahoo.com  Tue Jul 28 19:21:33 2009
From: td_miles at yahoo.com (Tony)
Date: Tue, 28 Jul 2009 16:21:33 -0700 (PDT)
Subject: [c-nsp] Freezing counters at 6500
In-Reply-To: <4A6F6A2D.40101@Janoszka.pl>
Message-ID: <717376.90194.qm@web110106.mail.gq1.yahoo.com>

Depending on what software you're using to monitor with you might look into whether it supports "filtering" values retrieved via SNMP to within a sane range that you configure ? 

Eg. On an E1 interface the maximum should only ever be 2048Kbps so it is ok to discard anything with a value greater than that as being a wrong value. To be safe usually we would configure it a little above the theoretical maximum, so maybe 2500Kbps in this example.

The solution you are looking for is on the SNMP software side, not the router.


regards,
Tony


--- On Wed, 29/7/09, Grzegorz Janoszka <Grzegorz at Janoszka.pl> wrote:

> From: Grzegorz Janoszka <Grzegorz at Janoszka.pl>
> Subject: [c-nsp] Freezing counters at 6500
> To: cisco-nsp at puck.nether.net
> Date: Wednesday, 29 July, 2009, 7:14 AM
> 
> Hi,
> 
> We have several 6500's, some of them heavily loaded. We use
> snmp to graph traffic on all interfaces - just the simplest
> solution. Since some time we have had an issue with the
> interface counters. When the CPU box is really loaded
> (usually synchronization of BGP sessions), the counters just
> freeze. The important thing is that only the displaying
> freezes, the counters are still counting. Both snmp and
> 'show interface' data is frozen and does not update for
> various time - from 30 seconds to 3-4 minutes. As the result
> we have spikes on graphs - there is always spike down, when
> snmp gives frozen data from the past, and after that spike
> up, when the counters unlock and start displaying correct
> data.
> 
> Have you had similar problems? It is not the big issue,
> only the graphs look not so nice with the rows of spikes
> down/up. If there is a simple solution to the problem we
> would like to know it.
> 
> Kind regards,
> 
> -- Grzegorz Janoszka



      

From jeff-kell at utc.edu  Tue Jul 28 22:06:13 2009
From: jeff-kell at utc.edu (Jeff Kell)
Date: Tue, 28 Jul 2009 22:06:13 -0400
Subject: [c-nsp] VSS question...
Message-ID: <4A6FAE95.6010806@utc.edu>

Excuse the naive question, just starting to look at VSS and trying to 
tune to the concept...

For those of you that have dived into VSS...  are you still doing 
redundant supervisors per chassis?  or just duplicating links on each 
chassis and crossing your fingers?

I've done the 3750 stacks and perhaps locked my thinking into designing 
with a complete chassis failure being "tolerable" in the end design.  
Does this scale up to VSS, or just a matter of how many ports can you 
afford to drop?

Jeff

From narmaw at pertamina-ep.com  Tue Jul 28 21:56:48 2009
From: narmaw at pertamina-ep.com (Narma Wahyuadi)
Date: Wed, 29 Jul 2009 08:56:48 +0700
Subject: [c-nsp] Monitoring VPN User on ASA
Message-ID: <008901ca0fef$d599fe80$80cdfb80$@com>

I want to monitoring vpn user on my ASA by snmp, it can trap vpn group but
it cannot trap the username (no such object available .) I use oid
1.3.6.1.4.1.9.9.392.1.3.21.1.1 , can you help me solve this problem ?


_____________________________________________________________________

Note: The information contained in this e-mail is intended only for the use of the individual or entity named above and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended party to receive the message and its attachment(s), you are hereby notified that any dissemination, distribution or copy of the message is strictly prohibited. Please immediately notify the sender and delete the message as soon as possible. Thank you for kind attention.
 
Catatan: Informasi yang terdapat dalam e-mail ini ditujukan hanya untuk penggunaan individu atau kelompok yang disebutkan di atas dan mungkin berisi informasi yang istimewa, rahasia dan dikecualikan dari pengungkapan menurut hukum yang berlaku. Jika Anda bukan pihak yang ditujukan untuk menerima pesan ini beserta lampirannya, dengan ini Anda diberitahukan bahwa penyebaran, pendistribusian atau penyalinan pesan ini adalah sangat dilarang. Harap segera memberitahu pengirim dan menghapus pesan ini secepatnya. Terima kasih atas perhatian Anda.

From tvarriale at comcast.net  Tue Jul 28 22:57:31 2009
From: tvarriale at comcast.net (Tony Varriale)
Date: Tue, 28 Jul 2009 21:57:31 -0500
Subject: [c-nsp] VSS question...
References: <4A6FAE95.6010806@utc.edu>
Message-ID: <D23DC08CC54249B584A1697FFE19F3F7@flamdt01>

Multiple sups per chassis are not supported.  From access to core, since VSS 
looks like one chassis, you would do 1 uplink to each physical 6500.

Cisco's data sheet: 
http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps9336/product_data_sheet0900aecd806ed759.html

Want to get into the weeds a little?  How about some tasty config guide?
http://www.cisco.com/en/US/partner/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/vss.html

tv
----- Original Message ----- 
From: "Jeff Kell" <jeff-kell at utc.edu>
To: "'NSP List'" <cisco-nsp at puck.nether.net>
Sent: Tuesday, July 28, 2009 9:06 PM
Subject: [c-nsp] VSS question...


> Excuse the naive question, just starting to look at VSS and trying to tune 
> to the concept...
>
> For those of you that have dived into VSS...  are you still doing 
> redundant supervisors per chassis?  or just duplicating links on each 
> chassis and crossing your fingers?
>
> I've done the 3750 stacks and perhaps locked my thinking into designing 
> with a complete chassis failure being "tolerable" in the end design.  Does 
> this scale up to VSS, or just a matter of how many ports can you afford to 
> drop?
>
> 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 MatlockK at exempla.org  Tue Jul 28 22:59:23 2009
From: MatlockK at exempla.org (Matlock, Kenneth L)
Date: Tue, 28 Jul 2009 20:59:23 -0600
Subject: [c-nsp] VSS question...
References: <4A6FAE95.6010806@utc.edu>
Message-ID: <4288131ED5E3024C9CD4782CECCAD2C70489E96B@LMC-MAIL2.exempla.org>

Last I had heard, the IOS code can only understand 2 supervisors total. Meaning you have an active and a standby, and that's it. So you have 1 supervisor in each chassis total. There is no current concept of an active, and multiple 'hot' standby supervisors.
 
That (among other things) made us decide not to do VSS, although having portchannels span multiple 6500's was an attractive feature....
 
And keep in mind that for VSS, you're looking at the Sup720-10G supervisors, and the WS-X6708 cards for the links between VSS pairs (sure, you can get away with just the links on the supervisors, but you have a huge single point of failure).
 
Ken Matlock
matlockk at exempla.org
Network Analyst
Exempla Healthcare
(303) 467-4671

________________________________

From: cisco-nsp-bounces at puck.nether.net on behalf of Jeff Kell
Sent: Tue 7/28/2009 8:06 PM
To: 'NSP List'
Subject: [c-nsp] VSS question...



Excuse the naive question, just starting to look at VSS and trying to
tune to the concept...

For those of you that have dived into VSS...  are you still doing
redundant supervisors per chassis?  or just duplicating links on each
chassis and crossing your fingers?

I've done the 3750 stacks and perhaps locked my thinking into designing
with a complete chassis failure being "tolerable" in the end design. 
Does this scale up to VSS, or just a matter of how many ports can you
afford to drop?

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 graham at g-rock.net  Tue Jul 28 22:36:27 2009
From: graham at g-rock.net (Graham Wooden)
Date: Tue, 28 Jul 2009 21:36:27 -0500
Subject: [c-nsp] VSS question...
In-Reply-To: <4A6FAE95.6010806@utc.edu>
Message-ID: <C6951FDB.78D5%graham@g-rock.net>

Hi there,

We are about to roll out VSS at our distro layer.  Currently with SXI1, you
can't have redundant sups.  Our assigned Cisco arch guy said that maybe
later this year or early next year that you will be able to have redundant
sups in a vss member chassis.


On 7/28/09 9:06 PM, "Jeff Kell" <jeff-kell at utc.edu> wrote:

> Excuse the naive question, just starting to look at VSS and trying to
> tune to the concept...
> 
> For those of you that have dived into VSS...  are you still doing
> redundant supervisors per chassis?  or just duplicating links on each
> chassis and crossing your fingers?
> 
> I've done the 3750 stacks and perhaps locked my thinking into designing
> with a complete chassis failure being "tolerable" in the end design.
> Does this scale up to VSS, or just a matter of how many ports can you
> afford to drop?
> 
> 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 kron at linkey.ru  Wed Jul 29 02:49:34 2009
From: kron at linkey.ru (Aleksandr Gurbo)
Date: Wed, 29 Jul 2009 10:49:34 +0400
Subject: [c-nsp] Re-pack IOS
Message-ID: <20090729104934.5a7d011c.kron@linkey.ru>

I have IOS image(134Mb) with size more then flash(128Mb) size.
Does it possible re-pack IOS image on 28xx/38xx/76xx series?

-- 
Alexandr Gurbo

From sethm at rollernet.us  Wed Jul 29 02:58:13 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Tue, 28 Jul 2009 23:58:13 -0700
Subject: [c-nsp] Re-pack IOS
In-Reply-To: <20090729104934.5a7d011c.kron@linkey.ru>
References: <20090729104934.5a7d011c.kron@linkey.ru>
Message-ID: <4A6FF305.7020200@rollernet.us>

Aleksandr Gurbo wrote:
> I have IOS image(134Mb) with size more then flash(128Mb) size.
> Does it possible re-pack IOS image on 28xx/38xx/76xx series?
> 

It's already compressed if you have "mz" in the image name.

~Seth

From gert at greenie.muc.de  Wed Jul 29 03:05:26 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Wed, 29 Jul 2009 09:05:26 +0200
Subject: [c-nsp] Freezing counters at 6500
In-Reply-To: <4A6F6A2D.40101@Janoszka.pl>
References: <4A6F6A2D.40101@Janoszka.pl>
Message-ID: <20090729070526.GG290@greenie.muc.de>

Hi,

On Tue, Jul 28, 2009 at 11:14:21PM +0200, Grzegorz Janoszka wrote:
> Have you had similar problems? It is not the big issue, only the graphs 
> look not so nice with the rows of spikes down/up. If there is a simple 
> solution to the problem we would like to know it.

Well, I think this is just the way this architecture works.  The hardware
does the actual counting, and every now and then a low-prio process grabs
all the counters from the hardware and fills in SNMP variables.

We haven't seen delays up to 3-4 minutes, just the normal 30-60 second
stuff - so our graphing (based on 5-minute samples) isn't really affected
by it.

When we do "real-time" monitoring ("there is a big customer event today,
we need to see quickly whether some pipes are filling up") we do rolling
averages, similar to what the "5 minute input" counters in IOS do - don't
use the SNMP counters "as is", but average with the last few values, to
smooth out the curves (and we don't use "nothing has changed" values as
"0 Mbit", but we wait for a change, and then calculate the bandwith based
on the number of seconds since the last change).  We still get jumps, but 
much more sane values overall.


So indeed, there is something that can be done on the display side - and
nothing I know of that can be done on the rotuer side.

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/20090729/5dac4c35/attachment.bin>

From mtinka at globaltransit.net  Wed Jul 29 02:40:20 2009
From: mtinka at globaltransit.net (Mark Tinka)
Date: Wed, 29 Jul 2009 14:40:20 +0800
Subject: [c-nsp] Humor: Cisco announces end of BGP
In-Reply-To: <4A6F66C2.1080400@justinshore.com>
References: <5.1.0.14.2.20090728104929.051778f8@efes.iucc.ac.il>
	<005901ca0fc2$939d6bc0$0a00000a@nil.si>
	<4A6F66C2.1080400@justinshore.com>
Message-ID: <200907291440.21183.mtinka@globaltransit.net>

On Wednesday 29 July 2009 04:59:46 am Justin Shore wrote:

> According to a Pannaway SE who visited us a few years
> ago, he'd seen SPs many times our size who used static
> routes for everything.  He said we weren't big enough to
> need a routing protocol.  Of course he also said that our
> pipes weren't saturated so we didn't need QoS and that
> IPv6 was just a fad and would never be adopted in the US.

<off_topic>
Well, we once had a major, very well known, fairly large 
global transit provider tell us they couldn't increase their 
BGP maximum prefix limit on our eBGP session to them because 
our circuit size was only 100Mbps. If we wanted to announce 
more prefixes through them, we'd have had to increase our 
subscribed capacity to them, first...

Makes you wonder...
</off_topic>

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/20090729/6012dfd9/attachment.bin>

From kron at linkey.ru  Wed Jul 29 03:56:01 2009
From: kron at linkey.ru (Aleksandr Gurbo)
Date: Wed, 29 Jul 2009 11:56:01 +0400
Subject: [c-nsp] Re-pack IOS
In-Reply-To: <4A6FF305.7020200@rollernet.us>
References: <20090729104934.5a7d011c.kron@linkey.ru>
	<4A6FF305.7020200@rollernet.us>
Message-ID: <20090729115601.c94e797b.kron@linkey.ru>

On Tue, 28 Jul 2009 23:58:13 -0700
Seth Mattinen <sethm at rollernet.us> wrote:

> Aleksandr Gurbo wrote:
> > I have IOS image(134Mb) with size more then flash(128Mb) size.
> > Does it possible re-pack IOS image on 28xx/38xx/76xx series?
> > 
> 
> It's already compressed if you have "mz" in the image name.
> 
> ~Seth

I know, but I know about ability to re-pack IOS on 26xx series( on russian - http://betep.wpl.ru/2009/02/cisco.html). I tried repeat steps for images on 28xx/38xx/76xx series but nothing happened.
My image is c7600s72033-adventerprisek9-mz.122-33.SRD2.bin

-- 
Aleksandr Gurbo

From A.L.M.Buxey at lboro.ac.uk  Wed Jul 29 04:12:52 2009
From: A.L.M.Buxey at lboro.ac.uk (Alan Buxey)
Date: Wed, 29 Jul 2009 09:12:52 +0100
Subject: [c-nsp] VSS question...
In-Reply-To: <4A6FAE95.6010806@utc.edu>
References: <4A6FAE95.6010806@utc.edu>
Message-ID: <20090729081252.GB11496@lboro.ac.uk>

Hi,

> For those of you that have dived into VSS...  are you still doing  
> redundant supervisors per chassis?  or just duplicating links on each  
> chassis and crossing your fingers?


VSS cannot currently support multiple sups in a chassis. which is handy
as it means you only need to buy one S720-10G for each box (earlier Sups
dont do VSS). then you just dual-uplink to each chassis

alan

From Grzegorz at Janoszka.pl  Wed Jul 29 04:13:25 2009
From: Grzegorz at Janoszka.pl (Grzegorz Janoszka)
Date: Wed, 29 Jul 2009 10:13:25 +0200
Subject: [c-nsp] Freezing counters at 6500
In-Reply-To: <20090729070526.GG290@greenie.muc.de>
References: <4A6F6A2D.40101@Janoszka.pl> <20090729070526.GG290@greenie.muc.de>
Message-ID: <4A7004A5.3090600@Janoszka.pl>

Gert Doering wrote:
> Well, I think this is just the way this architecture works.  The hardware
> does the actual counting, and every now and then a low-prio process grabs
> all the counters from the hardware and fills in SNMP variables.

Hi, thanks for the answer. Is there any way to somehow slightly increase 
priority of this process? Please note that 'show int' also has 'frozen' 
data.

-- 
Grzegorz Janoszka

From td_miles at yahoo.com  Wed Jul 29 04:14:28 2009
From: td_miles at yahoo.com (Tony)
Date: Wed, 29 Jul 2009 01:14:28 -0700 (PDT)
Subject: [c-nsp] Re-pack IOS
In-Reply-To: <20090729115601.c94e797b.kron@linkey.ru>
Message-ID: <874938.95628.qm@web110114.mail.gq1.yahoo.com>

--- On Wed, 29/7/09, Aleksandr Gurbo <kron at linkey.ru> wrote:

> > > I have IOS image(134Mb) with size more then
> flash(128Mb) size.
> > > Does it possible re-pack IOS image on
> 28xx/38xx/76xx series?
> > > 

>
> My image is c7600s72033-adventerprisek9-mz.122-33.SRD2.bin
> 


If it is for the 7600, then you will need to buy a larger flash card (eg 256 or 512MB).




      


From sethm at rollernet.us  Wed Jul 29 04:18:53 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Wed, 29 Jul 2009 01:18:53 -0700
Subject: [c-nsp] VSS question...
In-Reply-To: <20090729081252.GB11496@lboro.ac.uk>
References: <4A6FAE95.6010806@utc.edu> <20090729081252.GB11496@lboro.ac.uk>
Message-ID: <4A7005ED.7060305@rollernet.us>

Alan Buxey wrote:
> Hi,
> 
>> For those of you that have dived into VSS...  are you still doing  
>> redundant supervisors per chassis?  or just duplicating links on each  
>> chassis and crossing your fingers?
> 
> 
> VSS cannot currently support multiple sups in a chassis. which is handy
> as it means you only need to buy one S720-10G for each box (earlier Sups
> dont do VSS). then you just dual-uplink to each chassis
> 

So, 3750 stack on steroids?

~Seth

From gert at greenie.muc.de  Wed Jul 29 04:20:34 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Wed, 29 Jul 2009 10:20:34 +0200
Subject: [c-nsp] VPN clients on Cisco ASA
In-Reply-To: <23002.1477.qm@web80502.mail.mud.yahoo.com>
References: <23002.1477.qm@web80502.mail.mud.yahoo.com>
Message-ID: <20090729082033.GI290@greenie.muc.de>

Hi,

On Tue, Jul 28, 2009 at 02:12:31PM -0700, Randy wrote:
> 4) Also disable DPD(no isakmp keepalive. 

Why?

I haven't experienced any issues with DPD yet, but I regularily see people
recommending to turn off DPD, or blaim other issues (like "rekeying doesn't
work") on DPD - so I wonder what I'm missing here.

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/20090729/b35a0241/attachment.bin>

From A.L.M.Buxey at lboro.ac.uk  Wed Jul 29 04:38:13 2009
From: A.L.M.Buxey at lboro.ac.uk (Alan Buxey)
Date: Wed, 29 Jul 2009 09:38:13 +0100
Subject: [c-nsp] VSS question...
In-Reply-To: <4A7005ED.7060305@rollernet.us>
References: <4A6FAE95.6010806@utc.edu> <20090729081252.GB11496@lboro.ac.uk>
	<4A7005ED.7060305@rollernet.us>
Message-ID: <20090729083813.GA11906@lboro.ac.uk>

Hi,

> So, 3750 stack on steroids?

not really - with the 3750 you get a 32 or 64Gb backplane
stacking mechanism (stckwise or stackwise+) - whereas
with VSS its a 10Gb starter...

alan

From kron at linkey.ru  Wed Jul 29 05:19:16 2009
From: kron at linkey.ru (Aleksandr Gurbo)
Date: Wed, 29 Jul 2009 13:19:16 +0400
Subject: [c-nsp] Re-pack IOS
In-Reply-To: <4A700920.1040101@poggs.co.uk>
References: <20090729104934.5a7d011c.kron@linkey.ru>
	<4A6FF305.7020200@rollernet.us>
	<20090729115601.c94e797b.kron@linkey.ru>
	<4A700920.1040101@poggs.co.uk>
Message-ID: <20090729131916.20f2ff36.kron@linkey.ru>

On Wed, 29 Jul 2009 09:32:32 +0100
Peter Hicks <peter.hicks at poggs.co.uk> wrote:

> Hello
> 
> Aleksandr Gurbo wrote:
> > I know, but I know about ability to re-pack IOS on 26xx series( on russian - http://betep.wpl.ru/2009/02/cisco.html). I tried repeat steps for images on 28xx/38xx/76xx series but nothing happened.
> > My image is c7600s72033-adventerprisek9-mz.122-33.SRD2.bin
> >   
> You might be asking the wrong question.  You might have wanted to ask 
> "Can I load an IOS image over TFTP?", for example.  Or, "Can I expand 
> the flash on my router?" - or better still, "This image is too big for 
> my device, what options do I have?"
> 
> Personally, I've found non-Cisco CF to be exceedingly cheap.
> 
> 
> Peter

Thank you, Peter, for you wide answer, but my question is previous.
I explain. I want unpack image and pack again image, but with better parametres of compression. So I can receive image with size less, then I have. After this manipulations I can upload new compressed image on my 128Mb compact flash.
On images for 26xx series it is possible re-pack IOS, you can try yourself. I don't know about re-pack operations on images for 28xx/38xx/76xx series, may be new degree of protection or new methods of compression are used.

-- 
Alexandr Gurbo

From peter.hicks at poggs.co.uk  Wed Jul 29 04:32:32 2009
From: peter.hicks at poggs.co.uk (Peter Hicks)
Date: Wed, 29 Jul 2009 09:32:32 +0100
Subject: [c-nsp] Re-pack IOS
In-Reply-To: <20090729115601.c94e797b.kron@linkey.ru>
References: <20090729104934.5a7d011c.kron@linkey.ru>	<4A6FF305.7020200@rollernet.us>
	<20090729115601.c94e797b.kron@linkey.ru>
Message-ID: <4A700920.1040101@poggs.co.uk>

Hello

Aleksandr Gurbo wrote:
> I know, but I know about ability to re-pack IOS on 26xx series( on russian - http://betep.wpl.ru/2009/02/cisco.html). I tried repeat steps for images on 28xx/38xx/76xx series but nothing happened.
> My image is c7600s72033-adventerprisek9-mz.122-33.SRD2.bin
>   
You might be asking the wrong question.  You might have wanted to ask 
"Can I load an IOS image over TFTP?", for example.  Or, "Can I expand 
the flash on my router?" - or better still, "This image is too big for 
my device, what options do I have?"

Personally, I've found non-Cisco CF to be exceedingly cheap.


Peter

From Kiran.Oddiraju at cbre.com  Wed Jul 29 06:21:21 2009
From: Kiran.Oddiraju at cbre.com (Oddiraju, Kiran @ London SMC)
Date: Wed, 29 Jul 2009 11:21:21 +0100
Subject: [c-nsp] VPN clients on Cisco ASA
In-Reply-To: <6E21B2BDEF6E714EA0B5BA8D5D0E1401248380B434@zy-ex1.zyedge.local>
References: <B5CFB919B5EEF345969F51FAFE6360D50ADF31@GBLDCXMB10.emea.cbre.net>
	<6E21B2BDEF6E714EA0B5BA8D5D0E1401248380B434@zy-ex1.zyedge.local>
Message-ID: <B5CFB919B5EEF345969F51FAFE6360D50ADF6F@GBLDCXMB10.emea.cbre.net>

I changed the default-group-policy to Kiran-CUCM-VPN and now I am able
to VPN in to my network. Thanks Ryan and everyone for your help

Regards,
Kiran

-----Original Message-----
From: Ryan West [mailto:rwest at zyedge.com] 
Sent: 28 July 2009 15:18
To: Oddiraju, Kiran @ London SMC
Cc: cisco-nsp at puck.nether.net
Subject: RE: VPN clients on Cisco ASA

Kiran,

You'll want to get Xauth configured for your RA-VPN.  Do you have an
internal auth server you can query?  You can query AD directly through
LDAP / NT protocol / Kerberos or use IAS through RADIUS.  Once you
establish those servers, you'll want to call them in your tunnel-group
Kir-VPN gen attributes.  You probably also want to set your
default-group-policy to Kiran-CUCM-VPN in the same section.  Since you
are most likely failing IKE negotiations, you can run a 'debug cry isa
2' and gather more information.


I would recommend following this guide and leveraging IAS, it's more of
the traditional method, but I think it would be a good fit for your
needs.

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configura
tion_example09186a00806de37e.shtml

You should try to sanitize your configs in the future, just put in
x.x.x.x when posting public IPs.

-ryan


-----Original Message-----
From: Oddiraju, Kiran @ London SMC [mailto:Kiran.Oddiraju at cbre.com] 
Sent: Tuesday, July 28, 2009 10:01 AM
To: Ryan West
Cc: cisco-nsp at puck.nether.net
Subject: Re: VPN clients on Cisco ASA

Hi Guys,

Appreciate your help on this. Have tried the VPN Wizard and the CLI
config from the below link but still no luck. The Cisco VPN client tries
to connect and after for a few seconds shows Not Connected. I think it
is an ACL issue but I am not 100% sure. I have attached the running
config, could someone please take a look?

Many thanks,
Kiran

-----Original Message-----
From: Ryan West [mailto:rwest at zyedge.com]
Sent: 27 July 2009 13:57
To: Oddiraju, Kiran @ London SMC; cisco-nsp at puck.nether.net
Subject: RE: VPN clients on Cisco ASA

Hello again Kiran,

I think you should take a quick read through the following link.  You
can use the ASDM Remote Access VPN wizard to configure most of the
settings and if you're interested in doing it via CLI, that's also an
option.

http://www.cisco.com/en/US/products/ps6120/products_configuration_exampl
e09186a008060f25c.shtml

In particular, the options you have asked are all covered in the doc
except for split-tunneling, at least the associated output in CLI.
You'll want to configure that inside the group policy you create from
the link above.  Here is an example:

group-policy mygrouppolicyname attributes  split-tunnel-policy
tunnelspecified  split-tunnel-network-list value <ACL Here>

Let me know how it works out for you.

-ryan

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Oddiraju, Kiran
@ London SMC
Sent: Monday, July 27, 2009 8:33 AM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] VPN clients on Cisco ASA

Hi List,

 

Cisco ASA 5505

Cisco VPN Client 5.0

ASA External IP: 80.90.100.117 /29

Internal range: 192.168.0.0 /24

 

I am new to Cisco ASA world and have been struggling to configure my
5505 to accept VPN connections from external hosts. I want to allocate
IP address dynamically, allow access to certain subnets and allow
internet access thru their local connection. Can someone please post me
a sample ASA config?

 

Thanks guys

 

Regards,

Kiran


CB Richard Ellis Limited, Registered Office: St Martin's Court, 10
Paternoster Row, London, EC4M 7HP, registered in England and Wales No.
3536032. 
Regulated by the RICS and an appointed representative of CB Richard
Ellis Indirect Investment Services Limited which is authorised and
regulated by the Financial Services Authority.

This communication is from CB Richard Ellis Limited or one of its
associated/subsidiary companies. This communication contains information
which is confidential and may be privileged. If you are not the intended
recipient, please contact the sender immediately. Any use of its
contents is strictly prohibited and you must not copy, send or disclose
it, or rely on its contents in any way whatsoever. 
Reasonable care has been taken to ensure that this communication (and
any attachments or hyperlinks contained within it) is free from computer
viruses. 
No responsibility is accepted by CB Richard Ellis Limited or its
associated/subsidiary companies and the recipient should carry out any
appropriate virus checks.

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

CB Richard Ellis Limited, Registered Office: St Martin's Court, 10
Paternoster Row, London, EC4M 7HP, registered in England and Wales No.
3536032. 
Regulated by the RICS and an appointed representative of CB Richard
Ellis Indirect Investment Services Limited which is authorised and
regulated by the Financial Services Authority.

This communication is from CB Richard Ellis Limited or one of its
associated/subsidiary companies. This communication contains information
which is confidential and may be privileged. If you are not the intended
recipient, please contact the sender immediately. Any use of its
contents is strictly prohibited and you must not copy, send or disclose
it, or rely on its contents in any way whatsoever. 
Reasonable care has been taken to ensure that this communication (and
any attachments or hyperlinks contained within it) is free from computer
viruses. 
No responsibility is accepted by CB Richard Ellis Limited or its
associated/subsidiary companies and the recipient should carry out any
appropriate virus checks.

CB Richard Ellis Limited, Registered Office: St Martin's Court, 
10 Paternoster Row, London, EC4M 7HP, registered in England and Wales No. 3536032. 
Regulated by the RICS and an appointed representative of CB Richard Ellis 
Indirect Investment Services Limited which is authorised and regulated by the Financial Services Authority.

This communication is from CB Richard Ellis Limited or one of its 
associated/subsidiary companies. This communication contains information 
which is confidential and may be privileged. If you are not the intended recipient, 
please contact the sender immediately. Any use of its contents is strictly prohibited 
and you must not copy, send or disclose it, or rely on its contents in any way whatsoever. 
Reasonable care has been taken to ensure that this communication 
(and any attachments or hyperlinks contained within it) is free from computer viruses. 
No responsibility is accepted by CB Richard Ellis Limited or its associated/subsidiary 
companies and the recipient should carry out any appropriate virus checks.


From eric at atlantech.net  Wed Jul 29 06:33:53 2009
From: eric at atlantech.net (Eric Van Tol)
Date: Wed, 29 Jul 2009 06:33:53 -0400
Subject: [c-nsp] Humor: Cisco announces end of BGP
In-Reply-To: <4A6F66C2.1080400@justinshore.com>
References: <5.1.0.14.2.20090728104929.051778f8@efes.iucc.ac.il>
	<4A6F2DD0.1060608@justinshore.com>	<005901ca0fc2$939d6bc0$0a00000a@nil.si>
	<4A6F66C2.1080400@justinshore.com>
Message-ID: <2C05E949E19A9146AF7BDF9D44085B863541D03D0A@exchange.aoihq.local>

> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> bounces at puck.nether.net] On Behalf Of Justin Shore
> Sent: Tuesday, July 28, 2009 5:00 PM
> To: Ivan Pepelnjak
> Cc: cisco-nsp at puck.nether.net; 'Hank Nussbacher'
> Subject: Re: [c-nsp] Humor: Cisco announces end of BGP
> 
...
> IPv6 was just a fad and would never be adopted in the US.


Sadly, he's not too far off on this one.

From trejrco at gmail.com  Wed Jul 29 07:08:51 2009
From: trejrco at gmail.com (TJ)
Date: Wed, 29 Jul 2009 07:08:51 -0400
Subject: [c-nsp] Humor: Cisco announces end of BGP
In-Reply-To: <2C05E949E19A9146AF7BDF9D44085B863541D03D0A@exchange.aoihq.local>
References: <5.1.0.14.2.20090728104929.051778f8@efes.iucc.ac.il>	<4A6F2DD0.1060608@justinshore.com>	<005901ca0fc2$939d6bc0$0a00000a@nil.si>	<4A6F66C2.1080400@justinshore.com>
	<2C05E949E19A9146AF7BDF9D44085B863541D03D0A@exchange.aoihq.local>
Message-ID: <00c201ca103c$f6a82fa0$e3f88ee0$@com>

>From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
>bounces at puck.nether.net] On Behalf Of Eric Van Tol
>> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
>> bounces at puck.nether.net] On Behalf Of Justin Shore
>>
>> IPv6 was just a fad and would never be adopted in the US.
>Sadly, he's not too far off on this one.


Totally disagree, but I might also be biased ... in several cases IPv6
already is deployed (within the US), but let's talk again in 1-3 years?
/TJ


From Jonathan.Brashear at hq.speakeasy.net  Wed Jul 29 09:05:10 2009
From: Jonathan.Brashear at hq.speakeasy.net (Jonathan Brashear)
Date: Wed, 29 Jul 2009 06:05:10 -0700
Subject: [c-nsp] Humor: Cisco announces end of BGP
In-Reply-To: <00c201ca103c$f6a82fa0$e3f88ee0$@com>
References: <5.1.0.14.2.20090728104929.051778f8@efes.iucc.ac.il>
	<4A6F2DD0.1060608@justinshore.com>	<005901ca0fc2$939d6bc0$0a00000a@nil.si>
	<4A6F66C2.1080400@justinshore.com>
	<2C05E949E19A9146AF7BDF9D44085B863541D03D0A@exchange.aoihq.local>
	<00c201ca103c$f6a82fa0$e3f88ee0$@com>
Message-ID: <725755F5E728EE4086DAAF1A54DACF4F161E8B02@sea5exbe1.speakeasy.hq>

You guys need to get on the ARIN list and say that.  I'll make the popcorn. :)


Network Engineer, JNCIS-M
> 214-981-1954 (office) 
> 214-642-4075 (cell)
> jbrashear at hq.speakeasy.net 
http://www.speakeasy.net
-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of TJ
Sent: Wednesday, July 29, 2009 6:09 AM
To: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Humor: Cisco announces end of BGP

>From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
>bounces at puck.nether.net] On Behalf Of Eric Van Tol
>> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
>> bounces at puck.nether.net] On Behalf Of Justin Shore
>>
>> IPv6 was just a fad and would never be adopted in the US.
>Sadly, he's not too far off on this one.


Totally disagree, but I might also be biased ... in several cases IPv6
already is deployed (within the US), but let's talk again in 1-3 years?
/TJ

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

From rwest at zyedge.com  Wed Jul 29 09:18:54 2009
From: rwest at zyedge.com (Ryan West)
Date: Wed, 29 Jul 2009 09:18:54 -0400
Subject: [c-nsp] VPN clients on Cisco ASA
In-Reply-To: <23002.1477.qm@web80502.mail.mud.yahoo.com>
References: <23002.1477.qm@web80502.mail.mud.yahoo.com>
Message-ID: <6E21B2BDEF6E714EA0B5BA8D5D0E14012489DA290A@zy-ex1.zyedge.local>

Randy,

?
5) the outside acl is wide-open(with permit ip any any) Recommend locking it down. for vpn, allow tcp 50 and udp 500 to the outside int from any unless sysopt conn ipsec permit is enabled.
?
6) Probable would be a good idea to replace ip's with x.x.x.x when posting configs on a public site.
?
regards,
./Randy
?
When isakmp and a crypto map are enabled on the outside, the ACL is ignored completely, the same applies for management purposes like SSH and HTTPS.  If there were another device in front of the firewall, then you would need to enable protocol 50 (ESP) and UDP/500 (IKE).  The sysopt conn permit-vpn connection tells the firewall to ignore ACL processing of the tunneled traffic.? Good catch on the split tunnel, I glazed over that one.

-ryan
?
?
?


From awilliam1981 at gmail.com  Wed Jul 29 09:44:49 2009
From: awilliam1981 at gmail.com (Andy William)
Date: Wed, 29 Jul 2009 16:44:49 +0300
Subject: [c-nsp] ISP in US
Message-ID: <9569de140907290644j11098b10l7c9c929ce4b30bb9@mail.gmail.com>

Dear All



I need your advice , we'll open an office in Washinghton DC and will need a
reliable internet connection between US office and our office in middle east
to transport data and vidoe confernce traffic



according to your experince with ISPs in US , what is the best ISP that can
offer QoS-based service between 2 internet points (US and ME) ?



best regards

Andy

From ras at e-gerbil.net  Wed Jul 29 09:50:49 2009
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Wed, 29 Jul 2009 08:50:49 -0500
Subject: [c-nsp] Re-pack IOS
In-Reply-To: <20090729131916.20f2ff36.kron@linkey.ru>
References: <20090729104934.5a7d011c.kron@linkey.ru>
	<4A6FF305.7020200@rollernet.us>
	<20090729115601.c94e797b.kron@linkey.ru>
	<4A700920.1040101@poggs.co.uk>
	<20090729131916.20f2ff36.kron@linkey.ru>
Message-ID: <20090729135049.GU51443@gerbil.cluepon.net>

On Wed, Jul 29, 2009 at 01:19:16PM +0400, Aleksandr Gurbo wrote:
> On images for 26xx series it is possible re-pack IOS, you can try
> yourself. I don't know about re-pack operations on images for
> 28xx/38xx/76xx series, may be new degree of protection or new methods
> of compression are used.

Sure, IOS is IOS is IOS, the same techniques apply.

-rw-r--r--  1 root  code  132978980 Jul 29 08:34 c7600s72033-advipservicesk9-mz.122-33.SRD2a.bin
-rw-r--r--  1 root  code   65403172 Jul 29 08:38 c7600s72033-advipservicesk9-mz.122-33.SRD2a-lan.bin

The later image has had all the SIP/SPA and FlexWan type images removed,
LAN cards only. You can reduce your boot time on the 6500/7600 platform
by about 90-100 secs (depending on file size) if you can strip out the
unnecessary images and make it fit onto the old 64MB linear bootflash
rather than the modern ATA flash. The linear flash reads at 2MB/s while
the ATA flash only reads at 1MB/s, so you reduce the "read the image
into memory" time from 132 secs to 32 secs in the example above. This
has been discussed on this list many times, search the archives. :)

-- 
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 eric at atlantech.net  Wed Jul 29 09:58:26 2009
From: eric at atlantech.net (Eric Van Tol)
Date: Wed, 29 Jul 2009 09:58:26 -0400
Subject: [c-nsp] Humor: Cisco announces end of BGP
In-Reply-To: <00c201ca103c$f6a82fa0$e3f88ee0$@com>
References: <5.1.0.14.2.20090728104929.051778f8@efes.iucc.ac.il>
	<4A6F2DD0.1060608@justinshore.com>	<005901ca0fc2$939d6bc0$0a00000a@nil.si>
	<4A6F66C2.1080400@justinshore.com>
	<2C05E949E19A9146AF7BDF9D44085B863541D03D0A@exchange.aoihq.local>
	<00c201ca103c$f6a82fa0$e3f88ee0$@com>
Message-ID: <2C05E949E19A9146AF7BDF9D44085B863541D03D13@exchange.aoihq.local>

> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> bounces at puck.nether.net] On Behalf Of TJ
> Sent: Wednesday, July 29, 2009 7:09 AM
> To: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] Humor: Cisco announces end of BGP
> 
> >From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> >bounces at puck.nether.net] On Behalf Of Eric Van Tol
> >> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> >> bounces at puck.nether.net] On Behalf Of Justin Shore
> >>
> >> IPv6 was just a fad and would never be adopted in the US.
> >Sadly, he's not too far off on this one.
> 
> 
> Totally disagree, but I might also be biased ... in several cases IPv6
> already is deployed (within the US), but let's talk again in 1-3 years?
> /TJ

Let's see...from our "big carriers":

AboveNet: No IPv6
Verizon:  No IPv6
Savvis:  No IPv6
Level3: No IPv6
GBLX: IPv6!
Verio: IPv6!

Sure, we have some smaller providers and peers that run it, too, but until the majority of our so-called "Tier 1" providers start deploying it *and making it easy to request*, I stick to my guns by saying that he wasn't that far off.

-evt 

From Jeff.Wojciechowski at midlandpaper.com  Wed Jul 29 09:59:10 2009
From: Jeff.Wojciechowski at midlandpaper.com (Jeff Wojciechowski)
Date: Wed, 29 Jul 2009 08:59:10 -0500
Subject: [c-nsp] ISP in US
In-Reply-To: <9569de140907290644j11098b10l7c9c929ce4b30bb9@mail.gmail.com>
References: <9569de140907290644j11098b10l7c9c929ce4b30bb9@mail.gmail.com>
Message-ID: <6B8401A83219DF499C34DEAEE9A599921256B58ABF@XBOX.midlandpaper.com>

Andy:

I am told Level 3 is to have it by the end of the year. Not sure on their middle east connections but since they own AS #1 my guess is they have pretty good connectivity everywhere.

We are looking to use 2 internet connections as a failover route for our corporate VoIP - they said as long as the traffic stays on their Internet backbone that QoS will be honored (which it should be between our 2 offices).

-Jeff


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Andy William
Sent: Wednesday, July 29, 2009 8:45 AM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] ISP in US

Dear All



I need your advice , we'll open an office in Washinghton DC and will need a
reliable internet connection between US office and our office in middle east
to transport data and vidoe confernce traffic



according to your experince with ISPs in US , what is the best ISP that can
offer QoS-based service between 2 internet points (US and ME) ?



best regards

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 fasterfourier at gmail.com  Wed Jul 29 10:30:01 2009
From: fasterfourier at gmail.com (Robert Johnson)
Date: Wed, 29 Jul 2009 10:30:01 -0400
Subject: [c-nsp] High CPU usage on 3640
Message-ID: <4f84a6f80907290730j725b9383leae62b8bdcbe3bf5@mail.gmail.com>

Hello list,
I would appreciate any help with going through the following configuration
and making suggestions to reduce CPU usage on this router. The example
router is a 3640 with a single FE interface run to a 2924 switch. It is
loaded at peak times with less than 2000 PPS and 9 Mbps aggregate on the FE
interface. The bulk of the traffic is flowing between the f0/0.300 and
f0/0.302 interfaces. There is some ACL checking and QOS marking going on for
both of these interfaces in multiple directions. This is done to ensure
voice priority on wireless links that use 802.1p to form queues. All (for
the most part) of the CPU usage is due to interrupts.

Suggestions?

router>sho proc cpu hist

router   02:15:17 PM Wednesday Jul 29 2009 UTC


    5555555555544444444444444444444444443333344444333333333344
    2111114444466666666666666611111888882222200000222228888800
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)

    5565666666777666566545466566666666678768655666567666545446
    1106144112101388799093804673397940104983291383955552869770
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%

    86543223342226394789888887553333234323345777877776544 3234222124411223
    4660478341898942827940584834138343317626230724265716090656046791268613
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%


Configuration:

version 12.4
service timestamps debug uptime
service timestamps log uptime
service password-encryption
!
hostname router
!
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
 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
!
!
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
!
buffers tune automatic
!
interface FastEthernet0/0
 description Trunk to cat2924
 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 anotherrouter
 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 ****
 ip ospf hello-interval 1
 ip ospf dead-interval 5
 no snmp trap link-status
!
interface FastEthernet0/0.51
 description Management link to yetanotherrouter
 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 stillanotherrouter
 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 anotherrouter
 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 yetanotherrouter
 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 stillanotherrouter
 bandwidth 10610
 encapsulation dot1Q 302
 ip address xxx.xxx.xxx.xxx 255.255.255.252
 ip access-group internet-edge-ingress in
 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 verify unicast reverse-path
 rate-limit input access-group 100 768000 10000 200000 conform-action
transmit exceed-action drop
 rate-limit output access-group 100 768000 40000000 80000000 conform-action
transmit 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 yyyy
 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 xxxx
 neighbor xxx.xxx.xxx.xxx route-map pri-map out
 neighbor xxx.xxx.xxx.xxx remote-as yyyy
 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 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   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 3640stats 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  Property of xxxx. Unauthorized access attempts will be
prosecuted. 
!
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 17179619
ntp server 10.3.40.105
!
end

From trejrco at gmail.com  Wed Jul 29 10:32:24 2009
From: trejrco at gmail.com (TJ)
Date: Wed, 29 Jul 2009 10:32:24 -0400
Subject: [c-nsp] Humor: Cisco announces end of BGP
In-Reply-To: <2C05E949E19A9146AF7BDF9D44085B863541D03D13@exchange.aoihq.local>
References: <5.1.0.14.2.20090728104929.051778f8@efes.iucc.ac.il>	<4A6F2DD0.1060608@justinshore.com>	<005901ca0fc2$939d6bc0$0a00000a@nil.si>	<4A6F66C2.1080400@justinshore.com>	<2C05E949E19A9146AF7BDF9D44085B863541D03D0A@exchange.aoihq.local>
	<00c201ca103c$f6a82fa0$e3f88ee0$@com>
	<2C05E949E19A9146AF7BDF9D44085B863541D03D13@exchange.aoihq.local>
Message-ID: <016201ca1059$664174e0$32c45ea0$@com>

>-----Original Message-----
>From: Eric Van Tol [mailto:eric at atlantech.net]
>> >> bounces at puck.nether.net] On Behalf Of Justin Shore

>> >> IPv6 was just a fad and would never be adopted in the US.

>> >Sadly, he's not too far off on this one.

>> Totally disagree, but I might also be biased ... in several cases IPv6
>> already is deployed (within the US), but let's talk again in 1-3 years?
>> /TJ

>Let's see...from our "big carriers":
>AboveNet: No IPv6
>Verizon:  No IPv6
>Savvis:  No IPv6
>Level3: No IPv6
>GBLX: IPv6!
>Verio: IPv6!
>Sure, we have some smaller providers and peers that run it, too, but until
the
>majority of our so-called "Tier 1" providers start deploying it *and making
it
>easy to request*, I stick to my guns by saying that he wasn't that far off.

And therein lies the rub.  The objection was to "never be adopted" ...
I know several of the above (and other large carriers you omitted) have
"started deploying it", but "started deployment" != "commercially
available".
(i.e. - not "easy to request".  And for today, I totally agree ... that is
why I said in "1-3 years".)


/TJ


From swmike at swm.pp.se  Wed Jul 29 10:57:37 2009
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Wed, 29 Jul 2009 16:57:37 +0200 (CEST)
Subject: [c-nsp] High CPU usage on 3640
In-Reply-To: <4f84a6f80907290730j725b9383leae62b8bdcbe3bf5@mail.gmail.com>
References: <4f84a6f80907290730j725b9383leae62b8bdcbe3bf5@mail.gmail.com>
Message-ID: <alpine.DEB.1.10.0907291656540.10769@uplift.swm.pp.se>

On Wed, 29 Jul 2009, Robert Johnson wrote:

> Suggestions?

Please provide output from "show int switching" (not tab-completable) to 
verify that all traffic is cef switched.

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

From psirt at cisco.com  Wed Jul 29 11:00:00 2009
From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team)
Date: Wed, 29 Jul 2009 15:00:00 -0000
Subject: [c-nsp] Cisco Security Advisory: Cisco IOS Software Border Gateway
	Protocol 4-Byte Autonomous System Number Vulnerabilities
Message-ID: <20090729.bgp@psirt.cisco.com>

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

Cisco Security Advisory: Cisco IOS Software Border Gateway Protocol
                         4-Byte Autonomous System Number
                         Vulnerabilities

Advisory ID: cisco-sa-20090729-bgp

http://www.cisco.com/warp/public/707/cisco-sa-20090729-bgp.shtml

Revision: 1.0
=========

For Public Release 2009 July 29 1600 UTC (GMT)

Summary
=======

Recent versions of Cisco IOS Software support RFC4893 ("BGP Support
for Four-octet AS Number Space") and contain two remote denial of
service (DoS) vulnerabilities when handling specific Border Gateway
Protocol (BGP) updates.

These vulnerabilities affect only devices running Cisco IOS Software
with support for four-octet AS number space (here after referred to as
4-byte AS number) and BGP routing configured.

The first vulnerability could cause an affected device to reload when
processing a BGP update that contains autonomous system (AS) path
segments made up of more than one thousand autonomous systems.

The second vulnerability could cause an affected device to reload when
the affected device processes a malformed BGP update that has been
crafted to trigger the issue.

Cisco has released free software updates to address these
vulnerabilities.

No workarounds are available for the first vulnerability.

A workaround is available for the second vulnerability.

This advisory is posted at the following link:
http://www.cisco.com/warp/public/707/cisco-sa-20090729-bgp.shtml

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

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

These vulnerabilities affect only devices running Cisco IOS and 
Cisco IOS XE Software (here after both referred to as simply Cisco
IOS) with support for RFC4893 and that have been configured for 
BGP routing.

The software table in the section "Software Versions and Fixes" of
this advisory indicates all affected Cisco IOS Software versions that
have support for RFC4893 and are affected by this vulnerability.

A Cisco IOS software version that has support for RFC4893 will allow
configuration of AS numbers using 4 Bytes. The following example
identifies a Cisco device that has 4 byte AS number support:

    Router#configure terminal
    Enter configuration commands, one per line.  End with CNTL/Z.
    Router(config)#router bgp ?
      <1-65535>    Autonomous system number
      <1.0-XX.YY>  4 Octets Autonomous system number

    Or:

    Router#configure terminal
    Enter configuration commands, one per line.  End with CNTL/Z.
    Router(config)#router bgp ?
      <1-4294967295>  Autonomous system number
      <1.0-XX.YY>     Autonomous system number

The following example identifies a Cisco device that has 2 byte AS
number support:

    Router#configure terminal
    Enter configuration commands, one per line.  End with CNTL/Z.
    Router(config)#router bgp ?
      <1-65535>  Autonomous system number

A router that is running the BGP process will contain a line in the
configuration that defines the autonomous system number (AS number),
which can be seen by issuing the command line interface (CLI) command
"show running-config".

The canonical textual representation of four byte AS Numbers is
standardized by the IETF through RFC5396 (Textual Representation of
Autonomous System (AS) Numbers). Two major ways for textual
representation have been defined as ASDOT and ASPLAIN. Cisco IOS
routers support both textual representations of AS numbers. For
further information about textual representation of four byte AS
numbers in Cisco IOS Software consult the document "Explaining 4-Byte
Autonomous System (AS) ASPLAIN and ASDOT Notation for Cisco IOS" at
the following link:
http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6554/ps6599/white_paper_c11_516829.html
   
Cisco IOS Software with support for RFC4893 is affected by both
vulnerabilities if BGP routing is configured using either ASPLAIN or
ASDOT notation.

The following example identifies a Cisco device that is configured
for BGP using ASPLAIN notation:

    router bgp 65536

The following example identifies a Cisco device that is configured
for BGP using ASDOT notation:

    router bgp 1.0

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 following Cisco products are confirmed not vulnerable:

  * Cisco IOS Software not explicitly mentioned in this Advisory
  * Cisco IOS XR Software
  * Cisco IOS NX-OS

No other Cisco products are currently known to be affected by this
vulnerability.

Details     
=======   

RFC4271 has defined an AS number as a two-octet entity in BGP. 
RFC4893 has defined an AS number as a four-octet entity in BGP.

The first vulnerability could cause an affected device to reload when
processing a BGP update that contains AS path segments made up of more
than one thousand autonomous systems. If an affected 4-byte AS number
BGP speaker receives a BGP update from a 2-byte AS number BGP speaker
that contains AS path segments made up of more than one thousand
autonomous systems, the device may crash with memory corruption, and
the error "%%Software-forced reload" will be displayed.

The following three conditions are required for successful
exploitation of this vulnerability:

  * Affected Cisco IOS Software device is a 4-byte AS number BGP
    speaker
  * BGP peering neighbor is a 2-byte AS number BGP speaker
  * BGP peering neighbor is capable of sending a BGP update with a
    series of greater than one thousand AS numbers

    Note: Note: Cisco IOS, Cisco IOS XE, Cisco NX-OS and Cisco IOS XR
    Software, as a 2 byte AS number BGP speaker send BGP updates with
    a maximum of 255 AS numbers.

This vulnerability is documented in Cisco Bug ID CSCsy86021 and has
been assigned Common Vulnerabilities and Exposures (CVE) ID
CVE-2009-1168.

The second vulnerability could cause an affected device to reload when
the affected device processes a malformed BGP update that has been
crafted to trigger the issue. The following three conditions are
required for successful exploitation of this vulnerability:

  * Affected Cisco IOS Software device is a 4-byte AS number BGP
    speaker
  * BGP peering neighbor is a 2-byte AS number BGP speaker
  * BGP peering neighbor is capable of sending a non-RFC compliant
    crafted BGP update message

This vulnerability is documented in Cisco Bug ID CSCta33973 and has
been assigned Common Vulnerabilities and Exposures (CVE) ID 
CVE-2009-2049.

Further information regarding Cisco support for 4-byte AS number is
available in "Cisco IOS BGP 4-Byte ASN Support" at the following
link: 
http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6554/ps6599/data_sheet_C78-521821.html

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


CSCsy86021: Cisco IOS Software BGP Long AS-path Vulnerability

CVSS Base Score - 7.1

Access Vector           Network
Access Complexity       Medium
Authentication          None
Confidentiality Impact  None
Availability Impact     Complete

CVSS Temporal Score - 6.7
Exploitability          Functional
Remediation Level       Official-Fix
Report Confidence       Confirmed
 
   
CSCta33973: Cisco IOS Software Crafted BGP Update Message Vulnerability
 
CVSS Base Score - 5.4

Access Vector           Network
Access Complexity       High
Authentication          None
Confidentiality Impact  None
Availability Impact     Complete

CVSS Temporal Score - 4.5
Exploitability          Functional
Remediation Level       Official-Fix
Report Confidence       Confirmed
   
Impact
======     
   
Successful exploitation of the vulnerabilities described in this
document may result in a reload of the device. The issue could result
in repeated exploitation to cause an extended DoS condition.
   
Software Versions and Fixes
===========================

When considering software upgrades, also consult
http://www.cisco.com/go/psirt and any subsequent advisories to
determine exposure and a complete upgrade solution.

In all cases, customers should exercise caution to be certain the
devices to be upgraded contain sufficient memory and that current
hardware and software configurations will continue to be supported
properly by the new release. If the information is not clear, contact
the Cisco Technical Assistance Center (TAC) or your contracted
maintenance provider for assistance.

Each row of the Cisco IOS software table (below) names a Cisco IOS
release train. If a given release train is vulnerable, then the
earliest possible releases that contain the fix (along with the
anticipated date of availability for each, if applicable) are listed
in the "First Fixed Release" column of the table. The "Recommended
Release" column indicates the releases which have fixes for all the
published vulnerabilities at the time of this Advisory. A device
running a release in the given train that is earlier than the release
in a specific column (less than the First Fixed Release) is known to
be vulnerable. Cisco recommends upgrading to a release equal to or
later than the release in the "Recommended Releases" column of the
table.
   
+-------------------------------------------------------------------+
|  Major   |             Availability of Repaired Releases          |
| Release  |                                                        |
|----------+--------------------------------------------------------|
| Affected |                                           |Recommended |
|12.0-Based|           First Fixed Release             |  Release   |
| Releases |                                           |            |
|----------+-------------------------------------------+------------|
|12.0      |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.0DA    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.0DB    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.0DC    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|          |Releases up to and including 12.0(32)S11   |            |
|          |are not vulnerable; first fixed in         |            |
|12.0S     |12.0(32)S14;                               |            |
|          |                                           |            |
|          |Releases up to and including 12.0(33)S2 are|            |
|          |not vulnerable; first fixed in 12.0(33)S5  |            |
|----------+-------------------------------------------+------------|
|12.0SC    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.0SL    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.0SP    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.0ST    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.0SX    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.0SY    |Releases up to and including 12.0(32)SY7   |12.0(32)SY10|
|          |are not vulnerable; first fixed in         |            |
|          |12.0(32)SY9a.                              |            |
|----------+-------------------------------------------+------------|
|12.0SZ    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.0T     |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.0W     |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.0WC    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.0WT    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.0WX    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.0XA    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.0XB    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.0XC    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.0XD    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.0XE    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.0XF    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.0XG    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.0XH    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.0XI    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.0XJ    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.0XK    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.0XL    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.0XM    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.0XN    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.0XQ    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.0XR    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.0XS    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.0XT    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.0XV    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.0XW    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
| Affected |                                           |Recommended |
|12.1-Based|            First Fixed Release            |  Release   |
| Releases |                                           |            |
|-------------------------------------------------------------------|
|             There are no affected 12.1 based releases             |
|-------------------------------------------------------------------|
| Affected |                                           |Recommended |
|12.2-Based|            First Fixed Release            |  Release   |
| Releases |                                           |            |
|----------+-------------------------------------------+------------|
|12.2      |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2B     |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2BC    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2BW    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2BX    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2BY    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2BZ    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2CX    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2CY    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2CZ    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2DA    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2DD    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2DX    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2EW    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2EWA   |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2EX    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2EY    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2EZ    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2FX    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2FY    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2FZ    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2IRA   |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2IRB   |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2IRC   |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2IXA   |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2IXB   |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2IXC   |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2IXD   |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2IXE   |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2IXF   |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2IXG   |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2IXH   |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2JA    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2JK    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2MB    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2MC    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2S     |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2SB    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2SBC   |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2SCA   |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2SCB   |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2SE    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2SEA   |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2SEB   |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2SEC   |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2SED   |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2SEE   |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2SEF   |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2SEG   |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2SG    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2SGA   |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2SL    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2SM    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2SO    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2SQ    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2SRA   |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2SRB   |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2SRC   |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2SRD   |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2STE   |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2SU    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2SV    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2SVA   |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2SVC   |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2SVD   |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2SVE   |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2SW    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2SX    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2SXA   |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2SXB   |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2SXD   |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2SXE   |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2SXF   |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2SXH   |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|          |Releases up to and including 12.2(33)SXI   |            |
|12.2SXI   |are not vulnerable; CSCsy86021 first fixed |            |
|          |in 12.2(33)SXI2; CSCta33973 first fixed in |            |
|          |12.2(33)SXI3                               |            |
|----------+-------------------------------------------+------------|
|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.2XN    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2XNA   |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2XNB   |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2XNC   |12.2(33)XNC2                               |            |
|----------+-------------------------------------------+------------|
|12.2XND   |12.2(33)XND1; available 25th August 2009   |            |
|----------+-------------------------------------------+------------|
|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.2ZM    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2ZP    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2ZU    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2ZX    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2ZY    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.2ZYA   |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
| Affected |                                           |Recommended |
|12.3-Based|            First Fixed Release            |  Release   |
| Releases |                                           |            |
|-------------------------------------------------------------------|
|             There are no affected 12.3 based releases             |
|-------------------------------------------------------------------|
| Affected |                                           |Recommended |
|12.4-Based|            First Fixed Release            |  Release   |
| Releases |                                           |            |
|----------+-------------------------------------------+------------|
|12.4      |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.4JA    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.4JDA   |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.4JDC   |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.4JDD   |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.4JK    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.4JL    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.4JMA   |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.4JMB   |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.4JX    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.4MD    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.4MDA   |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.4MR    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.4SW    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|          |Releases up to 12.4(24)T are not           |            |
|12.4T     |vulnerable; first fixed in 12.4(24)T2      |            |
|          |available on 23-Oct-2009                   |            |
|----------+-------------------------------------------+------------|
|12.4XA    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.4XB    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.4XC    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.4XD    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.4XE    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.4XF    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.4XG    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.4XJ    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.4XK    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.4XL    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.4XM    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.4XN    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.4XP    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.4XQ    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.4XR    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.4XT    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.4XV    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.4XW    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.4XY    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.4XZ    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.4YA    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.4YB    |Not Vulnerable                             |            |
|----------+-------------------------------------------+------------|
|12.4YD    |Not Vulnerable                             |            |
+-------------------------------------------------------------------+

Cisco IOS XE Release Table
+-------------------------

+-------------------------------------------------------------------+
|  Major   |              Availability of Repaired Releases         |
| Release  |                                                        |
|----------+--------------------------------------------------------|
| Affected |                                                        |
|   2.1    | There are no affected 2.1 based releases               |
| Releases |                                                        |
|----------+--------------------------------------------------------|
| Affected |                                                        |
|   2.2    | There are no affected 2.2 based releases               |
| Releases |                                                        |
|----------+--------------------------------------------------------|
| Affected | Releases up to and including 2.3.1t are vulnerable;    |
|   2.3    | First fixed in 2.3.2                                   |
| Releases |                                                        |
|----------+--------------------------------------------------------+
| Affected | Releases up to and including 2.4.0 are vulnerable;     |
|   2.4    | First fixed in 2.4.1, available 25th August 2009       |
| Releases |                                                        |
+----------+--------------------------------------------------------+
   
Workarounds
===========

For the first vulnerability, there are no workarounds on the affected
device. Neighbors could be configured to discard routes that have
more than one thousand AS numbers in the AS-path segments. This
configuration will help prevent the further propagation of BGP
updates with the AS path segments made up of greater than one
thousand AS numbers.

Note: Configuring "bgp maxas-limit [value]" on the affected device
does not mitigate this vulnerability.

For the second vulnerability, configuring "bgp maxas-limit [value]"
on the affected device does mitigate this vulnerability. Cisco is
recommends using a conservative value of 100 to mitigate this
vulnerability.

Consult the document "Protecting Border Gateway Protocol for the
Enterprise" at the following link for additional best practices on
protecting BGP infrastructures: 
http://www.cisco.com/web/about/security/intelligence/protecting_bgp.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 malicious exploitation of either of
these vulnerabilities, although we are aware of some customers who
have seen the first vulnerability triggered within their
infrastructures. Further investigation of those incidents seems to
indicate that the vulnerability has been accidentally triggered.

These vulnerabilities were discovered via internal product testing.

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

This information is Cisco Highly Confidential - Do not redistribute.

THIS IS A DRAFT VERSION OF A SECURITY NOTICE THAT CONTAINS UNRELEASED
INFORMATION ABOUT CISCO PRODUCTS. DISTRIBUTION WITHIN CISCO IS
LIMITED TO PERSONNEL WITH A NEED TO KNOW. THIS DRAFT MAY CONTAIN
ERRORS OR OMIT IMPORTANT INFORMATION.

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.

Distribution
============

This advisory is posted on Cisco's worldwide website at:
   
http://www.cisco.com/warp/public/707/cisco-sa-20090729-bgp.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 1.0   | 2009-July-29 1600    | Initial 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 (Darwin)

iD8DBQFKcGNc86n/Gc8U/uARAks6AKCCWLTakna/WbNzMuIbeGPJGJHnbQCfbYEi
I6XwyRZTnktw7RSnT6Y/N1E=
=KmUm
-----END PGP SIGNATURE-----

From lmeade at signal.ca  Wed Jul 29 11:30:36 2009
From: lmeade at signal.ca (Leslie Meade)
Date: Wed, 29 Jul 2009 08:30:36 -0700
Subject: [c-nsp] policing question
Message-ID: <EAF4FF4AB2142D499F2F5A3B9D85152904D74724@exch-bo.MGVFS.McLeanNet>


I have a question,  I have over 50 vlans and each needs to be policed at different speeds. I have a cat 6509 with sup32's
Creating access-lists, class maps etc. are no issues for me. To my understanding that I can only police in one direction on any given interface. So I put a service-policy output on a vlan and another service-policy input on the other. But when I add more than 4 class?s to a policy map on my transit internet network it crawls to a dead stop. Anyone tell me why ? I gather the sup32?s/int cannot handle the output. To give you an idea of how much data I push out, in one week I will do over a Terabyte of data.

Here is an example of the standard ACL?s and policy-maps that I am using..

ip access-list extended VLAN14_WWW 
10 permit tcp any eq www any
20 permit tcp any any eq www


class-map match-any VLAN14_WWW-CL
  match access-group name VLAN14_WWW
  
policy-map VLAN14_OUTBOUND-PM
class VLAN14_WWW-CL 
                police cir 2097000 bc 66406 be 66406 conform-action transmit exceed-action drop violate-action drop

policy-map Internet-Access-PM
class VLAN14_WWW-CL 
                police cir 2097000 bc 66406 be 66406 conform-action transmit exceed-action drop violate-action drop
class VLAN15_WWW-CL 
                police cir 2097000 bc 66406 be 66406 conform-action transmit exceed-action drop violate-action drop
class VLAN16_WWW-CL 
                police cir 2097000 bc 66406 be 66406 conform-action transmit exceed-action drop violate-action drop
class VLAN17_WWW-CL 
                police cir 2097000 bc 66406 be 66406 conform-action transmit exceed-action drop violate-action drop


interface Vlan14
description VFS
ip address 10.1.14.2 255.255.255.0
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.14.1
standby 15 priority 250
standby 15 preempt
service-policy output  VLAN14_OUTBOUND-PM

interface Vlan254
description Transient 
 ip address 10.1.254.2 255.255.255.0
 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.254.1
standby 15 priority 250
standby 15 preempt
service-policy input  Internet-Access-PM

Cheers

Leslie

From vanormer at gmail.com  Wed Jul 29 11:41:15 2009
From: vanormer at gmail.com (Robert VanOrmer)
Date: Wed, 29 Jul 2009 10:41:15 -0500
Subject: [c-nsp] Humor: Cisco announces end of BGP
Message-ID: <003c01ca1063$0335e1b0$09a1a510$@com>

Verizon: IPv6!

 

We do have a IPv6 transport from Verizon, granted. (1) good luck globally
routing your /48 outside of VZB land, they won't do it unless your providing
a /32, and if you have been delegated any address space from an RIR, (2)
good luck getting delegated addressing from Verizon's chunk, they require
you to return any space delegated by an RIR before they will provide any of
there own. we are stuck in that Catch-22, but they are offering services.
Shows the lack of maturity in IPv6, but it's coming.

 

 

-----Original Message-----

Date: Wed, 29 Jul 2009 09:58:26 -0400

From: Eric Van Tol <eric at atlantech.net>

To: "'TJ'" <trejrco at gmail.com>, "cisco-nsp at puck.nether.net"

      <cisco-nsp at puck.nether.net>

Subject: Re: [c-nsp] Humor: Cisco announces end of BGP

Message-ID:

      <2C05E949E19A9146AF7BDF9D44085B863541D03D13 at exchange.aoihq.local>

Content-Type: text/plain; charset="us-ascii"

 

> -----Original Message-----

> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-

> bounces at puck.nether.net] On Behalf Of TJ

> Sent: Wednesday, July 29, 2009 7:09 AM

> To: cisco-nsp at puck.nether.net

> Subject: Re: [c-nsp] Humor: Cisco announces end of BGP

> 

> >From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-

> >bounces at puck.nether.net] On Behalf Of Eric Van Tol

> >> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-

> >> bounces at puck.nether.net] On Behalf Of Justin Shore

> >>

> >> IPv6 was just a fad and would never be adopted in the US.

> >Sadly, he's not too far off on this one.

> 

> 

> Totally disagree, but I might also be biased ... in several cases IPv6

> already is deployed (within the US), but let's talk again in 1-3 years?

> /TJ

 

Let's see...from our "big carriers":

 

AboveNet: No IPv6

Verizon:  No IPv6

Savvis:  No IPv6

Level3: No IPv6

GBLX: IPv6!

Verio: IPv6!

 

Sure, we have some smaller providers and peers that run it, too, but until
the majority of our so-called "Tier 1" providers start deploying it *and
making it easy to request*, I stick to my guns by saying that he wasn't that
far off.

 

-evt 

 


From gert at greenie.muc.de  Wed Jul 29 11:47:06 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Wed, 29 Jul 2009 17:47:06 +0200
Subject: [c-nsp] Humor: Cisco announces end of BGP
In-Reply-To: <016201ca1059$664174e0$32c45ea0$@com>
References: <5.1.0.14.2.20090728104929.051778f8@efes.iucc.ac.il>
	<4A6F2DD0.1060608@justinshore.com>
	<005901ca0fc2$939d6bc0$0a00000a@nil.si>
	<4A6F66C2.1080400@justinshore.com>
	<2C05E949E19A9146AF7BDF9D44085B863541D03D0A@exchange.aoihq.local>
	<00c201ca103c$f6a82fa0$e3f88ee0$@com>
	<2C05E949E19A9146AF7BDF9D44085B863541D03D13@exchange.aoihq.local>
	<016201ca1059$664174e0$32c45ea0$@com>
Message-ID: <20090729154706.GQ290@greenie.muc.de>

Hi,

On Wed, Jul 29, 2009 at 10:32:24AM -0400, TJ wrote:
> >Verio: IPv6!
> 
> And therein lies the rub.  The objection was to "never be adopted" ...
> I know several of the above (and other large carriers you omitted) have
> "started deploying it", but "started deployment" != "commercially
> available".
> (i.e. - not "easy to request".  And for today, I totally agree ... that is
> why I said in "1-3 years".)

Actually, NTT/Verio have had IPv6 available, as in "commercially available
and fully supported" for a number of years.

We're mandating full IPv6 support as part of all upstream procurements,
and this has been quite effective :-) - (and it turns away Cogent and L3 
salespeople, which is a nice side effect).

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/20090729/cad94b18/attachment.bin>

From kloch at kl.net  Wed Jul 29 11:16:19 2009
From: kloch at kl.net (Kevin Loch)
Date: Wed, 29 Jul 2009 11:16:19 -0400
Subject: [c-nsp] Freezing counters at 6500
In-Reply-To: <4A6F6A2D.40101@Janoszka.pl>
References: <4A6F6A2D.40101@Janoszka.pl>
Message-ID: <4A7067C3.7090200@kl.net>

Grzegorz Janoszka wrote:
> 
> Hi,
> 
> We have several 6500's, some of them heavily loaded. We use snmp to 
> graph traffic on all interfaces - just the simplest solution. Since some 
> time we have had an issue with the interface counters. When the CPU box 
> is really loaded (usually synchronization of BGP sessions), the counters 
> just freeze. The important thing is that only the displaying freezes, 
> the counters are still counting. Both snmp and 'show interface' data is 
> frozen and does not update for various time - from 30 seconds to 3-4 
> minutes. As the result we have spikes on graphs - there is always spike 
> down, when snmp gives frozen data from the past, and after that spike 
> up, when the counters unlock and start displaying correct data.

Try adjusting 'service counters max age' to zero if you haven't already.
As others have pointed out a delay of 3-4 minutes is not normal
What does your SP (not RP) cpu usage look like?  Try disabling netflow
if your SP cpu usage is maxing out.

- Kevin

From eric at atlantech.net  Wed Jul 29 12:11:59 2009
From: eric at atlantech.net (Eric Van Tol)
Date: Wed, 29 Jul 2009 12:11:59 -0400
Subject: [c-nsp] Humor: Cisco announces end of BGP
In-Reply-To: <20090729154706.GQ290@greenie.muc.de>
References: <5.1.0.14.2.20090728104929.051778f8@efes.iucc.ac.il>
	<4A6F2DD0.1060608@justinshore.com>	<005901ca0fc2$939d6bc0$0a00000a@nil.si>
	<4A6F66C2.1080400@justinshore.com>
	<2C05E949E19A9146AF7BDF9D44085B863541D03D0A@exchange.aoihq.local>
	<00c201ca103c$f6a82fa0$e3f88ee0$@com>
	<2C05E949E19A9146AF7BDF9D44085B863541D03D13@exchange.aoihq.local>
	<016201ca1059$664174e0$32c45ea0$@com>
	<20090729154706.GQ290@greenie.muc.de>
Message-ID: <2C05E949E19A9146AF7BDF9D44085B863541D03D18@exchange.aoihq.local>

> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> bounces at puck.nether.net] On Behalf Of Gert Doering
> Sent: Wednesday, July 29, 2009 11:47 AM
> To: TJ
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] Humor: Cisco announces end of BGP
> 
> Actually, NTT/Verio have had IPv6 available, as in "commercially available
> and fully supported" for a number of years.
> 
> We're mandating full IPv6 support as part of all upstream procurements,
> and this has been quite effective :-) - (and it turns away Cogent and L3
> salespeople, which is a nice side effect).
> 
> gert

This is true, but they are the only provider that we have run up against that actually charges *extra* for v6, at outrageous per-meg rates.  Last quote I got was two years ago, so perhaps things have changed.

-evt

From simon at slimey.org  Wed Jul 29 12:25:30 2009
From: simon at slimey.org (Simon Lockhart)
Date: Wed, 29 Jul 2009 17:25:30 +0100
Subject: [c-nsp] Humor: Cisco announces end of BGP
In-Reply-To: <2C05E949E19A9146AF7BDF9D44085B863541D03D18@exchange.aoihq.local>
References: <5.1.0.14.2.20090728104929.051778f8@efes.iucc.ac.il>
	<4A6F2DD0.1060608@justinshore.com>
	<005901ca0fc2$939d6bc0$0a00000a@nil.si>
	<4A6F66C2.1080400@justinshore.com>
	<2C05E949E19A9146AF7BDF9D44085B863541D03D0A@exchange.aoihq.local>
	<00c201ca103c$f6a82fa0$e3f88ee0$@com>
	<2C05E949E19A9146AF7BDF9D44085B863541D03D13@exchange.aoihq.local>
	<016201ca1059$664174e0$32c45ea0$@com>
	<20090729154706.GQ290@greenie.muc.de>
	<2C05E949E19A9146AF7BDF9D44085B863541D03D18@exchange.aoihq.local>
Message-ID: <20090729162530.GB2898@virtual.bogons.net>

On Wed Jul 29, 2009 at 12:11:59PM -0400, Eric Van Tol wrote:
> This is true, but they are the only provider that we have run up against that
> actually charges *extra* for v6, at outrageous per-meg rates.  Last quote I
> got was two years ago, so perhaps things have changed.

We've been running IPv6 with Level3 and NTT/Verio for a while now, and neither
charged any extra for the privilege.

Simon
-- 
Simon Lockhart | * Sun Server Colocation * ADSL * Domain Registration *
   Director    |    * Domain & Web Hosting * Internet Consultancy * 
  Bogons Ltd   | * http://www.bogons.net/  *  Email: info at bogons.net  * 

From trejrco at gmail.com  Wed Jul 29 12:44:54 2009
From: trejrco at gmail.com (TJ)
Date: Wed, 29 Jul 2009 12:44:54 -0400
Subject: [c-nsp] Humor: Cisco announces end of BGP
In-Reply-To: <20090729154706.GQ290@greenie.muc.de>
References: <5.1.0.14.2.20090728104929.051778f8@efes.iucc.ac.il>
	<4A6F2DD0.1060608@justinshore.com>
	<005901ca0fc2$939d6bc0$0a00000a@nil.si>
	<4A6F66C2.1080400@justinshore.com>
	<2C05E949E19A9146AF7BDF9D44085B863541D03D0A@exchange.aoihq.local>
	<00c201ca103c$f6a82fa0$e3f88ee0$@com>
	<2C05E949E19A9146AF7BDF9D44085B863541D03D13@exchange.aoihq.local>
	<016201ca1059$664174e0$32c45ea0$@com>
	<20090729154706.GQ290@greenie.muc.de>
Message-ID: <020201ca106b$e8b6a730$ba23f590$@com>

>> And therein lies the rub.  The objection was to "never be adopted" ...
>> I know several of the above (and other large carriers you omitted)
>> have "started deploying it", but "started deployment" != "commercially
>> available".
>> (i.e. - not "easy to request".  And for today, I totally agree ...
>> that is why I said in "1-3 years".)
>
>Actually, NTT/Verio have had IPv6 available, as in "commercially available
and
>fully supported" for a number of years.
>
>We're mandating full IPv6 support as part of all upstream procurements, and
>this has been quite effective :-) - (and it turns away Cogent and L3
>salespeople, which is a nice side effect).

Good point ... in fact, we had NTT/Verio for a bit.  Wish we still did (even
if they were doing the whole "/126 on point to point links" think).
(I meant to include that some carriers do fully offer IPv6 today, but
somehow edited that out ... my bad)


>gert
/TJ


From eric at atlantech.net  Wed Jul 29 12:47:15 2009
From: eric at atlantech.net (Eric Van Tol)
Date: Wed, 29 Jul 2009 12:47:15 -0400
Subject: [c-nsp] Humor: Cisco announces end of BGP
In-Reply-To: <20090729162530.GB2898@virtual.bogons.net>
References: <5.1.0.14.2.20090728104929.051778f8@efes.iucc.ac.il>
	<4A6F2DD0.1060608@justinshore.com>
	<005901ca0fc2$939d6bc0$0a00000a@nil.si>
	<4A6F66C2.1080400@justinshore.com>
	<2C05E949E19A9146AF7BDF9D44085B863541D03D0A@exchange.aoihq.local>
	<00c201ca103c$f6a82fa0$e3f88ee0$@com>
	<2C05E949E19A9146AF7BDF9D44085B863541D03D13@exchange.aoihq.local>
	<016201ca1059$664174e0$32c45ea0$@com>
	<20090729154706.GQ290@greenie.muc.de>
	<2C05E949E19A9146AF7BDF9D44085B863541D03D18@exchange.aoihq.local>
	<20090729162530.GB2898@virtual.bogons.net>
Message-ID: <2C05E949E19A9146AF7BDF9D44085B863541D03D19@exchange.aoihq.local>

> -----Original Message-----
> From: Simon Lockhart [mailto:simon at slimey.org]
> Sent: Wednesday, July 29, 2009 12:26 PM
> To: Eric Van Tol
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] Humor: Cisco announces end of BGP
> 
> 
> We've been running IPv6 with Level3 and NTT/Verio for a while now, and
> neither
> charged any extra for the privilege.
> 
> Simon

Last time I looked into it with Verio, they wanted close to $50/Meg on a 5M commit, plus an additional MRC of $500 for IPv6.  Needless to say, I couldn't justify it to the higher ups, especially when our primary v6 provider was offering it for free.  Again, this was two years ago (almost to the day!), so maybe things have changed.

-evt

From merlyn at Geeks.ORG  Wed Jul 29 12:52:10 2009
From: merlyn at Geeks.ORG (Doug McIntyre)
Date: Wed, 29 Jul 2009 11:52:10 -0500
Subject: [c-nsp] Re-pack IOS
In-Reply-To: <20090729131916.20f2ff36.kron@linkey.ru>
References: <20090729104934.5a7d011c.kron@linkey.ru>
	<4A6FF305.7020200@rollernet.us>
	<20090729115601.c94e797b.kron@linkey.ru>
	<4A700920.1040101@poggs.co.uk>
	<20090729131916.20f2ff36.kron@linkey.ru>
Message-ID: <20090729165210.GA73903@geeks.org>

On Wed, Jul 29, 2009 at 01:19:16PM +0400, Aleksandr Gurbo wrote:
> Thank you, Peter, for you wide answer, but my question is previous.
> I explain. I want unpack image and pack again image, but with better parametres of compression. So I can receive image with size less, then I have. After this manipulations I can upload new compressed image on my 128Mb compact flash.
> On images for 26xx series it is possible re-pack IOS, you can try yourself. I don't know about re-pack operations on images for 28xx/38xx/76xx series, may be new degree of protection or new methods of compression are used.


The reason it hasn't been done is because its not worthwhile. 

You say you want to gain 6MB, but I content its not possible to
compress it that much better.

I unpacked a 2800 image, and repacked it with 'gzip --best' and gained
only 78k. Then I did the same thing with 'bzip2 --best' and gained 1M

While the bzip2 method got you something almost signifigant, unless
you have a super wunder compression algorithm that can do
signifigantly better than 'bzip2 --best' (at least 6 times better), 
you aren't looking at this as viable, let alone the time to develop
the unpacker in IOS bare-metal coding, and implementing it correctly.
bzip2 takes a signifigant longer time to unpack than the current LWZ alg
does as well, increasing boot up time much more. 

The previous answers of either booting off TFTP or buying more flash
which is virtually dirt cheap on the 2800/3800/7600 routers is the
correct answer, even if you didn't like to hear it.

From david.freedman at uk.clara.net  Wed Jul 29 13:13:29 2009
From: david.freedman at uk.clara.net (David Freedman)
Date: Wed, 29 Jul 2009 18:13:29 +0100
Subject: [c-nsp] Humor: Cisco announces end of BGP
In-Reply-To: <020201ca106b$e8b6a730$ba23f590$@com>
References: <5.1.0.14.2.20090728104929.051778f8@efes.iucc.ac.il>	<4A6F2DD0.1060608@justinshore.com>	<005901ca0fc2$939d6bc0$0a00000a@nil.si>	<4A6F66C2.1080400@justinshore.com>	<2C05E949E19A9146AF7BDF9D44085B863541D03D0A@exchange.aoihq.local>	<00c201ca103c$f6a82fa0$e3f88ee0$@com>	<2C05E949E19A9146AF7BDF9D44085B863541D03D13@exchange.aoihq.local>	<016201ca1059$664174e0$32c45ea0$@com>	<20090729154706.GQ290@greenie.muc.de>
	<020201ca106b$e8b6a730$ba23f590$@com>
Message-ID: <4A708339.5020700@uk.clara.net>

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


> Good point ... in fact, we had NTT/Verio for a bit.  Wish we still did (even
> if they were doing the whole "/126 on point to point links" think).
> (I meant to include that some carriers do fully offer IPv6 today, but
> somehow edited that out ... my bad)

And what, prey tell is wrong with "/126 on point to point links",
you want to use SLAAC between routers?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpwgzkACgkQtFWeqpgEZrLoEgCdEU7U9UPtCo+47Cu1ET6B4NJV
Ip0AoMHfr+WIbNTJ68zW6+B7oAYH59Yc
=k+0K
-----END PGP SIGNATURE-----

From fasterfourier at gmail.com  Wed Jul 29 13:23:43 2009
From: fasterfourier at gmail.com (Robert Johnson)
Date: Wed, 29 Jul 2009 13:23:43 -0400
Subject: [c-nsp] High CPU usage on 3640
In-Reply-To: <alpine.DEB.1.10.0907291656540.10769@uplift.swm.pp.se>
References: <4f84a6f80907290730j725b9383leae62b8bdcbe3bf5@mail.gmail.com>
	<alpine.DEB.1.10.0907291656540.10769@uplift.swm.pp.se>
Message-ID: <4f84a6f80907291023i5b6c9aafo446ed8d6a81e51be@mail.gmail.com>

Here is what Michael and I have determined:
In the past hour, only about 0.3% of IP traffic has been process switched.
Where should I look next?

Here is a sho int switching and sho cef not-cef-switched from this morning:

router>sho cef not
CEF Packets passed on to next switching layer
Slot  No_adj No_encap Unsupp'ted Redirect  Receive  Options   Access
Frag
RP    519742       0           0      135  9230575        0        0
 0

router>sho int switching
FastEthernet0/0 Trunk to cat2924-pri
          Throttle count          0
                   Drops         RP      66318         SP          0
             SPD Flushes       Fast          0        SSE          0
             SPD Aggress       Fast          0
            SPD Priority     Inputs  434347726      Drops         14

    Protocol  IP
          Switching path    Pkts In   Chars In   Pkts Out  Chars Out
                 Process  444100384 4128900191  451024072 1623654938
            Cache misses    3165282          -          -          -
                    Fast  817529650  465527639  814305889 3034876515
               Auton/SSE          0          0          0          0

    Protocol  DEC MOP
          Switching path    Pkts In   Chars In   Pkts Out  Chars Out
                 Process          0          0      88719    6831363
            Cache misses          0          -          -          -
                    Fast          0          0          0          0
               Auton/SSE          0          0          0          0

    Protocol  ARP
          Switching path    Pkts In   Chars In   Pkts Out  Chars Out
                 Process     591696   35549720     880345   56342080
            Cache misses          0          -          -          -
                    Fast          0          0          0          0
               Auton/SSE          0          0          0          0

    Protocol  CDP
          Switching path    Pkts In   Chars In   Pkts Out  Chars Out
                 Process     889072  350294368     889559  310455284
            Cache misses          0          -          -          -
                    Fast          0          0          0          0
               Auton/SSE          0          0          0          0

    Protocol  Other
          Switching path    Pkts In   Chars In   Pkts Out  Chars Out
                 Process          3       1182    5337235  320234100
            Cache misses          0          -          -          -
                    Fast          0          0          0          0
               Auton/SSE          0          0          0          0

    NOTE: all counts are cumulative and reset only after a reload.


And from a little later:

router>sho cef not-cef-switched
CEF Packets passed on to next switching layer
Slot  No_adj No_encap Unsupp'ted Redirect  Receive  Options   Access
Frag
RP    519815       0           0      135  9231624        0        0
 0

router>sho int switching
FastEthernet0/0 Trunk to cat2924-pri
          Throttle count          0
                   Drops         RP      66318         SP          0
             SPD Flushes       Fast          0        SSE          0
             SPD Aggress       Fast          0
            SPD Priority     Inputs  434360075      Drops         14

    Protocol  IP
          Switching path    Pkts In   Chars In   Pkts Out  Chars Out
                 Process  444113247 4130580154  451036862 1625391199
            Cache misses    3165442          -          -          -
                    Fast  821810302 2800528162  818586397 1070317319
               Auton/SSE          0          0          0          0

    Protocol  DEC MOP
          Switching path    Pkts In   Chars In   Pkts Out  Chars Out
                 Process          0          0      88724    6831748
            Cache misses          0          -          -          -
                    Fast          0          0          0          0
               Auton/SSE          0          0          0          0

    Protocol  ARP
          Switching path    Pkts In   Chars In   Pkts Out  Chars Out
                 Process     591727   35551580     880393   56345152
            Cache misses          0          -          -          -
                    Fast          0          0          0          0
               Auton/SSE          0          0          0          0

    Protocol  CDP
          Switching path    Pkts In   Chars In   Pkts Out  Chars Out
                 Process     889122  350314068     889609  310472734
            Cache misses          0          -          -          -
                    Fast          0          0          0          0
               Auton/SSE          0          0          0          0

    Protocol  Other
          Switching path    Pkts In   Chars In   Pkts Out  Chars Out
                 Process          3       1182    5337537  320252220
            Cache misses          0          -          -          -
                    Fast          0          0          0          0
               Auton/SSE          0          0          0          0

    NOTE: all counts are cumulative and reset only after a reload.

Also:

CPU utilization for five seconds: 64%/61%; one minute: 54%; five minutes:
50%
 PID Runtime(ms)   Invoked      uSecs   5Sec   1Min   5Min TTY Process
 57   213461156 440960100        484  0.16%  0.18%  0.17%   0 IP Input


On Wed, Jul 29, 2009 at 10:57 AM, Mikael Abrahamsson <swmike at swm.pp.se>wrote:

> On Wed, 29 Jul 2009, Robert Johnson wrote:
>
>  Suggestions?
>>
>
> Please provide output from "show int switching" (not tab-completable) to
> verify that all traffic is cef switched.
>
> --
> Mikael Abrahamsson    email: swmike at swm.pp.se
>

From gert at greenie.muc.de  Wed Jul 29 13:50:41 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Wed, 29 Jul 2009 19:50:41 +0200
Subject: [c-nsp] Humor: Cisco announces end of BGP
In-Reply-To: <2C05E949E19A9146AF7BDF9D44085B863541D03D19@exchange.aoihq.local>
References: <005901ca0fc2$939d6bc0$0a00000a@nil.si>
	<4A6F66C2.1080400@justinshore.com>
	<2C05E949E19A9146AF7BDF9D44085B863541D03D0A@exchange.aoihq.local>
	<00c201ca103c$f6a82fa0$e3f88ee0$@com>
	<2C05E949E19A9146AF7BDF9D44085B863541D03D13@exchange.aoihq.local>
	<016201ca1059$664174e0$32c45ea0$@com>
	<20090729154706.GQ290@greenie.muc.de>
	<2C05E949E19A9146AF7BDF9D44085B863541D03D18@exchange.aoihq.local>
	<20090729162530.GB2898@virtual.bogons.net>
	<2C05E949E19A9146AF7BDF9D44085B863541D03D19@exchange.aoihq.local>
Message-ID: <20090729175041.GR290@greenie.muc.de>

Hi,

On Wed, Jul 29, 2009 at 12:47:15PM -0400, Eric Van Tol wrote:
> Last time I looked into it with Verio, they wanted close to $50/Meg on 
> a 5M commit, plus an additional MRC of $500 for IPv6.  

Which doesn't really make very much sense, indeed.

All our upstreams treat bits as bits, no matter which colour they have
- that is, v4 and v6 packets go over the same links, are counted as 
interface octets, and billing is based on these.

(Global Crossing tried to get us to sign up for "IPv6 commitment" and
"IPv4 commitment", we told them that this is a stupid approach to
things, and they dropped the idea...)

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/20090729/a917c795/attachment-0001.bin>

From trejrco at gmail.com  Wed Jul 29 14:00:23 2009
From: trejrco at gmail.com (TJ)
Date: Wed, 29 Jul 2009 14:00:23 -0400
Subject: [c-nsp] Humor: Cisco announces end of BGP
In-Reply-To: <4A708339.5020700@uk.clara.net>
References: <5.1.0.14.2.20090728104929.051778f8@efes.iucc.ac.il>	<4A6F2DD0.1060608@justinshore.com>	<005901ca0fc2$939d6bc0$0a00000a@nil.si>	<4A6F66C2.1080400@justinshore.com>	<2C05E949E19A9146AF7BDF9D44085B863541D03D0A@exchange.aoihq.local>	<00c201ca103c$f6a82fa0$e3f88ee0$@com>	<2C05E949E19A9146AF7BDF9D44085B863541D03D13@exchange.aoihq.local>	<016201ca1059$664174e0$32c45ea0$@com>	<20090729154706.GQ290@greenie.muc.de>	<020201ca106b$e8b6a730$ba23f590$@com>
	<4A708339.5020700@uk.clara.net>
Message-ID: <025401ca1076$74a53590$5defa0b0$@com>

>-----Original Message-----
>From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
>bounces at puck.nether.net] On Behalf Of David Freedman
>> Good point ... in fact, we had NTT/Verio for a bit.  Wish we still did
>> (even if they were doing the whole "/126 on point to point links" think).
>> (I meant to include that some carriers do fully offer IPv6 today, but
>> somehow edited that out ... my bad)
>
>And what, prey tell is wrong with "/126 on point to point links", you want
to
>use SLAAC between routers?

_Prey_ tell?  :)

Nothing is wrong, per se.  It certainly works.  Oh, and I don't believe I
said anything about SLAAC.
However, there have been numerous conversations back and forth, on many
sides of this.

My feeling is based on two things:
I don't like the idea of vendors/providers ignoring an RFC just because.  
	And note the RFC in question leaves no wiggle room here.
		If a different solution is better, codify it in a draft, get
community consensus and get it ratified in a RFC.
	Not saying the IETF is always right, but I'd prefer any such
disagreement gets vetted by as many eyes as possible.
		In this case there are lots of things that assume 64bits of
host space - most aren't relevant to PtP links, but still ... 
	
Aggregation
	IMHO the most efficient solution is to burn one of the client's /64s
on the client-facing link 
		... one covering prefix for entire client, including CPE.

IIRC there was some chatter about using /127s (again), dumping the subnet
router anycast address (for security reasons, I believe).
	I'd have the same thing to say to that conversation - get some loose
consensus pre-implementation.


In closing, I guess I would turn it around and say "provide me a "really
good reason" to not use /64s as dictated" ...
	


Again, /126 works just fine - otherwise I wouldn't be wishing for NTT/Verio
to be my SP again ;).
/TJ


From sethm at rollernet.us  Wed Jul 29 14:04:04 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Wed, 29 Jul 2009 11:04:04 -0700
Subject: [c-nsp] Humor: Cisco announces end of BGP
In-Reply-To: <003c01ca1063$0335e1b0$09a1a510$@com>
References: <003c01ca1063$0335e1b0$09a1a510$@com>
Message-ID: <4A708F14.8000907@rollernet.us>

Robert VanOrmer wrote:
> Verizon: IPv6!
> 
>  
> 
> We do have a IPv6 transport from Verizon, granted. (1) good luck globally
> routing your /48 outside of VZB land, they won't do it unless your providing
> a /32, and if you have been delegated any address space from an RIR, (2)
> good luck getting delegated addressing from Verizon's chunk, they require
> you to return any space delegated by an RIR before they will provide any of
> there own. we are stuck in that Catch-22, but they are offering services.
> Shows the lack of maturity in IPv6, but it's coming.
> 

Ouch, really? I'm supposed to be turning up a new Verizon circuit this
week or next. I guess I'll find out. I'll probably try refusing to
accept it if they give me any BS about routing my /48 that's already
working.

~Seth

From walter.keen at RainierConnect.net  Wed Jul 29 14:04:29 2009
From: walter.keen at RainierConnect.net (Walter Keen)
Date: Wed, 29 Jul 2009 11:04:29 -0700
Subject: [c-nsp] BFD + BGP on 7600 SRC or SRD
Message-ID: <4A708F2D.6010207@rainierconnect.net>

Hi, I'm looking at using BFD with BGP on 7600's (rsp720's and sup720-3b) 
and was wondering if there were any known issues with certain IOS's in 
the SRC or SRD train.



-- 


Walter Keen
Network Technician
Rainier Connect


From randy_94108 at yahoo.com  Wed Jul 29 14:09:33 2009
From: randy_94108 at yahoo.com (Randy)
Date: Wed, 29 Jul 2009 11:09:33 -0700 (PDT)
Subject: [c-nsp] VPN clients on Cisco ASA
Message-ID: <367644.3722.qm@web80502.mail.mud.yahoo.com>

Gert,
?
1) DPD on site-to-site vpn tunnels: I have used regularly and without issues.(dpd b/w cisco and 3com wouldn't work unless it has been fixed recently)
2) DPD with cisco VPN clients-to-ASA: I have had issues with.(on older versions of vpn clients).
Regards,
./Randy


--- On Wed, 7/29/09, Gert Doering <gert at greenie.muc.de> wrote:


From: Gert Doering <gert at greenie.muc.de>
Subject: Re: [c-nsp] VPN clients on Cisco ASA
To: "Randy" <randy_94108 at yahoo.com>
Cc: " Kiran @ London SMCOddiraju" <Kiran.Oddiraju at cbre.com>, cisco-nsp at puck.nether.net
Date: Wednesday, July 29, 2009, 1:20 AM


Hi,

On Tue, Jul 28, 2009 at 02:12:31PM -0700, Randy wrote:
> 4) Also disable DPD(no isakmp keepalive. 

Why?

I haven't experienced any issues with DPD yet, but I regularily see people
recommending to turn off DPD, or blaim other issues (like "rekeying doesn't
work") on DPD - so I wonder what I'm missing here.

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 swmike at swm.pp.se  Wed Jul 29 14:16:38 2009
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Wed, 29 Jul 2009 20:16:38 +0200 (CEST)
Subject: [c-nsp] BFD + BGP on 7600 SRC or SRD
In-Reply-To: <4A708F2D.6010207@rainierconnect.net>
References: <4A708F2D.6010207@rainierconnect.net>
Message-ID: <alpine.DEB.1.10.0907292015420.5086@uplift.swm.pp.se>

On Wed, 29 Jul 2009, Walter Keen wrote:

> Hi, I'm looking at using BFD with BGP on 7600's (rsp720's and sup720-3b) and 
> was wondering if there were any known issues with certain IOS's in the SRC or 
> SRD train.

SRC4 is has memory corruption bug with BFD running, this is a "crash and 
reload" type of bug.

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

From me at falz.net  Wed Jul 29 14:04:07 2009
From: me at falz.net (falz)
Date: Wed, 29 Jul 2009 13:04:07 -0500
Subject: [c-nsp] Manually set WS-X6148-GE-TX MTU size (1500, 1518)
Message-ID: <a62d17300907291104x7d92aa39qd47f796d84608220@mail.gmail.com>

Specs on WS-X6148-GE-TX say there is a maximum MTU of 1518:

http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/product_data_sheet0900aecd8017376e_ps4835_Products_Data_Sheet.html

However, on a 6500 running SXH, it will not let me use the mtu command
to adjust. I am trying to up the MTU for MPLS. Any way to do this
manually or is this something that's supported in hardware and
automatically upped slightly if a port were a trunk port, for example?

Trying to avoid purchasing WS-X6516-GE-TX or WS-X6748-GE-TX if possible.

From rubensk at gmail.com  Wed Jul 29 14:36:23 2009
From: rubensk at gmail.com (Rubens Kuhl)
Date: Wed, 29 Jul 2009 15:36:23 -0300
Subject: [c-nsp] Humor: Cisco announces end of BGP
In-Reply-To: <5.1.0.14.2.20090728104929.051778f8@efes.iucc.ac.il>
References: <5.1.0.14.2.20090728104929.051778f8@efes.iucc.ac.il>
Message-ID: <6bb5f5b10907291136s2f2d86a9t5cf6de6c18a25e4@mail.gmail.com>

Hank,

Any news on what exactly was EOL'ed ?


Rubens


On Tue, Jul 28, 2009 at 4:50 AM, Hank Nussbacher <hank at efes.iucc.ac.il> wrote:
>
> I just got this product alert from Cisco:
>
>> From: CiscoNotificationService at cisco.com
>> To: hank at efes.iucc.ac.il
>> Subject: Cisco Notification Alert -Alerts_Daily-07/28/2009 07:38 GMT
>>
>>
>> Cisco Notification Service Alert:
>>
>> Cisco Notification Alert -Alerts_Daily-07/28/2009 07:38 GMT
>>
>> End-of-Sale and End-of-Life Announcements-Border Gateway Protocol (BGP)-07/27/2009 08:44 GMT-07/28/2009 07:35 GMT
>
> What exactly does Cisco have planned as a replacement? ?:-)
>
> -Hank
>
>
> _______________________________________________
> cisco-nsp mailing list ?cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

From hank at efes.iucc.ac.il  Wed Jul 29 14:43:16 2009
From: hank at efes.iucc.ac.il (Hank Nussbacher)
Date: Wed, 29 Jul 2009 21:43:16 +0300
Subject: [c-nsp] Humor: Cisco announces end of BGP
In-Reply-To: <6bb5f5b10907291136s2f2d86a9t5cf6de6c18a25e4@mail.gmail.com
 >
References: <5.1.0.14.2.20090728104929.051778f8@efes.iucc.ac.il>
	<5.1.0.14.2.20090728104929.051778f8@efes.iucc.ac.il>
Message-ID: <5.1.0.14.2.20090729214300.00c30758@efes.iucc.ac.il>

At 15:36 29/07/2009 -0300, Rubens Kuhl wrote:
>Hank,
>
>Any news on what exactly was EOL'ed ?

I think it was a mistake on their part.

-Hank



>Rubens
>
>
>On Tue, Jul 28, 2009 at 4:50 AM, Hank Nussbacher <hank at efes.iucc.ac.il> wrote:
> >
> > I just got this product alert from Cisco:
> >
> >> From: CiscoNotificationService at cisco.com
> >> To: hank at efes.iucc.ac.il
> >> Subject: Cisco Notification Alert -Alerts_Daily-07/28/2009 07:38 GMT
> >>
> >>
> >> Cisco Notification Service Alert:
> >>
> >> Cisco Notification Alert -Alerts_Daily-07/28/2009 07:38 GMT
> >>
> >> End-of-Sale and End-of-Life Announcements-Border Gateway Protocol 
> (BGP)-07/27/2009 08:44 GMT-07/28/2009 07:35 GMT
> >
> > What exactly does Cisco have planned as a replacement?  :-)
> >
> > -Hank
> >
> >
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/


From mksmith at adhost.com  Wed Jul 29 14:46:54 2009
From: mksmith at adhost.com (Michael K. Smith - Adhost)
Date: Wed, 29 Jul 2009 11:46:54 -0700
Subject: [c-nsp] Humor: Cisco announces end of BGP
In-Reply-To: <4A708F14.8000907@rollernet.us>
References: <003c01ca1063$0335e1b0$09a1a510$@com>
	<4A708F14.8000907@rollernet.us>
Message-ID: <17838240D9A5544AAA5FF95F8D5203160676B6AE@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 Seth Mattinen
> Sent: Wednesday, July 29, 2009 11:04 AM
> To: Robert VanOrmer
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] Humor: Cisco announces end of BGP
> 
> Robert VanOrmer wrote:
> > Verizon: IPv6!
> >
> >
> >
> > We do have a IPv6 transport from Verizon, granted. (1) good luck
> globally
> > routing your /48 outside of VZB land, they won't do it unless your
> providing
> > a /32, and if you have been delegated any address space from an RIR,
> (2)
> > good luck getting delegated addressing from Verizon's chunk, they
> require
> > you to return any space delegated by an RIR before they will provide
> any of
> > there own. we are stuck in that Catch-22, but they are offering
> services.
> > Shows the lack of maturity in IPv6, but it's coming.
> >
> 
> Ouch, really? I'm supposed to be turning up a new Verizon circuit this
> week or next. I guess I'll find out. I'll probably try refusing to
> accept it if they give me any BS about routing my /48 that's already
> working.
> 
> ~Seth

I'm pretty sure their policy is to not route /48's *at all*.  Looking at
a 'sho bgp ipv6 regexp _701_' seems to support this.  There have also
been discussions on the ARIN mailing lists to this effect.

Mike

From kevin at gannons.net  Wed Jul 29 14:00:36 2009
From: kevin at gannons.net (kevin gannon)
Date: Wed, 29 Jul 2009 19:00:36 +0100
Subject: [c-nsp] OT: Network Automation in an MSP ?
Message-ID: <17eef0950907291100r684dff9frbcbaf22bc83ac853@mail.gmail.com>

I would love to hear from anyone using HP NAS in a MSP/Multi tenant setup
offline ?

Or anyone else doing configuration/provisioning/software management in a MSP
setup ?

Thanks and regards
Kevin

From sthaug at nethelp.no  Wed Jul 29 14:54:56 2009
From: sthaug at nethelp.no (sthaug at nethelp.no)
Date: Wed, 29 Jul 2009 20:54:56 +0200 (CEST)
Subject: [c-nsp] Humor: Cisco announces end of BGP
In-Reply-To: <025401ca1076$74a53590$5defa0b0$@com>
References: <020201ca106b$e8b6a730$ba23f590$@com>
	<4A708339.5020700@uk.clara.net>
	<025401ca1076$74a53590$5defa0b0$@com>
Message-ID: <20090729.205456.74738911.sthaug@nethelp.no>

> My feeling is based on two things:
> I don't like the idea of vendors/providers ignoring an RFC just because.  
> 	And note the RFC in question leaves no wiggle room here.

Please cite chapter and verse. As long as you use static IPv6
addresses, /126 is fine. No, a /126 address does *not* have to be
based on a 64 bit interface ID.

Steinar Haug, Nethelp consulting, sthaug at nethelp.no

From gsgranados at comcast.net  Wed Jul 29 14:55:21 2009
From: gsgranados at comcast.net (Scott Granados)
Date: Wed, 29 Jul 2009 11:55:21 -0700
Subject: [c-nsp] ASA5500 logging / diagnostic question.
Message-ID: <00a501ca107e$23e0a8d0$2208120a@am.thmulti.com>

Hi, I have what's probably an obvious question but googling isn't returning 
an obvious answer.

I'm installing a pair of new ASA5500 devices for the purposes of providing 
VPN connectivity to users running the Cisco VPN Client and also two lan to 
lan sessions.  When I try to connect from a client the client never goes to 
the authentication stage and after about 10 seconds drops.  What are some 
good logging options to have set for debugging connections (especially in a 
first time installation) and could someone post a good syslog portion from 
their ASA that will send appropriate data to a syslog server?  Right now I 
seem to be gathering data on connections that are built or taken down but no 
warning or error messages.  Any pointers would be appreciated.

Thanks
Scott


From Steven.Raymond at integratelecom.com  Wed Jul 29 14:56:47 2009
From: Steven.Raymond at integratelecom.com (Raymond, Steven)
Date: Wed, 29 Jul 2009 11:56:47 -0700
Subject: [c-nsp] BFD + BGP on 7600 SRC or SRD
In-Reply-To: <4A708F2D.6010207@rainierconnect.net>
References: <4A708F2D.6010207@rainierconnect.net>
Message-ID: <775A75B5625C6B418FC01477094E0BCC259C886965@IDCMAILBOX1.ads.integratelecom.com>

> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> bounces at puck.nether.net] On Behalf Of Walter Keen
> Sent: Wednesday, July 29, 2009 11:04 AM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] BFD + BGP on 7600 SRC or SRD
>
> Hi, I'm looking at using BFD with BGP on 7600's (rsp720's and sup720-3b)
> and was wondering if there were any known issues with certain IOS's in
> the SRC or SRD train.

We saw significant BFD bouncing issues on 12.2(33)SRC3 sup720 and ended up disabling it.  SRC3 on RSP720 did not have the same problem, and SRD2 with either proc seems okay.

Did not get a bug id, sorry.


From rwest at zyedge.com  Wed Jul 29 15:03:58 2009
From: rwest at zyedge.com (Ryan West)
Date: Wed, 29 Jul 2009 15:03:58 -0400
Subject: [c-nsp] ASA5500 logging / diagnostic question.
In-Reply-To: <00a501ca107e$23e0a8d0$2208120a@am.thmulti.com>
References: <00a501ca107e$23e0a8d0$2208120a@am.thmulti.com>
Message-ID: <6E21B2BDEF6E714EA0B5BA8D5D0E14012489DA29A8@zy-ex1.zyedge.local>

Scott,

If you want debug on a temporary basis for that traffic, you can try 'deb cry isa 2' (or higher than 2, but normally that's enough).  Another option is to use logging classes to troubleshoot just the VPN.  Here is an example:

logging class vpn monitor debugging

Assuming you have nothing else configured for monitor logging, a term mon will show just this traffic.

-ryan

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Scott Granados
Sent: Wednesday, July 29, 2009 2:55 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] ASA5500 logging / diagnostic question.

Hi, I have what's probably an obvious question but googling isn't returning 
an obvious answer.

I'm installing a pair of new ASA5500 devices for the purposes of providing 
VPN connectivity to users running the Cisco VPN Client and also two lan to 
lan sessions.  When I try to connect from a client the client never goes to 
the authentication stage and after about 10 seconds drops.  What are some 
good logging options to have set for debugging connections (especially in a 
first time installation) and could someone post a good syslog portion from 
their ASA that will send appropriate data to a syslog server?  Right now I 
seem to be gathering data on connections that are built or taken down but no 
warning or error messages.  Any pointers would be appreciated.

Thanks
Scott

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

From lobotiger at gmail.com  Wed Jul 29 15:05:11 2009
From: lobotiger at gmail.com (Lobo)
Date: Wed, 29 Jul 2009 15:05:11 -0400
Subject: [c-nsp] 3750 switch dropping packets when trust dscp enabled
Message-ID: <4A709D67.4050003@gmail.com>

I've been testing our different model of switches to allow for DSCP 
transparency by using the "mls qos trust dscp" command on their 
interfaces.  All of the switches seem to support this properly and I can 
tell when they're overwriting versus allowing the DSCP to continue 
through but I came across one unique problem with the 3750 series.

I setup a traffic generator to send 95Mbps of traffic with DSCP EF (46) 
across the different switches but when it hit the 3750, the egress 
traffic was only ~4Mbps.  Note that this is from a switch that has the 
default configuration with mls qos turned on globally and the "mls qos 
trust dscp" command put on the ingress and egress interfaces.  Nothing else.

After reading up a bit, I found a command "srr-queue bandwidth shape" 
that I could apply to the interfaces.  After adding that command with 
all 0s for the queues I was then able to receive all 95Mbps of traffic.  
I noticed that the default values for that command are 25 0 0 0.

Is this something that I'm supposed to do if I just want to trust the 
DSCP markings and not overwrite them on the 3750s?  I don't have a need 
for QoS (at the moment) and all my other Catalyst switches don't require 
it so I'm just curious if I'm doing anything wrong for this model of 
Catalyst.  Note that I don't see this issue if I change my packets to 
all go with DSCP of 0.

Thanks everyone.

Jose

From kloch at kl.net  Wed Jul 29 15:06:10 2009
From: kloch at kl.net (Kevin Loch)
Date: Wed, 29 Jul 2009 15:06:10 -0400
Subject: [c-nsp] Humor: Cisco announces end of BGP
In-Reply-To: <025401ca1076$74a53590$5defa0b0$@com>
References: <5.1.0.14.2.20090728104929.051778f8@efes.iucc.ac.il>	<4A6F2DD0.1060608@justinshore.com>	<005901ca0fc2$939d6bc0$0a00000a@nil.si>	<4A6F66C2.1080400@justinshore.com>	<2C05E949E19A9146AF7BDF9D44085B863541D03D0A@exchange.aoihq.local>	<00c201ca103c$f6a82fa0$e3f88ee0$@com>	<2C05E949E19A9146AF7BDF9D44085B863541D03D13@exchange.aoihq.local>	<016201ca1059$664174e0$32c45ea0$@com>	<20090729154706.GQ290@greenie.muc.de>	<020201ca106b$e8b6a730$ba23f590$@com>	<4A708339.5020700@uk.clara.net>
	<025401ca1076$74a53590$5defa0b0$@com>
Message-ID: <4A709DA2.6020501@kl.net>

TJ wrote:
>> -----Original Message-----
>> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
>> bounces at puck.nether.net] On Behalf Of David Freedman
>> And what, prey tell is wrong with "/126 on point to point links", you want
>> to use SLAAC between routers?
> 
> Nothing is wrong, per se.  It certainly works.  Oh, and I don't believe I
> said anything about SLAAC.
> However, there have been numerous conversations back and forth, on many
> sides of this.
> 
> My feeling is based on two things:
> I don't like the idea of vendors/providers ignoring an RFC just because.  
> 	And note the RFC in question leaves no wiggle room here.
> 		If a different solution is better, codify it in a draft, get
> community consensus and get it ratified in a RFC.
> 	Not saying the IETF is always right, but I'd prefer any such
> disagreement gets vetted by as many eyes as possible.
> 		In this case there are lots of things that assume 64bits of
> host space - most aren't relevant to PtP links, but still ... 
> 	
> Aggregation
> 	IMHO the most efficient solution is to burn one of the client's /64s
> on the client-facing link 
> 		... one covering prefix for entire client, including CPE.
> 
> IIRC there was some chatter about using /127s (again), dumping the subnet
> router anycast address (for security reasons, I believe).
> 	I'd have the same thing to say to that conversation - get some loose
> consensus pre-implementation.

Lots of folks, myself included use /112 for point to point links, server
only subnets and just about anything that doesn't require RA's (which is
almost everything in a hosting environment).  /112 is a convenient
bit boundary to work with and one size fits all (p-p and multipoint)
applications.

> In closing, I guess I would turn it around and say "provide me a "really
> good reason" to not use /64s as dictated" ...

Making it difficult for autoconf to work on certain subnets is a big
plus.

- Kevin

From sethm at rollernet.us  Wed Jul 29 15:25:10 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Wed, 29 Jul 2009 12:25:10 -0700
Subject: [c-nsp] Humor: Cisco announces end of BGP
In-Reply-To: <17838240D9A5544AAA5FF95F8D5203160676B6AE@ad-exh01.adhost.lan>
References: <003c01ca1063$0335e1b0$09a1a510$@com>
	<4A708F14.8000907@rollernet.us>
	<17838240D9A5544AAA5FF95F8D5203160676B6AE@ad-exh01.adhost.lan>
Message-ID: <4A70A216.7030304@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 Seth Mattinen
>> Sent: Wednesday, July 29, 2009 11:04 AM
>> To: Robert VanOrmer
>> Cc: cisco-nsp at puck.nether.net
>> Subject: Re: [c-nsp] Humor: Cisco announces end of BGP
>>
>> Robert VanOrmer wrote:
>>> Verizon: IPv6!
>>>
>>>
>>>
>>> We do have a IPv6 transport from Verizon, granted. (1) good luck
>> globally
>>> routing your /48 outside of VZB land, they won't do it unless your
>> providing
>>> a /32, and if you have been delegated any address space from an RIR,
>> (2)
>>> good luck getting delegated addressing from Verizon's chunk, they
>> require
>>> you to return any space delegated by an RIR before they will provide
>> any of
>>> there own. we are stuck in that Catch-22, but they are offering
>> services.
>>> Shows the lack of maturity in IPv6, but it's coming.
>>>
>> Ouch, really? I'm supposed to be turning up a new Verizon circuit this
>> week or next. I guess I'll find out. I'll probably try refusing to
>> accept it if they give me any BS about routing my /48 that's already
>> working.
>>
>> ~Seth
> 
> I'm pretty sure their policy is to not route /48's *at all*.  Looking at
> a 'sho bgp ipv6 regexp _701_' seems to support this.  There have also
> been discussions on the ARIN mailing lists to this effect.
> 

It's a good thing I put it in writing. ;) They didn't say anything to
the contrary when I placed the order.

~Seth

From gtb at slac.stanford.edu  Wed Jul 29 15:29:47 2009
From: gtb at slac.stanford.edu (Buhrmaster, Gary)
Date: Wed, 29 Jul 2009 12:29:47 -0700
Subject: [c-nsp] Humor: Cisco announces end of BGP
In-Reply-To: <5.1.0.14.2.20090729214300.00c30758@efes.iucc.ac.il>
References: <5.1.0.14.2.20090728104929.051778f8@efes.iucc.ac.il><5.1.0.14.2.20090728104929.051778f8@efes.iucc.ac.il>
	<5.1.0.14.2.20090729214300.00c30758@efes.iucc.ac.il>
Message-ID: <D0D0330CBD07114D85B70B784E80C2F2022FD38C@exch-mail2.win.slac.stanford.edu>

> At 15:36 29/07/2009 -0300, Rubens Kuhl wrote:
> >Hank,
> >
> >Any news on what exactly was EOL'ed ?
> 
> I think it was a mistake on their part.

When I saw it I thought it was one of the (various)
license options that we all (were supposed to have)
bought to run BGP on certain boxes, and that Cisco
has recently been bundling into the IOS licenses
(technically, it was the InterDomain Routing License
option as I recall, but that meant BGP).  So it
certainly made sense for the license to be EOL'd.
So, I never bothered to look further.

BGP worked with or without the license (no checks
in IOS), but one was supposed to license the use
of BGP, which we did (for the 7200s, the 7500s, and
the 6500s where appropriate).

Cisco makes it difficult to determine the license
requirements for features.  A gold star for those
that knew (ahead of time) that they needed to
purchase the FR-IOSSLB license.

Gary 

From nbernadeau at gallantsys.com  Wed Jul 29 16:41:27 2009
From: nbernadeau at gallantsys.com (Nathaniel Bernadeau)
Date: Wed, 29 Jul 2009 16:41:27 -0400
Subject: [c-nsp] Question CISCO3845-V/K9 Voice Bundle
Message-ID: <4A70B3F7.2040204@gallantsys.com>

Does anyone know how many PVDM2-64 comes with this unit? What is the 
total number of voice channels included in this unit?

-- 
regards,

Nathaniel Bernadeau
Gallant Systems,  LLC
11064 Livingston RD Suite 106-C
Fort Washington, MD 20744
Toll Free: 888-836-3751
Ph: 301-627-6358
Fax: 240-823-6897
Cell: 202-246-2229
nbernadeau at gallantsys.com
www.gallantsys.com


From zeusdadog at gmail.com  Wed Jul 29 16:42:45 2009
From: zeusdadog at gmail.com (Jay Nakamura)
Date: Wed, 29 Jul 2009 16:42:45 -0400
Subject: [c-nsp] DMVPN and OSPF
Message-ID: <9418aca70907291342u477505b0vf9c937dfb7d767ed@mail.gmail.com>

Has anyone seen this symptom?

1841, advanced IP feature set
DMVPN spoke and OSPF over the DMVPN

Running 12.4(24)T

Periodically, the router looses all it's OSPF routes and stays that
way.  Clearing the DMVPN or OSPF process does nothing.  It recreates
the OSPF session with neighbor but it still has no routes.  It can't
seem to re-connect to the backup DMVPN hub either.

Router still routes to the static default route for internet traffic
and everything else seems normal.  Just can't get to the VPN network.

It's really not doing anything fancy other than DMVPN and OSPF.

From sethm at rollernet.us  Wed Jul 29 16:56:10 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Wed, 29 Jul 2009 13:56:10 -0700
Subject: [c-nsp] DMVPN and OSPF
In-Reply-To: <9418aca70907291342u477505b0vf9c937dfb7d767ed@mail.gmail.com>
References: <9418aca70907291342u477505b0vf9c937dfb7d767ed@mail.gmail.com>
Message-ID: <4A70B76A.9010400@rollernet.us>

Jay Nakamura wrote:
> Has anyone seen this symptom?
> 
> 1841, advanced IP feature set
> DMVPN spoke and OSPF over the DMVPN
> 
> Running 12.4(24)T
> 
> Periodically, the router looses all it's OSPF routes and stays that
> way.  Clearing the DMVPN or OSPF process does nothing.  It recreates
> the OSPF session with neighbor but it still has no routes.  It can't
> seem to re-connect to the backup DMVPN hub either.
> 
> Router still routes to the static default route for internet traffic
> and everything else seems normal.  Just can't get to the VPN network.
> 
> It's really not doing anything fancy other than DMVPN and OSPF.


I have an 877W running 12.4(15)T6 doing the same OSPF over DMVPN and
I've never had that problem. According to the flash timestamp I've had
it at that version since Sep 9 2008. My DMVPN hub is a 2620XM running
12.4(10a).

~Seth

From rwest at zyedge.com  Wed Jul 29 16:56:43 2009
From: rwest at zyedge.com (Ryan West)
Date: Wed, 29 Jul 2009 16:56:43 -0400
Subject: [c-nsp] Question CISCO3845-V/K9 Voice Bundle
In-Reply-To: <4A70B3F7.2040204@gallantsys.com>
References: <4A70B3F7.2040204@gallantsys.com>
Message-ID: <6E21B2BDEF6E714EA0B5BA8D5D0E14012489DA29DB@zy-ex1.zyedge.local>

Hi,

The bundle ships one PVDM2-64 base.

CISCO3845-V/K9
 3845 Voice Bundle,PVDM2-64,SP Serv,64F/256D

-ryan

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Nathaniel Bernadeau
Sent: Wednesday, July 29, 2009 4:41 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Question CISCO3845-V/K9 Voice Bundle

Does anyone know how many PVDM2-64 comes with this unit? What is the 
total number of voice channels included in this unit?

-- 
regards,

Nathaniel Bernadeau
Gallant Systems,  LLC
11064 Livingston RD Suite 106-C
Fort Washington, MD 20744
Toll Free: 888-836-3751
Ph: 301-627-6358
Fax: 240-823-6897
Cell: 202-246-2229
nbernadeau at gallantsys.com
www.gallantsys.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 Grzegorz at Janoszka.pl  Wed Jul 29 17:12:03 2009
From: Grzegorz at Janoszka.pl (Grzegorz Janoszka)
Date: Wed, 29 Jul 2009 23:12:03 +0200
Subject: [c-nsp] Freezing counters at 6500
In-Reply-To: <4A7067C3.7090200@kl.net>
References: <4A6F6A2D.40101@Janoszka.pl> <4A7067C3.7090200@kl.net>
Message-ID: <4A70BB23.1090403@Janoszka.pl>

Kevin Loch wrote:
> Try adjusting 'service counters max age' to zero if you haven't already.

It has not changed anything.

> As others have pointed out a delay of 3-4 minutes is not normal
> What does your SP (not RP) cpu usage look like?  Try disabling netflow
> if your SP cpu usage is maxing out.

Disabling netflow helps. But the SP is not so heavily loaded:

#remote command switch sh proc cpu | i seco
CPU utilization for five seconds: 19%/1%; one minute: 41%; five minutes: 40%

#remote command switch sh proc cpu | i NDE
  269          64         1      64000  0.00%  0.00%  0.00%   0 Netflow 
NDE Task
  470    21333328   1711723      12463  3.19%  5.75%  5.67%   0 NDE - IPV4
  471        1120     95010         11  0.00%  0.00%  0.00%   0 NDE - MPLS
  472         792     95010          8  0.00%  0.00%  0.00%   0 NDE - L2
  473      805240    158391       5083  0.00%  0.00%  0.00%   0 NDE - IPV6

-- 
Grzegorz Janoszka

From teddy.asrat at africaonline.co.sz  Wed Jul 29 17:07:35 2009
From: teddy.asrat at africaonline.co.sz (Teddy A.)
Date: Wed, 29 Jul 2009 23:07:35 +0200
Subject: [c-nsp] CISCO AS5300 Shuts Down Abruptly
Message-ID: <007f01ca1090$99a91310$ccfb3930$@asrat@africaonline.co.sz>

Hi, I have been struggling with this issue for almost 10 days now. I have a
Cisco AS5300 which is being used as an NAS for Dialup and ISDN clients. A
few days back it shut down abruptly and I had to pull out the power cord
from the back and plug it back in again to start it up, since then now it is
shutting down every 5min or so. I have tried to connect the console cable
and monitor to see if there are any error logs or anything it shows before
going down, but there is nothing, it just dies. 

 

I have tried to strip it down and clean everything, the fans the modems, the
PRI cards, everything, but the problem is still the same. It even does is
with everything disconnected. I have tried to reload the IOS and have erased
all the configurations to no avail.

 

Don't know what is wrong, or what to do next? Please help . 

 

Kind Regards,

 

Teddy A.



 


From akspitz at cascadehealthcare.org  Wed Jul 29 19:06:29 2009
From: akspitz at cascadehealthcare.org (Aaron Spitz)
Date: Wed, 29 Jul 2009 16:06:29 -0700
Subject: [c-nsp] VSS question...
In-Reply-To: <20090729083813.GA11906@lboro.ac.uk>
References: <4A6FAE95.6010806@utc.edu>
	<20090729081252.GB11496@lboro.ac.uk><4A7005ED.7060305@rollernet.us>
	<20090729083813.GA11906@lboro.ac.uk>
Message-ID: <44C483CB52659549BA199961AEFAD717257FCB@b-exch-recovery.internal.scmc.org>

It's a 20Gb starter if you use both 10G ports on each sup, which has
worked fine for us with relatively light use.  According to the sales
pitch, it is also trivial to bond up to eight ports from a 10G line card
to increase the backplane between chassis.  We installed VSS as a
datacenter core about a year ago and it has been totally peachy except
for some random crashes that were fixed in SXH4.  With a pair of 3750G's
top of rack, I say good riddance to STP!


Aaron Spitz
Network Analyst
Cascade Healthcare Community
akspitz at cascadehealthcare.org

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Alan Buxey
Sent: Wednesday, July 29, 2009 1:38 AM
To: Seth Mattinen
Cc: 'NSP List'
Subject: Re: [c-nsp] VSS question...

Hi,

> So, 3750 stack on steroids?

not really - with the 3750 you get a 32 or 64Gb backplane
stacking mechanism (stckwise or stackwise+) - whereas
with VSS its a 10Gb starter...

alan


Important Notice: This e-mail, including any attachment, contains information that may be confidential or privileged. If you are not the intended recipient of this e-mail, please delete it and do not copy, save or distribute any copies of it.  Nothing in this e-mail, including any attachment, is intended to be a legally-binding signature.



From jlewis at lewis.org  Wed Jul 29 20:18:18 2009
From: jlewis at lewis.org (Jon Lewis)
Date: Wed, 29 Jul 2009 20:18:18 -0400 (EDT)
Subject: [c-nsp] CISCO AS5300 Shuts Down Abruptly
In-Reply-To: <007f01ca1090$99a91310$ccfb3930$@asrat@africaonline.co.sz>
References: <007f01ca1090$99a91310$ccfb3930$@asrat@africaonline.co.sz>
Message-ID: <Pine.LNX.4.61.0907292014220.4187@soloth.lewis.org>

On Wed, 29 Jul 2009, Teddy A. wrote:

> Hi, I have been struggling with this issue for almost 10 days now. I have a
> Cisco AS5300 which is being used as an NAS for Dialup and ISDN clients. A
> few days back it shut down abruptly and I had to pull out the power cord
> from the back and plug it back in again to start it up, since then now it is
> shutting down every 5min or so. I have tried to connect the console cable
> and monitor to see if there are any error logs or anything it shows before
> going down, but there is nothing, it just dies.

If by shut down, you mean all the lights go out, fans stop, etc., then it 
sounds like you may have a power supply gone bad.  If you mean it stops 
working, but lights are on, fans are spinning, just the software's locked 
up, then it be all sorts of things.  If it's doing either of things with 
ethernet and PRIs disconnected, it's almost certainly a hardware/power 
issue...and not a software one.  You're probably going to have to replace 
the unit.

----------------------------------------------------------------------
  Jon Lewis                   |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

From brad.henshaw at qcn.com.au  Wed Jul 29 20:14:24 2009
From: brad.henshaw at qcn.com.au (Brad Henshaw)
Date: Thu, 30 Jul 2009 10:14:24 +1000
Subject: [c-nsp] 3750 switch dropping packets when trust dscp enabled
Message-ID: <8B25B862BC09784B9B74FB950D4F64D40F84BC@qcnapp01.corp.qcn>

 
Lobo wrote:

> I setup a traffic generator to send 95Mbps of traffic with DSCP EF
> (46) across the different switches but when it hit the 3750, the
> egress traffic was only ~4Mbps.

> After reading up a bit, I found a command "srr-queue bandwidth shape" 
> that I could apply to the interfaces.  After adding that command with
> all 0s for the queues I was then able to receive all 95Mbps of
traffic.  
> I noticed that the default values for that command are 25 0 0 0.

> Is this something that I'm supposed to do if I just want to trust the
> DSCP markings and not overwrite them on the 3750s?

This isn't a marking issue, it's a shaping issue. As you discovered, 
Queue 1 (to which DSCP 46 is mapped) is shaped to 1/25th of the port
capacity which is 4Mbps. This was causing your traffic to be
rate-limited
to 4Mbps (not remarked).

The shape command you entered effectively disables shaping and all
queues
will operate in shared mode.

You might want to think about the implications of permitting an
uncontrolled quantity of DSCP 46 traffic into your network, either now
or
at a later date.

Regards,
Brad

From rodunn at cisco.com  Wed Jul 29 22:10:33 2009
From: rodunn at cisco.com (Rodney Dunn)
Date: Wed, 29 Jul 2009 22:10:33 -0400
Subject: [c-nsp] DMVPN and OSPF
In-Reply-To: <9418aca70907291342u477505b0vf9c937dfb7d767ed@mail.gmail.com>
References: <9418aca70907291342u477505b0vf9c937dfb7d767ed@mail.gmail.com>
Message-ID: <4A710119.50503@cisco.com>

OSPF and DMVPN can be a bit funky.

Did you force the DR to be the hub by setting the priority?

I forgot, did you set it to broadcast or multipoint?

I'd suggest you look at the packet capture feature and get a trace when 
it's down.

Do you see the LSA's in the database?
Can you ping 224.0.0.5 and get a response?

Are the neighbors flapping?



Jay Nakamura wrote:
> Has anyone seen this symptom?
> 
> 1841, advanced IP feature set
> DMVPN spoke and OSPF over the DMVPN
> 
> Running 12.4(24)T
> 
> Periodically, the router looses all it's OSPF routes and stays that
> way.  Clearing the DMVPN or OSPF process does nothing.  It recreates
> the OSPF session with neighbor but it still has no routes.  It can't
> seem to re-connect to the backup DMVPN hub either.
> 
> Router still routes to the static default route for internet traffic
> and everything else seems normal.  Just can't get to the VPN network.
> 
> It's really not doing anything fancy other than DMVPN and OSPF.
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

From zeusdadog at gmail.com  Wed Jul 29 22:28:13 2009
From: zeusdadog at gmail.com (Jay Nakamura)
Date: Wed, 29 Jul 2009 22:28:13 -0400
Subject: [c-nsp] DMVPN and OSPF
In-Reply-To: <4A710119.50503@cisco.com>
References: <9418aca70907291342u477505b0vf9c937dfb7d767ed@mail.gmail.com>
	<4A710119.50503@cisco.com>
Message-ID: <9418aca70907291928k2c152e81xceb3eb6fc8f72ce4@mail.gmail.com>

> Did you force the DR to be the hub by setting the priority?

Yes.  And confirmed.

> I forgot, did you set it to broadcast or multipoint?

broadcast

> I'd suggest you look at the packet capture feature and get a trace when it's
> down.

Is this what you are referring to?

http://www.cisco.com/en/US/docs/ios/12_4t/12_4t11/ht_rawip.html#wp1049404

There is no tech onsite and it's a little far so I can't do it at the
moment but if I can't figure out anything else, that will be the next
step.

> Do you see the LSA's in the database?

I believe it was blank.  It's working now after a reboot so I can't
check but I will check next time it happens.

> Can you ping 224.0.0.5 and get a response?
>
> Are the neighbors flapping?

It didn't flap at all.  Routes just disappeared.  Well, that's not
100% true.  The backup hub VPN connection went down and it wouldn't
come up.  I could ping the primary hub tunnel IP when the routes were
gone but none of the other DMVPN peer IP.


> Jay Nakamura wrote:
>>
>> Has anyone seen this symptom?
>>
>> 1841, advanced IP feature set
>> DMVPN spoke and OSPF over the DMVPN
>>
>> Running 12.4(24)T
>>
>> Periodically, the router looses all it's OSPF routes and stays that
>> way. ?Clearing the DMVPN or OSPF process does nothing. ?It recreates
>> the OSPF session with neighbor but it still has no routes. ?It can't
>> seem to re-connect to the backup DMVPN hub either.
>>
>> Router still routes to the static default route for internet traffic
>> and everything else seems normal. ?Just can't get to the VPN network.
>>
>> It's really not doing anything fancy other than DMVPN and OSPF.
>> _______________________________________________
>> cisco-nsp mailing list ?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  Wed Jul 29 23:27:14 2009
From: justin at justinshore.com (Justin Shore)
Date: Wed, 29 Jul 2009 22:27:14 -0500
Subject: [c-nsp] BFD + BGP on 7600 SRC or SRD
In-Reply-To: <4A708F2D.6010207@rainierconnect.net>
References: <4A708F2D.6010207@rainierconnect.net>
Message-ID: <4A711312.206@justinshore.com>

Walter Keen wrote:
> Hi, I'm looking at using BFD with BGP on 7600's (rsp720's and sup720-3b) 
> and was wondering if there were any known issues with certain IOS's in 
> the SRC or SRD train.

BFD support for SVIs was removed with SRB2 if that's something that you 
think you'll need.

Justin


From justin at justinshore.com  Wed Jul 29 23:37:51 2009
From: justin at justinshore.com (Justin Shore)
Date: Wed, 29 Jul 2009 22:37:51 -0500
Subject: [c-nsp] CISCO AS5300 Shuts Down Abruptly
In-Reply-To: <Pine.LNX.4.61.0907292014220.4187@soloth.lewis.org>
References: <007f01ca1090$99a91310$ccfb3930$@asrat@africaonline.co.sz>
	<Pine.LNX.4.61.0907292014220.4187@soloth.lewis.org>
Message-ID: <4A71158F.1010303@justinshore.com>

Jon Lewis wrote:
> If by shut down, you mean all the lights go out, fans stop, etc., then 
> it sounds like you may have a power supply gone bad.  If you mean it 
> stops working, but lights are on, fans are spinning, just the software's 
> locked up, then it be all sorts of things.  If it's doing either of 
> things with ethernet and PRIs disconnected, it's almost certainly a 
> hardware/power issue...and not a software one.  You're probably going to 
> have to replace the unit.

I took down a 5300 that had been running for several years to move it 
out of the basement under our CO to the actual CO itself.  I hate doing 
that because that's when most hardware fails.  Once I had it reracked 
and cabled again I tried to power it on to no avail.  It would come on 
but would more or less sit there dumb as a post.  Ultimately I 
determined that the board with the 8x PRI interfaces had gone bad (I 
forget the 5300 terminology and LC names; my therapist has done a good 
job of repressing those memories).  New LCs couldn't be purchased any 
more.  Official refurbs weren't availble.  SmartNets could no longer be 
purchased either.

In the end I spent $34 and bought a 4x PRI replacement LC on eBay.  The 
5300 has been working ever since.  Our dialup numbers have dwindled so 
low since that box was maxxed out (2 5300s were maxed out at that POP 
back in the days) that no one even noticed the loss of modem capacity. 
I almost wish that the box had completely baked itself so I could 
justify killing off the service.  I dread getting a call about a dialup 
problem.  "You have dialup and you live in town?  Down the street from 
the CO?  #$%%^&*!!!!"

Justin




From cisco at peakpeak.com  Wed Jul 29 23:23:33 2009
From: cisco at peakpeak.com (Security Team)
Date: Wed, 29 Jul 2009 21:23:33 -0600
Subject: [c-nsp] Balancing T1's with CEF
Message-ID: <C6966E55.5C14%cisco@peakpeak.com>

I rebooted a 7507 router that had a site connected with 3 T1's and now all
the traffic is nailing one line instead of being distributed over all 3
using the static routes/CEF.

I did look at the Cisco troubleshooting tips but didn't see anything
immensely helpful.  Here is a config snippet on the 7507 side (it's
obviously nothing
whizzy).

Has anyone seen this before?  I did an ip clear cache and also tried doing a
shut/no shut on each line individually on the 7507, but the traffic to the
customer's
28xx router always sacks one line.  It seems like in the past I did some
kind of clear on the 7507 and things got better, but I can't recall what
that may have been.

Thanks,
CJ

7507 (all PA adapters on the same VIP) config. One T1 comes in on a chan DS3
card breaking out individual T1?s, and the other 2 T1?s come in on a 4-port
PA adapter T1 card. I?m not using dCEF since I have never had good luck with
it.

ip cef
!
interface Serial1/0/0/12:0
 bandwidth 1536
 ip address x.x.x.x y.y.y.y
 load-interval 30
 no fair-queue
 down-when-looped
 no cdp enable
!
interface Serial1/1/0
 bandwidth 1536
 ip address x.x.x.x y.y.y.y
 load-interval 30
 no fair-queue
 down-when-looped
 no cdp enable
!
interface Serial1/1/3
 bandwidth 1536
 ip address x.x.x.x y.y.y.y
 load-interval 30
 no fair-queue
 down-when-looped
 no cdp enable


From mtinka at globaltransit.net  Thu Jul 30 00:27:44 2009
From: mtinka at globaltransit.net (Mark Tinka)
Date: Thu, 30 Jul 2009 12:27:44 +0800
Subject: [c-nsp] Humor: Cisco announces end of BGP
In-Reply-To: <4A709DA2.6020501@kl.net>
References: <5.1.0.14.2.20090728104929.051778f8@efes.iucc.ac.il>
	<025401ca1076$74a53590$5defa0b0$@com> <4A709DA2.6020501@kl.net>
Message-ID: <200907301227.45197.mtinka@globaltransit.net>

On Thursday 30 July 2009 03:06:10 am Kevin Loch wrote:

> Lots of folks, myself included use /112 for point to
> point links, server only subnets and just about anything
> that doesn't require RA's (which is almost everything in
> a hosting environment).  /112 is a convenient bit
> boundary to work with and one size fits all (p-p and
> multipoint) applications.

We've been happy using /126's for point-to-point links (core 
and customer connections), and /112's for LAN's.

> Making it difficult for autoconf to work on certain
> subnets is a big plus.

Couldn't agree more :-).

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/20090730/6fa49c06/attachment.bin>

From mtinka at globaltransit.net  Thu Jul 30 00:23:35 2009
From: mtinka at globaltransit.net (Mark Tinka)
Date: Thu, 30 Jul 2009 12:23:35 +0800
Subject: [c-nsp] BFD + BGP on 7600 SRC or SRD
In-Reply-To: <alpine.DEB.1.10.0907292015420.5086@uplift.swm.pp.se>
References: <4A708F2D.6010207@rainierconnect.net>
	<alpine.DEB.1.10.0907292015420.5086@uplift.swm.pp.se>
Message-ID: <200907301223.59917.mtinka@globaltransit.net>

On Thursday 30 July 2009 02:16:38 am Mikael Abrahamsson 
wrote:

> SRC4 is has memory corruption bug with BFD running, this
> is a "crash and reload" type of bug.

SRC5 fixes a somewhat similar issue for the NPE-G1 (after so 
much bi**ing & moaning, since SRC).

Not sure if this affects the 7600. Last I heard from TAC, 
it's not meant to (unless this is another BFD bug that 
induces an uncommanded reload).

What fun... :-).

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/20090730/3e62f910/attachment.bin>

From dean at eatworms.org.uk  Thu Jul 30 03:51:13 2009
From: dean at eatworms.org.uk (Dean Smith)
Date: Thu, 30 Jul 2009 08:51:13 +0100
Subject: [c-nsp] BFD + BGP on 7600 SRC or SRD
References: <4A708F2D.6010207@rainierconnect.net>
	<4A711312.206@justinshore.com>
Message-ID: <1BF60693ABD84D9F9693C9377E2739AD@experienbd1776>

So I can only have BFD + eBGP if its on a physical port ?

Does the same apply to SVI + OSPF ?

Any known reason for this limitiation ?

(Waiting for my test 7606s to arrive!)
Dean

----- Original Message ----- 
From: "Justin Shore" <justin at justinshore.com>
To: "Walter Keen" <walter.keen at rainierconnect.net>
Cc: <cisco-nsp at puck.nether.net>
Sent: Thursday, July 30, 2009 4:27 AM
Subject: Re: [c-nsp] BFD + BGP on 7600 SRC or SRD


> Walter Keen wrote:
>> Hi, I'm looking at using BFD with BGP on 7600's (rsp720's and sup720-3b) 
>> and was wondering if there were any known issues with certain IOS's in 
>> the SRC or SRD train.
>
> BFD support for SVIs was removed with SRB2 if that's something that you 
> think you'll need.
>
> 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/
>
> __________ NOD32 4289 (20090729) Information __________
>
> This message was checked by NOD32 antivirus system.
> http://www.eset.com
>
> 


From b.turnbow at twt.it  Thu Jul 30 04:35:10 2009
From: b.turnbow at twt.it (Brian Turnbow)
Date: Thu, 30 Jul 2009 10:35:10 +0200
Subject: [c-nsp] Manually set WS-X6148-GE-TX MTU size (1500, 1518)
In-Reply-To: <a62d17300907291104x7d92aa39qd47f796d84608220@mail.gmail.com>
References: <a62d17300907291104x7d92aa39qd47f796d84608220@mail.gmail.com>
Message-ID: <F2207DB22012F94E92D7030F81A26294025A81D4@twt-exch.milano.twt>

1518 = 1500 payload(ie IP) + 18Byte ethernet header and trailer
You need the 6148A to go higher 



Brian 

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of falz
Sent: mercoled? 29 luglio 2009 20.04
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Manually set WS-X6148-GE-TX MTU size (1500, 1518)

Specs on WS-X6148-GE-TX say there is a maximum MTU of 1518:

http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/product_data_sheet0900aecd8017376e_ps4835_Products_Data_Sheet.html

However, on a 6500 running SXH, it will not let me use the mtu command
to adjust. I am trying to up the MTU for MPLS. Any way to do this
manually or is this something that's supported in hardware and
automatically upped slightly if a port were a trunk port, for example?

Trying to avoid purchasing WS-X6516-GE-TX or WS-X6748-GE-TX if possible.
_______________________________________________
cisco-nsp mailing list  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  Thu Jul 30 04:53:43 2009
From: arla at rn.dk (Arne Larsen / Region Nordjylland)
Date: Thu, 30 Jul 2009 10:53:43 +0200
Subject: [c-nsp] HREAP on Cisco LWAPP access points
Message-ID: <8D68760F464FFD40A01BF2FB374E4A2801CC19061CDB@SRVEXC02.aas.its.nja.dk>

Hi Folks.

Can someone help me out here, I looking at some problems regarding HREAP on LWAPP access points. Wee have four SSID's on each access point, futher more we have an mng vlan. The mng vlan is native.
The clients that access the ssid that we use for adm. personnel should get an addr from the scope on a vlan that is tagged, but they sometimes get from the mng. native network.
Has someone seen something like this or am I doing something wrong regarding HREAP.
Does HREAP need to untagged ??

/Arne

From nick at inex.ie  Thu Jul 30 05:31:25 2009
From: nick at inex.ie (Nick Hilliard)
Date: Thu, 30 Jul 2009 10:31:25 +0100
Subject: [c-nsp] Manually set WS-X6148-GE-TX MTU size (1500, 1518)
In-Reply-To: <a62d17300907291104x7d92aa39qd47f796d84608220@mail.gmail.com>
References: <a62d17300907291104x7d92aa39qd47f796d84608220@mail.gmail.com>
Message-ID: <4A71686D.6050708@inex.ie>

On 29/07/2009 19:04, falz wrote:
> Trying to avoid purchasing WS-X6516-GE-TX or WS-X6748-GE-TX if possible.

Why avoid the 6748 card?  The 65xx and 61xx cards are certainly low-spec 
pieces of kit, but I've always found the 6748 to be rather good for a pure 
LAN card.  Ok, there are certain things it doesn't do which you need the 
ES-* line for, but apart from decent netflow support it does what it says 
on the tin.

Nick

From justin at justinshore.com  Thu Jul 30 06:29:02 2009
From: justin at justinshore.com (Justin Shore)
Date: Thu, 30 Jul 2009 05:29:02 -0500
Subject: [c-nsp] BFD + BGP on 7600 SRC or SRD
In-Reply-To: <1BF60693ABD84D9F9693C9377E2739AD@experienbd1776>
References: <4A708F2D.6010207@rainierconnect.net>
	<4A711312.206@justinshore.com>
	<1BF60693ABD84D9F9693C9377E2739AD@experienbd1776>
Message-ID: <4A7175EE.5070406@justinshore.com>

The response I got when I asked was that it was an "unintended feature". 
  That may be the case but it was working just fine.  I wish they'd add 
the feature.  It's really important for 7600s that serve access 
functions along with core/distribution functions.  The only other 
solution is to burn additional ports to separate the 1Q trunk between 
pairs of chassis for access VLANs (running a FHRP across the pair of 
7600s) and a separate pair of interfaces for the L3 relationship between 
the chassis.

Justin



Dean Smith wrote:
> So I can only have BFD + eBGP if its on a physical port ?
> 
> Does the same apply to SVI + OSPF ?
> 
> Any known reason for this limitiation ?
> 
> (Waiting for my test 7606s to arrive!)
> Dean
> 
> ----- Original Message ----- From: "Justin Shore" <justin at justinshore.com>
> To: "Walter Keen" <walter.keen at rainierconnect.net>
> Cc: <cisco-nsp at puck.nether.net>
> Sent: Thursday, July 30, 2009 4:27 AM
> Subject: Re: [c-nsp] BFD + BGP on 7600 SRC or SRD
> 
> 
>> Walter Keen wrote:
>>> Hi, I'm looking at using BFD with BGP on 7600's (rsp720's and 
>>> sup720-3b) and was wondering if there were any known issues with 
>>> certain IOS's in the SRC or SRD train.
>>
>> BFD support for SVIs was removed with SRB2 if that's something that 
>> you think you'll need.
>>
>> 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/
>>
>> __________ NOD32 4289 (20090729) Information __________
>>
>> This message was checked by NOD32 antivirus system.
>> http://www.eset.com
>>
>>
> 

From rodunn at cisco.com  Thu Jul 30 07:48:35 2009
From: rodunn at cisco.com (Rodney Dunn)
Date: Thu, 30 Jul 2009 07:48:35 -0400
Subject: [c-nsp] DMVPN and OSPF
In-Reply-To: <9418aca70907291928k2c152e81xceb3eb6fc8f72ce4@mail.gmail.com>
References: <9418aca70907291342u477505b0vf9c937dfb7d767ed@mail.gmail.com>	
	<4A710119.50503@cisco.com>
	<9418aca70907291928k2c152e81xceb3eb6fc8f72ce4@mail.gmail.com>
Message-ID: <4A718893.1050307@cisco.com>



Jay Nakamura wrote:
>> Did you force the DR to be the hub by setting the priority?
> 
> Yes.  And confirmed.
> 
>> I forgot, did you set it to broadcast or multipoint?
> 
> broadcast
> 
>> I'd suggest you look at the packet capture feature and get a trace when it's
>> down.
> 
> Is this what you are referring to?
> 
> http://www.cisco.com/en/US/docs/ios/12_4t/12_4t11/ht_rawip.html#wp1049404
>

No this one:

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



> There is no tech onsite and it's a little far so I can't do it at the
> moment but if I can't figure out anything else, that will be the next
> step.
> 
>> Do you see the LSA's in the database?
> 
> I believe it was blank.  It's working now after a reboot so I can't
> check but I will check next time it happens.
> 

Ok. That is the starting point if the neigbors are not flapping.


>> Can you ping 224.0.0.5 and get a response?
>>
>> Are the neighbors flapping?
> 
> It didn't flap at all.  Routes just disappeared.  Well, that's not
> 100% true.  The backup hub VPN connection went down and it wouldn't
> come up.  I could ping the primary hub tunnel IP when the routes were
> gone but none of the other DMVPN peer IP.
> 

Almost always issues like this are with packet loss. You have to make 
sure the multicast traffic can traverse the cloud and that requires 
replication at the hub..and the spoke if you are doing a single spoke 
tunnel with dual hubs.


> 
>> Jay Nakamura wrote:
>>> Has anyone seen this symptom?
>>>
>>> 1841, advanced IP feature set
>>> DMVPN spoke and OSPF over the DMVPN
>>>
>>> Running 12.4(24)T
>>>
>>> Periodically, the router looses all it's OSPF routes and stays that
>>> way.  Clearing the DMVPN or OSPF process does nothing.  It recreates
>>> the OSPF session with neighbor but it still has no routes.  It can't
>>> seem to re-connect to the backup DMVPN hub either.
>>>
>>> Router still routes to the static default route for internet traffic
>>> and everything else seems normal.  Just can't get to the VPN network.
>>>
>>> It's really not doing anything fancy other than DMVPN and OSPF.
>>> _______________________________________________
>>> cisco-nsp mailing list  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 Jul 30 07:50:33 2009
From: rodunn at cisco.com (Rodney Dunn)
Date: Thu, 30 Jul 2009 07:50:33 -0400
Subject: [c-nsp] Balancing T1's with CEF
In-Reply-To: <C6966E55.5C14%cisco@peakpeak.com>
References: <C6966E55.5C14%cisco@peakpeak.com>
Message-ID: <4A718909.70905@cisco.com>

Turn on:

config t
ip cef account load per pre hash

Just type it..it's hidden.

And then get "sh ip cef <dstprefix> internal" and send.

Then get 'sh cef int' and send.

Also a couple snapshots of 'sh int stat' after a "clear counters"..

Rodney



Security Team wrote:
> I rebooted a 7507 router that had a site connected with 3 T1's and now all
> the traffic is nailing one line instead of being distributed over all 3
> using the static routes/CEF.
> 
> I did look at the Cisco troubleshooting tips but didn't see anything
> immensely helpful.  Here is a config snippet on the 7507 side (it's
> obviously nothing
> whizzy).
> 
> Has anyone seen this before?  I did an ip clear cache and also tried doing a
> shut/no shut on each line individually on the 7507, but the traffic to the
> customer's
> 28xx router always sacks one line.  It seems like in the past I did some
> kind of clear on the 7507 and things got better, but I can't recall what
> that may have been.
> 
> Thanks,
> CJ
> 
> 7507 (all PA adapters on the same VIP) config. One T1 comes in on a chan DS3
> card breaking out individual T1?s, and the other 2 T1?s come in on a 4-port
> PA adapter T1 card. I?m not using dCEF since I have never had good luck with
> it.
> 
> ip cef
> !
> interface Serial1/0/0/12:0
>  bandwidth 1536
>  ip address x.x.x.x y.y.y.y
>  load-interval 30
>  no fair-queue
>  down-when-looped
>  no cdp enable
> !
> interface Serial1/1/0
>  bandwidth 1536
>  ip address x.x.x.x y.y.y.y
>  load-interval 30
>  no fair-queue
>  down-when-looped
>  no cdp enable
> !
> interface Serial1/1/3
>  bandwidth 1536
>  ip address x.x.x.x y.y.y.y
>  load-interval 30
>  no fair-queue
>  down-when-looped
>  no cdp enable
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

From cisco at peakpeak.com  Thu Jul 30 08:12:34 2009
From: cisco at peakpeak.com (Security Team)
Date: Thu, 30 Jul 2009 06:12:34 -0600
Subject: [c-nsp] Balancing T1's with CEF
In-Reply-To: <4A718909.70905@cisco.com>
Message-ID: <C696EA52.5C1C%cisco@peakpeak.com>

Hi Rodney:


I get errors on the commands:

#config t     
Enter configuration commands, one per line.  End with CNTL/Z.
(config)#ip cef account load per pre hash
                                     ^
% Invalid input detected at '^' marker.

(config)#ip cef account load per prehash
                                    ^
% Invalid input detected at '^' marker.



It DID take this one OK though:

(config)#ip cef account load per pre

#show ip cef x.y.z.0 internal
X.y.z.0/24, version 2739, epoch 0, attached, per-destination sharing
0 packets, 0 bytes
  via Serial1/1/0, 0 dependencies
    traffic share 1
    valid adjacency (0x43E8C140)
  via Serial1/1/3, 0 dependencies
    traffic share 1
    valid adjacency (0x43E8C440)
  via Serial1/0/0/12:0, 0 dependencies
    traffic share 1
    valid adjacency (0x43E8B9C0)

  0 packets, 0 bytes switched through the prefix
  tmstats: external 0 packets, 0 bytes
           internal 0 packets, 0 bytes
  Load distribution: 0 1 2 0 1 2 0 1 2 0 1 2 0 1 2 (refcount 1)

  Hash  OK  Interface                 Address         Packets
  1     Y   Serial1/1/0               point2point           0
  2     Y   Serial1/1/3               point2point           0
  3     Y   Serial1/0/0/12:0          point2point           0
  4     Y   Serial1/1/0               point2point           0
  5     Y   Serial1/1/3               point2point           0
  6     Y   Serial1/0/0/12:0          point2point           0
  7     Y   Serial1/1/0               point2point           0
  8     Y   Serial1/1/3               point2point           0
  9     Y   Serial1/0/0/12:0          point2point           0
  10    Y   Serial1/1/0               point2point           0
  11    Y   Serial1/1/3               point2point           0
  12    Y   Serial1/0/0/12:0          point2point           0
  13    Y   Serial1/1/0               point2point           0
  14    Y   Serial1/1/3               point2point           0
  15    Y   Serial1/0/0/12:0          point2point           0

I'll send the rest of the stuff off list if that's OK, it's huge anyway.

I should mention that at this point the traffic to their site is really low
so I can't tell if it is happening right now.

Thanks,
CJ



On 7/30/09 5:50 AM, "Rodney Dunn" <rodunn at cisco.com> wrote:

> Turn on:
> 
> config t
> ip cef account load per pre hash
> 
> Just type it..it's hidden.
> 
> And then get "sh ip cef <dstprefix> internal" and send.
> 
> Then get 'sh cef int' and send.
> 
> Also a couple snapshots of 'sh int stat' after a "clear counters"..
> 
> Rodney
> 
> 
> 
> Security Team wrote:
>> I rebooted a 7507 router that had a site connected with 3 T1's and now all
>> the traffic is nailing one line instead of being distributed over all 3
>> using the static routes/CEF.
>> 
>> I did look at the Cisco troubleshooting tips but didn't see anything
>> immensely helpful.  Here is a config snippet on the 7507 side (it's
>> obviously nothing
>> whizzy).
>> 
>> Has anyone seen this before?  I did an ip clear cache and also tried doing a
>> shut/no shut on each line individually on the 7507, but the traffic to the
>> customer's
>> 28xx router always sacks one line.  It seems like in the past I did some
>> kind of clear on the 7507 and things got better, but I can't recall what
>> that may have been.
>> 
>> Thanks,
>> CJ
>> 
>> 7507 (all PA adapters on the same VIP) config. One T1 comes in on a chan DS3
>> card breaking out individual T1?s, and the other 2 T1?s come in on a 4-port
>> PA adapter T1 card. I?m not using dCEF since I have never had good luck with
>> it.
>> 
>> ip cef
>> !
>> interface Serial1/0/0/12:0
>>  bandwidth 1536
>>  ip address x.x.x.x y.y.y.y
>>  load-interval 30
>>  no fair-queue
>>  down-when-looped
>>  no cdp enable
>> !
>> interface Serial1/1/0
>>  bandwidth 1536
>>  ip address x.x.x.x y.y.y.y
>>  load-interval 30
>>  no fair-queue
>>  down-when-looped
>>  no cdp enable
>> !
>> interface Serial1/1/3
>>  bandwidth 1536
>>  ip address x.x.x.x y.y.y.y
>>  load-interval 30
>>  no fair-queue
>>  down-when-looped
>>  no cdp enable
>> 
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 



From me at falz.net  Thu Jul 30 08:25:25 2009
From: me at falz.net (falz)
Date: Thu, 30 Jul 2009 07:25:25 -0500
Subject: [c-nsp] Manually set WS-X6148-GE-TX MTU size (1500, 1518)
In-Reply-To: <4A71686D.6050708@inex.ie>
References: <a62d17300907291104x7d92aa39qd47f796d84608220@mail.gmail.com>
	<4A71686D.6050708@inex.ie>
Message-ID: <a62d17300907300525i6db7663dt17e28b75ad7ee092@mail.gmail.com>

On Thu, Jul 30, 2009 at 4:31 AM, Nick Hilliard<nick at inex.ie> wrote:
> On 29/07/2009 19:04, falz wrote:
>>
>> Trying to avoid purchasing WS-X6516-GE-TX or WS-X6748-GE-TX if possible.
>
> Why avoid the 6748 card? ?The 65xx and 61xx cards are certainly low-spec
> pieces of kit, but I've always found the 6748 to be rather good for a pure
> LAN card. ?Ok, there are certain things it doesn't do which you need the
> ES-* line for, but apart from decent netflow support it does what it says on
> the tin.

6748 would be my ideal choice, but the cost is prohibitive.

From nick at inex.ie  Thu Jul 30 08:44:50 2009
From: nick at inex.ie (Nick Hilliard)
Date: Thu, 30 Jul 2009 13:44:50 +0100
Subject: [c-nsp] Manually set WS-X6148-GE-TX MTU size (1500, 1518)
In-Reply-To: <a62d17300907300525i6db7663dt17e28b75ad7ee092@mail.gmail.com>
References: <a62d17300907291104x7d92aa39qd47f796d84608220@mail.gmail.com>	<4A71686D.6050708@inex.ie>
	<a62d17300907300525i6db7663dt17e28b75ad7ee092@mail.gmail.com>
Message-ID: <4A7195C2.6020201@inex.ie>

On 30/07/2009 13:25, falz wrote:
> 6748 would be my ideal choice, but the cost is prohibitive.

A 6148 has the same switching power as 6 separate 8-port 1 gig hubs, 
aggregated into a single gig switch with uplink to the rest of the chassis. 
  A 6748 gives you about 37 fully nonblocking gig ports, or 48 ports at 75% 
contention - for twice the price.

If you need lots of traffic on that number of ports, the 6748 is much 
better value.  It also has lots more features, many of them important - 
decent storm control, for one thing.

Nick

From frnkblk at iname.com  Thu Jul 30 09:05:49 2009
From: frnkblk at iname.com (Frank Bulk - iName.com)
Date: Thu, 30 Jul 2009 08:05:49 -0500
Subject: [c-nsp] Monitoring BGP with NAGIOS
In-Reply-To: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAACgBVX1McEWTr789Gz1sQh4AQAAAAA=@iname.com>
References: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAACgBVX1McEWTr789Gz1sQh4AQAAAAA=@iname.com>
Message-ID: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAACwJo8le8A+S7La3iFp5v0eAQAAAAA=@iname.com>

I appreciate all the feedback I received.  The product of that feedback is
this NAGIOS plugin:
http://exchange.nagios.org/directory/Plugins/Network-Protocols/*-Routing/BGP
%252D4/check_bgp_counters/details

Regards,

Frank	

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Frank Bulk
Sent: Thursday, July 23, 2009 9:04 AM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Monitoring BGP with NAGIOS

We're a small shop and our group's upstream is single-homed in terms of
providers but dual-homed in terms of physical connectivity, with a private
ASN.
 

Occasionally there's BGP events and I would like to be remotely notified --
NAGIOS can do that and I prefer SNMP polling.  We're not doing an SNMP TRAP
or syslog processing at this time - that would be an obvious next step for
us.


Currently the NAGIOS plugin I'm developing polls the bgpPeerState,
bgpPeerIn/OutUpdates and bgpPeerIn/OutTotalMessages and alerts me if there's
a change.  Since a BGP session could be re-established in a short amount of
time, I would like to trigger an alert if the number of In/Out Updates or
Messages exceeds the regular value (I'm presuming that when the BGP session
re-establishes, these counters climb more quickly than during times of
stability).  But I'm not sure if Updates/Messages are normally sent every 30
or 60 seconds (I've seen 60 on a wiki page, but "sh ip bgp neighbors" says
that the "keepalive interval is 30 seconds" and "Default minimum time
between advertisement runs is 30 seconds".  I'm guessing this knob can be
adjusted in IOS, so ideally I would like the NAGIOS plugin to accommodate
for that, such that if the counters move '5' in 5 minutes that's OK with a
60 second period, but if it's a 30 second period, then those counts should
move 10 times.  But keep-alive/scan interval doesn't seem to be listed in
the MIB.

 

Also, there's a lot more information available at the Cisco CLI when
executing "sh ip bgp summary", specifically:

.         BGP table version

.         # of network entries

.         # of path entries

.         # of prefixes

.         # of paths

.         Up/Down times

Is any of that available via SNMP, because my walking isn't showing that at
all?

 

If you think I'm going about this the wrong way, please feel free to tell
me. =)

 

Regards,

 

Frank

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


From mhuff at ox.com  Thu Jul 30 09:32:23 2009
From: mhuff at ox.com (Matthew Huff)
Date: Thu, 30 Jul 2009 09:32:23 -0400
Subject: [c-nsp] Balancing T1's with CEF
In-Reply-To: <C6966E55.5C14%cisco@peakpeak.com>
References: <C6966E55.5C14%cisco@peakpeak.com>
Message-ID: <483E6B0272B0284BA86D7596C40D29F9D122128110@PUR-EXCH07.ox.com>

Unless you do "per-packet" load-sharing (which you don't want to do since
it's cpu switched), the path is session based. If most of the traffic is
going from one source to one destination, it won't be load-shared. What do
the routing tables look like in both directions?

----
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 Security Team
> Sent: Wednesday, July 29, 2009 11:24 PM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] Balancing T1's with CEF
> 
> I rebooted a 7507 router that had a site connected with 3 T1's and now
> all
> the traffic is nailing one line instead of being distributed over all 3
> using the static routes/CEF.
> 
> I did look at the Cisco troubleshooting tips but didn't see anything
> immensely helpful.  Here is a config snippet on the 7507 side (it's
> obviously nothing
> whizzy).
> 
> Has anyone seen this before?  I did an ip clear cache and also tried
> doing a
> shut/no shut on each line individually on the 7507, but the traffic to
> the
> customer's
> 28xx router always sacks one line.  It seems like in the past I did
> some
> kind of clear on the 7507 and things got better, but I can't recall
> what
> that may have been.
> 
> Thanks,
> CJ
> 
> 7507 (all PA adapters on the same VIP) config. One T1 comes in on a
> chan DS3
> card breaking out individual T1?s, and the other 2 T1?s come in on a 4-
> port
> PA adapter T1 card. I?m not using dCEF since I have never had good luck
> with
> it.
> 
> ip cef
> !
> interface Serial1/0/0/12:0
>  bandwidth 1536
>  ip address x.x.x.x y.y.y.y
>  load-interval 30
>  no fair-queue
>  down-when-looped
>  no cdp enable
> !
> interface Serial1/1/0
>  bandwidth 1536
>  ip address x.x.x.x y.y.y.y
>  load-interval 30
>  no fair-queue
>  down-when-looped
>  no cdp enable
> !
> interface Serial1/1/3
>  bandwidth 1536
>  ip address x.x.x.x y.y.y.y
>  load-interval 30
>  no fair-queue
>  down-when-looped
>  no cdp enable
> 
> _______________________________________________
> cisco-nsp mailing 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: 4229 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20090730/b3f9ecc9/attachment-0001.bin>

From trejrco at gmail.com  Thu Jul 30 10:31:25 2009
From: trejrco at gmail.com (TJ)
Date: Thu, 30 Jul 2009 10:31:25 -0400
Subject: [c-nsp] Humor: Cisco announces end of BGP
In-Reply-To: <20090729.205456.74738911.sthaug@nethelp.no>
References: <020201ca106b$e8b6a730$ba23f590$@com>	<4A708339.5020700@uk.clara.net>	<025401ca1076$74a53590$5defa0b0$@com>
	<20090729.205456.74738911.sthaug@nethelp.no>
Message-ID: <014c01ca1122$6dad3ab0$4907b010$@com>

>-----Original Message-----
>From: sthaug at nethelp.no [mailto:sthaug at nethelp.no]
>Subject: Re: [c-nsp] Humor: Cisco announces end of BGP
>
>> My feeling is based on two things:
>> I don't like the idea of vendors/providers ignoring an RFC just because.
>> 	And note the RFC in question leaves no wiggle room here.
>
>Please cite chapter and verse. As long as you use static IPv6 addresses,
/126
>is fine. No, a /126 address does *not* have to be based on a 64 bit
interface
>ID.


Sure ... 

RFC4291 
2.5.1
"   For all unicast addresses, except those that start with the binary
   value 000, Interface IDs are required to be 64 bits long and to be
   constructed in Modified EUI-64 format. "

2.5.4
"   All Global Unicast addresses other than those that start with binary
   000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as
   described in Section 2.5.1.  Global Unicast addresses that start with
   binary 000 have no such constraint on the size or structure of the
   interface ID field. "

That would seem pretty clear cut to me, rather explicitly calling for 64bit
IIDs in all unicast cases (excluding the "starts with 000 block").
Additionally, 3177 implies the same:
3.
"      -  /64 when it is known that one and only one subnet is needed by
         design. "


Again - I am not saying /126s (or others!) don't work.  And most
implementations let you assign arbitrary values for prefix length.
I am not saying /126s or similar options are (evil|bad), or even
functionally problematic.  
	In fact, RFC3627 explicitly mentions /126s as "less bad than /127s" 
	... but prefers /112s over /126s, and prefers /64s over all of the
above.

All I am saying that I prefer the spec(s) be updated based on real world
preferences/implementations, and that this proposed change get reviewed as
thoroughly as the original spec(s) did to ensure nothing breaks.  I fully
realize that the real world doesn't always agree with the IETF, but in
something this "low down" and yet relatively easy to codify I fail to see
why it hasn't been done, unless there is a reason not to?  (If you don't
mind wiggle room in specs, or implementers "reinterpreting" the specs, that
is (cough) fine.)

In closing, I would turn the question around - can you cite chapter and
verse where it says you are allowed to do this?  Hopefully including an
assessment of the potential "unintended consequences" (Note: If it exists,
Great! ... sorry I missed it!)



/TJ


From cisco at peakpeak.com  Thu Jul 30 11:15:26 2009
From: cisco at peakpeak.com (Security Team)
Date: Thu, 30 Jul 2009 09:15:26 -0600
Subject: [c-nsp] Multilink PPP Was -> Re: Balancing T1's with CEF
In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9D122128110@PUR-EXCH07.ox.com>
Message-ID: <C697152E.5C26%cisco@peakpeak.com>

Well.....we arent' doing per packet and the destinations are definitely
different.

The last time this problem occurred I did a clear ip cache and it went away.
Since it isn't doing it this time I guess I thought I should try something
else.

Here is what I tried, I tried converting to multilink ppp encaps instead of
HDLC to see if that would have any effect, and it didn't.

(on both ends):

aaa new-model
aaa authorization network noauth none
aaa session-id common

interface Multilink1
 no ip address
 load-interval 30
 no cdp enable
 ppp authorization noauth
 ppp multilink
 ppp multilink group 1
 no shut
!
Interface Serial1/1/0
 encapsulation ppp
 ppp authorization noauth
 shut
 no shut
!
Interface Serial1/1/3
 encapsulation ppp
 ppp authorization noauth
 shut
 no shut
!
Interface Serial1/0/0/12:0
 encapsulation ppp
 ppp authorization noauth
 shut
 no shut

So with 3 static routes like this:

ip route x.y.z.0 255.255.255.0 serial1/1/0
ip route x.y.z.0 255.255.255.0 serial1/1/3
ip route x.y.z.0 255.255.255.0 serial1/0/0/12:0

The customer works but still has the problem where all the traffic sacks one
line inbound to their 28xx from our 7507.  So all we accomplished here
really was pre-build a multilink PPP bundle but just change the encaps for
each serial interface to PPP instead of HDLC.

Then I thought what I'd do is add each serial interface to the multilink
bundle using:

Int Serial1/1/0
   ppp multilink
   ppp multilink group 1
Int Serial1/1/3
   ppp multilink
   ppp multilink group 1
Int Serial1/0/0/12:0
   ppp multilink
   ppp multilink group 1

That is when the fun stopped (no packets routed at all). I did get this
message on the console:

Jul 30 09:03:09 MDT: %RP_MLP-5-LINKTYPEMISMATCH: Link(Serial1/0/0/12:0)
added, Bundle(Multilink1) may not be distributed

Not sure what this means.

So I assume what I should have done in addition to adding the ppp multilink
grouping to the serial interfaces is remove the static routes and replace
them with this instead right?

ip route x.y.z.0 255.255.255.0 Multilink1

I haven't ever configured multilink PPP before but this is right isn't it?

Thanks,
CJ


On 7/30/09 7:32 AM, "Matthew Huff" <mhuff at ox.com> wrote:

> Unless you do "per-packet" load-sharing (which you don't want to do since
> it's cpu switched), the path is session based. If most of the traffic is
> going from one source to one destination, it won't be load-shared. What do
> the routing tables look like in both directions?
> 
> ----
> 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 Security Team
>> Sent: Wednesday, July 29, 2009 11:24 PM
>> To: cisco-nsp at puck.nether.net
>> Subject: [c-nsp] Balancing T1's with CEF
>> 
>> I rebooted a 7507 router that had a site connected with 3 T1's and now
>> all
>> the traffic is nailing one line instead of being distributed over all 3
>> using the static routes/CEF.
>> 
>> I did look at the Cisco troubleshooting tips but didn't see anything
>> immensely helpful.  Here is a config snippet on the 7507 side (it's
>> obviously nothing
>> whizzy).
>> 
>> Has anyone seen this before?  I did an ip clear cache and also tried
>> doing a
>> shut/no shut on each line individually on the 7507, but the traffic to
>> the
>> customer's
>> 28xx router always sacks one line.  It seems like in the past I did
>> some
>> kind of clear on the 7507 and things got better, but I can't recall
>> what
>> that may have been.
>> 
>> Thanks,
>> CJ
>> 
>> 7507 (all PA adapters on the same VIP) config. One T1 comes in on a
>> chan DS3
>> card breaking out individual T1?s, and the other 2 T1?s come in on a 4-
>> port
>> PA adapter T1 card. I?m not using dCEF since I have never had good luck
>> with
>> it.
>> 
>> ip cef
>> !
>> interface Serial1/0/0/12:0
>>  bandwidth 1536
>>  ip address x.x.x.x y.y.y.y
>>  load-interval 30
>>  no fair-queue
>>  down-when-looped
>>  no cdp enable
>> !
>> interface Serial1/1/0
>>  bandwidth 1536
>>  ip address x.x.x.x y.y.y.y
>>  load-interval 30
>>  no fair-queue
>>  down-when-looped
>>  no cdp enable
>> !
>> interface Serial1/1/3
>>  bandwidth 1536
>>  ip address x.x.x.x y.y.y.y
>>  load-interval 30
>>  no fair-queue
>>  down-when-looped
>>  no cdp enable
>> 
>> _______________________________________________
>> cisco-nsp mailing list  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  Thu Jul 30 11:37:16 2009
From: walter.keen at RainierConnect.net (Walter Keen)
Date: Thu, 30 Jul 2009 08:37:16 -0700
Subject: [c-nsp] BFD + BGP on 7600 SRC or SRD
In-Reply-To: <4A711312.206@justinshore.com>
References: <4A708F2D.6010207@rainierconnect.net>
	<4A711312.206@justinshore.com>
Message-ID: <4A71BE2C.4030501@rainierconnect.net>

I am looking to use it on vlan interfaces, I have one with 12.2(33)SRC2 
and it appears to support the option in the config, but I wanted to know 
if there were known bugs before I deployed it.


We have a situation where a peer currently connected via bgp at two 
locations has traffic routed to our voice softswitch, and are trying to 
provide an almost-realtime cutover between our two links to them in the 
event of a fiber cut.

example topology

CM
  |
  /\
A   B
 |    |
 C--D---SS

Forgive the bad ascii drawing.  CM is the partner's CMTS, running eigrp 
between CM and A/B, all within their AS.  Details of how many routers 
are between CM and A/B is unclear.
C and D are our 7600 series routers, with a BGP link to A/B 
repsectively.  C is connected via an electrical 100mbit connection, 
where the D portion of C->D and B->D is a Gig-E metro-ethernet 
connection, with the BGP session in a vlan (hence, if the fiber to D 
gets cut, B is unaware that the link is down until the bgp hold timers 
expire)
SS is our softswitch, and there are voip cablemodems on the partners 
cmts (CM).  In the event of a fiber cut to D, we want as fast of 
failover to the link through C as possible.  There is also another route 
from C to D through another network, routing across it is not a problem, 
OSPF seems to do a decent job of that.

The partner also is set on doing either static routing or BGP, and not 
wanting to introduce any other protocols into their edge routers for 
peering.

What is the best option for this scenario?  In the interim I've lowered 
the BGP timers so we have a hold time of 15sec, but that still means 
dropped calls.
 





Justin Shore wrote:
> Walter Keen wrote:
>> Hi, I'm looking at using BFD with BGP on 7600's (rsp720's and 
>> sup720-3b) and was wondering if there were any known issues with 
>> certain IOS's in the SRC or SRD train.
>
> BFD support for SVIs was removed with SRB2 if that's something that 
> you think you'll need.
>
> Justin
>

-- 


Walter Keen
Network Technician
Rainier Connect
(o) 360-832-4024
(c) 253-302-0194


From braaen at zcorum.com  Thu Jul 30 11:38:04 2009
From: braaen at zcorum.com (Brian Raaen)
Date: Thu, 30 Jul 2009 11:38:04 -0400
Subject: [c-nsp] Multilink PPP Was -> Re: Balancing T1's with CEF
In-Reply-To: <C697152E.5C26%cisco@peakpeak.com>
References: <C697152E.5C26%cisco@peakpeak.com>
Message-ID: <4A71BE5C.1010103@zcorum.com>

Here is what I have on a multi-link with AT&T.

interface Multilink1
 description XXXXX
 ip address XXX.XXX.XXX.XXX 255.255.255.252
 load-interval 30
 no keepalive
 no cdp enable
 ppp multilink
 ppp multilink fragment disable
 ppp multilink group 1

interface Serial1/0:0
 description XXXXXXX
 bandwidth 1536
 no ip address
 encapsulation ppp
 no fair-queue
 no cdp enable
 ppp multilink
 ppp multilink group 1
 max-reserved-bandwidth 100




Security Team wrote:
> Well.....we arent' doing per packet and the destinations are definitely
> different.
>
> The last time this problem occurred I did a clear ip cache and it went away.
> Since it isn't doing it this time I guess I thought I should try something
> else.
>
> Here is what I tried, I tried converting to multilink ppp encaps instead of
> HDLC to see if that would have any effect, and it didn't.
>
> (on both ends):
>
> aaa new-model
> aaa authorization network noauth none
> aaa session-id common
>
> interface Multilink1
>  no ip address
>  load-interval 30
>  no cdp enable
>  ppp authorization noauth
>  ppp multilink
>  ppp multilink group 1
>  no shut
> !
> Interface Serial1/1/0
>  encapsulation ppp
>  ppp authorization noauth
>  shut
>  no shut
> !
> Interface Serial1/1/3
>  encapsulation ppp
>  ppp authorization noauth
>  shut
>  no shut
> !
> Interface Serial1/0/0/12:0
>  encapsulation ppp
>  ppp authorization noauth
>  shut
>  no shut
>
> So with 3 static routes like this:
>
> ip route x.y.z.0 255.255.255.0 serial1/1/0
> ip route x.y.z.0 255.255.255.0 serial1/1/3
> ip route x.y.z.0 255.255.255.0 serial1/0/0/12:0
>
> The customer works but still has the problem where all the traffic sacks one
> line inbound to their 28xx from our 7507.  So all we accomplished here
> really was pre-build a multilink PPP bundle but just change the encaps for
> each serial interface to PPP instead of HDLC.
>
> Then I thought what I'd do is add each serial interface to the multilink
> bundle using:
>
> Int Serial1/1/0
>    ppp multilink
>    ppp multilink group 1
> Int Serial1/1/3
>    ppp multilink
>    ppp multilink group 1
> Int Serial1/0/0/12:0
>    ppp multilink
>    ppp multilink group 1
>
> That is when the fun stopped (no packets routed at all). I did get this
> message on the console:
>
> Jul 30 09:03:09 MDT: %RP_MLP-5-LINKTYPEMISMATCH: Link(Serial1/0/0/12:0)
> added, Bundle(Multilink1) may not be distributed
>
> Not sure what this means.
>
> So I assume what I should have done in addition to adding the ppp multilink
> grouping to the serial interfaces is remove the static routes and replace
> them with this instead right?
>
> ip route x.y.z.0 255.255.255.0 Multilink1
>
> I haven't ever configured multilink PPP before but this is right isn't it?
>
> Thanks,
> CJ
>
>
> On 7/30/09 7:32 AM, "Matthew Huff" <mhuff at ox.com> wrote:
>
>   
>> Unless you do "per-packet" load-sharing (which you don't want to do since
>> it's cpu switched), the path is session based. If most of the traffic is
>> going from one source to one destination, it won't be load-shared. What do
>> the routing tables look like in both directions?
>>
>> ----
>> 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 Security Team
>>> Sent: Wednesday, July 29, 2009 11:24 PM
>>> To: cisco-nsp at puck.nether.net
>>> Subject: [c-nsp] Balancing T1's with CEF
>>>
>>> I rebooted a 7507 router that had a site connected with 3 T1's and now
>>> all
>>> the traffic is nailing one line instead of being distributed over all 3
>>> using the static routes/CEF.
>>>
>>> I did look at the Cisco troubleshooting tips but didn't see anything
>>> immensely helpful.  Here is a config snippet on the 7507 side (it's
>>> obviously nothing
>>> whizzy).
>>>
>>> Has anyone seen this before?  I did an ip clear cache and also tried
>>> doing a
>>> shut/no shut on each line individually on the 7507, but the traffic to
>>> the
>>> customer's
>>> 28xx router always sacks one line.  It seems like in the past I did
>>> some
>>> kind of clear on the 7507 and things got better, but I can't recall
>>> what
>>> that may have been.
>>>
>>> Thanks,
>>> CJ
>>>
>>> 7507 (all PA adapters on the same VIP) config. One T1 comes in on a
>>> chan DS3
>>> card breaking out individual T1?s, and the other 2 T1?s come in on a 4-
>>> port
>>> PA adapter T1 card. I?m not using dCEF since I have never had good luck
>>> with
>>> it.
>>>
>>> ip cef
>>> !
>>> interface Serial1/0/0/12:0
>>>  bandwidth 1536
>>>  ip address x.x.x.x y.y.y.y
>>>  load-interval 30
>>>  no fair-queue
>>>  down-when-looped
>>>  no cdp enable
>>> !
>>> interface Serial1/1/0
>>>  bandwidth 1536
>>>  ip address x.x.x.x y.y.y.y
>>>  load-interval 30
>>>  no fair-queue
>>>  down-when-looped
>>>  no cdp enable
>>> !
>>> interface Serial1/1/3
>>>  bandwidth 1536
>>>  ip address x.x.x.x y.y.y.y
>>>  load-interval 30
>>>  no fair-queue
>>>  down-when-looped
>>>  no cdp enable
>>>
>>> _______________________________________________
>>> cisco-nsp mailing 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/
>   

-- 
-----------------
Brian Raaen
Network Engineer
email: /braaen at zcorum.com/ <mailto:braaen at zcorum.com>
Telephone /678-507-5000x5574/

From Jeff.Wojciechowski at midlandpaper.com  Thu Jul 30 12:01:50 2009
From: Jeff.Wojciechowski at midlandpaper.com (Jeff Wojciechowski)
Date: Thu, 30 Jul 2009 11:01:50 -0500
Subject: [c-nsp] Multilink PPP Was -> Re: Balancing T1's with CEF
In-Reply-To: <4A71BE5C.1010103@zcorum.com>
References: <C697152E.5C26%cisco@peakpeak.com> <4A71BE5C.1010103@zcorum.com>
Message-ID: <6B8401A83219DF499C34DEAEE9A599921256B58B4E@XBOX.midlandpaper.com>

We had a problem with balancing 3 T1s between 2 T1s on a dual port T1 controller WIC and the 3rd on a single port service module. Cisco TAC swore up and down that it SHOULD balance between the 2 types of WICs but more traffic was being sent over the WIC T1-DSU. Replacing the WIC 1-DSU with the controller did the trick. (And that's actually the problem that helped me find this wonderful list...THANKS!)

-Jeff


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Brian Raaen
Sent: Thursday, July 30, 2009 10:38 AM
To: cisco at peakpeak.com
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Multilink PPP Was -> Re: Balancing T1's with CEF

Here is what I have on a multi-link with AT&T.

interface Multilink1
 description XXXXX
 ip address XXX.XXX.XXX.XXX 255.255.255.252  load-interval 30  no keepalive  no cdp enable  ppp multilink  ppp multilink fragment disable  ppp multilink group 1

interface Serial1/0:0
 description XXXXXXX
 bandwidth 1536
 no ip address
 encapsulation ppp
 no fair-queue
 no cdp enable
 ppp multilink
 ppp multilink group 1
 max-reserved-bandwidth 100




Security Team wrote:
> Well.....we arent' doing per packet and the destinations are 
> definitely different.
>
> The last time this problem occurred I did a clear ip cache and it went away.
> Since it isn't doing it this time I guess I thought I should try 
> something else.
>
> Here is what I tried, I tried converting to multilink ppp encaps 
> instead of HDLC to see if that would have any effect, and it didn't.
>
> (on both ends):
>
> aaa new-model
> aaa authorization network noauth none
> aaa session-id common
>
> interface Multilink1
>  no ip address
>  load-interval 30
>  no cdp enable
>  ppp authorization noauth
>  ppp multilink
>  ppp multilink group 1
>  no shut
> !
> Interface Serial1/1/0
>  encapsulation ppp
>  ppp authorization noauth
>  shut
>  no shut
> !
> Interface Serial1/1/3
>  encapsulation ppp
>  ppp authorization noauth
>  shut
>  no shut
> !
> Interface Serial1/0/0/12:0
>  encapsulation ppp
>  ppp authorization noauth
>  shut
>  no shut
>
> So with 3 static routes like this:
>
> ip route x.y.z.0 255.255.255.0 serial1/1/0 ip route x.y.z.0 
> 255.255.255.0 serial1/1/3 ip route x.y.z.0 255.255.255.0 
> serial1/0/0/12:0
>
> The customer works but still has the problem where all the traffic 
> sacks one line inbound to their 28xx from our 7507.  So all we 
> accomplished here really was pre-build a multilink PPP bundle but just 
> change the encaps for each serial interface to PPP instead of HDLC.
>
> Then I thought what I'd do is add each serial interface to the 
> multilink bundle using:
>
> Int Serial1/1/0
>    ppp multilink
>    ppp multilink group 1
> Int Serial1/1/3
>    ppp multilink
>    ppp multilink group 1
> Int Serial1/0/0/12:0
>    ppp multilink
>    ppp multilink group 1
>
> That is when the fun stopped (no packets routed at all). I did get 
> this message on the console:
>
> Jul 30 09:03:09 MDT: %RP_MLP-5-LINKTYPEMISMATCH: 
> Link(Serial1/0/0/12:0) added, Bundle(Multilink1) may not be 
> distributed
>
> Not sure what this means.
>
> So I assume what I should have done in addition to adding the ppp 
> multilink grouping to the serial interfaces is remove the static 
> routes and replace them with this instead right?
>
> ip route x.y.z.0 255.255.255.0 Multilink1
>
> I haven't ever configured multilink PPP before but this is right isn't it?
>
> Thanks,
> CJ
>
>
> On 7/30/09 7:32 AM, "Matthew Huff" <mhuff at ox.com> wrote:
>
>   
>> Unless you do "per-packet" load-sharing (which you don't want to do 
>> since it's cpu switched), the path is session based. If most of the 
>> traffic is going from one source to one destination, it won't be 
>> load-shared. What do the routing tables look like in both directions?
>>
>> ----
>> 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 Security Team
>>> Sent: Wednesday, July 29, 2009 11:24 PM
>>> To: cisco-nsp at puck.nether.net
>>> Subject: [c-nsp] Balancing T1's with CEF
>>>
>>> I rebooted a 7507 router that had a site connected with 3 T1's and 
>>> now all the traffic is nailing one line instead of being distributed 
>>> over all 3 using the static routes/CEF.
>>>
>>> I did look at the Cisco troubleshooting tips but didn't see anything 
>>> immensely helpful.  Here is a config snippet on the 7507 side (it's 
>>> obviously nothing whizzy).
>>>
>>> Has anyone seen this before?  I did an ip clear cache and also tried 
>>> doing a shut/no shut on each line individually on the 7507, but the 
>>> traffic to the customer's 28xx router always sacks one line.  It 
>>> seems like in the past I did some kind of clear on the 7507 and 
>>> things got better, but I can't recall what that may have been.
>>>
>>> Thanks,
>>> CJ
>>>
>>> 7507 (all PA adapters on the same VIP) config. One T1 comes in on a 
>>> chan DS3 card breaking out individual T1?s, and the other 2 T1?s 
>>> come in on a 4- port PA adapter T1 card. I?m not using dCEF since I 
>>> have never had good luck with it.
>>>
>>> ip cef
>>> !
>>> interface Serial1/0/0/12:0
>>>  bandwidth 1536
>>>  ip address x.x.x.x y.y.y.y
>>>  load-interval 30
>>>  no fair-queue
>>>  down-when-looped
>>>  no cdp enable
>>> !
>>> interface Serial1/1/0
>>>  bandwidth 1536
>>>  ip address x.x.x.x y.y.y.y
>>>  load-interval 30
>>>  no fair-queue
>>>  down-when-looped
>>>  no cdp enable
>>> !
>>> interface Serial1/1/3
>>>  bandwidth 1536
>>>  ip address x.x.x.x y.y.y.y
>>>  load-interval 30
>>>  no fair-queue
>>>  down-when-looped
>>>  no cdp enable
>>>
>>> _______________________________________________
>>> cisco-nsp mailing 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/
>   

--
-----------------
Brian Raaen
Network Engineer
email: /braaen at zcorum.com/ <mailto:braaen at zcorum.com> Telephone /678-507-5000x5574/

From notrevebr at gmail.com  Thu Jul 30 12:34:17 2009
From: notrevebr at gmail.com (Everton Diniz)
Date: Thu, 30 Jul 2009 13:34:17 -0300
Subject: [c-nsp] Multilink PPP Was -> Re: Balancing T1's with CEF
In-Reply-To: <C697152E.5C26%cisco@peakpeak.com>
References: <483E6B0272B0284BA86D7596C40D29F9D122128110@PUR-EXCH07.ox.com>
	<C697152E.5C26%cisco@peakpeak.com>
Message-ID: <3cf174360907300934w32c2f65al38d226f6db3c3dd@mail.gmail.com>

CJ,

I don?t know if happens on 7500, but on 7200 if you config MLPPP using
links connected in different slots, even same PA, occurs problems like
stop traffic without reason or the MLPPP is down.

On Thu, Jul 30, 2009 at 12:15 PM, Security Team<cisco at peakpeak.com> wrote:
> Well.....we arent' doing per packet and the destinations are definitely
> different.
>
> The last time this problem occurred I did a clear ip cache and it went away.
> Since it isn't doing it this time I guess I thought I should try something
> else.
>
> Here is what I tried, I tried converting to multilink ppp encaps instead of
> HDLC to see if that would have any effect, and it didn't.
>
> (on both ends):
>
> aaa new-model
> aaa authorization network noauth none
> aaa session-id common
>
> interface Multilink1
> ?no ip address
> ?load-interval 30
> ?no cdp enable
> ?ppp authorization noauth
> ?ppp multilink
> ?ppp multilink group 1
> ?no shut
> !
> Interface Serial1/1/0
> ?encapsulation ppp
> ?ppp authorization noauth
> ?shut
> ?no shut
> !
> Interface Serial1/1/3
> ?encapsulation ppp
> ?ppp authorization noauth
> ?shut
> ?no shut
> !
> Interface Serial1/0/0/12:0
> ?encapsulation ppp
> ?ppp authorization noauth
> ?shut
> ?no shut
>
> So with 3 static routes like this:
>
> ip route x.y.z.0 255.255.255.0 serial1/1/0
> ip route x.y.z.0 255.255.255.0 serial1/1/3
> ip route x.y.z.0 255.255.255.0 serial1/0/0/12:0
>
> The customer works but still has the problem where all the traffic sacks one
> line inbound to their 28xx from our 7507. ?So all we accomplished here
> really was pre-build a multilink PPP bundle but just change the encaps for
> each serial interface to PPP instead of HDLC.
>
> Then I thought what I'd do is add each serial interface to the multilink
> bundle using:
>
> Int Serial1/1/0
> ? ppp multilink
> ? ppp multilink group 1
> Int Serial1/1/3
> ? ppp multilink
> ? ppp multilink group 1
> Int Serial1/0/0/12:0
> ? ppp multilink
> ? ppp multilink group 1
>
> That is when the fun stopped (no packets routed at all). I did get this
> message on the console:
>
> Jul 30 09:03:09 MDT: %RP_MLP-5-LINKTYPEMISMATCH: Link(Serial1/0/0/12:0)
> added, Bundle(Multilink1) may not be distributed
>
> Not sure what this means.
>
> So I assume what I should have done in addition to adding the ppp multilink
> grouping to the serial interfaces is remove the static routes and replace
> them with this instead right?
>
> ip route x.y.z.0 255.255.255.0 Multilink1
>
> I haven't ever configured multilink PPP before but this is right isn't it?
>
> Thanks,
> CJ
>
>
> On 7/30/09 7:32 AM, "Matthew Huff" <mhuff at ox.com> wrote:
>
>> Unless you do "per-packet" load-sharing (which you don't want to do since
>> it's cpu switched), the path is session based. If most of the traffic is
>> going from one source to one destination, it won't be load-shared. What do
>> the routing tables look like in both directions?
>>
>> ----
>> 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 Security Team
>>> Sent: Wednesday, July 29, 2009 11:24 PM
>>> To: cisco-nsp at puck.nether.net
>>> Subject: [c-nsp] Balancing T1's with CEF
>>>
>>> I rebooted a 7507 router that had a site connected with 3 T1's and now
>>> all
>>> the traffic is nailing one line instead of being distributed over all 3
>>> using the static routes/CEF.
>>>
>>> I did look at the Cisco troubleshooting tips but didn't see anything
>>> immensely helpful. ?Here is a config snippet on the 7507 side (it's
>>> obviously nothing
>>> whizzy).
>>>
>>> Has anyone seen this before? ?I did an ip clear cache and also tried
>>> doing a
>>> shut/no shut on each line individually on the 7507, but the traffic to
>>> the
>>> customer's
>>> 28xx router always sacks one line. ?It seems like in the past I did
>>> some
>>> kind of clear on the 7507 and things got better, but I can't recall
>>> what
>>> that may have been.
>>>
>>> Thanks,
>>> CJ
>>>
>>> 7507 (all PA adapters on the same VIP) config. One T1 comes in on a
>>> chan DS3
>>> card breaking out individual T1?s, and the other 2 T1?s come in on a 4-
>>> port
>>> PA adapter T1 card. I?m not using dCEF since I have never had good luck
>>> with
>>> it.
>>>
>>> ip cef
>>> !
>>> interface Serial1/0/0/12:0
>>> ?bandwidth 1536
>>> ?ip address x.x.x.x y.y.y.y
>>> ?load-interval 30
>>> ?no fair-queue
>>> ?down-when-looped
>>> ?no cdp enable
>>> !
>>> interface Serial1/1/0
>>> ?bandwidth 1536
>>> ?ip address x.x.x.x y.y.y.y
>>> ?load-interval 30
>>> ?no fair-queue
>>> ?down-when-looped
>>> ?no cdp enable
>>> !
>>> interface Serial1/1/3
>>> ?bandwidth 1536
>>> ?ip address x.x.x.x y.y.y.y
>>> ?load-interval 30
>>> ?no fair-queue
>>> ?down-when-looped
>>> ?no cdp enable
>>>
>>> _______________________________________________
>>> cisco-nsp mailing 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.tahina at moov.mg  Thu Jul 30 12:06:29 2009
From: r.tahina at moov.mg (RAZAFINDRATSIFA Rivo Tahina)
Date: Thu, 30 Jul 2009 19:06:29 +0300
Subject: [c-nsp] 7206 NPE-G2 - Cat 3750  sfp issue
Message-ID: <7.0.1.0.2.20090730185902.04b8d458@moov.mg>

Hi all,

I use
1000BASE-LX/LH (GLC-LH-SM), on both Catalyst and 7206 NPE-G2, 
interface and protocol are up but I cannot do anything, what am I missing?

Regards.

From sthaug at nethelp.no  Thu Jul 30 12:57:27 2009
From: sthaug at nethelp.no (sthaug at nethelp.no)
Date: Thu, 30 Jul 2009 18:57:27 +0200 (CEST)
Subject: [c-nsp] Humor: Cisco announces end of BGP
In-Reply-To: <014c01ca1122$6dad3ab0$4907b010$@com>
References: <025401ca1076$74a53590$5defa0b0$@com>
	<20090729.205456.74738911.sthaug@nethelp.no>
	<014c01ca1122$6dad3ab0$4907b010$@com>
Message-ID: <20090730.185727.74750681.sthaug@nethelp.no>

> >Please cite chapter and verse. As long as you use static IPv6 addresses,
> /126
> >is fine. No, a /126 address does *not* have to be based on a 64 bit
> interface
> >ID.
> 
> 
> Sure ... 
> 
> RFC4291 
> 2.5.1
> "   For all unicast addresses, except those that start with the binary
>    value 000, Interface IDs are required to be 64 bits long and to be
>    constructed in Modified EUI-64 format. "
> 
> 2.5.4
> "   All Global Unicast addresses other than those that start with binary
>    000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as
>    described in Section 2.5.1.  Global Unicast addresses that start with
>    binary 000 have no such constraint on the size or structure of the
>    interface ID field. "
> 
> That would seem pretty clear cut to me, rather explicitly calling for 64bit
> IIDs in all unicast cases (excluding the "starts with 000 block").

In theory, I agree it would seem pretty clear. In practice, Appendix
A, "Creating Modified EUI-64 Format Interface Identifiers", leaves so 
much wiggle room that you can drive a truck through it.

Another point worth mentioning here is that RFC 4291 does not use the
normative language ("MUST", "MUST NOT" etc.) of RFC 2119.

As an example, the 2001:DB8:0:0:8:800:200C:417A unicast address on page
4 - are the lower 64 bits (0008:0800:200C:417A) constructed according
the Modified EUI-64 format or are they not? Since they don't have a 1
in bit position 6, they are clearly not based on a globally unique IEEE
MAC address...

> All I am saying that I prefer the spec(s) be updated based on real world
> preferences/implementations, and that this proposed change get reviewed as
> thoroughly as the original spec(s) did to ensure nothing breaks.  I fully
> realize that the real world doesn't always agree with the IETF, but in
> something this "low down" and yet relatively easy to codify I fail to see
> why it hasn't been done, unless there is a reason not to?  (If you don't
> mind wiggle room in specs, or implementers "reinterpreting" the specs, that
> is (cough) fine.)

Wiggle room is sometimes good, not always. In this case I would argue
that we are many years too late to change existing IPv6 implementations,
and that the wiggle room in RFC 4291 is just what we need.

And I plan to continue using /124 static address for our backbone links.
As others have mentioned, the fact that autoconfig explicitly doesn't
work with such addresses is a *good* thing.

Steinar Haug, Nethelp consulting, sthaug at nethelp.no

From daryl at introspect.net  Thu Jul 30 13:42:19 2009
From: daryl at introspect.net (Daryl G. Jurbala)
Date: Thu, 30 Jul 2009 13:42:19 -0400
Subject: [c-nsp] ISP in US
In-Reply-To: <9569de140907290644j11098b10l7c9c929ce4b30bb9@mail.gmail.com>
References: <9569de140907290644j11098b10l7c9c929ce4b30bb9@mail.gmail.com>
Message-ID: <A6DBBABA-A6D8-41EF-9005-40DAFCE14657@introspect.net>

None.  There is no common carrier between the two.  The US has plenty  
to choose from.  The Middle East has very few, all buying from one or  
two top tier in-region carriers.

It is also likely that you will have to use a VPN between the sites,  
as any type of SIP/RTP/H.323 is likely to be blocked in the border in  
the Middle East.

That being said, I seriously doubt you need what you think you need  
(guaranteed QoS).  If you do, you can absolutely purchase an MPLS  
tunnel between wherever you like, with dedicated QoS.  After all of  
the interconnect fees from each carrier it may have to pass though,  
likely bandwidth-metered, it would be cheaper to purchase a private  
Gulfstream V and build an airport at each site.

On Jul 29, 2009, at 9:44 AM, Andy William wrote:

>
> according to your experince with ISPs in US , what is the best ISP  
> that can
> offer QoS-based service between 2 internet points (US and ME) ?
>


From zeusdadog at gmail.com  Thu Jul 30 13:54:39 2009
From: zeusdadog at gmail.com (Jay Nakamura)
Date: Thu, 30 Jul 2009 13:54:39 -0400
Subject: [c-nsp] DMVPN and OSPF
In-Reply-To: <9418aca70907301053l3614852cq76ca441447ec9903@mail.gmail.com>
References: <9418aca70907291342u477505b0vf9c937dfb7d767ed@mail.gmail.com>
	<4A710119.50503@cisco.com>
	<9418aca70907291928k2c152e81xceb3eb6fc8f72ce4@mail.gmail.com>
	<4A718893.1050307@cisco.com>
	<9418aca70907301053l3614852cq76ca441447ec9903@mail.gmail.com>
Message-ID: <9418aca70907301054h51d73effq72a4a9b672066862@mail.gmail.com>

Looking back on tickets, it seems like this problem started happening
after upgrading from 12.4(15)T5 to 12.4(24)T. ?Before the upgrade, it
was running solid for a year.

I have tried 12.4(24)T1 but that doesn't seem to have any effect. ?I
can't go below 12.4(20)T because we want to deploy IOS content
filtering.


> On Thu, Jul 30, 2009 at 7:48 AM, Rodney Dunn<rodunn at cisco.com> wrote:
>>
>>
>> Jay Nakamura wrote:
>>>>
>>>> Did you force the DR to be the hub by setting the priority?
>>>
>>> Yes. ?And confirmed.
>>>
>>>> I forgot, did you set it to broadcast or multipoint?
>>>
>>> broadcast
>>>
>>>> I'd suggest you look at the packet capture feature and get a trace when
>>>> it's
>>>> down.
>>>
>>> Is this what you are referring to?
>>>
>>> http://www.cisco.com/en/US/docs/ios/12_4t/12_4t11/ht_rawip.html#wp1049404
>>>
>>
>> No this one:
>>
>> http://supportwiki.cisco.com/ViewWiki/index.php/Tech_Insights:Utilizing_the_New_Packet_Capture_Feature
>>
>>
>>
>>> There is no tech onsite and it's a little far so I can't do it at the
>>> moment but if I can't figure out anything else, that will be the next
>>> step.
>>>
>>>> Do you see the LSA's in the database?
>>>
>>> I believe it was blank. ?It's working now after a reboot so I can't
>>> check but I will check next time it happens.
>>>
>>
>> Ok. That is the starting point if the neigbors are not flapping.
>>
>>
>>>> Can you ping 224.0.0.5 and get a response?
>>>>
>>>> Are the neighbors flapping?
>>>
>>> It didn't flap at all. ?Routes just disappeared. ?Well, that's not
>>> 100% true. ?The backup hub VPN connection went down and it wouldn't
>>> come up. ?I could ping the primary hub tunnel IP when the routes were
>>> gone but none of the other DMVPN peer IP.
>>>
>>
>> Almost always issues like this are with packet loss. You have to make sure
>> the multicast traffic can traverse the cloud and that requires replication
>> at the hub..and the spoke if you are doing a single spoke tunnel with dual
>> hubs.
>>
>>
>>>
>>>> Jay Nakamura wrote:
>>>>>
>>>>> Has anyone seen this symptom?
>>>>>
>>>>> 1841, advanced IP feature set
>>>>> DMVPN spoke and OSPF over the DMVPN
>>>>>
>>>>> Running 12.4(24)T
>>>>>
>>>>> Periodically, the router looses all it's OSPF routes and stays that
>>>>> way. ?Clearing the DMVPN or OSPF process does nothing. ?It recreates
>>>>> the OSPF session with neighbor but it still has no routes. ?It can't
>>>>> seem to re-connect to the backup DMVPN hub either.
>>>>>
>>>>> Router still routes to the static default route for internet traffic
>>>>> and everything else seems normal. ?Just can't get to the VPN network.
>>>>>
>>>>> It's really not doing anything fancy other than DMVPN and OSPF.
>>>>> _______________________________________________
>>>>> cisco-nsp mailing list ?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  Thu Jul 30 14:10:21 2009
From: luan at netcraftsmen.net (Luan Nguyen)
Date: Thu, 30 Jul 2009 14:10:21 -0400
Subject: [c-nsp] DMVPN and OSPF
In-Reply-To: <9418aca70907301054h51d73effq72a4a9b672066862@mail.gmail.com>
References: <9418aca70907291342u477505b0vf9c937dfb7d767ed@mail.gmail.com>	<4A710119.50503@cisco.com>	<9418aca70907291928k2c152e81xceb3eb6fc8f72ce4@mail.gmail.com>	<4A718893.1050307@cisco.com>	<9418aca70907301053l3614852cq76ca441447ec9903@mail.gmail.com>
	<9418aca70907301054h51d73effq72a4a9b672066862@mail.gmail.com>
Message-ID: <019f01ca1141$00f875f0$02e961d0$@net>

Care to post the configuration?  So maybe some of us who think that this
problem is interesting could plug it into dynamips and check it out for you?
Have you tried to remove the configuration and put it back?  Maybe add a few
loopback interfaces and advertise them?

Regards,

-----------------------------------
Luan Nguyen
Chesapeake NetCraftsmen, LLC.
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 Jay Nakamura
Sent: Thursday, July 30, 2009 1:55 PM
To: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] DMVPN and OSPF

Looking back on tickets, it seems like this problem started happening
after upgrading from 12.4(15)T5 to 12.4(24)T. ?Before the upgrade, it
was running solid for a year.

I have tried 12.4(24)T1 but that doesn't seem to have any effect. ?I
can't go below 12.4(20)T because we want to deploy IOS content
filtering.


> On Thu, Jul 30, 2009 at 7:48 AM, Rodney Dunn<rodunn at cisco.com> wrote:
>>
>>
>> Jay Nakamura wrote:
>>>>
>>>> Did you force the DR to be the hub by setting the priority?
>>>
>>> Yes. ?And confirmed.
>>>
>>>> I forgot, did you set it to broadcast or multipoint?
>>>
>>> broadcast
>>>
>>>> I'd suggest you look at the packet capture feature and get a trace when
>>>> it's
>>>> down.
>>>
>>> Is this what you are referring to?
>>>
>>>
http://www.cisco.com/en/US/docs/ios/12_4t/12_4t11/ht_rawip.html#wp1049404
>>>
>>
>> No this one:
>>
>>
http://supportwiki.cisco.com/ViewWiki/index.php/Tech_Insights:Utilizing_the_
New_Packet_Capture_Feature
>>
>>
>>
>>> There is no tech onsite and it's a little far so I can't do it at the
>>> moment but if I can't figure out anything else, that will be the next
>>> step.
>>>
>>>> Do you see the LSA's in the database?
>>>
>>> I believe it was blank. ?It's working now after a reboot so I can't
>>> check but I will check next time it happens.
>>>
>>
>> Ok. That is the starting point if the neigbors are not flapping.
>>
>>
>>>> Can you ping 224.0.0.5 and get a response?
>>>>
>>>> Are the neighbors flapping?
>>>
>>> It didn't flap at all. ?Routes just disappeared. ?Well, that's not
>>> 100% true. ?The backup hub VPN connection went down and it wouldn't
>>> come up. ?I could ping the primary hub tunnel IP when the routes were
>>> gone but none of the other DMVPN peer IP.
>>>
>>
>> Almost always issues like this are with packet loss. You have to make
sure
>> the multicast traffic can traverse the cloud and that requires
replication
>> at the hub..and the spoke if you are doing a single spoke tunnel with
dual
>> hubs.
>>
>>
>>>
>>>> Jay Nakamura wrote:
>>>>>
>>>>> Has anyone seen this symptom?
>>>>>
>>>>> 1841, advanced IP feature set
>>>>> DMVPN spoke and OSPF over the DMVPN
>>>>>
>>>>> Running 12.4(24)T
>>>>>
>>>>> Periodically, the router looses all it's OSPF routes and stays that
>>>>> way. ?Clearing the DMVPN or OSPF process does nothing. ?It recreates
>>>>> the OSPF session with neighbor but it still has no routes. ?It can't
>>>>> seem to re-connect to the backup DMVPN hub either.
>>>>>
>>>>> Router still routes to the static default route for internet traffic
>>>>> and everything else seems normal. ?Just can't get to the VPN network.
>>>>>
>>>>> It's really not doing anything fancy other than DMVPN and OSPF.
>>>>> _______________________________________________
>>>>> cisco-nsp mailing 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 cisco at peakpeak.com  Thu Jul 30 14:11:13 2009
From: cisco at peakpeak.com (Security Team)
Date: Thu, 30 Jul 2009 12:11:13 -0600
Subject: [c-nsp] Multilink PPP Was -> Re: Balancing T1's with CEF
In-Reply-To: <3cf174360907300934w32c2f65al38d226f6db3c3dd@mail.gmail.com>
Message-ID: <C6973E61.5C2E%cisco@peakpeak.com>

Thanks I appreciate the tips guys.

I ended up contacting TAC about it and am waiting to hear back. I got pretty
far with MLPPP (and talking the customer through the mods) and was seeing
the lines properly balance sending traffic to the customer, but they weren't
able to route out so this seems like the best way to proceed since they are
a secure gov site.

Regards,

CJ


On 7/30/09 10:34 AM, "Everton Diniz" <notrevebr at gmail.com> wrote:

> CJ,
> 
> I don?t know if happens on 7500, but on 7200 if you config MLPPP using
> links connected in different slots, even same PA, occurs problems like
> stop traffic without reason or the MLPPP is down.
> 

<snip>



From frnkblk at iname.com  Thu Jul 30 14:19:19 2009
From: frnkblk at iname.com (Frank Bulk - iName.com)
Date: Thu, 30 Jul 2009 13:19:19 -0500
Subject: [c-nsp] Multilink PPP Was -> Re: Balancing T1's with CEF
In-Reply-To: <6B8401A83219DF499C34DEAEE9A599921256B58B4E@XBOX.midlandpaper.com>
References: <C697152E.5C26%cisco@peakpeak.com> <4A71BE5C.1010103@zcorum.com>
	<6B8401A83219DF499C34DEAEE9A599921256B58B4E@XBOX.midlandpaper.com>
Message-ID: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAAoN+eMYZG1QKMWQzlsApLTAQAAAAA=@iname.com>

All of this is further confirmation that if its IP that you need to send
over multiple T1's, much better to get an ADC or like box that does Ethernet
over one or more "raw" T-1's.  Abstracts the whole transport issue, and
gives Ethernet interfaces on both sides.

Frank

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Jeff Wojciechowski
Sent: Thursday, July 30, 2009 11:02 AM
To: cisco at peakpeak.com
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Multilink PPP Was -> Re: Balancing T1's with CEF

We had a problem with balancing 3 T1s between 2 T1s on a dual port T1
controller WIC and the 3rd on a single port service module. Cisco TAC swore
up and down that it SHOULD balance between the 2 types of WICs but more
traffic was being sent over the WIC T1-DSU. Replacing the WIC 1-DSU with the
controller did the trick. (And that's actually the problem that helped me
find this wonderful list...THANKS!)

-Jeff


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Brian Raaen
Sent: Thursday, July 30, 2009 10:38 AM
To: cisco at peakpeak.com
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Multilink PPP Was -> Re: Balancing T1's with CEF

Here is what I have on a multi-link with AT&T.

interface Multilink1
 description XXXXX
 ip address XXX.XXX.XXX.XXX 255.255.255.252  load-interval 30  no keepalive
no cdp enable  ppp multilink  ppp multilink fragment disable  ppp multilink
group 1

interface Serial1/0:0
 description XXXXXXX
 bandwidth 1536
 no ip address
 encapsulation ppp
 no fair-queue
 no cdp enable
 ppp multilink
 ppp multilink group 1
 max-reserved-bandwidth 100




Security Team wrote:
> Well.....we arent' doing per packet and the destinations are 
> definitely different.
>
> The last time this problem occurred I did a clear ip cache and it went
away.
> Since it isn't doing it this time I guess I thought I should try 
> something else.
>
> Here is what I tried, I tried converting to multilink ppp encaps 
> instead of HDLC to see if that would have any effect, and it didn't.
>
> (on both ends):
>
> aaa new-model
> aaa authorization network noauth none
> aaa session-id common
>
> interface Multilink1
>  no ip address
>  load-interval 30
>  no cdp enable
>  ppp authorization noauth
>  ppp multilink
>  ppp multilink group 1
>  no shut
> !
> Interface Serial1/1/0
>  encapsulation ppp
>  ppp authorization noauth
>  shut
>  no shut
> !
> Interface Serial1/1/3
>  encapsulation ppp
>  ppp authorization noauth
>  shut
>  no shut
> !
> Interface Serial1/0/0/12:0
>  encapsulation ppp
>  ppp authorization noauth
>  shut
>  no shut
>
> So with 3 static routes like this:
>
> ip route x.y.z.0 255.255.255.0 serial1/1/0 ip route x.y.z.0 
> 255.255.255.0 serial1/1/3 ip route x.y.z.0 255.255.255.0 
> serial1/0/0/12:0
>
> The customer works but still has the problem where all the traffic 
> sacks one line inbound to their 28xx from our 7507.  So all we 
> accomplished here really was pre-build a multilink PPP bundle but just 
> change the encaps for each serial interface to PPP instead of HDLC.
>
> Then I thought what I'd do is add each serial interface to the 
> multilink bundle using:
>
> Int Serial1/1/0
>    ppp multilink
>    ppp multilink group 1
> Int Serial1/1/3
>    ppp multilink
>    ppp multilink group 1
> Int Serial1/0/0/12:0
>    ppp multilink
>    ppp multilink group 1
>
> That is when the fun stopped (no packets routed at all). I did get 
> this message on the console:
>
> Jul 30 09:03:09 MDT: %RP_MLP-5-LINKTYPEMISMATCH: 
> Link(Serial1/0/0/12:0) added, Bundle(Multilink1) may not be 
> distributed
>
> Not sure what this means.
>
> So I assume what I should have done in addition to adding the ppp 
> multilink grouping to the serial interfaces is remove the static 
> routes and replace them with this instead right?
>
> ip route x.y.z.0 255.255.255.0 Multilink1
>
> I haven't ever configured multilink PPP before but this is right isn't it?
>
> Thanks,
> CJ
>
>
> On 7/30/09 7:32 AM, "Matthew Huff" <mhuff at ox.com> wrote:
>
>   
>> Unless you do "per-packet" load-sharing (which you don't want to do 
>> since it's cpu switched), the path is session based. If most of the 
>> traffic is going from one source to one destination, it won't be 
>> load-shared. What do the routing tables look like in both directions?
>>
>> ----
>> 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 Security Team
>>> Sent: Wednesday, July 29, 2009 11:24 PM
>>> To: cisco-nsp at puck.nether.net
>>> Subject: [c-nsp] Balancing T1's with CEF
>>>
>>> I rebooted a 7507 router that had a site connected with 3 T1's and 
>>> now all the traffic is nailing one line instead of being distributed 
>>> over all 3 using the static routes/CEF.
>>>
>>> I did look at the Cisco troubleshooting tips but didn't see anything 
>>> immensely helpful.  Here is a config snippet on the 7507 side (it's 
>>> obviously nothing whizzy).
>>>
>>> Has anyone seen this before?  I did an ip clear cache and also tried 
>>> doing a shut/no shut on each line individually on the 7507, but the 
>>> traffic to the customer's 28xx router always sacks one line.  It 
>>> seems like in the past I did some kind of clear on the 7507 and 
>>> things got better, but I can't recall what that may have been.
>>>
>>> Thanks,
>>> CJ
>>>
>>> 7507 (all PA adapters on the same VIP) config. One T1 comes in on a 
>>> chan DS3 card breaking out individual T1?s, and the other 2 T1?s 
>>> come in on a 4- port PA adapter T1 card. I?m not using dCEF since I 
>>> have never had good luck with it.
>>>
>>> ip cef
>>> !
>>> interface Serial1/0/0/12:0
>>>  bandwidth 1536
>>>  ip address x.x.x.x y.y.y.y
>>>  load-interval 30
>>>  no fair-queue
>>>  down-when-looped
>>>  no cdp enable
>>> !
>>> interface Serial1/1/0
>>>  bandwidth 1536
>>>  ip address x.x.x.x y.y.y.y
>>>  load-interval 30
>>>  no fair-queue
>>>  down-when-looped
>>>  no cdp enable
>>> !
>>> interface Serial1/1/3
>>>  bandwidth 1536
>>>  ip address x.x.x.x y.y.y.y
>>>  load-interval 30
>>>  no fair-queue
>>>  down-when-looped
>>>  no cdp enable
>>>
>>> _______________________________________________
>>> cisco-nsp mailing 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/
>   

--
-----------------
Brian Raaen
Network Engineer
email: /braaen at zcorum.com/ <mailto:braaen at zcorum.com> Telephone
/678-507-5000x5574/
_______________________________________________
cisco-nsp mailing list  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  Thu Jul 30 14:22:00 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Thu, 30 Jul 2009 11:22:00 -0700
Subject: [c-nsp] DMVPN and OSPF
In-Reply-To: <019f01ca1141$00f875f0$02e961d0$@net>
References: <9418aca70907291342u477505b0vf9c937dfb7d767ed@mail.gmail.com>	<4A710119.50503@cisco.com>	<9418aca70907291928k2c152e81xceb3eb6fc8f72ce4@mail.gmail.com>	<4A718893.1050307@cisco.com>	<9418aca70907301053l3614852cq76ca441447ec9903@mail.gmail.com>	<9418aca70907301054h51d73effq72a4a9b672066862@mail.gmail.com>
	<019f01ca1141$00f875f0$02e961d0$@net>
Message-ID: <4A71E4C8.50505@rollernet.us>

Luan Nguyen wrote:
> Care to post the configuration?  So maybe some of us who think that this
> problem is interesting could plug it into dynamips and check it out for you?
> Have you tried to remove the configuration and put it back?  Maybe add a few
> loopback interfaces and advertise them?
> 

I'd be interested to see it as well to compare it to mine which isn't
exhibiting the problem.

~Seth

From Jeff.Wojciechowski at midlandpaper.com  Thu Jul 30 14:22:21 2009
From: Jeff.Wojciechowski at midlandpaper.com (Jeff Wojciechowski)
Date: Thu, 30 Jul 2009 13:22:21 -0500
Subject: [c-nsp] Multilink PPP Was -> Re: Balancing T1's with CEF
In-Reply-To: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAAoN+eMYZG1QKMWQzlsApLTAQAAAAA=@iname.com>
References: <C697152E.5C26%cisco@peakpeak.com> <4A71BE5C.1010103@zcorum.com>
	<6B8401A83219DF499C34DEAEE9A599921256B58B4E@XBOX.midlandpaper.com>
	<!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAAoN+eMYZG1QKMWQzlsApLTAQAAAAA=@iname.com>
Message-ID: <6B8401A83219DF499C34DEAEE9A599921256B58B64@XBOX.midlandpaper.com>

We are going to be deploying some more MLPPP ckts here in the next few months and I am not familiar with ADCs. Are those carrier dependant? Does this affect MPLS QoS?

Thanks,

-Jeff


-----Original Message-----
From: Frank Bulk - iName.com [mailto:frnkblk at iname.com] 
Sent: Thursday, July 30, 2009 1:19 PM
To: Jeff Wojciechowski; cisco at peakpeak.com; cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] Multilink PPP Was -> Re: Balancing T1's with CEF

All of this is further confirmation that if its IP that you need to send
over multiple T1's, much better to get an ADC or like box that does Ethernet
over one or more "raw" T-1's.  Abstracts the whole transport issue, and
gives Ethernet interfaces on both sides.

Frank

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Jeff Wojciechowski
Sent: Thursday, July 30, 2009 11:02 AM
To: cisco at peakpeak.com
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Multilink PPP Was -> Re: Balancing T1's with CEF

We had a problem with balancing 3 T1s between 2 T1s on a dual port T1
controller WIC and the 3rd on a single port service module. Cisco TAC swore
up and down that it SHOULD balance between the 2 types of WICs but more
traffic was being sent over the WIC T1-DSU. Replacing the WIC 1-DSU with the
controller did the trick. (And that's actually the problem that helped me
find this wonderful list...THANKS!)

-Jeff


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Brian Raaen
Sent: Thursday, July 30, 2009 10:38 AM
To: cisco at peakpeak.com
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Multilink PPP Was -> Re: Balancing T1's with CEF

Here is what I have on a multi-link with AT&T.

interface Multilink1
 description XXXXX
 ip address XXX.XXX.XXX.XXX 255.255.255.252  load-interval 30  no keepalive
no cdp enable  ppp multilink  ppp multilink fragment disable  ppp multilink
group 1

interface Serial1/0:0
 description XXXXXXX
 bandwidth 1536
 no ip address
 encapsulation ppp
 no fair-queue
 no cdp enable
 ppp multilink
 ppp multilink group 1
 max-reserved-bandwidth 100




Security Team wrote:
> Well.....we arent' doing per packet and the destinations are 
> definitely different.
>
> The last time this problem occurred I did a clear ip cache and it went
away.
> Since it isn't doing it this time I guess I thought I should try 
> something else.
>
> Here is what I tried, I tried converting to multilink ppp encaps 
> instead of HDLC to see if that would have any effect, and it didn't.
>
> (on both ends):
>
> aaa new-model
> aaa authorization network noauth none
> aaa session-id common
>
> interface Multilink1
>  no ip address
>  load-interval 30
>  no cdp enable
>  ppp authorization noauth
>  ppp multilink
>  ppp multilink group 1
>  no shut
> !
> Interface Serial1/1/0
>  encapsulation ppp
>  ppp authorization noauth
>  shut
>  no shut
> !
> Interface Serial1/1/3
>  encapsulation ppp
>  ppp authorization noauth
>  shut
>  no shut
> !
> Interface Serial1/0/0/12:0
>  encapsulation ppp
>  ppp authorization noauth
>  shut
>  no shut
>
> So with 3 static routes like this:
>
> ip route x.y.z.0 255.255.255.0 serial1/1/0 ip route x.y.z.0 
> 255.255.255.0 serial1/1/3 ip route x.y.z.0 255.255.255.0 
> serial1/0/0/12:0
>
> The customer works but still has the problem where all the traffic 
> sacks one line inbound to their 28xx from our 7507.  So all we 
> accomplished here really was pre-build a multilink PPP bundle but just 
> change the encaps for each serial interface to PPP instead of HDLC.
>
> Then I thought what I'd do is add each serial interface to the 
> multilink bundle using:
>
> Int Serial1/1/0
>    ppp multilink
>    ppp multilink group 1
> Int Serial1/1/3
>    ppp multilink
>    ppp multilink group 1
> Int Serial1/0/0/12:0
>    ppp multilink
>    ppp multilink group 1
>
> That is when the fun stopped (no packets routed at all). I did get 
> this message on the console:
>
> Jul 30 09:03:09 MDT: %RP_MLP-5-LINKTYPEMISMATCH: 
> Link(Serial1/0/0/12:0) added, Bundle(Multilink1) may not be 
> distributed
>
> Not sure what this means.
>
> So I assume what I should have done in addition to adding the ppp 
> multilink grouping to the serial interfaces is remove the static 
> routes and replace them with this instead right?
>
> ip route x.y.z.0 255.255.255.0 Multilink1
>
> I haven't ever configured multilink PPP before but this is right isn't it?
>
> Thanks,
> CJ
>
>
> On 7/30/09 7:32 AM, "Matthew Huff" <mhuff at ox.com> wrote:
>
>   
>> Unless you do "per-packet" load-sharing (which you don't want to do 
>> since it's cpu switched), the path is session based. If most of the 
>> traffic is going from one source to one destination, it won't be 
>> load-shared. What do the routing tables look like in both directions?
>>
>> ----
>> 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 Security Team
>>> Sent: Wednesday, July 29, 2009 11:24 PM
>>> To: cisco-nsp at puck.nether.net
>>> Subject: [c-nsp] Balancing T1's with CEF
>>>
>>> I rebooted a 7507 router that had a site connected with 3 T1's and 
>>> now all the traffic is nailing one line instead of being distributed 
>>> over all 3 using the static routes/CEF.
>>>
>>> I did look at the Cisco troubleshooting tips but didn't see anything 
>>> immensely helpful.  Here is a config snippet on the 7507 side (it's 
>>> obviously nothing whizzy).
>>>
>>> Has anyone seen this before?  I did an ip clear cache and also tried 
>>> doing a shut/no shut on each line individually on the 7507, but the 
>>> traffic to the customer's 28xx router always sacks one line.  It 
>>> seems like in the past I did some kind of clear on the 7507 and 
>>> things got better, but I can't recall what that may have been.
>>>
>>> Thanks,
>>> CJ
>>>
>>> 7507 (all PA adapters on the same VIP) config. One T1 comes in on a 
>>> chan DS3 card breaking out individual T1?s, and the other 2 T1?s 
>>> come in on a 4- port PA adapter T1 card. I?m not using dCEF since I 
>>> have never had good luck with it.
>>>
>>> ip cef
>>> !
>>> interface Serial1/0/0/12:0
>>>  bandwidth 1536
>>>  ip address x.x.x.x y.y.y.y
>>>  load-interval 30
>>>  no fair-queue
>>>  down-when-looped
>>>  no cdp enable
>>> !
>>> interface Serial1/1/0
>>>  bandwidth 1536
>>>  ip address x.x.x.x y.y.y.y
>>>  load-interval 30
>>>  no fair-queue
>>>  down-when-looped
>>>  no cdp enable
>>> !
>>> interface Serial1/1/3
>>>  bandwidth 1536
>>>  ip address x.x.x.x y.y.y.y
>>>  load-interval 30
>>>  no fair-queue
>>>  down-when-looped
>>>  no cdp enable
>>>
>>> _______________________________________________
>>> cisco-nsp mailing 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/
>   

--
-----------------
Brian Raaen
Network Engineer
email: /braaen at zcorum.com/ <mailto:braaen at zcorum.com> Telephone
/678-507-5000x5574/
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


From kgraham at industrial-marshmallow.com  Thu Jul 30 13:22:40 2009
From: kgraham at industrial-marshmallow.com (Kevin Graham)
Date: Thu, 30 Jul 2009 10:22:40 -0700 (PDT)
Subject: [c-nsp] Multilink PPP Was -> Re: Balancing T1's with CEF
In-Reply-To: <6B8401A83219DF499C34DEAEE9A599921256B58B4E@XBOX.midlandpaper.com>
References: <C697152E.5C26%cisco@peakpeak.com> <4A71BE5C.1010103@zcorum.com>
	<6B8401A83219DF499C34DEAEE9A599921256B58B4E@XBOX.midlandpaper.com>
Message-ID: <8398.3459.qm@web1201.biz.mail.gq1.yahoo.com>


> Cisco TAC swore up and down that it SHOULD balance between the 2

> types of WICs but more traffic was being sent over the WIC T1-DSU. 
> Replacing the WIC 1-DSU with the controller did the trick.

Ran into a similar problem mixing the T1 VWIC's (when they were new)
and WIC-1DSU-T1's. One type of controller reported the bandwidth as
1536kbps, the other as 1544kpbs, and (as would be expected) they
weren't installed as ECMP paths. Workaround was to simply manually
adjust interface bandwidth statement. (Don't believe we ever raised
this to TAC to see if there was a bug to address the discrepancy).

From sethm at rollernet.us  Thu Jul 30 14:31:06 2009
From: sethm at rollernet.us (Seth Mattinen)
Date: Thu, 30 Jul 2009 11:31:06 -0700
Subject: [c-nsp] Multilink PPP Was -> Re: Balancing T1's with CEF
In-Reply-To: <6B8401A83219DF499C34DEAEE9A599921256B58B4E@XBOX.midlandpaper.com>
References: <C697152E.5C26%cisco@peakpeak.com> <4A71BE5C.1010103@zcorum.com>
	<6B8401A83219DF499C34DEAEE9A599921256B58B4E@XBOX.midlandpaper.com>
Message-ID: <4A71E6EA.8020101@rollernet.us>

Jeff Wojciechowski wrote:
> We had a problem with balancing 3 T1s between 2 T1s on a dual port T1 controller WIC and the 3rd on a single port service module. Cisco TAC swore up and down that it SHOULD balance between the 2 types of WICs but more traffic was being sent over the WIC T1-DSU. Replacing the WIC 1-DSU with the controller did the trick. (And that's actually the problem that helped me find this wonderful list...THANKS!)
> 

Was that problem with MLPPP or CEF load sharing?

~Seth

From frnkblk at iname.com  Thu Jul 30 14:36:22 2009
From: frnkblk at iname.com (Frank Bulk - iName.com)
Date: Thu, 30 Jul 2009 13:36:22 -0500
Subject: [c-nsp] Multilink PPP Was -> Re: Balancing T1's with CEF
In-Reply-To: <6B8401A83219DF499C34DEAEE9A599921256B58B64@XBOX.midlandpaper.com>
References: <C697152E.5C26%cisco@peakpeak.com> <4A71BE5C.1010103@zcorum.com>
	<6B8401A83219DF499C34DEAEE9A599921256B58B4E@XBOX.midlandpaper.com>
	<!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAAoN+eMYZG1QKMWQzlsApLTAQAAAAA=@iname.com>
	<6B8401A83219DF499C34DEAEE9A599921256B58B64@XBOX.midlandpaper.com>
Message-ID: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAABCA8f39aBaQZ+33HAnZBeFAQAAAAA=@iname.com>

I wrote ADC but I meant, RAD, my fault.
http://www.ethernetaccess.com/Home/0,6583,19337,00.html

These basically bond T-1s and are carrier independent.  All that either end
sees is an Ethernet port.  They appear to have QoS priority queues, thought
I'm not personally familiar with this product to say anything more than what
is in their data sheets.

Frank

-----Original Message-----
From: Jeff Wojciechowski [mailto:Jeff.Wojciechowski at midlandpaper.com] 
Sent: Thursday, July 30, 2009 1:22 PM
To: frnkblk at iname.com
Cc: cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] Multilink PPP Was -> Re: Balancing T1's with CEF

We are going to be deploying some more MLPPP ckts here in the next few
months and I am not familiar with ADCs. Are those carrier dependant? Does
this affect MPLS QoS?

Thanks,

-Jeff


-----Original Message-----
From: Frank Bulk - iName.com [mailto:frnkblk at iname.com] 
Sent: Thursday, July 30, 2009 1:19 PM
To: Jeff Wojciechowski; cisco at peakpeak.com; cisco-nsp at puck.nether.net
Subject: RE: [c-nsp] Multilink PPP Was -> Re: Balancing T1's with CEF

All of this is further confirmation that if its IP that you need to send
over multiple T1's, much better to get an ADC or like box that does Ethernet
over one or more "raw" T-1's.  Abstracts the whole transport issue, and
gives Ethernet interfaces on both sides.

Frank

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Jeff Wojciechowski
Sent: Thursday, July 30, 2009 11:02 AM
To: cisco at peakpeak.com
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Multilink PPP Was -> Re: Balancing T1's with CEF

We had a problem with balancing 3 T1s between 2 T1s on a dual port T1
controller WIC and the 3rd on a single port service module. Cisco TAC swore
up and down that it SHOULD balance between the 2 types of WICs but more
traffic was being sent over the WIC T1-DSU. Replacing the WIC 1-DSU with the
controller did the trick. (And that's actually the problem that helped me
find this wonderful list...THANKS!)

-Jeff


-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Brian Raaen
Sent: Thursday, July 30, 2009 10:38 AM
To: cisco at peakpeak.com
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Multilink PPP Was -> Re: Balancing T1's with CEF

Here is what I have on a multi-link with AT&T.

interface Multilink1
 description XXXXX
 ip address XXX.XXX.XXX.XXX 255.255.255.252  load-interval 30  no keepalive
no cdp enable  ppp multilink  ppp multilink fragment disable  ppp multilink
group 1

interface Serial1/0:0
 description XXXXXXX
 bandwidth 1536
 no ip address
 encapsulation ppp
 no fair-queue
 no cdp enable
 ppp multilink
 ppp multilink group 1
 max-reserved-bandwidth 100




Security Team wrote:
> Well.....we arent' doing per packet and the destinations are 
> definitely different.
>
> The last time this problem occurred I did a clear ip cache and it went
away.
> Since it isn't doing it this time I guess I thought I should try 
> something else.
>
> Here is what I tried, I tried converting to multilink ppp encaps 
> instead of HDLC to see if that would have any effect, and it didn't.
>
> (on both ends):
>
> aaa new-model
> aaa authorization network noauth none
> aaa session-id common
>
> interface Multilink1
>  no ip address
>  load-interval 30
>  no cdp enable
>  ppp authorization noauth
>  ppp multilink
>  ppp multilink group 1
>  no shut
> !
> Interface Serial1/1/0
>  encapsulation ppp
>  ppp authorization noauth
>  shut
>  no shut
> !
> Interface Serial1/1/3
>  encapsulation ppp
>  ppp authorization noauth
>  shut
>  no shut
> !
> Interface Serial1/0/0/12:0
>  encapsulation ppp
>  ppp authorization noauth
>  shut
>  no shut
>
> So with 3 static routes like this:
>
> ip route x.y.z.0 255.255.255.0 serial1/1/0 ip route x.y.z.0 
> 255.255.255.0 serial1/1/3 ip route x.y.z.0 255.255.255.0 
> serial1/0/0/12:0
>
> The customer works but still has the problem where all the traffic 
> sacks one line inbound to their 28xx from our 7507.  So all we 
> accomplished here really was pre-build a multilink PPP bundle but just 
> change the encaps for each serial interface to PPP instead of HDLC.
>
> Then I thought what I'd do is add each serial interface to the 
> multilink bundle using:
>
> Int Serial1/1/0
>    ppp multilink
>    ppp multilink group 1
> Int Serial1/1/3
>    ppp multilink
>    ppp multilink group 1
> Int Serial1/0/0/12:0
>    ppp multilink
>    ppp multilink group 1
>
> That is when the fun stopped (no packets routed at all). I did get 
> this message on the console:
>
> Jul 30 09:03:09 MDT: %RP_MLP-5-LINKTYPEMISMATCH: 
> Link(Serial1/0/0/12:0) added, Bundle(Multilink1) may not be 
> distributed
>
> Not sure what this means.
>
> So I assume what I should have done in addition to adding the ppp 
> multilink grouping to the serial interfaces is remove the static 
> routes and replace them with this instead right?
>
> ip route x.y.z.0 255.255.255.0 Multilink1
>
> I haven't ever configured multilink PPP before but this is right isn't it?
>
> Thanks,
> CJ
>
>
> On 7/30/09 7:32 AM, "Matthew Huff" <mhuff at ox.com> wrote:
>
>   
>> Unless you do "per-packet" load-sharing (which you don't want to do 
>> since it's cpu switched), the path is session based. If most of the 
>> traffic is going from one source to one destination, it won't be 
>> load-shared. What do the routing tables look like in both directions?
>>
>> ----
>> 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 Security Team
>>> Sent: Wednesday, July 29, 2009 11:24 PM
>>> To: cisco-nsp at puck.nether.net
>>> Subject: [c-nsp] Balancing T1's with CEF
>>>
>>> I rebooted a 7507 router that had a site connected with 3 T1's and 
>>> now all the traffic is nailing one line instead of being distributed 
>>> over all 3 using the static routes/CEF.
>>>
>>> I did look at the Cisco troubleshooting tips but didn't see anything 
>>> immensely helpful.  Here is a config snippet on the 7507 side (it's 
>>> obviously nothing whizzy).
>>>
>>> Has anyone seen this before?  I did an ip clear cache and also tried 
>>> doing a shut/no shut on each line individually on the 7507, but the 
>>> traffic to the customer's 28xx router always sacks one line.  It 
>>> seems like in the past I did some kind of clear on the 7507 and 
>>> things got better, but I can't recall what that may have been.
>>>
>>> Thanks,
>>> CJ
>>>
>>> 7507 (all PA adapters on the same VIP) config. One T1 comes in on a 
>>> chan DS3 card breaking out individual T1?s, and the other 2 T1?s 
>>> come in on a 4- port PA adapter T1 card. I?m not using dCEF since I 
>>> have never had good luck with it.
>>>
>>> ip cef
>>> !
>>> interface Serial1/0/0/12:0
>>>  bandwidth 1536
>>>  ip address x.x.x.x y.y.y.y
>>>  load-interval 30
>>>  no fair-queue
>>>  down-when-looped
>>>  no cdp enable
>>> !
>>> interface Serial1/1/0
>>>  bandwidth 1536
>>>  ip address x.x.x.x y.y.y.y
>>>  load-interval 30
>>>  no fair-queue
>>>  down-when-looped
>>>  no cdp enable
>>> !
>>> interface Serial1/1/3
>>>  bandwidth 1536
>>>  ip address x.x.x.x y.y.y.y
>>>  load-interval 30
>>>  no fair-queue
>>>  down-when-looped
>>>  no cdp enable
>>>
>>> _______________________________________________
>>> cisco-nsp mailing 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/
>   

--
-----------------
Brian Raaen
Network Engineer
email: /braaen at zcorum.com/ <mailto:braaen at zcorum.com> Telephone
/678-507-5000x5574/
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/



From zeusdadog at gmail.com  Thu Jul 30 15:32:58 2009
From: zeusdadog at gmail.com (Jay Nakamura)
Date: Thu, 30 Jul 2009 15:32:58 -0400
Subject: [c-nsp] DMVPN and OSPF
In-Reply-To: <4A71E4C8.50505@rollernet.us>
References: <9418aca70907291342u477505b0vf9c937dfb7d767ed@mail.gmail.com>
	<4A710119.50503@cisco.com>
	<9418aca70907291928k2c152e81xceb3eb6fc8f72ce4@mail.gmail.com>
	<4A718893.1050307@cisco.com>
	<9418aca70907301053l3614852cq76ca441447ec9903@mail.gmail.com>
	<9418aca70907301054h51d73effq72a4a9b672066862@mail.gmail.com>
	<019f01ca1141$00f875f0$02e961d0$@net> <4A71E4C8.50505@rollernet.us>
Message-ID: <9418aca70907301232v1e0ab042o41b272c365734753@mail.gmail.com>

Here is the config (edited for real IP info, passwords, etc)...

Hub - Main
aaa new-model
!
ip cef
!
crypto isakmp policy 1
 encr aes
 authentication pre-share
 group 2
crypto isakmp key **** address 0.0.0.0 0.0.0.0
crypto isakmp keepalive 10
!
!
crypto ipsec transform-set AES128SHA esp-aes esp-sha-hmac
 mode transport
crypto ipsec transform-set AES128SHAComp esp-aes esp-sha-hmac comp-lzs
 mode transport
!
crypto ipsec profile IPSECPROFILE1
 set transform-set AES128SHA AES128SHAComp
!
!
!
interface Loopback0
 ip address 172.19.3.253 255.255.255.255
 ip nat inside
 ip virtual-reassembly
!
interface Tunnel1
 bandwidth 8000
 ip address 172.19.128.1 255.255.255.0
 no ip redirects
 ip mtu 1400
 ip nat inside
 ip nhrp authentication nhrpauth
 ip nhrp map multicast dynamic
 ip nhrp map multicast b.b.b.b
 ip nhrp map 172.19.128.2 b.b.b.b
 ip nhrp network-id 42
 ip nhrp holdtime 450
 ip virtual-reassembly
 ip tcp adjust-mss 1360
 ip ospf network broadcast
 ip ospf hello-interval 30
 ip ospf priority 200
 delay 1000
 tunnel source GigabitEthernet0/0
 tunnel mode gre multipoint
 tunnel key ****
 tunnel protection ipsec profile IPSECPROFILE1
!
interface GigabitEthernet0/0
 ip address a.a.a.a 255.255.255.240
 ip nat outside
 ip virtual-reassembly
 duplex auto
 speed auto
!
interface GigabitEthernet0/1
 ip address 172.19.0.2 255.255.255.0
 ip nat inside
 ip virtual-reassembly
 duplex full
 speed 1000
 mpls mtu 1508
 mpls ip
 standby 0 ip 172.19.0.1
 standby 0 preempt
 service-policy output VoIPPriority5
!
interface GigabitEthernet0/1.2
 encapsulation dot1Q 2
 ip vrf forwarding voipout
 ip address v.v.v.v 255.255.255.252
!
interface GigabitEthernet0/1.200
 encapsulation dot1Q 200
 ip address 172.19.3.1 255.255.255.248
 ip nat inside
 ip virtual-reassembly
 mpls ip
!
interface GigabitEthernet0/1.201
 encapsulation dot1Q 201
 ip address 172.19.3.9 255.255.255.248
 ip nat inside
 ip virtual-reassembly
!
interface GigabitEthernet0/1.500
 encapsulation dot1Q 500
 ip vrf forwarding dmz
 ip address 172.19.4.2 255.255.255.0
!
router ospf 1
 log-adjacency-changes
 passive-interface default
 no passive-interface GigabitEthernet0/1
 no passive-interface GigabitEthernet0/1.4
 no passive-interface GigabitEthernet0/1.200
 no passive-interface GigabitEthernet0/1.201
 no passive-interface Tunnel1
 network 172.19.0.0 0.0.0.255 area 0
 network 172.19.3.0 0.0.0.7 area 0
 network 172.19.3.8 0.0.0.7 area 0
 network 172.19.3.64 0.0.0.3 area 0
 network 172.19.3.252 0.0.0.1 area 0
 network 172.19.128.0 0.0.0.255 area 0
!
router bgp 100
 bgp log-neighbor-changes
 neighbor 172.19.0.3 remote-as 100
 neighbor 172.19.0.4 remote-as 100
 neighbor 172.19.3.3 remote-as 100
 !
 address-family ipv4
  neighbor 172.19.0.3 activate
  neighbor 172.19.0.4 activate
  neighbor 172.19.3.3 activate
  no auto-summary
  no synchronization
 exit-address-family
 !
 address-family vpnv4
  neighbor 172.19.0.3 activate
  neighbor 172.19.0.3 send-community both
  neighbor 172.19.0.4 activate
  neighbor 172.19.0.4 send-community both
  neighbor 172.19.3.3 activate
  neighbor 172.19.3.3 send-community both
 exit-address-family
 !
 address-family ipv4 vrf voipout
  redistribute connected
  redistribute static
  default-information originate
  no synchronization
 exit-address-family
 !
 address-family ipv4 vrf dmz
  redistribute connected
  redistribute static
  default-information originate
  no synchronization
 exit-address-family
!
ip forward-protocol nd
< static host routes to remote routers on internet side>
ip route vrf dmz 0.0.0.0 0.0.0.0 172.19.4.1
ip route vrf voipout 0.0.0.0 0.0.0.0 w.w.w.w

ip nat inside source list NATIP interface GigabitEthernet0/0 overload
!
ip access-list extended NATIP
 deny   ip 172.19.0.0 0.0.255.255 172.19.0.0 0.0.255.255
 deny   ip 172.19.0.0 0.0.255.255 172.20.20.0 0.0.0.255
 permit ip 172.19.0.0 0.0.255.255 any

access-list 50 remark Management Access Network
<snip>


----- One of the spoke

version 12.4
no ip dhcp use vrf connected
ip cef
crypto isakmp policy 3
 encr aes
 authentication pre-share
 group 2
crypto isakmp key **** address 0.0.0.0 0.0.0.0
crypto isakmp keepalive 60
!
!
crypto ipsec transform-set AES128SHA esp-aes esp-sha-hmac
!
crypto ipsec profile AES128SHAProfile
 set transform-set AES128SHA
!
!
track 123 ip sla 2 reachability
!
!
interface Tunnel0
 bandwidth 1000
 ip address 172.19.128.9 255.255.255.0
 no ip redirects
 ip mtu 1400
 ip nhrp authentication nhrpauth
 ip nhrp map multicast a.a.a.a
 ip nhrp map 172.19.128.1 a.a.a.a
 ip nhrp map multicast b.b.b.b
 ip nhrp map 172.19.128.2 b.b.b.b
 ip nhrp network-id 42
 ip nhrp holdtime 450
 ip nhrp nhs 172.19.128.1
 ip nhrp nhs 172.19.128.2
 no ip route-cache cef
 ip tcp adjust-mss 1360
 ip ospf network broadcast
 ip ospf cost 104
 ip ospf hello-interval 30
 ip ospf priority 0
 delay 1000
 tunnel source Serial0/0/0
 tunnel mode gre multipoint
 tunnel key ****
 tunnel protection ipsec profile AES128SHAProfile
!
interface FastEthernet0/0
 ip address 172.17.28.3 255.255.252.0
 ip nbar protocol-discovery
 ip nat inside
 ip virtual-reassembly
 ip ospf cost 2
 duplex auto
 speed auto
 standby 0 timers 1 3
 standby 2 ip 172.17.28.1
 standby 2 preempt
 standby 2 track Serial0/0/0 50
!
interface FastEthernet0/0.2
 encapsulation dot1Q 2
 ip address o.o.o.o 255.255.255.248
 ip nat outside
 ip virtual-reassembly
 standby 3 ip u.u.u.u
 standby 3 preempt
 standby 3 track Serial0/0/0
!
interface FastEthernet0/1
 no ip address
 shutdown
 duplex auto
 speed auto
!
interface Serial0/0/0
 ip address c.c.c.c 255.255.255.252
 ip nat outside
 ip virtual-reassembly
!
router ospf 1
 log-adjacency-changes
 passive-interface default
 no passive-interface FastEthernet0/0
 no passive-interface Tunnel0
 network 172.17.28.0 0.0.3.255 area 0
 network 172.19.128.0 0.0.0.255 area 0
!
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 d.d.d.d
!
ip nat inside source list NATIP interface Serial0/0/0 overload
!
ip access-list extended NATIP
 deny   ip 172.17.28.0 0.0.3.255 172.17.0.0 0.0.255.255
 deny   ip 172.17.28.0 0.0.3.255 10.1.100.0 0.0.0.255
 deny   ip 172.17.28.0 0.0.3.255 10.1.200.0 0.0.0.255
 deny   ip 172.17.28.0 0.0.3.255 172.19.0.0 0.0.255.255
 permit ip 172.17.28.0 0.0.3.255 any
!
ip sla 2
 icmp-echo 172.17.28.2
 timeout 2000
 threshold 2
 frequency 3
ip sla schedule 2 life forever start-time now
access-list 50 remark Management Access Network
<snip>

On Thu, Jul 30, 2009 at 2:22 PM, Seth Mattinen<sethm at rollernet.us> wrote:
> Luan Nguyen wrote:
>> Care to post the configuration? ?So maybe some of us who think that this
>> problem is interesting could plug it into dynamips and check it out for you?
>> Have you tried to remove the configuration and put it back? ?Maybe add a few
>> loopback interfaces and advertise them?
>>
>
> I'd be interested to see it as well to compare it to mine which isn't
> exhibiting the problem.
>
> ~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 cisco at peakpeak.com  Thu Jul 30 16:13:44 2009
From: cisco at peakpeak.com (Security Team)
Date: Thu, 30 Jul 2009 14:13:44 -0600
Subject: [c-nsp] Multilink PPP Was -> Re: Balancing T1's with CEF
In-Reply-To: <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAAAoN+eMYZG1QKMWQzlsApLTAQAAAAA=@iname.com>
Message-ID: <C6975B18.5C34%cisco@peakpeak.com>

Maybe, but in this case that is a bit like telling me that next time I buy a
new car I should buy Brand X.  Let's see, with gov budgets what they are I
bet that the money might be available in 2019...... :)

Also, only two of these 3 T's is raw so I'd also have to buy demux equipment
to break out the DS3....

It's good to know about though.

CJ


On 7/30/09 12:19 PM, "Frank Bulk - iName.com" <frnkblk at iname.com> wrote:

> All of this is further confirmation that if its IP that you need to send
> over multiple T1's, much better to get an ADC or like box that does Ethernet
> over one or more "raw" T-1's.  Abstracts the whole transport issue, and
> gives Ethernet interfaces on both sides.
> 
> Frank



From gsgranados at comcast.net  Thu Jul 30 18:18:37 2009
From: gsgranados at comcast.net (Scott Granados)
Date: Thu, 30 Jul 2009 15:18:37 -0700
Subject: [c-nsp] problem creating a static on Pix
Message-ID: <010601ca1163$b396cf00$2208120a@am.thmulti.com>

Hi, I'm having the following issue.

Background

I have two networks one public 206.x.x.77/27 and internal 10.18.x.253/27.  I 
wish to open port 80 to the world and allow web traffic.

I've added the following static line.

static (inside,outside) tcp 206.x.x.77 80 10.18.x.253 80 netmask 
255.255.255.255 0 0

I have added the following to my ACL

access-list acl-outside permit ip any host 10.18.x.253 eq 80
(the first line in sequence)

Finally, I apply the acl as follows

access-group acl-outside in interface outside

I've confirmed that the device is listening on 80 and accepting connections 
and I've confirmed that the device can route out to the internet by pinging 
some distant network addresses.  My issue is I can't initiate a connection 
from the outside in.  Telnet to 206.x.x.77 80 yields "no route to host" from 
a Linux box out in the field.  I tried to execute a telnet from the router 
on 206.x.x.65 (the gateway to the outside network) to 206.x.x.77 80 and it 
simply hangs.  (testing connectivity on the same segment)  What have I 
missed?

This feels like it should be something obvious but I've been pulling my hair 
out (what's left) and no lights are going on.  Any pointers would be 
appreciated.

Thanks
Scott


From mksmith at adhost.com  Thu Jul 30 18:35:46 2009
From: mksmith at adhost.com (Michael K. Smith - Adhost)
Date: Thu, 30 Jul 2009 15:35:46 -0700
Subject: [c-nsp] problem creating a static on Pix
In-Reply-To: <010601ca1163$b396cf00$2208120a@am.thmulti.com>
References: <010601ca1163$b396cf00$2208120a@am.thmulti.com>
Message-ID: <17838240D9A5544AAA5FF95F8D5203160676B7F4@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 Scott Granados
> Sent: Thursday, July 30, 2009 3:19 PM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] problem creating a static on Pix
> 
> Hi, I'm having the following issue.
> 
> Background
> 
> I have two networks one public 206.x.x.77/27 and internal
> 10.18.x.253/27.  I
> wish to open port 80 to the world and allow web traffic.
> 
> I've added the following static line.
> 
> static (inside,outside) tcp 206.x.x.77 80 10.18.x.253 80 netmask
> 255.255.255.255 0 0
> 
> I have added the following to my ACL
> 
> access-list acl-outside permit ip any host 10.18.x.253 eq 80
> (the first line in sequence)
> 

Your outside ACL should reference your outside IP, not the inside.

Access-list acl-outside permit ip any host 206.x.x.77 eqw 80

Regards,

Mike

From awilliam1981 at gmail.com  Thu Jul 30 18:42:00 2009
From: awilliam1981 at gmail.com (Andy William)
Date: Fri, 31 Jul 2009 01:42:00 +0300
Subject: [c-nsp] ISP in US
In-Reply-To: <A6DBBABA-A6D8-41EF-9005-40DAFCE14657@introspect.net>
References: <9569de140907290644j11098b10l7c9c929ce4b30bb9@mail.gmail.com>
	<A6DBBABA-A6D8-41EF-9005-40DAFCE14657@introspect.net>
Message-ID: <9569de140907301542j5519a2e5j9fd32c0a8bf16ce0@mail.gmail.com>

Thx all and i will think about Gulfstream Daryl :)

but i start to think about P2P connections like AT&T IPL (International
Private Line) or ATM PVC between both sites , what do you think ? what is
the estimated cost for 2M connection ?


best regards
Andy


On Thu, Jul 30, 2009 at 8:42 PM, Daryl G. Jurbala <daryl at introspect.net>wrote:

> None.  There is no common carrier between the two.  The US has plenty to
> choose from.  The Middle East has very few, all buying from one or two top
> tier in-region carriers.
>
> It is also likely that you will have to use a VPN between the sites, as any
> type of SIP/RTP/H.323 is likely to be blocked in the border in the Middle
> East.
>
> That being said, I seriously doubt you need what you think you need
> (guaranteed QoS).  If you do, you can absolutely purchase an MPLS tunnel
> between wherever you like, with dedicated QoS.  After all of the
> interconnect fees from each carrier it may have to pass though, likely
> bandwidth-metered, it would be cheaper to purchase a private Gulfstream V
> and build an airport at each site.
>
>
> On Jul 29, 2009, at 9:44 AM, Andy William wrote:
>
>
>> according to your experince with ISPs in US , what is the best ISP that
>> can
>> offer QoS-based service between 2 internet points (US and ME) ?
>>
>>
>

From td_miles at yahoo.com  Thu Jul 30 18:43:31 2009
From: td_miles at yahoo.com (Tony)
Date: Thu, 30 Jul 2009 15:43:31 -0700 (PDT)
Subject: [c-nsp] problem creating a static on Pix
In-Reply-To: <010601ca1163$b396cf00$2208120a@am.thmulti.com>
Message-ID: <643165.19962.qm@web110102.mail.gq1.yahoo.com>

Your access list need to have the OUTSIDE address in it, as this is what will be in the packets arriving on the outside interface of your PIX eg:

access-list acl-outside permit ip any host 206.x.x.77 eq 80


This URL:
http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080133ddd.shtml
http://tinyurl.com/8vrj

lists the order of operation that happen on the PIX. You can see that for outside-to-inside the access-list is step 3 and the NAT happens at step 6. This means that the ACL is checked before any NAT happens and so the packets will still have the outside address in them (they haven'tbeen NAT'ed yet).



regards,
Tony.




--- On Fri, 31/7/09, Scott Granados <gsgranados at comcast.net> wrote:

> From: Scott Granados <gsgranados at comcast.net>
> Subject: [c-nsp] problem creating a static on Pix
> To: cisco-nsp at puck.nether.net
> Date: Friday, 31 July, 2009, 8:18 AM
> Hi, I'm having the following issue.
> 
> Background
> 
> I have two networks one public 206.x.x.77/27 and internal
> 10.18.x.253/27.? I wish to open port 80 to the world
> and allow web traffic.
> 
> I've added the following static line.
> 
> static (inside,outside) tcp 206.x.x.77 80 10.18.x.253 80
> netmask 255.255.255.255 0 0
> 
> I have added the following to my ACL
> 
> access-list acl-outside permit ip any host 10.18.x.253 eq
> 80
> (the first line in sequence)
> 
> Finally, I apply the acl as follows
> 
> access-group acl-outside in interface outside
> 
> I've confirmed that the device is listening on 80 and
> accepting connections and I've confirmed that the device can
> route out to the internet by pinging some distant network
> addresses.? My issue is I can't initiate a connection
> from the outside in.? Telnet to 206.x.x.77 80 yields
> "no route to host" from a Linux box out in the field.?
> I tried to execute a telnet from the router on 206.x.x.65
> (the gateway to the outside network) to 206.x.x.77 80 and it
> simply hangs.? (testing connectivity on the same
> segment)? What have I missed?
> 
> This feels like it should be something obvious but I've
> been pulling my hair out (what's left) and no lights are
> going on.? Any pointers would be appreciated..
> 
> Thanks
> Scott
> 
> _______________________________________________
> cisco-nsp mailing list? cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 


      


From awilliam1981 at gmail.com  Thu Jul 30 18:43:44 2009
From: awilliam1981 at gmail.com (Andy William)
Date: Fri, 31 Jul 2009 01:43:44 +0300
Subject: [c-nsp] ISP in US
In-Reply-To: <9569de140907301542j5519a2e5j9fd32c0a8bf16ce0@mail.gmail.com>
References: <9569de140907290644j11098b10l7c9c929ce4b30bb9@mail.gmail.com>
	<A6DBBABA-A6D8-41EF-9005-40DAFCE14657@introspect.net>
	<9569de140907301542j5519a2e5j9fd32c0a8bf16ce0@mail.gmail.com>
Message-ID: <9569de140907301543y7ed282cfi2222a72247c31e2d@mail.gmail.com>

also SVC will be better

On Fri, Jul 31, 2009 at 1:42 AM, Andy William <awilliam1981 at gmail.com>wrote:

>  Thx all and i will think about Gulfstream Daryl :)
>
> but i start to think about P2P connections like AT&T IPL (International
> Private Line) or ATM PVC between both sites , what do you think ? what is
> the estimated cost for 2M connection ?
>
>
> best regards
> Andy
>
>
> On Thu, Jul 30, 2009 at 8:42 PM, Daryl G. Jurbala <daryl at introspect.net>wrote:
>
>> None.  There is no common carrier between the two.  The US has plenty to
>> choose from.  The Middle East has very few, all buying from one or two top
>> tier in-region carriers.
>>
>> It is also likely that you will have to use a VPN between the sites, as
>> any type of SIP/RTP/H.323 is likely to be blocked in the border in the
>> Middle East.
>>
>> That being said, I seriously doubt you need what you think you need
>> (guaranteed QoS).  If you do, you can absolutely purchase an MPLS tunnel
>> between wherever you like, with dedicated QoS.  After all of the
>> interconnect fees from each carrier it may have to pass though, likely
>> bandwidth-metered, it would be cheaper to purchase a private Gulfstream V
>> and build an airport at each site.
>>
>>
>> On Jul 29, 2009, at 9:44 AM, Andy William wrote:
>>
>>
>>> according to your experince with ISPs in US , what is the best ISP that
>>> can
>>> offer QoS-based service between 2 internet points (US and ME) ?
>>>
>>>
>>
>

From gsgranados at comcast.net  Thu Jul 30 18:50:04 2009
From: gsgranados at comcast.net (Scott Granados)
Date: Thu, 30 Jul 2009 15:50:04 -0700
Subject: [c-nsp] problem creating a static on Pix
References: <010601ca1163$b396cf00$2208120a@am.thmulti.com>
	<17838240D9A5544AAA5FF95F8D5203160676B7F4@ad-exh01.adhost.lan>
Message-ID: <012b01ca1168$19048cc0$2208120a@am.thmulti.com>

Cool, this really helps.

I also have an acl applied to the inside interface.  Would I have to add the 
inside IP to that ACL as well, is this a bidirectional arrangement?

Thank you again

----- Original Message ----- 
From: "Michael K. Smith - Adhost" <mksmith at adhost.com>
To: "Scott Granados" <gsgranados at comcast.net>; <cisco-nsp at puck.nether.net>
Sent: Thursday, July 30, 2009 3:35 PM
Subject: RE: [c-nsp] problem creating a static on Pix




> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> bounces at puck.nether.net] On Behalf Of Scott Granados
> Sent: Thursday, July 30, 2009 3:19 PM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] problem creating a static on Pix
>
> Hi, I'm having the following issue.
>
> Background
>
> I have two networks one public 206.x.x.77/27 and internal
> 10.18.x.253/27.  I
> wish to open port 80 to the world and allow web traffic.
>
> I've added the following static line.
>
> static (inside,outside) tcp 206.x.x.77 80 10.18.x.253 80 netmask
> 255.255.255.255 0 0
>
> I have added the following to my ACL
>
> access-list acl-outside permit ip any host 10.18.x.253 eq 80
> (the first line in sequence)
>

Your outside ACL should reference your outside IP, not the inside.

Access-list acl-outside permit ip any host 206.x.x.77 eqw 80

Regards,

Mike 


From gsgranados at comcast.net  Thu Jul 30 18:59:54 2009
From: gsgranados at comcast.net (Scott Granados)
Date: Thu, 30 Jul 2009 15:59:54 -0700
Subject: [c-nsp] problem creating a static on Pix
References: <010601ca1163$b396cf00$2208120a@am.thmulti.com>
	<17838240D9A5544AAA5FF95F8D5203160676B7F4@ad-exh01.adhost.lan>
	<012b01ca1168$19048cc0$2208120a@am.thmulti.com>
	<17838240D9A5544AAA5FF95F8D5203160676B7F7@ad-exh01.adhost.lan>
Message-ID: <014f01ca1169$78ba1620$2208120a@am.thmulti.com>

Mike, thank you this points me in the right direction.

Thanks!!!

Scott

----- Original Message ----- 
From: "Michael K. Smith - Adhost" <mksmith at adhost.com>
To: "Scott Granados" <gsgranados at comcast.net>; <cisco-nsp at puck.nether.net>
Sent: Thursday, July 30, 2009 3:51 PM
Subject: RE: [c-nsp] problem creating a static on Pix


Hello Scott:

> -----Original Message-----
> From: Scott Granados [mailto:gsgranados at comcast.net]
> Sent: Thursday, July 30, 2009 3:50 PM
> To: Michael K. Smith - Adhost; cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] problem creating a static on Pix
> 
> Cool, this really helps.
> 
> I also have an acl applied to the inside interface.  Would I have to
> add the
> inside IP to that ACL as well, is this a bidirectional arrangement?
> 

The inside ACL is just for traffic originating from the 10. Network.
Anything coming inbound will be allowed back out according to its
presence in the state table.  However, if you want to originate a
connection from the inside on port 80 or 443, as an example, those would
have to be added as such:

Access-list acl-inside permit tcp host 10.x.x.77 any eq 80

Regards,

Mike

From mksmith at adhost.com  Thu Jul 30 18:51:57 2009
From: mksmith at adhost.com (Michael K. Smith - Adhost)
Date: Thu, 30 Jul 2009 15:51:57 -0700
Subject: [c-nsp] problem creating a static on Pix
In-Reply-To: <012b01ca1168$19048cc0$2208120a@am.thmulti.com>
References: <010601ca1163$b396cf00$2208120a@am.thmulti.com>
	<17838240D9A5544AAA5FF95F8D5203160676B7F4@ad-exh01.adhost.lan>
	<012b01ca1168$19048cc0$2208120a@am.thmulti.com>
Message-ID: <17838240D9A5544AAA5FF95F8D5203160676B7F7@ad-exh01.adhost.lan>

Hello Scott:

> -----Original Message-----
> From: Scott Granados [mailto:gsgranados at comcast.net]
> Sent: Thursday, July 30, 2009 3:50 PM
> To: Michael K. Smith - Adhost; cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] problem creating a static on Pix
> 
> Cool, this really helps.
> 
> I also have an acl applied to the inside interface.  Would I have to
> add the
> inside IP to that ACL as well, is this a bidirectional arrangement?
> 

The inside ACL is just for traffic originating from the 10. Network.
Anything coming inbound will be allowed back out according to its
presence in the state table.  However, if you want to originate a
connection from the inside on port 80 or 443, as an example, those would
have to be added as such:

Access-list acl-inside permit tcp host 10.x.x.77 any eq 80

Regards,

Mike

From graham at g-rock.net  Thu Jul 30 21:07:55 2009
From: graham at g-rock.net (Graham Wooden)
Date: Thu, 30 Jul 2009 20:07:55 -0500
Subject: [c-nsp] confreg 0x42 on a Sup32
Message-ID: <C697AE1B.7AE6%graham@g-rock.net>

Hi there,

Not much out there on this for the Sup32. But since the Sup32 is a upgraded
MSFC2, will the config register ?0x42? bypass the config?
Someone borked up the aaa auth and I can't get into it.  Bah.

Thanks,

-graham 



From tstevens at cisco.com  Thu Jul 30 23:07:37 2009
From: tstevens at cisco.com (Tim Stevenson)
Date: Thu, 30 Jul 2009 20:07:37 -0700
Subject: [c-nsp] confreg 0x42 on a Sup32
In-Reply-To: <C697AE1B.7AE6%graham@g-rock.net>
References: <C697AE1B.7AE6%graham@g-rock.net>
Message-ID: <200907310307.n6V37bkC017097@sj-core-5.cisco.com>

Hi Graham -

The same rules for confreg that apply to the other c6k sups apply here as well.

Typical/recommended for sup32 is 0x2102. To 
ignore config 0x2142 will do it. 0x42 should work 
too, but for one thing, ignore break will be 
disabled, which is not desirable (router can drop 
to rommon during runtime due to deliberate/spurious break).

Hope that helps,
Tim



At 06:07 PM 7/30/2009, Graham Wooden asserted:

>Hi there,
>
>Not much out there on this for the Sup32. But since the Sup32 is a upgraded
>MSFC2, will the config register ?0x42? bypass the config?
>Someone borked up the aaa auth and I can't get into it.  Bah.
>
>Thanks,
>
>-graham
>
>
>_______________________________________________
>cisco-nsp mailing list  cisco-nsp at puck.nether.net
><https://puck.nether.net/mailman/listinfo/cisco-nsp>https://puck.nether.net/mailman/listinfo/cisco-nsp
>archive at 
><http://puck.nether.net/pipermail/cisco-nsp/>http://puck.nether.net/pipermail/cisco-nsp/




Tim Stevenson, tstevens at cisco.com
Routing & Switching CCIE #5561
Technical Marketing Engineer, Cisco Nexus 7000
Cisco - http://www.cisco.com
IP Phone: 408-526-6759
********************************************************
The contents of this message may be *Cisco Confidential*
and are intended for the specified recipients only.

From jckdaniels12 at gmail.com  Fri Jul 31 00:23:36 2009
From: jckdaniels12 at gmail.com (jack daniels)
Date: Fri, 31 Jul 2009 09:53:36 +0530
Subject: [c-nsp] SFC DOWN
In-Reply-To: <8bb137f40907302114n72fafa06ldc4ef0505774454c@mail.gmail.com>
References: <8bb137f40907302114n72fafa06ldc4ef0505774454c@mail.gmail.com>
Message-ID: <8bb137f40907302123w522dc0d7s3af539e0c38579b4@mail.gmail.com>

> Hi All,
>
> I'm facing a issue  in Cisco 12416  request your help -
>
>  show GSR -
>  "Slot 19 type = Switch Fabric Card 16XOC192
> state = Administratively Down, Powered" <<<<<<<<<<<<<<<<<<<<<<
>
> how to take it out of this Administratively down state to powered state.
>
> My IOS version is 12.0(32)SY6
>
>
> Regards
> Jack
>

From andy.saykao at staff.netspace.net.au  Fri Jul 31 01:44:37 2009
From: andy.saykao at staff.netspace.net.au (Andy Saykao)
Date: Fri, 31 Jul 2009 15:44:37 +1000
Subject: [c-nsp] How to monitor ipsec tunnel
Message-ID: <56F211C5E3F24F47B103EA1B253822BE044AAAD6@vic-cr-ex1.staff.netspace.net.au>

Hi All,
 
We've got an IPSEC tunnel configured with another provider for the
exchange of some sensitive data and I wanted to know if there was a way
to monitor the IPSEC tunnel to ensure it was up. 
 
We're using a Cisco 3640 running 12.2(46a). 
 
I've checked the mibs for this hardware platform and IOS from the Cisco
IOS MIB Locator but can't really find any mibs to help me monitor the
status of the tunnel.
 
http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml
 
core#sh crypto isakmp sa
dst             src             state           conn-id    slot
203.17.98.x     203.41.142.x    QM_IDLE               1       0
 
We are trying to monitor the IPSEC tunnel using nagios.
 
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 jrhett at netconsonance.com  Fri Jul 31 02:30:02 2009
From: jrhett at netconsonance.com (Jo Rhett)
Date: Thu, 30 Jul 2009 23:30:02 -0700
Subject: [c-nsp] Humor: Cisco announces end of BGP
In-Reply-To: <2C05E949E19A9146AF7BDF9D44085B863541D03D13@exchange.aoihq.local>
References: <5.1.0.14.2.20090728104929.051778f8@efes.iucc.ac.il>
	<4A6F2DD0.1060608@justinshore.com>	<005901ca0fc2$939d6bc0$0a00000a@nil.si>
	<4A6F66C2.1080400@justinshore.com>
	<2C05E949E19A9146AF7BDF9D44085B863541D03D0A@exchange.aoihq.local>
	<00c201ca103c$f6a82fa0$e3f88ee0$@com>
	<2C05E949E19A9146AF7BDF9D44085B863541D03D13@exchange.aoihq.local>
Message-ID: <6CB3EB3C-AE39-4FB1-8834-24B637A32BC6@netconsonance.com>

AboveNet and Savvis hardly count.   AboveNet is a great carrier but  
small, and Savvis is a walking dead man hoping someone will buy him.   
Neither one has, nor will have, the budget or personnel to handle v6.

Level3 and Verizon both have v6 if you ask real nice.  As does XO and  
others.

On Jul 29, 2009, at 6:58 AM, Eric Van Tol wrote:
> Let's see...from our "big carriers":
>
> AboveNet: No IPv6
> Verizon:  No IPv6
> Savvis:  No IPv6
> Level3: No IPv6
> GBLX: IPv6!
> Verio: IPv6!
>
> Sure, we have some smaller providers and peers that run it, too, but  
> until the majority of our so-called "Tier 1" providers start  
> deploying it *and making it easy to request*, I stick to my guns by  
> saying that he wasn't that far off.
>
> -evt
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

-- 
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source  
and other randomness


From rens at autempspourmoi.be  Fri Jul 31 03:34:59 2009
From: rens at autempspourmoi.be (Rens)
Date: Fri, 31 Jul 2009 09:34:59 +0200
Subject: [c-nsp] Point to Multipoint L2L
Message-ID: <645E47A9FBA049EB9B9B6F188CDC2F51@EU.corp.clearwire.com>

Hi all,

 

Currently we setup Lan2Lan services via L2TPv3 tunnels and with QinQ if vlan
transparency is needed.

The problem is that sometimes we need to connect multiple sites to the same
L2L.

 

I have read a little bit about VPLS but it seems you need a MPLS network for
this, which I don't have.

Any other possibilities without having MPLS?

 

Regards,

 

Rens


From ben at cuckoo.org  Fri Jul 31 03:42:40 2009
From: ben at cuckoo.org (Ben White)
Date: Fri, 31 Jul 2009 08:42:40 +0100
Subject: [c-nsp] How to monitor ipsec tunnel
In-Reply-To: <56F211C5E3F24F47B103EA1B253822BE044AAAD6@vic-cr-ex1.staff.netspace.net.au>
References: <AcoRof2gMPrASqnpT3urcG+Swt8jYA==>
	<56F211C5E3F24F47B103EA1B253822BE044AAAD6@vic-cr-ex1.staff.netspace.net.au>
Message-ID: <b4a117b30907310042k88682edk1fcf325a66f6cd52@mail.gmail.com>

You can get a count of the number of tunnels up under
1.3.6.1.4.1.9.9.171.1.3.1.1

http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Translate&objectInput=cipSecGlobalActiveTunnels

Check min/max values on that?

2009/7/31 Andy Saykao <andy.saykao at staff.netspace.net.au>:
> Hi All,
>
> We've got an IPSEC tunnel configured with another provider for the
> exchange of some sensitive data and I wanted to know if there was a way
> to monitor the IPSEC tunnel to ensure it was up.
>
> We're using a Cisco 3640 running 12.2(46a).
>
> I've checked the mibs for this hardware platform and IOS from the Cisco
> IOS MIB Locator but can't really find any mibs to help me monitor the
> status of the tunnel.
>
> http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml
>
> core#sh crypto isakmp sa
> dst ? ? ? ? ? ? src ? ? ? ? ? ? state ? ? ? ? ? conn-id ? ?slot
> 203.17.98.x ? ? 203.41.142.x ? ?QM_IDLE ? ? ? ? ? ? ? 1 ? ? ? 0
>
> We are trying to monitor the IPSEC tunnel using nagios.
>
> Cheers.
>
> Andy
>
> This email and any files transmitted with it are confidential and intended
> ?solely for the use of the individual or entity to whom they are addressed.
> Please notify the sender immediately by email if you have received this
> email by mistake and delete this email from your system. Please note that
> ?any views or opinions presented in this email are solely those of the
> ?author and do not necessarily represent those of the organisation.
> Finally, the recipient should check this email and any attachments for
> the presence of viruses. The organisation accepts no liability for any
> damage caused by any virus transmitted by this email.
>
> _______________________________________________
> cisco-nsp mailing list ?cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>



-- 
Ben

From andy.saykao at staff.netspace.net.au  Fri Jul 31 04:13:41 2009
From: andy.saykao at staff.netspace.net.au (Andy Saykao)
Date: Fri, 31 Jul 2009 18:13:41 +1000
Subject: [c-nsp] How to monitor ipsec tunnel
References: <AcoRof2gMPrASqnpT3urcG+Swt8jYA==>
	<56F211C5E3F24F47B103EA1B253822BE044AAAD6@vic-cr-ex1.staff.netspace.net.au>
	<b4a117b30907310042k88682edk1fcf325a66f6cd52@mail.gmail.com>
Message-ID: <56F211C5E3F24F47B103EA1B253822BE044AAADA@vic-cr-ex1.staff.netspace.net.au>

Thanks Ben.

Unfortunately, that OID object doesn't exist on the Cisco 3640 with the IOS I'm using.

nagios# snmpwalk -v 2c -c public 203.17.101.x 1.3.6.1.4.1.9.9.171.1.3.1.1
SNMPv2-SMI::enterprises.9.9.171.1.3.1.1 = No Such Object available on this agent at this OID

nagios# snmpwalk -v 2c -c public 203.17.101.x 1.3.6.1.4.1.9.9 | grep 171
nagios#

The CISCO-IPSEC-MIB with OID 1.3.6.1.4.1.9.10.62 doesn't exist either.

nagios# snmpwalk -v 2c -c public 203.17.101.x 1.3.6.1.4.1.9.10.62
SNMPv2-SMI::enterprises.9.10.62 = No Such Object available on this agent at this OID

Cheers.

Andy

-----Original Message-----
From: biwhite at gmail.com [mailto:biwhite at gmail.com] On Behalf Of Ben White
Sent: Friday, 31 July 2009 5:43 PM
To: Andy Saykao
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] How to monitor ipsec tunnel

You can get a count of the number of tunnels up under
1.3.6.1.4.1.9.9.171.1.3.1.1

http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Translate&objectInput=cipSecGlobalActiveTunnels

Check min/max values on that?

2009/7/31 Andy Saykao <andy.saykao at staff.netspace.net.au>:
> Hi All,
>
> We've got an IPSEC tunnel configured with another provider for the 
> exchange of some sensitive data and I wanted to know if there was a 
> way to monitor the IPSEC tunnel to ensure it was up.
>
> We're using a Cisco 3640 running 12.2(46a).
>
> I've checked the mibs for this hardware platform and IOS from the 
> Cisco IOS MIB Locator but can't really find any mibs to help me 
> monitor the status of the tunnel.
>
> http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml
>
> core#sh crypto isakmp sa
> dst ? ? ? ? ? ? src ? ? ? ? ? ? state ? ? ? ? ? conn-id ? ?slot 
> 203.17.98.x ? ? 203.41.142.x ? ?QM_IDLE ? ? ? ? ? ? ? 1 ? ? ? 0
>
> We are trying to monitor the IPSEC tunnel using nagios.
>
> Cheers.
>
> Andy
>
> This email and any files transmitted with it are confidential and 
> intended
> ?solely for the use of the individual or entity to whom they are addressed.
> Please notify the sender immediately by email if you have received 
> this email by mistake and delete this email from your system. Please 
> note that
> ?any views or opinions presented in this email are solely those of the
> ?author and do not necessarily represent those of the organisation.
> Finally, the recipient should check this email and any attachments for 
> the presence of viruses. The organisation accepts no liability for any 
> damage caused by any virus transmitted by this email.
>
> _______________________________________________
> cisco-nsp mailing list ?cisco-nsp at puck.nether.net 
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>



--
Ben

______________________________________________________________________
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 narmaw at pertamina-ep.com  Fri Jul 31 05:29:15 2009
From: narmaw at pertamina-ep.com (Narma Wahyuadi)
Date: Fri, 31 Jul 2009 16:29:15 +0700
Subject: [c-nsp] MTBF & MTTR in mpls
Message-ID: <013401ca11c1$5f0e3f50$1d2abdf0$@com>

anyone know what is value of mtbf & mttr usually in cloud MPLS ? is there
any resource to calculate it ? for me it's very difficult to know my MPLS
reliability


_____________________________________________________________________

Note: The information contained in this e-mail is intended only for the use of the individual or entity named above and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended party to receive the message and its attachment(s), you are hereby notified that any dissemination, distribution or copy of the message is strictly prohibited. Please immediately notify the sender and delete the message as soon as possible. Thank you for kind attention.
 
Catatan: Informasi yang terdapat dalam e-mail ini ditujukan hanya untuk penggunaan individu atau kelompok yang disebutkan di atas dan mungkin berisi informasi yang istimewa, rahasia dan dikecualikan dari pengungkapan menurut hukum yang berlaku. Jika Anda bukan pihak yang ditujukan untuk menerima pesan ini beserta lampirannya, dengan ini Anda diberitahukan bahwa penyebaran, pendistribusian atau penyalinan pesan ini adalah sangat dilarang. Harap segera memberitahu pengirim dan menghapus pesan ini secepatnya. Terima kasih atas perhatian Anda.

From markom at markom.info  Fri Jul 31 06:24:47 2009
From: markom at markom.info (Marko Milivojevic)
Date: Fri, 31 Jul 2009 10:24:47 +0000
Subject: [c-nsp] 7206 NPE-G2 - Cat 3750 sfp issue
In-Reply-To: <7.0.1.0.2.20090730185902.04b8d458@moov.mg>
References: <7.0.1.0.2.20090730185902.04b8d458@moov.mg>
Message-ID: <d163b99c0907310324u46104733yefd7a24a9623ce98@mail.gmail.com>

> I use
> 1000BASE-LX/LH (GLC-LH-SM), on both Catalyst and 7206 NPE-G2, interface and
> protocol are up but I cannot do anything, what am I missing?

How are your speed negotiation settings on both ends?

From lobotiger at gmail.com  Fri Jul 31 08:22:59 2009
From: lobotiger at gmail.com (Lobo)
Date: Fri, 31 Jul 2009 08:22:59 -0400
Subject: [c-nsp] 3750 switch dropping packets when trust dscp enabled
In-Reply-To: <8B25B862BC09784B9B74FB950D4F64D40F84BC@qcnapp01.corp.qcn>
References: <8B25B862BC09784B9B74FB950D4F64D40F84BC@qcnapp01.corp.qcn>
Message-ID: <4A72E223.5010400@gmail.com>

Thanks for the explanation Brad.  Makes sense to me now.

Jose

Brad Henshaw wrote:
>  
> Lobo wrote:
>
>   
>> I setup a traffic generator to send 95Mbps of traffic with DSCP EF
>> (46) across the different switches but when it hit the 3750, the
>> egress traffic was only ~4Mbps.
>>     
>
>   
>> After reading up a bit, I found a command "srr-queue bandwidth shape" 
>> that I could apply to the interfaces.  After adding that command with
>> all 0s for the queues I was then able to receive all 95Mbps of
>>     
> traffic.  
>   
>> I noticed that the default values for that command are 25 0 0 0.
>>     
>
>   
>> Is this something that I'm supposed to do if I just want to trust the
>> DSCP markings and not overwrite them on the 3750s?
>>     
>
> This isn't a marking issue, it's a shaping issue. As you discovered, 
> Queue 1 (to which DSCP 46 is mapped) is shaped to 1/25th of the port
> capacity which is 4Mbps. This was causing your traffic to be
> rate-limited
> to 4Mbps (not remarked).
>
> The shape command you entered effectively disables shaping and all
> queues
> will operate in shared mode.
>
> You might want to think about the implications of permitting an
> uncontrolled quantity of DSCP 46 traffic into your network, either now
> or
> at a later date.
>
> Regards,
> Brad
>   

From oboehmer at cisco.com  Fri Jul 31 09:28:58 2009
From: oboehmer at cisco.com (Oliver Boehmer (oboehmer))
Date: Fri, 31 Jul 2009 15:28:58 +0200
Subject: [c-nsp] Route Reflectors & Multipath
In-Reply-To: <004e01ca0bd7$b8199940$284ccbc0$@org.uk>
References: <004e01ca0bd7$b8199940$284ccbc0$@org.uk>
Message-ID: <70B7A1CCBFA5C649BD562B6D9F7ED78407BC8661@xmb-ams-333.emea.cisco.com>

Dean Smith <> wrote on Thursday, July 23, 2009 22:54:

> Is there any tweak, trick or feature that enables a route-reflector
> to pass on multiple iBGP paths to clients ?
> 
> This is for a straightforward iBGP ipv4 setup (no multiprotocol bgp
> or MPLS, so no unique VRF ids etc).

until add-path is available (not sure about roadmap), you can build two
RR planes, and try to keep the individual paths on separate planes. So
RRs in plane A don't peer with RRs in plane B.. It requires manual
policies (to send paths from a RR-client to the "right" plane with the
"right" metric), so it's not a general solution.

	oli

From graham at g-rock.net  Fri Jul 31 09:35:15 2009
From: graham at g-rock.net (Graham Wooden)
Date: Fri, 31 Jul 2009 09:35:15 -0400
Subject: [c-nsp] confreg 0x42 on a Sup32
In-Reply-To: <200907310307.n6V37bkC017097@sj-core-5.cisco.com>
References: <C697AE1B.7AE6%graham@g-rock.net>
	<200907310307.n6V37bkC017097@sj-core-5.cisco.com>
Message-ID: <20090731093515.ocbrusj2m808c044@webmail.iamforeverme.com>

Thanks Tim and Jesse for the replies.

Well, I only had a small window this morning to get this resolved and  
both confregs from rommon didn't seem to bypass the config like I  
wanted. Also tried just confreg with no args, and selecting it to  
ignore the config with still no affect.

But as I type this, I did it from the SP rommon.  Should I have done  
the break at the RP boot instead?

I will have another window this evening to get this resolved. Thanks  
for any suggestions.

-graham


Quoting Tim Stevenson <tstevens at cisco.com>:

> Hi Graham -
>
> The same rules for confreg that apply to the other c6k sups apply here
> as well.
>
> Typical/recommended for sup32 is 0x2102. To ignore config 0x2142 will
> do it. 0x42 should work too, but for one thing, ignore break will be
> disabled, which is not desirable (router can drop to rommon during
> runtime due to deliberate/spurious break).
>
> Hope that helps,
> Tim
>
>
>
> At 06:07 PM 7/30/2009, Graham Wooden asserted:
>
>> Hi there,
>>
>> Not much out there on this for the Sup32. But since the Sup32 is a upgraded
>> MSFC2, will the config register ?0x42? bypass the config?
>> Someone borked up the aaa auth and I can't get into it.  Bah.
>>
>> Thanks,
>>
>> -graham



From jason at pins.net  Fri Jul 31 10:58:20 2009
From: jason at pins.net (Jason)
Date: Fri, 31 Jul 2009 10:58:20 -0400
Subject: [c-nsp] GRE
Message-ID: <4A73068C.3080708@pins.net>

Greetings,

This is a quick and simple question.  Can someone confirm my suspicion 
that GRE is process switched on a 2651XM?  Also, if there's a document 
somewhere outlining what is process switched on which router/switch that 
would be really handy to have.

Thanks,
Jason

From jeff-kell at utc.edu  Fri Jul 31 11:23:36 2009
From: jeff-kell at utc.edu (Jeff Kell)
Date: Fri, 31 Jul 2009 11:23:36 -0400
Subject: [c-nsp] GRE/NAT ?
In-Reply-To: <4A73068C.3080708@pins.net>
References: <4A73068C.3080708@pins.net>
Message-ID: <4A730C78.6070804@utc.edu>

The GRE question reminded me of a nagging thought...

Can you NAT traffic inside GRE? 

Jeff

From rodunn at cisco.com  Fri Jul 31 11:40:00 2009
From: rodunn at cisco.com (Rodney Dunn)
Date: Fri, 31 Jul 2009 11:40:00 -0400
Subject: [c-nsp] GRE
In-Reply-To: <4A73068C.3080708@pins.net>
References: <4A73068C.3080708@pins.net>
Message-ID: <4A731050.3060908@cisco.com>



Jason wrote:
> Greetings,
> 
> This is a quick and simple question.  Can someone confirm my suspicion 
> that GRE is process switched on a 2651XM?

on 12.4 and later code (can't remember exactly where we did it) the SYN 
is CEF switched and the rest of the flow. RST/FIN's are process switched 
to tear down the translation.

Then if you have any ALG processing for embedded payload it's all 
process switched.

Plug for NAT:

ASR1k does it all in hardware. ;)


   Also, if there's a document
> somewhere outlining what is process switched on which router/switch that 
> would be really handy to have.

Doesn't exist. Too many variables.



> 
> 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 rodunn at cisco.com  Fri Jul 31 11:40:12 2009
From: rodunn at cisco.com (Rodney Dunn)
Date: Fri, 31 Jul 2009 11:40:12 -0400
Subject: [c-nsp] GRE/NAT ?
In-Reply-To: <4A730C78.6070804@utc.edu>
References: <4A73068C.3080708@pins.net> <4A730C78.6070804@utc.edu>
Message-ID: <4A73105C.3000907@cisco.com>

No.



Jeff Kell wrote:
> The GRE question reminded me of a nagging thought...
> 
> Can you NAT traffic inside GRE? 
> 
> 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 mksmith at adhost.com  Fri Jul 31 11:44:38 2009
From: mksmith at adhost.com (Michael K. Smith - Adhost)
Date: Fri, 31 Jul 2009 08:44:38 -0700
Subject: [c-nsp] Humor: Cisco announces end of BGP
In-Reply-To: <6CB3EB3C-AE39-4FB1-8834-24B637A32BC6@netconsonance.com>
References: <5.1.0.14.2.20090728104929.051778f8@efes.iucc.ac.il><4A6F2DD0.1060608@justinshore.com>	<005901ca0fc2$939d6bc0$0a00000a@nil.si><4A6F66C2.1080400@justinshore.com><2C05E949E19A9146AF7BDF9D44085B863541D03D0A@exchange.aoihq.local><00c201ca103c$f6a82fa0$e3f88ee0$@com><2C05E949E19A9146AF7BDF9D44085B863541D03D13@exchange.aoihq.local>
	<6CB3EB3C-AE39-4FB1-8834-24B637A32BC6@netconsonance.com>
Message-ID: <17838240D9A5544AAA5FF95F8D5203160676B840@ad-exh01.adhost.lan>

Add Time Warner to the IPv6 enabled list as well.

Mike

> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> bounces at puck.nether.net] On Behalf Of Jo Rhett
> Sent: Thursday, July 30, 2009 11:30 PM
> To: Eric Van Tol
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] Humor: Cisco announces end of BGP
> 
> AboveNet and Savvis hardly count.   AboveNet is a great carrier but
> small, and Savvis is a walking dead man hoping someone will buy him.
> Neither one has, nor will have, the budget or personnel to handle v6.
> 
> Level3 and Verizon both have v6 if you ask real nice.  As does XO and
> others.
> 
> On Jul 29, 2009, at 6:58 AM, Eric Van Tol wrote:
> > Let's see...from our "big carriers":
> >
> > AboveNet: No IPv6
> > Verizon:  No IPv6
> > Savvis:  No IPv6
> > Level3: No IPv6
> > GBLX: IPv6!
> > Verio: IPv6!
> >
> > Sure, we have some smaller providers and peers that run it, too, but
> > until the majority of our so-called "Tier 1" providers start
> > deploying it *and making it easy to request*, I stick to my guns by
> > saying that he wasn't that far off.
> >
> > -evt
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> 
> --
> Jo Rhett
> Net Consonance : consonant endings by net philanthropy, open source
> and other randomness
> 
> _______________________________________________
> cisco-nsp mailing list  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  Fri Jul 31 12:03:57 2009
From: luan at netcraftsmen.net (Luan Nguyen)
Date: Fri, 31 Jul 2009 12:03:57 -0400
Subject: [c-nsp] GRE/NAT ?
In-Reply-To: <4A73105C.3000907@cisco.com>
References: <4A73068C.3080708@pins.net> <4A730C78.6070804@utc.edu>
	<4A73105C.3000907@cisco.com>
Message-ID: <025401ca11f8$82938cf0$87baa6d0$@net>

No? 
I remember doing overlapping RFC1918 sites for GRE/IPSEC VPN.

Regards,

------------------------------------
Luan Nguyen
Chesapeake NetCraftsmen, LLC.
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 Rodney Dunn
Sent: Friday, July 31, 2009 11:40 AM
To: Jeff Kell
Cc: cisco-nsp
Subject: Re: [c-nsp] GRE/NAT ?

No.



Jeff Kell wrote:
> The GRE question reminded me of a nagging thought...
> 
> Can you NAT traffic inside GRE? 
> 
> 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/
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


From tstevens at cisco.com  Fri Jul 31 12:06:07 2009
From: tstevens at cisco.com (Tim Stevenson)
Date: Fri, 31 Jul 2009 09:06:07 -0700
Subject: [c-nsp] confreg 0x42 on a Sup32
In-Reply-To: <20090731093515.ocbrusj2m808c044@webmail.iamforeverme.com>
References: <C697AE1B.7AE6%graham@g-rock.net>
	<200907310307.n6V37bkC017097@sj-core-5.cisco.com>
	<20090731093515.ocbrusj2m808c044@webmail.iamforeverme.com>
Message-ID: <200907311606.n6VG68a7000786@sj-core-2.cisco.com>

Hi Graham,

You need to do this from *both* rommons. The 
config reg is sync'd between RP & SP when you do 
a write mem, but if you are manually changing it 
from in the rommon, then each rommon is going to have an independent value.

Break to the SP, confreg 0x2142, reset, then wait 
for the RP rommon to take control, it's after this msg:
00:00:07: %OIR-SP-6-CONSOLE: Changing console ownership to route processor

Then break to RP, confreg 0x2142, and reset, the 
box should come up w/no running config (startup will still have everything).

Make sure to restore the config-register 0x2102 
in config mode & write mem after you've changed the password.

Hope that helps,
Tim



At 06:35 AM 7/31/2009, Graham Wooden asserted:

>Thanks Tim and Jesse for the replies.
>
>Well, I only had a small window this morning to get this resolved and
>both confregs from rommon didn't seem to bypass the config like I
>wanted. Also tried just confreg with no args, and selecting it to
>ignore the config with still no affect.
>
>But as I type this, I did it from the SP rommon.  Should I have done
>the break at the RP boot instead?
>
>I will have another window this evening to get this resolved. Thanks
>for any suggestions.
>
>-graham
>
>
>Quoting Tim Stevenson <tstevens at cisco.com>:
>
> > Hi Graham -
> >
> > The same rules for confreg that apply to the other c6k sups apply here
> > as well.
> >
> > Typical/recommended for sup32 is 0x2102. To ignore config 0x2142 will
> > do it. 0x42 should work too, but for one thing, ignore break will be
> > disabled, which is not desirable (router can drop to rommon during
> > runtime due to deliberate/spurious break).
> >
> > Hope that helps,
> > Tim
> >
> >
> >
> > At 06:07 PM 7/30/2009, Graham Wooden asserted:
> >
> >> Hi there,
> >>
> >> Not much out there on this for the Sup32. 
> But since the Sup32 is a upgraded
> >> MSFC2, will the config register ?0x42? bypass the config?
> >> Someone borked up the aaa auth and I can't get into it.  Bah.
> >>
> >> Thanks,
> >>
> >> -graham
>




Tim Stevenson, tstevens at cisco.com
Routing & Switching CCIE #5561
Technical Marketing Engineer, Cisco Nexus 7000
Cisco - http://www.cisco.com
IP Phone: 408-526-6759
********************************************************
The contents of this message may be *Cisco Confidential*
and are intended for the specified recipients only.

From rodunn at cisco.com  Fri Jul 31 12:08:46 2009
From: rodunn at cisco.com (Rodney Dunn)
Date: Fri, 31 Jul 2009 12:08:46 -0400
Subject: [c-nsp] GRE/NAT ?
In-Reply-To: <025401ca11f8$82938cf0$87baa6d0$@net>
References: <4A73068C.3080708@pins.net> <4A730C78.6070804@utc.edu>
	<4A73105C.3000907@cisco.com> <025401ca11f8$82938cf0$87baa6d0$@net>
Message-ID: <4A73170E.5000604@cisco.com>

There is no code that does translation of the inner ip frame that I'm 
aware of.

Rodney



Luan Nguyen wrote:
> No? 
> I remember doing overlapping RFC1918 sites for GRE/IPSEC VPN.
> 
> Regards,
> 
> ------------------------------------
> Luan Nguyen
> Chesapeake NetCraftsmen, LLC.
> 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 Rodney Dunn
> Sent: Friday, July 31, 2009 11:40 AM
> To: Jeff Kell
> Cc: cisco-nsp
> Subject: Re: [c-nsp] GRE/NAT ?
> 
> No.
> 
> 
> 
> Jeff Kell wrote:
>> The GRE question reminded me of a nagging thought...
>>
>> Can you NAT traffic inside GRE? 
>>
>> 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/
> _______________________________________________
> cisco-nsp mailing list  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  Fri Jul 31 12:35:34 2009
From: luan at netcraftsmen.net (Luan Nguyen)
Date: Fri, 31 Jul 2009 12:35:34 -0400
Subject: [c-nsp] GRE/NAT ?
In-Reply-To: <4A73170E.5000604@cisco.com>
References: <4A73068C.3080708@pins.net> <4A730C78.6070804@utc.edu>
	<4A73105C.3000907@cisco.com> <025401ca11f8$82938cf0$87baa6d0$@net>
	<4A73170E.5000604@cisco.com>
Message-ID: <026101ca11fc$ed52ae50$c7f80af0$@net>

So you are talking about NAT after GRE?  You certainly could NAT and then
GRE-encapsulated the NATTED traffic?

Regards,

--------------------------------
Luan Nguyen
Chesapeake NetCraftsmen, LLC.
http://www.netcraftsmen.net
--------------------------------


-----Original Message-----
From: Rodney Dunn [mailto:rodunn at cisco.com] 
Sent: Friday, July 31, 2009 12:09 PM
To: Luan Nguyen
Cc: 'cisco-nsp'
Subject: Re: [c-nsp] GRE/NAT ?

There is no code that does translation of the inner ip frame that I'm 
aware of.

Rodney



Luan Nguyen wrote:
> No? 
> I remember doing overlapping RFC1918 sites for GRE/IPSEC VPN.
> 
> Regards,
> 
> ------------------------------------
> Luan Nguyen
> Chesapeake NetCraftsmen, LLC.
> 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 Rodney Dunn
> Sent: Friday, July 31, 2009 11:40 AM
> To: Jeff Kell
> Cc: cisco-nsp
> Subject: Re: [c-nsp] GRE/NAT ?
> 
> No.
> 
> 
> 
> Jeff Kell wrote:
>> The GRE question reminded me of a nagging thought...
>>
>> Can you NAT traffic inside GRE? 
>>
>> 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/
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


From rodunn at cisco.com  Fri Jul 31 12:46:53 2009
From: rodunn at cisco.com (Rodney Dunn)
Date: Fri, 31 Jul 2009 12:46:53 -0400
Subject: [c-nsp] GRE/NAT ?
In-Reply-To: <026101ca11fc$ed52ae50$c7f80af0$@net>
References: <4A73068C.3080708@pins.net> <4A730C78.6070804@utc.edu>
	<4A73105C.3000907@cisco.com> <025401ca11f8$82938cf0$87baa6d0$@net>
	<4A73170E.5000604@cisco.com> <026101ca11fc$ed52ae50$c7f80af0$@net>
Message-ID: <4A731FFD.9090608@cisco.com>

That yes. I took his question as nat'ing post encapsulated inner packets 
due to his "inside" reference:

 >>> Can you NAT traffic inside GRE?



Luan Nguyen wrote:
> So you are talking about NAT after GRE?  You certainly could NAT and then
> GRE-encapsulated the NATTED traffic?
> 
> Regards,
> 
> --------------------------------
> Luan Nguyen
> Chesapeake NetCraftsmen, LLC.
> http://www.netcraftsmen.net
> --------------------------------
> 
> 
> -----Original Message-----
> From: Rodney Dunn [mailto:rodunn at cisco.com] 
> Sent: Friday, July 31, 2009 12:09 PM
> To: Luan Nguyen
> Cc: 'cisco-nsp'
> Subject: Re: [c-nsp] GRE/NAT ?
> 
> There is no code that does translation of the inner ip frame that I'm 
> aware of.
> 
> Rodney
> 
> 
> 
> Luan Nguyen wrote:
>> No? 
>> I remember doing overlapping RFC1918 sites for GRE/IPSEC VPN.
>>
>> Regards,
>>
>> ------------------------------------
>> Luan Nguyen
>> Chesapeake NetCraftsmen, LLC.
>> 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 Rodney Dunn
>> Sent: Friday, July 31, 2009 11:40 AM
>> To: Jeff Kell
>> Cc: cisco-nsp
>> Subject: Re: [c-nsp] GRE/NAT ?
>>
>> No.
>>
>>
>>
>> Jeff Kell wrote:
>>> The GRE question reminded me of a nagging thought...
>>>
>>> Can you NAT traffic inside GRE? 
>>>
>>> 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/
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/

From daryl at introspect.net  Fri Jul 31 14:22:26 2009
From: daryl at introspect.net (Daryl G. Jurbala)
Date: Fri, 31 Jul 2009 14:22:26 -0400
Subject: [c-nsp] ISP in US
In-Reply-To: <9569de140907301542j5519a2e5j9fd32c0a8bf16ce0@mail.gmail.com>
References: <9569de140907290644j11098b10l7c9c929ce4b30bb9@mail.gmail.com>
	<A6DBBABA-A6D8-41EF-9005-40DAFCE14657@introspect.net>
	<9569de140907301542j5519a2e5j9fd32c0a8bf16ce0@mail.gmail.com>
Message-ID: <A7DB0C84-7DB8-4CCF-AF72-352888327CD2@introspect.net>


On Jul 30, 2009, at 6:42 PM, Andy William wrote:

> Thx all and i will think about Gulfstream Daryl :)
>
> but i start to think about P2P connections like AT&T IPL  
> (International Private Line) or ATM PVC between both sites , what do  
> you think ? what is the estimated cost for 2M connection ?
>

That is also a very expensive way to go (if not just as expensive),  
and a lot of it depends on where your office is in the Middle East (to  
determine which carrier you will need to pay AT&T to buy their last  
few miles of transit through).

I'm still not convinced that you need it - a 5 MB connection at each  
end with a VPN between the two and some sane QoS at each edge device  
ought to be more than enough.  I deliver thousands of simultaneous  
calls from the Middle East through 3 GB connections to 3 different  
ISPs at my colo in San Francisco.  No special agreements with anyone,  
the other sides of the calls originating from internet connections  
owned by our customers.  No real problems.

So before signing any contracts, I would simply give it a shot right  
over the Internet.  You'll likely be pleased with the results.

From gsgranados at comcast.net  Fri Jul 31 14:48:05 2009
From: gsgranados at comcast.net (Scott Granados)
Date: Fri, 31 Jul 2009 11:48:05 -0700
Subject: [c-nsp] can you port forward to a non connected subnet?
Message-ID: <007701ca120f$74a72180$0202fea9@am.thmulti.com>

Hi, I have a question RE port forwarding.

BACKGROUND

We have a pix with two interfaces.  One public interface has a static 
outside of 206.x.x.77 and we have an internal interface with an interface IP 
of 10.18.7.254.  On the inside interface we attach a core switch with lots 
of VLANs with different subnets attached and routing enabled in the switch. 
The default route on the core is set to point at 10.18.7.254 and nat is 
enabled.  One of these VLANS has a subnet of 10.18.4.128/26 which hosts some 
servers.  The servers are obviously not directly connected to the segment 
where the Pix is attached but they can route out to the Internet via the pix 
and reach 10.18.7.254 with out issue.  My question is can you map a port 
from the outside to one of the 10.18.4.128/26 servers through the core or 
does that server have to be a member of the 10.18.7.225/27 subnet where the 
pix is directly connected?  Would something like the following work?

static (inside,outside) 206.x.x.77 10.18.4.142 netmask 255.255.255.255 0 0

and the ACL
access-list acl-outside permit ip any 206.x.x.77 eq 80


If this will work, does anything special need to be configured or will this 
not work at all?  Also, if this does work is there anything particularly bad 
or bad form about this type of arrangement?  Any pointers would be 
appreciated.

Thank you
Scott


From rwest at zyedge.com  Fri Jul 31 14:53:08 2009
From: rwest at zyedge.com (Ryan West)
Date: Fri, 31 Jul 2009 14:53:08 -0400
Subject: [c-nsp] can you port forward to a non connected subnet?
In-Reply-To: <007701ca120f$74a72180$0202fea9@am.thmulti.com>
References: <007701ca120f$74a72180$0202fea9@am.thmulti.com>
Message-ID: <6E21B2BDEF6E714EA0B5BA8D5D0E14012489DA2AA2@zy-ex1.zyedge.local>

Hi,

That works fine.  You just need to enable routing to that remote subnet to the local SVI on the switch.

-ryan

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Scott Granados
Sent: Friday, July 31, 2009 2:48 PM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] can you port forward to a non connected subnet?

Hi, I have a question RE port forwarding.

BACKGROUND

We have a pix with two interfaces.  One public interface has a static 
outside of 206.x.x.77 and we have an internal interface with an interface IP 
of 10.18.7.254.  On the inside interface we attach a core switch with lots 
of VLANs with different subnets attached and routing enabled in the switch. 
The default route on the core is set to point at 10.18.7.254 and nat is 
enabled.  One of these VLANS has a subnet of 10.18.4.128/26 which hosts some 
servers.  The servers are obviously not directly connected to the segment 
where the Pix is attached but they can route out to the Internet via the pix 
and reach 10.18.7.254 with out issue.  My question is can you map a port 
from the outside to one of the 10.18.4.128/26 servers through the core or 
does that server have to be a member of the 10.18.7.225/27 subnet where the 
pix is directly connected?  Would something like the following work?

static (inside,outside) 206.x.x.77 10.18.4.142 netmask 255.255.255.255 0 0

and the ACL
access-list acl-outside permit ip any 206.x.x.77 eq 80


If this will work, does anything special need to be configured or will this 
not work at all?  Also, if this does work is there anything particularly bad 
or bad form about this type of arrangement?  Any pointers would be 
appreciated.

Thank you
Scott

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

From geoff at pendery.net  Fri Jul 31 14:57:02 2009
From: geoff at pendery.net (Geoffrey Pendery)
Date: Fri, 31 Jul 2009 13:57:02 -0500
Subject: [c-nsp] 7206 NPE-G2 - Cat 3750 sfp issue
In-Reply-To: <7.0.1.0.2.20090730185902.04b8d458@moov.mg>
References: <7.0.1.0.2.20090730185902.04b8d458@moov.mg>
Message-ID: <d6966e4b0907311157r53b74990gb21a6da4e1d4121b@mail.gmail.com>

I vaguely recalled the 7200VXR/G2's requiring the "fancy" DOM SFPs,
not the regular GLC- SFP's.
A little Googling turned up this:

http://www.cisco.com/en/US/prod/collateral/routers/ps341/prod_qas0900aecd80471791.html

"Q. Which SFP modules are supported on the Cisco NPE-G2?
A. The following SFP modules are supported: SFP-GE-S, SFP-GE-L, and SFP-GE-Z"

Could be that your GLC-LH-SM isn't supported, and you need to buy the
SFP-GE-L instead...

http://www.cisco.com/en/US/docs/routers/7200/install_and_upgrade/gbic_sfp_modules_install/5067g.html#wp90313


-Geoff


On Thu, Jul 30, 2009 at 11:06 AM, RAZAFINDRATSIFA Rivo
Tahina<r.tahina at moov.mg> wrote:
> Hi all,
>
> I use
> 1000BASE-LX/LH (GLC-LH-SM), on both Catalyst and 7206 NPE-G2, interface and
> protocol are up but I cannot do anything, what am I missing?
>
> 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 eninja at gmail.com  Fri Jul 31 15:17:54 2009
From: eninja at gmail.com (e ninja)
Date: Fri, 31 Jul 2009 12:17:54 -0700
Subject: [c-nsp] SFC DOWN
In-Reply-To: <8bb137f40907302123w522dc0d7s3af539e0c38579b4@mail.gmail.com>
References: <8bb137f40907302114n72fafa06ldc4ef0505774454c@mail.gmail.com>
	<8bb137f40907302123w522dc0d7s3af539e0c38579b4@mail.gmail.com>
Message-ID: <e8590f60907311217j23e5c01dnf947ea612dd8943c@mail.gmail.com>

Jack,

http://howtos.mysolvr.com/How_to_Power_Off_and_On_a_Cisco_GSR_12000_Linecard

Eninja


On Thu, Jul 30, 2009 at 9:23 PM, jack daniels <jckdaniels12 at gmail.com>wrote:

> > Hi All,
> >
> > I'm facing a issue  in Cisco 12416  request your help -
> >
> >  show GSR -
> >  "Slot 19 type = Switch Fabric Card 16XOC192
> > state = Administratively Down, Powered" <<<<<<<<<<<<<<<<<<<<<<
> >
> > how to take it out of this Administratively down state to powered state.
> >
> > My IOS version is 12.0(32)SY6
> >
> >
> > Regards
> > Jack
> >
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

From zeusdadog at gmail.com  Fri Jul 31 16:12:10 2009
From: zeusdadog at gmail.com (Jay Nakamura)
Date: Fri, 31 Jul 2009 16:12:10 -0400
Subject: [c-nsp] Recommended IOS for 7500
Message-ID: <9418aca70907311312u5beb5e8ao7b29f6b7b96882b@mail.gmail.com>

Not sure many people are still using 7500 but was wondering what IOS
people are using that's stable these days.  I googled the archive but
couldn't find anything past 2005.

RSP4/VIP2-50/ 1~2 MC-DS3 PA and 2 FE ports

Not much fancy feature needed.  Rate limiting and some class based QoS
capability.

Thanks,

-Jay

From gsgranados at comcast.net  Fri Jul 31 16:19:52 2009
From: gsgranados at comcast.net (Scott Granados)
Date: Fri, 31 Jul 2009 13:19:52 -0700
Subject: [c-nsp] Recommended IOS for 7500
References: <9418aca70907311312u5beb5e8ao7b29f6b7b96882b@mail.gmail.com>
Message-ID: <00e001ca121c$47ded2d0$0202fea9@am.thmulti.com>

I can't speak to the IOS but they do make good end tables.

:)

----- Original Message ----- 
From: "Jay Nakamura" <zeusdadog at gmail.com>
To: <cisco-nsp at puck.nether.net>
Sent: Friday, July 31, 2009 1:12 PM
Subject: [c-nsp] Recommended IOS for 7500


> Not sure many people are still using 7500 but was wondering what IOS
> people are using that's stable these days.  I googled the archive but
> couldn't find anything past 2005.
> 
> RSP4/VIP2-50/ 1~2 MC-DS3 PA and 2 FE ports
> 
> Not much fancy feature needed.  Rate limiting and some class based QoS
> capability.
> 
> Thanks,
> 
> -Jay
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

From rodunn at cisco.com  Fri Jul 31 16:24:12 2009
From: rodunn at cisco.com (Rodney Dunn)
Date: Fri, 31 Jul 2009 16:24:12 -0400
Subject: [c-nsp] Recommended IOS for 7500
In-Reply-To: <9418aca70907311312u5beb5e8ao7b29f6b7b96882b@mail.gmail.com>
References: <9418aca70907311312u5beb5e8ao7b29f6b7b96882b@mail.gmail.com>
Message-ID: <4A7352EC.7090909@cisco.com>

Latest 12.0(32)S rebuild that is on Cisco.com
or either 12.4(25).

Rodney



Jay Nakamura wrote:
> Not sure many people are still using 7500 but was wondering what IOS
> people are using that's stable these days.  I googled the archive but
> couldn't find anything past 2005.
> 
> RSP4/VIP2-50/ 1~2 MC-DS3 PA and 2 FE ports
> 
> Not much fancy feature needed.  Rate limiting and some class based QoS
> capability.
> 
> Thanks,
> 
> -Jay
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

From ras at e-gerbil.net  Fri Jul 31 16:39:53 2009
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Fri, 31 Jul 2009 15:39:53 -0500
Subject: [c-nsp] Recommended IOS for 7500
In-Reply-To: <9418aca70907311312u5beb5e8ao7b29f6b7b96882b@mail.gmail.com>
References: <9418aca70907311312u5beb5e8ao7b29f6b7b96882b@mail.gmail.com>
Message-ID: <20090731203953.GH51443@gerbil.cluepon.net>

On Fri, Jul 31, 2009 at 04:12:10PM -0400, Jay Nakamura wrote:
> Not sure many people are still using 7500 but was wondering what IOS
> people are using that's stable these days.  I googled the archive but
> couldn't find anything past 2005.
> 
> RSP4/VIP2-50/ 1~2 MC-DS3 PA and 2 FE ports
> 
> Not much fancy feature needed.  Rate limiting and some class based QoS
> capability.

I recommend you find a good scrap metal dealer, the price of copper is 
going back up. :)

-- 
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 zeusdadog at gmail.com  Fri Jul 31 16:50:05 2009
From: zeusdadog at gmail.com (Jay Nakamura)
Date: Fri, 31 Jul 2009 16:50:05 -0400
Subject: [c-nsp] Recommended IOS for 7500
In-Reply-To: <20090731203953.GH51443@gerbil.cluepon.net>
References: <9418aca70907311312u5beb5e8ao7b29f6b7b96882b@mail.gmail.com>
	<20090731203953.GH51443@gerbil.cluepon.net>
Message-ID: <9418aca70907311350t4c348ec9pc6adb866c2d713d6@mail.gmail.com>

Speaking of scrapping it, what router or L3 switch would you recommend to

- Connect legacy T1 users (1 or 2 DS3s)
- Connect direct Ethernet users (Colo or Eth WAN 40~50mbps aggragate)

that's cheap and reliable, new or used?  Again, QoS and rate limiting
is most we would use over simple L3 forwarding.  Doesn't have to carry
full BGP routes.  The two function can be on separate devices.


On Fri, Jul 31, 2009 at 4:39 PM, Richard A Steenbergen<ras at e-gerbil.net> wrote:
> On Fri, Jul 31, 2009 at 04:12:10PM -0400, Jay Nakamura wrote:
>> Not sure many people are still using 7500 but was wondering what IOS
>> people are using that's stable these days. ?I googled the archive but
>> couldn't find anything past 2005.
>>
>> RSP4/VIP2-50/ 1~2 MC-DS3 PA and 2 FE ports
>>
>> Not much fancy feature needed. ?Rate limiting and some class based QoS
>> capability.
>
> I recommend you find a good scrap metal dealer, the price of copper is
> going back up. :)
>
> --
> 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 ras at e-gerbil.net  Fri Jul 31 16:59:05 2009
From: ras at e-gerbil.net (Richard A Steenbergen)
Date: Fri, 31 Jul 2009 15:59:05 -0500
Subject: [c-nsp] Recommended IOS for 7500
In-Reply-To: <9418aca70907311350t4c348ec9pc6adb866c2d713d6@mail.gmail.com>
References: <9418aca70907311312u5beb5e8ao7b29f6b7b96882b@mail.gmail.com>
	<20090731203953.GH51443@gerbil.cluepon.net>
	<9418aca70907311350t4c348ec9pc6adb866c2d713d6@mail.gmail.com>
Message-ID: <20090731205905.GI51443@gerbil.cluepon.net>

On Fri, Jul 31, 2009 at 04:50:05PM -0400, Jay Nakamura wrote:
> Speaking of scrapping it, what router or L3 switch would you recommend to
> 
> - Connect legacy T1 users (1 or 2 DS3s)
> - Connect direct Ethernet users (Colo or Eth WAN 40~50mbps aggragate)
> 
> that's cheap and reliable, new or used?  Again, QoS and rate limiting
> is most we would use over simple L3 forwarding.  Doesn't have to carry
> full BGP routes.  The two function can be on separate devices.

Last time I looked at something like that (many many many years ago, but 
I doubt that much has changed), a Juniper M5/M10 with a chds3 pic was 
going to be much cheaper on the used market (and better performing) than 
any comperable Cisco solution like a 7206vxr. You should be able to 
clear that entire package in under $5k (maybe well under, depends) with 
15 mins judiciously spent on ebay.com. :)

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

From gert at greenie.muc.de  Fri Jul 31 17:02:33 2009
From: gert at greenie.muc.de (Gert Doering)
Date: Fri, 31 Jul 2009 23:02:33 +0200
Subject: [c-nsp] Recommended IOS for 7500
In-Reply-To: <9418aca70907311350t4c348ec9pc6adb866c2d713d6@mail.gmail.com>
References: <9418aca70907311312u5beb5e8ao7b29f6b7b96882b@mail.gmail.com>
	<20090731203953.GH51443@gerbil.cluepon.net>
	<9418aca70907311350t4c348ec9pc6adb866c2d713d6@mail.gmail.com>
Message-ID: <20090731210233.GI290@greenie.muc.de>

Hi,

On Fri, Jul 31, 2009 at 04:50:05PM -0400, Jay Nakamura wrote:
> Speaking of scrapping it, what router or L3 switch would you recommend to
> 
> - Connect legacy T1 users (1 or 2 DS3s)

7200VXR, NPE225 or NPE400 (NPEs below 225 won't work, 300 is unsupported).

> - Connect direct Ethernet users (Colo or Eth WAN 40~50mbps aggragate)

7200VXR, NPE400 or NPE-G1.  G1 is a bit overkill for 40-50 mbit/s, but
it gives you quite some room to grow.

We really like the 7200s.  Solid work horses...

Cisco-XX uptime is 8 years, 12 weeks, 5 days, 1 hour, 36 minutes
System image file is "slot0:c7200-k3p-mz.120-16.S1.bin"

(Yes, I know.  Security holes and other bugs lurking.  We know where the
problems are and have ACLs in place.  New IOS has been put into flash 
about 10 times since then, but why bother rebooting if the box happily
chugs along?  *If* it crashes, it will get fixed IOS)

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/20090731/a93f8050/attachment.bin>

From petelists at templin.org  Fri Jul 31 16:29:36 2009
From: petelists at templin.org (Pete Templin)
Date: Fri, 31 Jul 2009 15:29:36 -0500
Subject: [c-nsp] Recommended IOS for 7500
In-Reply-To: <9418aca70907311312u5beb5e8ao7b29f6b7b96882b@mail.gmail.com>
References: <9418aca70907311312u5beb5e8ao7b29f6b7b96882b@mail.gmail.com>
Message-ID: <4A735430.9070907@templin.org>

Jay Nakamura wrote:
> Not sure many people are still using 7500 but was wondering what IOS
> people are using that's stable these days.  I googled the archive but
> couldn't find anything past 2005.
> 
> RSP4/VIP2-50/ 1~2 MC-DS3 PA and 2 FE ports
> 
> Not much fancy feature needed.  Rate limiting and some class based QoS
> capability.

12.0(27)S5 has been absolutely bulletproof for us with exactly that port 
configuration.  We got the hint that we should be heading towards 
12.0(32), so we went to 32S10 on some "core" nodes (FE, DS3), but don't 
see any particular improvements there.  VIP4-50s would help you 
tremendously, but I know what it's like to have to use what you have.

pt

From graham at g-rock.net  Fri Jul 31 21:40:44 2009
From: graham at g-rock.net (Graham Wooden)
Date: Fri, 31 Jul 2009 20:40:44 -0500
Subject: [c-nsp] confreg 0x42 on a Sup32
In-Reply-To: <200907311606.n6VG68a7000786@sj-core-2.cisco.com>
Message-ID: <C699074C.7BCB%graham@g-rock.net>

Yup, that was the ticket. Thanks Tim!

-graham


On 7/31/09 11:06 AM, "Tim Stevenson" <tstevens at cisco.com> wrote:

> Hi Graham,
> 
> You need to do this from *both* rommons. The config reg is sync'd between RP &
> SP when you do a write mem, but if you are manually changing it from in the
> rommon, then each rommon is going to have an independent value.
> 
> Break to the SP, confreg 0x2142, reset, then wait for the RP rommon to take
> control, it's after this msg:
> 00:00:07: %OIR-SP-6-CONSOLE: Changing console ownership to route processor
> 
> Then break to RP, confreg 0x2142, and reset, the box should come up w/no
> running config (startup will still have everything).
> 
> Make sure to restore the config-register 0x2102 in config mode & write mem
> after you've changed the password.
> 
> Hope that helps,
> Tim
> 
> 
> 
> At 06:35 AM 7/31/2009, Graham Wooden asserted:
> 
>> Thanks Tim and Jesse for the replies.
>> 
>> Well, I only had a small window this morning to get this resolved and
>> both confregs from rommon didn't seem to bypass the config like I
>> wanted. Also tried just confreg with no args, and selecting it to
>> ignore the config with still no affect.
>> 
>> But as I type this, I did it from the SP rommon.  Should I have done
>> the break at the RP boot instead?
>> 
>> I will have another window this evening to get this resolved. Thanks
>> for any suggestions.
>> 
>> -graham
>> 
>> 
>> Quoting Tim Stevenson <tstevens at cisco.com>:
>> 
>>> > Hi Graham -
>>> >
>>> > The same rules for confreg that apply to the other c6k sups apply here
>>> > as well.
>>> >
>>> > Typical/recommended for sup32 is 0x2102. To ignore config 0x2142 will
>>> > do it. 0x42 should work too, but for one thing, ignore break will be
>>> > disabled, which is not desirable (router can drop to rommon during
>>> > runtime due to deliberate/spurious break).
>>> >
>>> > Hope that helps,
>>> > Tim
>>> >
>>> >
>>> >
>>> > At 06:07 PM 7/30/2009, Graham Wooden asserted:
>>> >
>>>> >> Hi there,
>>>> >>
>>>> >> Not much out there on this for the Sup32. But since the Sup32 is a
>>>> upgraded
>>>> >> MSFC2, will the config register ?0x42? bypass the config?
>>>> >> Someone borked up the aaa auth and I can't get into it. Bah.
>>>> >>
>>>> >> Thanks,
>>>> >>
>>>> >> -graham
>> 
> 
> 
> 
> 
> Tim Stevenson, tstevens at cisco.com
> Routing & Switching CCIE #5561
> Technical Marketing Engineer, Cisco Nexus 7000
> Cisco - http://www.cisco.com
>  <http://www.cisco.com/> IP Phone: 408-526-6759
> ********************************************************
> The contents of this message may be *Cisco Confidential*
> and are intended for the specified recipients only.
>