Re: [c-nsp] CPP and MAC address population

[Tim Stevenson]

Hi Chris,

The SMAC will be learned in that case.


Hope that helps,
Tim


At 06:55 PM 5/21/2010, Chris Woodfield opined:


Odd question, but there's a reason for it, I assure you...

On the 6500/Sup720 platform, will an ethernet frame that is dropped 
due to hitting a control-plane policer rule (or an inbound policer, 
or inbound access list, ...) still cause its source MAC address to 
be entered into the switch's MAC address table? Or will the fact 
that the frame is dropped prevent the MAC table population from taking place?


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/





Tim Stevenson, tstev...@cisco.com
Routing & Switching CCIE #5561
Technical Marketing Engineer, Cisco Nexus 7000
Cisco - http://www.cisco.com
IP Phone: 408-526-6759

The contents of this message may be *Cisco Confidential*
and are intended for the specified recipients only.


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

[c-nsp] CPP and MAC address population

[Chris Woodfield]

Odd question, but there's a reason for it, I assure you...

On the 6500/Sup720 platform, will an ethernet frame that is dropped due to 
hitting a control-plane policer rule (or an inbound policer, or inbound access 
list, ...) still cause its source MAC address to be entered into the switch's 
MAC address table? Or will the fact that the frame is dropped prevent the MAC 
table population from taking place?

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] Nexus 7k CoPP

[Anton Kapela]

On May 21, 2010, at 5:19 PM, Ziv Leyes wrote:

> ip access-list extended CP-CRITICAL-ROUTING
> permit tcp any any eq bgp

[snip]

L4-only matches are a suboptimal (this is a polite understatement) way to use 
CoPP any platform I'm familiar with. I recommend that nobody do this, 
especially for routing protocols. ACL's for routing protocols (ospf, bgp, etc) 
in CoPP-policies should match specific layer3 hosts (or aggregated prefixes, if 
you number links that way) which you explicitly expect IP packets from. 

-Tk
___
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] Nexus 7k CoPP

[Lincoln Dale]

On 21/05/2010, at 12:53 PM, Jason Leblanc wrote:

> We are deploying a ton of Nexus 7ks right now.  Our traditional standard had
> a named ACL for SNMP, we also use transport input ssh and have an ACL
> allowing access for that,  Our tools are only allowed from certain segments
> etc...  On the 7k's the only option is to use CoPP.  Does anyone out there
> have a configuration example of how they used this?  Cisco said they are
> working on getting the old features added back in as a feature enhancement
> later on.

N7K NX-OS does have ACL on out-of-band mgmt0 -- but not the 'vty access-class' 
that you're used to in IOS.
if you are doing mgmt using out-of-band then you can keep doing it the way you 
always have.
if you are doing it 'inband' then yes you need to tune the CoPP policy to 
achieve what you want.

here is how you can do it with CoPP:

--
In order to use CoPP to achieve the equivalent of a VTY access-class, one needs 
to explicitly define ACLs used in the CoPP policy to match  ‘allowed’ traffic 
(and police that to a given rate) as well as define CoPP policies to match 
‘denied’ traffic and drop that traffic.
CoPP is different from ACLs in that one cannot just use “deny ip any any’ as a 
policy, rather one needs to use ‘permit’ to match the undesired traffic then 
use the policer to ‘drop’ that traffic.

As an example, lets take an example of permitting access from the subnet 
30.30.30.0/24, in order to deploy CoPP to provide the equivalent of a VTY 
access-class, it could be configured as follows.  In this particular policy, we 
are explicitly allowing telnet/ssh/snmp/NTP/RADIUS/TACACS+ inbound from 
30.30.30/24 and anything outbound from the switch to 30.30.30.0/24.


ip access-list copp-system-acl-allow
  10 remark ### ALLOW TELNET from 30.30.30.0/24
  20 permit tcp 30.30.30.0/24 any eq telnet 
  30 permit tcp 30.30.30.0/24 any eq 107 
  40 remark ### ALLOW SSH from 30.30.30.0/24
  50 permit tcp 30.30.30.0/24 any eq 22 
  60 remark ### ALLOW SNMP from 30.30.30.0/24
  70 permit udp 30.30.30.0/24 any eq snmp 
  80 remark ### ALLOW TACACS from 30.30.30.0/24
  90 permit tcp 30.30.30.0/24 any eq tacacs 
  100 remark ### ALLOW RADIUS from 30.30.30.0/24
  110 permit udp 30.30.30.0/24 any eq 1812 
  120 permit udp 30.30.30.0/24 any eq 1813 
  130 permit udp 30.30.30.0/24 any eq 1645 
  140 permit udp 30.30.30.0/24 any eq 1646 
  150 permit udp 30.30.30.0/24 eq 1812 any 
  160 permit udp 30.30.30.0/24 eq 1813 any 
  170 permit udp 30.30.30.0/24 eq 1645 any 
  180 permit udp 30.30.30.0/24 eq 1646 any 
  190 remark ### ALLOW NTP from 30.30.30.0/24
  200 permit udp 30.30.30.0/24 any eq ntp 
  210 remark ### ALLOW ALL OUTBOUND traffic TO 30.30.30.0/24
  220 permit ip any 30.30.30.0/24
  statistics  # keep statistics on matches
ip access-list copp-system-acl-deny
  10 remark ### this is a catch-all to match any other traffic
  20 permit ip any any
  statistics  # keep statistics on matches
class-map type control-plane match-any copp-system-class-management-allow
  match access-group name copp-system-acl-allow
class-map type control-plane match-any copp-system-class-management-deny
  match access-group name copp-system-acl-deny
policy-map type control-plane copp-system-policy 
class copp-system-class-management-allow
police cir 6 kbps bc 250 ms conform transmit violate drop 
class copp-system-class-management-deny
police cir 6 kbps bc 250 ms conform drop violate drop 
control-plane
  service-policy input copp-system-policy 


The key points here are that:
• we use a class to match the traffic we want to allow (with a policer 
allowing transmit @ 6 kbps)
• for all other traffic we explicitly allow it (but with a policer set 
to drop the traffic)


cheers,

lincoln.


___
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] Nexus 7k CoPP

[Ziv Leyes]

I've found in this mailing list archives an answer I wrote to someone else:
==
Here are a couple of links that helped me out when I needed it the first time

This one contains some info about CoPP, thought it's quite an old document, 
it's still relevant http://aharp.ittns.northwestern.edu/papers/copp.html 

You may also consider securing the device all around, not only by CoPP, here's 
some useful info about Cisco security, this one is maintained and updated 
regularly. http://www.cymru.com/Documents/secure-ios-template.html 

==

Following the above recommendations, this is what I've came up with and use it 
on my border routers:

ip access-list standard CP-DEFAULT
 permit any
!
ip access-list extended CP-CRITICAL-ROUTING
 permit tcp any any eq bgp
ip access-list extended CP-ICMP
 permit icmp any any echo
ip access-list extended CP-NTP
 permit udp any any eq ntp
ip access-list extended CP-SNMP
 permit tcp any any eq 161
 permit tcp any any eq 162
ip access-list extended CP-TCP-SYN
 permit tcp any any syn
!
class-map match-any CP-TCP-SYN
 match access-group name CP-TCP-SYN
class-map match-any CP-IMPORTANT-NTP
 match access-group name CP-NTP
class-map match-any CP-ICMP
 match access-group name CP-ICMP
class-map match-any CP-CRITICAL-ROUTING
 match access-group name CP-CRITICAL-ROUTING
class-map match-any CP-IMPORTANT-SNMP
 match access-group name CP-SNMP
class-map match-any CP-DEFAULT
 match access-group name CP-DEFAULT
!
!
policy-map CONTROL-PLANE
 class CP-TCP-SYN
  police cir 10 bc 3125 be 3125
conform-action transmit 
exceed-action drop 
violate-action drop 
 class CP-CRITICAL-ROUTING
  police cir 100 bc 31250 be 31250
conform-action transmit 
exceed-action drop 
violate-action drop 
 class CP-IMPORTANT-SNMP
  police cir 10 bc 3125 be 3125
conform-action transmit 
exceed-action drop 
violate-action drop 
 class CP-IMPORTANT-NTP
  police cir 50 bc 15625 be 15625
conform-action transmit 
exceed-action drop 
violate-action drop 
 class CP-ICMP
  police cir 200 bc 15625 be 15625
conform-action transmit 
exceed-action drop 
violate-action drop 
 class CP-DEFAULT
  police cir 300 bc 31250 be 31250
conform-action transmit 
exceed-action drop 
violate-action drop 
!
control-plane
 service-policy input CONTROL-PLANE

I don't know if all the settings will fit on your platform, and also you may 
want or need to change some settings to fit your environment, but I guess this 
can give you something to start with.
Hope it helps
Ziv




-Original Message-
From: cisco-nsp-boun...@puck.nether.net 
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Jason Leblanc
Sent: Friday, May 21, 2010 10:54 PM
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] Nexus 7k CoPP

Hello,

We are deploying a ton of Nexus 7ks right now.  Our traditional standard had
a named ACL for SNMP, we also use transport input ssh and have an ACL
allowing access for that,  Our tools are only allowed from certain segments
etc...  On the 7k's the only option is to use CoPP.  Does anyone out there
have a configuration example of how they used this?  Cisco said they are
working on getting the old features added back in as a feature enhancement
later on.

Thanks,

//LeBlanc
___
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/

[c-nsp] (no subject)

[Alessandro Braga]

___
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] Ethernet Interfaces Speed and Duplex - Force or Auto

[Seth Mattinen]

On 5/21/2010 12:10, Jeff Kell wrote:
> On 5/21/2010 2:34 PM, Jason Gurtz wrote:
>> There *is* some stuff around here that doesn't auto-neg properly--100% old
>> scada-related gear.
>>   
> 
> There are still corner cases of 10/100 autoneg issues, I concur with
> others and  locally run autoneg  by default and hard-code exceptions
> (less than a dozen in 20K ports).
> 
> For those thinking hard coding more than necessary, note that
> autonegotiation is *mandatory* on 1000TX ethernet (at least to comply
> with IEEE specs). 
> 


And if by some chance your vendor doesn't support autoneg on 1000TX it's
time to find a new vendor.

~Seth
___
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] Ethernet Interfaces Speed and Duplex - Force or Auto

[Mark]

There are reasons why you don't set it to "auto". Working in a post production 
facility back then has taught me that some of the issues with final cut pro 
dropping frames when dumping to a raid storage can be caused by one side 
"downgrading" to 100 from 1000 and that would cause some grief. I usually set 
it to 1000 forced and if it drops, it drops. This holds especially true when 
you are dealing with video streams.


Mark

On 22-May-2010, at 2:34 AM, Jason Gurtz wrote:

>> It's more a matter of personal annoyance at network admins that refuse
>> to acknowledge that devices change and problems evolve, and insist that
>> "the rules that we have learned last century are cast in stone and must
>> be followed to the end".  The auto-neg/no auto-neg discussion is very
>> prototypical for that :-)
> 
> I've no idea how the CCIE re-cert process goes, but it would be great if
> they added something to that process to wake up the elderly CCIEs out
> there to this issue.
> 
> We have one that comes here from time to time on a contractual basis and
> I'm always setting things back to auto after he leaves.  Unfortunately,
> he's bringing up the CCNPs in his Co. to do the same thing :(
> 
> I have to admit to half-believing this same idea 'till I read a post and
> comments on Greg Ferro's blog:
> http://etherealmind.com/network-dictionary-mythinformation/
> 
> Lately he followed up with details:
> http://etherealmind.com/ethernet-autonegotiation-works-why-how-standard-sh
> ould-be-set/
> 
> There *is* some stuff around here that doesn't auto-neg properly--100% old
> scada-related gear.
> 
> ~JasonG
> 
> ___
> 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] Nexus 7k CoPP

[tkapela]

This list has extensive coverage of CoPP (how it works, examples, etc) for 
various platforms. I'd goodle up site: for a bit to see if that can satisfy 
your needs.

Conceptually, CoPP works the same across platforms.

Roland ;) will likely suggest iACL's (infrastructure) at strategic border/peer 
locations, but CoPP is certainly handy for more than controlling who can hit 
ssh or telnet.

-Tk

-Original Message-
From: Jason Leblanc 
Date: Fri, 21 May 2010 12:53:51 
To: 
Subject: [c-nsp]  Nexus 7k CoPP

Hello,

We are deploying a ton of Nexus 7ks right now.  Our traditional standard had
a named ACL for SNMP, we also use transport input ssh and have an ACL
allowing access for that,  Our tools are only allowed from certain segments
etc...  On the 7k's the only option is to use CoPP.  Does anyone out there
have a configuration example of how they used this?  Cisco said they are
working on getting the old features added back in as a feature enhancement
later on.

Thanks,

//LeBlanc
___
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] Nexus 7k CoPP

[Jason Leblanc]

Hello,

We are deploying a ton of Nexus 7ks right now.  Our traditional standard had
a named ACL for SNMP, we also use transport input ssh and have an ACL
allowing access for that,  Our tools are only allowed from certain segments
etc...  On the 7k's the only option is to use CoPP.  Does anyone out there
have a configuration example of how they used this?  Cisco said they are
working on getting the old features added back in as a feature enhancement
later on.

Thanks,

//LeBlanc
___
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] Ethernet Interfaces Speed and Duplex - Force or Auto

[Jeff Kell]

On 5/21/2010 2:34 PM, Jason Gurtz wrote:
> There *is* some stuff around here that doesn't auto-neg properly--100% old
> scada-related gear.
>   

There are still corner cases of 10/100 autoneg issues, I concur with
others and  locally run autoneg  by default and hard-code exceptions
(less than a dozen in 20K ports).

For those thinking hard coding more than necessary, note that
autonegotiation is *mandatory* on 1000TX ethernet (at least to comply
with IEEE specs). 

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] Ethernet Interfaces Speed and Duplex - Force or Auto

[Jason Gurtz]

> It's more a matter of personal annoyance at network admins that refuse
> to acknowledge that devices change and problems evolve, and insist that
> "the rules that we have learned last century are cast in stone and must
> be followed to the end".  The auto-neg/no auto-neg discussion is very
> prototypical for that :-)

I've no idea how the CCIE re-cert process goes, but it would be great if
they added something to that process to wake up the elderly CCIEs out
there to this issue.

We have one that comes here from time to time on a contractual basis and
I'm always setting things back to auto after he leaves.  Unfortunately,
he's bringing up the CCNPs in his Co. to do the same thing :(

I have to admit to half-believing this same idea 'till I read a post and
comments on Greg Ferro's blog:
http://etherealmind.com/network-dictionary-mythinformation/

Lately he followed up with details:
http://etherealmind.com/ethernet-autonegotiation-works-why-how-standard-sh
ould-be-set/

There *is* some stuff around here that doesn't auto-neg properly--100% old
scada-related gear.

~JasonG

___
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] Ethernet Interfaces Speed and Duplex - Force or Auto

[Kaegler, Mike]

FWIW, the following is an old email I sent to our internal IT list last
year reinforcing our current practice of auto/auto on all ports except
where autoneg is proven to fail.
It's a bit of historical review of reasons to hard-set.

~ Begin ~

>> Why did we continue to use 100/full?"

Social inertia.

Back in the day (1995) when FastEthernet was new, not all the
manufacturers had their... stuff... together. 802.3u (autoneg) had been
written, and everyone started working to build hardware on it. Most
manufacturers interpreted the standard one way... predictably cisco (and
a few others) interpreted it another. Cue surprised face. Disparate
hardware would not autonegotiate, or if the hardware was smart enough to
handle the different autonegotiation methods, it would be stupid enough
to do so unreliably.
Network admins, burned, disabled autonegotiation.

The vendor disagreements were settled in 1998. 802.3 was released.
In 1999, the current 802.3ab was released, to support gigabit and some
extra code pages.

Its 2009, a decade later. Well, for some of the network equipment we
run, its 4 years later. Anyway. The reasons to disable autoneg have been
dead for a very long time. In my entire career, I have only seen it fail
spectacularly once, oddly enough on a packeteer when it failed and
closed the relay to connect its in and out ports.

So the advantage is never having this problem.
The disadvantage is the theoretical possibility of having a suboptimum
link speed if the ethernet firmware on the server side doesn't strobe
correctly to signal capabilities and noone notices.

No vendors currently recommend disabling autoneg.
-porkchop


~ End ~

___
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] Ethernet Interfaces Speed and Duplex - Force or Auto

[Anton Kapela]

On May 21, 2010, at 1:37 PM, Rubens Kuhl wrote:

> systems and some switch brands allow this, but since this is a Cisco
> list I haven't found Cisco gear that allow this, so far.

I've found that:

-2900xl
-3500xl
-3550

...will *continue* to participate in ANEG (and this can be seen in link-beat 
offered options), but can be *forced* to only offer/operate in specific modes. 
I.e. 100/fdx, or 10 mbit hdx/fdx. 

Looks like 65xx and 67xx linecards require one to 'force' speed if they wish to 
also force duplex, implying that ANEG is not exchanged/spoken by ports that are 
manually-set. 

-Tk


___
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] Ethernet Interfaces Speed and Duplex - Force or Auto

[Rubens Kuhl]

Wherever possible I leave autoneg on but try to configure capabilities
to advertise only 100 (or 1000 or 100+1000) Full-Duplex. Operating
systems and some switch brands allow this, but since this is a Cisco
list I haven't found Cisco gear that allow this, so far.


Rubens


On Thu, May 20, 2010 at 4:18 PM, Jeff Wojciechowski
 wrote:
