Gelöst:SLP/Novell NW-Policy based- und Multicast-Routing

[cambies]

Hallo, ich bin mal wieder verzweifelt:

Wir haben zwei Subnets: 192.168.1.0/24 und 192.168.2.0/24 .
Wir arbeiten mit Novell Netware, und die Anmeldung am eDirectory erfolgt über Multicasts an 224.0.1.22 und 224.0.1.35. Nun befinden sich alle Directory-Agent-Server in 192.168.1.0er-Netz und und die User aus dem 2. Subnet können sich über SLP nicht anmelden, da as Multicast nicht vom 2 ins 1-Netz und wieder zurück geroutet wird.

Nun habe ich zusätzl. zwei Routen angelegt mit:

Ziel Mask Rtg.-Tag Router
224.0.0.0 224.0.0.0 1 192.168.1.254
224.0.0.0 224.0.0.0 2 192.168.2.254
224.0.0.0 224.0.0.0 0 0.0.0.0

Zum Zuteilen der Routen gibt es auch zwei Firewallregeln:

Von Nach Rtg.-Tag. Prio Aktion
192.168.1.0 224.0.0.0 1 2 allow
192.168.2.0 224.0.0.0 2 2 allow
Beliebig Beliebig 0 1 allow ALLOW-VPN-ROUTING
Beliebig Beliebig 0 0 deny cond. über Default-Route[DENY_ALL]

Nun mach ich ein trace + ip-r firewall und sehe folgendes:

Code: Alles auswählen

[Firewall] 2010/04/20 17:37:31,500
Packet matched rule ALLOW-VPN-ROUTING
DstIP: 224.0.1.22, SrcIP: 192.168.1.106, Len: 99, DSCP/TOS: 0x00
Prot.: UDP (17), DstPort: 427, SrcPort: 427

[IP-Router] 2010/04/20 17:37:31,500
IP-Router Rx (LAN-1, BUERO-NETZ, RtgTag: 0): 
DstIP: 224.0.1.22, SrcIP: 192.168.1.106, Len: 99, DSCP/TOS: 0x00
Prot.: UDP (17), DstPort: 427, SrcPort: 427
Network unreachable (no route) => Discard

Nun wundert mich, warum die Firewall nicht gewillt ist, meinem schönen Multicast-Paket ein entsprechendes Routing-Tag zu verpassen, sondern die in diesem Fall "falsche" Regel ALLOW_VPN_ROUTING heranzieht.
Wenn ich die Prioritäten auf 1 setze, passiert das gleiche.

Nachdem ich 'zig IPTV-Posts durchgeackert habe, wo allerdings Multicast/IGMP zwischen LAN und WAN geroutet wird, bin ich eigentlich der meinung, die Konfig ist so okay, oder habe ich einen Denkste-Fehler?

Die ganze Sache ist ziemlich dringend und über jeden hilfreichen Hinweis wäre ich dankbar.

Schöne Grüsse, cambies

[cambies]

Nicht mehr ganz so verzweifelt: Ich habs gelöst.

Der erste, zugegebenermaßen peinliche Grund war, dass ich bei Zuteilung des Routing-Tags über die FW-Regeln die Multicast-Adressen 224.0.0.0 mit der Subnetmask 255.0.0.0 gefiltert habe, währenddessen die Route in der Routing-Tabelle korrekt mit der Subnetmaske 240.0.0.0 versehen war. So konnte die FW-Regel nie zutreffen.

Ein zweiter Fehlergrund liegt in der Route selbst. Konfiguriert war

FW-Regeln:
--------------
Von 192.168.2.1 nach 224.0.0.0 -> Routing-Tag: 2
Von 192.168.1.1 nach 224.0.0.0 -> Routing-Tag: 1

Routing-Einträge:
---------------------
224.0.0.0 (RtgTag: 2) -> GW: 192.168.2.254
224.0.0.0 (RtgTag: 1) -> GW: 192.168.1.254

Entgegen dem herkömmlichen Routing, wo ich wie oben bei den "falschen" Routing-Einträgen als NEXT-HOPP das eigene Gateway angebe, muß jedoch das Gateway des Zielnetzes angegeben werden.
Die Routing-Einträge müssen also wie folgt lauten:

224.0.0.0 (RtgTag: 2) -> GW: 192.168.1.254
224.0.0.0 (RtgTag: 1) -> GW: 192.168.2.254

Was macht man jedoch bei 3 Subnetzen, was ja z.B. bei IGMP wahrscheinlich ist?

Für die NetWare-Problematik ist nun das letzte Hindernis nur noch die Windows-Firewall unter XP, die offensichtlich bei den Multicast-Paketen aus einem anderen Netzsegment zuschlägt.

Abschalten hilft , kann aber nicht Sinn der Sache sein!

Gruß, cambies