| Description | This article describes how to check the IP routing flow process under FortiSwitch. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Scope | Any FortiSwitch that supports the IP routing feature. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Solution |
When talking about forward all IP packets, it means IP routing from one interface to another. On this topology, PC1 is going to send IP packets to PC2, which has to be routed by the FortiSwitch-1 and FortiSwitch-2. To reach the subnet 192.168.4.x, it is necessary to set the IPs needed and create a static route back and forth.
Here is the configuration:
Configure static route:
FortiSwitch-2: Is the same process as the number 1:
Static route:
Previously IP address has been set to PC1 and PC2 with its own Gateway. It is now possible to reach the network 192.168.4.1 and vice versa:
PC2> ping 192.168.3.1 84 bytes from 192.168.3.1 icmp_seq=1 ttl=62 time=2.032 ms
PC1 creates an IP packet using its IP address 192.168.3.1 as the source. But using the IP 192.168.4.1 as the destination, PC1 has now a challenge to figure out evaluating if the destination is local or remote. In this case, PC1 is under the 192.168.3.1: 254 range and the IP 192.168.4.1 is not local. For that reason, it is necessary to use the default Gateway. Now a second challenge to PC1 is to know the destination MAC address from the default Gateway, and ARP table from PC1 shows the MAC address that belongs to the port1 Switch Gateway interface:
PC1> arp 0c:4e:73:60:00:01 192.168.3.254 expires in 118 seconds
The ethernet frame will be reflected like this under the FortiSwitch:
If the FCS is not correct, it is dropped immediately, if the FCS is correct, the frame will be processed this way:
In this scenario, the number 2 option is working for us using port1 from FortiSwitch-1. Also, another requirement to validate is the Header Checksum, if it does not have any error no issues here, otherwise it will be dropped.
Remember the Ethernet frame has the following fields:
Now at this point, the IP packet field is needed for the flow process, this field is divided into the following fields:
Let´s check the routing table under FortiSwitch-1, this Switch knows how to reach 192.168.4.0/24 network using the next hop 192.168.13.2 using the internal interface:
S108DVNEHL-----F # get router info routing-table Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - IS-IS, B - BGP, T - Table, > - selected route, * - FIB route, q - queued, r - rejected, b - backup, ^ - HW install failed t - trapped, o - offload failure
C>* 192.168.3.0/24 is directly connected, GWInt, 23:30:39 S>* 192.168.4.0/24 [10/0] via 192.168.13.2, internal, weight 1, 04:52:53 C>* 192.168.13.0/28 is directly connected, internal, 05:39:00
One field is in place, it is called TTL (Time to Live) which will be decreased by one, FortiSwitch-1 will do this by changing the IP header and calculating again the checksum.
Let´s check the FortiSwitch-1 ARP table, it is doing a match with the IP internal from FortiSwitch-2, if the ARP is empty, FortiSwitch-1 will be doing an ARP request to find out the MAC address from 192.168.13.2:
S108DVNEHL-----F # get system arp Address Age(min) Hardware Addr Interface 192.168.13.2 1 aa:81:8e:e7:a8:43 internal 192.168.3.1 8 00:50:79:66:68:00 GWInt
Now a net IP packet is encapsulated in a new Ethernet frame like this pointing to FortiSwitch-2:
FortiSwitch-2 will be doing the same as FortiSwitch-1, check the FCS, de-encapsulate the IP packet, check the IP header checksum, and check the destination IP address. The routing table from FortiSwitch-2, 192.168.4.0 is directly connected to GWInterf the TTL of the IP packet will be reduced by ONE from 254 to 253, this is the ideal number, but the value can be chosen randomly by another one.
S108DVAJT9-----D # get router info routing-table Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - IS-IS, B - BGP, T - Table, > - selected route, * - FIB route, q - queued, r - rejected, b - backup, ^ - HW install failed t - trapped, o - offload failure
S>* 0.0.0.0/0 [10/0] via 192.168.13.1, internal, weight 1, 05:19:57 C>* 192.168.4.0/24 is directly connected, GWInterf, 23:48:01 C>* 192.168.13.0/28 is directly connected, internal, 06:00:07
Let’s check the ARP table from FortiSwitch-2:
S108DVAJT9-----D # get system arp Address Age(min) Hardware Addr Interface 192.168.4.1 0 00:50:79:66:68:01 GWInterf 192.168.13.1 1 4a:ed:10:7f:00:01 internal
A new Ethernet frame is created in the following way:
Now let´s validate the TTL value from FortiSwitch-1 under a packet capture which is 64:
Now let´s validate the TTL value from FortiSwitch-2 which is 62, and the TTL always decreases till the destination:
The reason why TTL decremented 2, Is because PC1 is doing 2 hops:
PC1> trace 192.168.4.1 trace to 192.168.4.1, 8 hops max, press Ctrl+C to stop 1 192.168.3.254 0.648 ms 0.567 ms 0.439 ms 2 192.168.13.2 3.838 ms 3.328 ms 2.989 ms 3 *192.168.4.1 4.561 ms |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
