公司的webcdn 服务器为了保证高可用，采用了keepalived的ha方案，keepalived对网络环境的依赖性很高（如果服务器之前有丢包即可能导致keepalived vip发生漂移，影响应用的稳定性），因此keepalived适合部署在相近节点。
最近遇到关于invalid ttl的报警，在网上也没有找到解决方法，最后通过对keepalived源码查看找到了问题的原因。
现象：
两台服务器均能获取vip（至于为什么属于不同的组播域也能获取vip是因为我在源码中做了些更改，将多播的方式改成单播的方式了），但是其中一台A vip不能ping通，不能使用arping和ping来刷新ip-mac对应关系
查看日志：
Jul 17 17:19:05 hostname-a Keepalived: invalid ttl. 254 and expect 255
Jul 17 17:19:05 hostname-a Keepalived: bogus VRRP packet received on eth0 !!!
Jul 17 17:19:05 hostname-a Keepalived: VRRP_Instance(Nginx_251) ignoring received advertisment...
对源码的查看：
Vrrp.c中定义了这个错误的原因
/* MUST verify that the IP TTL is 255 */
if (ip->ttl != VRRP_IP_TTL) {
syslog(LOG_INFO, "invalid ttl. %d and expect %d", ip->ttl,
VRRP_IP_TTL);
return VRRP_PACKET_KO;
}
即，当ip->ttl 和VRRP_IP_TTL不相等时会报错，并将两个值同时报出来
Vrrp.h中关于VRRP_IP_TTL的定义：
/* protocol constants */
#define INADDR_VRRP_GROUP 0xe0000012 /* multicast addr - rfc2338.5.2.2 */
#define VRRP_IP_TTL 255 /* in and out pkt ttl -- rfc2338.5.2.3 */
#define IPPROTO_VRRP 112 /* IP protocol number -- rfc2338.5.2.4 */
#define VRRP_VERSION 2 /* current version -- rfc2338.5.3.1 */
#define VRRP_PKT_ADVERT 1 /* packet type -- rfc2338.5.3.2 */
#define VRRP_PRIO_OWNER 255 /* priority of the ip owner -- rfc2338.5.3.4 */
#define VRRP_PRIO_DFL 100 /* default priority -- rfc2338.5.3.4 */
#define VRRP_PRIO_STOP 0 /* priority to stop -- rfc2338.5.3.4 */
#define VRRP_AUTH_NONE 0 /* no authentification -- rfc2338.5.3.6 */
#define VRRP_AUTH_PASS 1 /* password authentification -- rfc2338.5.3.6 */
#define VRRP_AUTH_AH 2 /* AH(IPSec) authentification - rfc2338.5.3.6 */
#define VRRP_ADVER_DFL 1 /* advert. interval (in sec) -- rfc2338.5.3.7 */
#define VRRP_GARP_DELAY (5 * TIMER_HZ) /* Default delay to launch gratuitous arp */
查看rfc2338.5.2.3的说明：
5.2.3 TTL
The TTL MUST be set to 255. A VRRP router receiving a packet with the TTL not equal to 255 MUST discard the packet.
即VRRP_IP_TTL的值是唯一的确认的，只能是255
而 ip->ttl 这个值是变化得来的。
我们来看一下它是怎么得出来的
keepalived/vrrp/vrrp.c:380: ip->ttl = VRRP_IP_TTL;
/* build IP header */
static void
vrrp_build_ip(vrrp_rt * vrrp, char *buffer, int buflen) #定义了一个函数，这个函数会对vrrp的包进行一些定义
{
struct iphdr *ip = (struct iphdr *) (buffer);
ip->ihl = 5;
ip->version = 4;
ip->tos = 0;
ip->tot_len = ip->ihl * 4 + vrrp_hd_len(vrrp);
ip->tot_len = htons(ip->tot_len);
ip->id = htons(++vrrp->ip_id);
/* kernel will fill in ID if left to 0, so we overflow to 1 */
if (vrrp->ip_id == 65535)
vrrp->ip_id = 1;
ip->frag_off = 0;
ip->ttl = VRRP_IP_TTL; #定义初始的值，和VRRP_IP_TTL相等，为255
/* fill protocol type --rfc2402.2 */
ip->protocol =
(vrrp->auth_type == VRRP_AUTH_AH) ? IPPROTO_IPSEC_AH : IPPROTO_VRRP;
ip->saddr = VRRP_PKT_SADDR(vrrp);
ip->daddr = htonl(INADDR_VRRP_GROUP);
/* checksum must be done last */
ip->check = in_csum((u_short *) ip, ip->ihl * 4, 0);
}
通过上面的函数可以看出，默认初始的值ip->ttl = VRRP_IP_TTL，都是255.
根据ttl的定义，每经过一个路由器ttl的值就会减一。报错信息中现显示ip->ttl的值是254，这就说明对与vrrp来说，它认为包经过了一个路由，因此不属于同一个组播域，进而将报文丢包。
实际上A,B两台服务器的外网IP是同一个网段的，在A上 traceroute B,发现却多了一跳！而且走了错误的内网IP作为网关！
最后发现是由于这块网卡同时配置了内外网IP并同属于两个不同的vlan导致,问题找到，解决之。
本文转自菜菜光 51CTO博客，原文链接：http://blog.51cto.com/caiguangguang/933912，如需转载请自行联系原作者
