Here you are very typical architecture. Local Internet access and site to site VPN at the same router – easy case. To deploy this kind of configuration almost always we have to engage IPSec VPN and NAT at one platform. What does NAT imply for IPSec – let’s answer this question.

First we have to take a look at Cisco IOS order of operations. NAT is before encryption, what is means that traffic that needs to be encrypted will be first NATed then encypted. Mostly our crypto ACL that defines interesting traffic for encyption matches our source inside LAN subnet and remote end subnet IP. Once we add default NAT configuration, IPSec will not work properly. Traffic will never match crypto ACL because first will be translated and source IP will change (depends on NAT configuration) to outside interface IP or to dynamic IP defined in NAT pool.

To resolve this issue we have to exclude traffic that needs to be encrypted from NAT translation. Here you are quick configuration example how to proceed.

Assumptions:

Traffic from subnet 10.0.1.0/24 to 10.0.3.0/24 needs to be encrypted. Remaining traffic from 10.0.1.0/24 to Internet needs to be translated to outside interface IP.

Solution:

Define two ACLs. First needs to match VPN traffic (you can leverage of course crypto ACL that is already used by IPSec crypto map), second will define NAT traffic. Then create route map with two statements, in first statement we have to use deny key word and match crypto ACL, second permit statement will match NAT ACL. Route map has to be assigned under to ip nat inside configuration that describes traffic that will be translated. That’s all. Here you are how it looks like from configuration perspective.

ip access-list extended NAT
permit ip 10.0.1.0 0.0.0.255 any
ip access-list extended VPN
permit ip 10.0.1.0 0.0.0.255 10.0.3.0 0.0.0.255
!
route-map NAT deny 10
match ip address VPN
!
route-map NAT permit 20
match ip address NAT
!
ip nat inside source route-map NAT interface FastEthernet0/0 overload
!
interface FastEthernet0/0
ip nat outside
crypto map MAPA

, ,

I can bet that you say that to configure NAT/PAT, ip nat inside and ip nat outside commands are always needed. I will show you example where we can translate IPs just with ip nat outside.

Specific exception is traffic generated from the router itself. Let’s play with NAT, configure PAT with simple ACL and compare difference for traffic generated from host that resides behind the router and for traffic from the router itself.

I would to translate all traffic from LAN network to Internet and will use fa0/0 interface IP. Instead use specific subnet IP I’m going to configure any/any in ACL (this will make me in trouble ;)). I just configure ip nat outside command under fa0/0 interface that simulates internet subnet.

Here you are my base config. R1 and R2 are connected directly via fa0/0 interfaces.

interface FastEthernet0/0
ip address 10.0.12.1 255.255.255.0
ip nat outside
ip virtual-reassembly
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 192.168.1.210 255.255.255.0
duplex auto
speed auto
!
ip access-list extended NAT
permit ip any any
!
ip nat inside source list NAT interface FastEthernet0/0 overload

Let’s first generate telnet traffic from the host.
R2#show users
Line User Host(s) Idle Location
* 0 con 0 idle 00:00:00
66 vty 0 idle 00:00:15 192.168.1.105

As you see user has been connected from 192.168.1.105.

R1#sh ip nat translations
R1#

At R1 no translation appear, so NAT does not work and user’s telnet traffic has been simply routed with translation. To resolve this problem ip nat inside under int fa0/1 needs to be added.
Before we add it let’s generate test traffic from router itself.

R1#telnet 10.0.12.2 /source-interface fa0/1
Trying 10.0.12.2 ... Open
User Access Verification
Password:

R2#sh users
Line User Host(s) Idle Location
* 0 con 0 idle 00:00:00
67 vty 1 idle 00:00:34 10.0.12.1

NAT is working fine without ip nat inside even if we generated traffic with source fa0/1, telnet traffic has been translated to fa0/0 10.0.12.1.

R1#sh ip nat translations
Pro Inside global Inside local Outside local Outside global
tcp 10.0.12.1:28276 192.168.1.210:28276 10.0.12.2:23 10.0.12.2:23

Translation has been added.
What about traffic generated from the router itself. Let’s ping R2.

R1#ping 10.0.12.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.12.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/30/80 ms
R1#sh ip nat translations
Pro Inside global Inside local Outside local Outside global
icmp 10.0.12.1:1 10.0.12.1:1 10.0.12.1:1 10.0.12.1:1

R1 has translated own generated traffic. This test show us one important issue that can influence traffic from and to router. Because NAT is enabled on outside interface via ip nat outside command router verifies NAT policy, traffic matches ACL and source IP is translated to fa0/0 interface IP. For traffic passing thru the router for example from the host behind the router ip nat inside and ip nat outside commands are required to properly NAT traffic. Because NAT works also for traffic generated from the router itself even if we have just ip nat outside configured under outside interface traffic from the router will be translated. Important thing is to properly define source and/or destination traffic in ACL otherwise all traffic that match ACL will be nated. Improper ACL configuration can break our management traffic and thus we lose access to our box.
For example. I have configured simple PAT but didn’t add ip nat outside yet to fa0/0. I was able to established telnet session to the router. Once I added ip nat outside router started translate source TCP port due to PAT configured so port TCP 23 has been translated to TCP 3. Then TCP stack on PC from where I’m trying connect will drop these packets because they are not related to this session (wrong source port). If you would like to establish new telnet session to R1 from R2 you will get the same issue, R2 will sent SYN/ACK to reponse for SYN packet but source port 23 will be translated to different one, R2 will replay via RST packet because of wrong source port. Hope it was interesting post for you.

,

Following post will present you how Cisco router handles broadcast IP packets.

We have two types of IP broadcast address:

  • All subnets broadcast IP (255.255.255.255)
  • Directed broadcast – specific subnet broadcast IP (e.g. 10.0.12.255 for 10.0.12.0/24 subnet)

It’s worth to add that all subnets broadcast IP type is not directed broadcast, directed means broadcast sent to all hosts in specific subnets (directed to specific group of hosts).

By default Cisco router does not forward IP packets addressed to any type of broadcast address – router simple drops them or in case it’s ICMP echo to router’s directly connected broadcast subnet respond via echo reply to requestor.

Directed broadcast example

Let’s take a look on the first example. I have generated ping message from R1 to 10.0.23.255. Because R2 is directly connected to the 10.0.23.0/24 subnet will respond to echo via echo reply but will not forward the ICMP packet over Fa0/1 link towards R3 so R3 will never get it.

Here you are debug IP packet from R1 after ping:

R1#ping 10.0.23.255 repeat 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 10.0.23.255, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 60/60/60 ms
R1#
*Mar 1 00:24:54.467: IP: tableid=0, s=10.0.12.1 (local), d=10.0.23.255 (FastEthernet0/0), routed via FIB
*Mar 1 00:24:54.471: IP: s=10.0.12.1 (local), d=10.0.23.255 (FastEthernet0/0), len 100, sending
*Mar 1 00:24:54.475: ICMP type=8, code=0
*Mar 1 00:24:54.515: IP: tableid=0, s=10.0.12.2 (FastEthernet0/0), d=10.0.12.1 (FastEthernet0/0), routed via RIB
*Mar 1 00:24:54.519: IP: s=10.0.12.2 (FastEthernet0/0), d=10.0.12.1 (FastEthernet0/0), len 100, rcvd 3
*Mar 1 00:24:54.523: ICMP type=0, code=0

 As you can see R1 gets just R2’s respond.

Let’s add no ip directed-broadcast under Fa0/1 on R2 and see how th debug looks like now on R1:

R2(config-if)#int fa0/1
R2(config-if)#no ip directed-broadcast

R1#ping 10.0.23.255 repeat 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 10.0.23.255, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 36/36/36 ms
R1#
*Mar 1 00:03:56.839: IP: tableid=0, s=10.0.12.1 (local), d=10.0.23.255 (FastEthernet0/0), routed via FIB
*Mar 1 00:03:56.843: IP: s=10.0.12.1 (local), d=10.0.23.255 (FastEthernet0/0), len 100, sending
*Mar 1 00:03:56.847: ICMP type=8, code=0
*Mar 1 00:03:56.863: IP: tableid=0, s=10.0.12.2 (FastEthernet0/0), d=10.0.12.1 (FastEthernet0/0), routed via RIB
*Mar 1 00:03:56.867: IP: s=10.0.12.2 (FastEthernet0/0), d=10.0.12.1 (FastEthernet0/0), len 100, rcvd 3
*Mar 1 00:03:56.871: ICMP type=0, code=0
*Mar 1 00:03:56.931: IP: tableid=0, s=10.0.23.3 (FastEthernet0/0), d=10.0.12.1 (FastEthernet0/0), routed via RIB
R1#
*Mar 1 00:03:56.935: IP: s=10.0.23.3 (FastEthernet0/0), d=10.0.12.1 (FastEthernet0/0), len 100, rcvd 3
*Mar 1 00:03:56.939: ICMP type=0, code=0

