Oliver Boehmer (oboehmer) wrote:
On each border router we also have a static default route pointed to
the physical interface of the upstream peers (which if memory serves
me correctly that's a bad idea because it causes an ARP to be sent for
every flow that requires that specific route).

right, if this is not a p2p interface. So a very bad idea..

So if I have a static default I should aim it at the other side's
interface IP, correct?  I don't believe I need the static overall but it
would be good to know anyway.

and core for any routes that aren't in the borders' RIB.  This would
mainly be BOGONs and other non-routable space that we use internally
(so it
may not be a real problem).

and, in addition, such packets should not show up on your borders unless
you have downstream peers/customers on the borders as well and they
point a default towards you.

Right, so I'm not sure if I really need it at all.  I've begun
distributing BOGONs around the network with my RTBH, at least but the
martians that the IOS freaks out over.  I would hope that I can block
most of it on the edges but of course I can't guarantee that at this
time.  So this may not be a big issue anyway.

In theory I shouldn't ever have to rely
on a default route to my upstreams thanks to my full tables.  I'm also
concerned with how this may affect my uRPF and RTBH setup.  Would this
catchall route nullify the effect of a iBGP-learned null-route from my
RTBH setup?

Well, if your current static default doesn't affect your uRPF and RTBH
setup, why would a dynamic default do?

Um, good point.  That one escaped me.  So if I'm thinking about this
correctly, uRPF won't be harmed by the existence of a static default or
a dynamic default.

IS-IS doesn't have something like OSPF's "distribute-list in" to filter
routes from being entered into the RIB, but you can use the "distance"
command to achieve something similar:

A distribute-list would be a handy solution.

access-list 10 permit 0.0.0.0
router isis <foo>
 distance 255 0.0.0.0 255.255.255.255 10

this will assign distance 255 to the default-route (originated by
whatever neighbor), and 255 will suppress installation into the RIB.

I never thought of use distance in that manner.  That just might work!

Or you originate a default in iBGP and run your access nodes with a
limited BGP table only.

I had been thinking about this, trying to decide pros and cons. My access edges are each in their own route-reflector cluster with the 2 cores and the RTBH trigger server. Convergence and recovery speed might be an issue I suppose. I'll have to kick that around some more.

Thanks for the info.  Have a great holiday
 Justin
_______________________________________________
cisco-nsp mailing list  [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Reply via email to