<div dir="ltr"><div>Hi JK,</div>
<div>      Here is the response as per my understanding of the network. I can share excerpts from the configuration if you deem them necessary </div>
<div> </div>
<div>1. VE on the access FCX acts as the GW. No bridging.</div>
<div>2. Uplinks are in default vlans. In some cases the uplinks are multiple links to distribution running ECMP and in some the uplinks have been bundled using LACP</div>
<div>3. The distribution is route-only globally</div>
<div>4. We have MSTP on all the vlans on the Edge while no STP on distribution as these are L3.</div>
<div>5. I suppose so. But anything you want me to specifically look into?</div>
<div>6. It is PIM-SM</div>
<div> </div>
<div>BR<br>Salman<br><br></div>
<div class="gmail_quote">On Mon, Nov 11, 2013 at 10:25 AM, Kennedy, Joseph <span dir="ltr"><<a href="mailto:Joseph.Kennedy@purchase.edu" target="_blank">Joseph.Kennedy@purchase.edu</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote">Salman,<br><br>It’s difficult to say without seeing the configurations so pardon me if I ask some silly questions.<br>
<br>1. Gateway exists in VE on the edge FCX in ALL cases or are you bridging a few vlans where necessary(hybrid) in distribution? RSTP on edge vlans?<br>2. If you’re totally L3 to the edge are you leaving uplinks in the default vlan and marking them route-only, creating two separate vlans and leaving one uplink untagged in each, or tagged between distribution and edge in case you have to bridge later?(I’m assuming you aren’t using route-only globally on the edge and you only uplink each edge switch to distribution by two uplinks, but please correct me if I’m off the mark).<br>
3. Is your distribution layer set to route-only globally or on an interface basis(hybrid edge of course precludes globally)?<br>4. Have you enabled or disabled global-stp on your distribution and edge switches?<br>5. Can you confirm that ECMP is working as expected between each of the tiers?<br>
6. Do you run PIM and if so are you running SM or DM?<br><br><br>--JK<br>
<div class="HOEnZb">
<div class="h5"><br>On Nov 7, 2013, at 10:48 AM, salman sadiq <<a href="mailto:salmanravian@gmail.com">salmanravian@gmail.com</a>> wrote:<br><br>> Dear Experts,<br>>              We have a huge Brocade infrastructure deployed in a very hierarchical manner. The core devices (4 fully meshed) are MLX-32s, distribution (FCX,SXR) and access (mostly FCX). Access layer acts as the GW for the end clients and OSPF takes care of all the routing. We have seen a lot of connectivity issues in the network where an end client loses connectivity to the network, ie the client remains connected but cannot access anything. In some cases we have seen one-way voice issues as well. All looks good on the switches but there are repeated instances of problematic connectivity. The arp entry is always there. I've looked at the tcam mapping for some cases and it looks good too. The problem is always resolved by a "clear arp" either on the access switch or in some cases on the distribution device.<br>
><br>> Problem with the ARP is so fundamental in nature that I find it hard to swallow considering the fact that Brocade has a large customer base. TAC has been trying to root cause the problem but with no success at all. Has anyone else seen such issues? In our network we have to deal with such cases almost on daily basis.<br>
><br>> MLX is 5.4d<br>> FCX is 7202d and 7.4d<br>><br>> Thank you.<br>> Salman<br></div></div>
<div class="HOEnZb">
<div class="h5">> _______________________________________________<br>> foundry-nsp mailing list<br>> <a href="mailto:foundry-nsp@puck.nether.net">foundry-nsp@puck.nether.net</a><br>> <a href="http://puck.nether.net/mailman/listinfo/foundry-nsp" target="_blank">http://puck.nether.net/mailman/listinfo/foundry-nsp</a><br>
<br></div></div></blockquote></div><br></div>