06-17-2018 12:22 PM - edited 03-05-2019 10:36 AM
Hi all.
I'm trying to establish a GRE tunnel between two sites.
I'm using a cisco 2800 on each end. Each cisco router is behind a home broadband modem.
I've managed to get the tunnels up. Each router can ping each other. and some devices on one end can ping others, but it seems to be a one way ping at this stage with other devices not being able to ping in the opposite direction towards the B site.
Thought it might be a routing issue. Was just wondering if anyone would'nt mind checking my config.
Thankyou
Router A
Building configuration...
Current configuration : 2852 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
hostname SITE A
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
!
no ip domain lookup
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
interface Loopback0
no ip address
!
interface Tunnel0
ip address 172.16.1.1 255.255.255.0
tunnel source 192.168.1.8
tunnel destination 102.XXX.XXX.XX
!
interface FastEthernet0/0
ip address 192.168.1.8 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet0/1
no ip address
shutdown
duplex auto
speed auto
!
interface Serial0/0/0
no ip address
shutdown
clock rate 2016000
!
interface Serial0/0/1
no ip address
shutdown
clock rate 2016000
!
interface Serial0/0/2
no ip address
shutdown
clock rate 2016000
!
interface Serial0/0/3
no ip address
shutdown
clock rate 2016000
!
ip default-gateway 192.168.1.1
no ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 192.168.1.1
ip route 10.1.1.0 255.255.255.0 172.16.1.2
!
!
!
line con 0
login local
speed 115200
line aux 0
line vty 0 4
login local
!
!
end
---------------------------------Router B---------------------------------------
Current configuration : 1242 bytes
!
! Last configuration change at 18:30:06 UTC Sun Jun 17 2018 by admin
version 15.1
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname SITE B
!
boot-start-marker
boot-end-marker
!
!
!
no aaa new-model
!
!
dot11 syslog
ip source-route
!
!
ip cef
!
!
!
no ip domain lookup
no ipv6 cef
!
multilink bundle-name authenticated
!
!
!
!
!
!
!
!
!
!
!
crypto pki token default removal timeout 0
!
!
!
!
redundancy
!
!
!
!
!
!
!
!
!
!
interface Tunnel0
ip address 172.16.1.2 255.255.255.0
tunnel source 10.1.1.100
tunnel destination 203.XX.XXX.XX
!
interface FastEthernet0/0
ip address 10.1.1.100 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet0/1
no ip address
duplex auto
speed auto
!
ip default-gateway 10.1.1.1
ip forward-protocol nd
no ip http server
no ip http secure-server
!
!
ip route 0.0.0.0 0.0.0.0 10.1.1.1
ip route 192.168.1.0 255.255.255.0 172.16.1.1
!
!
!
!
!
!
!
control-plane
!
!
!
!
mgcp profile default
!
!
!
!
!
!
line con 0
line aux 0
line vty 0 4
login local
transport input telnet
!
scheduler allocate 20000 1000
end
Solved! Go to Solution.
06-20-2018 08:14 AM
It would be interesting to see if the behavior changes is you did change it so that the broadband modem was on one interface and the LAN was on a different interface. Doing this would mean that you will need one subnet for the connection of router and broadband modem and another subnet for the LAN.
Am I correct in understanding that at this point the main issue is that phones are not registering for SIP over the tunnel? I wonder if that might be an issue with MTU? When you send traffic over a GRE tunnel it does add some bytes to each packet and sometimes that does create MTU issues. Perhaps you might configure a smaller MTU for the tunnel and see if the behavior changes.
HTH
Rick
06-17-2018 01:52 PM
Hi
Are you trying to reach the broadcast interface?
Site A
interface FastEthernet0/0
ip address 192.168.1.8 255.255.255.0
Site B
interface FastEthernet0/0
ip address 10.1.1.100 255.255.255.0
Usually these interfaces are connected to the external network, so you should try reach a LAN behind of these routers.
Try using the Tunnel interface instead the next hop IP, I have never made it but you can try.
Site A
ip route 10.1.1.0 255.255.255.0 tunnel0
Site B
ip route 192.168.1.0 255.255.255.0 tunnel0
:-)
06-18-2018 12:29 PM
06-18-2018 01:20 PM
This environment is somewhat unusual and we do not know enough about it to give really good answers. Perhaps as we learn more about it we may get to what is causing the issue. As Julio suggests most of the time the router has an interface for the LAN (the "inside" network) and another interface for the WAN (path to the "outside" and the remote peer). But these configs have a single interface with a network and the path to outside is an IP on the inside network. This raises questions about the topology of the network. How is the router connected to the broadband modem? And how are hosts connected to the router? Are we to assume that hosts send their outbound traffic to the router which then forwards it to the broadband modem? I would think in that case the router would send ip redirect and the hosts might wind up sending their traffic directly to the broadband modem.
There is one thing about this config that is quite unusual. Most of the time when you configure a GRE tunnel the source and destination addresses match up between the peers (the source address on one peer is the destination address of the other peer). But this config uses the local private address as the source and the remote public address as the destination. It makes me wonder how the broadband modem reacts when it receives an IP packet with its own address as the destination. Is there some port forwarding set up so that it forwards the GRE to the router?
HTH
Rick
06-19-2018 10:21 AM
Hi, Thanks for your reply.
This is the first time i've tried setting up a tunnel.
Yes, both the router and modem are connected to each other over a switch, with other devices as well, laptops, ip phones ect. This is the same on both sites, except on one site where ethernet over power line adapters are in use between the switch and the modem.
Just strange how the phones must not like jumping hoops through this kind of setup when registering on a SIP server.
Do you think it might run better if the modem was connected to router interface FA0/0 and the switch connected to FA0/1 so they're on separate interfaces?
You might be right about the route redirects, as I have seen them occasionally during ping tests.
I tried port forwarding on ports 1723, 47 with UDP/TCP on each end of the tunnel and forwarded to the routers IP.
Strangly enough, even with these ports closed, the tunnel is still maintaining?
I added a keep alive command on both routers as I noticed the tunnel would shut down after a period of time, and only remained open if I performed ping tests. I kept this command on one end eventually as the tunnel would go down if the command was on both ends.
06-20-2018 12:37 AM - edited 06-20-2018 12:41 AM
Hello
Are these the only addresses you are trying to ping through the tunnel
Rtr1
source 172.16.1.0/24or 192.169.1.0/24
dest 172.16.1.0/24 or 10.1.1.0/24
rtr2
source 172.16.1.0/24 or 10.1.1.0/24
dest 172.16.1.0/24 or 192.168.1.0/24
res
Paul
06-20-2018 08:14 AM
It would be interesting to see if the behavior changes is you did change it so that the broadband modem was on one interface and the LAN was on a different interface. Doing this would mean that you will need one subnet for the connection of router and broadband modem and another subnet for the LAN.
Am I correct in understanding that at this point the main issue is that phones are not registering for SIP over the tunnel? I wonder if that might be an issue with MTU? When you send traffic over a GRE tunnel it does add some bytes to each packet and sometimes that does create MTU issues. Perhaps you might configure a smaller MTU for the tunnel and see if the behavior changes.
HTH
Rick
06-25-2018 03:20 AM
Thanks Richard, you were correct. I took a stab in the dark and I changed the MTU size on each tunnel interface to 500 and it worked.
The phone registered over the tunnel to the PBX.
Only problem is sometimes the tunnel won't self initiate after a reboot or power failure for example.
I find that if i remove the KEEPALIVE command from the tunnel on the main site router, then the tunnel picks up again immediately. But will then shut down after about 5 or ten minutes?
The keep alive interval is set to "15" at the moment as I just changed it. I think it was set to "5 4" previously.
06-25-2018 06:30 AM
I am glad to know that you have resolved the issue by setting the MTU smaller and that my suggestion pointed you in the right direction. Thank you for marking this question as solved. This will help other readers in the forum to identify discussions that have helpful information.
It is surprising that sometimes the tunnel will not self initiate. With an IPSEC tunnel it is normal that the tunnel will not come up until there is interesting traffic to send through the tunnel. But with GRE tunnel it should not be dependent on having interesting traffic to send. There is one thing to be aware of about GRE tunnels. When you configure keep alive on the tunnel then it is dependent on having end to end connectivity. If you send traffic through the tunnel (a keep alive packet) and receive a response then the tunnel goes into the up state. But if sending traffic and receiving a response is not successful then the GRE tunnel goes into the down state.
I am not clear when you describe the tunnel as shutting down whether you mean that the tunnel goes into the down state or do you mean simply that the tunnel does not successfully transmit traffic? Especially thinking about your comment in a previous post that you had to keep a ping running to keep the tunnel up I wonder if there is an issue that something along the path is timing out (perhaps something like an arp entry) and that keeping a flow of traffic through the tunnel keeps that entry active.
HTH
Rick
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide