Adding task to document the situation as I was looking at it. Consider magru, where we peer with Google at IX.BR. We have 3 peerings configured to Google, as they have three routers on the exchange:
cmooney@cr2-magru> show configuration | display set | match "187.16.221.212|187.16.222.90|187.16.216.55" | match peer-as set protocols bgp group IX4 neighbor 187.16.216.55 peer-as 15169 set protocols bgp group IX4 neighbor 187.16.221.212 peer-as 15169 set protocols bgp group IX4 neighbor 187.16.222.90 peer-as 15169
As you would expect we learn virtually the same set of routes from all of these peers. So for instance if we look at the table we see three valid paths for this example route:
cmooney@cr2-magru> show route protocol bgp 8.34.216.0/21 terse exact inet.0: 981850 destinations, 2026403 routes (981619 active, 1 holddown, 553 hidden) Restart Complete + = Active Route, - = Last Active, * = Both A V Destination P Prf Metric 1 Metric 2 Next hop AS path * N 8.34.216.0/21 B 170 280 0 15169 ? unknown >187.16.221.212 N B 170 280 0 15169 ? unknown >187.16.222.90 N B 170 280 0 15169 ? unknown >187.16.216.55
However we only send traffic to 187.16.221.212:
cmooney@cr2-magru> show route protocol bgp 8.34.216.0/21 terse exact active-path inet.0: 981839 destinations, 2026683 routes (981612 active, 1 holddown, 566 hidden) Restart Complete + = Active Route, - = Last Active, * = Both A V Destination P Prf Metric 1 Metric 2 Next hop AS path * N 8.34.216.0/21 B 170 280 0 15169 ? unknown >187.16.221.212
This is despite all the BGP attributes being the same, as we do not have BGP multipath configured globally or for the IX4 group.
I'm not sure this is a major issue. Certainly in this specific case Google are probably dealing with so much traffic on each of these three routers that us picking one of them to send all of ours to is no issue. But it might be something to consider when looking at the parent task (certainly where WE have mltiple IPs on an exchange we would like peers to load-share between our routers).