Re: [c-nsp] ACL logging on n5k

[Arvind .cisconsp]

I believe the datasheet refers to what is supported in hardware (capability
of hardware to log ACL hits)

Software support for this is coming in the next major release from what I
understand.

On Mon, Aug 9, 2010 at 3:22 PM, Tassos Chatzithomaoglou
wrote:

> N5k datasheet says it's supported, but i couldn't find any other reference.
> Is it supported and if yes, how do you enable it?
>
> --
> Tassos
>
> ___
> 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] Bundling ports on different WS6704 linecards

[Ivan]

On 9/Aug/2010 11:22 p.m., Phil Mayers wrote:

On 09/08/10 08:47, Rin wrote:

Hi group,



We are building a Core network of 3 7609 routers connecting as a 40Gbps
ring. On each router we have 4 WS6704 linecards. Each router will be
connected to other routers via 4 10G-links, these links will be
configured
as Port-Channel.



Should we place each link of the port-channel on different linecard on
each
router or should we allocate all 4 links on the same linecard? Anyone has
any problem with configuring etherchannel for ports on different WS6704
linecards?


We do that extensively. It works fine. It is better to have
cross-linecard portchannels in general.

HOWEVER - there are a couple of caveats to be aware of. One is if you've
got different linecards with different QoS queuing, you will need:

int PoX
no mls qos channel-consistency

Second is that there are some issues with cross-linecard portchannels if
you have service modules (ACE, FWSM, WiSM) in the chassis. I can't
remember the details or find the link at the moment.
___
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/


I was bitten by the FWSM and DEC.  The link that was referred to is
probably http://www.cisco.com/en/US/ts/fn/610/fn61935.html

Field Notice: FN - 61935 - Catalyst 6500 Series and 7600 Series Service
Module Incompatibility With Distributed EtherChannel and Packet
Re-Circulation

"Problem Description
When the listed service modules transmit packets to VLANs also used with
Distributed EtherChannel (DEC), those packets may be dropped and lost.

Background

The listed service modules do not support packet re-circulation. Packet
re-circulation is a specific means to forward packets internal to the
chassis between modules. When the service module attempts to forward a
packet onto such a VLAN with packet-recirculation enabled, it may fail and
the packet might be lost. When packet re-circulation is not enabled on the
destination VLAN, even if DEC is present, this problem will not be
encountered."

We ended up getting rid of the DEC and using plain EC and "no monitor
session servicemodule" as the span sessions were required for other
purposes.
(http://www.cisco.com/en/US/products/hw/modules/ps2706/products_qanda_item09186a00801e9e26.shtml#q44)

Cheers

Ivan
___
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] ACL logging on n5k

[Tassos Chatzithomaoglou]

N5k datasheet says it's supported, but i couldn't find any other reference.
Is it supported and if yes, how do you enable it?

--
Tassos

___
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] linux vpn client

[Adrian Minta]

http://www.shrew.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/

Re: [c-nsp] linux vpn client

[Gabriel]

vpnc

On Aug 9, 2010 9:07 PM, "Deric Kwok"  wrote:

Hi all

Can you suggest the linux vpn client?

eg: fedora, suse

I also try the anyconnect. but don't know how to put the configure file

When I use it in xwindow, it asks me to provide  "connect to " vpn gui

But I type the ip address, it won't work

Thank you
___
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] Linecard performance w/ SUP32's

[Mack McBride]

A side note is that F6K DFCs are not supported on SXI and are end of life.
http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod_end-of-life_notice0900aecd806d9953.html
They may work but they are not supported.

The 6548 cards are also End of life (meaning you can get them cheap but can't 
get support)
http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod_end-of-life_notice0900aecd8069af87.html

If you are upgrading and have money to spare you may want to look at the 6748 
cards.

Mack McBride
Network Architect

-Original Message-
From: cisco-nsp-boun...@puck.nether.net 
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Tim Stevenson
Sent: Monday, August 09, 2010 10:56 AM
To: Graham P. Wooden; cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Linecard performance w/ SUP32's

Hi Graham, please see inline below:

At 09:17 AM 8/9/2010, Graham P. Wooden averred:

>Hi there,
>
>I am trying to decide if swapping a few x6348s to x6548 
>(fabric-enabled/CEF256 .. no DFC) will be a huge performance gain 
>with SUP32s (IOS is SXI).

Nope.

> >From what I am reading, it looks like they will somewhat - but 
> appears that I will bump up against the 256 mark until the SUPs 
> themselves get upgraded.

