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: Th