In the event of the MTU setting not showing up, that means it's set for the default setting 1514. Sometimes it shows up when it's set for default, sometimes it doesn't. It varies from code to code and on different platforms.
On 3/28/07, STEVE KNAPP <SKNAPP@salliemae.com> wrote:
Does anyone know if there is a different command on an ISG-2000? When I run 'get envar' the MTU size is not returned.
spefwfi100(M)-> get envar
default_image=nsISG2000.5.0.0r8.2
run_image=default (nsISG2000.5.0.0r8.2)
loader_version=1.1.5
last_reset=2006-12-20 21:46:47 by admin
.hash-seg=11 (507713657)
sme=
Steve Knapp Sr. Data Network Engineer Sallie Mae 11100 USA Parkway Fishers, IN 46038 Tel: 317-578-6799 Cell: 317-847-9221 Fax: 317-595-1494 >>> "Tim Eberhard" <
xmin0s@gmail.com> 3/27/2007 2:58 PM >>>
Marc,
The MTU setting is a system wide configuration. To view this use the "get envar" command.
netscreen(M)-> get envar
> redirect output show resource variable
| match output
netscreen(M)-> get envar
default_image=ns5000.5.0.0
run_image=default (ns5000.5.0.0)
loader_version=1.0.0
last_reset=2006-11-11 13:44:12 by netscreen
max-frame-size=9830
The example above is a jumbo configuration. Normally the max-frame size should be 1514. To adjust the MTU you use the following command:
set envar max-frame-size=1514
That would change this to 1514. If you want to go smaller..that is how you would do it.
Good luck!
Tim Eberhard
On 3/27/07, Marc Haber <mh+qorbit-nn@zugschlus.de
> wrote:
On Tue, Mar 27, 2007 at 06:53:39AM -0800, Matt Florido wrote:
> * Marc Haber <
mh+qorbit-nn@zugschlus.de> [03-23-2007 19:18]:
> > (2) How can I for testing purposes reduce the MTU the NSR client uses
> > for data sent into the VPN tunnel? Setting the appropriate registry
> > key on the virtual ethernet adapter does not work; the setting is
> > simply igored (verified by ping with a big request packet)
>
> Try setting the MTU setting on the network adapter itself instead
> of the virtual adapter for NSR.
This does not help since the Tunnel's MTU is always smaller than the
MTU of the physical network.
> > (3) Why do such MTU issues only surface with one application?
> > Everything else seems to be just fine.
>
> You have only found it in one application, but I've found the issue
> manifests itself when applications like using max packet sizes.
Both E-Mail (Exchange, Outlook, *blech*) and network shares work fine
even when data sizes well beyond the network MTU are in use.
> Here's something to try. Adjust the TCP MSS settings on your NS5GT.
>
> set flow tcp-mss xxx (1300 is a good number to test with)
> set flow all-tcp-mss xxx (1400)
This seems to work fine:
ns5gt-> get config | include mss
set flow tcp-mss 1100
set flow all-tcp-mss 1200
ns5gt-> exit
19:17:04.306354 IP 10.2.90.51.1299 > 10.1.2.92.10000: S 1765254697:1765254697(0) win 16384 <mss 1200,nop,nop,sackOK>
19:17:04.306590 IP 10.1.2.92.10000 > 10.2.90.51.1299: S 3882353262:3882353262(0) ack 1765254698 win 5840 <mss 1460,nop,nop,sackOK>
19:17:04.308102 IP 10.2.90.51.1299 > 10.1.2.92.10000: . ack 1 win 16500
19:17:04.317237 IP 10.2.90.51.1299 > 10.1.2.92.10000: . 1:1101(1100) ack 1 win 16500
19:17:04.317653 IP 10.1.2.92.10000 > 10.2.90.51.1299
: . ack 1101 win 7700
19:17:04.318235 IP 10.2.90.51.1299 > 10.1.2.92.10000: . 1101:2201(1100) ack 1 win 16500
19:17:04.318651 IP 10.1.2.92.10000 > 10.2.90.51.1299: . ack 2201 win 9900
19:17:04.320681 IP 10.2.90.51.1299
> 10.1.2.92.10000: . 2201:3301(1100) ack 1 win 16500
19:17:04.321095 IP 10.1.2.92.10000 > 10.2.90.51.1299: . ack 3301 win 12100
19:17:04.323427 IP 10.2.90.51.1299 > 10.1.2.92.10000: . 3301:4401(1100) ack 1 win 16500
19:17:04.323530 IP 10.2.90.51.1299 > 10.1.2.92.10000: . 4401:5501(1100) ack 1 win 16500
19:17:04.323628 IP 10.2.90.51.1299 > 10.1.2.92.10000: . 5501:6601(1100) ack 1 win 16500
(
10.2.90.51 is the virtual IP of the client, 10.1.2.92 the address of
the "test server").
However, Microsoft Office Communicator still refuses to work:
19:19:31.693440 IP 10.2.90.51.1324 > 10.1.2.15.5060: S 214820639:214820639(0) win 16384 <mss 1200,nop,nop,sackOK>
19:19:31.693576 IP 10.1.2.15.5060 > 10.2.90.51.1324: S 2055039840:2055039840(0) ack 214820640 win 16384 <mss 1460,nop,nop,sackOK>
19:19:31.695100 IP 10.2.90.51.1324 > 10.1.2.15.5060: . ack 1 win 16500
19:19:31.695456 IP 10.1.2.15.5060 > 10.2.90.51.1301: R 3947954180:3947954180(0) ack 3726277644 win 0
19:19:31.751359 IP 10.2.90.51.1324
> 10.1.2.15.5060: P 1:660(659) ack 1 win 16500
19:19:31.751748 IP 10.1.2.15.5060 > 10.2.90.51.1324: P 1:561(560) ack 660 win 64876
19:19:34.706224 IP 10.1.2.15.5060 > 10.2.90.51.1324: P 1:561(560) ack 660 win 64876
19:19:34.710886 IP 10.2.90.51.1324 > 10.1.2.15.5060: . ack 561 win 15940
(10.1.2.15 is the MOC Server)
When I compare the session setup when the client is not connecting
over the VPN to this, I see that the VPN connect stalls when the
non-VPN connect begins transmitting datagrams of like 1360 bytes in
size.
Any more ideas?
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835
_______________________________________________
nn mailing list
nn@qorbit.net
http://qorbit.net/mailman/listinfo/nn
This E-Mail has been scanned for viruses.
_______________________________________________
nn mailing list
nn@qorbit.net
http://qorbit.net/mailman/listinfo/nn
_______________________________________________
nn mailing list
nn@qorbit.net
http://qorbit.net/mailman/listinfo/nn
|