[Xorp-hackers] [Xorp-cvs] XORP cvs commit: xorp/etc/templates xorp/static_routes xorp/xrl/interfaces xorp/xrl/targets
Pavlin Radoslavov
pavlin at icir.org
Tue Jan 23 15:14:27 PST 2007
> > Log message:
> > Implement support for floating static routes (i.e., static routes
> > for the same prefix with different next hop and metrics).
> >
> > A floating static route (also called "qualified" by some router
> > vendors) can be added with a configuration like:
> >
> > protocols {
> > static {
> > route 10.10.0.0/16 {
> > next-hop: 1.1.1.1
> > metric: 1
> > qualified-next-hop 1.1.1.2 {
> > metric: 10
> > }
> > }
> > interface-route 10.30.30.0/24 {
> > next-hop-interface: "rl0"
> > next-hop-vif: "rl0"
> > next-hop-router: 1.2.3.4
> > metric: 1
> > qualified-next-hop-interface rl0 {
> > qualified-next-hop-vif rl0 {
> > next-hop-router: 5.6.7.8
> > metric: 10
> > }
> > }
> > }
> > }
> > }
>
> Why so complicated? It's already UI nightmare, you shouldn't make it
> worse.
I agree it looks complicated, but there are reasons for using such
solution instead of what you suggest. The comments below are
separated for the "route" and the "interface-route" cases.
> protocols {
> static {
> route 10.10.0.0/16 {
> next-hop 1.1.1.1 {
> metric: 1
> }
> next-hop 1.1.1.2 {
> metric: 10
> }
> }
The reasons I introduced the new "qualified-next-hop" statement
instead of using the above configuration are:
* Preserve backward compatibility (configuration wise) about the
existing "next-hop" and "metric" statements.
* One of the main router vendors already use same configuration
structure (and naming) for the "route" and "qualified-next-hop"
statements.
* The "next-hop" leaf node statement is mandatory. If we make it a
multi-value node, then currently we don't have a mechanism
inside the rtrmgr templates to mandate that there is at least
one "next-hop" node configured.
Personally, if we didn't have the above factors, I actually do
prefer your example. In fact this was the mechanism I considered
first, but then I had to take into account those factors and modify
it the way it is now.
Though, none of those issues is a real show-stopper:
* From time to time we change the configuration syntax, so we don't
have to guarantee that there is always backward compatibility.
* In general, we follow the configuration syntax of other vendors,
but we don't have to stick to every word.
* If we can't make the "next-hop" mandatory, then someone who
forgets to put at least one "next-hop" entry simply won't have
the route installed and there won't be an error message pointing
to the error.
I don't have objections of changing the front-end interface the way
you suggest it, but only if people understand the trade-offs and
agree to accept the drawbacks.
> interface-route 10.30.30.0/24 {
> next-hop 1.2.3.4 {
> next-hop-interface: "rl0"
> next-hop-vif: "rl0"
> metric: 1
> }
> next-hop 5.6.7.8 {
> next-hop-interface: "rl0"
> next-hop-vif: "rl0"
> metric: 1
> }
> }
I should note that for interface-specific routes the next-hop IP
address is optional, hence it can't be used to differentiate the
routes. However, if we are to change the "route" syntax, the
"interface-route" syntax can be like:
interface-route 10.30.30.0/24 {
next-hop-interface rl0 {
next-hop-vif rl0 {
next-hop-router: 1.2.3.4
metric: 1
}
}
next-hop-interface rl1 {
next-hop-vif rl1 {
next-hop-router: 5.6.7.8
metric: 10
}
}
}
Alternative solution would be to use some (user-specified) text to
differentiate each interface-specific route. E.g.
interface-route 10.30.30.0/24 {
next-hop PRIMARY-ISP-A {
next-hop-interface: "rl0"
next-hop-vif: "rl0"
next-hop-router: 1.2.3.4
metric: 1
}
next-hop BACKUP-ISP-B {
next-hop-interface: "rl1"
next-hop-vif: "rl1"
/* next-hop-router: 5.6.7.8 */
metric: 10
}
}
> }
> }
>
> Note, that I actually don't understand why there is separate interface
> route node at all. It should be same route note just handled in the
> backend - if there is interface specified, it's interface route, if there
> isn't interface specified, it isn't interface route.
>
> protocols {
> static {
> route 10.10.0.0/16 {
> next-hop 1.1.1.1 {
> metric: 1
> }
> next-hop 1.1.1.2 {
> interface "rl0" {
> vif: "rl0"
> }
> metric: 10
> }
> }
> }
> }
Syntax like above is nice, but as I mentioned earlier, for
interface-specific routes we cannot use the optional IP address as
the multi-value key.
If people really want the simplicity of the
above syntax, this can be achieved by the introduction of the
user-specific text like in the interface-route example. E.g.:
interface-route 10.30.30.0/24 {
next-hop PRIMARY-ISP-A {
/* next-hop-interface: "rl0" */
/* next-hop-vif: "rl0" */
next-hop-router: 1.2.3.4
metric: 1
}
next-hop BACKUP-ISP-B {
next-hop-interface: "rl1"
next-hop-vif: "rl1"
/* next-hop-router: 5.6.7.8 */
metric: 10
}
}
The drawback of the above solution is that currently there is no
mechanism to specify in the rtrmgr templates that the next-hop
information must contain either next-hop-router or
next-hop-interface/next-hop-vif (or both). Hence, if an user doesn't
specify any of the next-hop-* information, then the xorpsh cannot
catch the configuration error and we need to rely on the backend
(static_routes) code to catch it. Again, this is not a show-stopper
but can be annoying because typically we try to catch such errors as
early as possible.
Finally, I should mention that the backend should support any of the
above frontend changes with no (or very few) modifications.
Regards,
Pavlin
>
>
> with my best wishes,
>
> --
> Hasso Tepper
>
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
More information about the Xorp-hackers
mailing list