There is no "256" with sup32. It is a bus-based sup, no xbar fabric 
whatsoever.

>Even if the line cards have the DFCs, can the SUP32-3B take advantage of them?

DFC + sup32 = not supported/possible.

Basically you're trading one bus-attached 48 port 1G card for 
another. There are some benefits perhaps - qos capabilities, 
possibility to u/g to sup720 in future & get fabric connections & add 
DFCs for more performance - but for now, they are pretty equivalent.

Hope that helps,
Tim

>Currently, this chassis doesn't see a whole-lot of traffic and is 
>very light on the QoS side - but I have the funds to get this 
>particular chassis upgraded and thought that spending a few bucks 
>for new line cards would be a step in the right direction.
>
>Appreciate any real-world comments on the older 6348 vs. 6548 w/ a SUP32.
>
>Thanks,
>
>-graham
>
>___
>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/

___
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] linux vpn client

[Deric Kwok]

Hi all

Can you suggest the linux vpn client?

eg: fedora, suse

I also try the anyconnect. but don't know how to put the configure file

When I use it in xwindow, it asks me to provide  "connect to " vpn gui

But I type the ip address, it won't work

Thank you
___
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] Linecard performance w/ SUP32's

[Graham P. Wooden]

Thanks Gert and Tim for the reply.  Yeah, I was thinking that the Sup32 had a 
fabric connection (kinda like a SFM2). Oh well - maybe one of these days I will 
be able to slide into a Sup720.


- Original Message -
From: "Gert Doering" 
To: "Graham P. Wooden" 
Cc: cisco-nsp@puck.nether.net
Sent: Monday, August 9, 2010 12:21:22 PM
Subject: Re: [c-nsp] Linecard performance w/ SUP32's

Hi,

On Mon, Aug 09, 2010 at 11:17:13AM -0500, Graham P. Wooden wrote:
> I am trying to decide if swapping a few x6348s to x6548 
> (fabric-enabled/CEF256 .. no DFC) will be a huge performance gain with SUP32s 
> (IOS is SXI).

Well, the Sup32 has no fabric.  So you'll still be limited to the
classic bus - if the card is supported at all (it might be, as the 65xx
cards work in a Sup2 system w/o fabric as well).

So if there is any performance gain it's due to "larger buffers" etc...

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] Linecard performance w/ SUP32's

[Gert Doering]

Hi,

On Mon, Aug 09, 2010 at 11:17:13AM -0500, Graham P. Wooden wrote:
> I am trying to decide if swapping a few x6348s to x6548 
> (fabric-enabled/CEF256 .. no DFC) will be a huge performance gain with SUP32s 
> (IOS is SXI).

Well, the Sup32 has no fabric.  So you'll still be limited to the
classic bus - if the card is supported at all (it might be, as the 65xx
cards work in a Sup2 system w/o fabric as well).

So if there is any performance gain it's due to "larger buffers" etc...

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


pgpXd9tPuNtaE.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] Linecard performance w/ SUP32's

[Tim Stevenson]

Hi Graham, please see inline below:

At 09:17 AM 8/9/2010, Graham P. Wooden averred:


Hi there,

I am trying to decide if swapping a few x6348s to x6548 
(fabric-enabled/CEF256 .. no DFC) will be a huge performance gain 
with SUP32s (IOS is SXI).


Nope.

>From what I am reading, it looks like they will somewhat - but 
appears that I will bump up against the 256 mark until the SUPs 
themselves get upgraded.


There is no "256" with sup32. It is a bus-based sup, no xbar fabric 
whatsoever.



Even if the line cards have the DFCs, can the SUP32-3B take advantage of them?


DFC + sup32 = not supported/possible.

Basically you're trading one bus-attached 48 port 1G card for 
another. There are some benefits perhaps - qos capabilities, 
possibility to u/g to sup720 in future & get fabric connections & add 
DFCs for more performance - but for now, they are pretty equivalent.


Hope that helps,
Tim

Currently, this chassis doesn't see a whole-lot of traffic and is 
very light on the QoS side - but I have the funds to get this 
particular chassis upgraded and thought that spending a few bucks 
for new line cards would be a step in the right direction.


Appreciate any real-world comments on the older 6348 vs. 6548 w/ a SUP32.

Thanks,

-graham

___
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] Linecard performance w/ SUP32's

[Graham P. Wooden]

Hi there,

