32bit address issue (ns-3.2 stable)

[Norman]

Hello,
Does anybody know if it is possible to assign /32 address to node (not
necessarily using a helper - I'm aware of that bug), that will act as
RID (Router ID).
I'm basically looking for a sort of Loopback 0 interface (in Cisco
terminology).
I tried to achieve this goal doing something like this:

void makerid(char *ipaddr, Ptr<Node> n) {
ObjectFactory m_queueFactory;
m_queueFactory.SetTypeId ("ns3::DropTailQueue");
ObjectFactory m_deviceFactory;
m_deviceFactory.SetTypeId ("ns3::CsmaNetDevice");
ObjectFactory m_channelFactory;
m_channelFactory.SetTypeId ("ns3::CsmaChannel");

Ptr<CsmaChannel> channel = m_channelFactory.Create ()-
>GetObject<CsmaChannel> ();
Ptr<CsmaNetDevice> csmadevice =
m_deviceFactory.Create<CsmaNetDevice> ();
csmadevice->SetAddress (Mac48Address::Allocate ());
csmadevice->SetName("rid");
n->AddDevice (csmadevice);
Ptr<Queue> queue = m_queueFactory.Create<Queue> ();
csmadevice->SetQueue (queue);
csmadevice->Attach (channel);

Ptr<NetDevice> device;
for(uint32_t i=0; i < n->GetNDevices(); i++) {
device = n->GetDevice(i);
if(device->GetName() == "rid") {
Ptr<Node> node = device->GetNode ();
NS_ASSERT_MSG (node, "Ipv4AddressHelper::Allocate(): Bad node");
Ptr<Ipv4> ipv4 = node->GetObject<Ipv4> ();
NS_ASSERT_MSG (ipv4, "Ipv4AddressHelper::Allocate(): Bad ipv4");
int32_t ifIndex = ipv4->FindInterfaceForDevice (device);
if (ifIndex == -1) {
ifIndex = ipv4->AddInterface (device);
}
NS_ASSERT_MSG (ifIndex >= 0, "Ipv4AddressHelper::Allocate():
Interface index not found");
Ipv4Address ip(ipaddr);
ipv4->SetAddress (ifIndex, ip);
ipv4->SetNetworkMask (ifIndex, 0xffffffff);
//ipv4->SetNetworkMask (ifIndex, 0xffffff00);
ipv4->SetMetric (ifIndex, 1);
ipv4->SetUp (ifIndex);
}
}
}

However such a approach doesn't work. In short I tried to create an
extra interface that would act as loopback.
What I noticed is that if interface is created (doesn't matter which
one i.e. p2p or csma), and has only one "client" i.e. nobody else is
connected to that interface it doesn't work.

For testing I'm using modified version of "first.cc", and what to
achieve (topology below) is to have a transmission from router's A
loopback 5.2.0.4 to router's B loopback 5.2.0.2 (in a similar way
like multihop BGP works).

RouterA(RID: 5.2.0.4) .73 <= p2p: 1.0.1.72/30 => .74 RouterB (RID:
5.2.0.2)

One more thing. I'm using global route manage to populate routing
tables.

Your input is highly appreciated!

Thanks,

--
Norman

[Gustavo Carneiro]

2008/11/24 Norman <baz.n...@yahoo.com>

Your code above seems awfully complicated.  I would suggest looking at Ipv4L3Protocol::SetupLoopback in src/internet-stack/ipv4-l3-protocol.cc and do the same thing that it does but with your custom address.  If it doesn't work then look for other more complicated solutions, but at least try the simple thing first.

Hope it helps.

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

[Mathieu Lacage]

hi,

On Mon, 2008-11-24 at 03:45 -0800, Norman wrote:
> Hello,
> Does anybody know if it is possible to assign /32 address to node (not
> necessarily using a helper - I'm aware of that bug), that will act as
> RID (Router ID).
> I'm basically looking for a sort of Loopback 0 interface (in Cisco
> terminology).

I am not sure this is related to your problem, but there is already a
loopback interface with address 127.0.0.1 which is automatically added
to every ipv4 stack when it is aggregated to a node.

regards,
Mathieu

[Norman]

Hi Gustavo,

Many thanks for your suggestion.
Are you sure that this object/functions are meant to use directly?
From what I see there is not header file in "./build/debug/ns3/" for
Ipv4LoopbackInterface.
[ this is not a problem since I can use the one from "./src/internet-
stack",
but what bothers me is the fact that AddIpv4Interface() method is
private for object "Ipv4L3Protocol" and I'm not sure how to use it
properly before starting to modifying "ns".

Snip from: "src/internet-stack/ipv4-l3-protocol.cc":
void
Ipv4L3Protocol::SetupLoopback (void)
{
NS_LOG_FUNCTION_NOARGS ();

Ptr<Ipv4LoopbackInterface> interface =
CreateObject<Ipv4LoopbackInterface> ();
interface->SetNode (m_node);
interface->SetAddress (Ipv4Address::GetLoopback ());
interface->SetNetworkMask (Ipv4Mask::GetLoopback ());
uint32_t index = AddIpv4Interface (interface);
AddHostRouteTo (Ipv4Address::GetLoopback (), index);
interface->SetUp ();
}

And below what I'm trying to do:
void makerid2(char *ipaddr, Ptr<Node> n) {
Ptr<Ipv4LoopbackInterface> interface =
CreateObject<Ipv4LoopbackInterface> ();
Ptr<Ipv4StaticRouting> srt = CreateObject<Ipv4StaticRouting> ();
Ipv4Address ip(ipaddr);
interface->SetNode (n);
interface->SetAddress (ip);
interface->SetNetworkMask (0xffffffff);

uint32_t index = AddIpv4Interface (interface);
srt->AddHostRouteTo (ip, index);
interface->SetUp ();
}

That's the error I get once trying to run it:
[469/513] cxx: scratch/myfirst.cc -> build/debug/scratch/myfirst_4.o
../scratch/myfirst.cc: In function 'void makerid2(char*,
ns3::Ptr<ns3::Node>)':
../scratch/myfirst.cc:236: error: 'AddIpv4Interface' was not declared
in this scope
Build failed
-> task failed (err #129): [bld:///wrk/ns3/ns-3.2/scratch/
myfirst_4.o]

This is because AddIpv4Interface is a private method,
any idea how to solve it nicely without any modification to ns?

Thanks,

--
Norbert

[Norman]

Hi Mathieu,

Is there any way to assign a second address to that loopback,
so that I could have 127.0.0.1 and my RID on that interface?

Thanks,

--
Norman

[Mathieu Lacage]

On Mon, 2008-11-24 at 07:36 -0800, Norman wrote:
> Hi Mathieu,
>
> Is there any way to assign a second address to that loopback,
> so that I could have 127.0.0.1 and my RID on that interface?

No, multiple address per interface is a feature tom is working on for
the next version of ns-3 (ns-3.5).

But you could easily add a copy of LoopbackIpv4Interface which does what
you want.

sorry,
Mathieu

[Mathieu Lacage]

There is no other way than to patch the src/internet-stack directory.

Mathieu

[Norman]

Hi Mathieu,

I did as you advised with Gustavo and patched internet-stack.
The only thing I did was a small change i.e. I made method
SetupLoopback() (from Ipv4L3Protocol object) public,
and added an overloaded version of the same method, that takes
IPaddress as an argument and returns interface index
(for setting an alternative loopbacks).

<diff>
$ diff -u ns-3.2.orginal/src/internet-stack/ipv4-l3-protocol.cc ns-3.2/
src/internet-stack/ipv4-l3-protocol.cc
--- ns-3.2.orginal/src/internet-stack/ipv4-l3-protocol.cc 2008-11-16
01:08:43.000000000 +0100
+++ ns-3.2/src/internet-stack/ipv4-l3-protocol.cc 2008-11-24
23:48:39.000000000 +0100
@@ -117,7 +117,7 @@
Ipv4L3Protocol::SetNode (Ptr<Node> node)
{
m_node = node;
- SetupLoopback ();
+ //SetupLoopback (); //me
}

void
@@ -157,6 +157,23 @@
interface->SetUp ();
}

