Re: CAM table not updating after STP TCN

Mr Brunner provided some great advice on this recently, but here is the
recommendation from Cisco

With asymmetric routing, transmit and receive packets follow different paths
between a host and the peer with which it communicates. This packet flow is a
result of the configuration of load balancing between HSRP routers, based on
HSRP priority, which set the HSRP to active or standby. This type of packet
flow in a switching environment can result in excessive unknown unicast
flooding. Also, Multilayer Switching (MLS) entries can be absent. Unknown
unicast flooding occurs when the switch floods a unicast packet out of all
ports. The switch floods the packet because there is no entry for the
destination MAC address. This behavior does not break connectivity because
packets are still forwarded. But, the behavior does account for the flood of
extra packets on host ports. This case studies the behavior of asymmetric
routing and why unicast flooding results.

Symptoms of asymmetric routing include:

Excessive unicast packet flooding

Absent MLS entry for flows

Sniffer trace that shows that packets on the host port are not destined for
the host

Increased network latency with L2-based packet rewrite engines, such as server
load balancers, web cache devices, and network appliances

Examples include the Cisco LocalDirector and Cisco Cache Engine.

Dropped packets on connected hosts and workstations that cannot handle the
additional unicast-flooding traffic load

Note: The default ARP cache aging time on a router is four hours. The default
aging time of the switch content-addressable memory (CAM) entry is five
minutes. The ARP aging time of the host workstations is not significant for
this discussion. but, the example sets the ARP aging time to four hours.

http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a00800
94afd.shtml

--
BR
Tony
Sent from my iPad
On 18 Jan 2013, at 03:38, Routing Freak <routingfreak_at_gmail.com> wrote:
> Hey
>
> In STP, when u receive a TCN, rom a non root bridge, the other non root
> bridge will send the TCN towards the root port to the Root bridge and when
> the root bridge sets the TC bit to 1 and send the BPDU to all other non
> root bridges,
> When Non root bridges receive this BPDU, they all flush out their MAC
> address on all the ports .
>
> So its now a pretty empty MAC table. Unlike IP ROUTE Table, there is no
> separate MAC exchange protocols  ( Yes BGP can do waterer u say ) , But
> generally ur MAC table will be populated only with the user traffic. So
> initially the unknown unicast flooding will happen for all unknown
> destination MAC address and all the MAC will be learnt from various ports
> and STP reconvergence happens and everything will be set.
>
> There will be initial flooding within the broadcast domain. So STP TCN has
> nothing to do with CAM table learning, it can help to inform Root bridge
> about a topology change ( ie Port going from blocking to forwarding or
> Forwarding to blocking )
> and root bridge informs the other non root bridges to flush the MAC address
> learned on all the ports.
>
> So the user generated traffic will really help u in building the MAC table.
>
> Speaking about ARP in switches, u wont find arp table in a pure L2 switch.
> Switch doesn't generate any ARP Packets, it just switches from one port to
> another.
>
> U can see ARP table in hosts , routers and L3 Switches . ARP will be
> generated by hosts inorder to get to the gateway or to another machine in
> the same domain.
> Routers / L3 switches generate ARP inorder to reach the hosts , when a
> packet comes to the router/L3 switch which is  destined to that particular
> host.
>
> So ARP table and CAM table has nothing to do with each other. But there is
> a scenario where ur L3 Switch will be doing asysmetric forwarding bcoz of
> Aging timer mismatch in ARP and CAM Table
>
> For example, when a frame enter the switch, it checks the CAM table, if
> there is any entry it will forward it,
> If the packet is destined to routing engine, it goes to ROute table and
> checks that route is installed in the table and we can send this packet out
> this interface. So to send this outside, we need L2 address to fill up. In
> that case it will check the ARP table and then fill up the L2 address .
>
> When there is no traffic sent for a while, ur CAM table will first age out
> in the Switch and it will do a unknown unicast flood and ur ARP table still
> holds the MAC info. Now inorder to avoid this discrepancy, when designing
> MAC and ARP table aging timers should be set higher for CAM and bit lower
> for ARP. So ARP will poll always and fill up the MAC table in order to
> avoid unknown unicast flooding
>
> Hope this helps
>
>
>
>
> On Mon, Jan 14, 2013 at 4:20 PM, ramesh Kumar
> <rameshkumar123321_at_yahoo.com>wrote:
>
>> I have 2 switches connected back to back on port-channel 1. As per my
>> understanding after any STP change, I should see CAM table update and
>> shortly
>> after that ARP table update. I see the ARP being refreshed but it looks
>> like
>> the CAM table on SW2 didnt update.
>>
>>
>> SW1# sh ip arp | i 34a8.4eb6.0aa2
>> 172.20.210.38   00:01:10  34a8.4eb6.0aa2  Vlan2010
>>
>>
>> SW1# sh mac add
>> dy | i 34a8.4eb6.0aa2
>> * 2010     34a8.4eb6.0aa2    dynamic   0          F
>> F  Eth1/9---> aging time 0 shows that we are getting traffic hitting this
>> entry continuously. Right?
>>
>>
>> SW2# sh ip arp | i 34a8.4eb6.0aa2
>> 172.20.210.38
>> 00:01:14  34a8.4eb6.0aa2  Vlan2010
>>
>>
>> SW2# sh mac add dy | i
>> 34a8.4eb6.0aa2
>> * 2010     34a8.4eb6.0aa2    dynamic   120         F    F
>> Po1----> it seems the CAM timer didn't reset after TCN but the ARP
>> refreshed
>> The link between the switches are configured like this and these switches
>> are
>> running HSRP for all the vlans with SW1 being STP root and HSRP primary
for
>> all the vlans
>>
>>
>> interface port-channel1
>>  switchport
>>  switchport mode trunk
>>
>> switchport trunk allowed vlan 2,650,660,720,730,790,1920,1930
>>  switchport
>> trunk allowed vlan add 1640,1960,1910,1930,1490,2000,2010
>>  spanning-tree
>> link-type point-to-point
>>  mtu 9216
>>  load-interval counter 1 60
>>
>>
>> For arp
>> there is a command "show ip arp internal event-history" which can show if
>> the
>> arp was refreshed due to a TCN or not. which command can help in checking
>> if
>> mac table was refreshed due to TCN or not apart from show mac address
>> table?
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>>
>>
>>
>>
>>
>>
>>
>>
>
>
> --
> Regards
> Routing Freak CCIE#35889 (SPv3)
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
Blogs and organic groups at http://www.ccie.net