Post by Chris KawchukPost by Julian CowleyWhen 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.
I just noticed that we're using lopsided metrics for the default route as
well (see below). This config has been fine tuned by many hands over the
years. :)
Looking more closely at our configuration, I also noticed that we're not
*always* generating a default route as I remembered, but only if we're
getting at least one route from the upstream based on the next hop. This
is similar to some of the other configs I saw posted.
Post by Chris KawchukWe 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.
In the past we've found that a certain amount of sites are in fact
reachable from our upstreams but not from the routes advertised to us.
We haven't looked at this in quite a while but I seem to remember that
this "background noise" accounted for at least several hundred kb/s.
Therefore we always install the default route into the tables.
Post by Chris KawchukHere's our config. Apologies to those who have seen this posted in these
(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.
You can use "metric add" for this. We just add 1 to the computed
metric for the interface on one of the Junipers.
Post by Chris KawchukNote 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.
We're using a generate statement for that instead of a static route.
Same thing, but it means you don't need to specify something for the
destination. The next hop of the default route is the next hop of the
"primary contributing route" in Juniper speak.
Since we're posting configs, here's ours:
generate {
route 0.0.0.0/0 policy if-upstream-routes-exist;
}
policy-statement if-upstream-routes-exist {
/* Each upstream is only one of the Junipers, but we keep the
same config on both, so only one of these terms will match.
Any route from the upstream will cause the default route to
be generated, with the next hop being the next hop of the
"primary contributing route". */
term upstream1-routes {
/* The IP address of the other link to the first upstream */
from next-hop xxx.1.1.1;
then accept;
}
term upstream2-routes {
/* The IP address of the other link to the second upstream */
from next-hop xxx.2.2.2;
then accept;
}
/* At this point, if no upstream routes are available, the default
route from the peer will take over. */
term all-other-routes {
then reject;
}
}
Here is part of the OSPF export policy:
term default-route {
from {
route-filter 0.0.0.0/0 exact;
}
then {
/* The metric change is only present on one of the routers. */
metric add 1;
external {
type 1;
}
}
}
Post by Chris KawchukHope 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.
Concur. We actually tested our configuration during a maintenance
period by bringing down each upstream peer and watching the action.
No problems with it.
--
"Seemed like to me would make them a step closer to achieving that
objective and we have an obligation in order to keep the peace to
work together to achieve the objective that we're trying to achieve
through the current diplomatic process." -- George W. Bush