10-10-2024 12:41 PM
Hi All,
We're using ACI in our environment and ran below command. I am not able to figure out on which leaf the tunnel destination "10.9.152.77" resides. I think the tunnel destination is the VTEP assigned to a vPC. How can we search it centrally and by avoid logging into each leaf.
cat-lef-1# show int tunnel91
Tunnel91 is up
MTU 9000 bytes, BW 0 Kbit
Transport protocol is in VRF "overlay-1"
Tunnel protocol/transport is ivxlan
Tunnel source 10.9.32.67/32 (lo0)
Tunnel destination 10.9.152.77
Output 2:
cat-lef-1# cat /mit/sys/tunnel-[tunnel1]/summary
# Tunnel Interface
id : tunnel1
aclTcamStQual :
adminSt : up
cfgdMtu : 9000
dest : 10.9.152.77
dn : sys/tunnel-[tunnel1]
idRequestorDn : sys/isis/inst-default/dom-overlay-1/lvl-l1/db-dtep/dtep-[10.9.152.77]
iod : 66
monPolDn : uni/fabric/monfab-default
operSt : up
rn : tunnel-[tunnel1]
src : 10.9.32.67/32
status :
tLayer : l3
tType : ivxlan
tmCfgFailedBmp :
tmCfgFailedTs : 00:00:00:00.000
tmCfgState : 0
type : physical
underlayVrfName :
v6Src : 0.0.0.0
vrfName : overlay-1
Solved! Go to Solution.
10-10-2024 01:09 PM
Hi @dhr.tech1 ,
You are trying to fix a broken light bulb by pulling the main switchboard apart!
In other words, I think you are looking in the wrong place for whatever your problem is.
But back to your question. If the VTEP 10.9.152.77 is indeed the vPC VTEP, then it will reside on each leaf. You can determine the IP address of the VPC by navigating to Fabric > Access Policies > Policies > Switch > Virtual Port Channel Default
But the comment you make ...
How can we search it centrally and by avoid logging into each leaf.
... worries me - because you will NEVER want to use the VTEP address to log into a leaf unless you are already logged into the APIC, in which case you should use something like ssh leaf1201
or similar based on the name you gave the leaf. The APIC's host file will find the appropriate address.
10-10-2024 01:09 PM
Hi @dhr.tech1 ,
You are trying to fix a broken light bulb by pulling the main switchboard apart!
In other words, I think you are looking in the wrong place for whatever your problem is.
But back to your question. If the VTEP 10.9.152.77 is indeed the vPC VTEP, then it will reside on each leaf. You can determine the IP address of the VPC by navigating to Fabric > Access Policies > Policies > Switch > Virtual Port Channel Default
But the comment you make ...
How can we search it centrally and by avoid logging into each leaf.
... worries me - because you will NEVER want to use the VTEP address to log into a leaf unless you are already logged into the APIC, in which case you should use something like ssh leaf1201
or similar based on the name you gave the leaf. The APIC's host file will find the appropriate address.
10-11-2024 02:40 AM
Thanks Chris, although I am bit new to ACI (closely worked on NSX VXLAN) but I don't think the vPC VTEP exists on all the leaf, it does on for NSX as we use Asymmetric Routing and Bridging but for ACI we use symmetric i.e. MAC VRFs are not required on the leaf where it is not required.
When I run "show system internal epm vpc" from the leaf I got the tunnel details only for the vPC hosted on the leaf itself.
10-11-2024 01:40 PM
Hi @dhr.tech1 ,
Thanks Chris, although I am bit new to ACI (closely worked on NSX VXLAN) but I don't think the vPC VTEP exists on all the leaf,
Correct. That is EXACTLY how ACI works. A leaf will never need to know the VTEP of a VPC until there is a flow that has a destination on the VPC, in which the leaf will receive an encapsulated frame from the device on the VPC, and from that frame the remote leaf will learn the VTEP address of the VPC. And even then, all you'll see in the endpoint table is the tunnel id that points to that VTEP.
If you want to know which tunnel ID a leaf uses for a remote VPC, then use this command:
show interface | grep Tunnel | grep -B3 <DTEP of VPC>
Leaf101# show interface | grep Tunnel | grep -B3 10.0.176.64 Tunnel13 is up Tunnel protocol/transport is ivxlan Tunnel source 10.0.192.64/32 (lo0) Tunnel destination 10.0.176.64
it does on for NSX as we use Asymmetric Routing and Bridging
I can't comment on that - I'm not sure how NSX works
but for ACI we use symmetric i.e. MAC VRFs are not required on the leaf where it is not required.
Sorry - maybe I need to understand NSX to understand what you mean by that
When I run "show system internal epm vpc" from the leaf I got the tunnel details only for the vPC hosted on the leaf itself.
Exactly. That command will give you details about the VPC peer, it was never designed to show tunnel destinations. To see Dynamic Tunnel End Point (DTEP) destination tunnel addresses on a particular leaf, use:show isis dteps vrf overlay-1
I'll add some good VPC troubleshooting examples below that I'll steal from this answer I gave some time ago.
But right now, I'm still scratching my head as to WHY you want to know the vPC VTEP? And why you want to view it on a leaf that hasn't received traffic from a source that is connected via the VPC?
apic1# show vpc map
is a pretty good place to start and
apic1# fabric xxx,yyy show vpc [extended]
is also good (where xxx and yyy are the switch IDs of the VPC pair).
Here are some samples
apic1# show vpc map Legends: N/D : Not Deployed Virtual Port-Channel Name Domain Virtual IP Peer IP VPC Leaf Id, Name Fex Id PC Id Ports -------------------------------- ------ ---------------- ---------------- ----- -------------------------------- ----- ------ -------------------- T1:L101..102:1:35_VPCIPG 12 10.0.192.67/32 10.0.16.64/32 686 101,Leaf101 po20 eth1/35 T1:L101..102:1:35_VPCIPG 12 10.0.192.67/32 10.0.16.66/32 686 102,Leaf102 po3 eth1/35 T3:L101..102:1:37_VPCIPG 12 10.0.192.67/32 10.0.16.64/32 345 101,Leaf101 po2 eth1/37 T3:L101..102:1:37_VPCIPG 12 10.0.192.67/32 10.0.16.66/32 345 102,Leaf102 po5 eth1/37 T4:L101..102:1:38_VPCIPG 12 10.0.192.67/32 10.0.16.64/32 2 101,Leaf101 po3 eth1/38 T4:L101..102:1:38_VPCIPG 12 10.0.192.67/32 10.0.16.66/32 2 102,Leaf102 po6 eth1/38 T5:L101..102:1:39_VPCIPG 12 10.0.192.67/32 10.0.16.64/32 3 101,Leaf101 po4 eth1/39 T5:L101..102:1:39_VPCIPG 12 10.0.192.67/32 10.0.16.66/32 3 102,Leaf102 po7 eth1/39 T6:L101..102:1:40_VPCIPG 12 10.0.192.67/32 10.0.16.64/32 344 101,Leaf101 po1 eth1/40 T6:L101..102:1:40_VPCIPG 12 10.0.192.67/32 10.0.16.66/32 344 102,Leaf102 po4 eth1/40 T7:L101..102:1:41_VPCIPG 12 10.0.192.67/32 10.0.16.64/32 688 101,Leaf101 po6 eth1/41 T7:L101..102:1:41_VPCIPG 12 10.0.192.67/32 10.0.16.66/32 688 102,Leaf102 po9 eth1/41 T8:L101..102:1:42_VPCIPG 12 10.0.192.67/32 10.0.16.64/32 689 101,Leaf101 po7 eth1/42 T8:L101..102:1:42_VPCIPG 12 10.0.192.67/32 10.0.16.66/32 689 102,Leaf102 po10 eth1/42
and
apic1# fabric 101,102 show vpc extended ---------------------------------------------------------------- Node 101 (Leaf101) ---------------------------------------------------------------- Legend: (*) - local vPC is down, forwarding via vPC peer-link vPC domain id : 12 Peer status : peer adjacency formed ok vPC keep-alive status : Disabled Configuration consistency status : success Per-vlan consistency status : success Type-2 consistency status : success vPC role : primary Number of vPCs configured : 7 Peer Gateway : Disabled Dual-active excluded VLANs : - Graceful Consistency Check : Enabled Auto-recovery status : Enabled (timeout = 240 seconds) Operational Layer3 Peer : Disabled vPC Peer-link status --------------------------------------------------------------------- id Port Status Active vlans -- ---- ------ -------------------------------------------------- 1 up - vPC status --------------------------------------------------------------------------------- id Port Status Consistency Reason Active vlans Bndl Grp Name -- ---- ------ ----------- ------ -------------------- ---------------- 2 Po3 up success success 2043-2044 T4:L101..102:1: 38_VPCIPG 3 Po4 up success success - T5:L101..102:1: 39_VPCIPG 344 Po1 up success success 2063-2064 T6:L101..102:1: 40_VPCIPG 345 Po2 up success success 2034 T3:L101..102:1: 37_VPCIPG 686 Po20 up success success 2013-2014 T1:L101..102:1: 35_VPCIPG 688 Po6 up success success - T7:L101..102:1: 41_VPCIPG 689 Po7 up success success 2083-2084 T8:L101..102:1: 42_VPCIPG ---------------------------------------------------------------- Node 102 (Leaf102) ---------------------------------------------------------------- Legend: (*) - local vPC is down, forwarding via vPC peer-link vPC domain id : 12 Peer status : peer adjacency formed ok vPC keep-alive status : Disabled Configuration consistency status : success Per-vlan consistency status : success Type-2 consistency status : success vPC role : secondary Number of vPCs configured : 7 Peer Gateway : Disabled Dual-active excluded VLANs : - Graceful Consistency Check : Enabled Auto-recovery status : Enabled (timeout = 240 seconds) Operational Layer3 Peer : Disabled vPC Peer-link status --------------------------------------------------------------------- id Port Status Active vlans -- ---- ------ -------------------------------------------------- 1 up - vPC status --------------------------------------------------------------------------------- id Port Status Consistency Reason Active vlans Bndl Grp Name -- ---- ------ ----------- ------ -------------------- ---------------- 2 Po6 up success success 2043-2044 T4:L101..102:1: 38_VPCIPG 3 Po7 up success success - T5:L101..102:1: 39_VPCIPG 344 Po4 up success success 2063-2064 T6:L101..102:1: 40_VPCIPG 345 Po5 up success success 2034 T3:L101..102:1: 37_VPCIPG 686 Po3 up success success 2013-2014 T1:L101..102:1: 35_VPCIPG 688 Po9 up success success - T7:L101..102:1: 41_VPCIPG 689 Po10 up success success 2083-2084 T8:L101..102:1: 42_VPCIPG
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide