Establishing BGP neighbor peering from multiple tunnel IPs to one dest

[chin_DC]

How do I create multiple BGP neighbor peering from multiple tunnel IPs to one destination IP and remote-as?

and when it comes to setting the routing preference how do we do that 

if someone can share a sample config.

Diagram

[M02@rt37]

Hello @chin_DC 

Example:

interface Tunnel1
ip address 10.1.1.1 255.255.255.0
tunnel source Loopback0
tunnel destination 192.0.2.1
!
interface Tunnel2
ip address 10.1.2.1 255.255.255.0
tunnel source Loopback0
tunnel destination 192.0.2.1
!
router bgp 65000
neighbor 192.0.2.1 remote-as 65001
neighbor 10.1.1.2 remote-as 65001
neighbor 10.1.2.2 remote-as 65001
!
address-family ipv4
neighbor 192.0.2.1 activate
neighbor 10.1.1.2 activate
neighbor 10.1.2.2 activate
neighbor 10.1.2.2 route-map set-local-pref in
!
route-map set-local-pref permit 10
match ip address prefix-list TUNNEL2-PEER
set local-preference 200
!
ip prefix-list TUNNEL2-PEER seq 10 permit 10.1.2.2/32

The reason for specifying the remote IP addresses of Tunnel1 and Tunnel2 in addition to the BGP peer's IP address is to ensure that the BGP updates are sent and received over the correct tunnel interface. By explicitly defining the remote IP addresses of the tunnel interfaces, the router ensures that BGP traffic is sent through the correct tunnel and that the BGP neighborship is established over the correct interface.

With this configuration, the local preference is set to 200 for BGP updates received over Tunnel2. This can influence the routing decisions for incoming traffic from that BGP peer, making it more preferred over other BGP peers.

[chin_DC]

Thanks for the detailed explanation.

The local preference is set to 200 and this is for incoming traffic, my requirement is for outbound, the remote end is a cloud provider, and the default route is pointing to the cloud.

How do I achieve this ? 

[MHM Cisco World]

keep away load sharing now, 
you have four tunnel end to same destination, GRE accept that 
but 
BGP allow you to establish only one TCP session between two Peer (because the distention is same)
so either union the tunnel or union the BGP 
there is no other solution 

[M02@rt37]

@chin_DC 

The LP 200 is applied to the prefixes received from neighbor 10.1.2.2 , then yes it's in INBOUND (in).

The LP 100 (default)  is applied to the prefix received from neighbor 10.1.1.2

Then, on the routing table on the edge router, the flow will choose TUNNEL-2 in primary due to the LP 200 to go OUTSIDE.

If you want to force traffic from outside to inside to come from TUNNEL-2, then you can use AS-PREPEND [AS-PATH], community or MED, depend of the remote end.

[paul driver]

Hello
You should only require a single bgp peering as an overlay to an igp such as ospf, This will provide resiliency plus you could then cost out the tunnels to the most preferred.

The single bgp peering would be a loopback (most preffered)

example:
int loopback 0
ip address 1.1.1.1 255.255.255.255
ip ospf x area 0

int  tun 1
ip ospf x area 0

int  tun 2
ip ospf x area 0
ip ospf cost 10

int  tun 3
ip ospf x area 0
ip ospf cost 15

int  tun 4
ip ospf x area 0
ip ospf cost 20

router ospf 1
router-id 1.1.1.1

router bgp1
bgp log-neighbor-changes
neighbor 1.1.1.2 remote-as 2
neighbor 1.1.1.2 ebgp-multihop 2
neighbor 1.1.1.2 update-source Loopback0

[MHM Cisco World]

you can do 
config LO in both side and use LO as tunnel source and tunnel destination, this will give you the load sharing for tunnel 
or you can do 
run multi tunnel and then use LO in BGP.

it up to you.