Tunneling provides a mechanism to transport packets of one protocol within another protocol. Generic Routing Encapsulation (GRE) is one of the available tunneling mechanisms which uses IP as the transport protocol and can be used for carrying many different protocols. Basically when you configure a tunnel, it is like you create a simple point-to-point connection between the two devices.
Let's consider following scenario with Cisco routers.
R1#show running-config interface tunnel 0
Building configuration...
Current configuration : 140 bytes
!
interface Tunnel0
ip address 192.168.99.1 255.255.255.0
keepalive 300 3
tunnel source 192.168.1.1
tunnel destination 192.168.2.3
end
R3#show running-config interface tunnel 0
Building configuration...
Current configuration : 140 bytes
!
interface Tunnel0
ip address 192.168.99.3 255.255.255.0
keepalive 300 3
tunnel source 192.168.2.3
tunnel destination 192.168.1.1
end
Connectivity test from router R4 to R5
R4#ping 172.16.2.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.2.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 44/74/84 ms
I would like to see what is happening if I am trying to reach same interface with do not fragment bit set:
R4#ping
Protocol [ip]:
Target IP address: 172.16.2.5
Repeat count [5]:
Datagram size [100]: 1500
Timeout in seconds [2]:
Extended commands [n]: yes
Source address or interface: 172.16.1.4
Type of service [0]:
Set DF bit in IP header? [no]: yes
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 1500-byte ICMP Echos to 172.16.2.5, timeout is 2 seconds:
Packet sent with a source address of 172.16.1.4
Packet sent with the DF bit set
M.M.M
Success rate is 0 percent (0/5)
As this packet traverse Tunnel interface, obviously fragmentation is happening and we sent icmp request with DF bit set. From where this fragmentation is coming? The forwarding router adds GRE encapsulation, which includes a 4-byte GRE header plus a 20-byte IP header to each fragment of the original IP datagram.
For example, if we are forming a tunnel over FastEthernet (IP MTU 1500), the IOS calculates the IP MTU on the tunnel as:
1500 bytes from Ethernet - 24 bytes for the GRE encapsulation = 1476 bytes:
R3#show ip interface tunnel 0
Tunnel0 is up, line protocol is up
Internet address is 192.168.99.3/24
Broadcast address is 255.255.255.255
Address determined by non-volatile memory
MTU is 1476 bytes
Many application are sending DF bit set and solution for this sort of issue could be making policy to override DF bit. The simplest method is with route map and this policy has to be applied on the incoming interface before packet is entering Tunnel. In our case it will be FastEthernet0/1 on R1:
R1(config)#access-list 110 permit ip any any
R1(config)#route-map clear-df-bit permit 10
R1(config-route-map)#match ip address 110
R1(config-route-map)#set ip df 0
R1(config-route-map)#exit
R1(config)#interface FastEthernet0/1
R1(config-if)#ip policy route-map clear-df-bit
R1(config-if)#exit
Let's verify connectivity and send ping with DF bit set.
R4#ping
Protocol [ip]:
Target IP address: 172.16.2.5
Repeat count [5]:
Datagram size [100]: 1500
Timeout in seconds [2]:
Extended commands [n]: yes
Source address or interface: 172.16.1.4
Type of service [0]:
Set DF bit in IP header? [no]: yes
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 1500-byte ICMP Echos to 172.16.2.5, timeout is 2 seconds:
Packet sent with a source address of 172.16.1.4
Packet sent with the DF bit set
!!!!!
Once again, configuration from FastEthernet0/1 interface on R1 (incoming interface before packet is entering tunnel):
R1#show running-config | begin interface FastEthernet0/1
interface FastEthernet0/1
ip address 172.16.1.1 255.255.255.0
ip policy route-map clear-df-bit
duplex auto
speed auto
and route-map:
!
route-map clear-df-bit permit 10
match ip address 110
set ip df 0
!
Let's consider following scenario with Cisco routers.
Building configuration...
Current configuration : 140 bytes
!
interface Tunnel0
ip address 192.168.99.1 255.255.255.0
keepalive 300 3
tunnel source 192.168.1.1
tunnel destination 192.168.2.3
end
R3#show running-config interface tunnel 0
Building configuration...
Current configuration : 140 bytes
!
interface Tunnel0
ip address 192.168.99.3 255.255.255.0
keepalive 300 3
tunnel source 192.168.2.3
tunnel destination 192.168.1.1
end
Connectivity test from router R4 to R5
R4#ping 172.16.2.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.2.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 44/74/84 ms
I would like to see what is happening if I am trying to reach same interface with do not fragment bit set:
R4#ping
Protocol [ip]:
Target IP address: 172.16.2.5
Repeat count [5]:
Datagram size [100]: 1500
Timeout in seconds [2]:
Extended commands [n]: yes
Source address or interface: 172.16.1.4
Type of service [0]:
Set DF bit in IP header? [no]: yes
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 1500-byte ICMP Echos to 172.16.2.5, timeout is 2 seconds:
Packet sent with a source address of 172.16.1.4
Packet sent with the DF bit set
M.M.M
Success rate is 0 percent (0/5)
As this packet traverse Tunnel interface, obviously fragmentation is happening and we sent icmp request with DF bit set. From where this fragmentation is coming? The forwarding router adds GRE encapsulation, which includes a 4-byte GRE header plus a 20-byte IP header to each fragment of the original IP datagram.
For example, if we are forming a tunnel over FastEthernet (IP MTU 1500), the IOS calculates the IP MTU on the tunnel as:
1500 bytes from Ethernet - 24 bytes for the GRE encapsulation = 1476 bytes:
R3#show ip interface tunnel 0
Tunnel0 is up, line protocol is up
Internet address is 192.168.99.3/24
Broadcast address is 255.255.255.255
Address determined by non-volatile memory
MTU is 1476 bytes
Many application are sending DF bit set and solution for this sort of issue could be making policy to override DF bit. The simplest method is with route map and this policy has to be applied on the incoming interface before packet is entering Tunnel. In our case it will be FastEthernet0/1 on R1:
R1(config)#access-list 110 permit ip any any
R1(config)#route-map clear-df-bit permit 10
R1(config-route-map)#match ip address 110
R1(config-route-map)#set ip df 0
R1(config-route-map)#exit
R1(config)#interface FastEthernet0/1
R1(config-if)#ip policy route-map clear-df-bit
R1(config-if)#exit
Let's verify connectivity and send ping with DF bit set.
R4#ping
Protocol [ip]:
Target IP address: 172.16.2.5
Repeat count [5]:
Datagram size [100]: 1500
Timeout in seconds [2]:
Extended commands [n]: yes
Source address or interface: 172.16.1.4
Type of service [0]:
Set DF bit in IP header? [no]: yes
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 1500-byte ICMP Echos to 172.16.2.5, timeout is 2 seconds:
Packet sent with a source address of 172.16.1.4
Packet sent with the DF bit set
!!!!!
Once again, configuration from FastEthernet0/1 interface on R1 (incoming interface before packet is entering tunnel):
R1#show running-config | begin interface FastEthernet0/1
interface FastEthernet0/1
ip address 172.16.1.1 255.255.255.0
ip policy route-map clear-df-bit
duplex auto
speed auto
and route-map:
!
route-map clear-df-bit permit 10
match ip address 110
set ip df 0
!
No comments:
Post a Comment