> All:
>
> Curious what other network admins are doing out there for Ethernet interfaces 
> as far as speed and duplex settings - weather to specify or to leave them 
> auto negotiate.
>
> The reason I am asking is we just installed some equipment in a new data 
> center we are in the process of bringing online for redundancy and the switch 
> ports on the network switch at the new location are set to 100/full while the 
> switch this equipment was built and tested on in our main facility was set to 
> auto/auto.
>
> Since equipment was moved to the new location I have been taking CRC errors 
> on almost all active network ports that this equipment is plugged into yet 
> the 3 months or so this system was in the other location with speed 
> auto/duplex auto, we had none. I tried swapping out the network switch but I 
> am still taking errors at about the same rate.
>
> Show int of port with most errors (WS-C3560-24TS)
>
> FastEthernet0/3 is up, line protocol is up (connected)
>  Hardware is Fast Ethernet, address is 001c.0f21.d085 (bia 001c.0f21.d085)
>  MTU 1500 bytes, BW 10 Kbit, DLY 100 usec,
>     reliability 255/255, txload 1/255, rxload 1/255
>  Encapsulation ARPA, loopback not set
>  Keepalive set (10 sec)
>  Full-duplex, 100Mb/s, media type is 10/100BaseTX
>  input flow-control is off, output flow-control is unsupported
>  ARP type: ARPA, ARP Timeout 04:00:00
>  Last input never, output 00:00:01, output hang never
>  Last clearing of "show interface" counters 1d18h
>  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
>  Queueing strategy: fifo
>  Output queue: 0/0 (size/max)
>  5 minute input rate 2000 bits/sec, 3 packets/sec
>  5 minute output rate 3000 bits/sec, 4 packets/sec
>     533310 packets input, 64455460 bytes, 0 no buffer
>     Received 5227 broadcasts (0 multicasts)
>     0 runts, 0 giants, 0 throttles
>     150 input errors, 69 CRC, 0 frame, 0 overrun, 0 ignored
>     0 watchdog, 0 multicast, 0 pause input
>     0 input packets with dribble condition detected
>     556098 packets output, 59830579 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
>
> During non-production hours, I will be setting those ports to auto/auto to 
> see if the errors go away - but still curious what others are doing - and 
> does it depend on what sort of device is using a port such as a server, 
> router, another switch, pc, etc?
>
> Thanks again,
>
> Jeff Wojciechowski
> LAN, WAN and Telephony Administrator
> Midland Paper Company
> 101 E Palatine Rd
> Wheeling, IL 60090
> * tel: 847.777.2829
> Ê fax: 847.403.6829
> e-mail: 
> jeff.wojciechow...@midlandpaper.com
> http://www.midlandpaper.com
>
> ___
> 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/

Re: [c-nsp] Ethernet Interfaces Speed and Duplex - Force or Auto

[Drew Weaver]

I agree, setting the link speed can be more dangerous than not setting it, some 
hardware like Watchguard still has quirks when it comes to autoneg but it is 
mostly a solved issue.

-Drew


-Original Message-
From: cisco-nsp-boun...@puck.nether.net 
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Charles Mills
Sent: Friday, May 21, 2010 1:21 PM
To: Jeff Wojciechowski
Cc: g...@greenie.muc.de; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Ethernet Interfaces Speed and Duplex - Force or Auto

That's ok Jeff.

I remember 15+ years ago when the advent of switching came upon us
that with such an eclectic cache of network cards and manufacturers
thereof that nobody seemed to be able to "get it right".
Autonegotiation was a path to trouble especially on big networks and
we did the same thing.  Now...hardly ever get a duplex mismatch unless
the cabling is substandard or there are other physical layer problems.


On Fri, May 21, 2010 at 1:07 PM, Jeff Wojciechowski
 wrote:
> Gert-
>
> I have done most of my learning this century so I am still somewhat green - 
> hence my post - and I have learned much by picking the brains of vetrans.
>
> (If I had a penny for every queston I've asked LOL)
>
> Thanks,
>
> -Jeff
>
> Sent from Midland Paper Company's - BB Server
>
> - Original Message -
> From: Gert Doering 
> To: Jeff Wojciechowski
> Cc: cisco-nsp@puck.nether.net 
> Sent: Fri May 21 11:57:54 2010
> Subject: Re: [c-nsp] Ethernet Interfaces Speed and Duplex - Force or Auto
>
> Hi,
>
> On Thu, May 20, 2010 at 02:18:34PM -0500, Jeff Wojciechowski wrote:
>> Curious what other network admins are doing out there for Ethernet
>> interfaces as far as speed and duplex settings - weather to specify
>> or to leave them auto negotiate.
>
> Since this is 2010, we default to "auto".  The amount of gear that makes
> problems in funny ways has been much lower with "auto" than with fixed
> setting for the last decade or so...
>
> Of course there are exceptions, most notably the 7200 FE ports that just
> don't *do* autoneg.  So for those, of course, the other end needs to be
> configured to manual/100/full.  Some carriers also insist in running their
> equipment in fixed-config mode (and inevitably get it wrong for the first
> few configuration tries).
>
> Unfortunately, there's still lot of admin folks around that have learned
> in the last century that "autoneg just doesn't work", so they go around and
> configure everything for 100/full - and then someone swaps some other gear,
> defaults to auto, boom, duplex mismatch, packet loss, nastiness.
>
> (For GigE on fiber, autoneg is good because it provides unidirectional
> link detection right away, which is something you *want* - but that's
> a different can of worms)
>
> 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-35655025                        g...@net.informatik.tu-muenchen.de
>
> ___
> 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/

___
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] Ethernet Interfaces Speed and Duplex - Force or Auto

[Matlock, Kenneth L]

I agree with Gert. We have a guy here that until I beat it into his head
for the better part of 2 years, was absolutely convinced that printers
(even brand-new ones) would only work at 10/Half Finally got him to
see the 'light'

Ken Matlock
Network Analyst
Exempla Healthcare
(303) 467-4671
matlo...@exempla.org


-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Gert Doering
Sent: Friday, May 21, 2010 11:15 AM
To: Jeff Wojciechowski
Cc: 'g...@greenie.muc.de'; 'cisco-nsp@puck.nether.net'
Subject: Re: [c-nsp] Ethernet Interfaces Speed and Duplex - Force or
Auto

Hi,

On Fri, May 21, 2010 at 12:07:36PM -0500, Jeff Wojciechowski wrote:
> I have done most of my learning this century so I am still somewhat
> green - hence my post - and I have learned much by picking the
> brains of vetrans.

I wasn't trying to pick on you - sorry if it came across that way.

It's more a matter of personal annoyance at network admins that refuse
to acknowledge that devices change and problems evolve, and insist that
"the rules that we have learned last century are cast in stone and must
be followed to the end".  The auto-neg/no auto-neg discussion is very
prototypical for that :-)

