[j-nsp] Conditional advertising of default routes
Chris Kawchuk
chrisk at distributel.ca
Fri Feb 3 20:55:02 EST 2006
> When we took a look at this issue last year, we came to conclusion to
always originate a default route from both of our Junipers
simultaneously. > This sounds exactly like Jee Kay's configuration now.
> Even if its upstream link goes down, a router can still be used as a
gateway since it will just punt to the other router via OSPF or iBGP.
We've had luck in doing just that - but with a twist. We originate a
default route in both POP Junipers; with 1 slightly higher metric than
the other, so that "downstream" Cisco devices don't do the "one packet
goes left, one packet goes right" when dealing with meshed equal-cost
OSPF downlinks from the core.
We also do a "no install" flag against the default origination, so even
though the Juniper M-series core routers are advertising a "default"
route to the rest of the downstream network via OSPF, they don't
actually install the route into the local forwarding table. This has the
nice effect of non-BGP/OSPF-only-speaking equipment "gravitating" all
their non-IGP traffic towards one of the core/transit routers, yet, in
the case of a non-routable address (i.e. an address that does not appear
in the global BGP table - such as 1.1.1.1 for example), the Juniper's
report ye olde "ICMP Network Unreachable", rather than sending the
packet up to a transit, who, after a few hops, declare the destination
network unreachable for the same reasons.
Here's our config. Apologies to those who have seen this posted in these
forums before:
routing-options {
static {
route 10.0.0.0/8 {
next-hop 10.1.1.1;
no-readvertise;
}
route 192.168.0.0/16 {
next-hop 10.1.1.1;
no-readvertise;
}
route 172.16.0.0/12 {
next-hop 10.1.1.1;
no-readvertise;
}
route 0.0.0.0/0 {
next-hop something-reachable-that-is-directly-connected;
no-install;
readvertise;
metric 1;
}
(Note what I am also doing w/RFC 1918 space - out interface fxp0 for my
own internal management reasons. Again this gives ICMP Network
Unreachable Messages, as traffic is not allowed to pass from a transit
interface to fxp0 - I suggest doing this, rather than using egress
filters/martians lists to remove RFC1918 space. (kudos to team cymru)
The other Core M-series router is the same config, but with "metric 2".
They have a local gigabit link between each of them, so, yes, one will
"punt" the traffic to the other in the case of an eBGP "better route" on
the second router.
Note that the "next hop" against the 0.0.0.0/0 entry must be something
directly reachable (and not a loopback). If you want to use a "far away
address", then you'll need the "resolve" keyword, which means the static
route will have an "actual" next-hop which is in the "general direction"
of your specific/hard-coded next hop.
Hope this helps. I realize it doesn't solve the exact problem (i.e.
create a 0.0.0.0/0 entry based on the availability of some route being
advertised by a directly-connected eBGP peer; but this method has shown
to work well in our network. Caveat Emptor.
Chris Kawchuk
Director, Data Telecommunications
Distributel Communications Ltd.
More information about the juniper-nsp
mailing list