On 22.09.18 17:11, Tom Smyth wrote:
Hello Stuart,
Thanks for the feedback , I have responded to your feedback in line,
On Sat, 22 Sep 2018 at 10:07, Stuart Henderson <[email protected]> wrote:
Interesting idea but I think the method you're suggesting puts you at
higher risk of things *not* reaching their destination - if you have
good and not-so-good transits, the diffs are likely to be things you
don't want anyway and could interfere with correct routing.
I see your point I had not considered that failure mode.
Some providers have a bit of a problem with "stuck" routes (if there's
a stuck more-specific route at one provider, that will be a difference,
and you'll send traffic there on a road to nowhere instead of to a valid
less-specific).
I get what you are saying however this would still be a problem if I had full
views (if I understand your point correctly, any more specific network that is
invalid would still blackhole traffic in the case where we have full tables )
also with that risk in mind I (think) such a setup would be better than
defaulting to a transit provider who has sent a withdraw message on a prefix
Another issue is that a good provider may have filtered a dubious
announcement (hijack attempt), a less fastidious one might not.
If I wanted to identify *whether* a transit provider is sending such
routes, analysing a diff of the announcements between them and another
provider is quite a good way to find them.
I agree with you ... there would have to be some steady state comparison
between the two (or more) Transit providers in normal conditions...
the usual threats (hijacks etc would have to be dealt with with the usual
IRR filtersetc
My suggestion if you're trying to use the hardware in this way: only use
transit providers who can be trusted to generally provide good transit
(which rules out a few ;) and just use defaults plus maybe allow some
extra through filters to encourage certain traffic to go a certain way,
or to balance load if your ports are hot.
Yeah ... that would be the (rough) plan .. .or build workaround filters
on the less well configured transit providers,
there are other things to consider which makes it a tough(er) problem to solve
what happens when your default provider looses connectivity with (most) of
its peers then it would be better to swap the default route to the other transit
provider and install exception routes (if any)
the whole discussion here reminds me somewhat about my idea I wanted to
realize some time ago:
suppose we have an imaginary "fast" router, which does hardware
assisted forwarding, and an OpenBGP(on a different host) lets call it
RDE, where it will provide routes for this fast router, to be put into
forwarding engine.
then we would have the following advantages:
1. nice way to configure whatever we need in BGP (because we all know
that bgpd.conf is a very nice thing)
2. real packet forwarding will take place on the hardware, specifically
built for this purpose.
3. if somebody would manufacture such say "dumb" forwarding planes, they
would definitely cost less then a fully featured router.
is this a feasible idea or am I thinking completely wrong ?