I am trying to decide if swapping a few x6348s to x6548 (fabric-enabled/CEF256 
.. no DFC) will be a huge performance gain with SUP32s (IOS is SXI).
>From what I am reading, it looks like they will somewhat - but appears that I 
>will bump up against the 256 mark until the SUPs themselves get upgraded.
Even if the line cards have the DFCs, can the SUP32-3B take advantage of them?

Currently, this chassis doesn't see a whole-lot of traffic and is very light on 
the QoS side - but I have the funds to get this particular chassis upgraded and 
thought that spending a few bucks for new line cards would be a step in the 
right direction.

Appreciate any real-world comments on the older 6348 vs. 6548 w/ a SUP32.

Thanks,

-graham

___
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] NAT "gaps" - packets not getting translated

[Ronan Mullally]

I've been struggling to get my head around this for the past few days
(trying to figure it out on a live box doesn't help).  I suspect I'm
missing something subtle (hopefully not obvious!).

I've got a setup like this:


 < VRF 1 >
   enduser - router --- router ---+
  | A  B
  +-+ 2811 +-- Internet
  +-+
  | A
   enduser - router --- router ---+
 < VRF n >

Packets at points A are typically 10.x.y.z, and can (but don't yet)
overlap in different VRFs.

These packets are NATed by the 2811 and have addresses of the form A.B.C.x
at point B.  Each VRF has a single IP address dedicated to it (so VRF 1
would be A.B.C.1, VRF 2 A.B.C.2, etc).

I have the following config on interfaces at A and B:

(A)
interface Port-channel1.1107
 description VRF 2
 mtu 1600
 encapsulation dot1Q 1107
 ip vrf forwarding VRF 2
 ip address 10.35.255.195 255.255.255.240
 ip mtu 1500
 ip nat inside
 ip virtual-reassembly
 standby 2 ip 10.35.255.193
 standby 2 follow vpn-vip
 standby 2 name vrf2-default
 crypto map CPE-vrf2 redundancy vrf2-default
end

(B)
interface Port-channel1.1011
 description Onwards Internet access via Sonicwall
 mtu 1600
 encapsulation dot1Q 1011
 ip address x.x.x.83 255.255.255.248
 ip mtu 1500
 ip nat outside
 ip virtual-reassembly
 standby delay minimum 30 reload 60
 standby 1 ip x.x.x.81
 standby 1 follow vpn-vip
 standby 1 authentication md5 x
 standby 1 name public-nat

The loopback interface on the 2811 for each VRF looks like:

interface Loopback1107
 description VRF 2 PWAN
 ip vrf forwarding VRF2
 ip address 10.35.255.252 255.255.255.255
 ip nat inside
 ip virtual-reassembly

I'm running BGP within each VRF to distribute routes.

I have the NAT mapping configured with:

 ip nat pool vrf1 A.B.C.1 A.B.C.1 netmask 255.255.255.128
 ip nat pool vrf2 A.B.C.2 A.B.C.2 netmask 255.255.255.128
 ip nat inside source list vrf1 pool vrf1 mapping-id 10 vrf VRF1 overload
 ip nat inside source list vrf2 pool vrf2 mapping-id 10 vrf VRF2 overload

(I've tried route-maps instead of source lists but it's made no
difference)

Most traffic works fine, however I'm seeing a steady stream of leaked
packets with internal source addresses, often ICMP traffic from loopback
interfaces on routers downstream within the various VRFs:

 10.0.0.49.1822 > x.x.x.x.21: S 1651477420:1651477420(0) win 65535 
 10.0.0.4 > x.x.x.x.49: ICMP time exceeded in-transit, length 36
 10.0.0.49.1822 > x.x.x.x.21: . ack 3704911765 win 65535

 (I can reproduce this at will using FTP connections)

 16:05:00.338256 IP 10.35.255.0.49154 > x.x.x.130.53: 55382+ A? . (35)
 16:05:01.273139 IP 10.35.255.10.49154 > x.x.x.130.53: 19873+ A? . 
(37)
 16:05:02.415973 IP 10.35.255.201 > x.x.x.130: ICMP time exceeded in-transit, 
length 36
 16:05:02.946458 IP 10.35.255.201 > x.x.x.130: ICMP time exceeded in-transit, 
length 36
 16:05:16.299198 IP 10.35.255.12.49154 > x.x.x.53: 19709+ A? . (40)
 16:05:17.038419 IP 10.35.255.10.49154 > x.x.x.53: 35638+ A? . (37)
 16:05:17.295820 IP 10.35.255.12.49154 > x.x.x.53: 19709+ A? . (40)

 (it also happens regularly, but not always for DNS lookups)

After several days of head scratching I'm at a loss.  Does anybody have
any ideas?


-Ronan
___
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] Site to Site VPN

[Mohammad Khalil]

hi all 

thanks for your support

the problem seemed that the VPN was retested from a side and the SA association 
from the other end 

> Date: Mon, 9 Aug 2010 15:16:04 +0200
> From: jma...@loplof.de
> To: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] Site to Site VPN
> 
> On Mon, Aug 09, 2010 at 01:40:14PM +0300, Mohammad Khalil wrote:
> > thanks for the response 
> > now man i have another issue is that the show crypto isakmp sa is showing 
> > that the tunnel is up QM_IDLE
> > but i cannot ping the other side and it was working normally 
> > and i see in the log message that there is "it is temporarly disabled due 
> > to recursive routing"
> 
> I've never seen this message in combination with IPSEC so far, but with
> GRE that meant the system was now trying to reach the tunnel endpoint
> by sending the traffic *into* the tunnel. Could be the same for this
> scenario?
> 
> Ciao
> Joerg
> -- 
> Joerg Mayer   
> We are stuck with technology when what we really want is just stuff that
> works. Some say that should read Microsoft instead of technology.
> ___
> 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] Blocking IPv6 on WiSM?

