“Datacenter troubleshooting guide” – a blog by Gilles Dufour.
Day 2 – Basic Loadbalancing
Now, let’s focus on basic loadbalancing.Since you have read the previous post (“Day 1 – Start with the basic” ) you already did preliminary work by checking connectivity between client – ACE and ACE – server.Everything is good and you can confirm traffic from client does it the ACE device.
Still, your loadbalancing solution does not work.
The next step is to check if ACE does count the client request against the appropriate VIP.For that you will use the command show service-policy <policy_name>.
Check if the“client pkt count” counter is increasing.Also check the “server pkt count”. If you do not see the server packet counter incrementing, it is often indication of asymmetric routing.You can quickly confirm this by configuring client nat.If that solves the problem, it does confirm that you have asymmetric routing.You then need to either fix the server routing table or keep client nat.
If your client packet counter does not increment and the “hit count” counter also stays unchanged, the traffic does not match this rule or it is not getting to the ACE device.
A quick way to check the traffic hits the correct rule is to call the following command :
show np 1 access-list trace vlan <inbound vlan> in pro <protocol> source <src ip> <src port> destination <dst ip> <dst port>
You can usually ignore the first part of the output from this command.It begins to be interesting from the “version+aceid”.
In our case the client ip address is 192.168.20.45. The source port is unknown so I use the value "0". The virtual ip address is 192.168.20.122 on port 80. Vlan 20 is the interface on which client traffic is coming into my ACE.
switch/Admin# show np 1 access-list trace vlan 20 in pro 6 source 192.168.20.45 0 des 192.168.20.122 80
What you want to look at first is the vserver id.In our example, the id is 0x51 or 81 in decimal.
You can then check if it corresponds to your policy-map and class-map by checking the config manager tables.
switch/Admin# show cfgmgr internal table l3-rule | i 81
81 135 104 0 0 DATA_VALID,
This command gives us a line matching our rule 81 and this rule is from policy-map 135 and class-map 104.
Again we can check the internal tables to identify those objects.
switch/Admin# show cfgmgr internal table policy-map | i 135 135 SLB 0 DATA_VALID, switch/Admin# show cfgmgr internal table class-map | i 104 104 VIP-122-80 0 DATA_VALID, switch/Admin#
As you can see object 135 is policy-map “SLB” and object 104 is class-map “VIP-122-80”.In my case, it does match the show service-policy command I initially typed.
If it does not match the rule you expected, it means ACE found a matching rule before the one you are testing.Check your configuration and try to re-order the rules.
Don’t forget ACE looks into service policies sequentially and it stops when it finds a match.So, it might not be the best match.Try to order your rules accordingly.
If the rule is correct, but hit count is not incrementing, the traffic is probably dropped before it gets to the ACE device.I will recommend reading the first post for troubleshooting connectivity issues.
Next time, I will focus on the other info contained in the show access-list trace command.
As we know ACI learn fabricPathEp in three ways which are.
1-non-aggregated ==> Not an aggregated link2-Link ==> Direct Port Channel3-Node ==> Virtual Port Channel
If the endpoint is being learnt by "Link or Node" we can then easily...
The reason of this post is I am confused by Cisco documents regarding the architecture of the transport network between ACI on-prem DC and ACI Cloud in AWS. Let me explain: 1. From ACI in AWS whitepaper here: https://www.cisco.com/c/en/us/solutions/c...
Hello Guys, I am trying to flash a 3164 from 7.0(3)I7(5a) to nxos.7.0.3.I4.8.bin But i keep getting the below error:I do have space so i do not think it's a space issue.Any ideas? Thank you. switch# sh verCisco Nexus Operating S...