[j-nsp] Conditional advertising of default routes

[Julian Cowley]

> > 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.

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.

> 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.

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.

> Here's our config. Apologies to those who have seen this posted in these
> forums before:
>
>
> (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.

> 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.

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;
 	    }
 	}
     }

> 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.

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