Hi there,   I would need your experience to determine if some behavior documented in the ACI L3 Config Guide is true or if I am reading it wrong. The document is here and the statement is:     When Allow all (0.0.0.0/0 with aggregate flag) is used in explicit prefix-list for export route-control, only the routes learned from a routing protocol (such as BGP, OSPF, or EIGRP) will be advertised. The 0/0 aggregate flag will not advertise prefixes corresponding to the following: Bridge domain (BD) subnets Directly Connected Interfaces on the border leaf switch Static routes defined on the L3Out So, I have 2 L3outs on a VRF, each L3out talks OSPF with an external router each. Simple transit routing. Some OSPF routes are learned from L3outA and I need them redistributed on L3outB with some higher OSPF metric.   So, L3outA by default learns properly the OSPF Routes and I can see them on all leafs of the Fabric. In order to export them on L3outB, my configuration is:   L3outB has the following RouteMap object:   RouteMap: Fabric.To.OSPF, using 'Match Routing Policy Only' to have the Match statement as source of truth Order 1: Permit, Match Subnet 0.0.0.0/0 as Aggregate, Set Metric to 50   This RouteMap is applied as Export Policy on L3outB's external network. L3outB-ExtNet: Subnet 0.0.0.0/0 used only as External Subnet, not Export Control nor Aggregate. Route Control Profile:  RouteMap  Fabric.To.OSPF as Export   With this configuration, and considering the Note above in the Config Guide, I would expect the exported routes to have a metric of 50 only for the routes learned from L3outA. However, all routes out of L3outB have set a metric of 50, all are affected by the RouteMap. This will indicate that the statement is false and should be corrected, and in the configuration I need to specify on the RouteMap only the L3outA's routes so that only those are affected.   To complete, some BD subnets are associated with L3outB to be advertised over the L3out (in theory, not affected by the route-map) and 2 static routes on L3outB's Node (which should not be affected either). APIC is version 3.1(2o)   If this interests anyone, I could provide some diagrams, exported XML config and show commands.   My guess is that the statement is not accurate, a subnet 0.0.0.0/0 Aggregate in the RouteMaps does match all routes subnet to export on the L3out.   All the best,   ... View more

Hi everyone, I have found, possibly, a bit of an issue. Our Cisco APIC use exclusively OOB management. In order to join the vCenter server to deploy magically the DVS, the APIC has no other choice but to use the OOB network. However, the vCenter server is on a subnet 172.17.17.0/24 and the APIC is not able to reach it because, apparently, there is a docker interface inside that overlaps the network. admin@APIC-1:~> ip route default via 10.101.1.254 dev oobmgmt  metric 16 <<<<<<<<<< OOB 10.50.0.0/16 via 10.50.0.30 dev bond0.3967  src 10.50.0.3 10.50.0.30 dev bond0.3967  scope link  src 10.50.0.3 10.101.0.0/23 dev oobmgmt  proto kernel  scope link  src 10.101.0.13 169.254.1.0/24 dev teplo-1  proto kernel  scope link  src 169.254.1.1 169.254.254.0/24 dev lxcbr0  proto kernel  scope link  src 169.254.254.254 172.17.0.0/16 dev docker0  proto kernel  scope link  src 172.17.0.1   >>>>>>>> Docker subnet thqt overlaps the vCenter IP APIC-3-NXCAPE007R# ping 172.17.17.10  >>>>>>>>>>>>>> Try to ping the vCenter PING 172.17.17.10 (172.17.17.10) 56(84) bytes of data. From 172.17.0.1 icmp_seq=1 Destination Host Unreachable  >>>>>>> The Docker Interface replies From 172.17.0.1 icmp_seq=2 Destination Host Unreachable From 172.17.0.1 icmp_seq=3 Destination Host Unreachable From 172.17.0.1 icmp_seq=4 Destination Host Unreachable What is this docker0 interface doing there? Have you had this issue before? Should I try to add static routes for the OOB to reach the vCenter properly via the OOB GW? Can I shut down this docker0 interface? Thanks! ... View more