Re: [c-nsp] ouch 7204vxr reloaded

[Mike]

Antonio Querubin wrote:


  So my inexperienced glancing would say it was something to do with 
OSPF.


How do you know you don't have some RAM going BAD?



I don't, and thats the point of my message - to get on the track to know 
and further to get enabled to resolve the problem, whatever it may wind 
up being.


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

Re: [c-nsp] ouch 7204vxr reloaded

[Ryan West]

Mike,

> -Original Message-
> Sent: Tuesday, April 27, 2010 6:40 PM
> To: Mike
> Cc: 'Cisco-nsp'
> Subject: Re: [c-nsp] ouch 7204vxr reloaded
> 
> On Tue, 27 Apr 2010, Mike wrote:
> 
> > unexpectedly and I find myself without a good explanation. Show version
> gives
> > me 'processor memory pairity error':
> >
> > System returned to ROM by processor memory parity error at PC 0x60640F70,
> 
> >   So my inexperienced glancing would say it was something to do with OSPF.
> 
> How do you know you don't have some RAM going BAD?
> 

Might want to have a look here at hard parity errors:

http://www.ciscotaccc.com/kaidara-advisor/core/showcase?case=K20414285

-ryan

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

Re: [c-nsp] ouch 7204vxr reloaded

[Antonio Querubin]

On Tue, 27 Apr 2010, Mike wrote:

unexpectedly and I find myself without a good explanation. Show version gives 
me 'processor memory pairity error':


System returned to ROM by processor memory parity error at PC 0x60640F70,



  So my inexperienced glancing would say it was something to do with OSPF.


How do you know you don't have some RAM going BAD?

Antonio Querubin
808-545-5282 x3003
e-mail/xmpp:  t...@lava.net
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] ouch 7204vxr reloaded

[Mike]

Howdy,

   Well that was fun, I discovered that my trusty 7204vxr reloaded 
unexpectedly and I find myself without a good explanation. Show version 
gives me 'processor memory pairity error':


System returned to ROM by processor memory parity error at PC 
0x60640F70, address 0x0 at 03:09:00 PST Tue Apr 27 2010

System restarted at 04:10:28 PDT Tue Apr 27 2010
System image file is "disk0:c7200-is-mz.123-26.bin"

   and digging thru the 'show tech' gave me:

Pid 3: Process "OSPF Hello" stack 0x63D733F0 savedsp 0x63D75660
Flags: analyze on_old_queue
Status 0x Orig_ra   0x Routine0x Signal 0
Caller_pc  0x60CDAE84 Callee_pc 0x60806190 Dbg_events 0x State  1
Totmalloc  548640 Totfree   441612 Totgetbuf  15876  
Totretbuf  0  Edisms0x60CD71A4 Eparm 0x64A91E7C
Elapsed0xC6E634   Ncalls0xE09B9AA  Ngiveups 0x491E   
Priority_q 3  Ticks_5s  2  Cpu_5sec   81   Cpu_1min 40
Cpu_5min   8  Stacksize 0x2328 Lowstack 0x2328   
Ttyptr 0x63D55FA8 Mem_holding 0x0Thrash_count 0

Wakeup_reasons  0x0FFF  Default_wakeup_reasons 0x0FFF
Direct_wakeup_major 0x  Direct_wakeup_minor 0x


   So my inexperienced glancing would say it was something to do with 
OSPF. My question tho is, #1, how do I really debug a problem like this, 
and #2, what would the minimum cisco contract be required to make sure I 
have access to the cco/bug advisor and possibly updated IOS for this 
device? Its been a tank with absolutely zero issues in this enviorment 
for more than a year, but this event underscores the fact that we have 
no real support route and probabbly should get on some program even for 
our little operation.



Thanks.

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

Re: [c-nsp] VPN over Comcast

[Christopher J. Wargaski]

Hello Michael--

   No laughs here. When a customer of mine lost its 100 foot tower that was
at the core of its wireless network (as in it fell down), they had to
scramble to bring up remote buildings on their network. We dropped Comcast
Business cable lines and ASA-5505s at each location that was affected and
did not have a backup path. The only problem that we had with Comcast was
them installing the correct service and provisioning static IP addresses.

   Once the network was in place and a new, taller and better tower was
erected, the VPN network was kept as a backup for the primary wireless
network.

   Once or twice in a six month period a VPN tunnel dropped and did not
revive itself. A reboot of the remote ASA resolved the issue and no reboot
of the cable modem was required. We weren't able to determine if there were
power hiccups or Comcast network issues. That behavior occurred so
infrequently that we thought nothing of it.

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

Re: [c-nsp] VPN over Comcast

[Ge Moua]

we are extending l2 pseudowire over ipsec tunnels through comcast 
business class internet and this seems to work mostly stable for us; I'm 
not sure if the sla for residential cable would incur more outage or 
not; albeit we are in the minneapolis mkt and not chicago.


--
Regards,
Ge Moua
Network Design Engineer

University of Minnesota | OIT - NTS


On 4/27/10 12:42 PM, Michael Malitsky wrote:

I will probably be laughed at, but I'll ask just in case.

We are having particularly bad luck trying to run VPN tunnels over
Comcast cable in the Chicago area.  The symptoms are basically complete
loss of connectivity (lasting minutes to sometimes hours), or sometimes
flapping for a period of time.  More often than not, a reboot of the
cable modem is required.  The most interesting ones involve the
following: a PIX or ASA configured as an EZvpn client, connecting to a
3000 concentrator, authentication over RADIUS.  When I go to look at the
RADIUS logs, I see connections from the same box with small intervals.
Timeout is 8 hours, so theoretically I should see 3 connections in a
24-hr period.  In some cases, I see dozens, in the most egregious cases,
thousands over a 24-hour period.  I am taking that as an indicator of a
really unstable Comcast circuit.  We have not had this problem with any
other ISP, anywhere in the country.
I am pretty much down to telling customers to find another provider...

Any thoughts or ideas on the matter will be appreciated.

PS.  To be fair (?) to Comcast, this is not a ubiquitous problem.  It
affects about 25% of the installations I get to see.

Sincerely,
Michael Malitsky



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

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

Re: [c-nsp] 6500/Sup720 and SVI xconnect?

[Asbjorn Hojmark - Lists]

On Tue, 27 Apr 2010 19:19:11 +0200, you wrote:

> I did actually mean xconnect configuration on a SVI. :-)

A 7600 chassis and ES+ cards will do that today.
It's probably less expensive than the SIP solution.
Plus, SR is IMO better software than SX. YMMV.

-A

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

Re: [c-nsp] IP route analysis solution

[Rutis, Cameron]

About a year ago we demoed netbrain for that sort of thing
http://www.netbraintech.com/


-Original Message-
From: cisco-nsp-boun...@puck.nether.net 
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Ibrahim Abo Zaid
Sent: Monday, April 26, 2010 12:47 PM
To: cisco_nsp
Subject: [c-nsp] IP route analysis solution

Hi all

i'm looking for IP route analysis solution that can discover and draw a
topology for the network and helps in planning process by simulating any
modifications

i did some googling and find 2 solutions in this area , Packet Design Route
Explorer and HP RAMS

do u have other ideas ? what are you impressions about these tools if you
tried any ?


thanks
--Ibrahim
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

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

Re: [c-nsp] 6500 latency

[David Prall]

Jeff,
This is an old document. But it gives the numbers.

http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod_white_
paper0900aecd800c9589.pdf

David

--
http://dcp.dcptech.com


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Jeff Bacon
> Sent: Tuesday, April 27, 2010 8:56 AM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] 6500 latency
> 
> OK, I know that a 6500 is not a super low latency box. I've seen around
> 17usec, card to card to another switch CFC mode, but due to time
> constraints have done little formal analysis.
> 
> 
> I'm guessing its better in DFC mode, and on 6700 cards, and if your
> traffic is local to a card or to a fabric port such that it doesn't
> have to traverse the fabric.
> 
> I'm also guessing that sup32s and anything on classic bus (including
> the two interfaces on the sup720) aren't super-high latency either.
> 
> Has anyone done any work on what the overall parameters are on a 6500's
> switching latency? Or got a pliable cisco rep who can get me to someone
> who can unlock those documents?
> 
> Clearly Cisco has, to the extent that a cisco exec told me yesterday
> that they see no role for the 6500 in low-latency financial market apps
> except in edge cases where NAT is needed and even then I should
> consider an ASR (of course they need to sell more nexii I imagine - but
> what, am I made of money???). Strangely, though, I find them highly
> reticent to share anything about the actual facts of the matter. Maybe
> they're annoyed that I buy mostly refurb gear. :)
> 
> (Then again, I tend to find that most micro-level-latency talk to be
> half marketing fluff and mantra, and/or an excuse to spend a ton more
> money on product X.)
> 
> It's a shame that most exchanges force me to NAT to talk to them unless
> I want to do Really Stupid Things with my network, or talk ARIN out of
> a /22. Which is why I have 6500s everywhere (and sometimes wonder about
> the wisdom thereof, given the costs).
> 
> OK, I admit I am ranting.
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

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

[c-nsp] VPN over Comcast

[Michael Malitsky]

I will probably be laughed at, but I'll ask just in case.

We are having particularly bad luck trying to run VPN tunnels over
Comcast cable in the Chicago area.  The symptoms are basically complete
loss of connectivity (lasting minutes to sometimes hours), or sometimes
flapping for a period of time.  More often than not, a reboot of the
cable modem is required.  The most interesting ones involve the
following: a PIX or ASA configured as an EZvpn client, connecting to a
3000 concentrator, authentication over RADIUS.  When I go to look at the
RADIUS logs, I see connections from the same box with small intervals.
Timeout is 8 hours, so theoretically I should see 3 connections in a
24-hr period.  In some cases, I see dozens, in the most egregious cases,
thousands over a 24-hour period.  I am taking that as an indicator of a
really unstable Comcast circuit.  We have not had this problem with any
other ISP, anywhere in the country.
I am pretty much down to telling customers to find another provider...  

Any thoughts or ideas on the matter will be appreciated.

PS.  To be fair (?) to Comcast, this is not a ubiquitous problem.  It
affects about 25% of the installations I get to see.

Sincerely,
Michael Malitsky



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

Re: [c-nsp] Using EoMPLS where you'd normally use a VLAN

[Arie Vayner (avayner)]

Yes, SIPs would allow you to do this.
Arie

-Original Message-
From: Jason Lixfeld [mailto:ja...@lixfeld.ca] 
Sent: Tuesday, April 27, 2010 19:58
To: Arie Vayner (avayner)
Cc: 
Subject: Re: [c-nsp] Using EoMPLS where you'd normally use a VLAN

What about a 6500+Sup720+SIP?

On 2010-04-27, at 2:00 AM, "Arie Vayner (avayner)" 
wrote:

> Jason,
> 
> You can do this with some of the devices. For example 7600 with ES+
(or
> ES20/SIP) modules can terminate a pseudowire (either point to point or
> VPLS...) on a SVI and also have layer 3 configuration on it. The same
> applies to ASR9000...
> 
> This can be used for many interesting solutions such as HSRP across an
> MPLS domain, Layer 3 services for a VPLS domain etc.
> 
> The extra hardware is required as this requires extra processing...
> 
> Arie
> 
> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net
> [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Jason Lixfeld
> Sent: Tuesday, April 27, 2010 01:50
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] Using EoMPLS where you'd normally use a VLAN
> 
> I'm wondering if I can use EoMPLS in a situation where I'd normally
use
> a VLAN.
> 
> For example, in a VLAN centric network, I'd have a node connected to
an
> access port on switch 1.  Switch 1 would be connected directly to
switch
> 2 over an appropriately configured 802.1q trunk port or access port.
> I'd assign an IP to an SVI on switch 2 and as long as the SVI had the
> same VLAN identifier as the access port on switch 1, I could pass
> traffic between the SVI on switch 2 and the node connected to the
access
> port on switch 1.
> 
> Is there an equivalent to this in EoMPLS land where I could do the
same
> thing using two devices that were both acting as P+PE devices?  I know
> that normally you can't assign an IP address on an interface that is
> also configured with an xconnect, but I'm wondering if there's a
feature
> out there somewhere that could make this sort of thing possible.
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

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

Re: [c-nsp] 6500/Sup720 and SVI xconnect?

[Peter Rathlev]

On Tue, 2010-04-27 at 18:31 +0200, Asbjorn Hojmark - Lists wrote:
> On Tue, 27 Apr 2010 10:58:27 +0200, you wrote:
> > > Also, on a 7600 (SR software), you can run Mux UNI (a trunk with
> > > VLANs and sub-interfaces on the same interface), even on LAN
> > > cards. I don't remember off the top of my head if that's supported
> > > on the 6500.
> >
> > It is, but won't help. You still can't put the xconnect configuration 
> > on the SVI.
> 
> The way I understood the question, that was not needed.

I did actually mean xconnect configuration on a SVI. :-)

We use MUX UNI with success on 6500/Sup720/SXI in several places. Where
we need to also have L3 functionality in the same VLAN we currently use
port mode EoMPLS and a cable looping between this and a switchport trunk
on the same box. This gives us the "poor mans" combination of EoMPLS and
L3 support on the same box.

It only works point-to-point though, so each PoP has two boxes, each
having a connection to one other PoP. The drawbacks to this are several:

 * It only supports a simple ring topology

 * There's no (easy) way to have the L2 domain (STP) know anything
   about the underlying actual topology, which means it's a pain to
   control. (TE on the EoMPLS LSP could solve this I guess, just
   haven't had the time to test and deploy it.) 

 * It costs two extra physical interfaces, apart from the regular
   core facing ones. Of course the LAN card interfaces are cheap
   compared to ES+/SIP-600.

We have some "system architects" that think the best way to design
systems is with some reliance on L2 connection even with the data
centres several hundred KMs apart. :-|

We're currently looking at what it would to take (i.e. how much it would
cost) to make this a more clean solution.

-- 
Peter


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

Re: [c-nsp] 6500 latency

[Mack McBride]

The lowest conceivable latency for a 1500 byte packet on 1GE is 12usec in a 
store and forward mode.
This does not include inter-frame gap or other overhead (ie. Switching).
This is simple physics.  You need to go to 10GE for really lowering latency.

LR Mack McBride
Network Architect
Viawest, Inc.

-Original Message-
From: cisco-nsp-boun...@puck.nether.net 
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Jeff Bacon
Sent: Tuesday, April 27, 2010 6:56 AM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] 6500 latency

OK, I know that a 6500 is not a super low latency box. I've seen around 17usec, 
card to card to another switch CFC mode, but due to time constraints have done 
little formal analysis. 


I'm guessing its better in DFC mode, and on 6700 cards, and if your traffic is 
local to a card or to a fabric port such that it doesn't have to traverse the 
fabric. 

I'm also guessing that sup32s and anything on classic bus (including the two 
interfaces on the sup720) aren't super-high latency either. 

Has anyone done any work on what the overall parameters are on a 6500's 
switching latency? Or got a pliable cisco rep who can get me to someone who can 
unlock those documents? 

Clearly Cisco has, to the extent that a cisco exec told me yesterday that they 
see no role for the 6500 in low-latency financial market apps except in edge 
cases where NAT is needed and even then I should consider an ASR (of course 
they need to sell more nexii I imagine - but what, am I made of money???). 
Strangely, though, I find them highly reticent to share anything about the 
actual facts of the matter. Maybe they're annoyed that I buy mostly refurb 
gear. :) 

(Then again, I tend to find that most micro-level-latency talk to be half 
marketing fluff and mantra, and/or an excuse to spend a ton more money on 
product X.)

It's a shame that most exchanges force me to NAT to talk to them unless I want 
to do Really Stupid Things with my network, or talk ARIN out of a /22. Which is 
why I have 6500s everywhere (and sometimes wonder about the wisdom thereof, 
given the costs).

OK, I admit I am ranting.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

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

Re: [c-nsp] Using EoMPLS where you'd normally use a VLAN

[Jason Lixfeld]

What about a 6500+Sup720+SIP?

On 2010-04-27, at 2:00 AM, "Arie Vayner (avayner)"  wrote:

> Jason,
> 
> You can do this with some of the devices. For example 7600 with ES+ (or
> ES20/SIP) modules can terminate a pseudowire (either point to point or
> VPLS...) on a SVI and also have layer 3 configuration on it. The same
> applies to ASR9000...
> 
> This can be used for many interesting solutions such as HSRP across an
> MPLS domain, Layer 3 services for a VPLS domain etc.
> 
> The extra hardware is required as this requires extra processing...
> 
> Arie
> 
> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net
> [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Jason Lixfeld
> Sent: Tuesday, April 27, 2010 01:50
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] Using EoMPLS where you'd normally use a VLAN
> 
> I'm wondering if I can use EoMPLS in a situation where I'd normally use
> a VLAN.
> 
> For example, in a VLAN centric network, I'd have a node connected to an
> access port on switch 1.  Switch 1 would be connected directly to switch
> 2 over an appropriately configured 802.1q trunk port or access port.
> I'd assign an IP to an SVI on switch 2 and as long as the SVI had the
> same VLAN identifier as the access port on switch 1, I could pass
> traffic between the SVI on switch 2 and the node connected to the access
> port on switch 1.
> 
> Is there an equivalent to this in EoMPLS land where I could do the same
> thing using two devices that were both acting as P+PE devices?  I know
> that normally you can't assign an IP address on an interface that is
> also configured with an xconnect, but I'm wondering if there's a feature
> out there somewhere that could make this sort of thing possible.
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 6500/Sup720 and SVI xconnect?

[Asbjorn Hojmark - Lists]

On Tue, 27 Apr 2010 10:58:27 +0200, you wrote:

>> Also, on a 7600 (SR software), you can run Mux UNI (a trunk with VLANs
>> and sub-interfaces on the same interface), even on LAN cards. I don't
>> remember off the top of my head if that's supported on the 6500.

> It is, but won't help. You still can't put the xconnect configuration 
> on the SVI.

The way I understood the question, that was not needed.

-A

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

Re: [c-nsp] Buffer capacity on access layer catalysts...

[Stephen Cobb]

I'd LOVE to see this documented in one place, as well.

I did find this on the 2950's: "8 MB memory architecture shared by all
ports"
http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps628/product_data_sheet09186a00801cfb64.html

Nothing elsewhere...

-- 
Stephen F. Cobb • Senior Sales Engineer
CCNA/CCDA/DCNID/ATSP
Telecoast Communications, LLC • Santa Barbara, CA
o 877.677.1182 x272 • c 760.807.0570 • f 805.618.1610
aim/yahoo telecoaststephen

On Tue, Apr 27, 2010 at 8:35 AM, Jeff Kell  wrote:

> Does anyone have a pointer to buffer specifications for the access layer
> Catalyst models (2950/2960/3550/3560)?
>
> Interested in per-port buffer specs (if applicable) or shared buffer
> sizes by model.
>
> The word "buffer" interestingly enough does not appear anywhere in the
> 2960 data sheets :-)
>
> I've heard discussions (and seen evidence) of some pretty shallow
> buffering abilities on some of these switches but never seen any
> concrete values.
>
> Jeff
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] traffic shape on 87x/88x/18xx SVI interfaces

[Arie Vayner (avayner)]

This kind of interfaces (FastEthernet) are actually Layer 2 switch ports
like you would usually find on LAN switches. Shaping on SVI interfaces
is usually not supported on this kind of platforms (Layer 2 switches),
so this is consistent.

You can still use shaping on "real" interfaces on the 800/1800/2800/3800
routers.

Arie

