BGP peering over two VPC paths in L3out interface profile

[irenof]

Hi all, I have the following situation:

I want to create an L3out (SVI) and add a BGP peering. Since the SVI consists of both the 2 VPCs I add a new path to the Interface profile of the L3Out, with the same ip addressing scheme.

My problem is how to create the BGP peering. I have to options:

1) By leaf loopback. Not the focus of this thread

2) Using the physical interface of the SVI (10.0.0.0/29). To do this I have in some way to "bind" the BGP peer to one path of the interface profile, e.g VPC20. But what about VPC10? 

As a try I created the same peering under both the path and it resulted in a double configuration in BGP CLI view. Deleting the peering under VPC10, also the BPG configuration clears one part. From CLI point-of-view all should work, but:
1) I am not able to test this

2) what happens if VPC20 fails? Will the BGP session remain UP thanks to the VPC20? 

I do not like the GUI view, where the BGP peering is binded with the path.

Am I reasoning wrong?

Thanks,

Irenofe

[balaji.bandi]

is this BGP peering  between firewall and Leaf switch, then always suggest to use Loopback interface

also how is your FW configured HA ? 

[irenof]

FW are active/standby.
I know that the better solution is using loopback, but what happen in case
I use physical ip addresses?

[MHM Cisco World]

One by One 

You run bgp between FW HA and two Nexus vPC?

MHM

[irenof]

In run bgp between the two leafs and the router behind the FWs. The fw just
route traffic.

[MHM Cisco World]

FW so transparent mode ? 

MHM

[irenof]

FW just route L3 traffic between leafs and router. The leafs have a static
router to the router via FW (and viceversa)

[balaji.bandi]

There are pros and cons and deploy and monitor concept.

we always use best practice which is tested, if you like to go other router yes possible and we need deploy and monitor.

[M02@rt37]

Hello @irenof 

First, Thanks for that diagramm and details.

Do a peer with leaf loopback so failover should be seamless. If you use the SVI IPs, you must configure the neighbor on both paths (each leaf IP), otherwise failover will not work.

Your gui show duplicates because bgp peers are bound per path. To go further and try explaining better, in aci, when you built an L3out with vpc-attached SVIs, the system treat each leaf as an independent path even if they share the same IP address on the SVI !

So when you configure a BGP neighbor using the svi subnet, aci doe not “merge” it into one logical peer for the VPC pair... instead, it apply the configuration separately under each leaf path. So, in the gui, this shows up as 2 peers, one under Vpc20 and one under VPC10, even though they reference the same neighbor IP. From the Cli you see duplicate neighbor entries as well. So the “duplicates” are not a mistake, they are just how aci represent the fact that the BGP neighbor is bound to a specific path (...a leaf in the VPC pair...). If you delete one, you’re essentialy removing the peering from that leaf, which break this redundancy !

[irenof]

Hi M02@rt37,

thanks for your answer.  

---

. If you delete one, you’re essentialy removing the peering from that leaf, which break this redundancy ! 

---

I do not understand this. I if I create the same BGP peering under both the VPC paths, in GUI I have something line:
- Peer 10.0.0.1 - VPC 10

- Peer 10.0.0.1 - VPC 20

This will apply two equal confs for neigh 10.0.0.1 in both the Leafs.

If I delete for example the second peering from the GUI, in the CLI of both Leafs I still have one BGP neigh conf under router bgp section.

My question is about the graphical binding of a BGP peering with the VPC path (not the leafs).

I know that using the loopbacks solves the problem, but I would like to understand this different mode

Thanks,

Irenof

[M02@rt37]

You're welcome @irenof.

GUI makes you bind bgp peers to vpc paths, so it looks like you're creating duplicates, but in reality, the cli on each leafs only shows a single neigbhor statement.

If you remove one peer from the gui, aci delete it only from the corresponding leaf, not both ! which means you loose redundancy if that leaf fails... so, that's why you must configure the neighbor on both vps paths, so eah leaf can establish the session independently and the bgp peering survives a leaf failure!

[irenof]

Hi M02@rt37,

I tried creating two equ

al BGP peers under both VPC paths (VPC10 enad VPC20):

and ACI creates the same neigh conf twice under each leaf (i.e. two equal bgp neighs under leaf 101and two equal bgp neighs under leaf 102). The actual BGP session then is just one, but the conf is duplicated in both the leafs:
Leaf101

vrf member tenant common vrf CLOUD
neighbor 10.171.19.30 l3out CLOUD_X
update-source vlan 3704
address-family ipv4 unicast
exit
local-as 65441 no-prepend replace-as
remote-as 65301
exit
neighbor 10.171.19.30 l3out CLOUD_X
update-source vlan 3704
address-family ipv4 unicast
exit
local-as 65441 no-prepend replace-as
remote-as 65301
exit
exit

If I delete one peering BGP e.g. from patch VPC20 for example, than on CLI, on each leaf, I will have just one bgp neigh configurated. 

I do not understand when you say: 

---

If you remove one peer from the gui, aci delete it only from the corresponding leaf, not both ! which means you loose redundancy if that leaf fails...

---

VPC 10 belongs to both leafs 101 and 102, so even with a single BPG peering profile (under vpc10), ACI configures the BGP neigh in both leafs.

I am asking myself why ACI asks for the path under the SVI, and not only the actual SVI object when a new BGP peering must be created...

BR,

Irenof

[M02@rt37]

Mmmm correct, add the peer under both vpc path is unnecessary... binding it one is enough for aci to deploy the neighbor for both leafs in that vpc domain !!!

A question, your peer is connected via a signle-homed routed interface or via dual-homed vpc ?

[irenof]

If the VPC where I "binded" the BPG peer goes down, what hapen to the session? I think that since there is the other VPC in the SVI, nothing happen. Even if the BGP peering  is under the other VPC...

I only tested this, with a SVI with two interfaces: 1/5 and 1/6. Onyl 1/5 is connected, while the eth1/6 is down and not connected. I added a BGP peer under the path ath1/6. All works..

BR,

irenof

[M02@rt37]

Ok @irenof.

When you configure bgp neighbor under one vpc path, ACI actually programs that neighbor under the bridge domain SVI context on both Leafs, regardless of which specific vpc path you select. That's why your test work no ? Even though you created the peer under eth1/6, the neighbor still came up using the live eth1/5 interface! because the SVI is shared accross both links of that vpc...

So, if the vpc link where you "bound" the peer goes donwn, the bgp session does not drop, as long as another active member link of the vpc is up! the session rides on that SVI, not the specific path you pikcked in your GUI.

From my point of view in a vpc SVI context, the "path" we choose for the bgp peer in ACI is more of a graphical/logical binding, not a hard physical dependency.