4 ms·

One thing a lot of people don't realize is that a good deal of how the internet routes traffic is simply determined by trust. Yes there are complicated legal a

by jtchang 14y ago

One thing a lot of people don't realize is that a good deal of how the internet routes traffic is simply determined by trust. Yes there are complicated legal agreements between AS's but when ti comes down to it any AS can advertise any route they want. Most edge routes are configured to simply trust routes as they come in. If they didn't we wouldn't have such a redundant infrastructure.

jlgaddis 14y ago
> when ti comes down to it any AS can advertise any route they want If the provider isn't filtering, sure. > Most edge routes are configured to simply trust routes as they come in Actually, edge routers are where your prefix filtering takes place. It's much more difficult to filter at the "core".
- windexh8er 14y ago
  Very true, but where is the core? I've setup many BGP peering sessions, and yes all of those direct edge connections into tier 1 providers is generally filtering prefixes longer than /24. These are where the big propagation problems happen. Whoops, I just advertised my internal network (including a bunch of /31 and /32s) to the Internet either clobbering route tables (capacity problem) or stomping routes. This is why my comment posted in the recent CloudFlare post mortem talks about good network engineers and the misunderstanding of many 'technical savvy' folks that know enough to do some really dumb things architecturally. This lends credence to the fact that, this is well understood if you've spun up peering sessions more than once. I find it slightly embarrassing most people don't realize how fragile a framework BGP really is. But it definitely comes to light reading through forums like HN that lean towards the developer side of readership.
  - jlgaddis 14y ago
    It's not hard to "do things right". We filter our customers advertisements to us (requiring them to register their routes in a routing registry and then manually verifying them before allowing the prefixes to be accepted) as well as filtering what we advertise upstream (and our upstream performs filtering on our advertisements as well). If you advertise /31s and /32s, well, you shouldn't be redistributing into BGP and, of course, your upstream should be filtering those prefixes and throwing them away. Problem solved. Perhaps the majority of people here on HN don't understand BGP. Then again, most of them probably don't need to.
    - noselasd 14y ago
      But how much of your transit providers or non-customer peers do you trust ?
nikcub 14y ago
It also means the internet is vulnerable to simple sysadmin errors. For eg. the only time Google went down world-wide was a BGP error: http://tech.slashdot.org/story/12/11/06/2040226/why-google-went-offline-today http://tech.slashdot.org/story/12/11/06/2040226/why-google-w... Syria being taken offline was also via BGP http://www.cert.at/services/blog/20121129184048-616.html http://www.cert.at/services/blog/20121129184048-616.html
derleth 14y ago
Remember AS7007! http://en.wikipedia.org/wiki/AS_7007_incident http://en.wikipedia.org/wiki/AS_7007_incident http://www.merit.edu/mail.archives/nanog/1997-04/msg00444.html http://www.merit.edu/mail.archives/nanog/1997-04/msg00444.ht... http://lists.ucc.gu.uwa.edu.au/pipermail/lore/2006-August/000040.html http://lists.ucc.gu.uwa.edu.au/pipermail/lore/2006-August/00...

by jtchang 14y ago

jlgaddis 14y ago

> when ti comes down to it any AS can advertise any route they want If the provider isn't filtering, sure. > Most edge routes are configured to simply trust routes as they come in Actually, edge routers are where your prefix filtering takes place. It's much more difficult to filter at the "core".

windexh8er 14y ago
Very true, but where is the core? I've setup many BGP peering sessions, and yes all of those direct edge connections into tier 1 providers is generally filtering prefixes longer than /24. These are where the big propagation problems happen. Whoops, I just advertised my internal network (including a bunch of /31 and /32s) to the Internet either clobbering route tables (capacity problem) or stomping routes. This is why my comment posted in the recent CloudFlare post mortem talks about good network engineers and the misunderstanding of many 'technical savvy' folks that know enough to do some really dumb things architecturally. This lends credence to the fact that, this is well understood if you've spun up peering sessions more than once. I find it slightly embarrassing most people don't realize how fragile a framework BGP really is. But it definitely comes to light reading through forums like HN that lean towards the developer side of readership.
- jlgaddis 14y ago
  It's not hard to "do things right". We filter our customers advertisements to us (requiring them to register their routes in a routing registry and then manually verifying them before allowing the prefixes to be accepted) as well as filtering what we advertise upstream (and our upstream performs filtering on our advertisements as well). If you advertise /31s and /32s, well, you shouldn't be redistributing into BGP and, of course, your upstream should be filtering those prefixes and throwing them away. Problem solved. Perhaps the majority of people here on HN don't understand BGP. Then again, most of them probably don't need to.
  - noselasd 14y ago
    But how much of your transit providers or non-customer peers do you trust ?

nikcub 14y ago

It also means the internet is vulnerable to simple sysadmin errors. For eg. the only time Google went down world-wide was a BGP error: http://tech.slashdot.org/story/12/11/06/2040226/why-google-went-offline-today http://tech.slashdot.org/story/12/11/06/2040226/why-google-w... Syria being taken offline was also via BGP http://www.cert.at/services/blog/20121129184048-616.html http://www.cert.at/services/blog/20121129184048-616.html

derleth 14y ago

Remember AS7007! http://en.wikipedia.org/wiki/AS_7007_incident http://en.wikipedia.org/wiki/AS_7007_incident http://www.merit.edu/mail.archives/nanog/1997-04/msg00444.html http://www.merit.edu/mail.archives/nanog/1997-04/msg00444.ht... http://lists.ucc.gu.uwa.edu.au/pipermail/lore/2006-August/000040.html http://lists.ucc.gu.uwa.edu.au/pipermail/lore/2006-August/00...