All, It seems that most answers and in fact the question itself assumes that all we can do here is to be reactive. In my books that is an indication that we have already failed.
I do think that any one who has more then one internet upstream ISPs (full table or even defaults out) can do performance routing in real time by evaluating quality of TCP sessions across 2 (or more). Based on that data it can intelligently shift the exit traffic on a per prefix basis. Folks like Google or Facebook are using such home grown tools for a long time (Espresso, Edge Fabric). Cisco pfr had at least originally single sided Internet edge OER. Of course with a bit of automation skills any one can build your own tool too - the only real requirement is tapped traffic such that you can passively measure the TCP quality to your user destinations. For TCP analysis for few years now I am using https://palermotec.net/ analyzer. TCP analytics it offers is simply fantastic. GUI and user interface still needs improvement - if someone is to rely on that. Just fyi ... I am also working with that team to build (Smart Edge Routing) SER controller - they already have alpha version, but hopefully in the coming months there will be more progress making it beta and eft. The assumption is of course that all interaction with routers (any vendor) is over standard protocols (BGP or static). As we all know each decent SD-WAN or Cisco iWAN has ability to monitor performance over the mesh of endpoints and choose more optimal paths. But that is slightly different as it relies on both ends ownership. Here I assume we are talking about just single sided exit routing where we have zero control over dst. All above is about exit. To do analogy inbound is also to some extent possible if you are advertising prefixes for your services out. But here the issue is much more difficult from the perspective of aggregating different services - so at most one could just average which uplinks are best for a given prefix for *most* of the users. Kind regards, R. On Sun, Mar 15, 2020 at 9:14 AM Marcel Bößendörfer <m...@marbis.net> wrote: > RIPE Atlas is also quite useful: https://atlas.ripe.net - beside NLNOG > RING. > > Am So., 15. März 2020 um 08:58 Uhr schrieb Tore Anderson <t...@fud.no>: > > > * james list > > > > > The question: once you notice issues on internet and your upstreams are > > > fine, what instrument or service or commands or web site do you use to > > try > > > to find out where is the problem and who is experiencing the problem > (ie > > a > > > tier1 carrier)? > > > > We find that being an NLNOG RING (https://ring.nlnog.net/) participant > is > > very useful in diagnosing these kind of issues. We can start pings or > > traceroutes towards towards our own network from 500+ locations all over > > the globe with a single command, for example. Furthermore, there is a > tool > > (ring-sqa) that does pretty much this continuously and alerts us if a > > partial outage is detected. > > > > Tore > > _______________________________________________ > > juniper-nsp mailing list juniper-nsp@puck.nether.net > > https://puck.nether.net/mailman/listinfo/juniper-nsp > > > > > -- > *Marcel Bößendörfer* > Geschäftsführer / CEO > > *marbis GmbH* > Griesbachstr. 10 > 76185 Karlsruhe, Germany > > Phone: +49 721 754044-11 > Fax: +49 800 100 3860 > E-Mail: m.boessendoer...@nitrado.net > Web: marbis.net / nitrado.net > > *Registered Office | Sitz der Gesellschaft:* Karlsruhe > *Register Court | Registergericht:* AG Mannheim, HRB 713868 > *Managing Directors | Geschäftsführer:* Marco Balle, Marcel Bößendörfer > > Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte > Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail > irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und > vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte > Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain > confidential and/or privileged information. If you are not the intended > recipient (or have received this e-mail in error) please notify the sender > immediately and delete this e-mail. Any unauthorized copying, disclosure or > distribution of the material in this e-mail is strictly forbidden. > _______________________________________________ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp