Re: VRRP packets with duplicate AH sequence number
Quentin Armitage <[email protected]> Wed, 17 May 2017 21:56:37 +0100
| Newsgroups | gmane.linux.keepalived.devel |
|---|---|
| Organization | The Armitage family |
| Message-ID | <[email protected]> |
Aleksey, This appears to confirm that keepalived is only sending the packet once, but for some reason the packet is being looped back to the keepalived process multiple times (in this case 86 times) in the space of 2.248 milli-seconds, and for the tcpdump trace you show the packets are being received at approximately 4 micro-second intervals. Before the problem of duplicate packets occurs keepalived is sending packets of intervals of approximately 1.001 seconds; after the duplicate packets issue is resolved the interval is approx 1.0005 seconds (i.e. the extra delay over the configured 1 second has halved). The packet that is duplicated (seq no 996 = 0x3e4) is first shown with a timestamp of 14:53:36.066046 (and final timestamp 14:53:36.068294), which suggests that the next packet should have been seen at 14:53:37.067 approximately, whereas it wasn't seen until 14:53:37.460675, approximately 390 milli-seconds later than expected, and it then continues from there at 1.0005 second intervals. This suggests that something has happened to NODE2 that caused a delay in the scheduling of keepalived. Whether it is something within the kernel on NODE2, or whether it is something happening within your network, I cannot say from the information provided. I suspect, however, it is something in your network that, having received the VRRP packet is retransmitting it multiple times, which would explain why keepalived is receiving the packet when it normally doesn't, and also the machine where you are running the tcpdump is seeing the packet multiple times. On the other hand, something is happening on NODE2 to cause a 1.39s interval between sending the packet with sequence no 996, and the next packet, with sequence no 1083; this could be down to processing a very high number of packets from the network or for some reason looping back messages itself. I do not see how keepalived can be causing the problem, since the log shows that there is only 1 call to sendmsg(), so the only conclusion I can see is that the problem is either occurring within the networking stack on NODE2, or elsewhere on your network. To me, this conclusion is reinforced by their being no other reports of similar problems, so far as I am aware. As an aside, I don't believe Keepalived is behaving as it should do in that when it receives a packet that it considers is invalid, since it is still incrementing the sequence number. It should be noted that IPSEC (or indeed any authentication) has not been part of the VRRP specification since 2004, when RFC3768 superseded RFC2338, but I understand some people still find authentication useful. RFC2338 didn't fully specify how IPSEC should be used, and so Alexandre wrote http://www.keepalived.org/draft-ietf-vrrp-ipsecah-spec-00.txt in 2003. It might be worth checking whether Keepalived still conforms to that document, and indeed whether when a master receives a packet that isn't of higher priority, it should not increment the next sequence number. Quentin On Wed, 2017-05-17 at 15:03 +0300, Aleksey wrote: > well, here is the output: > > 25127 May 17 14:53:33 NODE2 Keepalived_vrrp[15515]: Sending advert with > seq no 993 > 25128 May 17 14:53:34 NODE2 Keepalived_vrrp[15515]: Sending advert with > seq no 994 > 25129 May 17 14:53:35 NODE2 Keepalived_vrrp[15515]: Sending advert with > seq no 995 > 25130 May 17 14:53:36 NODE2 Keepalived_vrrp[15515]: Sending advert with > seq no 996 > 25131 May 17 14:53:36 NODE2 Keepalived_vrrp[15515]: VRRP_Instance(TEST) > IPSEC-AH : sequence number 996 already proceeded. Packet dropped. > Local(997) > 25132 May 17 14:53:36 NODE2 Keepalived_vrrp[15515]: bogus VRRP packet > received on eth0 !!! > 25133 May 17 14:53:36 NODE2 Keepalived_vrrp[15515]: VRRP_Instance(TEST) > Dropping received VRRP packet... > 25134 May 17 14:53:36 NODE2 Keepalived_vrrp[15515]: VRRP_Instance(TEST) > IPSEC-AH : sequence number 996 already proceeded. Packet dropped. > Local(998) > 25135 May 17 14:53:36 NODE2 Keepalived_vrrp[15515]: bogus VRRP packet > received on eth0 !!! > 25136 May 17 14:53:36 NODE2 Keepalived_vrrp[15515]: VRRP_Instance(TEST) > Dropping received VRRP packet... > 25137 May 17 14:53:36 NODE2 Keepalived_vrrp[15515]: VRRP_Instance(TEST) > IPSEC-AH : sequence number 996 already proceeded. Packet dropped. > Local(999) > ---some lines omitted--- > 25386 May 17 14:53:36 NODE2 Keepalived_vrrp[15515]: VRRP_Instance(TEST) > IPSEC-AH : sequence number 996 already proceeded. Packet dropped. > Local(1082) > 25387 May 17 14:53:36 NODE2 Keepalived_vrrp[15515]: bogus VRRP packet > received on eth0 !!! > 25388 May 17 14:53:36 NODE2 Keepalived_vrrp[15515]: VRRP_Instance(TEST) > Dropping received VRRP packet... > 25389 May 17 14:53:37 NODE2 Keepalived_vrrp[15515]: Sending advert with > seq no 1083 > 25390 May 17 14:53:38 NODE2 Keepalived_vrrp[15515]: Sending advert with > seq no 1084 > 25391 May 17 14:53:39 NODE2 Keepalived_vrrp[15515]: Sending advert with > seq no 1085 > 25392 May 17 14:53:40 NODE2 Keepalived_vrrp[15515]: Sending advert with > seq no 1086 > > > Here is the tcpdump: > 14:53:31.060704 IP 10.1.64.21 > 224.0.0.18: > AH(spi=0x0a014015,seq=0x3df): VRRPv2, Advertisement, vrid 73, prio 200, > authtype ah, intvl 1s, length 20 > 14:53:32.061823 IP 10.1.64.21 > 224.0.0.18: > AH(spi=0x0a014015,seq=0x3e0): VRRPv2, Advertisement, vrid 73, prio 200, > authtype ah, intvl 1s, length 20 > 14:53:33.062940 IP 10.1.64.21 > 224.0.0.18: > AH(spi=0x0a014015,seq=0x3e1): VRRPv2, Advertisement, vrid 73, prio 200, > authtype ah, intvl 1s, length 20 > 14:53:34.063809 IP 10.1.64.21 > 224.0.0.18: > AH(spi=0x0a014015,seq=0x3e2): VRRPv2, Advertisement, vrid 73, prio 200, > authtype ah, intvl 1s, length 20 > 14:53:35.064916 IP 10.1.64.21 > 224.0.0.18: > AH(spi=0x0a014015,seq=0x3e3): VRRPv2, Advertisement, vrid 73, prio 200, > authtype ah, intvl 1s, length 20 > 14:53:36.066046 IP 10.1.64.21 > 224.0.0.18: > AH(spi=0x0a014015,seq=0x3e4): VRRPv2, Advertisement, vrid 73, prio 200, > authtype ah, intvl 1s, length 20 > 14:53:36.066072 IP 10.1.64.21 > 224.0.0.18: > AH(spi=0x0a014015,seq=0x3e4): VRRPv2, Advertisement, vrid 73, prio 200, > authtype ah, intvl 1s, length 20 > 14:53:36.066076 IP 10.1.64.21 > 224.0.0.18: > AH(spi=0x0a014015,seq=0x3e4): VRRPv2, Advertisement, vrid 73, prio 200, > authtype ah, intvl 1s, length 20 > 14:53:36.066085 IP 10.1.64.21 > 224.0.0.18: > AH(spi=0x0a014015,seq=0x3e4): VRRPv2, Advertisement, vrid 73, prio 200, > authtype ah, intvl 1s, length 20 > ---some lines omitted--- > 14:53:36.068288 IP 10.1.64.21 > 224.0.0.18: > AH(spi=0x0a014015,seq=0x3e4): VRRPv2, Advertisement, vrid 73, prio 200, > authtype ah, intvl 1s, length 20 > 14:53:36.068292 IP 10.1.64.21 > 224.0.0.18: > AH(spi=0x0a014015,seq=0x3e4): VRRPv2, Advertisement, vrid 73, prio 200, > authtype ah, intvl 1s, length 20 > 14:53:36.068294 IP 10.1.64.21 > 224.0.0.18: > AH(spi=0x0a014015,seq=0x3e4): VRRPv2, Advertisement, vrid 73, prio 200, > authtype ah, intvl 1s, length 20 > 14:53:37.460675 IP 10.1.64.21 > 224.0.0.18: > AH(spi=0x0a014015,seq=0x43b): VRRPv2, Advertisement, vrid 73, prio 200, > authtype ah, intvl 1s, length 20 > 14:53:38.461012 IP 10.1.64.21 > 224.0.0.18: > AH(spi=0x0a014015,seq=0x43c): VRRPv2, Advertisement, vrid 73, prio 200, > authtype ah, intvl 1s, length 20 > 14:53:39.461632 IP 10.1.64.21 > 224.0.0.18: > AH(spi=0x0a014015,seq=0x43d): VRRPv2, Advertisement vrid 73, prio 200, > authtype ah, intvl 1s, length 20 > 14:53:40.461996 IP 10.1.64.21 > 224.0.0.18: > AH(spi=0x0a014015,seq=0x43e): VRRPv2, Advertisement, vrid 73, prio 200, > authtype ah, intvl 1s, length 20 > 14:53:41.462617 IP 10.1.64.21 > 224.0.0.18: > AH(spi=0x0a014015,seq=0x43f): VRRPv2, Advertisement, vrid 73, prio 200, > authtype ah, intvl 1s, length 20 > > > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Keepalived-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/keepalived-devel