[Xorp-users] Question on supporting multiple routing tables.

[Ben Greear]

Pavlin Radoslavov wrote:
>> This sounds like a good first step, and it sounds like it meets my 
>> immediate needs.  Instead
>>     
>
> OK, I just committed to CVS the changes for configuring the table
> ID. You can do it with configuration like:
>
>       fea {
>           unicast-forwarding4 {
>               table-id: 20
>           }
>           unicast-forwarding6 {
>               table-id: 20
>           }
>       }
>
> Obviously, you won't need the unicast-forwarding6 section if you
> don't need IPv6.
>
> I just did some simple testing and it appears to work.
> Please get the latest code from anon. CVS and let us know whether it
> works for you:
>
> http://www.xorp.org/cvs.html
>   
Thank you!  This was a bit faster than I had hoped, so it may take a day 
or two before
we can try it out!  I'm going to have to read up on how to configure 
Xorp, as I haven't
configured an OSPF router or set of routers before.

In case you have time & inclination, do you have two simple config files 
to make this route with OSPF:

VR1:  table 100, eth0, eth1
VR2:  table 101, eth2, eth3

Assume eth1 and eth2 are connected to each other via cross-over cable 
and some separate PCs
are connected to eth0 and eth3.

In order to make the messages go over the external interfaces, the Xorp 
code will probably
need an option to bind to the local IP and device.  For TCP sockets that
can do this, my code looks like this (I don't know if this applies to 
IPv6 or not..I've only
tried with IPv4.)

int createTcpSocket(unsigned int ip_addr, int ip_port, const char* 
dev_to_bind_to) {
 
   int s = socket(AF_INET, SOCK_STREAM, 0);  

   if (s < 0) {
      cerr << "ERROR: tcp socket:  " << LFSTRERROR << endl;
           return s;
   }

   close_exec(s);

   reuseaddr_socket(s);

   if (dev_to_bind_to) {
      // Bind to specific device.
#ifndef __WIN32__
      if (setsockopt(s, SOL_SOCKET, SO_BINDTODEVICE,
                     dev_to_bind_to, DEV_NAME_LEN + 1)) {
         VLOG_ERR(VLOG << "ERROR:  tcp-connect, setsockopt 
(BINDTODEVICE):  "
                  << LFSTRERROR << "  Not fatal in most 
cases..continuing...\n");
      }
#endif
   }//if

   struct sockaddr_in my_ip_addr;
   memset(&my_ip_addr, 0, sizeof(my_ip_addr));
  
   my_ip_addr.sin_family = AF_INET;
   my_ip_addr.sin_addr.s_addr = htonl(ip_addr);
   my_ip_addr.sin_port = htons(ip_port);
  
   int r; //retval
   r = bind(s, (struct sockaddr*)(&my_ip_addr), sizeof(my_ip_addr));
   if (r < 0) {
      //system("netstat -an");
      cerr << "ERROR: tcp bind:  " << LFSTRERROR << endl;
      closesocket(s);
      return r;
   }
   else {
      VLOG_INF(VLOG << "Successfully bound to IP: " << 
toStringIP(ip_addr) << " port: "
               << ip_port << endl);
   }

   nonblock(s, "create tcp socket");
   return s;
}



>> of an environment variable, I'd prefer a cmd-line variable and/or 
>> something in
>> the xorp router config file.  However, I know almost nothing about how Xorp
>> is written, so if it needs to be an environ variable, that is OK.
>>     
>
> Eventually, in the future we should add support for configuring the
> Finder's address and port inside the XORP confuguration file, but
> such change probably won't be trivial.
>
> BTW, if you set the environmental variable before starting the XORP
> rtrmgr, you need to set that variable as well before starting the
> corresponding xorpsh CLI.
>   
So, the environ variable is still needed, in addition to the 
unicast-forwarding { } sections above?
>> I do not need this to support multicast at the moment.
>>
>> Eventually, I'd like to scale to 100s of VRs, so it would probably be 
>> more efficient to run a
>> smaller number of Xorp processes, each able to handle a lot of routing 
>> tables, but
>> that can be dealt with later.  And, it may turn out that running 100+ 
>> processes
>> is not such a big deal considering all of the cores on newer systems...
>>     
>
> Probably you will be the first one to try 100s of XORP instances, so
> we would be very interested to know how it goes.
>
> BTW, in Linux you cannot have more than 255 or so forwarding tables,
> and some of those tables shouldn't be touched, so ~250 is the
> max. number of table IDs and XORP instances you can try.
>   
I worked with someone to get this fixed recently, and have tested 2000+ 
tables,
so this limit no longer exists since kernel 2.6.20 or so.  You need the 
latest 'ip'
tool as well...

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com> 
Candela Technologies Inc  http://www.candelatech.com