Implementation and Research of the Routing Table Function Calls

Over the past week, I have been working on mainly setting up the rest of the interfaces and getting them to work correctly on the board as well as researching and 'implementing' the routing table with Matthew.  In fact, while researching through the Nichestack functions for anything related to routing tables, most of the functions used to manipulate the routing table are already provided for us by the Nichestack/Simple Socket Server library.

To get the other two interfaces on the board to work with the previous two interfaces that we set up last quarter, I basically revised the SOPC design by adding in two extra Triple-Speed Ethernet MACs (for the PHY layer of the interfaces) as well as two extra sets of SGDMAs (two transmit SGDMAs and recieve SGDMAs) and  that can be used by the MACs to assist on forwarding packets and reducing overhead for the processor on the DE4 board.  The design is then implemented in Verilog code by adding and changing the code that was similarly used to implement the first two interfaces of the board.  Doing this allowed the board to recognize the two new interfaces and different MAC addresses were successfully given to all four ports.  Afterwards, Matthew and I tested the two new interfaces by pinging packets to the different subnetworks created by the four ports.  The ping packets were successfully forwarded to their respective destinations (i.e. 192.168.1.55 was able to ping to 192.168.0.52 by going through the board's two ports with IP addresses 192.168.1.51 and 192.168.0.51)

With forwarding functionality finally implemented on our board, Matthew and I then proceeded to the next agenda in our Gantt Chart: manipulation of the routing table.  Again, pretty much everything essential for a static routing table has been given to us by the Nichestack/Simple Socket Server library, so most of the time, we did research on how each routing table function works as well as where these functions are subsequently called and how they are being used.  The three main routing functions are rt_lookup, which basically looks up for a specific entry in the static routing table, add_route, which adds entries to the routing table, and del_route, which deletes entries in the routing table.

There are two methods in the Altera board support package that call rt_lookup: 'add_share_route' which is located in the file 'ipnet.c', and 'iproute' which is located in the file 'ip.c'.  'add_share_route' basically creates an entry in the routing table such that packets that use the source address of this entry will be forced out the same interface that it came from.  rt_lookup is used in this method to check if the entry is already in the routing table; if the entry is already there, its gets updated. If the entry does not exist yet, 'add_share_route' adds an entry that uses either the gateway address of the interface, the IP address of the interface, or the IP address of the original sender of the packet.  'iproute' is used to correctly route a packet  the correct interface on the board. uses 'rt_lookup' to find the IP address of the next hop/destination link on an entry in the routing table.  The static routing table also uses a single entry cache to determine if the most recently used entry of the routing table is the desired entry.

'add_route' is also called in 'iproute', as well as methods 'icmprcv', 'pcn_init', 'mn_add_route', and 'dhc_reclaim'. 'iproute calls 'add_route' when 'rt_lookup' fails to find a valid entry in the routing table. 'icmprcv' is a callback function that handles incoming received ICMP packets by determining what should be done to them depending on the type of ICMP message (i.e. prints a simple message or forwards it to a particular interface, etc.).  'icmprcv' calls 'add_route' whenever the ICMP packet is of message type 'REDIR' (redirect), which is used to inform a host to update its routing informaion in order to send its packets on an alternative route.  'pcn_init' is also a callback function that keeps track of the time it takes (cycles) to create the net interfaces.  'pcn_init' calls 'add_route' to add a route entry to match the interfaces that were created. I am not exactly sure of what 'mn_add_route' does, but I think it provides a menu interface for the user that allows the user to manually add a routing entry to the routing table.  'add_route' here is obviously called to make 'mn_add_route' functionable.  'dhc_reclaim' is used to work like DHCP Discover, but instead it is specifically used for machines that had a DHCP address before, but wants to reclaim the address back from the server.

The only method that 'del_route' is called in is at 'ni_set_state', which allows a network interface to be turned on or off based on the opcode parameter given to the function itself.  'ni_set_state' uses 'del_route' to flush all the routing table and ARP entries that are assigned to the interface specified by the parameter 'ifp' in 'ni_set_state'.

As of now, Matthew and I are currently trying to figure out on how to get ARP packets to forward correctly when all the interfaces on the router board are all assigned on the same sub-network.  This might be done by bridging the interfaces together, but we're not sure if the static routing table would work afterwards.