Skip to main content

Er zijn vast niet veel mensen die een Juniper SRX gebruiken als eigen router, maar goed wie appelen vaart, die appelen eet…

Ik plak hier stukjes van de configuratie waarmee de volgende zaken op de SRX worden ingesteld:

  • poort configuratie,
  • source NAT voor verkeer richting IPTV domein,
  • statische routes,
  • IGMP en PIM configuratie,
  • security zones
  • security policies

Op mijn SRX gebruik ik poort ge-0/0/2 voor de verbinding met de NTU:

   ge-0/0/2 {
description "Naar NT kastje";
promiscuous-mode;
flexible-vlan-tagging;
mtu 1550;
unit 4 {
vlan-id 4;
family inet {
dhcp {
no-dns-install;
lease-time 3600;
retransmission-attempt 60;
metric 150;
vendor-id IPTV_RG;
force-discover;
requested-options {
121;
}
}
}
}
unit 6 {
encapsulation ppp-over-ether;
vlan-id 6;
}
}

vlan4 gebruikt DHCP. niet alle opties hier zijn noodzakelijk. 

vlan 6 wordt gebruikt om een PPPoE verbinding op te zetten voor het internet.  de interface MTU is op 1550 gezet, omdat KPN specificeert dat de PPP payload MTU 1500 is. 

interface voor PPPoE instellingen: 

pp0 {
unit 0 {
description "KPN Glasvezel internet";
ppp-options {
pap {
local-name internet;
local-password "internet";
passive;
}
}
pppoe-options {
underlying-interface ge-0/0/2.6;
idle-timeout 0;
auto-reconnect 10;
client;
ppp-max-payload 1500;
}
family inet {
negotiate-address;
}
}
}

PIM maakt gebruik van rendevous points (RP) en de pim-to-igmp proxy heeft er een nodig op de firewall. daarvoor maken we een loopback interface. Het IP-adres van deze interface is alleen relevant voor deze firewall:

lo0 {
unit 0 {
family inet {
address 10.0.0.216/32;
}
}
}

Tot zover interfaces. Deze post gaat vooral over IPTV, dus internet-spul bespreek ik niet.

De router is voor KPN een eindpunt - dat houdt in dat we NAT moeten toepassen zodat KPN servers aanvragen krijgen van een adres dat ze kunnen vinden. De source-nat regel is hier eenvoudig gehouden:

 show configuration security nat source
session-persistence-scan;
rule-set nat-inet {
from zone trust untrust ];
to interface pp0.0;
rule match-any {
match {
source-address d 192.0.2.0/24 192.168.178.0/24 ];
}
then {
source-nat {
interface;
}
}
}
}
rule-set nat-iptv {
from zone trust;
to interface ge-0/0/2.4;
rule itv {
match {
source-address 192.0.2.0/24;
}
then {
source-nat {
interface;
}
}
}
}

192.0.2.0/24 is niet echt het netwerk waar mijn clients in zitten 😉 deze regels doen wat in linux ‘masquerade’ heet.

Er is nog iets nodig op de Juniper, en dat is het uitschakelen van een alg (een application helper) voor rtsp:

gerritb@fugu> show configuration security
alg {
rtsp disable;
}

Statische routes zijn nodig omdat Juniper SRX geen routes via DHCP optie 121 binnen krijgt. We vragen het wel, maar kunnen er niets mee.. Niet dat ik denk dat KPN heel snel een nieuw segment nodig heeft, met een /21 subnet kun je 2000 servers voorzien van een IP, en zoveel kanalen zijn er niet. De volgende routes heb ik in verschillende posts en pagina's gezien.

gerritb@fugu> show configuration routing-options
static {
route 0.0.0.0/0 next-hop pp0.0;
route 213.75.112.0/21 next-hop ge-0/0/2.4;
route 217.166.224.0/22 next-hop ge-0/0/2.4;
}
multicast {
pim-to-igmp-proxy {
upstream-interface ge-0/0/2.4;
}
}

De default gaat het internet op, en twee prefixes gaan naar het IPTV vlan. 

Extra belangrijk is de ‘pim-to-igmp-proxy’ regel. Hierbij geef je aan dat de router geen PIM verbinding heeft met upstream (kpn) routers, en in plaats daarvan via IGMP moet leren van upstream servers. Hiermee komen we bij een stukje aan waar ondergetekende een tijdje aan het spoorzoeken is geweest.

gerritb@fugu> show configuration protocols pim
rp {
local {
address 10.0.0.216;
}
}
interface ge-0/0/2.4 {
accept-remote-source;
}
interface irb.110;
interface all {
mode sparse;
}

gerritb@fugu> show configuration protocols igmp
query-interval 110;
robust-count 2;
accounting;
interface irb.110;
interface ge-0/0/2.4 {
immediate-leave;
promiscuous-mode;
}
interface irb.100;
interface all {
version 3;
immediate-leave;
}

Layer-3 apparatuur zoals routers en firewalls gebruiken PIM om te bepalen waar multicast vandaan komt en naartoe gaat. Layer-2 gebruikt IGMP. PIM is de kapitein, IGMP de machinist. 

Het statement ‘promiscuous-mode’  onder interface ge-0/0/2.4 is nodig omdat de multicast sources niet in het subnet van het vlan zitten. Zonder die optie gaat een ontvanger wel een IGMP join sturen, en krijg je ook een beeld terug. Maar de juniper gaat niet reageren op IGMP membership queries aan de KPN zijde. Het effect is dat de KPN router de stream afbreekt na 4 min 20 s (260 sec: 2x125 seconden query timeout + 10 sec response timeout).  afin, met deze config zit je goed…

Een SRX is een firewall. We moeten nog iets met security zones doen. In de volgende configuratie zitten de KPN interfaces in een zone ‘untrust’, en de zone met clients in ‘trust’. De juniper moet luisteren naar IGMP verkeer in beide zones.

gerritb@fugu> show configuration security zones
security-zone untrust {
interfaces {
ge-0/0/2.4 {
host-inbound-traffic {
system-services {
dhcp;
traceroute;
ping;
}
protocols {
pim;
igmp;
}
}
}
pp0.0 {
host-inbound-traffic {
system-services {
ping;
traceroute;
}
}
}
}
}
security-zone trust {
interfaces {
lo0.0 {
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
}
}
}

En dan, om ervoor te zorgen dat we kunnen multicasten, policies van zone untrust naar zone trust:

gerritb@fugu> show configuration security policies from-zone untrust to-zone trust
policy permit-mcast {
match {
source-address any;
destination-address mcast-announce-net;
application any;
}
then {
permit;
}
}

ik heb een address-book entry ‘mcast-announce-net’ gemaakt die het hele class-D segment omvat: 224.0.0.0/4. Dat kan krapper, maar ik vind het een beperkt risico.

Natuurlijk moeten clients ook iets naar het IPTV segment kunnen sturen. In mijn configuratie mogen clients van alles doen op een paar dingen na, maar die policies mag je zelf bepalen.

 

Ik hoop dat ik hier iemand een plezier mee doe. Voor inspiratie heb ik veel gehad aan https://netwerkje.com/routed-iptv, en enkele topics op dit forum en het forum van tweakers.net.  

Zo staat ergens dat je 217.166.0.0/16 en 10.0.0.0/8 richting IPTV moet sturen, hoewel ik die routes niet zag in de fritzbox diag. 10.0.0.0/8 zou voor firmware multicast zijn, en zelf zie ik ook niets van 217.166.224.0/22 komen. 

Bij de VIP5202 box liep ik tegen een probleem aan dat ik niet kon terugkijken, pauzeren of opnames bekijken. De exacte oorzaak weet ik niet, behalve dat in de huidige setup de box niet het IPTV adres kon bepalen (dus het adres dat de router van KPN krijgt op VLAN4), te zien in ‘instellingen’, ’informatie’, er staat dan “0.0.0.0”.  Dit merk je ook als de box opnieuw start en bij 85% voortgang een foutmelding met code 562 (verkeerd IP adres) krijgt.  Als iemand weet hoe een VIP5202 bepaalt wat het IPTV adres van de router is, hoor ik dat graag. Mijn ITV+ box heeft hier geen problemen mee, dus ik kan er mee leven..

 

 

 

 

 

 

Hi @gerritbij, welkom bij onze community. 

Wat leuk en ontzettend handig dat je dit op een rij hebt gezet en hier hebt geplaatst. Dankjewel! Hier kunnen andere klanten veel aan hebben. 

Voor andere meelezers met een eigen router, neem vooral ook onderstaande topic door en stel daar gerust vragen over het instellen ervan. 

 


@gerritbij dank voor je post alhoewel ik geen SRX gebruik zie ik dat je gedegen kennis bezit. Kan jij uit de Fritz Diag halen wat de subnetten zijn in de IGMP proxy? Ik doel op jouw onderstaande tekst:

 

Zo staat ergens dat je 217.166.0.0/16 en 10.0.0.0/8 richting IPTV moet sturen, hoewel ik die routes niet zag in de fritzbox diag. 10.0.0.0/8 zou voor firmware multicast zijn, en zelf zie ik ook niets van 217.166.224.0/22 komen. 


@gerritbij dank voor je post alhoewel ik geen SRX gebruik zie ik dat je gedegen kennis bezit. Kan jij uit de Fritz Diag halen wat de subnetten zijn in de IGMP proxy?

Nee, geen subnetten. De routetabel voor IPTV krijgt alleen 213.75.112.0/21 binnen. In de diagnose zat wel een multicast stream met source (217.166.226.140, 224.0.252.140), en ook op de SRX komen TV streams uit dat subnet. Ik denk dat de IGMP proxy in de fritzbox niet kijkt naar de oorsprong van een multicast stream.

 


Reageer