Hello!
> In mrouted, is it enough to just translate the outgoing announcements?
Not to translate, but to block all of them and to prepare new single one
with source address set to public masquerading address (i.e. address
of router).
[ Here, one problem with masq in 2.2 is that it does not allow to use
preassigned address for masquerading. It was possible via "ip rule",
but I was reported that subsequent changes to ip_masq broke this facility.
]
> at first. As simple as possible. Without modifications incoming multicast
Sure, because it does not require any work of your mrouted.
The problems will start only in sparse mode.
> works but outgoing is blocked because the source is internal address.
> Simple masq does no work - as expected.
...
> Which places in the kernel should be modified? Some reroute somewhere?
I do not know exactly. Honestly.
Conscience flow follows:
The key problem is that multicast packets usually arrive on _some_
interface and we forward them along tree constructed by mrouting protocol
(S_internal,G). When a packet is masqueraded, it looks as sourced by _router_,
tree is different and interface is undefined. As minimum, you have
to make query to mrouting daemon after the packet is rewritten
to get route for (S_masq,G) and find a way to cheat it and
to pass reasonable "input" interface (f.e. that one, which mrouted
will consider as iif for (S_masq,G)). Also, you have to make precautions
not to cause looping (compare this with the case, when (S_masq,G) is
sourced by router itself, these packets should be delivered to S_true
network, unlike masqueraded ones).
Summarizing, the solution will be so fragile and unnatural, that
I would prefer not to make this in ipmr. Essentially, when you use
ipchains to masquerade it looks much easier to flood packets over
ALL THE INTERFACES and filter redundant ones statically with ipchains.
Grr..., it looks like utter crap, but I guess it is exaclty what
people want when talking about "masquerading" multicasts.
Seems, the task is solved naturally, when mrouter can be sure,
that S_masq cannot be used to originate local traffic
(i.e. NAT, rather than masq) and all the packets translated to S_masq
are origined by single LAN. Do you see?
One internal multicast LAN (excluding router itself) <-> one address.
The address can be told to kernel to provide congruence of trees
for LAN and that S_masq. Seems, it is easy with netfilter, but not
in 2.2.
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