(Nothing bad in "learning from experience and designing rules/BCPs from
there", but there must be room for adjustment and new experience every
few years...)

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-35655025
g...@net.informatik.tu-muenchen.de

___
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] Ethernet Interfaces Speed and Duplex - Force or Auto

[Jeff Wojciechowski]

No offense taken at all :o)

Just trying to soak up as much of the experience/gotchas/best 
practices/insight/etc that others have been through on this list and apply that 
to my environment.

-Jeff

-Original Message-
From: Gert Doering [mailto:g...@greenie.muc.de] 
Sent: Friday, May 21, 2010 12:15 PM
To: Jeff Wojciechowski
Cc: 'g...@greenie.muc.de'; 'cisco-nsp@puck.nether.net'
Subject: Re: [c-nsp] Ethernet Interfaces Speed and Duplex - Force or Auto

Hi,

On Fri, May 21, 2010 at 12:07:36PM -0500, Jeff Wojciechowski wrote:
> I have done most of my learning this century so I am still somewhat 
> green - hence my post - and I have learned much by picking the brains 
> of vetrans.

I wasn't trying to pick on you - sorry if it came across that way.

It's more a matter of personal annoyance at network admins that refuse to 
acknowledge that devices change and problems evolve, and insist that "the rules 
that we have learned last century are cast in stone and must be followed to the 
end".  The auto-neg/no auto-neg discussion is very prototypical for that :-)

(Nothing bad in "learning from experience and designing rules/BCPs from there", 
but there must be room for adjustment and new experience every few years...)

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

___
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] Ethernet Interfaces Speed and Duplex - Force or Auto

[Charles Mills]

That's ok Jeff.

I remember 15+ years ago when the advent of switching came upon us
that with such an eclectic cache of network cards and manufacturers
thereof that nobody seemed to be able to "get it right".
Autonegotiation was a path to trouble especially on big networks and
we did the same thing.  Now...hardly ever get a duplex mismatch unless
the cabling is substandard or there are other physical layer problems.


On Fri, May 21, 2010 at 1:07 PM, Jeff Wojciechowski
 wrote:
> Gert-
>
> I have done most of my learning this century so I am still somewhat green - 
> hence my post - and I have learned much by picking the brains of vetrans.
>
> (If I had a penny for every queston I've asked LOL)
>
> Thanks,
>
> -Jeff
>
> Sent from Midland Paper Company's - BB Server
>
> - Original Message -
> From: Gert Doering 
> To: Jeff Wojciechowski
> Cc: cisco-nsp@puck.nether.net 
> Sent: Fri May 21 11:57:54 2010
> Subject: Re: [c-nsp] Ethernet Interfaces Speed and Duplex - Force or Auto
>
> Hi,
>
> On Thu, May 20, 2010 at 02:18:34PM -0500, Jeff Wojciechowski wrote:
>> Curious what other network admins are doing out there for Ethernet
>> interfaces as far as speed and duplex settings - weather to specify
>> or to leave them auto negotiate.
>
> Since this is 2010, we default to "auto".  The amount of gear that makes
> problems in funny ways has been much lower with "auto" than with fixed
> setting for the last decade or so...
>
> Of course there are exceptions, most notably the 7200 FE ports that just
> don't *do* autoneg.  So for those, of course, the other end needs to be
> configured to manual/100/full.  Some carriers also insist in running their
> equipment in fixed-config mode (and inevitably get it wrong for the first
> few configuration tries).
>
> Unfortunately, there's still lot of admin folks around that have learned
> in the last century that "autoneg just doesn't work", so they go around and
> configure everything for 100/full - and then someone swaps some other gear,
> defaults to auto, boom, duplex mismatch, packet loss, nastiness.
>
> (For GigE on fiber, autoneg is good because it provides unidirectional
> link detection right away, which is something you *want* - but that's
> a different can of worms)
>
> 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-35655025                        g...@net.informatik.tu-muenchen.de
>
> ___
> 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/

Re: [c-nsp] Ethernet Interfaces Speed and Duplex - Force or Auto

[Gert Doering]

Hi,

On Fri, May 21, 2010 at 12:07:36PM -0500, Jeff Wojciechowski wrote:
> I have done most of my learning this century so I am still somewhat
> green - hence my post - and I have learned much by picking the
> brains of vetrans.

I wasn't trying to pick on you - sorry if it came across that way.

It's more a matter of personal annoyance at network admins that refuse
to acknowledge that devices change and problems evolve, and insist that
"the rules that we have learned last century are cast in stone and must
be followed to the end".  The auto-neg/no auto-neg discussion is very
prototypical for that :-)

(Nothing bad in "learning from experience and designing rules/BCPs from
there", but there must be room for adjustment and new experience every
few years...)

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


pgpuBJvFAEKi2.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] Ethernet Interfaces Speed and Duplex - Force or Auto

[Jeff Wojciechowski]

Gert-

I have done most of my learning this century so I am still somewhat green - 
hence my post - and I have learned much by picking the brains of vetrans.

(If I had a penny for every queston I've asked LOL)

Thanks,

-Jeff 

Sent from Midland Paper Company's - BB Server

- Original Message -
From: Gert Doering 
To: Jeff Wojciechowski
Cc: cisco-nsp@puck.nether.net 
Sent: Fri May 21 11:57:54 2010
Subject: Re: [c-nsp] Ethernet Interfaces Speed and Duplex - Force or Auto

Hi,

On Thu, May 20, 2010 at 02:18:34PM -0500, Jeff Wojciechowski wrote:
> Curious what other network admins are doing out there for Ethernet
> interfaces as far as speed and duplex settings - weather to specify
> or to leave them auto negotiate.

Since this is 2010, we default to "auto".  The amount of gear that makes
problems in funny ways has been much lower with "auto" than with fixed 
setting for the last decade or so...

Of course there are exceptions, most notably the 7200 FE ports that just
don't *do* autoneg.  So for those, of course, the other end needs to be
configured to manual/100/full.  Some carriers also insist in running their
equipment in fixed-config mode (and inevitably get it wrong for the first
few configuration tries).

Unfortunately, there's still lot of admin folks around that have learned
in the last century that "autoneg just doesn't work", so they go around and
configure everything for 100/full - and then someone swaps some other gear,
defaults to auto, boom, duplex mismatch, packet loss, nastiness. 

(For GigE on fiber, autoneg is good because it provides unidirectional
link detection right away, which is something you *want* - but that's
a different can of worms)

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

___
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] Ethernet Interfaces Speed and Duplex - Force or Auto

