[Xorp-users] IGMP and Multicast question

[e***@free.fr]

Hi,

We are trying to make the following work, as a test platform for now, but then
it will be needed in a real case operation :

mcast source-------Linux smcroute---------LinuxXORP-------mcast receiver
^ ^ ^ ^
| | | |
192.168.1.1 eth0 eth1 192.168.3.4
192.168.2.3 192.168.3.3

smcroute is present only in the case of the test platform, it will later be
substituted with a Juniper router on which we will have no interaction possible.

The MC source is sending MC data to 230.1.1.1 (for the test)
This MC flow is seen on the Linux XORP router, interface eth0 (wireshark)
The fact to start the MC receiving application triggers an IGMP report, seen on
eth1 of the Linux XORP router.
There is no routing of the MC flow from the input interface eth0 to the output
interface eth1, on the Xorp router.

Our understanding of what should occur is probably wrong, but we thought that
the IGMP report received from the MC receiver should be enough for the XORP
router to have the necessary information to be able to forward the stream
received on eth0 to eth1. What is not correct in this assumption ?

Thanks in advance for helping.

Vincent

xorp traces extract:

[ 2008/02/05 11:01:53 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 1
vif_index = 0 src = 192.168.1.1 dst = 230.1.1.1
[ 2008/02/05 11:02:03 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 1
vif_index = 0 src = 192.168.1.1 dst = 230.1.1.1
[ 2008/02/05 11:02:04 TRACE xorp_igmp MLD6IGMP ] TX IGMP_MEMBERSHIP_QUERY from
192.168.3.3 to 224.0.0.1
[ 2008/02/05 11:02:04 TRACE xorp_igmp MLD6IGMP ] RX IGMP_MEMBERSHIP_QUERY from
192.168.3.3 to 224.0.0.1 on vif eth1
[ 2008/02/05 11:02:08 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT
from 192.168.3.4 to 230.1.1.1 on vif eth1
[ 2008/02/05 11:02:08 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT
from 192.168.3.4 to 224.0.0.251 on vif eth1
[ 2008/02/05 11:02:10 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT
from 192.168.3.3 to 224.0.0.2 on vif eth1
[ 2008/02/05 11:02:11 TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_MEMBERSHIP_REPORT
from 192.168.3.3 to 224.0.0.22 on vif eth1
[ 2008/02/05 11:02:13 TRACE xorp_fea MFEA ] RX kernel signal: message_type = 1
vif_index = 0 src = 192.168.1.1 dst = 230.1.1.1


Xorp configuration file :

/**** Interface list ****/
interfaces {
interface eth0 {
description: ""
disable: false
default-system-config
}
interface eth1 {
description: ""
disable: false
default-system-config
}
}

/**** Forwarding engine ****/
fea {
unicast-forwarding4 {
disable: false
}
unicast-forwarding6 {
disable: false
}
}

plumbing {
mfea4 {
disable: false
interface eth0 {
vif eth0 {
disable: false
}
}
interface eth1 {
vif eth1 {
disable: false
}
}
interface register_vif {
vif register_vif {
disable: false
}
}
traceoptions {
flag all {
disable: false
}
}
}
}

/**** IGMP ****/
protocols {
igmp {
disable: false
interface eth1 {
vif eth1 {
disable:false
}
}
traceoptions {
flag all {
disable: false
}
}
}
}

protocols {
fib2mrib {
disable: false
}
}

[Javier Fernandez-Sanguino]

Post by e***@free.fr
Hi,
We are trying to make the following work, as a test platform for now, but then
mcast source-------Linux smcroute---------LinuxXORP-------mcast receiver
^ ^ ^ ^
| | | |
192.168.1.1 eth0 eth1 192.168.3.4
192.168.2.3 192.168.3.3

Linux smcroute and LinuxXorp are different systems, right?

Question: why don't you enable IGMP on the eth0 interface?

I don't see how you can make this work, AFAIK Xorp cannot act as an
IGMP proxy (RFC4605?) and if you are working with two routers you need
to have PIM in both sides (i.e. in the Linux smcroute and LinuxXorp).

Actually, you are not simulating properly the Juniper case by just
adding a Linux system with smcroute. You need to have a PIM-enabled
daemon in that side, to simulate multicast routing amongst routers.

Post by e***@free.fr
Our understanding of what should occur is probably wrong, but we thought that
the IGMP report received from the MC receiver should be enough for the XORP
router to have the necessary information to be able to forward the stream
received on eth0 to eth1. What is not correct in this assumption ?

No, from my limited understanding (I'm not a multicast guru, but hey)
the Xorp router has to "find" which multicast routers are available
(through PIM) and then, when it sees, the IGMP repo from a MC receiver
on its side it will "subscribe" to the multicast group with its main
multicast router. In your environment there is only one multicast
router (i.e. Xorp) so it does not know who to contact to get the group
230.1.1.1 requested by the client.

That being said, I'm not sure if it will work if you add eth0 to the
IGMP definition, as smcroute will just forward (if properly
configured) the multicast traffic from the server "as is". Did you try
that?


Regards

Javier

[e***@free.fr]

Post by Javier Fernandez-Sanguino

Post by e***@free.fr
Hi,
We are trying to make the following work, as a test platform for now, but

then

Post by e***@free.fr
mcast source-------Linux smcroute---------LinuxXORP-------mcast receiver
^ ^ ^ ^
| | | |
192.168.1.1 eth0 eth1 192.168.3.4
192.168.2.3 192.168.3.3

Linux smcroute and LinuxXorp are different systems, right?

Yes, indeed. We used smcroute only for the test, because it is quick to
configure.

Post by Javier Fernandez-Sanguino
Question: why don't you enable IGMP on the eth0 interface?

In my understanding, activating an interface for igmp in Xorp means "listen for
potential receivers on this interface". And I know we have receivers only on
eth1. Am I wrong ? By the way, in a first configuration I in fact had configured
eth0 for igmp also, with no difference in behaviour.

Post by Javier Fernandez-Sanguino
I don't see how you can make this work, AFAIK Xorp cannot act as an
IGMP proxy (RFC4605?) and if you are working with two routers you need
to have PIM in both sides (i.e. in the Linux smcroute and LinuxXorp).
Actually, you are not simulating properly the Juniper case by just
adding a Linux system with smcroute. You need to have a PIM-enabled
daemon in that side, to simulate multicast routing amongst routers.

See below my comments about a "two PIM routers" configuration.

Post by Javier Fernandez-Sanguino

Post by e***@free.fr
Our understanding of what should occur is probably wrong, but we thought

that

Post by e***@free.fr
the IGMP report received from the MC receiver should be enough for the XORP
router to have the necessary information to be able to forward the stream
received on eth0 to eth1. What is not correct in this assumption ?

No, from my limited understanding (I'm not a multicast guru, but hey)
the Xorp router has to "find" which multicast routers are available
(through PIM) and then, when it sees, the IGMP repo from a MC receiver
on its side it will "subscribe" to the multicast group with its main
multicast router. In your environment there is only one multicast
router (i.e. Xorp) so it does not know who to contact to get the group
230.1.1.1 requested by the client.
That being said, I'm not sure if it will work if you add eth0 to the
IGMP definition, as smcroute will just forward (if properly
configured) the multicast traffic from the server "as is". Did you try
that?

Yes, we tried and saw no difference. We also tried to have a Xorp Pim daemon
running instead of smcroute, and it did work, the receiver had the MC flow
directed to him (it ?), but in the real world case, there will not be a PIM
router on the Juniper (AFAIK as of today).

Regards

Vincent

[Pavlin Radoslavov]

Post by e***@free.fr

Post by Javier Fernandez-Sanguino

Post by e***@free.fr
We are trying to make the following work, as a test platform for now, but

then

Post by e***@free.fr
mcast source-------Linux smcroute---------LinuxXORP-------mcast receiver
^ ^ ^ ^
| | | |
192.168.1.1 eth0 eth1 192.168.3.4
192.168.2.3 192.168.3.3

Linux smcroute and LinuxXorp are different systems, right?

Yes, indeed. We used smcroute only for the test, because it is quick to
configure.

Post by Javier Fernandez-Sanguino
Question: why don't you enable IGMP on the eth0 interface?

In my understanding, activating an interface for igmp in Xorp means "listen for
potential receivers on this interface". And I know we have receivers only on
eth1. Am I wrong ? By the way, in a first configuration I in fact had configured
eth0 for igmp also, with no difference in behaviour.

Post by Javier Fernandez-Sanguino
I don't see how you can make this work, AFAIK Xorp cannot act as an
IGMP proxy (RFC4605?) and if you are working with two routers you need
to have PIM in both sides (i.e. in the Linux smcroute and LinuxXorp).
Actually, you are not simulating properly the Juniper case by just
adding a Linux system with smcroute. You need to have a PIM-enabled
daemon in that side, to simulate multicast routing amongst routers.

See below my comments about a "two PIM routers" configuration.

Post by Javier Fernandez-Sanguino

Post by e***@free.fr
Our understanding of what should occur is probably wrong, but we thought

that

Post by e***@free.fr
the IGMP report received from the MC receiver should be enough for the XORP
router to have the necessary information to be able to forward the stream
received on eth0 to eth1. What is not correct in this assumption ?

No, from my limited understanding (I'm not a multicast guru, but hey)
the Xorp router has to "find" which multicast routers are available
(through PIM) and then, when it sees, the IGMP repo from a MC receiver
on its side it will "subscribe" to the multicast group with its main
multicast router. In your environment there is only one multicast
router (i.e. Xorp) so it does not know who to contact to get the group
230.1.1.1 requested by the client.
That being said, I'm not sure if it will work if you add eth0 to the
IGMP definition, as smcroute will just forward (if properly
configured) the multicast traffic from the server "as is". Did you try
that?

Yes, we tried and saw no difference. We also tried to have a Xorp Pim daemon
running instead of smcroute, and it did work, the receiver had the MC flow
directed to him (it ?), but in the real world case, there will not be a PIM
router on the Juniper (AFAIK as of today).

Juniper has PIM-SM so is there any reason not to configure/use it?
If Juniper won't be running PIM how are you going to get that box
forward the multicast traffic? Are you planning to have it running
IGMP proxy?
If this is the case then XORP needs to run PIM-SM with little
special configuration. I can provide that info to you once I
know what are you going to do on the Juniper side.

Regards,
Pavlin

[admin galerie]

Post by Pavlin Radoslavov

Post by e***@free.fr

Post by Javier Fernandez-Sanguino

Post by e***@free.fr
We are trying to make the following work, as a test platform for now, but

then

Post by e***@free.fr
mcast source-------Linux smcroute---------LinuxXORP-------mcast receiver
^ ^ ^ ^
| | | |
192.168.1.1 eth0 eth1 192.168.3.4
192.168.2.3 192.168.3.3

Linux smcroute and LinuxXorp are different systems, right?

Yes, indeed. We used smcroute only for the test, because it is quick to
configure.

Post by Javier Fernandez-Sanguino
Question: why don't you enable IGMP on the eth0 interface?

In my understanding, activating an interface for igmp in Xorp means "listen for
potential receivers on this interface". And I know we have receivers only on
eth1. Am I wrong ? By the way, in a first configuration I in fact had configured
eth0 for igmp also, with no difference in behaviour.

Post by Javier Fernandez-Sanguino
I don't see how you can make this work, AFAIK Xorp cannot act as an
IGMP proxy (RFC4605?) and if you are working with two routers you need
to have PIM in both sides (i.e. in the Linux smcroute and LinuxXorp).
Actually, you are not simulating properly the Juniper case by just
adding a Linux system with smcroute. You need to have a PIM-enabled
daemon in that side, to simulate multicast routing amongst routers.

See below my comments about a "two PIM routers" configuration.

Post by Javier Fernandez-Sanguino

Post by e***@free.fr
Our understanding of what should occur is probably wrong, but we thought

that

Post by e***@free.fr
the IGMP report received from the MC receiver should be enough for the XORP
router to have the necessary information to be able to forward the stream
received on eth0 to eth1. What is not correct in this assumption ?

No, from my limited understanding (I'm not a multicast guru, but hey)
the Xorp router has to "find" which multicast routers are available
(through PIM) and then, when it sees, the IGMP repo from a MC receiver
on its side it will "subscribe" to the multicast group with its main
multicast router. In your environment there is only one multicast
router (i.e. Xorp) so it does not know who to contact to get the group
230.1.1.1 requested by the client.
That being said, I'm not sure if it will work if you add eth0 to the
IGMP definition, as smcroute will just forward (if properly
configured) the multicast traffic from the server "as is". Did you try
that?

Yes, we tried and saw no difference. We also tried to have a Xorp Pim daemon
running instead of smcroute, and it did work, the receiver had the MC flow
directed to him (it ?), but in the real world case, there will not be a PIM
router on the Juniper (AFAIK as of today).

Juniper has PIM-SM so is there any reason not to configure/use it?
If Juniper won't be running PIM how are you going to get that box
forward the multicast traffic? Are you planning to have it running
IGMP proxy?
If this is the case then XORP needs to run PIM-SM with little
special configuration. I can provide that info to you once I
know what are you going to do on the Juniper side.

The Juniper side is not our responsibility, so we can't make choices
for the people who are going to configure it. Between the Juniper and
our Xorp router, there is a satellite network, and cypher/decypher
devices, where it is necessary to configure security associations for
each flow you intend to transmit (unicast and multicast). That is the
main reason why we try not to have PIM signalling between the Juniper
and us. I asked the person in charge of the Juniper how it was going to
forward the multicast traffic, and he answered there was a simple
static configuration, the kind "all MC traffic from interface A shall
be directed to interface B". Does it make sense ?

To resolve my problem, which seems to be a RFC4605 (thanks Javier) test
case, couldn't I start two instances of Xorp on my Xorp router ?

Thanks again for helping me (I confess I'm kind of a newbie in routing
magic...)

best regards,

Vincent

[Pavlin Radoslavov]

Post by admin galerie

Post by Pavlin Radoslavov
Juniper has PIM-SM so is there any reason not to configure/use it?
If Juniper won't be running PIM how are you going to get that box
forward the multicast traffic? Are you planning to have it running
IGMP proxy?
If this is the case then XORP needs to run PIM-SM with little
special configuration. I can provide that info to you once I
know what are you going to do on the Juniper side.

The Juniper side is not our responsibility, so we can't make choices
for the people who are going to configure it. Between the Juniper and
our Xorp router, there is a satellite network, and cypher/decypher
devices, where it is necessary to configure security associations for
each flow you intend to transmit (unicast and multicast). That is the
main reason why we try not to have PIM signalling between the Juniper
and us. I asked the person in charge of the Juniper how it was going to
forward the multicast traffic, and he answered there was a simple
static configuration, the kind "all MC traffic from interface A shall
be directed to interface B". Does it make sense ?
To resolve my problem, which seems to be a RFC4605 (thanks Javier) test
case, couldn't I start two instances of Xorp on my Xorp router ?

The simple answer is no.

However, if Juniper forwards all multicast traffic to you, there is
a way to get it working:

1. Configure PIM-SM on XORP and configure one of its interfaces as a
static RP for the whole 224.0.0.0/4 multicast address range.

2. Use the "alternative-subnet" configuration statement(s) for the
interface/vif on the XORP box toward the Juniper.
For example, "alternative subnet 10.0.0.0/8" will tell XORP to
consider all multicast traffic from source address in the
10.0.0.0/8 range appear like coming from a directly connected
subnet, and typically traffic from directly connected subnets
will be forwarded if there are downstream receivers.
You might need to use more than one such statement to cover all
possible sender addresses.

Regards,
Pavlin

[admin galerie]

Post by Pavlin Radoslavov

Post by admin galerie

Post by Pavlin Radoslavov
Juniper has PIM-SM so is there any reason not to configure/use it?
If Juniper won't be running PIM how are you going to get that box
forward the multicast traffic? Are you planning to have it running
IGMP proxy?
If this is the case then XORP needs to run PIM-SM with little
special configuration. I can provide that info to you once I
know what are you going to do on the Juniper side.

The Juniper side is not our responsibility, so we can't make choices
for the people who are going to configure it. Between the Juniper and
our Xorp router, there is a satellite network, and cypher/decypher
devices, where it is necessary to configure security associations for
each flow you intend to transmit (unicast and multicast). That is the
main reason why we try not to have PIM signalling between the Juniper
and us. I asked the person in charge of the Juniper how it was going to
forward the multicast traffic, and he answered there was a simple
static configuration, the kind "all MC traffic from interface A shall
be directed to interface B". Does it make sense ?
To resolve my problem, which seems to be a RFC4605 (thanks Javier) test
case, couldn't I start two instances of Xorp on my Xorp router ?

The simple answer is no.
However, if Juniper forwards all multicast traffic to you, there is
1. Configure PIM-SM on XORP and configure one of its interfaces as a
static RP for the whole 224.0.0.0/4 multicast address range.
2. Use the "alternative-subnet" configuration statement(s) for the
interface/vif on the XORP box toward the Juniper.
For example, "alternative subnet 10.0.0.0/8" will tell XORP to
consider all multicast traffic from source address in the
10.0.0.0/8 range appear like coming from a directly connected
subnet, and typically traffic from directly connected subnets
will be forwarded if there are downstream receivers.
You might need to use more than one such statement to cover all
possible sender addresses.

Thanks for your help Pavlin, I did not have time to test today your
configuration proposition, but I will try it tomorrow and will let you
know if it does what I need.

Best regards

Vincent