-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Shimol Shah
(shimshah)
Sent: Tuesday, April 27, 2010 18:28
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] traffic shape on 87x/88x/18xx SVI interfaces

Take a look at:


Switch Virtual Interface for Cisco Integrated Services Routers
==

http://www.cisco.com/en/US/prod/collateral/routers/ps5853/prod_white_pap
er0900aecd8064c9f4.html

Shimol


On 4/27/10 11:19 AM, Chris Flav wrote:
>
>
>> Hi,
>>
>> it's not working, have to use traffic policing instead of traffic
>> shaping on SVI. No way around that.
>
> How incredibly lame.  Hardware limitation?
>
> C.
>
>
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

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

[c-nsp] Buffer capacity on access layer catalysts...

[Jeff Kell]

Does anyone have a pointer to buffer specifications for the access layer
Catalyst models (2950/2960/3550/3560)?

Interested in per-port buffer specs (if applicable) or shared buffer
sizes by model.

The word "buffer" interestingly enough does not appear anywhere in the
2960 data sheets :-)

I've heard discussions (and seen evidence) of some pretty shallow
buffering abilities on some of these switches but never seen any
concrete values.

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

Re: [c-nsp] traffic shape on 87x/88x/18xx SVI interfaces

[Shimol Shah]

Take a look at:


Switch Virtual Interface for Cisco Integrated Services Routers
==

http://www.cisco.com/en/US/prod/collateral/routers/ps5853/prod_white_paper0900aecd8064c9f4.html

Shimol


On 4/27/10 11:19 AM, Chris Flav wrote:




Hi,

it's not working, have to use traffic policing instead of traffic
shaping on SVI. No way around that.


How incredibly lame.  Hardware limitation?

C.


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

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

Re: [c-nsp] traffic shape on 87x/88x/18xx SVI interfaces

[Chris Flav]

>Hi,
>
>it's not working, have to use traffic policing instead of traffic
>shaping on SVI. No way around that.

How incredibly lame.  Hardware limitation?

C.


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

Re: [c-nsp] traffic shape on 87x/88x/18xx SVI interfaces

[Jan Gregor]

Hi,

it's not working, have to use traffic policing instead of traffic
shaping on SVI. No way around that.

Best regards,

Jan

On 04/27/2010 04:06 PM, Chris Flav wrote:
> 
> Hello,
> 
> We are trying to do a simple "traffic-shape rate" command on a variety of 
> router platforms (871,881,1811) and have determined that the traffic-shape 
> does not actually take effect unless "no ip route-cache cef" is applied to 
> the Fe4 interface (or Fe0 or Fe1 on the 1811).  Traffic shape commands 
> applied to the Fe4 interface however work properly, and on the 1811 Fe0 and 
> Fe1 interfaces behave correctly.
> 
> Is there any other way to have shaping applied on VLANs configured on the SVI 
> interfaces without sacrificing CEF?
> 
> bug toolkit didn't show any bugs relating to shaping on the platforms I 
> checked.
> 
> Thanks,
> 
> C.
> 
> 
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/




signature.asc
Description: OpenPGP digital signature
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] traffic shape on 87x/88x/18xx SVI interfaces

[Chris Flav]

- Original Message 
From: Shimol Shah 
To: cisco-nsp@puck.nether.net
Sent: Tue, April 27, 2010 10:24:50 AM
Subject: Re: [c-nsp] traffic shape on 87x/88x/18xx SVI interfaces

GTS is the old way of doing Qos. It is not supported in the CEF path. MQC is 
the new and recommended way. With GTS if you do "sh cef int <>" you will see 
something like below





Well actually, we are using policy-maps;

policy-map Shape
 class class-default
  shape average 800 64000 0
!


interface Vlan1088
 description Internet
 ip vrf forwarding 1088
 ip address 192.168.12.1 255.255.255.248
 no ip proxy-arp
 service-policy output Shape
!

and unless "no ip route-cache cef" is applied to the Fe4 interface on the 
871/881 router used, no packets ever match.

This is MQC is it not?

C.


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

Re: [c-nsp] traffic shape on 87x/88x/18xx SVI interfaces

[Shimol Shah]

GTS is the old way of doing Qos. It is not supported in the CEF path. 
MQC is the new and recommended way. With GTS if you do "sh cef int <>" 
you will see something like below


DUT#sh run int g3/2
Building configuration...

Current configuration : 168 bytes
!
interface GigabitEthernet3/2
 ip address 192.168.3.1 255.255.255.0
 tag-switching ip
 traffic-shape rate 2000 50 50 1000
 max-reserved-bandwidth 100
end


DUT#sh cef int g3/2 int
GigabitEthernet3/2 is up (if_number 7)
  Corresponding hwidb fast_if_number 7
  Corresponding hwidb firstsw->if_number 7
  Internet address is 192.168.3.1/24
  ICMP redirects are always sent
  IP unicast RPF check is disabled
  Inbound access list is not set
  Outbound access list is not set
  IP policy routing is disabled
  BGP based policy accounting is disabled
  Packets switched to this interface are dropped to the next slow path: 
Traffic shaping



Notice the last line 

Without it you will see,

DUT#sh cef int g3/2 int
GigabitEthernet3/2 is up (if_number 7)
  Corresponding hwidb fast_if_number 7
  Corresponding hwidb firstsw->if_number 7
  Internet address is 192.168.3.1/24
  ICMP redirects are always sent
  IP unicast RPF check is disabled
  Inbound access list is not set
  Outbound access list is not set
  IP policy routing is disabled
  BGP based policy accounting is disabled
  Hardware idb is GigabitEthernet3/2 (7)
  Software idb is GigabitEthernet3/2 (7)
  Fast switching type 22, interface type 141
  IP CEF switching enabled
  IP Fast switching turbo vector
  IP CEF switching with tag imposition turbo vector
  Input fast flags 0x0, Output fast flags 0x0
  ifindex 4(4)
  Slot 3 Slot unit 2 VC -1
  Transmit limit accumulator 0x0 (0x0)
  IP MTU 1500
 Subblocks:
  MPLS subblock present

Hope that helps

Shimol



On 4/27/10 10:06 AM, Chris Flav wrote:


Hello,

We are trying to do a simple "traffic-shape rate" command on a variety of router 
platforms (871,881,1811) and have determined that the traffic-shape does not actually take effect 
unless "no ip route-cache cef" is applied to the Fe4 interface (or Fe0 or Fe1 on the 
1811).  Traffic shape commands applied to the Fe4 interface however work properly, and on the 1811 
Fe0 and Fe1 interfaces behave correctly.

Is there any other way to have shaping applied on VLANs configured on the SVI 
interfaces without sacrificing CEF?

bug toolkit didn't show any bugs relating to shaping on the platforms I checked.

