From neeraj.prasad at gmail.com  Fri Feb  2 00:24:42 2007
From: neeraj.prasad at gmail.com (Neeraj Prasad)
Date: Fri, 2 Feb 2007 13:54:42 +0530
Subject: [Xorp-users] Xorp-users Digest, Vol 10,
	Issue 20 : Change in RP vs change in next-hop for RP (Vikram KAUL)
Message-ID: <1d413a090702020024w4a138102w149e2cbfd9396be0@mail.gmail.com>

Hi,

Things will be handled differently for (*,*,RP) and (*,G).
For (*.*RP) -
------------------
See Section 4.1.2 :  (*,*,RP) State

The information for RP is really not required for (*,*,RP) case. This is why
RFC 4601 does not specify requirement to store 'Last RP used' for (*,*,RP)
state. The initiator of (*,*,RP) has to re-initiate the new Join for the new
RP and if it wants then can send a Prune for Last RP. As long as the RP is
reachable it does not matter.

For (*,G)
-------------
See  Section 4.1.3:  (*,G) State

The state machine should store the 'Last RP used'. Since this information is
present with us we can send a Prune to the Old RP and send Join to the new
RP.

This is specially important in BSR systems where a Candidate RP may be
changing so each time you will have new RP set to deal with. So the RP set
will be refreshed and old RP will be pruned off and new RP will be joined.

See the following Extract -

Section 4.7.1.  Group-to-RP Mapping
   . . .
   Note that if the set of possible group-range-to-RP mappings changes,
   each router will need to check whether any existing groups are
   affected.  This may, for example, cause a DR or acting DR to re-join
   a group, or cause it to restart register encapsulation to the new RP.
   . . .

For (S,G) Register process the standard has definitions which you know.

Please let me if this was helpful.

Thanks and Regards,
Neeraj.







On 2/1/07, xorp-users-request at xorp.org <xorp-users-request at xorp.org> wrote:
>
> Send Xorp-users mailing list submissions to
>         xorp-users at xorp.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
> or, via email, send a message with subject or body 'help' to
>         xorp-users-request at xorp.org
>
> You can reach the person managing the list at
>         xorp-users-owner at xorp.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Xorp-users digest..."
>
>
> Today's Topics:
>
>    1. Change in RP vs change in next-hop for RP (Vikram KAUL)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 31 Jan 2007 11:33:10 -0500 (Eastern Standard Time)
> From: Vikram KAUL <vkaul at research.telcordia.com>
> Subject: [Xorp-users] Change in RP vs change in next-hop for RP
> To: xorp-users at xorp.org
> Message-ID: <Pine.WNT.4.60.0701311114130.2784 at vkaul-laptop>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
>
> Hi,
>
>   Just wanted to verify the current implementation in XORP regarding
> events that might occur when a group G is active and data is being
> forwarded for that group. The (*,G) and (*,*,RP) state will exist in the
> router.
>
>   When the next-hop to the RP changes, the Upstream (*,*,RP) Join/Prune
> state machine which keeps the last RPF Neighbor towards that same RP, is
> triggered into sending a new Join(*,*,RP) to the new upstream neighbor and
> a Prune(*,*,RP) to the old upstream neighbor.
>
> This I can see in  pim_mre_rpf.cc
> PimMre::recompute_nbr_mrib_next_hop_rp_rp_changed()
>
>   However, I was not able to find what happenes when the RP itself changes
> when the group is active. The specs talk aboutthe "RP changed" impacting
> only the  "Per-(S,G) register state machine at the DR". (Look at the
> tabular form, last column, Section 4.4.1). The register tunnels get
> updated via an "update register channel" procedure when the state is Join.
>
>   Specifically, where are the conditions addressed when the RP itself
> changes for the (*,G) and (*,*,RP) state. Not the next hop changes, but
> the RP changes when the group is active. Is the protocol designed to
> handle this ?
>
>   Any pointers to the XORP code and/or the specs will be appreciated
>
> regards..
> Vikram
>
>
>
> ------------------------------
>
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
>
>
> End of Xorp-users Digest, Vol 10, Issue 20
> ******************************************
>



-- 
Thanks and Regards,
Neeraj Prasad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070202/180b262b/attachment.html 

From koippa at gmail.com  Mon Feb  5 11:57:58 2007
From: koippa at gmail.com (Kimmo Koivisto)
Date: Mon, 5 Feb 2007 21:57:58 +0200
Subject: [Xorp-users] xorp ospf endless loop problem?
Message-ID: <200702052157.58321.koippa@gmail.com>

Hello

I have simple environment with four routers R1-R4, tested with xorp 1.3 and 
cvs version from Jan 22. I am running RHEL4 ES. 

I have had some problems with ospf, sometimes when I reboot one router (let's 
say R1), other router (R2) just loops ospf related messages forever. I can 
see that xorp eats 99% of the cpu. Problem goes away if I restart xorp from 
R2.

Is there any known problems with xorp's ospf, could my problem be know one? 

Regards
Kimmo Koivisto

Ospf related configuration and log from the problem :

<xorp ospf config>
protocols {
  ospf4 {
    router-id: 10.0.1.2

    area 0.0.0.0 {
      interface eth0 {
        vif eth0 {
          address 10.0.1.2
        }
      }
      interface eth1 {
        vif eth1 {
          address 10.1.1.2
        }
      }
    }
  }
}

</xorp ospf config>


<xorp log from problem>
[ 2007/01/23 11:17:56  INFO xorp_ospfv2:4243 OSPF +4064 peer.cc 
link_state_update_received ] Same LSA
Network-LSA:
LS age 3600 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link State 
ID 11.0.1.2 Advertising Router 10.0
.1.2 LS sequence number 0x80000001 LS checksum 0x5ec6 length 32
        Network Mask 0xffffff00
        Attached Router 11.0.0.2
        Attached Router 10.0.1.2
Network-LSA:
LS age 3600 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link State 
ID 11.0.1.2 Advertising Router 10.0
.1.2 LS sequence number 0x80000001 LS checksum 0x5ec6 length 32
        Network Mask 0xffffff00
        Attached Router 11.0.0.2
        Attached Router 10.0.1.2
[ 2007/01/23 11:17:56  INFO xorp_ospfv2:4243 OSPF +4064 peer.cc 
link_state_update_received ] Same LSA
Network-LSA:
LS age 3600 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link State 
ID 11.0.2.1 Advertising Router 10.0
.1.2 LS sequence number 0x80000001 LS checksum 0x6fb3 length 32
        Network Mask 0xffffff00
        Attached Router 11.0.2.2
        Attached Router 10.0.1.2
Network-LSA:
LS age 3600 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link State 
ID 11.0.2.1 Advertising Router 10.0
.1.2 LS sequence number 0x80000001 LS checksum 0x6fb3 length 32
        Network Mask 0xffffff00
        Attached Router 11.0.2.2
        Attached Router 10.0.1.2
</xorp log from problem>


From lappa at psc.edu  Thu Feb  8 09:18:50 2007
From: lappa at psc.edu (Joseph Lappa)
Date: Thu, 8 Feb 2007 12:18:50 -0500
Subject: [Xorp-users] XORP and Route Server
Message-ID: <0133BFCD-A70D-45EA-A1EF-B618748C73C9@psc.edu>



From pavlin at icir.org  Thu Feb  8 14:20:54 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Thu, 08 Feb 2007 14:20:54 -0800
Subject: [Xorp-users] XORP and Route Server
In-Reply-To: Message from Joseph Lappa <lappa@psc.edu> of "Thu,
	08 Feb 2007 12:18:50 EST."
	<0133BFCD-A70D-45EA-A1EF-B618748C73C9@psc.edu> 
Message-ID: <200702082220.l18MKspT075171@possum.icir.org>

Joseph Lappa <lappa at psc.edu> wrote:

<EMPTY>

Please resend your email, because the body was empty.

Regards,
Pavlin

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


From lappa at psc.edu  Thu Feb  8 16:31:40 2007
From: lappa at psc.edu (Joseph Lappa)
Date: Thu, 8 Feb 2007 19:31:40 -0500
Subject: [Xorp-users] XORP and Route Server
In-Reply-To: <200702082220.l18MKspT075171@possum.icir.org>
References: <200702082220.l18MKspT075171@possum.icir.org>
Message-ID: <04D8ABF7-6914-4046-920C-8580C8CE0EE2@psc.edu>

Sorry about that..

Can XORP be used as a Route Server?  Would someone mind posting a  
sample config?

Thanks!
Joe

On Feb 8, 2007, at 5:20 PM, Pavlin Radoslavov wrote:

> Joseph Lappa <lappa at psc.edu> wrote:
>
> <EMPTY>
>
> Please resend your email, because the body was empty.
>
> Regards,
> Pavlin
>
>>
>> _______________________________________________
>> Xorp-users mailing list
>> Xorp-users at xorp.org
>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From lyra at pop-pr.rnp.br  Fri Feb  9 10:31:59 2007
From: lyra at pop-pr.rnp.br (Christian Lyra)
Date: Fri, 9 Feb 2007 16:31:59 -0200
Subject: [Xorp-users] multicast over GRE tunnel
Message-ID: <200702091631.59755.lyra@pop-pr.rnp.br>

Hi there,

	I?d like to setup a xorp router to do multicast over a GRE tunnel. My 
setup is like this:

[multicast_enabled_net]----[Cisco-Router]---[no-multicast_net]--[xorp_router]---[desktops]

	Between Cisco-router and xorp_router there?s a GRE tunnel so I can 
trasverse the non_multicast_net. The protocol used is PIM-SM and there
?s a "static" RP on multicast_enabled_net.

	I?m sure that all the other parts are ok, because I had a cisco 2500 in 
the place of xorp_router and it work just fine with a simple config 
like this one:

ip multicast-routing
interface Tunnel1
 ip address 200.x.x.154 255.255.255.252
 ip pim sparse-mode
 tunnel source 200.y.y.191
 tunnel destination 200.y.y.9

ip pim rp-address 200.z.z.z
ip mroute 0.0.0.0 0.0.0.0 tunnel0

	I tried to emulate this same configuration with xorp:

xorp at teste# show
    protocols {
        igmp {
            interface eth0 {
                vif eth0 {
                    query-interval: 30
                }
            }
            interface tun0 {
                vif tun0 {
                }
            }
        }
        pimsm4 {
            interface "register_vif" {
                vif "register_vif" {
                }
            }
            interface tun0 {
                vif tun0 {
                }
            }
            interface eth0 {
                vif eth0 {
                }
            }
            static-rps {
                rp 200.z.z.z {
                    group-prefix 224.0.0.0/4 {
                    }
                }
            }
        }
        static {
            route 0.0.0.0/0 {
                next-hop: 200.x.x.x
            }
            mrib-route 0.0.0.0/0 {
                next-hop: 200.x.x.153 /* tunnel */
}
        }
    }
    fea {
        unicast-forwarding4 {
        }
    }
    interfaces {
        interface eth0 {
            vif eth0 {
                address 200.x.x.191 {
                    prefix-length: 24
                }
            }
        }
        interface lo {
            vif lo {
            }
        }
        interface tun0 {
            vif tun0 {
                address 200.x.x.154 {
                    prefix-length: 30
                    multicast-capable: true
                }
            }
        }
    }
    plumbing {
        mfea4 {
            interface eth0 {
                vif eth0 {
                }
            }
            interface "register_vif" {
                vif "register_vif" {
                }
            }
	interface tun0 {
                vif tun0 {
                }
            }
        }
    }


	One thing that I noticed is this:
xorp at teste> show pim neighbors
Interface    DRpriority NeighborAddr    V Mode   Holdtime Timeout
tun0                  1 200.x.x.153   2 Sparse      105      82


	But Cisco doesnt see the xorp as a neighbor! (when using the cisco 2500 
instead of xorp, this Cisco router sees two neighbors, one is the 
upstream one and the other the 2500).

bb3#show ip pim neighbor
PIM Neighbor Table
Neighbor          Interface                Uptime/Expires    Ver   DR
Address                                                            
Prio/Mode
<wanip>     FastEthernet1/1/0        04:14:05/00:01:39 v2    N /


	Maybe I?m missing something.... or this can be compatibility problem 
between xorp and cisco? Any clues? I can see the PIM join messagens 
going out from tunnel interface.

	Btw... the xorp is running in a debian sarge. Kernel from distro, and a 
little script to create the tun interface before the xorp_rtmgr is 
started:

ip tunnel add tun0 mode gre remote 200.ci.s.co local 200.lo.ca.l dev 
eth0

ifconfig tun0 allmulti
ifconfig tun0 multicast


-- 
Christian Lyra
POP-PR - RNP

http://lyra.soueu.com.br

  ``The rules of programming are transitory; only Tao is eternal. 
Therefore you must contemplate Tao before you receive enlightenment.'' 
  ``But how will I know when I have received enlightenment?'' asked the 
novice. 
  ``Your program will then run correctly,'' replied the master. 
						The Tao Of Programing


From pavlin at icir.org  Fri Feb  9 10:59:58 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Fri, 09 Feb 2007 10:59:58 -0800
Subject: [Xorp-users] multicast over GRE tunnel
In-Reply-To: Message from Christian Lyra <lyra@pop-pr.rnp.br> of "Fri,
	09 Feb 2007 16:31:59 -0200." <200702091631.59755.lyra@pop-pr.rnp.br> 
Message-ID: <200702091859.l19Ixwp2084507@possum.icir.org>

Christian Lyra <lyra at pop-pr.rnp.br> wrote:

> Hi there,
> 
> 	I?d like to setup a xorp router to do multicast over a GRE tunnel. My 
> setup is like this:
> 
> [multicast_enabled_net]----[Cisco-Router]---[no-multicast_net]--[xorp_router]---[desktops]
> 
> 	Between Cisco-router and xorp_router there?s a GRE tunnel so I can 
> trasverse the non_multicast_net. The protocol used is PIM-SM and there
> ?s a "static" RP on multicast_enabled_net.
> 
> 	I?m sure that all the other parts are ok, because I had a cisco 2500 in 
> the place of xorp_router and it work just fine with a simple config 
> like this one:
> 
> ip multicast-routing
> interface Tunnel1
>  ip address 200.x.x.154 255.255.255.252
>  ip pim sparse-mode
>  tunnel source 200.y.y.191
>  tunnel destination 200.y.y.9
> 
> ip pim rp-address 200.z.z.z
> ip mroute 0.0.0.0 0.0.0.0 tunnel0
> 
> 	I tried to emulate this same configuration with xorp:
> 
> xorp at teste# show
>     protocols {
>         igmp {
>             interface eth0 {
>                 vif eth0 {
>                     query-interval: 30
>                 }
>             }
>             interface tun0 {
>                 vif tun0 {
>                 }
>             }
>         }
>         pimsm4 {
>             interface "register_vif" {
>                 vif "register_vif" {
>                 }
>             }
>             interface tun0 {
>                 vif tun0 {
>                 }
>             }
>             interface eth0 {
>                 vif eth0 {
>                 }
>             }
>             static-rps {
>                 rp 200.z.z.z {
>                     group-prefix 224.0.0.0/4 {
>                     }
>                 }
>             }
>         }
>         static {
>             route 0.0.0.0/0 {
>                 next-hop: 200.x.x.x
>             }
>             mrib-route 0.0.0.0/0 {
>                 next-hop: 200.x.x.153 /* tunnel */
> }
>         }
>     }
>     fea {
>         unicast-forwarding4 {
>         }
>     }
>     interfaces {
>         interface eth0 {
>             vif eth0 {
>                 address 200.x.x.191 {
>                     prefix-length: 24
>                 }
>             }
>         }
>         interface lo {
>             vif lo {
>             }
>         }
>         interface tun0 {
>             vif tun0 {
>                 address 200.x.x.154 {
>                     prefix-length: 30
>                     multicast-capable: true
>                 }
>             }
>         }
>     }
>     plumbing {
>         mfea4 {
>             interface eth0 {
>                 vif eth0 {
>                 }
>             }
>             interface "register_vif" {
>                 vif "register_vif" {
>                 }
>             }
> 	interface tun0 {
>                 vif tun0 {
>                 }
>             }
>         }
>     }
> 
> 
> 	One thing that I noticed is this:
> xorp at teste> show pim neighbors
> Interface    DRpriority NeighborAddr    V Mode   Holdtime Timeout
> tun0                  1 200.x.x.153   2 Sparse      105      82
> 
> 
> 	But Cisco doesnt see the xorp as a neighbor! (when using the cisco 2500 
> instead of xorp, this Cisco router sees two neighbors, one is the 
> upstream one and the other the 2500).
> 
> bb3#show ip pim neighbor
> PIM Neighbor Table
> Neighbor          Interface                Uptime/Expires    Ver   DR
> Address                                                            
> Prio/Mode
> <wanip>     FastEthernet1/1/0        04:14:05/00:01:39 v2    N /
> 
> 
> 	Maybe I?m missing something.... or this can be compatibility problem 
> between xorp and cisco? Any clues? I can see the PIM join messagens 
> going out from tunnel interface.
> 
> 	Btw... the xorp is running in a debian sarge. Kernel from distro, and a 
> little script to create the tun interface before the xorp_rtmgr is 
> started:
> 
> ip tunnel add tun0 mode gre remote 200.ci.s.co local 200.lo.ca.l dev 
> eth0
> 
> ifconfig tun0 allmulti
> ifconfig tun0 multicast


Your XORP configuration seems right. Well, you don't really need the
"lo" interface configuration, but it shouldn't hurt as long as you
don't touch it (e.g., reconfigure it).

You mentioned that you see PIM Join messages going out from the
tunnel interface. Do you see PIM Hello messages as well?

If yes, could you check whether they have the IP Router Alert option
set. This option shouldn't be set (it was specified in earlier drafts
of the PIM-SM spec, but not anymore), and some (Cisco?) equipment
might not like PIM control packets if the option is set.
XORP-1.3 and earlier had the IP Router Alert option included, but
this has been fixed in the latest XORP code in CVS.
If you are running XORP-1.3 (or earlier), please get the latest code
from anon CVS and see whether you still have the problem.

Regards,
Pavlin

> 
> -- 
> Christian Lyra
> POP-PR - RNP
> 
> http://lyra.soueu.com.br
> 
>   ``The rules of programming are transitory; only Tao is eternal. 
> Therefore you must contemplate Tao before you receive enlightenment.'' 
>   ``But how will I know when I have received enlightenment?'' asked the 
> novice. 
>   ``Your program will then run correctly,'' replied the master. 
> 						The Tao Of Programing
> 
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From lyra at pop-pr.rnp.br  Fri Feb  9 11:45:33 2007
From: lyra at pop-pr.rnp.br (Christian Lyra)
Date: Fri, 9 Feb 2007 17:45:33 -0200
Subject: [Xorp-users] multicast over GRE tunnel
In-Reply-To: <200702091859.l19Ixwp2084507@possum.icir.org>
References: <200702091859.l19Ixwp2084507@possum.icir.org>
Message-ID: <200702091745.34038.lyra@pop-pr.rnp.br>


>
>  Your XORP configuration seems right. Well, you don't really need the
>  "lo" interface configuration, but it shouldn't hurt as long as you
>  don't touch it (e.g., reconfigure it).

	right :-)
>
>  You mentioned that you see PIM Join messages going out from the
>  tunnel interface. Do you see PIM Hello messages as well?
>
	yes:
17:43:33.588639 IP 200.x.x.153 > 224.0.0.13: pim v2 Hello (Hold-time 
1m45s) (Genid: 0x000ee67a) (DR-Priority: 1) (State Refresh Capable; v1)
17:43:36.558766 IP 200.x.x.154 > 224.0.0.13: pim v2 Hello (Hold-time 
1m45s) (LAN-Prune-Delay: T-bit=0 lan-delay=500ms 
override-interval=2500ms) (DR-Priority: 1) (Genid: 0x4f41e2ab)

	153 is cisco, 154 is xorp.

>  If yes, could you check whether they have the IP Router Alert option
>  set. This option shouldn't be set (it was specified in earlier
> drafts of the PIM-SM spec, but not anymore), and some (Cisco?)
> equipment might not like PIM control packets if the option is set.

you mean this? 

xorp at teste# set protocols pimsm4 interface tun0 vif tun0 
enable-ip-router-alert-option-check false
[edit]
xorp at teste# commit

	didn work either. Perhaps cisco doenst like to greet a non-cisco 
router :-)

>  XORP-1.3 and earlier had the IP Router Alert option included, but
>  this has been fixed in the latest XORP code in CVS.
>  If you are running XORP-1.3 (or earlier), please get the latest code
>  from anon CVS and see whether you still have the problem.

	I?m using XORP-1.3. I will give the CVS one a try. Thanks for your 
reply.


-- 
Christian Lyra
POP-PR - RNP

http://lyra.soueu.com.br

  Why are programmers non-productive?
  Because their time is wasted in meetings. 
  Why are programmers rebellious?
  Because the management interferes too much. 
  Why are the programmers resigning one by one?
  Because they are burnt out. 
  Having worked for poor management, they no longer value their jobs. 
						The Tao Of Programing


From pavlin at icir.org  Fri Feb  9 12:49:53 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Fri, 09 Feb 2007 12:49:53 -0800
Subject: [Xorp-users] multicast over GRE tunnel
In-Reply-To: Message from Christian Lyra <lyra@pop-pr.rnp.br> of "Fri,
	09 Feb 2007 17:45:33 -0200." <200702091745.34038.lyra@pop-pr.rnp.br> 
Message-ID: <200702092049.l19KnrN9085357@possum.icir.org>

> >  You mentioned that you see PIM Join messages going out from the
> >  tunnel interface. Do you see PIM Hello messages as well?
> >
> 	yes:
> 17:43:33.588639 IP 200.x.x.153 > 224.0.0.13: pim v2 Hello (Hold-time 
> 1m45s) (Genid: 0x000ee67a) (DR-Priority: 1) (State Refresh Capable; v1)
> 17:43:36.558766 IP 200.x.x.154 > 224.0.0.13: pim v2 Hello (Hold-time 
> 1m45s) (LAN-Prune-Delay: T-bit=0 lan-delay=500ms 
> override-interval=2500ms) (DR-Priority: 1) (Genid: 0x4f41e2ab)
> 
> 	153 is cisco, 154 is xorp.

I don't remember whether the IP options are always printed, so could
you use a command like the following to make sure that option (if
presented) is not omitted from the tcpdump output:

tcpdump -i eth0 -n -vvv -s 0 -x proto \\pim

> >  If yes, could you check whether they have the IP Router Alert option
> >  set. This option shouldn't be set (it was specified in earlier
> > drafts of the PIM-SM spec, but not anymore), and some (Cisco?)
> > equipment might not like PIM control packets if the option is set.
> 
> you mean this? 
> 
> xorp at teste# set protocols pimsm4 interface tun0 vif tun0 
> enable-ip-router-alert-option-check false
> [edit]
> xorp at teste# commit
> 
> 	didn work either. Perhaps cisco doenst like to greet a non-cisco 
> router :-)

This option is to enable/disable the (now unnecessary) check whether
the received PIM control messages contain the IP Router Alert
option. Hence, it doesn't have effect on the outgoing packets.

> >  XORP-1.3 and earlier had the IP Router Alert option included, but
> >  this has been fixed in the latest XORP code in CVS.
> >  If you are running XORP-1.3 (or earlier), please get the latest code
> >  from anon CVS and see whether you still have the problem.
> 
> 	I?m using XORP-1.3. I will give the CVS one a try. Thanks for your 
> reply.

Please let us know what happens. Also, you might want to check the
Cisco's log messages for any clues (if you haven't done that yet).
If the CVS code doesn't solve the problem, we can start debugging
from there.

Regards,
Pavlin


> 
> -- 
> Christian Lyra
> POP-PR - RNP
> 
> http://lyra.soueu.com.br
> 
>   Why are programmers non-productive?
>   Because their time is wasted in meetings. 
>   Why are programmers rebellious?
>   Because the management interferes too much. 
>   Why are the programmers resigning one by one?
>   Because they are burnt out. 
>   Having worked for poor management, they no longer value their jobs. 
> 						The Tao Of Programing
> 
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From lyra at pop-pr.rnp.br  Sat Feb 10 03:16:22 2007
From: lyra at pop-pr.rnp.br (Christian Lyra)
Date: Sat, 10 Feb 2007 09:16:22 -0200
Subject: [Xorp-users] multicast over GRE tunnel
In-Reply-To: <200702091859.l19Ixwp2084507@possum.icir.org>
References: <200702091859.l19Ixwp2084507@possum.icir.org>
Message-ID: <200702100916.22990.lyra@pop-pr.rnp.br>

Hi there,

	Just a message to let you know that the setup below just works. But 
there was a few details missing. First when configuring the linux side 
of tunnel I had to explicit set the TTL with the command ifconfig tun0 
ttl 64. I took a while to found this... my firewall showed packets 
coming in one interface but didnt leaving on the other! Second, I had 
to disable rp_filter on xorp router! dont exactly know why. Btw there?s 
a missing detail on my setup description. Xorp router has only one 
ethernet card. It?s on the same net as desktops.


	Thanks for listening (er... reading :-) ).


On Friday 09 February 2007 16:59, Pavlin Radoslavov wrote:
>  Christian Lyra <lyra at pop-pr.rnp.br> wrote:
>  > Hi there,
>  >
>  > 	I?d like to setup a xorp router to do multicast over a GRE
>  > tunnel. My setup is like this:
>  >
>  > [multicast_enabled_net]----[Cisco-Router]---[no-multicast_net]--[x
>  >orp_router]---[desktops]
>  >
>  > 	Between Cisco-router and xorp_router there?s a GRE tunnel so I
>  > can trasverse the non_multicast_net. The protocol used is PIM-SM
>  > and there ?s a "static" RP on multicast_enabled_net.
>  >
>  > 	I?m sure that all the other parts are ok, because I had a cisco
>  > 2500 in the place of xorp_router and it work just fine with a
>  > simple config like this one:
>  >
>  > ip multicast-routing
>  > interface Tunnel1
>  >  ip address 200.x.x.154 255.255.255.252
>  >  ip pim sparse-mode
>  >  tunnel source 200.y.y.191
>  >  tunnel destination 200.y.y.9
>  >
>  > ip pim rp-address 200.z.z.z
>  > ip mroute 0.0.0.0 0.0.0.0 tunnel0
>  >
>  > 	I tried to emulate this same configuration with xorp:
>  >
>  > xorp at teste# show
>  >     protocols {
>  >         igmp {
>  >             interface eth0 {
>  >                 vif eth0 {
>  >                     query-interval: 30
>  >                 }
>  >             }
>  >             interface tun0 {
>  >                 vif tun0 {
>  >                 }
>  >             }
>  >         }
>  >         pimsm4 {
>  >             interface "register_vif" {
>  >                 vif "register_vif" {
>  >                 }
>  >             }
>  >             interface tun0 {
>  >                 vif tun0 {
>  >                 }
>  >             }
>  >             interface eth0 {
>  >                 vif eth0 {
>  >                 }
>  >             }
>  >             static-rps {
>  >                 rp 200.z.z.z {
>  >                     group-prefix 224.0.0.0/4 {
>  >                     }
>  >                 }
>  >             }
>  >         }
>  >         static {
>  >             route 0.0.0.0/0 {
>  >                 next-hop: 200.x.x.x
>  >             }
>  >             mrib-route 0.0.0.0/0 {
>  >                 next-hop: 200.x.x.153 /* tunnel */
>  > }
>  >         }
>  >     }
>  >     fea {
>  >         unicast-forwarding4 {
>  >         }
>  >     }
>  >     interfaces {
>  >         interface eth0 {
>  >             vif eth0 {
>  >                 address 200.x.x.191 {
>  >                     prefix-length: 24
>  >                 }
>  >             }
>  >         }
>  >         interface lo {
>  >             vif lo {
>  >             }
>  >         }
>  >         interface tun0 {
>  >             vif tun0 {
>  >                 address 200.x.x.154 {
>  >                     prefix-length: 30
>  >                     multicast-capable: true
>  >                 }
>  >             }
>  >         }
>  >     }
>  >     plumbing {
>  >         mfea4 {
>  >             interface eth0 {
>  >                 vif eth0 {
>  >                 }
>  >             }
>  >             interface "register_vif" {
>  >                 vif "register_vif" {
>  >                 }
>  >             }
>  > 	interface tun0 {
>  >                 vif tun0 {
>  >                 }
>  >             }
>  >         }
>  >     }
>  >
>  >
>  > 	One thing that I noticed is this:
>  > xorp at teste> show pim neighbors
>  > Interface    DRpriority NeighborAddr    V Mode   Holdtime Timeout
>  > tun0                  1 200.x.x.153   2 Sparse      105      82
>  >
>  >
>  > 	But Cisco doesnt see the xorp as a neighbor! (when using the
>  > cisco 2500 instead of xorp, this Cisco router sees two neighbors,
>  > one is the upstream one and the other the 2500).
>  >
>  > bb3#show ip pim neighbor
>  > PIM Neighbor Table
>  > Neighbor          Interface                Uptime/Expires    Ver  
>  > DR Address
>  > Prio/Mode
>  > <wanip>     FastEthernet1/1/0        04:14:05/00:01:39 v2    N /
>  >
>  >
>  > 	Maybe I?m missing something.... or this can be compatibility
>  > problem between xorp and cisco? Any clues? I can see the PIM join
>  > messagens going out from tunnel interface.
>  >
>  > 	Btw... the xorp is running in a debian sarge. Kernel from distro,
>  > and a little script to create the tun interface before the
>  > xorp_rtmgr is started:
>  >
>  > ip tunnel add tun0 mode gre remote 200.ci.s.co local 200.lo.ca.l
>  > dev eth0
>  >
>  > ifconfig tun0 allmulti
>  > ifconfig tun0 multicast
>
>  Your XORP configuration seems right. Well, you don't really need the
>  "lo" interface configuration, but it shouldn't hurt as long as you
>  don't touch it (e.g., reconfigure it).
>
>  You mentioned that you see PIM Join messages going out from the
>  tunnel interface. Do you see PIM Hello messages as well?
>
>  If yes, could you check whether they have the IP Router Alert option
>  set. This option shouldn't be set (it was specified in earlier
> drafts of the PIM-SM spec, but not anymore), and some (Cisco?)
> equipment might not like PIM control packets if the option is set.
>  XORP-1.3 and earlier had the IP Router Alert option included, but
>  this has been fixed in the latest XORP code in CVS.
>  If you are running XORP-1.3 (or earlier), please get the latest code
>  from anon CVS and see whether you still have the problem.
>
>  Regards,
>  Pavlin
>
>  > --
>  > Christian Lyra
>  > POP-PR - RNP
>  >
>  > http://lyra.soueu.com.br
>  >
>  >   ``The rules of programming are transitory; only Tao is eternal.
>  > Therefore you must contemplate Tao before you receive
>  > enlightenment.'' ``But how will I know when I have received
>  > enlightenment?'' asked the novice.
>  >   ``Your program will then run correctly,'' replied the master.
>  > 						The Tao Of Programing
>  >
>  > _______________________________________________
>  > Xorp-users mailing list
>  > Xorp-users at xorp.org
>  > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users

-- 
Christian Lyra
POP-PR - RNP

http://lyra.soueu.com.br

  Thus spake the master programmer: 
  ``After three days without programming, life becomes meaningless.'' 
						The Tao Of Programing


From pavlin at icir.org  Sat Feb 10 14:19:01 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Sat, 10 Feb 2007 14:19:01 -0800
Subject: [Xorp-users] multicast over GRE tunnel
In-Reply-To: Message from Christian Lyra <lyra@pop-pr.rnp.br> of "Sat,
	10 Feb 2007 09:16:22 -0200." <200702100916.22990.lyra@pop-pr.rnp.br> 
Message-ID: <200702102219.l1AMJ1w1006215@possum.icir.org>

> 	Just a message to let you know that the setup below just works. But 
> there was a few details missing. First when configuring the linux side 
> of tunnel I had to explicit set the TTL with the command ifconfig tun0 
> ttl 64. I took a while to found this... my firewall showed packets 
> coming in one interface but didnt leaving on the other! Second, I had 
> to disable rp_filter on xorp router! dont exactly know why. Btw there?s 
> a missing detail on my setup description. Xorp router has only one 
> ethernet card. It?s on the same net as desktops.

Great!
I should had realized earlier that there could be missing pieces in
your GRE tunnel setup.
For the record, below is an example (taken from pimd README.config)
for setting a GRE tunnel.

1.1 GRE tunnel between two machines (host 11.11.11.11 and
  33.33.33.33)

Physical interfaces:    [11.11.11.11]         [33.33.33.33]
GRE tunnel:              22.22.22.11<--------->22.22.22.33

==== host 11.11.11.11 (GRE interface 22.22.22.11)
echo 1 > /proc/sys/net/ipv4/ip_forward
echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
ip link set gre1 down
ip tunnel del gre1
ip tunnel add gre1 mode gre remote 33.33.33.33 local 11.11.11.11 ttl
127
ip addr add 22.22.22.11/24 peer 22.22.22.33/24 dev gre1
ip link set gre1 up multicast on


==== host 33.33.33.33 (GRE interface 22.22.22.33)
echo 1 > /proc/sys/net/ipv4/ip_forward
echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
ip link set gre1 down
ip tunnel del gre1
ip tunnel add gre1 mode gre remote 11.11.11.11 local 33.33.33.33 ttl
127
ip addr add 22.22.22.33/24 peer 22.22.22.11/24 dev gre1
ip link set gre1 up multicast on

I just added a subsection to the XORP User Manual for configuring
a multicast tunnel. For now the examples are for GRE and OpenVPN.
If someone has working examples for other tunnels/setups, please let
me know so I can include them in the document.

Pavlin


From agaviola at infoweapons.com  Tue Feb 13 02:30:05 2007
From: agaviola at infoweapons.com (Archimedes S. Gaviola)
Date: Tue, 13 Feb 2007 18:30:05 +0800
Subject: [Xorp-users] Question on XORP PIM-SSM Support
Message-ID: <00b601c74f59$fd220fa0$0b02030a@cebu.infoweapons.com>

To Whom It May Concerned:
 
Hi! I'm currently investigating XORP release 1.3 for our multicast router
with PIM SSM. Is there any specific configuration parameters we need to
specify in the config.boot file with SSM? As I can see it, the default
configuration does have the ASM configuration with RP as specified. Thank
you very much.
 
Sincerely Yours,
 
Archimedes S. Gaviola
Network Engineer
InfoWeapons Corporation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070213/c4882e2b/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3353 bytes
Desc: not available
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070213/c4882e2b/attachment.bin 

From vkaul at research.telcordia.com  Tue Feb 13 09:18:06 2007
From: vkaul at research.telcordia.com (Vikram KAUL)
Date: Tue, 13 Feb 2007 12:18:06 -0500 (Eastern Standard Time)
Subject: [Xorp-users] Change in RP vs change in next-hop for RP
In-Reply-To: <200701312153.l0VLrpxA068096@possum.icir.org>
References: <200701312153.l0VLrpxA068096@possum.icir.org>
Message-ID: <Pine.WNT.4.60.0702131210130.1212@vkaul-laptop>


Hi Pavlin,

 Please see below..

pavlin>>   Specifically, where are the conditions addressed when the RP itself 
pavlin>> changes for the (*,G) and (*,*,RP) state. Not the next hop changes, but 
pavlin>> the RP changes when the group is active. Is the protocol designed to 
pavlin>> handle this ?
pavlin>> 
pavlin>>From the perspective of transmitting the Join/Prune messages toward
pavlin>the RP it is important to send the messages in the right direction
pavlin>(i.e., next-hop router), and the downstream routers don't really
pavlin>care about the particular RP address. In fact, if we ignore the PIM
pavlin>Register mechanism, then the RP address doesn't even have to belong
pavlin>to a real host, and this is exactly how Bidir-PIM works.
pavlin>
pavlin>That said, it is important to notice only if the next-hop router
pavlin>toward the RP changes, regardless whether the change is because the
pavlin>underlying RPF information changed or because the RP address was
pavlin>changed. In other words, the RP change will translate eventually in
pavlin>same handling as the RPF(*,G) change.
pavlin>
pavlin>Note that even though the (*,G) Join message conains the RP address
pavlin>for group G, there is no need to trigger immediately a new (*,G)
pavlin>Join message with the new RP address if the next-hop router hasn't
pavlin>changed. The new RP address will be included with the next periodic
pavlin>(*,G) Join message.

Is this the current handling in XORP ? Can you point to the section of the 
code where I can see this happen ? Thanks for your help in advance

regards..
Vikram


From pavlin at icir.org  Tue Feb 13 10:34:02 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Tue, 13 Feb 2007 10:34:02 -0800
Subject: [Xorp-users] Question on XORP PIM-SSM Support
In-Reply-To: Message from "Archimedes S. Gaviola" <agaviola@infoweapons.com> 
	of "Tue, 13 Feb 2007 18:30:05 +0800."
	<00b601c74f59$fd220fa0$0b02030a@cebu.infoweapons.com> 
Message-ID: <200702131834.l1DIY2gq040067@possum.icir.org>

Archimedes S. Gaviola <agaviola at infoweapons.com> wrote:

> Hi! I'm currently investigating XORP release 1.3 for our multicast router
> with PIM SSM. Is there any specific configuration parameters we need to
> specify in the config.boot file with SSM? As I can see it, the default
> configuration does have the ASM configuration with RP as specified. Thank
> you very much.

The only SSM-specific thing you need to apply to your configuration
is to set the IGMP version to 3 (for IPv6 the MLD version has to be
set to 2), because the default version is IGMPv2 and MLDv1. E.g.

protocols {
    igmp {
        interface eth0 {
            vif eth0 {
                disable: false
                version: 3
            }
        }
        ...
    }
}

FYI, in the future IGMPv3 and MLDv2 might become the default so you
won't need the "version" statement.

The bootstrap and the static-rps configurations are optional,
so you don't need to include it. In fact, you could use SSM even if
you have then configured.

Please let us know how it goes.

Regards,
Pavlin

> Sincerely Yours,
>  
> Archimedes S. Gaviola
> Network Engineer
> InfoWeapons Corporation
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From pavlin at icir.org  Tue Feb 13 10:52:57 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Tue, 13 Feb 2007 10:52:57 -0800
Subject: [Xorp-users] Change in RP vs change in next-hop for RP
In-Reply-To: Message from Vikram KAUL <vkaul@research.telcordia.com> of "Tue,
	13 Feb 2007 12:18:06 EST."
	<Pine.WNT.4.60.0702131210130.1212@vkaul-laptop> 
Message-ID: <200702131852.l1DIqvjw040281@possum.icir.org>

>  Please see below..
> 
> pavlin>>   Specifically, where are the conditions addressed when the RP itself 
> pavlin>> changes for the (*,G) and (*,*,RP) state. Not the next hop changes, but 
> pavlin>> the RP changes when the group is active. Is the protocol designed to 
> pavlin>> handle this ?
> pavlin>> 
> pavlin>>From the perspective of transmitting the Join/Prune messages toward
> pavlin>the RP it is important to send the messages in the right direction
> pavlin>(i.e., next-hop router), and the downstream routers don't really
> pavlin>care about the particular RP address. In fact, if we ignore the PIM
> pavlin>Register mechanism, then the RP address doesn't even have to belong
> pavlin>to a real host, and this is exactly how Bidir-PIM works.
> pavlin>
> pavlin>That said, it is important to notice only if the next-hop router
> pavlin>toward the RP changes, regardless whether the change is because the
> pavlin>underlying RPF information changed or because the RP address was
> pavlin>changed. In other words, the RP change will translate eventually in
> pavlin>same handling as the RPF(*,G) change.
> pavlin>
> pavlin>Note that even though the (*,G) Join message conains the RP address
> pavlin>for group G, there is no need to trigger immediately a new (*,G)
> pavlin>Join message with the new RP address if the next-hop router hasn't
> pavlin>changed. The new RP address will be included with the next periodic
> pavlin>(*,G) Join message.
> 
> Is this the current handling in XORP ? Can you point to the section of the 
> code where I can see this happen ? Thanks for your help in advance

Yes. The relevant code for handling various RPF-related events is in
pim/pim_mre_rpf.cc. Note that each PimMre::recompute_FOO() method is
a single action (per multicast routing entry).

However, handling the event "RP changed" might require a number of
actions (even per same multicast routing entry).
FYI, those actions are listed in human-readable format (in the order
they are executed) inside pim/docs/pim_track_state_name.txt:

Input = INPUT_STATE_RP_CHANGED
        OUTPUT_STATE_MRIB_RP_RP                                    (*,*,RP)
        OUTPUT_STATE_NBR_MRIB_NEXT_HOP_RP_RP                       (*,*,RP)
        OUTPUT_STATE_RP_WC                                            (*,G)
        OUTPUT_STATE_MRIB_RP_WC                                       (*,G)
        OUTPUT_STATE_IS_JOIN_DESIRED_WC                               (*,G)
        OUTPUT_STATE_NBR_MRIB_NEXT_HOP_RP_WC                          (*,G)
        OUTPUT_STATE_RPFP_NBR_WC_NOT_ASSERT                           (*,G)
        OUTPUT_STATE_COULD_ASSERT_WC                                  (*,G)
        OUTPUT_STATE_ASSERT_TRACKING_DESIRED_WC                       (*,G)
        OUTPUT_STATE_MY_ASSERT_METRIC_WC                              (*,G)
        OUTPUT_STATE_RP_SG                                            (S,G)
        OUTPUT_STATE_RP_SG_RPT                                    (S,G,rpt)
        OUTPUT_STATE_MRIB_RP_SG                                       (S,G)
        OUTPUT_STATE_MRIB_RP_SG_RPT                               (S,G,rpt)
        OUTPUT_STATE_INHERITED_OLIST_SG_RPT                       (S,G,rpt)
        OUTPUT_STATE_IS_JOIN_DESIRED_SG                               (S,G)
        OUTPUT_STATE_IS_RPT_JOIN_DESIRED_G                        (S,G,rpt)
        OUTPUT_STATE_IS_PRUNE_DESIRED_SG_RPT                      (S,G,rpt)
        OUTPUT_STATE_IS_PRUNE_DESIRED_SG_RPT_SG                       (S,G)
        OUTPUT_STATE_IS_COULD_REGISTER_SG                             (S,G)
        OUTPUT_STATE_ASSERT_TRACKING_DESIRED_SG                       (S,G)
        OUTPUT_STATE_COULD_ASSERT_SG                                  (S,G)
        OUTPUT_STATE_MY_ASSERT_METRIC_SG                              (S,G)
        OUTPUT_STATE_RPFP_NBR_SG_RPT                              (S,G,rpt)
        OUTPUT_STATE_RPFP_NBR_SG_RPT_SG                               (S,G)
        OUTPUT_STATE_SET_KEEPALIVE_TIMER_SG                           (S,G)
        OUTPUT_STATE_RP_MFC                                           (MFC)
        OUTPUT_STATE_IIF_OLIST_MFC                                    (MFC)
        OUTPUT_STATE_MONITORING_SWITCH_TO_SPT_DESIRED_MFC             (MFC)
        OUTPUT_STATE_UPDATE_SPTBIT_MFC                                (MFC)

If you are curious about the mapping between OUTPUT_STATE_FOO and
the corresponding PimMre C++ method, please check (both) methods
PimMreAction::perform_action() inside pim/pim_mre_track_state.cc.
FYI, the above list was generated automatically by the event
dependency tracking mechanism implemented in XORP.

Regards,
Pavlin


From agaviola at infoweapons.com  Tue Feb 13 17:43:39 2007
From: agaviola at infoweapons.com (Archimedes S. Gaviola)
Date: Wed, 14 Feb 2007 09:43:39 +0800
Subject: [Xorp-users] Question on XORP PIM-SSM Support
In-Reply-To: <200702131834.l1DIY2gq040067@possum.icir.org>
References: Message from "Archimedes S. Gaviola" <agaviola@infoweapons.com> of
	"Tue, 13 Feb 2007 18:30:05 +0800."
	<00b601c74f59$fd220fa0$0b02030a@cebu.infoweapons.com>
	<200702131834.l1DIY2gq040067@possum.icir.org>
Message-ID: <000901c74fd9$9cc93cc0$0b02030a@cebu.infoweapons.com>

Sir Pavlin,

Thank you very much for your reply. Yes, once I got my PIM SSM multicast
network works, then I'll let you know how my XORP router behaves.

Sincerely Yours,

Archimedes S. Gaviola
Network Engineer
InfoWeapons Corporation

-----Original Message-----
From: Pavlin Radoslavov [mailto:pavlin at icir.org] 
Sent: Wednesday, February 14, 2007 2:34 AM
To: Archimedes S. Gaviola
Cc: xorp-users at xorp.org
Subject: Re: [Xorp-users] Question on XORP PIM-SSM Support 

Archimedes S. Gaviola <agaviola at infoweapons.com> wrote:

> Hi! I'm currently investigating XORP release 1.3 for our multicast 
> router with PIM SSM. Is there any specific configuration parameters we 
> need to specify in the config.boot file with SSM? As I can see it, the 
> default configuration does have the ASM configuration with RP as 
> specified. Thank you very much.

The only SSM-specific thing you need to apply to your configuration is to
set the IGMP version to 3 (for IPv6 the MLD version has to be set to 2),
because the default version is IGMPv2 and MLDv1. E.g.

protocols {
    igmp {
        interface eth0 {
            vif eth0 {
                disable: false
                version: 3
            }
        }
        ...
    }
}

FYI, in the future IGMPv3 and MLDv2 might become the default so you won't
need the "version" statement.

The bootstrap and the static-rps configurations are optional, so you don't
need to include it. In fact, you could use SSM even if you have then
configured.

Please let us know how it goes.

Regards,
Pavlin

> Sincerely Yours,
>  
> Archimedes S. Gaviola
> Network Engineer
> InfoWeapons Corporation
> _______________________________________________
> 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: smime.p7s
Type: application/x-pkcs7-signature
Size: 3353 bytes
Desc: not available
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070214/a3300fa5/attachment.bin 

From neeraj.prasad at gmail.com  Thu Feb 15 00:32:10 2007
From: neeraj.prasad at gmail.com (Neeraj Prasad)
Date: Thu, 15 Feb 2007 14:02:10 +0530
Subject: [Xorp-users] Xorp-users Digest, Vol 11, Issue 9
In-Reply-To: <mailman.5.1171483203.18372.xorp-users@xorp.org>
References: <mailman.5.1171483203.18372.xorp-users@xorp.org>
Message-ID: <1d413a090702150032j1d5b53d6k5627acf0def8a821@mail.gmail.com>

Hi,

Is XORP latest version supporting PIM-SSM. I could not see such behaviour
nor could I get any configuration statement to do so.

Regards,
Neeraj.


On 2/15/07, xorp-users-request at xorp.org <xorp-users-request at xorp.org> wrote:
>
> Send Xorp-users mailing list submissions to
>         xorp-users at xorp.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
> or, via email, send a message with subject or body 'help' to
>         xorp-users-request at xorp.org
>
> You can reach the person managing the list at
>         xorp-users-owner at xorp.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Xorp-users digest..."
>
>
> Today's Topics:
>
>    1. Re: Question on XORP PIM-SSM Support (Archimedes S. Gaviola)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 14 Feb 2007 09:43:39 +0800
> From: "Archimedes S. Gaviola" <agaviola at infoweapons.com>
> Subject: Re: [Xorp-users] Question on XORP PIM-SSM Support
> To: "'Pavlin Radoslavov'" <pavlin at icir.org>
> Cc: xorp-users at xorp.org
> Message-ID: <000901c74fd9$9cc93cc0$0b02030a at cebu.infoweapons.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Sir Pavlin,
>
> Thank you very much for your reply. Yes, once I got my PIM SSM multicast
> network works, then I'll let you know how my XORP router behaves.
>
> Sincerely Yours,
>
> Archimedes S. Gaviola
> Network Engineer
> InfoWeapons Corporation
>
> -----Original Message-----
> From: Pavlin Radoslavov [mailto:pavlin at icir.org]
> Sent: Wednesday, February 14, 2007 2:34 AM
> To: Archimedes S. Gaviola
> Cc: xorp-users at xorp.org
> Subject: Re: [Xorp-users] Question on XORP PIM-SSM Support
>
> Archimedes S. Gaviola <agaviola at infoweapons.com> wrote:
>
> > Hi! I'm currently investigating XORP release 1.3 for our multicast
> > router with PIM SSM. Is there any specific configuration parameters we
> > need to specify in the config.boot file with SSM? As I can see it, the
> > default configuration does have the ASM configuration with RP as
> > specified. Thank you very much.
>
> The only SSM-specific thing you need to apply to your configuration is to
> set the IGMP version to 3 (for IPv6 the MLD version has to be set to 2),
> because the default version is IGMPv2 and MLDv1. E.g.
>
> protocols {
>     igmp {
>         interface eth0 {
>             vif eth0 {
>                 disable: false
>                 version: 3
>             }
>         }
>         ...
>     }
> }
>
> FYI, in the future IGMPv3 and MLDv2 might become the default so you won't
> need the "version" statement.
>
> The bootstrap and the static-rps configurations are optional, so you don't
> need to include it. In fact, you could use SSM even if you have then
> configured.
>
> Please let us know how it goes.
>
> Regards,
> Pavlin
>
> > Sincerely Yours,
> >
> > Archimedes S. Gaviola
> > Network Engineer
> > InfoWeapons Corporation
> > _______________________________________________
> > 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: smime.p7s
> Type: application/x-pkcs7-signature
> Size: 3353 bytes
> Desc: not available
> Url :
> http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070214/a3300fa5/attachment-0001.bin
>
> ------------------------------
>
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
>
>
> End of Xorp-users Digest, Vol 11, Issue 9
> *****************************************
>



-- 
Thanks and Regards,
Neeraj Prasad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070215/78c3e52b/attachment.html 

From pavlin at icir.org  Thu Feb 15 11:01:55 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Thu, 15 Feb 2007 11:01:55 -0800
Subject: [Xorp-users] Xorp-users Digest, Vol 11, Issue 9
In-Reply-To: Message from "Neeraj Prasad" <neeraj.prasad@gmail.com> of "Thu,
	15 Feb 2007 14:02:10 +0530."
	<1d413a090702150032j1d5b53d6k5627acf0def8a821@mail.gmail.com> 
Message-ID: <200702151901.l1FJ1t9W061355@possum.icir.org>

> Is XORP latest version supporting PIM-SSM. I could not see such behaviour
> nor could I get any configuration statement to do so.

The base PIM-SM spec includes PIM-SSM as well, and yes, XORP
supports PIM-SSM.
There is no need for any pimsm{4,6} configuration statements to
enable/use PIM-SSM. The difference is that if you are going to
use only PIM-SSM, then you don't need to configure any RP-related
information (the "bootstrap" and the "static-rps" statements).

The only thing you need to do is to set the IGMP version to 3 (as I
mentioned in my previous email):

protocols {
    igmp {
        interface eth0 {
            vif eth0 {
                disable: false
                version: 3
            }
        }
        ...
    }
}

And, of course, your host (the receiver) must support IGMPv3 in the
kernel.
BTW, I believe the host/router running XORP doesn't need to have
IGMPv3 support in the kernel if it will be used only for SSM routing
(i.e., if you won't be running SSM application on the same host),
because all IGMPv3 router-side processing is done in userland by
XORP.

Regards,
Pavlin


From neeraj.prasad at gmail.com  Sat Feb 17 04:10:23 2007
From: neeraj.prasad at gmail.com (Neeraj Prasad)
Date: Sat, 17 Feb 2007 17:40:23 +0530
Subject: [Xorp-users] PIM registering process
Message-ID: <1d413a090702170410h6e1f084cvfb11f3265022b1ae@mail.gmail.com>

Thanks Pavlin. I was unable to see any SSM behaviour in XORP so this
question.

Also, is there some problem with PIM register. I did the usual set up and
configuration but the system wont register encapsulate the data packet. All
parameters were correctly mentioned and why register_vif takes address of
the first physical interface.

Regards,
Neeraj.



On 2/16/07, Pavlin Radoslavov <pavlin at icir.org> wrote:
>
> > Is XORP latest version supporting PIM-SSM. I could not see such
> behaviour
> > nor could I get any configuration statement to do so.
>
> The base PIM-SM spec includes PIM-SSM as well, and yes, XORP
> supports PIM-SSM.
> There is no need for any pimsm{4,6} configuration statements to
> enable/use PIM-SSM. The difference is that if you are going to
> use only PIM-SSM, then you don't need to configure any RP-related
> information (the "bootstrap" and the "static-rps" statements).
>
> The only thing you need to do is to set the IGMP version to 3 (as I
> mentioned in my previous email):
>
> protocols {
>    igmp {
>        interface eth0 {
>            vif eth0 {
>                disable: false
>                version: 3
>            }
>        }
>        ...
>    }
> }
>
> And, of course, your host (the receiver) must support IGMPv3 in the
> kernel.
> BTW, I believe the host/router running XORP doesn't need to have
> IGMPv3 support in the kernel if it will be used only for SSM routing
> (i.e., if you won't be running SSM application on the same host),
> because all IGMPv3 router-side processing is done in userland by
> XORP.
>
> Regards,
> Pavlin
>



-- 
Thanks and Regards,
Neeraj Prasad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070217/0326480f/attachment.html 

From pavlin at icir.org  Sat Feb 17 07:58:20 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Sat, 17 Feb 2007 07:58:20 -0800
Subject: [Xorp-users] PIM registering process
In-Reply-To: Message from "Neeraj Prasad" <neeraj.prasad@gmail.com> of "Sat,
	17 Feb 2007 17:40:23 +0530."
	<1d413a090702170410h6e1f084cvfb11f3265022b1ae@mail.gmail.com> 
Message-ID: <200702171558.l1HFwKH1088480@possum.icir.org>

> Thanks Pavlin. I was unable to see any SSM behaviour in XORP so this
> question.

If it still doesn't work, did you try to debug the problem?
A starting point would be the "show igmp group" xorpsh command on
the router directly connected to the SSM receiver. If it shows the
(S,G) receiver, then the "show pim join" xorpsh command should show
the (S,G) PIM-SM state.

> Also, is there some problem with PIM register. I did the usual set up and
> configuration but the system wont register encapsulate the data packet. All
> parameters were correctly mentioned and why register_vif takes address of
> the first physical interface.

I presume here you are talking about ASM and that you had configured
the Cand-RP set, because PIM Registers are not needed/used with SSM.

It is normal for register_vif to take the address of the first
physical interface.
Did the PIM-SM (S,G) state for the directly connected sender (use
the "show pim join" command to see it) contained the register_vif in
the outgoing interface set? If yes, what about the MFC state
("show pim mfea")?

Regards,
Pavlin


From neeraj.prasad at gmail.com  Sun Feb 18 01:26:27 2007
From: neeraj.prasad at gmail.com (Neeraj Prasad)
Date: Sun, 18 Feb 2007 14:56:27 +0530
Subject: [Xorp-users] PIM registering process
In-Reply-To: <200702171558.l1HFwKH1088480@possum.icir.org>
References: <neeraj.prasad@gmail.com>
	<1d413a090702170410h6e1f084cvfb11f3265022b1ae@mail.gmail.com>
	<200702171558.l1HFwKH1088480@possum.icir.org>
Message-ID: <1d413a090702180126s60df6014h6264f3fb81fd23c3@mail.gmail.com>

I will do a debug and let you know the results, for the PIM SSM related
issues.

With respect to the PIM register issue, i had this topology

if1------x1,x2---------if2

I mentioned if2 as the RP on XORP router(x1 and x2 represent the XORP
interfaces and if1 and if2 are interfaces on my machine), the register_vif
takes IP address of interface x1.

I am sending a UDP data packet from if1 to 225.1.1.1, and I am capturing
packets on if2 using ethereal, but no PIM Register packets are arriving on
if2.

I am receiving PIM hello on both if1 and if2.

Also, I dont need to send PIM hello from if1 and if2 as it is not required
since PIM Registers are unicast.

Am i missing something.

Regards,
Neeraj.



On 2/17/07, Pavlin Radoslavov <pavlin at icir.org> wrote:
>
> > Thanks Pavlin. I was unable to see any SSM behaviour in XORP so this
> > question.
>
> If it still doesn't work, did you try to debug the problem?
> A starting point would be the "show igmp group" xorpsh command on
> the router directly connected to the SSM receiver. If it shows the
> (S,G) receiver, then the "show pim join" xorpsh command should show
> the (S,G) PIM-SM state.
>
> > Also, is there some problem with PIM register. I did the usual set up
> and
> > configuration but the system wont register encapsulate the data packet.
> All
> > parameters were correctly mentioned and why register_vi





f takes address of
> > the first physical interface.
>
> I presume here you are talking about ASM and that you had configured
> the Cand-RP set, because PIM Registers are not needed/used with SSM.
>
> It is normal for register_vif to take the address of the first
> physical interface.
> Did the PIM-SM (S,G) state for the directly connected sender (use
> the "show pim join" command to see it) contained the register_vif in
> the outgoing interface set? If yes, what about the MFC state
> ("show pim mfea")?
>
> Regards,
> Pavlin
>



-- 
Thanks and Regards,
Neeraj Prasad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070218/b4f9a0bb/attachment.html 

From pavlin at icir.org  Sun Feb 18 13:16:10 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Sun, 18 Feb 2007 13:16:10 -0800
Subject: [Xorp-users] PIM registering process
In-Reply-To: Message from "Neeraj Prasad" <neeraj.prasad@gmail.com> of "Sun,
	18 Feb 2007 14:56:27 +0530."
	<1d413a090702180126s60df6014h6264f3fb81fd23c3@mail.gmail.com> 
Message-ID: <200702182116.l1ILGAcf092685@possum.icir.org>

> With respect to the PIM register issue, i had this topology
> 
> if1------x1,x2---------if2
> 
> I mentioned if2 as the RP on XORP router(x1 and x2 represent the XORP
> interfaces and if1 and if2 are interfaces on my machine), the register_vif
> takes IP address of interface x1.
> 
> I am sending a UDP data packet from if1 to 225.1.1.1, and I am capturing
> packets on if2 using ethereal, but no PIM Register packets are arriving on
> if2.

You need to look into the "show pim join" and "show pim mfc" to see
whether the register_vif is really in the oifs set. Also,
double-check that the TTL of the data packets originated by if1 is
larger than 1.

> I am receiving PIM hello on both if1 and if2.
> 
> Also, I dont need to send PIM hello from if1 and if2 as it is not required
> since PIM Registers are unicast.

Periodic sending of PIM Hello packets on all enabled interfaces is
required by the PIM spec.

Regards,
Pavlin


From agaviola at infoweapons.com  Tue Feb 13 02:09:00 2007
From: agaviola at infoweapons.com (Archimedes S. Gaviola)
Date: Tue, 13 Feb 2007 18:09:00 +0800
Subject: [Xorp-users] Question on XORP PIM-SSM Support
Message-ID: <009c01c74f57$0c88f600$0b02030a@cebu.infoweapons.com>

To Whom It May Concerned:
 
Hi! I'm currently investigating XORP release 1.3 for our multicast router
with PIM SSM. Is there any specific configuration parameters we need to
specify in the config.boot file with SSM? As I can see it, the default
configuration does have the ASM configuration with RP as specified. Thank
you very much.
 
Sincerely Yours,
 
Archimedes S. Gaviola
Network Engineer
InfoWeapons Corporation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070213/34f28397/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3353 bytes
Desc: not available
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070213/34f28397/attachment.bin 

From ashishkarpe at gmail.com  Sat Feb 24 01:33:42 2007
From: ashishkarpe at gmail.com (Ashish Karpe)
Date: Sat, 24 Feb 2007 15:03:42 +0530
Subject: [Xorp-users] query about igmp !!!
Message-ID: <f87e63a0702240133u7b39f719yfffae00648681448@mail.gmail.com>

Hi all,
        In PIM-SM how to create groups ? i.e how to send request from
receiver (Host) to join a particular group ? is there any command for it ?

Thank you,
Ashish
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070224/d265e114/attachment.html 

From pavlin at icir.org  Sat Feb 24 07:09:58 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Sat, 24 Feb 2007 07:09:58 -0800
Subject: [Xorp-users] query about igmp !!!
In-Reply-To: Message from "Ashish Karpe" <ashishkarpe@gmail.com> of "Sat,
	24 Feb 2007 15:03:42 +0530."
	<f87e63a0702240133u7b39f719yfffae00648681448@mail.gmail.com> 
Message-ID: <200702241509.l1OF9wRQ057876@possum.icir.org>

>         In PIM-SM how to create groups ? i.e how to send request from
> receiver (Host) to join a particular group ? is there any command for it ?

You need an external command/application running on the receiver
host. MGEN is a program that can be used to send or receive
multicast traffic, etc:
http://cs.itd.nrl.navy.mil/work/mgen/index.php

Alternatively, mtest is a bare-bones sender/receiver program
available from:
http://netweb.usc.edu/pim/pimd/

Regards,
Pavlin


From agaviola at infoweapons.com  Tue Feb 27 05:39:16 2007
From: agaviola at infoweapons.com (agaviola at infoweapons.com)
Date: Tue, 27 Feb 2007 21:39:16 +0800 (PHT)
Subject: [Xorp-users] XORP 1.3 PIM-SSM Support
Message-ID: <4266.10.3.2.11.1172583556.squirrel@mail2.infoweapons.com>

Sir Pavlin,

Based on my evaluation with XORP 1.3, PIM-SSM support works. I got two
FreeBSD machines that act as IPv4 multicast routers with source and
receiver nodes using Windows XP SP2 installed with VLC, source as the
streaming server while receiver as the client. Since IGMPv3 is required on
SSM operation, so Windows XP platform and VLC application are used.

Simulated network setup:

  +----------+    192.168.96.50/24 +------------+
  | Source/  +---------------------| PIM-SSM    |
  | Sender   |                     | router 1   |
  +----------+                     +-----+------+
192.168.96.49/24                         | 10.3.2.18/12
                                         |
                                         | (unicast static route)
                                         |
                                         |
                                         | 10.3.2.20/12
  +----------+    192.168.96.50/24 +-----+------+
  | Client/  +---------------------| PIM-SSM    |
  | Receiver |                     | router 2   |
  +----------+                     +------------+
 192.168.97.49/24

Multicast router (PIM-SSM) configurations:

archie# /usr/local/xorp/config.boot

interfaces {
    interface em0 {
        description: "upstream interface"
        disable: false
        default-system-config
    }
    interface vr0 {
        description: "downstream interface"
        disable: false
        default-system-config
    }
}

fea {
    unicast-forwarding4 {
        disable: false
    }
}

plumbing {
    mfea4 {
        disable: false
        interface em0 {
            vif em0 {
                disable: false
            }
        }
        interface vr0 {
            vif vr0 {
                disable: false
            }
        }
        interface register_vif {
            vif register_vif {
                disable: false
            }
        }
        traceoptions {
            flag all {
                disable: false
            }
        }
    }
}

protocols {
    igmp {
        disable: false
        interface em0 {
            vif em0 {
                version: 3
                disable: false
            }
        }
        interface vr0 {
            vif vr0 {
                version: 3
                disable: false
            }
        }
        traceoptions {
            flag all {
                disable: false
           }
       }
    }
}

protocols {
    pimsm4 {
       disable: false
       interface em0 {
           vif em0 {
              disable: false
           }
        }
        interface vr0 {
           vif vr0 {
              disable: false
           }
        }
       interface register_vif {
                vif register_vif {
                disable: false
                   }
               }
        traceoptions {
           flag all {
              disable: false
              }
           }
      }
  }

protocols {
    fib2mrib {
        disable: false
    }
}

Running XORP routing manager....

archie# /usr/local/xorp/bin/xorp_rtrmgr

[ 2007/02/27 19:42:49  INFO xorp_rtrmgr:1801 RTRMGR +240
master_conf_tree.cc execute ] Changed modules: interfaces, fea, mfea4,
rib, fib2mrib, igmp, pimsm4
[ 2007/02/27 19:42:49  INFO xorp_rtrmgr:1801 RTRMGR +99 module_manager.cc
execute ] Executing module: interfaces (fea/xorp_fea)
[ 2007/02/27 19:42:49 INFO xorp_fea MFEA ] MFEA enabled
[ 2007/02/27 19:42:49 INFO xorp_fea MFEA ] CLI enabled
[ 2007/02/27 19:42:49 INFO xorp_fea MFEA ] CLI started
[ 2007/02/27 19:42:49 INFO xorp_fea MFEA ] MFEA enabled
[ 2007/02/27 19:42:49 INFO xorp_fea MFEA ] CLI enabled
[ 2007/02/27 19:42:49 INFO xorp_fea MFEA ] CLI started
[ 2007/02/27 19:42:51  INFO xorp_rtrmgr:1801 RTRMGR +99 module_manager.cc
execute ] Executing module: fea (fea/xorp_fea)
[ 2007/02/27 19:42:57  INFO xorp_rtrmgr:1801 RTRMGR +99 module_manager.cc
execute ] Executing module: mfea4 (fea/xorp_fea)
[ 2007/02/27 19:42:57 INFO xorp_fea MFEA ] Interface added: Vif[em0]
pif_index: 1 vif_index: 0 addr: 10.3.2.20 subnet: 10.0.0.0/12 broadcast:
10.15.255.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP
MTU: 1500
[ 2007/02/27 19:42:57 INFO xorp_fea MFEA ] Interface added: Vif[vr0]
pif_index: 2 vif_index: 1 addr: 192.168.97.50 subnet: 192.168.97.0/24
broadcast: 192.168.97.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST
UNDERLYING_VIF_UP MTU: 1500
[ 2007/02/27 19:42:57 INFO xorp_fea MFEA ] MFEA started
[ 2007/02/27 19:42:58 INFO xorp_fea MFEA ] Interface enabled Vif[em0]
pif_index: 1 vif_index: 0 addr: 10.3.2.20 subnet: 10.0.0.0/12 broadcast:
10.15.255.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP
MTU: 1500 DOWN IPv4 ENABLED
[ 2007/02/27 19:42:58 INFO xorp_fea MFEA ] Interface started: Vif[em0]
pif_index: 1 vif_index: 0 addr: 10.3.2.20 subnet: 10.0.0.0/12 broadcast:
10.15.255.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP
MTU: 1500 UP IPv4 ENABLED
[ 2007/02/27 19:42:58 INFO xorp_fea MFEA ] Interface added:
Vif[register_vif] pif_index: 1 vif_index: 2 addr: 10.3.2.20 subnet:
10.3.2.20/32 broadcast: 10.3.2.20 peer: 0.0.0.0 Flags: PIM_REGISTER
UNDERLYING_VIF_UP MTU: 1500
[ 2007/02/27 19:42:58 INFO xorp_fea MFEA ] Interface enabled Vif[vr0]
pif_index: 2 vif_index: 1 addr: 192.168.97.50 subnet: 192.168.97.0/24
broadcast: 192.168.97.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST
UNDERLYING_VIF_UP MTU: 1500 DOWN IPv4 ENABLED
[ 2007/02/27 19:42:58 INFO xorp_fea MFEA ] Interface started: Vif[vr0]
pif_index: 2 vif_index: 1 addr: 192.168.97.50 subnet: 192.168.97.0/24
broadcast: 192.168.97.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST
UNDERLYING_VIF_UP MTU: 1500 UP IPv4 ENABLED
[ 2007/02/27 19:42:58 INFO xorp_fea MFEA ] Interface enabled
Vif[register_vif] pif_index: 1 vif_index: 2 addr: 10.3.2.20 subnet:
10.3.2.20/32 broadcast: 10.3.2.20 peer: 0.0.0.0 Flags: PIM_REGISTER
UNDERLYING_VIF_UP MTU: 1500 DOWN IPv4 ENABLED
[ 2007/02/27 19:42:58 INFO xorp_fea MFEA ] Interface started:
Vif[register_vif] pif_index: 1 vif_index: 2 addr: 10.3.2.20 subnet:
10.3.2.20/32 broadcast: 10.3.2.20 peer: 0.0.0.0 Flags: PIM_REGISTER
UNDERLYING_VIF_UP MTU: 1500 UP IPv4 ENABLED
[ 2007/02/27 19:42:58  INFO xorp_rtrmgr:1801 RTRMGR +99 module_manager.cc
execute ] Executing module: rib (rib/xorp_rib)
[ 2007/02/27 19:43:00  INFO xorp_rtrmgr:1801 RTRMGR +99 module_manager.cc
execute ] Executing module: fib2mrib (fib2mrib/xorp_fib2mrib)
[ 2007/02/27 19:43:02  INFO xorp_rtrmgr:1801 RTRMGR +99 module_manager.cc
execute ] Executing module: igmp (mld6igmp/xorp_igmp)
[ 2007/02/27 19:43:02  WARNING xorp_rtrmgr:1801 XrlFinderTarget +406
../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling
method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed
Target "IGMP" does not exist or is not enabled.
[ 2007/02/27 19:43:02 INFO xorp_igmp MLD6IGMP ] Protocol enabled
[ 2007/02/27 19:43:02 INFO xorp_igmp MLD6IGMP ] CLI enabled
[ 2007/02/27 19:43:02 INFO xorp_igmp MLD6IGMP ] CLI started
[ 2007/02/27 19:43:03 INFO xorp_igmp MLD6IGMP ] Interface added: Vif[em0]
pif_index: 0 vif_index: 0 addr: 10.3.2.20 subnet: 10.0.0.0/12 broadcast:
10.15.255.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP
MTU: 1500
[ 2007/02/27 19:43:03 INFO xorp_igmp MLD6IGMP ] Interface added: Vif[vr0]
pif_index: 0 vif_index: 1 addr: 192.168.97.50 subnet: 192.168.97.0/24
broadcast: 192.168.97.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST
UNDERLYING_VIF_UP MTU: 1500
[ 2007/02/27 19:43:03 INFO xorp_igmp MLD6IGMP ] Protocol started
[ 2007/02/27 19:43:04 INFO xorp_igmp MLD6IGMP ] Interface enabled:
Vif[em0] pif_index: 0 vif_index: 0 addr: 10.3.2.20 subnet: 10.0.0.0/12
broadcast: 10.15.255.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST
UNDERLYING_VIF_UP MTU: 1500 DOWN IPv4 ENABLED
[ 2007/02/27 19:43:04 INFO xorp_igmp MLD6IGMP ] Interface started:
Vif[em0] pif_index: 0 vif_index: 0 addr: 10.3.2.20 subnet: 10.0.0.0/12
broadcast: 10.15.255.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST
UNDERLYING_VIF_UP MTU: 1500 UP IPv4 ENABLED
[ 2007/02/27 19:43:04 INFO xorp_igmp MLD6IGMP ] Interface enabled:
Vif[vr0] pif_index: 0 vif_index: 1 addr: 192.168.97.50 subnet:
192.168.97.0/24 broadcast: 192.168.97.255 peer: 0.0.0.0 Flags: MULTICAST
BROADCAST UNDERLYING_VIF_UP MTU: 1500 DOWN IPv4 ENABLED
[ 2007/02/27 19:43:04 INFO xorp_igmp MLD6IGMP ] Interface started:
Vif[vr0] pif_index: 0 vif_index: 1 addr: 192.168.97.50 subnet:
192.168.97.0/24 broadcast: 192.168.97.255 peer: 0.0.0.0 Flags: MULTICAST
BROADCAST UNDERLYING_VIF_UP MTU: 1500 UP IPv4 ENABLED
[ 2007/02/27 19:43:04 TRACE xorp_igmp MLD6IGMP ] RX IGMP_MEMBERSHIP_QUERY
from 10.3.2.20 to 224.0.0.1 on vif em0
[ 2007/02/27 19:43:04  INFO xorp_rtrmgr:1801 RTRMGR +99 module_manager.cc
execute ] Executing module: pimsm4 (pim/xorp_pimsm4)
[ 2007/02/27 19:43:04  WARNING xorp_rtrmgr:1801 XrlFinderTarget +406
../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling
method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed
Target "PIMSM_4" does not exist or is not enabled.
[ 2007/02/27 19:43:04 TRACE xorp_igmp MLD6IGMP ] RX
IGMP_V2_MEMBERSHIP_REPORT from 192.168.97.50 to 224.0.0.2 on vif vr0
[ 2007/02/27 19:43:04 TRACE xorp_igmp MLD6IGMP ] Notify routing add
membership for (0.0.0.0, 224.0.0.2) on vif vr0
[ 2007/02/27 19:43:04 TRACE xorp_igmp MLD6IGMP ] RX
IGMP_V2_MEMBERSHIP_REPORT from 192.168.97.50 to 224.0.0.22 on vif vr0
[ 2007/02/27 19:43:04 TRACE xorp_igmp MLD6IGMP ] Notify routing add
membership for (0.0.0.0, 224.0.0.22) on vif vr0
[ 2007/02/27 19:43:04 TRACE xorp_igmp MLD6IGMP ] RX IGMP_MEMBERSHIP_QUERY
from 192.168.97.50 to 224.0.0.1 on vif vr0
[ 2007/02/27 19:43:05 INFO xorp_pimsm4 PIM ] Protocol enabled
[ 2007/02/27 19:43:05 INFO xorp_pimsm4 PIM ] CLI enabled
[ 2007/02/27 19:43:05 INFO xorp_pimsm4 PIM ] CLI started
[ 2007/02/27 19:43:05 INFO xorp_pimsm4 PIM ] Interface added: Vif[em0]
pif_index: 0 vif_index: 0 addr: 10.3.2.20 subnet: 10.0.0.0/12 broadcast:
10.15.255.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP
MTU: 1500
[ 2007/02/27 19:43:05 INFO xorp_pimsm4 PIM ] Interface added:
Vif[register_vif] pif_index: 0 vif_index: 2 addr: 10.3.2.20 subnet:
10.3.2.20/32 broadcast: 10.3.2.20 peer: 0.0.0.0 Flags: PIM_REGISTER
UNDERLYING_VIF_UP MTU: 1500
[ 2007/02/27 19:43:05 INFO xorp_pimsm4 PIM ] Interface added: Vif[vr0]
pif_index: 0 vif_index: 1 addr: 192.168.97.50 subnet: 192.168.97.0/24
broadcast: 192.168.97.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST
UNDERLYING_VIF_UP MTU: 1500
[ 2007/02/27 19:43:05 INFO xorp_pimsm4 PIM ] Protocol started
[ 2007/02/27 19:43:06 TRACE xorp_igmp MLD6IGMP ] RX
IGMP_V2_MEMBERSHIP_REPORT from 10.3.2.20 to 224.0.0.2 on vif em0
[ 2007/02/27 19:43:06 INFO xorp_pimsm4 PIM ] Interface enabled: Vif[em0]
pif_index: 0 vif_index: 0 addr: 10.3.2.20 subnet: 10.0.0.0/12 broadcast:
10.15.255.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP
MTU: 1500 DOWN IPv4 ENABLED
[ 2007/02/27 19:43:06 INFO xorp_pimsm4 PIM ] Interface started: Vif[em0]
pif_index: 0 vif_index: 0 addr: 10.3.2.20 subnet: 10.0.0.0/12 broadcast:
10.15.255.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP
MTU: 1500 UP IPv4 ENABLED
[ 2007/02/27 19:43:06 INFO xorp_pimsm4 PIM ] Interface enabled: Vif[vr0]
pif_index: 0 vif_index: 1 addr: 192.168.97.50 subnet: 192.168.97.0/24
broadcast: 192.168.97.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST
UNDERLYING_VIF_UP MTU: 1500 DOWN IPv4 ENABLED
[ 2007/02/27 19:43:06 TRACE xorp_igmp MLD6IGMP ] RX
IGMP_V2_MEMBERSHIP_REPORT from 10.3.2.20 to 224.0.0.13 on vif em0
[ 2007/02/27 19:43:06 TRACE xorp_igmp MLD6IGMP ] Notify routing add
membership for (0.0.0.0, 224.0.0.13) on vif em0
[ 2007/02/27 19:43:06 INFO xorp_pimsm4 PIM ] Interface started: Vif[vr0]
pif_index: 0 vif_index: 1 addr: 192.168.97.50 subnet: 192.168.97.0/24
broadcast: 192.168.97.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST
UNDERLYING_VIF_UP MTU: 1500 UP IPv4 ENABLED
[ 2007/02/27 19:43:06 INFO xorp_pimsm4 PIM ] Interface enabled:
Vif[register_vif] pif_index: 0 vif_index: 2 addr: 10.3.2.20 subnet:
10.3.2.20/32 broadcast: 10.3.2.20 peer: 0.0.0.0 Flags: PIM_REGISTER
UNDERLYING_VIF_UP MTU: 1500 DOWN IPv4 ENABLED
[ 2007/02/27 19:43:06 TRACE xorp_igmp MLD6IGMP ] RX
IGMP_V2_MEMBERSHIP_REPORT from 192.168.97.50 to 224.0.0.13 on vif vr0
[ 2007/02/27 19:43:06 TRACE xorp_igmp MLD6IGMP ] Notify routing add
membership for (0.0.0.0, 224.0.0.13) on vif vr0
[ 2007/02/27 19:43:06 INFO xorp_pimsm4 PIM ] Interface started:
Vif[register_vif] pif_index: 0 vif_index: 2 addr: 10.3.2.20 subnet:
10.3.2.20/32 broadcast: 10.3.2.20 peer: 0.0.0.0 Flags: PIM_REGISTER
UNDERLYING_VIF_UP MTU: 1500 UP IPv4 ENABLED
[ 2007/02/27 19:43:06  INFO xorp_rtrmgr:1801 RTRMGR +2228 task.cc run_task
] No more tasks to run
[ 2007/02/27 19:43:08 TRACE xorp_igmp MLD6IGMP ] RX
IGMP_V2_MEMBERSHIP_REPORT from 192.168.97.50 to 224.0.0.2 on vif vr0
[ 2007/02/27 19:43:09 TRACE xorp_igmp MLD6IGMP ] RX
IGMP_V2_MEMBERSHIP_REPORT from 192.168.97.50 to 224.0.0.22 on vif vr0
[ 2007/02/27 19:43:09 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 10.3.2.20
to 224.0.0.13 on vif em0
[ 2007/02/27 19:43:10 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from
192.168.97.50 to 224.0.0.13 on vif vr0
[ 2007/02/27 19:43:11 TRACE xorp_igmp MLD6IGMP ] RX
IGMP_V3_MEMBERSHIP_REPORT from 192.168.97.49 to 224.0.0.22 on vif vr0
[ 2007/02/27 19:43:11 TRACE xorp_igmp MLD6IGMP ] Notify routing add
membership for (0.0.0.0, 239.255.255.250) on vif vr0
[ 2007/02/27 19:43:11 TRACE xorp_pimsm4 PIM ] Add membership for (0.0.0.0,
239.255.255.250) on vif vr0
[ 2007/02/27 19:43:11 WARNING xorp_pimsm4 PIM ] JoinDesired(*,G) = true:
RP for group 239.255.255.250: not found
[ 2007/02/27 19:43:12 TRACE xorp_igmp MLD6IGMP ] RX
IGMP_V2_MEMBERSHIP_REPORT from 192.168.97.50 to 224.0.0.13 on vif vr0
[ 2007/02/27 19:43:14 TRACE xorp_igmp MLD6IGMP ] RX
IGMP_V2_MEMBERSHIP_REPORT from 10.3.2.20 to 224.0.0.22 on vif em0
[ 2007/02/27 19:43:15 TRACE xorp_igmp MLD6IGMP ] RX
IGMP_V2_MEMBERSHIP_REPORT from 10.3.2.20 to 224.0.0.13 on vif em0
[ 2007/02/27 19:43:36 TRACE xorp_igmp MLD6IGMP ] TX IGMP_MEMBERSHIP_QUERY
from 10.3.2.20 to 224.0.0.1
[ 2007/02/27 19:43:36 TRACE xorp_igmp MLD6IGMP ] RX IGMP_MEMBERSHIP_QUERY
from 10.3.2.20 to 224.0.0.1 on vif em0
[ 2007/02/27 19:43:36 TRACE xorp_igmp MLD6IGMP ] TX IGMP_MEMBERSHIP_QUERY
from 192.168.97.50 to 224.0.0.1
[ 2007/02/27 19:43:36 TRACE xorp_igmp MLD6IGMP ] RX IGMP_MEMBERSHIP_QUERY
from 192.168.97.50 to 224.0.0.1 on vif vr0
[ 2007/02/27 19:43:36 TRACE xorp_igmp MLD6IGMP ] RX
IGMP_V2_MEMBERSHIP_REPORT from 10.3.2.20 to 224.0.0.2 on vif em0
[ 2007/02/27 19:43:37 TRACE xorp_igmp MLD6IGMP ] RX
IGMP_V2_MEMBERSHIP_REPORT from 192.168.97.50 to 224.0.0.13 on vif vr0
[ 2007/02/27 19:43:37 TRACE xorp_igmp MLD6IGMP ] RX
IGMP_V2_MEMBERSHIP_REPORT from 10.3.2.20 to 224.0.0.13 on vif em0
[ 2007/02/27 19:43:38 TRACE xorp_igmp MLD6IGMP ] RX
IGMP_V2_MEMBERSHIP_REPORT from 10.3.2.20 to 224.0.0.22 on vif em0
[ 2007/02/27 19:43:38 TRACE xorp_igmp MLD6IGMP ] RX
IGMP_V3_MEMBERSHIP_REPORT from 192.168.97.49 to 224.0.0.22 on vif vr0
[ 2007/02/27 19:43:39 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 10.3.2.20
to 224.0.0.13 on vif em0
[ 2007/02/27 19:43:40 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from
192.168.97.50 to 224.0.0.13 on vif vr0
[ 2007/02/27 19:43:43 TRACE xorp_igmp MLD6IGMP ] RX
IGMP_V2_MEMBERSHIP_REPORT from 192.168.97.50 to 224.0.0.2 on vif vr0
[ 2007/02/27 19:43:43 TRACE xorp_igmp MLD6IGMP ] RX
IGMP_V2_MEMBERSHIP_REPORT from 192.168.97.50 to 224.0.0.22 on vif vr0

Logs on XORP with VLC streaming server activated ...

[ 2007/02/27 20:01:01 TRACE xorp_fea MFEA ] RX kernel signal: message_type
= 3 vif_index = 2 src = 192.168.97.49 dst = 232.10.10.10
[ 2007/02/27 20:01:01 TRACE xorp_pimsm4 PIM ] RX WHOLEPKT signal from
MFEA_4: vif_index = 2 src = 192.168.97.49 dst = 232.10.10.10 len = 1356
[ 2007/02/27 20:01:01 WARNING xorp_pimsm4 PIM ] RX WHOLEPKT signal from
MFEA_4: vif_index = 2 src = 192.168.97.49 dst = 232.10.10.10 len = 1356:
no RP address for this group
[ 2007/02/27 20:01:01 TRACE xorp_fea MFEA ] RX kernel signal: message_type
= 3 vif_index = 2 src = 192.168.97.49 dst = 232.10.10.10
[ 2007/02/27 20:01:01 TRACE xorp_pimsm4 PIM ] RX WHOLEPKT signal from
MFEA_4: vif_index = 2 src = 192.168.97.49 dst = 232.10.10.10 len = 1356
[ 2007/02/27 20:01:01 WARNING xorp_pimsm4 PIM ] RX WHOLEPKT signal from
MFEA_4: vif_index = 2 src = 192.168.97.49 dst = 232.10.10.10 len = 1356:
no RP address for this group
[ 2007/02/27 20:01:01 TRACE xorp_fea MFEA ] RX kernel signal: message_type
= 3 vif_index = 2 src = 192.168.97.49 dst = 232.10.10.10
[ 2007/02/27 20:01:01 TRACE xorp_pimsm4 PIM ] RX WHOLEPKT signal from
MFEA_4: vif_index = 2 src = 192.168.97.49 dst = 232.10.10.10 len = 1356
[ 2007/02/27 20:01:01 WARNING xorp_pimsm4 PIM ] RX WHOLEPKT signal from
MFEA_4: vif_index = 2 src = 192.168.97.49 dst = 232.10.10.10 len = 1356:
no RP address for this group
[ 2007/02/27 20:01:01 TRACE xorp_fea MFEA ] RX kernel signal: message_type
= 3 vif_index = 2 src = 192.168.97.49 dst = 232.10.10.10
[ 2007/02/27 20:01:01 TRACE xorp_pimsm4 PIM ] RX WHOLEPKT signal from
MFEA_4: vif_index = 2 src = 192.168.97.49 dst = 232.10.10.10 len = 1356
[ 2007/02/27 20:01:01 WARNING xorp_pimsm4 PIM ] RX WHOLEPKT signal from
MFEA_4: vif_index = 2 src = 192.168.97.49 dst = 232.10.10.10 len = 1356:
no RP address for this group
[ 2007/02/27 20:01:01 TRACE xorp_fea MFEA ] RX kernel signal: message_type
= 3 vif_index = 2 src = 192.168.97.49 dst = 232.10.10.10
[ 2007/02/27 20:01:01 TRACE xorp_pimsm4 PIM ] RX WHOLEPKT signal from
MFEA_4: vif_index = 2 src = 192.168.97.49 dst = 232.10.10.10 len = 1356
[ 2007/02/27 20:01:01 WARNING xorp_pimsm4 PIM ] RX WHOLEPKT signal from
MFEA_4: vif_index = 2 src = 192.168.97.49 dst = 232.10.10.10 len = 1356:
no RP address for this group
[ 2007/02/27 20:01:01 TRACE xorp_fea MFEA ] RX kernel signal: message_type
= 3 vif_index = 2 src = 192.168.97.49 dst = 232.10.10.10
[ 2007/02/27 20:01:01 TRACE xorp_pimsm4 PIM ] RX WHOLEPKT signal from
MFEA_4: vif_index = 2 src = 192.168.97.49 dst = 232.10.10.10 len = 1356

Running a VLC streaming server
http://www.videolan.org/doc/streaming-howto/en/ch04.html#id294730

Running a VLC client with SSM:
http://www.videolan.org/doc/play-howto/en/ch04.html

archie# vlc udp:unicast_server_address at multicast_address[:server_port]

where,

unicast_server_address = 192.168.97.49 (source/streaming server's unicast
address)
multicast_address = 232.10.10.10 (Group)
server_port = 1234 (default on VLC)

IGMP Status with XORPSH:

archie at mcast.cebu.example.ph> show igmp interface
Interface    State    Querier         Timeout Version Groups
em0          UP       192.168.96.50      None       3      5
vr0          UP       10.3.2.18          None       3      3

archie at mcast.cebu.example.ph> show igmp group
Interface    Group           Source          LastReported Timeout V State
em0          224.0.0.2       0.0.0.0         192.168.96.50     251 2     E
em0          224.0.0.13      0.0.0.0         192.168.96.50     249 2     E
em0          224.0.0.22      0.0.0.0         192.168.96.50     255 2     E
em0          232.10.10.10    0.0.0.0         192.168.96.49       0 3     I
em0          232.10.10.10    192.168.97.49   192.168.96.49      78 3     F
em0          239.255.255.250 0.0.0.0         192.168.96.48     251 3     E
vr0          224.0.0.2       0.0.0.0         10.3.2.20        248 2     E
vr0          224.0.0.13      0.0.0.0         10.3.2.18        248 2     E
vr0          224.0.0.22      0.0.0.0         10.3.2.18        251 2     E

On this statistic, it shows that 192.168.96.49 VLC client requests for
source-specific multicast channel to the streaming server 192.168.97.49 in
a multicast group of 232.10.10.10.

Thanks.

Sincerely Yours,

Archimedes S. Gaviola
Network Engineer
InfoWeapons Corporation


--------
This email and/or attachments are confidential and may also be
legally privileged. If you are not the intended recipient, you are
hereby notified, that any review, dissemination, distribution or
copying of this email and/or attachments is strictly prohibited.
Please notify security at infoweapons.com immediately by email and
delete this message and all its attachments. Thank you.


From pavlin at icir.org  Tue Feb 27 10:34:32 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Tue, 27 Feb 2007 10:34:32 -0800
Subject: [Xorp-users] XORP 1.3 PIM-SSM Support
In-Reply-To: Message from agaviola@infoweapons.com of "Tue,
	27 Feb 2007 21:39:16 +0800."
	<4266.10.3.2.11.1172583556.squirrel@mail2.infoweapons.com> 
Message-ID: <200702271834.l1RIYW7m090549@possum.icir.org>

agaviola at infoweapons.com wrote:

> Sir Pavlin,

Please call me just "Pavlin" :)

> Based on my evaluation with XORP 1.3, PIM-SSM support works. I got two
> FreeBSD machines that act as IPv4 multicast routers with source and
> receiver nodes using Windows XP SP2 installed with VLC, source as the
> streaming server while receiver as the client. Since IGMPv3 is required on
> SSM operation, so Windows XP platform and VLC application are used.

Great! Thank you for the update and detailed description of your
setup so other folks can use it as a reference.

Please let us know if you run into any issues.

Regards,
Pavlin

> Simulated network setup:
> 
>   +----------+    192.168.96.50/24 +------------+
>   | Source/  +---------------------| PIM-SSM    |
>   | Sender   |                     | router 1   |
>   +----------+                     +-----+------+
> 192.168.96.49/24                         | 10.3.2.18/12
>                                          |
>                                          | (unicast static route)
>                                          |
>                                          |
>                                          | 10.3.2.20/12
>   +----------+    192.168.96.50/24 +-----+------+
>   | Client/  +---------------------| PIM-SSM    |
>   | Receiver |                     | router 2   |
>   +----------+                     +------------+
>  192.168.97.49/24
> 
> Multicast router (PIM-SSM) configurations:
> 
> archie# /usr/local/xorp/config.boot
> 
> interfaces {
>     interface em0 {
>         description: "upstream interface"
>         disable: false
>         default-system-config
>     }
>     interface vr0 {
>         description: "downstream interface"
>         disable: false
>         default-system-config
>     }
> }
> 
> fea {
>     unicast-forwarding4 {
>         disable: false
>     }
> }
> 
> plumbing {
>     mfea4 {
>         disable: false
>         interface em0 {
>             vif em0 {
>                 disable: false
>             }
>         }
>         interface vr0 {
>             vif vr0 {
>                 disable: false
>             }
>         }
>         interface register_vif {
>             vif register_vif {
>                 disable: false
>             }
>         }
>         traceoptions {
>             flag all {
>                 disable: false
>             }
>         }
>     }
> }
> 
> protocols {
>     igmp {
>         disable: false
>         interface em0 {
>             vif em0 {
>                 version: 3
>                 disable: false
>             }
>         }
>         interface vr0 {
>             vif vr0 {
>                 version: 3
>                 disable: false
>             }
>         }
>         traceoptions {
>             flag all {
>                 disable: false
>            }
>        }
>     }
> }
> 
> protocols {
>     pimsm4 {
>        disable: false
>        interface em0 {
>            vif em0 {
>               disable: false
>            }
>         }
>         interface vr0 {
>            vif vr0 {
>               disable: false
>            }
>         }
>        interface register_vif {
>                 vif register_vif {
>                 disable: false
>                    }
>                }
>         traceoptions {
>            flag all {
>               disable: false
>               }
>            }
>       }
>   }
> 
> protocols {
>     fib2mrib {
>         disable: false
>     }
> }
> 
> Running XORP routing manager....
> 
> archie# /usr/local/xorp/bin/xorp_rtrmgr
> 
> [ 2007/02/27 19:42:49  INFO xorp_rtrmgr:1801 RTRMGR +240
> master_conf_tree.cc execute ] Changed modules: interfaces, fea, mfea4,
> rib, fib2mrib, igmp, pimsm4
> [ 2007/02/27 19:42:49  INFO xorp_rtrmgr:1801 RTRMGR +99 module_manager.cc
> execute ] Executing module: interfaces (fea/xorp_fea)
> [ 2007/02/27 19:42:49 INFO xorp_fea MFEA ] MFEA enabled
> [ 2007/02/27 19:42:49 INFO xorp_fea MFEA ] CLI enabled
> [ 2007/02/27 19:42:49 INFO xorp_fea MFEA ] CLI started
> [ 2007/02/27 19:42:49 INFO xorp_fea MFEA ] MFEA enabled
> [ 2007/02/27 19:42:49 INFO xorp_fea MFEA ] CLI enabled
> [ 2007/02/27 19:42:49 INFO xorp_fea MFEA ] CLI started
> [ 2007/02/27 19:42:51  INFO xorp_rtrmgr:1801 RTRMGR +99 module_manager.cc
> execute ] Executing module: fea (fea/xorp_fea)
> [ 2007/02/27 19:42:57  INFO xorp_rtrmgr:1801 RTRMGR +99 module_manager.cc
> execute ] Executing module: mfea4 (fea/xorp_fea)
> [ 2007/02/27 19:42:57 INFO xorp_fea MFEA ] Interface added: Vif[em0]
> pif_index: 1 vif_index: 0 addr: 10.3.2.20 subnet: 10.0.0.0/12 broadcast:
> 10.15.255.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP
> MTU: 1500
> [ 2007/02/27 19:42:57 INFO xorp_fea MFEA ] Interface added: Vif[vr0]
> pif_index: 2 vif_index: 1 addr: 192.168.97.50 subnet: 192.168.97.0/24
> broadcast: 192.168.97.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST
> UNDERLYING_VIF_UP MTU: 1500
> [ 2007/02/27 19:42:57 INFO xorp_fea MFEA ] MFEA started
> [ 2007/02/27 19:42:58 INFO xorp_fea MFEA ] Interface enabled Vif[em0]
> pif_index: 1 vif_index: 0 addr: 10.3.2.20 subnet: 10.0.0.0/12 broadcast:
> 10.15.255.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP
> MTU: 1500 DOWN IPv4 ENABLED
> [ 2007/02/27 19:42:58 INFO xorp_fea MFEA ] Interface started: Vif[em0]
> pif_index: 1 vif_index: 0 addr: 10.3.2.20 subnet: 10.0.0.0/12 broadcast:
> 10.15.255.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP
> MTU: 1500 UP IPv4 ENABLED
> [ 2007/02/27 19:42:58 INFO xorp_fea MFEA ] Interface added:
> Vif[register_vif] pif_index: 1 vif_index: 2 addr: 10.3.2.20 subnet:
> 10.3.2.20/32 broadcast: 10.3.2.20 peer: 0.0.0.0 Flags: PIM_REGISTER
> UNDERLYING_VIF_UP MTU: 1500
> [ 2007/02/27 19:42:58 INFO xorp_fea MFEA ] Interface enabled Vif[vr0]
> pif_index: 2 vif_index: 1 addr: 192.168.97.50 subnet: 192.168.97.0/24
> broadcast: 192.168.97.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST
> UNDERLYING_VIF_UP MTU: 1500 DOWN IPv4 ENABLED
> [ 2007/02/27 19:42:58 INFO xorp_fea MFEA ] Interface started: Vif[vr0]
> pif_index: 2 vif_index: 1 addr: 192.168.97.50 subnet: 192.168.97.0/24
> broadcast: 192.168.97.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST
> UNDERLYING_VIF_UP MTU: 1500 UP IPv4 ENABLED
> [ 2007/02/27 19:42:58 INFO xorp_fea MFEA ] Interface enabled
> Vif[register_vif] pif_index: 1 vif_index: 2 addr: 10.3.2.20 subnet:
> 10.3.2.20/32 broadcast: 10.3.2.20 peer: 0.0.0.0 Flags: PIM_REGISTER
> UNDERLYING_VIF_UP MTU: 1500 DOWN IPv4 ENABLED
> [ 2007/02/27 19:42:58 INFO xorp_fea MFEA ] Interface started:
> Vif[register_vif] pif_index: 1 vif_index: 2 addr: 10.3.2.20 subnet:
> 10.3.2.20/32 broadcast: 10.3.2.20 peer: 0.0.0.0 Flags: PIM_REGISTER
> UNDERLYING_VIF_UP MTU: 1500 UP IPv4 ENABLED
> [ 2007/02/27 19:42:58  INFO xorp_rtrmgr:1801 RTRMGR +99 module_manager.cc
> execute ] Executing module: rib (rib/xorp_rib)
> [ 2007/02/27 19:43:00  INFO xorp_rtrmgr:1801 RTRMGR +99 module_manager.cc
> execute ] Executing module: fib2mrib (fib2mrib/xorp_fib2mrib)
> [ 2007/02/27 19:43:02  INFO xorp_rtrmgr:1801 RTRMGR +99 module_manager.cc
> execute ] Executing module: igmp (mld6igmp/xorp_igmp)
> [ 2007/02/27 19:43:02  WARNING xorp_rtrmgr:1801 XrlFinderTarget +406
> ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling
> method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed
> Target "IGMP" does not exist or is not enabled.
> [ 2007/02/27 19:43:02 INFO xorp_igmp MLD6IGMP ] Protocol enabled
> [ 2007/02/27 19:43:02 INFO xorp_igmp MLD6IGMP ] CLI enabled
> [ 2007/02/27 19:43:02 INFO xorp_igmp MLD6IGMP ] CLI started
> [ 2007/02/27 19:43:03 INFO xorp_igmp MLD6IGMP ] Interface added: Vif[em0]
> pif_index: 0 vif_index: 0 addr: 10.3.2.20 subnet: 10.0.0.0/12 broadcast:
> 10.15.255.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP
> MTU: 1500
> [ 2007/02/27 19:43:03 INFO xorp_igmp MLD6IGMP ] Interface added: Vif[vr0]
> pif_index: 0 vif_index: 1 addr: 192.168.97.50 subnet: 192.168.97.0/24
> broadcast: 192.168.97.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST
> UNDERLYING_VIF_UP MTU: 1500
> [ 2007/02/27 19:43:03 INFO xorp_igmp MLD6IGMP ] Protocol started
> [ 2007/02/27 19:43:04 INFO xorp_igmp MLD6IGMP ] Interface enabled:
> Vif[em0] pif_index: 0 vif_index: 0 addr: 10.3.2.20 subnet: 10.0.0.0/12
> broadcast: 10.15.255.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST
> UNDERLYING_VIF_UP MTU: 1500 DOWN IPv4 ENABLED
> [ 2007/02/27 19:43:04 INFO xorp_igmp MLD6IGMP ] Interface started:
> Vif[em0] pif_index: 0 vif_index: 0 addr: 10.3.2.20 subnet: 10.0.0.0/12
> broadcast: 10.15.255.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST
> UNDERLYING_VIF_UP MTU: 1500 UP IPv4 ENABLED
> [ 2007/02/27 19:43:04 INFO xorp_igmp MLD6IGMP ] Interface enabled:
> Vif[vr0] pif_index: 0 vif_index: 1 addr: 192.168.97.50 subnet:
> 192.168.97.0/24 broadcast: 192.168.97.255 peer: 0.0.0.0 Flags: MULTICAST
> BROADCAST UNDERLYING_VIF_UP MTU: 1500 DOWN IPv4 ENABLED
> [ 2007/02/27 19:43:04 INFO xorp_igmp MLD6IGMP ] Interface started:
> Vif[vr0] pif_index: 0 vif_index: 1 addr: 192.168.97.50 subnet:
> 192.168.97.0/24 broadcast: 192.168.97.255 peer: 0.0.0.0 Flags: MULTICAST
> BROADCAST UNDERLYING_VIF_UP MTU: 1500 UP IPv4 ENABLED
> [ 2007/02/27 19:43:04 TRACE xorp_igmp MLD6IGMP ] RX IGMP_MEMBERSHIP_QUERY
> from 10.3.2.20 to 224.0.0.1 on vif em0
> [ 2007/02/27 19:43:04  INFO xorp_rtrmgr:1801 RTRMGR +99 module_manager.cc
> execute ] Executing module: pimsm4 (pim/xorp_pimsm4)
> [ 2007/02/27 19:43:04  WARNING xorp_rtrmgr:1801 XrlFinderTarget +406
> ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling
> method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed
> Target "PIMSM_4" does not exist or is not enabled.
> [ 2007/02/27 19:43:04 TRACE xorp_igmp MLD6IGMP ] RX
> IGMP_V2_MEMBERSHIP_REPORT from 192.168.97.50 to 224.0.0.2 on vif vr0
> [ 2007/02/27 19:43:04 TRACE xorp_igmp MLD6IGMP ] Notify routing add
> membership for (0.0.0.0, 224.0.0.2) on vif vr0
> [ 2007/02/27 19:43:04 TRACE xorp_igmp MLD6IGMP ] RX
> IGMP_V2_MEMBERSHIP_REPORT from 192.168.97.50 to 224.0.0.22 on vif vr0
> [ 2007/02/27 19:43:04 TRACE xorp_igmp MLD6IGMP ] Notify routing add
> membership for (0.0.0.0, 224.0.0.22) on vif vr0
> [ 2007/02/27 19:43:04 TRACE xorp_igmp MLD6IGMP ] RX IGMP_MEMBERSHIP_QUERY
> from 192.168.97.50 to 224.0.0.1 on vif vr0
> [ 2007/02/27 19:43:05 INFO xorp_pimsm4 PIM ] Protocol enabled
> [ 2007/02/27 19:43:05 INFO xorp_pimsm4 PIM ] CLI enabled
> [ 2007/02/27 19:43:05 INFO xorp_pimsm4 PIM ] CLI started
> [ 2007/02/27 19:43:05 INFO xorp_pimsm4 PIM ] Interface added: Vif[em0]
> pif_index: 0 vif_index: 0 addr: 10.3.2.20 subnet: 10.0.0.0/12 broadcast:
> 10.15.255.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP
> MTU: 1500
> [ 2007/02/27 19:43:05 INFO xorp_pimsm4 PIM ] Interface added:
> Vif[register_vif] pif_index: 0 vif_index: 2 addr: 10.3.2.20 subnet:
> 10.3.2.20/32 broadcast: 10.3.2.20 peer: 0.0.0.0 Flags: PIM_REGISTER
> UNDERLYING_VIF_UP MTU: 1500
> [ 2007/02/27 19:43:05 INFO xorp_pimsm4 PIM ] Interface added: Vif[vr0]
> pif_index: 0 vif_index: 1 addr: 192.168.97.50 subnet: 192.168.97.0/24
> broadcast: 192.168.97.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST
> UNDERLYING_VIF_UP MTU: 1500
> [ 2007/02/27 19:43:05 INFO xorp_pimsm4 PIM ] Protocol started
> [ 2007/02/27 19:43:06 TRACE xorp_igmp MLD6IGMP ] RX
> IGMP_V2_MEMBERSHIP_REPORT from 10.3.2.20 to 224.0.0.2 on vif em0
> [ 2007/02/27 19:43:06 INFO xorp_pimsm4 PIM ] Interface enabled: Vif[em0]
> pif_index: 0 vif_index: 0 addr: 10.3.2.20 subnet: 10.0.0.0/12 broadcast:
> 10.15.255.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP
> MTU: 1500 DOWN IPv4 ENABLED
> [ 2007/02/27 19:43:06 INFO xorp_pimsm4 PIM ] Interface started: Vif[em0]
> pif_index: 0 vif_index: 0 addr: 10.3.2.20 subnet: 10.0.0.0/12 broadcast:
> 10.15.255.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP
> MTU: 1500 UP IPv4 ENABLED
> [ 2007/02/27 19:43:06 INFO xorp_pimsm4 PIM ] Interface enabled: Vif[vr0]
> pif_index: 0 vif_index: 1 addr: 192.168.97.50 subnet: 192.168.97.0/24
> broadcast: 192.168.97.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST
> UNDERLYING_VIF_UP MTU: 1500 DOWN IPv4 ENABLED
> [ 2007/02/27 19:43:06 TRACE xorp_igmp MLD6IGMP ] RX
> IGMP_V2_MEMBERSHIP_REPORT from 10.3.2.20 to 224.0.0.13 on vif em0
> [ 2007/02/27 19:43:06 TRACE xorp_igmp MLD6IGMP ] Notify routing add
> membership for (0.0.0.0, 224.0.0.13) on vif em0
> [ 2007/02/27 19:43:06 INFO xorp_pimsm4 PIM ] Interface started: Vif[vr0]
> pif_index: 0 vif_index: 1 addr: 192.168.97.50 subnet: 192.168.97.0/24
> broadcast: 192.168.97.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST
> UNDERLYING_VIF_UP MTU: 1500 UP IPv4 ENABLED
> [ 2007/02/27 19:43:06 INFO xorp_pimsm4 PIM ] Interface enabled:
> Vif[register_vif] pif_index: 0 vif_index: 2 addr: 10.3.2.20 subnet:
> 10.3.2.20/32 broadcast: 10.3.2.20 peer: 0.0.0.0 Flags: PIM_REGISTER
> UNDERLYING_VIF_UP MTU: 1500 DOWN IPv4 ENABLED
> [ 2007/02/27 19:43:06 TRACE xorp_igmp MLD6IGMP ] RX
> IGMP_V2_MEMBERSHIP_REPORT from 192.168.97.50 to 224.0.0.13 on vif vr0
> [ 2007/02/27 19:43:06 TRACE xorp_igmp MLD6IGMP ] Notify routing add
> membership for (0.0.0.0, 224.0.0.13) on vif vr0
> [ 2007/02/27 19:43:06 INFO xorp_pimsm4 PIM ] Interface started:
> Vif[register_vif] pif_index: 0 vif_index: 2 addr: 10.3.2.20 subnet:
> 10.3.2.20/32 broadcast: 10.3.2.20 peer: 0.0.0.0 Flags: PIM_REGISTER
> UNDERLYING_VIF_UP MTU: 1500 UP IPv4 ENABLED
> [ 2007/02/27 19:43:06  INFO xorp_rtrmgr:1801 RTRMGR +2228 task.cc run_task
> ] No more tasks to run
> [ 2007/02/27 19:43:08 TRACE xorp_igmp MLD6IGMP ] RX
> IGMP_V2_MEMBERSHIP_REPORT from 192.168.97.50 to 224.0.0.2 on vif vr0
> [ 2007/02/27 19:43:09 TRACE xorp_igmp MLD6IGMP ] RX
> IGMP_V2_MEMBERSHIP_REPORT from 192.168.97.50 to 224.0.0.22 on vif vr0
> [ 2007/02/27 19:43:09 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 10.3.2.20
> to 224.0.0.13 on vif em0
> [ 2007/02/27 19:43:10 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from
> 192.168.97.50 to 224.0.0.13 on vif vr0
> [ 2007/02/27 19:43:11 TRACE xorp_igmp MLD6IGMP ] RX
> IGMP_V3_MEMBERSHIP_REPORT from 192.168.97.49 to 224.0.0.22 on vif vr0
> [ 2007/02/27 19:43:11 TRACE xorp_igmp MLD6IGMP ] Notify routing add
> membership for (0.0.0.0, 239.255.255.250) on vif vr0
> [ 2007/02/27 19:43:11 TRACE xorp_pimsm4 PIM ] Add membership for (0.0.0.0,
> 239.255.255.250) on vif vr0
> [ 2007/02/27 19:43:11 WARNING xorp_pimsm4 PIM ] JoinDesired(*,G) = true:
> RP for group 239.255.255.250: not found
> [ 2007/02/27 19:43:12 TRACE xorp_igmp MLD6IGMP ] RX
> IGMP_V2_MEMBERSHIP_REPORT from 192.168.97.50 to 224.0.0.13 on vif vr0
> [ 2007/02/27 19:43:14 TRACE xorp_igmp MLD6IGMP ] RX
> IGMP_V2_MEMBERSHIP_REPORT from 10.3.2.20 to 224.0.0.22 on vif em0
> [ 2007/02/27 19:43:15 TRACE xorp_igmp MLD6IGMP ] RX
> IGMP_V2_MEMBERSHIP_REPORT from 10.3.2.20 to 224.0.0.13 on vif em0
> [ 2007/02/27 19:43:36 TRACE xorp_igmp MLD6IGMP ] TX IGMP_MEMBERSHIP_QUERY
> from 10.3.2.20 to 224.0.0.1
> [ 2007/02/27 19:43:36 TRACE xorp_igmp MLD6IGMP ] RX IGMP_MEMBERSHIP_QUERY
> from 10.3.2.20 to 224.0.0.1 on vif em0
> [ 2007/02/27 19:43:36 TRACE xorp_igmp MLD6IGMP ] TX IGMP_MEMBERSHIP_QUERY
> from 192.168.97.50 to 224.0.0.1
> [ 2007/02/27 19:43:36 TRACE xorp_igmp MLD6IGMP ] RX IGMP_MEMBERSHIP_QUERY
> from 192.168.97.50 to 224.0.0.1 on vif vr0
> [ 2007/02/27 19:43:36 TRACE xorp_igmp MLD6IGMP ] RX
> IGMP_V2_MEMBERSHIP_REPORT from 10.3.2.20 to 224.0.0.2 on vif em0
> [ 2007/02/27 19:43:37 TRACE xorp_igmp MLD6IGMP ] RX
> IGMP_V2_MEMBERSHIP_REPORT from 192.168.97.50 to 224.0.0.13 on vif vr0
> [ 2007/02/27 19:43:37 TRACE xorp_igmp MLD6IGMP ] RX
> IGMP_V2_MEMBERSHIP_REPORT from 10.3.2.20 to 224.0.0.13 on vif em0
> [ 2007/02/27 19:43:38 TRACE xorp_igmp MLD6IGMP ] RX
> IGMP_V2_MEMBERSHIP_REPORT from 10.3.2.20 to 224.0.0.22 on vif em0
> [ 2007/02/27 19:43:38 TRACE xorp_igmp MLD6IGMP ] RX
> IGMP_V3_MEMBERSHIP_REPORT from 192.168.97.49 to 224.0.0.22 on vif vr0
> [ 2007/02/27 19:43:39 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from 10.3.2.20
> to 224.0.0.13 on vif em0
> [ 2007/02/27 19:43:40 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from
> 192.168.97.50 to 224.0.0.13 on vif vr0
> [ 2007/02/27 19:43:43 TRACE xorp_igmp MLD6IGMP ] RX
> IGMP_V2_MEMBERSHIP_REPORT from 192.168.97.50 to 224.0.0.2 on vif vr0
> [ 2007/02/27 19:43:43 TRACE xorp_igmp MLD6IGMP ] RX
> IGMP_V2_MEMBERSHIP_REPORT from 192.168.97.50 to 224.0.0.22 on vif vr0
> 
> Logs on XORP with VLC streaming server activated ...
> 
> [ 2007/02/27 20:01:01 TRACE xorp_fea MFEA ] RX kernel signal: message_type
> = 3 vif_index = 2 src = 192.168.97.49 dst = 232.10.10.10
> [ 2007/02/27 20:01:01 TRACE xorp_pimsm4 PIM ] RX WHOLEPKT signal from
> MFEA_4: vif_index = 2 src = 192.168.97.49 dst = 232.10.10.10 len = 1356
> [ 2007/02/27 20:01:01 WARNING xorp_pimsm4 PIM ] RX WHOLEPKT signal from
> MFEA_4: vif_index = 2 src = 192.168.97.49 dst = 232.10.10.10 len = 1356:
> no RP address for this group
> [ 2007/02/27 20:01:01 TRACE xorp_fea MFEA ] RX kernel signal: message_type
> = 3 vif_index = 2 src = 192.168.97.49 dst = 232.10.10.10
> [ 2007/02/27 20:01:01 TRACE xorp_pimsm4 PIM ] RX WHOLEPKT signal from
> MFEA_4: vif_index = 2 src = 192.168.97.49 dst = 232.10.10.10 len = 1356
> [ 2007/02/27 20:01:01 WARNING xorp_pimsm4 PIM ] RX WHOLEPKT signal from
> MFEA_4: vif_index = 2 src = 192.168.97.49 dst = 232.10.10.10 len = 1356:
> no RP address for this group
> [ 2007/02/27 20:01:01 TRACE xorp_fea MFEA ] RX kernel signal: message_type
> = 3 vif_index = 2 src = 192.168.97.49 dst = 232.10.10.10
> [ 2007/02/27 20:01:01 TRACE xorp_pimsm4 PIM ] RX WHOLEPKT signal from
> MFEA_4: vif_index = 2 src = 192.168.97.49 dst = 232.10.10.10 len = 1356
> [ 2007/02/27 20:01:01 WARNING xorp_pimsm4 PIM ] RX WHOLEPKT signal from
> MFEA_4: vif_index = 2 src = 192.168.97.49 dst = 232.10.10.10 len = 1356:
> no RP address for this group
> [ 2007/02/27 20:01:01 TRACE xorp_fea MFEA ] RX kernel signal: message_type
> = 3 vif_index = 2 src = 192.168.97.49 dst = 232.10.10.10
> [ 2007/02/27 20:01:01 TRACE xorp_pimsm4 PIM ] RX WHOLEPKT signal from
> MFEA_4: vif_index = 2 src = 192.168.97.49 dst = 232.10.10.10 len = 1356
> [ 2007/02/27 20:01:01 WARNING xorp_pimsm4 PIM ] RX WHOLEPKT signal from
> MFEA_4: vif_index = 2 src = 192.168.97.49 dst = 232.10.10.10 len = 1356:
> no RP address for this group
> [ 2007/02/27 20:01:01 TRACE xorp_fea MFEA ] RX kernel signal: message_type
> = 3 vif_index = 2 src = 192.168.97.49 dst = 232.10.10.10
> [ 2007/02/27 20:01:01 TRACE xorp_pimsm4 PIM ] RX WHOLEPKT signal from
> MFEA_4: vif_index = 2 src = 192.168.97.49 dst = 232.10.10.10 len = 1356
> [ 2007/02/27 20:01:01 WARNING xorp_pimsm4 PIM ] RX WHOLEPKT signal from
> MFEA_4: vif_index = 2 src = 192.168.97.49 dst = 232.10.10.10 len = 1356:
> no RP address for this group
> [ 2007/02/27 20:01:01 TRACE xorp_fea MFEA ] RX kernel signal: message_type
> = 3 vif_index = 2 src = 192.168.97.49 dst = 232.10.10.10
> [ 2007/02/27 20:01:01 TRACE xorp_pimsm4 PIM ] RX WHOLEPKT signal from
> MFEA_4: vif_index = 2 src = 192.168.97.49 dst = 232.10.10.10 len = 1356
> 
> Running a VLC streaming server
> http://www.videolan.org/doc/streaming-howto/en/ch04.html#id294730
> 
> Running a VLC client with SSM:
> http://www.videolan.org/doc/play-howto/en/ch04.html
> 
> archie# vlc udp:unicast_server_address at multicast_address[:server_port]
> 
> where,
> 
> unicast_server_address = 192.168.97.49 (source/streaming server's unicast
> address)
> multicast_address = 232.10.10.10 (Group)
> server_port = 1234 (default on VLC)
> 
> IGMP Status with XORPSH:
> 
> archie at mcast.cebu.example.ph> show igmp interface
> Interface    State    Querier         Timeout Version Groups
> em0          UP       192.168.96.50      None       3      5
> vr0          UP       10.3.2.18          None       3      3
> 
> archie at mcast.cebu.example.ph> show igmp group
> Interface    Group           Source          LastReported Timeout V State
> em0          224.0.0.2       0.0.0.0         192.168.96.50     251 2     E
> em0          224.0.0.13      0.0.0.0         192.168.96.50     249 2     E
> em0          224.0.0.22      0.0.0.0         192.168.96.50     255 2     E
> em0          232.10.10.10    0.0.0.0         192.168.96.49       0 3     I
> em0          232.10.10.10    192.168.97.49   192.168.96.49      78 3     F
> em0          239.255.255.250 0.0.0.0         192.168.96.48     251 3     E
> vr0          224.0.0.2       0.0.0.0         10.3.2.20        248 2     E
> vr0          224.0.0.13      0.0.0.0         10.3.2.18        248 2     E
> vr0          224.0.0.22      0.0.0.0         10.3.2.18        251 2     E
> 
> On this statistic, it shows that 192.168.96.49 VLC client requests for
> source-specific multicast channel to the streaming server 192.168.97.49 in
> a multicast group of 232.10.10.10.
> 
> Thanks.
> 
> Sincerely Yours,
> 
> Archimedes S. Gaviola
> Network Engineer
> InfoWeapons Corporation
> 
> 
> --------
> This email and/or attachments are confidential and may also be
> legally privileged. If you are not the intended recipient, you are
> hereby notified, that any review, dissemination, distribution or
> copying of this email and/or attachments is strictly prohibited.
> Please notify security at infoweapons.com immediately by email and
> delete this message and all its attachments. Thank you.
> 
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From koippa at gmail.com  Tue Feb 27 13:29:41 2007
From: koippa at gmail.com (Kimmo Koivisto)
Date: Tue, 27 Feb 2007 23:29:41 +0200
Subject: [Xorp-users] Xorp and ospf memory usage?
Message-ID: <200702272329.42736.koippa@gmail.com>

Hello

My colleagues have done some testing with xorp 1.3 in x86, linux 2.6 kernel 
with some router testing equipment (don't know what kind of tester it is, but 
commercial one). Testing equipment sends 500 routes to xorp.

When xorp is started (and no routes are sent yet) xorp's total memory 
consumption is around 20-30 Mb and after 500 routes through ospf memory 
consumption is about 60-70 Mb.

This 60-70 Mb sounds quite much, comparing to the study made in september 06:
http://lib.tkk.fi/Dipl/2006/urn007510.pdf

In that study, quagga, nexthop gated, ipinfusion zebos and Nokia ipsrd consume 
less that 20 Mb with 10 000 routes running in linux  (pages 48-49).

So, my question is, how much xorp should consume memory when processing those 
500 routes in x86 linux, 2.6 kernel?

Best Regards
Kimmo Koivisto


From atanu at ICSI.Berkeley.EDU  Wed Feb 28 08:01:03 2007
From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Wed, 28 Feb 2007 08:01:03 -0800
Subject: [Xorp-users] xorp ospf endless loop problem?
In-Reply-To: Message from Kimmo Koivisto <koippa@gmail.com> of "Mon,
	05 Feb 2007 21:57:58 +0200." <200702052157.58321.koippa@gmail.com> 
Message-ID: <17879.1172678463@tigger.icir.org>

An embedded and charset-unspecified text was scrubbed...
Name: diff
Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20070228/eeed2bd2/attachment.ksh 

From atanu at ICSI.Berkeley.EDU  Wed Feb 28 08:29:53 2007
From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Wed, 28 Feb 2007 08:29:53 -0800
Subject: [Xorp-users] Xorp and ospf memory usage?
In-Reply-To: Message from Kimmo Koivisto <koippa@gmail.com> of "Tue,
	27 Feb 2007 23:29:41 +0200." <200702272329.42736.koippa@gmail.com> 
Message-ID: <24766.1172680193@tigger.icir.org>

Hi,

This memory usage seems too high, could you send me the LSA database
so that I can try this for myself?

The program print_lsas with the '-S' argument will save the LSA database
to a file, you will find the program in the tools directory under ospf.

   Atanu.

>>>>> "Kimmo" == Kimmo Koivisto <koippa at gmail.com> writes:

    Kimmo> Hello My colleagues have done some testing with xorp 1.3 in
    Kimmo> x86, linux 2.6 kernel with some router testing equipment
    Kimmo> (don't know what kind of tester it is, but commercial
    Kimmo> one). Testing equipment sends 500 routes to xorp.

    Kimmo> When xorp is started (and no routes are sent yet) xorp's
    Kimmo> total memory consumption is around 20-30 Mb and after 500
    Kimmo> routes through ospf memory consumption is about 60-70 Mb.

    Kimmo> This 60-70 Mb sounds quite much, comparing to the study made
    Kimmo> in september 06: http://lib.tkk.fi/Dipl/2006/urn007510.pdf

    Kimmo> In that study, quagga, nexthop gated, ipinfusion zebos and
    Kimmo> Nokia ipsrd consume less that 20 Mb with 10 000 routes
    Kimmo> running in linux (pages 48-49).

    Kimmo> So, my question is, how much xorp should consume memory when
    Kimmo> processing those 500 routes in x86 linux, 2.6 kernel?

    Kimmo> Best Regards Kimmo Koivisto

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


From atanu at ICSI.Berkeley.EDU  Wed Feb 28 13:54:31 2007
From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Wed, 28 Feb 2007 13:54:31 -0800
Subject: [Xorp-users] Announcing XORP Release Candidate 1.4
Message-ID: <89366.1172699671@tigger.icir.org>

On behalf of the entire XORP team, I'm delighted to announce the XORP
1.4 Release Candidate, which is now available from <http://www.xorp.org>.

The major feature of this release is the addition of OSPFv3 (OSPF for IPv6).

Once the release candidate has proven to be stable, the actual 1.4
release will be prepared. This is planned to occur in the next two
weeks. In the intervening period we will be fixing minor problems and
updating the documentation.

In general, to test XORP, we run automated regression tests on a daily
basis with various operating systems and compilers. We also run a
number of PCs as XORP routers. We have enabled as many protocols as
feasible on those routers to test protocol interactions (for example a
BGP IPv6 multicast feed being used by PIM-SM). In addition, automated
scripts are run to externally toggle BGP peerings. Finally, we have
automated scripts that interact directly with the xorpsh to change the
configuration settings.

We have put significant effort into testing but obviously we have not
found all the problems. This is where you can help us to make XORP
more stable, by downloading and using it!

As always we'd welcome your comments - xorp-users at xorp.org is the
right place for general discussion, and private feedback to the XORP
core team can be sent to feedback at xorp.org.

 - The XORP Team

P.S.
Release notes included below.

------------------------------------------------------------------
		XORP RELEASE NOTES

Release 1.4-RC (2006/02/28)
=========================
  ALL:
    - XORP now builds on DragonFlyBSD-1.8, FreeBSD-6.2, Linux Fedora
      Core6, Linux Debian-3.1 (sarge), NetBSD-3.1 and OpenBSD-4.0.

    - XORP now can be compiled with the Intel C/C++ compiler 9.* on
      Linux.

    - XORP now can be cross-compiled for IA-64, MIPS (Broadcom for
      Linksys WRT54G), PowerPC-603, Sparc64, and XScale processors.

    - Implementation of OSPFv3 (draft-ietf-ospf-ospfv3-update-14.txt).

    - Implementation of floating static routes (i.e., static routes
      for the same prefix with different next hop and metrics).

  CONFIGURATION:
    - Allow static routes to have "nexthop4" and "nexthop6" policy
      matching conditions in the "from" block.

    - Addition of new FEA configuration statements to retain XORP
      unicast forwarding entries on startup or shutdown:

      fea {
          unicast-forwarding4 {
              forwarding-entries {
                  retain-on-startup: false
                  retain-on-shutdown: false
              }
          }
          unicast-forwarding6 {
              forwarding-entries {
                  retain-on-startup: false
                  retain-on-shutdown: false
              }
          }
      }

      The default value for each statement is false.
      Note that those statements prevent the FEA itself from deleting
      the forwarding entries and does not prevent the RIB or any of the
      unicast routing protocols from deleting the entries on shutdown.

    - The "elements" policy statements for configuring sets of network
      routes have been deprecated:

      policy {
          network4-list foo {
              elements: "1.2.0.0/16,3.4.0.0/16"
          }
          network6-list bar {
              elements: "2222::/64,3333::/64"
          }
      }

      The new replacement statement is "network" and can be used to
      specify one element per line:

      policy {
          network4-list foo {
              network 1.2.0.0/16
              network 3.4.0.0/16
          }
          network6-list bar {
              network 2222::/64
              network 3333::/64
          }
      }

    - The following keywords are supported inside the policy
      configuration when comparing IPv4 or IPv6 network prefixes:
      exact, longer, orlonger, shorter, orshorter, not. For example:

      "network4 exact 10.0.0.0/8"     SAME AS "network4 == 10.0.0.0/8"
      "network4 longer 10.0.0.0/8"    SAME AS "network4 < 10.0.0.0/8"
      "network4 orlonger 10.0.0.0/8"  SAME AS "network4 <= 10.0.0.0/8"
      "network4 shorter 10.0.0.0/8"   SAME AS "network4 > 10.0.0.0/8"
      "network4 orshorter 10.0.0.0/8" SAME AS "network4 >= 10.0.0.0/8"
      "network4 not 10.0.0.0/8"       SAME AS "network4 != 10.0.0.0/8"

      The original operators are supported as well.

    - A floating static route (also called "qualified" by some router
      vendors) can be added with a configuration like:

      protocols {
          static {
              route 10.10.0.0/16 {
                  next-hop: 172.16.0.1
                  metric: 1
                  qualified-next-hop 172.17.0.2 {
                      metric: 10
                  }
              }
              interface-route 10.30.30.0/24 {
                  next-hop-interface: "rl0"
                  next-hop-vif: "rl0"
                  next-hop-router: 172.16.0.1
                  metric: 1
                  qualified-next-hop-interface rl1 {
                      qualified-next-hop-vif rl1 {
                          next-hop-router: 172.17.0.2
                          metric: 10
                      }
                  }
              }
          }
      }

  LIBXORP:
    - The XORP scheduler now has support for priority-based tasks.

  LIBXIPC:
    - No significant changes.

  LIBFEACLIENT:
    - No significant changes.

  XRL:
    - No significant changes.

  RTRMGR:
    - Bug fix in the semantics of the rtrmgr template %activate keyword.

  XORPSH:
    - No significant changes.

  POLICY:
    - Bug fix related to creating export policies that match protocol's
      its own routes (e.g., a policy that modifies the BGP routes
      exported to its peers).

    - Various other bug fixes.

  FEA/MFEA:
    - Fix the routing socket based mechanism (used by BSD-derived
      systems) for obtaining the interface name (toward the destination)
      for a routing entry.

    - Apply a performance improvement when configuring a large number of
      interfaces/VIFs, each of them with the "default-system-config"
      configuration statement.

    - Bug fix related to atomically modifying the IP address of an interface.

  RIB:
    - Bug fix related to (not) installing redundant host-specific
      entries for the other side of a point-to-point interface if the
      netmask for the interface covers the host-specific entry.

  RIP:
    - No significant changes.

  OSPF:
    - OSPFv3 is now available.

    - The OSPFv3 protocol requires that link-local addresses are used,
      therefore it is necessary to configure a link-local address for
      each interface, this restriction will be removed in the future.

    - The OSPFv3 configuration allows multiple instances to be configured
      however only one instance will be created.

    - For OSPFv3 only one global address can be set on an interface,
      multiple addresses will be allowed in the final release. Please
      note that the configuration will change when multiple addresses
      are supported.

    - The OSPFv3 specification requires that unknown LSAs should be
      processed, currently unknown LSAs are incorrectly considered an
      error. Unknown LSAs will be handled in the final release.

    - OSPFv3 has support for virtual links but adjacencies are not
      always correctly formed.
      
    - Bug fix related to the processing of previously generated LSAs
      on startup has been fixed. Restarting a router that was the
      designated router could exhibit this problem.
      
    - Bug fix on a broadcast interface if the router was not the
      designated router then the nexthop was incorrectly
      unconditionally set to the designated router; introducing an
      unnecessary extra hop.

  BGP:
    - BGP has taken advantage of the priority-based tasks in the XORP
      scheduler and background tasks are run at a low priority;
      leading to improved performance.

  STATIC_ROUTES:
    - Bug fix related to declaring some of the policy matching
      conditions in the "from" block.

  MLD/IGMP:
    - Bug fix related to atomically modifying the IP address of an
      interface.

    - Bug fix related to ignoring protocol messages that are not
      recognized by the configured protocol version on an interface.

    - Ignore control messages if the source address is not directly
      connected.

    - Don't send the periodic Group-Specific or Group-and-Source-Specific
      Queries for entries that are in IGMPv1 mode.

  PIM-SM:
    - Bug fix related to atomically modifying the IP address of an
      interface.

    - The PIM-SM control messages do not include the IP Router Alert
      option anymore, because it has been included from the newer
      revisions of the PIM-SM protocol specification (RFC 4601 and
      draft-ietf-pim-sm-bsr-09.txt,.ps).

    - Don't send PIM Hello message with DR Priority of 0 when shutting
      down an interface, because this is not part of the protocol
      specification.

  FIB2MRIB:
    - Bug fix related to updating the interface and vif name of a
      forwarding entry received from the FEA.

  CLI:
    - Performance improvement if the CLI is processing a large amount
      of data. E.g., if xorpsh is used in a pipe like:

      cat commands.txt | xorpsh

  SNMP:
    - Bug fix with the snmpd arguments when sampling whether snmpd
      can start and its version is >= 5.2.

------------------------------------------------------------------