[nsp] Policy routing .. Cisco-6006

[Tim Stevenson]

Well, before I tried anything else, your 1st problem may be that you are running 12.0(7)XE1 (!!!!) which is *incredibly* ancient code, and also one of the very 1st releases for the platform.. Before anything else, I would move to more recent code (12.1E based), and see if the problem still exists. 

The 3-5 hr timeframe suggests ARP (to me). There were several bugs relating to ARP and the MLS cache in old code, you could very well be hitting one of them.

Note that PBR is in s/w by default on this platform. Not sure what perf you need, if you want to do PBR in h/w in sup1, you need the mls ip pbr command. There are some caveats with this command due to the flow-based nature of sup1.

Tim

At 06:53 PM 3/17/2004, cisco-nsp-request at puck.nether.net announced:
>Message: 2
>Date: Wed, 17 Mar 2004 14:19:12 -0500
>From: "MGG" <hiruy at comcast.net>
>Subject: [nsp] Policy routing .. Cisco-6006
>To: <cisco-nsp at puck.nether.net>
>Message-ID:
>     <FD1B6DC5FFF43C4888DCC155FE8C1FFEC8A060 at 7xch10ka.sevenspace.local>
>Content-Type: text/plain;     charset="us-ascii"
>
>Dear all,
>
>We are trying to transition our VPN network from the old Netscreen to the
>newer faster model.  Currently we are supporting 30+ networks and the plan
>is to cut-over one network at a time without making any changes to the
>remote side (especially peer gateway IP).  The old Netscreen is connected to
>Cisco 6006 w/MSFC1 which serves as a gateway to the internet. 
>
>The approach we have taken is to use policy-route.  We place the new
>Netscreen behind a temp-router (C3640) using the same subnet/IP address as
>the old one.  The inbound traffic which matches ACL is directed to the
>router's 2nd interface which is directly connected to Cisco-6006. 
>
>ISP --> [C6006] --------------> OLD Netscreen-----|   
>               |
>|----internal network
>               |---->[C3640] ---> New Netscreen ----|   
>
>Well everything works fine and we have managed to cut-over few networks
>already.  The problem we have is once in awhile [say every 3-5 hours] users
>behind the new network will lose their connection (VPN drops off) for few
>seconds while the users behind the new users stay up. I have done some
>troubleshooting and have not been able to find the problem and the
>intermittent nature of the problem makes it difficult to debug and isolate
>the problem.  I was wondering if anyone had seen this problem before.  Any
>tweaks, suggestions you can offer is very much appreciated!
>
>Here is the abbreviated and sanitized version of the config to protect the
>innocent (me ;-) ) 
>
>---------------------------------------
>interface Vlan15 [ISP uplink]
>  ip address <ISP Facing WAN IP> 
>  ip access-group BlockRFC1918 in
>  no ip directed-broadcast
>  ip route-cache policy
>  ip policy route-map RouteToNewVPN
>  no cdp enable
>end
>
>Extended IP access list EverythingElse
>    permit ip any any 
>
>Extended IP access list NewVPN
>    permit udp host <remote-VPN ip> host <local-VPN IP> eq isakmp 
>    permit esp host <remote-VPN ip> host <local-VPN IP> 
>    permit icmp host <remote-VPN ip> host <local-VPN IP> 
> 
>route-map Route-To-New-VPN permit 10
> match ip address NewVPN
> set ip next-hop <IP Address of 3640>
>!
>route-map Route-To-New-VPN deny 20
> match ip address EverythingElse
>
>"show ver"  --- snippet --- 
>
>IOS (tm) MSFC Software (C6MSFC-IS-M), Version 12.0(7)XE1
>cisco Cat6k-MSFC (R5000) processor with 122880K/8192K bytes of memory.
>R5000 CPU at 200Mhz, Implementation 35, Rev 2.1, 512KB L2 Cache
>Bridging software.
>X.25 software, Version 3.0.0.
>6 Virtual Ethernet/IEEE 802.3  interface(s)
>123K bytes of non-volatile configuration memory.
>4096K bytes of packet SRAM memory.
>
>
>-MGG.


Tim Stevenson, tstevens at cisco.com
Routing & Switching CCIE #5561
Technical Marketing Engineer, Catalyst 6500
Cisco Systems, 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.