[Xorp-users] "Reloading" config

Ben Greear greearb at candelatech.com
Mon Aug 16 09:37:39 PDT 2010


On 08/16/2010 09:29 AM, Jeff Mitchell wrote:
> I should have made it clear I'm on xorp.ct, fairly recent git. Comments
> inline:
>
> On 08/16/2010 11:21 AM, Ben Greear wrote:

>> One thing we noticed is that we needed to commit after un-loading old
>> stuff,
>> and again after loading the new stuff. Xorp.ct makes commit much faster,
>> but it's still around 1 second for big changes on moderate machines.
>>
>> Some of those limitations may be removed in xorp.ct, but I haven't
>> tried removing my intermediate 'commit' logic from my scripts.
>
> The xorp config file I need to use is getting generated
> dynamically...it'd be quite difficult to unload old stuff and then load
> the new stuff in. I think. Or is it?

Yeah, it's not trivial..but you are going to have to do a 'diff' somehow,
which means delete the un-needed stuff and add new.

In my case, if I am going to change IP on an interface, I might
just remove the interface completely (from the protocol sections)
and then re-add it.

Actually, xorpsh will do a 'diff' for you, but again, at least when
I started, it was flaky unless I committed after deleting and before
re-adding.  Especially if you have time to debug and help fix things,
you might try using xorpsh to do all the 'diff' logic and not worry
about any extra commits..and just help fix bugs that might pop up.

> Any advice on the topic appreciated. Ideally, I'd be able to change
> configs over with minimal interruption to routing protocols and no
> packet loss for static routes. I am using the system routes within xorp,
> but if it does something like turns off IPv4 forwarding when one config
> is removed/committed and then only turns it back on when the next config
> is loaded/committed then that might be an issue.

I don't think it would be that bad..but you'd want to do lots of
testing to make sure it does what you want.  Each protocol handles
changes slightly different.  We've dealt primarily with OSPF and
multicast for dynamic changes..and those work pretty well in xorp.ct,
but other protocols may be a bit more touchy still.

I guess my suggestion would be to try to use xorpsh in the easiest manner
possible, and see how that works.  If you find bugs, maybe we can just
fix them, and if not, you can start adding more commits and such to xorpsh
to work around them.

Thanks,
Ben

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



More information about the Xorp-users mailing list