Main Contents

Juniper ex4200 trouble

September 11, 2009

The other day I encountered a problem where the Juniper switch I was working on would no longer allow servers to connect the SAN disk attached to it through the switch. Soft-rebooting of the switch didn’t correct the problem. Instead what it did was allow the servers to see the disk and then it would disappear only to come back again in a yo-yo pattern. 

Opening a ticket with tech support they pulled the revision of code running on the switch which was ver 9.2.R2.15. The tech noted there were some problems with this version of code and needed to confirm. He ran the following console commands through an ssh connection.

- cli

-start shell

-vty fpc0  — that is a zero on the end

- show shim register 0×03000040

This produced the following results:

bit number—->  |3 3 2 2 |2 2 2 2 |2 2 2 2 |1 1 1 1 |1 1 1 1 |1 1 0 0 |0 0 0 0 |0 0 0 0

dev     reg: value   |1 0 9 8 |7 6 5 4 |3 2 1 0 |9 8 7 6 |5 4 3 2 |1 0 9 8 |7 6 5 4 |3 2 1 0

0   3000040: 0       |0 0 0 0 |0 0 0 0 |1 0 0 0 |0 0 0 0 |0 0 0 0 |0 0 0 0 |0 0 0 0 |0 0 0 0
1   3000040: 0       |0 0 0 0 |0 0 0 0 |0 0 1 0 |0 0 0 0 |0 0 0 0 |0 0 0 0 |0 0 0 0 |0 0 0 0
2   3000040: 0       |0 0 0 0 |0 0 0 0 |1 0 0 0 |0 0 0 0 |0 0 0 0 |0 0 0 0 |0 0 0 0 |0 0 0 0

The results of this register confirmed his suspicions. He said in the register all items in section 0,1,2 should be zero, which means it is properly handling data passing through it. In this case you have a few "1"’s which means there is corruption and the switch will not work correctly until the code is upgraded to a minimal of version 9.3R4. He also pointed to PSN-2008-12-116 which outlines some of the issues. This PSN is posted below:

After patching was complete all the systems became stable and able to see the disk correctly. We reran the previous command confirming the patch was successful by see all zeros in the register. See the results below.

bit number—->  |3 3 2 2 |2 2 2 2 |2 2 2 2 |1 1 1 1 |1 1 1 1 |1 1 0 0 |0 0 0 0 |0 0 0 0 dev     reg: value   |1 0 9 8 |7 6 5 4 |3 2 1 0 |9 8 7 6 |5 4 3 2 |1 0 9 8 |7 6 5 4 |3 2 1 0

0   3000040: 0       |0 0 0 0 |0 0 0 0 |0 0 0 0 |0 0 0 0 |0 0 0 0 |0 0 0 0 |0 0 0 0 |0 0 0 0
1   3000040: 0       |0 0 0 0 |0 0 0 0 |0 0 0 0 |0 0 0 0 |0 0 0 0 |0 0 0 0 |0 0 0 0 |0 0 0 0
2   3000040: 0       |0 0 0 0 |0 0 0 0 |0 0 0 0 |0 0 0 0 |0 0 0 0 |0 0 0 0 |0 0 0 0 |0 0 0 0

Title
Service Impacting Issues in JUNOS 9.2 Software for EX-Series Switches

Products Affected
EX-Series Switch Platforms Running JUNOS 9.2R2.15 and older are affected

Platforms Affected

  • EX-series

    Revision Number
    1

    PSN Issue :

    On-going testing and customer feedback has identified critical issues with JUNOS 9.2 Software for EX-Series Switches that may impede normal operation of the switch. Solution:

    All JUNOS software built on or after November 26, 2008, have been modified to correct the above issues.

    • PR 314088  Slot 0 interfaces disappeared on virtual chassis due to internal vcp port stuck in TXQ.
    • PR 388285  VC Member looses Membership in the VC under certain conditions.
    • PR 390667  (VRRP) Virtual IP next-hop not being added to PFE.
    • PR 393895  When a trunk interface is configured as tagged as well as native-vlan for a particular vlan and then native-vlan is deleted, the interface continues to send as untagged.
    • PR 397035  eswd core@task_quit, task_terminate, task_signal_kevent after gres and related testing.
    • PR 397054  Stack split after rebooting a member of virtual chassis.
    • PR 399213  Invalid Next Hop entries in Ethernet-switching table.
    • PR 399887  Performing a reboot on a linecard in a virtual chassis may result in a 12-15 second packet loss.

    • Filed under: Junos, Switches | Comments (0)

    Leave a comment

    «