From Holger.Kummert at sophos.com  Thu Mar 13 10:31:46 2014
From: Holger.Kummert at sophos.com (Holger Kummert)
Date: Thu, 13 Mar 2014 18:31:46 +0100
Subject: [Xorp-users] PIM/SM: Missing Join and Register-Stop from RP
Message-ID: <5321EB82.1020500@Sophos.com>


Hello,

I do not understand XORP's behavior when running PIM/SM and Register 
messages (that encapsulate multicast traffic) are received by the
RP from S.
What I am really missing is the Join msg towards S in order to avoid
the encapsulating overhead. Therefore the Register-Stop (in order to
stop sending the Register msgs) is also not sent by RP.

Shouldn't both messages be sent according to RFC 4601, ch. 3.2?

The only situation where I could force the Register-Stop to be sent
was by enabling and setting 'switch-to-spt-threshold' to '0'.
This sending is independent of any Join'ed receivers and happens
immediately after the receive of the first Register message.
But this is obviously not the intended usage.

Anyhow under no circumstances any Join messages are sent by RP to S.

Could someone give more insight on this?


Thanks in advance,
Holger


From greearb at candelatech.com  Thu Mar 13 10:44:48 2014
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 13 Mar 2014 10:44:48 -0700
Subject: [Xorp-users] PIM/SM: Missing Join and Register-Stop from RP
In-Reply-To: <5321EB82.1020500@Sophos.com>
References: <5321EB82.1020500@Sophos.com>
Message-ID: <5321EE90.5060804@candelatech.com>

On 03/13/2014 10:31 AM, Holger Kummert wrote:
> 
> Hello,
> 
> I do not understand XORP's behavior when running PIM/SM and Register 
> messages (that encapsulate multicast traffic) are received by the
> RP from S.
> What I am really missing is the Join msg towards S in order to avoid
> the encapsulating overhead. Therefore the Register-Stop (in order to
> stop sending the Register msgs) is also not sent by RP.
> 
> Shouldn't both messages be sent according to RFC 4601, ch. 3.2?
> 
> The only situation where I could force the Register-Stop to be sent
> was by enabling and setting 'switch-to-spt-threshold' to '0'.
> This sending is independent of any Join'ed receivers and happens
> immediately after the receive of the first Register message.
> But this is obviously not the intended usage.
> 
> Anyhow under no circumstances any Join messages are sent by RP to S.
> 
> Could someone give more insight on this?

I'm afraid I never knew much about multicast, and what I did learn
while hacking on xorp mcast logic I have mostly forgotten.

But, if you figure out a patch that makes xorp work better,
please post it and I will try to review it.

Thanks,
Ben

> 
> 
> Thanks in advance,
> Holger
> 
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
> 


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


From william at losrios.edu  Thu Mar 13 10:56:21 2014
From: william at losrios.edu (Williams, Mark)
Date: Thu, 13 Mar 2014 17:56:21 +0000
Subject: [Xorp-users] PIM/SM: Missing Join and Register-Stop from RP
In-Reply-To: <5321EE90.5060804@candelatech.com>
References: <5321EB82.1020500@Sophos.com> <5321EE90.5060804@candelatech.com>
Message-ID: <F954257BC7B9CF499CA940B39B9C45B2BDD8AFD9@LRCCD-MBX05.LRCCD.ad.losrios.edu>

>From what I understand, JOINs aren't send towards the source, they are sent to the RP. 

Sources don't know where receivers are; they just forward the traffic at layer two to their nearest multicast neighbor/router. It's up to the neighbor/router and upstream RP to build the tree. The register-stop message occurs once the source/tree is built. I think this is the normal function of the RP, and how it works regardless of implementation. Behaves the same way in Alcatel-Lucent and Cisco.

-Mark Williams

-----Original Message-----
From: xorp-users-bounces at xorp.org [mailto:xorp-users-bounces at xorp.org] On Behalf Of Ben Greear
Sent: Thursday, March 13, 2014 10:45 AM
To: Holger Kummert
Cc: xorp-users at xorp.org
Subject: Re: [Xorp-users] PIM/SM: Missing Join and Register-Stop from RP

On 03/13/2014 10:31 AM, Holger Kummert wrote:
> 
> Hello,
> 
> I do not understand XORP's behavior when running PIM/SM and Register 
> messages (that encapsulate multicast traffic) are received by the RP 
> from S.
> What I am really missing is the Join msg towards S in order to avoid 
> the encapsulating overhead. Therefore the Register-Stop (in order to 
> stop sending the Register msgs) is also not sent by RP.
> 
> Shouldn't both messages be sent according to RFC 4601, ch. 3.2?
> 
> The only situation where I could force the Register-Stop to be sent 
> was by enabling and setting 'switch-to-spt-threshold' to '0'.
> This sending is independent of any Join'ed receivers and happens 
> immediately after the receive of the first Register message.
> But this is obviously not the intended usage.
> 
> Anyhow under no circumstances any Join messages are sent by RP to S.
> 
> Could someone give more insight on this?