Thanks,

C.


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

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

Re: [c-nsp] SNMPv3 bug on 3550

[Church, Charles]

I can't find my notes on it, but I seem to remember it being a bug.  I
believe a later code fixed our issue.

 

Chuck Church
Network Planning Engineer, CCIE #8776

Southcom

Harris IT Services

1210 N. Parker Rd.

Greenville, SC 29609 
Office: 864-335-9473

Cell: 864-266-3978

E-mail:   charles.chu...@harris.com

Southcom E-mail:  
charles.church@hq.southcom.mil

 

From: Ibrahim Abo Zaid [mailto:ibrahim.aboz...@gmail.com] 
Sent: Tuesday, April 27, 2010 7:15 AM
To: Peter Rathlev
Cc: Church, Charles; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] SNMPv3 bug on 3550

 

Hi All

Iam facing the same below issue on 7200 with 12.2(25)S image

does anyone face the same problem ? is it a bug ?


thanks
--Ibrahim



On Thu, Feb 7, 2008 at 1:33 AM, Peter Rathlev  wrote:

Sorry about the "empty" mail before, was busy wiping up coffee from my
keyboard. :-)

I've tested the same on our 3550/SEE2's and with the same results. Trial
and error shows that if I exclude the "auth md5 blah" part of the user
definition, everything works as expected. It doesn't help using SHA.

When creating the user I get this log message by the way:

Feb  7 00:16:56.657 met: Configuring snmpv3 USM user, persisting
snmpEngineBoots. Please Wait...

It never gets further.

It also seems to be the "snmp-server host ..." command that creates the
"snmp-server group testuser" command. I'm no expert in SNMPv3, but that
may or may not be an error.

So I'd say it's a bug. (Just use v2c, hacky sacks never really died so
why should v2c? :-)

Regards,
Peter



On Wed, 2008-02-06 at 15:03 -0600, Church, Charles wrote:

> Thanks.  I did try it that way too.  Long log shows it doing this:
>
> PSRB-U00-OS-03(config)#do sh run | i test
>
> PSRB-U00-OS-03(config)#do sh snmp user
>
> PSRB-U00-OS-03(config)#do sh snmp group
>
> PSRB-U00-OS-03(config)#snmp-server group testgroup v3 auth access 98
>
> PSRB-U00-OS-03(config)#do sh run | i test
> snmp-server group testgroup v3 auth access 98
>
> PSRB-U00-OS-03(config)#snmp-server user testuser testgroup v3 auth md5
>  blah access 98
>
> PSRB-U00-OS-03(config)#do sh run | i test
> snmp-server group testgroup v3 auth access 98
>
> PSRB-U00-OS-03(config)#snmp-server host 172.24.4.5 version 3 auth testuser
> PSRB-U00-OS-03(config)#snmp-server host 172.24.5.6 version 3 auth testuser
> PSRB-U00-OS-03(config)#snmp-server host 172.26.4.7 version 3 auth testuser
>
> PSRB-U00-OS-03(config)#do sh run | i test
> snmp-server group testuser v3 auth notify
*tv....0F
> snmp-server group testgroup v3 auth access 98
> snmp-server host 172.24.4.5 version 3 auth testuser
> snmp-server host 172.24.5.6 version 3 auth testuser
> snmp-server host 172.26.4.7 version 3 auth testuser
>
> PSRB-U00-OS-03(config)#do sh snmp group
> groupname: testuser security model:v3 auth
> readview :   writeview: 
> notifyview: *tv....F
> row status: active
>
> groupname: testgroupsecurity model:v3 auth
> readview : v1defaultwriteview: 
> notifyview: 
> row status: active  access-list: 98
>
> PSRB-U00-OS-03(config)#do sh snmp user
>
> User name: testuser
> Engine ID: 8009030D65D8D281
> storage-type: nonvolatileactive access-list: 98
> Authentication Protocol: MD5
> Privacy Protocol: None
> Group-name: testgroup
>
> PSRB-U00-OS-03(config)#
>
>
> So it would appear that the configuration of the trap destinations is
>  what's causing the group with the user name to be created.  Same
>  result if you do the user first, and then the group.  Any ideas?
>
> Thanks,
>
> Chuck
>
> -Original Message-
> From: Tassos Chatzithomaoglou [mailto:ach...@forthnet.gr]
> Sent: Wednesday, February 06, 2008 3:42 PM
> To: Church, Charles
> Cc: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] SNMPv3 bug on 3550
>
>
> I think you have to create group first, then user.
>
> --
> Tassos
>
>
> Church, Charles wrote on 6/2/2008 9:27 μμ:
> > Hey all,
> >
> > I'm seeing the following behavior on 3550s running
> > c3550-ipbasek9-mz.122-25.SEE2.bin:
> >
> > Commands entered:
> > snmp-server user testuser testgroup v3 auth md5 (password) access 98
> > snmp-server group testgroup v3 auth not
> > *tv....FF access 98
> > snmp-server host 172.24.4.5 version 3 auth testuser
> >
> > Results of commands:
> > snmp-server group testuser v3 auth notify
> > *tv....0F
> > snmp-server group testgroup v3 auth notify
> > *tv....FF
> > snmp-server host 172.24.4.5 version 3 auth testuser
> >
> > So the configuration of a user called 'testuser' is creating a group
> > called 'testuser'.  We should only be seeing 'testgroup' exist as a
> > group, right?  I did a search through bug navigator, didn't see anything
> > involving snmp and user or group listed.  Is this a known is

[c-nsp] traffic shape on 87x/88x/18xx SVI interfaces

[Chris Flav]

Hello,

We are trying to do a simple "traffic-shape rate" command on a variety of 
router platforms (871,881,1811) and have determined that the traffic-shape does 
not actually take effect unless "no ip route-cache cef" is applied to the Fe4 
interface (or Fe0 or Fe1 on the 1811).  Traffic shape commands applied to the 
Fe4 interface however work properly, and on the 1811 Fe0 and Fe1 interfaces 
behave correctly.

Is there any other way to have shaping applied on VLANs configured on the SVI 
interfaces without sacrificing CEF?

bug toolkit didn't show any bugs relating to shaping on the platforms I checked.

Thanks,

C.


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

Re: [c-nsp] WiMAX Download

[David Prall]

I'd say long fat pipe issues.

--
http://dcp.dcptech.com


> -Original Message-
> From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-
> boun...@puck.nether.net] On Behalf Of Mohammad Khalil
> Sent: Tuesday, April 27, 2010 9:31 AM
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] WiMAX Download
> 
> 
> Dears
> 
> many of the customers who uses our WiMAX service claims that they
> cannot get their full speed using one session , when they open more
> than 1 session they can almost get all the speed , is that reasonable ?
> is it related to network infrastructure or WiMAX infrastructure (ASN GW
> and CPEs)
> 
> Thanks in advance
> 
> 
> 
> _
> Hotmail: Free, trusted and rich email service.
> https://signup.live.com/signup.aspx?id=60969
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

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

Re: [c-nsp] WiMAX Download

[Rubens Kuhl]

Yes, it's reasonable due to the high latency of 802.16e and to some
packet losses that are intrinsic to wireless access. Bandwidth is
something related to latency in an inverse linear proportion, and to
that latency you have the add all the way till the server where the
user is getting content from, which is usually in another country and
subject to more latency.

Having caches (both HTTP and P2P) and CDNs on your network may provide
a better perception of service quality.


Rubens




On Tue, Apr 27, 2010 at 10:31 AM, Mohammad Khalil  wrote:
>
> Dears
>
> many of the customers who uses our WiMAX service claims that they cannot get 
> their full speed using one session , when they open more than 1 session they 
> can almost get all the speed , is that reasonable ? is it related to network 
> infrastructure or WiMAX infrastructure (ASN GW and CPEs)
>
> Thanks in advance
>
>
>
> _
> Hotmail: Free, trusted and rich email service.
> https://signup.live.com/signup.aspx?id=60969
> ___
> cisco-nsp mailing list  cisco-...@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>

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

[c-nsp] WiMAX Download

[Mohammad Khalil]

Dears

many of the customers who uses our WiMAX service claims that they cannot get 
their full speed using one session , when they open more than 1 session they 
can almost get all the speed , is that reasonable ? is it related to network 
infrastructure or WiMAX infrastructure (ASN GW and CPEs)

Thanks in advance


  
_
Hotmail: Free, trusted and rich email service.
https://signup.live.com/signup.aspx?id=60969
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] 6500 latency

[Jeff Bacon]

OK, I know that a 6500 is not a super low latency box. I've seen around 17usec, 
card to card to another switch CFC mode, but due to time constraints have done 
little formal analysis. 


I'm guessing its better in DFC mode, and on 6700 cards, and if your traffic is 
local to a card or to a fabric port such that it doesn't have to traverse the 
fabric. 

I'm also guessing that sup32s and anything on classic bus (including the two 
interfaces on the sup720) aren't super-high latency either. 

Has anyone done any work on what the overall parameters are on a 6500's 
switching latency? Or got a pliable cisco rep who can get me to someone who can 
unlock those documents? 

Clearly Cisco has, to the extent that a cisco exec told me yesterday that they 
see no role for the 6500 in low-latency financial market apps except in edge 
cases where NAT is needed and even then I should consider an ASR (of course 
they need to sell more nexii I imagine - but what, am I made of money???). 
Strangely, though, I find them highly reticent to share anything about the 
actual facts of the matter. Maybe they're annoyed that I buy mostly refurb 
gear. :) 

(Then again, I tend to find that most micro-level-latency talk to be half 
marketing fluff and mantra, and/or an excuse to spend a ton more money on 
product X.)

It's a shame that most exchanges force me to NAT to talk to them unless I want 
to do Really Stupid Things with my network, or talk ARIN out of a /22. Which is 
why I have 6500s everywhere (and sometimes wonder about the wisdom thereof, 
given the costs).

OK, I admit I am ranting.
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] ras configuration

[Ziv Leyes]

Could you be more specific?
What kind of connections, protocols, etc would you like the RAS to use? What 
equipment do you own or plan to buy?
I can send you a sample config, but I need some more details...
Ziv



-Original Message-
From: cisco-nsp-boun...@puck.nether.net 
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of sagar sas
Sent: Tuesday, April 27, 2010 9:43 AM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] ras configuration

Can somebody help to configure ras
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

 
 

This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer 
viruses.





 
 

This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer 
viruses.





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

Re: [c-nsp] 6500/Sup720 and SVI xconnect?

[Peter Rathlev]

Thanks for the answers so far. We'll check with our AM to see if they
have any further details. :-)

On Tue, 2010-04-27 at 09:04 +0200, Peter Rathlev wrote:
> If one were to want xconnected SVIs and "real" VPLS on a 6500/Sup720,
> what would one need? We need 10G, and using SIP-600 as core facing
> interfaces seems to be the only solution, albeit rather expensive.

-- 
Peter


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

Re: [c-nsp] SNMPv3 bug on 3550

[Ibrahim Abo Zaid]

Hi All

Iam facing the same below issue on 7200 with 12.2(25)S image

does anyone face the same problem ? is it a bug ?


thanks
--Ibrahim


On Thu, Feb 7, 2008 at 1:33 AM, Peter Rathlev  wrote:

> Sorry about the "empty" mail before, was busy wiping up coffee from my
> keyboard. :-)
>
> I've tested the same on our 3550/SEE2's and with the same results. Trial
> and error shows that if I exclude the "auth md5 blah" part of the user
> definition, everything works as expected. It doesn't help using SHA.
>
> When creating the user I get this log message by the way:
>
> Feb  7 00:16:56.657 met: Configuring snmpv3 USM user, persisting
> snmpEngineBoots. Please Wait...
>
> It never gets further.
>
> It also seems to be the "snmp-server host ..." command that creates the
> "snmp-server group testuser" command. I'm no expert in SNMPv3, but that
> may or may not be an error.
>
> So I'd say it's a bug. (Just use v2c, hacky sacks never really died so
> why should v2c? :-)
>
> Regards,
> Peter
>
>
> On Wed, 2008-02-06 at 15:03 -0600, Church, Charles wrote:
> > Thanks.  I did try it that way too.  Long log shows it doing this:
> >
> > PSRB-U00-OS-03(config)#do sh run | i test
> >
> > PSRB-U00-OS-03(config)#do sh snmp user
> >
> > PSRB-U00-OS-03(config)#do sh snmp group
> >
> > PSRB-U00-OS-03(config)#snmp-server group testgroup v3 auth access 98
> >
> > PSRB-U00-OS-03(config)#do sh run | i test
> > snmp-server group testgroup v3 auth access 98
> >
> > PSRB-U00-OS-03(config)#snmp-server user testuser testgroup v3 auth md5
> >  blah access 98
> >
> > PSRB-U00-OS-03(config)#do sh run | i test
> > snmp-server group testgroup v3 auth access 98
> >
> > PSRB-U00-OS-03(config)#snmp-server host 172.24.4.5 version 3 auth
> testuser
> > PSRB-U00-OS-03(config)#snmp-server host 172.24.5.6 version 3 auth
> testuser
> > PSRB-U00-OS-03(config)#snmp-server host 172.26.4.7 version 3 auth
> testuser
> >
> > PSRB-U00-OS-03(config)#do sh run | i test
> > snmp-server group testuser v3 auth notify
> *tv....0F
> > snmp-server group testgroup v3 auth access 98
> > snmp-server host 172.24.4.5 version 3 auth testuser
> > snmp-server host 172.24.5.6 version 3 auth testuser
> > snmp-server host 172.26.4.7 version 3 auth testuser
> >
> > PSRB-U00-OS-03(config)#do sh snmp group
> > groupname: testuser security model:v3 auth
> > readview :   writeview:  specified>
> > notifyview: *tv....F
> > row status: active
> >
> > groupname: testgroupsecurity model:v3 auth
> > readview : v1defaultwriteview:  specified>
> > notifyview: 
> > row status: active  access-list: 98
> >
> > PSRB-U00-OS-03(config)#do sh snmp user
> >
> > User name: testuser
> > Engine ID: 8009030D65D8D281
> > storage-type: nonvolatileactive access-list: 98
> > Authentication Protocol: MD5
> > Privacy Protocol: None
> > Group-name: testgroup
> >
> > PSRB-U00-OS-03(config)#
> >
> >
> > So it would appear that the configuration of the trap destinations is
> >  what's causing the group with the user name to be created.  Same
> >  result if you do the user first, and then the group.  Any ideas?
> >
> > Thanks,
> >
> > Chuck
> >
> > -Original Message-
> > From: Tassos Chatzithomaoglou [mailto:ach...@forthnet.gr]
> > Sent: Wednesday, February 06, 2008 3:42 PM
> > To: Church, Charles
> > Cc: cisco-nsp@puck.nether.net
> > Subject: Re: [c-nsp] SNMPv3 bug on 3550
> >
> >
> > I think you have to create group first, then user.
> >
> > --
> > Tassos
> >
> >
> > Church, Charles wrote on 6/2/2008 9:27 μμ:
> > > Hey all,
> > >
> > > I'm seeing the following behavior on 3550s running
> > > c3550-ipbasek9-mz.122-25.SEE2.bin:
> > >
> > > Commands entered:
> > > snmp-server user testuser testgroup v3 auth md5 (password) access 98
> > > snmp-server group testgroup v3 auth not
> > > *tv....FF access 98
> > > snmp-server host 172.24.4.5 version 3 auth testuser
> > >
> > > Results of commands:
> > > snmp-server group testuser v3 auth notify
> > > *tv....0F
> > > snmp-server group testgroup v3 auth notify
> > > *tv....FF
> > > snmp-server host 172.24.4.5 version 3 auth testuser
> > >
> > > So the configuration of a user called 'testuser' is creating a group
> > > called 'testuser'.  We should only be seeing 'testgroup' exist as a
> > > group, right?  I did a search through bug navigator, didn't see
> anything
> > > involving snmp and user or group listed.  Is this a known issue?  We
> use
> > > the same command set on 6500s running 12.2(18)SXF9, don't see that
> > > happen.
> > >
> > > Thanks,
> > >
> > > Chuck Church
> > > Principal Network Engineer, CCIE #8776
> > > Harris Information Technology Services
> > > EDS Contractor - Navy Marine Corps Intranet (NMCI)
> > > 1210 N. Parker Rd. | Greenville, SC 29609
> > > Office: 864-335-9473 | Cell: 864-266-3978

Re: [c-nsp] 10G Ethernet Module

[Gert Doering]

Hi,

On Mon, Apr 26, 2010 at 09:58:38PM -0400, Tim Durack wrote:
> I suspect that 6500 + 20th Century OS = Nexus. Cisco are just being
> really careful how they break that news to their customers.

This is what I'm suspecting as well.  Nexus or IOS-XE.

(Now the interesting thing is: will the existing IOS landscape ever
run this "next generation" IOS?  Or will it only run on Sup-2T and
to-be-released interface cards...?)

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


pgpWAqbM7vJV6.pgp
Description: PGP signature
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 10G Ethernet Module

[Gert Doering]

Hi,

On Mon, Apr 26, 2010 at 08:48:40PM -0500, Tony Varriale wrote:
> From: "Gert Doering" 
> 
> >(Regarding your question, I can't say.  We decided to go for 6500 
> >chassis and SX* IOS - to eventually get software modularity...
> 
> And how's that working out for you?

Well.

 - positive points: SXH/SXI seems to have less exciting and amazing bugs
   than the SR* series.  Most of the releases "just work" for us, even
   though we hit some esoteric bugs every now and the.

 - positive points: LAN cards "just work for us"

 - we have only lab-tested SXI-modular so far, and it seemed to be
   well-behaving - bit I'm a bit disappointed at the lack of visible
   progress here, as in "no more patches" and "the modularity is not
   *that* modular at all yet, with CDPd being the outstanding example of
   an IOS process being made its own stand-alone routing daemon".

 - negative points: RSP720 has a much faster CPU, and that's something
   where the Sup720(-10G) could need some improvement...

Overall, we feel that *for us*, 6500+SX software has been the right
decision.

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


pgp0IhzU2eA2s.pgp
Description: PGP signature
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] MPLS over VLAN

[Rob Shakir]

On 27 Apr 2010, at 06:50, Samit wrote:

> But my understanding is it should not...because the c-tag and s-tag or
> whatsoever like b-vid.it..would be considered as a  payload when it
> enters the MPLS network.Appreciate if someone comment or confirm this..

Seems to me like the confusion here is around the fact that you've forgotten 
where MPLS sits in the stack :-)

Bear in mind that the frame that comes out of your PE looks something like the 
following:

+--+
|  Ethernet Header with 802.1q |
+--+
|  MPLS Label(s) + Headers |
+--+
|  Customer's Ethernet Header  |
+--+
|  Customer's Packet Payload   |
+--+

Your infrastructure just looks at the top Ethernet header, if it's an L2 
device. If it's an MPLS (L2.5) device, then it looks at the MPLS label, at 
which time it'll have a VFI ID or a VC ID, and this will be forwarded according 
to that (assuming it's an edge LSR - if it's a midpoint, it'll just swap the 
labels as usual). Nothing in your infrastructure (assuming that you're looking 
at VPLS with the customer connected to the PE, rather than H-VPLS or so with 
some metro L2 at the edge), will look at the customer's frame.

If there is a metro, then as you say, you'll likely have QinQ or similar, so 
you'll look at your outer 802.1q on the popped packet. As Gert says, any L2 
switches a frame, it'll do so on MAC, and has no awareness of what's in the 
packet, or what relevance it has to any service.

Kind regards,
Rob

