GRE

[andnagy122]

Hi guys,

I'm currently stucked with GRE, with the following topology:

Here's the config of R1 and R3 (R2 has only been configured with the proper IPs):

R1

!

ip address 192.168.1.1 255.255.255.252

tunnel source Loopback0

tunnel destination 172.16.11.1

!

ip route 172.16.11.0 255.255.255.0 200.40.49.1

!

R2

!

ip address 192.168.1.2 255.255.255.252

tunnel source Loopback0

tunnel destination 172.16.10.1

!
ip route 172.16.10.0 255.255.255.0 210.40.49.1

!

show int tunnel 1 output from R1:

Tunnel1 is up, line protocol is up

Internet address is 192.168.1.1/30

Tunnel source 172.16.10.1 (Loopback0), destination 172.16.11.1

Tunnel protocol/transport GRE/IP

Routing table on R1:

200.40.49.0/30 is subnetted, 1 subnets
C 200.40.49.0 is directly connected, FastEthernet0/0
172.16.0.0/24 is subnetted, 2 subnets
C 172.16.10.0 is directly connected, Loopback0
S 172.16.11.0 [1/0] via 200.40.49.1
192.168.1.0/30 is subnetted, 1 subnets
C 192.168.1.0 is directly connected, Tunnel1

show int tunnel 1 output from R3:

Tunnel1 is up, line protocol is up

Internet address is 192.168.1.2/30

Tunnel source 172.16.11.1 (Loopback0), destination 172.16.10.1

Tunnel protocol/transport GRE/IP

Routing table on R3:

172.16.0.0/24 is subnetted, 2 subnets
S 172.16.10.0 [1/0] via 210.40.49.1
C 172.16.11.0 is directly connected, Loopback0
210.40.49.0/30 is subnetted, 1 subnets
C 210.40.49.0 is directly connected, FastEthernet0/1
192.168.1.0/30 is subnetted, 1 subnets
C 192.168.1.0 is directly connected, Tunnel1

Traceroute from R1 to R3's loopback of 172.16.11.1:

Tracing the route to 172.16.11.1

1 200.40.49.1 48 msec 64 msec 64 msec
2 200.40.49.1 !H !H !H

At this point, I understand, that the problem is that R2 doesn't have an appropriate route for 172.16.11.0/24 and for 172.16.10.0/24.

I just don't understand it. Imagine that R2 represents a router of the ISP between R1 (Branch site) and R3 (HQ site).

As far as I know it should be enough to configure the GRE tunnel itself plus a route for the tunnel's destination and that's all.

I mean you can't configure all routers in the path towards the tunnel's destination (in this case 172.16.10.0/24 and 172.16.11.0/24).

But if it's the case, how could you establish a fully functioning path towards the destination?

I could configure static routes to the tunnels' destinations but R2 is owned by the ISP... In such a case, I don't think I should ask the ISP to configure the appropriate paths...

Could you advise me?

Thank you in advance :)

[paul driver]

Hello
Your statics are incorrect and it seems your interface addressing also!

The next hop addressing needs to be specific to the router subnet it is connecting to.

So something like this:

R1 = 210.41.49.1  connecting to R2 210.41.49.2
Lo0 = 172.16.10.1
ip route 172.16.11.3 255.255.255.255 210.41.49.2


R3 = 210.43.49.3  connecting to R2 210.43.49.2
Lo0 = 172.16.11.3
ip route 172.16.10.1 255.255.255.255 210.43.49.2

R2: 210.41.49.2  connecting to R1 210.41.49.1
R2: 210.43.49.2  connecting to R3 210.43.49.3

ip route 172.16.10.1 255.255.255.255 210.41.49.1
ip route 172.16.11.3 255.255.255.255 210.43.49.3

res
Paul

[andnagy122]

Hi again,

>> paul:

My IP addressing scheme is correct just because it could be somewhat more readable.

>> chrihussey:

yeah that's working!

I configured OSPF on both remote routers to advertise the loopback and tunnel subnets plus configured a static route to reach the respective physical subnets with next-hop of the neighboring router's IP.

What I still don't understand is:

what if there are many more routers classified as ISP routers between the remote sites (as is the case in real environments)?

What static route should I configure then? - as many more physical /30 subnets exist between the remote sites.

Anoher question:

What if I set the tunnel source and destination to the loopback interfaces?

I tried to advertise the loopback and tunnel subnets with OSPF and configured a static route to the respective physical subnet as previously, plus configured two static entries on R2 to reach the loopbacks as well (next-hop of the physical link's other end), but it didn't work.

Btw, thank you both for your help, very appreciated! :)

[chrihussey]

What I still don't understand is:

what if there are many more routers classified as ISP routers between the remote sites (as is the case in real environments)? RESPONSE: It should not matter how many ISP routers are between the remote sites. The connections to the ISP are using the ISP's space so the ISP should know how to get from one point to another. 

What static route should I configure then? - as many more physical /30 subnets exist between the remote sites. RESPONSE: You just need the default route to the ISP. As stated in the previous response. The ISP would be running an IGP of it's own and should know how to get from one IP to another on it's own network no matter how many routers there were.

Anoher question:

What if I set the tunnel source and destination to the loopback interfaces? RESPONSE: You could do this but it complicates things from an ISP perspective as the ISP would have to know and route to these interfaces on your router.

I tried to advertise the loopback and tunnel subnets with OSPF and configured a static route to the respective physical subnet as previously, plus configured two static entries on R2 to reach the loopbacks as well (next-hop of the physical link's other end), but it didn't work. RESPONSE: Once again you probably had recursive routing going on where the tunnel source and destinations were routed through the tunnel. This won't work.

[andnagy122]

Yeah so basically both of you state the same thing that the ISP should be aware of its own physical links between the two remote sites, therefore I only have to configure the GRE tunnel between the sites and it will work. It's logical, thank you :)

On the other side, chrihussey, is it then more practical to configure the tunnel source/dest to the physical interfaces' IPs on both ends towards each other, instead of using other interfaces?

[paul driver]

Hello
so basically both of you state the same thing that the ISP should be aware of its own physical links between the two remote sites, therefore I only have to configure the GRE tunnel between the sites and it will work. It's logical, thank you :

Yes correct - However they WONT beware of other prefixes like your loopbacks or lan subnets ,These you need to advertised to them OR inform them ot there awareness.

is it then more practical to configure the tunnel source/dest to the physical interfaces' IPs on both ends towards each other, instead of using other interfaces?

You obviously use both, But I would say using logical interlaces if applicable such has loopbacks is viable good practice, As physical interfaces tend to change/ flap or shutdown, but logical interfaces provides more stability for the interface to be in a constant up/up state

Then as long as there is routing between the src/dst addressing all is good

res
Paul

[chrihussey]

To add to Paul's comments, if an ISP has provided a block of Internet address space that they route to you, you could also use these IPs for the tunnel source and destinations.

[andnagy122]

Culd you please be so kind to write a sample config for the case when the tunnel source and destination are the loopbacks?

Then I think I would fully understand this thing.

Thank you.

[paul driver]

Hello

i already did - please review my previous posts!

res

paul

[paul driver]

Hello
Yes it is indeed it was somewhat confusing with the OP - Is this a production environment?, I guessed it wasn't seeing as you were configuring static routing everywhere, Hence why i posted you some sample configuration with static routing for GRE for the whole topology

As I explained the ISP or ISP's should be aware of all the routing between those two sites all what you needed to do was create the tunnel,Apply the correct scr/dst and tunnel addressing and the reachability to each others tunnel destination addressing will should be known by the ISPs providing they are made aware those prefixes, either via a statically defined route or dynamically via a routing protocol

But glad to hear it is working anyway

res
Paul