[Phil Mayers]

On 09/08/10 14:13, Joerg Mayer wrote:

On Mon, Aug 09, 2010 at 12:20:26PM +0100, Phil Mayers wrote:

At this point, I'd settle for a firmware upgrade that drops all packets
with ethertype=0x86dd. I have a very hard time believing the hardware
can't do that...


As this would be done by the CPU, this is not a missing HW feature but
a missing SW feature. And Cisco's BU that's responsible for the WiSM seems


Sure.


to care very little about IPv6. We run a production dual stack network
and our hackaround regarding the missing RA guard is just horrible (but
working).


Can you share any details?
___
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] 2 IOS DHCP Questions

[Jeff Wojciechowski]

I will check this out when I get caught up.

Thanks much,

-Jeff

From: arvindc.cisconsp cisco [mailto:arvindc.cisco...@gmail.com]
Sent: Friday, August 06, 2010 6:04 PM
To: Jeff Wojciechowski
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] 2 IOS DHCP Questions

1) AFAIK setting option 1 is not supported on Cisco routers.

That said, one workaround I could think of was to use the correct windows 
settings to disable NetBIOS over TCP/IP on the host stack 
http://support.microsoft.com/kb/313314

If you have a scaled setup, you could deploy this change using a group policy 
and push it out to all your clients assuming they are all a part of a single 
domain etc etc.

2) With a Windows DNS Server, the client "registers" by writing its address 
into the DNS file. With the Cisco router serving up addresses there is no such 
"file". You can either script out something that looks periodically at the 
routers show commands and inserts / deletes appropriate entries into the DNS 
server.

Take a look at Dynamic DNS 
http://www.cisco.com/en/US/docs/ios/12_3/12_3y/12_3ya8/gt_ddns.html to see if 
it fits your bill / requirements. (assuming your server supports DynamicDNS).

my 2c
Arvind

On Fri, Aug 6, 2010 at 4:52 PM, Jeff Wojciechowski 
mailto:jeff.wojciechow...@midlandpaper.com>>
 wrote:
All:


1)  This one seems easy but not sure what I am doing wrong - I want to have 
my 2801 routers feed windows clients DHCP option 0001 with a value of 0x2 to 
disable NetBIOS using DHCP

a.   Tried several variations of "option 1 hex 0x0002" in the dhcp pool 
config

b.  Error message I get back is "% DHCP does not allow raw option 1"

c.   (MS DHCP server says this option is for Win2k but if at all possible I 
want all NetBIOS gone so open to other ideas)

2)  I would like the same windows DHCP clients of the 2801 routers to 
"register in dns" with the dns servers they are learning via DHCP. When we ran 
centralized DHCP/DNS on the same 2008 servers, we had no issue with this. Now 
that DHCP resides on each local site on the router none of the pcs register in 
DNS.

Pool configuration for both above is:

ip dhcp pool 0
  network X.X.X.0 255.255.255.0
  default-router X.X.X.X
  dns-server X.X.X.X X.X.X.X
  domain-name *our domain name - just added this option this afternoon at my 
test site but haven't had anyone have time to reboot their pc yet

Router specs:
2801 running 12.4(22)T3

Thanks ahead of time for any and all insight...

Jeff



