[j-nsp] Rate selectability on MPC7E-MRATE

[Joe Horton]

First, I would like to clarify that yes you can provision up to 240G of capacity per PFE/PIC on the MPC7.
It can be any combination of 100/40/10, just as long as the total doesn't go over 240, noting that only certain ports are 100G capable.

Second, to Tobias' comments, yes that is a good suggestion and I'll pass it on internally.

Also, while I haven't explicitly tested this, and I'll try if I can get lab access and have some cycles, in my prior experience, changing the chassis portion of the configuration doesn't change anything until you restart the PIC.
Of course, if someone also changes the "interfaces" stanza that new config would be attempted but fail.  But changing the chassis portion alone won't "kill" an active port, at least not without a reset.  So some heavy annotations in that portion of the configuration are probably a good idea on a large team.
Second, inserting an optic doesn't do anything either, in face the optics basically won't work until you get the chassis portion of the config to match (ran into that myself in early testing prior to learning you have to reset the PIC)
So operationally you are pretty safe from someone unexpected installing an optic.

Joe

On 5/6/20, 12:42 PM, "juniper-nsp on behalf of Tobias Heister" <juniper-nsp-bounces at puck.nether.net on behalf of lists at tobias-heister.de> wrote:

    [External Email. Be cautious of content]


    Hi,

    On 06.05.2020 18:03, Chris Wopat wrote:
    > On Wed, May 6, 2020 at 9:41 AM Brian Johnson <brian.johnson at netgeek.us> wrote:
    >>
    >> So you have a 4x10G breakout and a 100G QSFP28 in the same group of 3 interfaces and they are all working? Just because I can install and configure the optics, doesn’t mean they will function. This would conflict with what is coming from Juniper Product teams.
    >>
    >> To be clear, I realize that the ports do not “disappear” because you insert the QSP28 into the port group, just that they will not work. :)
    >
    > We've been this with MPC7s, works fine. You can squeeze the 240g out
    > of each PIC just fine, you simply cannot oversub.
    >
    >      fpc 7 {
    >          pic 0 {
    >              port 2 {
    >                  speed 100g;
    >              }
    >              port 4 {
    >                  speed 10g;
    >              }
    >              port 5 {
    >                  speed 100g;
    >              }
    >          }
    >      }
    >
    > ports 4 and 5 in same 'group of 3', et-7/05 up at 100g and
    > xe-7/0/4:[0-3] up at 10g.

    I always wondered whether there is an explicit knob to disable a port in order to prevent accidental wrong configs or transceivers inserts down the road. Of course you can annotate the existing ports or the pic, but besides that. Also what happens if somebody plugs in a transceiver into any of the remaining ports? Will the setup just fall apart?

    You have 6 Ports per PFE and if you do 100GE on two of them you will end up with something similar to the above config (you can choose whether to do 40 or 10GE on one of the ports).  Which leaves three interfaces unconfigured or not listed in the config. In fact whenever one port is configured to 100G you will "loose" at least one of the ports and have to leave it not listed in config for things to work.

    If at some point in the future somebody configures any of the remaining ports for an invalid  speed it will not work. Even worse default mode for MPC7E-MRATE is to fallback to 10GE Mode on all ports on invalid config which could kill your 100GE production ports. Luckily you have to bounce the PFE for speed changes, which could be even worse if your wrong config hits you during your next reboot if you do not mind the alarms ;)

    "If rate selectability is not configured or if invalid port speeds are configured, each port operates as four 10-Gigabit Ethernet interface"
    "When you change an existing port speed configuration at the port level, you must reset the MPC7E-MRATE PIC for the configuration to take effect. An alarm is generated indicating the change in port speed configuration."

    https://www.juniper.net/documentation/en_US/junos/topics/topic-map/rate-selectability-configuring.html

    So it would be great to have a config option to explicitly disable specific ports and not just leave them unconfigured. Of course you can also misconfigure any of the disabled ports into a unsupported speed combo, but it would be a bit more visible that they are disabled by intention.

    You probably could configure all ports and literally "deactivate" the configs that you do not want to be enabled and annotate that, but it feels a bit clunky.

    Especially on boxes like MX204 and MX10003 we would always explicitly configure the ports into a valid config combination to prevent somebody from putting in transceivers and the box trying to be smart and mess up your ports. I think you cannot easily do that on the MPC7

    --
    Kind Regards
    Tobias Heister
    _______________________________________________
    juniper-nsp mailing list juniper-nsp at puck.nether.net
    https://urldefense.com/v3/__https://puck.nether.net/mailman/listinfo/juniper-nsp__;!!NEt6yMaO-gk!Vjrpfyr8jbKuGTooxsyfhg9eTqR_YsZ-jwlIJL4blDspCKcRG6tSTY19nASybahv$


Juniper Business Use Only