Yes you are correct. In native this would not be an issue on the 6500. Dave
Larry Letterman wrote: > > I am assuming the switch/msfc is not running native ios.. > > Larry Letterman > Cisco Systems > [EMAIL PROTECTED] > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of > MADMAN > Sent: Monday, March 18, 2002 7:13 AM > To: [EMAIL PROTECTED] > Subject: Re: cisco switches (with MSFC) arp timer question [7:38635] > > Interesting that you brought the differance in the ARP timers up. I > have seen some weird problems in a couple of network, things were not > breaking but would see strange traffic, packets getting dropped etc. > Bumped up the CAM timers on the Cat to match the routers, 14400. > > http://www.cisco.com/warp/public/473/62.shtml#casestudy8 > > This probably doesn't answer your question but it reminded me of the > this issue!! > > Dave > > z z wrote: > > > > 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/ > -- > David Madland > Sr. Network Engineer > CCIE# 2016 > Qwest Communications Int. Inc. > [EMAIL PROTECTED] > 612-664-3367 > > "Emotion should reflect reason not guide it" Larry Letterman wrote: > > I am assuming the switch/msfc is not running native ios.. > > Larry Letterman > Cisco Systems > [EMAIL PROTECTED] > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of > MADMAN > Sent: Monday, March 18, 2002 7:13 AM > To: [EMAIL PROTECTED] > Subject: Re: cisco switches (with MSFC) arp timer question [7:38635] > > Interesting that you brought the differance in the ARP timers up. I > have seen some weird problems in a couple of network, things were not > breaking but would see strange traffic, packets getting dropped etc. > Bumped up the CAM timers on the Cat to match the routers, 14400. > > http://www.cisco.com/warp/public/473/62.shtml#casestudy8 > > This probably doesn't answer your question but it reminded me of the > this issue!! > > Dave > > z z wrote: > > > > 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/ > -- > David Madland > Sr. Network Engineer > CCIE# 2016 > Qwest Communications Int. Inc. > [EMAIL PROTECTED] > 612-664-3367 > > "Emotion should reflect reason not guide it" -- David Madland Sr. Network Engineer CCIE# 2016 Qwest Communications Int. Inc. [EMAIL PROTECTED] 612-664-3367 "Emotion should reflect reason not guide it" Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=38669&t=38635 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