As you see R1 now gets response from R2 and R3.

Take a look how it looks like on R2 and R3:

R2#*Mar  1 00:10:16.995: IP: tableid=0, s=10.0.12.1 (FastEthernet0/0), d=10.0.23.255 (FastEthernet0/1), routed via RIB
*Mar  1 00:10:16.999: IP: s=10.0.12.1 (FastEthernet0/0), d=10.0.23.255 (FastEthernet0/1), g=255.255.255.255, len 100, forward directed broadcast
*Mar  1 00:10:17.007:     ICMP type=8, code=0

R3#*Mar  1 00:07:20.491: IP: s=10.0.12.1 (FastEthernet0/1), d=255.255.255.255, len 100, rcvd 2
*Mar  1 00:07:20.495:     ICMP type=8, code=0
*Mar  1 00:07:20.499: IP: tableid=0, s=10.0.23.3 (local), d=10.0.12.1 (FastEthernet0/1), routed via FIB
*Mar  1 00:07:20.499: IP: s=10.0.23.3 (local), d=10.0.12.1 (FastEthernet0/1), len 100, sending
*Mar  1 00:07:20.503:     ICMP type=0, code=0

As you can discovered ip directed-broadcast changes the destination directed broadcast address (10.1.23.255) to all subnet broadcast 255.255.255.255.

What in case we would still send directed broadcast to subnet IP? We can use broadcast-address command for this propose.

R2#show run int fa0/1
interface FastEthernet0/1
 ip address 10.0.23.2 255.255.255.0
 ip broadcast-address 10.0.23.255
 ip directed-broadcast

Now R3 gets ICMP packet directed to subnet broadcast 10.0.23.255.

R3#*Mar  1 00:41:35.391: IP: s=10.0.12.1 (FastEthernet0/1), d=10.0.23.255 (FastEthernet0/1), len 100, rcvd 3
*Mar  1 00:41:35.395:     ICMP type=8, code=0

Here you are diagram that shows above tests.

 

 

All subnets broadcast example

In the following example I will show you how router handles typical broadcast packets. The best example is the DHCP address allocation process (more about it you can read here). The first message called as DHCP Discovery is sent to 255.255.255.255 broadcast address. By default router will ignore this packet and drop it. To properly handle it and send as unicast IP toward final destination we have to use ip helper-address command under fa0/0 interface on R2, exactly under interface that receives broadcast packets.

Please check following scheme and take a look on the mentioned post. Enjoy 😉

  

 

,

In simplified way Network Address Translation (NAT) allow us to translate source or/and destination address of IP packet. There is few reasons to do it like managment purpose, security or IP address savings. NAT is one of technology that with success delays IPv6 world wide deployment. First of all let’s explain NAT wording that at first sight looks slightly confused. Below simple diagram will help us to understand the concept.

  • Inside local IP is how inside address is seen localy by inside hosts, so from the our LAN perspective it’s real IP of our PC. 
  • Inside global IP is how inside address is seen globaly by outside hosts, so from the outside hosts in Internet it’s translated (NATed) IP of our host. 
  • Outside local IP is how outside address is seen localy by inside hosts, so from the LAB perspective it’s translated (NATed) IP of host that resides out of our network like in Internet. Hosts in LAN will use it as destination IP address.
  • Outside global IP is how outside address is seen globaly by outside hosts, so from the our LAN perspective it’s real IP address of host that resides out of our network.

Inside translation type is frequently used in today’s networks. In case we have 10000 hosts in our LAN and would allow them to connect to the Internet resource then we need provide external public IP address for each internal hosts. So big range of public IP addresses expensive but sometimes even not be available for not service provider company. NAT is a solution in this example. We can simple translate all inside IP addresses to 1 public IP using Port Address Translation (PAT) NAT feature. The first question that comes to the mind is how the router will be able to distinguish the packets once they back from the Internet. PAT simply translate the IPs to one outside IP but additionaly translates the layer 4 source ports. Router initially simple rewrites the TCP or UDP source port changing just a source IP but in case another host intimates session with the same layer 4 source then router will take first free port. Based on this easy mechanism router is able to create around 64511 session for one public IP (we have 65535 ports where first 1024 are reserved). The second example of inside NAT is static one-2-one translation. Inside NAT allows us to hide the server real IP address (frequently used private IP range) and put it under public IP in the Internet as service for public use. Thanks to this we can hide our network infrastructure and additionaly again save our public IP range because all of our public services can be hosted under one IP.
The outside NAT translation changing destination IP address. It’s usful when our company has business connection to third party and they are using IP address that is already used in our network somewhere.

Let’s take a first example and try to configure inside and outside static NAT translation based on the below diagram.

First inside so source IP (from the LAN perspective) translation.
R2(config)#ip nat inside source static ?
A.B.C.D Inside local IP address
esp IPsec-ESP (Tunnel mode) support
network Subnet translation
tcp Transmission Control Protocol
udp User Datagram Protocol
R2(config)#ip nat inside source static 10.0.12.1 ?
A.B.C.D Inside global IP address
interface Specify interface for global address
R2(config)#ip nat inside source static 10.0.12.1 132.0.1.100

Inside done. All traffic from the PC with IP 10.0.12.1 will be NATed to the 132.0.1.100.
Next let’s define the server IP address (192.168.1.7) that will be used by local PC as destination IP.

R2(config)#ip nat outside source static ?
A.B.C.D Outside global IP address
network Subnet translation
tcp Transmission Control Protocol
udp User Datagram Protocol
R2(config)#ip nat outside source static 200.1.2.3 ?
A.B.C.D Outside local IP address
R2(config)#ip nat inside source static 10.0.12.1 132.0.1.100

We have to define the inside and outside interface.
R2(config)#int fa0/1
R2(config-if)#ip nat outside
R2(config-if)#int fa0/0
R2(config-if)#ip nat inside
R2(config-if)#no ip route-cache
R2#show ip nat translations
Pro Inside global Inside local Outside local Outside global
--- --- --- 192.168.1.7 200.1.2.3
--- 132.0.1.100 10.0.12.1 --- ---

OK all done. Two static one2one translation have been added to the NAT table. It’s worth to mention here that this type of entry is kinf of reversible translation type – it’s possible to initiate connection from inside or from outside. In case of dynamic NAT it’s impossible to initiate connection from outside unless dynamic NAT with route-map and reversible option at the end is used.

Let’s run the debug IP packet and initiate test traffic doing telnet to outside local IP address – 192.168.1.7 from the PC.

R2#debug ip packet detail
IP packet debugging is on (detailed)
*Mar 1 02:32:44.819: IP: s=10.0.12.1 (FastEthernet0/0), d=192.168.1.7, len 44, unroutable
*Mar 1 02:32:44.823: TCP src=35649, dst=23, seq=391750710, ack=0, win=4128 SYN
*Mar 1 02:32:44.827: IP: tableid=0, s=10.0.12.2 (local), d=10.0.12.1 (FastEthernet0/0), routed via FIB
*Mar 1 02:32:44.831: IP: s=10.0.12.2 (local), d=10.0.12.1 (FastEthernet0/0), len 56, sending
*Mar 1 02:32:44.835: ICMP type=3, code=1

Hmm 192.168.1.7 is unroutable, does it mean that router first take routing decision before translation.
Here you are short list of Cisco IOS order of operation: 

  1. If IPsec, then check input access list
  2. Decryption—for Cisco Encryption Technology (CET) or IPsec
  3. Check input access list
  4. Check input rate limits
  5. Input accounting
  6. Policy routing
  7. Routing
  8. Redirect to Web cache
  9. NAT
  10. Crypto (check map and mark for encryption)
  11. Check output access list
  12. Inspect context-based access control (CBAC)
  13. TCP intercept
  14. Encryption
  15. Queueing

OK let’s add routing to the 192.168.1.7 and see what happens.
R2#*Mar 1 03:23:34.311: IP: tableid=0, s=10.0.12.1 (FastEthernet0/0), d=192.168.1.7 (FastEthernet0/1), routed via FIB ---Routing over Fa0/1
*Mar 1 03:23:34.315: NAT: s=10.0.12.1->132.0.1.100, d=192.168.1.7 [318] --- source NAT
*Mar 1 03:23:34.319: NAT: s=132.0.1.100, d=192.168.1.7->200.1.2.3 [318] --- destination NAT
*Mar 1 03:23:34.323: IP: s=132.0.1.100 (FastEthernet0/0), d=200.1.2.3 (FastEthernet0/1), g=10.0.23.3, len 44, forward
*Mar 1 03:23:34.327: TCP src=31740, dst=23, seq=1913933555, ack=0, win=4128 SYN

R2#show ip nat translations
Pro Inside global      Inside local       Outside local      Outside global
--- ---                ---                192.168.1.7        200.1.2.3
tcp 132.0.1.100:31740  10.0.12.1:31740    192.168.1.7:23     200.1.2.3:23
--- 132.0.1.100        10.0.12.1          ---                ---

Connection initiated successfully. First SYN packet is routed and will be push out over Fa0/1 (red), next inside (source) and outside (destination) NAT is taking place. TCP source and destination ports 31740 and 23 respectively have been written in NAT translation table. Enjoy the NAT.

Ping tool is very usful to discover or understand some network behaviours related to network protocols or services that are run on Cisco routers or MS Windows. Before we start with ping test, first of all we have to know how this tool has been deployed in both systems.

Datagram/Packet size (IP Total Length field) = IP Header + Payload
As name imply it’s datagram/packet size so IP Header + Payload.

With Cisco IOS the case is simple. In below example packet size is equal to 1000 bytes, it means that ICMP Echo ping message will be generated with standard 20 bytes for IP Header + 980 for ICMP Payload (ICMP type field: 1B, code: 1B, checksum: 2B, identifier: 2B, sequence number: 2B, data: 972B).

R1#ping 10.0.23.3 repeat 1 size 1000
Type escape sequence to abort.
Sending 1, 1000-byte ICMP Echos to 10.0.23.3, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 80/80/80 ms

In case of Windows OS it’s more complicated. We can define specific data size (don’t mix up it with payload) so in this example 1000B means exactly ICMP data in payload + fields in ICMP + IP Header. In this case IP packet size will have 20 bytes for IP Header + 1008 bytes for ICMP Payload (ICMP type field: 1B, code: 1B, checksum: 2B, identifier: 2B, sequence number: 2B, data: 1000B). So in case of Ethernet network frame will have 1042B (14B Ethernet II Header included). 

C:\>ping 10.0.10.1 -l 1000 -n 1

Here you can find sniff of ICMP echo request based on the Windows ping tool.

To recap:
Cisco ping size = total IP packet length
Windows ping size = just ICMP data without ICMP 8B fields like type, code, checksum, identifier and sequence.

Fragmentation and Maximum Transmission Unit (MTU)

For IP protocol MTU defines size of IP packet (so IP Total Length field) can can be send thru network device interface. As packets are encapsulated into frame in data link layer they have to be small enough to be transmited by the physical transmission technology.  In case packet is larger then maximum size of underlying network technology there is need to divide an IP packet in to smaller IP chunks. This process is called as IP fragmentation, puttin chunks all together back on the second end of the transmission is called as reassemble, the reassemble of IP packets is done on the IP destination end.

Fragmentation issues

Fragmentation couse more overhead for the receiver then to sender. Device responsible for fragmentation needs to create new header and devide orignal pacekts into fragments. From the other side receivermust allocate memeory to properly serve all fragments and consolidate them all togther. It is not a issue for final destinatio like a host but could couse a problem for routers.

Several issues related to IP fragmentation that couse that is should be avoided:

  • Requires the support of slow path processing on the routers and additionaly use CPU of the receiver part  to reassemble the fragments (forwarding functions is done by software so process switched). 
  • In case router gets fragmented needs to do IP reassembling it reserve the largest buffer available with which to work because it has no idea what size of the original IP packet will be get.
  • If one fragment of an IP packet is dropped, then the entire IP packet must be resend and fragmented again.

 Fragmentation with GRE and IPsec tunnel

The biggest issue with IP fragmentation is related to GRE tunnel. Let’s take a look on the following example. Router A gets 1476B packet then adds GRE header into and sends to tunnel destination. Assume there is a router in the MPLS cloud with link MTU 1400B. This router will fragment GRE packet (GRE IP header, inner origanl IP and TCP headers will be only in the first fragment), in this case GRE tunnel destination router must reassemble the fragmented packets.