I'm afraid I never knew much about multicast, and what I did learn while hacking on xorp mcast logic I have mostly forgotten.

But, if you figure out a patch that makes xorp work better, please post it and I will try to review it.

Thanks,
Ben

> 
> 
> Thanks in advance,
> Holger
> 
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
> 


--
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

_______________________________________________
Xorp-users mailing list
Xorp-users at xorp.org
http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From Holger.Kummert at sophos.com  Fri Mar 14 10:30:24 2014
From: Holger.Kummert at sophos.com (Holger Kummert)
Date: Fri, 14 Mar 2014 18:30:24 +0100
Subject: [Xorp-users] PIM/SM: Missing Join and Register-Stop from RP
In-Reply-To: <F954257BC7B9CF499CA940B39B9C45B2BDD8AFD9@LRCCD-MBX05.LRCCD.ad.losrios.edu>
References: <5321EB82.1020500@Sophos.com> <5321EE90.5060804@candelatech.com>
	<F954257BC7B9CF499CA940B39B9C45B2BDD8AFD9@LRCCD-MBX05.LRCCD.ad.losrios.edu>
Message-ID: <53233CB0.6010709@Sophos.com>



Am 13.03.2014 18:56, schrieb Williams, Mark:
>  From what I understand, JOINs aren't send towards the source, they are sent to the RP.

This counts only for downstream routers.

>
> Sources don't know where receivers are; they just forward the
> traffic  at layer two to their nearest multicast neighbor/router. It's up to the
> neighbor/router and upstream RP to build the tree.

That's true. But between RP and S (the router where the actual source of 
the multicast stream is connected to) there is a small SPT built up.
The setting is like

    sender --- S --- RP --- another MC-Router --- receiver

 > The register-stop
> message occurs once the source/tree is built.

No, there are many cases where a Register-Stop is sent from RP to S.
E.g. when RP has no Joins received from downstream (= no one is 
interested in the multicast data) and there are Register-Messages
coming from S to RP. Then RP has to save this information, discard
all the Register messages and send an Register-Stop back to S
(doesn't happen).

When later a receiver Joins (through the MC-Router) at RP, RP should
Join itself to S (what also doesn't happen ...).

 >      I think this is the normal
 > function of the RP, and how it works regardless of implementation.
> Behaves the same way in Alcatel-Lucent and Cisco.

Yes, that's how it should work like. But unfortunately XORP doesn't.

Currently I'm going through the source code and look for an improvement.


Holger


>
> -Mark Williams
>
> -----Original Message-----
> From: xorp-users-bounces at xorp.org [mailto:xorp-users-bounces at xorp.org] On Behalf Of Ben Greear
> Sent: Thursday, March 13, 2014 10:45 AM
> To: Holger Kummert
> Cc: xorp-users at xorp.org
> Subject: Re: [Xorp-users] PIM/SM: Missing Join and Register-Stop from RP
>
> On 03/13/2014 10:31 AM, Holger Kummert wrote:
>>
>> Hello,
>>
>> I do not understand XORP's behavior when running PIM/SM and Register
>> messages (that encapsulate multicast traffic) are received by the RP
>> from S.
>> What I am really missing is the Join msg towards S in order to avoid
>> the encapsulating overhead. Therefore the Register-Stop (in order to
>> stop sending the Register msgs) is also not sent by RP.
>>
>> Shouldn't both messages be sent according to RFC 4601, ch. 3.2?
>>
>> The only situation where I could force the Register-Stop to be sent
>> was by enabling and setting 'switch-to-spt-threshold' to '0'.
>> This sending is independent of any Join'ed receivers and happens
>> immediately after the receive of the first Register message.
>> But this is obviously not the intended usage.
>>
>> Anyhow under no circumstances any Join messages are sent by RP to S.
>>
>> Could someone give more insight on this?
>
> I'm afraid I never knew much about multicast, and what I did learn while hacking on xorp mcast logic I have mostly forgotten.
>
> But, if you figure out a patch that makes xorp work better, please post it and I will try to review it.
>
> Thanks,
> Ben
>
>>
>>
>> Thanks in advance,
>> Holger
>>



From Holger.Kummert at sophos.com  Mon Mar 24 03:50:10 2014
From: Holger.Kummert at sophos.com (Holger Kummert)
Date: Mon, 24 Mar 2014 11:50:10 +0100
Subject: [Xorp-users] PIM/SM: Missing Join and Register-Stop from RP
In-Reply-To: <5321EE90.5060804@candelatech.com>
References: <5321EB82.1020500@Sophos.com> <5321EE90.5060804@candelatech.com>
Message-ID: <53300DE2.5060300@Sophos.com>


Please find attached a patch to improve RP's behavior when Register
messages are received (improve_register_receive.patch).
With this patch a JOIN will get sent towards S if there are
Joined receivers present at RP.
Register-Stop messages are sent back to the sender of the Registers
for each received one.
A slight disadvantage is that the Register-Stops are sent immediately
as an answer to the Register messages, not after normal multicast
traffic is received (as stated in RFC4601, sec 3.2).
Therefore a certain amount of packet loss will occur.

The other patches cover improvements for logging:
- flatten log output of TX to look similar to RXs
- Avoid double timestamp in logs.

The latter only applies if logging to syslog (has its own timestamp).
So if there are reasons to leave it as it is the patch could safely
be ignored of course.


Best regards,
Holger

Am 13.03.2014 18:44, schrieb Ben Greear:
> On 03/13/2014 10:31 AM, Holger Kummert wrote:
>>
>> Hello,
>>
>> I do not understand XORP's behavior when running PIM/SM and Register
>> messages (that encapsulate multicast traffic) are received by the
>> RP from S.
>> What I am really missing is the Join msg towards S in order to avoid
>> the encapsulating overhead. Therefore the Register-Stop (in order to
>> stop sending the Register msgs) is also not sent by RP.
>>
>> Shouldn't both messages be sent according to RFC 4601, ch. 3.2?
>>
>> The only situation where I could force the Register-Stop to be sent
>> was by enabling and setting 'switch-to-spt-threshold' to '0'.
>> This sending is independent of any Join'ed receivers and happens
>> immediately after the receive of the first Register message.
>> But this is obviously not the intended usage.
>>
>> Anyhow under no circumstances any Join messages are sent by RP to S.
>>
>> Could someone give more insight on this?
>
> I'm afraid I never knew much about multicast, and what I did learn
> while hacking on xorp mcast logic I have mostly forgotten.
>
> But, if you figure out a patch that makes xorp work better,
> please post it and I will try to review it.
>
> Thanks,
> Ben
>
>>
>>
>> Thanks in advance,
>> Holger
>>
>> _______________________________________________
>> Xorp-users mailing list
>> Xorp-users at xorp.org
>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
>>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: improve_register_receive.patch
Type: text/x-patch
Size: 2063 bytes
Desc: not available
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20140324/1c7c9de0/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: flatten_tx_log_output.patch
Type: text/x-patch
Size: 851 bytes
Desc: not available
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20140324/1c7c9de0/attachment-0001.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: avoid_double_timestamp_in_log.patch
Type: text/x-patch
Size: 1599 bytes
Desc: not available
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20140324/1c7c9de0/attachment-0002.bin 

From amir at net-saas.com  Sun Mar 30 02:57:36 2014
From: amir at net-saas.com (Amir Naftali)
Date: Sun, 30 Mar 2014 12:57:36 +0300
Subject: [Xorp-users] xorp route integration with openswan/strongswan
Message-ID: <CAKB-oATbOpwsx7C6_3uymtQQir0pROYWsw+E22kRFW0D6UEQ1w@mail.gmail.com>

Hi,

I'm a newbe to xorp and want to run some tests to see if it can handle
route redundancy  inside my IPSec tunnels (IPSec using either openswan or
strongswan)

My scenario is as follows...
I have the following 3 subnets that are connected via IPSec
1) 10.100.1.0/24
2) 10.100.2.0/24
3) 10.100.3.0/24

In each network I'm running a single IPSec end point that also has a public
ip address
1) GW A - 10.100.1.254 with public IP of 5.5.1.254
2) GW B - 10.100.2.254 with public IP of 5.5.2.254
3) GW C - 10.100.3.254 with public IP of 5.5.3.254

(the public IPs above are of course not my real public IPs)

All GWs are interconnected. So I basically have a full mesh of 3 IPSec GWs,
but since openswan install the route itself for each connection it doesn't
allow overlapping ip addresses to exist between tw different routes - So in
a full mesh only allows the local subnets to be published in the connection
and prevent me from publishing a remote subnet.

Example (based on above data)

A,B,C are all connected but I would like to be allow A to reach C via B if
it's direct connection (A<->C) is down. if i'll explicitly write this done
in the A<->B IPSec connection then A will fail creating one of the
connection since it will say that route to C already exist.

My questions...

   1. can xorp take ownership over the policy based route installation for
   openswan (or strongswan) and automatically cause reroute of traffic once
   one of my IPSec links is down? If the answer is yes, Is there an reference
   xorp config example that I can used to see how is this done?
   2. Which routing protocol should I use in this case (I need the one that
   will provide the shortest downtime once one of the link is failing)?
   3. Any limitation of such a solution (what if I had a full mesh of 20
   IPSec GWs)?


Appreciate your help

Amir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20140330/fd3af804/attachment.html