되는 서버와 안 되는 서버의 커널 버전이 같나요? 지금까지 말씀으로 짐작하건데 안 되는 쪽 서버 커널이 IGMPv3를 지원하지 않는 더 오래된 버전인 게 아닌가 싶습니다.
그 상태에서 멀티캐스트 라우터가 IGMPv3만 지원하는 거라면 왜 패킷 수신이 안 되는지가 설명됩니다. 그걸 검증하시려면 tcpdump 같은 패킷 캡처 프로그램으로 IGMP 패킷을 들여다보시면 될 것 같습니다.
잘 되는 쪽 서버에서는 아마 다음과 같은 식으로 패킷이 보이지 싶습니다.
1. 라우터에서 뿌리는 IGMP query v3
2. (직후) 서버에서 보내는 IGMP report v3
안 되는 쪽 서버는 혹시 다음과 같은 식으로 패킷이 보이지 않을까 찍어봅니다.
1. 라우터에서 뿌리는 IGMP query v3
2. (앞의 패킷과 무관한 간격으로) 서버에서 보내는 IGMP report v2
정리하자면, 저 같으면 다음 사항을 확인해보겠습니다.
1. 두 서버에서 각각 IGMP 패킷이 어떻게 오가고 있는지 확인
2. 되는 서버와 안 되는 서버의 커널 버전이 동일한지 여부 확인
3. 안 되는 서버 커널이 IGMPv3를 지원하는 버전인지 여부 확인
4. 멀티캐스트 라우터가 IGMPv2를 지원하게 설정 가능한지 여부 확인
해결을 하셨나 모르겠네요. 지난 주말에 잉여거리다 몇 가지 확인해본 것들이 있어서 정리해 봅니다.
가상머신을 하나 만들어서 Fedora Core 14를 설치했습니다. 그리고 이웃 호스트에서 멀티캐스트 패킷을 쏴서 수신이 되는지 확인해 봤습니다. 가난한 살림 탓에 멀티캐스트 라우터가 없어서 IGMP 동작에 대한 건 확인해 보지 못했습니다. 대신 force_igmp_version 등에 대한 걸 좀 확인해 봤습니다.
1. /proc/net/igmp에 "V3"가 아니라 "V2"라고만 나타나는 문제
IGMP 버전을 제어하는 proc 파일은 /proc/sys/net/ipv4/conf/DEV/force_igmp_version입니다. 그런데... /proc/sys/net/ipv4/conf/all/force_igmp_version도 영향을 줍니다. eth1 쪽에 3이라고 설정하더라도 all 쪽에 2라고 설정돼 있으면 V2를 사용합니다.
/proc/sys/net/ipv4/conf/all/force_igmp_version의 기본값은 0입니다. 그게 2로 돼 있다면 누군가 sysctl 설정 등을 통해 net.ipv4.conf.all.force_igmp_version이나 net.ipv4.conf.default.force_igmp_version 항목의 값을 바꿔줘서일 겁니다.
2. 현재 IGMP 동작 상황
10월 14일에 올리신 패킷 덤프를 보면 IGMP query의 버전이 2입니다. 따라서 1번 문제는 사실 별 문제가 아닌 셈입니다.
즉, IGMP 수준에서는 별 이상이 없어 보입니다.
3. 방화벽 열기
수신측 호스트에서 과감하게 INPUT 체인 처음에 모든 패킷을 ACCEPT 하는 규칙을 추가했습니다. 멀티캐스트 패킷만을 허용하도록 조건을 상세히 지정해주는 게 맞지만... 그냥, 잉여로운 테스트니까요...;;;
join은 해주신 거죠?
join은 해주신 거죠?
$PWD `date`
네 조인은 했습니다.
똑같은 소스로 다른 컴퓨터의 다른 서버에서는 잘 돌아가는데 이 서버에서만 안돌아가네요... ㅡ.ㅡ
$PWD 'date' 은 무엇인가요?
흠... 설마 안 되는 쪽 서버의 커널 구성에
흠... 설마 안 되는 쪽 서버의 커널 구성에 멀티캐스트 지원이 빠져있을 리도 없고...
데몬을 실행한 상태에서 /proc/net/igmp 파일의 내용이 두 서버에서 어떻게 다른지 확인해보실 수 있을 것 같습니다. 멤버십 조인이 잘 이뤄졌다면 양쪽 서버에 같은 항목이 들어가 있어야 합니다.
방화벽과 관련해선... 혹시 방화벽 차단/허용 조건에 두 서버에서 달라질 수 있는 조건(인터페이스 이름 등)이 들어있는지 확인해보실 수 있을 것 같습니다.
그 이상은 저도 잘...^^a
"$PWD `date`"는 작성자 서명입니다. "내 계정" 메뉴 => "편집" 탭 => "Signature settings" 항목에서 설정하실 수 있습니다.
$PWD `date`
/proc/net/igmp 을 해보았는데 reporter가 틀리네요.
답변감사합니다.
/proc/net/igmp 을 해보았는데 아래와 같이 Reporter 부분이 틀린데 이것이 문제 일수 있을까요?
<안되는쪽서버> Idx Device : Count Querier Group Users Timer Reporter 4 eth2 : 2 V2 FB0000E0 1 0:00000000 1 010000E0 1 0:00000000 0
<되는 서버> 4 eth1 : 5 V3 3E3625E9 1 0:00000000 0 3D3625E9 2 0:00000000 0 473625E9 1 0:00000000 0 FB0000E0 1 0:00000000 0 010000E0 1 0:00000000 0 ~
방화벽은 iptables 에서 stop 으로 꺼버린상태입니다.
감사합니다.
안 되는 쪽에 항목이 두 개만 있네요. 제 PC에서도
안 되는 쪽에 항목이 두 개만 있네요. 제 PC에서도 '따로 프로그램을 안 돌렸을 때 기본적으로' 항목이 두 개 보입니다.
제 PC에서는 멤버십 조인 하고 나면 항목이 하나 더 추가됩니다.
Reporter가 0이 아니고 1인 건 저도 잘...-_-a
기본 그룹 주소가 224.0.0.251, 224.0.0.1... 사용하고자 하는 멀티캐스트 그룹 주소는 233.37.54.61, 62, 71이지 않나요?
"V3"가 아니라 "V2"가 나오는 것도 좀 이상하네요. 혹시 안 되는 쪽 서버 커널이 IGMPv2만 지원하는 오래된 버전인 건 아닐까요? (멀티캐스트) 라우터가 IGMPv3만 지원하고 서버가 IGMPv2만 지원하는 건 아닐까 싶기도 합니다.
$PWD `date`
흠 혹시 이게 문제일수있나요?
아직 해결을 못했습니다.
혹시 아래 화면에서보면 Metric정보가 0과 1로 서로 다르게 나오는데 이게 문제 일수가 있나요?
Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.246.0 * 255.255.255.0 U 0 0 0 eth1 172.40.1.0 * 255.255.255.0 U 0 0 0 eth3 10.200.30.0 * 255.255.255.0 U 0 0 0 eth0
eth1 Link encap:Ethernet HWaddr 00:1F:29:0D:0A:71 inet addr:192.168.246.173 Bcast:192.168.246.255 Mask:255.255.255.0 inet6 addr: fe80::21f:29ff:fe0d:a71/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:711920 errors:0 dropped:0 overruns:0 frame:0 TX packets:2076 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:182926572 (174.4 MiB) TX bytes:107163 (104.6 KiB) Interrupt:19 Memory:fe560000-fe580000
흠 Metric 0 ,1 이게 문제일수있나요?
아직 해결을 못했습니다.
혹시 아래 화면에서보면 Metric정보가 0과 1로 서로 다르게 나오는데 이게 문제 일수가 있나요?
-Router 명령어 실행 화면 : Metric 0-
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.246.0 * 255.255.255.0 U 0 0 0 eth1
172.40.1.0 * 255.255.255.0 U 0 0 0 eth3
10.200.30.0 * 255.255.255.0 U 0 0 0 eth0
-ifconfig 실행시 화면 : Metric 1-
eth1 Link encap:Ethernet HWaddr 00:1F:29:0D:0A:71
inet addr:192.168.246.173 Bcast:192.168.246.255 Mask:255.255.255.0
inet6 addr: fe80::21f:29ff:fe0d:a71/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:711920 errors:0 dropped:0 overruns:0 frame:0
TX packets:2076 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:182926572 (174.4 MiB) TX bytes:107163 (104.6 KiB)
Interrupt:19 Memory:fe560000-fe580000
감사합니다.
echo 3 > /proc/sys/net/ipv4/conf/eth2/force_igmp_version 으로 3으로
echo 3 > /proc/sys/net/ipv4/conf/eth2/force_igmp_version 으로 3으로 변경하였는데도 proc/net/igmp 파일을 열어보니 그대로 v2로 나오는데 왜 안바뀌는걸까요? eth1도 재기동 하였는데 안 바뀌네요.. ㅡ.ㅡ
되는 서버와 안 되는 서버의 커널 버전이 같나요?
되는 서버와 안 되는 서버의 커널 버전이 같나요? 지금까지 말씀으로 짐작하건데 안 되는 쪽 서버 커널이 IGMPv3를 지원하지 않는 더 오래된 버전인 게 아닌가 싶습니다.
그 상태에서 멀티캐스트 라우터가 IGMPv3만 지원하는 거라면 왜 패킷 수신이 안 되는지가 설명됩니다. 그걸 검증하시려면 tcpdump 같은 패킷 캡처 프로그램으로 IGMP 패킷을 들여다보시면 될 것 같습니다.
잘 되는 쪽 서버에서는 아마 다음과 같은 식으로 패킷이 보이지 싶습니다.
1. 라우터에서 뿌리는 IGMP query v3
2. (직후) 서버에서 보내는 IGMP report v3
안 되는 쪽 서버는 혹시 다음과 같은 식으로 패킷이 보이지 않을까 찍어봅니다.
1. 라우터에서 뿌리는 IGMP query v3
2. (앞의 패킷과 무관한 간격으로) 서버에서 보내는 IGMP report v2
정리하자면, 저 같으면 다음 사항을 확인해보겠습니다.
1. 두 서버에서 각각 IGMP 패킷이 어떻게 오가고 있는지 확인
2. 되는 서버와 안 되는 서버의 커널 버전이 동일한지 여부 확인
3. 안 되는 서버 커널이 IGMPv3를 지원하는 버전인지 여부 확인
4. 멀티캐스트 라우터가 IGMPv2를 지원하게 설정 가능한지 여부 확인
$PWD `date`
답변 정말 감사드립니다.
답변 정말 감사드립니다. 조금씩 해결이 되가는거같습니다.
현재 안되는쪽 서버의 커널이 더 높고, 64비트 리눅스를 설치하였습니다. (되는쪽 서버는 32비트 리눅스 입니다.
지금 문제는 V2를 V3로 설정이 안되는것입니다. 서버를 다시 켜도 바뀌지 않는게 이상하네요...
하나 이상한 점을 발견한 것이 답변해주신것과 같은 현상이 일어나고 있는거 같습니다.
1. 라우터에서 뿌리는 IGMP query v3
2. (앞의 패킷과 무관한 간격으로) 서버에서 보내는 IGMP report v2
아래와 같은 현상이 계속 일어나고 있는 것처럼 보입니다.
안되는 서버
[root@realneuron ~]# uname -a
Linux realneuron 2.6.35.6-45.fc14.x86_64 #1 SMP Mon Oct 18 23:57:44 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux
[root@realneuron ~]# cat /proc/net/igmp
Idx Device : Count Querier Group Users Timer Reporter
3 eth1 : 2 V2
FB0000E0 1 0:00000000 1
010000E0 1 0:00000000 0
[root@realneuron ~]# tcpdump -i eth1 igmp
16:57:24.299441 IP 192.168.246.2 > 224.0.0.1: igmp query v2
16:57:27.182361 IP 192.168.246.173 > 224.0.0.251: igmp v2 report 224.0.0.251
16:58:24.703454 IP 192.168.246.2 > 224.0.0.1: igmp query v2
16:58:34.054303 IP 192.168.246.173 > 224.0.0.251: igmp v2 report 224.0.0.251
----------------------------------------------------------------------------------------------------------
되는 서버
[root@Neuron ~]# uname -a
Linux Neuron 2.6.29.4-167.fc11.i586 #1 SMP Wed May 27 17:14:37 EDT 2009 i686 i686 i386 GNU/Linux
[root@Neuron ~]# cat /proc/net/igmp
Idx Device : Count Querier Group Users Timer Reporter
4 eth1 : 2 V3
FB0000E0 1 0:00000000 0
010000E0 1 0:00000000 0
[root@Neuron ~]# tcpdump -i eth1 igmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
16:57:35.779411 IP 192.168.246.2 > 224.0.0.1: igmp query v2
16:58:36.178119 IP 192.168.246.2 > 224.0.0.1: igmp query v2
16:59:36.580178 IP 192.168.246.2 > 224.0.0.1: igmp query v2 010000E0 1 0:00000000 0
질문
구경하다가질문을합니다
Igmp를사용하여멀티캐스트를활용하는실제적인예들이어떤게있나요?
여기질문자분의상황도궁금하네요
자기실력이 좋다고 느껴지는건 공부를 안하고 있다는 신호.
해결을 하셨나 모르겠네요. 지난 주말에 잉여거리다 몇
해결을 하셨나 모르겠네요. 지난 주말에 잉여거리다 몇 가지 확인해본 것들이 있어서 정리해 봅니다.
가상머신을 하나 만들어서 Fedora Core 14를 설치했습니다. 그리고 이웃 호스트에서 멀티캐스트 패킷을 쏴서 수신이 되는지 확인해 봤습니다. 가난한 살림 탓에 멀티캐스트 라우터가 없어서 IGMP 동작에 대한 건 확인해 보지 못했습니다. 대신 force_igmp_version 등에 대한 걸 좀 확인해 봤습니다.
1. /proc/net/igmp에 "V3"가 아니라 "V2"라고만 나타나는 문제
IGMP 버전을 제어하는 proc 파일은 /proc/sys/net/ipv4/conf/DEV/force_igmp_version입니다. 그런데... /proc/sys/net/ipv4/conf/all/force_igmp_version도 영향을 줍니다. eth1 쪽에 3이라고 설정하더라도 all 쪽에 2라고 설정돼 있으면 V2를 사용합니다.
/proc/sys/net/ipv4/conf/all/force_igmp_version의 기본값은 0입니다. 그게 2로 돼 있다면 누군가 sysctl 설정 등을 통해 net.ipv4.conf.all.force_igmp_version이나 net.ipv4.conf.default.force_igmp_version 항목의 값을 바꿔줘서일 겁니다.
2. 현재 IGMP 동작 상황
10월 14일에 올리신 패킷 덤프를 보면 IGMP query의 버전이 2입니다. 따라서 1번 문제는 사실 별 문제가 아닌 셈입니다.
즉, IGMP 수준에서는 별 이상이 없어 보입니다.
3. 방화벽 열기
수신측 호스트에서 과감하게 INPUT 체인 처음에 모든 패킷을 ACCEPT 하는 규칙을 추가했습니다. 멀티캐스트 패킷만을 허용하도록 조건을 상세히 지정해주는 게 맞지만... 그냥, 잉여로운 테스트니까요...;;;
4. 패킷 전달 테스트
http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/topic/rzab6/xmulticast.htm 페이지에 있는 예시 프로그램을 필요한 부분만 수정해서 사용했습니다. 멀티캐스트 주소는 225.1.1.1입니다.
수신측 호스트에서 예시 프로그램을 실행하기 전 /proc/net/igmp의 내용물은 다음과 같습니다.
proc 설정이 V2로 돼 있는 경우:
Idx Device : Count Querier Group Users Timer Reporter 1 lo : 1 V2 010000E0 1 0:00000000 0 2 eth0 : 2 V2 FB0000E0 1 0:00000000 1 010000E0 1 0:00000000 0proc 설정이 V3로 돼 있는 경우:
Idx Device : Count Querier Group Users Timer Reporter 1 lo : 1 V3 010000E0 1 0:00000000 0 2 eth0 : 2 V3 FB0000E0 1 0:00000000 0 010000E0 1 0:00000000 0예시 프로그램을 실행하여 bind() 및 setsockopt(IP_ADD_MEMBERSHIP) 하고서 recv() 하며 기다릴 때의 /proc/net/igmp 내용물은 다음과 같습니다.
proc 설정이 V2로 돼 있는 경우:
Idx Device : Count Querier Group Users Timer Reporter 1 lo : 1 V2 010000E0 1 0:00000000 0 2 eth0 : 3 V2 010101E1 1 0:00000000 1 FB0000E0 1 0:00000000 1 010000E0 1 0:00000000 0proc 설정이 V3로 돼 있는 경우:
Idx Device : Count Querier Group Users Timer Reporter 1 lo : 1 V3 010000E0 1 0:00000000 0 2 eth0 : 3 V3 010101E1 1 0:00000000 0 FB0000E0 1 0:00000000 0 010000E0 1 0:00000000 0버전 설정에 상관없이 listen 하는 멀티캐스트 주소(225.1.1.1) 항목이 추가되는 걸 알 수 있습니다. 이 상태에서 이웃 호스트에서 225.1.1.1로 멀티캐스트 패킷을 쏘면 버전 설정에 상관없이 패킷을 잘 수신합니다. 패킷 덤프는 다음과 같은 식입니다.
20:18:17.114382 IP (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto UDP (17), length 38) 10.0.2.10.35070 > 225.1.1.1.5555: UDP, length 10이상이 확인 결과입니다. 뭔가 지금까지 생각지 않았던 다른 데 원인이 있는 게 아닐까 싶습니다.
$PWD `date`
너무나 친절한 답변 정말 감사드립니다.
너무나 친절한 답변 정말 감사드립니다.
올려주신 답변을 보고 많이 배웠습니다.
아무래도 저희가 쓰는 4포트 이더넷 카드 문제일수 있을거 같아서 방금 이더넷 카드를 사왔습니다.
오랜시간동안 신경써주셔서 정말 감사드립니다~!
행복하세요!!!
댓글 달기