Bug 947

Summary: Need function for printing routing tables
Product: ns-3 Reporter: Antti Mäkelä <antti.makela>
Component: routingAssignee: Hemanth Narra <hemanthnarra222>
Status: RESOLVED FIXED    
Severity: enhancement CC: gjcarneiro, tomh
Priority: P5    
Version: pre-release   
Hardware: All   
OS: All   
Bug Depends on:    
Bug Blocks: 963    
Attachments: Patch to print the routing tables to the trace files

Description Antti Mäkelä 2010-06-21 08:03:02 UTC 
Hey,

  There's been ton of requests on ns-3-user on how to print routing table. I think it would be prudent for the simulator to provide such functionality by itself. So setting up this bug for further discussion.

  I myself use a function PrintRoutingTables(Ptr<Node> node) that basically assumes that GlobalRouting and StaticRouting are on every node and walks through the routes, printing them. However, a more generic solution might be something like this:

Grab Ipv4ListRouting object out of Node
Get number of routing protocols via Ipv4ListRouting -> GetNRoutingProtocols()

Grabs all routing protocols into a map<uint16_t priority, Ptr<IPv4RoutingProtocol> >

Iterate through the map (at this point a priority-sorted array of routing protocols), and grabbing the routing information as appropriate for each protocol. Basically attempt a DynamicCast<Routingprotocol> for every object and, eventually, get an array of Ipv4RoutingTableEntry objects, and then print them out.

However, probably a better design would be to define PrintRoutes() as a virtual for Ipv4RoutingProtocol where each protocol would have to implement printing out their table. For ListRouting this would simply mean calling the function for all routing protos in the list and let dynamic binding worry about the rest.

Now, you'd obviously have to decide output format. Just ASCII, or something parseable? Should a simple string be returned, or maybe something else (vector <Ipv4RoutingTableEntry>?). 

Hopefully there will eventually be a "standard" approach...
Comment 2 Antti Mäkelä 2010-06-21 12:29:52 UTC 
Better mention this in FAQ then (and if there is a C++ version too) :), as it seems genuinely rather frequently asked question.
Comment 3 Gustavo J. A. M. Carneiro 2010-06-21 13:15:31 UTC 
No, I don't mean to say "just use PyViz".  I meant more in the sense that, 1) yes, there is a real need for this, so much that I wrote it into pyviz, 2) there's some code that may be used as basis if someone wants to convert to C++.  That's all.
Comment 4 Tom Henderson 2010-06-24 01:36:34 UTC 
I strongly agree on the need for this.  I think the main issue is to agree on the API.  

At the lowest level (Ipv4RoutingProtocol) there probably should be a method or methods that exports containers of Ipv4Routes and Ipv4MulticastRoutes via some Get() method.  There probably should be callbacks for asynchronous notifications of route deletes and additions.  There should probably be a method such as
virtual void Print (std::ostream &os) const = 0;
for pretty printing using a protocol's own format.

At the helper layer, I envision that it could be similar to ascii tracing, where the class Ipv4RoutingHelper and Ipv6RoutingHelper could be extended with methods like:

  PrintRoutes (Ptr<Node>, Ptr<OutputStreamWrapper>);
  PrintRoutesAt (Ptr<Node>, Ptr<OutputStreamWrapper>, Time);  // schedule for particular time
  PrintRouteChanges (Ptr<Node>, Ptr<OutputStreamWrapper); // asynchronous
  // Node container versions of the above

Additional helpers could be defined in the future to, e.g. format the output similar to the output of Linux ip command.

Comments on something like the above API, or other suggestions?
Comment 5 Hemanth Narra 2010-10-17 17:52:58 UTC 
Created attachment 1000 [details]
Patch to print the routing tables to the trace files

Taking clues from Tom's suggestion, I have created a patch to print the routing tables to the trace file. Please find the attached patch.
Comment 6 Tom Henderson 2010-12-13 01:26:28 UTC 
I created a proposed final patch, and moved to codereview to better collect any comments:

http://codereview.appspot.com/3613041/
Comment 7 Tom Henderson 2010-12-13 01:29:11 UTC 
*** Bug 963 has been marked as a duplicate of this bug. ***
Comment 8 Tom Henderson 2010-12-23 18:21:28 UTC 
changeset: a590022a1536