I've recently "inherited" responsibility of our CSMs.
Unfortunately, the configs are a mess and I'm looking to clean them up a bit.
Honestly, I'm astounded they're working -albeit, not without issue.
And so, I believe I have a good approach in starting to configure these correctly .
However, I do have some immediate issues and I was hoping to solicit some feedback as to any interim workarounds.
I have one client vlan - 146 and two server vlans - 74 and 75.
Problem #1: servers in vlan 74 cannot get out to internet - network 184.108.40.206. i've done some sniffer traces and I see the connection attempts going out but return packets are getting lost. also, direct access from client network to these system are required - which works fine.
Problem #2: servers located in vlan 75 can get to the internet ok but direct access to these servers is not working.
again i ran some sniffer traces and I see the connection attempts going out but return packets are getting lost.
1. client gateway on the MFSC is not properly defined. All traffic is traversing over vlan 1. i do not want to do this...
2. Server VLAN interfaces (74 & 75) are defined on MFSC. I believe this may be causing an issue as well.
I believe these issues are due to mis-configuration on the CSMs and the MFSC.
I was hoping to get some feedback to address the more immediate problems described above.
the problem of having the MSFC in the same vlan as the CSM [vlan 74 and 75] will cause asymetric routing.
The CSM does not tolerate asymetric routing.
So, you should find a way to remove those vlans.
Create a static route on the MSFC pointing to the CSM.
However, if there are devices in these vlans that generate a lot of traffic and are not of any use to the CSM, you may end up killing the CSM [which does not have the same bandwidth as the MSFC]. Just make sure what is there and if necessary, move some devices in a different vlan.
If the return packet is getting lost when accsing from vlan 74, it could be because the subnet associated with this vlan is not know by the remote end. It should be troubleshooted at the other end to be sure.
Another solution could be to enable client nat for server initiated traffic. You could nat the traffic from vlan 74 with an ip of vlan 75 since it seems to work for this one.
For that you would create a new serverfarm like this
Topology & Design:
Two ACI fabrics
Stretching VLANs using OTV
Both fabrics are advertising BD subnets into same routing domain
Some BDs(or say VLANs) are stretched, but some are not.
Endpoints can move betwee...
VMware Trunk Port Group is supported from ACI version 2.1
VMM integration must be configured properly
ASA device package must be uploaded to APIC
ASAv version must be compatible with ACI and device package version
Topology &Design:Traffic flow within same fabric:Endpoint moves to Fabric-2Bounce Entry Times OutTraffic Black-holedSummarySolutionAppendix:
In the Previous articles of ACI Automation, we are using Postman/Newman a...