To avoid IP fragmentation the best way is to increase the MTU on whole packet way (so on each router on the path), in case of MPLS provider is not the issue because more and more vendors already increased this value up to 1600B to support IPsec or GRE without any problems. In case provider does not support higher MTU or transmit network is Internet we have three options: decrease IP MTU on tunnel interface, adjust MSS value or use PMTUD.  Let’s move from fragmentation theory and take a look how to take advantage of ping to discover the fragmentation issue related to MTU on the packet way and how it can be avoided.

Example – pure network

Suppose that we have pure network enviroment, two CE routers one in branch A and second one in remote branch B, we would confirm that MTU on the path especially minimum MTU in the provider MPLS cloud is equal to 1500B.

To test the MTU on the path the best option is to send the packets each time incrementing overall size. Extended ping feature with sweep option is perfect in this case. In the below example we do send ICMP echo request eith overall size equal to 1490B, we set sweep max size to 1510B where weep interval so we are going to increment each packet by 1B. Important option in this example is setting of Don’t Fragment bit.
R1#p
Protocol [ip]:
Target IP address: 10.0.23.3
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface:
Type of service [0]:
Set DF bit in IP header? [no]: y
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]: y
Sweep min size [36]: 1490
Sweep max size [18024]: 1510
Sweep interval [1]:
Type escape sequence to abort.
Sending 105, [1490..1510]-byte ICMP Echos to 10.0.23.3, timeout is 2 seconds:
Packet sent with the DF bit set
!!!!!!!!!!!..........!!!!!!!!!!!..........!!!!!!!!!!!..........!!!!!!!
!!!!..........!!!!!!.
Success rate is 54 percent (50/91), round-trip min/avg/max = 40/99/224 ms

We have sent out 10 ICMP echo request starting from 1490B and we have got 10 responses, but next 10 pacets has not been answered at all, it’s means that packets was not be able to reach a final destination due to MTU, in fact pacekts longer then 1500B even has not been routed and leave router. Tested router has MTU equal 1500B configured on the interfaces so in the debug you can show that packets longer then 1500B has been routed just by FIB not by RIB like others.
*Mar 1 00:16:42.179: IP: tableid=0, s=10.0.12.1 (local), d=10.0.23.3 (FastEthernet0/0), routed via FIB
*Mar 1 00:16:42.183: IP: s=10.0.12.1 (local), d=10.0.23.3 (FastEthernet0/0), len 1499, sending
*Mar 1 00:16:42.183: ICMP type=8, code=0
*Mar 1 00:16:42.219: IP: tableid=0, s=10.0.23.3 (FastEthernet0/0), d=10.0.12.1 (FastEthernet0/0), routed via RIB
*Mar 1 00:16:42.223: IP: s=10.0.23.3 (FastEthernet0/0), d=10.0.12.1 (FastEthernet0/0), len 1499, rcvd 3
*Mar 1 00:16:42.227: ICMP type=0, code=0
*Mar 1 00:16:42.231: IP: tableid=0, s=10.0.12.1 (local), d=10.0.23.3 (FastEthernet0/0), routed via FIB
*Mar 1 00:16:42.231: IP: s=10.0.12.1 (local), d=10.0.23.3 (FastEthernet0/0), len 1500, sending
*Mar 1 00:16:42.231: ICMP type=8, code=0
*Mar 1 00:16:42.283: IP: tableid=0, s=10.0.23.3 (FastEthernet0/0), d=10.0.12.1 (FastEthernet0/0), routed via RIB
*Mar 1 00:16:42.287: IP: s=10.0.23.3 (FastEthernet0/0), d=10.0.12.1 (FastEthernet0/0), len 1500, rcvd 3
*Mar 1 00:16:42.291: ICMP type=0, code=0
*Mar 1 00:16:42.299: IP: tableid=0, s=10.0.12.1 (local), d=10.0.23.3 (FastEthernet0/0), routed via FIB
*Mar 1 00:16:42.299: IP: s=10.0.12.1 (local), d=10.0.23.3 (FastEthernet0/0), len 1501, sending
*Mar 1 00:16:42.303: ICMP type=8, code=0
*Mar 1 00:16:44.295: IP: tableid=0, s=10.0.12.1 (local), d=10.0.23.3 (FastEthernet0/0), routed via FIB
*Mar 1 00:16.:44.299: IP: s=10.0.12.1 (local), d=10.0.23.3 (FastEthernet0/0), len 1502, sending