-- 
Rob Shakir  
Network Development EngineerGX Networks/Vialtus Solutions
ddi: +44208 587 6077mob: +44797 155 4098
pgp: 0xc07e6deb nic-hdl: RJS-RIPE

This email is subject to: http://www.vialtus.com/disclaimer.html





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

Re: [c-nsp] 6500/Sup720 and SVI xconnect?

[Bartlomiej Anszperger]

W dniu 2010-04-27 10:37, Asbjorn Hojmark - Lists pisze:

> Also, on a 7600 (SR software), you can run Mux UNI (a trunk with VLANs
> and sub-interfaces on the same interface), even on LAN cards. I don't
> remember off the top of my head if that's supported on the 6500.

Supported since 12.2(33)SXH
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/pfc3mpls.html#wp1407597

> -A

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

Re: [c-nsp] 6500/Sup720 and SVI xconnect?

[Gert Doering]

Hi,

On Tue, Apr 27, 2010 at 10:37:34AM +0200, Asbjorn Hojmark - Lists wrote:
> Also, on a 7600 (SR software), you can run Mux UNI (a trunk with VLANs
> and sub-interfaces on the same interface), even on LAN cards. I don't
> remember off the top of my head if that's supported on the 6500.

It is, but won't help. You still can't put the xconnect configuration 
on the SVI.

gert

-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


pgpQYT9pIfKZJ.pgp
Description: PGP signature
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] 6500/Sup720 and SVI xconnect?

[Asbjorn Hojmark - Lists]

On Tue, 27 Apr 2010 09:04:35 +0200, you wrote:

> If one were to want xconnected SVIs and "real" VPLS on a 6500/Sup720,
> what would one need? We need 10G, and using SIP-600 as core facing
> interfaces seems to be the only solution, albeit rather expensive.

Check with your account team if the ES+ will be supported on the 6500
in a future software release. 

Also, on a 7600 (SR software), you can run Mux UNI (a trunk with VLANs
and sub-interfaces on the same interface), even on LAN cards. I don't
remember off the top of my head if that's supported on the 6500.

-A

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

Re: [c-nsp] 10G Ethernet Module

[Artyom Viklenko]

26.04.2010 17:56, William Jobs пишет:

Hi,

I'm in need of a 10G Ethernet module to run in a 7606 chassis. According to
the following page:

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/hardware/Module_Installation/Mod_Install_Guide/02ethern.html

the module I'm interested in, the WS-X6708-10G-3CXL, is only supported by
the Supervisor Engine 720 and the Supervisor Engine 720-10GE. The chassis I
have has the RSP720.

What options are available for a chassis running the RSP720?


Hi!

We have WS-X6708-10GE with WS-F6700-DFC3CXL on 7600-s
with RSP720-3CXL-GE. Works fine.

You need at least SRC IOS version. SRB doesn't support 8-port card,
only 4-port WS-X6704-10GE.

--
   Sincerely yours,
Artyom Viklenko.
---
ar...@aws-net.org.ua | http://www.aws-net.org.ua/~artem
ar...@viklenko.net   | 
FreeBSD: The Power to Serve   -  http://www.freebsd.org
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: [c-nsp] MPLS over VLAN

[Gert Doering]

Hi,

On Mon, Apr 26, 2010 at 05:32:05PM -0400, Paul Stewart wrote:
> Can someone explain this a bit better for me? ;)   Sorry if this is "MPLS
> 101"...
> 
> We are getting ready to deploy some equipment (mixture of Cisco/Juniper)
> that is MPLS capable.  We'd like to transport some VPLS traffic however in
> the middle of a few of the links are layer2 switches - we've been told this
> isn't possible even with 1600 MTU frame size supported Juniper is
> telling us (in one particular segment) that we must hang MX gear in there to
> make it work with MPLS... 

Well, the L2 switches "in between" wouldn't know how to handle MPLS, but
"should" (as in "I have not seen evidence to the contrary") not interfere
with the MPLS packets as such.  (Except for MTU issues, but that's 
independent of MPLS encapsulation)

Just as these L2 switches would be able to transport IP or IPv6 as L3
protocols, without understanding what these protocols are about.

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


pgph8YbCNxFf8.pgp
Description: PGP signature
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[c-nsp] 6500/Sup720 and SVI xconnect?

[Peter Rathlev]

Hi,

For some time we have used loop cables and port mode EoMPLS in order to
both to L2 transport over MPLS and L3 termination of the same VLAN. This
might sometimes result in supoptimal switching, since there's no (easy)
way to make the switches understand the way the L2 and L3 topology work
together.

If one were to want xconnected SVIs and "real" VPLS on a 6500/Sup720,
what would one need? We need 10G, and using SIP-600 as core facing
interfaces seems to be the only solution, albeit rather expensive.

Are there any other options? Apart from waiting for an EARL8 supervisor
for the 6500 of course. :-)

-- 
Peter


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

Re: [c-nsp] IP route analysis solution

[Pan vangels]

...and ALU has a very powerful (multivendor) solution as well:
http://www.alcatel-lucent.com/wps/portal/!ut/p/kcxml/04_Sj9SPykssy0xPLMnMz0vM0Y_QjzKLd4w3dnTRL8h2VAQADYR9IA!!?LMSG_CABINET=Solution_Product_Catalog&LMSG_CONTENT_FILE=Products/Product_Detail_000520.xml&LMSG_PARENT=Product_Families/Product_Family_000188.xml&LMSG_GPARENT=Product_Categories/Product_Category_33.xml&LMSG_CATEGORY=Y&LMSG_SUBCATEGORY=Y

Pan.


> Date: Tue, 27 Apr 2010 01:17:39 +0300
> From: ach...@forthnet.gr
> To: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] IP route analysis solution
> 
> Juniper has also a similar product:
> http://www.juniper.net/us/en/products-services/software/junos-platform/junos-space/applications/route-insight-manager/
> 
> --
> Tassos
> 
> Ibrahim Abo Zaid wrote on 26/04/2010 22:47:
> > Hi all
> >
> > i'm looking for IP route analysis solution that can discover and draw a
> > topology for the network and helps in planning process by simulating any
> > modifications
> >
> > i did some googling and find 2 solutions in this area , Packet Design Route
> > Explorer and HP RAMS
> >
> > do u have other ideas ? what are you impressions about these tools if you
> > tried any ?
> >
> >
> > thanks
> > --Ibrahim
> > ___
> > cisco-nsp mailing list  cisco-nsp@puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> >
> >
> 
> ___
> cisco-nsp mailing list  cisco-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
  
_
Hotmail: Trusted email with powerful SPAM protection.
https://signup.live.com/signup.aspx?id=60969
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/