Wednesday, February 15, 2006
GRE and policy routing. (Question #11)
Consider the following topology
Client -- R1 ---- R2 -- Gateway -- Web server (22.1.1.1)
There is a GRE tunnel between routers R1 and R2.
R1 has the following config
and router R2 has the following config
In addition, on router R2 the following additional config is seen -
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.
Client -- R1 ---- R2 -- Gateway -- Web server (22.1.1.1)
There is a GRE tunnel between routers R1 and R2.
R1 has the following config
interface Tunnel1
ip address 20.20.20.1 255.255.255.0
keepalive 10 5
tunnel source 10.10.10.1
tunnel destination 10.10.10.2
!
interface Ethernet0
ip address 10.10.10.1 255.255.255.0
no keepalive
and router R2 has the following config
interface Tunnel1
ip address 20.20.20.2 255.255.255.0
keepalive 10 5
tunnel source 10.10.10.2
tunnel destination 10.10.10.1
!
interface Ethernet0
ip address 10.10.10.2 255.255.255.0
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 22.1.1.0 0.0.0.255 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.
Comments:
<< Home
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.
# posted by 
: Fri Mar 24, 09:38:00 AM 2006
: Fri Mar 24, 09:38:00 AM 2006
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 10.10.10.0/24 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
R2(config-if)^Z
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.
1. Why would data from the web server to the client ever traverse the tunnel?
The tunnel source and destination are on the same 10.10.10.0/24 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
R2(config-if)^Z
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.
# posted by : Thu Mar 30, 07:42:00 PM 2006
: Thu Mar 30, 07:42:00 PM 2006
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 !! :)
Post a Comment
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 !! :)
<< Home
