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
To establish GRE tunnel then the tunnel scr/dst addressing needs to reachable between peers, in this case R2 would be the hub router to perform this, if this was an ISP then it would no doubt have this information on where to forward the packets to and from due to possibly having a full Internet bgp table.

The two gre peers just require a default route pointing towards it hub rtr (R2)

as for the GRE addressing that does not need to known by the ISP (R2)

res
Paul

[andnagy122]

I'm not sure I understand you correctly, but if I'm right you said that the tunnel source and dest - in this case 192.168.1.1 and .2 - should be reachable by the GRE peers.

Following this logic, I configured one more static route:

on R1: ip route 192.168.1.2 255.255.255.255 200.40.49.1

on R3: ip route 192.168.1.1 255.255.255.255 210.40.49.1

but this didn't help as R2 still doesn't know about 192.168.1.1 and .2 and 172.16.10.0/24 and 172.16.11.0/24.

I don't want to configure a default route because the goal is to fully understand the concept behind GRE. In addition, by configuring a default route, R1 and R3 would have an appropriate route towards each other but R2 still wouldn't.

[paul driver]

Hello

in this case 192.168.1.1 and .2 - should be reachable by the GRE peers.

No - those are your tunnel addressing - What I am saying is the physical network of each rtr  and also the Source and Destination of the GRE peering needs to be reachable.

In your diagram, you are eventually going to create a "Tunnel " via the physical links and peer on the loopbacks so these addresses needs to be known by R2 (ISP)

It will be aware of the physical subnets of either spoke rtr as its already directly connected to them but it wont be aware of the loopbacks  - So these loopbacks need to be either advertised to R2 via a dyanmic routing protocol or have static routes applied to R2 to tell it where to go for those loopbacks

Now R2 is the "ISP" and knows where to route all packets sent to it.
R1/R3 also needs to know where to route packets not local it itself - So again taking your diagram into count

If R1/R3 has a simple static route pointing to R2 for each others loopbacks/physical address, R2 will then perform route table lookup and know that it needs to forward packets to each loopback of R1/R3 via its physical connected links.

As stated, this can be accomplish by simply adding an additional static route on R2 pointing towards each R1/R3 for their relative loopback addresses or enable dynamic routing protocol between all 3 rtrs and advertise (apart from the tunnel addressing) all prefixes.

Example:

rtr1
int lo0
ip address 1.1.1.1 255.255.255.255

int fa0/0
description Link to R2 (ISP)
ip address  172.16.10.1 255.255.255.0

In tun 1
description GRE to R3
ip address 192.168.1.1 255.255.255.0
tunnel source loopback 0
tunnel destination 2.2.2.2

ip route 2.2.2.2 255.255.255.255 172.16.10.2



rtr2
int fa0/0
description Link to R1
ip address 172.16.10.2 255.255.255.0

int fa0/1
description Link to R3
ip address  172.16.11.2 255.255.255.0

ip route 1.1.1.1 255.255.255.255 172.16.10.1
ip route 2.2.2.2 255.255.255.255 172.16.11.3

rtr3
int lo0
ip address 2.2.2.2 255.255.255.255

int fa0/1
description Link to R2 (ISP)
ip address 172.16.11.3 255.255.255.0

In tun 1
description GRE to R1
ip address 192.168.1.3 255.255.255.0
tunnel source loopback 0
tunnel destination 1.1.1.1

ip route 1.1.1.1 255.255.255.255 172.16.11.2


res
Paul

[andnagy122]

I configured it but it doesn't work.

By issuing a traceroute from 172.16.10.1 to 172.16.11.1 you can see that the traffic flows through the physical links as without a GRE tunnel in place.

By tracing 192.168.1.1 and .2, you can see that the traffic uses one hop, as usual when using a GRE tunnel.

[paul driver]

Hello
You need to amend it to your own exiting config.

If you are using the exact config I posted then you will also need a static route at each spoke site pointing to the other isp facing subnet or default default static and then point your gre addressing and any other traffic you wish to reach through the tunnel

rtr1
ip route 2.2.2.2 255.255.255.255 172.16.10.2
ip route 172.16.11.0 255.255.255.0 172.16.10.2
or
ip route 0.0.0.0 0.0.0.0 172.16.10.2
ip route 192.168.1.0 255.255.255.0 Tunnel1<--this says -"to get to this subnet go via the gre tunnel"
ip route 133 133.133.3 255.255.255.255 tunnel1  <--this says -"to get to this host address go via the gre tunnel"


rtr3
ip route 1.1.1.1 255.255.255.255 172.16.11.2
ip route 172.16.10.0 255.255.255.0 172.16.11.2

