Hacker News new | past | comments | ask | show | jobs | submit login

This could have been as simple as the individual accidentally "missing" a single line of a large, multi-line configuration when copy/pasting it into the router's console -- after all of the config review, etc., already occurred.

I'm not sure what vendor's gear was in use in this particular case, but the configs for a BGP peering session are typically (as mentioned above) large, multi-line configurations. For example, here's the (slightly redacted) configuration for one single BGP session on one of my routers:

  neighbor 10.10.10.10 remote-as 65432
  neighbor 10.10.10.10 transport connection-mode passive
  neighbor 10.10.10.10 description TO CUST FOO BAR INC ...
  neighbor 10.10.10.10 ebgp-multihop 3
  neighbor 10.10.10.10 update-source Loopback0
  neighbor 10.10.10.10 send-community
  neighbor 10.10.10.10 soft-reconfiguration inbound
  neighbor 10.10.10.10 prefix-list ACCEPTED-PREFIXES-AS65432 in
  neighbor 10.10.10.10 prefix-list ADVERTISED-PREFIXES-AS65432 out
  neighbor 10.10.10.10 password 7 0123456789ABCDEF0123456789ABCDEF
  neighbor 10.10.10.10 maximum-prefix 200
  neighbor 10.10.10.10 default-originate
That doesn't even include the associate prefix lists (or filter lists or route-maps or ...). All it would take is fat-fingering/typo'ing one of these lines or missing one to cause some very unintended effects.

Since we don't know exactly what happened, it's easy to say "they should've done this" or "they didn't do that". In reality, however, we simply don't know what they did or didn't do. You've shown no evidence that they didn't do any of the things you mention and, in some cases, you can do all of that and still have things go wrong.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: