Linux에서 패킷 당 다중 경로 라우팅을 달성하는 방법은 무엇입니까?


9

3.6 이전의 Linux Kernel은 경로 캐싱을 사용하여 IPv4 다중 경로 라우팅을 수행했습니다. 이는 두 개의 개별 회선 / ISP 간 라우팅이 매우 쉬웠 음을 의미합니다. 3.6에서 알고리즘은 패킷 당으로 변경되었는데, 이는 두 라인 / ISP를 달성하기 위해 일부 라우팅 테이블 / 룰 / iptables 마커 트릭이 필요하다는 것을 의미합니다.

그러나 동일한 ISP에 두 개의 회선이있어 단일 IP를 패킷 당 두 개의 회선으로 균형 / 장애 조치 방식으로 라우팅 할 수있는 경우 3.6부터는 다음과 같은 이유로 회선 연결 (IP 수준)을 쉽게 달성 할 수 있습니다. 양방향 패킷 라우팅.

4.4 에서 커널 은 소스 및 대상 주소의 해시를 기반으로 흐름 기반로드 밸런싱으로 다시 변경되었습니다 .

현재 커널 4.4.36을 실행 중이며 PPPoE 연결을 통한 다중 경로 라우팅을 사용하고 있습니다. ISP의 다운 스트림 트래픽은 패킷별로 두 개의 개별 회선을 통해 라우팅됩니다 (하나의 IP가 두 회선으로 라우팅 됨). 이것은 하나의 개별 라인의 속도보다 빠른 다운로드 속도를 제공합니다. 두 라인의 속도가 거의 합산되었습니다. Skype 비디오, VoIP (UDP), YouTube 등은 모두 잘 작동합니다.

다운 스트림 환경이 좋기 때문에 업스트림으로 시도하고 싶지만 내 업스트림 트래픽은 두 개의 ppp 장치 (동일한 IP 주소를 가짐)에 걸쳐 새로운 흐름 기반 알고리즘에 따라 라우팅됩니다. 즉, 한 줄의 속도보다 빠른 업로드 속도를 달성 할 수 없습니다.

패킷 당 알고리즘을 사용하도록 현재 커널을 구성하는 방법이 있습니까? 또는 패킷 당 다중 경로 라우팅을 달성하는 다른 방법이 있습니까? 이전 커널로 되돌려 야합니까 (여러 가지 이유로하고 싶지 않습니다)?

ISP가 멀티 링크 ppp를 지원하지 않습니다.

관련이있는 경우, 현재 Raspberry Pi 3에서 Arch Linux ARMv7을 실행하고 있습니다.


3
이것은 매우 나쁜 생각입니다. L2에서의 패킷 당 밸런싱 (즉, MLPPP)은 패킷을 순서대로 재 조립하기에 충분한 로직을 포함한다. IP를 통해이를 실행하면 비 순차적 배송에 대한 엄청난 기회 (거의 불확실성이 아닌 경우)가 열립니다. 이것은 느린 TCP 세션, UDP의 고장, 모든 종류의 실시간 스트리밍 문제 등과 같은 수많은 문제를 일으킬 것입니다. 다른 문제는 ISP에 라운드 로빈을 패킷으로 보내는 경우에도 그들이 당신과 비슷하게 균형을 잡을 것이라는 절대적인 제안은 없습니다.
rnxrx

귀하의 의견에 감사합니다 @rnxrx-추가 세부 사항을 제공하기 위해 질문을 편집했습니다. 내 질문에 따르면 : "ISP의 다운 스트림 트래픽은 패킷별로 두 개의 개별 회선을 통해 라우팅됩니다". ISP는 제어판을 제공합니다. 두 회선을 통해 라우팅 할 IP를 하나 선택한 다음 패킷별로 완벽하게 균형 잡힌 라운드 로빈을 라우팅합니다. 함께 추가 된 두 회선의 총 속도의 약 90 %에서 잘 작동하며 즉각적인 장애 조치를 제공합니다. 스트리밍 스카이프 비디오, VOIP 통화, 유튜브, BBC 등 모든 위대한 - 이러한 좋은 다운 스트림 경험이 나를 상류 시도 할 수 있습니다
bao7uo

1
Ahh-알았는데 ... 현재 두 개의 고유 한 IP (연결 당 하나)가 있거나 두 개의 병렬 경로를 통해 사용자 측의 단일 IP (또는 서브넷)로 라우팅되고 있습니까? 모든 종류의 NAT를 실행하는 경우이 균형 조정 전에 발생하는 것이 중요합니다. 어쨌든 support.aa.net.uk/…보셨습니까 ? iptables 확장을 사용하여 기본적으로 설명하는 것을 달성하므로 합리적으로 현대적인 커널 버전에서 상당히 일관성이 있어야합니다.
rnxrx