This electronic mail (including any attachments) may contain information that 
is privileged, confidential, or otherwise protected from disclosure to anyone 
other than its intended recipient(s). Any dissemination or use of this 
electronic mail or its contents (including any attachments) by persons other 
than the intended recipient(s) is strictly prohibited. If you have received 
this message in error, please delete the original message in its entirety 
(including any attachments) and notify us immediately by reply email so that we 
may correct our internal records. Midland Paper Company accepts no 
responsibility for any loss or damage from use of this electronic mail, 
including any damage resulting from a computer virus.
___
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 electronic mail (including any attachments) may contain information that 
is privileged, confidential, or otherwise protected from disclosure to anyone 
other than its intended recipient(s). Any dissemination or use of this 
electronic mail or its contents (including any attachments) by persons other 
than the intended recipient(s) is strictly prohibited. If you have received 
this message in error, please delete the original message in its entirety 
(including any attachments) and notify us immediately by reply email so that we 
may correct our internal records. Midland Paper Company accepts no 
responsibility for any loss or damage from use of this electronic mail, 
including any damage resulting from a computer virus.
___
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] Site to Site VPN

[Florin Florian]

Hi,

When the best path to the tunnel destination is via the tunnel itself,
recursive routing causes the tunnel interface to flap. To avoid recursive
routing problem, use static routes to override the first hop.

You can add a static route at the remote site to the corporate peer via the
Internet gateway. This route will be more specific then the learned network
route so it took precedence and the tunnel will be stable.

Good luck !

fflorin

On Mon, Aug 9, 2010 at 6:40 AM, Mohammad Khalil wrote:

>
> hey man
>
> thanks for the response
> now man i have another issue is that the show crypto isakmp sa is showing
> that the tunnel is up QM_IDLE
> but i cannot ping the other side and it was working normally
> and i see in the log message that there is "it is temporarly disabled due
> to recursive routing"
>
> Date: Mon, 9 Aug 2010 11:42:05 +0200
> From: jan.gre...@chronix.org
> To: cisco-nsp@puck.nether.net
> Subject: Re: [c-nsp] Site to Site VPN
>
> Hi,
>
> > what is the possible solution to solve this issue ?
> > IKE message from x.x.x.x has no SA and is not an initialization offer
>
> Probably reset of VPN on the other side. This message is commonly seen a
> when one side of vpn reloads. The other side just does not know that
> association is not valid any more.
> If this is persistent problem and the VPN cannot establish itself, then
> capture some debugs a sent them in, just this error message is not
> sufficient to draw any conclusions. Otherwise just ignore it, it is
> correct behaviour.
>
> Best regards,
>
> Jan
>
>
>  ___
> 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] Site to Site VPN

[Joerg Mayer]

On Mon, Aug 09, 2010 at 01:40:14PM +0300, Mohammad Khalil wrote:
> thanks for the response 
> now man i have another issue is that the show crypto isakmp sa is showing 
> that the tunnel is up QM_IDLE
> but i cannot ping the other side and it was working normally 
> and i see in the log message that there is "it is temporarly disabled due to 
> recursive routing"

I've never seen this message in combination with IPSEC so far, but with
GRE that meant the system was now trying to reach the tunnel endpoint
by sending the traffic *into* the tunnel. Could be the same for this
scenario?

Ciao
Joerg
-- 
Joerg Mayer   
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
___
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] Blocking IPv6 on WiSM?

[Joerg Mayer]

On Mon, Aug 09, 2010 at 12:20:26PM +0100, Phil Mayers wrote:
> At this point, I'd settle for a firmware upgrade that drops all packets  
> with ethertype=0x86dd. I have a very hard time believing the hardware  
> can't do that...

As this would be done by the CPU, this is not a missing HW feature but
a missing SW feature. And Cisco's BU that's responsible for the WiSM seems
to care very little about IPv6. We run a production dual stack network
and our hackaround regarding the missing RA guard is just horrible (but
working).

Ciao
Joerg
-- 
Joerg Mayer   
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
___
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] Bundling ports on different WS6704 linecards

[Phil Mayers]

On 09/08/10 08:47, Rin wrote:

Hi group,



We are building a Core network of 3 7609 routers connecting as a 40Gbps
ring. On each router we have 4 WS6704 linecards. Each router will be
connected to other routers via 4 10G-links, these links will be configured
as Port-Channel.



Should we place each link of the port-channel on different linecard on each
router or should we allocate all 4 links on the same linecard? Anyone has
any problem with configuring etherchannel for ports on different WS6704
linecards?


