Re: [c-nsp] 6509 console access problem

[Ben Hammadi, Kayssar (NSN - TN/Tunis)]

Yes : 

line con 0
 exec-timeout 5 0

but it reach a week until know and I am enable to access the router console 
neither to make a wr : 

TSA3-PACOSWA9002#show  startup-config 
Using 114367 out of 1964024 bytes
%Error opening nvram:/startup-config (Device or resource busy)
TSA3-PACOSWA9002#
TSA3-PACOSWA9002#wr
startup-config file open failed (Device or resource busy)


BEN HAMMADI Kayssar
 
NOKIA SIEMENS NETWORKS
Lead Engineer -BroadBand Connectivity
JNCIE-M (#471), JNCIE-SP (#1147), CCIP 
Mobile : +216 29 349 952  /  +216 98 349 952
FIX  : +216 71 108 173
Skype : kayssar ben hammadi
kayssar.ben_hamm...@nsn.com

-Original Message-
From: ext Tiago Hirao [mailto:tiago.hi...@locaweb.com.br] 
Sent: Wednesday, November 13, 2013 11:55 AM
To: Ben Hammadi, Kayssar (NSN - TN/Tunis); 
Subject: RES: [c-nsp] 6509 console access problem

Do you have configured "exec-timeout" on "line con 0" ?



De: cisco-nsp [cisco-nsp-boun...@puck.nether.net] em nome de Ben Hammadi, 
Kayssar (NSN - TN/Tunis) [kayssar.ben_hamm...@nsn.com]
Enviado: quarta-feira, 13 de novembro de 2013 6:01
Para: 
Assunto: Re: [c-nsp] 6509 console access problem

  Dears ,

   I have no console access on my 6509 , I see I have an idle console 
connection but I am eable to clear it , "neither clear line"  nor "clear line 
console"  solve the problem

SWA#show users
Line   User   Host(s)  Idle   Location
   0 con 0idle6d21h
*  1 vty 0 hbib.sahn  idle 00:00:00 10.203.9.141


SWA#clear line 0
[confirm]
 [OK]

SWA #show  users
Line   User   Host(s)  Idle   Location
   0 con 0idle6d21h
*  1 vty 0 hbib.sahn  idle 00:00:00 10.203.9.141

SWA #clear line console 0
[confirm]
 [OK]

SWA #show  users
Line   User   Host(s)  Idle   Location
   0 con 0idle6d21h
*  1 vty 0 hbib.sahn  idle 00:00:00 10.203.9.141


 Any idea?

Br.

BEN HAMMADI Kayssar

NOKIA SIEMENS NETWORKS
Lead Engineer -BroadBand Connectivity
JNCIE-M (#471), JNCIE-SP (#1147), CCIP



___
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] How to prevent https facebook from the cisco router 1841

[Hari bamsha Sapkota]

HTTPs inspection is not supported by the c1841 but it works well for
insecure connection.


On Thu, Nov 14, 2013 at 9:53 AM, Curtis LaMasters  wrote:

> This is the best option I have found for needs in the past.
> https://supportforums.cisco.com/docs/DOC-23236
>
> Curtis LaMasters
> http://www.curtis-lamasters.com
> http://www.builtnetworks.com
>
>
> On Wed, Nov 13, 2013 at 9:58 PM, mohamed nagy  >wrote:
>
> > Hello ,
> >
> > i need to prevent users to open Facebook https traffic from my router
> cisco
> > 1841
> >
> > i can put it as ip but is there any thing else because the ip way not
> > efficient
> >
> > What is the best scenario for that ??
> > ___
> > 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/

Re: [c-nsp] How to prevent https facebook from the cisco router 1841

[Kirill Bychkov]

In the comments to Curtis link:
"HI, i used that config and it worked well, but if you want to block a
website that the addreses starts with "HTTPS"  (secure) does't block them..
do you have a solution for that?"
For block HTTPS use proxy with your PKI, because HTTPS packet with URL from
USER to SERVER must be decrypted.


On 14 November 2013 08:08, Curtis LaMasters wrote:

> This is the best option I have found for needs in the past.
> https://supportforums.cisco.com/docs/DOC-23236
>
> Curtis LaMasters
> http://www.curtis-lamasters.com
> http://www.builtnetworks.com
>
>
> On Wed, Nov 13, 2013 at 9:58 PM, mohamed nagy  >wrote:
>
> > Hello ,
> >
> > i need to prevent users to open Facebook https traffic from my router
> cisco
> > 1841
> >
> > i can put it as ip but is there any thing else because the ip way not
> > efficient
> >
> > What is the best scenario for that ??
> > ___
> > 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/

Re: [c-nsp] How to prevent https facebook from the cisco router 1841

[Curtis LaMasters]

This is the best option I have found for needs in the past.
https://supportforums.cisco.com/docs/DOC-23236

Curtis LaMasters
http://www.curtis-lamasters.com
http://www.builtnetworks.com


On Wed, Nov 13, 2013 at 9:58 PM, mohamed nagy wrote:

> Hello ,
>
> i need to prevent users to open Facebook https traffic from my router cisco
> 1841
>
> i can put it as ip but is there any thing else because the ip way not
> efficient
>
> What is the best scenario for that ??
> ___
> 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] How to prevent https facebook from the cisco router 1841

[mohamed nagy]

Hello ,

i need to prevent users to open Facebook https traffic from my router cisco
1841

i can put it as ip but is there any thing else because the ip way not
efficient

What is the best scenario for that ??
___
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] ME3600 BFD session to A9K breaks after upgrade to 15.3(3)S1a

[Waris Sagheer (waris)]

Hi Jason,
I am working with engineering to figure out the issue. Can you please unicast 
me your configuration on both routers?

Best Regards,

[http://www.cisco.com/web/europe/images/email/signature/horizontal06.jpg]

Waris Sagheer
Technical Marketing Manager
Service Provider Access Group (SPAG)
wa...@cisco.com
Phone: +1 408 853 6682
Mobile: +1 408 835 1389

CCIE - 19901






This email may contain confidential and privileged material for the sole use of 
the intended recipient. Any review, use, distribution or disclosure by others 
is strictly prohibited. If you are not the intended recipient (or authorized to 
receive for the recipient), please contact the sender by reply email and delete 
all copies of this message.

For corporate legal information go 
to:http://www.cisco.com/web/about/doing_business/legal/cri/index.html



From: Jason Lixfeld mailto:ja...@lixfeld.ca>>
Date: Tuesday, November 12, 2013 11:09 AM
To: adam vitkovsky mailto:adam.vitkov...@swan.sk>>
Cc: "cisco-nsp@puck.nether.net" 
mailto:cisco-nsp@puck.nether.net>>
Subject: Re: [c-nsp] ME3600 BFD session to A9K breaks after upgrade to 
15.3(3)S1a

No, it's not the same, but it's not the same on a working interface either.

The 15.3(3)S1a ME3600 has a CLNS MTU of 9213.
The 15.3(3)S ME3600 has a CLNS MTU of 1497.
The 4.3.1 ASR9000 has a CLNS MTU of 9199.

15.3(3)S1a ME3600 is directly connected to the 15.3(3)S ME3600 and has an ISIS 
adjacency and BFD session.
The 15.3(3)S1a ME3600 is directly connected to the 4.3.1 ASR9K and does not 
have an ISIS adjacency or BFD session.

If it was a CLNS MTU issue, I'd suspect the 15.3(3)S1a and 15.3(3)S ME3600 ISIS 
and BFD session would be down as well, but it's not.

That notwithstanding, the BFD session between the 9K and 15.3(3)S1a ME3600 is 
down as well.  ISIS CLNS issue or not, that's not going to work unless BFD 
works, no?

On Nov 12, 2013, at 10:20 AM, Adam Vitkovsky 
mailto:adam.vitkov...@swan.sk>> wrote:

Hi Jason,
Is the CLNS MTU equal at both ends please?
It appears this is again one of the conditions to form ISIS session in
15.3(3)S1
adam


___
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] shaping > 128 mbps - asr9k

[Lukas Tribus]

Hi!


> Thanks. I'm trying to slow down ddos attacks that use legitimate udp ports,
> do I really want to police my friendly udp traffic right along with my
> attack udp traffic? The line of thinking that I was running with was to
> merely slow down the udp traffic, not drop it completely. Basically, I'm
> getting ddos udp attacks in the realm of 2 and 3 gbps up to 2 hours in
> duration. This is killing my distribution networks feed at 1 gbps rates. I
> wanted to slow down (shape) udp on an on-going basis, so as to slow down the
> momentary udp attacks. Thoughts?

You don't slow down DoS by input shaping it. You police it.

What advantage do you have from input shaping it? Your friendly and legitimate
udp traffic will be dropped anyway if the attack traffic saturates the shaper.

You really should police this traffic, there is no point in queueing attack
traffic.

And you should spend more time in trying to figure out differences between
attack and legitimate traffic, and then you can use different policiers
depending on the likelihood of the match being an attack (look at things
like dst/src ports, ip and udp checksums, payload length, etc). This has
helped us a lot with non-sophisticated attacks.

With the less sophisticated attacks, if there is a static attribute in the
packet that you can exploit to match the packet and drop it, then EEM and FPM
helps you (but thats a cat-and-mouse game).



> This is killing my distribution networks feed at 1 gbps rates.

In an broadband/PPP environment, you can use "Per Session Queuing and
Shaping" [1], it will then only saturate the attacked subscriber, not
your access/distribution network.


[1] 
http://www.cisco.com/en/US/docs/ios/bbdsl/configuration/guide/bba_ppoe_ses_q_rad.html



Regards,

Lukas 
___
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] shaping > 128 mbps - asr9k

[Aaron]

Thanks.  I'm trying to slow down ddos attacks that use legitimate udp ports,
do I really want to police my friendly udp traffic right along with my
attack udp traffic?  The line of thinking that I was running with was to
merely slow down the udp traffic, not drop it completely.  Basically, I'm
getting ddos udp attacks in the realm of 2 and 3 gbps up to 2 hours in
duration.  This is killing my distribution networks feed at 1 gbps rates.  I
wanted to slow down (shape) udp on an on-going basis, so as to slow down the
momentary udp attacks.  Thoughts?

Aaron

-Original Message-
From: Lars Eidsheim [mailto:l...@intellit.no] 
Sent: Wednesday, November 13, 2013 7:36 AM
To: Aaron; 'Oliver Boehmer (oboehmer)'; cisco-nsp@puck.nether.net
Subject: SV: [c-nsp] shaping > 128 mbps - asr9k

Do you need to use shaping? If not you can use a policer,

Example:

policy-map from-internet-child
 class udp-attack
  police rate 500 mbps
 !
 class class-default
 !
 end-policy-map

Mvh

Lars Eidsheim
iNTELLiT


-Opprinnelig melding-
Fra: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] På vegne av Aaron
Sendt: 12. november 2013 22:00
Til: 'Oliver Boehmer (oboehmer)'; cisco-nsp@puck.nether.net
Emne: Re: [c-nsp] shaping > 128 mbps - asr9k

policy-map from-internet-child
 class udp-attack
  shape average 600 mbps
 !
 class class-default
 !
 end-policy-map


-Original Message-
From: Aaron [mailto:aar...@gvtc.com]
Sent: Tuesday, November 12, 2013 2:58 PM
To: 'Oliver Boehmer (oboehmer)'; 'cisco-nsp@puck.nether.net'
Subject: RE: [c-nsp] shaping > 128 mbps - asr9k


(here's the uncommitted (failing) config... basically I want to shape
inbound UDP to 600 mbps.  please show me how to accomplish that.)

RP/0/RSP0/CPU0:eng-lab-9k-1(config-pmap-c)#show config

policy-map from-internet-parent
 class class-default
  service-policy from-internet-child
  shape average 1 gbps
 !
 end-policy-map
!
interface GigabitEthernet0/0/0/5
 service-policy input from-internet-parent !
end

RP/0/RSP0/CPU0:eng-lab-9k-1(config-pmap-c)#commi

% Failed to commit one or more configuration items during a pseudo-atomic
operation. All changes made have been reverted. Please issue 'show
configuration failed' from this session to view the errors

RP/0/RSP0/CPU0:eng-lab-9k-1(config-pmap-c)#show config failed

!! SEMANTIC ERRORS: This configuration was rejected by !! the system due to
semantic errors. The individual !! errors with each failed configuration
command can be !! found below.

interface GigabitEthernet0/0/0/5
 service-policy input from-internet-parent !!% 'prm_ezhal' detected the
'warning' condition 'Cannot support child/flat shape rate > 128Mbps'
!
end

RP/0/RSP0/CPU0:eng-lab-9k-1(config-pmap-c)#do sh run class-map

class-map match-all udp-attack
 match protocol udp
 end-class-map
!




-Original Message-
From: Oliver Boehmer (oboehmer) [mailto:oboeh...@cisco.com]
Sent: Tuesday, November 12, 2013 2:23 PM
To: Aaron; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] shaping > 128 mbps - asr9k



>Anyone know how to accomplish shaping traffic at a rate greater than
>128 mbps ?
>
>When I apply the policy-map/class-map to an interface it fails with 
>this message.
>
>'Cannot support child/flat shape rate > 128Mbps'

can you please share the configuration you are trying to apply, including
policy-maps and where you want to apply this?

oli

___
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 email has been scanned and secured by Intellit

This communication is for use by the intended recipient and contains
information that may be privileged, confidential and exempt from disclosure
or copyrighted under applicable law. If you are not the intended recipient,
you are hereby formally notified that any dissemination, use, copying or
distribution of this e-mail, in whole or in part, is strictly prohibited.
Please notify the sender by return e-mail and delete this e-mail from your
system.


___
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] FHRP selection within Nexus

[Gert Doering]

Hi,

On Wed, Nov 13, 2013 at 02:28:05PM -0500, Oliver Garraux wrote:
> HSRP is only active/active if you're using VPC on Nexus.  If VPC is being
> used both VPC peers will route traffic with a destination MAC of the HSRP
> virtual MAC (as well as their local MAC's).

OK, thanks.  This was not so clear to me from the quote provided.

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


pgpHT8QJXsZHC.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] FHRP selection within Nexus

[Phil Mayers]

On 13/11/2013 19:03, Gert Doering wrote:


If an ARP request coming from a server arrives on the secondary HSRP
device, it is forwarded to the active HSRP
device through the peer link.


"forwarding to the active HSRP device" and "only the active HSRP interface
answers ARP request" doesn't particularily sound "active-active" to me :-)

*This* is what happens on any 6500 that does HSRP on a SVI...


Dual-active HSRP on Nexus is where both devices will forward traffic 
destined to the HSRP vMAC. To actually make traffic for one vMAC reach 
both devices, it needs to come in via a vPC - what normal people call 
multi-chassis link-agg.


IIRC (rather weirdly) the master still does the all the ARP replies...

So yes, Nexus will do dual-active HSRP, but only with vPC I think, and 
as per my original email, vPC comes with a list of caveats that may, or 
may not, be acceptable in any given environment.


[For myself, the Nexus vPC implementation seems a bit fragile and 
hyper-specific about matching a lot parameters at both ends *just* 
right. If that's necessary, the box should do it for you, not make you 
do yet more typing]


It might be worth noting that, AIUI, Nexus will also do "local" 
forwarding of the HSRP vMAC on OTV (which seems to be VPLS with all the 
config hidden) using a similar mechanisms but OTV has even more caveats, 
and I know of people for whom it's gone rather wrong...


Local forwarding of FHRP is really not magic - just make all routers 
process IP traffic to the vMAC. I don't see why it fundamentally has to 
rely on vPC - and maybe it doesn't - since you could jiggle STP costs to 
make one Nexus forwarding for 1/2 switches and one for the other 1/2.

___
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] FHRP selection within Nexus

[Tim Stevenson]

At 11:03 AM 11/13/2013  Wednesday, Gert Doering pronounced:

Hi,

On Thu, Nov 14, 2013 at 05:51:15AM +1100, Andrew Miehs wrote:
> > How does that work?
> >
> > Have a read of
> 
http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9670/C07-572835-00_NX-OS_vPC_DG.pdf

