An established BGP session only proves that two routers can exchange messages. It does not prove that accepted routes are safe, preferred paths are commercially sensible or failure behaviour has been tested.
1. Letting policy emerge from configuration order
When local preference, communities and filters are added one incident at a time, the network eventually contains policy that nobody can explain from first principles.
2. Treating a second transit provider as automatic resilience
Two carriers may share a duct, POP, upstream or power dependency. Routing may also continue preferring a degraded path unless the design includes suitable health signals and operational procedures.
3. Accepting more routes than the relationship requires
Customer, peer and upstream sessions need explicit prefix rules and maximum-prefix controls. Trust without verification turns another organisation’s error into your incident.
4. Deploying IPv6 as a separate project
IPv6 policy should match the intent of IPv4 across filtering, local preference, communities, monitoring and failure testing.
5. Skipping live validation
A routing design is not complete until engineers have observed intended path selection, controlled failure and recovery, and recorded the evidence needed for future troubleshooting.
What to do next
Document the intended policy before changing the configuration. Review every session against that policy, then test failure modes in a controlled window.