From greearb at candelatech.com  Tue Jun  1 00:03:35 2010
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 01 Jun 2010 00:03:35 -0700
Subject: [Xorp-users] xorp.ct is now on github
Message-ID: <4C04B0C7.8080301@candelatech.com>

I manually rebased all 177 or so patches in xorp.ct on top of
the 1.7 SVN release of xorp.

http://github.com/greearb/xorp.ct

I think the results will be same as the previous xorp.ct, but
it needs some testing just in case I missed something in the
rebase & merge.

I'm going to try to import all the Sourceforge Trac bug-entries
into github if it can be done automatically.

I plan to put the html up somewhere public and modify it
to suit xorp.ct.  I will also be releasing 1.7 one way or
another (you can already download a 1.7 tarball on github).

As far as I am concerned, Sourceforge Xorp SVN is mothballed, and I
welcome all who are interested to use and develop on the new xorp.ct
tree.  My goal is to make xorp.ct better than the original xorp in
every way, including stability, performance, features, etc.  If
patches are ever posted to Xorp SVN, I'll merge them into xorp.ct
if that seems prudent.

I prefer that patches are posted to the mailing list for
discussion.  I'll commit them (with credit to the original author).
I could also pull from a developer's own xorp.ct repository if
that is more convenient.

Thanks,
Ben

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


From naresh_raga at yahoo.co.in  Tue Jun  1 15:45:01 2010
From: naresh_raga at yahoo.co.in (naresh raga)
Date: Wed, 2 Jun 2010 04:15:01 +0530 (IST)
Subject: [Xorp-users] Definition for BGP damping parameters are not
	defined in user manual
In-Reply-To: <4C02F312.3070207@candelatech.com>
Message-ID: <823534.92959.qm@web94814.mail.in2.yahoo.com>

>The answer is probably somewhere in the bgp/* code, but I don't have 
time
>right now to look closer.

Yes,the code related to this is in damping.cc and damping.hh in bgp folder.

>You might try some recursive 
greps to see if you can find anything.

>You might try google as 
well...likely that info is defined in RFCs
>somewhere and hopefully 
xorp already adheres to that.


>I'll take a closer look later this 
evening if I get a chance.

>Thanks,
>Ben

I have gone into the code and found the definitions for parameters.

Thank you,
T.Raga Naresh Kumar.


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

From greearb at candelatech.com  Tue Jun  1 16:34:48 2010
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 01 Jun 2010 16:34:48 -0700
Subject: [Xorp-users] Definition for BGP damping parameters are not
 defined in user manual
In-Reply-To: <823534.92959.qm@web94814.mail.in2.yahoo.com>
References: <823534.92959.qm@web94814.mail.in2.yahoo.com>
Message-ID: <4C059918.1050708@candelatech.com>

On 06/01/2010 03:45 PM, naresh raga wrote:
>  >The answer is probably somewhere in the bgp/* code, but I don't have time
>  >right now to look closer.
>
> Yes,the code related to this is in damping.cc and damping.hh in bgp folder.
>
>  >You might try some recursive greps to see if you can find anything.
>
>  >You might try google as well...likely that info is defined in RFCs
>  >somewhere and hopefully xorp already adheres to that.
>
>
>  >I'll take a closer look later this evening if I get a chance.
>
>  >Thanks,
>  >Ben
>
> I have gone into the code and found the definitions for parameters.

Please post for all to see and/or send a patch for the user-guide.

Thanks,
Ben

>
> Thank you,
> T.Raga Naresh Kumar.
>
>


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


From greearb at candelatech.com  Tue Jun  1 23:57:13 2010
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 01 Jun 2010 23:57:13 -0700
Subject: [Xorp-users] Getting ready for release 1.8-CT
Message-ID: <4C0600C9.1010301@candelatech.com>

I am very close to releasing Xorp version 1.8-CT.

The code is basically what has been in xorp.ct for some time,
but I have also tweaked the documentation and the web page
html.

I'm now hosting my copy of the Xorp web page at:

http://www.candelatech.com/xorp.ct/

Please let me know if you find broken links or stale info.

The github project has been updated with the latest code:
http://github.com/greearb/xorp.ct

Commit messages are being sent to xorp-cvs at xorp.org now,
so subscribe to this if you want such notifications pushed
to you.  (Thanks to Atanu for fixing up the mailing list for
me.)

I plan to do some builds tomorrow and spot-test to make
sure nothing obvious broke.  If it works OK, I'll create
a 1.8-CT tag, do some binary builds, and call 1.8-CT done
(It should be easy to do a 1.8.x point release if bugs are
found...)

If anyone gets a chance to try it out, I'm interested in
the results!

Thanks,
Ben

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


From greearb at candelatech.com  Wed Jun  2 11:49:49 2010
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 02 Jun 2010 11:49:49 -0700
Subject: [Xorp-users] XORP 1.8-CT is released.
Message-ID: <4C06A7CD.8070208@candelatech.com>

I've tagged the git repo and uploaded binary builds for several
different versions of Fedora.

To install the binaries:
su - root
cd /usr/local/
tar -xvzf [xorp-binary.tgz]
cd xorp
./xorp_install.bash

Or, build from source:
git clone git://github.com/greearb/xorp.ct.git xorp.ct.github
cd xorp.ct.github/xorp
scons
su
./lf_pkg.bash
# Resulting file should be in $USER/tmp/xorp_xx.tgz
# See the section above on installing binaries, though the ./lf_pkg.bash
# script has already placed the files in /usr/local/xorp

The install script will create the xorp user, group, etc and attempt
to soft-link libraries to match if your distribution isn't exactly the
same as the build version.

To start xorp:
cd /usr/local/xorp/sbin/
./xorp_rtrmgr -b [your config file]

Then, connect with xorpsh (in another console):

su - root
/usr/local/xorp/sbin/xorpsh


I'm going to use the LANforge live CD as the xorp.ct live cd.  I'll
try to get some useful docs written up for using that and upload that
iso image to github within the next few days.


Release notes for 1.8-CT:

Major changes include:

    * Allow OSPF, RIP, BGP, OSLR, and PIM to better handle interfaces
       being added to and deleted from a running xorp instance via the 'xorpsh' CLI tool.

    * PIM: Fix state-machine lockup due to failure to advance state machine in some error cases.

    * RIP, BGP, PIM: Allow binding the protocol sockets to specific interfaces.

    * FEA: Support binding to specific interfaces, including multicast protocols.
       Use Netlink (Linux only) to filter events so that a single instance of
       xorp pays attention to only it's interfaces.

    * FEA: Support new Linux kernel API to provide multiple multicast
      routing tables per kernel instance. This requires kernel 2.6.34
      and the latest iproute and iptable tools.  These changes are
      backwards compatible with normal kernels.

    * OLSR: Enable building OLSR, support binding to a specific interface.

    * Support building IPv6 multicast support on Linux. Haven't tested functionality yet.



git shortlog for commits since Release 1.7.

Achmad Basuki:
       rpms:  Add scripts & files to build RPM packages on Fedora Linux (at least).

Ben Greear:
       Remove tags and branches dir.
       Move trunk/* to ./, remove trunk directory.
       xorp-ct:  Merge old CVS patch into svn repository.
       olsr:  Enable OLSR compile in scons
       olsr:  Fix OLSR install target, properly add OLSR templates if OLSR is enabled.
       libxorp: Work-around crash in selector.cc due to accessing stale memory.
       fea:  Add method to dump netlink route messages.
       libxipc:  De-obfuscate ReplyPacket (it was just a vector of bytes)
       libxipc:  Give user a better clue as to why xrl router timed out.
       Fix some uninitialized memory errors found by valgrind.
       Remove some noisy logging.      Add code to clean up pid-file if possible (on exit)
       Fix logging & tracing to show micro-seconds, greatly aids debugging performance issues.
       mfea:  Fix vif removal race related to mld6igmp
       startup:  Make startup faster by implementing startup methods.
       fea:  Don't fail commit because we can't remove multicast addresses that are already deleted.
       startup: Put 'startup' method in common.xif.
       pim:  Don't fail commit if pim can't find interface to stop.
       fea:  Don't fail commit if vif is gone when un-registering protocol on interface.
       mfea:   Defer start of mfea_vif if it can't be started when immediately requested.
       ospf:  Add OSPF logging in the path that disables an interface.
       rtrmgr:  Add some logging to rtr-mgr to help track configuration commits.
       mld6igmp:  Defer mld6igmp vif start if vif is DOWN
       pim:  Handle deferred vif_start for pim.
       mld6igmp:   Don't faile igmp if it can't join multicast group.
       ospf:   More logging to help track down OSPF peer link issue.
       ospf/fea: Add logic to print out the configuration tree.
       Add xorp_install.bash script
       Add scripts to generate .deb files on Fedora.
       cli:  Fix memory leak
       libxorp:  Add BugCatcher class to help debug use-after-free and similar errors.
       rtrmgr: Disable XRLdb run-time verification by default.  Should speed up startup.
       build:  Enable gprof
       fea:  Allow filtering netlink messages
       policy:  Fix redist static and connected routes to ospf.
       Fix compile errors on Ubuntu
       fea:  Replace all instances of HAVE_PCAP with HAVE_PCAP_H
       OSPF:  Interop with RFC4813, fix router-link metric for loopback case.
       scons:  Properly detect multicast header files for older Linux distributions.
       fea:  Properly check for minimum ethernet packet size.
       fea:  Dynamically attempt to use ioctl to set device flags if netlink doesn't work.
       vrrp:  Remove assert that appears to be wrong.
       ArpHeader/vrrp:  Fix a compile error on Sparc, related to ArpHeader.
       fea:  Remove some un-needed casts and assignments related to netlink messages.
       fea/vrrp:  Make some errors about adding/deleting macs non-critical.
       fea:  Detect pcap-bpf.h and don't use the feature if it isn't available.
       fea/pcap:  Don't link against libpcap if it doesn't exist.
       Fix build on BSD.
       Move MULT_MCAST table detection logic into allconfig.py instead of hard-coding it.
       netlink:  ifdef out netlink code if not compiled to use netlink sockets.
       fea:  Thoroughly disable all routing_socket code if platform doesn't support it.
       fea: Don't compile ioctl get/set logic if netlink is defined (we prefer netlink).
       fea/click:  Disable CLICK by default.  Saves around 200k of disk space.
       AlignData cannot be made to copy-data, other code makes assumptions that it does not.
       Allow disabling of IPv6 via scons...even if OS supports it.
       ipv6:  Conditionally compile much of the IPv6 related code.
       ipv6:  Conditionally compile some more IPv6 code.
       fea/firewall:  Allow to compile out firewall code, saves ~180k stripped.
       Only generate .scons_build_args when doing a build (not an install, for instance)
       Build template 'build-script' to strip 'firewall' out of fea.tp.raw.
       Fix crash when DEBUG_LOGGING was enabled, fix build when DEBUG_LOGING was enabled.
       Revert "Conditionally compile much of the IPv6 related code.:
       fea:  Conditionally compile Remove socket6 API
       ipv6:  Conditionally compile socket6 logic.  Saves around 80k on disk.
       ipv6/fea:  Conditionally compile socket6 API        Saves about 80k on disk.
       ipv6/pim:  Don't build pim6 if IPv6 is disabled.  Saves about 12k on disk
       ospfv3/ipv6:  Disable ospfv3 when ipv6 is disabled.  Saves about 270k on disk.
       ospf:  Fix up build errors introduced earlier, when ipv6 is enabled.
       Fix compile on really old systems (Fedora 5)
       fea/netlink:  Fix problem with older kernels (FC5, 2.6.28 kernel, for instance)
       ripng/ipv6:  Don't build ripng if not using IPv6
       fea/ipv6:  Conditionally compile ipv6 stuff in fea-fib-client interface.
       rib/xif: Re-arrange so that it will be easier to ifdef out the ipv6 functions.
       static/ipv6:  Conditionally compile some ipv6 logic in static.
       ospf:  Group ipv6 code together to make it easier to conditionally compile.
       ospf/ipv6:  Conditionally compile all ipv6 code in xrl_io.cc, saves 50k
       rib/ipv6: Conditionally compile some ipv6 code in tools.
       pim/ipv6:  Conditionally compile some xrl_pim_node ipv6 code.
       fib2mrib/ipv6:  Conditionally compile ipv6 code, saves 20k
       ipv6:  Conditionally compile (more) ipv6 code for bgp, ospf, rib, and static-routes.
       vrrp:  Fix assert related to packet size.
       fea/ipv6:  Conditionally compile a bunch more fea/rib/pim ipv6 code.
       vrrp/fea:  The commit logic was paying more attention to the error_msg string than return codes.
       vrrp:  Enable creating/deleting secondary IP address for the VRRP masters.
       vrrp:  If vrrp tries to remove the VRRP MAC, and it's the only one that exists
              ..then create a random MAC to take it's place.  Otherwis
       ipv6/pim:  conditionally compile more ipv6 code.
       rpms:  Script to automate building RPMs.
       fea:  Add better decoding for netlink error messages.
       vrrp:  Don't allow user to mis-configure interval.
       fea:  If we try to read netlink for a particular seqno, but do not find it
             before netlink socket is out of packets to read, then do
       fea:  Add work-around for older kernels that cannot pull single interfaces.
       fea:  Fix link & MTU detection on funky systems.
       Fix 'scons check' build.
       carrier-sense:  My previous fix for sensing carrier by looking at sysfs files
             on linux neglected to deal with exceptions thrown by
       IPMR:  Add support for new multiple mcast table API.
       Logging:  Enable conditional compilation of logging code.
       mfea:  Update IPv6 mcast code to modern kernels.
       Small improvement to memory usage related to xrl_error
       xrl:  Move ipv4 and ipv4Net objects into xrl_atom
       ipv6/mcast:  BSD doesn't have mifc6ctl.vifc_threshold member.
       selector:  Work around assert in selector logic.
       beautify code:  Had to stare at offending line for quite a while to parse it.
       exceptions:  Pass string back by reference.
       fea,comm:  Remove some noisy logging.
       mld6igmp:  Tweak logging and add/delete callback.
       policy:  Add support for exporting routes from fib2mrib to ospf.
       rib/show_routes:  Fix crash due to race.
       Move parse_netlink_socket logic into get_netlink_socket.cc file.
       fea:  route distribution debugging
       Package script used by Candela.
       Final xorp.ct merge
       Update README for XORP.ct and rls 1.8
       olsr/ospf/libxorp:  Add some files missed in xorp.ct merge.
       oslr:  Build OLSR by default.
       Move README to base directory.
       Update README file.

Eric S. Johnson:
       vrrp:  Fix asserts, remove IPs on shutdown.

Saurabh <saurabh.pandya at elitecore.com>
       IPv6/PIM:  conditionally compile more ipv6 code.


Thanks,
Ben

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


From Tom.McMillan at l-3com.com  Mon Jun  7 15:56:53 2010
From: Tom.McMillan at l-3com.com (Tom.McMillan at l-3com.com)
Date: Mon, 7 Jun 2010 15:56:53 -0700
Subject: [Xorp-users] Generating PIM-SM control packets...
Message-ID: <E3144A5AFE0BEE438E3074CFD47AAC10D68889@SD-EX1.Linkabit.L-3com.com>

In the document "XORP SIM-SM Test Suite 1.6", there is a mention on the
very first page of a mechanism for testing XORP:

 

"More specifically, the XORP PIM-SM implementation has extensions that
can be used to generate various PIM-SM protocol control packets for
testing purpose[s]."

 

But there's no other mention of these extensions elsewhere in the
document.  Where are these test extensions documented?  How do I
generate test packets?  Is there some piece of code somewhere that I can
use as a template for generating these test packets?  I'm not sure where
to look...

 

Thanks for any pointers that you can give me.

 

~ Tom McMillan

 




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20100607/2ebc79b6/attachment.html 

From greearb at candelatech.com  Mon Jun  7 16:34:55 2010
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 07 Jun 2010 16:34:55 -0700
Subject: [Xorp-users] Generating PIM-SM control packets...
In-Reply-To: <E3144A5AFE0BEE438E3074CFD47AAC10D68889@SD-EX1.Linkabit.L-3com.com>
References: <E3144A5AFE0BEE438E3074CFD47AAC10D68889@SD-EX1.Linkabit.L-3com.com>
Message-ID: <4C0D821F.3060509@candelatech.com>

On 06/07/2010 03:56 PM, Tom.McMillan at l-3com.com wrote:
> In the document ?XORP SIM-SM Test Suite 1.6?, there is a mention on the
> very first page of a mechanism for testing XORP:
>
> ?More specifically, the XORP PIM-SM implementation has extensions that
> can be used to generate various PIM-SM protocol control packets for
> testing purpose[s].?
>
> But there?s no other mention of these extensions elsewhere in the
> document. Where are these test extensions documented? How do I generate
> test packets? Is there some piece of code somewhere that I can use as a
> template for generating these test packets? I?m not sure where to look?
>
> Thanks for any pointers that you can give me.

I haven't tried, but maybe some of the *test* or other methods in
the xrl_pim_shell_funcs.sh file?

Maybe one of the original developers will speak up.

Or, possibly using something like gitk or 'git log' one could
search back and see if any commits went in mentioning that
feature.
This assumes you would be using a git import of the xorp
source code tree, such as my xorp.ct branch:
http://github.com/greearb/xorp.ct

Thanks,
Ben

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


From greearb at candelatech.com  Wed Jun  9 15:02:10 2010
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 09 Jun 2010 15:02:10 -0700
Subject: [Xorp-users] Xorp.CT RPM packages are uploaded.
Message-ID: <4C100F62.8090802@candelatech.com>

I just built some new RPM files for XORP.CT.

You can download them here:

http://github.com/greearb/xorp.ct/downloads

I have a binary for Fedora 13 32-bit, but the source RPM
builds on F13 and Fedora 11 (and probably others).  It
does NOT build on Fedora 8 because it seems tar doesn't
understand the lzma suffix there.

To build the source rpm, try something like:

rpm -i [src-rpm-file]
cd ~/rpmbuild/SPECS/
rpmbuild -bb xorp.ct.spec

Binary RPM will be at:
../RPMS/*

If you need rpmbuild:
yum install rpm-build


If you want to build your own RPM files from the xorp repository,
close the latest xorp.ct on github and then run:

cd xorp.ct.git/xorp
./build_rpms.bash

Likely this process and/or spec file could still be improved.

Let me know if you see anything strange....

Thanks,
Ben

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


From saurabh.pandya at elitecore.com  Thu Jun 10 00:21:17 2010
From: saurabh.pandya at elitecore.com (saurabh)
Date: Thu, 10 Jun 2010 12:51:17 +0530
Subject: [Xorp-users] Fwd: Is there any way you 'r seeing ,
 to get xorp (multicast part) under 6 MB form 10 MB
Message-ID: <4C10926D.6030600@elitecore.com>



Dear Ben,BMS,atanu and all core members,

First congregates for community version 1.8 of xorp.ct.

I have been exploring various ways of getting xorp under 6 MB form 10 MB (of my cutoff version)
(likely want 45% of further size reduction), but yield without conclusion.

Are you or other core members are seeing any alternate solution to get xorp
upto this size ? This is now being barrier for my embedded target. (may many like me facing such situations)

As I see that xorp itself written in C++ with STL etc, eating lots 
of space and memory, despite many of our size reduction patches.

-Thanks
Saurabh


From a.greenhalgh at cs.ucl.ac.uk  Thu Jun 10 02:29:57 2010
From: a.greenhalgh at cs.ucl.ac.uk (Adam Greenhalgh)
Date: Thu, 10 Jun 2010 10:29:57 +0100
Subject: [Xorp-users] [Xorp-hackers] Fwd: Is there any way you 'r seeing
	, to get xorp 	(multicast part) under 6 MB form 10 MB
In-Reply-To: <4C10926D.6030600@elitecore.com>
References: <4C10926D.6030600@elitecore.com>
Message-ID: <AANLkTinyDqvvz2IIyxnJVt_9tWRaXX9AqxQxZruHjVGT@mail.gmail.com>

I've often wondered whether this would be any good ?

http://cxx.uclibc.org/index.html

Adam

On 10 June 2010 08:21, saurabh <saurabh.pandya at elitecore.com> wrote:
>
>
> Dear Ben,BMS,atanu and all core members,
>
> First congregates for community version 1.8 of xorp.ct.
>
> I have been exploring various ways of getting xorp under 6 MB form 10 MB (of my cutoff version)
> (likely want 45% of further size reduction), but yield without conclusion.
>
> Are you or other core members are seeing any alternate solution to get xorp
> upto this size ? This is now being barrier for my embedded target. (may many like me facing such situations)
>
> As I see that xorp itself written in C++ with STL etc, eating lots
> of space and memory, despite many of our size reduction patches.
>
> -Thanks
> Saurabh
>
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers at icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
>


From greearb at candelatech.com  Thu Jun 10 09:33:40 2010
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 10 Jun 2010 09:33:40 -0700
Subject: [Xorp-users] [Xorp-hackers] Fwd: Is there any way you 'r seeing
 , to get xorp 	(multicast part) under 6 MB form 10 MB
In-Reply-To: <AANLkTinyDqvvz2IIyxnJVt_9tWRaXX9AqxQxZruHjVGT@mail.gmail.com>
References: <4C10926D.6030600@elitecore.com>
	<AANLkTinyDqvvz2IIyxnJVt_9tWRaXX9AqxQxZruHjVGT@mail.gmail.com>
Message-ID: <4C1113E4.7020208@candelatech.com>

On 06/10/2010 02:29 AM, Adam Greenhalgh wrote:
> I've often wondered whether this would be any good ?
>
> http://cxx.uclibc.org/index.html

Might be interesting to see if xorp compiled against
it.

Another possibility would be to change all of our 'string'
class instances to 'xstring', and provide our own non-templated
string class.  On another project I worked on some years ago
this was a big binary space win (but, this was on a mips platform,
so who knows if modern stuff has the same penalty/gain).

If someone wants to go through and replace 'string' with 'xstring',
typdef string to xstring, and send me the patch, I'll drop in my
own string class and see how it goes.

Thanks,
Ben

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


From greearb at candelatech.com  Thu Jun 10 09:36:58 2010
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 10 Jun 2010 09:36:58 -0700
Subject: [Xorp-users] Fwd: Is there any way you 'r seeing ,
 to get xorp (multicast part) under 6 MB form 10 MB
In-Reply-To: <4C10926D.6030600@elitecore.com>
References: <4C10926D.6030600@elitecore.com>
Message-ID: <4C1114AA.7050304@candelatech.com>

On 06/10/2010 12:21 AM, saurabh wrote:
>
>
> Dear Ben,BMS,atanu and all core members,
>
> First congregates for community version 1.8 of xorp.ct.
>
> I have been exploring various ways of getting xorp under 6 MB form 10 MB (of my cutoff version)
> (likely want 45% of further size reduction), but yield without conclusion.
>
> Are you or other core members are seeing any alternate solution to get xorp
> upto this size ? This is now being barrier for my embedded target. (may many like me facing such situations)
>
> As I see that xorp itself written in C++ with STL etc, eating lots
> of space and memory, despite many of our size reduction patches.

Can you send us the output of:
find /usr/local/xorp -name "*" -print|xargs ls -l
so we can see exactly what files you are currently using?

Do you need the policy features?  I started looking at conditionally
compiling that out the other day, but it looked fairly invasive so
I went on to other things.  Still, it might be worth a try.

Also, I'll add an option to compile with -Os (optimize for size)
to see if that helps the binary size...

Thanks,
Ben


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


From jmitchell at ll.mit.edu  Thu Jun 10 09:37:34 2010
From: jmitchell at ll.mit.edu (Jeff Mitchell)
Date: Thu, 10 Jun 2010 12:37:34 -0400
Subject: [Xorp-users] [Xorp-hackers] Fwd: Is there any way you 'r seeing
 , to get xorp 	(multicast part) under 6 MB form 10 MB
In-Reply-To: <4C1113E4.7020208@candelatech.com>
References: <4C10926D.6030600@elitecore.com>	<AANLkTinyDqvvz2IIyxnJVt_9tWRaXX9AqxQxZruHjVGT@mail.gmail.com>
	<4C1113E4.7020208@candelatech.com>
Message-ID: <4C1114CE.6020401@ll.mit.edu>

On 06/10/2010 12:33 PM, Ben Greear wrote:
> On 06/10/2010 02:29 AM, Adam Greenhalgh wrote:
>> I've often wondered whether this would be any good ?
>>
>> http://cxx.uclibc.org/index.html
>
> Might be interesting to see if xorp compiled against
> it.

Clang might be useful for the OP to check out too.

http://clang.llvm.org/cxx_status.html

I don't know how it does with binary size -- getting a 40% reduction 
isn't too easy -- but it may help.

The OP may also want to seriously consider building statically and then 
using an executable packer like UPX:

http://upx.sourceforge.net/

No idea if this approach would bear fruit though.

--Jeff


From greearb at candelatech.com  Thu Jun 10 09:52:45 2010
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 10 Jun 2010 09:52:45 -0700
Subject: [Xorp-users] [Xorp-hackers] Fwd: Is there any way you 'r seeing
 , to get xorp 	(multicast part) under 6 MB form 10 MB
In-Reply-To: <4C1114CE.6020401@ll.mit.edu>
References: <4C10926D.6030600@elitecore.com>	<AANLkTinyDqvvz2IIyxnJVt_9tWRaXX9AqxQxZruHjVGT@mail.gmail.com>	<4C1113E4.7020208@candelatech.com>
	<4C1114CE.6020401@ll.mit.edu>
Message-ID: <4C11185D.9060105@candelatech.com>

On 06/10/2010 09:37 AM, Jeff Mitchell wrote:
> On 06/10/2010 12:33 PM, Ben Greear wrote:
>> On 06/10/2010 02:29 AM, Adam Greenhalgh wrote:
>>> I've often wondered whether this would be any good ?
>>>
>>> http://cxx.uclibc.org/index.html
>>
>> Might be interesting to see if xorp compiled against
>> it.
>
> Clang might be useful for the OP to check out too.
>
> http://clang.llvm.org/cxx_status.html
>
> I don't know how it does with binary size -- getting a 40% reduction
> isn't too easy -- but it may help.
>
> The OP may also want to seriously consider building statically and then
> using an executable packer like UPX:
>
> http://upx.sourceforge.net/
>
> No idea if this approach would bear fruit though.

That UPX thing looks cool, but if someone is tight on space,
hopefully they are already running a compressed file system, so
adding compression of the binaries might not gain too much.

Still, it would be neat see the results of a upx packaging!

Thanks,
Ben

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


From greearb at candelatech.com  Thu Jun 10 11:27:45 2010
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 10 Jun 2010 11:27:45 -0700
Subject: [Xorp-users] [Xorp-hackers] Fwd: Is there any way you 'r seeing
 , to get xorp (multicast part) under 6 MB form 10 MB
In-Reply-To: <4C10926D.6030600@elitecore.com>
References: <4C10926D.6030600@elitecore.com>
Message-ID: <4C112EA1.6000802@candelatech.com>

On 06/10/2010 12:21 AM, saurabh wrote:
>
>
> Dear Ben,BMS,atanu and all core members,
>
> First congregates for community version 1.8 of xorp.ct.
>
> I have been exploring various ways of getting xorp under 6 MB form 10 MB (of my cutoff version)
> (likely want 45% of further size reduction), but yield without conclusion.
>
> Are you or other core members are seeing any alternate solution to get xorp
> upto this size ? This is now being barrier for my embedded target. (may many like me facing such situations)

I just fixed optimize=size compile on Fedora 13 (not sure if it worked elsewhere or not).
Fix has been pushed to xorp.ct on github.

Compiling with:
  scons -j4 disable_ipv6=yes disable_fw=yes disable_warninglogs=yes disable_tracelogs=yes disable_fatallogs=yes disable_infologs=yes disable_assertlogs=yes 
disable_errorlogs=yes enable_olsr=no enable_bgp=no enable_ospf=no enable_vrrp=no enable_policy=no optimize=size

gave me install image size of 9852 on Fedora 13, 32-bit:

[root at grok2 xorp]# du -s /usr/local/xorp
9852	/usr/local/xorp

Without the optimize=size, it was 11700, so it's a decent improvement.

I still haven't compiled out rip, and seems no need for xorp_fea_dummy
either..

[root at grok2 xorp]# ls /usr/local/xorp/lib/xorp/sbin/
xorp_fea        xorp_fib2mrib  xorp_mld     xorp_policy  xorp_rip
xorp_fea_dummy  xorp_igmp      xorp_pimsm4  xorp_rib     xorp_static_routes

Thanks,
Ben

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


From miro_todorovic at yahoo.com  Thu Jun 10 13:22:46 2010
From: miro_todorovic at yahoo.com (Miroslav Todorovic)
Date: Thu, 10 Jun 2010 13:22:46 -0700 (PDT)
Subject: [Xorp-users] Problem with network reachability
Message-ID: <738693.83034.qm@web37006.mail.mud.yahoo.com>

Hello,

My network has five xorp routers. U used vmware ubuntu virtual machine to install xorp.? I also have five windows VM in the network.
My problem is:

When I try to ping interfaces in the network from windows VM I could not reach all interfaces, but if I try to ping from any router, I have full network reachability.
In other words, some routers, but not all, don't realise how to forward packets to destination address when I send packets from windows VM. Problem doesn't exist if I 
ping from any routers.

Any idea?

Thank you!

Miroslav??? 



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20100610/06c598b8/attachment.html 

From greearb at candelatech.com  Thu Jun 10 13:22:46 2010
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 10 Jun 2010 13:22:46 -0700
Subject: [Xorp-users] [Xorp-hackers] Fwd: Is there any way you 'r seeing
 , to get xorp (multicast part) under 6 MB form 10 MB
In-Reply-To: <4C112EA1.6000802@candelatech.com>
References: <4C10926D.6030600@elitecore.com> <4C112EA1.6000802@candelatech.com>
Message-ID: <4C114996.1060606@candelatech.com>

On 06/10/2010 11:27 AM, Ben Greear wrote:
> On 06/10/2010 12:21 AM, saurabh wrote:
>>
>>
>> Dear Ben,BMS,atanu and all core members,
>>
>> First congregates for community version 1.8 of xorp.ct.
>>
>> I have been exploring various ways of getting xorp under 6 MB form 10 MB (of my cutoff version)
>> (likely want 45% of further size reduction), but yield without conclusion.
>>
>> Are you or other core members are seeing any alternate solution to get xorp
>> upto this size ? This is now being barrier for my embedded target. (may many like me facing such situations)
>
> I just fixed optimize=size compile on Fedora 13 (not sure if it worked elsewhere or not).
> Fix has been pushed to xorp.ct on github.

I allowed compiling out some other things, including xorpsh.  No idea if resulting
code functions, but it's a lot smaller:

scons -j4 disable_ipv6=yes disable_fw=yes disable_warninglogs=yes disable_tracelogs=yes disable_fatallogs=yes disable_infologs=yes disable_assertlogs=yes 
disable_errorlogs=yes enable_olsr=no enable_bgp=no enable_ospf=no enable_vrrp=no enable_policy=no enable_rip=no optimize=size enable_fea_dummy=no 
enable_xorpsh=no disable_profile=yes

[root at grok2 xorp]# du -s /usr/local/xorp
8000	/usr/local/xorp

You can probably get rid of the policy binaries if you are not using
policies, the *shell_funcs.sh and call_xrl in /usr/local/xorp/sbin,
and probably everything in xorp/lib/xorp/bin.

Also the share/xorp/templates/policy.*

That gets you to 7784 KB of disk space.
I think that you might not need any templates at all, which would
bring it down to:  7604 KB.

After this, I'm not so sure.  There's probably some more ipv6
stuff to conditionally compile, and might could compile out
at least much of the policy stuff.

If you try this out, I'm interested to know the results.

Thanks,
Ben

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


From greearb at candelatech.com  Thu Jun 10 13:46:15 2010
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 10 Jun 2010 13:46:15 -0700
Subject: [Xorp-users] Problem with network reachability
In-Reply-To: <738693.83034.qm@web37006.mail.mud.yahoo.com>
References: <738693.83034.qm@web37006.mail.mud.yahoo.com>
Message-ID: <4C114F17.8020001@candelatech.com>

On 06/10/2010 01:22 PM, Miroslav Todorovic wrote:
> Hello,
>
> My network has five xorp routers. U used vmware ubuntu virtual machine
> to install xorp. I also have five windows VM in the network.
> My problem is:
>
> When I try to ping interfaces in the network from windows VM I could not
> reach all interfaces, but if I try to ping from any router, I have full
> network reachability.
> In other words, some routers, but not all, don't realise how to forward
> packets to destination address when I send packets from windows VM.
> Problem doesn't exist if I
> ping from any routers.

Maybe your windows system doesn't have the needed routes in it?

Try something like traceroute to see where the packets go in
the network...

Thanks,
Ben

>
> Any idea?
>
> Thank you!
>
> Miroslav
>
>
>
>
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


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


From greearb at candelatech.com  Thu Jun 10 14:47:37 2010
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 10 Jun 2010 14:47:37 -0700
Subject: [Xorp-users] [Xorp-hackers] Fwd: Is there any way you 'r seeing
 , to get xorp 	(multicast part) under 6 MB form 10 MB
In-Reply-To: <4C1114CE.6020401@ll.mit.edu>
References: <4C10926D.6030600@elitecore.com>	<AANLkTinyDqvvz2IIyxnJVt_9tWRaXX9AqxQxZruHjVGT@mail.gmail.com>	<4C1113E4.7020208@candelatech.com>
	<4C1114CE.6020401@ll.mit.edu>
Message-ID: <4C115D79.5070204@candelatech.com>

On 06/10/2010 09:37 AM, Jeff Mitchell wrote:
> On 06/10/2010 12:33 PM, Ben Greear wrote:
>> On 06/10/2010 02:29 AM, Adam Greenhalgh wrote:
>>> I've often wondered whether this would be any good ?
>>>
>>> http://cxx.uclibc.org/index.html
>>
>> Might be interesting to see if xorp compiled against
>> it.
>
> Clang might be useful for the OP to check out too.
>
> http://clang.llvm.org/cxx_status.html

I gave this a try on Fedora 13:

# Default llvm/clang is broken..the thing in updates-testing
# fixed at least some of the problems.

yum --enablerepo=updates-testing update llvm llvm-devel clang

cd xorp;
scons CC=clang CXX=clang++

clang doesn't seem to understand namespaces and dumps core.

So, guess it isn't quite ready yet!

Thanks,
Ben

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


From saurabh.pandya at elitecore.com  Thu Jun 10 22:29:11 2010
From: saurabh.pandya at elitecore.com (saurabh)
Date: Fri, 11 Jun 2010 10:59:11 +0530
Subject: [Xorp-users] [Xorp-hackers] Fwd: Is there any way you 'r seeing
 , to get xorp 	(multicast part) under 6 MB form 10 MB
In-Reply-To: <AANLkTinyDqvvz2IIyxnJVt_9tWRaXX9AqxQxZruHjVGT@mail.gmail.com>
References: <4C10926D.6030600@elitecore.com>
	<AANLkTinyDqvvz2IIyxnJVt_9tWRaXX9AqxQxZruHjVGT@mail.gmail.com>
Message-ID: <4C11C9A7.304@elitecore.com>

On 06/10/10 14:59, Adam Greenhalgh wrote:
> I've often wondered whether this would be any good ?
>
> http://cxx.uclibc.org/index.html
>
>   
Well seems potential horizons there ,
well i will give this try and let see how it can help...

thanks


From greearb at candelatech.com  Fri Jun 11 13:18:02 2010
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 11 Jun 2010 13:18:02 -0700
Subject: [Xorp-users] [Xorp-hackers] Fwd: Is there any way you 'r seeing
 , to get xorp 	(multicast part) under 6 MB form 10 MB
In-Reply-To: <4C115D79.5070204@candelatech.com>
References: <4C10926D.6030600@elitecore.com>	<AANLkTinyDqvvz2IIyxnJVt_9tWRaXX9AqxQxZruHjVGT@mail.gmail.com>	<4C1113E4.7020208@candelatech.com>	<4C1114CE.6020401@ll.mit.edu>
	<4C115D79.5070204@candelatech.com>
Message-ID: <4C1299FA.8080806@candelatech.com>

On 06/10/2010 02:47 PM, Ben Greear wrote:
> On 06/10/2010 09:37 AM, Jeff Mitchell wrote:
>> On 06/10/2010 12:33 PM, Ben Greear wrote:
>>> On 06/10/2010 02:29 AM, Adam Greenhalgh wrote:
>>>> I've often wondered whether this would be any good ?
>>>>
>>>> http://cxx.uclibc.org/index.html
>>>
>>> Might be interesting to see if xorp compiled against
>>> it.
>>
>> Clang might be useful for the OP to check out too.
>>
>> http://clang.llvm.org/cxx_status.html

I got this compiling a minimal set of xorp modules.  Unfortunately,
it seems clang isn't so good at -Os as g++. g++ code is about 20% smaller.

I'm going to get the rest of xorp compiling with clang for
completeness.  It's very strict, so might help catch a few
bugs, and may have other benefits as well.

Thanks,
Ben

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


From gs050486d at student.etf.rs  Sun Jun 13 11:39:38 2010
From: gs050486d at student.etf.rs (=?UTF-8?Q?Stevan_Grbi=C4=87_05/0486?=)
Date: Sun, 13 Jun 2010 20:39:38 +0200
Subject: [Xorp-users] one more issue with ospf and network topology
Message-ID: <b2e5298394bbc8a20d31c2ebe0fe8417@student.etf.rs>

Hi,
I'm trying to configure basic network topology like A=B=C=D(=E) using
OSPF4. My config of routers is posted down. (using VirtualBox and and NIC
set to internal network, to  separate traffic from outside world, and to
make more realistic scenario-like 3 (4 and 5) routers connected in
cascade). I'm  pinging routers to check for availability, as well as route
advertising.

1. in the 1st scenario like A=B=C I'm able to ping from router A router C
(this time router C has only one interface enabled and OSPF set on it, in
config file) and it's work just fine. (only in this case)
2. next step is to add router D for A=B=C=D scenario, after this I'm not
able to ping router D from A,as network is not reachable..and I don't get
any response from pinging C's interface on B side...

Here is my config file for B router (& all routers, except edge routers
which have one interface):

interfaces {
    restore-original-config-on-shutdown: false
    interface eth0 {
	description: "data interface"
	disable: false
	/* default-system-config */
	vif eth0 {
	    disable: false
	    address 1.1.1.3 {
		prefix-length: 24
		broadcast: 1.1.1.255
		disable: false
	    }
	}
    }
