VMPS Problem with similar requests
Hi, If two vmps requests are sent in close succession (within cleanup_delay), with the same source port, from the same switch (which does in fact seem to be common, as the cisco switch I'm using for testing sends *all* requests with a source port picked on startup), they are detected as identical by freeradius as identical, even if they are for different mac addresses. This means the second request gets the same response as the first, even when they should be different. For example, testing with the vqpcli tool: Close together: server:/etc/freeradius/tests# ./vqpcli.pl -s 127.0.0.1 -v tc.example.com -w 192.168.248.32 -i Fa0/17 -m 0016.4111.0bfe Vlan: BRIDGE MAC Address: 001641110bfe Status: ALLOW server:/etc/freeradius/tests# ./vqpcli.pl -s 127.0.0.1 -v tc.example.com -w 192.168.248.32 -i Fa0/17 -m 0016.4111.0bff Vlan: BRIDGE MAC Address: 001641110bfe Status: ALLOW then a short time later (outside cleanup_delay) server:/etc/freeradius/tests# ./vqpcli.pl -s 127.0.0.1 -v tc.example.com -w 192.168.248.32 -i Fa0/17 -m 0016.4111.0bff Vlan: MAC Address: Status: DENY Which is the correct response Cheers --Mike
Michael Bryant wrote:
If two vmps requests are sent in close succession (within cleanup_delay), with the same source port, from the same switch (which does in fact seem to be common, as the cisco switch I'm using for testing sends *all* requests with a source port picked on startup), they are detected as identical by freeradius as identical, even if they are for different mac addresses.
Hmm... does the client use the *same* VMPS transaction Id for the packets? If so, that's not nice. It means that the server can't cache packets to lower loads due to re-transmits. Alan DeKok.
participants (2)
-
Alan DeKok -
Michael Bryant