|
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.
|