감사합니다 @rnxrx-예 옵션 (병렬 경로를 통해 두 개의 고유 IP 또는 단일 IP)을 수행 할 수 있습니다. 더 이해하기 쉬운 단일 IP 옵션을 선호했습니다.
bao7uo

답변:


3

좋아, 그래서 이것을 조사하는 데 더 많은 시간을 보낸 후 Linux TEQL (True Link Equalizer)을 사용하는 방법을 찾았습니다. 여기에 느슨하게 따라가는 링크가 있지만 약간의 조정이 있습니다.

http://lartc.org/howto/lartc.loadshare.html

이것이 내가 아치 리눅스 ARMv7 (라즈베리 파이 3)에서 작동하게하는 방법입니다.

부팅시 :

부팅시 적절한 커널 모듈을로드하려면 다음 명령을 실행해야합니다.

modprobe sch_teql

다음 명령은 또한 eth0의 로컬 네트워크에서 NAT를 원한다고 가정 할 때 부팅시 실행됩니다.

sysctl -w net.ipv4.ip_forward=1
iptables -A INPUT -i ppp+ -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i ppp+ -o eth0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A POSTROUTING -t nat -o teql+ -j MASQUERADE

FORWARD 리턴 트래픽은 ppp +에 있고, 나가는 트래픽은 teql에서 나가고 리턴 트래픽은 ppp에 다시 있기 때문에 teql +에 POSTROUTING MASQUERADE가 있습니다.

ppp 링크가 나타나면 :

로드 밸런싱 될 링크가 ppp라고 가정하면 다음 명령은 스크립트의 스크립트에서 실행됩니다 /etc/ppp/ip-up.d/.

sysctl -w net.ipv4.conf.ppp1.rp_filter=2
sysctl -w net.ipv4.conf.ppp2.rp_filter=2
tc qdisc add dev ppp1 root teql0
tc qdisc add dev ppp2 root teql0
ip address add 1.1.1.1/32 dev teql0
# you can add additional public IP addresses teql0 if you need to
ip link set teql0 up
ip route replace default scope global dev teql0

1.1.1.1ISP가 직면 한 공용 IP 주소는 어디에 있습니까 ? 추가 공용 IP를 teql0 장치에 할당 할 수 있지만 ppp 장치에 할당 할 필요는 없습니다. 내 설정에서 두 ppp 링크는 동일한 IP를 공유합니다 (pppoe 등으로 협상). 위에 표시된 것처럼 수동으로 할당 한 teql 링크. ISP는 두 링크 모두에서 동일하게 IP 트래픽을 보내야합니다.

위 스크립트에서 리버스 경로 ( rp_filter)가 2모두 (느슨하게) 설정되어 반환 패킷이 teql0이 아닌 ppp 인터페이스로 되돌아 와서 삭제되지 않습니다.

나는 그런 식으로 설정했으며 완벽하게 작동합니다. 아주 쉽게! 링크가 실패하면 완벽한 장애 조치가 수행됩니다. 그들이 올라 오면 다시 일하기 시작합니다. 페일 오버시 패킷 손실이나 지연이없고 다시 시작될 때 패킷 손실이없는 것 같습니다.

또한 의견 제시 자 중 한 명이 iptables를 사용하여 다른 모든 패킷 등을 표시하는 정책 라우팅을 사용하는 아래 링크를 제안했지만 며칠 안에 위보다 더 나은지 여부를 확인하고 이에 따라 피드백을 제공하려고합니다.

http://support.aa.net.uk/Router_-_Linux_upload_bonding_using_policy_routing


TEQL이 잘 작동했기 때문에 정책 라우팅을 시도하지 않았습니다. 그것이
깨지지

이 작업을 수행하려고합니다. 본딩 작업이 있는데 라우터에서 본딩 인터페이스를 사용할 수 있습니다. 나는 나의 LAN에서 트래픽이 결합 링크 :( 추락하지 않습니다 불구하고 NAT 작업 얻을 수 없다
andynormancx

서버 결함에 대한 새로운 질문을 게시하고 의견에서 링크하면 나는 당신을 위해 그것을 알아 내려고 노력할 것입니다. 의견에 여기에있는 모든 정보를 맞출 수 없다면 인터페이스 / IP 구성, 라우팅 테이블, iptables 규칙 등과 같은 가능한 많은 정보를 포함 하시겠습니까?
bao7uo

1
추신. 내 구성에서 실수를 발견했습니다. 그것은 말 sysctl -w net.ipv4.ip_forward했지만 sysctl -w net.ipv4.ip_forward=1내가 위에서 수정 했다고 말해야 합니다. 이는 LAN의 트래픽이 본드 링크로 내려가는 것을 확실히 방지합니다.
bao7uo

나는 그것이 나를 위해 작동을 멈추게 한 것이라고 생각하지 않는다. 나는 sysctl에서 전달을 가능하게했다. 나는 지금보고있는 대량의 비 순차적 패킷이 예상되는지 여부를 해결하려고 노력하고 있습니다.
andynormancx
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.