Aruba 2530 REST API

[netvis]

I am running firmware version YA.16.02.0014 on a 2530-8 switch. The following cURL command from the REST API and JSON Schema works:

curl -X POST http://10.0.0.62/rest/v1/vlans -d '{"vlan_id":5,"name":"VLAN5"}'

However, when I try to issue the same request using the Python Requests module, the request never completes:

#!/usr/bin/env python
import json
import requests

requests.post("http://10.0.0.62/rest/v1/vlans",
  data=json.dumps({'vlan_id':5,'name':'VLAN5'}))

I followed both requests with TCP dump and the only significant difference I can see is that in the cURL case, the HTTP headers and body arrive in one packet, but in the Python case, the headers and body are sent in two separate packets.

I am experiencing the same problem with POST operations using a Java URLConnection client. Operations without a message body (GET, DELETE) are successful.

[netvis]

I tried the latest YA.16.03.0003 release, but the results are the same.

[Michael Patmon]

You're trying to create a VLAN?  Try:

r = requests.post("http://210.5.0.2/rest/v1/vlans", json={"vlan_id":77})
print r.status_code
print r.json()

[mpatmon@mpatmon1 ~]$ ./rest.py 210.5.0.2
http://210.5.0.2/rest/v1/vlans
201
{u'status': u'VS_PORT_BASED', u'is_voice_enabled': False, u'is_jumbo_enabled': False, u'uri': u'/vlans/77', u'is_dsnoop_enabled': False, u'type': u'VT_STATIC', u'vlan_id': 77, u'name': u'VLAN77'}

In 16.03 you can also send a CLI command via REST.  Not as elegant but works if needed:

r = requests.post("http://210.5.0.2/rest/v2/cli", json={"cmd":"no vlan 77"})

[netvis]

I can confirm that the POST request works with the latest version of the Python requests library. Looking at the packets in tcpdump, it appears that the request headers and body now appear in a single packet:

16:11:22.139589 IP 10.0.0.134.36370 > dhcp12a.sf.inmon.com.http: Flags [P.], seq 1:190, ack 1, win 115, options [nop,nop,TS val 2023130 ecr 8679240], length 189: HTTP: POST /rest/v1/vlans HTTP/1.1
0x0000:  4500 00f1 709f 4000 4006 b4a4 0a00 0086  E...p.@.@.......
0x0010:  0a00 003e 8e12 0050 fe23 ae45 62b8 9e54  ...>...P.#.Eb..T
0x0020:  8018 0073 15a7 0000 0101 080a 001e deda  ...s............
0x0030:  0084 6f48 504f 5354 202f 7265 7374 2f76  ..oHPOST./rest/v
0x0040:  312f 766c 616e 7320 4854 5450 2f31 2e31  1/vlans.HTTP/1.1
0x0050:  0d0a 486f 7374 3a20 3130 2e30 2e30 2e36  ..Host:.10.0.0.6
0x0060:  320d 0a43 6f6e 6e65 6374 696f 6e3a 206b  2..Connection:.k
0x0070:  6565 702d 616c 6976 650d 0a41 6363 6570  eep-alive..Accep
0x0080:  742d 456e 636f 6469 6e67 3a20 677a 6970  t-Encoding:.gzip
0x0090:  2c20 6465 666c 6174 650d 0a41 6363 6570  ,.deflate..Accep
0x00a0:  743a 202a 2f2a 0d0a 5573 6572 2d41 6765  t:.*/*..User-Age
0x00b0:  6e74 3a20 7079 7468 6f6e 2d72 6571 7565  nt:.python-reque
0x00c0:  7374 732f 322e 3132 2e35 0d0a 436f 6e74  sts/2.12.5..Cont
0x00d0:  656e 742d 4c65 6e67 7468 3a20 3135 0d0a  ent-Length:.15..
0x00e0:  0d0a 7b22 766c 616e 5f69 6422 3a20 3738  ..{"vlan_id":.78
0x00f0:  7d                                       }

However, if I use the older Python library, or a Java URLConnection then request header and body are split across two packets and I get a 404 (not found error)

15:48:43.365947 IP (tos 0x0, ttl 64, id 33613, offset 0, flags [DF], proto TCP (6), length 258)
pphaal.sf.inmon.com.37412 > 10.0.0.62.http: Flags [P.], cksum 0x15d4 (incorrect -> 0x6928), seq 1:207, ack 1, win 115, options [nop,nop,TS val 798340907 ecr 7847420], length 206
0x0000: 4500 0102 834d 4000 4006 a1c9 0a00 00a2 E....M@.@.......
0x0010: 0a00 003e 9224 0050 d8c0 3515 564c 966c ...>.$.P..5.VL.l
0x0020: 8018 0073 15d4 0000 0101 080a 2f95 b72b ...s......../..+
0x0030: 0077 bdfc 504f 5354 202f 7265 7374 2f76 .w..POST./rest/v
0x0040: 312f 766c 616e 7320 4854 5450 2f31 2e31 1/vlans.HTTP/1.1
0x0050: 0d0a 486f 7374 3a20 3130 2e30 2e30 2e36 ..Host:.10.0.0.6
0x0060: 320d 0a43 6f6e 7465 6e74 2d4c 656e 6774 2..Content-Lengt
0x0070: 683a 2031 350d 0a41 6363 6570 742d 456e h:.15..Accept-En
0x0080: 636f 6469 6e67 3a20 677a 6970 2c20 6465 coding:.gzip,.de
0x0090: 666c 6174 652c 2063 6f6d 7072 6573 730d flate,.compress.
0x00a0: 0a41 6363 6570 743a 202a 2f2a 0d0a 5573 .Accept:.*/*..Us
0x00b0: 6572 2d41 6765 6e74 3a20 7079 7468 6f6e er-Agent:.python
0x00c0: 2d72 6571 7565 7374 732f 312e 302e 3420 -requests/1.0.4.
0x00d0: 4350 7974 686f 6e2f 322e 362e 3620 4c69 CPython/2.6.6.Li
0x00e0: 6e75 782f 322e 362e 3332 2d32 3739 2e31 nux/2.6.32-279.1
0x00f0: 392e 312e 656c 362e 7838 365f 3634 0d0a 9.1.el6.x86_64..
0x0100: 0d0a ..
15:48:43.376529 IP (tos 0x0, ttl 64, id 60971, offset 0, flags [DF], proto TCP (6), length 52)
10.0.0.62.http > pphaal.sf.inmon.com.37412: Flags [.], cksum 0xaf41 (correct), seq 1, ack 207, win 32664, options [nop,nop,TS val 7847620 ecr 798340705], length 0
0x0000: 4500 0034 ee2b 4000 4006 37b9 0a00 003e E..4.+@.@.7....>
0x0010: 0a00 00a2 0050 9224 564c 966c d8c0 35e3 .....P.$VL.l..5.
0x0020: 8010 7f98 af41 0000 0101 080a 0077 bec4 .....A.......w..
0x0030: 2f95 b661 /..a
15:48:43.377193 IP (tos 0x0, ttl 64, id 33614, offset 0, flags [DF], proto TCP (6), length 67)
pphaal.sf.inmon.com.37412 > 10.0.0.62.http: Flags [P.], cksum 0x1515 (incorrect -> 0x2899), seq 207:222, ack 1, win 115, options [nop,nop,TS val 798340918 ecr 7847620], length 15
0x0000: 4500 0043 834e 4000 4006 a287 0a00 00a2 E..C.N@.@.......
0x0010: 0a00 003e 9224 0050 d8c0 35e3 564c 966c ...>.$.P..5.VL.l
0x0020: 8018 0073 1515 0000 0101 080a 2f95 b736 ...s......../..6
0x0030: 0077 bec4 7b22 766c 616e 5f69 6422 3a20 .w..{"vlan_id":.
0x0040: 3738 7d 78}
15:48:43.386966 IP (tos 0x0, ttl 64, id 60972, offset 0, flags [DF], proto TCP (6), length 52)
10.0.0.62.http > pphaal.sf.inmon.com.37412: Flags [.], cksum 0xae77 (correct), seq 1, ack 207, win 32664, options [nop,nop,TS val 7847620 ecr 798340907], length 0
0x0000: 4500 0034 ee2c 4000 4006 37b8 0a00 003e E..4.,@.@.7....>
0x0010: 0a00 00a2 0050 9224 564c 966c d8c0 35e3 .....P.$VL.l..5.
0x0020: 8010 7f98 ae77 0000 0101 080a 0077 bec4 .....w.......w..
0x0030: 2f95 b72b /..+
15:48:43.401485 IP (tos 0x0, ttl 64, id 60973, offset 0, flags [DF], proto TCP (6), length 253)
10.0.0.62.http > pphaal.sf.inmon.com.37412: Flags [P.], cksum 0xd8cf (correct), seq 1:202, ack 222, win 32657, options [nop,nop,TS val 7847640 ecr 798340918], length 201
0x0000: 4500 00fd ee2d 4000 4006 36ee 0a00 003e E....-@.@.6....>
0x0010: 0a00 00a2 0050 9224 564c 966c d8c0 35f2 .....P.$VL.l..5.
0x0020: 8018 7f91 d8cf 0000 0101 080a 0077 bed8 .............w..
0x0030: 2f95 b736 4854 5450 2f31 2e31 2034 3034 /..6HTTP/1.1.404
0x0040: 204e 6f74 2046 6f75 6e64 0d0a 5365 7276 .Not.Found..Serv
0x0050: 6572 3a20 6548 5454 5020 7632 2e30 0d0a er:.eHTTP.v2.0..
0x0060: 436f 6e6e 6563 7469 6f6e 3a20 4b65 6570 Connection:.Keep
0x0070: 2d41 6c69 7665 0d0a 436f 6e74 656e 742d -Alive..Content-
0x0080: 5479 7065 3a20 7465 7874 2f68 746d 6c0d Type:.text/html.
0x0090: 0a43 6f6e 7465 6e74 2d4c 656e 6774 683a .Content-Length:
0x00a0: 2038 360d 0a0d 0a3c 4854 4d4c 3e3c 5449 .86....<HTML><TI
0x00b0: 544c 453e 3430 343a 204e 6f74 2046 6f75 TLE>404:.Not.Fou
0x00c0: 6e64 2e3c 2f54 4954 4c45 3e3c 4831 3e4e nd.</TITLE><H1>N
0x00d0: 6f74 2046 6f75 6e64 2e3c 2f48 313e 4572 ot.Found.</H1>Er
0x00e0: 726f 7220 3430 343a 204e 6f74 2046 6f75 ror.404:.Not.Fou
0x00f0: 6e64 2e3c 503e 3c2f 4854 4d4c 3e nd.<P></HTML>

 This appears to be an issue with the eHTTP v2.0 server not waiting for the full request body before processing the request.

[netvis]

The problem with posting appears to be fixed in theYA.16.04.0008 release.

Is there any documentation describing the "CLI Commands over REST Interface" feature added in this release? The referenced "ArubaOS-Switch REST API Guide" was last updated in January and I cannot see a description of the 'CliCommand' object. 

[netvis · Accepted solution]

The CLI command REST call is working.

The following article demonstrates how to use sFlow telemetry along with the REST API to automatically manage usage quotas, Real-time visibility and control of campus networks