> The bottom of page 24...
>
> HSRP
> The use of HSRP in the context of vPC does not require any special
> configuration. With vPC, only the active HSRP
> interface answers ARP requests, but both HSRP interfaces (active and
> standby) can forward traffic.
> If an ARP request coming from a server arrives on the secondary HSRP
> device, it is forwarded to the active HSRP
> device through the peer link.

"forwarding to the active HSRP device" and "only the active HSRP interface
answers ARP request" doesn't particularily sound "active-active" to me :-)



You're confusing "ARP" and "data packets".

ARP is handled by the control plane active; data packets are handled 
by either VPC peer.


Tim



*This* is what happens on any 6500 that does HSRP on a SVI...

GLBP is active-active in that both L3 routers will accept packets to the
world, instead of L2-forwarding them to the other one inside 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


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

Re: [c-nsp] FHRP selection within Nexus

[Oliver Garraux]

HSRP is only active/active if you're using VPC on Nexus.  If VPC is being
used both VPC peers will route traffic with a destination MAC of the HSRP
virtual MAC (as well as their local MAC's).

There is also a "peer gateway" feature with VPC, that allows both VPC peers
to route traffic going to the HSRP vMAC, its on local MAC, or the local MAC
of the VPC peer.  L3 traffic that one of the Nexus boxes forwards on to the
subnet has the router's local MAC for the SVI as the source.  Some poorly
behaved devices just reply straight to that local MAC rather than doing an
ARP to find the MAC of the default gateway.  The peer gateway feature is
needed to allow these broken devices to work when VPC is being used.

If you're not using VPC, HSRP on Nexus works just like it does on anything
else.

Oliver

-

Oliver Garraux
Check out my blog:  blog.garraux.net
Follow me on Twitter:  twitter.com/olivergarraux


On Wed, Nov 13, 2013 at 2:12 PM, Andrew Miehs  wrote:

> On Thu, Nov 14, 2013 at 6:03 AM, Gert Doering  wrote:
>
> >
> > "forwarding to the active HSRP device" and "only the active HSRP
> interface
> > answers ARP request" doesn't particularily sound "active-active" to me
> :-)
> >
> > *This* is what happens on any 6500 that does HSRP on a SVI...
> >
> > GLBP is active-active in that both L3 routers will accept packets to the
> > world, instead of L2-forwarding them to the other one inside the SVI.
> >
> >
> >
> Maybe I am missing something, but I understand the below text to indicate
> that both the primary and secondary HSRP peers will accept the packet to
> their "local" svi - rather than pushing it across the link...  (Continued
> on page 25)
>
> 
>
> The most significant difference between the HSRP implementation of a
> non-vPC configuration compared with a vPC
> configuration is that the HSRP MAC addresses of a vPC configuration are
> programmed with the G (gateway) flag on
> both systems, compared with a non-vPC configuration where only the active
> HSRP interface can program the MAC
> address with the G flag.
>
> Given this fact, routable traffic can be forwarded by both the vPC primary
> device (where HSRP is primary) and the
> vPC secondary device (where HSRP is secondary), with no need to send this
> traffic to the HSRP primary device.
> Without this flag, traffic sent to the MAC address would not be routed.
>
> 
> ___
> 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] FHRP selection within Nexus

[Andrew Miehs]

On Thu, Nov 14, 2013 at 6:03 AM, Gert Doering  wrote:

>
> "forwarding to the active HSRP device" and "only the active HSRP interface
> answers ARP request" doesn't particularily sound "active-active" to me :-)
>
> *This* is what happens on any 6500 that does HSRP on a SVI...
>
> GLBP is active-active in that both L3 routers will accept packets to the
> world, instead of L2-forwarding them to the other one inside the SVI.
>
>
>
Maybe I am missing something, but I understand the below text to indicate
that both the primary and secondary HSRP peers will accept the packet to
their "local" svi - rather than pushing it across the link...  (Continued
on page 25)



The most significant difference between the HSRP implementation of a
non-vPC configuration compared with a vPC
configuration is that the HSRP MAC addresses of a vPC configuration are
programmed with the G (gateway) flag on
both systems, compared with a non-vPC configuration where only the active
HSRP interface can program the MAC
address with the G flag.

Given this fact, routable traffic can be forwarded by both the vPC primary
device (where HSRP is primary) and the
vPC secondary device (where HSRP is secondary), with no need to send this
traffic to the HSRP primary device.
Without this flag, traffic sent to the MAC address would not be routed.


___
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] FHRP selection within Nexus

[Gert Doering]

Hi,

On Thu, Nov 14, 2013 at 05:51:15AM +1100, Andrew Miehs wrote:
> > How does that work?
> >
> > Have a read of
> http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9670/C07-572835-00_NX-OS_vPC_DG.pdf
> The bottom of page 24...
> 
> HSRP
> The use of HSRP in the context of vPC does not require any special
> configuration. With vPC, only the active HSRP
> interface answers ARP requests, but both HSRP interfaces (active and
> standby) can forward traffic.
> If an ARP request coming from a server arrives on the secondary HSRP
> device, it is forwarded to the active HSRP
> device through the peer link.

"forwarding to the active HSRP device" and "only the active HSRP interface
answers ARP request" doesn't particularily sound "active-active" to me :-)

*This* is what happens on any 6500 that does HSRP on a SVI...

GLBP is active-active in that both L3 routers will accept packets to the
world, instead of L2-forwarding them to the other one inside 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


pgpSiJ97Nek4O.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] FHRP selection within Nexus

[Andrew Miehs]

On Thu, Nov 14, 2013 at 5:41 AM, Gert Doering  wrote:

> Hi,
>
> On Thu, Nov 14, 2013 at 05:16:15AM +1100, Andrew Miehs wrote:
> > HSRP is dual active on the Nexus, so I would just go with that.
>
> How does that work?
>
> Have a read of
http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9670/C07-572835-00_NX-OS_vPC_DG.pdf
The bottom of page 24...

HSRP
The use of HSRP in the context of vPC does not require any special
configuration. With vPC, only the active HSRP
interface answers ARP requests, but both HSRP interfaces (active and
standby) can forward traffic.
If an ARP request coming from a server arrives on the secondary HSRP
device, it is forwarded to the active HSRP
device through the peer link.
___
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] FHRP selection within Nexus

[Gert Doering]

Hi,

On Thu, Nov 14, 2013 at 05:16:15AM +1100, Andrew Miehs wrote:
> HSRP is dual active on the Nexus, so I would just go with that.

How does that work?

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


pgptlnat7X_Fk.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] con0 and XRemote problem which ends with serious memory issues

[Antonio Soares]

Hello Team,

I found this old question since I am getting exactly the same problem. The
6500 is running 122-33.SXH8b.

Apart from the reboot or possibly from the Supervisor Switchover, anyone
knows who to solve this ?

It was the first time I heard about Cisco IOS running XRemote. I was able to
reproduce this in the lab with 12.2.18SFX17b.





Regards,

Antonio Soares, CCIE #18473 (R&S/SP)
amsoa...@netcabo.pt
http://www.ccie18473.net



-Original Message-
From: cisco-nsp-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Andy B.
Sent: quinta-feira, 12 de Maio de 2011 14:39
To: cisco-nsp@puck.nether.net
Subject: [c-nsp] con0 and XRemote problem which ends with serious memory
issues

Hi,

I'm facing an issue with a 6500 running SXI5 that eventually ends up eating
all memory and reload is the only way to solve it:

#who
Line   User   Host(s)  Idle   Location
   0 con 0XRemote: 24 clients  01:54:29


This box has been up for 12 hours, and the number of XRemote increases over
the day, while no console is attached to con 0.

I tried to clear line con 0 to no avail and then I also tried to identify
the TCB by using sh tcp brief and then clearing the TCB.

Here is an example:

5B09CF34  x.x.189.1.8000  x.218.199.147.2055  CLOSED

#sh tcp tcb 5B09CF34
Connection state is CLOSED, I/O status: 8, unread input bytes: 9 Mininum
incoming TTL 0, Outgoing TTL 255 Local host: x.x.189.1, Local port: 8000
Foreign host: x.218.199.147, Foreign port: 2055

Enqueued packets for retransmit: 0, input: 1  mis-ordered: 0 (0 bytes)

Event Timers (current time is 0x289A8DC):
Timer  StartsWakeupsNext
Retrans 1  0 0x0
TimeWait0  0 0x0
AckHold 1  1 0x0
SendWnd 0  0 0x0
KeepAlive   0  0 0x0
GiveUp  0  0 0x0
PmtuAger0  0 0x0
DeadWait1  0   0x291DA40

iss: 2341161453  snduna: 2341161454  sndnxt: 2341161454 sndwnd:  65535
irs: 1925376677  rcvnxt: 1925376687  rcvwnd:   4119  delrcvwnd:  0

SRTT: 52 ms, RTTO: 1968 ms, RTV: 1916 ms, KRTT: 0 ms
minRTT: 416 ms, maxRTT: 416 ms, ACK hold: 200 ms
Flags: passive open, higher precedence, retransmission timeout
  path mtu capable

Datagrams (max data segment is 1460 bytes):
Rcvd: 4 (out of order: 0), with data: 1, total data bytes: 9
Sent: 4 (retransmit: 0), with data: 0, total data bytes: 0


(Note that all those XRemote sessions seem to be on port 8000, but I cannot
explain why)

#clear tcp tcb 5B09CF34
[confirm]
 [OK]


It does not disappear from the list and I tried to clear it numerous times,
and eventually it disappeared.



Furthermore, while this goes on, this is spamming my logs:

May 12 15:32:05.660 CEST: %SYS-2-GETBUF: Bad getbuffer, bytes= -10 -Process=
"Exec", ipl= 0, pid= 119 -Traceback= 42377590 422007D0 422013A4 42200A60
42203984 4052E5B0 4233FCAC 4055C178 41392EC8 41392EB4 May 12 15:32:05.928
CEST: %SYS-2-GETBUF: Bad getbuffer, bytes= -10 -Process= "Exec", ipl= 0,
pid= 119 -Traceback= 42377590 422007D0 422013A4 42200A60 42203984 4052E5B0
4233FCAC 4055C178 41392EC8 41392EB4 May 12 15:32:06.180 CEST: %SYS-2-GETBUF:
Bad getbuffer, bytes= -10 -Process= "Exec", ipl= 0, pid= 119 -Traceback=
42377590 422007D0 422013A4 42200A60 42203984 4052E5B0 4233FCAC 4055C178
41392EC8 41392EB4 May 12 15:32:06.432 CEST: %SYS-2-GETBUF: Bad getbuffer,
bytes= -10 -Process= "Exec", ipl= 0, pid= 119 -Traceback= 42377590 422007D0
422013A4 42200A60 42203984 4052E5B0 4233FCAC 4055C178 41392EC8 41392EB4 May
12 15:32:06.684 CEST: %SYS-2-GETBUF: Bad getbuffer, bytes= -10 -Process=
"Exec", ipl= 0, pid= 119 -Traceback= 42377590 422007D0 422013A4 42200A60
42203984 4052E5B0 4233FCAC 4055C178 41392EC8 41392EB4 May 12 15:32:06.936
CEST: %SYS-2-GETBUF: Bad getbuffer, bytes= -10 -Process= "Exec", ipl= 0,
pid= 119 -Traceback= 42377590 422007D0 422013A4 42200A60 42203984 4052E5B0
4233FCAC 4055C178 41392EC8 41392EB4 May 12 15:32:07.200 CEST: %SYS-2-GETBUF:
Bad getbuffer, bytes= -10 -Process= "Exec", ipl= 0, pid= 119 -Traceback=
42377590 422007D0 422013A4 42200A60 42203984 4052E5B0 4233FCAC 4055C178
41392EC8 41392EB4



The main problem is that the number of XRemote sessions is going up to
128 and it is slowly eating up all available memory until it is all used up
and you are forced to reload. Last time this happened, memory was full in
roughly 6 weeks.

I have no service and no ACL using port 8000.

When I reload the box it's good for a while, and then it starts over again.


Has anyone seen this behaviour? How can this be solved without reloading
every once and a while?

Thanks.

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

Re: [c-nsp] FHRP selection within Nexus

[Andrew Miehs]

On Thu, Nov 14, 2013 at 4:22 AM, Phil Mayers wrote:

> On 13/11/13 17:07, Blake Pfankuch - Mailing List wrote:
>
>  I am weighing options between HSRP and GLBP knowing that GLBP is
>> Cisco only.  This environment will be Cisco only for the foreseeable
>>
>
> If you need the performance, use GLBP. Otherwise use HSRP, because it's
> marginally simpler and more common (therefore better tested).
>

HSRP is dual active on the Nexus, so I would just go with that.

Should you ever decide to buy another hardware platform, I would then
possibly reconsider the decision at that stage. This is really not that
hard to change.
___
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] fabricpath and vPC+

[quinn snyder]

http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9402/white_paper_c07-728188.pdf

take it with a grain of salt — as some of it is very marketecture related.

q.
--
quinn snyder
snyd...@gmail.com


On 13-Nov-13, at 10:23 , Arne Larsen / Region Nordjylland  wrote:

> Hi all
> 
> What is the correct setup when one is using fabricpath and vPC+
> If 2 5k are direct connected with 2 10G fabricpath interfaces, should these 2 
> be a channel group
> or doesn't it really matter, because of the equal cost routing in isis
> 
> /Arne
> 
> ___
> 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] fabricpath and vPC+

[James Slepicka (c-nsp)]

Use port channels.  In a FabricPath topology, loop-free trees are created to 
forward multidestination frames (broadcast, multicast, etc.).  If you use 
individual links between switches, only one of those links will be a part of 
the tree.  If you use port channels, the entire port channel will be used.

Additionally, though I doubt it matters in most deployments, with port channels 
you'll have 2-16x fewer ISIS adjacencies (reduced CPU utilization).

James

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Arne 
Larsen / Region Nordjylland
Sent: Wednesday, November 13, 2013 11:23 AM
To: 'cisco-nsp@puck.nether.net'
Subject: [c-nsp] fabricpath and vPC+

Hi all

What is the correct setup when one is using fabricpath and vPC+ If 2 5k are 
direct connected with 2 10G fabricpath interfaces, should these 2 be a channel 
group or doesn't it really matter, because of the equal cost routing in isis

/Arne

___
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] fabricpath and vPC+

[Tim Stevenson]

At 09:23 AM 11/13/2013  Wednesday, Arne Larsen  / Region Nordjylland quipped:

Hi all

What is the correct setup when one is using fabricpath and vPC+
If 2 5k are direct connected with 2 10G fabricpath interfaces, 
should these 2 be a channel group

or doesn't it really matter, because of the equal cost routing in isis



If you really want VPC+, then yes it should be a port channel and 
configured as the VPC peer link. PL & PKA are required in VPC+ just 
like in VPC.


If you don't need VPC+, then yes you could just do parallel FP links 
and use ECMP for load sharing instead of port-channel, it's your choice.


Hope that helps,
Tim





/Arne

___
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
Distinguished 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] fabricpath and vPC+

[Arne Larsen / Region Nordjylland]

Hi all

What is the correct setup when one is using fabricpath and vPC+
If 2 5k are direct connected with 2 10G fabricpath interfaces, should these 2 
be a channel group
or doesn't it really matter, because of the equal cost routing in isis

/Arne

___
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] FHRP selection within Nexus

[Phil Mayers]

On 13/11/13 17:07, Blake Pfankuch - Mailing List wrote:


I am weighing options between HSRP and GLBP knowing that GLBP is
Cisco only.  This environment will be Cisco only for the foreseeable


HSRP is Cisco-proprietary as well. Only VRRP is actually cross-platform.

[Personally I feel your vendor loyalty is misguided; you should evaluate 
all purchases on merit, not "It has Cisco written on it". But that's 
your call...]



on it.  Any issues or know bugs that have been hit related to GLBP?


On NX-OS 5.2 GLBP is IPv4-only, which is an annoyance. If you need IPv6 
(and you should be doing IPv6) you should check into this. They might 
have fixed it in 6.2 - not sure.



With that in mind, would you as peers favor GLBP or HSRP?  I am
looking at host dependent load balancing specifically to allow better
traffic distribution cross sides of the datacenter, with times
configured for 1 second hello and 4 second hold timers.


We use HSRP by preference. I like knowing which router is the active at 
any given time - it aids troubleshooting, and we don't need the 
performance of having both devices active.


If you need the performance, use GLBP. Otherwise use HSRP, because it's 
marginally simpler and more common (therefore better tested).


Finally, since you're on NX-OS, you should also check into vPC and 
dual-active HSRP. Personally I dislike vPC - it has too many moving 
parts, and a list of caveats a mile long - but it might suit your needs.

___
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] FHRP selection within Nexus

[Blake Pfankuch - Mailing List]

Howdy,
I am going through the preliminary design and rough 
configuration migrating from legacy 6500's to our new Nexus 7000 core and am 
trying to alleviate existing design flaws through the infrastructure.  I did 
not build the original network, I have only been maintaining it for a short 
period of time.  Currently my L3 core has a large number of vlan interfaces.  
There is no properly configured FHRP, just an equal split of defined gateways 
(vlan 1 through 2000 vlan interfaces live on 6500-01 and 2001 through 4000 live 
on 6500-02) and a failure of an HSRP deployment.  I have it narrowed down to 2 
deployment options and I am hoping some of my educated peers might have some 
suggestions.  I also have some questions as it has been a while since I did 
this...

I am weighing options between HSRP and GLBP knowing that GLBP is Cisco only.  
This environment will be Cisco only for the foreseeable future (always if I 
have my say).  The entire network infrastructure (meaning anything speaking a 
routing protocol or passing traffic) will be Cisco.

The devices holding L3 routing will be Nexus 7004 with redundant Sup2's and M2 
10GBE line cards and running NX-OS 6.2 (2a).  My Cisco team stated that either 
were accepted solutions, but he did not favor one way or the other as he did 
not have reviews on GLBP deployments.  I am looking for someone who has 
deployed GLBP on 6.x and impressions on it.  Any issues or know bugs that have 
been hit related to GLBP?

One of our big initiatives for next year is redundancy and seamless failover.  
With this in mind, we are in the process of implementing N+N redundancy 
splitting our datacenter North/South with a distributed edge load balancing 
implementation.  We are trying to decrease the traffic flow across north and 
south sides of that datacenter so I am favoring GLBP in my mind with some of 
the traffic distribution options.

With that in mind, would you as peers favor GLBP or HSRP?  I am looking at host 
dependent load balancing specifically to allow better traffic distribution 
cross sides of the datacenter, with times configured for 1 second hello and 4 
second hold timers.

Thanks!
Blake
___
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 QOS on ME3600 not working???

[Pete Lumbis]

This is similar, but not the right bug. This bug is fixed in the 15.3.3S
train and it is specific to class-map ACLs that are matching on L4 ports.
In Adam's case we are on later code and there are no ACLs matching L4 ports.

I've updated the release note to indicate the requirement of L4 information
in the ACL, it should change on cisco.com tomorrow.

-Pete


On Wed, Nov 13, 2013 at 5:43 AM, Shawn Nolan <
shawn.no...@convergencegroup.co.uk> wrote:

> This is a bug. We ran into the same one a while back when we performed a
> IOS upgrade.
>
> I believe this is the code CSCug39331
>
> Options are. Upgrade to a newer release or straight from TAC:
>
> "If moving to later release is not an option, you could consider the below
> workaround for this issue which we tested already. This will make it a L4
> ACL policy case internally and should work as expected.
>
> Add a dummy class-map matching on L4 ACL to the same policymap. (class
> matching none of the traffic streams so that actual classes are not
> affected)
>
> Class Map match-all tcpudp (id 51)
>Match access-group name tcpudp
>
> Extended IP access list tcpudp
> 10 permit tcp host 1.2.3.4 any
> "
>
>
>
> -Original Message-
> From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
> Waris Sagheer (waris)
> Sent: 12 November 2013 19:10
> To: Adam Vitkovsky; cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] MPLS QOS on ME3600 not working???
>
> Hi Adam,
> Did you work with TAC or BU on this issue? Can you send me your
> configuration so that I can take a look at it. I need to class-maps and
> policies as well as the interface configuration.
>
> Best Regards,
>
> [http://www.cisco.com/web/europe/images/email/signature/horizontal06.jpg]
>
> Waris Sagheer
> Technical Marketing Manager
> Service Provider Access Group (SPAG)
> wa...@cisco.com
> Phone: +1 408 853 6682
> Mobile: +1 408 835 1389
>
> CCIE - 19901
>
>
> 
>
>
>
> This email may contain confidential and privileged material for the sole
> use of the intended recipient. Any review, use, distribution or disclosure
> by others is strictly prohibited. If you are not the intended recipient (or
> authorized to receive for the recipient), please contact the sender by
> reply email and delete all copies of this message.
>
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>
>
>
> From: adam vitkovsky mailto:adam.vitkov...@swan.sk
> >>
> Date: Tuesday, November 12, 2013 5:39 AM
> To: "cisco-nsp@puck.nether.net" <
> cisco-nsp@puck.nether.net>
> Subject: [c-nsp] MPLS QOS on ME3600 not working???
>
> Hi Folks,
>
> Is anyone using MPLS QOS on ME3600 platform please or I am the only one
> hitting the issue?
> As seen below all traffic is matched into the first class defined in the
> policy-map no matter how the packets are marked.
> If I would remove the class core_class7 from the policy-map (and might
> have then add it back so that it would appears at the bottom) all the
> traffic is going to be matched by the next class that happens to be at the
> top of the policy-map which would be core_class6 and so on and so on.
> This is seen on all boxes and across couple of different IOS versions.
>
> Somehow I fail to convince Cisco that my MPLS traffic patterns are not
> changing from EXP7/Prec7 to EXP6/Prec6 to ... miraculously as I'm changing
> the inbound policy-map on some random PE even though I showed them that the
> neighboring P-core sees a variety of EXP5 to EXP1 marked packets in output
> policy-maps in direction towards the ME3600.
>
> sh policy-map int te0/1 in
> TenGigabitEthernet0/1
>
>   Service-policy input: core_policy_ver5.0_input
>
> Class-map: core_class7 (match-any)
>   74193994 packets, 7015406412 bytes
>   30 second offered rate 33000 bps, drop rate  bps
>   Match: mpls experimental topmost 7
>   Match:  precedence 7
> set qos-group 7
> set discard-class 7
>
> Class-map: core_class6 (match-any)
>   0 packets, 0 bytes
>   30 second offered rate  bps, drop rate  bps
>   Match: mpls experimental topmost 6
>   Match:  precedence 6
>   Match: access-group name AL_BFD
> set qos-group 6
> set discard-class 6
>
> Class-map: core_class5 (match-any)
>   0 packets, 0 bytes
>   30 second offered rate  bps, drop rate  bps
>   Match: mpls experimental topmost 5
>   Match:  precedence 5
> set qos-group 5
> set discard-class 5
>
> Class-map: core_class4 (match-any)
>   0 packets, 0 bytes
>   30 second offered rate  bps, drop rate  bps
>   Match: mpls experimental topmost 4
>   Match:  precedence 4
> set qos-group 4
> set discard-class 4
>
> Class-map: core_class3 (match-any)
>   0 packets, 0 bytes
>   30 second offered rate  bps

Re: [c-nsp] shaping > 128 mbps - asr9k

[Lars Eidsheim]

Do you need to use shaping? If not you can use a policer,

Example:

policy-map from-internet-child
 class udp-attack
  police rate 500 mbps
 !
 class class-default
 !
 end-policy-map

Mvh

Lars Eidsheim
iNTELLiT


-Opprinnelig melding-
Fra: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] På vegne av Aaron
Sendt: 12. november 2013 22:00
Til: 'Oliver Boehmer (oboehmer)'; cisco-nsp@puck.nether.net
Emne: Re: [c-nsp] shaping > 128 mbps - asr9k

policy-map from-internet-child
 class udp-attack
  shape average 600 mbps
 !
 class class-default
 !
 end-policy-map


-Original Message-
From: Aaron [mailto:aar...@gvtc.com]
Sent: Tuesday, November 12, 2013 2:58 PM
To: 'Oliver Boehmer (oboehmer)'; 'cisco-nsp@puck.nether.net'
Subject: RE: [c-nsp] shaping > 128 mbps - asr9k


(here's the uncommitted (failing) config... basically I want to shape
inbound UDP to 600 mbps.  please show me how to accomplish that.)

RP/0/RSP0/CPU0:eng-lab-9k-1(config-pmap-c)#show config

policy-map from-internet-parent
 class class-default
  service-policy from-internet-child
  shape average 1 gbps
 !
 end-policy-map
!
interface GigabitEthernet0/0/0/5
 service-policy input from-internet-parent !
end

RP/0/RSP0/CPU0:eng-lab-9k-1(config-pmap-c)#commi

% Failed to commit one or more configuration items during a pseudo-atomic
operation. All changes made have been reverted. Please issue 'show
configuration failed' from this session to view the errors

RP/0/RSP0/CPU0:eng-lab-9k-1(config-pmap-c)#show config failed

!! SEMANTIC ERRORS: This configuration was rejected by !! the system due to
semantic errors. The individual !! errors with each failed configuration
command can be !! found below.

interface GigabitEthernet0/0/0/5
 service-policy input from-internet-parent !!% 'prm_ezhal' detected the
'warning' condition 'Cannot support child/flat shape rate > 128Mbps'
!
end

RP/0/RSP0/CPU0:eng-lab-9k-1(config-pmap-c)#do sh run class-map

class-map match-all udp-attack
 match protocol udp
 end-class-map
!




-Original Message-
From: Oliver Boehmer (oboehmer) [mailto:oboeh...@cisco.com]
Sent: Tuesday, November 12, 2013 2:23 PM
To: Aaron; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] shaping > 128 mbps - asr9k



>Anyone know how to accomplish shaping traffic at a rate greater than
>128 mbps ?
>
>When I apply the policy-map/class-map to an interface it fails with
>this message.
>
>'Cannot support child/flat shape rate > 128Mbps'

can you please share the configuration you are trying to apply, including
policy-maps and where you want to apply this?

oli

___
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 email has been scanned and secured by Intellit

This communication is for use by the intended recipient and contains 
information that may be privileged, confidential and exempt from disclosure or 
copyrighted under applicable law. If you are not the intended recipient, you 
are hereby formally notified that any dissemination, use, copying or 
distribution of this e-mail, in whole or in part, is strictly prohibited. 
Please notify the sender by return e-mail and delete this e-mail from your 
system.

___
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] ME3600 BFD session to A9K breaks after upgrade to 15.3(3)S1a

[Stephen Fulton]

Between 15.3(3)S1 and S1a, yes just a naming change.  I as upgrading 
from 15.3(1)S1.


-- Stephen

On 13/11/2013 8:03 AM, Adam Vitkovsky wrote:

So there actually is a difference between .S1 and .S1a?
I thought it's the same code and that just a naming changed.

adam

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
Stephen Fulton
Sent: Wednesday, November 13, 2013 1:22 PM
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] ME3600 BFD session to A9K breaks after upgrade to
15.3(3)S1a

I upgraded an ME3600 to 15.3(3)S1a an hour ago from 15.3(1)s1, which had a
working BFD session with a directly connected 6500.  After the upgrade, BFD
stopped working.

Noticed that ISIS was also done (had previously been up).  Had to explicitly
define the CLNS MTU on the ME3600X interface (was defined on the 6500
opposite) and ISIS came back up.  BFD came up on that interface at the time
as well.

On 12/11/2013 2:09 PM, Jason Lixfeld wrote:

No, it's not the same, but it's not the same on a working interface

either.


The 15.3(3)S1a ME3600 has a CLNS MTU of 9213.
The 15.3(3)S ME3600 has a CLNS MTU of 1497.
The 4.3.1 ASR9000 has a CLNS MTU of 9199.

15.3(3)S1a ME3600 is directly connected to the 15.3(3)S ME3600 and has an

ISIS adjacency and BFD session.

The 15.3(3)S1a ME3600 is directly connected to the 4.3.1 ASR9K and does

not have an ISIS adjacency or BFD session.


If it was a CLNS MTU issue, I'd suspect the 15.3(3)S1a and 15.3(3)S ME3600

ISIS and BFD session would be down as well, but it's not.


That notwithstanding, the BFD session between the 9K and 15.3(3)S1a ME3600

is down as well.  ISIS CLNS issue or not, that's not going to work unless
BFD works, no?


On Nov 12, 2013, at 10:20 AM, Adam Vitkovsky 

wrote:



Hi Jason,

Is the CLNS MTU equal at both ends please?
It appears this is again one of the conditions to form ISIS session
in
15.3(3)S1

adam




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

Re: [c-nsp] ME3600 BFD session to A9K breaks after upgrade to 15.3(3)S1a

[Adam Vitkovsky]

So there actually is a difference between .S1 and .S1a?
I thought it's the same code and that just a naming changed.

adam 

-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of
Stephen Fulton
Sent: Wednesday, November 13, 2013 1:22 PM
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] ME3600 BFD session to A9K breaks after upgrade to
15.3(3)S1a

I upgraded an ME3600 to 15.3(3)S1a an hour ago from 15.3(1)s1, which had a
working BFD session with a directly connected 6500.  After the upgrade, BFD
stopped working.

Noticed that ISIS was also done (had previously been up).  Had to explicitly
define the CLNS MTU on the ME3600X interface (was defined on the 6500
opposite) and ISIS came back up.  BFD came up on that interface at the time
as well.

On 12/11/2013 2:09 PM, Jason Lixfeld wrote:
> No, it's not the same, but it's not the same on a working interface
either.
>
> The 15.3(3)S1a ME3600 has a CLNS MTU of 9213.
> The 15.3(3)S ME3600 has a CLNS MTU of 1497.
> The 4.3.1 ASR9000 has a CLNS MTU of 9199.
>
> 15.3(3)S1a ME3600 is directly connected to the 15.3(3)S ME3600 and has an
ISIS adjacency and BFD session.
> The 15.3(3)S1a ME3600 is directly connected to the 4.3.1 ASR9K and does
not have an ISIS adjacency or BFD session.
>
> If it was a CLNS MTU issue, I'd suspect the 15.3(3)S1a and 15.3(3)S ME3600
ISIS and BFD session would be down as well, but it's not.
>
> That notwithstanding, the BFD session between the 9K and 15.3(3)S1a ME3600
is down as well.  ISIS CLNS issue or not, that's not going to work unless
BFD works, no?
>
> On Nov 12, 2013, at 10:20 AM, Adam Vitkovsky 
wrote:
>
>> Hi Jason,
>>
>> Is the CLNS MTU equal at both ends please?
>> It appears this is again one of the conditions to form ISIS session 
>> in
>> 15.3(3)S1
>>
>> adam
>>
>
>
> ___
> 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/

Re: [c-nsp] ME3600 BFD session to A9K breaks after upgrade to 15.3(3)S1a

[Stephen Fulton]

I upgraded an ME3600 to 15.3(3)S1a an hour ago from 15.3(1)s1, which had 
a working BFD session with a directly connected 6500.  After the 
upgrade, BFD stopped working.


Noticed that ISIS was also done (had previously been up).  Had to 
explicitly define the CLNS MTU on the ME3600X interface (was defined on 
the 6500 opposite) and ISIS came back up.  BFD came up on that interface 
at the time as well.


On 12/11/2013 2:09 PM, Jason Lixfeld wrote:

No, it's not the same, but it's not the same on a working interface either.

The 15.3(3)S1a ME3600 has a CLNS MTU of 9213.
The 15.3(3)S ME3600 has a CLNS MTU of 1497.
The 4.3.1 ASR9000 has a CLNS MTU of 9199.

15.3(3)S1a ME3600 is directly connected to the 15.3(3)S ME3600 and has an ISIS 
adjacency and BFD session.
The 15.3(3)S1a ME3600 is directly connected to the 4.3.1 ASR9K and does not 
have an ISIS adjacency or BFD session.

If it was a CLNS MTU issue, I'd suspect the 15.3(3)S1a and 15.3(3)S ME3600 ISIS 
and BFD session would be down as well, but it's not.

That notwithstanding, the BFD session between the 9K and 15.3(3)S1a ME3600 is 
down as well.  ISIS CLNS issue or not, that's not going to work unless BFD 
works, no?

On Nov 12, 2013, at 10:20 AM, Adam Vitkovsky  wrote:


Hi Jason,

Is the CLNS MTU equal at both ends please?
It appears this is again one of the conditions to form ISIS session in
15.3(3)S1

adam




___
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] ACS 5.4 UCP - where does it listen?

[Pierfrancesco Caci]

Hi,
I have an ACS 5.4 with two interfaces, one where we get the tacacs
queries, and one for management. Trying to get UCP (using the java
thingie) to work, I can't figure which of the two interfaces it's
listening on, and which port I need to open on the firewall. 
You can cluebat me with a pointer to the docs, if that's written
somewhere :-)

Thanks

Pf

-- 
Pierfrancesco Caci, ik5pvx
___
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] Meraki...information

[Eric Van Tol]

Not yet - the TAC engineer is working with the BU to verify whether it's 
something they've seen before or if it's a new bug.  It has taken more than a 
week just to get them to pay attention to it.  Once I have a more definitive 
answer, I'll post to the list.

-evt

> -Original Message-
> From: Nick Hilliard [mailto:n...@foobar.org]
> Sent: Wednesday, November 13, 2013 6:00 AM
> To: Eric Van Tol; cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] Meraki...information
> 
> On 24/10/2013 18:52, Eric Van Tol wrote:
> > If this does turn out to be a bug, I'll be happy to post it to the list
> > or you can contact me directly to request further details.
> 
> Did you ever get a bugid for this problem?
> 
> Nick


___
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] Meraki...information

[Nick Hilliard]

On 24/10/2013 18:52, Eric Van Tol wrote:
> If this does turn out to be a bug, I'll be happy to post it to the list
> or you can contact me directly to request further details.

Did you ever get a bugid for this problem?

Nick

___
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] 7600 10GE card recommendations (1 & 2 port cards)

[Nick Hilliard]

On 13/11/2013 10:20, James Bensley wrote:
> WS-X6501-10GEX4:

this is an ancient line card.  They have trashy buffers, trashy buffering
mechanisms, bad qos and don't support vpls (although they can run l2vpn and
l3vpn).  I would avoid them like the plague.

> 7600-ES20-10G3C:
> This seems more what I'm after, 2x 10G ports, no too expensive, plus
> they look like they will do line rate 10 gig.

these cards are rubbish because they don't achieve what they set out to do.
 Although they support vpls, they have a fatal flaw in that they don't
support local vlan significance.  Local vlan significance means that vlan X
on one port or one ethernet service instance is the same as vlan X on
another port or another ethernet service instance.  This means it's
practically impossible to provide complex metro ethernet services on the
cards because of the risk of overlapping vlan IDs.  The problem was fixed
on the plus variant of the card.

Also, these cards have a builtin DFC, which means that you need to match
this with your SUP.  As you're already using RSP720-3CXLs, if you put a
DFC3C line card in, you'll cause the entire chassis to drop its forwarding
capacity to RSP720-3C status, i.e. 240k ipv4 routes.  This is probably not
what you want.

Unless you need to run vpls services on your 10G cards, you should probably
pick up some 4 port WS-X6704-10GE line cards on ebay because they're cheap.
 They have a pile of well documented problems, but if you're looking for a
simple uplink for transporting mpls packets, they will be fine.

Nick


___
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] %PLATFORM-CIH-5-ASIC_ERROR_SCRUB_THRESH

[Antonio Soares]

I can confirm that the reload solved the issue. It was a 1x100GBE/CRS-FP140 
pair of cards.

Regards,

Antonio Soares, CCIE #18473 (R&S/SP)
amsoa...@netcabo.pt
http://www.ccie18473.net



-Original Message-
From: Edward Salonia [mailto:e...@edgeoc.net] 
Sent: quarta-feira, 6 de Novembro de 2013 16:33
To: Antonio Soares
Cc: ; cisco-nsp; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] %PLATFORM-CIH-5-ASIC_ERROR_SCRUB_THRESH

There should be an SMU to suppress those "informational" messages. Apparently 
they resulted in a bunch of unnecessary RMA's.

- Ed

On Nov 6, 2013, at 7:13, "Antonio Soares"  wrote:

Thank you for the feedback. It's good to know that the reload worked for you.

The new bug tool shows that 65 support cases were opened for this issue:

https://tools.cisco.com/bugsearch/bug/CSCts11174

If it was something severe, we would know it.


Regards,

Antonio Soares, CCIE #18473 (R&S/SP)
amsoa...@netcabo.pt
http://www.ccie18473.net



-Original Message-
From: jean-francois.d...@videotron.com
[mailto:jean-francois.d...@videotron.com]
Sent: terça-feira, 5 de Novembro de 2013 22:54
To: amsoa...@netcabo.pt
Cc: cisco-nsp@puck.nether.net; cisco-nsp
Subject: RE: [c-nsp] %PLATFORM-CIH-5-ASIC_ERROR_SCRUB_THRESH

Hi Antonio,

I had a similar issue and decided to reload the linecard.

pse_pogo_driver[281]: %PLATFORM-CIH-5-ASIC_ERROR_SPECIAL_HANDLE : pse[1]: A sbe 
error has occurred causing  data corrected. 0x12470007


I don't like to see any messages regarding single bit error (SBE) and even less 
when it's in packet switching engine (PSE) ASIC so that's why I reloaded the 
linecard. The messages went away.

I used "show asic-errors all detail location 0/x/CPU0" to see the errors on the 
linecard.


Cheers,

JF

Jean-François Dubé
Technicien, Opérations Réseau IP
Ingénierie Exploitation des Réseaux
Vidéotron

"cisco-nsp"  a écrit sur 2013-10-28
11:52:02 :

> De : "Antonio Soares"  A : 
> , Date : 2013-10-28 11:54 Objet : [c-nsp] 
> %PLATFORM-CIH-5-ASIC_ERROR_SCRUB_THRESH
> Envoyé par : "cisco-nsp" 
> 
> Hello Team,
> 
> I'm getting this message:
> 
> 
> pse_pogo_driver[244]: %PLATFORM-CIH-5-ASIC_ERROR_SCRUB_THRESH : 
> pse[1]: A sbe error has occurred causing data corrected. 0x12470009 
> Threshold has
been
> exceeded
> 
> 
> Exactly every 14 minutes and 10 seconds. I found bug CSCts11174 and 
> they
> say:
> 
> 
> Workaround:
> Sometimes an LC reload can fix the issue but it is not guaranteed.
> This does not harm any user or control traffic and should not trigger 
> RMA
or
> EFA in particular.
> 
> 
> Can someone confirm that this is really cosmetic ?
> 
> I'm getting it on a 1X100GBE/CRS-FP140.
> 
> 
> Thanks.
> 
> Regards,
> 
> Antonio Soares, CCIE #18473 (R&S/SP)
> amsoa...@netcabo.pt
> http://www.ccie18473.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/



___
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] MPLS QOS on ME3600 not working???

[Shawn Nolan]

This is a bug. We ran into the same one a while back when we performed a IOS 
upgrade.

I believe this is the code CSCug39331

Options are. Upgrade to a newer release or straight from TAC:

"If moving to later release is not an option, you could consider the below 
workaround for this issue which we tested already. This will make it a L4 ACL 
policy case internally and should work as expected.

Add a dummy class-map matching on L4 ACL to the same policymap. (class matching 
none of the traffic streams so that actual classes are not affected)

Class Map match-all tcpudp (id 51)
   Match access-group name tcpudp

Extended IP access list tcpudp
10 permit tcp host 1.2.3.4 any
"



-Original Message-
From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Waris 
Sagheer (waris)
Sent: 12 November 2013 19:10
To: Adam Vitkovsky; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] MPLS QOS on ME3600 not working???

Hi Adam,
Did you work with TAC or BU on this issue? Can you send me your configuration 
so that I can take a look at it. I need to class-maps and policies as well as 
the interface configuration.

Best Regards,

[http://www.cisco.com/web/europe/images/email/signature/horizontal06.jpg]

Waris Sagheer
Technical Marketing Manager
Service Provider Access Group (SPAG)
wa...@cisco.com
Phone: +1 408 853 6682
Mobile: +1 408 835 1389

CCIE - 19901






This email may contain confidential and privileged material for the sole use of 
the intended recipient. Any review, use, distribution or disclosure by others 
is strictly prohibited. If you are not the intended recipient (or authorized to 
receive for the recipient), please contact the sender by reply email and delete 
all copies of this message.

For corporate legal information go 
to:http://www.cisco.com/web/about/doing_business/legal/cri/index.html



From: adam vitkovsky mailto:adam.vitkov...@swan.sk>>
Date: Tuesday, November 12, 2013 5:39 AM
To: "cisco-nsp@puck.nether.net" 
mailto:cisco-nsp@puck.nether.net>>
Subject: [c-nsp] MPLS QOS on ME3600 not working???

Hi Folks,

Is anyone using MPLS QOS on ME3600 platform please or I am the only one hitting 
the issue?
As seen below all traffic is matched into the first class defined in the 
policy-map no matter how the packets are marked.
If I would remove the class core_class7 from the policy-map (and might have 
then add it back so that it would appears at the bottom) all the traffic is 
going to be matched by the next class that happens to be at the top of the 
policy-map which would be core_class6 and so on and so on.
This is seen on all boxes and across couple of different IOS versions.

Somehow I fail to convince Cisco that my MPLS traffic patterns are not changing 
from EXP7/Prec7 to EXP6/Prec6 to ... miraculously as I'm changing the inbound 
policy-map on some random PE even though I showed them that the neighboring 
P-core sees a variety of EXP5 to EXP1 marked packets in output policy-maps in 
direction towards the ME3600.

sh policy-map int te0/1 in
TenGigabitEthernet0/1

  Service-policy input: core_policy_ver5.0_input

Class-map: core_class7 (match-any)
  74193994 packets, 7015406412 bytes
  30 second offered rate 33000 bps, drop rate  bps
  Match: mpls experimental topmost 7
  Match:  precedence 7
set qos-group 7
set discard-class 7

Class-map: core_class6 (match-any)
  0 packets, 0 bytes
  30 second offered rate  bps, drop rate  bps
  Match: mpls experimental topmost 6
  Match:  precedence 6
  Match: access-group name AL_BFD
set qos-group 6
set discard-class 6

Class-map: core_class5 (match-any)
  0 packets, 0 bytes
  30 second offered rate  bps, drop rate  bps
  Match: mpls experimental topmost 5
  Match:  precedence 5
set qos-group 5
set discard-class 5

Class-map: core_class4 (match-any)
  0 packets, 0 bytes
  30 second offered rate  bps, drop rate  bps
  Match: mpls experimental topmost 4
  Match:  precedence 4
set qos-group 4
set discard-class 4

Class-map: core_class3 (match-any)
  0 packets, 0 bytes
  30 second offered rate  bps, drop rate  bps
  Match: mpls experimental topmost 3
  Match:  precedence 3
set qos-group 3
set discard-class 3

Class-map: core_class2 (match-any)
  0 packets, 0 bytes
  30 second offered rate  bps, drop rate  bps
  Match: mpls experimental topmost 2
  Match:  precedence 2
set qos-group 2
set discard-class 2

Class-map: core_class1 (match-any)
  0 packets, 0 bytes
  30 second offered rate  bps, drop rate  bps
  Match: mpls experimental topmost 1
  Match:  precedence 1
set qos-group 1
set discard-class 1

Class-map: class-default (match-any)
  0 packets, 0 by

[c-nsp] 7600 10GE card recommendations (1 & 2 port cards)

[James Bensley]

Hi All,

I am looking for some 1 and 2 port 10Gig Ethernet line cards for 7600
series chassis (7604/6/9) which already have SUP-720-3CXLs in them.

Some need 1 10G port and others 2 (larger chassis, 7609), so 4 or more
ports is too many as that seems to at least double the price so I
don't want to purchase 4 port cards and have spare ports with nothing
on the horizon to allocate them for.


I have seen the following;

WS-X6501-10GEX4:
Apart from being old, they seem to be SC only which isn't the end of
the world as I can buy an SC to LC cable although these seem to only
have an 8Gbps bus (unless I'm mistaken), so I can't get 10G out of it
anyway! Please correct me if I'm wrong.

7600-ES20-10G3C:
This seems more what I'm after, 2x 10G ports, no too expensive, plus
they look like they will do line rate 10 gig.

Are there any other cards that have 1x or 2x 10G ports that also
support Ethernet/IP/MPLS at line rate? That first card I believe
doesn't support MPLS (I can't decipher the Cisco docs), if that is
correct it's no use to me anyway. I'm preferably after cards with
optic slots on them like SFP slots or X2 slots etc, no 10G copper
Ethernet cards.

The cards are for uplink ports into the core so no QoS is required for
example or ACLs but Ethernet/IP/MPLS features at line rate are
required.

Many thanks,
James.
___
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] policy routing by dest port?

[Lukas Tribus]

Hi!


> Wouldn't there be some NATing involved? Else what is your DNS server going
> to do with a destination address that it doesn't own?

Well, the server can certainly be configured to respond to all destination
IPs. Thats not a problem in linux, you just need to think the whole routing
path through.



Regards,

Lukas 
___
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] policy routing by dest port?

[Tony]

Yes you can policy route based on a ACL that matches anything you can match in 
an ACL (within reason and some limitations), but as another poster pointed out 
your DNS isn't going to answer queries that aren't directed at it.

Perhaps instead of trying to route the traffic to your DNS you should just 
route it to null0 instead ?

I imagine that to apply a policy-route to PPP subscribers you'll need to supply 
it via RADIUS so that it ends up on virtual-access interfaces.



regards,
Tony.





 From: Mike 
To: 'Cisco-nsp'  
Sent: Wednesday, 13 November 2013 2:26 AM
Subject: [c-nsp] policy routing by dest port?
 

Hi,

     I have a situation which may require me to reroute all dns traffic 
in my network comming from subscribers destined to offsite resolvers, 
over to one of my own resolvers instead. The subscribers are all 
terminated on 7201 and effectively I would like to have a rule I can 
drop in that says 'dns traffic to anywhere but my official resolvers is 
forwarded '. The subscribers are mostly pppoe which means lots of 
virtual access interfaces on the router, and no adjusting the supplied 
dns servers via ppp won't do (I need to overcome corrupt / hijacked cpe 
which are ignoring these values).

Thanks for any pointers.

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/
___
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 console access problem

[Ben Hammadi, Kayssar (NSN - TN/Tunis)]

  Dears ,

   I have no console access on my 6509 , I see I have an idle console 
connection but I am eable to clear it , "neither clear line"  nor "clear line 
console"  solve the problem

SWA#show users
Line   User   Host(s)  Idle   Location
   0 con 0idle6d21h
*  1 vty 0 hbib.sahn  idle 00:00:00 10.203.9.141


SWA#clear line 0
[confirm]
 [OK]

SWA #show  users
Line   User   Host(s)  Idle   Location
   0 con 0idle6d21h
*  1 vty 0 hbib.sahn  idle 00:00:00 10.203.9.141

SWA #clear line console 0
[confirm]
 [OK]

SWA #show  users
Line   User   Host(s)  Idle   Location
   0 con 0idle6d21h
*  1 vty 0 hbib.sahn  idle 00:00:00 10.203.9.141


 Any idea?

Br.

BEN HAMMADI Kayssar

NOKIA SIEMENS NETWORKS
Lead Engineer -BroadBand Connectivity
JNCIE-M (#471), JNCIE-SP (#1147), CCIP



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