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 ()-

  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);
    }
  }

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,

Hope it helps.

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 ();

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

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

Thanks,

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,

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

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);

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-

  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;

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-

  //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;

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

Is there anything else I can try?

Many Thanks,

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.

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,

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

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,

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?

Thanks,

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.

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).

Regards,