For step 3, it depends whether the link between core 1 and core 2 is a routed link or a trunk (ISL or 802.1Q) link. If its a routed link (such as VLAN 3, with all VLANs running OSPF), core 1 will route the packet to core 2 and core 2 will route the packet to client 2.
For step 4, client 2 will not ARP for client 1. Since client 1 and client 2 are on different VLANs, client 2 will ARP for its default gateway - core 2. When core 2 receives the packet it will send it via core 1. Again, depending on whether this is a routed or trunked link will dictate exactly how this packet is sent from core 2 to core 1. Anytime a router (MSFC) needs to forward a packet to a client, if it does not have an ARP entry, it will ARP for the client. If a switch ages a MAC address out from its CAM table, it will flood (to all ports on the VLAN) the very first frame that has a destination of the "unknown" MAC address. Due to the flooding, the frame will reach the correct destination. Once that station replies with the very first packet, the CAM table will be updated and no more flooding will occur. Hope that helps - Rob. CCIE 6922 ""z z"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Hi > > One interesting scenario here. Two core switches (with > MSFC) running HSRP. Core 1 is the master for vlan 1, > and core 2 is the master for vlan 2. Understand MSFC > arp timer is 4 hours, but switch CAM timer is 300 > seconds. So there will be one problem: > > > 1. Client 1 (vlan 1) wants to talk to client 2 > (vlan2). It will send one frame to client 2 using Core > 1s mac address as the destination mac, because Core 1 > is its gw. > 2. Core 1 will check its routing table and forward the > packet to client 2. Meantime, it will change the > frames source mac address to its own mac and the des > mac to client 2s mac address. > 3. Core 2 will just simply switch the frame to client > 2, because core 1 has done the routing. To core 2, its > arp table and aft table wont contains client 1s mac > address so far, since core 1 has translated the > frames source mac address. > 4. When client 2 wants to reply, it will send the > replying packets to core 2. Core 2 will arp for client > 1s mac address. When client 1 reply this arp request, > core 2 will add its mac address to both its arp table > and aft table. > 5. this is working fine so far. > 6. after 300 seconds, core 2s aft table time out. > However its arp table is still valid, so it wont do > any more arp request. When client 2 wants to talk to > client 1, core 2 will do the routing correctly, but > then flood the frames to all the switch ports. > > Is my theory correct? > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Sports - live college hoops coverage > http://sports.yahoo.com/ Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=38701&t=38635 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
