Once you've successfully peered, it's tempting to want to start to make many micro changes as possible to try to optimise your peering. After all anything that you can do to move more traffic across your peering sessions, is a Good Thing for your network!
In practice, this is a dangerous practice to follow. Whilst BGP comes with a large amount of knobs that you can tweak, smart network operators know that it's generally only best to tweak something if, and only if, it's necessary, else you risk adding complexity to your network.
We generally recommend that peers consider setting the localpref on their peering sessions, to be higher than the localpref on their IP transit sessions, forcing your network to use your peering points for traffic if an alternate, equal-cost path exists. Blindly setting your BGP local preference to a random high number without thinking through a complete policy, is a Really Bad Idea. It's a much better idea to plan out a BGP local preference strategy for your network, and then execute according to that. Here are some ideas to help you get started below, keeping in mind the general principle that localpref works on the basis of client_localpref should be higher than peering_localpref which should be higher than transit_localpref. Substitute the numbers for ones that make sense in your network!
| Description | Role | Suggestion |
|---|---|---|
| Customer prefix | Primary prefix learnt from customer | 999 |
| Customer backup | Customer backup prefix | 950 |
| Domestic peer | Peers within a metro | 899 |
| Domestic peer backup | Backup for metro peering | 850 |
| Regional peer | Peers from a defined region | 799 |
| Regional peer backup | Backup for regional peers | 750 |
| Transit | 90 | |
| Backup Transit | 50 |
The "standard" local prefer on a Cisco and Juniper router is 100, so, do make sure that you have the localpref for your transit lower than this.
This is just a rough idea of system that could work. You're encouraged to spend time to think about where your traffic entry and exit points are, how you would like traffic to flow through your network, and how to design for efficiency, and cost savings.
The general rule of thumb is to accept that, without prior arrangement, no peer will be willing to accepts your MEDs. That said, there are some peers might be willing to entertain these. Nothing works better than simply asking your peering partner what measures they have to manage traffic control.
Peering works because the networks involved in peering appreciate that sometimes they have to carry traffic across the "long" path to their network, and sometimes, you (the remote peer) has to do this. Hot potato routing (ie. quickest exit) helps to keep the system equitable to all parties involved. Most peers will request that you make equal cost advertisements if you peer with them at multiple exchanges and we strongly advise you to do this!
