Hei nyt tämä Sonera tai Telia ihan sama kumpi ja IPTV ongelma on ratkaistu, niin pitkälle, että data lähti kulkemaan. Nyt sekin liikenne kulkee EdgeRouter Pro:n läpi. Melkin suljin itseni ulos, koska asetin sillan samaan porttiin jossa kaikki muu verkko oli, mutta onneksi oli konfiguroituna kaikki EdgeRouter Pro:n portit valmiiksi, niin löytyi helposti yksi reikä mistä pääsin uudestaan sisään korjaamaan tekemiäni virheitä. Silta on nyt asetettu EdgeRouter Pron:n porttiin eth2, jossa on IPTV boksi suoraan kytkettynä.
Koodi:
interfaces {
bridge br1 {
description "IPTV bridge"
multicast enable
}
ethernet eth0 {
address dhcp
description WAN
dhcp-options {
default-route update
default-route-distance 210
name-server no-update
}
duplex auto
firewall {
in {
name WAN_IN
}
local {
name WAN_LOCAL
}
}
speed auto
}
ethernet eth1 {
address dhcp
bridge-group {
bridge br1
}
description "WAN 2"
dhcp-options {
default-route update
default-route-distance 210
name-server no-update
}
duplex auto
firewall {
in {
name WAN_IN
}
local {
name WAN_LOCAL
}
}
speed auto
}
ethernet eth2 {
bridge-group {
bridge br1
}
description "Telia IPTV box"
duplex auto
firewall {
in {
modify balance
}
}
speed auto
}
ethernet eth3 {
address 196.168.75.1/24
description "Test Network 4"
duplex auto
firewall {
in {
modify balance
}
}
speed auto
}
ethernet eth4 {
address 192.168.74.1/24
description "Test Network 3"
duplex auto
firewall {
in {
modify balance
}
}
speed auto
}
ethernet eth5 {
address 192.168.73.1/24
description "Test Network 2"
duplex auto
firewall {
in {
modify balance
}
}
speed auto
}
ethernet eth6 {
address 192.168.72.1/24
description "Test Network 1"
duplex auto
firewall {
in {
modify balance
}
}
speed auto
}
ethernet eth7 {
address 192.168.71.1/24
bridge-group {
}
description Local
duplex auto
firewall {
in {
modify balance
}
}
speed auto
}
loopback lo {
}
}
IPTV boksi on käynnistetty kokonaan uudestaan ja se hyväksyi uuden konfiguraation ja lähti toimimaan, eli homma pelittää. Modeemi jonka kautta liikenne kulkee on EdgeRouter Pro:n eth1 liittimessä kiinni, eli se liikenne kulkee nyt eth1 ja eth2 liittimen välillä. eht2 liittimessä on kiinni IPTV boksi.
Minulle jäi 3 paikkaa vapaaksi EdgeRouter Pro:sta 5 muuta on jo varattu. Nämä on yllätyksiä joihin ei osaa varautua, ellei tee samaa, kuin minä. 2 modeemia, 2 jatko yhteyttä seuraavaan paikkaan ja 1 IPTV boksi niin siinä se viisi paikkaa meni jo reitittimestä tavallaan 4 porttia on aika turhia, mutta ne on varattu testikäyttöön joista se ensimmäinen on käytössä.
Suljin itseni ulos, kun tein eka väärän konfiguraation ja annoin käskyn commit, niin heti alkoi iptv:ssä kuva pätkimään ja nykimään. Siinä kohtaa tajusin, että nyt tein yhdistelmän useasta verkosta samaksi, joka ei toimi koska ne sotii keskenään. Sen takia aina tallennan vanhan konfiguraation jo ennen, kuin alan muuttelemaan mitään asetuksia, että reset nappi ja vanhan konfiguraation lataus palauttaisi takaisin vanhan tilanteen, missä ei ole muutoksia tehty vielä. Sama eht7:n, niin kaikki sekoaa, koska siellä on koko muu verkko ja niin kävi. eht7 perässä on valokuitu linkki EdgeSwitch 16 XG:n, johon olen siirtänyt kaikki sisäverkon laitteet, eli on pakko jättää tuo IPTV boksi omaan yksinäisyytensä ja antaa sille silta modeemille jonka kansa se juttelee.
Set ja delete on niitä millä noita konfiguraatio komentoja joilla lähdetään muuttelee tai poistamaan. Heti, kun CLI:n pääsee käsiksi, niin eka komento on configure ja seuraava komento on edit liitteellä se osa jota aletaan konfiguroimaan. ?-merkki on se jolla saa apuja komentovaihtoehdoista joka vaiheessa, kun komentoa kirjoittaa, jos ? merkki ei anna palautetta, niin on todennäköisesti kirjoitusvirhe ohjauskomennoissa. Delete komentoa joutui käyttää koska mokasin ja se poisti eht7 liittimisestä tuon br1 sillan, jonka olin mennyt tekemään ja heti välähti, että se pitää ohjata ihan omaan porttiin mikä ei ole yhteydessä muihin laitteisiin mitenkään. Komento show näyttää sen mitä on asetettu - ja + merkkien perässä on ne poistettavat tai lisättävät, kun annetaan komento commit, niin muutos on hyväksytty ja se otetaan käyttöön heti sen jälkeen. Save on seuraava komento, koska se tallentaa muutoksen pysyväksi.
IPTV siis toimii, mutta oletan että sen sillan IP-liikennettä hoitaa se modeemi toisessa päässä, eli jos siellä on käytössä DHCP, niin se jakaa, myös sillan toiseen päähän IP-numeroitaan ja tämän takia koko verkkoni sekosi.
Minulla on ihan oma DHCP palvelin jota hoitaa Windows Server ja se on pakollinen paha minun windows maailmassa.
Konfiguraatiossa näkyy nyt sitten kaikki se mitä IPTV Boksi vaatii ja se oli helposti eristetty omaksi systeemiksi. Poistin DHCP:n käytöstä liittimestä johon IPTV boksin kytken ja sen näkee konfiguraatiosta.
Nyt iloitsin liian aikaisin Load-balancing lakkasi heti toimimasta ja yhteyttä ei saa IPTV-purkin modeemiin reitittimen kautta. Konfiguraation pystyy siis tekemään käsin komentorivien avulla ja se toimii IPTV:n osalta, mutta konfiguraatio ei pysy, koska reititin muuttaa sen seuraavan käynnistyksen yhteydessä erilaiseksi, eikä se konfiguraatio toimi ja eth1 liitin on kadonnut kokonaan. Ei siis toimi EdgeRouter Pro:n kanssa, vaikka dataa päivän verran kulki IPTV purkille ja TV-kuva näkyi. Kokeilin vielä käsin lisätä eth1 liittimen komentorivien kautta, niin sama homma uudelleenkäynnistyksen jälkeen, eli eth1 hävisi automaattisesti pois. Saattaa toimia ER-X reitittimen kanssa, mutta ei EdgeRouter Pro:n kanssa, eli tuo automaattinen korjaus konfiguraatiossa sotkee kaiken. Olin tallentanut vanhan konfiguraation ennen muutoksia tietokoneen kovalevylle. Piti palata vanhaan konfiguraatioon.
Luin ohjeita tuolta, mutta tuo ei toimi minun EdgeRouter Pro reitittimellä.
Edge router X for IPTV (telia) | Ubiquiti Community
--- Uusi yritys, koska edellinen vaihtoehto ei toiminut ---
Tutkin tätä EdgeRouter Pro:n ongelmaa tässä jo pari päivää ja nyt on aika erikoinen konfiguraatio joka toimii, mutta on aika kummallista, että joutuu uhraamaan näin monta porttia, että saa IP-TV:n mukaan reitittimen portteihin ja liikenteeseen. Konfiguraatio ei nyt enää sekoa EdgeRouter Pro:n omien toimien seurauksena, kun konfiguraatio on tallennettu ja reititin käynnistetty uudestaan. Telian IPTV näkyy ja Telian IPTV toimii normaalisti samoilla asetuksilla, kuin Telian modeemissa, joka edelleen jakaa sille IP-numerot ja kaiken.
Silta on nyt asetettu eth2, eth3 ja eth4 portteihin ja ne näkee toinen toisensa.
Koodi:
firewall {
all-ping enable
broadcast-ping disable
group {
network-group PRIVATE_NETS {
network 192.168.0.0/16
network 172.16.0.0/12
network 10.0.0.0/8
}
}
ipv6-receive-redirects disable
ipv6-src-route disable
ip-src-route disable
log-martians disable
modify balance {
rule 10 {
action modify
description "do NOT load balance lan to lan"
destination {
group {
network-group PRIVATE_NETS
}
}
modify {
table main
}
}
rule 20 {
action modify
description "do NOT load balance destination public address"
destination {
group {
address-group ADDRv4_eth0
}
}
modify {
table main
}
}
rule 30 {
action modify
description "do NOT load balance destination public address"
destination {
group {
address-group ADDRv4_eth1
}
}
modify {
table main
}
}
rule 110 {
action modify
modify {
lb-group G
}
}
}
name WAN_IN {
default-action drop
description "WAN to internal"
rule 10 {
action accept
description "Allow established/related"
state {
established enable
related enable
}
}
rule 20 {
action drop
description "Drop invalid state"
state {
invalid enable
}
}
}
name WAN_LOCAL {
default-action drop
description "WAN to router"
rule 10 {
action accept
description "Allow established/related"
state {
established enable
related enable
}
}
rule 20 {
action drop
description "Drop invalid state"
state {
invalid enable
}
}
}
receive-redirects disable
send-redirects enable
source-validation disable
syn-cookies enable
}
interfaces {
bridge br0 {
aging 300
bridged-conntrack disable
hello-time 2
max-age 20
priority 32768
promiscuous disable
stp false
}
ethernet eth0 {
address dhcp
description WAN
dhcp-options {
default-route update
default-route-distance 210
name-server no-update
}
duplex auto
firewall {
in {
name WAN_IN
}
local {
name WAN_LOCAL
}
}
speed auto
}
ethernet eth1 {
address dhcp
description "WAN 2"
dhcp-options {
default-route update
default-route-distance 210
name-server no-update
}
duplex auto
firewall {
in {
name WAN_IN
}
local {
name WAN_LOCAL
}
}
speed auto
}
ethernet eth2 {
bridge-group {
bridge br0
}
description "IPTV Bridge Loop wire to eth1 port"
duplex auto
speed auto
}
ethernet eth3 {
bridge-group {
bridge br0
}
description "IPTV Bridge connection to Telia IPTV Box"
duplex auto
speed auto
}
ethernet eth4 {
bridge-group {
bridge br0
}
description "IPTV Bridge connection to Telia Modem"
duplex auto
speed auto
}
ethernet eth5 {
address 192.168.73.1/24
description "Test Network 2"
duplex auto
firewall {
in {
modify balance
}
}
speed auto
}
ethernet eth6 {
address 192.168.72.1/24
description "Test Network 1"
duplex auto
firewall {
in {
modify balance
}
}
speed auto
}
ethernet eth7 {
address 192.168.71.1/24
description Local
duplex auto
firewall {
in {
modify balance
}
}
speed auto
}
loopback lo {
}
}
load-balance {
group G {
exclude-local-dns disable
flush-on-active enable
gateway-update-interval 20
interface eth0 {
weight 67
}
interface eth1 {
weight 33
}
lb-local enable
lb-local-metric-change disable
}
}
port-forward {
auto-firewall enable
hairpin-nat enable
lan-interface eth5
lan-interface eth6
lan-interface eth7
rule 1 {
description "Destiny 2"
forward-to {
address 192.168.71.8
port 3074
}
original-port 3074
protocol udp
}
rule 2 {
description "Destiny 2"
forward-to {
address 192.168.71.8
port 3097
}
original-port 3097
protocol udp
}
rule 3 {
description "UniFi Controller Server"
forward-to {
address 192.168.71.8
port 8443
}
original-port 8443
protocol tcp
}
rule 4 {
description "UNMS Controller"
forward-to {
address 192.168.71.7
port 443
}
original-port 443
protocol tcp
}
rule 5 {
description "UNMS Controller"
forward-to {
address 192.168.71.7
port 80
}
original-port 81
protocol tcp
}
rule 6 {
description "UNMS NetFlow"
forward-to {
address 192.168.71.7
port 2055
}
original-port 12055
protocol tcp_udp
}
wan-interface eth0
}
service {
dhcp-server {
disabled false
hostfile-update disable
shared-network-name Test_Network_1 {
authoritative disable
subnet 192.168.72.0/24 {
default-router 192.168.72.1
dns-server 8.8.8.8
dns-server 8.8.4.4
lease 86400
start 192.168.72.2 {
stop 192.168.72.100
}
static-mapping amon-router {
ip-address 192.168.72.3
mac-address 00:02:b3:42:76:98
}
}
}
shared-network-name Test_Network_2 {
authoritative disable
subnet 192.168.73.0/24 {
default-router 192.168.73.1
dns-server 8.8.8.8
dns-server 8.8.4.4
lease 86400
start 192.168.73.2 {
stop 192.168.73.100
}
}
}
static-arp disable
use-dnsmasq disable
}
dns {
forwarding {
cache-size 150
listen-on eth5
listen-on eth6
listen-on eth7
}
}
gui {
http-port 80
https-port 443
older-ciphers enable
}
nat {
rule 5000 {
description "masquerade for WAN"
outbound-interface eth0
type masquerade
}
rule 5002 {
description "masquerade for WAN 2"
outbound-interface eth1
type masquerade
}
}
ssh {
port 22
protocol-version v2
}
suspend {
allow-domain 192.168.71.7
allow-ip [***Secret***]
redirect {
url http://[***Secret***]/crm/suspension/
}
}
unms {
connection wss://[***Secret***]:443+[********************Secret**********************************************]
}
}
system {
conntrack {
expect-table-size 4096
hash-size 4096
table-size 32768
tcp {
half-open-connections 512
loose enable
max-retrans 3
}
}
flow-accounting {
disable-memory-table
ingress-capture post-dnat
interface eth7
netflow {
enable-egress {
engine-id 51
}
engine-id 50
mode daemon
server 192.168.71.7 {
port 2055
}
timeout {
expiry-interval 60
flow-generic 60
icmp 60
max-active-life 60
tcp-fin 10
tcp-generic 60
tcp-rst 10
udp 60
}
version 9
}
syslog-facility daemon
}
host-name amon-router
login {
user amon {
authentication {
encrypted-password ****************
plaintext-password ****************
}
full-name "[**secret***]"
level admin
}
}
name-server 8.8.8.8
name-server 8.8.4.4
ntp {
server 0.ubnt.pool.ntp.org {
}
server 1.ubnt.pool.ntp.org {
}
server 2.ubnt.pool.ntp.org {
}
server 3.ubnt.pool.ntp.org {
}
}
offload {
hwnat disable
ipv4 {
forwarding disable
}
}
syslog {
global {
facility all {
level notice
}
facility protocols {
level debug
}
}
}
time-zone Europe/Helsinki
traffic-analysis {
dpi enable
export enable
}
}
traffic-control {
optimized-queue {
policy global
policy queues
}
}
Nyt näen mihin kaikkialle Telian IPTV kirjautuu EdgeRouter Pro:n web hallinnan kautta ja huomasin, että se käyttää Ruotsissa sijaitsevia Telian palvelimia. Samalla näen UNMS tallentamasta statistiikasta, että IPTV liikenne sisään on noin 9,3Mbps. Kauko ohjain levähti, mutta voin käyttää vanhaa iPhonea tähän hätään kauko ohjaimena. Mulla on kaksi kauko ohjainta, eli jossain on toinenkin ohjain ja hajonneen paristopesä on rikki. WLAN kautta voi ohjata IPTV boksia puhelin app:n kautta.
Ihan näin vaikeaa tuo ei pitäisi olla ja olettaisin, että on helpompikin vaihtoehto ja pienen EdgeRouter:n portit loppuu kesken, mutta tässä niitä on kahdeksan ja ne ei ole juurikaan muussa käytössä, niin ei tullut estettä, näin oudolle konfiguraatiolle. Tämä konfiguraatio pitää jo tallentaa tietokoneen kovalevylle, koska se on ensimmäinen Load-balancing konfiguraatio mihin on lisätty toimiva Telian IPTV yhteys, niin voin palata siihen uudelleen.
--- Muuta päivä on taas kulunut ---
Tuo viimeisin julkaisemani EdgeRouter Pro:n konfiguraatio poisti ongelman, jonka olin huomannut Destiny 2 pelissä, eli se heittelee jatkuvasti ulos pelistä, jos Telian yhteysmodeemi on kiinni. Syytä siihen miksi tuo ongelma loppui tai korjaantui en tiedä. Tietysti epäilen, että se olisi voinut johtua tekemästäni konfiguraatiosta, mutta en voi olla täysin varma. Load Balancing toimii, eli jos toisen operaattorin kaapelin ottaa irti, niin yhteydet toimii. Yhteydet siis vaihtuu, eli sekin puoli toimii. Destiny 2 pelissä on monella muullakin ollut ongelmia tiettyjen yhteysmodeemien kanssa. Nyt Telia modeemi on vain yhdellä kaapelilla EdgeRouter Pro:ssa kiinni ja IPTV liikenne kiertää EdgeRouter:n läpi ja sen jälkeen se tulee 30cm kaapelilla takaisin WAN 2 porttiin. Nyt Telian modeemi ongelma on helppo kytkeä irti, mutta IGMP konfiguraatiossa pimenee, myös TV, jos en yhtään siinä erehdy. Jopa pelinkehittäjät ovat yrittäneet ratkaista ongelmaa, mutta eivät ole sitä ehkä löytäneet, koska se on edelleen. Yhteysongelmat ovat siis hävinneet Telia puolelta ja tätä en osannut odottaa tai arvata. Sekin on mielessä, että modeemi hukkaisi dataa, koska se on alitehoinen, mutta EdgeRouter Pro ei sitä ole 100M yhteyksillä. Mulla meni aikoinaan hermot vanhoihin 100M pieniin reitittimiin, koska ne jumitti yhteydet ja sitten piti rakentaa tietokoneesta reititin.
Minulla on se IGMP konfiguraatiokin mielessä olen sitä kerran yrittänyt ja ensimmäisellä kerralla se ei onnistunut, eikä toiminut.
--- Testien tulos ---
Olen nyt testannut tarpeeksi tuota bridge konfiguraatiota. En lennä ulos peleistä mutta ne itkee jotain muita ongelmia. Telia modeemin Internet valo käy, joskus punaisella, eli oletan että se hukkaa dataa. TV-kuva IPTV puolella saattaa nytkähdellä joissain kohti. Nettiliikenne datan hukkaaminen aiheuttaa aina ongelman nettipeleissä, jos pelaisin suoraan tuon modeemin takana, niin siitä ei tulisi mitään ainakaan Destiny 2 pelissä. Toiminta varmuus selvästi on parantunut, koska lensin monesti ulos, jos load balancing konfiguraatiossa oli Telian Modeemi kytkettynä, eli se piti aina repiä irti fyysisesti ja nyt sitä ei ole tarvinnut enää tehdä. Se olikin ideana, jos toisen operaattorin yhteydet lakkaa toimimasta, niin se ongelma ei kosketa minua, koska kaikki yhteydet siirtyy toiselle operaattorille, koska yhteyden katkeaminen tunnistetaan reitittimessä. Vahalla työpaikalla piti ohjelmistotestaus puolella tehdä kahdennuksia, eli ehjä laite korvaa vikaantuneen ja sitä käytettiin varsinkin juuri tietoliikenteessä, että tiedon kulku ei katkea, jos yksi laite vikaantuu ja niitä toimitettiin lentokentille, eli olen ilmailupuolestakin perillä ja sinne pitäisi enemmän lisätä kahdennusta lentoasema puolen laitteisiin. Tällä pallon puoliskolla lähi idässä on juurikin tietyt lentoasemat hyvin hoidettu, koska ne eivät säästelleet ja haluttiin sen hetken parasta. Muutenkin kahdennus oli ollut jo pitkään käytössä. Load balancing on vähän eri juttu mutta se tekee samaan, kun toinen yhteys on menetetty ja tuosta kahdennuksesta se ei ole pakko jättää yhteen, vaan sitä voi olla vaikka neljä yhteyttä tai enemmän, jotka tekee samaa varmistusta.
