levcons
asked on
Juniper SSG Ethernet trunk MTU
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!
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!
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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.
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.
ASKER
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.
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.
ASKER
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.