Juniper SSG Ethernet trunk MTU

levcons
levcons used Ask the Experts™
on
The simple question is…  
  Does a Juniper SSG350M support an MTU of 1504 on a trunked Ethernet interface?

Background:

I am working with a cluster of two Juniper SSG350M (Screenos 6.2.0 r3.0) Gateways and having performance issues with upload bandwidth through the ISP.  The SSG350’s each have the standard 4 ethernet ports and no expansion cards.  All 4 ports are in use (Trust, Untrust, DMZ, & HA) and since we have two untrust connections, the untrust interface is configured with two subinterfaces and uses 802.1q vlan tagging.

Both untrust ports on the SSG350’s are connected to  trunk ports on the Cisco 2960.  Then, each ISP is connected to an access port on the Cisco.

The configuration is functional, however, when troubleshooting the upload issues with the ISP, they complained that they had to add MTU and MSS adjustments on their side to make things work.

The interface configuration on the Junipers is:

set interface ethernet0/2.1 mtu 1500
set interface "ethernet0/2.1" tag 100 zone "Untrust"
set interface "ethernet0/2.4" tag 400 zone "Untrust"
set interface ethernet0/2.1 ip x.x.x.x/27
set interface ethernet0/2.1 route
set interface ethernet0/2.4 ip y.y.y.y/24
set interface ethernet0/2.4 route

The intermediate Cisco switch interfaces are:

interface FastEthernet0/1
 description ISP A
 switchport access vlan 400
 switchport mode access
 spanning-tree portfast
!
interface FastEthernet0/10
 description ISP B
 switchport access vlan 100
 switchport mode access
 spanning-tree portfast
!
interface FastEthernet0/13
 description Juniper SSG350 A
 switchport trunk allowed vlan 1,100,200,400
 switchport mode trunk
 spanning-tree portfast
!
interface FastEthernet0/14
 description Juniper SSG350 B
 switchport trunk allowed vlan 1,100,200,400
 switchport mode trunk
 spanning-tree portfast

The ISP shared their interface config from their router:

interface FastEthernet0/1
 description => To public interface of Internet firewall
 ip vrf forwarding internet
 ip address x.x.x.9 255.255.255.248 secondary
 ip address x.x.x.97 255.255.255.224
 no ip redirects
 no ip proxy-arp
 ip mtu 1496
 ip tcp adjust-mss 1456
 load-interval 30
 duplex auto
 speed auto
 service-policy output 15Mbs
!


The ISP is complaining that they shouldn’t have to set the TCP and MSS on their side, but without it, things simply don’t work.  My suspicion is that running the interface on the Juniper SSG’s in 802.1q tagging mode increases the header by 4-bits, which causes issues when all the hosts around it are set with an MTU of 1500.

Is it possible to set the MTU on the Juniper’s 0/2.1 interface to 1504?  Thus accounting for the extra vlan tag bytes and passing untagged 1500-byte packets that are generated on either side of the trunk without an issue?  Or, will screenos accommodate this by simply removing that config line?

Additionally, can I just resolve all of this MTU mismatch with "set flow tcp-mss 1350" and "set flow all-tcp-mss 1400" on the Juniper?

Thanks!
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Top Expert 2014
Commented:
I don't think setting the MTU to 1504 will fix this.  That MTU size should not take into account the VLAN tag, which is added to the size of the Ethernet frame.

Non-jumbo "Ethernet" frame is 1518, when you add the VLAN tag it goes to 1522.  With either of these (non-tagged and tagged) the IP stack works at 1500.  

Unless of course you have the true IEEE standard of Ethernet, in which case there is another 8 bytes of Ethernet information and IP only has 1492 bytes to work with.

What happens if you remove "set interface ethernet0/2.1 mtu 1500".

Author

Commented:
Thanks for the post giltjr.

It turns out that there was a problem with the ISP and their provider.  The ISP was insisting that the SSG was behaving as if the MTU was set at 1496, which required them to set their router at 1496.  When I got on site and was able to capture from the 2960, I confirmed that the Juniper was working properly.

After removing the custom configurations from the ISP's router, we determined that their provider was inappropriately configured for 1496.  I'm now waiting on them to make the change and reboot one of their core routers.
Top Expert 2014

Commented:
Thanks for the points and the update.  Where in the world did they get 1496?  I would understand 1492, but 1496?

Not sure how that would work, unless they were trying to support VLAN tagging in bridge mode on a device that did not understand VLAN tagging.  But I'm not sure that would work.

Author

Commented:
When they dumped the "ip tcp mss-adjust 1456" from their router, they insisted that I was still sending packets with a max length of 1510 (1496 MTU + 14).  I spanned the inbound port and saw normal 1514 length packets, but could not span at the 2960, so I trusted the ISP - my mistake.  

While chasing that down, I found a few posts insisting that Juniper <-> Cisco 802.1q trunks required mismatched MTU configurations.  That *may* have been the case in other versions of screenos / ios, but I'm doubting it.  BTW, these SSG's are running 6.2.0 r3.0.

Once on site, I was able to diagnose from the intermediate switch and confirm that the Juniper was fine all along.  Then, I had the ISP remove the MTU and mss-adjust configs from their router and we were good to their router, but not beyond.

The next step is a metro-ethernet switch, managed by the LEC that the ISP is buying through.  I suspect this is a QinQ issue on their metro-e side of things.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial