Effect of MRU setting on EX Switch

MRU (Maximum Receive Unit) has a close relation to MTU but as far as I can see it has different effects in various active devices.
For example setting an MTU value of 1000 on an Ethernet interface of a Linux machine or an SRX box doesn’t prevent the larger packet from being accepted. However if the very same interface tries to return a similar size packet then it has to be fragmented. However on EX switch I saw something else. Let me explain;

root@ex2200-1> show interfaces ge-0/0/8
Physical interface: ge-0/0/8, Enabled, Physical link is Down
  Interface index: 138, SNMP ifIndex: 520
  Link-level type: Ethernet, MTU: 900, Speed: Auto, Duplex: Auto, BPDU Error: None, MAC-REWRITE Error: None, Loopback: Disabled, Source filtering: Disabled,
  Flow control: Enabled, Auto-negotiation: Enabled, Remote fault: Online
  Device flags   : Present Running Down
  Interface flags: Hardware-Down SNMP-Traps Internal: 0x4000
  Link flags     : None
  CoS queues     : 8 supported, 8 maximum usable queues
  Current address: a8:d0:e5:b3:99:cb, Hardware address: a8:d0:e5:b3:99:cb
  Last flapped   : 2012-12-26 14:04:45 CET (00:03:06 ago)
  Input rate     : 0 bps (0 pps)
  Output rate    : 0 bps (0 pps)
  Active alarms  : LINK
  Active defects : LINK
  Interface transmit statistics: Disabled

  Logical interface ge-0/0/8.0 (Index 87) (SNMP ifIndex 523)
    Flags: Device-Down SNMP-Traps 0x4000 Encapsulation: ENET2
    Input packets : 1
    Output packets: 16
    Protocol eth-switch
      Flags: None

I connected two PCs to my ex2200 test switch’s ge-0/0/8 and 9 port and assigned to the same vlan. Then I pinged from the PC connected to the port 8 to PC on 9. port with size 1000bytes and it worked. Then I set the interface MTU of port 8 to 900bytes and checked the MRU value.

% lcdd_cmd -f fpc0 -d chassism -c "show mac ge-0/0/8"
chassism<0>#show mac ge-0/0/8
MAC Layer Information
devNum:0, portNum:9
MAC Control Reg0:   0x00008719     Port Enable  YES
                                   Port Type    SGMII
                                   MRU          908
MAC Control Reg1:   0x00000481
MAC Control Reg2:   0x0000c009     InBand Autoneg Mode  SGMII
MAC Control Reg3:   0x00000300     Combo Mode  0
Auto-Neg Config Reg:0x0000b1f4     Link Config   DONT FORCE LINK UP
                                                 DONT FORCE LINK DOWN
                                   Duplex        ENABLE AN
                                   Speed         ENABLE AN
                                   Flow Control  DISABLE AN
                                                 ENABLE FC
                                   Pause Adv     DISABLE
                                   Bypass        DISABLE
                                   InBand AN     ENABLE
MAC Status Reg0:    0x0000e802     InBand Autoneg Bypass  NOT ACTIVATED
                                   AnDone  DONE
                                   Duplex  HALF
                                   Speed   1000
                                   Link    DOWN
MAC Status Reg1:    0x00000000

As it can be seen MRU is 908 since Junos adds 8 bytes to calculate this value. After this setting I again tried to send a ping with 1000 size but no success. Here is the point because it is a switch and also it is MRU but not MTU your sender won’t get notified by any ICMP message even if you have PMTU discovery is turned on. You can literally beat the air if you have a small MRU setting on the switch this is my humble opinion:)

Tags: , ,

About: rtoodtoo

Worked for more than 10 years as a Network/Support Engineer and also interested in Python, Linux, Security and SD-WAN // JNCIE-SEC #223 / RHCE / PCNSE

One thought on “Effect of MRU setting on EX Switch”

  1. Great article! Thank you!
    So it seems this issue exists only when both hosts are on the same VLAN right? As far as I can understand if there is router/fw between them it will reply with ICMP message and the source will fragment the packet.

You have a feedback?

Discover more from RtoDto.net

Subscribe now to keep reading and get access to the full archive.

Continue reading