GRE tunnels - help understanding the basic configuration

aftereffector

I've reached the GRE tunnel section of my CCNA studies and I seem to be running into a wall. I am following along in the Odom book where the author sets up a tunnel between two private networks, 10.1.1.0/24 and 10.1.2.0/24, using tunnel IPs 10.1.3.1 and 10.1.3.2 going out the routers' serial interfaces (1.1.1.1 and 2.2.2.2 respectively). As far as I understand it, 1.1.1.1 is a public IP address for R1's outgoing serial interface connected to the Internet, and 2.2.2.2 is the same for R2. R1 is directly connected to the 10.1.1.0/24 private network. The tunnel config for R1 would look like so:

R1# [B]config term[/B]
R1(config)# i[B]nt tunnel 1[/B]
R1(config-int)# i[B]p address 10.1.3.1 255.255.255.0[/B]
R1(config-int)# [B]tunnel source s0/0/0[/B]
R1(config-int)# [B]tunnel destination 2.2.2.2[/B]

R2 would have a mirrored configuration for its tunnel:

R2# [B]config term[/B]
R2(config)# i[B]nt tunnel 11[/B]
R2(config-int)# i[B]p address 10.1.3.2 255.255.255.0[/B]
R2(config-int)# [B]tunnel source s0/0/1[/B]
R2(config-int)# [B]tunnel destination 1.1.1.1[/B]

In Odom's running-config examples, both R1 and R2 have OSPF configured with 10.1.0.0 0.0.255.255 area 0.
As I understand it, this is the logic behind the configurations: the private network on one side needs a secure way to communicate with the private network on the other side. This is provided through the GRE tunnel. A packet from a host on R1's LAN would send a packet to its default gateway (in the 10.1.1.0/24 subnet), which is R1. R1 would then route the packet to R2 via the tunnel, which acts as a sort of virtual serial link using 10.1.3.1 and 10.1.3.2. The public IP addresses on R1 and R2's serial interfaces are there to set up the tunnel by connecting to each other through the internet. However, this is where my understanding breaks down.

Why would a router use the tunnel interface to route a packet if there is already a route between R1's s0/0/0 and R2's s0/0/1 interfaces (1.1.1.1 to 2.2.2.2)? That route has to exist in order for the routers to know about each other in the first place, so it's not like you could just restrict OSPF to the 10.1.x.x address range - because the routers would not be able to set up their tunnel in the first place; afer all, it has to have something to tunnel *through* - but Odom seems to have done exactly that with his restricted OSPF network configuration command. Does he have static routes that he isn't showing, or another OSPF area or something? In short, how do you set up a tunnel without advertising a route between R1 and R2's serial interfaces, and with that route, why would the router ever use the tunnel?

I'm simulating this with PacketTracer and the results are unfailingly frustrating. If I have OSPF set up covering all IP addresses (network 0.0.0.0 255.255.255.255), both tunnels are up/up and I can ping from one end to the other, but the routers don't use the tunnel. If I restrict OSPF to just the tunnel interface (network 10.1.0.0 0.0.255.255), the tunnels go to up/down and I can't ping anything at all.

Help! I've stayed up all night banging my head against this wall and I've read the chapter front to back four times in a row... please tell me I'm missing something really basic that will make this very simple concept work?

EdTheLad

As I understand it, this is the logic behind the configurations: the private network on one side needs a secure way to communicate with the private network on the other side. This is provided through the GRE tunnel.

No, this is not secure, there is no encryption taking place, if you wanted a secure tunnel you would use IPSEC.

A packet from a host on R1's LAN would send a packet to its default gateway (in the 10.1.1.0/24 subnet), which is R1. R1 would then route the packet to R2 via the tunnel, which acts as a sort of virtual serial link using 10.1.3.1 and 10.1.3.2. The public IP addresses on R1 and R2's serial interfaces are there to set up the tunnel by connecting to each other through the internet. However, this is where my understanding breaks down.

When R1 receives the packet from the host it will look in its routing table and see in order to get to 10.1.2.0/24 it needs to use the tunnel interface. For this to work there must be a route pointing at the tunnel interface for 10.1.2.0/24, this is why Odom has configured ospf, ospf is running over the tunnel interface, not the physical interface, network statement 10.1.0.0 area 0 sets this up. OSPF isn't configured on the physical interfaces 1.1.1.1 and 2.2.2.2.
This could also be done statically without ospf by configuring static routes:
ip route 10.1.1.0 255.255.255.0 10.1.3.2 on R1
ip route 10.1.2.0 255.255.255.0 10.1.3.1 on R2

For the tunnel to come up in the first place a route must be present for the tunnel destination, so R1 will need a route to 2.2.2.2 to point out it's serial interface and R2 will need a route to 1.1.1.1 to point out its serial interface.

Why would a router use the tunnel interface to route a packet if there is already a route between R1's s0/0/0 and R2's s0/0/1 interfaces (1.1.1.1 to 2.2.2.2)? That route has to exist in order for the routers to know about each other in the first place, so it's not like you could just restrict OSPF to the 10.1.x.x address range - because the routers would not be able to set up their tunnel in the first place; afer all, it has to have something to tunnel *through* - but Odom seems to have done exactly that with his restricted OSPF network configuration command. Does he have static routes that he isn't showing, or another OSPF area or something? In short, how do you set up a tunnel without advertising a route between R1 and R2's serial interfaces, and with that route, why would the router ever use the tunnel?

OSPF has been enabled on the tunnel interface only, not the physical interface. So there should only be one route pointing to the tunnel interface. If you configure ospf on all interfaces network 0.0.0.0 255.255.255.255, then the route is learned via the tunnel and the physical. As i said before the tunnel comes up is there is a route to the tunnel destination, this route would have been configured statically. This route is limited to the 1.1.1.1 and 2.2.2.2 host address so it doesn't interfere with routing the 10.1.x.x network

I'm simulating this with PacketTracer and the results are unfailingly frustrating. .

Seriously in this day and age i cant understand why anybody would use PacketTracer, we have GNS3 now, its works with a real cisco image and is free.
If you want to be a network engineer throw away PT and get GNS3.

Help! I've stayed up all night banging my head against this wall and I've read the chapter front to back four times in a row... please tell me I'm missing something really basic that will make this very simple concept work?

Bad idea, you would be surprised how many problems i've solved in my sleep, or quickly the next morning with a fresh head.

aftereffector

Thanks for the quick and in-depth reply!

So... I do indeed have to have routes for the physical interfaces. That would be easiest to do with a static route, right? I'm not too confident on multi-area OSPF - all my routing labs have just used the 0.0.0.0 255.255.255.255 shotgun blast method - but I suppose I could try the following on R1:

R1(config)# [B]router ospf 1[/B]
R1(config-router)# [B]network 10.1.0.0 0.0.255.255 area 0
[/B]R1(config-router)# [B]network 2.0.0.0 0.255.255.255 area 0[/B]

Would that accomplish establishing the tunnel while only routing traffic from 10.1.1.0/24 to 10.1.2.0/24?

Regarding PacketTracer - I'd love to use GNS3 but I don't have an IOS image to play with (yet). It's annoying to learn new commands from the Odom book but not be able to use them in a lab, like seemingly half of the show commands and any modifiers to show running-config, but it's free...

Again, thanks so much for your help! I've only been a member of this forum for a few days but it has already become my #1 resource for certs, networking help, and career advice.

EdTheLad

The reason you need routes for the physical interfaces is due to needing to have a route to the tunnel destination, i wouldnt call these routes to the physical interface, tr and understand how tunneling is working, you are adding a new header with an ip src and dst address. If your going to add a dest ip to a packet you should know how to get to that dest ip.

This is not multi-area ospf, since we are just using area 0. You need to go back and learn wildcard masking, the ospf network statement is used to indicate which interfaces will run ospf, network 0.0.0.0 255.255.255.255 will eable ospf on every interface, network 10.1.3.1 0.0.0.0 will enable ospf on a single interface which has that ip address, network 10.1.0 0.0.255.255 will enable ospf on all interfaces which have an ip address with the first 16 bits 10.1.x.x.

You don't need the network statement 2.0.0.0 0.255.255.255 area 0, why do you want to enable ospf on this interface, its not needed.

Cisco IOS images are all over the internet, google and you will find lots of threads on GNS and locations for images.

I think you are trying to run before you can walk, you are trying to learn advanced topics before you have a handle on the foundations. You need to go back and learn routing, how masks work. Then if you want to study about tunnels start off with static routing and when you are comfortable move to dynamic over tunnels. Then maybe look at the different tunnel encapsulation techniques ipip, ipsec etc.

aftereffector

I finally got it working! I was configuring my static routes wrong, no doubt due to staying up all night and my brain being fuzzy. I still wish Odom had been a little more explicit about the public routing config (or at least shown one of those lines in the running-config examples) but all's well that ends well... on to chapter 8, implementing OSPF for IPv4!