The MIC-MRATE and its derivatives (for example MPC7-MRATE) provide a mechanism called "port profile," which allows operators to select and use different port speeds.
This article details the points that need to be taken into account while using a port profile in your device.
There are three possible modes of operation:
The default mode
This mode is active when there is no explicit configuration under the chassis/FPC/PIC stanza. All inserted QSFP+ modules operate in the "channelized" (4 x 10G) mode. The system creates interface devices (IFD) for all ports on the MIC, irrespective of the physical presence of QSFP+.
PIC-level port profile
In this mode, all the ports are configured uniformly:
chassis { fpc 0 { pic 0 { pic-mode 10G; } } }
When the above configuration is committed, the MIC is power-cycled (bounced) automatically. Similar to the previous mode, the system creates interface devices (IFD) for all ports on the MIC.
Port-level profile
This is the only mode that allows configuration of ports to operate at different speeds:
chassis { fpc 0 { pic 0 { port 0 { speed 40g; } port 1 { speed 40g; } } } }
The granularity comes with a price, however. The following points need to be kept in mind while operating the MIC in this mode.
A configuration change has to be activated manually.
Every time the speed-related configuration is altered and committed, the changes are not programmed immediately. Instead, the previous port profile is still in use until the MIC is power-cycled (bounced). In other words, an additional action has to be taken to make the changes effective. The system raises a minor alarm as a reminder of the pending action.
user@device> show chassis alarms 1 alarm currently active Alarm time Class Description 2021-07-01 07:20:21 PDT Minor FPC 0 PIC 0 Need bounce
Note: This alarm might hinder other operational activities, for example a primary role switchover.
user@device> request chassis routing-engine master switch warning: Traffic will be interrupted while the PFE is re-initialized Toggle mastership between routing engines ? [yes,no] (no) yes error: FPC0 PIC0 Need bounce
The power cycle can be conducted as follows:
user@device> request chassis mic fpc-slot 0 mic-slot 0 offline fpc 0 mic 0 offline initiated, use "show chassis fpc pic-status 0" to verify user@device> request chassis mic fpc-slot 0 mic-slot 0 online fpc 0 mic 0 online initiated, use "show chassis fpc pic-status 0" to verify
Note: If an erroneous configuration is being committed (for example a port is incapable of operating at the configured speed), the system raises an alarm and continues using the port profile that was active prior to the change.
user@device> show chassis alarms 1 alarm currently active Alarm time Class Description 2021-07-01 07:46:48 PDT Minor FPC 0 PIC 0 Invalid port profile configuration
Only the explicitly configured ports are active.
Only the ports that are specified in the configuration are considered "active". The system creates the corresponding interface devices only for the active ports. Another important aspect is that "inactive" means that detection of a transceiver via I2C is also disabled. A short example follows.
Four QSFP+ are installed in MIC0/0:
user@device> show chassis pic fpc-slot 0 pic-slot 0 FPC slot 0, PIC slot 0 information: Type MRATE-12xQSFPP-XGE-XLGE-CGE State Online PIC version 1.12 Uptime 15 seconds PIC port information: Fiber Xcvr vendor Wave- Xcvr JNPR Port Cable type type Xcvr vendor part number length Firmware Rev 0 40GBASE SR4 MM AVAGO AFBR-79EQPZ-JU1 850 nm 0.0 REV 01 1 40GBASE SR4 MM FINISAR CORP FTL410QE3C-J1 850 nm 0.0 REV 01 10 40GBASE SR4 MM FINISAR CORP FTL410QE4C-J1 850 nm 0.0 REV 01 11 40GBASE SR4 MM AVAGO AFBR-79EQPZ-JU1 850 nm 0.0 REV 01 [snip]
By default, all ports operate at 10G and there are 12x4 = 48 IFDs.
user@device> show interfaces terse | match "^xe-0/0/[0-9]+:[0-3]\ +" | count Count: 48 lines
Now let's convert the first port to 40G.
[edit] + chassis { + fpc 0 { + pic 0 { + port 0 { + speed 40g; + } + } + } + }
When the configuration is committed and the MIC power-cycled, only one IFD is created.
user@device> show interfaces et-0/* terse Interface Admin Link Proto Local Remote et-0/0/0 up down et-0/0/0.16386 up down user@device> show interfaces xe-0/* terse user@device>
The QSFPs located in the inactive ports are not visible anymore.
After the previous configuration change, the QSFPs installed in ports 1, 10 and 11 became "invisible" in the CLI:
user@device> show chassis pic fpc-slot 0 pic-slot 0 FPC slot 0, PIC slot 0 information: Type MRATE-12xQSFPP-XGE-XLGE-CGE State Online PIC version 1.12 Uptime 2 minutes, 45 seconds PIC port information: Fiber Xcvr vendor Wave- Xcvr JNPR Port Cable type type Xcvr vendor part number length Firmware Rev 0 40GBASE SR4 MM AVAGO AFBR-79EQPZ-JU1 850 nm 0.0 REV 01 [snip] user@device> request pfe execute target fpc0 command "show qsfp list" SENT: Ukern command: show qsfp list QSFP Toolkit summary: wakeup count: 273262, debug: 0 thread: 0xdeb47aa0, itable: 0xdeb17740 Index Name State ----- ---- ----- 1 qsfp-0/0/0 Present 2 qsfp-0/0/1 Absent 3 qsfp-0/0/2 Absent 4 qsfp-0/0/3 Absent 5 qsfp-0/0/4 Absent 6 qsfp-0/0/5 Absent 7 qsfp-0/0/6 Absent 8 qsfp-0/0/7 Absent 9 qsfp-0/0/8 Absent 10 qsfp-0/0/9 Absent 11 qsfp-0/0/10 Absent 12 qsfp-0/0/11 Absent
Takeaways and Recommended Best Current Practices
Avoiding the use of a default port profile aids in configuration readability. Explicit port speed configuration eliminates the possibility of unexpected deactivation of ports when a non-default port speed is configured (due to [2]). Postponing a PIC power cycle after a configuration change (for example, until the next Maintenance Window) might not be a good idea. Any unplanned events such as a PIC restart, a crash of the hosting FPC, or an ungraceful primary role switchover might activate the pending changes unexpectedly. Since I2C polling is disabled on inactive ports, the installed QSFPs are not displayed in the CLI. Remember this fact always to avoid unnecessary hardware replacements.
Avoiding the use of a default port profile aids in configuration readability.
Explicit port speed configuration eliminates the possibility of unexpected deactivation of ports when a non-default port speed is configured (due to [2]).
Postponing a PIC power cycle after a configuration change (for example, until the next Maintenance Window) might not be a good idea. Any unplanned events such as a PIC restart, a crash of the hosting FPC, or an ungraceful primary role switchover might activate the pending changes unexpectedly.
Since I2C polling is disabled on inactive ports, the installed QSFPs are not displayed in the CLI. Remember this fact always to avoid unnecessary hardware replacements.