Can you ping a Subnet gateway with no Endpoints assigned to the EPG?

[vv0bbLeS]

Hello all,

If I configure a Bridge Domain with a Subnet, should I be able to ping the gateway of that Subnet? I am currently unable to do so. I also have an EPG configured and assigned to that Bridge Domain, but no Endpoints currently reside in the EPG.

I guess my question could be rephrased as: Can you ping the gateway of a Subnet in ACI when no Endpoints reside in that Subnet?

[RedNectar · Accepted solution]

Hi @vv0bbLeS ,

I just love this question, because it's going to give me an excuse to get into discussing my favourite aspect of ACI.  In fact, I've been thinking about writing a post entitled something like "Why you spent so much money on ACI"

And your question would highlight the perfect reason.

Which is ...

ACI deploys what is needed when it is needed dynamically (and withdraws it when not needed)

In many ways, think of it like dynamic routing protocols vs static routing. In ACI, even default gateway addresses are dynamic, as well as all the VLANs, Bridge Domains, VRFs, filters and ACL policies.

So back to your question. Whichever way you ask it. Same thing

---

If I configure a Bridge Domain with a Subnet, should I be able to ping the gateway of that Subnet?

Can you ping the gateway of a Subnet in ACI when no Endpoints reside in that Subnet?

---

The answer is a resounding...

IT DEPENDS on whether any EPG linked to the subnet has been allocated any port/encap mappings (either static or dynamic)

Why?

Because all you have defined is a model of the IP Address that you'd like deployed WHEN it is needed.  And it will NOT be needed until there is a mapping (static or dynamic) defining the traffic that identifies that EPG.  And if there is no static mapping for an EPG, or there is no reason for a dynamic mapping to be applied to an EPG, you will NOT be able to ping the gateway IP because it doesn't exist yet. Just as a statement in your Catalyst routing configuration of network 10.0.0.0 does not cause subnets to be advertised that don't exist yet.

Now, the best way to see this is to start a terminal session to a leaf switch. Issue a

show ip route vrf tenant_name:vrf_name 

command, before you allocate a static mapping to an EPG

Then issue it again AFTER you do a static mapping for that EPG to an interface on the leaf you have your console session.

And of course, what you'll see is that the IP address has been dynamically allocated and appears as a /32 in the routing table.

Here's my example

BEFORE - the VRF doesn't even exist

Leaf2201# show ip route vrf RedNectar:Production_VRF
No IP Route Table for VRF "RedNectar:Production_VRF"

AFTER adding a static mapping to interface eth1/27 on the leaf for an EPG linked to a BD with IP 10.217.11.1/24

Leaf2201# show ip route vrf RedNectar:Production_VRF
IP Route Table for VRF "RedNectar:Production_VRF"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%' in via output denotes VRF 

10.217.11.0/24, ubest/mbest: 1/0, attached, direct, pervasive
    *via 10.2.0.65%overlay-1, [1/0], 00:00:01, static, tag 4294967294
10.217.11.1/32, ubest/mbest: 1/0, attached, pervasive
    *via 10.217.11.1, vlan49, [0/0], 00:00:01, local, local

Now I could talk for some time about this (ask my students, I've been known to rave for some time...) but the key thing as for as your question goes is that the IP address now exists on the leaf switch, so you can now ping it.  At this stage, there are no actual servers deployed to the EPG, but the IP address lives on the leaf and is pingable

Leaf2201# iping -V RedNectar:Production_VRF 10.217.11.1
PING 10.217.11.1 (10.217.11.1) from 10.217.11.1: 56 data bytes
64 bytes from 10.217.11.1: icmp_seq=0 ttl=65 time=0.355 ms
64 bytes from 10.217.11.1: icmp_seq=1 ttl=65 time=0.214 ms
64 bytes from 10.217.11.1: icmp_seq=2 ttl=65 time=0.35 ms
64 bytes from 10.217.11.1: icmp_seq=3 ttl=65 time=0.416 ms
64 bytes from 10.217.11.1: icmp_seq=4 ttl=65 time=0.392 ms

--- 10.217.11.1 ping statistics ---
5 packets transmitted, 5 packets received, 0.00% packet loss
round-trip min/avg/max = 0.214/0.345/0.416 ms

Another interesting discussion (for another time) is to discuss the 

10.217.11.0/24, ubest/mbest: 1/0, attached, direct, pervasive
    *via 10.2.0.65%overlay-1, [1/0], 00:00:01, static, tag 4294967294

route in the routing table and why it is directed at the IPv4 anycast address.

I hope this helps.

---

Don't forget to mark answers as correct if it solves your problem. This helps others find the correct answer if they search for the same problem.

---

[vv0bbLeS]

@RedNectar  wow what a great explanation! That makes complete sense. Thank you so much! And yes you should write that in an article! (I would also read an article on the "anycast" routing table entry you mentioned.) Thanks again!