[Click] XORP+Click Hotconfig

Pavlin Radoslavov pavlin at icir.org
Tue Oct 3 16:27:14 EDT 2006


Swati Sinha Deb <Swati.Deb at bristol.ac.uk> wrote:

> Hi Pavlin,
> 
> Thanks for your reply. A quick check before and after applying the hotswap
> indicates that the forwarding entries have been cleared by hotswapping(as you
> guessed). Is there any way we can force XORP to re-publish the routes? Below
> is the result from read _xorp_rt4.table...

No, there is no mechanism to force XORP to re-insert the routes into
the forwarding engine.
If a third-party software (e.g., your hotswap program) is indirectly
manipulating the forwarding table, then this program should restore
the missing routes. In other words, your program should read the
forwarding table before and after the hotswap, compare both tables,
and add the missing routes.

Regards,
Pavlin

> Before Hotswap
> --------------
> read _xorp_rt4.table
> 200 Read handler '_xorp_rt4.table' OK
> DATA 148
> # Active routes
> 172.20.2.1/32           0.0.0.0         2
> 172.20.1.1/32           0.0.0.0         2
> 172.20.2.0/24           0.0.0.0         0
> 172.20.1.0/24           0.0.0.0         1
> 172.20.3.0/24           172.20.2.2      0
> 
> After Hotswap
> -------------
> read _xorp_rt4.table
> 200 Read handler '_xorp_rt4.table' OK
> DATA 68
> # Active routes
> 172.20.2.1/32           0.0.0.0         2
> 172.20.1.1/32           0.0.0.0         2
> 
> regards,
> Swati
> 
> 
> 
> --On 03 October 2006 10:14 -0700 Pavlin Radoslavov <pavlin at icir.org> wrote:
> 
> >> I am trying to implement hotswap in my xorp+click test bed. However, it
> >> is  not functioning correctly. I would appreciate if I get some help to
> >> fix  this issue. Here is what I am trying to do...
> >>
> >> Network configuration
> >> ---------------------
> >>
> >>
> >> PC 1---------ROUTER1------ROUTER2--------PC 2
> >>             eth4  eth3   eth1  eth2
> >>
> >> Where Router1 and Router2 are both running Xorp+click. The xorp config
> >> file  has the following entry...
> >>
> >> user-click {
> >> 	disable: false
> >> 	command-file: "/home/eessd/click/bin/click"
> >> 	command-extra-arguments: "-R"
> >> 	command-execute-on-startup: true
> >> 	control-address: 127.0.0.1
> >> 	control-socket-port: 13000
> >> 	startup-config-file: "/dev/null"
> >> 	user-click-config-generator-file:
> >> "/usr/localxorp/fea/xorp_fea_click_config"
> >> }
> >
> > First, a small observation: I presume that
> > "/usr/localxorp/fea/xorp_fea_click_config" is either a typo
> > (in your configuration the correct value is
> > "/usr/local/xorp/fea/xorp_fea_click_config"), or that your XORP
> > installation is indeed in the "/usr/localxorp" directory.
> >
> >> Given the above all is well and I can ping PC2 from PC1 with the above
> >> configuration.
> >>
> >> Now, I try to change the click configuration in ROUTER1. For doing this,
> >> I  have a separate application which connects to port 13000 on ROUTER1
> >> and  invokes the relevant controlsocket server commands (writedata and
> >> write on  hotconfig handler). The server returns a success i.e, 200 OK
> >> indicating  that the new config has been applied correctly. However,
> >> when I try to ping  PC2   from PC1 it starts failing.
> >
> > Note that every time any of the XORP interfaces is reconfigured
> > XORP will regenerate new Click configuration using
> > user-click-config-generator-file, and that configuration will
> > overwrite your config. Hence, make sure that if you do hotswap by
> > directly writing to port 13000, the user-click-config-generator-file
> > is updated as well to contain your new changes.
> > Though, if you don't change anything in the XORP configuration while
> > playing with the hotswap, then this shouldn't have impact on your
> > results.
> >
> >> I have compared the old and new click configuration and there is nothing
> >> which should prevent the ping from failing (I have changed a few
> >> parameters  to my custom/local click elements). Is there something
> >> fundamentally  incorrect with the above approach.
> >
> > One thing to check is the Click forwarding table. For that purpose
> > you need to talk directly to the Click forwarding element, because
> > from the XORP CLI you can print only the routing entries that are
> > stored inside XORP.
> > Off the top of my head:
> >
> > telnet localhost 13000
> > READ _xorp_rt4::table
> >
> > Do this before and after the hotswap.
> >
> > My guess is that the hotswap has cleared the forwarding entries
> > in ROUTER1, including the entry necessary to reach PC2.
> >
> > If the forwarding entries are fine, then you could try to test the
> > hotswap without XORP. For that purpose you need to do the following
> > on ROUTER1:
> >
> > 1. Start XORP and make sure the forwarding is running
> > 2. Read the Click configuration as installed by XORP and save it to
> >    a file.
> > 3. Stop XORP and start Click by hand using the above saved
> >    configuration.
> > 4. Perform the hotswap and see what happens.
> >    If the forwarding fails as before, then you need to track the
> >    problem in the Click level. If the hotswap succeeds, then the
> >    problem is somewhere in XORP.
> >
> > Regards,
> > Pavlin
> >
> >> I have also tried defining my own controlsocket (port 14000) via config
> >> file (added a statement in /usr/localxorp/fea/xorp_fea_click_config
> >> inorder  to do this). But I encounter the same issue. The server returns
> >> OK after  each hotswap attempt and the ping fails.
> >>
> >> Would be great if I get some tips on fixing the above issue. Please let
> >> me  know if I have missed out anything which would help in this
> >> investigation.
> >>
> >> Additionally after hotswap, a tcpdump on eth3 (Router1) indicates that
> >> the  ping packets are not reaching eth3, I can see it on eth4. The xorp
> >> routing  table is also fine.
> >>
> >> Thanks
> >> Swati
> >>
> >>
> >> _______________________________________________
> >> click mailing list
> >> click at amsterdam.lcs.mit.edu
> >> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
> 
> 
> 
> ----------------------
> Swati Sinha Deb, Research Fellow
> Wireless and Networks Research Laboratory,
> Electrical & Electronic Engineering, University of Bristol,
> Merchant Venturers Building, Woodland Road,
> Bristol BS8 1UB
> E-mail: Swati.Deb at bristol.ac.uk
> Tel.: +44 (0)117 331 5058


More information about the click mailing list