From sureshkannan at gmail.com  Thu Mar  1 01:52:02 2007
From: sureshkannan at gmail.com (Suresh kannan)
Date: Thu, 1 Mar 2007 15:22:02 +0530
Subject: [Xorp-hackers] Multicast routing
In-Reply-To: <200702151849.l1FInFAj061152@possum.icir.org>
References: <sachinutd@gmail.com>
	<fcfc34be0702142120x344ad2aau84983a1bf020583e@mail.gmail.com>
	<200702151849.l1FInFAj061152@possum.icir.org>
Message-ID: <84f679e0703010152q42cb78e9m5ff1deb690de5d62@mail.gmail.com>

Hi Pavlin,

Sorry for very late response. I was bit busy with other works.
Please look for inline comments. %suresh :

Thanks,
Regards,
Suresh kannan.

On 2/16/07, Pavlin Radoslavov <pavlin at icir.org> wrote:
>
> Sachin K <sachinutd at gmail.com> wrote:
>
> > How does the XORP multicast router sniff IGMP/MLD messages from the
> network?
> >
> > I checked the some routers' code. Most of them just open a RAW socket
> with
> > protocol set to IPPROTO_IGMP. But using this the router gets the
> > packets addressed to 224.0.0.1 only.
> >
> > How does it receive IGMPv2 and IGMPv3 membership reports sent by other
> hosts?
>
> The kernel gets all multicast packets because the interface is set
> in ALLMULTI mode (i.e., snoop all multicast packets). This happens
> after the multicast routing socket has been opened with
> setsockopt(..., MRT_INIT, ...) and then each interface is added with
> setsockopt(..., MRT_ADD_VIF, ...).


%Suresh : In FreeBSD, IGMP packets are handled in from ipintr() in
ip_input.c where it directly goes to igmp_input() (igmp.c). From here, it
puts packet to applications via rip_input call. So, I guess to receive IGMP
packets we no need to setsockopt though IGMP ( XORP,etc) adds to VIF; thats
to enable Mrouting on that interface. Not particularly to receive IGMP
control packets. Please correct me if I'm wrong here.

Then the userland program can receive the IGMP packets with opening
> a raw IPPROTO_IGMP socket.
>
> BTW, note that there could be only one multicast routing socket open
> at a time (across all processes).
>
> Regards,
> Pavlin
>
>
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20070301/e5f96f4e/attachment.html 

From pavlin at icir.org  Thu Mar  1 11:04:43 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Thu, 01 Mar 2007 11:04:43 -0800
Subject: [Xorp-hackers] Multicast routing
In-Reply-To: Message from "Suresh kannan" <sureshkannan@gmail.com> of "Thu,
	01 Mar 2007 15:22:02 +0530."
	<84f679e0703010152q42cb78e9m5ff1deb690de5d62@mail.gmail.com> 
Message-ID: <200703011904.l21J4hAW066958@possum.icir.org>

> > > How does the XORP multicast router sniff IGMP/MLD messages from the
> > network?
> > >
> > > I checked the some routers' code. Most of them just open a RAW socket
> > with
> > > protocol set to IPPROTO_IGMP. But using this the router gets the
> > > packets addressed to 224.0.0.1 only.
> > >
> > > How does it receive IGMPv2 and IGMPv3 membership reports sent by other
> > hosts?
> >
> > The kernel gets all multicast packets because the interface is set
> > in ALLMULTI mode (i.e., snoop all multicast packets). This happens
> > after the multicast routing socket has been opened with
> > setsockopt(..., MRT_INIT, ...) and then each interface is added with
> > setsockopt(..., MRT_ADD_VIF, ...).
> 
> 
> %Suresh : In FreeBSD, IGMP packets are handled in from ipintr() in
> ip_input.c where it directly goes to igmp_input() (igmp.c). From here, it
> puts packet to applications via rip_input call. So, I guess to receive IGMP
> packets we no need to setsockopt though IGMP ( XORP,etc) adds to VIF; thats
> to enable Mrouting on that interface. Not particularly to receive IGMP
> control packets. Please correct me if I'm wrong here.

You need MRT_ADD_VIF if you want to guarantee you will receive all
IGMP packets.

The IP stack will get a multicast packet (including the IGMP packets
that are always sent to a multicast destination) only if:

 (a) The host has explicitly joined the particular multicast group
 on the particular network interface.

OR

 (b) The network interface is in IFF_ALLMULTI mode (i.e., to snoop
 and pass all multicast packets to the IP stack).

Otherwise a multicast packet will be ignored by the network
interface and won't even reach ip_input().

Obviously, you cannot do (a) for each of the multicast groups in the
whole multicast address space.
Hence, to guarantee that you will get all IGMP packets you need to
do (b).
I believe the only API that allows the user to set the IFF_ALLMULTI
flag on an interface is by using setsockopt(MRT_ADD_VIF).
At least, this is the API that is guaranteed to work on all UNIX
systems that support multicast forwarding.

However, if you care only about the IGMP packets sent to a small
number of multicast groups, then you could explicitly join each of
those groups and you don't need setsockopt(MRT_ADD_VIF).

Regards,
Pavlin

> Then the userland program can receive the IGMP packets with opening
> > a raw IPPROTO_IGMP socket.
> >
> > BTW, note that there could be only one multicast routing socket open
> > at a time (across all processes).
> >
> > Regards,
> > Pavlin
> >
> >
> > _______________________________________________
> > Xorp-hackers mailing list
> > Xorp-hackers at icir.org
> > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
> >
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers


From sureshkannan at gmail.com  Thu Mar  1 23:15:46 2007
From: sureshkannan at gmail.com (Suresh kannan)
Date: Fri, 2 Mar 2007 12:45:46 +0530
Subject: [Xorp-hackers] Multicast routing
In-Reply-To: <200703011904.l21J4hAW066958@possum.icir.org>
References: <sureshkannan@gmail.com>
	<84f679e0703010152q42cb78e9m5ff1deb690de5d62@mail.gmail.com>
	<200703011904.l21J4hAW066958@possum.icir.org>
Message-ID: <84f679e0703012315i339e4202y65862ef22bd3c89@mail.gmail.com>

Hi Pavlin,

Sounds great. Thanks for the info. It clears my doubt which i had for long
time.

Thanks,
Regards,
Suresh kannan.

On 3/2/07, Pavlin Radoslavov <pavlin at icir.org> wrote:
>
> > > > How does the XORP multicast router sniff IGMP/MLD messages from the
> > > network?
> > > >
> > > > I checked the some routers' code. Most of them just open a RAW
> socket
> > > with
> > > > protocol set to IPPROTO_IGMP. But using this the router gets the
> > > > packets addressed to 224.0.0.1 only.
> > > >
> > > > How does it receive IGMPv2 and IGMPv3 membership reports sent by
> other
> > > hosts?
> > >
> > > The kernel gets all multicast packets because the interface is set
> > > in ALLMULTI mode (i.e., snoop all multicast packets). This happens
> > > after the multicast routing socket has been opened with
> > > setsockopt(..., MRT_INIT, ...) and then each interface is added with
> > > setsockopt(..., MRT_ADD_VIF, ...).
> >
> >
> > %Suresh : In FreeBSD, IGMP packets are handled in from ipintr() in
> > ip_input.c where it directly goes to igmp_input() (igmp.c). From here,
> it
> > puts packet to applications via rip_input call. So, I guess to receive
> IGMP
> > packets we no need to setsockopt though IGMP ( XORP,etc) adds to VIF;
> thats
> > to enable Mrouting on that interface. Not particularly to receive IGMP
> > control packets. Please correct me if I'm wrong here.
>
> You need MRT_ADD_VIF if you want to guarantee you will receive all
> IGMP packets.
>
> The IP stack will get a multicast packet (including the IGMP packets
> that are always sent to a multicast destination) only if:
>
> (a) The host has explicitly joined the particular multicast group
> on the particular network interface.
>
> OR
>
> (b) The network interface is in IFF_ALLMULTI mode (i.e., to snoop
> and pass all multicast packets to the IP stack).
>
> Otherwise a multicast packet will be ignored by the network
> interface and won't even reach ip_input().
>
> Obviously, you cannot do (a) for each of the multicast groups in the
> whole multicast address space.
> Hence, to guarantee that you will get all IGMP packets you need to
> do (b).
> I believe the only API that allows the user to set the IFF_ALLMULTI
> flag on an interface is by using setsockopt(MRT_ADD_VIF).
> At least, this is the API that is guaranteed to work on all UNIX
> systems that support multicast forwarding.
>
> However, if you care only about the IGMP packets sent to a small
> number of multicast groups, then you could explicitly join each of
> those groups and you don't need setsockopt(MRT_ADD_VIF).
>
> Regards,
> Pavlin
>
> > Then the userland program can receive the IGMP packets with opening
> > > a raw IPPROTO_IGMP socket.
> > >
> > > BTW, note that there could be only one multicast routing socket open
> > > at a time (across all processes).
> > >
> > > Regards,
> > > Pavlin
> > >
> > >
> > > _______________________________________________
> > > Xorp-hackers mailing list
> > > Xorp-hackers at icir.org
> > > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
> > >
> > _______________________________________________
> > Xorp-hackers mailing list
> > Xorp-hackers at icir.org
> > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20070302/30b0227f/attachment.html 

From pavlin at icir.org  Fri Mar  2 15:56:47 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Fri, 02 Mar 2007 15:56:47 -0800
Subject: [Xorp-hackers] Removing unused test programs
Message-ID: <200703022356.l22Nulkx095943@possum.icir.org>

I am planning to remove the following test programs because they are
not needed anymore: fea/test_mfea, mld6igmp/test_mld6igmp and
pim/test_pim?

Does anyone use/need them?

Thanks,
Pavlin


From prachi.gaikwad at gmail.com  Mon Mar  5 07:05:58 2007
From: prachi.gaikwad at gmail.com (prachi gaikwad)
Date: Mon, 5 Mar 2007 20:35:58 +0530
Subject: [Xorp-hackers] debugging code..help required...
Message-ID: <c482a6460703050705g69615307ya14936b68f4be057@mail.gmail.com>

We have to provide point to multipoint multicast as an extension to existing
LDP
http://tools.ietf.org/wg/mpls/draft-ietf-mpls-ldp-p2mp/draft-ietf-mpls-ldp-p2mp-01.txt

--Label Distribution Protocol Extensions for Point-to-Multipoint and
Multipoint-to-Multipoint Label Switched Paths.

. since we are using zMPLS(zMPLS supports LDP) we would like to know how to
debug the existing code...can we insert ' printf ()' statements in
code...??? ..
also where will the output of such statements be logged...

since most of the code is based on zebra routing software.......

we would like to know how we can understand the exact flow of code as in
which functions get called when..we have studied the code for zMPLS but some
suggestions on this would be of great help..

thank you,
regards,
Prachi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20070305/73806d17/attachment.html 

From prachi.gaikwad at gmail.com  Mon Mar  5 07:05:58 2007
From: prachi.gaikwad at gmail.com (prachi gaikwad)
Date: Mon, 5 Mar 2007 20:35:58 +0530
Subject: [Xorp-hackers] debugging code..help required...
Message-ID: <c482a6460703050705g69615307ya14936b68f4be057@mail.gmail.com>

We have to provide point to multipoint multicast as an extension to existing
LDP
http://tools.ietf.org/wg/mpls/draft-ietf-mpls-ldp-p2mp/draft-ietf-mpls-ldp-p2mp-01.txt

--Label Distribution Protocol Extensions for Point-to-Multipoint and
Multipoint-to-Multipoint Label Switched Paths.

. since we are using zMPLS(zMPLS supports LDP) we would like to know how to
debug the existing code...can we insert ' printf ()' statements in
code...??? ..
also where will the output of such statements be logged...

since most of the code is based on zebra routing software.......

we would like to know how we can understand the exact flow of code as in
which functions get called when..we have studied the code for zMPLS but some
suggestions on this would be of great help..

thank you,
regards,
Prachi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20070305/73806d17/attachment-0001.html 

From chintamanisw at gmail.com  Mon Mar  5 07:57:25 2007
From: chintamanisw at gmail.com (chintamani wandhre)
Date: Mon, 5 Mar 2007 21:27:25 +0530
Subject: [Xorp-hackers] PIM-SM / PIM-Bidir doubt about (*,G) entries.
In-Reply-To: <200702182124.l1ILORgq092765@possum.icir.org>
References: <shamita1010@gmail.com>
	<cb2733e40702180452je1fe5ddvaf4b7d8499feaaa1@mail.gmail.com>
	<200702182124.l1ILORgq092765@possum.icir.org>
Message-ID: <8385815b0703050757p53b60d95qfa73ff19870c368@mail.gmail.com>

On 2/19/07, Pavlin Radoslavov <pavlin at icir.org> wrote:
>
> > As per your reply regarding setting the bidir-bit so as to differentiate
> > between the PIM-SM and PIM-Bidir (*,G) entries ,we are not very clear
> about
> > how the (*,G) entries are stored in PIM_SM as per your
> implementation.(We
> > tried searching for those in PIM_MRE.hh ,PIM.h,IPv4.h.)So we are unable
> to
> > decide the setting of the Bidir-bit for (*,G) entries.
> >
> > Can we use a flag along with the (*,G) entries and store both of them
> > together in the templates????
>
> The PimMre class is defined in pim_mre.hh. This class is used for
> any type of multicast routing entries, so you have to add the
> bidir flag to that class.
>
>

          Till now we have enabled enable_pim_bidir  flag by using config
file (pim.tp) & now we are able to use this flag to check
is_pim_bidir_enable in PimNode.cc. Also we have managed to add
PIM_BIDIR_CAPABLE flag in pim_proto_hello.cc !!!!
          Sir we are thinking of using the same flag(is_pim_bidir_enable) to
maintain the (*,G) entries in PIM-MRE class.If this flag is enabled then we
are going to consider every (*,G) entry for pim-bidir. Please validate us!!

Thanking you in anticipation
 -Shamita
-Ashish
-chintamani
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20070305/90845e16/attachment.html 

From pavlin at icir.org  Mon Mar  5 09:46:27 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Mon, 05 Mar 2007 09:46:27 -0800
Subject: [Xorp-hackers] PIM-SM / PIM-Bidir doubt about (*,G) entries.
In-Reply-To: Message from "chintamani wandhre" <chintamanisw@gmail.com> 
	of "Mon, 05 Mar 2007 21:27:25 +0530."
	<8385815b0703050757p53b60d95qfa73ff19870c368@mail.gmail.com> 
Message-ID: <200703051746.l25HkRaO025045@possum.icir.org>

chintamani wandhre <chintamanisw at gmail.com> wrote:

> On 2/19/07, Pavlin Radoslavov <pavlin at icir.org> wrote:
> >
> > > As per your reply regarding setting the bidir-bit so as to differentiate
> > > between the PIM-SM and PIM-Bidir (*,G) entries ,we are not very clear
> > about
> > > how the (*,G) entries are stored in PIM_SM as per your
> > implementation.(We
> > > tried searching for those in PIM_MRE.hh ,PIM.h,IPv4.h.)So we are unable
> > to
> > > decide the setting of the Bidir-bit for (*,G) entries.
> > >
> > > Can we use a flag along with the (*,G) entries and store both of them
> > > together in the templates????
> >
> > The PimMre class is defined in pim_mre.hh. This class is used for
> > any type of multicast routing entries, so you have to add the
> > bidir flag to that class.
> >
> >
> 
>           Till now we have enabled enable_pim_bidir  flag by using config
> file (pim.tp) & now we are able to use this flag to check
> is_pim_bidir_enable in PimNode.cc. Also we have managed to add
> PIM_BIDIR_CAPABLE flag in pim_proto_hello.cc !!!!
>           Sir we are thinking of using the same flag(is_pim_bidir_enable) to

Please call me just Pavlin :)

> maintain the (*,G) entries in PIM-MRE class.If this flag is enabled then we
> are going to consider every (*,G) entry for pim-bidir. Please validate us!!

I believe this is the right approach.

Regards,
Pavlin


> Thanking you in anticipation
>  -Shamita
> -Ashish
> -chintamani
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers


From chintamanisw at gmail.com  Tue Mar  6 08:07:35 2007
From: chintamanisw at gmail.com (chintamani wandhre)
Date: Tue, 6 Mar 2007 21:37:35 +0530
Subject: [Xorp-hackers] [PIM] Setting a bit in the Encoded source address
Message-ID: <8385815b0703060807o42af2f69j6a60db6709f5a10d@mail.gmail.com>

hello,
We have to set the bidirectional bit in the ENCODED GROUP ADDRESS


 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Addr Family  | Encoding Type |B| Reserved  |Z|  Mask Len     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                Group multicast Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

By using following function we can get octet but how can we set the single
bit ( B )?  :)

i could not get the flow in the following code :

#define GET_OCTET(val, cp, rcvlen)                      \
do {                                                                    \
    if ((size_t)(rcvlen) < (size_t)1)                            \
        goto rcvlen_error;                                         \
    (rcvlen)--;                                                         \
    ((val) = *(cp)++);                                               \
} while (0)

thanking you in anticipation

shamita
ashish
chintamani
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20070306/8f590b92/attachment.html 

From pavlin at icir.org  Tue Mar  6 12:05:13 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Tue, 06 Mar 2007 12:05:13 -0800
Subject: [Xorp-hackers] [PIM] Setting a bit in the Encoded source address
In-Reply-To: Message from "chintamani wandhre" <chintamanisw@gmail.com> 
	of "Tue, 06 Mar 2007 21:37:35 +0530."
	<8385815b0703060807o42af2f69j6a60db6709f5a10d@mail.gmail.com> 
Message-ID: <200703062005.l26K5DNg040109@possum.icir.org>

chintamani wandhre <chintamanisw at gmail.com> wrote:

> hello,
> We have to set the bidirectional bit in the ENCODED GROUP ADDRESS
> 
> 
>  0                   1                   2                   3
>  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |  Addr Family  | Encoding Type |B| Reserved  |Z|  Mask Len     |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |                Group multicast Address
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
> 
> By using following function we can get octet but how can we set the single
> bit ( B )?  :)
> 
> i could not get the flow in the following code :
> 
> #define GET_OCTET(val, cp, rcvlen)                      \
> do {                                                                    \
>     if ((size_t)(rcvlen) < (size_t)1)                            \
>         goto rcvlen_error;                                         \
>     (rcvlen)--;                                                         \
>     ((val) = *(cp)++);                                               \
> } while (0)
> 
> thanking you in anticipation

You could use the PUT_OCTET() macro.
I believe the remaining 7 bits in the Reserved field are suppose to
be 0. Hence you need to use PUT_OCTET() to set both Reserved and Z
at the same time (because they belong to the same octet).

Regards,
Pavlin


From chintamanisw at gmail.com  Wed Mar  7 07:08:19 2007
From: chintamanisw at gmail.com (chintamani wandhre)
Date: Wed, 7 Mar 2007 20:38:19 +0530
Subject: [Xorp-hackers] [PIM] Setting a bit in the Encoded source address
In-Reply-To: <200703062005.l26K5DNg040109@possum.icir.org>
References: <chintamanisw@gmail.com>
	<8385815b0703060807o42af2f69j6a60db6709f5a10d@mail.gmail.com>
	<200703062005.l26K5DNg040109@possum.icir.org>
Message-ID: <8385815b0703070708v288d98d6qa2351b0adb8d9db0@mail.gmail.com>

On 3/7/07, Pavlin Radoslavov <pavlin at icir.org> wrote:
>
> chintamani wandhre <chintamanisw at gmail.com> wrote:
>
> > hello,
> > We have to set the bidirectional bit in the ENCODED GROUP ADDRESS
> >
> >
> >  0                   1                   2                   3
> >  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |  Addr Family  | Encoding Type |B| Reserved  |Z|  Mask Len     |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |                Group multicast Address
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
> >
> > By using following function we can get octet but how can we set the
> single
> > bit ( B )?  :)
> >
> > i could not get the flow in the following code :
> >
> > #define GET_OCTET(val, cp, rcvlen)                      \
> > do
> {                                                                    \
> >     if ((size_t)(rcvlen) < (size_t)1)                            \
> >         goto rcvlen_error;                                         \
> >     (rcvlen)--;
> \
> >     ((val) = *(cp)++);                                               \
> > } while (0)
> >
> > thanking you in anticipation
>
> You could use the PUT_OCTET() macro.
> I believe the remaining 7 bits in the Reserved field are suppose to
> be 0. Hence you need to use PUT_OCTET() to set both Reserved and Z
> at the same time (because they belong to the same octet).


hello,
we set that B bit but now we want to check that bit.
we were able to see the BIDIR_CAPABLE Flag in hello messages using
ethereal.How can we do the same for checking this B bit???

We made changes as follows
in file
------------------------------------------------------
-> pim_proto.hh
#define EGADDR _B_BIT    0x80
------------------------------------------------------
-> pim_proto_join_prune_message.cc
group_addr_reserved_flag |= EGADDR _B_BIT
--------------------------------------------------------------------
i hope this will do the work!!!!


thanking you in anticipation
Ashish
Shamita
Chintamani




Regards,
> Pavlin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20070307/7f1ae1ba/attachment.html 

From pavlin at icir.org  Wed Mar  7 10:14:13 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Wed, 07 Mar 2007 10:14:13 -0800
Subject: [Xorp-hackers] [PIM] Setting a bit in the Encoded source address
In-Reply-To: Message from "chintamani wandhre" <chintamanisw@gmail.com> 
	of "Wed, 07 Mar 2007 20:38:19 +0530."
	<8385815b0703070708v288d98d6qa2351b0adb8d9db0@mail.gmail.com> 
Message-ID: <200703071814.l27IEDPd049005@possum.icir.org>

> > > We have to set the bidirectional bit in the ENCODED GROUP ADDRESS
> > >
> > >
> > >  0                   1                   2                   3
> > >  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > |  Addr Family  | Encoding Type |B| Reserved  |Z|  Mask Len     |
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > > |                Group multicast Address
> > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
> > >
> > > By using following function we can get octet but how can we set the
> > single
> > > bit ( B )?  :)
> > >
> > > i could not get the flow in the following code :
> > >
> > > #define GET_OCTET(val, cp, rcvlen)                      \
> > > do
> > {                                                                    \
> > >     if ((size_t)(rcvlen) < (size_t)1)                            \
> > >         goto rcvlen_error;                                         \
> > >     (rcvlen)--;
> > \
> > >     ((val) = *(cp)++);                                               \
> > > } while (0)
> > >
> > > thanking you in anticipation
> >
> > You could use the PUT_OCTET() macro.
> > I believe the remaining 7 bits in the Reserved field are suppose to
> > be 0. Hence you need to use PUT_OCTET() to set both Reserved and Z
> > at the same time (because they belong to the same octet).
> 
> 
> hello,
> we set that B bit but now we want to check that bit.
> we were able to see the BIDIR_CAPABLE Flag in hello messages using
> ethereal.How can we do the same for checking this B bit???
> 
> We made changes as follows
> in file
> ------------------------------------------------------
> -> pim_proto.hh
> #define EGADDR _B_BIT    0x80

The correct definition for the bit is 0x1, because it is the
least-significant bit in the Reserved octet.

> ------------------------------------------------------
> -> pim_proto_join_prune_message.cc
> group_addr_reserved_flag |= EGADDR _B_BIT
> --------------------------------------------------------------------
> i hope this will do the work!!!!

Yes, but make sure you remove the extra space between
EGADDR and _B_BIT :)
Also, the correct name of the variable is group_addr_reserved_flags
(used inside method PimJpHeader::network_send()).

Regards,
Pavlin

> 
> thanking you in anticipation
> Ashish
> Shamita
> Chintamani
> 
> 
> 
> 
> Regards,
> > Pavlin
> >
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers


From jonirucoeith at gmail.com  Wed Mar  7 15:34:33 2007
From: jonirucoeith at gmail.com (Jon Andersson)
Date: Thu, 08 Mar 2007 00:34:33 +0100
Subject: [Xorp-hackers] Error in make check??
Message-ID: <op.touefvr4ra252f@ici-xp>

Hi,

Installed 1.4RC on an Ubuntu 6.06 system, and ran make check.

The following was reported:

<snip>
PASS: test_templates
test_sample_config: config tree init error: PARSE ERROR [Config File  
./config.boot.sample, line 26]: No template found in template map; Last  
symbol parsed was "prefix-length"
test_sample_config: TEST FAILED
FAIL: test_sample_config
[ 2007/03/08 00:11:28 TRACE test_module_manager RTRMGR ] New module:  
finder (../libxipc/xorp_finder)
[ 2007/03/08 00:11:28 INFO test_module_manager RTRMGR ] Executing module:  
finder (../libxipc/xorp_finder)
</snip>

Since this is the first install and check, I'd like some feedback on yhis.

Thanks,

Jon


From atanu at ICSI.Berkeley.EDU  Wed Mar  7 15:40:44 2007
From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Wed, 07 Mar 2007 15:40:44 -0800
Subject: [Xorp-hackers] Error in make check??
In-Reply-To: Message from "Jon Andersson" <jonirucoeith@gmail.com> 
	of "Thu, 08 Mar 2007 00:34:33 +0100." <op.touefvr4ra252f@ici-xp> 
Message-ID: <2631.1173310844@tigger.icir.org>

Hi,

This has now been fixed, I made a change to the sample config file just
before the release candidate without realising that the file is
checked.

     Atanu.

diff -c -r1.44 -r1.45
*** config.boot.sample  28 Feb 2007 00:24:01 -0000      1.44
--- config.boot.sample  1 Mar 2007 02:53:36 -0000       1.45
***************
*** 1,4 ****
! /* $XORP: xorp/rtrmgr/config.boot.sample,v 1.44 2007/02/28 00:24:01 atanu Exp $ */
  
  
  interfaces {
--- 1,4 ----
! /* $XORP: xorp/rtrmgr/config.boot.sample,v 1.45 2007/03/01 02:53:36 pavlin Exp $ */
  
  
  interfaces {
***************
*** 21,27 ****
            }
  */
  /*
!           address fe80::1 { /* Link-local address */
                prefix-length: 64
                disable: false
            }
--- 21,27 ----
            }
  */
  /*
!           address fe80::1 {
                prefix-length: 64
                disable: false
            }

>>>>> "Jon" == Jon Andersson <jonirucoeith at gmail.com> writes:

    Jon> Hi, Installed 1.4RC on an Ubuntu 6.06 system, and ran make
    Jon> check.

    Jon> The following was reported:

    Jon> <snip> PASS: test_templates test_sample_config: config tree
    Jon> init error: PARSE ERROR [Config File ./config.boot.sample, line
    Jon> 26]: No template found in template map; Last symbol parsed was
    Jon> "prefix-length" test_sample_config: TEST FAILED FAIL:
    Jon> test_sample_config [ 2007/03/08 00:11:28 TRACE
    Jon> test_module_manager RTRMGR ] New module: finder
    Jon> (../libxipc/xorp_finder) [ 2007/03/08 00:11:28 INFO
    Jon> test_module_manager RTRMGR ] Executing module: finder
    Jon> (../libxipc/xorp_finder) </snip>

    Jon> Since this is the first install and check, I'd like some
    Jon> feedback on yhis.

    Jon> Thanks,

    Jon> Jon

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


From ashishkarpe at gmail.com  Wed Mar  7 18:05:58 2007
From: ashishkarpe at gmail.com (Ashish Karpe)
Date: Thu, 8 Mar 2007 07:35:58 +0530
Subject: [Xorp-hackers] Problem in dissabling pimbidir flag !!!!!
Message-ID: <f87e63a0703071805l7e7ab330x995617f818a3fd33@mail.gmail.com>

hello ,

        now we tried to disable PIM-Bidir by making enable-pim-bidir :
falsein config file !!! but it failed because it is entering in if()
bloack shown
below :

---------------------------------------------------------------------
In pim_node_cli.cc

//    To Add Commands for PIM-Bidir

is_enabled = pim_node().is_pim_bidir_enabled().get();
if (pim_node().is_ipv4() && is_enabled){

    add_cli_dir_command("show pimbidir","Display information about IPv4
PIMBIDIR");


    add_cli_command("show pimbidir bootstrap",
            "Display information about PIMBIDIR IPv4 bootstrap routers",
            callback(this, &PimNodeCli::cli_show_pimbidir_bootstrap));
.
.
.


--------------------------------------------------------
Modification in pim_node.cc file
In PimNode::PimNode(....)
.
.
.
_is_pim_bidir_enabled
.
.
.
---------------------------------------------------------

We are we going wrong why are not we able to disable pim-bidir through
config file !!!

Thank you,
Ashish

Chintamani
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20070308/c336f9dd/attachment.html 

From pavlin at icir.org  Thu Mar  8 05:30:31 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Thu, 08 Mar 2007 05:30:31 -0800
Subject: [Xorp-hackers] Problem in dissabling pimbidir flag !!!!!
In-Reply-To: Message from "Ashish Karpe" <ashishkarpe@gmail.com> of "Thu,
	08 Mar 2007 07:35:58 +0530."
	<f87e63a0703071805l7e7ab330x995617f818a3fd33@mail.gmail.com> 
Message-ID: <200703081330.l28DUVpw062196@possum.icir.org>

Ashish Karpe <ashishkarpe at gmail.com> wrote:

> hello ,
> 
>         now we tried to disable PIM-Bidir by making enable-pim-bidir :
> falsein config file !!! but it failed because it is entering in if()
> bloack shown
> below :
> 
> ---------------------------------------------------------------------
> In pim_node_cli.cc
> 
> //    To Add Commands for PIM-Bidir
> 
> is_enabled = pim_node().is_pim_bidir_enabled().get();
> if (pim_node().is_ipv4() && is_enabled){
> 
>     add_cli_dir_command("show pimbidir","Display information about IPv4
> PIMBIDIR");
> 
> 
>     add_cli_command("show pimbidir bootstrap",
>             "Display information about PIMBIDIR IPv4 bootstrap routers",
>             callback(this, &PimNodeCli::cli_show_pimbidir_bootstrap));
> .
> .
> .
> 
> 
> --------------------------------------------------------
> Modification in pim_node.cc file
> In PimNode::PimNode(....)
> .
> .
> .
> _is_pim_bidir_enabled
> .
> .
> .
> ---------------------------------------------------------
> 
> We are we going wrong why are not we able to disable pim-bidir through
> config file !!!

What is the default value for the _is_pim_bidir_enabled flag?
Note that the PimNodeCli::add_all_cli_commands() method is executed
before the PIM-SM module is configured, hence whatever configuration
changes you make to the _is_pim_bidir_enabled flag they will be in
effect after the PimNodeCli::add_all_cli_commands() method is
executed.

Regards,
Pavlin

> Thank you,
> Ashish
> 
> Chintamani
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers


From jonirucoeith at gmail.com  Fri Mar  9 01:11:13 2007
From: jonirucoeith at gmail.com (Jon Andersson)
Date: Fri, 09 Mar 2007 10:11:13 +0100
Subject: [Xorp-hackers] XORP and Multi-Topology (MT) Routing in OSPF
Message-ID: <op.towzszijra252f@ici-xp.sici.thales.no>

Hi,

Are there any plans to support this in XORP?

I have been looking into the possibillity of doing an implementation of  
Multi-Topology (MT) Routing in OSPF (draft-ietf-ospf-mt-08.txt) with XORP  
as the framework.

I would like some feedback on a few design issues, mostly related to  
roadmap and overall philosophy:

a) Should the design aim for a separate protocol (making it ospf4, ospf6,  
ospf4mt...) or configurable extensions to existing implementations?

b) After a look at the XORP architecture, I have (so far) identified  
changes (apart from ospf) in RIB, CLI(!) and POLICY.

c) My impression is theat changes to FEA might depend on chosen  
implementation. Other changes I would need to make?


Cheers,

Jon


From greenhal at icir.org  Fri Mar  9 03:43:45 2007
From: greenhal at icir.org (Adam Greenhalgh)
Date: Fri, 9 Mar 2007 11:43:45 +0000
Subject: [Xorp-hackers] RFC : xorp fea
Message-ID: <4769af410703090343y51131087k916b9ab996db19d@mail.gmail.com>

Hi folks,

Pavlin and I are looking at how refactor the fea to make it more
modular and more flexible to use. Does anyone have any ideas or
requirements ? I'm not promising any suggestions will be taken up but
ideas are welcome.

Adam


From atanu at ICSI.Berkeley.EDU  Fri Mar  9 10:00:42 2007
From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Fri, 09 Mar 2007 10:00:42 -0800
Subject: [Xorp-hackers] XORP and Multi-Topology (MT) Routing in OSPF
In-Reply-To: Message from "Jon Andersson" <jonirucoeith@gmail.com> of "Fri,
	09 Mar 2007 10:11:13 +0100." <op.towzszijra252f@ici-xp.sici.thales.no> 
Message-ID: <23591.1173463242@tigger.icir.org>

Hi,

Multi-Topology (MT) Routing in OSPF is not something that we have been
looking at.

According to the draft the association of a topology with an incoming
packet is outside its scope. It seems the first thing that you would
need to do is to find an operating system that supports multiple
forwarding tables based on the DSCP in the IP header or some other
feature, then the FEA would need to be taught how to install such an MT
route.

Apart from the FEA for all the other XORP processes the MT identifier
can be opaque. New route add, delete and replace XRLs will need to carry
this extra MT identifier, a value such as zero could be choosen for the
default topology.

The RIB already supports multiple tables, a routing protocol on startup
creates one or more tables in the RIB to which it will add routes. The
MT identifier could be added as part of the creation process. The RIB
can then use the MT identifier when a route is sent to the FEA.

If I was adding this feature to OSPF I would be inclined to make it a
configuration option to ospf4. As far as I can tell from a quick reading
of the draft the protocol hasn't really changed much. The majority of
the changes are in the MT routing table computations. At the moment
there is one routing table per area it shouldn't be too complicated to
make multiple routing table instances; it's already a separate class.

By design no changes will be required to POLICY or the CLI, all the
changes will be in the template files.

The show commands that operate on the RIB to show routing tables will
need to be enhanced to support a MT identifier argument.

     Atanu.

>>>>> "Jon" == Jon Andersson <jonirucoeith at gmail.com> writes:

    Jon> Hi, Are there any plans to support this in XORP?

    Jon> I have been looking into the possibillity of doing an
    Jon> implementation of Multi-Topology (MT) Routing in OSPF
    Jon> (draft-ietf-ospf-mt-08.txt) with XORP as the framework.

    Jon> I would like some feedback on a few design issues, mostly
    Jon> related to roadmap and overall philosophy:

    Jon> a) Should the design aim for a separate protocol (making it
    Jon> ospf4, ospf6, ospf4mt...) or configurable extensions to
    Jon> existing implementations?

    Jon> b) After a look at the XORP architecture, I have (so far)
    Jon> identified changes (apart from ospf) in RIB, CLI(!) and POLICY.

    Jon> c) My impression is theat changes to FEA might depend on chosen
    Jon> implementation. Other changes I would need to make?


    Jon> Cheers,

    Jon> Jon

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


From ashishkarpe at gmail.com  Sat Mar 10 06:38:47 2007
From: ashishkarpe at gmail.com (Ashish Karpe)
Date: Sat, 10 Mar 2007 20:08:47 +0530
Subject: [Xorp-hackers] doubt about PIM-RP election ......
Message-ID: <f87e63a0703100638h7ae71aby27f9a85c52cc1c8b@mail.gmail.com>

Hi all,
        For DF election in PIM-BIDIR we are using same RP elected by
PIM-SM.  Now we want to confirm that, will following code return
1) elected RP for that domain ??
2) Will this function work for statically configured RP.



********************************************************************************************
IN pim_rp.cc

PimRp *
RpTable::rp_find(const IPvX& group_addr)
{
.
.
.

if (best_rp == NULL) {
        best_rp = pim_rp;
        continue;
.
;
.
.}
.
.
.
}

****************************************************************************************************

If this is true then we planned to use it as the entry point for DF Election
process for bidirectional.


Thanking You In Anticipation
Ashish
Shamita
Chintamani
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20070310/562e79c1/attachment.html 

From pavlin at icir.org  Sat Mar 10 07:37:09 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Sat, 10 Mar 2007 07:37:09 -0800
Subject: [Xorp-hackers] doubt about PIM-RP election ......
In-Reply-To: Message from "Ashish Karpe" <ashishkarpe@gmail.com> of "Sat,
	10 Mar 2007 20:08:47 +0530."
	<f87e63a0703100638h7ae71aby27f9a85c52cc1c8b@mail.gmail.com> 
Message-ID: <200703101537.l2AFb9Ox083110@possum.icir.org>

>         For DF election in PIM-BIDIR we are using same RP elected by
> PIM-SM.  Now we want to confirm that, will following code return
> 1) elected RP for that domain ??
> 2) Will this function work for statically configured RP.

Yes, the RpTable::rp_find() method can be used to return the (best)
RP for a multicast group address.
And yes, it will work for static RPs as well.

Regards,
Pavlin

> 
> 
> ********************************************************************************************
> IN pim_rp.cc
> 
> PimRp *
> RpTable::rp_find(const IPvX& group_addr)
> {
> .
> .
> .
> 
> if (best_rp == NULL) {
>         best_rp = pim_rp;
>         continue;
> .
> ;
> .
> .}
> .
> .
> .
> }
> 
> ****************************************************************************************************
> 
> If this is true then we planned to use it as the entry point for DF Election
> process for bidirectional.
> 
> 
> Thanking You In Anticipation
> Ashish
> Shamita
> Chintamani
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers


From shamita1010 at gmail.com  Sat Mar 10 08:16:04 2007
From: shamita1010 at gmail.com (shamita pisal)
Date: Sat, 10 Mar 2007 21:46:04 +0530
Subject: [Xorp-hackers] Doubt about packet forwarding
Message-ID: <cb2733e40703100816r61d024fftd3988231e52e278a@mail.gmail.com>

hello,
1.We are not able to find how the data packet are forwarded in PIM SM.
2.How the packet is identified weather it is a data packet for pim sm? Where
is it processed ?
3.where are the data forwarding rules implimented??
4.We are not able to figure out flow !!! :) Please suggest the class
name/file name.

thanking you in anticipation
shamita
ashish
chintamani
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20070310/03c840ed/attachment.html 

From pavlin at icir.org  Sat Mar 10 08:22:33 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Sat, 10 Mar 2007 08:22:33 -0800
Subject: [Xorp-hackers] Doubt about packet forwarding
In-Reply-To: Message from "shamita pisal" <shamita1010@gmail.com> of "Sat,
	10 Mar 2007 21:46:04 +0530."
	<cb2733e40703100816r61d024fftd3988231e52e278a@mail.gmail.com> 
Message-ID: <200703101622.l2AGMXKC083444@possum.icir.org>

> 1.We are not able to find how the data packet are forwarded in PIM SM.
> 2.How the packet is identified weather it is a data packet for pim sm? Where
> is it processed ?
> 3.where are the data forwarding rules implimented??
> 4.We are not able to figure out flow !!! :) Please suggest the class
> name/file name.

The data packets are not forwarded by PIM-SM, but by the kernel.
I am excluding the data packets encapsulated in PIM Registers,
because those are not used in Bidir-PIM.
PIM-SM however installs (via the MFEA) the forwarding entries in the
kernel.

If you are interested in the PIM control packets however, then
PimNode::proto_recv() inside pim/pim_node.cc is the entry point, and
then follow the code :)

Regards,
Pavlin


From chintamanisw at gmail.com  Sat Mar 10 10:05:06 2007
From: chintamanisw at gmail.com (chintamani wandhre)
Date: Sat, 10 Mar 2007 23:35:06 +0530
Subject: [Xorp-hackers] Doubt about packet forwarding
In-Reply-To: <200703101622.l2AGMXKC083444@possum.icir.org>
References: <shamita1010@gmail.com>
	<cb2733e40703100816r61d024fftd3988231e52e278a@mail.gmail.com>
	<200703101622.l2AGMXKC083444@possum.icir.org>
Message-ID: <8385815b0703101005k5b04048ejd929682443936e4f@mail.gmail.com>

On 3/10/07, Pavlin Radoslavov <pavlin at icir.org> wrote:
>
> > 1.We are not able to find how the data packet are forwarded in PIM SM.
> > 2.How the packet is identified weather it is a data packet for pim sm?
> Where
> > is it processed ?
> > 3.where are the data forwarding rules implimented??
> > 4.We are not able to figure out flow !!! :) Please suggest the class
> > name/file name.
>
> The data packets are not forwarded by PIM-SM, but by the kernel.
> I am excluding the data packets encapsulated in PIM Registers,
> because those are not used in Bidir-PIM.
> PIM-SM however installs (via the MFEA) the forwarding entries in the
> kernel.
>
> If you are interested in the PIM control packets however, then
> PimNode::proto_recv() inside pim/pim_node.cc is the entry point, and
> then follow the code :)


we are not able to identify how do we by pass packet forwarding rules of
PIM-SM & use rules for PIM-Bidir which we want to implement i.e oglist for
bidir


Regards,
> Pavlin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20070310/43c1d08d/attachment.html 

From pavlin at icir.org  Sat Mar 10 10:47:55 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Sat, 10 Mar 2007 10:47:55 -0800
Subject: [Xorp-hackers] Doubt about packet forwarding
In-Reply-To: Message from "chintamani wandhre" <chintamanisw@gmail.com> 
	of "Sat, 10 Mar 2007 23:35:06 +0530."
	<8385815b0703101005k5b04048ejd929682443936e4f@mail.gmail.com> 
Message-ID: <200703101847.l2AIlt1W084420@possum.icir.org>

> we are not able to identify how do we by pass packet forwarding rules of
> PIM-SM & use rules for PIM-Bidir which we want to implement i.e oglist for
> bidir

Please have a look at PimMrt::receive_data() inside pim/pim_mrt_mfc.cc .
Despite its name, it implements the logic (as specified in the spec)
when data packet is received, but in reality it is not called per
data packet. It is called only when certain events occur.
Pay close attention when the PimMfc::update_mfc() method is called
which does the job of (re)calculating and installing the forwarding
entry.

Regards,
Pavlin


From guptalavi at gmail.com  Mon Mar 12 10:29:03 2007
From: guptalavi at gmail.com (Pallavi Gupta)
Date: Mon, 12 Mar 2007 10:29:03 -0700
Subject: [Xorp-hackers] RIP Updates
Message-ID: <22e357c80703121029r119668e3x256709304347b30a@mail.gmail.com>

Hi there,

I was wondering if maybe some could help me clarify this.
In XORP implentation of RIP, does rip send its entire routing table in
the updates ? Or does it send partial updates only?  What about
sending entire routing table in the periodic updates and only partial
routing table entries in the triggered updates ? Thanks.

Regards,
Pallavi Gupta,

-- 
"Little things make big differences in life"


From sachinutd at gmail.com  Mon Mar 12 14:43:15 2007
From: sachinutd at gmail.com (Sachin K)
Date: Mon, 12 Mar 2007 16:43:15 -0500
Subject: [Xorp-hackers] Handling LEAVE(*, G)
Message-ID: <fcfc34be0703121443j6f0e7195le8539c5ee8dec708@mail.gmail.com>

Hi all,
How XORP handles the following scenario?

                +---------------+
[A]-------|     |               |<---------->[S1]
           |-----|   MRouter|<---------->[S2]
[B]-------|     |               |<---------->[S3]
                +---------------+
1. A and B are on the same LAN and MRouter is the multicast router on that LAN.
2. A joins (S1,G) and B joins (S2, G).
3. A leaves G and sends a leave (*,G)

How does MRouter handles this (*,G) LEAVE?

Thanks,
Sachin


From oho at acm.org  Mon Mar 12 19:42:06 2007
From: oho at acm.org (Orion Hodson)
Date: Mon, 12 Mar 2007 19:42:06 -0700
Subject: [Xorp-hackers] RIP Updates
In-Reply-To: <22e357c80703121029r119668e3x256709304347b30a@mail.gmail.com>
References: <22e357c80703121029r119668e3x256709304347b30a@mail.gmail.com>
Message-ID: <22B82F28-96DC-4847-86EF-96D6CDE7EB37@acm.org>

Yes, it does triggered updates and unsolicited periodic updates.  It  
is a pretty straightforward implementation of the RIPv2 RFC.  To pre- 
empt the next question, yes, it randomizes the intervals between  
triggered updates (triggered-delay and triggered-jitter in the  
command-line) and the intervals between unsolicited updates (update- 
interval and update-jitter in the command-line).

The magic words to look for in the rip directory are 'triggered' and  
'unsolicited'.  Most of the code for dealing with these updates is in  
port.{hh,cc}.  There are slides from a design talk in the docs/rip  
directory that might be helpful.

Cheers
- Orion



On Mar 12, 2007, at 10:29 AM, Pallavi Gupta wrote:

> Hi there,
>
> I was wondering if maybe some could help me clarify this.
> In XORP implentation of RIP, does rip send its entire routing table in
> the updates ? Or does it send partial updates only?  What about
> sending entire routing table in the periodic updates and only partial
> routing table entries in the triggered updates ? Thanks.
>
> Regards,
> Pallavi Gupta,
>
> -- 
> "Little things make big differences in life"
>
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers


From pavlin at icir.org  Mon Mar 12 22:21:32 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Mon, 12 Mar 2007 22:21:32 -0700
Subject: [Xorp-hackers] Handling LEAVE(*, G)
In-Reply-To: Message from "Sachin K" <sachinutd@gmail.com> of "Mon,
	12 Mar 2007 16:43:15 CDT."
	<fcfc34be0703121443j6f0e7195le8539c5ee8dec708@mail.gmail.com> 
Message-ID: <200703130521.l2D5LWCt007054@possum.icir.org>

> How XORP handles the following scenario?
> 
>                 +---------------+
> [A]-------|     |               |<---------->[S1]
>            |-----|   MRouter|<---------->[S2]
> [B]-------|     |               |<---------->[S3]
>                 +---------------+
> 1. A and B are on the same LAN and MRouter is the multicast router on that LAN.
> 2. A joins (S1,G) and B joins (S2, G).
> 3. A leaves G and sends a leave (*,G)
> 
> How does MRouter handles this (*,G) LEAVE?

The behavior is specified in the IGMPv3 spec (RFC 3376).

Before Step 3, Mrouter is in INCLUDE (A+B) state.
The IGMPv2 Leave (*,G) in Step 3 is equivalent to the IGMPv3
TO_IN( {} ) message (see Section 7.3.2 in the IGMPv3 spec).

Then according to Section 6.4.2 the new router state and actions
are (note that I changed A->M and B->N in the original description
to avoid confusion with your example):

Router State   Report Rec'd New Router State        Actions
------------   ------------ ----------------        -------
INCLUDE (M)    TO_IN (N)    INCLUDE (M+N)           (N)=GMI
                                                    Send Q(G,M-N)

In your example, M= A+B, while N is {} (i.e., empty). Therefore, the
new router state is INCLUDE (A+B+{}) = INCLUDE(A+B).
In addition, the router will send Group-and-Source Specific Query to
G with source-list {A+B}. 
Future state of MRouter depends on the received Reports. See Section
6.4.2 in the IGMPv3 spec for complete description of the state
transitions.

Regards,
Pavlin


From sachinutd at gmail.com  Tue Mar 13 07:11:15 2007
From: sachinutd at gmail.com (Sachin K)
Date: Tue, 13 Mar 2007 09:11:15 -0500
Subject: [Xorp-hackers] IGMP version used on an interface
Message-ID: <fcfc34be0703130711n480b5150h8ef3abefab69d36@mail.gmail.com>

Thank you for the reply.

I have a multicast router with multiple interfaces, each connected to
different network. Each network uses a different version of IGMP. I am
running Linux on the router.

If the user space multicast routing daemon had to send a group
specific query on all interfaces then how to know which interface is
using what version of IGMP?

Is there any ioctl or getsockopt call to know that on linux?

Thanks,
Sachin

On 3/13/07, Pavlin Radoslavov <pavlin at icir.org> wrote:
> > How XORP handles the following scenario?
> >
> >                 +---------------+
> > [A]-------|     |               |<---------->[S1]
> >            |-----|   MRouter|<---------->[S2]
> > [B]-------|     |               |<---------->[S3]
> >                 +---------------+
> > 1. A and B are on the same LAN and MRouter is the multicast router on that LAN.
> > 2. A joins (S1,G) and B joins (S2, G).
> > 3. A leaves G and sends a leave (*,G)
> >
> > How does MRouter handles this (*,G) LEAVE?
>
> The behavior is specified in the IGMPv3 spec (RFC 3376).
>
> Before Step 3, Mrouter is in INCLUDE (A+B) state.
> The IGMPv2 Leave (*,G) in Step 3 is equivalent to the IGMPv3
> TO_IN( {} ) message (see Section 7.3.2 in the IGMPv3 spec).
>
> Then according to Section 6.4.2 the new router state and actions
> are (note that I changed A->M and B->N in the original description
> to avoid confusion with your example):
>
> Router State   Report Rec'd New Router State        Actions
> ------------   ------------ ----------------        -------
> INCLUDE (M)    TO_IN (N)    INCLUDE (M+N)           (N)=GMI
>                                                    Send Q(G,M-N)
>
> In your example, M= A+B, while N is {} (i.e., empty). Therefore, the
> new router state is INCLUDE (A+B+{}) = INCLUDE(A+B).
> In addition, the router will send Group-and-Source Specific Query to
> G with source-list {A+B}.
> Future state of MRouter depends on the received Reports. See Section
> 6.4.2 in the IGMPv3 spec for complete description of the state
> transitions.
>
> Regards,
> Pavlin
>


From pavlin at icir.org  Tue Mar 13 08:50:52 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Tue, 13 Mar 2007 08:50:52 -0700
Subject: [Xorp-hackers] IGMP version used on an interface
In-Reply-To: Message from "Sachin K" <sachinutd@gmail.com> of "Tue,
	13 Mar 2007 09:11:15 CDT."
	<fcfc34be0703130711n480b5150h8ef3abefab69d36@mail.gmail.com> 
Message-ID: <200703131550.l2DFoqTd011490@possum.icir.org>

> I have a multicast router with multiple interfaces, each connected to
> different network. Each network uses a different version of IGMP. I am
> running Linux on the router.
> 
> If the user space multicast routing daemon had to send a group
> specific query on all interfaces then how to know which interface is
> using what version of IGMP?
> 
> Is there any ioctl or getsockopt call to know that on linux?

Inside of XORP each interface is explicitly configured with the IGMP
version number so XORP itself uses that information when dealing
with each subnet. All the router-side IGMP machinery is implemented
in user space, so the kernel doesn't know the version used by XORP
on each interface.

The host-side IGMP machinery however is implemented inside the
kernel. I believe it is system-specific whether/how you can
configure or access the IGMP host version on each interface.
E.g., on Linux "cat /proc/net/igmp" will give you the Querier
version on each interface.
Hitoshi Asaeda (CC-ed in this email) should know better about the
IGMP host-side story.

Regards,
Pavlin


From asaeda at sfc.wide.ad.jp  Tue Mar 13 09:26:46 2007
From: asaeda at sfc.wide.ad.jp (Hitoshi Asaeda)
Date: Wed, 14 Mar 2007 01:26:46 +0900 (JST)
Subject: [Xorp-hackers] IGMP version used on an interface
In-Reply-To: <200703131550.l2DFoqTd011490@possum.icir.org>
References: <sachinutd@gmail.com> <200703131550.l2DFoqTd011490@possum.icir.org>
Message-ID: <20070314.012646.21591765.asaeda@sfc.wide.ad.jp>

I don't know about linux implementation, because it's not mine.
I can talk about my original igmpv3/mldv2 implementation for NetBSD
and KAME for other BSD.

In short, there is no command to know which igmp/mld version is used
on the interface, while you can statically configure igmp to v3 or mld
to v2 to disable to automatically degrade the version.
I think knowing the current version is interesting function, and I may
try to implement it if I have an opportunity.
Anyway, if you are interested in the BSD version, you may want to read
the following README files;
http://www.sfc.wide.ad.jp/~asaeda/igmpv3/README.txt
http://www.sfc.wide.ad.jp/~asaeda/mldv2/README.txt

Regards,
--
Hitoshi Asaeda


From hasso at linux.ee  Wed Mar 14 00:25:02 2007
From: hasso at linux.ee (Hasso Tepper)
Date: Wed, 14 Mar 2007 09:25:02 +0200
Subject: [Xorp-hackers] Announcing XORP Release Candidate 1.4
In-Reply-To: <89366.1172699671@tigger.icir.org>
References: <89366.1172699671@tigger.icir.org>
Message-ID: <200703140925.02462.hasso@linux.ee>

Two OSPF tests fail in Linux XORP current CVS compiled with Intel C++
compiler 9.1.

hasso at t1:~/source/xorp/ospf$ ./test_routing -v -t r8
Running: r8
****** DATABASE START ******
Router-LSA:
LS age    0 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link State ID 10.0.1.1 Advertising Router 10.0.1.1 LS sequence number 0x80000001 LS checksum 0xb171 length 36
        bit Nt false
        bit V false
        bit E false
        bit B false
        Type 2 Transit network IP address of Designated router 10.0.1.1 Routers interface address 10.0.1.1 Metric 1
Router-LSA:
LS age    0 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link State ID 10.0.1.6 Advertising Router 10.0.1.6 LS sequence number 0x80000001 LS checksum 0xaa68 length 36
        bit Nt false
        bit V false
        bit E false
        bit B true
        Type 2 Transit network IP address of Designated router 10.0.1.1 Routers interface address 10.0.1.6 Metric 1
Network-LSA:
LS age    0 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link State ID 10.0.1.1 Advertising Router 10.0.1.1 LS sequence number 0x80000001 LS checksum 0xab79 length 32
        Network Mask 0xffff0000
        Attached Router 10.0.1.1
        Attached Router 10.0.1.6
Summary-LSA:
LS age    0 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x3 Link State ID 0.0.0.0 Advertising Router 10.0.1.6 LS sequence number 0x80000001 LS checksum 0xef5b length 28
        Network Mask 0
        Metric 1
****** DATABASE END ********
[ 2007/03/14 07:19:00  TRACE test_routing:27858 OSPF +343 area_router.cc check_for_virtual_linkV2 ] Checking for virtual links Router-LSA:
LS age    0 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link State ID 10.0.1.6 Advertising Router 10.0.1.6 LS sequence number 0x80000001 LS checksum 0xaa68 length 36
        bit Nt false
        bit V false
        bit E false
        bit B true
        Type 2 Transit network IP address of Designated router 10.0.1.1 Routers interface address 10.0.1.6 Metric 1
[ 2007/03/14 07:19:00  TRACE test_routing:27858 OSPF +487 area_router.cc find_interface_address ] Find interface address
src:
Router-LSA:
LS age    0 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link State ID 10.0.1.1 Advertising Router 10.0.1.1 LS sequence number 0x80000001 LS checksum 0xb171 length 36
        bit Nt false
        bit V false
        bit E false
        bit B false
        Type 2 Transit network IP address of Designated router 10.0.1.1 Routers interface address 10.0.1.1 Metric 1
dst:
Router-LSA:
LS age    0 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link State ID 10.0.1.6 Advertising Router 10.0.1.6 LS sequence number 0x80000001 LS checksum 0xaa68 length 36
        bit Nt false
        bit V false
        bit E false
        bit B true
        Type 2 Transit network IP address of Designated router 10.0.1.1 Routers interface address 10.0.1.6 Metric 1
verify_routes:265:r8: Line number: 1293
verify_routes:266:r8: Expecting 1 routes got 0
Failed: r8
hasso at t1:~/source/xorp/ospf$

hasso at t1:~/source/xorp/ospf$ ./test_routing1.py -v -t r5V3
['r5V3']
[set_router_id]
set_router_id 0.0.0.1
[create]
create 0.0.0.0 normal
[select]
select 0.0.0.0
[replace]
replace RouterLsa V6-bit E-bit R-bit lsid 42.0.0.1 adv 0.0.0.1     p2p iid 1 nid 1 nrid 0.0.0.2 metric 1
[add]
add LinkLsa lsid 0.0.0.1 adv 0.0.0.1     link-local-address fe80:0001::1
[add]
add RouterLsa bit-B V6-bit E-bit R-bit lsid 42.0.0.1 adv 0.0.0.2     p2p iid 1 nid 1 nrid 0.0.0.1 metric 1     transit iid 20 nid 20 nrid 0.0.0.2 metric 5
[add]
add LinkLsa lsid 0.0.0.1 adv 0.0.0.2     link-local-address fe80:0001::2
[add]
add SummaryNetworkLsa lsid 42.0.0.2 adv 0.0.0.2     metric 6     IPv6Prefix 5f00:0000:c001:0200::/56
[compute]
compute 0.0.0.0
****** DATABASE START ******
Router-LSA:
LS age    0 LS type 0x2001 Link State ID 42.0.0.1 Advertising Router 0.0.0.1 LS sequence number 0x80000001 LS checksum 0 length 0
        bit Nt false
        bit W false
        bit V false
        bit E false
        bit B false
        Options 0x13 DC: 0 R: 1 N: 0 MC: 0 E: 1 V6: 1
        Type 1 Point-to-point Interface ID 1 Neighbour Interface ID 1 Neighbour Router ID 0.0.0.2 Metric 1
Link-LSA:
LS age    0 LS type 0x8 Link State ID 0.0.0.1 Advertising Router 0.0.0.1 LS sequence number 0x80000001 LS checksum 0 length 0
        Rtr Priority 0
        Options 0 DC: 0 R: 0 N: 0 MC: 0 E: 0 V6: 0
        Link-local Interface Address fe80:1::1
Router-LSA:
LS age    0 LS type 0x2001 Link State ID 42.0.0.1 Advertising Router 0.0.0.2 LS sequence number 0x80000001 LS checksum 0 length 0
        bit Nt false
        bit W false
        bit V false
        bit E false
        bit B true
        Options 0x13 DC: 0 R: 1 N: 0 MC: 0 E: 1 V6: 1
        Type 1 Point-to-point Interface ID 1 Neighbour Interface ID 1 Neighbour Router ID 0.0.0.1 Metric 1
        Type 2 Transit network Interface ID 20 Designated Router Interface ID 20 Designated Router ID 0.0.0.2 Metric 5
Link-LSA:
LS age    0 LS type 0x8 Link State ID 0.0.0.1 Advertising Router 0.0.0.2 LS sequence number 0x80000001 LS checksum 0 length 0
        Rtr Priority 48
        Options 0xb7db2a30 DC: 1 R: 1 N: 0 MC: 0 E: 0 V6: 0
        Link-local Interface Address fe80:1::2
Inter-Area-Prefix-LSA:
LS age    0 LS type 0x2003 Link State ID 42.0.0.2 Advertising Router 0.0.0.2 LS sequence number 0x80000001 LS checksum 0 length 0
        Metric 6
        IPv6Prefix Options    0 DN-bit: 0 P-bit: 0 MC-bit: 0 LA-bit: 0 NU-bit: 0 Address 5f00:0:c001:200::/56
****** DATABASE END ********
[ 2007/03/14 07:17:26  TRACE test_routing_interactive:27049 OSPF +404 area_router.cc check_for_virtual_linkV3 ] Checking for virtual links Router-LSA:
LS age    0 LS type 0x2001 Link State ID 42.0.0.1 Advertising Router 0.0.0.2 LS sequence number 0x80000001 LS checksum 0 length 0
        bit Nt false
        bit W false
        bit V false
        bit E false
        bit B true
        Options 0x13 DC: 0 R: 1 N: 0 MC: 0 E: 1 V6: 1
        Type 1 Point-to-point Interface ID 1 Neighbour Interface ID 1 Neighbour Router ID 0.0.0.1 Metric 1
        Type 2 Transit network Interface ID 20 Designated Router Interface ID 20 Designated Router ID 0.0.0.2 Metric 5
[verify_routing_table_size]
verify_routing_table_size 1
InvalidString from line 195 of test_routing_interactive.cc -> Routing table size expected 1 actual 0 [verify_routing_table_size 1]
Running: r5V3 FAILED
hasso at t1:~/source/xorp/ospf$


From atanu at ICSI.Berkeley.EDU  Wed Mar 14 09:50:14 2007
From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Wed, 14 Mar 2007 09:50:14 -0700
Subject: [Xorp-hackers] Announcing XORP Release Candidate 1.4
In-Reply-To: Message from Hasso Tepper <hasso@linux.ee> of "Wed,
	14 Mar 2007 09:25:02 +0200." <200703140925.02462.hasso@linux.ee> 
Message-ID: <87029.1173891014@tigger.icir.org>

An embedded message was scrubbed...
From: Atanu Ghosh <atanu at icir.org>
Subject: [Xorp-cvs] XORP cvs commit: xorp/ospf
Date: Wed, 14 Mar 2007 09:14:06 GMT
Size: 3416
Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20070314/cc8cf29b/attachment.mht 

From hasso at linux.ee  Thu Mar 15 01:04:59 2007
From: hasso at linux.ee (Hasso Tepper)
Date: Thu, 15 Mar 2007 10:04:59 +0200
Subject: [Xorp-hackers] Announcing XORP Release Candidate 1.4
In-Reply-To: <87029.1173891014@tigger.icir.org>
References: <87029.1173891014@tigger.icir.org>
Message-ID: <200703151004.59965.hasso@linux.ee>

Atanu Ghosh wrote:
> Could you try running the latest version of test_routing_table.cc?

Yes, that seemed to help - all OSPF tests pass now.


regards,

-- 
Hasso Tepper


From Ruke.Wang at citrix.com  Thu Mar 15 09:23:08 2007
From: Ruke.Wang at citrix.com (Ruke Wang)
Date: Thu, 15 Mar 2007 09:23:08 -0700
Subject: [Xorp-hackers] XORP CLI
Message-ID: <BCFF9826D9C4D642BA2649C98A56D3400413E0D0@SJCPEXCH01.citrite.net>

Hi there,

 

If CLI questions are not expected to this list, please either discard or
redirect me to the proper mailing list.  Thanks.

 

The XORP CLI looks quite nice and I would like to get it out for another
project.  However, I got myself lost in the way how it works with the
XRL thing when I tried to scope the work since XORP CLI is also a
process, as the other router processes and looks like every router
process handles its own CLI command suits.

 

What I need is only the CLI part, which parses the template file and
constructs the tree, then read user input/configuration files.  I would
like to get rid of the router manager, module manager, XRL ....  Anybody
can give me a hint on where to start?  I took a look at cli/test_cli.cc,
but did not figure out how to see the added commands.

 

CLI development documentation will be a great help too.

 

Thanks,

Ruke

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20070315/f6f9022f/attachment.html 

From Ruke.Wang at citrix.com  Wed Mar 14 16:03:31 2007
From: Ruke.Wang at citrix.com (Ruke Wang)
Date: Wed, 14 Mar 2007 16:03:31 -0700
Subject: [Xorp-hackers] XORP CLI
Message-ID: <BCFF9826D9C4D642BA2649C98A56D3400409EA9D@SJCPEXCH01.citrite.net>

Hi there,

 

If CLI questions are not expected to this list, please either discard or
redirect me to the proper mailing list.  Thanks.

 

The XORP CLI looks quite nice and I would like to get it out for another
project.  However, I got myself lost in the way how it works with the
XRL thing when I tried to scope the work since XORP CLI is also a
process, as the other router processes and looks like every router
process handles its own CLI command suits.

 

What I need is only the CLI part, which parses the template file and
constructs the tree, then read user input/configuration files.  I would
like to get rid of the router manager, module manager, XRL ....  Anybody
can give me a hint on where to start?  I took a look at cli/test_cli.cc,
but did not figure out how to see the added commands.

 

CLI development documentation will be a great help too.

 

Thanks,

Ruke

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20070314/ed457c55/attachment.html 

From atanu at ICSI.Berkeley.EDU  Thu Mar 15 11:42:32 2007
From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Thu, 15 Mar 2007 11:42:32 -0700
Subject: [Xorp-hackers] Announcing XORP Release Candidate 1.4
In-Reply-To: Message from Hasso Tepper <hasso@linux.ee> of "Thu,
	15 Mar 2007 10:04:59 +0200." <200703151004.59965.hasso@linux.ee> 
Message-ID: <47577.1173984152@tigger.icir.org>

>>>>> "Hasso" == Hasso Tepper <hasso at linux.ee> writes:

    Hasso> Atanu Ghosh wrote:

    >> Could you try running the latest version of test_routing_table.cc?

    Hasso> Yes, that seemed to help - all OSPF tests pass now.

OSPF has an class that holds a routing table entry, this class does not
have a copy constructor or an assignment operator (a deliberate
decision). There was a test in test_routing_table.cc that assigned a
routing table entry and verified that one of the fields had been
copied. When you reported a problem I wondered if something was going
wrong with assigning a routing table entry so I augmented the test to
verify that all fields had been copied. It's good to hear that all the
test now pass, but my change shouldn't have made any difference. I
accidentally broke some of the tests last week for about a day perhaps
thats when you did the checkout.

     Atanu.


From pavlin at icir.org  Thu Mar 15 13:32:49 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Thu, 15 Mar 2007 13:32:49 -0700
Subject: [Xorp-hackers] XORP CLI
In-Reply-To: Message from "Ruke Wang" <Ruke.Wang@citrix.com> of "Thu,
	15 Mar 2007 09:23:08 PDT."
	<BCFF9826D9C4D642BA2649C98A56D3400413E0D0@SJCPEXCH01.citrite.net>
Message-ID: <200703152032.l2FKWnNZ079366@possum.icir.org>

> If CLI questions are not expected to this list, please either discard or
> redirect me to the proper mailing list.  Thanks.
> 
>  
> 
> The XORP CLI looks quite nice and I would like to get it out for another
> project.  However, I got myself lost in the way how it works with the
> XRL thing when I tried to scope the work since XORP CLI is also a
> process, as the other router processes and looks like every router
> process handles its own CLI command suits.
> 
>  
> 
> What I need is only the CLI part, which parses the template file and
> constructs the tree, then read user input/configuration files.  I would
> like to get rid of the router manager, module manager, XRL ....  Anybody
> can give me a hint on where to start?  I took a look at cli/test_cli.cc,
> but did not figure out how to see the added commands.
> 
>  
> 
> CLI development documentation will be a great help too.

Ruke,

At the very heart of the CLI is libtecla. We have a local (slightly
modified) copy inside xorp/cli/libtecla, but it is not the most
recent version.
Libtecla provides the command editing, command-line completion, help
strings, etc.

The XORP CLI library (xorp/cli) builds on top of libtecla.
It gives the XORP-like look, adds supports for pipes, keeps
various internal data like the command tree, etc.

The CLI library is used in two ways: as an attachment to a process
(legacy stuff), and as part of xorpsh.

What you see in cli/test_cli.cc is a variation of the first method
which shouldn't be used anymore. Though, if you curious about
test_cli, then start it as a stand alone program and use
"telnet localhost 12000" to connect to it.

Xorpsh itself builds on top of libcli. It adds all the XORP CLI
commands (edit, set, etc) and the corresponding XRLs, parses the
template files, communicates with the XORP rtrmgr, etc.

Personally, if your project has nothing to do with XORP and you have
the development resources, I'd recommend to use only libtecla and
add the stuff you need on top of it.
There are lots of hacks inside libcli so it is better to avoid it.

However, it seems that you want to reuse the XORP template and
configuration mechanism hence you need to use libcli and part of
xorpsh.
In that case you might want to look at the "XORP Router Manager
Process (rtrmgr)" design document available from
http://www.xorp.org/design_docs.html .
The second part of this document is about xorpsh, but you might want
to read the whole document to get a feeling about the operational
and configuration modes in xorpsh, the interaction between xorpsh
and the rtrmgr, etc.

Note that in operational mode xorpsh invokes external programs for
each CLI operational command (i.e., no XRLs by xorpsh itself).
In configuration mode the xorpsh uses XRLs to interact with the
rtrmgr to send/receive the configuration changes, etc.
If you take the rtrmgr out of the picture (along with the module
manager which is part of it) and modify xorpsh accordingly not to
expect/communicate with the rtrmgr, then this xorpsh process will be
able to read the operational and configuration templates and execute
external commands (when in operational mode). In configuration mode
xorpsh should be able to construct/modify the configuration tree,
and then you need to add your hooks what to do with that
configuration.

Unfortunately there is no clean cut to separate xorpsh from the
rtrmgr. Please have a look at the xorpsh_SOURCES variable inside
rtrmgr/Makefile.am. It contains all xorpsh source files. The main
files to start looking at are rtrmgr/xorpsh_main.cc, rtrmgr/cli.cc
and rtrmgr/xrl_xorpsh_interface.cc. You can remove
SlaveModuleManager which is needed to monitor the state of XORP
processes and add or remove the operational commands associated with
each process.

Hopefully this will give you a starting point. Please let us know if
you have any other questions.

Regards,
Pavlin


From ashishkarpe at gmail.com  Fri Mar 16 05:12:33 2007
From: ashishkarpe at gmail.com (Ashish Karpe)
Date: Fri, 16 Mar 2007 17:42:33 +0530
Subject: [Xorp-hackers] doubt abt packet format(PIM)
Message-ID: <f87e63a0703160512q1a2d3c6q80af55cfeec39a58@mail.gmail.com>

hello,
We want to implement packet header for DF -election messages.The format is
as under:

All DF election BIDIR-PIM control messages share the common header
   below:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |PIM Ver| Type  |Subtype| Rsvd  |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               RP Address (Encoded-Unicast format)           ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Sender Metric Preference                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sender Metric                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Sub-type field  is to be implemented.But
In pim.h

Struct  pim {
.
.
.
uint8_t   pim_reserved
uint16_t pim_checksum
.
.
.}

we want to add the sub type....how do we add it without disturbing the
already existing code.
Is it possible to add that subtype in this structure or do we have to define
another structure which will be only used for DF election messages.
Also can we use the already defined flag
#define PIM_ALL_DF_ELECTION
in file pim.h. How can we use this flag for bidir DF election messages.

Thanking you in anticipation
ashish karpe
chintamani wandhre
shamita pisal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20070316/d1e7ba06/attachment.html 

From pavlin at icir.org  Fri Mar 16 12:29:06 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Fri, 16 Mar 2007 12:29:06 -0700
Subject: [Xorp-hackers] doubt abt packet format(PIM)
In-Reply-To: Message from "Ashish Karpe" <ashishkarpe@gmail.com> of "Fri,
	16 Mar 2007 17:42:33 +0530."
	<f87e63a0703160512q1a2d3c6q80af55cfeec39a58@mail.gmail.com> 
Message-ID: <200703161929.l2GJT63l095169@possum.icir.org>

> We want to implement packet header for DF -election messages.The format is
> as under:
> 
> All DF election BIDIR-PIM control messages share the common header
>    below:
> 
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |PIM Ver| Type  |Subtype| Rsvd  |           Checksum            |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |               RP Address (Encoded-Unicast format)           ...
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                   Sender Metric Preference                    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                        Sender Metric                          |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> The Sub-type field  is to be implemented.But
> In pim.h
> 
> Struct  pim {
> .
> .
> .
> uint8_t   pim_reserved
> uint16_t pim_checksum
> .
> .
> .}

Don't use "struct pim" to access the fields.
Instead, have a look at the beginning of PimVif::pim_process()
inside pim_vif.cc. In particular, check the mechanism for accessing
the Type field and use similar mechanism to access Subtype as well.
Basically, you explicitly get the second octet from the beginning of
the packet, and you extract the top 4 bits from it.

Regards,
Pavlin


> we want to add the sub type....how do we add it without disturbing the
> already existing code.
> Is it possible to add that subtype in this structure or do we have to define
> another structure which will be only used for DF election messages.
> Also can we use the already defined flag
> #define PIM_ALL_DF_ELECTION
> in file pim.h. How can we use this flag for bidir DF election messages.
> 
> Thanking you in anticipation
> ashish karpe
> chintamani wandhre
> shamita pisal
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers


From ashishkarpe at gmail.com  Sun Mar 18 14:26:32 2007
From: ashishkarpe at gmail.com (Ashish Karpe)
Date: Mon, 19 Mar 2007 02:56:32 +0530
Subject: [Xorp-hackers] error in gmake
Message-ID: <f87e63a0703181426h48fa1120na247d02179b2be9c@mail.gmail.com>

hi all,
         we are getting error in gmake !!! we made changes in pim_vif.cc/hh
!! but we are getting error  in those files(pim.h & pim_proto_register.cc )
which we haven't modified  also  those  changes  made by  us was
independent  of  file  which  are  showing  error  !!


******************************************************************************************
In pim_vif.cc


.
.
.
// modification by us

    int        pim_bidir_df_send(const IPvX& assert_source_addr,
                const IPvX& assert_group_addr,
                bool rpt_bit,
                uint32_t metric_preference,
                uint32_t metric,
                string& error_msg);

    int        pim_register_send(const IPvX& rp_addr,
                  const IPvX& source_addr,
                  const IPvX& group_addr,
                  const uint8_t *rcvbuf,
                  size_t rcvlen,
                  string& error_msg);
    int        pim_register_null_send(const IPvX& rp_addr,
                       const IPvX& source_addr,
                       const IPvX& group_addr,
                       string& error_msg);



******************************************************************************************
error :

pim_proto_register.cc: In member function 'int
PimVif::pim_register_null_send(const IPvX&, const IPvX&, const IPvX&,
std::string&)':
pim_proto_register.cc:832: error: 'struct pim' has no member named
'pim_cksum'
gmake[2]: *** [pim_proto_register.lo] Error 1
gmake[2]: Leaving directory `/root/project/pimbidir/xorp-1.3/pim'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/root/project/pimbidir/xorp-1.3'
gmake: *** [all] Error 2

*****************************************************************************************

pim.h :



#ifndef _NETINET_PIM_H_
#define _NETINET_PIM_H_

/*
 * Protocol Independent Multicast (PIM) definitions.
 * RFC 2362, June 1998.
 *
 * Written by Ahmed Helmy, USC/SGI, July 1996.
 * Modified by George Edmond Eddy (Rusty), ISI, February 1998.
 * Modified by Pavlin Radoslavov, USC/ISI, May 1998, October 2000.
 */


