From bms at incunabulum.net  Thu Jul  2 03:35:39 2009
From: bms at incunabulum.net (Bruce Simpson)
Date: Thu, 02 Jul 2009 11:35:39 +0100
Subject: [Xorp-hackers] Fix for PIM task list hang
In-Reply-To: <4A4A8AD9.2020107@candelatech.com>
References: <4A4A8AD9.2020107@candelatech.com>
Message-ID: <4A4C8D7B.9010108@incunabulum.net>

Ben,

It sounds like you've found a real bug here.

Have you managed to get any feedback from Pavlin on this patch? He 
probably knows the PIM-SM code better than anyone else.

Ben Greear wrote:
> On some error conditions related to interface removal, the PIM 
> callbacks would
> not handle the next task, and so nothing would ever look at the task 
> queue
> again, effectively hanging the multicast routing daemon. 

Unfortunately this can't go in until the community branch re-opens, the 
commented-out XLOG macros probably need to get reintroduced as warnings 
just to be conservative (and tidy).

thanks
BMS


From greearb at candelatech.com  Thu Jul  2 08:06:55 2009
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 02 Jul 2009 08:06:55 -0700
Subject: [Xorp-hackers] Fix for PIM task list hang
In-Reply-To: <4A4C8D7B.9010108@incunabulum.net>
References: <4A4A8AD9.2020107@candelatech.com>
	<4A4C8D7B.9010108@incunabulum.net>
Message-ID: <4A4CCD0F.1020908@candelatech.com>

Bruce Simpson wrote:
> Ben,
>
> It sounds like you've found a real bug here.
>
> Have you managed to get any feedback from Pavlin on this patch? He 
> probably knows the PIM-SM code better than anyone else.
>
> Ben Greear wrote:
>> On some error conditions related to interface removal, the PIM 
>> callbacks would
>> not handle the next task, and so nothing would ever look at the task 
>> queue
>> again, effectively hanging the multicast routing daemon. 
>
> Unfortunately this can't go in until the community branch re-opens, 
> the commented-out XLOG macros probably need to get reintroduced as 
> warnings just to be conservative (and tidy).
>
> thanks
> BMS
I've received no other feedback.    When the community branch opens, 
I'll make a push to clean up my patch set and
try to get this and others accepted upstream if the maintainers are willing.

Thanks,
Ben

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



From greearb at candelatech.com  Tue Jul  7 16:29:08 2009
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 07 Jul 2009 16:29:08 -0700
Subject: [Xorp-hackers] OLSR seems to be mostly working, but no subnet routes
Message-ID: <4A53DA44.70408@candelatech.com>

I'm doing some testing with OLSR (plus my hacks to make it work with
multiple router tables and multiple instances of xorp).

I thought it was working previously, but I wasn't paying close enough
attention.  It is adding routes to individual interfaces, but no subnet routes,
so traffic won't actually flow across my network.

A diagram of my network is at:
http://www.candelatech.com/oss/olsr_diag.pdf

The routes for router 3 are:

10.2.2.2 via 10.2.3.2 dev 2.3.3  proto xorp  metric 5 notify
10.1.2.2 via 10.2.3.2 dev 2.3.3  proto xorp  metric 5 notify
10.1.2.1 via 10.1.3.1 dev 1.3.3  proto xorp  metric 5 notify
10.2.3.2 via 10.2.3.2 dev 2.3.3  proto xorp  metric 5 notify
10.1.3.1 via 10.1.3.1 dev 1.3.3  proto xorp  metric 5 notify
10.1.1.1 via 10.1.3.1 dev 1.3.3  proto xorp  metric 5 notify
10.2.3.0/24 dev 2.3.3  scope link
10.1.3.0/24 dev 1.3.3  scope link
10.3.3.0/24 dev br3  scope link
unreachable default  proto xorp  metric 1 notify
fe80::/64 dev 2.3.3  metric 1024  mtu 1500 advmss 1440 hoplimit 4294967295
unreachable default dev lo  metric 1024  error -101 mtu 16436 advmss 16376 hoplimit 4294967295


I was assuming that OLSR would be sharing subnet routes for the subnets directly connected
to remote OLSR routers, and not just the interface IP routes.


My config for router 3 is below.  Others are similar:

