Keepalived, Junos 및 ARP 캐싱

Keepalived, Junos 및 ARP 캐싱

stunnelKeepalived를 사용하여 회사 데이터 센터의 공용 IP 주소에 대해 활성-수동 설정을 구성하려고 합니다 . 다음 시나리오에서 라우터 또는 스위치 재구성이 권장되는지 알고 싶습니다.

stunnel현재 두 개의 CentOS 6 상자 각각에 다른 (내부) 서버의 테스트 페이지에 대한 연결을 프록시하는 작동이 확인된 설치가 있습니다 . 나는 구성을 기반으로이 튜토리얼. ( eth1무고한 자를 보호하기 위해 기기 에 존재하는 외부 가상 IP를 수정했습니다 .)

# Box 1 (primary)
vrrp_script chk_stunnel {           # Requires keepalived-1.1.13
        script "killall -0 stunnel"     # cheaper than pidof
        interval 2                      # check every 2 seconds
        weight 2                        # add 2 points of prio if OK
}

vrrp_instance stunnel_cluster {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 101
    advert_int 1
    virtual_ipaddress {
        <VIRTUAL IP>/32 dev eth1
    }
    track_script {
        chk_stunnel
    }
}

# Box 2 (secondary)
vrrp_script chk_stunnel {           # Requires keepalived-1.1.13
        script "killall -0 stunnel"     # cheaper than pidof
        interval 2                      # check every 2 seconds
        weight 2                        # add 2 points of prio if OK
}

vrrp_instance stunnel_cluster {
    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    virtual_ipaddress {
        <VIRTUAL IP>/32 dev eth1
    }
    track_script {
        chk_stunnel
    }
}

의 기본 인스턴스를 종료하면 stunnelsyslogs는 보조 상자가 예상대로 불필요한 ARP 패킷을 보내기 시작하지만 테스트 웹 페이지가 장애 조치되지 않고 대신 사용할 수 없게 된다는 것을 나타냅니다. 어느 정도 시간이 지나면(최소 몇 시간) 마침내 두 번째 상자가 이어집니다.

나에게 이것은 적어도 하나의 Juniper 장치(공용 라우터 및 별도의 스위치)에서 ARP 캐싱처럼 들립니다. 기본 시간 초과(6시간으로 생각됨)를 무시하는 대신 무료 ARP가 예상대로 작동하고 라우팅 테이블 업데이트를 트리거하도록 하는 것이 더 좋습니다.

나는 믿는다gratuitous-arp-reply여기서 설정이 유용할 수 있습니다. 시스템을 변경하기 전에 누군가가 다음 사항을 알아주기를 바랍니다.

  • 장애 조치 실패의 원인일 가능성이 더 높은 범인을 간과했나요?
  • ARP 캐싱이 문제인 경우 이 변경 사항이 내가 하려는 작업을 수행하는 "표준" 방법처럼 들립니까?
  • 회사 네트워크 경계가 합리적으로 보호되어 있다고 가정할 때 이 설정을 변경하면 불합리한 보안 위험이 발생합니까?
  • 제가 알아야 할 다른 "문제점"이 있나요?

감사합니다.

관련 정보