interface eth1 {
	description: "data interface"
	disable: false
	/* default-system-config */
	vif eth1 {
	    disable: false
	    address 2.2.2.2 {
		prefix-length: 24
		broadcast: 2.2.2.255
		disable: false
	    }
	}
    }
}

fea {
    unicast-forwarding4 {
        disable: false
    }

    unicast-forwarding6 {
        disable: false
    }
}

protocols {
    ospf4 {
	router-id: 2.0.0.0

	area 1.1.1.0 {
	    interface eth0 {
		link-type: "broadcast"
		vif eth0 {
		    address 1.1.1.3 {
		    }
		}
	    }
	}

	area 2.2.2.0 {
	    interface eth1 {
		link-type: "broadcast"
		vif eth1 {
		    address 2.2.2.2 {
		    }
		}
	    }
	}
    }
}

Router A: eth0-1.1.1.2  area:1.1.1.0 | router-id: 1.1.1.2  
Router C: eth0-2.2.2.3  area:2.2.2.0 | eth1-3.3.3.2  area:3.3.3.0 |
router-id 3.0.0.0
Router D: eth0-3.3.3.3  area:3.3.3.0 | eth1-4.4.4.2  area:4.4.4.0 |
router-id 4.0.0.0
etc.

If someone can point me on mistake, or suggest me some other solution for
this (cascade) scenario (of four and five routers).

Thanks in advance!


From greearb at candelatech.com  Sun Jun 13 12:23:40 2010
From: greearb at candelatech.com (Ben Greear)
Date: Sun, 13 Jun 2010 12:23:40 -0700
Subject: [Xorp-users] one more issue with ospf and network topology
In-Reply-To: <b2e5298394bbc8a20d31c2ebe0fe8417@student.etf.rs>
References: <b2e5298394bbc8a20d31c2ebe0fe8417@student.etf.rs>
Message-ID: <4C15303C.2060204@candelatech.com>

On 06/13/2010 11:39 AM, Stevan Grbi? 05/0486 wrote:
> Hi,
> I'm trying to configure basic network topology like A=B=C=D(=E) using
> OSPF4. My config of routers is posted down. (using VirtualBox and and NIC
> set to internal network, to  separate traffic from outside world, and to
> make more realistic scenario-like 3 (4 and 5) routers connected in
> cascade). I'm  pinging routers to check for availability, as well as route
> advertising.

> Router A: eth0-1.1.1.2  area:1.1.1.0 | router-id: 1.1.1.2
> Router C: eth0-2.2.2.3  area:2.2.2.0 | eth1-3.3.3.2  area:3.3.3.0 |
> router-id 3.0.0.0
> Router D: eth0-3.3.3.3  area:3.3.3.0 | eth1-4.4.4.2  area:4.4.4.0 |
> router-id 4.0.0.0
> etc.
>
> If someone can point me on mistake, or suggest me some other solution for
> this (cascade) scenario (of four and five routers).

Does it work if you put them all in the same area?

It may take something special to get different areas to share
routes?

Thanks,
Ben


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


From miro_todorovic at yahoo.com  Sun Jun 13 13:00:15 2010
From: miro_todorovic at yahoo.com (Miroslav Todorovic)
Date: Sun, 13 Jun 2010 13:00:15 -0700 (PDT)
Subject: [Xorp-users] Problem with network reachability
In-Reply-To: <4C114F17.8020001@candelatech.com>
Message-ID: <576946.67943.qm@web37001.mail.mud.yahoo.com>


Thank you!

I didn't check routing tables in windows, but I did use traceroute for forwarding paths monitoring. 
If the packets could not be delivered to destination address, problem is router's forwarding. There is always one router, (first, the second or third on the path), in the network where the packets getting stuck. It could not realise how to forward packets to some other router, or its subnet.
All router's routing tables are formed correctly. 

I want to test multicast streaming. I used ospf as unicast protocol, and the simpliest ospf configuration, like: 

protocols {
    ospf4 {
	router-id: 10.10.10.10

	area 0.0.0.0 {
	    interface dc0 {
		vif dc0 {
		    address 10.10.10.10 {
		    }
		}
	    }
	}
    }
}
Maybe I need to specify something more in configuration?
I've tried with smaller network, and it worked well.

From: Ben Greear <greearb at candelatech.com>
Subject: Re: [Xorp-users] Problem with network reachability
To: "Miroslav Todorovic" <miro_todorovic at yahoo.com>
Cc: "xorp comunity" <xorp-users at xorp.org>
Date: Thursday, June 10, 2010, 1:46 PM

On 06/10/2010 01:22 PM, Miroslav Todorovic wrote:
> Hello,
>
> My network has five xorp routers. U used vmware ubuntu virtual machine
> to install xorp. I also have five windows VM in the network.
> My problem is:
>
> When I try to ping interfaces in the network from windows VM I could not
> reach all interfaces, but if I try to ping from any router, I have full
> network reachability.
> In other words, some routers, but not all, don't realise how to forward
> packets to destination address when I send packets from windows VM.
> Problem doesn't exist if I
> ping from any routers.

Maybe your windows system doesn't have the needed routes in it?

Try something like traceroute to see where the packets go in
the network...

Thanks,
Ben

>
> Any idea?
>
> Thank you!
>
> Miroslav
>
>
>
>
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


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



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

From greearb at candelatech.com  Sun Jun 13 21:38:27 2010
From: greearb at candelatech.com (Ben Greear)
Date: Sun, 13 Jun 2010 21:38:27 -0700
Subject: [Xorp-users] Problem with network reachability
In-Reply-To: <576946.67943.qm@web37001.mail.mud.yahoo.com>
References: <576946.67943.qm@web37001.mail.mud.yahoo.com>
Message-ID: <4C15B243.505@candelatech.com>

On 06/13/2010 01:00 PM, Miroslav Todorovic wrote:
>
> Thank you!
>
> I didn't check routing tables in windows, but I did use traceroute for
> forwarding paths monitoring.
> If the packets could not be delivered to destination address, problem is
> router's forwarding. There is always one router, (first, the second or
> third on the path), in the network where the packets getting stuck. It
> could not realise how to forward packets to some other router, or its
> subnet.
> All router's routing tables are formed correctly.

If the routes are correct, then I have a hard time understanding
why it would not be forwarding packets.  Is ip_forward enabled?

Can you set up routes manually (w/out xorp running) to get it
working?

For multicast, make sure you have the time-to-live set to a large number
so that it will route through your network.

What version of xorp are you using?

Thanks,
Ben

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


From gs050486d at student.etf.rs  Mon Jun 14 05:16:10 2010
From: gs050486d at student.etf.rs (=?UTF-8?Q?Stevan_Grbi=C4=87_05/0486?=)
Date: Mon, 14 Jun 2010 14:16:10 +0200
Subject: [Xorp-users] one more issue with ospf and network topology
In-Reply-To: <4C15303C.2060204@candelatech.com>
References: <b2e5298394bbc8a20d31c2ebe0fe8417@student.etf.rs>
	<4C15303C.2060204@candelatech.com>
Message-ID: <1a825aeb5f51d9e7a4d98fff2d4673de@student.etf.rs>

Thanks Ben it works just fine, ie. it pings like a charm. 

On Sun, 13 Jun 2010 12:23:40 -0700, Ben Greear <greearb at candelatech.com>
wrote:
> On 06/13/2010 11:39 AM, Stevan Grbi? 05/0486 wrote:
>> Hi,
>> I'm trying to configure basic network topology like A=B=C=D(=E) using
>> OSPF4. My config of routers is posted down. (using VirtualBox and and
NIC
>> set to internal network, to  separate traffic from outside world, and
to
>> make more realistic scenario-like 3 (4 and 5) routers connected in
>> cascade). I'm  pinging routers to check for availability, as well as
>> route
>> advertising.
> 
>> Router A: eth0-1.1.1.2  area:1.1.1.0 | router-id: 1.1.1.2
>> Router C: eth0-2.2.2.3  area:2.2.2.0 | eth1-3.3.3.2  area:3.3.3.0 |
>> router-id 3.0.0.0
>> Router D: eth0-3.3.3.3  area:3.3.3.0 | eth1-4.4.4.2  area:4.4.4.0 |
>> router-id 4.0.0.0
>> etc.
>>
>> If someone can point me on mistake, or suggest me some other solution
for
>> this (cascade) scenario (of four and five routers).
> 
> Does it work if you put them all in the same area?
> 
> It may take something special to get different areas to share
> routes?
> 
> Thanks,
> Ben


From greearb at candelatech.com  Mon Jun 14 08:50:51 2010
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 14 Jun 2010 08:50:51 -0700
Subject: [Xorp-users] one more issue with ospf and network topology
In-Reply-To: <1a825aeb5f51d9e7a4d98fff2d4673de@student.etf.rs>
References: <b2e5298394bbc8a20d31c2ebe0fe8417@student.etf.rs>
	<4C15303C.2060204@candelatech.com>
	<1a825aeb5f51d9e7a4d98fff2d4673de@student.etf.rs>
Message-ID: <4C164FDB.6090106@candelatech.com>

On 06/14/2010 05:16 AM, Stevan Grbi? 05/0486 wrote:
> Thanks Ben it works just fine, ie. it pings like a charm.

We need to figure out what the deal is with multiple-area OSPF
networks..  Maybe needs some policy exports or something?


Thanks,
Ben


>
> On Sun, 13 Jun 2010 12:23:40 -0700, Ben Greear<greearb at candelatech.com>
> wrote:
>> On 06/13/2010 11:39 AM, Stevan Grbi? 05/0486 wrote:
>>> Hi,
>>> I'm trying to configure basic network topology like A=B=C=D(=E) using
>>> OSPF4. My config of routers is posted down. (using VirtualBox and and
> NIC
>>> set to internal network, to  separate traffic from outside world, and
> to
>>> make more realistic scenario-like 3 (4 and 5) routers connected in
>>> cascade). I'm  pinging routers to check for availability, as well as
>>> route
>>> advertising.
>>
>>> Router A: eth0-1.1.1.2  area:1.1.1.0 | router-id: 1.1.1.2
>>> Router C: eth0-2.2.2.3  area:2.2.2.0 | eth1-3.3.3.2  area:3.3.3.0 |
>>> router-id 3.0.0.0
>>> Router D: eth0-3.3.3.3  area:3.3.3.0 | eth1-4.4.4.2  area:4.4.4.0 |
>>> router-id 4.0.0.0
>>> etc.
>>>
>>> If someone can point me on mistake, or suggest me some other solution
> for
>>> this (cascade) scenario (of four and five routers).
>>
>> Does it work if you put them all in the same area?
>>
>> It may take something special to get different areas to share
>> routes?
>>
>> Thanks,
>> Ben


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


From gs050486d at student.etf.rs  Mon Jun 14 09:57:47 2010
From: gs050486d at student.etf.rs (=?UTF-8?Q?Stevan_Grbi=C4=87_05/0486?=)
Date: Mon, 14 Jun 2010 18:57:47 +0200
Subject: [Xorp-users] one more issue with ospf and network topology
In-Reply-To: <4C164FDB.6090106@candelatech.com>
References: <b2e5298394bbc8a20d31c2ebe0fe8417@student.etf.rs>
	<4C15303C.2060204@candelatech.com>
	<1a825aeb5f51d9e7a4d98fff2d4673de@student.etf.rs>
	<4C164FDB.6090106@candelatech.com>
Message-ID: <a7ddfb280965de1d52b5218ed045dc62@student.etf.rs>

I have also tried with policies, but again nothing happens (with multiple
areas), I have no idea why I couldn't ping over different areas.

On Mon, 14 Jun 2010 08:50:51 -0700, Ben Greear <greearb at candelatech.com>
wrote:
> On 06/14/2010 05:16 AM, Stevan Grbi? 05/0486 wrote:
>> Thanks Ben it works just fine, ie. it pings like a charm.
> 
> We need to figure out what the deal is with multiple-area OSPF
> networks..  Maybe needs some policy exports or something?
> 
> 
> Thanks,
> Ben
> 
> 
>>
>> On Sun, 13 Jun 2010 12:23:40 -0700, Ben Greear<greearb at candelatech.com>
>> wrote:
>>> On 06/13/2010 11:39 AM, Stevan Grbi? 05/0486 wrote:
>>>> Hi,
>>>> I'm trying to configure basic network topology like A=B=C=D(=E) using
>>>> OSPF4. My config of routers is posted down. (using VirtualBox and and
>> NIC
>>>> set to internal network, to  separate traffic from outside world, and
>> to
>>>> make more realistic scenario-like 3 (4 and 5) routers connected in
>>>> cascade). I'm  pinging routers to check for availability, as well as
>>>> route
>>>> advertising.
>>>
>>>> Router A: eth0-1.1.1.2  area:1.1.1.0 | router-id: 1.1.1.2
>>>> Router C: eth0-2.2.2.3  area:2.2.2.0 | eth1-3.3.3.2  area:3.3.3.0 |
>>>> router-id 3.0.0.0
>>>> Router D: eth0-3.3.3.3  area:3.3.3.0 | eth1-4.4.4.2  area:4.4.4.0 |
>>>> router-id 4.0.0.0
>>>> etc.
>>>>
>>>> If someone can point me on mistake, or suggest me some other solution
>> for
>>>> this (cascade) scenario (of four and five routers).
>>>
>>> Does it work if you put them all in the same area?
>>>
>>> It may take something special to get different areas to share
>>> routes?
>>>
>>> Thanks,
>>> Ben


From miro_todorovic at yahoo.com  Mon Jun 14 12:06:21 2010
From: miro_todorovic at yahoo.com (Miroslav Todorovic)
Date: Mon, 14 Jun 2010 12:06:21 -0700 (PDT)
Subject: [Xorp-users] Problem with network reachability
In-Reply-To: <4C15B243.505@candelatech.com>
Message-ID: <46934.24773.qm@web37001.mail.mud.yahoo.com>

I use xorp-1.6.

ip_forward was set to 0. I changed that to 1, but nothing happened with my reachability.



Something very strange happening for me. I find that one router could
not forward packets to its subnet when I ping from one VM, but when I
ping from another VM, which is attached on the same router as the first
one and need to take the same path to destination, the router? forwards
the packets correctly to the same destination.



I changed the network topology, and now I have network reachability.



But I noticed the problem with multicast streaming. 

I stream a file on one router's interface, and notice that router start
to send traffic on another interface although nobody ask for stream on
that interface. So, to manage that router stop sending stream on that
interface I need to set one VM to ask for the stream on that interface,
and then to stop streaming on that VM.

It is happening always on the same router's interface. Another works fine - there is traffic only if somebody ask for.

It seems like adjacent router is looking for the stream. When I shut
down that VM, router stops sending stream on that interface. But I just
have xorp running on adjacent Ubuntu VM.? 



Any idea what is happening?



Thank you!

From: Ben Greear <greearb at candelatech.com>
Subject: Re: [Xorp-users] Problem with network reachability
To: "Miroslav Todorovic" <miro_todorovic at yahoo.com>
Cc: "xorp comunity" <xorp-users at xorp.org>
Date: Sunday, June 13, 2010, 9:38 PM

On 06/13/2010 01:00 PM, Miroslav Todorovic wrote:
>
> Thank you!
>
> I didn't check routing tables in windows, but I did use traceroute for
> forwarding paths monitoring.
> If the packets could not be delivered to destination address, problem is
> router's forwarding. There is always one router, (first, the second or
> third on the path), in the network where the packets getting stuck. It
> could not realise how to forward packets to some other router, or its
> subnet.
> All router's routing tables are formed correctly.

If the routes are correct, then I have a hard time understanding
why it would not be forwarding packets.? Is ip_forward enabled?

Can you set up routes manually (w/out xorp running) to get it
working?

For multicast, make sure you have the time-to-live set to a large number
so that it will route through your network.

What version of xorp are you using?

Thanks,
Ben

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



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20100614/4818b550/attachment.html 

From greearb at candelatech.com  Mon Jun 14 14:25:39 2010
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 14 Jun 2010 14:25:39 -0700
Subject: [Xorp-users] Problem with network reachability
In-Reply-To: <46934.24773.qm@web37001.mail.mud.yahoo.com>
References: <46934.24773.qm@web37001.mail.mud.yahoo.com>
Message-ID: <4C169E53.8040508@candelatech.com>

On 06/14/2010 12:06 PM, Miroslav Todorovic wrote:
> I use xorp-1.6.
> ip_forward was set to 0. I changed that to 1, but nothing happened with
> my reachability.

Well, you will always want to enable ip_forward.

You might also try xorp.ct 1.8-CT release, though I'm not
sure that would help anything in this case.

>
> Something very strange happening for me. I find that one router could
> not forward packets to its subnet when I ping from one VM, but when I
> ping from another VM, which is attached on the same router as the first
> one and need to take the same path to destination, the router forwards
> the packets correctly to the same destination.

You probably need to use tcpdump and manually inspect routes to make
sure packets go where you think they should.  It's easy to mess things
up when you are virtualizing everything.

>
> I changed the network topology, and now I have network reachability.
>
> But I noticed the problem with multicast streaming.
> I stream a file on one router's interface, and notice that router start
> to send traffic on another interface although nobody ask for stream on
> that interface. So, to manage that router stop sending stream on that
> interface I need to set one VM to ask for the stream on that interface,
> and then to stop streaming on that VM.
> It is happening always on the same router's interface. Another works
> fine - there is traffic only if somebody ask for.
> It seems like adjacent router is looking for the stream. When I shut
> down that VM, router stops sending stream on that interface. But I just
> have xorp running on adjacent Ubuntu VM.
>
> Any idea what is happening?

No..sorry.  Multicast routing is even trickier than normal routing.
One thing:  slow streams may be routed differently than fast steams,
so you might make sure you are running a faster stream for your testing.

Thanks,
Ben

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


From qmail at top-consulting.net  Wed Jun 16 15:53:11 2010
From: qmail at top-consulting.net (qmail at top-consulting.net)
Date: Wed, 16 Jun 2010 18:53:11 -0400
Subject: [Xorp-users] Multicast Routing over gif0 tunnel in FreeBSD 8.0
Message-ID: <20100616185311.101471ldix0jresk@mail.top-consulting.net>

I'm trying to configure Xorp 1.6 on FreebSD 8.0 to route multicast  
packets between two networks.

The Xorp box is directly connected to the client over bge0 and to a  
Cisco router over a gif0 tunnel.

ifconfigs are:

bge0:  
flags=8b43<UP,BROADCAST,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST>  
metric 0 mtu 1500
         options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
         ether 00:00:1a:1a:6e:1a
         inet 172.31.2.1 netmask 0xffffff00 broadcast 172.31.2.255
         media: Ethernet autoselect (100baseTX <full-duplex>)
         status: active


gif0: flags=8251<UP,POINTOPOINT,RUNNING,ALLMULTI,MULTICAST> metric 0 mtu 1500
         tunnel inet 216.X.X.X --> 70.X.X.X
         inet 172.31.1.2 --> 172.31.1.255 netmask 0xffffff00
         options=1<ACCEPT_REV_ETHIP_VER>


The configuration file is this:
interfaces {
     restore-original-config-on-shutdown: false
     interface bge0 {
         description: "data interface"
         disable: false
         /* default-system-config */
         vif bge0 {
             disable: false
             address 172.31.2.1 {
                 prefix-length: 24
                 broadcast: 172.31.2.255
                 disable: false
             }
         }
     }

     interface gif0 {
         description: "data interface"
         disable: false
         /* default-system-config */
         vif gif0 {
             disable: false
             address 172.31.1.2 {
                 prefix-length: 24
                 multicast-capable:true
                 disable: false
                 broadcast: 172.31.1.255
             }
         }
     }
}

fea {
     unicast-forwarding4 {
         disable: false
     }

     unicast-forwarding6 {
         disable: false
     }
}

plumbing {
     mfea4 {
         disable: false
         interface bge0 {
             vif bge0 {
                 disable: false
             }
         }

         interface gif0 {
             vif gif0 {
                 disable: false
             }
         }

         interface register_vif {
             vif register_vif {
                 /* Note: this vif should be always enabled */
                 disable: false
             }
         }
         traceoptions {
             flag all {
                 disable: false
             }
         }
     }
}

protocols {

     static {
         route 10.16.0.0/16 {
             next-hop: 172.31.1.1
             metric: 1
         }

         mrib-route 10.16.0.0/16 {
             next-hop: 172.31.1.1
             metric: 1
         }

         route 10.253.248.0/24 {
             next-hop: 172.31.1.1
             metric: 1
         }

         mrib-route 10.253.248.0/24 {
             next-hop: 172.31.1.1
             metric: 1
         }

     }

     igmp {
         disable: false
         interface bge0 {
             vif bge0 {
                 disable: false
             }
         }

         interface gif0 {
             vif gif0 {
                 disable: false
             }
         }

         traceoptions {
             flag all {
                 disable: false
             }
         }
     }

     pimsm4 {
         disable: false
         interface bge0 {
             vif bge0 {
                 disable: false
             }
         }

         interface gif0 {
             vif gif0 {
                 disable: false
             }
         }

         interface register_vif {
             vif register_vif {
                 /* Note: this vif should be always enabled */
                 disable: false
             }
         }

         static-rps {
             rp 10.16.0.64{
                 group-prefix 224.0.0.0/4 {
                     /* rp-priority: 192 */
                     /* hash-mask-len: 30 */
                 }
             }
         }

         switch-to-spt-threshold {
             /* approx. 1K bytes/s (10Kbps) threshold */
             disable: false
             interval: 100
             bytes: 102400
         }

         traceoptions {
             flag all {
                 disable: false
             }
         }
     }

     fib2mrib {
         disable: false
     }
}


show igmp group
Interface    Group           Source          LastReported Timeout V State
bge0         224.0.0.2       0.0.0.0         172.31.2.1       216 2     E
bge0         224.0.0.22      0.0.0.0         172.31.2.1       215 2     E
gif0         224.0.0.2       0.0.0.0         172.31.1.2       215 2     E
gif0         224.0.0.22      0.0.0.0         172.31.1.2       216 2     E


show pim join
Group           Source          RP              Flags

show pim neighbors
Interface    DRpriority NeighborAddr    V Mode   Holdtime Timeout
gif0                  1 172.31.1.1      2 Sparse      105      97

show pim rps
RP              Type      Pri Holdtime Timeout ActiveGroups GroupPrefix
10.16.0.64      static    192       -1      -1            0 224.0.0.0/4


Is there anything that I am missing or doing wrong ?

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



From jmitchell at ll.mit.edu  Thu Jun 17 06:39:34 2010
From: jmitchell at ll.mit.edu (Jeff Mitchell)
Date: Thu, 17 Jun 2010 09:39:34 -0400
Subject: [Xorp-users] Reread config file?
Message-ID: <4C1A2596.10801@ll.mit.edu>

Is there a way to tell XORP to read a specific configuration file from 
the command line?

I'd like to be able to adjust the config file and have running xorp read 
and commit it, but xorp_rtrmgr doesn't seem to have a way to do this, 
and I'm trying to avoid having to code it up in some expect-y way.

Thanks,
Jeff


From greearb at candelatech.com  Thu Jun 17 11:53:37 2010
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 17 Jun 2010 11:53:37 -0700
Subject: [Xorp-users] Reread config file?
In-Reply-To: <4C1A2596.10801@ll.mit.edu>
References: <4C1A2596.10801@ll.mit.edu>
Message-ID: <4C1A6F31.5060205@candelatech.com>

On 06/17/2010 06:39 AM, Jeff Mitchell wrote:
> Is there a way to tell XORP to read a specific configuration file from
> the command line?
>
> I'd like to be able to adjust the config file and have running xorp read
> and commit it, but xorp_rtrmgr doesn't seem to have a way to do this,
> and I'm trying to avoid having to code it up in some expect-y way.

There is no way to re-read.  You can pass commands in via xorpsh -c 'whatever'
but it is hard to do any proper error checking once you send stuff to
xorpsh (we attempt to do all error checking before sending any commands
into xorpsh and expect the xorpsh commands to always work).

A patch to enable re-reading a config file would be welcome :)

Thanks,
Ben

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


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


From qmail at top-consulting.net  Thu Jun 17 12:33:36 2010
From: qmail at top-consulting.net (qmail at top-consulting.net)
Date: Thu, 17 Jun 2010 15:33:36 -0400
Subject: [Xorp-users] Multicast Routing over gif0 tunnel in FreeBSD 8.0
In-Reply-To: <20100616185311.101471ldix0jresk@mail.top-consulting.net>
References: <20100616185311.101471ldix0jresk@mail.top-consulting.net>
Message-ID: <20100617153336.21191qdycikyiqhw@mail.top-consulting.net>

More informations:

If we replace the FreeBSD Xorp box with a Cisco router configured with  
PIM it works right away.

The only configs on the Cisco are:

ip pim bidir-enable
ip pim rp-address 10.16.0.64

On the Xorp config I entered:
static-rps {
             rp 10.16.0.64{
                 group-prefix 224.0.0.0/4 {
                     rp-priority: 1
                     /* hash-mask-len: 30 */
                 }
             }
         }



and I see messages like this in the log:

172.31.1.2 is my end of the tunnel
172.31.1.1 is the other end

