cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
756
Views
0
Helpful
8
Replies

site-to-site by GRE tunnel with ADSL

ccnpccnp77
Level 1
Level 1

i have a VPDN ADSL line which gets fixed IP 192.168.104.85,gw:196.168.150.1(1841 router connects to ADSL modem by F0/1); it will connects to 10.10.12.5 which is my centeral cisco router. the VPDN is provided by my ISP. the remote site can access central successfully, but the central can't access the remote, and only access 192.168.104.85. so i am considering to use GRE tunnel for site-to-site access, but the tunnel interface on remote router's state flaps from up to down every 20 seconds, from down to up every 10 seconds. i don't know how to solve it, anybody help?

hostname C1800

logging buffered 51200 warnings

enable secret xxxx

!

!

mmi polling-interval 60

no mmi auto-configure

no mmi pvc

mmi snmp-timeout 180

ip subnet-zero

ip cef

vpdn enable

vpdn ip udp ignore checksum

vpdn-group pppoe

request-dialin

protocol pppoe

username xxxx privilege 15 secret xxxx

!

interface Tunnel0

ip address 10.200.200.2 255.255.255.0

no ip redirects

ip mtu 1492

tunnel source 192.168.104.85

tunnel destination 10.10.12.5

!

interface FastEthernet0/0

description $ETH-LAN$$ETH-SW-LAUNCH$$INTF-INFO-FE 0$

ip address 172.x.x.x.255.255.0

duplex auto

speed auto

!

interface FastEthernet0/1

no ip address

duplex auto

speed auto

pppoe enable

pppoe-client dial-pool-number 1

!

interface Dialer1

mtu 1492

ip address negotiated

encapsulation ppp

no ip mroute-cache

dialer pool 1

dialer-group 1

no cdp enable

ppp authentication pap callin

ppp pap sent-username xxxx password 0 xxxx

!

no ip classless

ip route 0.0.0.0 x.x.x.x.168.150.1

!

access-list 1 permit any

dialer-list 1 protocol ip permit

*Apr 19 07:51:35.991: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, c

hanged state to down

*Apr 19 07:51:45.991: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, c

hanged state to up

*Apr 19 07:52:05.991: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, c

hanged state to down

*Apr 19 07:52:15.991: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, c

hanged state to up

*Apr 19 07:52:35.991: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, c

hanged state to down

*Apr 19 07:52:45.991: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, c

hanged state to up

*Apr 19 07:53:05.991: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, c

hanged state to down

8 Replies 8

spremkumar
Level 9
Level 9

Hi

Do add a static ip route for the central site network on your router towards the tunnel interface so that the traffic destined to your central site can take the tunnel path.

ip route 10.10.12.0 255.255.255.0 tunnel0

The same way you need to route the branch router local network towards your tunnel interface there in your central site

ip route 172.168.124.0 255.255.255.0 tunnel0

Once you are done with this you will be able to ping both the lans..

regds

attrgautam
Level 5
Level 5

I think the tunnel is flapping because of recursive routing or if the pppoe is flapping. Is the connection stable or do u have any routes pointed to the tunnel ?

the connection is stable because i can always ping the remote router's Dialer1 192.168.104.85 from the central router.

from the remote router of 1841, i see that there are only incoming packets,but not any output packets. so strange.

Can you make it ip classless and check ? And as Edwin pointed out ensure you have the necessary routes to the tunnels.

As I look at the config I believe that the basic problem is, as Edwin suggests, the configuration of static routes on the router. Currently the configured default route sends all remote traffic to the routers next hop gateway:

ip route 0.0.0.0 x.x.x.x.168.150.1

unfortunately this bypasses the tunnel. This explains the difficulty with traffic going out of the router.

I would suggest that the configuration be changed so that the default route points to the remote end of the tunnel as its next hop. Probably it would be this:

ip route 0.0.0.0 0.0.0.0 10.200.200.1 (or whatever address is the other end)

I also suggest that a static route be added for the destination address of the tunnel:

ip route 10.10.12.5 255.255.255.255 192.168.150.1

This will assure that tunnel packets will be properly routed (otherwise there will be a recursive routing problem and the tunnel will not work).

HTH

Rick

HTH

Rick

thanks for your kind help. but i still failed after i configured as you suggest.

the tunnel interfaces at both ends were down even after i 'shu/no shut' them, but the Dialer interface at remote site and Serial int at central site are up. when should the interface be down and how to get them up?

hi

Is it possible for your to post out your central site configs ? i feel that may provide some vital info..

Also when both your interfaces are up connected on both the sides you can verify the connectivity between the locations using a simple ping to the destination ip which you configure in your tunnel config which can give some rough idea in narrowing down the possibilities involved..

regds