Hi,   You do need to watch out how you configure the interface policies for port-channels and vPC's.  When u build a policy for both of them, it will consider that policy to be the name of your port-channel/vPC, so when u try to bundle certain interfaces in this interface policy group, they'll be sending out of the same PDU's. So you cannot have 1 standard vPC/PC interface policy group for all of your hosts that are connecting via that way, you'd be creating 1 giant channel when you do that and it won't work.   So when u are talking about configuring vPC from the leaf to the host, you'll need define an interface policy group for each host that needs to be connected this way. Another tip is to use the same port on both leafs when you are doing vPC, it makes your interface selector configuration a lot easier and you'll have more insight. ... View more

Thanks,   That last sentence really got me :) I have never thought about doing that, but yes. That would make it a lot less tedious. ... View more

Hi,   So at the current brownfield network design, I'm pretty sure that vlan's are stretched between the 2 data centers. The issue i'm having is that when i migrate a vlan to a BD in the ACI Fabric, the mac-address will be in the ACI Fabric, but if that vlan's is known in both data centers brownfield network. This could cause assymetric forwarding.   It will be brief since the vlan will be removed after it's migrated in the ACI Fabric.   I also intend to create a layer 2 out per data centers, because some vlan's that have been migrated have their L3 on a firewall in each data center. So vlan 100 is active in DC1 and has their L3 in that DC1. So vlan 200 is active in DC2 and has their L3 in that DC2.   It looks prudent to then create a L2Out per data centers to avoid having traffic exiting the ACI fabric to have to be forwarded across the brownfield DCI.       ... View more

Hello,   So it will be a regular multi-pod with POD-1 in 1 data center and POD-2 in another.   We are using 2 DWDM circuits connecting via 4 IPN switches: 2 on each line in each data center. This whole multi-pod has been setup. Both ends have been configured and can see each other as BGP neighbours.   The following question is: How do you plan a migration from the brownfield network, which is pretty similar. It has 2 7K Core's connecting to a lot of 5K switches and everything is setup in back to back vPC redundancy. Now the brownfield network is also connected with 2 DWDM circuits and the logical connection is a vPC between the 2 7K clusters. So the DWDM is a vPC member.   Since it could very well be possible that vlan's in DC 1 are trunked to DC 2 across the brownfield data center interconnect. The problem is that I would like to have an exit from the ACI Fabric in DC1 and DC2 to smooth a possible migration. I guess I would have to kill the vlans's from going across the brownfield data center interconnect to avoid having a loop. ... View more

Hello,   Thanks for the assistance.   I've wiped the APIC clean and adapted the script, now it's still not joining. I did notice from a acidiag avread that the software version of this APIC is different then the other 2 that are already in the fabric.   So I'm guessing I'll have to upgrade the APIC before I can join it into the fabric? Can I upgrade the APIC via the CIMC of the Cisco UCS? ... View more

Hi,   Any reason you want to dual home those FEX to the 5K. As an experience i have come to the realisation that adding that layer of connectvity will just add up the complexity of the network instead of more redundancy.   I would single home your FEX to the 5K, you can still dual home the host to the FEX'es and build a vPC.    Why did i choose the single home?   - ISSU on dual home scenario (Enhanced vPC) is very limited to non existing, all of your FEX'es are known on both 5K. So an upgrade would require a downtime from all of the FEX'es   - This layer of redudancy is adding more complexity to the network but not more redundancy in my opinion. Your host will remain dual homed to the FEX'es.   - In eVPC, the vPC's are automatically created if i remember correctly, i did not like this. Configuration wise it added a bit more confusion then just copy pasting the same config on both 5K's.   - Using switch profiles to sync config i found to be very annoying. ... View more

Hello,   Thanks for the message. I will do this   We have also done a bit of troubleshooting on the F5 and noticed that it's actually the server that seems to not respond towards the F5's packet. So the server receives a connection from the F5's float IP, but very often the server does not respond anymore and the F5 has send DUP ACK and eventually retransmit the connection.   What i did notice:   The MTU of the physical interface of the viprion is set to 9198, but the MTU of a vCMP is set to 1500. The MTU of the switch is also set to 1500, do we need to match everything here to avoid problems? Or is this like a eventuality that the F5 is ready to receive jumbo frames or does it always expect them.   Also i noticed that when i perform a traceroute from the server the next hop is the Nexus core (which is normal in this case, because the F5 uses SNAT), but it sometimes changes the first hop. Sometimes it's the first nexus core and sometimes it's the other nexus core, i have noticed that peer-gateway command is on the vPC domain. So this would say that both cores can proxy for the VIP address of HSRP, but is it normal that i see the next hope then change in the tracert on the server? Should i just always see the VIP HSRP address? ... View more

Hello thanks for your message,   I have looked at the thread but there are some differences.    We did not connect our F5 Viprion's to the Core layer of the data center, we connected it to the edge with a Nexus 9K. We are using a ToR design aswell with vPC. This means that one chassis is connected to 2 ToR 9K that form a vPC towards the chassis and are a vPC domain on themselves. They then form a vPC towards the core which is a 7K.   The other chassis is connected the exact same way.   The config goes as follows: on the left end of the picture interface port-channel141 description Chassis 1 - vPC channel switchport mode trunk switchport trunk native vlan 999 switchport trunk allowed vlan 310,312,410-415 spanning-tree port type edge trunk spanning-tree bpduguard disable spanning-tree guard root spanning-tree bpdufilter disable logging event port link-status logging event port trunk-status storm-control broadcast level 80.00 storm-control multicast level 80.00 lacp mode delay vpc 141 interface Ethernet1/1 description Po141: Chassis1 1.1 - 10G FO MM - vPC channel member lacp port-priority 1 no cdp enable switchport mode trunk switchport trunk native vlan 999 switchport trunk allowed vlan 310,312,410-415 logging event port trunk-status storm-control broadcast level 80.00 storm-control multicast level 80.00 channel-group 141 mode active interface Ethernet1/2 description Po141: Chassis 1 1.2 - 10G FO MM - vPC channel member no cdp enable switchport mode trunk switchport trunk native vlan 999 switchport trunk allowed vlan 310,312,410-415 logging event port trunk-status storm-control broadcast level 80.00 storm-control multicast level 80.00 channel-group 141 mode active The only thing i see different is that we give 1 port LACP port-priority 1, i do not know if that affects it. We also use lacp mode delay, so the port-channel will wait for the host to setup the connection i guess. ... View more