[Xorp-users] Address not adding

Pavlin Radoslavov pavlin at icir.org
Wed Aug 1 16:15:14 PDT 2007


Inlander <inlanderground at gmail.com> wrote:

> Hi, I'm a new user. I also running rip, with multicast. with 2 ethernet
> almost like yours.
> I saw that your configuration doesn't include prefix-length.
> I think you should add them to each interface.
> As long as I know. the IP 169.254.xxx.xxx is the autoconfiguration address.
> MS Windows use it when Windows doesn't find any dhcp address.
> those IP use prefix-length or subnet mask in 16 length.
> so I think probably your xorp can't be called as a router if they have same
> addresses
> on their interfaces.

Good question about the prefix-length. Independently, I also started
looking into that direction, because it wasn'c clear from Emmanuel's
email whether the 169.254.8.14 and 169.254.5.17 belong to the same
subnet address prefix (i.e., whether the prefix length is 16 or 24
bits for example).


Myself I did some tests with both addresses being the same subnet,
and I found that the RIP packets originated by XORP are not received
back (even though they are originated on two different interfaces).
The reason for that is because there is a single UDP socket (that
was bind(2) to address ZERO (or any) and port 520), and that socket
is used for all sending and receiving. The "multicast_loopback"
socket option for that socket is explicitly disabled, hence no
packets sent on that socket are received back.

Well, this behavior is technically correct because there is no point
for RIP itself to receive and process its own packets.
Though this probably not the behavior you were expecting :)

Anyway, if you REALLY want to receive the RIP packets, then just
apply the following patch that will enable the "multicast_loopback"
option:

Index: xrl_port_io.cc
===================================================================
RCS file: /usr/local/share/doc/apache/cvs/xorp/rip/xrl_port_io.cc,v
retrieving revision 1.22
diff -u -p -r1.22 xrl_port_io.cc
--- xrl_port_io.cc	16 Feb 2007 22:47:17 -0000	1.22
+++ xrl_port_io.cc	1 Aug 2007 23:01:19 -0000
@@ -112,7 +112,7 @@ XrlPortIO<IPv4>::request_no_loop()
 {
     XrlSocket4V0p1Client cl(&_xr);
     return cl.send_set_socket_option(
-		_ss.c_str(), socket_id(), "multicast_loopback", 0,
+		_ss.c_str(), socket_id(), "multicast_loopback", 1,
 		callback(this, &XrlPortIO<IPv4>::no_loop_cb));
 }
 
@@ -225,7 +225,7 @@ XrlPortIO<IPv6>::request_no_loop()
 {
     XrlSocket6V0p1Client cl(&_xr);
     return cl.send_set_socket_option(
-		_ss.c_str(), socket_id(), "multicast_loopback", 0,
+		_ss.c_str(), socket_id(), "multicast_loopback", 1,
 		callback(this, &XrlPortIO<IPv6>::no_loop_cb));
 }


However, note that this is NOT the intended RIP operation, so if you
do this all bets are OFF: there is no guarantee that the received
packets will be processed as you might expect, etc.

Instead, you might want to try running two different instances of
XORP. For that, you need to set the XORP_FINDER_SERVER_PORT
environmental variable to two different values before starting each
XORP instance. E.g., in csh/tcsh:

setenv XORP_FINDER_SERVER_PORT 22222
./xorp_rtrmgr -b config1.boot

setenv XORP_FINDER_SERVER_PORT 22223
./xorp_rtrmgr -b config2.boot

There is no guarantee this will work, because most likely both
instances might try to install the same route to the kernel so the
result will be unpredictable. To get around this you might need to
run, say, two VMWare instances one for each XORP instances, and
just interconnect them via some of the virtual vmnet* interfaces.

Other solutions that come to mind are using UML (User Mode Linux)
and/or something like VINI (http://www.vini-veritas.net/).

Again, as I mentioned in my earlier emails, if you have two PCs and
you want to avoid the extra hassle of installing and configuring
VMWare and friends, then just connect those PCs together and run RIP
on each of them.

Regards,
Pavlin


> CMIIW
> 
> Regards,
> 
> >Are you intending to configure RIP in such way so you can see the RIP
> > >packets originated by one of the IP addresses on the interface and
> > >received on the same interface (but the other IP address)?
> > >I don't think it will work this way.
> > >You should run RIP instances on two different (neighbor) machines,
> > >and even then you should enable RIP on one IP address per interface.
> >
> > I've tried running RIP on two different interface card on the same
> > machine,
> > using a different address on the cards but still no luck. Part of the
> > config
> > is below as well as the results I get.
> >
> > protocols {
> >     rip {
> >         export: "connected"
> >         interface eth0 {
> >             vif eth0 {
> >                 address 169.254.8.14 {
> >                   disable: false
> >                   metric: 1
> >                   horizon: "split-horizon-poison-reverse"
> >                   passive: false
> >                   accept-non-rip-requests: true
> >                   accept-default-route: true
> >                   /* advertise-defaut-route: true */
> >                   route-timeout: 180
> >                   deletion-delay: 120
> >                   triggered-delay: 3
> >                   triggered-jitter: 66
> >                   update-interval: 30
> >                   update-jitter: 16
> >                   request-interval: 30
> >                   interpacket-delay: 50
> >                   /*
> >                   authentication {
> >                     simple-password: "password";
> >                     md5 @: u32 {
> >                       password: "password";
> >                       start-time: "2006-01-01.12:00"
> >                       end-time: "2007-01-01.12:00"
> >                     }
> >                   }
> >                   */
> >                 }
> >             }
> >         }
> >         export: "connected"
> >
> >         interface eth2 {
> >             vif eth2 {
> >                 address 169.254.5.17 {
> >                   disable: false
> >                   metric: 1
> >                   horizon: "split-horizon-poison-reverse"
> >                   passive: false
> >                   accept-non-rip-requests: true
> >                   accept-default-route: true
> >                   route-timeout: 180
> >                   deletion-delay: 120
> >                   triggered-delay: 3
> >                   triggered-jitter: 66
> >                   update-interval: 30
> >                   update-jitter: 16
> >                   request-interval: 30
> >                   interpacket-delay: 50
> >                 }
> >             }
> >         }
> >         export: "connected"
> >     }
> > }
> >
> > root at eLinuxBox> show rip statistics all
> >
> > * RIP on eth0 eth0 169.254.8.14
> >   Status: enabled
> >
> >   Counter                                     Value
> >   -------------------------------- ----------------
> >   Requests Sent                                  33
> >   Updates Sent                                   31
> >   Triggered Updates Sent                          1
> >   Non-RIP Updates Sent                            0
> >   Total Packets Received                          0
> >   Request Packets Received                        0
> >   Update Packets Received                         0
> >   Bad Packets Received                            0
> >   Authentication Failures                         0
> >   Bad Routes Received                             0
> >   Non-RIP Requests Received                       0
> >
> > * RIP on eth2 eth2 169.254.5.17
> >   Status: enabled
> >
> >   Counter                                     Value
> >   -------------------------------- ----------------
> >   Requests Sent                                  33
> >   Updates Sent                                   32
> >   Triggered Updates Sent                          0
> >   Non-RIP Updates Sent                            0
> >   Total Packets Received                          0
> >   Request Packets Received                        0
> >   Update Packets Received                         0
> >   Bad Packets Received                            0
> >   Authentication Failures                         0
> >   Bad Routes Received                             0
> >   Non-RIP Requests Received                       0
> >
> >
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users



More information about the Xorp-users mailing list