[j-nsp] Topology failure on EX4200
jjones at danrj.com
Sun Jul 16 16:35:55 EDT 2017
VC can be configured on any optical port, not jsut the dedicated on the rear.
On Jul 16, 2017, at 10:17 AM, Victor Sudakov <vas at mpeks.tomsk.su> wrote:
Roger Wiklund wrote:
>> There is a ring of EX4200 switches, please look at http://noc.sibptus.ru/jun1.png
>> If MUX1 fails, the MSTP topology adjusts and the PCs continue to see
>> one another just fine.
>> However, some switches become inaccessible in the management vlan
>> (vlan3 in this example). For example, you can still ping 192.168.1.3
>> from 192.168.1.2, but not 192.168.1.4 from 192.168.1.2.
>> One important note. If MUX1 fails, the corresponding interfaces on
>> 192.168.1.2 and 192.168.1.4 don't go down, it is only the traffic
>> (including BPDUs) that stops flowing through the mux.
>> If I shutdown the corresponding interfaces on 192.168.1.2 and
>> 192.168.1.4 (or use OAM to shutdown the interfaces automatically when
>> the mux fails), the problem disappears and I can ping any switch from
>> any switch.
>> What's the theory behind this?
>> "clear arp" and "clear ethernet-switching table" don't fix the
> Have you configured loop protection?
I have configured OAM (link-down on link-adjacency-loss) which helped.
But I'm wondering why the situation in question was happening without
the interfaces going physically down.
> On a design note, why not use Virtual Chassis instead?
Sorry, I don't understand. Virtual Chassis uses a special short cable,
doesn't it? My switches are not located nearby enough to use that
cable. In fact, they are connected by multiplexers and can be far
away from one another.
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
juniper-nsp mailing list juniper-nsp at puck.nether.net
More information about the juniper-nsp