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

Routing issues

Areyouserious
Level 1
Level 1

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

1 Accepted Solution

Accepted Solutions

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

HTH

Rick

View solution in original post

8 Replies 8

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

 

:-)

 

 

 

 




>> Marcar como útil o contestado, si la respuesta resolvió la duda, esto ayuda a futuras consultas de otros miembros de la comunidad. <<

Hi thanks for your reply.

It's just strange.

The main reason for this GRE tunnel was to connect some IP phones from one
site to another.

The telephones is responding to pings from the SIP server, and I can access
the ip phone webpage's, but for some reason they won't register on the SIP
server. However the sip server can successfully ping the IP phone on the
remote site from the SIP server's command line on the main site. If I bring
those phones over to the main site and plug them in they work fine on the
network over here, just seems to be something wrong with the tunnel.
Unless of course GRE tunnels don't support SIP protocol?

I would like to experiment and see if an IPSEC Tunnel would make any
difference.

Richard Burts
Hall of Fame
Hall of Fame

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

HTH

Rick

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.

 

 

 

 

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


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

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

HTH

Rick

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.  

 

 

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

HTH

Rick
Review Cisco Networking products for a $25 gift card