IPv4 Routing behaviour after interface SetDown procedure

[Egemen Cetinkaya]

Hi,

I am trying to simulate a scenario which brings down a PointToPoint
link between a node pair. The topology consists of three nodes, no
loop, and using GlobalRoute manager to route OnOff traffic. To
accomplish this we used Ipv4::SetDown and Ipv4::SetUp procedures.

It looks like setting down and setting up the IPv4 interfaces (of the
source node and the hop node) are working fine. Although, I am
observing that after setting the "interfaces up", the source does not
able to send the packets. Below is the portion in the logs I think as
problematic:

1800000000ns Ipv4L3Protocol:SendRealOut(): No route to host. Drop.

My interpretation of the "Ipv4L3Protocol:SendRealOut(): No route to
host. Drop." is that:

A-This can be due to LSAs not being sent on a regular basis (or maybe
they are being performed without showing anything in the logs). I
observed in the logs that Link State algorithm do calculations only at
the beginning of the script. At the end the LS data is cleared due to
Simulation:Destroy command.

or

B-In the ipv4-l3-protocol.cc file it states that (starting line 596):

" XXX Note here that in most ipv4 stacks in the world, the route
calculation for an outgoing packet is not done in the ip layer. It is
done within the application socket when the first packet is sent to
avoid this costly lookup on a per-packet basis. That would require us
to get the route from the packet, most likely with a packet tag. The
higher layers do not do this yet for us. "

Which I interpret, since there is no IP layer calculation, after the
interface is brought up, application socket doesn't know how to route
the packets. (But why, I don't know)

Now, my first question is what should I do for the source node to be
able to forward the packets after its interface is setdown and setup?
I was thinking to reinitialize GlobalRouterManager via a schedule, but
the script complained about using the PopulateRoutingTables (); since
it was used previously to initialize/populate routing tables.

Second question is: do you think not sending LSAs periodically is the
normal behaviour, or can it be a bug?

Thank you beforehand for your help,

Regards,

Egemen

[Gustavo Carneiro]

2008/11/6 Egemen Cetinkaya <egemen.c...@gmail.com>

I don't think that XXX is related to your problem, don't worry.  The XXX only mentions a possible optimization, to make things faster, not anything that would change any semantics.
 

Now, my first question is what should I do for the source node to be
able to forward the packets after its interface is setdown and setup?
I was thinking to reinitialize GlobalRouterManager via a schedule, but
the script complained about using the PopulateRoutingTables (); since
it was used previously to initialize/populate routing tables.

Second question is: do you think not sending LSAs periodically is the
normal behaviour, or can it be a bug?

In the "real world", when an interface goes down and is later brought back up, one of two things normally happen.  If the node is a router, the routing protocol will add the needed IP routing table entries, after a few seconds.  If it is a terminal, the O.S. should automatically trigger a DHCP request, and the reply would cause a "default gateway" routing table entry to be added.

Since you are using GlobalRoutingManager, I must say that this is a problem caused by the way GlobalRoutingManager works, and so GlobalRoutingManager should be fixed.  IMHO, if PopulateRoutingTables cannot be called again in the middle of the simulation, it is a bug that needs to be fixed.  So, file a bug report in nsnam bug tracker.

While you wait for a bug fix, you can do one of two things: 1. try to fix the bug yourself ;) or, 2. work around it, i.e. when you bring the network interface up manually add an appropriate routing table entry.

Regards,
--
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert