i have currently running a BGP Session to one peer. I want to add another peer.
Currently, i am connected to a 10gbit uplink. The new peer will have 100mbit speed.
Can it be done, that as much as possible traffic is routed over the 100mbit peer but if a connection need more than 100mbit, then the 10gbit uplink should be used as addition. So some pakets should then come over 100mbit peer and other over the 10gbit peer.
Example:
What happens if somebody downloads a testfile from a 1gbit mirror and it is routed trough the 100mbit uplink - can it be done, that the 100mbit link is used and the remaining bandwidth is used from the other peer?
The same for outgoing datas (upload).
How can i ensure that my backends are receiving/sending with maximum bandwidth if one of the peers have only 100mbit? Can the data pakets be routed dynamically?
It is ultimately impossible to do exactly what you ask.
There are a few methods of load balancing between BGP peers.
1st is to just allow natural BGP redistribution. Networks around the world choose shortest path, which depending on how your 2 upstreams diversify their own links, could mean a perfect balance or a lopsided one. You have no control over this essentially.
2nd is to ‘cherry pick’ some /24 prefixes that will use close to the 100mbit at peak, and advertise those prefixes out the 2nd peer as a /24 so as to be a more ‘specific’ route than your supernet. For instance if you have a /22 (4x/24’s) you can advertise the /22 to peer1 with 10gbit, then choose one /24 out of the subnet and advertise to peer2 with 100mbit. This method does mean that the /24 network on peer2 can only use the maximum 100mbit, but if peer 2 goes down then peer1 will pick up the slack (as you have the /22 advertised there).
The main problem is, that our 10gbit uplink has sometimes connectivity problems.
Sometimes the connection isnt stable for some seconds (this happens multiple times per day sometimes..).
We want to use the second peer as a backup, i trough i could use it as normal link also.
Would it be possibly that i declare this peer to:
automatic failover if the other peer has connection issue (does this can work if the peer only have connection issues for some seconds?)
the 100mbit peer should not be only backup/failover - it should route a little bit traffic too.
You can influence traffic in a few ways - joegoldman has already mentioned that you can advertise split up your advertisements between peers. If you advertise the same prefix(es) to multiple peers, you basically have 2 ways to influence inbound traffic’s choice of circuits to use:
Providers set local_preference on their side - this is usually done by the use of BGP communities. They give you a list of communities which can affect their policy, and you send one which increases or decreases the chance of certain prefixes being used by that provider.
AS_PATH length - for more distant networks, this is going to be the main attribute that influences traffic. You can prepend your AS number several times when sending it to the less preferred peer. So if there is a prefix you would rather receive via ISP2, then when sending this prefix to ISP1, you prepend it two or three times.
If you use prepend and communities, then you can advertise prefixes to both ISPs and if the first choice goes down, then the internet will start using the second-best path to reach your network.
As for outbound traffic, you tend to use local_pref to engineer your network’s choice of next hop.
so the switch to the other peer - if the one peer has paket loss - will be instantly and there will no more be paket loss if we activate the second peer?
BGP will stop only at very high packet loss or loss of connectivity to the peer all together, if you are wanting auto failover on link degradation you’d need something external monitoring the link, and talking with your routerboard to force the swap over.
The feature you are looking for does exist in BGP, just not in MikroTik. BGP Link bandwidth can be advertised to another AS as an extended community in Cisco routers. If the routers you are peering to are Cisco and will accept this community, then you might be able to make this work by doing the Community calculations and then tagging that towards the peer
This is only when communicating to the same eBGP network though is it not? How can 2 separate ISP’s be simultaneously aware of this for load balancing - my understanding is its an extension of ECMP so both links would have to go to same provider, where-as I think the question is 2 different network provider uplinks.
I think you may be thinking about the MED which does have all the requirements you mentioned
Actually, because the bgp link bandwidth feature is extended community based, it will transit any AS that is configured to be aware of and act on that community. It is not limited to eBGP and can pass between iBGP peers as well.
It doesn’t really use ECMP since the concept is to be able to perform unequal cost load sharing similar to EIGRP. There is a traffic load sharing algorithm built into the protocol that will distribute traffic based on the speed of the link even if one is 100 Mbps and the other is 10 Gbps.
I very much doubt it would translate far beyond your upstreams networks if they even allowed it - certainly not back to Tier1 - although I’ve never used it so I could be wrong there, it just seems like a technology that would be more likely used if you had 2 unequal links to the same provider, not when using 2 different upstream providers.
This sounds to me like a way to get some form of “cost” attribute to be associated with the entire path. If every ASN were to add their own peering bandwidth every time an AS border is crossed, then something analogous to a link-state protocol behavior could be done to choose the path based on path bandwidth…
I don’t see this getting tons of traction, simply because most networks are much more concerned with the bandwidth load of their OWN circuits. Not only that, but this wouldn’t communicate any kind of real-time load information, so I would imagine that it would contribute more towards an active/backup type of behavior…
