Layer 3 IP Models

How IP and IPv6 are modeled

Packet Tracer models only certain aspects of IP.

• IP version 4 is modeled.
• IP addresses are 32 bits long, and displayed using the dot-decimal notation, where each octet or byte of the IP address is displayed in decimal number and separated by a dot.
• All class A, B, and C addresses (1.0.0.0 to 224.255.255.255) except loopback addresses (127.0.0.0 to 127.255.255.255) can be assigned to ports.
• All IP packet fields are displayed in the PDU details.  However, only the following four fields are used: Destination IP Address, Source IP Address, TTL, and Protocol. 
• The Protocol field in the IP packet identifies the layer 4 PDU. When a device sends an IP packet, it places the value corresponding to the layer 4 process or service in the Protocol field. When a device receives an IP packet, it dispatches the layer 4 PDU to a process or service corresponding to the value of the Protocol field.

Packet Tracer also models IPv6.

• IP addresses are 128 bits long, and displayed as eight groups of four hexadecimal digits separated by colons.
• There are no classes of addresses in IPv6. Each address assignment has an address and a prefix in the format with / followed by the prefix length of the network.
• All IPv6 packet fields are displayed in the PDU details.  However, only the following four fields are in used: Destination IPv6 Address, Source IPv6 Address, Hop Limit, and Next Header. 
• The Next Header field in the IPv6 packet identifies the layer 4 PDU or the next option in the IPv6 header. When a device sends an IPv6 packet, it places the value corresponding to the layer 4 process or service in the Next Header field. When a device receives an IPv6 packet, it dispatches the layer 4 PDU or the IPv6 header to a process or service corresponding to the value of the Next Header field.

How devices process incoming ICMP packets

When a device receives an ICMP packet:

• It checks the ICMP message contained in the packet.
  • If the packet contains the message "TTL Exceeded" or "Echo Reply:"
    • It checks to see if it has recently sent an ICMP message with the same identification as the received ICMP message.
      • If so, it sends out the ICMP.

How devices process incoming ICMPv6 packets

ICMPv6 works similar to ICMP for Echo, Echo Reply, Hop Limit Expire (TTL Expire), Unreachable messages. For Neighbor Discovery (ND) messages, ICMPv6 process sends them to the ND process. Refer to ND process for more details.

How ND for IPv6 processes incoming packets

When an ND process for IPv6 receives a packet (flowchart here):

• If the packet is a Neighbor Solicitation, the process executes the following actions:
  • It will drop the packet if it doesn’t contain a Link Layer option.
  • If the destination IPv6 address doesn’t match with the receiving interface’s IPv6 address:
    • If there is an entry already exists in the ARP table, the entry will be updated with the information in the packet.
  • If matched,
    • If the host device is not a switch, the process will update the ARP table with information from the packet (source IPv6 address, source MAC address).
    • Then ND process creates an ARP Reply packet that contains its MAC address and sends to the source device.
• If the packet is a Neighbor Advertisement, the process executes the following actions:
  • It will drop the packet if it meets any of the following conditions:
    • It does not contain a Link Layer option.
    • It has not sent an ARP request but received an ARP reply
  • Otherwise, it will do the following actions:
    • The device’s ARP process will updates the ARP table with the received information.
    • If there are buffers contained in the received packet, the ARP process takes out these buffers and resends them.
• It the packet is a Router Solicitation, the process executes the following actions:
  • It will drop the packet if the message is a not valid Router Solicitation.  A valid Router Solicitation message must meet the following conditions:
    • The IP Hop Limit field has a value of 255.
    • ICMP code is 0.
    • ICMP length is 8 or more octets.
    • All included options have a length that is greater than zero.
    • If the IP source address is the unspecified address, there is no source link-layer address option in the message.
  • If the packet is a valid Router Solicitation, it will create a Router Advertisement and multicast it to the all-nodes group.
• If the packet is a Router Advertisement, the process executes the following actions:
  • It cancels any existing router solicitation timer scheduled on the receiving interface.
  • It retrieves information from the Router Advertisement such as source IPv6 address, prefix and prefix length, and with the receiving interface’s local link address, it creates an IPv6 address.
    • If the Router Advertisement’s prefix option is on-link, the ND process sets the newly created IPv6 address to the receiving interface.
    • If the Router Advertisement’s prefix option is off-link, the ND process removes the IPv6 address from the receiving interface.

