[nsp] L2tp into VRF

[Steven Godfrey]

Hi,
I'm facing a problem terminating an L2TP tunnel in a vrf.

The end user connection I can push in to a vrf no problem but I actually want the L2TP tunnel to terminate in a vrf.

The Tunnel source is a 3rd party and I want to control this access in a vrf. As the remote users connect they are pushed in to the
relevant VRF via a RADIUS attribute.

If I move the interface that the tunnel arrives on in to a VRF the router responds with the correct address from the VRF but then
looks in the Global routing table to route the reply to the tunnel set up.

Has anyone resolved this issue in the past?

I have copied some of the debug below..


(PPP Enduser)---(3rd Party)---L2TP---(My LNS)

The config looks like this:

ip vrf 3rd-Party
 rd 9090:12
 route-target export 9090:12
 route-target import 9090:12
!
ip vrf DYNAMIC-VRF
 rd 1:42
 route-target export 11:11
 route-target import 22:22
!
vpdn-group INTECH
 accept-dialin
  protocol l2tp
  virtual-template 1
 terminate-from hostname LAC
 local name LNS
 source-ip 10.12.13.15
!
interface Loopback45
 ip vrf forwarding 3rd-Party
 ip address 10.12.13.15 255.255.255.255
!
interface FastEthernet0/0
 ip vrf forwarding 3rd-Party
 ip address 12.12.12.6 255.255.255.252
 speed auto
 full-duplex
 no cdp enable
!
interface Virtual-Template1
 ip unnumbered Loopback0
 ip broadcast-address 0.0.0.0
 no peer default ip address
 ppp authentication chap
 ppp chap hostname LNS


The packet debugging:
*Mar 12 23:04:00.332: IP: s=10.12.13.15 (local), d=10.12.13.14, len 178, cef process switched
*Mar 12 23:04:00.332: IP: s=10.12.13.15 (local), d=10.12.13.14, len 178, unroutable
*Mar 12 23:04:06.356: IP: s=10.12.13.15 (local), d=10.12.13.14, len 178, cef process switched
*Mar 12 23:04:06.356: IP: s=10.12.13.15 (local), d=10.12.13.14, len 178, unroutable

VPDN Debugging:
*Mar 12 22:59:51.092:   Tnl34012 L2TP: New tunnel created for remote LAC, address 10.12.13.14
*Mar 12 22:59:51.092:   Tnl34012 L2TP: O SCCRP  to LAC tnlid 61367
*Mar 12 22:59:51.092:   Tnl34012 L2TP: Control channel retransmit delay set to 1 seconds
*Mar 12 22:59:51.092:   Tnl34012 L2TP: Tunnel state change from idle to wait-ctl-reply
*Mar 12 22:59:52.088: L2TP: I SCCRQ from LAC tnl 61367
*Mar 12 22:59:52.088:   Tnl34012 L2TP: Tunnel exists, must be a duplicate SCCRQ
*Mar 12 22:59:52.092:   Tnl34012 L2TP: O Resend SCCRP, flg TLS, ver 2, len 150, tnl 61367, cl 0, ns 0, nr 1
*Mar 12 22:59:52.092:   Tnl34012 L2TP: Control channel retransmit delay set to 2 seconds
*Mar 12 22:59:54.088: L2TP: I SCCRQ from LAC tnl 61367
*Mar 12 22:59:54.088:   Tnl34012 L2TP: Tunnel exists, must be a duplicate SCCRQ
*Mar 12 22:59:54.092:   Tnl34012 L2TP: O Resend SCCRP, flg TLS, ver 2, len 150, tnl 61367, cl 0, ns 0, nr 1
*Mar 12 22:59:54.092:   Tnl34012 L2TP: Control channel retransmit delay set to 4 secondsL2X: Result code(2): 2: General error -
refer to error code
*Mar 12 22:59:58.088:      Error code(6): Vendor specific
*Mar 12 22:59:58.088:      Optional msg: Too many retransmits
*Mar 12 22:59:58.088:   Tnl34012 L2TP: Shutdown tunnel
*Mar 12 22:59:58.088:   Tnl34012 L2TP: Tunnel state change from wait-ctl-reply to idle
*Mar 12 23:00:00.116: L2TP: I SCCRQ from LAC tnl 14130
*Mar 12 23:00:00.116:   Tnl18265 L2TP: Got a challenge in SCCRQ, LAC

etc etc..

thanks in advance..

Regards,

Steven Godfrey


_____________________________________________________________________
This message has been checked for all known viruses by the 
CitC Virus Scanning Service powered by SkyLabs. For further information visit
http://www.citc.it