#ifndef _PIM_VT
#ifndef BYTE_ORDER
# error BYTE_ORDER is not defined!
#endif
#if (BYTE_ORDER != BIG_ENDIAN) && (BYTE_ORDER != LITTLE_ENDIAN)
# error BYTE_ORDER must be defined to either BIG_ENDIAN or LITTLE_ENDIAN
#endif
#endif /* ! _PIM_VT */

/*
 * PIM packet header
 */
struct pim {
#ifdef _PIM_VT
    uint8_t        pim_vt;        /* PIM version and message type    */
#else /* ! _PIM_VT   */
#if BYTE_ORDER == BIG_ENDIAN
    u_int        pim_vers:4,    /* PIM protocol version        */
            pim_type:4;    /* PIM message type        */
#endif
#if BYTE_ORDER == LITTLE_ENDIAN
    u_int        pim_type:4,    /* PIM message type        */
            pim_vers:4;    /* PIM protocol version        */
#endif
#endif /* ! _PIM_VT  */
    uint8_t        pim_reserved;    /* Reserved            */
    uint16_t    pim_cksum;    /* IP-style checksum        */
};
/* KAME-related name backward compatibility */
#define pim_ver pim_vers
#define pim_rsv pim_reserved

#ifdef _PIM_VT
#define PIM_MAKE_VT(v, t)    (0xff & (((v) << 4) | (0x0f & (t))))
#define PIM_VT_V(x)        (((x) >> 4) & 0x0f)
#define PIM_VT_T(x)        ((x) & 0x0f)
#endif /* _PIM_VT */

#define PIM_VERSION        2
#define PIM_MINLEN        8    /* PIM message min. length    */
#define PIM_REG_MINLEN    (PIM_MINLEN+20)    /* PIM Register hdr + inner
IPv4 hdr */
#define PIM6_REG_MINLEN    (PIM_MINLEN+40)    /* PIM Register hdr + inner
IPv6 hdr */

/*
 * PIM message types
 */
#define PIM_HELLO        0x0    /* PIM-SM and PIM-DM        */
#define PIM_REGISTER        0x1    /* PIM-SM only            */
#define PIM_REGISTER_STOP    0x2    /* PIM-SM only            */
#define PIM_JOIN_PRUNE        0x3    /* PIM-SM and PIM-DM        */
#define PIM_BOOTSTRAP        0x4    /* PIM-SM only            */
#define PIM_ASSERT        0x5    /* PIM-SM and PIM-DM        */
#define PIM_GRAFT        0x6    /* PIM-DM only            */
#define PIM_GRAFT_ACK        0x7    /* PIM-DM only            */
#define PIM_CAND_RP_ADV        0x8    /* PIM-SM only            */
#define PIM_ALL_DF_ELECTION    0xa    /* Bidir-PIM-SM only        */

/*
 * PIM-Register message flags
 */
#define PIM_BORDER_REGISTER 0x80000000U    /* The Border bit (host-order)
 */
#define PIM_NULL_REGISTER   0x40000000U    /* The Null-Register bit
(host-order)*/

/*
 * All-PIM-Routers IPv4 and IPv6 multicast addresses
 */
#define INADDR_ALLPIM_ROUTERS_GROUP    (uint32_t)0xe000000dU  /* 224.0.0.13*/
#define IN6ADDR_LINKLOCAL_ALLPIM_ROUTERS    "ff02::d"
#define IN6ADDR_LINKLOCAL_ALLPIM_ROUTERS_INIT                \
    {{{ 0xff, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,        \
        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x0d }}}

#endif /* _NETINET_PIM_H_ */


********************************************************************************************

In pim_proto_register.cc Error @ this line :


pim_header.pim_cksum = cksum;

********************************************************************************************

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

From ashishkarpe at gmail.com  Sun Mar 18 14:58:09 2007
From: ashishkarpe at gmail.com (Ashish Karpe)
Date: Mon, 19 Mar 2007 03:28:09 +0530
Subject: [Xorp-hackers] error in gmake
In-Reply-To: <f87e63a0703181426h48fa1120na247d02179b2be9c@mail.gmail.com>
References: <f87e63a0703181426h48fa1120na247d02179b2be9c@mail.gmail.com>
Message-ID: <f87e63a0703181458h47281182yf56f5f5eda7e51e7@mail.gmail.com>

hi all,
        sorry !!! it was my mistake i complied wrong code :(
please forgive me !!!!

On 3/19/07, Ashish Karpe <ashishkarpe at gmail.com> wrote:
>
> hi all,
>          we are getting error in gmake !!! we made changes in
> pim_vif.cc/hh !! but we are getting error  in those files(pim.h &
> pim_proto_register.cc ) which we haven't modified  also  those  changes
> made by  us was independent  of  file  which  are  showing  error  !!
>
>
>
> ******************************************************************************************
> In pim_vif.cc
>
>
> .
> .
> .
> // modification by us
>
>     int        pim_bidir_df_send(const IPvX& assert_source_addr,
>                 const IPvX& assert_group_addr,
>                 bool rpt_bit,
>                 uint32_t metric_preference,
>                 uint32_t metric,
>                 string& error_msg);
>
>     int        pim_register_send(const IPvX& rp_addr,
>                   const IPvX& source_addr,
>                   const IPvX& group_addr,
>                   const uint8_t *rcvbuf,
>                   size_t rcvlen,
>                   string& error_msg);
>     int        pim_register_null_send(const IPvX& rp_addr,
>                        const IPvX& source_addr,
>                        const IPvX& group_addr,
>                        string& error_msg);
>
>
>
>
> ******************************************************************************************
> error :
>
> pim_proto_register.cc: In member function 'int
> PimVif::pim_register_null_send(const IPvX&, const IPvX&, const IPvX&,
> std::string&)':
> pim_proto_register.cc:832: error: 'struct pim' has no member named
> 'pim_cksum'
> gmake[2]: *** [pim_proto_register.lo] Error 1
> gmake[2]: Leaving directory `/root/project/pimbidir/xorp-1.3/pim'
> gmake[1]: *** [all-recursive] Error 1
> gmake[1]: Leaving directory `/root/project/pimbidir/xorp-1.3'
> gmake: *** [all] Error 2
>
> *****************************************************************************************
>
>
> pim.h :
>
>
>
> #ifndef _NETINET_PIM_H_
> #define _NETINET_PIM_H_
>
> /*
>  * Protocol Independent Multicast (PIM) definitions.
>  * RFC 2362, June 1998.
>  *
>  * Written by Ahmed Helmy, USC/SGI, July 1996.
>  * Modified by George Edmond Eddy (Rusty), ISI, February 1998.
>  * Modified by Pavlin Radoslavov, USC/ISI, May 1998, October 2000.
>  */
>
>
> #ifndef _PIM_VT
> #ifndef BYTE_ORDER
> # error BYTE_ORDER is not defined!
> #endif
> #if (BYTE_ORDER != BIG_ENDIAN) && (BYTE_ORDER != LITTLE_ENDIAN)
> # error BYTE_ORDER must be defined to either BIG_ENDIAN or LITTLE_ENDIAN
> #endif
> #endif /* ! _PIM_VT */
>
> /*
>  * PIM packet header
>  */
> struct pim {
> #ifdef _PIM_VT
>     uint8_t        pim_vt;        /* PIM version and message type    */
> #else /* ! _PIM_VT   */
> #if BYTE_ORDER == BIG_ENDIAN
>     u_int        pim_vers:4,    /* PIM protocol version        */
>             pim_type:4;    /* PIM message type        */
> #endif
> #if BYTE_ORDER == LITTLE_ENDIAN
>     u_int        pim_type:4,    /* PIM message type        */
>             pim_vers:4;    /* PIM protocol version        */
> #endif
> #endif /* ! _PIM_VT  */
>     uint8_t        pim_reserved;    /* Reserved            */
>     uint16_t    pim_cksum;    /* IP-style checksum        */
> };
> /* KAME-related name backward compatibility */
> #define pim_ver pim_vers
> #define pim_rsv pim_reserved
>
> #ifdef _PIM_VT
> #define PIM_MAKE_VT(v, t)    (0xff & (((v) << 4) | (0x0f & (t))))
> #define PIM_VT_V(x)        (((x) >> 4) & 0x0f)
> #define PIM_VT_T(x)        ((x) & 0x0f)
> #endif /* _PIM_VT */
>
> #define PIM_VERSION        2
> #define PIM_MINLEN        8    /* PIM message min. length    */
> #define PIM_REG_MINLEN    (PIM_MINLEN+20)    /* PIM Register hdr + inner
> IPv4 hdr */
> #define PIM6_REG_MINLEN    (PIM_MINLEN+40)    /* PIM Register hdr + inner
> IPv6 hdr */
>
> /*
>  * PIM message types
>  */
> #define PIM_HELLO        0x0    /* PIM-SM and PIM-DM        */
> #define PIM_REGISTER        0x1    /* PIM-SM only            */
> #define PIM_REGISTER_STOP    0x2    /* PIM-SM only            */
> #define PIM_JOIN_PRUNE        0x3    /* PIM-SM and PIM-DM        */
> #define PIM_BOOTSTRAP        0x4    /* PIM-SM only            */
> #define PIM_ASSERT        0x5    /* PIM-SM and PIM-DM        */
> #define PIM_GRAFT        0x6    /* PIM-DM only            */
> #define PIM_GRAFT_ACK        0x7    /* PIM-DM only            */
> #define PIM_CAND_RP_ADV        0x8    /* PIM-SM only            */
> #define PIM_ALL_DF_ELECTION    0xa    /* Bidir-PIM-SM only        */
>
> /*
>  * PIM-Register message flags
>  */
> #define PIM_BORDER_REGISTER 0x80000000U    /* The Border bit
> (host-order)    */
> #define PIM_NULL_REGISTER   0x40000000U    /* The Null-Register bit
> (host-order)*/
>
> /*
>  * All-PIM-Routers IPv4 and IPv6 multicast addresses
>  */
> #define INADDR_ALLPIM_ROUTERS_GROUP    (uint32_t)0xe000000dU  /*
> 224.0.0.13 */
> #define IN6ADDR_LINKLOCAL_ALLPIM_ROUTERS    "ff02::d"
> #define IN6ADDR_LINKLOCAL_ALLPIM_ROUTERS_INIT                \
>     {{{ 0xff, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,        \
>         0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x0d }}}
>
> #endif /* _NETINET_PIM_H_ */
>
>
>
> ********************************************************************************************
>
> In pim_proto_register.cc Error @ this line :
>
>
> pim_header.pim_cksum = cksum;
>
> ********************************************************************************************
>
>
> Thank you,
> Ashish
>



-- 
-Ashish
Mobile : 9890066682
Home   : 020-65212425
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Param Vaibhavam Netum etat Swaraashtram
| Samrthaa Bhavatwaashishaa Tebhrusham
|
| || Bharat Maata Ki Jay ||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20070319/d87519d3/attachment-0001.html 

From ashishkarpe at gmail.com  Sun Mar 18 15:35:07 2007
From: ashishkarpe at gmail.com (Ashish Karpe)
Date: Mon, 19 Mar 2007 04:05:07 +0530
Subject: [Xorp-hackers] Display BIDIR_CAPABLE flag name in ethereal !!!!
Message-ID: <f87e63a0703181535v1054cee7h2d24fd89fd91e30a@mail.gmail.com>

hi all,
   we have enabled PIM_HELLO_BIDIR_CAPABLE by defining it in pim_proto.h of
value (type) 22 (as per RFC) . Also we are able to catch this bidir capable
option in ethereal !! But it shows type Unknown but its vaule is 22 which is
correct !!!
    So what should we do so that it will show PIM_HELLO_BIDIR_CAPABLE
instead of Unknown type in ethereal. It also shows  proper  name  for other
options like  Holdtime,  Lanprune Delay, DR Priority which has been defined
in same file !!!!

Thank you ,
Ashish Karpe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20070319/1c77eaf0/attachment.html 

From pavlin at icir.org  Mon Mar 19 10:26:19 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Mon, 19 Mar 2007 10:26:19 -0700
Subject: [Xorp-hackers] Display BIDIR_CAPABLE flag name in ethereal !!!!
In-Reply-To: Message from "Ashish Karpe" <ashishkarpe@gmail.com> of "Mon,
	19 Mar 2007 04:05:07 +0530."
	<f87e63a0703181535v1054cee7h2d24fd89fd91e30a@mail.gmail.com> 
Message-ID: <200703191726.l2JHQJQJ020762@possum.icir.org>

>    we have enabled PIM_HELLO_BIDIR_CAPABLE by defining it in pim_proto.h of
> value (type) 22 (as per RFC) . Also we are able to catch this bidir capable
> option in ethereal !! But it shows type Unknown but its vaule is 22 which is
> correct !!!
>     So what should we do so that it will show PIM_HELLO_BIDIR_CAPABLE
> instead of Unknown type in ethereal. It also shows  proper  name  for other
> options like  Holdtime,  Lanprune Delay, DR Priority which has been defined
> in same file !!!!

Most likely Ethereal doesn't has support for the Bidir-capable Hello
option. If you are using an older version of Ethereal check whether
the latest release supports it. If no, then you can add the support
for it and send the patch to the Ethereal folks.

Alternatively, I believe that recent versions of tcpdump have
support for that option, so if you can live without GUI then you can
use tcpdump instead.

Regards,
Pavlin


From shamita1010 at gmail.com  Wed Mar 21 07:16:25 2007
From: shamita1010 at gmail.com (shamita pisal)
Date: Wed, 21 Mar 2007 19:46:25 +0530
Subject: [Xorp-hackers] doubt abt packet format(PIM)
In-Reply-To: <200703161929.l2GJT63l095169@possum.icir.org>
References: <ashishkarpe@gmail.com>
	<f87e63a0703160512q1a2d3c6q80af55cfeec39a58@mail.gmail.com>
	<200703161929.l2GJT63l095169@possum.icir.org>
Message-ID: <cb2733e40703210716y1f681fh1addc4e34d8835d3@mail.gmail.com>

On 3/17/07, Pavlin Radoslavov <pavlin at icir.org> wrote:
>
> > We want to implement packet header for DF -election messages.The format
> is
> > as under:
> >
> > All DF election BIDIR-PIM control messages share the common header
> >    below:
> >
> >     0                   1                   2                   3
> >     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |PIM Ver| Type  |Subtype| Rsvd  |           Checksum            |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |               RP Address (Encoded-Unicast format)           ...
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                   Sender Metric Preference                    |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |                        Sender Metric                          |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> > The Sub-type field  is to be implemented.But
> > In pim.h
> >
> > Struct  pim {
> > .
> > .
> > .
> > uint8_t   pim_reserved
> > uint16_t pim_checksum
> > .
> > .
> > .}
>
> Don't use "struct pim" to access the fields.
> Instead, have a look at the beginning of PimVif::pim_process()
> inside pim_vif.cc. In particular, check the mechanism for accessing
> the Type field and use similar mechanism to access Subtype as well.
> Basically, you explicitly get the second octet from the beginning of
> the packet, and you extract the top 4 bits from it.
>
> Regards,
> Pavlin


hello,
       We have done the following changes and using those we were able to
set the version and type bit for DF election messages.  When we catch these
packets  in  the  ethereal we were able to see the values of TYPE and
VERSION fields but we were unable to see the value of subtype.
1.)        It is showing XLOG_INFO (DF_OFFER) but it is unable to show the
value in ethereal.So we are not confident as to whether the sub-type value
is set or no.




****************************************************************************************************
In pim_bidir_df.cc


int
PimVif::pim_bidir_df_send(const IPvX& src, const IPvX& dst,
         uint8_t message_type,uint8_t message_subtype , buffer_t *buffer,
         string& error_msg)
{
    ....
.......
......

    // Prepare the PIM-BIDIR messages are Multicast with TTL 1           //
to the "ALL-PIm-ROUTERS" header
    //  All DF election BIDIR-PIM control message share the
  //     common    header.

    datalen = BUFFER_DATA_SIZE(buffer);
    BUFFER_RESET_TAIL(buffer);

    pim_vt = PIM_MAKE_VT(proto_version(), message_type);

BUFFER_PUT_OCTET(pim_vt, buffer); // PIM version and message type


    switch(message_subtype){

    case DF_OFFER :
        XLOG_INFO("ash : DF_OFFER");
 BUFFER_PUT_OCTET(DF_OFFER, buffer);    // Offer + Reserved
        break;

    case DF_WINNER :
        XLOG_INFO("ash : DF_WINNER");
BUFFER_PUT_OCTET(DF_WINNER, buffer);  // Winner + Reserved
        break;

    case DF_BACKOFF :
XLOG_INFO("ash : DF_BACKOFF");
BUFFER_PUT_OCTET(DF_BACKOFF, buffer);// Backoff + Reserved         break;

    case DF_PASS    :
   XLOG_INFO("ash : DF_PASS");
   BUFFER_PUT_OCTET(DF_PASS, buffer);     // Pass +Reserved
        break;

    default :
        XLOG_INFO("ash : Default");
        BUFFER_PUT_OCTET(0xb, buffer);
        break;

}
    //    BUFFER_PUT_OCTET(DF_OFFER, buffer);

  BUFFER_PUT_HOST_16(0, buffer);        // Zero the checksum field

 // Restore the buffer to include the data

    BUFFER_RESET_TAIL(buffer);
    BUFFER_PUT_SKIP(datalen, buffer);

    //
    // Send the message
    //
    ret_value = pim_node().pim_send(vif_index(), src, dst, ttl, ip_tos,
                    is_router_alert, buffer, error_msg);

    return (ret_value);

*********************************************************************************************
pim_bidir_df.hh



/*
 * PIM-BIDIR DF election message subtypes
 */

#define DF_OFFER    0x1
#define DF_WINNER    0x2
#define DF_BACKOFF    0x3
#define DF_PASS        0x4

*********************************************************************************************

2.)Also could you please tell us where are the PIM-SM General purpose states
implemented  in  PIM-SM code.

Thanking you in anticipation,
Chintamani
Shamita
Ashish







> we want to add the sub type....how do we add it without disturbing the
> > already existing code.
> > Is it possible to add that subtype in this structure or do we have to
> define
> > another structure which will be only used for DF election messages.
> > Also can we use the already defined flag
> > #define PIM_ALL_DF_ELECTION
> > in file pim.h. How can we use this flag for bidir DF election messages.
> >
> > Thanking you in anticipation
> > ashish karpe
> > chintamani wandhre
> > shamita pisal
> > _______________________________________________
> > Xorp-hackers mailing list
> > Xorp-hackers at icir.org
> > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20070321/de0f0e5b/attachment.html 

From atanu at ICSI.Berkeley.EDU  Wed Mar 21 11:58:27 2007
From: atanu at ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Wed, 21 Mar 2007 11:58:27 -0700
Subject: [Xorp-hackers] Announcing XORP Release 1.4
Message-ID: <66492.1174503507@tigger.icir.org>

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

The major new feature with this release is:

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

In addition, this release contains numerous bug fixes.

There are still a number of non-critical bugs that we know about which
will not be addressed until the 1.5 release; these are documented in
the XORP Bugzilla database <http://www.xorp.org/bugzilla/index.cgi>.

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 are included below.

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

Release 1.4 (2007/03/20)
=========================
  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. Configuring multiple
      OSPFv3 instances is guaranteed to cause problems.

    - 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.


From ashishkarpe at gmail.com  Wed Mar 21 13:24:17 2007
From: ashishkarpe at gmail.com (Ashish Karpe)
Date: Thu, 22 Mar 2007 01:54:17 +0530
Subject: [Xorp-hackers] error in buflen_error & rcvlen_error lables !!
Message-ID: <f87e63a0703211324x176bf683l9ba75a8f297572fd@mail.gmail.com>

hi all ,

We are not able to figure out what the error is coz haven't  use
those(buflen_error & rcvlen_error) lables  !!

*****************************************************************************************************

In pim_bidir_df.cc

int
PimVif::pim_bidir_df_send(const IPvX& src, const IPvX& dst,
         uint8_t message_type,uint8_t message_subtype , buffer_t *buffer,
         string& error_msg)
{
    uint8_t pim_vt;
    uint16_t cksum;
    uint16_t cksum2 = 0;
    int ip_tos = -1;
    int ret_value;
    size_t datalen;
    int ttl = MINTTL;
    bool is_router_alert = true;

    //
    // Prepare the PIM-BIDIR messages are Multicast with TTL 1 to the
"ALL-PIm-ROUTERS" header
    //All DF election BIDIR-PIM control message share the common header.

    datalen = BUFFER_DATA_SIZE(buffer);
    BUFFER_RESET_TAIL(buffer);
    //
    pim_vt = PIM_MAKE_VT(proto_version(), message_type);
    BUFFER_PUT_OCTET(pim_vt, buffer);        // PIM version and message type

    switch(message_subtype){
    case DF_OFFER :
        XLOG_INFO("ash : DF_OFFER");
            BUFFER_PUT_OCTET(DF_OFFER, buffer);    // Offer + Reserved
        //BUFFER_PUT_HOST_16(DF_OFFER, buffer);
        break;
    case DF_WINNER :
        XLOG_INFO("ash : DF_WINNER");
            BUFFER_PUT_OCTET(DF_WINNER, buffer);    // Winner + Reserved
//        BUFFER_PUT_HOST_16(DF_WINNER, buffer);
        break;
    case DF_BACKOFF :
        XLOG_INFO("ash : DF_BACKOFF");
            BUFFER_PUT_OCTET(DF_BACKOFF, buffer);    // Backoff + Reserved
        break;
    case DF_PASS    :
        XLOG_INFO("ash : DF_PASS");
            BUFFER_PUT_OCTET(DF_PASS, buffer);    // Pass + Reserved
        break;

    default :
        XLOG_INFO("ash : Default");
        BUFFER_PUT_OCTET(0xb, buffer);
        break;

}

    BUFFER_PUT_HOST_16(0, buffer);        // Zero the checksum field


 // Restore the buffer to include the data
    BUFFER_RESET_TAIL(buffer);
    BUFFER_PUT_SKIP(datalen, buffer);

    //
    // Compute the checksum
    //
    if (is_ipv6()) {
    //
    // XXX: The checksum for IPv6 includes the IPv6 "pseudo-header"
    // as described in RFC 2460.
    //
    size_t ph_len;
    if (message_type == PIM_REGISTER)
        ph_len = PIM_REGISTER_HEADER_LENGTH;
    else
        ph_len = BUFFER_DATA_SIZE(buffer);
    cksum2 = calculate_ipv6_pseudo_header_checksum(src, dst, ph_len,
                               IPPROTO_PIM);
    }

    // XXX: The checksum for PIM_REGISTER excludes the encapsulated data
packet
    switch (message_type) {
    case PIM_REGISTER:
    cksum = INET_CKSUM(BUFFER_DATA_HEAD(buffer),
               PIM_REGISTER_HEADER_LENGTH);
    break;
    default:
    cksum = INET_CKSUM(BUFFER_DATA_HEAD(buffer), BUFFER_DATA_SIZE(buffer));
    break;
    }

    cksum = INET_CKSUM_ADD(cksum, cksum2);
    BUFFER_COPYPUT_INET_CKSUM(cksum, buffer, 2);    // XXX: the ckecksum

    //
    // Send the message
    //
    ret_value = pim_node().pim_send(vif_index(), src, dst, ttl, ip_tos,
                    is_router_alert, buffer, error_msg);

    return (ret_value);


}


/**
 * PimVif::pim__bidir_df_recv:
 * @pim_nbr: The PIM neighbor message originator (or NULL if not a
neighbor).
 * @src: The message source address.
 * @dst: The message destination address.
 * @buffer: The buffer with the message.
 *
 * Receive PIM_ASSERT message.
 *
 * Return value: %XORP_OK on success, otherwise %XORP_ERROR.
 **/
int
PimVif::pim_bidir_df_recv(const IPvX& src,const IPvX& dst,int ip_ttl,
         int ip_tos,buffer_t *buffer)
{

    uint8_t pim_vt;
    uint8_t message_type, proto_version,message_subtype;

    // Ignore my own PIM messages
//    if (pim_node().is_my_addr(src))
//            return (XORP_ERROR);

    //
    // Message length check.
    //

    if (BUFFER_DATA_SIZE(buffer) < PIM_MINLEN) {
    XLOG_WARNING("RX packet from %s to %s on vif %s: "
             "too short data field (%u bytes)",
             cstring(src), cstring(dst),
             name().c_str(),
             XORP_UINT_CAST(BUFFER_DATA_SIZE(buffer)));
    ++_pimstat_bad_length_messages;
    return (XORP_ERROR);
    }

    //
    // Parse the message
    //


    //
    // Get the message type and PIM protocol version.
    // XXX: First we need the message type to verify correctly the checksum.
    //

    BUFFER_GET_OCTET(pim_vt, buffer);
    BUFFER_GET_SKIP_REVERSE(1, buffer);        // Rewind back


proto_version = PIM_VT_V(pim_vt);


//    BUFFER_GET_OCTET(pim_vt, buffer);


    while (BUFFER_DATA_SIZE(buffer) > 0) {
    BUFFER_GET_OCTET(pim_vt, buffer);
    message_type = PIM_VT_T(pim_vt);
    switch(message_type)
    {
        case PIM_ALL_DF_ELECTION :
                    XLOG_INFO("ash :  PIM_ALL_DF_ELECTION recvd");
                    break;

        default :
                XLOG_INFO("ash : Wrong PIM_ALL_DF_ELECTION Election Recvd");
                    break;

    }


    BUFFER_GET_OCTET(message_subtype, buffer);
        switch(message_subtype)
        {
                case DF_OFFER :
                    XLOG_INFO("ash : DF_OFFER recvd");
                    break;

                case DF_WINNER :
                    XLOG_INFO("ash : DF_WINNER recvd");
                    break;

                case DF_BACKOFF :
                    XLOG_INFO("ash : DF_BACKOFF recvd");
                    break;

                case DF_PASS :
                    XLOG_INFO("ash : DF_PASS recvd");
                    break;

                default :
                    XLOG_INFO("ash : Wrong DF offers Election Recvd");
                    break;

        }
    }
        //
        // TODO: check the TTL and TOS if we are running in secure mode
        //
        UNUSED(ip_ttl);
        UNUSED(ip_tos);
#if 0
        if (ip_ttl != MINTTL) {
        XLOG_WARNING("RX %s from %s to %s on vif %s: "
                 "ip_ttl = %d instead of %d",
                 PIMTYPE2ASCII(message_type),
                 cstring(src), cstring(dst),
                 name().c_str(),
                 ip_ttl, MINTTL);
        ret_value = XORP_ERROR;
        goto ret_label;
        }
#endif // 0

    return (XORP_OK);




}

********************************************************************************************************
error :

pim_bidir_df.cc:110: error: label 'buflen_error' used but not defined
pim_bidir_df.cc: In member function 'int PimVif::pim_bidir_df_recv(const
IPvX&, const IPvX&, int, int, buffer_t*)':
pim_bidir_df.cc:286: error: label 'rcvlen_error' used but not defined
gmake[2]: *** [pim_bidir_df.lo] Error 1
gmake[2]: Leaving directory `/root/project/df/xorp-1.3/pim'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/root/project/df/xorp-1.3'
gmake: *** [all] Error 2


********************************************************************************************************
Error shown @ following lines :

Line No. 110 : BUFFER_PUT_OCTET(pim_vt, buffer);        // PIM version and
message type

Line No. 286 : BUFFER_GET_OCTET(pim_vt, buffer);

************************************************************************

Thank you,
ashish
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20070322/e3214a2e/attachment.html 

From pavlin at icir.org  Wed Mar 21 13:47:36 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Wed, 21 Mar 2007 13:47:36 -0700
Subject: [Xorp-hackers] doubt abt packet format(PIM)
In-Reply-To: Message from "shamita pisal" <shamita1010@gmail.com> of "Wed,
	21 Mar 2007 19:46:25 +0530."
	<cb2733e40703210716y1f681fh1addc4e34d8835d3@mail.gmail.com> 
Message-ID: <200703212047.l2LKlaaA002201@possum.icir.org>

>        We have done the following changes and using those we were able to
> set the version and type bit for DF election messages.  When we catch these
> packets  in  the  ethereal we were able to see the values of TYPE and
> VERSION fields but we were unable to see the value of subtype.
> 1.)        It is showing XLOG_INFO (DF_OFFER) but it is unable to show the
> value in ethereal.So we are not confident as to whether the sub-type value
> is set or no.

Your code below seems to be doing the right thing.

Look into the raw bytes on the wire (I presume Ethereal can show
them) rather than what Ethereal decodes.
If necessary, use tcpdump and again look into the raw bytes.

> 
> 
> 
> ****************************************************************************************************
> In pim_bidir_df.cc
> 
> 
> int
> PimVif::pim_bidir_df_send(const IPvX& src, const IPvX& dst,
>          uint8_t message_type,uint8_t message_subtype , buffer_t *buffer,
>          string& error_msg)
> {
>     ....
> .......
> ......
> 
>     // Prepare the PIM-BIDIR messages are Multicast with TTL 1           //
> to the "ALL-PIm-ROUTERS" header
>     //  All DF election BIDIR-PIM control message share the
>   //     common    header.
> 
>     datalen = BUFFER_DATA_SIZE(buffer);
>     BUFFER_RESET_TAIL(buffer);
> 
>     pim_vt = PIM_MAKE_VT(proto_version(), message_type);
> 
> BUFFER_PUT_OCTET(pim_vt, buffer); // PIM version and message type
> 
> 
>     switch(message_subtype){
> 
>     case DF_OFFER :
>         XLOG_INFO("ash : DF_OFFER");
>  BUFFER_PUT_OCTET(DF_OFFER, buffer);    // Offer + Reserved
>         break;
> 
>     case DF_WINNER :
>         XLOG_INFO("ash : DF_WINNER");
> BUFFER_PUT_OCTET(DF_WINNER, buffer);  // Winner + Reserved
>         break;
> 
>     case DF_BACKOFF :
> XLOG_INFO("ash : DF_BACKOFF");
> BUFFER_PUT_OCTET(DF_BACKOFF, buffer);// Backoff + Reserved         break;
> 
>     case DF_PASS    :
>    XLOG_INFO("ash : DF_PASS");
>    BUFFER_PUT_OCTET(DF_PASS, buffer);     // Pass +Reserved
>         break;
> 
>     default :
>         XLOG_INFO("ash : Default");
>         BUFFER_PUT_OCTET(0xb, buffer);
>         break;
> 
> }
>     //    BUFFER_PUT_OCTET(DF_OFFER, buffer);
> 
>   BUFFER_PUT_HOST_16(0, buffer);        // Zero the checksum field
> 
>  // Restore the buffer to include the data
> 
>     BUFFER_RESET_TAIL(buffer);
>     BUFFER_PUT_SKIP(datalen, buffer);
> 
>     //
>     // Send the message
>     //
>     ret_value = pim_node().pim_send(vif_index(), src, dst, ttl, ip_tos,
>                     is_router_alert, buffer, error_msg);
> 
>     return (ret_value);
> 
> *********************************************************************************************
> pim_bidir_df.hh
> 
> 
> 
> /*
>  * PIM-BIDIR DF election message subtypes
>  */
> 
> #define DF_OFFER    0x1
> #define DF_WINNER    0x2
> #define DF_BACKOFF    0x3
> #define DF_PASS        0x4
> 
> *********************************************************************************************
> 
> 2.)Also could you please tell us where are the PIM-SM General purpose states
> implemented  in  PIM-SM code.

Those states are non-group specific are are kept inside pim_vif.hh .
E.g., search for "effective_override_interval" and
"effective_propagation_delay" .
Note that some of the state is computed on-the-fly when it is
needed.

Regards,
Pavlin


From pavlin at icir.org  Wed Mar 21 13:48:54 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Wed, 21 Mar 2007 13:48:54 -0700
Subject: [Xorp-hackers] error in buflen_error & rcvlen_error lables !!
In-Reply-To: Message from "Ashish Karpe" <ashishkarpe@gmail.com> of "Thu,
	22 Mar 2007 01:54:17 +0530."
	<f87e63a0703211324x176bf683l9ba75a8f297572fd@mail.gmail.com> 
Message-ID: <200703212048.l2LKmsDt002225@possum.icir.org>

> We are not able to figure out what the error is coz haven't  use
> those(buflen_error & rcvlen_error) lables  !!

Those labels are legacy stuff and should disappear in the future.
For the time being check the rest of the PIM code for examples how
to use them.

Regards,
Pavlin


From priyanka_swd at yahoo.com  Mon Mar 26 02:04:21 2007
From: priyanka_swd at yahoo.com (Priyanka Sharma)
Date: Mon, 26 Mar 2007 02:04:21 -0700 (PDT)
Subject: [Xorp-hackers] regarding routing multimedia traffic through XORP
Message-ID: <705841.10120.qm@web37912.mail.mud.yahoo.com>

Hello everyone,

What support does XORP specifically have for routing
multimedia traffic?  I need to route the traffic based
on some QoS factors. How do I do this through XORP?
Kindly give me the clue.

thanks
priyanka 


 
____________________________________________________________________________________
No need to miss a message. Get email on-the-go 
with Yahoo! Mail for Mobile. Get started.
http://mobile.yahoo.com/mail 


From t.schooley at cs.ucl.ac.uk  Mon Mar 26 11:29:23 2007
From: t.schooley at cs.ucl.ac.uk (Tim Schooley)
Date: Mon, 26 Mar 2007 19:29:23 +0100
Subject: [Xorp-hackers] Patch for TCP over XRL fixes + libcomm api changes
Message-ID: <46081103.1090207@cs.ucl.ac.uk>

Hi all,

Please find attached a patch for the current Xorp CVS root, with the 
following notable changes:

- TCP over XRL
     - Added a few new functions to the TCP socket{4,6} XRL interfaces:
       tcp_listen and {tcp,udp}_open. These allow more atomic operations
       for socket setup.
     - Finished off the TCP relay code within fea/xrl_socket_*, and
       added test code for it (see fea/test_xrl_sockets4_tcp.*). Updated
       Jamfile and Makefile.am accordingly.
- libcomm
     - Modified the libcomm api, found in libcomm/comm_api.h. Binding a
       socket with comm_bind_tcp no longer implicitly call listen. This
       is now done explicitly in comm_listen. All code affected by this
       change within the Xorp source tree has also been updated.

The patch has been tested on Linux (2.6), and FreeBSD 6.1-RELEASE.

To apply the patch, place it in the root directory of the Xorp source, 
patch with -p0, chmod 755 fea/test_xrl_sockets4_tcp.sh, bootstrap, 
configure, and compile. The patch can also be found at 
http://midget.evilbyte.org/fea_xrl_socket_tcp_patch_03-26-07.diff

I welcome all comments/concerns/criticism! And if anyone could test this 
on windows, I'd be most grateful.

Once I get CVS access, I should be committing this code to the 
repository, along with any required changes that might be pointed out. I 
should imagine a fair number of changes will be needed in 3rd party code 
that uses libcomm, although the changes will be tiny.

Kind regards,

Tim
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: fea_xrl_socket_tcp_patch_03-26-07.diff
Url: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20070326/54b7ffa1/attachment-0001.ksh 

From pavlin at icir.org  Mon Mar 26 14:13:32 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Mon, 26 Mar 2007 14:13:32 -0700
Subject: [Xorp-hackers] regarding routing multimedia traffic through XORP
In-Reply-To: Message from Priyanka Sharma <priyanka_swd@yahoo.com> of "Mon,
	26 Mar 2007 02:04:21 PDT."
	<705841.10120.qm@web37912.mail.mud.yahoo.com> 
Message-ID: <200703262113.l2QLDWm3088323@possum.icir.org>

> What support does XORP specifically have for routing
> multimedia traffic?  I need to route the traffic based
> on some QoS factors. How do I do this through XORP?
> Kindly give me the clue.

No, currently XORP doesn't have QoS support. Within the context of
multicast, it implements IGMP/MLD and PIM-SM so basically you get
just the multicast routing/forwarding.
If the kernel has QoS support, you might be able to do the QoS
configuration outside of XORP, but I haven't looked into that
whether it will really work.

What QoS multicast-related support are you looking in particular
(e.g., RFC number or Internet Draft name)?

Regards,
Pavlin


From shamita1010 at gmail.com  Wed Mar 28 07:48:51 2007
From: shamita1010 at gmail.com (shamita pisal)
Date: Wed, 28 Mar 2007 20:18:51 +0530
Subject: [Xorp-hackers] doubt regarding RP
Message-ID: <cb2733e40703280748y12b5160g2769deaa8c89fbb@mail.gmail.com>

hi,

We are going to use the pim-sm elected  RP  as  RPA for Pim-Bidir .The RPA
is to be send in the form of ENCODED_UNICAST_ADDRESS in the Pim-Bidir
message packet.

We tried to use PimRp * RpTable::rp_find() function which returns  best_rp
but the  return  type does not match  the  ENCODED_UNICAST_ADDRESS.

Colud you please tell us how to go about it.

Thanking you in anticipation,
Ashish Karpe
Chintamani Wandhre
Shamita Pisal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20070328/46b83c34/attachment.html 

From pavlin at icir.org  Wed Mar 28 12:58:54 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Wed, 28 Mar 2007 12:58:54 -0700
Subject: [Xorp-hackers] doubt regarding RP
In-Reply-To: Message from "shamita pisal" <shamita1010@gmail.com> of "Wed,
	28 Mar 2007 20:18:51 +0530."
	<cb2733e40703280748y12b5160g2769deaa8c89fbb@mail.gmail.com> 
Message-ID: <200703281958.l2SJwskx063812@possum.icir.org>

> We are going to use the pim-sm elected  RP  as  RPA for Pim-Bidir .The RPA
> is to be send in the form of ENCODED_UNICAST_ADDRESS in the Pim-Bidir
> message packet.
> 
> We tried to use PimRp * RpTable::rp_find() function which returns  best_rp
> but the  return  type does not match  the  ENCODED_UNICAST_ADDRESS.
> 
> Colud you please tell us how to go about it.

How did you configure the CandRP set? Did you use static Cand-RPs or
did you use the Bootstrap mechanism.
In either case, make sure that the "show pim rps" output is same
for all XORP routers.

Then based on this output calculate by hand the correct address of
the RP for the particular multicast group.

Finally, print both values: the output of the rp_find() and the
ENCODED_UNICAST_ADDRESS. This will tell you which value is wrong.

Regards,
Pavlin

> 
> Thanking you in anticipation,
> Ashish Karpe
> Chintamani Wandhre
> Shamita Pisal
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers


From ashishkarpe at gmail.com  Thu Mar 29 08:01:53 2007
From: ashishkarpe at gmail.com (Ashish Karpe)
Date: Thu, 29 Mar 2007 20:31:53 +0530
Subject: [Xorp-hackers] (no subject)
Message-ID: <f87e63a0703290801g2039d662x43e98e552bf29326@mail.gmail.com>

We are currently implementing the state summerization macros for PIM-Bidir

1.olist(G) =
       RPF_interface(RPA(G)) (+) joins(G) (+) pim_include(G)

code:
const Mifset&
PimMre::bidir_olist_wc() const
{
    static Mifset mifs;

    if (! (is_wc() ) {
    mifs.reset();
    return (mifs);
    }

    mifs = joins_wc_bidir();
    mifs |= pim_include_wc_bidir();


   //    TODO : here we have to get  rpf_interface(RPA(G))..can we use the
PimMre::rpf_interface_rp() to return RPF_interface(RP(G)) i.e rpf interface
for that group .????


    return (mifs);
}

2.pim_include(G) =
       { all interfaces I such that:
         I_am_DF(RPA(G),I) AND  local_receiver_include(G,I) }


//todo: here we want to return a static DF(hard-coded IP address) which will
be  used for the time being.Could you suggest how it can be done??


code:
const Mifset&
PimMre::pim_include_wc_bidir() const
{
    static Mifset mifs;

    mifs = i_am_df();
    mifs &= local_receiver_include_wc();

    return (mifs);
}


3.joins(G) =
       { all interfaces I such that
         I_am_DF(RPA(G),I) AND
         DownstreamJPState(G,I) is either Joined or PrunePending }

code:
const Mifset&
PimMre::joins_wc_bidir() const
{
    static Mifset mifs;
    const PimMre *pim_mre_wc;

    if (is_wc()) {
    pim_mre_wc = this;
    } else {
    pim_mre_wc = wc_entry();
    if (pim_mre_wc == NULL) {
        mifs.reset();
        return (mifs);
    }
    }


Please validate us,

Thanking you in anticipation,
Ashish Karpe
Chintamani Wandhre
Shamita Pisal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20070329/bed8b54d/attachment.html 

From pavlin at icir.org  Thu Mar 29 10:43:10 2007
From: pavlin at icir.org (Pavlin Radoslavov)
Date: Thu, 29 Mar 2007 10:43:10 -0700
Subject: [Xorp-hackers] (no subject)
In-Reply-To: Message from "Ashish Karpe" <ashishkarpe@gmail.com> of "Thu,
	29 Mar 2007 20:31:53 +0530."
	<f87e63a0703290801g2039d662x43e98e552bf29326@mail.gmail.com> 
Message-ID: <200703291743.l2THhAkY098912@possum.icir.org>

> 1.olist(G) =
>        RPF_interface(RPA(G)) (+) joins(G) (+) pim_include(G)
> 
> code:
> const Mifset&
> PimMre::bidir_olist_wc() const
> {
>     static Mifset mifs;
> 
>     if (! (is_wc() ) {
>     mifs.reset();
>     return (mifs);
>     }
> 
>     mifs = joins_wc_bidir();
>     mifs |= pim_include_wc_bidir();
> 
> 
>    //    TODO : here we have to get  rpf_interface(RPA(G))..can we use the
> PimMre::rpf_interface_rp() to return RPF_interface(RP(G)) i.e rpf interface
> for that group .????
> 
> 
>     return (mifs);
> }

Yes, this looks right.
For calculating the RPF_interface(RPA(G)) you can use
PimMre::rpf_interface_rp(), but make sure that you validate it
first. E.g.,

    uint32_t rpf_interface = rpf_interface_rp();

    if (rpf_interface != Vif::VIF_INDEX_INVALID) {
        mifs.set(rpf_interface);
    }

> 2.pim_include(G) =
>        { all interfaces I such that:
>          I_am_DF(RPA(G),I) AND  local_receiver_include(G,I) }
> 
> 
> //todo: here we want to return a static DF(hard-coded IP address) which will
> be  used for the time being.Could you suggest how it can be done??
> 
> 
> code:
> const Mifset&
> PimMre::pim_include_wc_bidir() const
> {
>     static Mifset mifs;
> 
>     mifs = i_am_df();
>     mifs &= local_receiver_include_wc();
> 
>     return (mifs);
> }

This also looks right. If however it is suppose to be called only
for (*,G) entries, then it will be safer it you test this as in the
first example. E.g.:

    if (! (is_wc() ) {
        mifs.reset();
        return (mifs);
    }


> 3.joins(G) =
>        { all interfaces I such that
>          I_am_DF(RPA(G),I) AND
>          DownstreamJPState(G,I) is either Joined or PrunePending }
> 
> code:
> const Mifset&
> PimMre::joins_wc_bidir() const
> {
>     static Mifset mifs;
>     const PimMre *pim_mre_wc;
> 
>     if (is_wc()) {
>     pim_mre_wc = this;
>     } else {
>     pim_mre_wc = wc_entry();
>     if (pim_mre_wc == NULL) {
>         mifs.reset();
>         return (mifs);
>     }
>     }

This one seems unfinished. It looks like you have mastered the art
of translating the Bidir spec macros into real code so you should be
able to complete it on your own :)
As a hint, you can use methods PimMre::downstream_join_state() and
PimMre::downstream_prune_pending_state() to get the set of
interfaces that are in Joined and PrunePending state respectively.

Regards,
Pavlin


> Please validate us,
> 
> Thanking you in anticipation,
> Ashish Karpe
> Chintamani Wandhre
> Shamita Pisal
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers