NetworkLife

Masters Partenaires Datacenter (Cisco France)

Benoit — Thu, 30 Nov 2023 22:27:06 +0000

J’ai eu l’occasion de participer cette semaine aux Masters Data Center dans les nouveaux locaux de Cisco France à Paris. L’occasion de faire le point avec les “technical solution architect” français sur les produits Data Center, de voir quelques deep dives, packet walks, et les roadmaps des produits à venir en 2024. Je profite donc de cette occasion pour dépoussiérer ce blog :) Au programme du mercredi : Nouveautés et update ACI Update produit : pourquoi évolution 400G/800G NXOS / NDFC Insertion de service en VxLAN Sécurité et micro-segmentation embarquée sur ACI Nexus Dashboard et Insights Voici quelques notes des passages qui m’ont intéressé le plus. Nouveautés et update ACI ACI est toujours la solution privilégiée aujourd’hui en Data-Center dans la gamme des produits Cisco, il me semble important de le rappeler, car NDFC n’est pas aussi abouti, moins mature selon moi. En 2024, Cisco cherche à développer l’adoption des différentes features offertes par ACI, car beaucoup de clients ont déjà renouvelé leurs DC mais sont encore beaucoup en “network-centric” et n’utilisent pas vraiment les fonctions avancées (contrats, L4/L7 services…etc). Cisco cherche aussi à développer la partie opérationnelle via le couplage avec NDI (Nexus dashboard Insights) qui offre des options supplémentaires de visualisation et d’assistance au troubleshooting (moyennant le bon niveau de licence, dont le modèle à changé récemment). L’adoption est d’ailleurs poussée via la proposition de “healthcheck ACI”, grâce à des rapports NDI pour les clients qui le souhaitent afin d’en démontrer les avantages. La cadence des releases change légèrement pour devenir “prédictibles”. À partir de la 6.0, les 3 premières releases sont orientées features (6.0.1, 2 et 3) sur une durée de 12 mois, à partir de 6.0.4, ils freezent le code, et passent en maintenance release pendant 15 mois, par la suite, bug fix exceptionnels seulement, avec focus sécurité et CVE pendant 15 mois à nouveau, il restera alors 6 mois pour upgrader en version supérieure. Il faudra donc changer de train tous les 2 ans environ, ce qui semble une durée raisonnable, surtout lorsque tous les endpoints sont double attachés (possible d’upgrader les équipements pairs/impairs facilement, sans coupure. La version 5.2(8) est la version recommandée à ce jour. La version 5.3(1) est aussi recommandée pour les clients qui veulent rester sur le train 5.x mais ayant renouvelé leurs APICs avec les nouveaux modèles M/L4. Ces APICs apportent un changement de processeur (AMD) ainsi qu’un changement d’OS (CentOS) et l’appliance est à base d’UCS Gen6. Cisco développe sa capacité à patcher, pour ajouter du code sur le train logiciel, en ne fixant que ce qui est fixé, 90% des patchs fournis aujourd’hui sont côté control-plane, et ne nécessitent pas de reboot. Ils essayent de faire des patch “hitless”, sans dégradation de traffic. (patchs = SNU = software maintenance update). Le portfolio N9K évolue avec l’arrivée de la gamme 800G, sur les gros chassis modulaire, assez peu déployés chez les clients. Le scale initialement “arbitraire” en termes de nombre de leafs supportés par Fabric va augmenter, les chiffres […]

The post Masters Partenaires Datacenter (Cisco France) first appeared on NetworkLife.

Building a Cisco ACI Lab

Benoit — Tue, 02 Feb 2021 07:30:00 +0000

This article is a summary of the best solutions to practice Cisco ACI before using it in a production environment.

The post Building a Cisco ACI Lab first appeared on NetworkLife.

HowTo Parse log records of ACI APIC

Benoit — Fri, 22 Jan 2021 08:00:00 +0000

Every time I have to search for something inside the Event menu of the Cisco APIC, I'm complaining about the lack of search options... That's why I developed this Python script to parse everything easily and quickly.

The post HowTo Parse log records of ACI APIC first appeared on NetworkLife.

Cisco ACI L4-L7 Service-Graph One-Arm mode PBR with Fortinet Firewall

Benoit — Thu, 02 Jul 2020 06:44:00 +0000

I just launched my first youtube video where I configure and deploy a Cisco ACI Service graph with Policy Based Redirect. I’m using the VMM domain integration, and I’m redirecting the flows between two VMs (client and server) from two different EPGs into a Fortinet VM64 Firewall. Please comment the video if you have any question, but first, go put a like on the video ;)

The post Cisco ACI L4-L7 Service-Graph One-Arm mode PBR with Fortinet Firewall first appeared on NetworkLife.

What are the Endpoint Security Groups (ESGs) of ACI ?

Benoit — Mon, 18 May 2020 22:39:27 +0000

You should have noticed the release 5.0(1) of Cisco ACI last week, it introduces a few new features among which we can find the Endpoint Security Groups (ESGs).

The post What are the Endpoint Security Groups (ESGs) of ACI ? first appeared on NetworkLife.

ACI | APIC unreachable after PCIe NIC card replacement

Benoit — Mon, 13 Apr 2020 07:39:15 +0000

Following a hardware issue on a Cisco APIC, we had to replace the PCIe NIC card of the server (based on Cisco UCS). And as you may also encounter if you are reading this, it wasn’t straight forward :) The initial problem was that the Eth2-1 and Eth2-2 ports went down after a few hours after each reboot, and that’s a problem in an active APIC cluster… we decided to replace this APIC by the standby one in order to maintain a stable cluster of 3x APICs, before replacing the card. How to replace an active APIC with a standby one is an article to be created soon :) We replaced the card ~20 minutes operation (shutdown the server, open the top panel, extract the PCIe card, replace with the new one, close the top panel, rack back the server, power it on, cable it back). The details can be found here, and for any other component replacement, it’s here. Symptoms After replacement, the symptoms are the following: The Card was now seen correctly from the CIMC (Networking > Adapter Card 1) Ports “Up” on the APIC side, Wrong LLDP information (no real hostname and port detected, only the MAC addresses were displayed) and Ports “Out of service” on the leaf side… LEAF101# show lldp neighbors Device ID Local Intf Hold-time Capability Port ID c4f7.d592.b85e Eth1/47 120 c4f7.d592.b862 LEAF101# show int eth1/47 status Port Name Status Vlan Duplex Speed Type Eth1/47 -- out-of-ser trunk full 10G 10Gbase-SR Resolution The problem was the following: after the replacement of the card, the LLDP configuration was enabled on the UCS side, and it was overwriting the LLDP packets in direction to the Leaf switch. The leaf switches based on received LLDP packets were not able to determine that those ports were connected to the APIC and put interfaces in Out of Service state. We had to disable LLDP from the CIMC interface of the APIC (Networking > Adapter Card 1 > General > Uncheck “Enable LLDP”). Click Save, and then a reboot of the APIC is mandatory for it to be applied. (from the CIMC > Host Power > Power Cycle). After that, LLDP was functioning properly on the APIC, connectivity with the cluster was re-established : LEAF101# show lldp neighbors Device ID Local Intf Hold-time Capability Port ID APIC Eth1/47 120 eth2-1 The standby APIC was able to reach all the active APICs (it wasn’t before): admin@APIC:> ping 10.30.0.1 PING 10.30.0.1 (10.30.0.1) 56(84) bytes of data. 64 bytes from 10.30.0.1: icmp_seq=1 ttl=58 time=0.282 ms 64 bytes from 10.30.0.1: icmp_seq=2 ttl=58 time=0.294 ms 64 bytes from 10.30.0.1: icmp_seq=3 ttl=58 time=0.237 ms admin@APIC:> ping 10.30.0.2 PING 10.30.0.2 (10.30.0.2) 56(84) bytes of data. 64 bytes from 10.30.0.2: icmp_seq=1 ttl=58 time=0.282 ms 64 bytes from 10.30.0.2: icmp_seq=2 ttl=58 time=0.294 ms 64 bytes from 10.30.0.2: icmp_seq=3 ttl=58 time=0.237 ms admin@APIC:> ping 10.30.0.3 PING 10.30.0.3 (10.30.0.3) 56(84) bytes of data. 64 bytes from 10.30.0.3: icmp_seq=1 ttl=58 time=0.282 ms 64 bytes from 10.30.0.3: icmp_seq=2 ttl=58 time=0.294 ms 64 bytes from 10.30.0.3: icmp_seq=3 ttl=58 time=0.237 ms admin@APIC:> […]

The post ACI | APIC unreachable after PCIe NIC card replacement first appeared on NetworkLife.

ACI | Network 172.17.0.0/16 unreachable from APIC

Benoit — Fri, 27 Mar 2020 07:00:00 +0000

Some days ago I had to configure a radius server on an APIC cluster. This server was addressed in the 172.17.0.0/16 range and it worked well for the spines and leaves of the fabric but not for any APIC of the cluster. From the APIC, we had the “unreachable” faults: From the CLI, the problem seemed more clear: APIC1# bashadmin@APIC1:~> ping 172.17.1.50PING 172.17.1.50 (172.17.1.50) 56(84) bytes of data.From 172.17.0.1 icmp_seq=1 Destination Host UnreachableFrom 172.17.0.1 icmp_seq=2 Destination Host UnreachableFrom 172.17.0.1 icmp_seq=3 Destination Host Unreachable^C— 172.17.1.50 ping statistics —5 packets transmitted, 0 received, +3 errors, 100% packet loss, time 4090mspipe 4 admin@APIC1:~> traceroute 172.17.1.50traceroute to 172.17.1.50 (172.17.1.50), 30 hops max, 60 byte packets1 172.17.0.1 (172.17.0.1) 3049.452 ms !H 3049.385 ms !H 3049.357 ms !H The traceroute stopped at 172.17.0.1, not the out-of-band gateway configured. admin@APIC1:~> routeKernel IP routing tableDestination Gateway Genmask Flags Metric Ref Use Ifacedefault 10.200.200.1 0.0.0.0 UG 16 0 0 oobmgmt10.30.0.0 10.30.0.30 255.255.0.0 UG 0 0 0 bond0.391410.30.0.30 0.0.0.0 255.255.255.255 UH 0 0 0 bond0.391410.200.200.0 0.0.0.0 255.255.255.0 U 0 0 0 oobmgmt169.254.1.0 0.0.0.0 255.255.255.0 U 0 0 0 teplo-1169.254.254.0 0.0.0.0 255.255.255.0 U 0 0 0 lxcbr0172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0 The radius servers where in the docker range of the APIC, so the docker route is preferred…. as explained in this enhancement request https://bst.cloudapps.cisco.com/bugsearch/bug/CSCve84297, a service cannot be reached by using the APIC out-of-band management that exists within the 172.17.0.0/16 sub-net. Solution The solution is to change the Docker bridge-IP of the APIC, it can be performed from a simple API call (the most complicated action would be to find another /16 subnet available :) ). The detail of the API call is below, the script is replacing the default 172.17.0.1/16 by another IP in the range 10.255.0.0/16 : POST {{apic-url}}/api/plgnhandler/mo/.xml <?xml version=”1.0″ encoding=”UTF-8″?> <apPluginPolContr> <apContainerPol containerBip=”10.255.0.1/16“/> </apPluginPolContr> Conclusion Be careful and change the internal network of the docker service before running under production if you have this internal subnet used on your data center network (even if the action of changing it is not impacting the production, we always prefer to spot and correct this kind of problem before).

The post ACI | Network 172.17.0.0/16 unreachable from APIC first appeared on NetworkLife.

[Cheat Sheet] ACI – Contracts

Benoit — Tue, 03 Mar 2020 23:20:48 +0000

This week I detail the Contracts inside ACI, allowing to filter the traffic between endpoints, like an ACL would do in a classic network. In this document, I describe the VRF default behaviors and how we can improve the filtering with the Contracts. How the contracts are working inside ACI, the object model and some example of configurations and their effect (Reverse Filter Ports, Apply Both Directions…). The file is still in progress, but I think the information is already ready to be shared with enough information to help a lot of people understanding the basics of the ACI contracts The file is available here: ACI 05 – Contracts. PS: The other files of this series can be found here: ACI 01 – The Basics. ACI 02 – Fabric Access Policies ACI 03 – The Tenants ACI 04 – L3out

The post [Cheat Sheet] ACI – Contracts first appeared on NetworkLife.

[Cheat Sheet] ACI – L3out

Benoit — Wed, 12 Feb 2020 05:47:00 +0000

This week I detail the L3out object of ACI, allowing routed connectivity to external networks. In this document, I describe the objects and their relationships, present the most common designs, gateway redundancy and there is also a step by step configuration guide. The file is available here: ACI 04 – L3out. PS: The other files of this series can be found here: ACI 01 – The Basics. ACI 02 – Fabric Access Policies ACI 03 – The Tenants

The post [Cheat Sheet] ACI – L3out first appeared on NetworkLife.

[Cheat Sheet] ACI – The Tenants

Benoit — Thu, 30 Jan 2020 07:30:00 +0000

The third part of these Cheat Sheets series continues to develop the different objects of the Cisco ACI Fabric. After reviewing the Fabric tab last week which can be seen as the “underlay”, now it’s time to take a look at the Tenant tab, the “overlay” where the EPGs are located. The “Tenant” tab of the APIC is as confusing as the Fabric tab, there is a multitude of objects to take care of, from the Application profile to the EPG and from the VRF to the Subnets, this cheat sheet will help you to better understand the big picture of the ACI Tenants. The file is available here: ACI 03 – The Tenants. Let me know if it helped! PS: The other files of this series can be found here: ACI 01 – The Basics. ACI 02 – Fabric Access Policies

The post [Cheat Sheet] ACI – The Tenants first appeared on NetworkLife.