Re: L2TP configuration on CISCO 871 - Page 2

mariov652 · ‎10-16-2009

Hi,

We've just taken charge of a new internet connection with a new service provider. Access is over a coaxial cable and the link is advertised to go upto 100Mbps. We have 2 ISP-provided modems that sync up and work fine.

However, I'd like to change the modems from 'router' to 'bridge' in order to move over some existing site-to-site VPN's from another provider (standard ADSL internet access) using existing CISCO 871's to continue providing the internet firewalling and VPN.

This works fine, except that, to allow us to use static IP Address, we need to create an L2TP tunnel to be assigned the static address (from the modem config).

I have the L2TP authentication and server details from the modem config.

The CISCO 871 is assigned a DHCP address to the WAN interface (fastethernet 4), however the L2TP tunnel does not come up correctly.

My current config is below and I'd appreciate if someone is able to point me in the right direction / documentation to set this up correctly:

interface FastEthernet4

description WAN interface to ISP

ip address dhcp

ip virtual-reassembly

load-interval 30

duplex auto

speed auto

interface Virtual-PPP1

description L2TP dialer to ISP

ip address negotiated

ip nat outside

ip virtual-reassembly

ppp pap sent-username xxxxx password 0 xxxxx

ppp ipcp dns request accept

pseudowire x.x.x.x 2 pw-class ISP

interface Vlan1

description Internal LAN

ip address y.y.y.y 255.255.255.0

ip nat inside

ip virtual-reassembly

ip route 0.0.0.0 0.0.0.0 Virtual-PPP1

ip route <l2tp server ip> 255.255.255.255 FastEthernet4

Thanks for any advice,

Mario

Giuseppe Larosa · ‎10-27-2009

Hello Mario,

only one point of attention:

you have disabled ip routing and then you use specific ip static routes.

I would expect you to be able to use

ip default-gateway

when ip routing is disabled.

Actually if you look at your own IP routing table when ip routing is disabled it shows you only the default-gateway as expected.

the ip static routes can be not effective when ip routing is disabled.

this may be a problem, I would enable ip routing again.

All other parts of your config look like fine.

Hope to help

Giuseppe

mariov652 · ‎10-27-2009

Hi Giuseppe,

The reason I had removed ip routing is because only once this was removed did I start to see the L2TP messages sent from my 871.

Removing the static routes to (except for the one to the L2TP server and the virtual-ppp1), the resulting routing table likes like:

Gateway of last resort is 85.171.16.1 to network 0.0.0.0

85.0.0.0/22 is subnetted, 1 subnets

C 85.171.16.0 is directly connected, FastEthernet4

212.198.0.0/32 is subnetted, 1 subnets

S 212.198.0.161 [254/0] via 85.171.16.1, FastEthernet4

195.132.16.0/32 is subnetted, 1 subnets

S 195.132.16.228 is directly connected, FastEthernet4

S* 0.0.0.0/0 [254/0] via 85.171.16.1

The 212.198.0.161 is assigned automatically.

I'll do some additional reading on routing to try and understand why the L2TP is sent out one way and not the other.

iaa_cisco · ‎10-27-2009

It's look like you get the public IP address from your ISP.Please issue command: "sh ip int b" , if your see on fastethernet4 IP address 85.171.19.151 yor'e connected and don't need virtual ppp.

P.S.

I can telnet your router on this IP!!!

85.171.19.151

mariov652 · ‎10-27-2009

Thanks and you are right, for the moment I've left things 'open' while I test to avoid having acl's and fw cause this problem. There is nothing connected behind the router yet and as it's DHCP this address wil change.

The reason I need virtual ppp is because we require a static ip. The ISP provides this to us by first assigning a DHCP address and then an L2TP session is established with a static IP address - This is the part which is not working.

This works fine with the ISP supplied modem, but so far not on our 871..

iaa_cisco · ‎10-27-2009

(The reason I need virtual ppp is because we require a static ip. The ISP provides this to us by first assigning a DHCP address and then an L2TP session is established with a static IP address - This is the part which is not working.)

-----------------------------------------

It's not necessarily have to be through L2TP.The ISP can assing you static ip address through DHCP(P2P) per modem mac address or something like that!

One more think .Do you spoke with ISP?

Ask them what you need to do for setup L2TP? What ip address terminate the L2TP connections?

In my case the cable company and ISP two deferent companies.In this situation the cable company jast teminate me and assign dynamic ip address, after that reroute me through VRF or MPLS to my ISP and then connection terminated with L2TP.

In you case, i guess the cable company and ISP is the same company and if you ask for static ip address they can provide you without any L2TP connection.

Try to clarify this!

iaa_cisco · ‎10-27-2009

One more think.

Connect your cable modem to computer and setup L2TP connection on computer.

If you success, something wrong in router config if not success, the ISP is not provide you L2TP service.

mariov652 · ‎10-29-2009

Firstly, yourself and Giuseppe have been a great source in helping me understand this better. Thank you so much to both of you.

Yes, I've tried speaking with the ISP and as this is not a more expensive 'business' service I keep getting the run-around, even though this is a line for a company. For now, I'm stuck with getting the static IP via L2TP unfortunately.

Since your last message though, it seems they must have changed something on their end. With the same config as before (with L2TP messages going back and forth, all of a sudden I began to receive ppp config-request messages from their LNS to my device!

Looking at the packets, I noticed requests for CHAP authentication and I changed the authentication on the virtual-ppp interface accordingly.

The virtual interface config now looks like this:

interface Virtual-PPP1

description L2TP dialer to ISP

ip address negotiated

ppp chap hostname xxxxxxxx

ppp chap password 0 xxxxxxx

ppp ipcp dns request accept

pseudowire 195.132.16.228 1 pw-class ISP

The virtual-ppp interface finally came up for the first time!

Unfortunately that's not the end of the story (although i think I'm pretty much 95% there)....

I mentioned before that I only noticed L2TP messages when I had ip routing removed and set a static default route to the ISP's router assigned via DHCP. Part of the trouble (even from the beginning of this post) seems to be the routing on my device. I'll explain:

[For both examples below, The DHCP assigned IP to Fa4 here at the time was 85.169.125.x/22; and the static IP assigned to the virtual-ppp interface is 212.198.x.x/32]

With the routing config below, (no static routes set), the virtual-ppp interface comes up and stays up.

myrouter#sh run | inc ip route

myrouter#

myrouter#sh ip route

....

Gateway of last resort is 85.169.124.1 to network 0.0.0.0

85.0.0.0/22 is subnetted, 1 subnets

C 85.169.124.0 is directly connected, FastEthernet4

212.198.x.x/32 is subnetted, 1 subnets

S 212.198.0.162 [254/0] via 85.169.124.1, FastEthernet4

195.132.16.0/32 is subnetted, 1 subnets

C 195.132.16.229 is directly connected, Virtual-PPP1

212.198.x.x/32 is subnetted, 1 subnets

C 212.198.x.x is directly connected, Virtual-PPP1

S* 0.0.0.0/0 [254/0] via 85.169.124.1

The route 195.132.16.229 via virtual-ppp1 above is the ISP 'router' for the L2TP tunnel in the same network as the LNS.

Traceroute to the LNS gives me

Tracing the route to 195.132.16.28

1 * * * --> The real IP obviously changes depending on the DHCP IP assigned.

2 81.67.2.33 8 msec 12 msec 12 msec

3 80.236.0.34 8 msec 8 msec 32 msec

4 212.198.4.x 12 msec 8 msec 12 msec

5 212.198.0.x 12 msec 12 msec 12 msec

myrouter#

When adding static routes as below, the virtual-ppp1 interfaces bounces up and down:

myrouter(config)#ip route 0.0.0.0 0.0.0.0 Virtual-PPP1

myrouter(config)#ip route 195.132.16.228 255.255.255.255 Fastethernet4

myrouter(config)#

*Oct 29 11:18:36.835: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-PPP1, changed state to down

myrouter#sh run | inc ip route

ip route 0.0.0.0 0.0.0.0 Virtual-PPP1

ip route 195.132.16.228 255.255.255.255 FastEthernet4

and then a few seconds later the routing changes to..

myrouter#sh ip route

Gateway of last resort is 85.169.124.1 to network 0.0.0.0

85.0.0.0/22 is subnetted, 1 subnets

C 85.169.124.0 is directly connected, FastEthernet4

212.198.x.x/32 is subnetted, 1 subnets

S 212.198.x.x [254/0] via 85.169.124.1, FastEthernet4

195.132.16.0/32 is subnetted, 1 subnets

S 195.132.16.228 is directly connected, FastEthernet4

S* 0.0.0.0/0 [254/0] via 85.169.124.1

I get the same result if I add a static route to the router in the L2TP tunnel (195.132.16.229)

mariov652 · ‎10-29-2009

Just to add to the above.

Immediately after the static routes are added, the routing table changes to:

Gateway of last resort is 0.0.0.0 to network 0.0.0.0

85.0.0.0/22 is subnetted, 1 subnets

C 85.169.124.0 is directly connected, FastEthernet4

212.198.0.0/32 is subnetted, 1 subnets

S 212.198.0.162 [254/0] via 85.169.124.1, FastEthernet4

195.132.16.0/32 is subnetted, 2 subnets

C 195.132.16.229 is directly connected, Virtual-PPP1

S 195.132.16.228 is directly connected, FastEthernet4

212.198.x.x/32 is subnetted, 1 subnets

C 212.198.x.x is directly connected, Virtual-PPP1

S* 0.0.0.0/0 is directly connected, Virtual-PPP1

Then, after a few seconds it looks like:

Gateway of last resort is 85.169.124.1 to network 0.0.0.0

85.0.0.0/22 is subnetted, 1 subnets

C 85.169.124.0 is directly connected, FastEthernet4

212.198.0.0/32 is subnetted, 1 subnets

S 212.198.0.162 [254/0] via 85.169.124.1, FastEthernet4

195.132.16.0/32 is subnetted, 1 subnets

C 195.132.16.229 is directly connected, Virtual-PPP1

212.198.x.x/32 is subnetted, 1 subnets

C 212.198.x.x is directly connected, Virtual-PPP1

S* 0.0.0.0/0 [254/0] via 85.169.124.1

and the virtual interface then remains down.

Is this normal behaviour?

iaa_cisco · ‎10-29-2009

Can you provide the output from show running-config?

mariov652 · ‎10-29-2009

Of course...

This is with no static routes and provides the virtual interface as up up

version 12.4

no service pad

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname myrouter

!

boot-start-marker

boot-end-marker

!

logging message-counter syslog

!

no aaa new-model

!

dot11 syslog

ip source-route

!

ip cef

no ipv6 cef

!

multilink bundle-name authenticated

!

archive

log config

hidekeys

!

pseudowire-class ISP

encapsulation l2tpv2

ip local interface FastEthernet4

!

interface FastEthernet0

duplex full

speed 100

!

interface FastEthernet1

!

interface FastEthernet2

!

interface FastEthernet3

!

interface FastEthernet4

description WAN interface to ISP

ip address dhcp

load-interval 30

speed 100

full-duplex

!

interface Virtual-PPP1

description L2TP dialer to ISP

ip address negotiated

ppp chap hostname xxxxxx

ppp chap password 0 xxxxxxx

ppp ipcp dns request accept

pseudowire 195.132.16.228 1 pw-class ISP

!

interface Vlan1

shutdown

!

ip forward-protocol nd

no ip http server

no ip http secure-server

!

no cdp run

!

!control-plane

!

iaa_cisco · ‎10-29-2009

You can surf the internet? Mean when the virtual-ppp connected .

mariov652 · ‎10-29-2009

Yes I have tested with ping, but this works only if the source address is Fa4. No access if I make the source address Virtual-PPP1.

Also, I can configure NAT for an internal device, but only for the Fa4 interface as "ip nat outside". Not for the Virtual interface - for the same reason as the ping failing I think.

Below is the current routing table:

Gateway of last resort is 85.169.124.1 to network 0.0.0.0

85.0.0.0/22 is subnetted, 1 subnets

C 85.169.124.0 is directly connected, FastEthernet4

212.198.0.0/32 is subnetted, 1 subnets

S 212.198.0.161 [254/0] via 85.169.124.1, FastEthernet4

195.132.16.0/32 is subnetted, 1 subnets

C 195.132.16.229 is directly connected, Virtual-PPP1

212.198.x.x/32 is subnetted, 1 subnets

C is directly connected, Virtual-PPP1

S* 0.0.0.0/0 [254/0] via 85.169.124.1

And, as above, if I add static 0.0.0.0 route to Virtual-PPP1, the interface goes down.

A screen-shot from the ISP modem is attached. This is where I got the L2TP details originally.

The modem is set in 'pass through mode' and the 871 connected to one of the ports.

I noticed the modem config have a check for RIP routing enabled (when in routing modem and not using the 871). I haven't configured RIP on the 871. Would this make a difference?

mariov652 · ‎10-29-2009

I'm going to spend some additional time learning / reading the various routing protocols.

I'm sure the answer is very close, I just need to spend some time and understand more deeply how the protocols work.

Once I understand that, and if I still need help I'll come back with a decent question.

If I'm able to work it out, I'll post back the solution.

Mario

mariov652 · ‎11-04-2009

Hi Giuseppe & iaa_cisco...

Ok, after much thought and a little holiday this is now working. The answer seems obvious, but it just took a little while to get there...

The biggest trouble was that I did not understand why the link would drop when I added the static IP routes, as explained in the previous messages.

It finally dawned that in order to keep the L2TP tunnel up, the route to the L2TP server needs to be available. The route I was adding for the L2TP server was not correct. I needed to add the remote gateway IP, which was assigned by DHCP, to the syntax.

So, my working config for receiving an IP via DHCP and then an L2TP tunnel for static IP is as follows (chap authentication in this case):

pseudowire-class ISP

encapsulation l2tpv2

ip local interface

!

interface FastEthernet4

description WAN interface to ISP

ip address dhcp

load-interval 30

!

interface Virtual-PPP1

description L2TP dialer to ISP

ip address negotiated

ppp chap hostname xxxxxxx

ppp chap password 0 xxxxxxxx

ppp ipcp dns request accept

pseudowire 1 pw-class ISP

!

ip route 0.0.0.0 0.0.0.0 Virtual-PPP1

ip route 255.255.255.255 dhcp --> This is where I was going wrong!

Thanks again for all the assistance along the way!

I hope somebody will be able to avoid going through the same pain by reading this thread sometime...

Ciao,

Giuseppe Larosa · ‎11-05-2009

Hello Mario,

this is good news and your findings makes sense.

Actually in my case the ip address on the physical interface is not assigned by DHCP.

Sorry for having missed this aspect of the issue.

I've rated your post with the working solution as it deserves.

Hope to help

Giuseppe