or
ip route 0.0.0.0 0.0.0.0 172.16.11.2
ip route 192.168.1.0 255.255.255.0 Tunnel1 <--this says -"to get to this subnet go via the gre tunnel"

int lo100
description TEST tunnel
ip address 133.133.133.3 255.255.255.255

res
Paul

[andnagy122]

What interesting is that when I configured the default route + static to 192.168.1.0 through the tunnel, it didn't work.

After I configured one more static to reach the respective loopback with next-hop of 192.168.1.1 and .2, it worked without problems.

But I don't understand why because it seems to be recursive routing: tunnel source/dest are routes through the tunnel itself.

The following routing entry is in R1's routing table:

S       172.16.11.1/32 [1/0] via 192.168.1.2

where 172.16.11.1 is the loopback address, I didn't modificated it.

[paul driver]

Hello

default route + static to 192.168.1.0 through the tunnel, it didn't work.

The default needs to point to the ISP next hop not the tunnel
-
Statically you only need tell each spoke site how to get to the physical interfaces of the other spoke - be it by a default route or individual statics  which in this case would be the ISP next hop

As I have post - if the default route is specified - which basically states "everything not local to me go via here" which will be the isp next hop

You will then need to tell the spoke how to reach the gre subnet and any other subnet you wish to reach via the tunnel with and additional static pointing to the tunnel interface

res
Paul

[andnagy122]

"You will then need to tell the spoke how to reach the gre subnet"

I think you don't need to specify such a static because if the spokes can reach each other with a static default through the ISP, they will discover the tunnel subnet as directly connected. Therefore I think you only have to configure a static for each subnet you wish to reach with next-hop of the tunnel IP on the other end (which was previously discovered as directly connected).

Right?

[paul driver · Accepted solution]

Hello

if you configure specific statics towards the spoke physical subjects then NO your wont be required to use an additional static for the gre subnet but will for any other network you wish to reach through the tunnel

If you use a default static then YES you will required to specify addtional static for the gre addressing and for any other network you wish to reach via the tunnel

res

paul

[andnagy122]

Hi again,

so now I finally understand it.

The point is to always make remote site routers be able to route to the other remote site router's physical IP in some way, in order for the GRE tunnel to be established. This route can either be a static specific route through the ISP or a static default pointing to the ISP.

On the other hand, the remote routers should also be able to route to subnets - which we like to go through the tunnel - through the tunnel.

Therefore, we either need to configure specific statics to them with a next-hop of the neighboring tunnel IP on the other remote site or to enable some IGP and advertise the LAN and tunnel subnets with that on both sides of the tunnel.

Correct?

[paul driver]

Hello

Sounds good to me!

res

paul

[chrihussey]

So in your scenario, your sites are R1 and R3 with LAN segments on either end (172.16.10 & 11) that you want to have connectivity between and the ISP is R2.

That said, consider making the tunnel interfaces source and destination the respective 200.40.49.2 and 210.40.49.2 addresses and still use the 192.168.1.1 & 2 as the tunnel IPs.

Both R1 & R3 have a default route to the ISP.They would also run a routing protocol or have static routes to each others LAN segment through the tunnel.

The ISP would not have to know about the LAN segments (172.16.10 & 11), nor would they see the 192.168.1.x IPs. All tunnel packets between R1 & R3 would be encapsulated in packets with the ISP 200 & 210 addressing.

Hope that makes sense and helps

[andnagy122]

Hi,

>> chrihussey:

"That said, consider making the tunnel interfaces source and destination the respective 200.40.49.2 and 210.40.49.2 addresses and still use the 192.168.1.1 & 2 as the tunnel IPs."

I changed the config to use te physical IPs on R1&R3 plus configured OSPF on all three routers (all routers advertise their directly connected subnets).

The problem in this case is that the tunnel interface's line status remained in a down state and I cannot find the cause of that.

Additionally, the OSPF neighborships also have not been formed at all.

>> paul: I tried this solution as well. I configured static routes as you mentioned:

R1: ip route 172.16.11.0 255.255.255.0 200.40.49.1

R3: ip route 172.16.10.0 255.255.255.0 210.40.49.1

R2: ip route 172.16.10.0 255.255.255.0 200.40.49.2

       ip route 172.16.11.0 255.255.255.0 210.40.49.2

but it didn't work, routing gets stucked on R2, even if R2 can ping both loopbacks without any problem..

[chrihussey · Accepted solution]

If you are going to peer across the tunnel interface using OSPF, the ISP IPs should not be part of the peering. Only specify the 192.168.x.x and 172.16.x.x networks in OSPF. With the ISP IPs included you may be causing the tunnel to not come up because of recursive routuing where the tunnel destination in through the tunnel (which won't work).

Also don't forget the default route pointing to the ISP next hop. You shouldn't need any other statics.