Here it is:
http://rapidshare.com/files/439826677/6k_7k.jpg
Regards
On Wed, Dec 29, 2010 at 12:56 AM, Paul Cocker <paul.cocker_at_gmx.com> wrote:
> can you upload a visio somewhere so we can have a look?
>
> On 28/12/2010 23:43, Ivan Hrvatska wrote:
>>
>> I figured it out. The problem is in fact that arp timeout is 4 hours and
>> mac
>> aging time is 6 minutes on 6k switches. Doesn't have anything to do with
>> asa. Two 6k switches are connected with two wan routers with 4 p2p L3
>> links
>> and between them is ospf. So, when first packet comes from wan cloud 6k1
>> looks at routing table and sees that destination host is on directly
>> connected network. It sends arp and it gets respons that host is in vlanif
>> 514. Mac table also learns that host's mac is in interface between 6k1 and
>> 6k2. Since 6k2 has p2p L3 link with primary Wan router, packet from S to H
>> never goes back to 6k1. After 6 min 6k1 removes entry from mac table but
>> arp
>> entry remains. When next packet from H to S comes to 6k1, it doesn't know
>> on
>> which port to send frame, so it floods on all ports in vlan 514.
>> So, now I'm considering option to have only 6k1 as active hsrp gw and root
>> bridge for all vlans. Right now I have half vlans active on 6k1 and other
>> half on 6k2. Also, to configure arp timeout 2 hours and mac aging little
>> bit
>> less than 2 hours. Also, on p2p L3 links between 6k and wan routers to
>> configure cost so that traffic takes only one path. It seems littlr bit
>> hard
>> to follow flow of the traffic with ospf load balancing and load balancing
>> at
>> layer 2.
>> What do you think?
>>
>> On Dec 28, 2010 9:58 PM, "Vijay Shekhar"<v.shekhar_at_globalassurance.net>
>> wrote:
>>>
>>> I am a bit confused by your statement. May be its just me.
>>>
>>> You mentioned that 6k1 - 6k2 and 2960 are in L2 domain, and you also
>>> mention that 6k2 should do interval Routing. There are contradictory.
>>>
>>> If 6k2 is indeed doing interval routing then 6k1 will see the MAC
>>> address of 6k2 SVI to reach "s".
>>>
>>> It would perhaps he helpful if you can list out the VLAN #'s SVI IPs
>>> and S& H IPs.
>>>
>>> Cheers!
>>>
>>> -Vijay Shekhar
>>> CCIE(sec)#17589/CISSP/RHCE.
>>> http://au.linkedin.com/in/vshekhar
>>>
>>>
>>> Quoting Ivan Hrvatska<ivanzghr_at_gmail.com>:
>>>
>>>> Hi,
>>>>
>>>> I have scenario like this:
>>>>
>>>> H---Asa----6k1-----6k2
>>>> ! !
>>>> ! !
>>>> 2960sw
>>>> !
>>>> S
>>>>
>>>> H-host in cloud (172.30.4.5), somewhere in distance network.y
>>>> Asa-running in transparent mode
>>>> Between 6k switches and 2960 is l2 domain (trunks).
>>>> 6k switches running hsrp and 6k2 is active gw for vlans 500 and 514. It
>>
>> is
>>>>
>>>> also root bridge for those vlans. Asa has one IP in vlan 500.
>>>> S is in vlan 514.
>>>> Problem is that 6k1 never learns mac address of S. When traffic comes
>>
>> from H
>>>>
>>>> 6k1 floods network with packets that should go to S. Only time when 6k1
>>>> learns S mac address is when you ping S from 6k1. After 480 sec is aging
>>>> time and mac address is cleared. As I understand 6k1 should forward
>>
>> packets
>>>>
>>>> which has S as destanation to 6k2 as it is active gw for vlan 500 and
>>
>> then
>>>>
>>>> 6k2 should perform intervlan routing. Why flooding happens? Could asa
>>
>> make
>>>>
>>>> some problems cause of transparent mode?
>>>>
>>>> Regards
>>>>
>>>>
>>>> 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
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>
>
> 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
Received on Wed Dec 29 2010 - 17:08:49 ART
This archive was generated by hypermail 2.2.0 : Sat Jan 01 2011 - 09:37:50 ART