MikroTik에서 LG IPTV 설정하기
이 글은 AI LLM(GPT)의 도움을 받아 설정 과정을 정리한 내용입니다. 답변을 그대로 적용한 것은 아니며, 직접 검토하고 시험한 결과를 바탕으로 작성했지만 일부 잘못된 내용이 있을 수 있으니 참고용으로 봐주시기 바랍니다.
MikroTik을 메인 라우터로 사용하면서 LG IPTV 셋톱박스를 연결했는데, 셋톱박스가 IP는 정상적으로 받지만 방송 화면이 나오지 않는 문제가 있었다.
처음에는 단순히 “IPTV는 VLAN 설정이 필요한가?” 정도로 생각했지만, 실제로 확인해보니 이 환경에서는 VLAN보다 IGMP Proxy, IGMP Snooping, alternative-subnets, 방화벽 설정이 핵심이었다.
특히 이번 구성에서는 IPTV 셋톱박스가 MikroTik에 직접 연결된 것이 아니라, 거실의 ASUS 공유기 AP 모드 장비 뒤에 연결되어 있었다. 그래도 ASUS가 AP 모드로 동작하고 있었기 때문에, 최종적으로는 MikroTik에서 IPTV multicast를 처리하는 방식으로 해결할 수 있었다.
문서 출처
이 문서의 저작권을 특별히 주장할 의도는 없지만, 작성자와 출처 확인을 위해 최초 공개 주소를 함께 남겨두려고 한다. 글에는 오류가 있을 수 있으며, 별도 공지 없이 수정될 수 있다. 다른 경로에서 이 글을 보았다면 가능하면 원문 또는 최신 버전을 확인해주기 바란다.
이 문서의 최신 버전은 https://hacked.mx/posts/mikrotik-lg-iptv 에 게시되어 있다.
1. 최종 네트워크 구성
현재 네트워크 구성은 대략 다음과 같다.
인터넷 회선
↓
MikroTik
↓
현관 단자함의 분배기/스위치
↓
거실 첫 번째 랜포트
↓
ASUS 공유기(AP 모드)
├─ Wi-Fi / AiMesh
└─ LAN 포트 → LG IPTV 셋톱박스
처음에는 거실에 있는 두 번째 랜포트에 IPTV 셋톱박스를 직접 연결하려고 했다. 하지만 해당 포트는 인터넷 연결이 정상적으로 되지 않는 것 같아서 사용하지 않았다.
결국 IPTV 셋톱박스는 거실 첫 번째 랜포트에 연결된 ASUS 공유기의 LAN 포트에 연결했다.
여기서 중요한 점은 ASUS 공유기가 라우터 모드가 아니라 AP 모드라는 것이다. AP 모드에서는 ASUS가 NAT 라우터 역할을 하지 않고, 거의 브리지/스위치처럼 동작한다. 따라서 ASUS 뒤에 연결된 IPTV 셋톱박스도 MikroTik의 DHCP에서 IP를 받고, MikroTik의 LAN bridge 아래에 있는 장비처럼 동작한다.
즉, 이 구성에서 IPTV 설정의 핵심은 ASUS가 아니라 MikroTik이다.
2. 기존에는 왜 됐을까?
기존에는 ASUS 공유기를 메인 라우터로 사용했고, ASUS의 IPTV 관련 기능을 사용했다. 이때는 IPTV가 정상적으로 동작했다.
하지만 MikroTik을 메인 라우터로 변경하고 ASUS를 AP 모드로 바꾸면서 상황이 달라졌다.
ASUS가 메인 라우터일 때는 ASUS의 IPTV 기능이 내부적으로 다음과 같은 작업을 처리했을 가능성이 있다.
IGMP Proxy
IGMP Snooping
Multicast forwarding
통신사 IPTV preset
필요한 multicast source 대역 허용
하지만 ASUS가 AP 모드가 되면 이런 라우팅/프록시 처리를 담당하지 않는다.
결국 이 역할을 MikroTik에서 직접 설정해줘야 한다.
3. 초기 증상
IPTV 셋톱박스를 ASUS AP의 LAN 포트에 연결하면 IP는 정상적으로 받았다.
MikroTik에서 DHCP lease를 확인하면 다음과 같이 보인다.
/ip dhcp-server lease print
예시:
20 D 192.168.30.222 XX:XX:XX:XX:XX:XX dhcp-main bound
즉, 셋톱박스가 네트워크에 아예 연결되지 않는 상태는 아니었다.
인터넷 IP도 정상적으로 할당되고 있었다.
하지만 실시간 방송 화면이 나오지 않았다.
이런 경우 단순 DHCP나 인터넷 연결 문제가 아니라, IPTV 실시간 방송에 사용되는 multicast 처리 문제를 의심해야 한다.
4. MikroTik bridge 확인
먼저 MikroTik에서 LAN bridge 구성을 확인했다.
/interface bridge print
출력은 다음과 같았다.
Flags: D - dynamic; X - disabled, R - running
0 R ;;; LAN Bridge (No VLAN, ARP reply-only)
name="bridge1" mtu=auto actual-mtu=1500 l2mtu=1592
protocol-mode=rstp fast-forward=yes
igmp-snooping=no
vlan-filtering=no
LAN bridge 이름은 bridge1이었다.
그리고 처음에는 igmp-snooping=no 상태였다.
IPTV 셋톱박스는 ASUS AP 뒤에 연결되어 있지만, ASUS가 AP 모드이므로 결과적으로 이 bridge1 아래에 있는 장비처럼 동작한다.
5. IGMP Snooping 활성화
IPTV는 multicast 트래픽을 사용한다. IGMP Snooping이 꺼져 있으면 multicast 트래픽이 LAN 전체로 불필요하게 퍼질 수 있다.
특히 이번 구성처럼 IPTV 셋톱박스가 ASUS AP 뒤에 있는 경우, multicast가 Wi-Fi나 AiMesh 쪽으로 불필요하게 퍼질 가능성도 있다. 따라서 bridge에서 IGMP Snooping을 켜는 것이 좋다.
/interface bridge
set bridge1 igmp-snooping=yes
확인은 다음 명령으로 한다.
/interface bridge print
bridge1에 igmp-snooping=yes가 보이면 된다.
6. WAN과 LAN 인터페이스 확인
IGMP Proxy를 설정하기 전에 WAN 인터페이스와 LAN bridge 이름을 확인했다.
/interface print
출력은 다음과 같았다.
# NAME TYPE ACTUAL-MTU
0 R WAN ether 1500
1 RS ether2 ether 1500
2 S ether3 ether 1500
3 S ether4 ether 1500
4 ether5 ether 1500
5 R bridge1 bridge 1500
6 R lo loopback 65536
이 환경에서는 다음처럼 정리할 수 있다.
인터넷/WAN 쪽: WAN
내부 LAN bridge: bridge1
따라서 IGMP Proxy에서는 다음 구조가 된다.
upstream = WAN
downstream = bridge1
7. IGMP Proxy 설정
먼저 IGMP Proxy의 quick-leave를 활성화했다.
/routing igmp-proxy
set quick-leave=yes
그 다음 IGMP Proxy interface를 추가한다.
/routing igmp-proxy interface
add interface=WAN upstream=yes
add interface=bridge1 upstream=no
여기서 주의할 점이 있다. MikroTik RouterOS에서는 downstream=yes가 아니라 upstream=no 방식으로 downstream 역할을 지정한다.
처음에 아래처럼 입력하면 오류가 날 수 있다.
add interface=bridge1 downstream=yes
오류 예:
expected end of command
따라서 bridge 쪽은 아래처럼 넣으면 된다.
add interface=bridge1 upstream=no
설정 확인:
/routing igmp-proxy interface print detail
정상이라면 다음과 비슷하게 보인다.
Flags: X - disabled, I - inactive, D - dynamic; U - upstream
0 U interface=WAN threshold=1 alternative-subnets="" upstream=yes
1 interface=bridge1 threshold=1 alternative-subnets="" upstream=no
여기까지 설정한 뒤 셋톱박스를 재부팅했지만, 아직 방송 화면은 나오지 않았다.
8. MFC 상태 확인
IPTV에서 실시간 채널을 켠 상태에서 MikroTik의 multicast forwarding cache를 확인했다.
/routing igmp-proxy mfc print
처음에는 이런 항목이 보였다.
GROUP SOURCE UPSTREAM-INTERFACE
239.255.255.250 192.168.30.226 *FFFFFFFF
239.255.255.250은 보통 SSDP/UPnP 장비 탐색에 사용되는 multicast 주소다. IPTV 방송 채널이라고 보기는 어렵다.
실제 채널을 켜고 다시 확인하니 다음과 같은 항목이 나타났다.
GROUP SOURCE UPSTREAM-INTERFACE
233.18.145.141 115.89.8.X *FFFFFFFF
233.x.x.x는 IPTV multicast group으로 보이고, 115.89.8.x는 방송 source로 보인다.
즉, 셋톱박스의 IPTV multicast 요청 자체는 MikroTik까지 들어오고 있었다.
하지만 문제는 UPSTREAM-INTERFACE가 WAN이 아니라 *FFFFFFFF로 나온다는 점이었다.
이 상태는 MikroTik이 해당 multicast source를 어느 upstream interface에서 받아야 하는지 제대로 판단하지 못하고 있다는 의미로 볼 수 있다.
9. 방화벽 설정
MikroTik 방화벽에서 WAN input을 막고 있다면 IGMP Proxy가 정상 동작하지 않을 수 있다.
기존 방화벽에는 다음과 같은 규칙이 있었다.
chain=input action=drop in-interface=WAN
따라서 이 drop 규칙보다 위에 IGMP 허용 규칙을 추가해야 한다.
/ip firewall filter
add chain=input in-interface=WAN protocol=igmp action=accept comment="Allow IPTV IGMP from WAN"
또한 실제 방송 multicast UDP는 라우터 자신이 받는 것이 아니라 WAN에서 LAN으로 전달되어야 한다. 따라서 input이 아니라 forward chain에서 허용해야 한다.
/ip firewall filter
add chain=forward in-interface=WAN out-interface=bridge1 protocol=udp dst-address=224.0.0.0/4 action=accept comment="Allow IPTV multicast UDP to LAN"
규칙 순서는 중요하다.
위 규칙들은 기존 drop 규칙보다 위에 있어야 한다.
확인은 다음 명령으로 한다.
/ip firewall filter print
10. 핵심 해결: alternative-subnets
방화벽을 열어도 mfc print에서는 여전히 *FFFFFFFF가 보였다.
233.18.145.141 115.89.8.X *FFFFFFFF
여기서 해결의 핵심은 alternative-subnets였다.
MikroTik IGMP Proxy는 multicast source가 일반 라우팅/인터페이스 판단과 맞지 않으면, 해당 source를 upstream으로 제대로 인정하지 못하는 경우가 있다.
현재 LG IPTV 방송 source가 115.89.8.x 대역에서 오고 있었기 때문에, WAN upstream interface에 이 대역을 명시했다.
/routing igmp-proxy interface
set [find interface=WAN] alternative-subnets=115.89.8.0/24
확인:
/routing igmp-proxy interface print detail
정상적으로 적용되면 다음처럼 보인다.
interface=WAN threshold=1 alternative-subnets=115.89.8.0/24 upstream=yes
그 후 셋톱박스를 전원 재부팅하고 다시 확인했다.
/routing igmp-proxy mfc print
결과가 다음처럼 바뀌었다.
GROUP SOURCE UPSTREAM-INTERFACE ACTIVE-DOWNSTREAM-INTERFACES
233.18.145.140 115.89.8.A WAN bridge1
233.18.145.129 115.89.8.B WAN bridge1
233.18.145.132 115.89.8.C WAN bridge1
이제 *FFFFFFFF가 아니라 WAN으로 잡혔고, downstream도 bridge1로 표시되었다.
이 상태에서 일부 채널 화면이 나오기 시작했다.
11. 일부 채널만 나오는 문제
처음에는 이제 다 해결된 줄 알았다. 하지만 실제로 채널을 돌려보니 일부 채널만 나오고, 일부 채널은 여전히 나오지 않았다.
예를 들면 9번 채널은 나오는데 10번 채널은 안 나오고, 11번 채널은 다시 나오는 식이었다.
안 나오는 채널을 켠 상태에서 다시 MFC를 확인했다.
/routing igmp-proxy mfc print
출력 중 다음 줄이 보였다.
GROUP SOURCE UPSTREAM-INTERFACE
233.14.202.16 1.222.8.X *FFFFFFFF
기존에 추가한 source 대역은 115.89.8.0/24였다.
하지만 안 나오는 채널은 source가 1.222.8.X였다.
즉, 채널마다 IPTV multicast source 대역이 달랐던 것이다.
처음에는 테스트로 넓게 열어보았다.
/routing igmp-proxy interface
set [find interface=WAN] alternative-subnets=115.89.8.0/24,1.222.0.0/16
이후 안 나오던 채널들도 정상적으로 나오기 시작했다.
다만 /16은 범위가 넓기 때문에, 실제 운영에서는 확인된 source 대역만 좁게 넣는 편이 낫다.
현재 확인된 source가 1.222.8.2였으므로 /24로 좁혀서 다음처럼 설정할 수 있다.
/routing igmp-proxy interface
set [find interface=WAN] alternative-subnets=115.89.8.0/24,1.222.8.0/24
설정 후 여러 채널을 돌려보면서 mfc print에서 *FFFFFFFF가 더 이상 나오지 않으면 이 설정으로 충분하다.
12. 왜 채널마다 source IP 대역이 다를까?
관찰된 내용을 보면 일부 채널은 115.89.8.x 대역에서 오고, 다른 채널은 1.222.8.x 대역에서 왔다.
정확한 통신사 내부 구성은 알 수 없지만, 추정해보면 다음과 같은 구조일 수 있다.
지역 방송/지역 우선 채널
→ 지역 headend 또는 지역 송출 장비
→ 115.89.8.x
전국 공통 채널/일반 채널
→ 중앙 송출 장비 또는 다른 IPTV source
→ 1.222.8.x
실제로 처음에 잘 나오던 일부 채널은 지역 방송이 들어간 공중파 계열이었고, 나오지 않던 채널은 지역과 직접 관계없는 채널들이었다.
따라서 115.89.8.0/24만 허용했을 때는 해당 source를 사용하는 일부 채널만 나오고, 1.222.8.x source를 사용하는 채널은 *FFFFFFFF로 남으면서 화면이 나오지 않았던 것으로 볼 수 있다.
이 부분은 통신사 내부 IPTV망 구조에 따라 달라질 수 있으므로, 다른 지역이나 다른 회선에서는 source 대역이 다를 수도 있다.
13. 최종 설정 예시
현재 환경에서 최종적으로 사용한 설정은 다음과 같다.
Bridge IGMP Snooping
/interface bridge
set bridge1 igmp-snooping=yes
IGMP Proxy
기존에 interface 항목이 이미 있는 경우:
/routing igmp-proxy
set quick-leave=yes
/routing igmp-proxy interface
set [find interface=WAN] alternative-subnets=115.89.8.0/24,1.222.8.0/24 upstream=yes
set [find interface=bridge1] upstream=no
처음부터 추가하는 경우:
/routing igmp-proxy
set quick-leave=yes
/routing igmp-proxy interface
add interface=WAN upstream=yes alternative-subnets=115.89.8.0/24,1.222.8.0/24
add interface=bridge1 upstream=no
방화벽
/ip firewall filter
add chain=input in-interface=WAN protocol=igmp action=accept comment="Allow IPTV IGMP from WAN"
/ip firewall filter
add chain=forward in-interface=WAN out-interface=bridge1 protocol=udp dst-address=224.0.0.0/4 action=accept comment="Allow IPTV multicast UDP to LAN"
방화벽 규칙은 기존 drop 규칙보다 위에 있어야 한다.
14. 확인 방법
설정 후에는 IPTV 셋톱박스를 전원 재부팅한다.
셋톱박스 전원 어댑터 분리
→ 10초 정도 대기
→ 다시 연결
→ 부팅 완료 후 실시간 채널 확인
IGMP Proxy interface 상태 확인:
/routing igmp-proxy interface print detail
정상 예:
interface=WAN threshold=1 alternative-subnets=115.89.8.0/24,1.222.8.0/24 upstream=yes
interface=bridge1 threshold=1 alternative-subnets="" upstream=no
실시간 채널을 켠 상태에서 MFC 확인:
/routing igmp-proxy mfc print
정상 예:
GROUP SOURCE UPSTREAM-INTERFACE ACTIVE-DOWNSTREAM-INTERFACES
233.18.145.129 115.89.8.X WAN bridge1
233.14.202.16 1.222.8.X WAN bridge1
문제 상황 예:
233.14.202.16 1.222.8.X *FFFFFFFF
이 경우 해당 SOURCE 대역을 alternative-subnets에 추가해야 한다.
예를 들어 source가 1.222.9.34라면 다음처럼 추가할 수 있다.
/routing igmp-proxy interface
set [find interface=WAN] alternative-subnets=115.89.8.0/24,1.222.8.0/24,1.222.9.0/24
테스트 목적으로는 잠깐 넓게 열어볼 수도 있다.
/routing igmp-proxy interface
set [find interface=WAN] alternative-subnets=0.0.0.0/0
하지만 정상 동작 확인 후에는 실제 필요한 대역만 좁혀서 넣는 편이 좋다.
15. ASUS AP 뒤에 IPTV를 연결할 때 주의할 점
이번 구성에서는 IPTV 셋톱박스가 MikroTik에 직접 연결된 것이 아니라 ASUS AP의 LAN 포트에 연결되어 있었다.
이 구성이 가능했던 이유는 ASUS가 AP 모드로 동작했기 때문이다.
MikroTik bridge1
↓
단자함 분배기/스위치
↓
ASUS AP
↓
IPTV 셋톱박스
ASUS가 AP 모드이면 IPTV 셋톱박스는 MikroTik DHCP에서 IP를 받고, 같은 LAN bridge 아래에 있는 것처럼 동작한다. 따라서 IPTV multicast 처리는 MikroTik의 IGMP Proxy에서 담당한다.
다만 AP나 중간 스위치가 multicast를 제대로 전달하지 못하는 경우에는 같은 MikroTik 설정을 해도 동작하지 않을 수 있다. 이 경우 ASUS 쪽에서 다음과 같은 옵션을 확인해볼 필요가 있다.
IGMP Snooping
Multicast enhancement
Wireless multicast forwarding 관련 옵션
IPTV 관련 옵션
하지만 이 환경에서는 ASUS AP 뒤에서도 multicast가 정상적으로 전달되었고, MikroTik 설정만으로 IPTV가 정상 동작했다.
16. DHCP lease에 IPTV 메모 남기기
셋톱박스가 어떤 IP를 받았는지 관리하기 위해 DHCP lease에 comment를 남겨두면 편하다.
먼저 lease를 확인한다.
/ip dhcp-server lease print
예:
20 D 192.168.30.222 XX:XX:XX:XX:XX:XX dhcp-main bound
동적 lease에 바로 comment를 남길 수도 있다.
/ip dhcp-server lease
set 20 comment="LG IPTV"
다만 장기적으로 관리하려면 static lease로 바꾸는 것이 좋다.
/ip dhcp-server lease
make-static [find mac-address=XX:XX:XX:XX:XX:XX]
set [find mac-address=XX:XX:XX:XX:XX:XX] comment="LG IPTV"
확인:
/ip dhcp-server lease print where comment="LG IPTV"
17. 설정 백업
설정이 정상 동작하면 export를 남겨두는 것이 좋다.
/export file=iptv-working
생성되는 파일은 다음과 같다.
iptv-working.rsc
WinBox에서는 Files 메뉴에서 해당 파일을 다운로드할 수 있다.
설정을 정리하거나 추가 실험을 하기 전에는 한 번 더 export를 남겨두면 안전하다.
/export file=iptv-working-before-cleanup
/export는 사람이 읽을 수 있는 설정 파일이라 비교하거나 일부 설정만 복구할 때 유용하다.
필요하다면 같은 장비 전체 롤백용으로 binary backup도 추가로 저장할 수 있다.
/system backup save name=iptv-working-before-cleanup
다만 설정을 사람이 보고 정리하거나 일부만 되돌릴 목적이라면 /export가 더 유용하다.
18. 정리
이번 문제는 IPTV 셋톱박스가 IP를 못 받는 문제가 아니었다. DHCP는 정상적으로 동작했고, 셋톱박스는 MikroTik에서 192.168.30.x 대역의 IP를 받았다.
문제는 실시간 방송에 필요한 multicast 처리가 MikroTik에서 제대로 되지 않았던 것이다.
처음에는 IGMP Proxy만 설정하면 될 줄 알았지만, 실제로는 다음 요소들이 모두 필요했다.
1. bridge1에 IGMP Snooping 활성화
2. IGMP Proxy에서 WAN을 upstream, bridge1을 downstream으로 설정
3. 방화벽에서 WAN IGMP와 multicast UDP 허용
4. WAN upstream에 LG IPTV multicast source 대역을 alternative-subnets로 추가
특히 가장 중요한 단서는 다음 출력이었다.
233.x.x.x 115.89.8.x *FFFFFFFF
또는:
233.x.x.x 1.222.8.x *FFFFFFFF
UPSTREAM-INTERFACE가 *FFFFFFFF로 보이면 MikroTik이 해당 multicast source를 WAN upstream으로 제대로 인식하지 못하고 있는 상태다.
이때 alternative-subnets에 source 대역을 추가하면 다음처럼 정상화된다.
233.x.x.x 115.89.8.x WAN bridge1
233.x.x.x 1.222.8.x WAN bridge1
이번 환경에서 최종적으로 확인된 source 대역은 다음 두 개였다.
115.89.8.0/24
1.222.8.0/24
따라서 최종 설정은 다음과 같이 정리할 수 있다.
/interface bridge
set bridge1 igmp-snooping=yes
/routing igmp-proxy
set quick-leave=yes
/routing igmp-proxy interface
set [find interface=WAN] alternative-subnets=115.89.8.0/24,1.222.8.0/24 upstream=yes
set [find interface=bridge1] upstream=no
그리고 방화벽:
/ip firewall filter
add chain=input in-interface=WAN protocol=igmp action=accept comment="Allow IPTV IGMP from WAN"
add chain=forward in-interface=WAN out-interface=bridge1 protocol=udp dst-address=224.0.0.0/4 action=accept comment="Allow IPTV multicast UDP to LAN"
다른 지역이나 다른 LG IPTV 회선에서는 source 대역이 다를 수 있다.
따라서 무작정 같은 값을 넣기보다는, 안 나오는 채널을 켠 상태에서 아래 명령으로 source를 확인하는 것이 가장 확실하다.
/routing igmp-proxy mfc print
*FFFFFFFF로 표시되는 source가 있다면 해당 대역을 alternative-subnets에 추가하면 된다.
MikroTik은 일반 공유기처럼 IPTV 설정이 자동으로 준비되어 있지는 않지만, 대신 multicast 흐름을 직접 확인하면서 문제를 추적할 수 있다. 이번 경우도 원인을 알고 나면 설정 자체는 비교적 명확했다.