root at nehalem# show
     protocols {
         olsr4 {
             main-address: 10.3.3.3
             interface br3 {
                 vif br3 {
                     address 10.3.3.3 {
                     }
                 }
             }
             interface "1.3.3" {
                 vif "1.3.3" {
                     address 10.1.3.3 {
                         interface-cost: 2
                     }
                 }
             }
             interface "2.3.3" {
                 vif "2.3.3" {
                     address 10.2.3.3 {
                         interface-cost: 2
                     }
                 }
             }
         }
         static {
             interface-route 0.0.0.0/0 {
                 next-hop-interface: "my_discard"
                 next-hop-vif: "my_discard"
             }
         }
     }
     fea {
         unicast-forwarding4 {
             table-id: 10003
         }
     }
     interfaces {
         interface "my_discard" {
             unreachable: true
             vif "my_discard" {
             }
         }
         interface br3 {
             vif br3 {
                 address 10.3.3.3 {
                     prefix-length: 24
                 }
             }
         }
         interface "1.3.3" {
             vif "1.3.3" {
                 address 10.1.3.3 {
                     prefix-length: 24
                 }
             }
         }
         interface "2.3.3" {
             vif "2.3.3" {
                 address 10.2.3.3 {
                     prefix-length: 24
                 }
             }
         }
     }

Thanks,
Ben

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


From bms at incunabulum.net  Wed Jul  8 07:54:21 2009
From: bms at incunabulum.net (Bruce Simpson)
Date: Wed, 08 Jul 2009 15:54:21 +0100
Subject: [Xorp-hackers] OLSR seems to be mostly working,
 but no subnet routes
In-Reply-To: <4A53DA44.70408@candelatech.com>
References: <4A53DA44.70408@candelatech.com>
Message-ID: <4A54B31D.9090200@incunabulum.net>

Ben Greear wrote:
> I'm doing some testing with OLSR (plus my hacks to make it work with
> multiple router tables and multiple instances of xorp).
>
> I thought it was working previously, but I wasn't paying close enough
> attention.  It is adding routes to individual interfaces, but no subnet routes,
> so traffic won't actually flow across my network.
>   

Off the top of my head, this would be by design -- OLSR doesn't add 
subnet routes for interfaces, as it's a peer-to-peer protocol -- unless 
you explicitly configured an HNA advertisement somewhere. It doesn't do 
any kind of auto summaries or anything like that. It's been a while 
since I wrote that code, though.

Are you sure the regression tests continue to run OK with your changes? 
Some of them are quite detailed and incomplete (it can be difficult to 
make sure the timings are right, and the OLSR tests would often fail on 
slow or old machines due to timer aliasing). But HNA should get tested 
in there.

The only thing that multiple interfaces would turn on in the protocol is 
MID. Subnet routes never appear in OLSR unless explicitly advertised in 
HNA messages.

cheers
BMS
> A diagram of my network is at:
> http://www.candelatech.com/oss/olsr_diag.pdf
>
> The routes for router 3 are:
>
> 10.2.2.2 via 10.2.3.2 dev 2.3.3  proto xorp  metric 5 notify
> 10.1.2.2 via 10.2.3.2 dev 2.3.3  proto xorp  metric 5 notify
> 10.1.2.1 via 10.1.3.1 dev 1.3.3  proto xorp  metric 5 notify
> 10.2.3.2 via 10.2.3.2 dev 2.3.3  proto xorp  metric 5 notify
> 10.1.3.1 via 10.1.3.1 dev 1.3.3  proto xorp  metric 5 notify
> 10.1.1.1 via 10.1.3.1 dev 1.3.3  proto xorp  metric 5 notify
> 10.2.3.0/24 dev 2.3.3  scope link
> 10.1.3.0/24 dev 1.3.3  scope link
> 10.3.3.0/24 dev br3  scope link
> unreachable default  proto xorp  metric 1 notify
> fe80::/64 dev 2.3.3  metric 1024  mtu 1500 advmss 1440 hoplimit 4294967295
> unreachable default dev lo  metric 1024  error -101 mtu 16436 advmss 16376 hoplimit 4294967295
>
>
> I was assuming that OLSR would be sharing subnet routes for the subnets directly connected
> to remote OLSR routers, and not just the interface IP routes.
>
>
> My config for router 3 is below.  Others are similar:
>
> root at nehalem# show
>      protocols {
>          olsr4 {
>              main-address: 10.3.3.3
>              interface br3 {
>                  vif br3 {
>                      address 10.3.3.3 {
>                      }
>                  }
>              }
>              interface "1.3.3" {
>                  vif "1.3.3" {
>                      address 10.1.3.3 {
>                          interface-cost: 2
>                      }
>                  }
>              }
>              interface "2.3.3" {
>                  vif "2.3.3" {
>                      address 10.2.3.3 {
>                          interface-cost: 2
>                      }
>                  }
>              }
>          }
>          static {
>              interface-route 0.0.0.0/0 {
>                  next-hop-interface: "my_discard"
>                  next-hop-vif: "my_discard"
>              }
>          }
>      }
>      fea {
>          unicast-forwarding4 {
>              table-id: 10003
>          }
>      }
>      interfaces {
>          interface "my_discard" {
>              unreachable: true
>              vif "my_discard" {
>              }
>          }
>          interface br3 {
>              vif br3 {
>                  address 10.3.3.3 {
>                      prefix-length: 24
>                  }
>              }
>          }
>          interface "1.3.3" {
>              vif "1.3.3" {
>                  address 10.1.3.3 {
>                      prefix-length: 24
>                  }
>              }
>          }
>          interface "2.3.3" {
>              vif "2.3.3" {
>                  address 10.2.3.3 {
>                      prefix-length: 24
>                  }
>              }
>          }
>      }
>
> Thanks,
> Ben
>
>   


From greearb at candelatech.com  Wed Jul  8 09:54:19 2009
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 08 Jul 2009 09:54:19 -0700
Subject: [Xorp-hackers] OLSR seems to be mostly working,
 but no subnet routes
In-Reply-To: <4A54B31D.9090200@incunabulum.net>
References: <4A53DA44.70408@candelatech.com> <4A54B31D.9090200@incunabulum.net>
Message-ID: <4A54CF3B.8020309@candelatech.com>

Bruce Simpson wrote:
> Ben Greear wrote:
>> I'm doing some testing with OLSR (plus my hacks to make it work with
>> multiple router tables and multiple instances of xorp).
>>
>> I thought it was working previously, but I wasn't paying close enough
>> attention.  It is adding routes to individual interfaces, but no 
>> subnet routes,
>> so traffic won't actually flow across my network.
>>   
>
> Off the top of my head, this would be by design -- OLSR doesn't add 
> subnet routes for interfaces, as it's a peer-to-peer protocol -- 
> unless you explicitly configured an HNA advertisement somewhere. It 
> doesn't do any kind of auto summaries or anything like that. It's been 
> a while since I wrote that code, though.
>
> Are you sure the regression tests continue to run OK with your 
> changes? Some of them are quite detailed and incomplete (it can be 
> difficult to make sure the timings are right, and the OLSR tests would 
> often fail on slow or old machines due to timer aliasing). But HNA 
> should get tested in there.
>
> The only thing that multiple interfaces would turn on in the protocol 
> is MID. Subnet routes never appear in OLSR unless explicitly 
> advertised in HNA messages.
Looks like I need to figure out how to do this HNA thing then.  It 
doesn't do me so much good to talk
to just routers...I really want to talk to systems connected to them, 
thus the need for somehow propagating
subnet routes.

Ben

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



From bms at incunabulum.net  Thu Jul  9 03:14:20 2009
From: bms at incunabulum.net (Bruce Simpson)
Date: Thu, 09 Jul 2009 11:14:20 +0100
Subject: [Xorp-hackers] OLSR seems to be mostly working,
 but no subnet routes
In-Reply-To: <4A54CF3B.8020309@candelatech.com>
References: <4A53DA44.70408@candelatech.com> <4A54B31D.9090200@incunabulum.net>
	<4A54CF3B.8020309@candelatech.com>
Message-ID: <4A55C2FC.4070004@incunabulum.net>

Ben Greear wrote:
> Looks like I need to figure out how to do this HNA thing then.  It 
> doesn't do me so much good to talk
> to just routers...I really want to talk to systems connected to them, 
> thus the need for somehow propagating
> subnet routes. 

Redistributing routes, from another XORP protocol into OLSR, using 
policies, will redistribute them as HNA routes.

cheerss
BMS


From greearb at candelatech.com  Thu Jul  9 08:26:18 2009
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 09 Jul 2009 08:26:18 -0700
Subject: [Xorp-hackers] OLSR seems to be mostly working,
 but no subnet routes
In-Reply-To: <4A55C2FC.4070004@incunabulum.net>
References: <4A53DA44.70408@candelatech.com> <4A54B31D.9090200@incunabulum.net>
	<4A54CF3B.8020309@candelatech.com>
	<4A55C2FC.4070004@incunabulum.net>
Message-ID: <4A560C1A.5080002@candelatech.com>

Bruce Simpson wrote:
> Ben Greear wrote:
>> Looks like I need to figure out how to do this HNA thing then.  It 
>> doesn't do me so much good to talk
>> to just routers...I really want to talk to systems connected to them, 
>> thus the need for somehow propagating
>> subnet routes. 
>
> Redistributing routes, from another XORP protocol into OLSR, using 
> policies, will redistribute them as HNA routes.
Any idea how to do this with normal subnet routes?   I don't even think 
Xorp creates these, though it can certainly
read and display them.

Thanks,
Ben

>
> cheerss
> BMS


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



From greearb at candelatech.com  Thu Jul  9 10:12:46 2009
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 09 Jul 2009 10:12:46 -0700
Subject: [Xorp-hackers] OLSR seems to be mostly working,
 but no subnet routes
In-Reply-To: <4A560C1A.5080002@candelatech.com>
References: <4A53DA44.70408@candelatech.com>
	<4A54B31D.9090200@incunabulum.net>	<4A54CF3B.8020309@candelatech.com>	<4A55C2FC.4070004@incunabulum.net>
	<4A560C1A.5080002@candelatech.com>
Message-ID: <4A56250E.1070706@candelatech.com>

On 07/09/2009 08:26 AM, Ben Greear wrote:
> Bruce Simpson wrote:
>> Ben Greear wrote:
>>> Looks like I need to figure out how to do this HNA thing then.  It
>>> doesn't do me so much good to talk
>>> to just routers...I really want to talk to systems connected to them,
>>> thus the need for somehow propagating
>>> subnet routes.
>> Redistributing routes, from another XORP protocol into OLSR, using
>> policies, will redistribute them as HNA routes.
> Any idea how to do this with normal subnet routes?   I don't even think
> Xorp creates these, though it can certainly
> read and display them.

This seems to work:

policy {
     policy-statement static-to-olsr {
         term export {
             from {
                 protocol: "static"
             }
             then {
                 metric: 0
             }
         }
     }

     policy-statement connected-to-olsr {
         term export {
             from {
                 protocol: "connected"
             }
             then {
                 metric: 0
             }
         }
     }
}

     olsr4 {
         /* Redistribute static routes */
         export: "static-to-olsr,connected-to-olsr"
         main-address: 10.2.2.2
...

Thanks!
Ben


>
> Thanks,
> Ben
>
>> cheerss
>> BMS
>
>


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


From mkaddoura at atcorp.com  Wed Jul 15 11:41:17 2009
From: mkaddoura at atcorp.com (Maher Kaddoura)
Date: Wed, 15 Jul 2009 13:41:17 -0500
Subject: [Xorp-hackers] dynamic BGP peering
Message-ID: <704B16EB878B46479C0ABD64D7807332@Coho>

Hi,

I am trying to add peers to BGP dynamically using the XRL functions.

I am using the flowing two calls: Send_add_peer & send_enable_peer.

The calls are working and I can see that the peers are establishing
communication using: Show bgp peers detail 

However they are not sending update messages. In the config.boot file I have
initialize the local bgp to export rip routes, but when I add new peers they
are not exporting the rip routes. 

I am assuming I need to enable export policy on the new peers using policy
send_export but not sure. Also, I do not know how to enable it using
send_export. 


Can someone please let me know what calls I need to use to make the new
peers exchange update messages (for example export rip routes)?  An example
of the calls would be very helpful. 


Thanks,

Maher




From bms at incunabulum.net  Wed Jul 15 17:00:29 2009
From: bms at incunabulum.net (Bruce Simpson)
Date: Thu, 16 Jul 2009 01:00:29 +0100
Subject: [Xorp-hackers] dynamic BGP peering
In-Reply-To: <704B16EB878B46479C0ABD64D7807332@Coho>
References: <704B16EB878B46479C0ABD64D7807332@Coho>
Message-ID: <4A5E6D9D.9050404@incunabulum.net>

Hi Maher,

First places I'd start looking:
    Are you able to statically configure at least one end of the peering?
    Is the BGP session being opened at TCP level (i.e. are sockets 
coming up, do SYN packets flow) ?
    I'd also check the AS settings -- are these peers in the same AS, or 
a different AS?

Maher Kaddoura wrote:
> ...
> Can someone please let me know what calls I need to use to make the new
> peers exchange update messages (for example export rip routes)?  An example
> of the calls would be very helpful. 
>   

The way to learn what BGP is doing is to follow what the Router Manager 
does when setting up a BGP peering, after the xorpsh has performed a 
commit. By enabling the debugging log statements (see configure for now) 
you should be able to do that.


cheers,
BMS


From yuzhijun263 at sina.com  Thu Jul 16 08:52:37 2009
From: yuzhijun263 at sina.com (yuzhijun263)
Date: Thu, 16 Jul 2009 23:52:37 +0800
Subject: [Xorp-hackers] Question about templates
References: <200907161628071651545@sina.com>, <200907161838038121021@sina.com>
Message-ID: <200907162352371715409@sina.com>

Hello!
I'm doing some test about my own protocol.But there are some questions about templates.

My template:
protocols {
test {
targetname: txt = "test";
test1: i32;
}
}
protocols {
test {
%help: short "Configure test";
%modinfo: provides test;
%modinfo: depends rib;
%modinfo: depends policy;
targetname {
    %user-hidden: "XRL target name";
    %help: short "XRL target name";
    %set:;
}
test1{
%help: short "test";
%set:;
}
}
}

The .boot:
protocols{
test{
test1: 1
}
}

When I start the xorp_rtrmgr process,the problem as follow:
ERROR xorp_rtrmgr:10616 RTRMGR +330 main_rtrmgr.cc run ] rtrmgr shutting down due to an init error: PARSE ERROR [Config File /root/xorp1111/xorp-1.4/rtrmgr/config.boot, line 5]: "protocols test test1" has type int, and value 1 is not a valid int; Last symbol parsed was "1" 

If the type of test1 change u32,it's ok.The version of xorp is xorp1.4.Don't the version support the type of i32?
What should I do for the question? 

Thanks!
fisher
2009-07-16 


From schintan at gmail.com  Sun Jul 26 22:10:34 2009
From: schintan at gmail.com (Chintan Shah)
Date: Mon, 27 Jul 2009 01:10:34 -0400
Subject: [Xorp-hackers] RPF check in PIM-SM
Message-ID: <bbf0e0350907262210rbb20772m802e37b6fd78eb02@mail.gmail.com>

Hello,

We are trying to implement a fast repair mechanism for PIM-SM  multicast
trees.
For that I need to know when is the RPF check performed on a received
packet. From whatever I could gather,
I understand that the kernel first tries to find a matching (S,G) entry in
the MFC table and if  it is  found then it
matches the incoming interface for the packet with the actual interface  on
which the packet was received and if both are  same then forwards the packet
to the outgoing interfaces from the outgoing interface list. My question is
whether this is the only RPF check that is performed on the packet or is
there any
other check involved like looking up the unicast table and then checking the
reverse path to the source
I am asking this question because the solution that we implemented is to
install the MFC entries
manually and there is  chance that the unicast table might be pointing to a
different interface than the MFC entry that we installed.
Could you please elaborate on how a multicast packet forwarded in the xorp
router.


Thanks a lot,
Chintan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-hackers/attachments/20090727/1896fc0e/attachment.html 

From bms at incunabulum.net  Mon Jul 27 07:43:14 2009
From: bms at incunabulum.net (Bruce Simpson)
Date: Mon, 27 Jul 2009 15:43:14 +0100
Subject: [Xorp-hackers] RPF check in PIM-SM
In-Reply-To: <bbf0e0350907262210rbb20772m802e37b6fd78eb02@mail.gmail.com>
References: <bbf0e0350907262210rbb20772m802e37b6fd78eb02@mail.gmail.com>
Message-ID: <4A6DBD02.4060505@incunabulum.net>

Chintan Shah wrote:
> Hello,
>
> We are trying to implement a fast repair mechanism for PIM-SM  
> multicast trees.
> For that I need to know when is the RPF check performed on a received 
> packet. From whatever I could gather,
> I understand that the kernel first tries to find a matching (S,G) 
> entry in the MFC table and if  it is  found then it
> matches the incoming interface for the packet with the actual 
> interface  on which the packet was received and if both are  same then 
> forwards the packet to the outgoing interfaces from the outgoing 
> interface list. My question is whether this is the only RPF check that 
> is performed on the packet or is there any
> other check involved like looking up the unicast table and then 
> checking the reverse path to the source

RPF checks normally happen in-kernel, and not under direct XORP control. 
This is one reason why the fib2mrib process exists -- to push unicast 
routes from the RIB into the MFEA.

>
> Could you please elaborate on how a multicast packet forwarded in the 
> xorp router. 

XORP doesn't forward packets, the host operating system does.

Both Linux and FreeBSD MROUTING have a common ancestor, they are pretty 
much equivalent code.

Good luck with your app.

thanks,
BMS