[Xorp-hackers] Recursive next-hop lookup..

[Steffen Schumacher]

On 28.08.2007 18:06:48 -0700, Pavlin Radoslavov wrote:
> Steffen Schumacher <steffen at schumacher.dk> wrote:
> 
> > Hi!
> > 
> > I read the status page, so that the feature in subject still isnt
> > implemented. (http://www.xorp.org/status.html)
> > 
> > Or is it simply not working? Does anyone know if it will be working
> > by 1.5?
> > 
> > Currently I've used quagga, but it seems that it also doesn't support
> > it. I'd really like it, because my ISP will only announce a default
> > candidate via bgp, vs. a default. The idea is that I configure a static
> > default directed at this Default candidate, and my default will then
> > move around when my eBGP peers go up/down.
> 
> Could you please send an ASCII diagram with your topology and a
> little extra explanation, because we are finding it difficult to
> understand the issue you are facing.
> 
> Atanu & Pavlin
> 

I'm connected to the same ISP via two xDSL lines, and want automatic
failover when one goes down.

 PE1 (Cisco) ----xDSL (Bridged Ethernet) ---- CPE1(quagga/xorp)
                                               |GigE
 PE2 (Juniper) --xDSL (Bridged Ethernet) ---- CPE2(quagga/xorp)
 
The provider insists on providing what they call a default candidate:
a single prefix. which is used as next-hop for the default.
The lines are small, so full table is not a viable option, and its
not supported on one of the PEs.
Juniper must have a default route in their table in order to inject it,
and it doesn't which is I guess is why they use this default candidate 
scheme.

The idea is to create a default route with a next-hop within the
provider announced prefix.
The CPE should then update the next-hop info (interface, L2 address)
according to that of the provider anounced prefix. This (I guess)
requires a recursive lookup.
When the PE1 line goes down, the two CPEs will reach the default
candidate via PE2 and vice versa. The static default should then 
have the next-hop info updated, if PE1 was prefered before.

I don't know if that is descriptive enough, if not please let me know.

/Steffen

> > If there is simply a bug in the code I'd like to have a look at it.
> > But implementing the feature might be a bit much, since this is not
> > a small task.
> > 
> > Anyways - any status updates on the feature would be nice!