TCPIP ifconfig results in an "exceeded byte count quota" message

[Brian Reiter]

4 node cluster, Itanium RX2800s all at OpenVMS 8-4, Update 7 TCPIP 5-7 ECO 3.

From the system accounr the command TCPIP IFCONFIG IE7  gives:

(CATA1)SYSTEM>TCPIP IFCONFIG IE7
IE7: flags=8000c43<UP,BROADCAST,RUNNING,MULTICAST,SIMPLEX,MULTINET>
%SYSTEM-F-EXBYTLM, exceeded byte count quota

The system uses quite a lot of network aliases and will fail from machine to machine depending on the number of aliaes in place on that machine. When the command starts failing the TCPIP$CONFIG command procedure will fail when trying to access the interface information.

I seem to recall a similar problem being listed but for the life of me can't remember the solution. I can easily up the byte count quota

(CATA1)SYSTEM>sho proc/quo

 9-FEB-2015 14:06:38.63   User: SYSTEM           Process ID:   202026D0
                          Node: CATA1            Process name: "_TNA6:"

Process Quotas:
 Account name: SYSTEM
 CPU limit:                      Infinite  Direct I/O limit:      5000
 Buffered I/O byte count quota: 199999808  Buffered I/O limit:    5000
 Timer queue entry quota:            2000  Open file quota:       1000
 Paging file quota:             705024096  Subprocess quota:       100
 Default page fault cluster:           64  AST quota:              498
 Enqueue quota:                      4000  Shared file limit:        0
 Max detached processes:                0  Max active jobs:          0

But I am more concerned that there is another problem lurking somewhere.

cheers

Brian

[John Gillings]

Brian,

   It looks like you have plenty of BYTLM, but it's a somewhat strange quota, so it's worth investigating further. Look at all 3 values:

$ WRITE SYS$OUTPUT F$GETJPI("","ORG_BYTLM")  ! This is your original allocation

$ WRITE SYS$OUTPUT F$GETJPI("","BYTLM")             ! This is your remaining allocation after "permanent" allocations

$ WRITE SYS$OUTPUT F$GETJPI("","BYTCNT")           ! This is what you have to play with

I can't remember which value SHOW PROCESS/QUOTA displays. Remember that you share the allocation with all processes in your job tree. That includes parent, sibling and child processes.

These days you can probably crank up the value (BYTLM in the UAF) a fair bit to see if that helps. It's probably also worth looking at the SYSGEN parameter DEFMBXBUFQUO (the default BYTLM allocated to a mailbox which doesn't specify a quota). If this is set too high, you can deplete your quota very quickly.

[Brian Reiter]

Hi John,

Well the results are:

(CATA1)SYSTEM>WRITE SYS$OUTPUT F$GETJPI("","ORG_BYTLM")
800000000
(CATA1)SYSTEM>WRITE SYS$OUTPUT F$GETJPI("","BYTLM")
799999808
(CATA1)SYSTEM>WRITE SYS$OUTPUT F$GETJPI("","BYTCNT")
799999808
(CATA1)SYSTEM>

At the moment its more an incovenience, but I'm worried that other issues may be lurking.

cheers

Brian

[Brian Reiter]

OK, so using a second terminal session to monitor the quotas etc. of the session issuing the "TCPIP ifconfig -a" command shows no real depletion of the available quotas, a couple of them dip and then recover, but nothing gets remotely near to zero.

Both the "ifconfig -a" and "ifconfig -v" commands return the exceeded byte count quota message. Other commands suach as netstat work as expected. Doing "mc tcpip$ifconfig -a" results in the same error.

The command works as expected on other nodes in the cluster work as expected, the difference being the number of aliases defined on the system.

[Volker Halle]

Brian,

this is most likely a bug in the TCPIP software !

Consider to escalate this problem to HP.

You're not running the most recent available TCPIP V5.7 patch level, so expect to be asked to install ECO 5.

Volker.

[Brian Reiter]

Hi Volker,

Thanks for that. That was the conclusion I was coming to.

cheers

Brian

[Volker Halle]

Brian,

how many aliases do you have defined ? Can you maybe reproduce this problem on some test system with the same or a similar amount of aliases ? Most not even be an I64 system, but should have similar TCPIP version.

Volker.

[Brian Reiter]

Hi Volker,

The error is caused at the creation of the 44th alias. Up to that point I can view them all. The aliases are split amoung the various pysical interfaces.

I'll have look and see if I can find another machine to experiment with.

cheers

Brian

[Volker Halle]

Brian,

I did a simple test on an emulated OpenVMS Alpha V8.3 TCPIP V5.7 ECO 3 system:

CHAALP $ ifconfig se0 aliaslist 10.20.31.1-50/24     ! creating 50 aliases in one command

CHAALP $ ifconfig -a
LO0: flags=100c89<UP,LOOPBACK,NOARP,MULTICAST,SIMPLEX,NOCHECKSUM>
     inet 127.0.0.1 netmask ff000000 ipmtu 4096

SE0: flags=8000c43<UP,BROADCAST,RUNNING,MULTICAST,SIMPLEX,MULTINET>
    *inet 10.20.30.207 netmask ffffff00 broadcast 10.255.255.255 ipmtu 1500
     inet 10.20.31.1 netmask ffffff00 broadcast 10.20.31.255 ipmtu 1500
     inet 10.20.31.2 netmask ffffff00 broadcast 10.20.31.255 ipmtu 1500
...
     inet 10.20.31.49 netmask ffffff00 broadcast 10.20.31.255 ipmtu 1500
     inet 10.20.31.50 netmask ffffff00 broadcast 10.20.31.255 ipmtu 1500

TN0: flags=80<NOARP>

TN1: flags=80<NOARP>

CHAALP $ ifconfig se0 -aliaslist 10.20.31.1-50

So it does not seem to be the sheer NUMBER of aliases, it's more likely the no. of aliases distributed over multiple interfaces - but I only have one on this test system.

Volker.

[Brian Reiter]

Hi Volker,

Thanks for the help. I'll see about getting the issue passed onto HP.

cheers

Brian

[John Gillings]

Brian,

   Another thing I'd try is to REDUCE your BYTLM. Those numbers seem very high to me, and it's fairly clear you're only using a tiny fraction of the allocation. Try with BYTLM set low enough to at least get it out of the high hex digit of a 32 bit longword. Maybe 50000000 (though to my eyes that still looks like a HUGE allocation - and I can't imagine what you would be doing with it all!). It's possible that there is some code path in a dusty corner has an assumption, explicit or implicit, that BYTLM will never be that high, and some calculation overflows or goes negative.

Just out of curiosity, what are the pool allocations on this system? See SHOW MEM/POOL.

Your quota is more than a quarter of the maximum theoretical limit for NPAGEDYN. Most systems I've ever dealt with measure NPAGEDYN in 10's of MB, maybe up to 80 or 90MB. If it gets into 100's that's something that needs looking at. Your allocation is nearly 800MB. Is that really your intention?

[Brian Reiter]

Hi John,

Now that's worth a try, I think the allocation at the moment was a temporary increase to see if that helped, it didn't. I'll try reducing the value when I get back in the office next week.

Cheers

Brian