Wednesday, February 15, 2006


GRE and policy routing. (Question #11)

Consider the following topology

Client -- R1 ---- R2 -- Gateway -- Web server (

There is a GRE tunnel between routers R1 and R2.

R1 has the following config

interface Tunnel1
ip address
keepalive 10 5
tunnel source
tunnel destination
interface Ethernet0
ip address
no keepalive

and router R2 has the following config

interface Tunnel1
ip address
keepalive 10 5
tunnel source
tunnel destination
interface Ethernet0
ip address
no keepalive

In addition, on router R2 the following additional config is seen -

interface ethernet0
ip policy route-map mystery

route-map mystery permit 10
match ip address 101
set ip df 0

access-list 101 permit tcp any

Now here are some questions regarding this set-up -
1. What purpose is the keepalive on the tunnel serving?
2. What is the route-map doing?
3. Think up a scenario for a problem that is being solved by policy routing in the example above.

Ok, I'm going to try and answer this one best I can off the top of my head see how I do :)

1. The keepalive is a way of determing if the tunnel is up/functional. If its down, you want the tunnel interface to go down to ensure routing convergance happens. The keepalive 10 5 statement would mean that keepalives are sent every 10 seconds, with 5 retries before it declares the tunnel inactive and deactivates the tunnel1 interface. So in a sense, the line would have to be down for 50 seconds. *Note, this could be a bad scenario if a line is flapping less than every 50 seconds. The tunnel would not go down, and routing would continue to go out a flapping interface.

2. The route map is turning off the DF (do not fragment) bit so that the packet can be fragmented. A common problem with tunnels.

3. Hosts are on the LAN using a 1500 byte MTU, Path MTU discovery and/or ICMP response to fragmentation Type 3, code 4 is blocked somewhere along the path to the end point. DF bits set, and an overall MTU higher than the WAN interfaces can support, the packet will be dropped. By changing the DF bit, the packet will get fragmented along the way if necessary.

Side note - Cisco da Gama, this is a really good site and is really helpful to address those odd scenarios out there than any aspiring CCIE should know. Kudos!

Ryan, your answers are correct. Thanks for your encouragement apropos the site!
MTU on a 3550 for example is 1514. L3 switch interfaces and Router interfaces have different mtu sizes. Keep that in mind, especially with OSPF to a L3-switch.
Several comments:

1. Why would data from the web server to the client ever traverse the tunnel?

The tunnel source and destination are on the same network, so they only way I can think of would be because of policy routing, and there isn't anything in the route map affecting routing.

2. Avoiding fragmentation is almost always better than allowing it.

Assuming traffic is going over the GRE tunnel, adding the following to R2 will reduce the size of the data the web server sends, so it won’t exceed the 1500 MTU when the GRE overhead is added.

R2# conf t
R2(config)# int t1
R2(config-if)# ip tcp adjust-mss 1436

1500 (MTU of ethernet) - 20 tcp header - 20 ip header - 24 GRE = 1436 Maximum Segment Size (MSS). You may want to make this smaller if there are other things decreasing the path MTU.

You can use this in conjunction with the clearing of the df bit, but I generally use only the ip tcp adjust-mss.

Cisco recommends the "tunnel path-mtu-discovery" option, which copies the df bit of the packet being encapsulated to the new IP header (of the GRE packet). However, if you use this, make sure it is working as expected, I have seen problems with this actually creating a black hole for packets near the MTU, at least when using GRE along with IPSec (specifically with crypto map applied to physical interface and not to the tunnel)

There are two good references on the cisco web site. Google for "why can't i browse the internet when using a gre tunnel" for an overview, and "ip fragmentation and pmtud" (Cisco Document ID: 25885) for the details.
Latest news. Viagra, cialis

ip tcp adjust-mss only prevents TCP SYN packets with large MTUs. You will still have problems with UDP services (Remote desktop, audio/video streaming, etc).
yes true jon.
also the tcp-adjust-mss and mtu commands are sort of straight forward and we all know CCIE lab looks for the most unpractical situations and scenarios !
shucks.. ryan has beat me to it !! :) - [url=]site[/url] site
To acquire a higher publicity for your facebook account, Persons expend bucks to Buy Facebook Followers to easily find hype on world-wide-web. buy followers for facebook
Post a Comment

Links to this post:

Create a Link

<< Home

This page is powered by Blogger. Isn't yours?