[Gert Doering]

Hi,

On Thu, May 20, 2010 at 02:18:34PM -0500, Jeff Wojciechowski wrote:
> Curious what other network admins are doing out there for Ethernet
> interfaces as far as speed and duplex settings - weather to specify
> or to leave them auto negotiate.

Since this is 2010, we default to "auto".  The amount of gear that makes
problems in funny ways has been much lower with "auto" than with fixed 
setting for the last decade or so...

Of course there are exceptions, most notably the 7200 FE ports that just
don't *do* autoneg.  So for those, of course, the other end needs to be
configured to manual/100/full.  Some carriers also insist in running their
equipment in fixed-config mode (and inevitably get it wrong for the first
few configuration tries).

Unfortunately, there's still lot of admin folks around that have learned
in the last century that "autoneg just doesn't work", so they go around and
configure everything for 100/full - and then someone swaps some other gear,
defaults to auto, boom, duplex mismatch, packet loss, nastiness. 

(For GigE on fiber, autoneg is good because it provides unidirectional
link detection right away, which is something you *want* - but that's
a different can of worms)

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


pgpUc2bHl9SAC.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] Ethernet Interfaces Speed and Duplex - Force or Auto

[Chris Burwell]

We leave things set to auto as well. We dabbled with hard-coding the
speed and duplex after a network overhaul on one of our buildings. The
down side was that we still have some "legacy" equipment which
required 10/Half while the rest of our equipment was 100 or 1000/Full.

In the end we determined that it would just be too much work to track
down these legacy device and change the port settings for each one.
With six buildings and one network admin (me) we did not see the
benefits to hard-coding port speeds.

It's good to know that I can take one device and plug it into any
other port on the network without having to dive into the switch and
make changes to the speed and duplex settings.

- Chris
___
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] confed as-path length preservatopm

[Tim Durack]

On Fri, May 21, 2010 at 10:55 AM, David Freedman
 wrote:
> Not that I know of, you should really be using MED for this kind of
> inter-subconfederation BGP TE, but if you must use the path, you can
> always count it on ingress (and then set attributes based on it),
> i.e:
>
> ip as-path access-list X permit \([0-9]+\)
>
> (this will match one subconfederation traversed)

I eventually came up with this:

ip as-path access-list CONFED-0 permit ^$
ip as-path access-list CONFED-1 permit ^\((65[0-9]+\ ?){1}\)$
ip as-path access-list CONFED-2 permit ^\((65[0-9]+\ ?){2}\)$
ip as-path access-list CONFED-3 permit ^\((65[0-9]+\ ?){3}\)$
ip as-path access-list CONFED-4 permit ^\((65[0-9]+\ ?){4}\)$
ip as-path access-list CONFED-5 permit ^\((65[0-9]+\ ?){5}\)$
ip as-path access-list LOCAL permit ^$

route-map CORE-OUT permit 5
 match as-path LOCAL
!
route-map CORE-OUT permit 10
 match as-path CONFED-1
 set as-path prepend 
!
route-map CORE-OUT permit 20
 match as-path CONFED-2
 set as-path prepend  
!
route-map CORE-OUT permit 30
 match as-path CONFED-3
 set as-path prepend   
!
route-map CORE-OUT permit 40
 match as-path CONFED-4
 set as-path prepend
!
route-map CORE-OUT permit 50
 match as-path CONFED-5
 set as-path prepend 
!

Seems to work okay.

-- 
Tim:>
___
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] confed as-path length preservatopm

[David Freedman]

Tim Durack wrote:
> Is there anyway to route-map convert confed as-path into a normal
> as-path? I'm trying to preserve as-path length outside a confed (this
> is actually for a private VPN using BGP, not the Internet.)
> 
> I'm looking for something like:
> 
> (65001 65002 65003) -> ASn ASn ASn
> 
> Creative ideas are welcomed!

Not that I know of, you should really be using MED for this kind of
inter-subconfederation BGP TE, but if you must use the path, you can
always count it on ingress (and then set attributes based on it),
i.e:

ip as-path access-list X permit \([0-9]+\)

(this will match one subconfederation traversed)


-- 


David Freedman
Group Network Engineering
Claranet Group

___
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] 6509 Auto Qos

[Chris Lane]

Thats interesting. I just tried it and it failed.
What line cards do you have?
What IOS
Thanks for your input.

On Fri, May 21, 2010 at 9:45 AM, Florin Florian wrote:

> Hi Chris,
>
> I got the same problem couple of weeks ago. I wasn't able to apply AutoQoS
> on the interface and I reverse the proccess. It means I create the AutoQoS
> on the lab (emtpy SW configuration) and I applied on production. What I did
> was just to apply (copy/paste) the config on the global config and after
> that I was able to configure my interfaces for AutoQoS.
>
> I'm running AutoQoS on Cisco 4506 with Sup6E
>
> interface GigabitEthernet2/3
>  service-policy output AutoQos-VoIP-Output-Policy-queue-only
>
> interface Port-channel12
>  service-policy input AutoQos-VoIP-Input-Cos-Policy
>   service-policy output AutoQos-VoIP-Output-Policy-non-queue
>
> class-map match-all AutoQos-VoIP-Bearer-Cos
>  match cos  5
> class-map match-all AutoQos-VoIP-Control-QosGroup24
>  match qos-group 24
> class-map match-all AutoQos-VoIP-Control-QosGroup26
>  match qos-group 26
> class-map match-all AutoQos-VoIP-Bearer-QosGroup
>  match qos-group 46
> class-map match-all AutoQos-VoIP-Control-Cos
>  match cos  3
> !
> !
> policy-map AutoQos-VoIP-Output-Policy-queue-only
>  class AutoQos-VoIP-Bearer-QosGroup
> priority
>  class AutoQos-VoIP-Control-QosGroup26
> bandwidth remaining percent 5
>  class AutoQos-VoIP-Control-QosGroup24
> bandwidth remaining percent 5
>  class class-default
> dbl
> policy-map AutoQos-VoIP-Input-Cos-Policy
>  class AutoQos-VoIP-Bearer-Cos
>   set qos-group 46
>  class AutoQos-VoIP-Control-Cos
>   set qos-group 24
> policy-map AutoQos-VoIP-Output-Policy-non-queue
>  class AutoQos-VoIP-Bearer-QosGroup
>   set dscp ef
>   set cos 5
> police cir 6
>  class AutoQos-VoIP-Control-QosGroup26
>   set dscp af31
>   set cos 3
>  class AutoQos-VoIP-Control-QosGroup24
>   set dscp cs3
>   set cos 3
>
> I hope that help.
>
> fflorin
>
> On Thu, May 20, 2010 at 1:53 PM, Chris Lane  wrote:
>
>> All,
>> I need to run Auto QoS for a Cisco soft phone on a 6509 running IOS
>> 122-33.SXH1
>> according to the cisco docs this feature was released with this train and
>> later.
>> i believe its my line cards which are:
>> 1   48  48-port 10/100 mb RJ45 WS-X6148-45AF
>>  SAL085281YQ
>>  2   48  48 port 10/100 mb RJ45 WS-X6348-RJ-45
>> SAL0540CQA4
>>  3   48  48-port 10/100 mb RJ45 WS-X6148-RJ45V
>> SAL06499J4Q
>>  4   48  48-port 10/100 mb RJ45 WS-X6148-RJ45V
>> SAL0750QMGV
>>
>> and i have a Sup720/3bxl
>>
>> any help would greatly be appreciated.
>>
>> Regards,
>>
>> --
>> //CL
>>   ___
>> 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/
>>
>>
>


-- 
//CL
___
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] 6509 Auto Qos

[Florin Florian]

Hi Chris,

I got the same problem couple of weeks ago. I wasn't able to apply AutoQoS
on the interface and I reverse the proccess. It means I create the AutoQoS
on the lab (emtpy SW configuration) and I applied on production. What I did
was just to apply (copy/paste) the config on the global config and after
that I was able to configure my interfaces for AutoQoS.

I'm running AutoQoS on Cisco 4506 with Sup6E

interface GigabitEthernet2/3
 service-policy output AutoQos-VoIP-Output-Policy-queue-only

interface Port-channel12
 service-policy input AutoQos-VoIP-Input-Cos-Policy
  service-policy output AutoQos-VoIP-Output-Policy-non-queue

class-map match-all AutoQos-VoIP-Bearer-Cos
 match cos  5
class-map match-all AutoQos-VoIP-Control-QosGroup24
 match qos-group 24
class-map match-all AutoQos-VoIP-Control-QosGroup26
 match qos-group 26
class-map match-all AutoQos-VoIP-Bearer-QosGroup
 match qos-group 46
class-map match-all AutoQos-VoIP-Control-Cos
 match cos  3
!
!
policy-map AutoQos-VoIP-Output-Policy-queue-only
 class AutoQos-VoIP-Bearer-QosGroup
priority
 class AutoQos-VoIP-Control-QosGroup26
bandwidth remaining percent 5
 class AutoQos-VoIP-Control-QosGroup24
bandwidth remaining percent 5
 class class-default
dbl
policy-map AutoQos-VoIP-Input-Cos-Policy
 class AutoQos-VoIP-Bearer-Cos
  set qos-group 46
 class AutoQos-VoIP-Control-Cos
  set qos-group 24
policy-map AutoQos-VoIP-Output-Policy-non-queue
 class AutoQos-VoIP-Bearer-QosGroup
  set dscp ef
  set cos 5
police cir 6
 class AutoQos-VoIP-Control-QosGroup26
  set dscp af31
  set cos 3
 class AutoQos-VoIP-Control-QosGroup24
  set dscp cs3
  set cos 3

I hope that help.

fflorin

On Thu, May 20, 2010 at 1:53 PM, Chris Lane  wrote:

> All,
> I need to run Auto QoS for a Cisco soft phone on a 6509 running IOS
> 122-33.SXH1
> according to the cisco docs this feature was released with this train and
> later.
> i believe its my line cards which are:
> 1   48  48-port 10/100 mb RJ45 WS-X6148-45AF
>  SAL085281YQ
>  2   48  48 port 10/100 mb RJ45 WS-X6348-RJ-45
> SAL0540CQA4
>  3   48  48-port 10/100 mb RJ45 WS-X6148-RJ45V
> SAL06499J4Q
>  4   48  48-port 10/100 mb RJ45 WS-X6148-RJ45V
> SAL0750QMGV
>
> and i have a Sup720/3bxl
>
> any help would greatly be appreciated.
>
> Regards,
>
> --
> //CL
>  ___
> 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] confed as-path length preservatopm

[Tim Durack]

Is there anyway to route-map convert confed as-path into a normal
as-path? I'm trying to preserve as-path length outside a confed (this
is actually for a private VPN using BGP, not the Internet.)

I'm looking for something like:

(65001 65002 65003) -> ASn ASn ASn

Creative ideas are welcomed!
-- 
Tim:>
___
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] Server Load Balancer - Cisco vs Brocade vs F5

[tkapela]

(Plug) ...You can't forget about gf-slb:

http://www.nanog.org/meetings/nanog41/presentations/Kapela-lightning.pdf

Some LB tasks are simply "perfect" workloads for ecmp and a few server 
boxes...also note IP SLA + tracked objects + IOS embeded event manager can do 
far more than I show in these slides.

In short, your LB task might not require dedicated hardware.

-Tk

-Original Message-
From: scott owens 
Date: Fri, 21 May 2010 07:30:25 
To: 
Subject: [c-nsp] Server Load Balancer - Cisco vs Brocade vs F5

Not knowing what the intended traffic type is -
you left out Barracuda and NetScalers which perform great and are at
opposite ends of the financial spectrum.

Don't just look at the 3 you mentioned.



> Message: 1
> Date: Tue, 18 May 2010 22:42:44 +
> From: Felix Nkansah 
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] Server Load Balancer - Cisco vs Brocade vs F5
> Message-ID:
>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi All,
>
> I deployed a number of Cisco CSS load balancers for a client, about 2 years
> ago.
>
> However, they tell me today that they are unhappy with the product and are
> considering non-Cisco alternatives for their new projects.
>
> Interestingly, all they say is that they have "issues" with Cisco CSS; I
> don't know what those problems are.
>
> They are considering either of F5 BIG-IP Local Traffic Manager or Brocade
> ServerIron ADX platforms for their new server load-balancing needs.
>
> I was wondering if any of you have praises for the F5 and/or Brocade
> load-balancing offerings?
>
> Thanks.
>
>
>
___
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] Server Load Balancer - Cisco vs Brocade vs F5

[scott owens]

Not knowing what the intended traffic type is -
you left out Barracuda and NetScalers which perform great and are at
opposite ends of the financial spectrum.

Don't just look at the 3 you mentioned.



> Message: 1
> Date: Tue, 18 May 2010 22:42:44 +
> From: Felix Nkansah 
> To: cisco-nsp@puck.nether.net
> Subject: [c-nsp] Server Load Balancer - Cisco vs Brocade vs F5
> Message-ID:
>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi All,
>
> I deployed a number of Cisco CSS load balancers for a client, about 2 years
> ago.
>
> However, they tell me today that they are unhappy with the product and are
> considering non-Cisco alternatives for their new projects.
>
> Interestingly, all they say is that they have "issues" with Cisco CSS; I
> don't know what those problems are.
>
> They are considering either of F5 BIG-IP Local Traffic Manager or Brocade
> ServerIron ADX platforms for their new server load-balancing needs.
>
> I was wondering if any of you have praises for the F5 and/or Brocade
> load-balancing offerings?
>
> Thanks.
>
>
>
___
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] MRTG

[David Freedman]

Mark Wheadon wrote:
> I am in the process of restricting SNMP access into our CPE.  Does
> anyone know what specific OID's as a minimum MRTG will need to be able
> to add a Cisco ISR device ( I am trying to avoid doing a debug).
> 
Not quite sure what you mean by "minimum MRTG", you could start by only
allowing mib-2 and if you are concerned about routing table being
scraped, just move down to ifMib.

Dave.


> 
> ___
> 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/
> 


-- 


David Freedman
Group Network Engineering
Claranet Group

___
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] Ethernet Interfaces Speed and Duplex - Force or Auto

[Jeff Wojciechowski]

Thanks all for the great info and suggestions.

I set the interfaces to auto/auto and there were *almost* no errors overnight.

-Jeff

-Original Message-
From: cisco-nsp-boun...@puck.nether.net 
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Pshem Kowalczyk
Sent: Thursday, May 20, 2010 5:01 PM
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Ethernet Interfaces Speed and Duplex - Force or Auto

Hi

On 21 May 2010 07:18, Jeff Wojciechowski  
wrote:
> All:
>
> Curious what other network admins are doing out there for Ethernet interfaces 
> as far as speed and duplex settings - weather to specify or to leave them 
> auto negotiate.

{cut}

We always set the port speed and duplex, only if the other side doesn't support 
that (for example unmanaged media converters) we leave it to auto. We had cases 
in the past where devices got reloaded and when came back didn't negotiate 
properly (most often stuck in half-duplex). Those issues are sometimes quite 
difficult to spot. So we settled on hard settings.

kind regards
Pshem
___
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] 6509 Auto Qos

[Chris Lane]

Thank you Peter, problem i don't have the option to use Auto Qos on
interface, which i believe to be a line card issue or Ios.
still trying to determine.
Regards,
Chris

On Thu, May 20, 2010 at 6:07 PM, Peter Rathlev  wrote:

> On Thu, 2010-05-20 at 13:53 -0400, Chris Lane wrote:
> > I need to run Auto QoS for a Cisco soft phone on a 6509 running IOS
> > 122-33.SXH1
> [...]
> > any help would greatly be appreciated.
>
> Auto-QoS is not always a very good way of doing QoS, but at least it's
> very easy. On SXI it's something like:
>
> Switch(config)# do show run int gi4/24
> Building configuration...
>
> Current configuration : 62 bytes
> !
> interface GigabitEthernet4/24
>  no ip address
>  shutdown
> end
>
> Switch(config)# interface gi4/24
> Switch(config-if)# switchport
> Switch(config-if)# auto qos voip cisco-phone
> (loads of messages)
> Switch(config-if)#
> Switch(config-if)# do show run int gi4/24
> Building configuration...
>
> Current configuration : 931 bytes
> !
> interface GigabitEthernet4/24
>  switchport
>  shutdown
>  wrr-queue bandwidth 20 100 200
>  priority-queue queue-limit 5
>  wrr-queue queue-limit 65 15 15
>  wrr-queue random-detect min-threshold 1 70 100 100 100 100 100 100 100
>  wrr-queue random-detect min-threshold 2 70 100 100 100 100 100 100 100
>  wrr-queue random-detect min-threshold 3 40 40 50 50 60 60 70 70
>  wrr-queue random-detect max-threshold 1 100 100 100 100 100 100 100 100
>  wrr-queue random-detect max-threshold 2 100 100 100 100 100 100 100 100
>  wrr-queue random-detect max-threshold 3 70 70 80 80 90 90 100 100
>  wrr-queue cos-map 2 1 1 2
>  wrr-queue cos-map 3 5 3 4
>  wrr-queue cos-map 3 7 6 7
>  rcv-queue cos-map 1 2 1
>  rcv-queue cos-map 1 3 2
>  rcv-queue cos-map 1 4 3
>  rcv-queue cos-map 1 5 4
>  rcv-queue cos-map 1 6 5
>  rcv-queue cos-map 1 7 6
>  rcv-queue cos-map 1 8 7
>  mls qos trust device cisco-phone
>  mls qos trust cos
>  auto qos voip cisco-phone
> end
>
> Switch(config)#
>
> Please test this in a lab first, and verify that the configuration suits
> your needs. And be aware that there are a lot of considerations
> regarding port-groups and QoS on neighboring ports.
>
> --
> Peter
>
>
>


-- 
//CL
___
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] MRTG

[Mark Wheadon]

I am in the process of restricting SNMP access into our CPE.  Does 
anyone know what specific OID's as a minimum MRTG will need to be able 
to add a Cisco ISR device ( I am trying to avoid doing a debug).



___
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/