[ 2010/06/17 14:13:13 TRACE xorp_pimsm4 PIM ] RX PIM_HELLO from  
172.31.1.1 to 224.0.0.13 on vif gif0
[ 2010/06/17 14:13:27 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from  
172.31.1.2 to 224.0.0.13 on vif gif0
[ 2010/06/17 14:13:43 TRACE xorp_pimsm4 PIM ] RX PIM_HELLO from  
172.31.1.1 to 224.0.0.13 on vif gif0
[ 2010/06/17 14:13:57 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from  
172.31.1.2 to 224.0.0.13 on vif gif0
[ 2010/06/17 14:14:13 TRACE xorp_pimsm4 PIM ] RX PIM_HELLO from  
172.31.1.1 to 224.0.0.13 on vif gif0
[ 2010/06/17 14:14:27 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from  
172.31.1.2 to 224.0.0.13 on vif gif0

but it doesn't go any further than that. what am I missing something ?
> I'm trying to configure Xorp 1.6 on FreebSD 8.0 to route multicast
> packets between two networks.
>
> The Xorp box is directly connected to the client over bge0 and to a
> Cisco router over a gif0 tunnel.
>
> ifconfigs are:
>
> bge0:
> flags=8b43<UP,BROADCAST,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST>
> metric 0 mtu 1500
>          options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
>          ether 00:00:1a:1a:6e:1a
>          inet 172.31.2.1 netmask 0xffffff00 broadcast 172.31.2.255
>          media: Ethernet autoselect (100baseTX <full-duplex>)
>          status: active
>
>
> gif0: flags=8251<UP,POINTOPOINT,RUNNING,ALLMULTI,MULTICAST> metric 0 mtu 1500
>          tunnel inet 216.X.X.X --> 70.X.X.X
>          inet 172.31.1.2 --> 172.31.1.255 netmask 0xffffff00
>          options=1<ACCEPT_REV_ETHIP_VER>
>
>
> The configuration file is this:
> interfaces {
>      restore-original-config-on-shutdown: false
>      interface bge0 {
>          description: "data interface"
>          disable: false
>          /* default-system-config */
>          vif bge0 {
>              disable: false
>              address 172.31.2.1 {
>                  prefix-length: 24
>                  broadcast: 172.31.2.255
>                  disable: false
>              }
>          }
>      }
>
>      interface gif0 {
>          description: "data interface"
>          disable: false
>          /* default-system-config */
>          vif gif0 {
>              disable: false
>              address 172.31.1.2 {
>                  prefix-length: 24
>                  multicast-capable:true
>                  disable: false
>                  broadcast: 172.31.1.255
>              }
>          }
>      }
> }
>
> fea {
>      unicast-forwarding4 {
>          disable: false
>      }
>
>      unicast-forwarding6 {
>          disable: false
>      }
> }
>
> plumbing {
>      mfea4 {
>          disable: false
>          interface bge0 {
>              vif bge0 {
>                  disable: false
>              }
>          }
>
>          interface gif0 {
>              vif gif0 {
>                  disable: false
>              }
>          }
>
>          interface register_vif {
>              vif register_vif {
>                  /* Note: this vif should be always enabled */
>                  disable: false
>              }
>          }
>          traceoptions {
>              flag all {
>                  disable: false
>              }
>          }
>      }
> }
>
> protocols {
>
>      static {
>          route 10.16.0.0/16 {
>              next-hop: 172.31.1.1
>              metric: 1
>          }
>
>          mrib-route 10.16.0.0/16 {
>              next-hop: 172.31.1.1
>              metric: 1
>          }
>
>          route 10.253.248.0/24 {
>              next-hop: 172.31.1.1
>              metric: 1
>          }
>
>          mrib-route 10.253.248.0/24 {
>              next-hop: 172.31.1.1
>              metric: 1
>          }
>
>      }
>
>      igmp {
>          disable: false
>          interface bge0 {
>              vif bge0 {
>                  disable: false
>              }
>          }
>
>          interface gif0 {
>              vif gif0 {
>                  disable: false
>              }
>          }
>
>          traceoptions {
>              flag all {
>                  disable: false
>              }
>          }
>      }
>
>      pimsm4 {
>          disable: false
>          interface bge0 {
>              vif bge0 {
>                  disable: false
>              }
>          }
>
>          interface gif0 {
>              vif gif0 {
>                  disable: false
>              }
>          }
>
>          interface register_vif {
>              vif register_vif {
>                  /* Note: this vif should be always enabled */
>                  disable: false
>              }
>          }
>
>          static-rps {
>              rp 10.16.0.64{
>                  group-prefix 224.0.0.0/4 {
>                      /* rp-priority: 192 */
>                      /* hash-mask-len: 30 */
>                  }
>              }
>          }
>
>          switch-to-spt-threshold {
>              /* approx. 1K bytes/s (10Kbps) threshold */
>              disable: false
>              interval: 100
>              bytes: 102400
>          }
>
>          traceoptions {
>              flag all {
>                  disable: false
>              }
>          }
>      }
>
>      fib2mrib {
>          disable: false
>      }
> }
>
>
> show igmp group
> Interface    Group           Source          LastReported Timeout V State
> bge0         224.0.0.2       0.0.0.0         172.31.2.1       216 2     E
> bge0         224.0.0.22      0.0.0.0         172.31.2.1       215 2     E
> gif0         224.0.0.2       0.0.0.0         172.31.1.2       215 2     E
> gif0         224.0.0.22      0.0.0.0         172.31.1.2       216 2     E
>
>
> show pim join
> Group           Source          RP              Flags
>
> show pim neighbors
> Interface    DRpriority NeighborAddr    V Mode   Holdtime Timeout
> gif0                  1 172.31.1.1      2 Sparse      105      97
>
> show pim rps
> RP              Type      Pri Holdtime Timeout ActiveGroups GroupPrefix
> 10.16.0.64      static    192       -1      -1            0 224.0.0.0/4
>
>
> Is there anything that I am missing or doing wrong ?
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
>
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
>



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



From michael.vincent at ll.mit.edu  Fri Jun 18 09:03:51 2010
From: michael.vincent at ll.mit.edu (Vincent, Michael - 0665 - MITLL)
Date: Fri, 18 Jun 2010 12:03:51 -0400
Subject: [Xorp-users] OSPF point-to-multipoint issue
Message-ID: <201006181604.o5IG48SV000641@pork.ICSI.Berkeley.EDU>

We're doing some testing with 6 Redhat VM's.

# uname -a
Linux nlet-89-1 2.6.18-194.el5.g63 #1 SMP Wed Apr 7 00:08:09 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux

All the VM's have an interface to 172.16.1.0 /24 on which OSPF is configured in point to multipoint mode creating a full-mesh.

We're using a linux kernel module to selectively drop packets between certain hosts (based on MAC address) to simulate link loss.  We expect OSPF to route around the failures by multi-hopping to hosts it can still reach.  This works fine.

----
EXAMPLE:
- host IP's are host numbers
- IP's are on interface eth1
- eth1 is OSPF point-to-multipoint *

        host1      host2

host3     172.16.1.0/24    host4

    host5              host6

* Example config for host1
protocols {
    ospf4 {
        router-id: 10.10.1.1
        area 0.0.0.0 {
            area-type: "normal"
            interface eth1 {
                link-type: "p2m"
                vif eth1 {
                    address 172.16.1.1 {
                        hello-interval: 1
                        router-dead-interval: 4
                        neighbor 172.16.1.2 {
                            router-id: 10.10.1.2
                        }
...
----

As we simulate loss of link between host1 and host3, host1 continues to forward packets to host3 via a new host route created to host5.  This is verified by a "route -n" from the linux command line also.

ISSUE:
When we re-establish the link between host1 and host3, host1 *CONTINUES* to forward packets to host3 via the host route created to host5.  OSPF does *NOT* recover and remove the host route from the table.  This is verified by a "route -n" from the linux command line also.


QUESTION:
Is there some configuration option I'm missing that will allow OSPF to remove host routes from the routing table (and kernel/linux routing table) when OSPF converges?


It's important to note we did this exact experiment with Quagga 0.99.16 (ospfd) and it behaved as expected - OSPF recovered and the multi-hop host route was removed.


    Cheers.

-- 
Michael J. Vincent
Group 65 - Advanced Networks and Applications
MIT Lincoln Laboratory
244 Wood Street
Lexington, MA 02420
Office:  +1.781.981.3459




From greearb at candelatech.com  Fri Jun 18 10:13:51 2010
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 18 Jun 2010 10:13:51 -0700
Subject: [Xorp-users] OSPF point-to-multipoint issue
In-Reply-To: <201006181604.o5IG48SV000641@pork.ICSI.Berkeley.EDU>
References: <201006181604.o5IG48SV000641@pork.ICSI.Berkeley.EDU>
Message-ID: <4C1BA94F.2070203@candelatech.com>

On 06/18/2010 09:03 AM, Vincent, Michael - 0665 - MITLL wrote:
> We're doing some testing with 6 Redhat VM's.
>
> # uname -a
> Linux nlet-89-1 2.6.18-194.el5.g63 #1 SMP Wed Apr 7 00:08:09 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux
>
> All the VM's have an interface to 172.16.1.0 /24 on which OSPF is configured in point to multipoint mode creating a full-mesh.
>
> We're using a linux kernel module to selectively drop packets between certain hosts (based on MAC address) to simulate link loss.  We expect OSPF to route around the failures by multi-hopping to hosts it can still reach.  This works fine.
>
> ----
> EXAMPLE:
> - host IP's are host numbers
> - IP's are on interface eth1
> - eth1 is OSPF point-to-multipoint *
>
>          host1      host2
>
> host3     172.16.1.0/24    host4
>
>      host5              host6
>
> * Example config for host1
> protocols {
>      ospf4 {
>          router-id: 10.10.1.1
>          area 0.0.0.0 {
>              area-type: "normal"
>              interface eth1 {
>                  link-type: "p2m"
>                  vif eth1 {
>                      address 172.16.1.1 {
>                          hello-interval: 1
>                          router-dead-interval: 4
>                          neighbor 172.16.1.2 {
>                              router-id: 10.10.1.2
>                          }
> ...
> ----
>
> As we simulate loss of link between host1 and host3, host1 continues to forward packets to host3 via a new host route created to host5.  This is verified by a "route -n" from the linux command line also.
>
> ISSUE:
> When we re-establish the link between host1 and host3, host1 *CONTINUES* to forward packets to host3 via the host route created to host5.  OSPF does *NOT* recover and remove the host route from the table.  This is verified by a "route -n" from the linux command line also.

If you look at the OSPF neighbors, are they properly re-established when you rejoin the link?

We do the same test, except with emulated ethernet links instead of 'p2m' connections,
and the rejoins appear to work correctly.

Are you using ospf costs to make one route more preferred than the other?  If all costs
are the same, then it won't flip back to the original route.

Thanks,
Ben

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


From michael.vincent at ll.mit.edu  Fri Jun 18 10:36:02 2010
From: michael.vincent at ll.mit.edu (Vincent, Michael - 0665 - MITLL)
Date: Fri, 18 Jun 2010 13:36:02 -0400
Subject: [Xorp-users] OSPF point-to-multipoint issue
In-Reply-To: <4C1BA94F.2070203@candelatech.com>
References: <201006181604.o5IG48SV000641@pork.ICSI.Berkeley.EDU>
	<4C1BA94F.2070203@candelatech.com>
Message-ID: <201006181736.o5IHaI9I002214@pork.ICSI.Berkeley.EDU>

No, the OSPF neighbors do not go to 'FULL', they stay 'DOWN'.  Note that we changed timers, hello/dead = 1/4.  We also did this with the default (10/40) and got the same (non-working) result.


    Cheers.

-- 
Michael J. Vincent
Group 65 - Advanced Networks and Applications
MIT Lincoln Laboratory
244 Wood Street
Lexington, MA 02420
Office:  +1.781.981.3459


-----Original Message-----
From: Ben Greear [mailto:greearb at candelatech.com] 
Sent: Friday, June 18, 2010 1:14 PM
To: Vincent, Michael - 0665 - MITLL
Cc: xorp-users at xorp.org; Zuena, John - 0665 - MITLL
Subject: Re: [Xorp-users] OSPF point-to-multipoint issue

On 06/18/2010 09:03 AM, Vincent, Michael - 0665 - MITLL wrote:
> We're doing some testing with 6 Redhat VM's.
>
> # uname -a
> Linux nlet-89-1 2.6.18-194.el5.g63 #1 SMP Wed Apr 7 00:08:09 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux
>
> All the VM's have an interface to 172.16.1.0 /24 on which OSPF is configured in point to multipoint mode creating a full-mesh.
>
> We're using a linux kernel module to selectively drop packets between certain hosts (based on MAC address) to simulate link loss.  We expect OSPF to route around the failures by multi-hopping to hosts it can still reach.  This works fine.
>
> ----
> EXAMPLE:
> - host IP's are host numbers
> - IP's are on interface eth1
> - eth1 is OSPF point-to-multipoint *
>
>          host1      host2
>
> host3     172.16.1.0/24    host4
>
>      host5              host6
>
> * Example config for host1
> protocols {
>      ospf4 {
>          router-id: 10.10.1.1
>          area 0.0.0.0 {
>              area-type: "normal"
>              interface eth1 {
>                  link-type: "p2m"
>                  vif eth1 {
>                      address 172.16.1.1 {
>                          hello-interval: 1
>                          router-dead-interval: 4
>                          neighbor 172.16.1.2 {
>                              router-id: 10.10.1.2
>                          }
> ...
> ----
>
> As we simulate loss of link between host1 and host3, host1 continues to forward packets to host3 via a new host route created to host5.  This is verified by a "route -n" from the linux command line also.
>
> ISSUE:
> When we re-establish the link between host1 and host3, host1 *CONTINUES* to forward packets to host3 via the host route created to host5.  OSPF does *NOT* recover and remove the host route from the table.  This is verified by a "route -n" from the linux command line also.

If you look at the OSPF neighbors, are they properly re-established when you rejoin the link?

We do the same test, except with emulated ethernet links instead of 'p2m' connections,
and the rejoins appear to work correctly.

Are you using ospf costs to make one route more preferred than the other?  If all costs
are the same, then it won't flip back to the original route.

Thanks,
Ben

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


From greearb at candelatech.com  Fri Jun 18 11:19:34 2010
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 18 Jun 2010 11:19:34 -0700
Subject: [Xorp-users] OSPF point-to-multipoint issue
In-Reply-To: <201006181736.o5IHaCea021486@ns3.lanforge.com>
References: <201006181604.o5IG48SV000641@pork.ICSI.Berkeley.EDU>
	<4C1BA94F.2070203@candelatech.com>
	<201006181736.o5IHaCea021486@ns3.lanforge.com>
Message-ID: <4C1BB8B6.7000303@candelatech.com>

On 06/18/2010 10:36 AM, Vincent, Michael - 0665 - MITLL wrote:
> No, the OSPF neighbors do not go to 'FULL', they stay 'DOWN'.  Note that we changed timers, hello/dead = 1/4.  We also did this with the default (10/40) and got the same (non-working) result.

Are your interfaces up (according to Xorp)?

I fixed some problems in OSPF in xorp.ct (a year or so ago) that were related to interfaces
being improperly shown as DOWN in OSPF even though they were really
up.  That said, I think there may still be some races in that area...
I left a lot of debugging in the logs so if that turns out to be the problem,
plz send me the logs and/or investigate them yourself.

Thanks,
Ben

>
>
>      Cheers.
>


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


From michael.vincent at ll.mit.edu  Fri Jun 18 11:43:41 2010
From: michael.vincent at ll.mit.edu (Vincent, Michael - 0665 - MITLL)
Date: Fri, 18 Jun 2010 14:43:41 -0400
Subject: [Xorp-users] OSPF point-to-multipoint issue
In-Reply-To: <4C1BB8B6.7000303@candelatech.com>
References: <201006181604.o5IG48SV000641@pork.ICSI.Berkeley.EDU>
	<4C1BA94F.2070203@candelatech.com>
	<201006181736.o5IHaCea021486@ns3.lanforge.com>
	<4C1BB8B6.7000303@candelatech.com>
Message-ID: <201006181844.o5IIi50R003539@pork.ICSI.Berkeley.EDU>

Yes, show interfaces shows the interface in question (the ones OSPF does peering on) as ENABLED.

Additionally, if we exit from xorpsh and remove the offending host routes from linux (route del x.x.x.x) (the ones Xorp OSPF should be removing when OSPF converges) the OSPF sessions are re-established.  This is further feeding my belief that Xorp is not properly removing OSPF routes during OSPF convergence.



    Cheers.

-- 
Michael J. Vincent
Group 65 - Advanced Networks and Applications
MIT Lincoln Laboratory
244 Wood Street
Lexington, MA 02420
Office:  +1.781.981.3459


-----Original Message-----
From: Ben Greear [mailto:greearb at candelatech.com] 
Sent: Friday, June 18, 2010 2:20 PM
To: Vincent, Michael - 0665 - MITLL
Cc: xorp-users at xorp.org; Zuena, John - 0665 - MITLL
Subject: Re: [Xorp-users] OSPF point-to-multipoint issue

On 06/18/2010 10:36 AM, Vincent, Michael - 0665 - MITLL wrote:
> No, the OSPF neighbors do not go to 'FULL', they stay 'DOWN'.  Note that we changed timers, hello/dead = 1/4.  We also did this with the default (10/40) and got the same (non-working) result.

Are your interfaces up (according to Xorp)?

I fixed some problems in OSPF in xorp.ct (a year or so ago) that were related to interfaces
being improperly shown as DOWN in OSPF even though they were really
up.  That said, I think there may still be some races in that area...
I left a lot of debugging in the logs so if that turns out to be the problem,
plz send me the logs and/or investigate them yourself.

Thanks,
Ben

>
>
>      Cheers.
>


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



From greearb at candelatech.com  Fri Jun 18 11:51:53 2010
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 18 Jun 2010 11:51:53 -0700
Subject: [Xorp-users] OSPF point-to-multipoint issue
In-Reply-To: <201006181843.o5IIhwLw027296@ns3.lanforge.com>
References: <201006181604.o5IG48SV000641@pork.ICSI.Berkeley.EDU>
	<4C1BA94F.2070203@candelatech.com>
	<201006181736.o5IHaCea021486@ns3.lanforge.com>
	<4C1BB8B6.7000303@candelatech.com>
	<201006181843.o5IIhwLw027296@ns3.lanforge.com>
Message-ID: <4C1BC049.5070704@candelatech.com>

On 06/18/2010 11:43 AM, Vincent, Michael - 0665 - MITLL wrote:
> Yes, show interfaces shows the interface in question (the ones OSPF does peering on) as ENABLED.
>
> Additionally, if we exit from xorpsh and remove the offending host routes from linux (route del x.x.x.x) (the ones Xorp OSPF should be removing when OSPF converges) the OSPF sessions are re-established.  This is further feeding my belief that Xorp is not properly removing OSPF routes during OSPF convergence.

Ahh, so to get to the original peer, it needs to first remove the routes on the secondary link?

Maybe xorp doesn't bother removing routes until it establishes FULL access with the
new router, which would be a neat catch-22 scenario in your case.

Can you post the results of 'show ospf4 neighbor'
for each of your steps:

*  Initial config  (This is working OK, right)
*  First link failure (And this is OK too)
*  Second link failure  ( But this fails to switch back to initial config setup??)

Thanks,
Ben

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


From michael.vincent at ll.mit.edu  Fri Jun 18 12:21:11 2010
From: michael.vincent at ll.mit.edu (Vincent, Michael - 0665 - MITLL)
Date: Fri, 18 Jun 2010 15:21:11 -0400
Subject: [Xorp-users] OSPF point-to-multipoint issue
In-Reply-To: <4C1BC049.5070704@candelatech.com>
References: <201006181604.o5IG48SV000641@pork.ICSI.Berkeley.EDU>
	<4C1BA94F.2070203@candelatech.com>
	<201006181736.o5IHaCea021486@ns3.lanforge.com>
	<4C1BB8B6.7000303@candelatech.com>
	<201006181843.o5IIhwLw027296@ns3.lanforge.com>
	<4C1BC049.5070704@candelatech.com>
Message-ID: <201006181921.o5IJLZoM004335@pork.ICSI.Berkeley.EDU>

> Ahh, so to get to the original peer, it needs to first remove the routes on the secondary link?

Not necessarily, you can still get there (data path) through the multi-hop path; however, OSPF won't form an adjacency over a multi hop.  So to that point, yes, the host route that OSPF added needs to be removed for OSPF to then re-form it's adjacency.  Catch-22 sounds appropriate.


I've only included the outputs for nodes 1 and 3 as that is what the example is talking about.  The actual experiment fails other links also and thus more peering sessions go down and do not re-establish.


START:
root at nlet-89-1> show ospf4 neighbor
  Address         Interface             State      ID              Pri  Dead
172.16.1.2       eth1/eth1              Full      10.10.1.2        128     2
172.16.1.3       eth1/eth1              Full      10.10.1.3        128     3
172.16.1.4       eth1/eth1              Full      10.10.1.5        128     3
172.16.1.5       eth1/eth1              Full      10.10.1.5        128     2
172.16.1.6       eth1/eth1              Full      10.10.1.6        128     2
172.17.2.1       eth2.1212/eth2.1212    Full      10.10.1.8          1    31
root at nlet-89-1>

--

[root at nlet-89-3 DISA]# xorpsh -c "show ospf4 neighbor"
Welcome to XORP on nlet-89-3
root at nlet-89-3> show ospf4 neighbor
  Address         Interface             State      ID              Pri  Dead
172.16.1.1       eth1/eth1              Full      10.10.1.1        128     2
172.16.1.2       eth1/eth1              Full      10.10.1.2        128     3
172.16.1.4       eth1/eth1              Full      10.10.1.4        128     2
172.16.1.5       eth1/eth1              Full      10.10.1.5        128     3
172.16.1.6       eth1/eth1              Full      10.10.1.6        128     3
root at nlet-89-3> [root at nlet-89-3 DISA]#


INTERMEDIATE:
root at nlet-89-1> show ospf4 neighbor
  Address         Interface             State      ID              Pri  Dead
172.16.1.2       eth1/eth1              Down      10.10.1.2          0     0
172.16.1.3       eth1/eth1              Full      10.10.1.3        128     3
172.16.1.4       eth1/eth1              Down      10.10.1.5          0     0
172.16.1.5       eth1/eth1              Down      10.10.1.5          0     0
172.16.1.6       eth1/eth1              Down      10.10.1.6          0     0
172.17.2.1       eth2.1212/eth2.1212    Full      10.10.1.8          1    31
root at nlet-89-1>

--

[root at nlet-89-3 DISA]# xorpsh -c "show ospf4 neighbor"
Welcome to XORP on nlet-89-3
root at nlet-89-3> show ospf4 neighbor
  Address         Interface             State      ID              Pri  Dead
172.16.1.1       eth1/eth1              Down      10.10.1.1          0     0
172.16.1.2       eth1/eth1              Down      10.10.1.2          0     0
172.16.1.4       eth1/eth1              Full      10.10.1.4        128     2
172.16.1.5       eth1/eth1              Down      10.10.1.5          0     0
172.16.1.6       eth1/eth1              Down      10.10.1.6          0     0
root at nlet-89-3> [root at nlet-89-3 DISA]#


FINAL:
root at nlet-89-1> show ospf4 neighbor
  Address         Interface             State      ID              Pri  Dead
172.16.1.2       eth1/eth1              Down      10.10.1.2          0     0
172.16.1.3       eth1/eth1              Full      10.10.1.3        128     3
172.16.1.4       eth1/eth1              Down      10.10.1.5          0     0
172.16.1.5       eth1/eth1              Down      10.10.1.5          0     0
172.16.1.6       eth1/eth1              Down      10.10.1.6          0     0
172.17.2.1       eth2.1212/eth2.1212    Full      10.10.1.8          1    31
root at nlet-89-1>

--

[root at nlet-89-3 DISA]# xorpsh -c "show ospf4 neighbor"
Welcome to XORP on nlet-89-3
root at nlet-89-3> show ospf4 neighbor
  Address         Interface             State      ID              Pri  Dead
172.16.1.1       eth1/eth1              Down      10.10.1.1          0     0
172.16.1.2       eth1/eth1              Down      10.10.1.2          0     0
172.16.1.4       eth1/eth1              Full      10.10.1.4        128     2
172.16.1.5       eth1/eth1              Down      10.10.1.5          0     0
172.16.1.6       eth1/eth1              Down      10.10.1.6          0     0
root at nlet-89-3> [root at nlet-89-3 DISA]#



    Cheers.

-- 
Michael J. Vincent
Group 65 - Advanced Networks and Applications
MIT Lincoln Laboratory
244 Wood Street
Lexington, MA 02420
Office:  +1.781.981.3459


-----Original Message-----
From: Ben Greear [mailto:greearb at candelatech.com] 
Sent: Friday, June 18, 2010 2:52 PM
To: Vincent, Michael - 0665 - MITLL
Cc: xorp-users at xorp.org; Zuena, John - 0665 - MITLL
Subject: Re: [Xorp-users] OSPF point-to-multipoint issue

On 06/18/2010 11:43 AM, Vincent, Michael - 0665 - MITLL wrote:
> Yes, show interfaces shows the interface in question (the ones OSPF does peering on) as ENABLED.
>
> Additionally, if we exit from xorpsh and remove the offending host routes from linux (route del x.x.x.x) (the ones Xorp OSPF should be removing when OSPF converges) the OSPF sessions are re-established.  This is further feeding my belief that Xorp is not properly removing OSPF routes during OSPF convergence.

Ahh, so to get to the original peer, it needs to first remove the routes on the secondary link?

Maybe xorp doesn't bother removing routes until it establishes FULL access with the
new router, which would be a neat catch-22 scenario in your case.

Can you post the results of 'show ospf4 neighbor'
for each of your steps:

*  Initial config  (This is working OK, right)
*  First link failure (And this is OK too)
*  Second link failure  ( But this fails to switch back to initial config setup??)

Thanks,
Ben

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



From greearb at candelatech.com  Fri Jun 18 12:33:45 2010
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 18 Jun 2010 12:33:45 -0700
Subject: [Xorp-users] OSPF point-to-multipoint issue
In-Reply-To: <201006181921.o5IJLT6M030590@ns3.lanforge.com>
References: <201006181604.o5IG48SV000641@pork.ICSI.Berkeley.EDU>
	<4C1BA94F.2070203@candelatech.com>
	<201006181736.o5IHaCea021486@ns3.lanforge.com>
	<4C1BB8B6.7000303@candelatech.com>
	<201006181843.o5IIhwLw027296@ns3.lanforge.com>
	<4C1BC049.5070704@candelatech.com>
	<201006181921.o5IJLT6M030590@ns3.lanforge.com>
Message-ID: <4C1BCA19.7090704@candelatech.com>

On 06/18/2010 12:21 PM, Vincent, Michael - 0665 - MITLL wrote:
>> Ahh, so to get to the original peer, it needs to first remove the routes on the secondary link?
>
> Not necessarily, you can still get there (data path) through the multi-hop path; however, OSPF won't form an adjacency over a multi hop.  So to that point, yes, the host route that OSPF added needs to be removed for OSPF to then re-form it's adjacency.  Catch-22 sounds appropriate.
>
>
> I've only included the outputs for nodes 1 and 3 as that is what the example is talking about.  The actual experiment fails other links also and thus more peering sessions go down and do not re-establish.
>
>
> START:
> root at nlet-89-1>  show ospf4 neighbor
>    Address         Interface             State      ID              Pri  Dead
> 172.16.1.2       eth1/eth1              Full      10.10.1.2        128     2
> 172.16.1.3       eth1/eth1              Full      10.10.1.3        128     3
> 172.16.1.4       eth1/eth1              Full      10.10.1.5        128     3
> 172.16.1.5       eth1/eth1              Full      10.10.1.5        128     2
> 172.16.1.6       eth1/eth1              Full      10.10.1.6        128     2
> 172.17.2.1       eth2.1212/eth2.1212    Full      10.10.1.8          1    31
> root at nlet-89-1>
>
> --
>
> [root at nlet-89-3 DISA]# xorpsh -c "show ospf4 neighbor"
> Welcome to XORP on nlet-89-3
> root at nlet-89-3>  show ospf4 neighbor
>    Address         Interface             State      ID              Pri  Dead
> 172.16.1.1       eth1/eth1              Full      10.10.1.1        128     2
> 172.16.1.2       eth1/eth1              Full      10.10.1.2        128     3
> 172.16.1.4       eth1/eth1              Full      10.10.1.4        128     2
> 172.16.1.5       eth1/eth1              Full      10.10.1.5        128     3
> 172.16.1.6       eth1/eth1              Full      10.10.1.6        128     3
> root at nlet-89-3>  [root at nlet-89-3 DISA]#
>
>
> INTERMEDIATE:
> root at nlet-89-1>  show ospf4 neighbor
>    Address         Interface             State      ID              Pri  Dead
> 172.16.1.2       eth1/eth1              Down      10.10.1.2          0     0
> 172.16.1.3       eth1/eth1              Full      10.10.1.3        128     3
> 172.16.1.4       eth1/eth1              Down      10.10.1.5          0     0
> 172.16.1.5       eth1/eth1              Down      10.10.1.5          0     0
> 172.16.1.6       eth1/eth1              Down      10.10.1.6          0     0
> 172.17.2.1       eth2.1212/eth2.1212    Full      10.10.1.8          1    31
> root at nlet-89-1>
>
> --
>
> [root at nlet-89-3 DISA]# xorpsh -c "show ospf4 neighbor"
> Welcome to XORP on nlet-89-3
> root at nlet-89-3>  show ospf4 neighbor
>    Address         Interface             State      ID              Pri  Dead
> 172.16.1.1       eth1/eth1              Down      10.10.1.1          0     0
> 172.16.1.2       eth1/eth1              Down      10.10.1.2          0     0
> 172.16.1.4       eth1/eth1              Full      10.10.1.4        128     2
> 172.16.1.5       eth1/eth1              Down      10.10.1.5          0     0
> 172.16.1.6       eth1/eth1              Down      10.10.1.6          0     0
> root at nlet-89-3>  [root at nlet-89-3 DISA]#

So, in this case, router 1 has Full adjacency to 3, but 3 shows 1 as Down??
If so, that seems wrong, but maybe I just don't understand point to multi-point
OSPF configs...


>
>
> FINAL:
> root at nlet-89-1>  show ospf4 neighbor
>    Address         Interface             State      ID              Pri  Dead
> 172.16.1.2       eth1/eth1              Down      10.10.1.2          0     0
> 172.16.1.3       eth1/eth1              Full      10.10.1.3        128     3
> 172.16.1.4       eth1/eth1              Down      10.10.1.5          0     0
> 172.16.1.5       eth1/eth1              Down      10.10.1.5          0     0
> 172.16.1.6       eth1/eth1              Down      10.10.1.6          0     0
> 172.17.2.1       eth2.1212/eth2.1212    Full      10.10.1.8          1    31
> root at nlet-89-1>
>
> --
>
> [root at nlet-89-3 DISA]# xorpsh -c "show ospf4 neighbor"
> Welcome to XORP on nlet-89-3
> root at nlet-89-3>  show ospf4 neighbor
>    Address         Interface             State      ID              Pri  Dead
> 172.16.1.1       eth1/eth1              Down      10.10.1.1          0     0
> 172.16.1.2       eth1/eth1              Down      10.10.1.2          0     0
> 172.16.1.4       eth1/eth1              Full      10.10.1.4        128     2
> 172.16.1.5       eth1/eth1              Down      10.10.1.5          0     0
> 172.16.1.6       eth1/eth1              Down      10.10.1.6          0     0
> root at nlet-89-3>  [root at nlet-89-3 DISA]#

3 still shows 1 as Down?

Thanks,
Ben


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


From michael.vincent at ll.mit.edu  Fri Jun 18 12:42:21 2010
From: michael.vincent at ll.mit.edu (Vincent, Michael - 0665 - MITLL)
Date: Fri, 18 Jun 2010 15:42:21 -0400
Subject: [Xorp-users] OSPF point-to-multipoint issue
In-Reply-To: <4C1BCA19.7090704@candelatech.com>
References: <201006181604.o5IG48SV000641@pork.ICSI.Berkeley.EDU>
	<4C1BA94F.2070203@candelatech.com>
	<201006181736.o5IHaCea021486@ns3.lanforge.com>
	<4C1BB8B6.7000303@candelatech.com>
	<201006181843.o5IIhwLw027296@ns3.lanforge.com>
	<4C1BC049.5070704@candelatech.com>
	<201006181921.o5IJLT6M030590@ns3.lanforge.com>
	<4C1BCA19.7090704@candelatech.com>
Message-ID: <201006181942.o5IJgUuD004698@pork.ICSI.Berkeley.EDU>

> So, in this case, router 1 has Full adjacency to 3, but 3 shows 1 as Down??
> If so, that seems wrong, but maybe I just don't understand point to multi-point OSPF configs...

Agreed.  Hence our dilemma.

    Cheers.

-- 
Michael J. Vincent
Group 65 - Advanced Networks and Applications
MIT Lincoln Laboratory
244 Wood Street
Lexington, MA 02420
Office:  +1.781.981.3459


-----Original Message-----
From: Ben Greear [mailto:greearb at candelatech.com] 
Sent: Friday, June 18, 2010 3:34 PM
To: Vincent, Michael - 0665 - MITLL
Cc: xorp-users at xorp.org; Zuena, John - 0665 - MITLL
Subject: Re: [Xorp-users] OSPF point-to-multipoint issue

On 06/18/2010 12:21 PM, Vincent, Michael - 0665 - MITLL wrote:
>> Ahh, so to get to the original peer, it needs to first remove the routes on the secondary link?
>
> Not necessarily, you can still get there (data path) through the multi-hop path; however, OSPF won't form an adjacency over a multi hop.  So to that point, yes, the host route that OSPF added needs to be removed for OSPF to then re-form it's adjacency.  Catch-22 sounds appropriate.
>
>
> I've only included the outputs for nodes 1 and 3 as that is what the example is talking about.  The actual experiment fails other links also and thus more peering sessions go down and do not re-establish.
>
>
> START:
> root at nlet-89-1>  show ospf4 neighbor
>    Address         Interface             State      ID              Pri  Dead
> 172.16.1.2       eth1/eth1              Full      10.10.1.2        128     2
> 172.16.1.3       eth1/eth1              Full      10.10.1.3        128     3
> 172.16.1.4       eth1/eth1              Full      10.10.1.5        128     3
> 172.16.1.5       eth1/eth1              Full      10.10.1.5        128     2
> 172.16.1.6       eth1/eth1              Full      10.10.1.6        128     2
> 172.17.2.1       eth2.1212/eth2.1212    Full      10.10.1.8          1    31
> root at nlet-89-1>
>
> --
>
> [root at nlet-89-3 DISA]# xorpsh -c "show ospf4 neighbor"
> Welcome to XORP on nlet-89-3
> root at nlet-89-3>  show ospf4 neighbor
>    Address         Interface             State      ID              Pri  Dead
> 172.16.1.1       eth1/eth1              Full      10.10.1.1        128     2
> 172.16.1.2       eth1/eth1              Full      10.10.1.2        128     3
> 172.16.1.4       eth1/eth1              Full      10.10.1.4        128     2
> 172.16.1.5       eth1/eth1              Full      10.10.1.5        128     3
> 172.16.1.6       eth1/eth1              Full      10.10.1.6        128     3
> root at nlet-89-3>  [root at nlet-89-3 DISA]#
>
>
> INTERMEDIATE:
> root at nlet-89-1>  show ospf4 neighbor
>    Address         Interface             State      ID              Pri  Dead
> 172.16.1.2       eth1/eth1              Down      10.10.1.2          0     0
> 172.16.1.3       eth1/eth1              Full      10.10.1.3        128     3
> 172.16.1.4       eth1/eth1              Down      10.10.1.5          0     0
> 172.16.1.5       eth1/eth1              Down      10.10.1.5          0     0
> 172.16.1.6       eth1/eth1              Down      10.10.1.6          0     0
> 172.17.2.1       eth2.1212/eth2.1212    Full      10.10.1.8          1    31
> root at nlet-89-1>
>
> --
>
> [root at nlet-89-3 DISA]# xorpsh -c "show ospf4 neighbor"
> Welcome to XORP on nlet-89-3
> root at nlet-89-3>  show ospf4 neighbor
>    Address         Interface             State      ID              Pri  Dead
> 172.16.1.1       eth1/eth1              Down      10.10.1.1          0     0
> 172.16.1.2       eth1/eth1              Down      10.10.1.2          0     0
> 172.16.1.4       eth1/eth1              Full      10.10.1.4        128     2
> 172.16.1.5       eth1/eth1              Down      10.10.1.5          0     0
> 172.16.1.6       eth1/eth1              Down      10.10.1.6          0     0
> root at nlet-89-3>  [root at nlet-89-3 DISA]#

So, in this case, router 1 has Full adjacency to 3, but 3 shows 1 as Down??
If so, that seems wrong, but maybe I just don't understand point to multi-point
OSPF configs...


>
>
> FINAL:
> root at nlet-89-1>  show ospf4 neighbor
>    Address         Interface             State      ID              Pri  Dead
> 172.16.1.2       eth1/eth1              Down      10.10.1.2          0     0
> 172.16.1.3       eth1/eth1              Full      10.10.1.3        128     3
> 172.16.1.4       eth1/eth1              Down      10.10.1.5          0     0
> 172.16.1.5       eth1/eth1              Down      10.10.1.5          0     0
> 172.16.1.6       eth1/eth1              Down      10.10.1.6          0     0
> 172.17.2.1       eth2.1212/eth2.1212    Full      10.10.1.8          1    31
> root at nlet-89-1>
>
> --
>
> [root at nlet-89-3 DISA]# xorpsh -c "show ospf4 neighbor"
> Welcome to XORP on nlet-89-3
> root at nlet-89-3>  show ospf4 neighbor
>    Address         Interface             State      ID              Pri  Dead
> 172.16.1.1       eth1/eth1              Down      10.10.1.1          0     0
> 172.16.1.2       eth1/eth1              Down      10.10.1.2          0     0
> 172.16.1.4       eth1/eth1              Full      10.10.1.4        128     2
> 172.16.1.5       eth1/eth1              Down      10.10.1.5          0     0
> 172.16.1.6       eth1/eth1              Down      10.10.1.6          0     0
> root at nlet-89-3>  [root at nlet-89-3 DISA]#

3 still shows 1 as Down?

Thanks,
Ben


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



From greearb at candelatech.com  Fri Jun 18 13:36:20 2010
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 18 Jun 2010 13:36:20 -0700
Subject: [Xorp-users] OSPF point-to-multipoint issue
In-Reply-To: <201006181942.o5IJgOrj032415@ns3.lanforge.com>
References: <201006181604.o5IG48SV000641@pork.ICSI.Berkeley.EDU>
	<4C1BA94F.2070203@candelatech.com>
	<201006181736.o5IHaCea021486@ns3.lanforge.com>
	<4C1BB8B6.7000303@candelatech.com>
	<201006181843.o5IIhwLw027296@ns3.lanforge.com>
	<4C1BC049.5070704@candelatech.com>
	<201006181921.o5IJLT6M030590@ns3.lanforge.com>
	<4C1BCA19.7090704@candelatech.com>
	<201006181942.o5IJgOrj032415@ns3.lanforge.com>
Message-ID: <4C1BD8C4.2060501@candelatech.com>

On 06/18/2010 12:42 PM, Vincent, Michael - 0665 - MITLL wrote:
>> So, in this case, router 1 has Full adjacency to 3, but 3 shows 1 as Down??
>> If so, that seems wrong, but maybe I just don't understand point to multi-point OSPF configs...
>
> Agreed.  Hence our dilemma.

So, if you remove a route on 3 (pointing towards 1 via router 5), it works?

What added the route to begin with..OSPF?

If it was OSPF, then I guess the code should be changed
to remove the route, perhaps when it starts receiving
broadcast pkts from the peer again?

Can you confirm that the problem happens on rejoin of the
networks and not on link 1-3 failure?  I had asked for
'show neighbor' on link failure, and if that was your second
set of dumps, then the problem appears to already exist before you
ever get to the rejoin phase.

Thanks,
Ben

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


From naresh_raga at yahoo.co.in  Sun Jun 20 13:43:14 2010
From: naresh_raga at yahoo.co.in (naresh raga)
Date: Sun, 20 Jun 2010 13:43:14 -0700 (PDT)
Subject: [Xorp-users] xorp-1.8.ct build is resulting in errors.
Message-ID: <750350.28601.qm@web94815.mail.in2.yahoo.com>

Hello Ben,
I am trying to build Xorp-1.8-CT(greearb-xorp.ct-xorp-1-8-CT-0-gf199960.zip) downloaded from 
http://github.com/greearb/xorp.ct/downloads
I am building it on Ubuntu 9.04 using gcc-4.4.3.The options I am supplying to scons are:

scons -j4 CC=gcc-4.4 CXX=g++-4.4 disable_ipv6=yes disable_fw=yes enable_olsr=no enable_bgp=yes optimize=size disable_profile=yes

The error it resulting in is:

Symlink("/home/student/Desktop/xorp-greearbv2/obj/i686-pc-linux-gnu/xrl/targets/libxst_test_socket4.so", as "/home/student/Desktop/xorp-greearbv2/obj/i686-pc-linux-gnu/lib/libxst_test_socket4.so")
/home/student/Desktop/xorp-greearbv2/xrl/scripts/tgt-gen -Ixrl/interfaces -Iobj/i686-pc-linux-gnu -I. --output-dir obj/i686-pc-linux-gnu/xrl/targets xrl/targets/olsr4.tgt

Interface profile/0.1 not defined in file xrl/targets/olsr4.tgt line 12

Valid interfaces are:
??? common/0.1
??? finder_event_observer/0.1
??? policy_backend/0.1
??? policy_redist4/0.1
??? olsr4/0.1
??? socket4_user/0.1
scons: *** [obj/i686-pc-linux-gnu/xrl/targets/olsr4_base.cc] Error 1
scons: building terminated because of errors.

My aim is to build xorp with minimum size(with all features required.)CT build had more options (in reducing size)than Xorp-1.7 build,so I switched to this.

I have tried to build the same(xorp-1.8-CT) without any options(i.e simply scons),the build is successful.So the problem could be with the options.

Any help would be really grateful.Your work towards making xorp suitable for embedded platforms is really great.

Thanks,
T Raga Naresh.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20100620/064e7d1b/attachment.html 

From greearb at candelatech.com  Sun Jun 20 22:43:49 2010
From: greearb at candelatech.com (Ben Greear)
Date: Sun, 20 Jun 2010 22:43:49 -0700
Subject: [Xorp-users] xorp-1.8.ct build is resulting in errors.
In-Reply-To: <750350.28601.qm@web94815.mail.in2.yahoo.com>
References: <750350.28601.qm@web94815.mail.in2.yahoo.com>
Message-ID: <4C1EFC15.6010209@candelatech.com>

On 06/20/2010 01:43 PM, naresh raga wrote:
> Hello Ben,
> I am trying to build
> Xorp-1.8-CT(greearb-xorp.ct-xorp-1-8-CT-0-gf199960.zip) downloaded from
> http://github.com/greearb/xorp.ct/downloads
> I am building it on Ubuntu 9.04 using gcc-4.4.3.The options I am
> supplying to scons are:
>
> scons -j4 CC=gcc-4.4 CXX=g++-4.4 disable_ipv6=yes disable_fw=yes
> enable_olsr=no enable_bgp=yes optimize=size disable_profile=yes

Please try the top-of-tree:  I just committed a fix for an issue
in bgp, but I didn't see any issues with olsr.  Please note that
the official 1.8-CT release does have some issues with compiling
out various components, so you'll need to use the top-of-tree:

git clone git at github.com:greearb/xorp.ct.git

Also, when changing config options, its safest to rm -fr obj
to make sure all dependencies are cleaned up properly.

Thanks,
Ben


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


From michael.vincent at ll.mit.edu  Mon Jun 21 04:37:25 2010
From: michael.vincent at ll.mit.edu (Vincent, Michael - 0665 - MITLL)
Date: Mon, 21 Jun 2010 07:37:25 -0400
Subject: [Xorp-users] OSPF point-to-multipoint issue
In-Reply-To: <4C1BD8C4.2060501@candelatech.com>
References: <201006181604.o5IG48SV000641@pork.ICSI.Berkeley.EDU>
	<4C1BA94F.2070203@candelatech.com>
	<201006181736.o5IHaCea021486@ns3.lanforge.com>
	<4C1BB8B6.7000303@candelatech.com>
	<201006181843.o5IIhwLw027296@ns3.lanforge.com>
	<4C1BC049.5070704@candelatech.com>
	<201006181921.o5IJLT6M030590@ns3.lanforge.com>
	<4C1BCA19.7090704@candelatech.com>
	<201006181942.o5IJgOrj032415@ns3.lanforge.com>
	<4C1BD8C4.2060501@candelatech.com>
Message-ID: <201006211137.o5LBboIE006801@pork.ICSI.Berkeley.EDU>

> If it was OSPF, then I guess the code should be changed
> to remove the route, perhaps when it starts receiving
> broadcast pkts from the peer again?

That sounds right.

To 'resolve' the issue, we exit xorpsh and at the linux command line, issue:

for i in `route -n | grep 255.255.255.255 | awk '{print $1}'`; do route del ${i}; done

This removes all the host routes that OSPF added.  There are no host routes (mask of 255.255.255.255) in the linux kernel routing table by default.  The host routes that are added are related to those routes in Xorp OSPF configuration.

> Can you confirm that the problem happens on rejoin of the
> networks and not on link 1-3 failure?  I had asked for
> 'show neighbor' on link failure, and if that was your second
> set of dumps, then the problem appears to already exist before you
> ever get to the rejoin phase.

As the link fails, the host routes are added and OSPF peers drop.  This behavior is expected.  When we bring the link back up, OSPF does not re-establish adjacencies (your previous statement regarding "remove route [...] when it starts receiving broadcast pkts from the peer [...]") and thus the host route is not removed.  With the host route not removed, the 'neighbor' looks multiple hops away and thus not adjacent so no OSPF peering.  That's the catch-22 we eluded to earlier.

The 'show' outputs are from 1) steady state, 2) after the link is failed, 3) after the link is re-established.  Note 2) and 3) outputs are very similar as OSPF goes into the expected fail state during/after link failure.  We don't expect the results from 3) as after link recovery, we would expect the OSPF 'show' output to be similar to 1) steady state.



    Cheers.

-- 
Michael J. Vincent
Group 65 - Advanced Networks and Applications
MIT Lincoln Laboratory
244 Wood Street
Lexington, MA 02420
Office:  +1.781.981.3459


-----Original Message-----
From: Ben Greear [mailto:greearb at candelatech.com] 
Sent: Friday, June 18, 2010 4:36 PM
To: Vincent, Michael - 0665 - MITLL
Cc: xorp-users at xorp.org; Zuena, John - 0665 - MITLL
Subject: Re: [Xorp-users] OSPF point-to-multipoint issue

On 06/18/2010 12:42 PM, Vincent, Michael - 0665 - MITLL wrote:
>> So, in this case, router 1 has Full adjacency to 3, but 3 shows 1 as Down??
>> If so, that seems wrong, but maybe I just don't understand point to multi-point OSPF configs...
>
> Agreed.  Hence our dilemma.

So, if you remove a route on 3 (pointing towards 1 via router 5), it works?

What added the route to begin with..OSPF?

If it was OSPF, then I guess the code should be changed
to remove the route, perhaps when it starts receiving
broadcast pkts from the peer again?

Can you confirm that the problem happens on rejoin of the
networks and not on link 1-3 failure?  I had asked for
'show neighbor' on link failure, and if that was your second
set of dumps, then the problem appears to already exist before you
ever get to the rejoin phase.

Thanks,
Ben

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



From naresh_raga at yahoo.co.in  Mon Jun 21 06:31:10 2010
From: naresh_raga at yahoo.co.in (naresh raga)
Date: Mon, 21 Jun 2010 19:01:10 +0530 (IST)
Subject: [Xorp-users] xorp-1.8.ct build is resulting in errors.
Message-ID: <465483.18204.qm@web94807.mail.in2.yahoo.com>

Hello Ben,
I have tried to download from top-of-tree.But it is refusing the connection.Might be because of proxy system of our Institute.Our Institute uses Kerberos protocol for authentication.I have logged in my browser while typing git clone command in my console.But even then it is not downloading.The errors are shown below.

student at student-desktop:~$ sudo git clone? git://github.com/greearb/xorp.ct.gt
Initialized empty Git repository in /home/student/xorp.ct.gt/.git/
github.com[0: 207.97.227.239]: errno=Connection refused
fatal: unable to connect a socket (Connection refused)
student at student-desktop:~$ sudo git clone git at github.com:greearb/xorp.ct.git
Initialized empty Git repository in /home/student/xorp.ct/.git/
Permission denied (publickey).
fatal: The remote end hung up unexpectedly

Please can you mail me the xorp(the latest one) personally to my mail id:naresh_raga at yahoomail.co.in.I? think by archiving it ,it will be below 5MB and you can send it through mail.

Thanks Ben,
Naresh.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20100621/3060bbd5/attachment.html 

From miro_todorovic at yahoo.com  Mon Jun 21 07:15:30 2010
From: miro_todorovic at yahoo.com (Miroslav Todorovic)
Date: Mon, 21 Jun 2010 07:15:30 -0700 (PDT)
Subject: [Xorp-users] RP in multicast streaming
Message-ID: <254714.88009.qm@web37007.mail.mud.yahoo.com>

Hello,

Could anyone tell me how to check what is RP (rendenzvous point) in my multicast network?
I use bootstrap mechanism.

Thank you!



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

From greearb at candelatech.com  Mon Jun 21 10:35:14 2010
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 21 Jun 2010 10:35:14 -0700
Subject: [Xorp-users] xorp-1.8.ct build is resulting in errors.
In-Reply-To: <465483.18204.qm@web94807.mail.in2.yahoo.com>
References: <465483.18204.qm@web94807.mail.in2.yahoo.com>
Message-ID: <4C1FA2D2.3070806@candelatech.com>

On 06/21/2010 06:31 AM, naresh raga wrote:
> Hello Ben,
> I have tried to download from top-of-tree.But it is refusing the
> connection.Might be because of proxy system of our Institute.Our
> Institute uses Kerberos protocol for authentication.I have logged in my
> browser while typing git clone command in my console.But even then it is
> not downloading.The errors are shown below.
>
> student at student-desktop:~$ sudo git clone
> git://github.com/greearb/xorp.ct.gt
> Initialized empty Git repository in /home/student/xorp.ct.gt/.git/
> github.com[0: 207.97.227.239]: errno=Connection refused
> fatal: unable to connect a socket (Connection refused)
> student at student-desktop:~$ sudo git clone git at github.com:greearb/xorp.ct.git
> Initialized empty Git repository in /home/student/xorp.ct/.git/
> Permission denied (publickey).
> fatal: The remote end hung up unexpectedly
>
> Please can you mail me the xorp(the latest one) personally to my mail
> id:naresh_raga at yahoomail.co.in.I think by archiving it ,it will be below
> 5MB and you can send it through mail.
>
> Thanks Ben,
> Naresh.
>
>

Sorry, please try this:

git clone git://github.com/greearb/xorp.ct.git


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


From michael.vincent at ll.mit.edu  Tue Jun 22 06:14:51 2010
From: michael.vincent at ll.mit.edu (Vincent, Michael - 0665 - MITLL)
Date: Tue, 22 Jun 2010 09:14:51 -0400
Subject: [Xorp-users] OSPF point-to-multipoint issue
In-Reply-To: <201006211137.o5LBboIE006801@pork.ICSI.Berkeley.EDU>
References: <201006181604.o5IG48SV000641@pork.ICSI.Berkeley.EDU>
	<4C1BA94F.2070203@candelatech.com>
	<201006181736.o5IHaCea021486@ns3.lanforge.com>
	<4C1BB8B6.7000303@candelatech.com>
	<201006181843.o5IIhwLw027296@ns3.lanforge.com>
	<4C1BC049.5070704@candelatech.com>
	<201006181921.o5IJLT6M030590@ns3.lanforge.com>
	<4C1BCA19.7090704@candelatech.com>
	<201006181942.o5IJgOrj032415@ns3.lanforge.com>
	<4C1BD8C4.2060501@candelatech.com>
	<201006211137.o5LBboIE006801@pork.ICSI.Berkeley.EDU>
Message-ID: <201006221315.o5MDF6Vi004731@pork.ICSI.Berkeley.EDU>

After some tcpdump analysis between Quagga and Xorp, I think I see our issue.  Quagga - like Cisco - allows you to configure OSPF point-to-multipoint interfaces *without* having to specify neighbors statically in the configuration.  When I tried this on Xorp, the OSPF neighbors never came up.  I specifically needed to configure the neighbors under the OSPF point-to-multipoint interface.

When OSPF then starts sending its HELLO packets, Cisco and Quagga both send to AllSPFRouters (224.0.0.5) with a TTL of 1.  This ensures that all OSPF routers on a segment get the HELLO and adjacencies are formed between all routers without letting multihop neighbors establish adjacencies (TTL 1).  Xorp sends the HELLO packets to the configured neighbors' IP address, *not* the 224.0.0.5 multicast address.

During link failure, in both cases (Xorp and Quagga/Cisco), the adjacencies across the failed link are lost as expected.  Host routes are added (Xorp and Quagga) to the linux/kernel routing table to 'route around' the failures.

During link re-establish, in Quagga/Cisco, the multicast packets to 224.0.0.5 are again heard over the re-established link and the SPF routers at both ends re-establish their adjacency.  Once their adjacency is up again and OSPF converges, the host route in the linux/kernel routing table is removed.

During link re-establish in Xorp, the Xorp routers continue to send directed HELLO packets to their established neighbors but do not send them to all configured neighbors.  In other words, once the neighbor is lost, it seems Xorp stops sending the directed HELLO packets to this neighbor.  Once the link to the neighbor is back up, Xorp is still not sending the HELLO packets so the adjacency is never reestablished.  This leaves us in the DOWN state and the host routes still in the linux/kernel routing table.



    Cheers.

-- 
Michael J. Vincent
Group 65 - Advanced Networks and Applications
MIT Lincoln Laboratory
244 Wood Street
Lexington, MA 02420
Office:  +1.781.981.3459


-----Original Message-----
From: xorp-users-bounces at xorp.org [mailto:xorp-users-bounces at xorp.org] On Behalf Of Vincent, Michael - 0665 - MITLL
Sent: Monday, June 21, 2010 7:37 AM
To: Ben Greear
Cc: xorp-users at xorp.org; Zuena, John - 0665 - MITLL
Subject: Re: [Xorp-users] OSPF point-to-multipoint issue

> If it was OSPF, then I guess the code should be changed
> to remove the route, perhaps when it starts receiving
> broadcast pkts from the peer again?

That sounds right.

To 'resolve' the issue, we exit xorpsh and at the linux command line, issue:

for i in `route -n | grep 255.255.255.255 | awk '{print $1}'`; do route del ${i}; done

This removes all the host routes that OSPF added.  There are no host routes (mask of 255.255.255.255) in the linux kernel routing table by default.  The host routes that are added are related to those routes in Xorp OSPF configuration.

> Can you confirm that the problem happens on rejoin of the
> networks and not on link 1-3 failure?  I had asked for
> 'show neighbor' on link failure, and if that was your second
> set of dumps, then the problem appears to already exist before you
> ever get to the rejoin phase.

As the link fails, the host routes are added and OSPF peers drop.  This behavior is expected.  When we bring the link back up, OSPF does not re-establish adjacencies (your previous statement regarding "remove route [...] when it starts receiving broadcast pkts from the peer [...]") and thus the host route is not removed.  With the host route not removed, the 'neighbor' looks multiple hops away and thus not adjacent so no OSPF peering.  That's the catch-22 we eluded to earlier.

The 'show' outputs are from 1) steady state, 2) after the link is failed, 3) after the link is re-established.  Note 2) and 3) outputs are very similar as OSPF goes into the expected fail state during/after link failure.  We don't expect the results from 3) as after link recovery, we would expect the OSPF 'show' output to be similar to 1) steady state.



    Cheers.

-- 
Michael J. Vincent
Group 65 - Advanced Networks and Applications
MIT Lincoln Laboratory
244 Wood Street
Lexington, MA 02420
Office:  +1.781.981.3459


-----Original Message-----
From: Ben Greear [mailto:greearb at candelatech.com] 
Sent: Friday, June 18, 2010 4:36 PM
To: Vincent, Michael - 0665 - MITLL
Cc: xorp-users at xorp.org; Zuena, John - 0665 - MITLL
Subject: Re: [Xorp-users] OSPF point-to-multipoint issue

On 06/18/2010 12:42 PM, Vincent, Michael - 0665 - MITLL wrote:
>> So, in this case, router 1 has Full adjacency to 3, but 3 shows 1 as Down??
>> If so, that seems wrong, but maybe I just don't understand point to multi-point OSPF configs...
>
> Agreed.  Hence our dilemma.

So, if you remove a route on 3 (pointing towards 1 via router 5), it works?

What added the route to begin with..OSPF?

If it was OSPF, then I guess the code should be changed
to remove the route, perhaps when it starts receiving
broadcast pkts from the peer again?

Can you confirm that the problem happens on rejoin of the
networks and not on link 1-3 failure?  I had asked for
'show neighbor' on link failure, and if that was your second
set of dumps, then the problem appears to already exist before you
ever get to the rejoin phase.

Thanks,
Ben

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


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


From greearb at candelatech.com  Tue Jun 22 08:53:11 2010
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 22 Jun 2010 08:53:11 -0700
Subject: [Xorp-users] OSPF point-to-multipoint issue
In-Reply-To: <201006221315.o5MDEx82011216@ns3.lanforge.com>
References: <201006181604.o5IG48SV000641@pork.ICSI.Berkeley.EDU>	<4C1BA94F.2070203@candelatech.com>	<201006181736.o5IHaCea021486@ns3.lanforge.com>	<4C1BB8B6.7000303@candelatech.com>	<201006181843.o5IIhwLw027296@ns3.lanforge.com>	<4C1BC049.5070704@candelatech.com>	<201006181921.o5IJLT6M030590@ns3.lanforge.com>	<4C1BCA19.7090704@candelatech.com>	<201006181942.o5IJgOrj032415@ns3.lanforge.com>	<4C1BD8C4.2060501@candelatech.com>
	<201006211137.o5LBboIE006801@pork.ICSI.Berkeley.EDU>
	<201006221315.o5MDEx82011216@ns3.lanforge.com>
Message-ID: <4C20DC67.9030602@candelatech.com>

On 06/22/2010 06:14 AM, Vincent, Michael - 0665 - MITLL wrote:
> After some tcpdump analysis between Quagga and Xorp, I think I see our issue.  Quagga - like Cisco - allows you to configure OSPF point-to-multipoint interfaces *without* having to specify neighbors statically in the configuration.  When I tried this on Xorp, the OSPF neighbors never came up.  I specifically needed to configure the neighbors under the OSPF point-to-multipoint interface.

 From a brief reading of the RFC 2178, the Quagga/Cisco approach seems valid, though it appears point-to-multipoint was
originally designed for networks that couldn't do broadcast/multicast (FrameRelay), so maybe that is why Xorp doesn't
try the multicast discovery...

> When OSPF then starts sending its HELLO packets, Cisco and Quagga both send to AllSPFRouters (224.0.0.5) with a TTL of 1.  This ensures that all OSPF routers on a segment get the HELLO and adjacencies are formed between all routers without letting multihop neighbors establish adjacencies (TTL 1).  Xorp sends the HELLO packets to the configured neighbors' IP address, *not* the 224.0.0.5 multicast address.

Unless someone knows of a good reason not to, I think we could implement the multicast send
in addition to the directed message to any configured neighbours.

>
> During link failure, in both cases (Xorp and Quagga/Cisco), the adjacencies across the failed link are lost as expected.  Host routes are added (Xorp and Quagga) to the linux/kernel routing table to 'route around' the failures.
>
> During link re-establish, in Quagga/Cisco, the multicast packets to 224.0.0.5 are again heard over the re-established link and the SPF routers at both ends re-establish their adjacency.  Once their adjacency is up again and OSPF converges, the host route in the linux/kernel routing table is removed.
>
> During link re-establish in Xorp, the Xorp routers continue to send directed HELLO packets to their established neighbors but do not send them to all configured neighbors.  In other words, once the neighbor is lost, it seems Xorp stops sending the directed HELLO packets to this neighbor.  Once the link to the neighbor is back up, Xorp is still not sending the HELLO packets so the adjacency is never reestablished.  This leaves us in the DOWN state and the host routes still in the linux/kernel routing table.

I'm busy with some other projects at the moment, so no time to attempt to implement this,
but I'll be happy to review and test (in my non point-to-multipoint) setup if you guys
come up with a patch.

Thanks,
Ben


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


From amarnath at copperheadsystems.com  Thu Jun 24 04:17:03 2010
From: amarnath at copperheadsystems.com (amarnath at copperheadsystems.com)
Date: Thu, 24 Jun 2010 05:17:03 -0600
Subject: [Xorp-users] Cross Compilation of xorp code with static flag
	enabled.
Message-ID: <e3c09d5e406764e94a6ee6d5588afbc2.squirrel@mail.copperheadsystems.com>



Hi All,
This is Amarnath.V from CopperHeadSystems India.
I am doing the cross compilation of the xorp code, enabling the static
flag as i want to compile it for the target environment.But i am facing
the below mentioned problem while doing the compilation.

./configure --host=x86 --target=ppc CC=ppc_82xx-gcc CXX=ppc_82xx-g++
CXXFLAGS=--static LDFLAGS="-L /opt/cross_compiler/ppc_82xx/lib/libstdc++.a
" --disable-shared.

Error:
=====
attempted static link of dynamic object
`/opt/cross_compiler/ppc_82xx/lib/libstdc++.so'

Can any one please suggest the solution for this.

Thanks in Advance.

Regards,
Amarnath.



From greearb at candelatech.com  Thu Jun 24 09:23:17 2010
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 24 Jun 2010 09:23:17 -0700
Subject: [Xorp-users] Cross Compilation of xorp code with static flag
 enabled.
In-Reply-To: <e3c09d5e406764e94a6ee6d5588afbc2.squirrel@mail.copperheadsystems.com>
References: <e3c09d5e406764e94a6ee6d5588afbc2.squirrel@mail.copperheadsystems.com>
Message-ID: <4C238675.5050003@candelatech.com>

On 06/24/2010 04:17 AM, amarnath at copperheadsystems.com wrote:
>
>
> Hi All,
> This is Amarnath.V from CopperHeadSystems India.
> I am doing the cross compilation of the xorp code, enabling the static
> flag as i want to compile it for the target environment.But i am facing
> the below mentioned problem while doing the compilation.
>
> ./configure --host=x86 --target=ppc CC=ppc_82xx-gcc CXX=ppc_82xx-g++
> CXXFLAGS=--static LDFLAGS="-L /opt/cross_compiler/ppc_82xx/lib/libstdc++.a
> " --disable-shared.

You might try xorp.ct.  I think you would do something like:

scons CC=ppc_82xx-gcc CXX=ppc_82xx-g++

I tried similar with an arm cross-compiler chain on Fedora 13 the other day,
but since I didn't have a cross-compiled openssl package, I didn't get very
far....

http://github.com/greearb/xorp.ct

If you do try xorp.ct, please let me know the results.

Thanks,
Ben

>
> Error:
> =====
> attempted static link of dynamic object
> `/opt/cross_compiler/ppc_82xx/lib/libstdc++.so'
>
> Can any one please suggest the solution for this.
>
> Thanks in Advance.
>
> Regards,
> Amarnath.
>
>
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


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


From naresh_raga at yahoo.co.in  Sat Jun 26 11:27:24 2010
From: naresh_raga at yahoo.co.in (naresh raga)
Date: Sat, 26 Jun 2010 23:57:24 +0530 (IST)
Subject: [Xorp-users] Is there any ways to start xorp other than using
	xorp_rtrmgr
In-Reply-To: <4C1FA2D2.3070806@candelatech.com>
Message-ID: <985239.62137.qm@web94809.mail.in2.yahoo.com>

Hi friends,
???? I have observed while starting xorp using ./xorp_rtrmgr with a small boot file having interfaces and fea enabled is more CPU resource intensive.Using top I have observed CPU and memory? requirements (peak values) as:
Process????????? %CPU????? %MEM
xorp_rtrmgr?????? 6?????????????? 0.3
xorp_fea??????????? 4?????????????? 0.2

These values are for xorp-1.7 built with optimization(compiler flags used-Os ) and the build size in /usr/local/xorp is around 21MB after stripping the binaries.
????? My systems had two CPUs each of 3.00GHz and RAM is 1.9GB.So on calculating 10% of 6.00GHz=600MHz (nearly) is the CPU needed to start xorp with such a small configuration.
????? If more modules like rip,bgp,ospf would have been configured,more would be the requirement of CPU.I am working to port xorp onto an embedded platform(arm-based).So I need? ways of starting xorp on less resource platform.It seems xorp_rtrmgr is more resource-intensive.Is there any ways to start xorp other than using xorp_rtrmgr.

Also If someone has already ported xorp onto an embedded platform,Can you suggest the ideal CPU and RAM requirements for XORP to work.


Thanks,
T Raga Naresh.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20100626/10d06407/attachment.html 

From naresh_raga at yahoo.co.in  Sat Jun 26 11:47:58 2010
From: naresh_raga at yahoo.co.in (naresh raga)
Date: Sun, 27 Jun 2010 00:17:58 +0530 (IST)
Subject: [Xorp-users] Need suggestion about Embedded platform requirments.
Message-ID: <49921.51986.qm@web94811.mail.in2.yahoo.com>

Hello Ben and Surabh,
I am also working to port xorp onto Embedded platform(arm-based).I have seen all your conversations in the mailing list.You have worked a lot in reducing the memory footprint of xorp.I am worried about the CPU requirements.
???? I have observed while starting xorp using ./xorp_rtrmgr with a small
boot file having interfaces and fea enabled is more CPU resource
intensive.Using top I have observed CPU and memory? requirements (peak values) as:
Process????????? %CPU????? %MEM
xorp_rtrmgr?????? 6?????????????? 0.3
xorp_fea??????????? 4?????????????? 0.2

These
values are for xorp-1.7 built with optimization(compiler flags used-Os
) and the build size in /usr/local/xorp is around 21MB after stripping
the binaries.My systems had two CPUs each of 3.00GHz and RAM is 1.9GB.So on
calculating 10% of 6.00GHz=600MHz (nearly) is the CPU needed to start
xorp with such a small configuration.Are there ways in reducing CPU .

I need suggestion what could be the minimum CPU and RAM requirement for complete xorp to work on embedded target.Or
Quagga(unicast)+Xorp(multicast):For this combination what could be the CPU and RAM requirements of an embedded target to work.
I think saurabh can come up with a good reply for the latter case as he is working on this combination on embedded platform.

Thanks for your work and support,
T Raga Naresh






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

From greearb at candelatech.com  Sat Jun 26 14:04:50 2010
From: greearb at candelatech.com (Ben Greear)
Date: Sat, 26 Jun 2010 14:04:50 -0700
Subject: [Xorp-users] Is there any ways to start xorp other than using
 xorp_rtrmgr
In-Reply-To: <985239.62137.qm@web94809.mail.in2.yahoo.com>
References: <985239.62137.qm@web94809.mail.in2.yahoo.com>
Message-ID: <4C266B72.4090308@candelatech.com>

On 06/26/2010 11:27 AM, naresh raga wrote:
> Hi friends,
> I have observed while starting xorp using ./xorp_rtrmgr with a small
> boot file having interfaces and fea enabled is more CPU resource
> intensive.Using top I have observed CPU and memory requirements (peak
> values) as:
> Process %CPU %MEM
> xorp_rtrmgr 6 0.3
> xorp_fea 4 0.2
>
> These values are for xorp-1.7 built with optimization(compiler flags
> used-Os ) and the build size in /usr/local/xorp is around 21MB after
> stripping the binaries.
> My systems had two CPUs each of 3.00GHz and RAM is 1.9GB.So on
> calculating 10% of 6.00GHz=600MHz (nearly) is the CPU needed to start
> xorp with such a small configuration.
> If more modules like rip,bgp,ospf would have been configured,more would
> be the requirement of CPU.I am working to port xorp onto an embedded
> platform(arm-based).So I need ways of starting xorp on less resource
> platform.It seems xorp_rtrmgr is more resource-intensive.Is there any
> ways to start xorp other than using xorp_rtrmgr.
>
> Also If someone has already ported xorp onto an embedded platform,Can
> you suggest the ideal CPU and RAM requirements for XORP to work.

Much of the startup cost is in parsing the template files (last I checked),
and I think that is needed to load the config file properly.  When I was optimizing
xorp.ct some time back, I think I got much of the easy optimizations
completed.  The template parsing logic is based on auto-generated code
that appears very hard to optimize.  It would probably be easier to
completely re-write the parser, perhaps to using some existing framework
to make it easier.

At one time, compiling with profiling was supported, so you might try
that if you want to do further optimizations.  I think the valgrind
toolset also has some tools to aid with optimization which may be better
and/or easier to use, but I haven't used it.

The good news is that after it starts, the CPU usage should go down
to a minimal load.

Hopefully, you will not be starting xorp much.  Also, even if you are running
very slow mzh, it should still work..it will just take a bit longer to get
started.

Thanks,
Ben


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


From greearb at candelatech.com  Sat Jun 26 14:13:32 2010
From: greearb at candelatech.com (Ben Greear)
Date: Sat, 26 Jun 2010 14:13:32 -0700
Subject: [Xorp-users] Need suggestion about Embedded platform
	requirments.
In-Reply-To: <49921.51986.qm@web94811.mail.in2.yahoo.com>
References: <49921.51986.qm@web94811.mail.in2.yahoo.com>
Message-ID: <4C266D7C.6090402@candelatech.com>

On 06/26/2010 11:47 AM, naresh raga wrote:
> Hello Ben and Surabh,
> I am also working to port xorp onto Embedded platform(arm-based).I have
> seen all your conversations in the mailing list.You have worked a lot in
> reducing the memory footprint of xorp.I am worried about the CPU
> requirements.
> I have observed while starting xorp using ./xorp_rtrmgr with a small
> boot file having interfaces and fea enabled is more CPU resource
> intensive.Using top I have observed CPU and memory requirements (peak
> values) as:
> Process %CPU %MEM
> xorp_rtrmgr 6 0.3
> xorp_fea 4 0.2
>
> These values are for xorp-1.7 built with optimization(compiler flags
> used-Os ) and the build size in /usr/local/xorp is around 21MB after
> stripping the binaries.My systems had two CPUs each of 3.00GHz and RAM
> is 1.9GB.So on calculating 10% of 6.00GHz=600MHz (nearly) is the CPU
> needed to start xorp with such a small configuration.Are there ways in
> reducing CPU .

You might try xorp.ct 1.8 or top-of-tree xorp.ct.  It has all of my patches,
which includes some startup optimizations I did some time back.  1.7 has
only a few of my patches, and very little of the optimizations I worked
on back when I was trying to run 100 instances of xorp on a single machine.

It's still a pretty heavy CPU load to startup though.

> I need suggestion what could be the minimum CPU and RAM requirement for
> complete xorp to work on embedded target.Or
> Quagga(unicast)+Xorp(multicast):For this combination what could be the
> CPU and RAM requirements of an embedded target to work.
> I think saurabh can come up with a good reply for the latter case as he
> is working on this combination on embedded platform.

You really need to try it out and see how it works.  You could use optimization
tools (gprof, valgrind, etc) to try to find hot-spots in your particular
configuration for further optimizations.  Also, I'd compile out anything
you don't need.  Getting rid of IPv6 support is likely to help CPU usage a small
bit, for instance.

Also, if you get it cross-compiling for your ARM target, please post
instructions how you did it and I'll add to the BUILD_NOTES file.

Thanks,
Ben


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


From saurabh.pandya at elitecore.com  Mon Jun 28 03:49:02 2010
From: saurabh.pandya at elitecore.com (saurabh)
Date: Mon, 28 Jun 2010 16:19:02 +0530
Subject: [Xorp-users] Need suggestion about Embedded platform
	requirments.
In-Reply-To: <49921.51986.qm@web94811.mail.in2.yahoo.com>
References: <49921.51986.qm@web94811.mail.in2.yahoo.com>
Message-ID: <5C334A7298464653816B80D8C2A1A962@elitecore.com>

My experiments with xorp stats that cpu over-head is one time in
initialization. Well If you are bound even by memories 

As well you can recompile while disabling IPV6 and all loggings and further
use only PIM and IGMP 

(off course with fea, rib, fib2mrib and other basic libs only) and remove
all bgp, ospf, vrrp, rip, riping , static routes from

/usr/lib (by manually delete all files or remove them from scons build
process) , lead you to have around 10-12 Mb 

Of package. 

 

-Saurabh

 

  _____  

From: naresh raga [mailto:naresh_raga at yahoo.co.in] 
Sent: Sunday, June 27, 2010 12:18 AM
To: greearb at candelatech.com; saurabh.pandya at elitecore.com
Cc: xorp-users at xorp.org
Subject: Need suggestion about Embedded platform requirments.

 


Hello Ben and Surabh,
I am also working to port xorp onto Embedded platform(arm-based).I have seen
all your conversations in the mailing list.You have worked a lot in reducing
the memory footprint of xorp.I am worried about the CPU requirements.
     I have observed while starting xorp using ./xorp_rtrmgr with a small
boot file having interfaces and fea enabled is more CPU resource
intensive.Using top I have observed CPU and memory  requirements (peak
values) as:
Process          %CPU      %MEM
xorp_rtrmgr       6               0.3
xorp_fea            4               0.2

These values are for xorp-1.7 built with optimization(compiler flags used-Os
) and the build size in /usr/local/xorp is around 21MB after stripping the
binaries.My systems had two CPUs each of 3.00GHz and RAM is 1.9GB.So on
calculating 10% of 6.00GHz=600MHz (nearly) is the CPU needed to start xorp
with such a small configuration.Are there ways in reducing CPU .

I need suggestion what could be the minimum CPU and RAM requirement for
complete xorp to work on embedded target.Or
Quagga(unicast)+Xorp(multicast):For this combination what could be the CPU
and RAM requirements of an embedded target to work.
I think saurabh can come up with a good reply for the latter case as he is
working on this combination on embedded platform.

Thanks for your work and support,
T Raga Naresh





 

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

From jmitchell at ll.mit.edu  Mon Jun 28 08:33:29 2010
From: jmitchell at ll.mit.edu (Jeff Mitchell)
Date: Mon, 28 Jun 2010 11:33:29 -0400
Subject: [Xorp-users] Endless PIMv2 Register messages
Message-ID: <4C28C0C9.4070408@ll.mit.edu>

Hello,

I've been using the address 234.5.6.7 to send a multicast video stream 
for a long time.

The other day I wanted to send a second video stream, and used the 
address 225.6.7.8. However, when I use this address, the 
directly-connected XORP router to the sending host starts sending 
endless numbers of PIMv2 Register messages do a downstream neighbor:

11:27:06.562760 IP 192.168.20.1 > 192.168.20.2: PIMv2, Register, length: 
1352
11:27:06.565949 IP 192.168.20.1 > 192.168.20.2: PIMv2, Register, length: 
1352
11:27:06.569345 IP 192.168.20.1 > 192.168.20.2: PIMv2, Register, length: 
1352
11:27:06.572563 IP 192.168.20.1 > 192.168.20.2: PIMv2, Register, length: 
1352
11:27:06.575814 IP 192.168.20.1 > 192.168.20.2: PIMv2, Register, length: 
1352
11:27:06.579119 IP 192.168.20.1 > 192.168.20.2: PIMv2, Register, length: 
1352
11:27:06.582372 IP 192.168.20.1 > 192.168.20.2: PIMv2, Register, length: 
1352
11:27:06.585665 IP 192.168.20.1 > 192.168.20.2: PIMv2, Register, length: 
1352
11:27:06.589024 IP 192.168.20.1 > 192.168.20.2: PIMv2, Register, length: 
1352

Oddly, the video *does* actually work if I subscibe with a client a few 
hops away -- in tcpdump I end up with these register messages 
interspersed with the video packets (in fact they seem 1:1).

Any idea what's going on?

Thanks,
Jeff


From jmitchell at ll.mit.edu  Mon Jun 28 10:09:39 2010
From: jmitchell at ll.mit.edu (Jeff Mitchell)
Date: Mon, 28 Jun 2010 13:09:39 -0400
Subject: [Xorp-users] Endless PIMv2 Register messages
In-Reply-To: <4C28C0C9.4070408@ll.mit.edu>
References: <4C28C0C9.4070408@ll.mit.edu>
Message-ID: <4C28D753.80600@ll.mit.edu>

On 06/28/2010 11:33 AM, Jeff Mitchell wrote:
> Hello,
>
> I've been using the address 234.5.6.7 to send a multicast video stream
> for a long time.
>
> The other day I wanted to send a second video stream, and used the
> address 225.6.7.8. However, when I use this address, the
> directly-connected XORP router to the sending host starts sending
> endless numbers of PIMv2 Register messages do a downstream neighbor:
>
> 11:27:06.562760 IP 192.168.20.1>  192.168.20.2: PIMv2, Register, length:
> 1352
> 11:27:06.565949 IP 192.168.20.1>  192.168.20.2: PIMv2, Register, length:
> 1352
> 11:27:06.569345 IP 192.168.20.1>  192.168.20.2: PIMv2, Register, length:
> 1352
> 11:27:06.572563 IP 192.168.20.1>  192.168.20.2: PIMv2, Register, length:
> 1352
> 11:27:06.575814 IP 192.168.20.1>  192.168.20.2: PIMv2, Register, length:
> 1352
> 11:27:06.579119 IP 192.168.20.1>  192.168.20.2: PIMv2, Register, length:
> 1352
> 11:27:06.582372 IP 192.168.20.1>  192.168.20.2: PIMv2, Register, length:
> 1352
> 11:27:06.585665 IP 192.168.20.1>  192.168.20.2: PIMv2, Register, length:
> 1352
> 11:27:06.589024 IP 192.168.20.1>  192.168.20.2: PIMv2, Register, length:
> 1352
>
> Oddly, the video *does* actually work if I subscibe with a client a few
> hops away -- in tcpdump I end up with these register messages
> interspersed with the video packets (in fact they seem 1:1).
>
> Any idea what's going on?

Oddly, it turns out that if I try to send traffic on 234.5.6.8, I get 
the same problem.

I can't have simply stumbled upon the one address (234.5.6.7) that 
doesn't display this behavior -- surely something else is going awry.

I've pasted my xorp config below, but as far as I can tell it doesn't 
look problematic.

Thanks,
Jeff

# cat /etc/xorp/xorp.conf
/* XORP configuration file
  *
  * Configuration format: 1.1
  * XORP version: 1.7-WIP
  * Date: 2010/05/11 15:07:48.718756
  * Host: uav1eml
  * User: root
  */

protocols {
     fib2mrib {
         disable: false
     }
     igmp {
         disable: false
         interface "rtrs" {
             vif "rtrs" {
                 disable: false
                 version: 2
                 enable-ip-router-alert-option-check: false
                 query-interval: 125
                 query-last-member-interval: 1
                 query-response-interval: 10
                 robust-count: 2
             }
         }
         interface "eth0.501" {
             vif "eth0.501" {
                 disable: false
                 version: 2
                 enable-ip-router-alert-option-check: false
                 query-interval: 125
                 query-last-member-interval: 1
                 query-response-interval: 10
                 robust-count: 2
             }
         }
         traceoptions {
             flag {
                 all {
                     disable: false
                 }
             }
         }
     }
     pimsm4 {
         disable: false
         interface "rtrs" {
             vif "rtrs" {
                 disable: false
                 dr-priority: 1
                 hello-period: 30
                 hello-triggered-delay: 5
             }
         }
         interface "eth0.501" {
             vif "eth0.501" {
                 disable: false
                 dr-priority: 1
                 hello-period: 30
                 hello-triggered-delay: 5
             }
         }
         interface "register_vif" {
             vif "register_vif" {
                 disable: false
                 dr-priority: 1
                 hello-period: 30
                 hello-triggered-delay: 5
             }
         }
         bootstrap {
             disable: false
             cand-bsr {
                 scope-zone 224.0.0.0/4 {
                     is-scope-zone: false
                     cand-bsr-by-vif-name: "rtrs"
                     cand-bsr-by-vif-addr: 0.0.0.0
                     bsr-priority: 1
                     hash-mask-len: 30
                 }
             }
             cand-rp {
                 group-prefix 224.0.0.0/4 {
                     is-scope-zone: false
                     cand-rp-by-vif-name: "rtrs"
                     cand-rp-by-vif-addr: 0.0.0.0
                     rp-priority: 1
                     rp-holdtime: 150
                 }
             }
         }
         switch-to-spt-threshold {
             disable: false
             interval: 100
             bytes: 102400
         }
         traceoptions {
             flag {
                 all {
                     disable: false
                 }
             }
         }
     }
     static {
         disable: false
         route 192.168.51.0/24 {
             next-hop: 192.168.20.2
             metric: 1
         }
         mrib-route 192.168.51.0/24 {
             next-hop: 192.168.20.2
             metric: 1
         }
         route 192.168.52.0/24 {
             next-hop: 192.168.20.3
             metric: 1
         }
         mrib-route 192.168.52.0/24 {
             next-hop: 192.168.20.3
             metric: 1
         }
     }
}
fea {
     unicast-forwarding4 {
         disable: false
     }
     unicast-forwarding6 {
         disable: true
     }
}
interfaces {
     restore-original-config-on-shutdown: false
     interface "eth0.501" {
         description: ""
         disable: false
         discard: false
         unreachable: false
         management: false
         default-system-config
     }
     interface "rtrs" {
         description: ""
         disable: false
         discard: false
         unreachable: false
         management: false
         default-system-config
     }
}
plumbing {
     mfea4 {
         disable: false
         interface "rtrs" {
             vif "rtrs" {
                 disable: false
             }
         }
         interface "eth0.501" {
             vif "eth0.501" {
                 disable: false
             }
         }
         interface "register_vif" {
             vif "register_vif" {
                 disable: false
             }
         }
         traceoptions {
             flag {
                 all {
                     disable: false
                 }
             }
         }
     }
     mfea6 {
         disable: true
     }
}
rtrmgr {
     config-directory: "/etc/xorp"
     load-file-command: "fetch"
     load-file-command-args: "-o"
     load-ftp-command: "fetch"
     load-ftp-command-args: "-o"
     load-http-command: "fetch"
     load-http-command-args: "-o"
     load-tftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'"
     load-tftp-command-args: ""
     save-file-command: "sh -c 'echo Not implemented 1>&2 && exit 1'"
     save-file-command-args: ""
     save-ftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'"
     save-ftp-command-args: ""
     save-http-command: "sh -c 'echo Not implemented 1>&2 && exit 1'"
     save-http-command-args: ""
     save-tftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'"
     save-tftp-command-args: ""
}



From peirce at maine.edu  Mon Jun 28 12:08:39 2010
From: peirce at maine.edu (Garry Peirce)
Date: Mon, 28 Jun 2010 15:08:39 -0400
Subject: [Xorp-users] Endless PIMv2 Register messages
In-Reply-To: <4C28D753.80600@ll.mit.edu>
References: <4C28C0C9.4070408@ll.mit.edu> <4C28D753.80600@ll.mit.edu>
Message-ID: <05b901cb16f5$50fc1f10$f2f45d30$@edu>

Jeff,
Sounds like your source traffic is being unicast encapsulated towards the RP
(through the downstream neighbor).
I'd verify your RP will accepts being the RP for this group.


> -----Original Message-----
> From: xorp-users-bounces at xorp.org [mailto:xorp-users-bounces at xorp.org]
> On Behalf Of Jeff Mitchell
> Sent: Monday, June 28, 2010 1:10 PM
> To: xorp-users at xorp.org
> Subject: Re: [Xorp-users] Endless PIMv2 Register messages
> 
> On 06/28/2010 11:33 AM, Jeff Mitchell wrote:
> > Hello,
> >
> > I've been using the address 234.5.6.7 to send a multicast video
> stream
> > for a long time.
> >
> > The other day I wanted to send a second video stream, and used the
> > address 225.6.7.8. However, when I use this address, the
> > directly-connected XORP router to the sending host starts sending
> > endless numbers of PIMv2 Register messages do a downstream neighbor:
> >
> > 11:27:06.562760 IP 192.168.20.1>  192.168.20.2: PIMv2, Register,
> length:
> > 1352
> > 11:27:06.565949 IP 192.168.20.1>  192.168.20.2: PIMv2, Register,
> length:
> > 1352
> > 11:27:06.569345 IP 192.168.20.1>  192.168.20.2: PIMv2, Register,
> length:
> > 1352
> > 11:27:06.572563 IP 192.168.20.1>  192.168.20.2: PIMv2, Register,
> length:
> > 1352
> > 11:27:06.575814 IP 192.168.20.1>  192.168.20.2: PIMv2, Register,
> length:
> > 1352
> > 11:27:06.579119 IP 192.168.20.1>  192.168.20.2: PIMv2, Register,
> length:
> > 1352
> > 11:27:06.582372 IP 192.168.20.1>  192.168.20.2: PIMv2, Register,
> length:
> > 1352
> > 11:27:06.585665 IP 192.168.20.1>  192.168.20.2: PIMv2, Register,
> length:
> > 1352
> > 11:27:06.589024 IP 192.168.20.1>  192.168.20.2: PIMv2, Register,
> length:
> > 1352
> >
> > Oddly, the video *does* actually work if I subscibe with a client a
> few
> > hops away -- in tcpdump I end up with these register messages
> > interspersed with the video packets (in fact they seem 1:1).
> >
> > Any idea what's going on?
> 
> Oddly, it turns out that if I try to send traffic on 234.5.6.8, I get
> the same problem.
> 
> I can't have simply stumbled upon the one address (234.5.6.7) that
> doesn't display this behavior -- surely something else is going awry.
> 
> I've pasted my xorp config below, but as far as I can tell it doesn't
> look problematic.
> 
> Thanks,
> Jeff
> 
> # cat /etc/xorp/xorp.conf
> /* XORP configuration file
>   *
>   * Configuration format: 1.1
>   * XORP version: 1.7-WIP
>   * Date: 2010/05/11 15:07:48.718756
>   * Host: uav1eml
>   * User: root
>   */
> 
> protocols {
>      fib2mrib {
>          disable: false
>      }
>      igmp {
>          disable: false
>          interface "rtrs" {
>              vif "rtrs" {
>                  disable: false
>                  version: 2
>                  enable-ip-router-alert-option-check: false
>                  query-interval: 125
>                  query-last-member-interval: 1
>                  query-response-interval: 10
>                  robust-count: 2
>              }
>          }
>          interface "eth0.501" {
>              vif "eth0.501" {
>                  disable: false
>                  version: 2
>                  enable-ip-router-alert-option-check: false
>                  query-interval: 125
>                  query-last-member-interval: 1
>                  query-response-interval: 10
>                  robust-count: 2
>              }
>          }
>          traceoptions {
>              flag {
>                  all {
>                      disable: false
>                  }
>              }
>          }
>      }
>      pimsm4 {
>          disable: false
>          interface "rtrs" {
>              vif "rtrs" {
>                  disable: false
>                  dr-priority: 1
>                  hello-period: 30
>                  hello-triggered-delay: 5
>              }
>          }
>          interface "eth0.501" {
>              vif "eth0.501" {
>                  disable: false
>                  dr-priority: 1
>                  hello-period: 30
>                  hello-triggered-delay: 5
>              }
>          }
>          interface "register_vif" {
>              vif "register_vif" {
>                  disable: false
>                  dr-priority: 1
>                  hello-period: 30
>                  hello-triggered-delay: 5
>              }
>          }
>          bootstrap {
>              disable: false
>              cand-bsr {
>                  scope-zone 224.0.0.0/4 {
>                      is-scope-zone: false
>                      cand-bsr-by-vif-name: "rtrs"
>                      cand-bsr-by-vif-addr: 0.0.0.0
>                      bsr-priority: 1
>                      hash-mask-len: 30
>                  }
>              }
>              cand-rp {
>                  group-prefix 224.0.0.0/4 {
>                      is-scope-zone: false
>                      cand-rp-by-vif-name: "rtrs"
>                      cand-rp-by-vif-addr: 0.0.0.0
>                      rp-priority: 1
>                      rp-holdtime: 150
>                  }
>              }
>          }
>          switch-to-spt-threshold {
>              disable: false
>              interval: 100
>              bytes: 102400
>          }
>          traceoptions {
>              flag {
>                  all {
>                      disable: false
>                  }
>              }
>          }
>      }
>      static {
>          disable: false
>          route 192.168.51.0/24 {
>              next-hop: 192.168.20.2
>              metric: 1
>          }
>          mrib-route 192.168.51.0/24 {
>              next-hop: 192.168.20.2
>              metric: 1
>          }
>          route 192.168.52.0/24 {
>              next-hop: 192.168.20.3
>              metric: 1
>          }
>          mrib-route 192.168.52.0/24 {
>              next-hop: 192.168.20.3
>              metric: 1
>          }
>      }
> }
> fea {
>      unicast-forwarding4 {
>          disable: false
>      }
>      unicast-forwarding6 {
>          disable: true
>      }
> }
> interfaces {
>      restore-original-config-on-shutdown: false
>      interface "eth0.501" {
>          description: ""
>          disable: false
>          discard: false
>          unreachable: false
>          management: false
>          default-system-config
>      }
>      interface "rtrs" {
>          description: ""
>          disable: false
>          discard: false
>          unreachable: false
>          management: false
>          default-system-config
>      }
> }
> plumbing {
>      mfea4 {
>          disable: false
>          interface "rtrs" {
>              vif "rtrs" {
>                  disable: false
>              }
>          }
>          interface "eth0.501" {
>              vif "eth0.501" {
>                  disable: false
>              }
>          }
>          interface "register_vif" {
>              vif "register_vif" {
>                  disable: false
>              }
>          }
>          traceoptions {
>              flag {
>                  all {
>                      disable: false
>                  }
>              }
>          }
>      }
>      mfea6 {
>          disable: true
>      }
> }
> rtrmgr {
>      config-directory: "/etc/xorp"
>      load-file-command: "fetch"
>      load-file-command-args: "-o"
>      load-ftp-command: "fetch"
>      load-ftp-command-args: "-o"
>      load-http-command: "fetch"
>      load-http-command-args: "-o"
>      load-tftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'"
>      load-tftp-command-args: ""
>      save-file-command: "sh -c 'echo Not implemented 1>&2 && exit 1'"
>      save-file-command-args: ""
>      save-ftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'"
>      save-ftp-command-args: ""
>      save-http-command: "sh -c 'echo Not implemented 1>&2 && exit 1'"
>      save-http-command-args: ""
>      save-tftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'"
>      save-tftp-command-args: ""
> }
> 
> 
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From jmitchell at ll.mit.edu  Mon Jun 28 12:26:29 2010
From: jmitchell at ll.mit.edu (Jeff Mitchell)
Date: Mon, 28 Jun 2010 15:26:29 -0400
Subject: [Xorp-users] Endless PIMv2 Register messages
In-Reply-To: <05b901cb16f5$50fc1f10$f2f45d30$@edu>
References: <4C28C0C9.4070408@ll.mit.edu> <4C28D753.80600@ll.mit.edu>
	<05b901cb16f5$50fc1f10$f2f45d30$@edu>
Message-ID: <4C28F765.2030709@ll.mit.edu>

On 06/28/2010 03:08 PM, Garry Peirce wrote:
> Jeff,
> Sounds like your source traffic is being unicast encapsulated towards the RP
> (through the downstream neighbor).
> I'd verify your RP will accepts being the RP for this group.

How would this fit my experience, though?

Literally changing my command line from:

cvlc -vvv myvideo.mpg --sout 
'#std{access=udp,mux=ts,dst=234.5.6.7:1234}' --ttl 10 --loop

to:

cvlc -vvv myvideo.mpg --sout 
'#std{access=udp,mux=ts,dst=234.5.6.8:1234}' --ttl 10 --loop

triggers the problem.

Other than the small multicast address change nothing else is different, 
so I'm not aware of any reason that VLC would unicast encapsulate the 
traffic with one address and not the other.

Thanks,
Jeff


From peirce at maine.edu  Mon Jun 28 13:06:08 2010
From: peirce at maine.edu (Garry Peirce)
Date: Mon, 28 Jun 2010 16:06:08 -0400
Subject: [Xorp-users] Endless PIMv2 Register messages
In-Reply-To: <4C28F765.2030709@ll.mit.edu>
References: <4C28C0C9.4070408@ll.mit.edu> <4C28D753.80600@ll.mit.edu>
	<05b901cb16f5$50fc1f10$f2f45d30$@edu> <4C28F765.2030709@ll.mit.edu>
Message-ID: <05c801cb16fd$59480460$0bd80d20$@edu>

Jeff,
It wouldn't be the host doing this, but the DR router (in this case the XORP
router), encapsulating the packets (within PIM control msgs) towards what it
believes is the RP for this group.

Who does XORP think the RP for 234.5.6.8 is? 
What do 'show pim neighbors' and 'show pim rps' and 'show pim mrib' look
like?


> -----Original Message-----
> From: Jeff Mitchell [mailto:jmitchell at ll.mit.edu]
> Sent: Monday, June 28, 2010 3:26 PM
> To: Garry Peirce
> Cc: xorp-users at xorp.org
> Subject: Re: [Xorp-users] Endless PIMv2 Register messages
> 
> On 06/28/2010 03:08 PM, Garry Peirce wrote:
> > Jeff,
> > Sounds like your source traffic is being unicast encapsulated towards
> the RP
> > (through the downstream neighbor).
> > I'd verify your RP will accepts being the RP for this group.
> 
> How would this fit my experience, though?
> 
> Literally changing my command line from:
> 
> cvlc -vvv myvideo.mpg --sout
> '#std{access=udp,mux=ts,dst=234.5.6.7:1234}' --ttl 10 --loop
> 
> to:
> 
> cvlc -vvv myvideo.mpg --sout
> '#std{access=udp,mux=ts,dst=234.5.6.8:1234}' --ttl 10 --loop
> 
> triggers the problem.
> 
> Other than the small multicast address change nothing else is
> different,
> so I'm not aware of any reason that VLC would unicast encapsulate the
> traffic with one address and not the other.
> 
> Thanks,
> Jeff


From jmitchell at ll.mit.edu  Mon Jun 28 13:09:50 2010
From: jmitchell at ll.mit.edu (Jeff Mitchell)
Date: Mon, 28 Jun 2010 16:09:50 -0400
Subject: [Xorp-users] Endless PIMv2 Register messages
In-Reply-To: <05c801cb16fd$59480460$0bd80d20$@edu>
References: <4C28C0C9.4070408@ll.mit.edu> <4C28D753.80600@ll.mit.edu>
	<05b901cb16f5$50fc1f10$f2f45d30$@edu> <4C28F765.2030709@ll.mit.edu>
	<05c801cb16fd$59480460$0bd80d20$@edu>
Message-ID: <4C29018E.8080305@ll.mit.edu>

On 06/28/2010 04:06 PM, Garry Peirce wrote:
> Jeff,
> It wouldn't be the host doing this, but the DR router (in this case the XORP
> router), encapsulating the packets (within PIM control msgs) towards what it
> believes is the RP for this group.

Ah, thanks for the clarification.

> Who does XORP think the RP for 234.5.6.8 is?
> What do 'show pim neighbors' and 'show pim rps' and 'show pim mrib' look
> like?

Here are the results of running those commands from 192.168.20.1.

show pim neighbors:

rtrs                  1 192.168.20.2    2 Sparse      105      86
rtrs                  1 192.168.20.3    2 Sparse      105      93

(rtrs is the interface; those are the correct IPs for the two other XORP 
boxes)

show pim rps:

RP              Type      Pri Holdtime Timeout ActiveGroups GroupPrefix 

192.168.20.3    bootstrap   1      150     139            0 224.0.0.0/4 

192.168.20.1    bootstrap   1      150     139            0 224.0.0.0/4 

192.168.20.2    bootstrap   1      150     139            0 224.0.0.0/4

DestPrefix         NextHopRouter   VifName VifIndex MetricPref Metric
192.168.20.0/24    192.168.20.1    rtrs    1                 0      0
192.168.51.0/24    192.168.51.254  eth0.501 0                 0      0
192.168.52.0/24    192.168.20.2    rtrs    1                 1      1
192.168.53.0/24    192.168.20.3    rtrs    1                 1      1

Those look fine to me.

FWIW, I'm running Ben Greear's xorp.ct repo (a bit old by now, as it's 
been moved to GitHub) version 7e89cbe2b0e97d2f76f78b9da7fe590543a91764, 
from May 9th.

--Jeff


From william at losrios.edu  Mon Jun 28 14:10:23 2010
From: william at losrios.edu (Williams, Mark)
Date: Mon, 28 Jun 2010 21:10:23 +0000
Subject: [Xorp-users] Endless PIMv2 Register messages
In-Reply-To: <4C29018E.8080305@ll.mit.edu>
References: <4C28C0C9.4070408@ll.mit.edu> <4C28D753.80600@ll.mit.edu>
	<05b901cb16f5$50fc1f10$f2f45d30$@edu> <4C28F765.2030709@ll.mit.edu>
	<05c801cb16fd$59480460$0bd80d20$@edu>,<4C29018E.8080305@ll.mit.edu>
Message-ID: <C025046A77B3034399C773D87A765D2E027113@LRCCD-MBX01.LRCCD.ad.losrios.edu>

There should only be one RP for any particular group. Try going to your other Xorp systems (192.168.20.2 and 192.168.20.3) and removing the cand-rp section of the config. Also, keep the cand-bsr section, but only one router should have the cand-bsr-by-vif-name entry. 

-Mark Williams

________________________________________
From: xorp-users-bounces at xorp.org [xorp-users-bounces at xorp.org] on behalf of Jeff Mitchell [jmitchell at ll.mit.edu]
Sent: Monday, June 28, 2010 1:09 PM
To: Garry Peirce
Cc: xorp-users at xorp.org
Subject: Re: [Xorp-users] Endless PIMv2 Register messages

On 06/28/2010 04:06 PM, Garry Peirce wrote:
> Jeff,
> It wouldn't be the host doing this, but the DR router (in this case the XORP
> router), encapsulating the packets (within PIM control msgs) towards what it
> believes is the RP for this group.

Ah, thanks for the clarification.

> Who does XORP think the RP for 234.5.6.8 is?
> What do 'show pim neighbors' and 'show pim rps' and 'show pim mrib' look
> like?

Here are the results of running those commands from 192.168.20.1.

show pim neighbors:

rtrs                  1 192.168.20.2    2 Sparse      105      86
rtrs                  1 192.168.20.3    2 Sparse      105      93

(rtrs is the interface; those are the correct IPs for the two other XORP
boxes)

show pim rps:

RP              Type      Pri Holdtime Timeout ActiveGroups GroupPrefix

192.168.20.3    bootstrap   1      150     139            0 224.0.0.0/4

192.168.20.1    bootstrap   1      150     139            0 224.0.0.0/4

192.168.20.2    bootstrap   1      150     139            0 224.0.0.0/4

DestPrefix         NextHopRouter   VifName VifIndex MetricPref Metric
192.168.20.0/24    192.168.20.1    rtrs    1                 0      0
192.168.51.0/24    192.168.51.254  eth0.501 0                 0      0
192.168.52.0/24    192.168.20.2    rtrs    1                 1      1
192.168.53.0/24    192.168.20.3    rtrs    1                 1      1

Those look fine to me.

FWIW, I'm running Ben Greear's xorp.ct repo (a bit old by now, as it's
been moved to GitHub) version 7e89cbe2b0e97d2f76f78b9da7fe590543a91764,
from May 9th.

--Jeff

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


From peirce at maine.edu  Mon Jun 28 14:33:46 2010
From: peirce at maine.edu (Garry Peirce)
Date: Mon, 28 Jun 2010 17:33:46 -0400
Subject: [Xorp-users] Endless PIMv2 Register messages
In-Reply-To: <4C29018E.8080305@ll.mit.edu>
References: <4C28C0C9.4070408@ll.mit.edu> <4C28D753.80600@ll.mit.edu>
	<05b901cb16f5$50fc1f10$f2f45d30$@edu> <4C28F765.2030709@ll.mit.edu>
	<05c801cb16fd$59480460$0bd80d20$@edu> <4C29018E.8080305@ll.mit.edu>
Message-ID: <05e301cb1709$96f16ca0$c4d445e0$@edu>

It seems you have 3 routers in mesh (?) with all acting as BSRs for the
entire mcast block.
You may have an RP-RPF/DR issue given that.
I'll assume that .3 is likely the DR (highest IP) and perhaps the basis for
your symptom.

First hop (20.1) unicast encapsulates to .2
Join from .2 is ignored by .1 as .3 is the DR (as all are RPs covering the
same group).
.3 creates state but it would not be seen by .1 (which would then initiate
the reg-stop.)
Therefore join/reg-stop never occurs from .2 and .1 continues to send via
encaps-unicast.

1) Can you post 'sh ip pim int' for each of them?

2) Do you need all routers to be RPs? You might select just one to simply
this.
PIM-SM will eventually create SPTs for efficient traffic flow.

3) Also, I noticed this from your initial config (is this from 20.1?)
static {
         disable: false
         route 192.168.51.0/24 {
             next-hop: 192.168.20.2
             metric: 1
         }
         mrib-route 192.168.51.0/24 {
             next-hop: 192.168.20.2
             metric: 1
         }
...


And later (from 20.1 output)

DestPrefix         NextHopRouter   VifName VifIndex MetricPref Metric
192.168.20.0/24    192.168.20.1    rtrs    1                 0      0
192.168.51.0/24    192.168.51.254  eth0.501 0                 0      0


This would seem to show that 192.168.51.0/24 is known via both eth0.501
along with an 
static mrib route to it via 20.2. Perhaps this static mroute is
misconfigured?




> -----Original Message-----
> From: Jeff Mitchell [mailto:jmitchell at ll.mit.edu]
> Sent: Monday, June 28, 2010 4:10 PM
> To: Garry Peirce
> Cc: xorp-users at xorp.org
> Subject: Re: [Xorp-users] Endless PIMv2 Register messages
> 
> On 06/28/2010 04:06 PM, Garry Peirce wrote:
> > Jeff,
> > It wouldn't be the host doing this, but the DR router (in this case
> the XORP
> > router), encapsulating the packets (within PIM control msgs) towards
> what it
> > believes is the RP for this group.
> 
> Ah, thanks for the clarification.
> 
> > Who does XORP think the RP for 234.5.6.8 is?
> > What do 'show pim neighbors' and 'show pim rps' and 'show pim mrib'
> look
> > like?
> 
> Here are the results of running those commands from 192.168.20.1.
> 
> show pim neighbors:
> 
> rtrs                  1 192.168.20.2    2 Sparse      105      86
> rtrs                  1 192.168.20.3    2 Sparse      105      93
> 
> (rtrs is the interface; those are the correct IPs for the two other
> XORP
> boxes)
> 
> show pim rps:
> 
> RP              Type      Pri Holdtime Timeout ActiveGroups GroupPrefix
> 
> 192.168.20.3    bootstrap   1      150     139            0 224.0.0.0/4
> 
> 192.168.20.1    bootstrap   1      150     139            0 224.0.0.0/4
> 
> 192.168.20.2    bootstrap   1      150     139            0 224.0.0.0/4
> 
> DestPrefix         NextHopRouter   VifName VifIndex MetricPref Metric
> 192.168.20.0/24    192.168.20.1    rtrs    1                 0      0
> 192.168.51.0/24    192.168.51.254  eth0.501 0                 0      0
> 192.168.52.0/24    192.168.20.2    rtrs    1                 1      1
> 192.168.53.0/24    192.168.20.3    rtrs    1                 1      1
> 
> Those look fine to me.
> 
> FWIW, I'm running Ben Greear's xorp.ct repo (a bit old by now, as it's
> been moved to GitHub) version 7e89cbe2b0e97d2f76f78b9da7fe590543a91764,
> from May 9th.
> 
> --Jeff


From naresh_raga at yahoo.co.in  Tue Jun 29 06:29:43 2010
From: naresh_raga at yahoo.co.in (naresh raga)
Date: Tue, 29 Jun 2010 18:59:43 +0530 (IST)
Subject: [Xorp-users] Need suggestion about Embedded platform
	requirments.
In-Reply-To: <5C334A7298464653816B80D8C2A1A962@elitecore.com>
Message-ID: <943821.7996.qm@web94805.mail.in2.yahoo.com>

Thanks Saurabh for your response.

>>My experiments with xorp stats that cpu over-head
is one time in initialization. 
CPU over-head is my concern. I had 2 arm9 boards.One with 200MHz and the other with 512MHz processor.I am trying to port xorp onto either of these boards.I had cross-compiler and? cross-compiled openssl package.I have cross-compiled xorp-1.6 many times.
I have tried to cross-compile xorp-1.7.It is asking for cross-compiled boost libraries.
I think disabling ipv6,boost and log messages is in build of xorp.ct-1.8.For xorp.ct-1.8,I need to clone the repository using
git clone git://github.com/greearb/xorp.ct.git

I had problem in cloning the repository using git.
Our IIT institute uses LDAP and Kerberos systems for authorization 
and authentication.I am unable to know the procedure how to clone a repository
behind such a proxy server.

If you or Ben can mail me the xorp.ct-1.8(archived),I can work on it and use the
features Ben and you both added to it and see whether cross-compiled xorp.ct ports on
my board.

Thanks,
T Raga Naresh,
IIT Delhi.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20100629/8539de0e/attachment.html 

From greearb at candelatech.com  Tue Jun 29 07:10:35 2010
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 29 Jun 2010 07:10:35 -0700
Subject: [Xorp-users] Need suggestion about Embedded platform
	requirments.
In-Reply-To: <943821.7996.qm@web94805.mail.in2.yahoo.com>
References: <943821.7996.qm@web94805.mail.in2.yahoo.com>
Message-ID: <4C29FEDB.8070402@candelatech.com>

On 06/29/2010 06:29 AM, naresh raga wrote:
> Thanks Saurabh for your response.
>
>
>> >My experiments with xorp stats that cpu over-head is one time in
> initialization.
>
> CPU over-head is my concern. I had 2 arm9 boards.One with 200MHz and the
> other with 512MHz processor.I am trying to port xorp onto either of
> these boards.I had cross-compiler and cross-compiled openssl package.I
> have cross-compiled xorp-1.6 many times.
> I have tried to cross-compile xorp-1.7.It is asking for cross-compiled
> boost libraries.
> I think disabling ipv6,boost and log messages is in build of
> xorp.ct-1.8.For xorp.ct-1.8,I need to clone the repository using
>
> git clonegit://github.com/greearb/xorp.ct.git
>
> I had problem in cloning the repository using git.
> Our IIT institute uses LDAP and Kerberos systems for authorization
> and authentication.I am unable to know the procedure how to clone a repository
> behind such a proxy server.
>
> If you or Ben can mail me the xorp.ct-1.8(archived),I can work on it and use
>   the
> features Ben and you both added to it and see whether cross-compiled xorp.ct ports on
> my board.

You shouldn't need any authorization to download xorp.ct from github in
read-only mode:

git clone git://github.com/greearb/xorp.ct.git

Please email me the results if it does fail.

You can also download snapshots from github:

Click on the 'Download Source' button on this page:
http://github.com/greearb/xorp.ct



Thanks,
Ben

>
> Thanks,
> T Raga Naresh,
> IIT Delhi.
>
>


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


From jmitchell at ll.mit.edu  Tue Jun 29 07:27:07 2010
From: jmitchell at ll.mit.edu (Jeff Mitchell)
Date: Tue, 29 Jun 2010 10:27:07 -0400
Subject: [Xorp-users] Endless PIMv2 Register messages
In-Reply-To: <05e301cb1709$96f16ca0$c4d445e0$@edu>
References: <4C28C0C9.4070408@ll.mit.edu> <4C28D753.80600@ll.mit.edu>
	<05b901cb16f5$50fc1f10$f2f45d30$@edu> <4C28F765.2030709@ll.mit.edu>
	<05c801cb16fd$59480460$0bd80d20$@edu> <4C29018E.8080305@ll.mit.edu>
	<05e301cb1709$96f16ca0$c4d445e0$@edu>
Message-ID: <4C2A02BB.6070806@ll.mit.edu>

On 06/28/2010 05:33 PM, Garry Peirce wrote:
> It seems you have 3 routers in mesh (?)

Yes.

> with all acting as BSRs for the
> entire mcast block.

They're supposed to all be acting as candidates. The bootstrap process 
does seem to work though, given that the end result is two candidates 
and one elected:

Active zones:
BSR             Pri LocalAddress    Pri State           Timeout SZTimeout
192.168.20.3      1 192.168.20.1      1 Candidate            87        -1
Expiring zones:
BSR             Pri LocalAddress    Pri State           Timeout SZTimeout
Configured zones:
BSR             Pri LocalAddress    Pri State           Timeout SZTimeout
192.168.20.1      1 192.168.20.1      1 Init                 -1        -1


Active zones:
BSR             Pri LocalAddress    Pri State           Timeout SZTimeout
192.168.20.3      1 192.168.20.2      1 Candidate            80        -1
Expiring zones:
BSR             Pri LocalAddress    Pri State           Timeout SZTimeout
Configured zones:
BSR             Pri LocalAddress    Pri State           Timeout SZTimeout
192.168.20.2      1 192.168.20.2      1 Init                 -1        -1


Active zones:
BSR             Pri LocalAddress    Pri State           Timeout SZTimeout
192.168.20.3      1 192.168.20.3      1 Elected              59        -1
Expiring zones:
BSR             Pri LocalAddress    Pri State           Timeout SZTimeout
Configured zones:
BSR             Pri LocalAddress    Pri State           Timeout SZTimeout
192.168.20.3      1 192.168.20.3      1 Init                 -1        -1

> You may have an RP-RPF/DR issue given that.
> I'll assume that .3 is likely the DR (highest IP) and perhaps the basis for
> your symptom.
>
> First hop (20.1) unicast encapsulates to .2
> Join from .2 is ignored by .1 as .3 is the DR (as all are RPs covering the
> same group).
> .3 creates state but it would not be seen by .1 (which would then initiate
> the reg-stop.)
> Therefore join/reg-stop never occurs from .2 and .1 continues to send via
> encaps-unicast.
>
> 1) Can you post 'sh ip pim int' for each of them?

Sure:

Interface    State    Mode   V PIMstate Priority DRaddr          Neighbors
eth0.501     UP       Sparse 2 DR              1 192.168.51.254          0
rtrs         UP       Sparse 2 NotDR           1 192.168.20.3            2
register_vif UP       Sparse 2 DR              1 192.168.20.1            0

Interface    State    Mode   V PIMstate Priority DRaddr          Neighbors
eth0.502     UP       Sparse 2 DR              1 192.168.52.254          0
rtrs         UP       Sparse 2 NotDR           1 192.168.20.3            2
register_vif UP       Sparse 2 DR              1 192.168.20.2            0

Interface    State    Mode   V PIMstate Priority DRaddr          Neighbors
eth0.503     UP       Sparse 2 DR              1 192.168.53.254          0
rtrs         UP       Sparse 2 DR              1 192.168.20.3            2
register_vif UP       Sparse 2 DR              1 192.168.20.3            0

> 2) Do you need all routers to be RPs? You might select just one to simply
> this.

Not sure. I may want to have multicast traffic flowing from behind each 
one...would it be better to break up the zones in this case?

> 3) Also, I noticed this from your initial config (is this from 20.1?)
> static {
>           disable: false
>           route 192.168.51.0/24 {
>               next-hop: 192.168.20.2
>               metric: 1
>           }
>           mrib-route 192.168.51.0/24 {
>               next-hop: 192.168.20.2
>               metric: 1
>           }
> ...
>
>
> And later (from 20.1 output)
>
> DestPrefix         NextHopRouter   VifName VifIndex MetricPref Metric
> 192.168.20.0/24    192.168.20.1    rtrs    1                 0      0
> 192.168.51.0/24    192.168.51.254  eth0.501 0                 0      0
>
>
> This would seem to show that 192.168.51.0/24 is known via both eth0.501
> along with an
> static mrib route to it via 20.2. Perhaps this static mroute is
> misconfigured?

Sorry, those bits were posted at different times, and I did in fact 
change the configuration between the two times. (I had had the routers 
have the 91, 51, and 52 subnets behind them; now it's the 51, 52, and 53 
subnets corresponding to 192.168.20.1/2/3 respectively.)

Thanks,
Jeff


From jmitchell at ll.mit.edu  Tue Jun 29 09:12:19 2010
From: jmitchell at ll.mit.edu (Jeff Mitchell)
Date: Tue, 29 Jun 2010 12:12:19 -0400
Subject: [Xorp-users] Endless PIMv2 Register messages
In-Reply-To: <C025046A77B3034399C773D87A765D2E027113@LRCCD-MBX01.LRCCD.ad.losrios.edu>
References: <4C28C0C9.4070408@ll.mit.edu>
	<4C28D753.80600@ll.mit.edu>	<05b901cb16f5$50fc1f10$f2f45d30$@edu>
	<4C28F765.2030709@ll.mit.edu>	<05c801cb16fd$59480460$0bd80d20$@edu>,
	<4C29018E.8080305@ll.mit.edu>
	<C025046A77B3034399C773D87A765D2E027113@LRCCD-MBX01.LRCCD.ad.losrios.edu>
Message-ID: <4C2A1B63.3040600@ll.mit.edu>

On 06/28/2010 05:10 PM, Williams, Mark wrote:
> There should only be one RP for any particular group. Try going to your other Xorp systems (192.168.20.2 and 192.168.20.3) and removing the cand-rp section of the config. Also, keep the cand-bsr section, but only one router should have the cand-bsr-by-vif-name entry.

This fixed my problem (I had to remove the cand-bsr section as well 
since attempting to start XORP with just the cand-bsr-by-vif-name entry 
removed resulted in an error).

My understanding was that this setup should have worked, since the RP 
and BSR should have been chosen from the candidates; was this an issue 
with my configuration, or with XORP?

Thanks,
Jeff


From greearb at candelatech.com  Tue Jun 29 10:21:41 2010
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 29 Jun 2010 10:21:41 -0700
Subject: [Xorp-users] Endless PIMv2 Register messages
In-Reply-To: <4C2A1B63.3040600@ll.mit.edu>
References: <4C28C0C9.4070408@ll.mit.edu>	<4C28D753.80600@ll.mit.edu>	<05b901cb16f5$50fc1f10$f2f45d30$@edu>	<4C28F765.2030709@ll.mit.edu>	<05c801cb16fd$59480460$0bd80d20$@edu>,
	<4C29018E.8080305@ll.mit.edu>	<C025046A77B3034399C773D87A765D2E027113@LRCCD-MBX01.LRCCD.ad.losrios.edu>
	<4C2A1B63.3040600@ll.mit.edu>
Message-ID: <4C2A2BA5.2020309@candelatech.com>

On 06/29/2010 09:12 AM, Jeff Mitchell wrote:
> On 06/28/2010 05:10 PM, Williams, Mark wrote:
>> There should only be one RP for any particular group. Try going to your other Xorp systems (192.168.20.2 and 192.168.20.3) and removing the cand-rp section of the config. Also, keep the cand-bsr section, but only one router should have the cand-bsr-by-vif-name entry.
>
> This fixed my problem (I had to remove the cand-bsr section as well
> since attempting to start XORP with just the cand-bsr-by-vif-name entry
> removed resulted in an error).
>
> My understanding was that this setup should have worked, since the RP
> and BSR should have been chosen from the candidates; was this an issue
> with my configuration, or with XORP?

I run clusters of xorps with bootstrap sections on each xorp,
including cand-bsr sections, and at least in previous testing,
it seemed to be doing the right thing.

My clusters are connected by virtual ethernet links, not on a single broadcast domain
though, so maybe that makes a difference?

Thanks,
Ben


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


From naresh_raga at yahoo.co.in  Tue Jun 29 10:24:34 2010
From: naresh_raga at yahoo.co.in (naresh raga)
Date: Tue, 29 Jun 2010 22:54:34 +0530 (IST)
Subject: [Xorp-users] Need suggestion about Embedded platform requirments.
Message-ID: <985998.21908.qm@web94806.mail.in2.yahoo.com>

Hi Ben,
Thanks Ben.I have downloaded.I had a doubt.While Cross-compiling xorp-1.6,the configure command is
./configure --host=${CROSS_ARCH} --with-openssl=${CROSS_ROOT_ARCH}/usr/local/ssl
What are the corresponding options with scons.How to provide openssl to scons build.

Thanks,
Naresh.




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

From greearb at candelatech.com  Tue Jun 29 10:34:06 2010
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 29 Jun 2010 10:34:06 -0700
Subject: [Xorp-users] Need suggestion about Embedded platform
	requirments.
In-Reply-To: <985998.21908.qm@web94806.mail.in2.yahoo.com>
References: <985998.21908.qm@web94806.mail.in2.yahoo.com>
Message-ID: <4C2A2E8E.9080506@candelatech.com>

On 06/29/2010 10:24 AM, naresh raga wrote:
> Hi Ben,
> Thanks Ben.I have downloaded.I had a doubt.While Cross-compiling
> xorp-1.6,the configure command is
> ./configure --host=${CROSS_ARCH}
> --with-openssl=${CROSS_ROOT_ARCH}/usr/local/ssl
> What are the corresponding options with scons.How to provide openssl to
> scons build.

I'd try:  scons CXX=my-arm-g++ CC=my-arm-gcc

As for openssl, you are going to have to cross-compile it as well
and somehow make it visible to your build environment.  Probably
the cross-compiler toolchains are going to look somewhere special
for their standard includes and libs, so you can put the cross-compiled
openssl there.  You *might* be able to find a cross-compiled openssl
already, perhaps from wherever you got your cross-compiler toolchain.

I don't have time to deal with setting up a cross-compiler chain now, but
if you have one, and can get openssl cross-compiled, I may be able to help
with any other issues.

Thanks,
Ben


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


From naresh_raga at yahoo.co.in  Tue Jun 29 11:28:02 2010
From: naresh_raga at yahoo.co.in (naresh raga)
Date: Tue, 29 Jun 2010 23:58:02 +0530 (IST)
Subject: [Xorp-users] Need suggestion about Embedded platform
	requirments.
In-Reply-To: <4C2A2E8E.9080506@candelatech.com>
Message-ID: <100210.11211.qm@web94808.mail.in2.yahoo.com>

>I'd try:? scons CXX=my-arm-g++ CC=my-arm-gcc

>As for openssl, you 
are going to have to cross-compile it as well
>and somehow make it 
visible to your build environment.? Probably
>the cross-compiler 
toolchains are going to look somewhere special
>for their standard 
includes and libs, so you can put the cross-compiled
>openssl there.? 

>Thanks,
>Ben

I had cross-compile tool chain and cross-compiled openssl also.I can set CC,CXX,STRIP to my cross-compile toolchain binaries.But I don't know how to make cross-compiled openssl visible to scons build.In xorp-1.6 there is an option --with-openssl? while running ./configure.What about in scons.


Thanks,
Naresh.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20100629/75e277e0/attachment-0001.html 

From greearb at candelatech.com  Tue Jun 29 11:42:15 2010
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 29 Jun 2010 11:42:15 -0700
Subject: [Xorp-users] Need suggestion about Embedded platform
	requirments.
In-Reply-To: <100210.11211.qm@web94808.mail.in2.yahoo.com>
References: <100210.11211.qm@web94808.mail.in2.yahoo.com>
Message-ID: <4C2A3E87.4040004@candelatech.com>

On 06/29/2010 11:28 AM, naresh raga wrote:
>  >I'd try:  scons CXX=my-arm-g++ CC=my-arm-gcc
>
>  >As for openssl, you are going to have to cross-compile it as well
>  >and somehow make it visible to your build environment. Probably
>  >the cross-compiler toolchains are going to look somewhere special
>  >for their standard includes and libs, so you can put the cross-compiled
>  >openssl there.
>
>  >Thanks,
>  >Ben
>
> I had cross-compile tool chain and cross-compiled openssl also.I can set
> CC,CXX,STRIP to my cross-compile toolchain binaries.But I don't know how
> to make cross-compiled openssl visible to scons build.In xorp-1.6 there
> is an option --with-openssl while running ./configure.What about in scons.

Would it be easy for you to tar up the whole cross-compiler chain and
upload it somewhere I could get it?

I might need to add some scons logic to enable specifying where
to find openssl.

Thanks,
Ben

>
>
> Thanks,
> Naresh.
>
>


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


From naresh_raga at yahoo.co.in  Tue Jun 29 12:33:19 2010
From: naresh_raga at yahoo.co.in (naresh raga)
Date: Wed, 30 Jun 2010 01:03:19 +0530 (IST)
Subject: [Xorp-users] Need suggestion about Embedded platform
	requirments.
Message-ID: <435658.59217.qm@web94811.mail.in2.yahoo.com>

Hi Ben,
I have used a file hosting site to upload the cross-compiler tool chain .I have compiled openssl using the steps(points e,f and g) said in BUILD_NOTES of xorp-1.6.
Therefore,openssl is installed in $CROSS_ROOT_ARCH=
/crosstool/arm-linux/gcc-3.3.4-glibc-2.3.2/arm-linux/usr/local/ssl

The cross-tool chain is provided by Technologic systems(ARM Board TS-7300 manufacturers) but not built using kegel.com.

The link to download is:
http://www.filehosting.org/file/details/154445/yDk3Pw8KtRvwKQdw/crosstool.tar.bz2

If you are unable to download,please tell me.

Thanks,
Naresh.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20100630/85c9ad05/attachment.html 

From naresh_raga at yahoo.co.in  Tue Jun 29 13:02:30 2010
From: naresh_raga at yahoo.co.in (naresh raga)
Date: Wed, 30 Jun 2010 01:32:30 +0530 (IST)
Subject: [Xorp-users] Need suggestion about Embedded platform requirments.
Message-ID: <430208.46899.qm@web94802.mail.in2.yahoo.com>

Hi Ben,
I have built xorp.ct-1.8 on my system.The scons command used to build is:
?scons -j4 disable_ipv6=yes disable_fw=yes enable_olsr=no optimize=size disable_profile=yes strip=yes.
The build is successful and the size of /usr/local/xorp came around 13.3 MB.
I have tried to build same xorp.ct-1.8 with cross-compiler tool chain.The command used is:

$sudo scons -j4 CC=/opt/crosstool/arm-linux/gcc-3.3.4-glibc-2.3.2/bin/arm-linux-gcc CXX=/opt/crosstool/arm-linux/gcc-3.3.4-glibc-2.3.2/bin/arm-linux-g++ STRIP=/opt/crosstool/arm-linux/gcc-3.3.4-glibc-2.3.2/bin/arm-linux-strip host=arm-linux os=linux strip=yes disable_ipv6=yes disable_fw=yes enable_olsr=no optimize=size disbale_profile=yes

Finally this resulted in an error saying:
ERROR:? Cannot find required openssl/md5.h.
? On Fedora/RedHat:? yum install openssl-devel
? After install, rm -fr xorp/obj build directory to
? clear the configure cache before re-building.

This problem is definitely related to cross-compiled openssl.

I am also posting here the complete message generated by build before resulting in the error:

scons: Reading SConscript files ...
Mkdir("/home/raganaresh/Desktop/xorpbencross/obj/i686-pc-linux-gnu")
Mkdir("/home/raganaresh/Desktop/xorpbencross/obj/i686-pc-linux-gnu")
scons: *** /home/raganaresh/Desktop/xorpbencross/obj/i686-pc-linux-gnu: File exists
Build System Type:? i686-pc-linux-gnu
Host System Type:?? arm-unknown-linux-gnu
Source path:??????? /home/raganaresh/Desktop/xorpbencross
Build path:???????? /home/raganaresh/Desktop/xorpbencross/obj/i686-pc-linux-gnu
Install prefix:???? /usr/local/xorp
CC:??????????????? /opt/crosstool/arm-linux/gcc-3.3.4-glibc-2.3.2/bin/arm-linux-gcc
CXX:?????????????? /opt/crosstool/arm-linux/gcc-3.3.4-glibc-2.3.2/bin/arm-linux-g++
STRIP:???????????? /opt/crosstool/arm-linux/gcc-3.3.4-glibc-2.3.2/bin/arm-linux-strip
Strip binaries:??? True
Optimize code:???? size
Profile code:????? no
Default XRL transport: local
Shared libraries:? True
Use rtld ORIGIN:?? True
Ignore check errors:? False
Debug symbols:???? full
Debug STL:???????? False
Debug messages:??? False
Debug function names:? False
Debug callbacks:?? False
Debug XRL syntax:? False
Enable OLSR:?????? False
Enable OSPF:?????? True
Enable RIP:??????? True
Enable VRRP:?????? True
Enable xorpsh????? True
Enable Test Programs:? False
Enable CLICK:????? False
Enable FEA Dummy:? True
Enable BGP:??????? True
Try Enable BOOST:? False
Try Enable uSTL :? False
Disable IPv6:????? True
Disable Firewall:? True
Disable Profile :? False
Disable warning logs :? False
Disable error logs :? False
Disable trace logs :? False
Disable fatal logs :? False
Disable info logs :? False
Disable assert logs :? False
Disable other logs :? False
Checking whether byte ordering is bigendian... (cached) no
Checking for C header file stdint.h... yes
Checking for C header file inttypes.h... yes
Checking for C type int8_t... yes
Checking for C type uint8_t... yes
Checking for C type int16_t... yes
Checking for C type uint16_t... yes
Checking for C type int32_t... yes
Checking for C type uint32_t... yes
Checking for C type int64_t... yes
Checking for C type uint64_t... yes
Checking for C header file stddef.h... yes
Checking for C header file stdarg.h... yes
Checking for C header file stdlib.h... yes
Checking for C header file strings.h... yes
Checking for C header file string.h... yes
Checking for C header file signal.h... yes
Checking for C header file math.h... yes
Checking for C header file memory.h... yes
Checking for C function strftime()... yes
Checking for C function strlcpy()... no
Checking for C function strlcat()... no
Checking whether va_copy is declared... yes
Checking for C header file sys/types.h... yes
Checking for C header file fcntl.h... yes
Checking for C header file getopt.h... yes
Checking for C header file glob.h... yes
Checking for C header file grp.h... yes
Checking for C header file pthread.h... yes
Checking for C header file pwd.h... yes
Checking for C header file mqueue.h... no
Checking for C header file regex.h... yes
Checking for C header file syslog.h... yes
Checking for C header file termios.h... yes
Checking for C header file time.h... yes
Checking for C header file unistd.h... yes
Checking for C header file vfork.h... no
Checking for C function readv()... yes
Checking for C function strerror()... yes
Checking for C function syslog()... yes
Checking for C function uname()... yes
Checking for C function writev()... yes
Checking for C library xnet... no
Checking for C function recvmsg()... yes
Checking for C function sendmsg()... yes
Checking for C library rt... yes
Checking for C function clock_gettime()... yes
Checking whether CLOCK_MONOTONIC is declared... no
Checking whether CLOCK_MONOTONIC_FAST is declared... no
Checking for C type struct timespec... yes
Checking for C header file paths.h... yes
Checking for C header file sysexits.h... yes
Checking for C function realpath()... yes
Checking for C function strptime()... yes
Checking for C function sysctl()... yes
Checking for C header file netdb.h... yes
Checking for C library resolv... yes
Checking for C function hstrerror()... yes
Checking for C header file sys/cdefs.h... yes
Checking for C header file sys/param.h... yes
Checking for C header file sys/utsname.h... yes
Checking for C header file sys/errno.h... yes
Checking for C header file sys/wait.h... yes
Checking for C header file sys/signal.h... yes
Checking for C header file sys/time.h... yes
Checking for C header file sys/uio.h... yes
Checking for C header file sys/ioctl.h... yes
Checking for C header file sys/select.h... yes
Checking for C header file sys/socket.h... yes
Checking for C header file sys/sockio.h... no
Checking for C header file sys/un.h... yes
Checking for C header file sys/mount.h... yes
Checking for C header file sys/resource.h... yes
Checking for C header file sys/stat.h... yes
Checking for C header file sys/syslog.h... yes
Checking for C header file sys/linker.h... no
Checking for C header file sys/sysctl.h... yes
Checking for C header file linux/types.h... yes
Checking for C header file linux/sockios.h... yes
Checking for C type struct iovec... yes
Checking for C type struct msghdr... yes
Checking for C type struct cmsghdr... yes
Checking whether AF_INET is declared... yes
Checking whether AF_INET6 is declared... yes
Checking whether SOCK_STREAM is declared... yes
Checking whether SOCK_DGRAM is declared... yes
Checking whether SOCK_RAW is declared... yes
Checking whether C type struct msghdr has member msg_control... yes
Checking whether C type struct msghdr has member msg_iov... yes
Checking whether C type struct msghdr has member msg_name... yes
Checking whether C type struct msghdr has member msg_namelen... yes
Checking whether C type struct sockaddr has member sa_len... no
Checking whether C type struct sockaddr_storage has member ss_len... no
Checking whether C type struct sockaddr_un has member sun_len... no
Checking for C header file net/ethernet.h... yes
Checking for C header file sys/ethernet.h... no
Checking for C header file net/if.h... yes
Checking for C header file net/if_arp.h... yes
Checking for C header file net/if_dl.h... no
Checking for C header file net/if_ether.h... no
Checking for C header file net/if_media.h... no
Checking for C header file net/if_var.h... no
Checking for C header file net/if_types.h... no
Checking for C header file net/route.h... yes
Checking for C header file ifaddrs.h... yes
Checking for C header file stropts.h... yes
Checking for C header file linux/ethtool.h... no
Checking for C header file linux/if_tun.h... yes
Checking for C header file linux/netlink.h... yes
Checking for C header file linux/rtnetlink.h... yes
Checking whether RTA_TABLE is declared... no
Checking whether C type struct sockaddr_dl has member sdl_len... no
Checking whether C type struct ifreq has member ifr_hwaddr... yes
Checking whether C type struct ifreq has member ifr_ifindex... yes
Checking for C function ether_aton()... yes
Checking for C function ether_aton_r()... yes
Checking for C function ether_ntoa()... yes
Checking for C function ether_ntoa_r()... yes
Checking for C function getaddrinfo()... yes
Checking for C function getifaddrs()... yes
Checking for C function getnameinfo()... yes
Checking for C function if_indextoname()... yes
Checking for C function if_nametoindex()... yes
Checking for C function inet_ntop()... yes
Checking for C function inet_pton()... yes
Checking for C type struct ether_addr... yes
Checking whether system has sysctl NET_RT_DUMP... no
Checking whether system has sysctl NET_RT_IFLIST... no
Checking whether SIOCGIFCONF is declared... yes
Checking for C header file netinet/in.h... yes
Checking for C header file netinet/in_systm.h... yes
Checking for C header file netinet/in_var.h... no
Checking for C header file netinet/ip.h... yes
Checking for C header file netinet/tcp.h... yes
Checking for C header file netinet/igmp.h... yes
Checking for C header file netinet/ether.h... yes
Checking for C header file netinet/if_ether.h... yes
Checking for C header file inet/nd.h... no
Checking for C header file inet/ip.h... no
Checking for C header file arpa/inet.h... yes
Checking for C header file arpa/telnet.h... yes
Checking whether C type struct sockaddr_in has member sin_len... no
Checking whether IP_MULTICAST_IF is declared... yes
Checking whether IP_MULTICAST_TTL is declared... yes
Checking whether IP_MULTICAST_LOOP is declared... yes
Checking whether IP_ADD_MEMBERSHIP is declared... yes
Checking whether IP_DROP_MEMBERSHIP is declared... yes
Enabling MULT_MCAST_TABLES logic since we are compiling for Linux.

Checking whether system has sysctl IPCTL_FORWARDING... no
Checking whether __KAME__ is declared... no
Checking whether inet6_opt_init is declared... no
Checking whether C type struct sockaddr_in6 has member sin6_len... no
Checking whether C type struct sockaddr_in6 has member sin6_scope_id... yes
Checking for C header file netinet/ip6.h... yes
Checking for C header file netinet/icmp6.h... yes
Checking for C type struct mld_hdr... no
Checking for C header file netinet6/in6_var.h... no
Checking for C header file netinet6/nd6.h... no
Checking for C++ header file netinet6/nd6.h... no
Checking whether system has sysctl IPV6CTL_FORWARDING... no
Checking whether system has sysctl IPV6CTL_ACCEPT_RTADV... no
Checking whether IPV6_MULTICAST_IF is declared... yes
Checking whether IPV6_MULTICAST_LOOP is declared... yes
Checking for C header file netinet/ip_mroute.h... no
Checking for C header file net/ip_mroute/ip_mroute.h... no
Checking for C header file linux/mroute.h... no
Checking for C header file linux/mroute.h... yes
Checking for C type struct mfcctl2... no
Checking whether C type struct mfcctl2 has member mfcc_flags... no
Checking whether C type struct mfcctl2 has member mfcc_rp... no
Checking for C header file netinet/pim.h... no
Checking for C type struct pim... no
Checking whether C type struct pim has member pim_vt... no
Checking for C header file netinet6/ip6_mroute.h... no
Checking for C header file linux/mroute6.h... no
Checking for C type struct mf6cctl2... no
Checking whether C type struct mf6cctl2 has member mf6cc_flags... no
Checking whether C type struct mf6cctl2 has member mf6cc_rp... no
Checking whether C type struct mif6ctl has member vifc_threshold... no
Checking for C header file netinet/ip_compat.h... no
Checking for C header file netinet/ip_fil.h... no
Checking for C header file netinet/ip_fw.h... no
Checking for C header file net/pfvar.h... no
Checking for C++ header file linux/netfilter_ipv4/ip_tables.h... no
Checking for C++ header file linux/netfilter_ipv6/ip6_tables.h... no
Checking for C header file net/if_vlanvar.h... no
Checking for C header file net/if_vlan_var.h... no
Checking for C header file net/vlan/if_vlan_var.h... no
Checking for C header file linux/if_vlan.h... yes
Checking whether GET_VLAN_REALDEV_NAME_CMD is declared... no
Checking whether GET_VLAN_VID_CMD is declared... no
Checking for C header file pcre.h... no
Checking for C header file pcreposix.h... no
Checking for C library pcre... no
Checking for C library pcreposix... no
Checking for C header file openssl/md5.h... no

ERROR:? Cannot find required openssl/md5.h.

? On Fedora/RedHat:? yum install openssl-devel

? After install, rm -fr xorp/obj build directory to

? clear the configure cache before re-building.


Thanks,
Naresh.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20100630/2990680e/attachment-0001.html 

From greearb at candelatech.com  Tue Jun 29 14:40:54 2010
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 29 Jun 2010 14:40:54 -0700
Subject: [Xorp-users] Need suggestion about Embedded platform
	requirments.
In-Reply-To: <430208.46899.qm@web94802.mail.in2.yahoo.com>
References: <430208.46899.qm@web94802.mail.in2.yahoo.com>
Message-ID: <4C2A6866.1020703@candelatech.com>

On 06/29/2010 01:02 PM, naresh raga wrote:
> Hi Ben,
> I have built xorp.ct-1.8 on my system.The scons command used to build is:
> scons -j4 disable_ipv6=yes disable_fw=yes enable_olsr=no optimize=size
> disable_profile=yes strip=yes.
> The build is successful and the size of /usr/local/xorp came around 13.3 MB.
> I have tried to build same xorp.ct-1.8 with cross-compiler tool
> chain.The command used is:

This command below got me past the openssl part, but now we need a cross-compiled ncurses library.

scons CC=arm-linux-gcc CXX=arm-linux-g++ CXXFLAGS=-I/home/greearb/crosstool/arm-linux/gcc-3.3.4-glibc-2.3.2/arm-linux/usr/local/ssl/include 
LINKFLAGS=-L/home/greearb/crosstool/arm-linux/gcc-3.3.4-glibc-2.3.2/arm-linux/usr/local/ssl/lib 
CFLAGS=-I/home/greearb/crosstool/arm-linux/gcc-3.3.4-glibc-2.3.2/arm-linux/usr/local/ssl/include

Thanks,
Ben

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


From greearb at candelatech.com  Tue Jun 29 14:43:38 2010
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 29 Jun 2010 14:43:38 -0700
Subject: [Xorp-users] Need suggestion about Embedded platform
	requirments.
In-Reply-To: <4C2A6866.1020703@candelatech.com>
References: <430208.46899.qm@web94802.mail.in2.yahoo.com>
	<4C2A6866.1020703@candelatech.com>
Message-ID: <4C2A690A.2000507@candelatech.com>

On 06/29/2010 02:40 PM, Ben Greear wrote:
> On 06/29/2010 01:02 PM, naresh raga wrote:
>> Hi Ben,
>> I have built xorp.ct-1.8 on my system.The scons command used to build is:
>> scons -j4 disable_ipv6=yes disable_fw=yes enable_olsr=no optimize=size
>> disable_profile=yes strip=yes.
>> The build is successful and the size of /usr/local/xorp came around
>> 13.3 MB.
>> I have tried to build same xorp.ct-1.8 with cross-compiler tool
>> chain.The command used is:
>
> This command below got me past the openssl part, but now we need a
> cross-compiled ncurses library.
>
> scons CC=arm-linux-gcc CXX=arm-linux-g++
> CXXFLAGS=-I/home/greearb/crosstool/arm-linux/gcc-3.3.4-glibc-2.3.2/arm-linux/usr/local/ssl/include
> LINKFLAGS=-L/home/greearb/crosstool/arm-linux/gcc-3.3.4-glibc-2.3.2/arm-linux/usr/local/ssl/lib
> CFLAGS=-I/home/greearb/crosstool/arm-linux/gcc-3.3.4-glibc-2.3.2/arm-linux/usr/local/ssl/include

I should have mentioned..I had these hacks to SConstruct in as well.  Trying to figure out the
right way to do this now:

[greearb at ben-dt2 xorp]$ git diff
diff --git a/xorp/SConstruct b/xorp/SConstruct
index 04307ce..43346c3 100644
--- a/xorp/SConstruct
+++ b/xorp/SConstruct
@@ -159,13 +159,22 @@ if (len(COMMAND_LINE_TARGETS) == 0):

  # XXX TODO: Make initial CPPPATH/LIBPATH derive from
  # autodetected host system *or* command line.
+#env = Environment(
+#                TOOLS = ['default', 'autotest', 'clntgen', 'tgtgen',
+#                         'TOOL_SUBST'],
+#                ENV = os.environ,
+#                BUILDDIR = builddir,
+#                CPPPATH=['/usr/local/include', '$BUILDDIR'],
+#                LIBPATH=['usr/lib', '/usr/local/lib'],
+#                variables = vars)
+
  env = Environment(
                   TOOLS = ['default', 'autotest', 'clntgen', 'tgtgen',
                            'TOOL_SUBST'],
                   ENV = os.environ,
                   BUILDDIR = builddir,
-                 CPPPATH=['/usr/local/include', '$BUILDDIR'],
-                 LIBPATH=['usr/lib', '/usr/local/lib'],
+                 CPPPATH=['$BUILDDIR'],
+                 LIBPATH=['usr/lib'],
                   variables = vars)

  prefix = env['prefix']
@@ -499,6 +508,10 @@ else:
  if not env.GetOption('clean') and \
     not env.GetOption('help'):

+    env.AppendUnique( CFLAGS = Split(ARGUMENTS.get('CFLAGS', '')) )
+    env.AppendUnique( CXXFLAGS = Split(ARGUMENTS.get('CXXFLAGS', '')) )
+    env.AppendUnique( LINKFLAGS = Split(ARGUMENTS.get('LINKFLAGS', '')) )
+
      env['MISSING_DEPS'] = []
      env['SKIPPED_DEPS'] = []

@@ -638,10 +651,6 @@ if SCons.Tool.FindTool(['gcc'], env) is None or \
     SCons.Tool.FindTool(['g++'], env) is None:
      print gnutoolwarning % 'gcc or g++ compiler'

-env.AppendUnique( CFLAGS = Split(ARGUMENTS.get('CFLAGS', '')) )
-env.AppendUnique( CXXFLAGS = Split(ARGUMENTS.get('CXXFLAGS', '')) )
-env.AppendUnique( LINKFLAGS = Split(ARGUMENTS.get('LINKFLAGS', '')) )
-
  # If the user didn't override our default optimization, then
  # sanitize user's CFLAGS/CXXFLAGS to not contain optimization options,
  # and map to an appropriate GCC flag.


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


From greearb at candelatech.com  Tue Jun 29 19:38:29 2010
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 29 Jun 2010 19:38:29 -0700
Subject: [Xorp-users] Need suggestion about Embedded platform
	requirments.
In-Reply-To: <430208.46899.qm@web94802.mail.in2.yahoo.com>
References: <430208.46899.qm@web94802.mail.in2.yahoo.com>
Message-ID: <4C2AAE25.5030404@candelatech.com>

On 06/29/2010 01:02 PM, naresh raga wrote:
> Hi Ben,
> I have built xorp.ct-1.8 on my system.The scons command used to build is:
> scons -j4 disable_ipv6=yes disable_fw=yes enable_olsr=no optimize=size
> disable_profile=yes strip=yes.
> The build is successful and the size of /usr/local/xorp came around 13.3 MB.
> I have tried to build same xorp.ct-1.8 with cross-compiler tool
> chain.The command used is:

I just pushed new commits to XORP.CT with some detailed instructions
for building a cross-compiled xorp for the ARM processor.  (Similar
instructions should work for other compilers).

See BUILD_NOTES for the details.

I don't have a way to test the resulting binaries, but at least it
seemed to build clean.

Please let me know if that works for you.

Thanks,
Ben

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


From naresh_raga at yahoo.co.in  Wed Jun 30 11:38:33 2010
From: naresh_raga at yahoo.co.in (naresh raga)
Date: Thu, 1 Jul 2010 00:08:33 +0530 (IST)
Subject: [Xorp-users] Need suggestion about Embedded platform
	requirments.
In-Reply-To: <4C2AAE25.5030404@candelatech.com>
Message-ID: <30690.65074.qm@web94807.mail.in2.yahoo.com>

Hi Ben,
I have followed the steps for cross-compilation part in xorp.ct-1.8.I have built cross-compiled xorp successfully.The cross-compiled xorp is running successfully on the embedded target.The features of my embedded platform (TS-7300) are:
200MHz ARM9 CPU

32MB SDRAM
For more details of the embedded target I am using,follow the below link:
http://www.embeddedarm.com/products/board-detail.php?product=TS-7300

Thanks Ben,your work is great.The command I used for scons build is:
sudo scons -j4 build=arm-linux STRIP=/opt/crosstool/arm-linux/gcc-3.3.4-glibc-2.3.2/bin/arm-linux-strip CC=/opt/crosstool/arm-linux/gcc-3.3.4-glibc-2.3.2/bin/arm-linux-gcc CXX=/opt/crosstool/arm-linux/gcc-3.3.4-glibc-2.3.2/bin/arm-linux-g++ CFLAGS=-I/opt/crosstool/arm-linux/gcc-3.3.4-glibc-2.3.2/arm-linux/include CXXFLAGS=-I/opt/crosstool/arm-linux/gcc-3.3.4-glibc-2.3.2/arm-linux/include LINKFLAGS=-L/opt/crosstool/arm-linux/gcc-3.3.4-glibc-2.3.2/arm-linux/lib disable_ipv6=yes disable_fw=yes enable_olsr=no optimize=size disable_profile=yes strip=yes install

But I am seeing many warning messages while running ./xorp_rtrmgr of your build.But there are no such messages while running? xorp-1.7 .

Thanks,
Naresh.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20100701/392a4bf5/attachment.html 

From greearb at candelatech.com  Wed Jun 30 11:51:45 2010
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 30 Jun 2010 11:51:45 -0700
Subject: [Xorp-users] Need suggestion about Embedded platform
	requirments.
In-Reply-To: <30690.65074.qm@web94807.mail.in2.yahoo.com>
References: <30690.65074.qm@web94807.mail.in2.yahoo.com>
Message-ID: <4C2B9241.8050502@candelatech.com>

On 06/30/2010 11:38 AM, naresh raga wrote:
> Hi Ben,
> I have followed the steps for cross-compilation part in xorp.ct-1.8.I
> have built cross-compiled xorp successfully.The cross-compiled xorp is
> running successfully on the embedded target.The features of my embedded
> platform (TS-7300) are:
> 200MHz ARM9 CPU
> 32MB SDRAM
> For more details of the embedded target I am using,follow the below link:
> http://www.embeddedarm.com/products/board-detail.php?product=TS-7300
>
> Thanks Ben,your work is great.The command I used for scons build is:
> sudo scons -j4 build=arm-linux
> STRIP=/opt/crosstool/arm-linux/gcc-3.3.4-glibc-2.3.2/bin/arm-linux-strip
> CC=/opt/crosstool/arm-linux/gcc-3.3.4-glibc-2.3.2/bin/arm-linux-gcc
> CXX=/opt/crosstool/arm-linux/gcc-3.3.4-glibc-2.3.2/bin/arm-linux-g++
> CFLAGS=-I/opt/crosstool/arm-linux/gcc-3.3.4-glibc-2.3.2/arm-linux/include CXXFLAGS=-I/opt/crosstool/arm-linux/gcc-3.3.4-glibc-2.3.2/arm-linux/include
> LINKFLAGS=-L/opt/crosstool/arm-linux/gcc-3.3.4-glibc-2.3.2/arm-linux/lib
> disable_ipv6=yes disable_fw=yes enable_olsr=no optimize=size
> disable_profile=yes strip=yes install
>
> But I am seeing many warning messages while running ./xorp_rtrmgr of
> your build.But there are no such messages while running xorp-1.7 .

Please do post those error messages.

Are you seeing any problems other than error messages?

Thanks,
Ben

>
> Thanks,
> Naresh.
>
>


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


From william at losrios.edu  Wed Jun 30 13:25:01 2010
From: william at losrios.edu (Williams, Mark)
Date: Wed, 30 Jun 2010 20:25:01 +0000
Subject: [Xorp-users] MFEA crashing on system with subinterfaces
Message-ID: <C025046A77B3034399C773D87A765D2E028152@LRCCD-MBX01.LRCCD.ad.losrios.edu>

Hello,

I have been successfully using Xorp to perform PIM-SM multicast routing within our network. I recently deployed a new Linux system that uses 802.1q sub-interfaces, and I am having a problem with the Xorp mfea.

If I start Xorp with a minimal configuration that includes only the interface defenitions, it starts fine. But as soon as I add an IGMP or PIM interface, I get this error

[ 2010/06/30 13:21:39  INFO xorp_rtrmgr:13238 RTRMGR +101 module_manager.cc execute ] Executing module: mfea4 (fea/xorp_fea)
[ 2010/06/30 13:21:39  FATAL xorp_fea:13239 MFEA +539 mfea_node.cc vif_update ] Assertion (vif_index != Vif::VIF_INDEX_INVALID) failed
[ 2010/06/30 13:21:39  ERROR xorp_rtrmgr:13238 RTRMGR +754 module_manager.cc done_cb ] Command "/usr/local/xorp/fea/xorp_fea": terminated with signal 6.
[ 2010/06/30 13:21:39  INFO xorp_rtrmgr:13238 RTRMGR +299 module_manager.cc module_exited ] Module abnormally killed: fea
[ 2010/06/30 13:21:39  INFO xorp_rtrmgr:13238 RTRMGR +299 module_manager.cc module_exited ] Module abnormally killed: firewall
[ 2010/06/30 13:21:39  INFO xorp_rtrmgr:13238 RTRMGR +299 module_manager.cc module_exited ] Module abnormally killed: interfaces
[ 2010/06/30 13:21:39  INFO xorp_rtrmgr:13238 RTRMGR +299 module_manager.cc module_exited ] Module abnormally killed: mfea4
[ 2010/06/30 13:21:39  ERROR xorp_rtrmgr:13238 RTRMGR +2003 task.cc task_fail ] Shutting down fatally wounded process (mfea4)
[ 2010/06/30 13:21:39  ERROR xorp_rtrmgr:13238 RTRMGR +691 master_conf_tree.cc commit_pass2_done ] Commit failed: Can't startup process mfea4
I did some searches, but couldn't find anything conclusive. Is there a known problem with Xorp mfea and sub-interfaces?

Thanks,

-Mark Williams
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20100630/e3d576a2/attachment.html 

From jmitchell at ll.mit.edu  Wed Jun 30 13:35:46 2010
From: jmitchell at ll.mit.edu (Jeff Mitchell)
Date: Wed, 30 Jun 2010 16:35:46 -0400
Subject: [Xorp-users] MFEA crashing on system with subinterfaces
In-Reply-To: <C025046A77B3034399C773D87A765D2E028152@LRCCD-MBX01.LRCCD.ad.losrios.edu>
References: <C025046A77B3034399C773D87A765D2E028152@LRCCD-MBX01.LRCCD.ad.losrios.edu>
Message-ID: <4C2BAAA2.9050103@ll.mit.edu>

On 06/30/2010 04:25 PM, Williams, Mark wrote:
> Hello,
> I have been successfully using Xorp to perform PIM-SM multicast routing
> within our network. I recently deployed a new Linux system that uses
> 802.1q sub-interfaces, and I am having a problem with the Xorp mfea.
> If I start Xorp with a minimal configuration that includes only the
> interface defenitions, it starts fine. But as soon as I add an IGMP or
> PIM interface, I get this error
> [ 2010/06/30 13:21:39 INFO xorp_rtrmgr:13238 RTRMGR +101
> module_manager.cc execute ] Executing module: mfea4 (fea/xorp_fea)
> [ 2010/06/30 13:21:39 FATAL xorp_fea:13239 MFEA +539 mfea_node.cc
> vif_update ] Assertion (vif_index != Vif::VIF_INDEX_INVALID) failed
> [ 2010/06/30 13:21:39 ERROR xorp_rtrmgr:13238 RTRMGR +754
> module_manager.cc done_cb ] Command "/usr/local/xorp/fea/xorp_fea":
> terminated with signal 6.
> [ 2010/06/30 13:21:39 INFO xorp_rtrmgr:13238 RTRMGR +299
> module_manager.cc module_exited ] Module abnormally killed: fea
> [ 2010/06/30 13:21:39 INFO xorp_rtrmgr:13238 RTRMGR +299
> module_manager.cc module_exited ] Module abnormally killed: firewall
> [ 2010/06/30 13:21:39 INFO xorp_rtrmgr:13238 RTRMGR +299
> module_manager.cc module_exited ] Module abnormally killed: interfaces
> [ 2010/06/30 13:21:39 INFO xorp_rtrmgr:13238 RTRMGR +299
> module_manager.cc module_exited ] Module abnormally killed: mfea4
> [ 2010/06/30 13:21:39 ERROR xorp_rtrmgr:13238 RTRMGR +2003 task.cc
> task_fail ] Shutting down fatally wounded process (mfea4)
> [ 2010/06/30 13:21:39 ERROR xorp_rtrmgr:13238 RTRMGR +691
> master_conf_tree.cc commit_pass2_done ] Commit failed: Can't startup
> process mfea4
> I did some searches, but couldn't find anything conclusive. Is there a
> known problem with Xorp mfea and sub-interfaces?

I've been using them for a while now for PIM-SM.

It might help if you can paste your configuration.

Thanks,
Jeff


From greearb at candelatech.com  Wed Jun 30 14:07:29 2010
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 30 Jun 2010 14:07:29 -0700
Subject: [Xorp-users] MFEA crashing on system with subinterfaces
In-Reply-To: <C025046A77B3034399C773D87A765D2E028152@LRCCD-MBX01.LRCCD.ad.losrios.edu>
References: <C025046A77B3034399C773D87A765D2E028152@LRCCD-MBX01.LRCCD.ad.losrios.edu>
Message-ID: <4C2BB211.80508@candelatech.com>

On 06/30/2010 01:25 PM, Williams, Mark wrote:
> Hello,
> I have been successfully using Xorp to perform PIM-SM multicast routing
> within our network. I recently deployed a new Linux system that uses
> 802.1q sub-interfaces, and I am having a problem with the Xorp mfea.
> If I start Xorp with a minimal configuration that includes only the
> interface defenitions, it starts fine. But as soon as I add an IGMP or
> PIM interface, I get this error
> [ 2010/06/30 13:21:39 INFO xorp_rtrmgr:13238 RTRMGR +101
> module_manager.cc execute ] Executing module: mfea4 (fea/xorp_fea)
> [ 2010/06/30 13:21:39 FATAL xorp_fea:13239 MFEA +539 mfea_node.cc
> vif_update ] Assertion (vif_index != Vif::VIF_INDEX_INVALID) failed
> [ 2010/06/30 13:21:39 ERROR xorp_rtrmgr:13238 RTRMGR +754
> module_manager.cc done_cb ] Command "/usr/local/xorp/fea/xorp_fea":
> terminated with signal 6.
> [ 2010/06/30 13:21:39 INFO xorp_rtrmgr:13238 RTRMGR +299
> module_manager.cc module_exited ] Module abnormally killed: fea
> [ 2010/06/30 13:21:39 INFO xorp_rtrmgr:13238 RTRMGR +299
> module_manager.cc module_exited ] Module abnormally killed: firewall
> [ 2010/06/30 13:21:39 INFO xorp_rtrmgr:13238 RTRMGR +299
> module_manager.cc module_exited ] Module abnormally killed: interfaces
> [ 2010/06/30 13:21:39 INFO xorp_rtrmgr:13238 RTRMGR +299
> module_manager.cc module_exited ] Module abnormally killed: mfea4
> [ 2010/06/30 13:21:39 ERROR xorp_rtrmgr:13238 RTRMGR +2003 task.cc
> task_fail ] Shutting down fatally wounded process (mfea4)
> [ 2010/06/30 13:21:39 ERROR xorp_rtrmgr:13238 RTRMGR +691
> master_conf_tree.cc commit_pass2_done ] Commit failed: Can't startup
> process mfea4
> I did some searches, but couldn't find anything conclusive. Is there a
> known problem with Xorp mfea and sub-interfaces?
> Thanks,
> -Mark Williams

What version of xorp?  Can you try xorp.ct if you are not already
using it?

http://www.candelatech.com/xorp.ct/

Please do post your config as well.

Thanks,
Ben


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


From william at losrios.edu  Wed Jun 30 14:43:33 2010
From: william at losrios.edu (Williams, Mark)
Date: Wed, 30 Jun 2010 21:43:33 +0000
Subject: [Xorp-users] MFEA crashing on system with subinterfaces
In-Reply-To: <4C2BB211.80508@candelatech.com>
References: <C025046A77B3034399C773D87A765D2E028152@LRCCD-MBX01.LRCCD.ad.losrios.edu>,
	<4C2BB211.80508@candelatech.com>
Message-ID: <C025046A77B3034399C773D87A765D2E0281AB@LRCCD-MBX01.LRCCD.ad.losrios.edu>

I am using 1.6. 

Here is the configuration of the native interfaces on the Linux system itself:
eth0      Link encap:Ethernet  HWaddr 00:0F:20:98:A5:17
          inet addr:172.27.0.1  Bcast:172.27.255.255  Mask:255.255.0.0
          inet6 addr: fe80::20f:20ff:fe98:a517/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:845013 errors:0 dropped:0 overruns:0 frame:0
          TX packets:880720 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:107779155 (102.7 MiB)  TX bytes:147334738 (140.5 MiB)
          Interrupt:177 Memory:f7df0000-f7e00000
eth0.2400 Link encap:Ethernet  HWaddr 00:0F:20:98:A5:17
          inet addr:165.196.182.254  Bcast:165.196.182.255  Mask:255.255.255.0
          inet6 addr: fe80::20f:20ff:fe98:a517/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:770010 errors:0 dropped:0 overruns:0 frame:0
          TX packets:837373 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:80934576 (77.1 MiB)  TX bytes:135522439 (129.2 MiB)
eth0.3400 Link encap:Ethernet  HWaddr 00:0F:20:98:A5:17
          inet addr:165.196.183.254  Bcast:165.196.183.255  Mask:255.255.255.0
          inet6 addr: fe80::20f:20ff:fe98:a517/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:117 errors:0 dropped:0 overruns:0 frame:0
          TX packets:43320 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:5382 (5.2 KiB)  TX bytes:3381874 (3.2 MiB)
eth1      Link encap:Ethernet  HWaddr 00:0F:20:98:A5:01
          inet addr:172.18.255.254  Bcast:172.18.255.255  Mask:255.255.0.0
          inet6 addr: fe80::20f:20ff:fe98:a501/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:28234 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14320 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:12280669 (11.7 MiB)  TX bytes:1915095 (1.8 MiB)
          Interrupt:185 Memory:f7ff0000-f8000000
eth2      Link encap:Ethernet  HWaddr 00:13:21:78:C4:FC
          inet addr:165.196.190.253  Bcast:165.196.190.255  Mask:255.255.255.128
          inet6 addr: fe80::213:21ff:fe78:c4fc/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:18618881 errors:0 dropped:0 overruns:0 frame:0
          TX packets:24945308 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:380107056 (362.4 MiB)  TX bytes:3884887570 (3.6 GiB)
eth3      Link encap:Ethernet  HWaddr 00:13:21:78:C4:FD
          inet addr:165.196.192.253  Bcast:165.196.192.255  Mask:255.255.255.128
          inet6 addr: fe80::213:21ff:fe78:c4fd/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:29503244 errors:0 dropped:0 overruns:0 frame:0
          TX packets:40214761 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:1156470672 (1.0 GiB)  TX bytes:898363986 (856.7 MiB)
eth3.3402 Link encap:Ethernet  HWaddr 00:13:21:78:C4:FD
          inet addr:165.196.184.254  Bcast:165.196.184.255  Mask:255.255.255.0
          inet6 addr: fe80::213:21ff:fe78:c4fd/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3031290 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4972821 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:280804345 (267.7 MiB)  TX bytes:2362081912 (2.1 GiB)
eth3.3404 Link encap:Ethernet  HWaddr 00:13:21:78:C4:FD
          inet addr:165.196.185.254  Bcast:165.196.185.255  Mask:255.255.255.0
          inet6 addr: fe80::213:21ff:fe78:c4fd/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3 errors:0 dropped:0 overruns:0 frame:0
          TX packets:43322 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1053 (1.0 KiB)  TX bytes:3382106 (3.2 MiB)
eth4      Link encap:Ethernet  HWaddr 00:13:21:78:C4:FE
          inet addr:165.196.26.242  Bcast:165.196.26.255  Mask:255.255.255.240
          inet6 addr: fe80::213:21ff:fe78:c4fe/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:67174688 errors:0 dropped:0 overruns:0 frame:0
          TX packets:50465127 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:1283825546 (1.1 GiB)  TX bytes:2277745046 (2.1 GiB)
Here is my Xorp config:
fea {
    unicast-forwarding4 {
        disable: false
    }
}
interfaces {
    restore-original-config-on-shutdown: false
    interface eth4 {
        description: ""
        disable: false
        discard: false
        unreachable: false
        management: false
        default-system-config
    }
    interface eth2 {
        description: ""
        disable: false
        discard: false
        unreachable: false
        management: false
        default-system-config
    }
    interface eth3 {
        description: ""
        disable: false
        discard: false
        unreachable: false
        management: false
        default-system-config
    }
    interface eth1 {
        description: ""
        disable: false
        discard: false
        unreachable: false
        management: false
        default-system-config
    }
}
This is the output of "show interfaces" in xorpsh
eth1/eth1: Flags:<ENABLED,BROADCAST,MULTICAST> mtu 1500 speed 100 Mbps
        inet6 fe80::20f:20ff:fe98:a501 prefixlen 64
        inet 172.18.255.254 subnet 172.18.0.0/16 broadcast 172.18.255.255
        physical index 3
        ether 0:f:20:98:a5:1
eth2/eth2: Flags:<ENABLED,BROADCAST,MULTICAST> mtu 1500 speed 100 Mbps
        inet6 fe80::213:21ff:fe78:c4fc prefixlen 64
        inet 165.196.190.253 subnet 165.196.190.128/25 broadcast 165.196.190.255
        physical index 4
        ether 0:13:21:78:c4:fc
eth3/eth3: Flags:<ENABLED,BROADCAST,MULTICAST> mtu 1500 speed 100 Mbps
        inet6 fe80::213:21ff:fe78:c4fd prefixlen 64
        inet 165.196.192.253 subnet 165.196.192.128/25 broadcast 165.196.192.255
        physical index 5
        ether 0:13:21:78:c4:fd
eth3/eth3.3402: Flags:<ENABLED,BROADCAST,MULTICAST> mtu 1500 speed 100 Mbps
        inet6 fe80::213:21ff:fe78:c4fd prefixlen 64
        inet 165.196.184.254 subnet 165.196.184.0/24 broadcast 165.196.184.255
        physical index 11
        ether 0:13:21:78:c4:fd
        vlan: 3402 parent interface: eth3
eth3/eth3.3404: Flags:<ENABLED,BROADCAST,MULTICAST> mtu 1500 speed 100 Mbps
        inet6 fe80::213:21ff:fe78:c4fd prefixlen 64
        inet 165.196.185.254 subnet 165.196.185.0/24 broadcast 165.196.185.255
        physical index 12
        ether 0:13:21:78:c4:fd
        vlan: 3404 parent interface: eth3
eth4/eth4: Flags:<ENABLED,BROADCAST,MULTICAST> mtu 1500 speed 100 Mbps
        inet6 fe80::213:21ff:fe78:c4fe prefixlen 64
        inet 165.196.26.242 subnet 165.196.26.240/28 broadcast 165.196.26.255
        physical index 6
        ether 0:13:21:78:c4:fe
If I go to configure mode and enter 
root at gw-s-edc# set plumbing mfea4 interface eth4 vif eth4 disable false
[edit]
root at gw-s-edc# commit
I get the error 
Commit Failed
Can't startup process mfea4[edit]
Console output from xorp_rtrmgr process is 
 2010/06/30 14:13:54  INFO xorp_rtrmgr:20073 RTRMGR +101 module_manager.cc execute ] Executing module: mfea4 (fea/xorp_fea)
[ 2010/06/30 14:13:54  FATAL xorp_fea:20074 MFEA +539 mfea_node.cc vif_update ] Assertion (vif_index != Vif::VIF_INDEX_INVALID) failed
[ 2010/06/30 14:13:54  ERROR xorp_rtrmgr:20073 RTRMGR +754 module_manager.cc done_cb ] Command "/usr/local/xorp/fea/xorp_fea": terminated with signal 6.
[ 2010/06/30 14:13:54  INFO xorp_rtrmgr:20073 RTRMGR +299 module_manager.cc module_exited ] Module abnormally killed: fea
[ 2010/06/30 14:13:54  INFO xorp_rtrmgr:20073 RTRMGR +299 module_manager.cc module_exited ] Module abnormally killed: firewall
[ 2010/06/30 14:13:54  INFO xorp_rtrmgr:20073 RTRMGR +299 module_manager.cc module_exited ] Module abnormally killed: interfaces
[ 2010/06/30 14:13:54  INFO xorp_rtrmgr:20073 RTRMGR +299 module_manager.cc module_exited ] Module abnormally killed: mfea4
[ 2010/06/30 14:13:54  ERROR xorp_rtrmgr:20073 RTRMGR +2003 task.cc task_fail ] Shutting down fatally wounded process (mfea4)
[ 2010/06/30 14:13:54  ERROR xorp_rtrmgr:20073 RTRMGR +691 master_conf_tree.cc commit_pass2_done ] Commit failed: Can't startup process mfea4


________________________________________
From: Ben Greear [greearb at candelatech.com]
Sent: Wednesday, June 30, 2010 2:07 PM
To: Williams, Mark
Cc: xorp-users at xorp.org
Subject: Re: [Xorp-users] MFEA crashing on system with subinterfaces

On 06/30/2010 01:25 PM, Williams, Mark wrote:
> Hello,
> I have been successfully using Xorp to perform PIM-SM multicast routing
> within our network. I recently deployed a new Linux system that uses
> 802.1q sub-interfaces, and I am having a problem with the Xorp mfea.
> If I start Xorp with a minimal configuration that includes only the
> interface defenitions, it starts fine. But as soon as I add an IGMP or
> PIM interface, I get this error
> [ 2010/06/30 13:21:39 INFO xorp_rtrmgr:13238 RTRMGR +101
> module_manager.cc execute ] Executing module: mfea4 (fea/xorp_fea)
> [ 2010/06/30 13:21:39 FATAL xorp_fea:13239 MFEA +539 mfea_node.cc
> vif_update ] Assertion (vif_index != Vif::VIF_INDEX_INVALID) failed
> [ 2010/06/30 13:21:39 ERROR xorp_rtrmgr:13238 RTRMGR +754
> module_manager.cc done_cb ] Command "/usr/local/xorp/fea/xorp_fea":
> terminated with signal 6.
> [ 2010/06/30 13:21:39 INFO xorp_rtrmgr:13238 RTRMGR +299
> module_manager.cc module_exited ] Module abnormally killed: fea
> [ 2010/06/30 13:21:39 INFO xorp_rtrmgr:13238 RTRMGR +299
> module_manager.cc module_exited ] Module abnormally killed: firewall
> [ 2010/06/30 13:21:39 INFO xorp_rtrmgr:13238 RTRMGR +299
> module_manager.cc module_exited ] Module abnormally killed: interfaces
> [ 2010/06/30 13:21:39 INFO xorp_rtrmgr:13238 RTRMGR +299
> module_manager.cc module_exited ] Module abnormally killed: mfea4
> [ 2010/06/30 13:21:39 ERROR xorp_rtrmgr:13238 RTRMGR +2003 task.cc
> task_fail ] Shutting down fatally wounded process (mfea4)
> [ 2010/06/30 13:21:39 ERROR xorp_rtrmgr:13238 RTRMGR +691
> master_conf_tree.cc commit_pass2_done ] Commit failed: Can't startup
> process mfea4
> I did some searches, but couldn't find anything conclusive. Is there a
> known problem with Xorp mfea and sub-interfaces?
> Thanks,
> -Mark Williams

What version of xorp?  Can you try xorp.ct if you are not already
using it?

http://www.candelatech.com/xorp.ct/

Please do post your config as well.

Thanks,
Ben


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


From william at losrios.edu  Wed Jun 30 15:59:01 2010
From: william at losrios.edu (Williams, Mark)
Date: Wed, 30 Jun 2010 22:59:01 +0000
Subject: [Xorp-users] MFEA crashing on system with subinterfaces
In-Reply-To: <C025046A77B3034399C773D87A765D2E0281AB@LRCCD-MBX01.LRCCD.ad.losrios.edu>
References: <C025046A77B3034399C773D87A765D2E028152@LRCCD-MBX01.LRCCD.ad.losrios.edu>,
	<4C2BB211.80508@candelatech.com>,
	<C025046A77B3034399C773D87A765D2E0281AB@LRCCD-MBX01.LRCCD.ad.losrios.edu>
Message-ID: <C025046A77B3034399C773D87A765D2E0281E2@LRCCD-MBX01.LRCCD.ad.losrios.edu>

I was able to get some interfaces working by removing the default-system-config primitive and specifying all the necessary information. However, I cannot get the 802.1q tagged interfaces to work. It allows me to create a vif with a vlan-id specified, but when I try to create the mfea4 interface, I get an error saying that the underlying vif is not up. 

-Mark Williams


From greearb at candelatech.com  Wed Jun 30 16:27:54 2010
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 30 Jun 2010 16:27:54 -0700
Subject: [Xorp-users] MFEA crashing on system with subinterfaces
In-Reply-To: <C025046A77B3034399C773D87A765D2E0281E2@LRCCD-MBX01.LRCCD.ad.losrios.edu>
References: <C025046A77B3034399C773D87A765D2E028152@LRCCD-MBX01.LRCCD.ad.losrios.edu>,
	<4C2BB211.80508@candelatech.com>,
	<C025046A77B3034399C773D87A765D2E0281AB@LRCCD-MBX01.LRCCD.ad.losrios.edu>
	<C025046A77B3034399C773D87A765D2E0281E2@LRCCD-MBX01.LRCCD.ad.losrios.edu>
Message-ID: <4C2BD2FA.1050006@candelatech.com>

On 06/30/2010 03:59 PM, Williams, Mark wrote:
> I was able to get some interfaces working by removing the default-system-config primitive and specifying all the necessary information. However, I cannot get the 802.1q tagged interfaces to work. It allows me to create a vif with a vlan-id specified, but when I try to create the mfea4 interface, I get an error saying that the underlying vif is not up.

I fixed a bunch of problems related to dynamically configuring protocols
and interfaces in xorp.ct.  I don't know if it will fix your problem,
but at least it has a chance.  And, if you can still reproduce it on
xorp.ct, I'll attempt to fix it :)

One other thing, in xorp.ct, you must specify all interfaces that you want
to use in the xorp.cfg file (or later through xorpsh).  It will ignore
any interfaces present in the system that are not configured in xorp.

Thanks,
Ben

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