[Xorp-users] XORP talking to a remote Click

[Pavlin Radoslavov]

> I have been trying to let a XORP instance running on my local PC talk 
> (send its forwarding table) to a Click instance on another machine. I 
> only tried to set a static route in XORP so far. A new route did show up 
> in the Click (IP lookup element named _xorp_rt4). However, it was the 
> default route of the local interface (eth0 of my local PC) in the XORP 
> interfaces configure (e.g., 128.112.95.0/24), not the static route I 
> configured (111.222.0.0/16).
> 
> A piece of additional information: when I started xorp_rtrmgr with this 
> configuration (pasted below), there was such an error message:
> [ 2006/10/27 14:21:48  ERROR xorp_fea:20687 FEA +331 
> fticonfig_entry_set_click.cc add_entry ] User-level Click command error: 
> 520-Write handler '_xorp_rt4.add' error:
> 520 conflict with existing route '128.112.95.0/24 - 0'
> 
> My guess is that XORP does not know how to reach 192.168.1.2 from eth0. 
> Any suggestions on how to get around this?

First, I should mention that the FEA-Click interaction hasn't been
designed to run them on different machines. The purpose of the
user-click control-address is to specify a different local IP
address (instead of the default 127.0.0.1).

One of the issues with running remote Click is that the FEA performs
various interface-related checks, and the FEA obtains this
information from the kernel itself (i.e., the local
machine). Obviously, this interface information doesn't apply for
the remote machine with Click.

You should try to run both the FEA and Click on the remote machine.
For that purpose you need to do few tricks in XORP. Off the top of
my head, below is one possible manual procedure for doing this.

1. Replace the fea/xorp_fea binary with an executable (it could be a
   shell script) that sleeps forever.
2. Set the XORP_FINDER_SERVER_ADDRESS environmental variable before
   starting XORP to one of the IP addresses of the machine running
   xorp_rtrmgr. E.g., in csh/tcsh

setenv XORP_FINDER_SERVER_ADDRESS 1.2.3.4

3. Start XORP like:
   ./xorp_rtrmgr -i 1.2.3.4 -a 5.6.7.8
   where 5.6.7.8 is the IP address of the machine that will be
   running the FEA.

4. As soon as you start xorp_rtrmgr, start the original xorp_fea
   binary on the remote machine (probably within 30 seconds if not less),
   but make sure you have set the XORP_FINDER_SERVER_ADDRESS
   environmental variable. E.g., 

env XORP_FINDER_SERVER_ADDRESS=1.2.3.4 fea/xorp_fea

If this doesn't work, try changing the order of (3) and (4).

Other folks on the list probably have played with similar
procedure for running remote FEA, so they might have a better
(automated?) mechanism for starting everything.

> Another more general question I have is: say a XORP instance is runnning 
> only BGP (without any IGPs), is there a way to configure this XORP 
> instance such that it passes all the best routes to a remote Click 
> without trying to resolve the immediate next-hops or outgoing interfaces?

All routes need to be resolvable before going to the FEA. If you run
both Click and FEA on the same machine, then eventually this
shouldn't be an issue.

Regards,
Pavlin

> Thanks,
> Yi
> 
> --------------
> 
> The toy XORP configue file I used:
> 
> interfaces {
>      interface eth0 {
>          disable: false
>          default-system-config
>      }
> }
> 
> fea {
>      unicast-forwarding4 {
>          disable: true
>      }
> 
>      click {
>          disable: false
> 
>          duplicate-routes-to-kernel: true
> 
>          user-click {
>              disable: false
>              command-file: "/usr/local/bin/click"
>              command-extra-arguments: "-R"
>              command-execute-on-startup: false
>              control-address: 198.32.154.235	/* the address of the 
> remote box where Click is running */
>              control-socket-port: 13750
>          }
>      }
> }
> 
> protocols {
>          static {
>                  route 111.222.0.0/16 {
>                          next-hop: 192.168.1.2
>                          metric: 1
>                  }
>          }
> }
> 
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users