Router sends 20 packets (starting from 1490 up to 1510, later on starting process again this is why we see exclamation mark and dots and exclamation again). We have sent 10 packets to starting from 1490 + 10 it means that last one was 1500B long and the router has 1500B MTU configured and droped the packets because was not able to fragment it due to DF bit set. The propose of this example was just to show way of test.

Example 2 – GRE over IPsec

Fragmentation can be a issue in case of use GRE over IPsec where end point that terminates the IPsec tunnel has to add GRE Header and next encrypts it all together. GRs header adds 24B to the packet, IPsec with ESP 56B so we have 80B overhead. As we have mentioned the best option to use in this case is PMTUD but what if routers on the path blocks the ICMP messages then the best option is to use optimum MTU size under tunnel GRE interface. GRE source router then will responsible for IP fragmentation befrore adding GRE and IPsec headers. To calulate the the MTU for tunnel the best option is to use sweep ping as above.

Let’s assume that we have GRE/IPsec between R1 and R3. We have experience issues related to the slow response time of application and high CPU on the R3 router. We expect that IP fragmentation is a culprit. We would to figure out what minimal MTU is on the path to adjust tunnel MTU to avoid IP fragmentation.
We are not able to ping with DF bit set to simulate traffic with GRE/IPsec because router will not copy DF bit in to IPsec header ( GRE tunnel cleares DF bit unless we use tunnel path-mtu discovery under tunnel GRE), istead of this we have to ping pure IP so for example remote head end of IPsec tunnel and be sure that this traffic will not be encrypted.

Test – test of minimal MTU on the path

R1#ping
Protocol [ip]:
Target IP address: 10.0.23.3
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface:
Type of service [0]:
Set DF bit in IP header? [no]: y
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]: y
Sweep min size [36]: 1300
Sweep max size [18024]: 1500
Sweep interval [1]:
Type escape sequence to abort.
Sending 1005, [1300..1500]-byte ICMP Echos to 10.0.23.3, timeout is 2 seconds:
Packet sent with the DF bit set
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!M.M.M.M.M.M.M.M.M.M.M.M.M.M.M.M.M.M.M.M
.M.M.M.
Success rate is 68 percent (101/147), round-trip min/avg/max = 4/19/60 ms

After 101 successful request so we get response for ICMP with 1300B lenght until 1400B so the minimal MTU on the path is 1400B. M means could not fragment. Then recomended is to lower IP MTU under GRE to minimal MTU on the path – 80B (24B for GRE and 56B for ESP tunnel IPsec).

To read more about IP Fragmentation, MTU, MSS and PMTUD issues with GRE and IPsec I recomend to read this very good and interesting Cisco Technology White Paper.

, , , , ,

It will be just overview about the Dynamic Host Configuration Protocol (DHCP) and background for post about DHCP snooping feature that will be posted soon. DHCP is the probably the most popular way of dynamic IP address assignment and other options like lease time, gateway and DNS IPs or domain name for the hosts in the PC enviroment.  DHCP works in a client – server architecture and the basic process of address assignments is depicted on the below figure.

 

We have 4-step process. First clients sends the DHCP Discovery request to the server. Because the client doesn’t have any idea what is a IP address of the server even more client doesn’t have IP address configured yet and it’s what is looking for, it sends layer 2 broadcast address with own MAC address as source and FFFF:FFFF:FFFF as destination MAC address. From the layer 3 perspecctive 0.0.0.0 is placed as IP source and 255.255.255.255 as destination broadcast. Server responds to the client with the DHCP Offer packet that includes client IP address proposition and with other options. Clients responds to the server with DHCP Request (request for IP address that is has been just offered to the client), and server confirm IP address assignment via DHCP ACK packet.

Above example was based on the LAN enviroment where client and server resides on the same subnet. What about if we have clients PC in the branch office and DHCP server in out data center HQ. The solution for this is DHCP Relay Agent feature needs to be configured on the LAN interface of the gateway router. Below diagram shows the process flow for the Relay Agent. 

 

 

From the client perspective nothing changed, this process is transparent and client doesn’t know even that traffic is going thru the WAN cloud to the data center on the other side of the world. By default
all subnet broadcast (255.255.255.255) is not forwarded unles ip helper-address is confgured.  Once the router gets the broadcast address with bootp on board and ip helper IP address is configured, router will encapsulate the DHCP Discover and sends it as unicast to the configured IP address in the ip helper-address command (it have to be DHCP server IP).