[Xorp-users] xorp with click and RIP
Robert Joseph Suk
rsuk at ucsc.edu
Tue Dec 11 15:00:44 PST 2007
I upgraded to the CVS versions of both xorp(1.52) and
click(1.6.0) and it solved the problem of using the click
forwarding path. My hardware is set up as follows:
PC2--PC3--PC4
PC2: xl0: 10.0.1.22, xl1: 10.0.2.22
PC3: xl0: 10.0.2.33, xl1: 10.0.3.33
PC4: xl0: 10.0.3.44, xl1: 10.0.4.44
The click forwarding path works fine, and RIP runs just
fine in userspace, but XORP routes are not being added to
click.
Below is my xorp config:
PC3# cat xorpclick_pc3.boot
interfaces{
restore-original-config-on-shutdown: false
interface xl0 {
description: "from 10.0.2"
disable: false
vif xl0 {
disable: false
address 10.0.2.33 {
prefix-length: 24
broadcast: 10.0.2.255
disable: false
}
}
}
interface xl1 {
description: "to 10.0.3"
disable: false
vif xl1 {
disable: false
address 10.0.3.33 {
prefix-length: 24
broadcast: 10.0.3.255
disable: false
}
}
}
} /* </interfaces> */
fea{
unicast-forwarding4 {
disable: false
}
unicast-forwarding6 {
disable: true
}
click {
disable: false
duplicate-routes-to-kernel: true
kernel-click{
disable: true
}
user-click{
disable: false
command-file:
"/usr/local/bin/click"
command-extra-arguments: "-R"
command-execute-on-startup: true
startup-config-file:
"/usr/local/xorp/iprouter_auto.click"
user-click-config-generator-file:
"/usr/local/fea/xorp_fea_click_config_generator"
}
}
} /* </fea> */
policy {
/*Describe connected routes for redistribution*/
policy-statement connected {
term export {
from {
protocol: "connected"
}
}
}
}
protocols {
static{
route 224.0.0.0/4{
next-hop: 10.0.2.22
metric: 1
}
}
rip {
export: "connected"
/*run on both interfaces*/
interface xl0 {
vif xl0 {
address 10.0.2.33 {
disable: false
}
}
}
interface xl1 {
vif xl1 {
address 10.0.3.33 {
disable: false
}
}
}
} /* </rip> */
} /* </protocols>*/
And here is my click_config_generator:
*note, this is the same click config as
iprouter_auto.click in my xorp config.
PC3# cat xorp_fea_click_config_generator
printf("
// Generated by make-ip-conf.pl
// xl0 10.0.2.33 00:01:02:42:20:EC
// xl1 10.0.3.33 00:01:02:3E:4E:3A
// Shared IP input path and routing table
ip :: Strip(14)
-> good_header :: CheckIPHeader(INTERFACES
10.0.2.33/255.255.255.0 10.0.3.33/255.255.255.0)
good_header[0] -> _xorp_rt4 :: LinearIPLookup(
10.0.2.33/32 2,
10.0.2.255/32 2,
10.0.2.0/32 2,
10.0.3.33/32 2,
10.0.3.255/32 2,
10.0.3.0/32 2, //above are local interfaces.
deliver locally
10.0.2.0/255.255.255.0 0, //xl0
10.0.3.0/255.255.255.0 1, //xl1
255.255.255.255/32 0.0.0.0 2, //broadcasts are
local and get dropped
0.0.0.0/32 2,
0.0.0.0/0.0.0.0 10.0.2.22 0);
// ARP responses are copied to each ARPQuerier and the
host.
arpt :: Tee(3);
// Input and output paths for xl0
c0 :: Classifier(12/0806 20/0001, 12/0806 20/0002,
12/0800, -);
FromDevice(xl0) -> c0;
out0 :: Queue(200) -> todevice0 :: ToDevice(xl0);
c0[0] -> ar0 :: ARPResponder(10.0.2.33 00:01:02:42:20:EC)
-> out0;
arpq0 :: ARPQuerier(10.0.2.33, 00:01:02:42:20:EC) ->
newOUT::Tee(2);
newOUT[0]->out0;
c0[1] -> arpt;
arpt[0] -> [1]arpq0;
c0[2] -> Paint(1) -> ip;
c0[3] -> Print("xl0 non-IP") -> Discard;
// Input and output paths for xl1
c1 :: Classifier(12/0806 20/0001, 12/0806 20/0002,
12/0800, -);
FromDevice(xl1) -> c1;
out1 :: Queue(200) -> todevice1 :: ToDevice(xl1);
c1[0] -> ar1 :: ARPResponder(10.0.3.33 00:01:02:3E:4E:3A)
-> out1;
arpq1 :: ARPQuerier(10.0.3.33, 00:01:02:3E:4E:3A) -> out1;
newOUT[1]->out1;
c1[1] -> arpt;
arpt[1] -> [1]arpq1;
c1[2] -> Paint(2) -> ip;
c1[3] -> Print("xl1 non-IP") -> Discard;
// Local delivery
toh :: Print(toh) -> Discard;
arpt[2] -> toh;
_xorp_rt4[2] -> IPReassembler -> ping_ipc ::
IPClassifier(icmp type echo, -);
ping_ipc[0] -> ICMPPingResponder -> [0]_xorp_rt4;
ping_ipc[1] -> EtherEncap(0x0800, 1:1:1:1:1:1,
2:2:2:2:2:2) -> toh;
// Forwarding path for xl0
_xorp_rt4[0] -> DropBroadcasts
-> cp0 :: PaintTee(1)
-> gio0 :: IPGWOptions(10.0.2.33)
-> FixIPSrc(10.0.2.33)
-> dt0 :: DecIPTTL
-> fr0 :: IPFragmenter(1500)
-> [0]arpq0;
dt0[1] -> ICMPError(10.0.2.33, timeexceeded) -> _xorp_rt4;
fr0[1] -> ICMPError(10.0.2.33, unreachable, needfrag) ->
_xorp_rt4;
gio0[1] -> ICMPError(10.0.2.33, parameterproblem) ->
_xorp_rt4;
cp0[1] -> ICMPError(10.0.2.33, redirect, host) ->
_xorp_rt4;
// Forwarding path for xl1
_xorp_rt4[1] -> DropBroadcasts
-> cp1 :: PaintTee(2)
-> gio1 :: IPGWOptions(10.0.3.33)
-> FixIPSrc(10.0.3.33)
-> dt1 :: DecIPTTL
-> fr1 :: IPFragmenter(1500)
-> [0]arpq1;
dt1[1] -> ICMPError(10.0.3.33, timeexceeded) -> _xorp_rt4;
fr1[1] -> ICMPError(10.0.3.33, unreachable, needfrag) ->
_xorp_rt4;
gio1[1] -> ICMPError(10.0.3.33, parameterproblem) ->
_xorp_rt4;
cp1[1] -> ICMPError(10.0.3.33, redirect, host) ->
_xorp_rt4;
");
On Thu, 06 Dec 2007 18:01:55 -0800
Pavlin Radoslavov <pavlin at icir.org> wrote:
> Robert Joseph Suk <rsuk at ucsc.edu> wrote:
>
>> Thanks for your reply, Pavlin.
>> I'm not exactly sure the best way to get the
>> xorp_fea_click_config_generator to unconditionally
>>return
>> my static config, but I replaced the config_generator
>> script with my config file, inside a printf("") and it
>> seems to work. I also made sure to rename my
>> LinearIPlookup from "rt" to "_xorp_rt4" so xorp could
>> handle it. The router still receives updates from
>
> Yes, this hack should do it.
>
>> neighboring routers and updates the RIB, but now xorp
>> throws an error:
>>
>> [ 2007/12/06 17:28:07 ERROR xorp_fea:1612 FEA +71
>> fti_transaction.cc operation_result ] FTI transaction
>> commit failed on AddE
>> ntry4: net = 10.0.0.0/24 nexthop = 10.0.2.22 ifname =
>>xl0
>> vifname = xl0 metric = 2 admin_distance = 120 xorp_route
>>=
>> true is_d
>> eleted = false is_unresolved = false is_connected_route
>>=
>> false
>> [ 2007/12/06 17:28:07 ERROR xorp_fea:1612 FEA +301
>> fticonfig_entry_set_click.cc add_entry ] Cannot find
>> outgoing port number
>> for the Click forwarding table element to add entry net
>>=
>> 10.0.1.0/24 nexthop = 10.0.2.22 ifname = xl0 vifname =
>>xl0
>> metric =
>> 1 admin_distance = 120 xorp_route = true is_deleted =
>> false is_unresolved = false is_connected_route = false
>
> There seems to be some error with adding the routes to
>Click.
> Could you update to the latest XORP from CVS.
> The update might not fix the problem, but will make it
>easier to
> debug it:
>
> http://www.xorp.org/cvs.html
>
> Please send me your latest XORP configuration as well as
>your
> hacked xorp_fea_click_config_generator.
> Also, please tell me the Click version you are using.
>
> Thanks,
> Pavlin
>
>>
>> and click still won't function.
>> When I run "click myconfig.click", pings across the
>>router
>> work fine, while pinging the router directly generates
>> Duplicate replies (one from the kernel, and one from
>> click).
>> As a debug, in my click config I added a Tee to the
>>output
>> of xl0 and copied all click-generated responses out to
>>The
>> other interface, xl1. Now when I ping the router, I can
>> see the extra traffic on a TCPdump of xl1. When I run
>> xorp with my config and ping the router, I only get one
>> response, and nothing on xl1, leading me to believe that
>> either my click config isn't running, or it just isnt
>> getting any traffic.
>>
>>
>> On Thu, 06 Dec 2007 12:39:47 -0800
>> Pavlin Radoslavov <pavlin at icir.org> wrote:
>> >> I'm trying to set up a xorp/click configuration
>>which
>> >> runs RIP. I have RIP working with xorp, but when I
>> >>enable
>> >> the user click forwarding path, I get strange
>>behavior.
>> >>If
>> >> I 'duplicate-routes-to-kernel' everything works fine.
>> >> However, when I don't duplicate routes-to-kernel, the
>> >> routes still show up in xorpsh (show route table ipv4
>> >> unicast rip/final), but if I ping any of those
>> >>addresses,
>> >> I get 'no route to host'. Xorp also cannot send RIP
>> >> updates, getting the send_from_multicast_if failed.
>> >
>> >First the (hopefully) easy part:
>> > As you know already, FreeBSD requires to have a
>>matching
>> >route
>> > (e.g., 0.0.0.0/0) in the unicast forwarding table in
>>the
>> >kernel to
>> > be able to originate multicast packets. If you use
>>XORP
>> >to configure
>> > the 0.0.0.0/0 static route, and if
>> >"duplicate-routes-to-kernel" is
>> > disabled, this route won't reach the kernel.
>> > Hence, to get around this problem you should add
>> >0.0.0.0/0 to the
>> > kernel by hand before starting XORP.
>> >
>> >> The reason I want to turn
>>'duplicate-routes-to-kernel'
>> >> off, is so that I can check that the click forwarding
>> >>path
>> >> is working.
>> >>
>> >> I already added a static route 0.0.0.0/0 to an
>>attached
>> >> interface, and put "multicast_host="YES"" in my
>>rc.conf.
>> >> I'm running BSD6.2, and my xorp config is below. The
>> >>click
>> >> config I'm running is simply the one generated by
>> >> 'make-ip-conf.pl' which is a basic IP router
>> >> Any ideas why xorp sees the routes in xorpsh but
>>can't
>> >>use
>> >> them?
>> >
>> > If you are to use your own static config with
>> >make-ip-conf.pl, it
>> > will be safer if you also modify the sample
>> > "/usr/local/fea/xorp_fea_click_config_generator"
>> >generator to
>> > unconditionally return that configuration. FYI, the
>> >config generator
>> > is automatically called by XORP whenenever something
>>in
>> >the
>> > interface configuration changes, so on startup it
>>might
>> >actually be
>> > overwriting your own static config.
>> >
>> > Once you eliminate the config generation factor, then
>> >you need to
>> > investigate whether userland Click itself is working
>>as
>> > expected. For that purpose I'd recommend to start
>> >userland Click by
>> > hand (without XORP), and then manually configure it
>>with
>> >your static
>> > config (including the routes that should be generated
>>by
>> >RIP).
>> > Then do the ping test to see whether userland Click on
>> >its own is
>> > fine.
>> > One thing to have in mind is that the ping packets
>> >originated on the
>> > router running Click might not actually be processed
>>by
>> >Click: such
>> > packets will lookup the unicast forwarding table in
>>the
>> >kernel, and
>> > therefore fail. Hence, you might want to run ping on a
>> >machine
>> > directly connected to the router running Click.
>> >
>> > Hopefully the above tests will narrow the problem.
>> >
>> > Regards,
>> > Pavlin
>> >
>> > P.S. In your config you don't need the plumbing/mfea4
>> >and mfea6
>> > sections.
>> >
>> >
>> >>
>> >> interfaces{
>> >> restore-original-config-on-shutdown: false
>> >> interface xl0 {
>> >> description: "from 10.0.2"
>> >> disable: false
>> >> vif xl0 {
>> >> disable: false
>> >> address 10.0.2.33 {
>> >> prefix-length: 24
>> >> broadcast:
>>10.0.2.255
>> >> disable: false
>> >> }
>> >> }
>> >> }
>> >> interface xl1 {
>> >> description: "to 10.0.3"
>> >> disable: false
>> >> vif xl1 {
>> >> disable: false
>> >> address 10.0.3.33 {
>> >> prefix-length: 24
>> >> broadcast:
>>10.0.3.255
>> >> disable: false
>> >> }
>> >> }
>> >> }
>> >> } /* </interfaces> */
>> >>
>> >> fea{
>> >> unicast-forwarding4 {
>> >> disable: true
>> >> }
>> >>
>> >> unicast-forwarding6 {
>> >> disable: true
>> >> }
>> >>
>> >> click {
>> >> disable: false /*run autogenerated
>> >> config from /conf/make-ip-conf.pl*/
>> >> duplicate-routes-to-kernel: true
>> >>
>> >> kernel-click{
>> >> disable: true
>> >> }
>> >>
>> >> user-click{
>> >> disable: false
>> >> command-file:
>> >> "/usr/local/bin/click"
>> >> command-extra-arguments:
>>"-R"
>> >> command-execute-on-startup:
>> >>true
>> >> startup-config-file:
>> >> "/usr/local/xorp/iprouter_auto.click"
>> >>
>> user-click-config-generator-file:
>> >> "/usr/local/fea/xorp_fea_click_config_generator"
>> >> }
>> >> }
>> >> } /* </fea> */
>> >> plumbing{
>> >> mfea4 {
>> >> disable: true
>> >> }
>> >> mfea6{
>> >> disable: true
>> >> }
>> >> }
>> >> policy {
>> >> /*Describe connected routes for
>> >>redistribution*/
>> >> policy-statement connected {
>> >> term export {
>> >> from {
>> >> protocol:
>>"connected"
>> >> }
>> >> }
>> >> }
>> >> }
>> >>
>> >> protocols {
>> >> static{
>> >> route 0.0.0.0/0{
>> >> next-hop: 10.0.2.22
>> >> metric: 1
>> >> }
>> >> }
>> >> rip {
>> >> export: "connected"
>> >>
>> >> /*run on both interfaces*/
>> >> interface xl0 {
>> >> vif xl0 {
>> >> address 10.0.2.33 {
>> >> disable:
>>false
>> >> }
>> >> }
>> >> }
>> >> interface xl1 {
>> >> vif xl1 {
>> >> address 10.0.3.33 {
>> >> disable:
>>false
>> >> }
>> >> }
>> >> }
>> >> } /* </rip> */
>> >> } /* </protocols>*/
>> >>
>> >>
>> >>
>> >> -Robbie
>> >>
>> >> _______________________________________________
>> >> Xorp-users mailing list
>> >> Xorp-users at xorp.org
>> >>
>>http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
>>
>> -Robbie
>>
>> _______________________________________________
>> Xorp-users mailing list
>> Xorp-users at xorp.org
>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
-Robbie
More information about the Xorp-users
mailing list