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) Thanks for your feedback and time Tom Smyth
