Multiple upstream interfaces?
120 views
Skip to first unread message
Doe Beg
Mar 17, 2016, 10:17:54 AM3/17/16
to Multicast Proxy
Hi Sebastian,
I saw in changelog that last version of mcproxy can work with a multiple upstream interfaces.
Is mcproxy able to handle 2 GRE tunnels as upstream interfaces and lets say
4 GRE tunnels as downstream interfaces?
upstream gre0 ---> ---> downstream gre2
\ / ---> downstream gre3
MCPROXY
/ \ ---> downstream gre4
upstream gre1 ---> ---> downstream gre5
Regards
Sebastian Wölke
Mar 18, 2016, 5:22:23 AM3/18/16
to Multicast Proxy
Hello,
Mcproxy can handle GRE tunnel on the upstream side as well as on the downstream side.
The answer to multiple upstream depends on your intended behavior.
The following behavior is easy feasible (here you have two independent multicast proxy instances)
Regards,
Sebastian
Mcproxy can handle GRE tunnel on the upstream side as well as on the downstream side.
The answer to multiple upstream depends on your intended behavior.
The following behavior is easy feasible (here you have two independent multicast proxy instances)
upstream gre0 ---> Mcproxy (instance 1) ---> downstream gre2
---> downstream gre3
---------------------------------------------------------------------------------
Could you describe your intended behavior?upstream gre1 ---> Mcproxy (instance 2) ---> downstream gre4
---> downstream gre5
On the other side, mixing and filtering data streams in some way between the upstream interfaces is buggy in the current version.
On the other side, mixing and filtering data streams in some way between the upstream interfaces is buggy in the current version.
Regards,
Sebastian
Doe Beg
Mar 25, 2016, 5:28:19 AM3/25/16
to Multicast Proxy
Hi,
thanks for answer...
The idea is to incorporate two multicast sources and forward them to several destinations.
-Receive multicast from two headends (for ex. 239.0.0.0/8 on gre0 and 232.0.0.0/8 on gre1)
-Forward both ranges to all downstream interfaces (gre2,3,4,5).
igmpproxy allows only one upstream interface, making this scenario impossible...
Regards
Doe
Sebastian Wölke
Mar 26, 2016, 11:57:56 AM3/26/16
to Multicast Proxy
Hi Doe,
ok, interesting. You are the first, who ask for multiple upstreams (besides the very special origin research topic of Mcproxy).
ok, interesting. You are the first, who ask for multiple upstreams (besides the very special origin research topic of Mcproxy).
The idea is to incorporate two multicast sources and forward them to several destinations.
Why have the sources be located at the upstream?
Or why cannot the sources be connected to downstream interfaces?
For example Mcproxy has three downstream interfaces (1,2,3) and no upstream interface.
Source 1 is connected to interface 1 and Source 2 is connected to interface 2.
If you have a Listener of Source 1 on interface 3, Mcproxy would forward the data of source 1 from interface 1 to interface 3.
The same for Source 2.
And of course this applies for further downstream interfaces (like gre 2,3,4,5) with listeners of Source 1 and 2.
Regards
Sebastian
Or why cannot the sources be connected to downstream interfaces?
For example Mcproxy has three downstream interfaces (1,2,3) and no upstream interface.
Source 1 is connected to interface 1 and Source 2 is connected to interface 2.
If you have a Listener of Source 1 on interface 3, Mcproxy would forward the data of source 1 from interface 1 to interface 3.
The same for Source 2.
And of course this applies for further downstream interfaces (like gre 2,3,4,5) with listeners of Source 1 and 2.
Regards
Sebastian
Doe Beg
Mar 26, 2016, 1:21:10 PM3/26/16
to Multicast Proxy
Hello Sebastian,
thanks for your time.
Why have the sources be located at the upstream?
Or why cannot the sources be connected to downstream interfaces?
I did not know that this is possible to do... I want to try!
For example Mcproxy has three downstream interfaces (1,2,3) and no upstream interface.
Source 1 is connected to interface 1 and Source 2 is connected to interface 2.
If you have a Listener of Source 1 on interface 3, Mcproxy would forward the data of source 1 from interface 1 to interface 3.
The same for Source 2.
And of course this applies for further downstream interfaces (like gre 2,3,4,5) with listeners of Source 1 and 2.
Okay, how to achieve this, if we have two interfaces that are GRE tunnels to the multicast sources and four interfaces that are GRE tunnels to the multicast destinations, how config file should look then?!
Regards
Doe
Sebastian Wölke
Mar 26, 2016, 1:46:55 PM3/26/16
to Multicast Proxy
Hello Doe,
here (https://tools.ietf.org/html/rfc4605) is the IGMP/MLD Proxy description, if you are interested and you want to know why this works.
I think it is easy written and quite short (for an RFC).
here (https://tools.ietf.org/html/rfc4605) is the IGMP/MLD Proxy description, if you are interested and you want to know why this works.
I think it is easy written and quite short (for an RFC).
Okay, how to achieve this, if we have two interfaces that are GRE tunnels to the multicast sources and four interfaces that are GRE tunnels to the multicast destinations, how config file should look then?!
This should be enough:
pinstance myProxy: ==> gre1 gre2 gre3 gre4 gre5 gre6;
You have to add the names of your downstream interfaces the downstream list.
Regards
Sebastian
pinstance myProxy: ==> gre1 gre2 gre3 gre4 gre5 gre6;
You have to add the names of your downstream interfaces the downstream list.
Regards
Sebastian
Message has been deleted
Doe Beg
Mar 27, 2016, 6:17:55 AM3/27/16
to Multicast Proxy
Hi Sebastian,
Last days I tested with one upstream if (gre0) and 4 downstream ifs (gre2,3,4,5), like this:
pinstance myProxy: gre0 ==> gre2 gre3 gre4 gre5;
and it perfectly worked.
Last night i tried what you suggested, also with one source, just to see how mcproxy will behave without upstream if.
This should be enough:
pinstance myProxy: ==> gre1 gre2 gre3 gre4 gre5 gre6;
I moved source if, gre0 to downstream list, like this:
pinstance myProxy: ==> gre0 gre2 gre3 gre4 gre5;
mcproxy -dvvs -f /us/local/etc/mcproxy.conf
Started listeners on gre2,3,4,5 but no data is forwarded from gre0...
Here is part of output:
@@##-- proxy instance myProxy (table:0,lifetime:26sec) --##@@
pinstance myProxy upstream * in rulematching first
pinstance myProxy upstream
pinstance myProxy upstream * out rulematching all
##-- simple multicast routing information base --##
##-- upstream interfaces --##
##-- downstream interface: gre0 (index:6) --##
querier version: IGMPv2
is querier: true
general query timer: 4sec
startup query count: 0
subscribed groups: 2
-- group address: 224.0.0.2
IGMPv2(242sec), EXCLUDE_MODE(242sec)
requested list(#0):
exclude_list(#0):
-- group address: 224.0.0.22
IGMPv2(239sec), EXCLUDE_MODE(239sec)
requested list(#0):
exclude_list(#0):
##-- downstream interface: gre2 (index:7) --##
querier version: IGMPv2
is querier: true
general query timer: 4sec
startup query count: 0
subscribed groups: 26
-- group address: 224.0.0.2
IGMPv2(243sec), EXCLUDE_MODE(243sec)
requested list(#0):
exclude_list(#0):
-- group address: 224.0.0.22
IGMPv2(240sec), EXCLUDE_MODE(240sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.4.2
IGMPv2(259sec), EXCLUDE_MODE(258sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.21.1
IGMPv2(259sec), EXCLUDE_MODE(1sec,0sec,1x)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.21.2
IGMPv2(255sec), EXCLUDE_MODE(255sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.21.8
IGMPv2(257sec), EXCLUDE_MODE(257sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.21.10
IGMPv2(259sec), EXCLUDE_MODE(259sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.21.16
IGMPv2(253sec), EXCLUDE_MODE(253sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.21.17
IGMPv2(259sec), EXCLUDE_MODE(254sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.21.22
IGMPv2(255sec), EXCLUDE_MODE(255sec,0sec,0x)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.21.23
IGMPv2(258sec), EXCLUDE_MODE(258sec,0sec,0x)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.21.24
IGMPv2(240sec), EXCLUDE_MODE(240sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.21.25
IGMPv2(259sec), EXCLUDE_MODE(259sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.21.26
IGMPv2(236sec), EXCLUDE_MODE(236sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.21.27
IGMPv2(255sec), EXCLUDE_MODE(255sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.21.28
IGMPv2(259sec), EXCLUDE_MODE(255sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.21.29
IGMPv2(255sec), EXCLUDE_MODE(255sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.21.30
IGMPv2(259sec), EXCLUDE_MODE(257sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.21.31
IGMPv2(239sec), EXCLUDE_MODE(239sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.21.33
IGMPv2(236sec), EXCLUDE_MODE(236sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.21.34
IGMPv2(256sec), EXCLUDE_MODE(256sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.21.35
IGMPv2(259sec), EXCLUDE_MODE(257sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.21.37
IGMPv2(259sec), EXCLUDE_MODE(259sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.21.39
IGMPv2(255sec), EXCLUDE_MODE(255sec,0sec,0x)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.21.40
IGMPv2(240sec), EXCLUDE_MODE(240sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.21.42
IGMPv2(259sec), EXCLUDE_MODE(254sec)
requested list(#0):
exclude_list(#0):
##-- downstream interface: gre3 (index:8) --##
querier version: IGMPv2
is querier: true
general query timer: 4sec
startup query count: 0
subscribed groups: 40
-- group address: 224.0.0.2
IGMPv2(251sec), EXCLUDE_MODE(251sec)
requested list(#0):
exclude_list(#0):
-- group address: 224.0.0.22
IGMPv2(246sec), EXCLUDE_MODE(246sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.3.1
IGMPv2(256sec), EXCLUDE_MODE(256sec,0sec,0x)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.4.1
IGMPv2(259sec), EXCLUDE_MODE(254sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.4.3
IGMPv2(255sec), EXCLUDE_MODE(255sec,0sec,0x)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.4.4
IGMPv2(255sec), EXCLUDE_MODE(255sec,0sec,0x)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.20.13
IGMPv2(255sec), EXCLUDE_MODE(255sec,0sec,0x)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.20.14
IGMPv2(257sec), EXCLUDE_MODE(257sec,0sec,0x)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.20.16
IGMPv2(259sec), EXCLUDE_MODE(255sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.20.22
IGMPv2(255sec), EXCLUDE_MODE(255sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.20.23
IGMPv2(257sec), EXCLUDE_MODE(257sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.20.25
IGMPv2(259sec), EXCLUDE_MODE(254sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.20.29
IGMPv2(259sec), EXCLUDE_MODE(1sec,0sec,1x)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.21.1
IGMPv2(259sec), EXCLUDE_MODE(255sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.21.2
IGMPv2(238sec), EXCLUDE_MODE(238sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.21.5
IGMPv2(254sec), EXCLUDE_MODE(254sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.21.10
IGMPv2(243sec), EXCLUDE_MODE(243sec,0sec,0x)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.21.11
IGMPv2(258sec), EXCLUDE_MODE(258sec,0sec,0x)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.21.21
IGMPv2(255sec), EXCLUDE_MODE(255sec,0sec,0x)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.21.22
IGMPv2(256sec), EXCLUDE_MODE(256sec,0sec,0x)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.21.24
IGMPv2(243sec), EXCLUDE_MODE(243sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.21.26
IGMPv2(256sec), EXCLUDE_MODE(256sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.21.27
IGMPv2(259sec), EXCLUDE_MODE(256sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.21.28
IGMPv2(244sec), EXCLUDE_MODE(244sec,0sec,0x)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.21.30
IGMPv2(258sec), EXCLUDE_MODE(0sec,0sec,0x)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.21.31
IGMPv2(236sec), EXCLUDE_MODE(236sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.21.32
IGMPv2(255sec), EXCLUDE_MODE(255sec,0sec,0x)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.21.33
IGMPv2(259sec), EXCLUDE_MODE(256sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.21.34
IGMPv2(259sec), EXCLUDE_MODE(259sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.21.35
IGMPv2(259sec), EXCLUDE_MODE(1sec,0sec,1x)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.21.41
IGMPv2(251sec), EXCLUDE_MODE(249sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.21.42
IGMPv2(259sec), EXCLUDE_MODE(259sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.22.2
IGMPv2(244sec), EXCLUDE_MODE(244sec,0sec,0x)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.22.5
IGMPv2(259sec), EXCLUDE_MODE(254sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.22.10
IGMPv2(256sec), EXCLUDE_MODE(256sec,0sec,0x)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.22.11
IGMPv2(241sec), EXCLUDE_MODE(241sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.22.12
IGMPv2(255sec), EXCLUDE_MODE(255sec,0sec,0x)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.22.14
IGMPv2(255sec), EXCLUDE_MODE(255sec,0sec,0x)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.22.29
IGMPv2(258sec), EXCLUDE_MODE(258sec,0sec,0x)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.41.1
IGMPv2(251sec), EXCLUDE_MODE(250sec)
requested list(#0):
exclude_list(#0):
##-- downstream interface: gre4 (index:9) --##
querier version: IGMPv2
is querier: true
general query timer: 4sec
startup query count: 0
subscribed groups: 13
-- group address: 224.0.0.2
IGMPv2(245sec), EXCLUDE_MODE(245sec)
requested list(#0):
exclude_list(#0):
-- group address: 224.0.0.22
IGMPv2(246sec), EXCLUDE_MODE(246sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.4.2
IGMPv2(259sec), EXCLUDE_MODE(255sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.21.1
IGMPv2(255sec), EXCLUDE_MODE(255sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.21.2
IGMPv2(258sec), EXCLUDE_MODE(0sec,0sec,0x)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.21.10
IGMPv2(259sec), EXCLUDE_MODE(254sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.21.24
IGMPv2(259sec), EXCLUDE_MODE(259sec,0sec,0x)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.22.3
IGMPv2(239sec), EXCLUDE_MODE(239sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.22.32
IGMPv2(259sec), EXCLUDE_MODE(256sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.29.1
IGMPv2(259sec), EXCLUDE_MODE(254sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.29.2
IGMPv2(251sec), EXCLUDE_MODE(246sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.29.3
IGMPv2(258sec), EXCLUDE_MODE(256sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.29.4
IGMPv2(259sec), EXCLUDE_MODE(259sec,0sec,0x)
requested list(#0):
exclude_list(#0):
##-- downstream interface: gre5 (index:10) --##
querier version: IGMPv2
is querier: true
general query timer: 4sec
startup query count: 0
subscribed groups: 16
-- group address: 224.0.0.2
IGMPv2(241sec), EXCLUDE_MODE(241sec)
requested list(#0):
exclude_list(#0):
-- group address: 224.0.0.22
IGMPv2(243sec), EXCLUDE_MODE(243sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.3.3
IGMPv2(259sec), EXCLUDE_MODE(259sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.4.1
IGMPv2(258sec), EXCLUDE_MODE(258sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.20.8
IGMPv2(252sec), EXCLUDE_MODE(252sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.20.22
IGMPv2(259sec), EXCLUDE_MODE(1sec,0sec,1x)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.20.28
IGMPv2(259sec), EXCLUDE_MODE(254sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.21.31
IGMPv2(237sec), EXCLUDE_MODE(237sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.22.1
IGMPv2(241sec), EXCLUDE_MODE(241sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.22.2
IGMPv2(236sec), EXCLUDE_MODE(236sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.22.4
IGMPv2(236sec), EXCLUDE_MODE(236sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.22.6
IGMPv2(241sec), EXCLUDE_MODE(241sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.22.7
IGMPv2(243sec), EXCLUDE_MODE(243sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.22.10
IGMPv2(255sec), EXCLUDE_MODE(255sec)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.22.14
IGMPv2(256sec), EXCLUDE_MODE(256sec,0sec,0x)
requested list(#0):
exclude_list(#0):
-- group address: 232.10.22.36
IGMPv2(255sec), EXCLUDE_MODE(255sec,0sec,0x)
requested list(#0):
exclude_list(#0):
I am doing something wrong here...
Best regards
Doe
Doe Beg
Mar 27, 2016, 6:20:33 AM3/27/16
to Multicast Proxy
Sorry for large post, maybe i should put log as attachment...
Sebastian Wölke
Mar 29, 2016, 5:26:48 AM3/29/16
to Multicast Proxy
Hello Deo,
Ok, I think I see the problem, this was probably a quick shot from me.
If you use gre0 as upstream interface, Multicast Proxies are aggregating all join messages from the downstreams to its upstream.
In this case, nothing can go wrong.
If you use gre0 as downstream interface, Multicast Proxies do not send any join messages in this direction.
In this case, when gre0 receives continuous data of the source, every thing is fine.
This usually happens, when the source is located in the same subnet or the source is connected to this subnet via a further Multicast Proxy.
But if the source is located in a bigger Multicast infrastructure (e.g. controlled by an ISP, which use Multicast routing protocols like PIM) you have to subscribe the source explicitly, which is not happend on a downstream interface of a Multicast Proxy.
I think this explains your problem, and so you have to use gre0 as upstream interface.
To your original question, how can you merge two sources (let us say: from different ISPs) with Mcproxy.
You would do it as follow:
pinstance myProxy: gre0 gre1 ==> gre2 gre3 gre4 gre5;
pinstance myProxy upstream * out rulematching first; #forward data to all upstreams with appropriate rules (all rules are appropriate per default)
pinstance myProxy upstream * in rulematching mutex 10000; #subscribe merged groups at all upstreams with an appropriate rule, if the Mcproxy receives this data from one interfaces all other upstream interfaces unsubscribes this group. After a timeout of X milliseconds Mcproxy checks if data still arrive at this interface if not the Mcproxy subscribes this group at all upstreams again.
Unfortunately, as I said, the multi-upstream behavior is currently buggy. (And there is currently no tutorial for this)
Sebastian
Last days I tested with one upstream if (gre0) and 4 downstream ifs (gre2,3,4,5), like this:pinstance myProxy: gre0 ==> gre2 gre3 gre4 gre5;and it perfectly worked.Last night i tried what you suggested, also with one source, just to see how mcproxy will behave without upstream if.This should be enough:
pinstance myProxy: ==> gre1 gre2 gre3 gre4 gre5 gre6;I moved source if, gre0 to downstream list, like this:pinstance myProxy: ==> gre0 gre2 gre3 gre4 gre5;mcproxy -dvvs -f /us/local/etc/mcproxy.confStarted listeners on gre2,3,4,5 but no data is forwarded from gre0...
Ok, I think I see the problem, this was probably a quick shot from me.
If you use gre0 as upstream interface, Multicast Proxies are aggregating all join messages from the downstreams to its upstream.
In this case, nothing can go wrong.
If you use gre0 as downstream interface, Multicast Proxies do not send any join messages in this direction.
In this case, when gre0 receives continuous data of the source, every thing is fine.
This usually happens, when the source is located in the same subnet or the source is connected to this subnet via a further Multicast Proxy.
But if the source is located in a bigger Multicast infrastructure (e.g. controlled by an ISP, which use Multicast routing protocols like PIM) you have to subscribe the source explicitly, which is not happend on a downstream interface of a Multicast Proxy.
I think this explains your problem, and so you have to use gre0 as upstream interface.
To your original question, how can you merge two sources (let us say: from different ISPs) with Mcproxy.
You would do it as follow:
pinstance myProxy: gre0 gre1 ==> gre2 gre3 gre4 gre5;
pinstance myProxy upstream * out rulematching first; #forward data to all upstreams with appropriate rules (all rules are appropriate per default)
pinstance myProxy upstream * in rulematching mutex 10000; #subscribe merged groups at all upstreams with an appropriate rule, if the Mcproxy receives this data from one interfaces all other upstream interfaces unsubscribes this group. After a timeout of X milliseconds Mcproxy checks if data still arrive at this interface if not the Mcproxy subscribes this group at all upstreams again.
Unfortunately, as I said, the multi-upstream behavior is currently buggy. (And there is currently no tutorial for this)
But you could try this anyway, as I'm currently not 100 percent sure whether you touch the bug with your scenario.
Regards,Sebastian
Doe Beg
Apr 22, 2016, 3:11:09 PM4/22/16
to Multicast Proxy
Hello Sabestian,
results of testing :)
pinstance myProxy: gre0 gre1 ==> gre2 gre3 gre4 gre5;
pinstance myProxy upstream * out rulematching first; #forward data to all upstreams with appropriate rules (all rules are appropriate per default)
pinstance myProxy upstream * in rulematching mutex 10000; #subscribe merged groups at all upstreams with an appropriate rule, if the Mcproxy receives this data from one interfaces all other upstream interfaces unsubscribes this group. After a timeout of X milliseconds Mcproxy checks if data still arrive at this interface if not the Mcproxy subscribes this group at all upstreams again.
I tried this but unfortunely...
When I start MC with exactly same lines you wrote:
pinstance myProxy: gre0 gre1 ==> gre2 gre3 gre4 gre5;
pinstance myProxy upstream * out rulematching first;
pinstance myProxy upstream * in rulematching mutex 10000;
there is no traffic at all, nothing happens.
However, after I comment both rules under:
However, after I comment both rules under:
pinstance myProxy: gre0 gre1 ==> gre2 gre3 gre4 gre5;
#pinstance myProxy upstream * out rulematching first;
#pinstance myProxy upstream * in rulematching mutex 10000;
Traffic starts but only from first upstream interface listed (gre0, 232...)
There is no data from other upstream interface (gre1, 239...)
If i change order of upstream IFs, like this:
pinstance myProxy: gre1 gre0 ==> gre2 gre3 gre4 gre5;
Then only multicast from gre1 is avaliable...
Regards
Doe
Reply all
Reply to author
Forward
0 new messages