Classless static route in SSG-5

[Volk]

Had mijn vraag al in Systeembeheerders en hun problemen - deel 33 gedropt, maar dat mocht dus niet Dus dan maar hier:

rfolkers schreef op vrijdag 23 mei 2014 @ 23:08:
Iemand enig idee hoe je op een SSG-5 of ScreenOS in het algemeen een classless static route toevoegt aan je DHCP server?
We hebben op een nevenlocatie 2 routers in hetzelfde subnet, ideetje van de Voip leverancier, en voor 1 bepaald subnet moet verkeer over router B, dus:
0.0.0.0 > 10.0.9.254
10.0.8.x > 10.0.9.253

Een route op de Juniper kan natuurlijk, maar dan gaan we de mist in met onze hopcount en RDP struikelt hierover. Constante disconnects etc.
Daarom willen we graag de routetabel vullen middels DHCP, wat via Windows-DHCP simpel is, maar via de betreffende SSG is er nauwelijks informatie beschikbaar. Het betreft DHCP option 33, 121 of eventueel 249.
Het enige wat ik tot nu toe heb kunnen vinden is een Juniper KB artikel waarin we in ASCII iets moeten toevoegen, maar zoals gezegd is de informatie summier. Daarom hoop ik op wat hands-on ervaring hier

[Verwijderd]

Uit dat zelfde artikel maak ik eigenlijk op dat het gewoon niet kan. Wegens geen support voor extended ASCII.

Dus de enige weg om dit op te lossennis om een route op de juniper toe te voegen. Eventueel de 2de router in een nieuwe zone te droppen.

Rdp moet perfect overweg kunnen met meerdere hops. Dus dat zal je ook verder moeten troubleshooten dan.

[TeGek]

Verwijderd schreef op zaterdag 24 mei 2014 @ 13:49:
Uit dat zelfde artikel maak ik eigenlijk op dat het gewoon niet kan. Wegens geen support voor extended ASCII.

Dus de enige weg om dit op te lossennis om een route op de juniper toe te voegen. Eventueel de 2de router in een nieuwe zone te droppen.

Rdp moet perfect overweg kunnen met meerdere hops. Dus dat zal je ook verder moeten troubleshooten dan.

Behalve dat dit het juiste antwoord is, is het ook officieel het enige RFC compliant antwoord .

RDP moet inderdaad "oneindig" hops aan kunnen. Wat wel een issue kan zijn is dat je split-routing hebt door bijvoorbeeld VVRP of verkeerde ingesteld PBR / Source routing. Source routing moet je zo veel mogelijk vermijden. Als je de destination IPs/range weet kan je gewoon een destination route aanmaken over de trust-vr met als gateway de andere router. Wij hebben in hetzelfde schuitje gezeten met een andere leverancier

[ Voor 14% gewijzigd door TeGek op 24-05-2014 18:30 ]

[pablo_p]

Een situatie die voor problemen kan zorgen in een opstelling met 2 'gateways' in een netwerk met een specifieke static route op een van de devices, is dat de verkeersstroom asymmetrisch. Stateful devices (typisch: firewalls) droppen verkeersstromen als ze maar een richting van de verkeersstroom zien.
Technishe oplossingen hiervoor zijn:
- de default getaway op een niet-stateful device zetten
- op de default gateway 'icmp redirects' activeren. Dan leren de clients de betere uitgangen voor bepaalde verkeersstromen

Persoonlijk vind ik beide ongewenste oplossingen. Als je het simpel en deterministisch wilt houden, is er maar een actieve gateway IP adres in een subnet. Twee gateways in een netwerk lijkt een makkelijke, snelle, goedkope oplossing, maar is lastig in onderhoud en daarmee duur en onbetrouwbaar. Niet doen dus.

[Paul]

Kun je het verkeer van je VOIP-provider niet termineren op router A? Nieuwe interface aanmaken en daar de WAN van router B op? Of, als dat ADSL is, je ADSL-modem in bridge ertussen...

En vervolgens PBR instellen, alles naar 10.0.8.0/24 over interface B, de rest over interface A?

Overigens, als het een VOIP-provider is ga ik er vanuit dat het om telefoons gaat. Hebben die niet hun eigen VLAN?

[pablo_p]

Paul schreef op maandag 26 mei 2014 @ 16:06:
En vervolgens PBR instellen, alles naar 10.0.8.0/24 over interface B, de rest over interface A?

Ik snap dat niet. Als je verkeer naar een subnet naar interface B stuurt en een default route naar interface A hebt, waarom zou je dan policy based routing nodig hebben? Dat is toch gewoon routeren?

Ik zie algemeen in het forum hier een voorkeur voor het inzetten policy-based routing. Ik vind dat een techniek die je zo min mogelijk moet gebruiken. In mijn optiek kan je het (bijna) altijd voorkomen en ik streef erna het niet te gebruiken. Ik probeer alles zo simpel mogelijk te houden en PBR maakt het altijd minder duidelijk.

De oplossing van de Voice router achter de SSG is een prima oplossing. Een multilayer switch logisch tussen de clients en de SSG&voice router zetten is ook een rechttoe-rechtaan oplossing, die geen trucs vereist.

[Paul]

pablo_p schreef op dinsdag 27 mei 2014 @ 11:17:
Ik snap dat niet. Als je verkeer naar een subnet naar interface B stuurt en een default route naar interface A hebt, waarom zou je dan policy based routing nodig hebben? Dat is toch gewoon routeren?

Klopt. Alleen in veel (met name consumenten)routers stel je dat in onder het kopje PBR

Soms is het wat minder straight forward, zo heb ik wel eens bij klanten terug moeten vallen op "alles naar UDP/5060 moet over interface B ipv A" maar in dit geval is het inderdaad gewoon een static route.