I have a CSM configured to load balance a pair of servers hosting a Web Applicaiton and DNS.
The Web App work sfine but the CSM seems to be ignoring the DNS requests, can anyone see a mistake here? I've attached the exerpt from the config and the output showing that it is not matching the rule...
This should just work, so I hope it's a simple mistake I haven't spotted!
I have performed a trace and the results would seem to confirm the CSM is not behaving properly.
We used a 'monitor seesion 1 source vlan x' to capture the traffic on the client vlan of the CSM.
The IP range used for virtual services is 10.x.34.0/24. There is a static route from the MSFC to the primary CSM address.
One affect of this is that any packet sent to an IP in the 10.x.34.0/24 range which is not processed by a CSM virtual rule is forwarded by the CSM through the default route, which is back into the MSFC. This causes the packet to bounce between the MSFC and CSM until the TTL expires.
This is exactly what I see in the trace for UDP packets.
The first packet appears with a source MAC of the MSFC (00:17:0f range) and a destination of the CSM primary (00:13:c3 range).
The same packet then appears with a source of the CSM from a different MAC range (00:01:64) and a destination of the HSRP on the MSFC which is default gateway for the CSM.
This pairing of packets continues until the TTL expires...
So, the CSM must have processed the packet but decided it does not match a vserver... where do I go next?
No, the vserver does not forward the unknown traffic, it's just the routing table of the CSM.
The CSM has a gateway of the MSFC through which it communicates with the rest of the platform through the client vlan.
The expected behaviour (as works for the TCP/80 traffic) is for incoming packet 10.x.34.9:80 to be matched to the vserver and server nat the packet to the selected real IP, then output the packet on the server vlan.
For DNS we see the packet coming in for 10.x.34.9:53 and because the CSM isn't matching the vserver for some reason it acting as a router and forwarding the packet to the next hop, which happens to be the default gateway.
It is something I should cover with an acl or blackhole the unused IP, but I don't believe it is the problem here...
This configuration is working for TCP but not UDP, I don't understand why it is any different for the CSM?
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...