We do that extensively. It works fine. It is better to have 
cross-linecard portchannels in general.


HOWEVER - there are a couple of caveats to be aware of. One is if you've 
got different linecards with different QoS queuing, you will need:


int PoX
 no mls qos channel-consistency

Second is that there are some issues with cross-linecard portchannels if 
you have service modules (ACE, FWSM, WiSM) in the chassis. I can't 
remember the details or find the link at the moment.

___
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] Blocking IPv6 on WiSM?

[Phil Mayers]

On 09/08/10 06:06, Tristan Gulyas wrote:

Hi,


Until RA Guard + DHCPv6 Snooping become routinely available in
Ethernet switches, managing this kind of problem will be hectic at
best.



We currently implement an ACL on our 3750 switches (ipbase) which can
block router advertisements and we find this to be very effective.
We haven't done anything for DHCPv6 however few clients support
this.

Unfortunately we have yet to deal with clients on the wireless side.
There's no IPv6 support coming for the WiSMs/WLCs till Q1 2011 as far
as I know (but have not heard anything definitive).  One solution to
drop RAs would be to disable peer to peer communication however this
may break other applications such as voip and video (not ideal when
you have lots of students rocking up on campus who try to make
FaceTime calls!).

Phil - you are correct by stating that IPv6 disables VLAN steering
which is the same reason that our wireless (and load balancing)
services are the only things that don't currently talk native IPv6.
We're waiting on the same thing - Cisco to ship something IPv6
native.


At this point, I'd settle for a firmware upgrade that drops all packets 
with ethertype=0x86dd. I have a very hard time believing the hardware 
can't do 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] Site to Site VPN

[Mohammad Khalil]

hey man 

thanks for the response 
now man i have another issue is that the show crypto isakmp sa is showing that 
the tunnel is up QM_IDLE
but i cannot ping the other side and it was working normally 
and i see in the log message that there is "it is temporarly disabled due to 
recursive routing"

Date: Mon, 9 Aug 2010 11:42:05 +0200
From: jan.gre...@chronix.org
To: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] Site to Site VPN

Hi,
 
> what is the possible solution to solve this issue ?
> IKE message from x.x.x.x has no SA and is not an initialization offer
 
Probably reset of VPN on the other side. This message is commonly seen a
when one side of vpn reloads. The other side just does not know that
association is not valid any more.
If this is persistent problem and the VPN cannot establish itself, then
capture some debugs a sent them in, just this error message is not
sufficient to draw any conclusions. Otherwise just ignore it, it is
correct behaviour.
 
Best regards,
 
Jan
 

___
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] Site to Site VPN

[Jan Gregor]

Hi,

> what is the possible solution to solve this issue ?
> IKE message from x.x.x.x has no SA and is not an initialization offer

Probably reset of VPN on the other side. This message is commonly seen a
when one side of vpn reloads. The other side just does not know that
association is not valid any more.
If this is persistent problem and the VPN cannot establish itself, then
capture some debugs a sent them in, just this error message is not
sufficient to draw any conclusions. Otherwise just ignore it, it is
correct behaviour.

Best regards,

Jan



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

[c-nsp] Site to Site VPN

[Mohammad Khalil]

what is the possible solution to solve this issue ?
IKE message from x.x.x.x has no SA and is not an initialization offer

Best Regards,
  
___
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] Bundling ports on different WS6704 linecards

[Mark Tinka]

On Monday, August 09, 2010 03:47:06 pm Rin wrote:

> Should we place each link of the port-channel on
> different linecard on each router or should we allocate
> all 4 links on the same linecard? Anyone has any problem
> with configuring etherchannel for ports on different
> WS6704 linecards?

General practice (I'd imagine) would be to distribute the 
member links across different slots, in case you lose a 
single line card.

We have some WS-X6708's, but haven't run 802.1AX on them 
yet. However, we've had no issues with this design on the 
Gig-E line cards.

Cheers,

Mark.


signature.asc
Description: This is a digitally signed message part.
___
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] Bundling ports on different WS6704 linecards

[Rin]

Hi group, 

 

We are building a Core network of 3 7609 routers connecting as a 40Gbps
ring. On each router we have 4 WS6704 linecards. Each router will be
connected to other routers via 4 10G-links, these links will be configured
as Port-Channel. 

 

Should we place each link of the port-channel on different linecard on each
router or should we allocate all 4 links on the same linecard? Anyone has
any problem with configuring etherchannel for ports on different WS6704
linecards? 

 

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/