+uint32_t
+Ipv4L3Protocol::SetupLoopback (Ipv4Address ipaddr)
+{
+ NS_LOG_FUNCTION_NOARGS ();
+
+ Ptr<Ipv4LoopbackInterface> interface =
CreateObject<Ipv4LoopbackInterface> ();
+ interface->SetNode (m_node);
+ interface->SetAddress (ipaddr);
+ interface->SetNetworkMask (0xffffffff);
+ uint32_t index = AddIpv4Interface (interface);
+ AddHostRouteTo (ipaddr, index);
+ interface->SetUp ();
+ return index;
+}
+
+
+
void
Ipv4L3Protocol::SetDefaultTtl (uint8_t ttl)
{
</diff>

Also I had to include functionality of internet stack helper and
"internet-stack.cc" files/classes into my program
so I copied all of the necessary functions as they were with a slight
modification to function AddInternetStack(), in which
I basically added new version of AddIpv4Stack function called
AddIpv4Stack2().

void
AddInternetStack (Ptr<Node> node)
{
AddArpStack (node);
//AddIpv4Stack (node);
AddIpv4Stack2 (node);
AddUdpStack (node);
AddTcpStack (node);
}

here how it looks:

static void
AddIpv4Stack2(Ptr<Node> node)
{
Ptr<Ipv4L3Protocol> ipv4 = CreateObject<Ipv4L3Protocol> ();
ipv4->SetNode (node);
ipv4->SetupLoopback();

Ipv4Address myloopback("1.2.3.4");
uint32_t index = ipv4->SetupLoopback(myloopback);
std::cout << "index: " << index << std::endl;

node->AggregateObject (ipv4);
Ptr<Ipv4Impl> ipv4Impl = CreateObject<Ipv4Impl> ();
ipv4Impl->SetIpv4 (ipv4);
node->AggregateObject (ipv4Impl);

Ipv4Address ip("127.0.0.1");
std::cout << "lo: " << ipv4->FindInterfaceForAddr (ip) << std::endl;
Ptr<Ipv4Interface> ipv4intf = ipv4->GetInterface (ipv4-
>FindInterfaceForAddr(ip));
Ipv4Address addr = ipv4intf->GetAddress();
std::cout << "lo addr : " << addr << std::endl;

Ipv4Address ip2("1.2.3.4");
std::cout << "lo: " << ipv4->FindInterfaceForAddr (ip2) <<
std::endl;
ipv4intf = ipv4->GetInterface (ipv4->FindInterfaceForAddr(ip2));
addr = ipv4intf->GetAddress();
std::cout << "lo addr : " << addr << std::endl;
}


Everything compiles nicely, output from program suggests that
everything works:
<output>
$ ./waf --run scratch/myfirst
Entering directory `/wrk/ns3/ns-3.2/build'

[469/513] cxx: scratch/myfirst.cc -> build/debug/scratch/myfirst_4.o

[511/513] cxx_link: build/debug/scratch/myfirst_4.o -> build/debug/
scratch/myfirst
Compilation finished successfully
index: 1
lo: 0
lo addr : 127.0.0.1
lo: 1
lo addr : 1.2.3.4
index: 1
lo: 0
lo addr : 127.0.0.1
lo: 1
lo addr : 1.2.3.4
index: 1
lo: 0
lo addr : 127.0.0.1
lo: 1
lo addr : 1.2.3.4
Sent 1024 bytes to 1.0.1.69
</output>
however routing doesn't work. I'm no longer able to send data between
source and destination.
Everything works without adding extra loopback:
lo: 0
lo addr : 127.0.0.1
lo: 0
lo addr : 127.0.0.1
lo: 0
lo addr : 127.0.0.1
Sent 1024 bytes to 1.0.1.69
Received 1024 bytes from 1.0.1.73
Received 1024 bytes from 1.0.1.69

Function AddIpv4Stack2() looks than like this:
static void
AddIpv4Stack2(Ptr<Node> node)
{
Ptr<Ipv4L3Protocol> ipv4 = CreateObject<Ipv4L3Protocol> ();
ipv4->SetNode (node);
ipv4->SetupLoopback();

//Ipv4Address myloopback("1.2.3.4");
//uint32_t index = ipv4->SetupLoopback(myloopback);
//std::cout << "index: " << index << std::endl;

node->AggregateObject (ipv4);
Ptr<Ipv4Impl> ipv4Impl = CreateObject<Ipv4Impl> ();
ipv4Impl->SetIpv4 (ipv4);
node->AggregateObject (ipv4Impl);

Ipv4Address ip("127.0.0.1");
std::cout << "lo: " << ipv4->FindInterfaceForAddr (ip) << std::endl;
Ptr<Ipv4Interface> ipv4intf = ipv4->GetInterface (ipv4-
>FindInterfaceForAddr(ip));
Ipv4Address addr = ipv4intf->GetAddress();
std::cout << "lo addr : " << addr << std::endl;

//Ipv4Address ip2("1.2.3.4");
//std::cout << "lo: " << ipv4->FindInterfaceForAddr (ip2) <<
std::endl;
//ipv4intf = ipv4->GetInterface (ipv4->FindInterfaceForAddr(ip2));
//addr = ipv4intf->GetAddress();
//std::cout << "lo addr : " << addr << std::endl;
}

My personal observation is that the same type of symptom (lack of
routing) is same for three different (separate) type of
configurations:
1. Adding an extra loopback (as described above)
2. Adding second IP address to the same interface (this is unsupported
as you pointed out Mathieu)
3. Adding a sort of pseudo-interface (additional csma or p2p) to act
as loopback and addressing it with /32 (as I described in my initial
email).

All three scenarios are failing in the same way - routing is broken.

Is there anything else I can try?

Many Thanks,

--
Norman (Norbert) Baz

[Tom Henderson]

Norman,

In response to above, no, presently there is not clean support for that.
See this bug:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=188

We are reworking the Ipv4Interface class to allow it to hold multiple
IPv4 addresses (one primary and multiple secondary), as in Linux, but
that support will not be merged until after ns-3.3 is released. The
code that implements this IP aliasing is presently in the private branch
http://code.nsnam.org/tomh/ns-3-ip

Regarding your other question:

> My personal observation is that the same type of symptom (lack of
> routing) is same for three different (separate) type of
> configurations:
> 1. Adding an extra loopback (as described above)
> 2. Adding second IP address to the same interface (this is unsupported
> as you pointed out Mathieu)
> 3. Adding a sort of pseudo-interface (additional csma or p2p) to act
> as loopback and addressing it with /32 (as I described in my initial
> email).
>
> All three scenarios are failing in the same way - routing is broken.
>

I believe that this in general is related to the lack of support for
stub networks, as has been recently called out in the end of bug 406:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=406

I believe that, after bug 406 is fixed, you should be able to create a
new virtual device (a second loopback) and put an address on it and use
that as a router ID; I'll write a test case for that scenario.

I am going to prioritize fixing the above this week and will get back to
you when I make progress.

- Tom

[Norman]

> I believe that this in general is related to the lack of support for
> stub networks, as has been recently called out in the end of bug 406:http://www.nsnam.org/bugzilla/show_bug.cgi?id=406
>
> I believe that, after bug 406 is fixed, you should be able to create a
> new virtual device (a second loopback) and put an address on it and use
> that as a router ID; I'll write a test case for that scenario.
>
> I am going to prioritize fixing the above this week and will get back to
> you when I make progress.

Hi Tom,

Thanks for your replay. Now I understand that problem is caused by a
stub networks.
I would be great if you could somehow manage to fix it!
I appreciate prioritizing this issue, that's fantastic!

One more question, by problem with "stab networks" do you mean a
general routing issue
or just a problem with global route manager? Bug seems to be related
only to global route manager,
so my understanding is that if I will use a static route API (I didn't
try this before) routing should work?

Once again many thanks for you, Mathieu and Gustavo help.

Best Regards,

--
Norman

[Tom Henderson]

The global route manager is a port of the Dijkstra algorithm from
quagga's OSPFv2 implementation. OSPF shortest path computation is a
two-stage process; in the first stage, routes to shared and transit
links are computed, and in the second stage, routes to stub networks and
interfaces are computed. We only implemented the first stage initially,
since it was sufficient to cover initial use cases in which every link
was part of the routing topology.

Yes, you can directly set routes using the static routing API available
in class ns3::Ipv4.

- Tom

[Norman]

Hi Tom,

One more observation.

I tried over the week static route API. Static routes basically works
fine,
but again not with 32bit addresses. As I understand this is a
separate
issue which has nothing to do with stub networks (since Global Route
Manager/SPF computation is not applied).

I have a very basic setup, in which 3 routers A, B and C are connected
via p2p interfaces.
(a.a.a.a/32)A<--x.x.x.0/30-->B<--y.y.y.0/30-->C(c.c.c.c/32)
router A and C have additionally (beside p2p interface toward B) 32bit
address assigned
on additional interface. It is csma interface (not connected to
anything), but is marked as up.
For some reasons static routes doesn't work in this scenario (I'm
using a modified
version of first.cc program to send a couple of UDP packets).

I'm actually not sure if it is problem of static routes or something
else. It looks like everything
i.e. the whole routing is getting broken once I assign /32 address on
interface
(before even adding static routes). If I will hash out call to
function responsible for assigning
those /32 addresses, I'm able to send/receive packets on x.x.x.x/30
and y.y.y.y/30 networks
- in order to do that (of course) also I need to modify
UdpEchoClientHelper echoClient ("c.c.c.c", 9);
to something like this:
UdpEchoClientHelper echoClient ("y.y.y.2", 9);

Conclusion from all of this /32 bit discussion is that (as I believe) /
32 bit address problem
is not only related to global route manager. /32 addresses do not work
at all and their mere presence
seem to broke also regular routing between non-/32 addresses.

Hope this help to diagnose the issue.

Thanks,

--
Norman

[Tom Henderson]

Norman,

Could you please have a look at the test programs in this bug report:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=432

I tried to reproduce the above topology, and I found that I could get
static routing to work correctly, and global routing to work with a
small patch to ns-3-dev. These programs take advantage of the patches
to recent bugs (400, 406) that were checked into ns-3-dev in the past
day or so.

Do you think that the /32 issue is fixed for you now?

Tom

[Norman]

> Norman,
>
> Could you please have a look at the test programs in this bug report:http://www.nsnam.org/bugzilla/show_bug.cgi?id=432
>
> I tried to reproduce the above topology, and I found that I could get
> static routing to work correctly, and global routing to work with a
> small patch to ns-3-dev. These programs take advantage of the patches
> to recent bugs (400, 406) that were checked into ns-3-dev in the past
> day or so.
>
> Do you think that the /32 issue is fixed for you now?
>
> Tom

Hi Tom,
Sorry for not replaying, I somehow missed your email.
My tested were based on version 3.2, currently I'm using development
branch
and will test it over a week. In case of spotting any problems I will
let you know.
Once again sorry for late replay.

Thanks,

--
Norman

[Tom Henderson]

Norman,
I put the example programs into ns-3-dev recently, and they should be in
the ns-3.3 release, so you can test that when it is published.

Tom

[Norman]

Hi Tom,
I've tested /32 addresses on ns-3.3-RC2
Static routing seems to work fine (thanks for that!).
However, global route manager is still broken, displays following
message:

GlobalRouter::GetAdjacent (): Channel with other than two devices
Command ['/path/to/my/ns-3.3-RC2/build/debug/scratch/test'] exited
with code -11

As I understand this is expected behavior due to stub networks.

--
Norman

[Tom Henderson]

I think the problem may be due to declaring these devices as
point-to-point rather than csma. The example script
examples/global-routing-slash32.cc works fine with ns-3.3, but when I
change the stub interfaces from csma to point-to-point device types, I
get the failure you note above.

Can you retry, for now, declaring those stubs as CsmaNetDevice type? I
will fix the point-to-point code shortly, which presently assumes that
exactly 2 devices will be on a point-to-point link (this assumption can
be relaxed).

Tom

[Norman]

> Can you retry, for now, declaring those stubs as CsmaNetDevice type?  I
> will fix the point-to-point code shortly, which presently assumes that
> exactly 2 devices will be on a point-to-point link (this assumption can
> be relaxed).

Hi Tom,
Sure, my tests are based on L3 so I can use any type of link.
Thanks for fixing this!

Regards,

--
Norman