How IP Does Fragmenting

Before sending out a packet, IP follows the process below (flowchart here):

• It checks if the total length (TTL) of the packet is greater than the MTU of the out-going interface. Note that setting of the mtu command will override the ip mtu command.
• If yes, it checks if the packet has the DF flag on.
• If yes, it drops the packet.
• It checks if TTL is less than or equal to the value configured via the command ip mtu.
• If yes, it sends the packet.
• It no,
  • It obtains the payload of the packet.
  • It does fragmenting on the payload.
  • It sends out fragments.

How IP Processes Reassembling

When IP receives an incoming packet (flowchart here):

• It checks if this packet is intended for this device.
  • If yes, the packet is sent to the reassembling function.
  • If no, it forwards to the routing or host process for more processing.
• Reassembling functionality:
  • It checks if the DF flag is on, and the fragment offset (FO) is 0.
  • If yes, it forwards to the routing or host process for more processing.
  • It checks if the buffer ID exists. The buffer ID is a combination of the source and destination address, and the protocol and identification fields of the IP header.
  • If yes, it loads the reassembling resource for this buffer ID.
  • If no, it creates a new reassembling resource for this buffer ID.
  • It updates necessary information for the reassembling resource with this fragment.
  • It checks if it is the last fragment:
  • If yes, it starts reassembling all received fragments.
  • If successful, it sends the IP packet to the routing or host process for more processing.
  • If not successful due to missing fragments, it drops all fragments and releases the reassembling resource.
  • If no, it starts or restarts the reassembling timeout timer for this buffer ID.

How IPv6 Does Source Fragmenting

Before sending out a packet at the source, IPv6 follows the process below (flowchart here):

• It checks if the total length (TTL) of the packet is greater than the MTU of the out-going interface. Note that setting of the mtu command will override the ipv6 mtu command.
• If no, it sends out the packet.
• If yes, it checks if TTL is less than or equal to the value configured via the command ipv6 mtu.
• If yes, it sends the packet.
• If no,
• It obtains the payload of the packet.
• It does fragmenting on the payload.
• It sends out fragments; each has the IPv6 Fragment Extension Header.

How IPv6 Does Path MTU Discovery at Middle Routers

Before sending out a packet at the middle router, IPv6 follows the process below (flowchart here):

• It checks if the total length (TTL) of the packet is greater than the MTU of the out-going interface.
• If yes, it triggers the Path MTU (PMTU) process to send out an ICMPv6 Packet-Too-Big message to the source.

How IPv6 Processes Reassembling

When IPv6 receives an incoming packet (flowchart here):

• It checks if this packet is intended for this device.
  • If yes, the packet is sent to the reassembling function.
  • If no, it forwards to the routing or host process for more processing.
• Reassembling functionality:
  • It checks the IPv6 fragment extension header if the M flag is off, and the fragment offset (FO) is 0.
  • If yes, it forwards to the routingv6 or hostv6 process for more processing.
  • It checks if the buffer ID exists. The buffer ID is a combination of the source and destination address, and the protocol and identification fields of the IP header.
  • If yes, it loads the reassembling resource for this buffer ID.
  • If no, it creates a new reassembling resource for this buffer ID.
  • It updates necessary information for the reassembling resource with this fragment.
  • It checks if it is the last fragment:
  • If yes, it starts reassembling all received fragments.
  • If successful, it sends the IP packet to the routing or host process for more processing.
  • If not successful due to missing fragments, it drops all fragments and releases the reassembling resource.
  • If no, it starts or restarts the reassembling timeout timer for this buffer ID.

How CBAC works

When a packet is send out of a router port (flowchart here):

• If the received port has an ACL configured and its an extended ACL:
  • It checks if the packet is part of an existing session:
    • If the lookup finds a matching entry in the session table :
      • It updates the session state table.
      • It sends to the lower process.
    • Or else if the packet is just a pass through packet after been checked by the received port:
      • It sends to the lower process.
    • Else
      • It looks for a matching acl statement:
        • If the packet is DENIED by the ACL, it DROPs the packet.
        • Else
          • It does the inspection and checks if an inspection rule is present or not:
            • If inspection rule is NOT present, it sends the packet to the lower process without inspection.
            • Else:
              • It creates a session entry and update the state table.
              • It sends out of the interface to the lower process.
• If acl is NOT present:
  • It does the inspection and checks if an inspection rule is present or not:
    • If inspection rule is NOT present, it sends the packet to the lower process without inspection.
    • Else
      • It creates a session entry and update the state table.
      • It sends out of the interface to the lower process.

When a router receives a packet (flowchart here):

• If the received port has an ACL configured and it is an extended ACL:
  • It checks if the packet is part of an existing session:
    • If the lookup finds a matching entry in the session table:
      • It updates the session state table.
      • It sends to the higher process.
    • If no matching session found:
      • It looks for an ACL matching statement:
        • if a matching statement found, it permits the packet and sends to the higher process.
        • if the packet is denied, it drops the packet.
• If no acl present, it sends the packet to the higher process.

How Zone based Firewall (ZFW) works

When a packet goes out of a zone based firewall router port (flowchart here):

• If ACL NOT present or ACL permits packet:
• ZFW checks if the received port and port to send are both zone members.
• If both the ports are members of any zone, ZFW finds a match for the current zone-pair (recv port - send port zone pair).
• If a match FOUND, it gets the policy map for this zone-pair and go through the classmap list.
• If a matching class map statement FOUND:
• If the policy-classmap action is to "drop" or no action set (default action is to drop), it creates a session and updates the state table and drops the packet.
• Else it creates a session and updates the state table. Then it passes the packet to the lower layer.
• If matching zone-pair NOT found, it drops the packet.
• Else if either one of the ports is not part of any zone member, it drops the packet.
• Or else if both the ports are not part of any zone member ( ie., router is not configured fully for Zone based firewall), it passes the packet to the lower layer.
• Else if ACL drops the packet, ZFW drops the packet.

When a packet is received on a zone based firewall router port (flowchart here):

• The packet is checked for a matching entry in the session table to see if it is part of an existing session:
• If a matching entry FOUND, it updates the state table entries and passes it to the higher layer/process.
• If NO matching entry found in the session table, it checks if the packet is intended for THIS router:
• If so, it looks for a matching self-zone/zone-self pair.
• If a matching zone-pair FOUND:
• It creates a session entry and update the state table.
• It passes the packet to the higher layer.
• If a matching zone-pair is NOT found, it passes the packet to the higher layer.

How IPS Signature Scan Works

ICMP (2004:0) signature is the only ips signature that is currently supported in PT. The signature is made a built-in signature. The ips config location and category needs to be configured and the ips rule needs to be applied to the interface in order to enable IPS on a router (flowchart here):

• If IPS enabled, the device checks if ACL is present.
• If ACL NOT present or acl PERMITS the packet, The device scans through the signature list to see if the signature is unretired and enabled.
• If UNRETIRED and ENABLED:
• If the signature matches, it does all the actions defined for this signature:
• If action has to deny the packet along with others, it denies the packet.
• Else it passes the packet to higher/lower layer.
• If ACL DENIES the packet, the device denies the packet and returns from IPS.
• If IPS is not enabled, the device returns from IPS, does ACL match, and proceeds.

How Outside NAT Works

When a packet is sent out of the router port (flowchart here):

• If the received port was NOT inside nat port, or the sending port is NOT an outside nat port, or the packet header is invalid:
• It passes the packet to the lower layer - NO translation done.
• Else
  • It lookups the NAT table for a matching dynamic entry for the local addresses.
  • If match FOUND,
  • It starts the timer.
  • It does the packet translation.
  • It passes the packet to the lower layer.
  • If match NOT found
    • It looks up the table for static matching entry for both source and destination.
    • If match FOUND for SOURCE and DESTINATION, or if match FOUND for SOURCE only, or match FOUND for destination only
    • It creates a dynamic entry in the nat table.
    • It does the packet translation.
    • It passes the packet to the lower layer.
    • Else if NO match found,
    • It passes the packet to the lower layer - NO translation done.

When a packet is received by a router port (flowchart here):

