Switching

last person joined: yesterday 

Ask questions and share experiences about EX and QFX portfolios and all switching solutions across your data center, campus, and branch locations.
  • 1.  QSFP port not coming up on QFX5100

    Posted 06-02-2020 05:39

    Hello,

    I wonder if someone can help. We have QFX5100 switches in a virtual chassis configuration. I am trying to use "QSFPP-4X10GE-LR" transceiver Module to channelise using "MTP to 4 LC" cable. Issue I am having is that if I plug the transceiver module to a port in one switch the port comes up but if I plug the same transceiver module to a port in a separate switch in the same Virtual Chassis the port doesn't come up. Auto-channelisation is not disabled on the the port.

     

    On the switch the port where the port is coming up it correctly shows the port as one of the "xe" ports being up

     

    show interfaces terse | match 2/0/50
    xe-2/0/50:0             up    up
    xe-2/0/50:1             up    down
    xe-2/0/50:2             up    down
    xe-2/0/50:3             up    down
    xe-2/0/50:3.0           up    down eth-switch

    But on the switch the port doesn't come up it still shows an the port as "et" and down

     

    show interfaces terse | match 1/0/52
    et-1/0/52               up    down
    et-1/0/52.16386         up    down

     

    Once I unplug the trensceiver the et-1/0/52 disappears from the output of "show interfaces terse" command.

     

    The command "show log chassisd" shows that it has identified the transceiver

     

    Jun  2 10:38:59  pic_copy_port_info:Got cable_type for FPC 1 PIC 0 port 52 cable num=140, str=4X10GBASE LR
    Jun  2 10:38:59  pic_copy_port_info:Got SFP Rev=REV 01, Pno=740-054050, Sno=G1908028201
    Jun  2 10:38:59  notify_sfp_add: NULL kvpairs for PIC 0
    Jun  2 10:38:59  create_pic_entry: pic i2c 0xf0b0, hw qs 12 supported qs 12, flags 0x0, pic port 52, speed 40000000000
    Jun  2 10:38:59  ch_fru_db_key DB key pic_slot 0 is_mod_pic 0 lc_supports_mod_pic 0
    
    Jun  2 10:38:59  et-1/0/52 ifm_channel: 0x0, ifm_fe = 0, local_dev_id:0, global_dev_id:1, port_num:65
    Jun  2 10:38:59  capability: et-1/0/52, cap flag = 43136, media: 2 porttype 184
    Jun  2 10:38:59  ifdev_create entered et-1/0/52
    Jun  2 10:38:59  et-1/0/52: large delay buffer cleared
    Jun  2 10:38:59  fpc_is_synce_cap: FPC i2c: 0xbda, PIC type: 0xf0b0
    
    Jun  2 10:38:59  pic_update_ifdev_tlvs: et-1/0/52 Not SyncE capable
    
    Jun  2 10:38:59  pic_update_ifdev_tlvs: et-1/0/52 IFM type is Ether, SyncE TLV is added

    Similarly "show chassis hardware" displays to correct transceiver plugged in

     

    FPC 1            REV 14       QFX5100-48T-6Q
      CPU                         FPC CPU
      PIC 0                       48x10GBaseT-6x40G
        Xcvr 48      REV 01       QSFP+-40G-CU5M
        Xcvr 49      REV 01       QSFP+-40G-CU3M
        Xcvr 52      REV 01       QSFP+-4X10G-LR

    (Xcvr 52 is where the transceiver is plugged in)

     

    Any help with that will be really appriciated. 

     

    Thanks



  • 2.  RE: QSFP port not coming up on QFX5100
    Best Answer

     
    Posted 06-02-2020 05:51

    Hi jam,

     

    it seems that the ports are differently configured, 2/0/50 is configured as 4x10G channelized, et-1/0/52 as a 40G port. To make 1/0/52 to a 4x10G channelized port as well, you have to configure the following, after this it should work:

     

    set chassis fpc 1 pic 0 port 52 channel-speed 10g



  • 3.  RE: QSFP port not coming up on QFX5100

    Posted 06-02-2020 06:43

    Thanks F1ght3r

     

    That did fix the issue. Interesting that without any configuration on the switch one port decides to correctly channelize into 10g links and the other doesn't and you have to configure it.



  • 4.  RE: QSFP port not coming up on QFX5100

     
    Posted 06-02-2020 06:49

    You're welcome.

     

    I've observed the same that the automatic decision if this is 40G or 4x10G does not work, this changes even after device reboots, which is not funny.

    It is always a best practice to configure such settings fixed, to minimize problematic behavior.