We are big ISP, and we are peering ebgp with several International ISPs for inetrnet connectivity. My question is how to load balance between the several ISPs, I mean based on what?, we need to make sure to load balance in both ways.
by default BGP does not load balance and this because BGP will only put one route in the IP routing no matter how many paths it has learned. In order to force BGp to put mulitple paths in the IP routing table you will need to use the "maximum-paths" command in BGP.
As we are talking about BGP any mechanism influencing path selection can be used to load balance local traffic.
Basically you send traffic towards some destinations through one peering point and some traffic to other destinations through other peering points. Local Preference could be a good way to achieve this.
Be aware that you need some traffic analysis in order to influence the local traffic in the desired way.
Regarding option 2):
We are talking about BGP and what you want is to influence the routing decisions of other ASes. Bad news: there is no way to make SURE it will happen the way you want this to happen. They are AUTONOMOUS and therefore can also use f.e. LocPref to achieve their goals. Those might contradict yours.
But from a technical point of view the BGP updates you send should contain "hints" as to where the return traffic should be sent. As anything can be stripped of a BGP update except well-known mandatory attributes (origin, next-hop, AS path) usually AS path prepending is the measure to make return traffic for one of your prefixes prefer one way. And traffic for other prefixes you own another way.
Also be aware that BGP in itself was not built for Load sharing per prefix, because every BGP speaker will only announce the best path per prefix. So even in the neighbor AS after a route-reflector all BGP speakers will only learn ONE path to your AS per prefix.
Hope this helps
P.S.: Do not prepend too many ASes and do not split your IP address space in to many small junks. Also look at RIPE document 229, which talks about route flap dampening ... larger prefixes are always better.
We are pleased to announce availability of Beta software for 16.6.3. 16.6.3 will be the second rebuild on the 16.6 release train targeted towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are looking for early feedback from custome...