Handling Of Switch-Destined Traffic - Dell S4048T Configuration Manual

• Packets whose destination TCP/UDP port does not match a configured management application, take
the regular route lookup flow in the IP stack.
• In the ARP layer, for all ARP packets received through the management interface, a double route lookup
is done, one in the default routing table and another in the management EIS routing table. This is
because in the ARP layer, we do not have TCP/UDP port information to decide the table in which the
route lookup should be done.
• The show arp command is enhanced to show the routing table type for the ARP entry.
• For the clear arp-cache command, upon receiving the ARP delete request, the route corresponding
to the destination IP is identified. The ARP entries learned in the management EIS routing table are also
cleared.
• Therefore, a separate control over clearing the ARP entries learned via routes in the EIS table is not
present. If the ARP entry for a destination is cleared in the default routing table, then if an ARP entry for
the destination exists in the EIS table, that entry is also cleared.
• Because fallback support is removed, if the management port is down or the route lookup in EIS table
fails packets are dropped. Therefore, switch-initiated traffic sessions that used to work previously via
fallback may not work now.

Handling of Switch-Destined Traffic

• The switch processes all traffic received on the management port destined to the management port IP
address or the front-end port destined to the front-end IP address.
• If the source TCP/UDP port number matches a configured EIS or non-EIS management application and
the source IP address is a management Port IP address, then the EIS route lookup is done for the
response traffic and hence is sent out of the management port. In this case, the source IP address is a
management port IP address only if the traffic was originally destined to the management port IP.
• ICMP-based applications like ping and traceroute are exceptions to the preceding logic since we do not
have TCP/UDP port number. So if source IP address of the packet matches the management port IP
address EIS route lookup is done.
• Management application packet counter is incremented if EIS route lookup succeeds and packet is sent
out of the management port.
• If route lookup in the EIS routing table fails or if the management port is down, then packets are
dropped. The management application drop counter is incremented.
• Whenever IP address is assigned to the management port, it is stored in a global variable in the IP stack,
which is used for comparison with the source IP address of the packet.
• Rest of the response traffic is handled as per existing behavior by doing route lookup in the default
routing table. So if the traffic is destined to the front-end port IP address, the response is sent out by
doing a route lookup in the default routing table, which is an existing behavior.
Consider a sample topology in which ip1 is an address assigned to the management port and ip2 is an address
assigned to any of the front panel port. A and B are end users on the management and front-panel port
networks. The OS-initiated traffic for management applications takes a preference for ip1 as source IP and
uses the management network to reach the destination. If the management port is down or the route lookup
in EIS routing table fails, ip2 is the source IP and the front-panel port is used to reach the destination. The
fallback route between the management and data networks is used in such a case. At any given time, end
Internet Group Management Protocol (IGMP) 445