• If NAT is NOT configured on the received port or the received packet header is invalid
• It passes the packet to the higher layer - no translation done.
• If received port is a nat inside port
• It passes the packet to the higher layer.
• If NOT inside port, check is received port is an outside NAT port.
• If NOT outside port, it passes packet to the higher layer.
• Else if the received port is an OUTSIDE nat port:
• It looks up the nat table for a matching dynamic entry for the global addresses:
• If match FOUND:
• It starts timer.
• Packet is translated from global to local - Nat translation done.
• It passes the packet to the higher layer.
• If NOT found:
• Looks up the static matching entry for both source and destination addresses:
• If match FOUND for SOURCE and DESTINATION:
• It creates a new dynamic entry and add to the nat table.
• It does the packet translation.
• It passes the translated packet to the higher layer.
• Else if match FOUND only for SOURCE
• It checks whether the next hoping router port is an inside NAT port.
• If NOT:
• It passes the packet to the higher layer - No translation done.
• If the next hop port is INSIDE nat port:
• It creates a new dynamic entry and add the nat table.
• It does the packet translation.
• It passes the packet to the higher layer.
• Else if match FOUND only for DESTINATION:
• It creates a new dynamic entry and add to the nat table.
• It does the packet translation.
• It passes the translated packet to the higher layer.

How QoS Works

When a packet is going out of a router interface (flowchart here):

• It classifies the packet based on shaping configured.
• If shaping configured:
• It checks if shaping is full:
• If yes, it drops the packet.
• If no, it puts the packet in shape queue. Then it starts the timer and checks if software queue is full.
• If yes, it drops the packet.
• If no, it puts in software queue.
• Else if not configured:
• It checks if the software queue is empty or not.
• If NOT EMPTY, it calculates using the Weighted Random Early Detection (WRED) whether the packet can be dropped or not. A packet is dropped if the average queue size is greater that maximum threshold or average queue size is between minimum and maximum threshold and the packet count meets the threshold mark. If WRED calculates to DROP the packet:
• If yes, it drops the packet.
• Else, it checks if the software queue is full or not:
• If FULL, it drops the packet.
• Else, it puts the packet in the software queue.
• If EMPTY:
  • It checks if hardware queue is full or not:
  • If FULL, it puts in software queue.
  • If NOT,
  • It puts the packet the in hardware queue.
  • If the hardware queue has packet,
  • It sends the packet out of the interface
  • Retrieves packets from the software queue
  • places it in the hardware queue.

How Devices Handle GRE Packets

When a device sending a GRE packet (flowchart here):

• If a packet getting out of the device is having the same source IP address as one of the tunnel interfaces that is configured on the device:
• It encapsulates it in GRE header.
• IP layer encapsulates the GRE header in another IP header with source and destination address of associated tunnel interface.

When a device receiving a GRE packet (flowchart here):

• After Ethernet and IP header are removed from the received data:
• If the receiving packet has GRE header:
• GRE header is removed and hand it in to the associated tunnel interface.
• Tunnel interfaces pass it up to the IP layer for the further processing.

How Routers Handle ESP/AH Segments

When a router sending an ESP/AH segment (flowchart here):

• If the packet is getting out of the device is not encrypted, and it is interested traffic, and if the outgoing port is configured with the crypto map:
• ISAKMP negotiation for security SAs:
• If Successful:
• It gets the SA for the interested flow and encapsulates the packet in the ESP packet:
• If SAs has been negotiated for AH, the router encapsulates ESP in AH segment and sends it to the lower layers to process.
• Otherwise, it sends the ESP segment to the lower layers to process.
• Otherwise, it drops the packet.

When a router receiving an ESP/AH segment (flowchart here):

• If the packet receiving on the port is ESP/AH packet.
• If the port is not configured with a crypto map command, it drops the packet.
• Otherwise
• If the ESP/AH packet has matching ESP/AH SA numbers:
• If packet is encapsulated in AH, AH authenticates the packet and removes the AH header and pass the packet to ESP.
• ESP decrypts the packet and removes the ESP header. Also it passes the decrypted packet to the next layer of data for further processing.
• Otherwise, it increments the error counter for the specific flow that matches the packet and drops the packet