From feamster@lcs.mit.edu  Tue Nov  1 00:21:23 2005
From: feamster@lcs.mit.edu (Nick Feamster)
Date: Mon, 31 Oct 2005 19:21:23 -0500
Subject: [Xorp-users] Re: help establishing OSPF adjacencies
In-Reply-To: <80646.1130573270@tigger.icir.org>
References: <feamster@lcs.mit.edu> <20051029041201.GD19630@lcs.mit.edu> <80646.1130573270@tigger.icir.org>
Message-ID: <20051101002122.GD29278@lcs.mit.edu>

Atanu,

The latest code does not compile (I have been having this error for a
few days now, but didn't get around to sending this until now...figured
maybe I had a mid-update version, but it appears not).

thanks,
-Nick

g++ -g -W -Wall -Wwrite-strings -Wcast-qual -Werror -Wpointer-arith
-Wcast-alig\
n -Wstrict-prototypes -Woverloaded-virtual -ftemplate-depth-25 -pipe -o
xorp_po\
licy xorp_policy.o policy_target.o  ./.libs/libpolicy.a
./common/.libs/libpolic\
ycommon.a ../xrl/targets/.libs/libpolicybase.a
../xrl/interfaces/.libs/libpolic\
ybackendxif.a ../xrl/interfaces/.libs/libfindereventnotifierxif.a
../xrl/interf\
aces/.libs/libribxif.a ../libxipc/.libs/libxipc.a
../libcomm/.libs/libcomm.a ..\
/libxorp/.libs/libxorp.a -lcrypto
policy_target.o(.text+0x22): In function
`PolicyTarget::PolicyTarget[not-in-cha\
rge](XrlStdRouter&)':
/usr/include/c++/3.3.3/bits/list.tcc:76: undefined reference to
`ProtocolMap::P\
rotocolMap[in-charge]()'
policy_target.o(.text+0x1c0): In function
`PolicyTarget::PolicyTarget[in-charge\
](XrlStdRouter&)':
/home/feamster/xorp/policy/policy_target.cc:42: undefined reference to
`Protoco\
lMap::ProtocolMap[in-charge]()'
policy_target.o(.text+0x6cf): In function
`PolicyTarget::set_proto_target(std::\
basic_string<char, std::char_traits<char>, std::allocator<char> >
const&, std::\
basic_string<char, std::char_traits<char>, std::allocator<char> >
const&)':
/home/feamster/xorp/policy/policy_target.cc:178: undefined reference to
`Protoc\
olMap::set_xrl_target(std::basic_string<char, std::char_traits<char>,
std::allo\
cator<char> > const&, std::basic_string<char, std::char_traits<char>,
std::allo\
cator<char> > const&)'
./.libs/libpolicy.a(filter_manager.o)(.text+0x763): In function
`FilterManager:\
:update_tagmap(std::basic_string<char, std::char_traits<char>,
std::allocator<c\
har> > const&)':
/home/feamster/xorp/policy/filter_manager.cc:109: undefined reference to
`Proto\
colMap::xrl_target(std::basic_string<char, std::char_traits<char>,
std::allocat\
or<char> > const&)'
./.libs/libpolicy.a(filter_manager.o)(.text+0x975): In function
`FilterManager:\
:flush_export_queue()':
/home/feamster/xorp/policy/filter_manager.cc:140: undefined reference to
`Proto\
colMap::xrl_target(std::basic_string<char, std::char_traits<char>,
std::allocat\
or<char> > const&)'
./.libs/libpolicy.a(filter_manager.o)(.text+0xa0e):/home/feamster/xorp/policy/f\
ilter_manager.cc:145: undefined reference to
`ProtocolMap::xrl_target(std::basi\
c_string<char, std::char_traits<char>, std::allocator<char> > const&)'
./.libs/libpolicy.a(filter_manager.o)(.text+0xb72): In function
`FilterManager:\
:flush_queue(std::map<std::basic_string<char, std::char_traits<char>,
std::allo\
cator<char> >, std::basic_string<char, std::char_traits<char>,
std::allocator<c\
har> >, std::less<std::basic_string<char, std::char_traits<char>,
std::allocato\
r<char> > >, std::allocator<std::pair<std::basic_string<char,
std::char_traits<\
char>, std::allocator<char> > const, std::basic_string<char,
std::char_traits<c\
har>, std::allocator<char> > > > >&, filter::Filter)':
/home/feamster/xorp/policy/filter_manager.cc:176: undefined reference to
`Proto\
colMap::xrl_target(std::basic_string<char, std::char_traits<char>,
std::allocat\
or<char> > const&)'
./.libs/libpolicy.a(filter_manager.o)(.text+0xc0a):/home/feamster/xorp/policy/f\
ilter_manager.cc:181: undefined reference to
`ProtocolMap::xrl_target(std::basi\
c_string<char, std::char_traits<char>, std::allocator<char> > const&)'
./.libs/libpolicy.a(filter_manager.o)(.text+0xd2e):/home/feamster/xorp/policy/f\
ilter_manager.cc:205: more undefined references to
`ProtocolMap::xrl_target(std\
::basic_string<char, std::char_traits<char>, std::allocator<char> >
const&)' fo\
llow
./.libs/libpolicy.a(process_watch.o)(.text+0x4cd): In function
`ProcessWatch::b\
irth(std::basic_string<char, std::char_traits<char>,
std::allocator<char> > con\
st&)':
/home/feamster/xorp/policy/process_watch.cc:67: undefined reference to
`Protoco\
lMap::protocol(std::basic_string<char, std::char_traits<char>,
std::allocator<c\
har> > const&)'
./.libs/libpolicy.a(process_watch.o)(.text+0x52d): In function
`ProcessWatch::d\
eath(std::basic_string<char, std::char_traits<char>,
std::allocator<char> > con\
st&)':
/home/feamster/xorp/policy/process_watch.cc:79: undefined reference to
`Protoco\
lMap::protocol(std::basic_string<char, std::char_traits<char>,
std::allocator<c\
har> > const&)'
collect2: ld returned 1 exit status


On Sat, Oct 29, 2005 at 01:07:50AM -0700, Atanu Ghosh wrote:
> Hi,
> 
> I don't think that you have the latest code, I still see an Assertion in
> the trace (Assertion (do_dr_or_bdr()) failed).
> 
>     Atanu.
> 
> >>>>> "Nick" == Nick Feamster <feamster@lcs.mit.edu> writes:
> 
>     Nick> Spoke a bit too soon.  I'm still getting these error logs on
>     Nick> p4: [ 2005/10/29 00:10:27 TRACE xorp_ospfv2 OSPF ]
>     Nick> Event(DataDescriptionReceived-pse udo-event)
>     Nick> Interface(eth0/eth0) Neighbour(128.31.1.15) State(ExStart) [
>     Nick> 2005/10/29 00:10:27 TRACE xorp_ospfv2 OSPF ]
>     Nick> Event(NegotiationDone) Interface( eth0/eth0)
>     Nick> Neighbour(128.31.1.15) State(ExStart) [ 2005/10/29 00:10:27
>     Nick> TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pse
>     Nick> udo-event) Interface(eth0/eth0) Neighbour(128.31.1.15)
>     Nick> State(Exchange) [ 2005/10/29 00:10:27 TRACE xorp_ospfv2 OSPF ]
>     Nick> Event(ExchangeDone) Interface(eth 0/eth0)
>     Nick> Neighbour(128.31.1.15) State(Exchange) [ 2005/10/29 00:10:27
>     Nick> TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pse
>     Nick> udo-event) Interface(eth0/eth0) Neighbour(128.31.1.13)
>     Nick> State(Loading) [ 2005/10/29 00:10:27 TRACE xorp_ospfv2 OSPF ]
>     Nick> Event(LoadingDone) Interface(eth0 /eth0)
>     Nick> Neighbour(128.31.1.13) State(Loading) [ 2005/10/29 00:10:27
>     Nick> FATAL xorp_ospfv2:2866 OSPF +914 peer.cc is_neighbour_DR_
>     Nick> or_BDR ] Assertion (do_dr_or_bdr()) failed [ 2005/10/29
>     Nick> 00:10:37 ERROR xorp_fea:2175 FEA +433
>     Nick> fticonfig_entry_set_click.cc delete_entry ] User-level Click
>     Nick> command error: 520-Write handler '_xorp_rt4.rem ove' error:
>     Nick> 520 route '10.0.1.0/24 - -1' not found [ 2005/10/29 00:10:37
>     Nick> ERROR xorp_fea:2175 FEA +71 fti_transaction.cc operation_
>     Nick> result ] FTI transaction commit failed on DeleteEntry4: net =
>     Nick> 10.0.1.0/24 nextho p = 0.0.0.0 ifname = vifname = metric = 0
>     Nick> admin_distance = 0 xorp_route = fals e is_deleted = false
>     Nick> is_unresolved = false is_connected_route = false [ 2005/10/29
>     Nick> 00:10:37 ERROR xorp_fea:2175 FEA +433
>     Nick> fticonfig_entry_set_click.cc delete_entry ] User-level Click
>     Nick> command error: 520-Write handler '_xorp_rt4.rem ove' error:
>     Nick> 520 route '10.0.2.0/24 - -1' not found [ 2005/10/29 00:10:37
>     Nick> ERROR xorp_fea:2175 FEA +433 fticonfig_entry_set_click.cc
>     Nick> delete_entry ] User-level Click command error: 520-Write
>     Nick> handler '_xorp_rt4.rem ove' error: 520 route '10.0.3.0/24 -
>     Nick> -1' not found [ 2005/10/29 00:10:37 WARNING xorp_fea
>     Nick> XrlFeaTarget ] Handling method for redist
>     Nick> _transaction4/0.1/commit_transaction failed: XrlCmdError 102
>     Nick> Command failed Dele teEntry4: net = 10.0.1.0/24 nexthop =
>     Nick> 0.0.0.0 ifname = vifname = metric = 0 ad min_distance = 0
>     Nick> xorp_route = false is_deleted = false is_unresolved = false
>     Nick> is_ connected_route = false
> 
> 
>     Nick> On Fri, Oct 21, 2005 at 02:53:59AM -0700, Atanu Ghosh wrote:
>     >> >>>>> "Nick" == Nick Feamster <feamster@lcs.mit.edu> writes:
>     >> 
>     Nick> On Wed, Oct 19, 2005 at 03:27:03PM -0700, Atanu Ghosh wrote:
>     >> >> of the routers neighbours are the designated router or backup
>     >> >> designated router. This method should only be called if the
>     >> the >> link type is Broadcast or NBMA, as these are the only link
>     >> types >> that perform DR election. I assume that the link-type is
>     >> set to >> point-to-multipoint (p2m), in when case the assert is
>     >> signalling >> a programming error. The OSPF process will have
>     >> exited. A stack >> backtrace might yield some clues.
>     >> 
>     Nick> Yes, the link-type is p2m in our case, so perhaps this method
>     Nick> should not be called?  It appears that the OSPF process dies
>     Nick> completely as a result.  Sure, I will send along a backtrace.
>     >>  This problem is now fixed in CVS.
>     >> 
>     >> >> If the problem is reproducible with the latest code from CVS
>     >> then >> the configuration files and some information about the
>     >> topology >> would be useful.
>     >> 
>     Nick> Simple topology:
>     >>
>     Nick> A <-> B <-> C, where both links are p2m links.  I've attached
>     Nick> the configuration files.
>     >>  I'v included a cut down configuration files that worked for
>     >> me. I had to modify the prefix length from 32 to 24 on the first
>     >> router. Also you shouldn't be setting discard to true on
>     >> interfaces that you want to route traffic through.
>     >> 
>     >> >> If an attempt was made to add a route to the RIB and it failed
>     >> >> you should error messages in the log.
>     >> 
>     Nick> How do I ensure that routes are in the RIB, then?  Here's what
>     Nick> I see in the log.
>     >>  Use the show route command:
>     Xorp> show route table ipv4 unicast ospf
>     >> Network 128.31.1.15/32 Nexthop := 128.31.1.14 Metric := 10
>     >> Protocol := ospf Interface := eth0 Vif := eth0
>     >> 
>     >> To see the final table:
>     Xorp> show route table ipv4 unicast final
>     >> Network 128.31.1.0/24 Nexthop := 128.31.1.13 Metric := 0 Protocol
>     >> := connected Interface := eth0 Vif := eth0 Network 128.31.1.15/32
>     >> Nexthop := 128.31.1.14 Metric := 10 Protocol := ospf Interface :=
>     >> eth0 Vif := eth0
>     >> 
>     >> Atanu.
>     >> 
> 
>     Nick> Content-Description: p3
>     >> interfaces { interface eth0 { vif eth0 { address 128.31.1.13 {
>     >> prefix-length: 24 } } } } protocols { ospf4 { router-id:
>     >> 128.31.1.13
>     >> 
>     >> area 0.0.0.0 { interface eth0 { link-type: "p2m" vif eth0 {
>     >> address 128.31.1.13 { interface-cost: 5 neighbour 128.31.1.14 {
>     >> router-id: 128.31.1.14 } } } } } } } }
> 
>     Nick> Content-Description: p4
>     >> interfaces { interface eth0 { vif eth0 { address 128.31.1.14 {
>     >> prefix-length: 24 } } } } protocols { ospf4 { router-id:
>     >> 128.31.1.14
>     >> 
>     >> area 0.0.0.0 { interface eth0 { link-type: "p2m" vif eth0 {
>     >> address 128.31.1.14 { interface-cost: 5 neighbour 128.31.1.13 {
>     >> router-id: 128.31.1.13 } neighbour 128.31.1.15 { router-id:
>     >> 128.31.1.15 } } } } } } } }
> 
>     Nick> Content-Description: p5
>     >> interfaces { interface eth0 { vif eth0 { address 128.31.1.15 {
>     >> prefix-length: 24 } } } } protocols { ospf4 { router-id:
>     >> 128.31.1.15
>     >> 
>     >> area 0.0.0.0 { interface eth0 { link-type: "p2m" vif eth0 {
>     >> address 128.31.1.15 { interface-cost: 5 neighbour 128.31.1.13 {
>     >> router-id: 128.31.1.13 } neighbour 128.31.1.14 { router-id:
>     >> 128.31.1.14 } } } } } } } }

From atanu@ICSI.Berkeley.EDU  Tue Nov  1 00:41:59 2005
From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Mon, 31 Oct 2005 16:41:59 -0800
Subject: [Xorp-users] Re: help establishing OSPF adjacencies
In-Reply-To: Message from Nick Feamster <feamster@lcs.mit.edu>
 of "Mon, 31 Oct 2005 19:21:23 EST." <20051101002122.GD29278@lcs.mit.edu>
Message-ID: <75305.1130805719@tigger.icir.org>

Hi,

We run regression tests on a variety of platforms every night and we
haven't seen a compilation or test failure for a while.

The data structure that seems to be causing the problem ProtocolMap was
introduced 8 days ago and is in xorp/policy/protocol_map.hh. Do you have
this file in your source tree?

     Atanu.

>>>>> "Nick" == Nick Feamster <feamster@lcs.mit.edu> writes:

    Nick> Atanu, The latest code does not compile (I have been having
    Nick> this error for a few days now, but didn't get around to
    Nick> sending this until now...figured maybe I had a mid-update
    Nick> version, but it appears not).

    Nick> thanks, -Nick

    Nick> g++ -g -W -Wall -Wwrite-strings -Wcast-qual -Werror
    Nick> -Wpointer-arith -Wcast-alig\ n -Wstrict-prototypes
    Nick> -Woverloaded-virtual -ftemplate-depth-25 -pipe -o xorp_po\
    Nick> licy xorp_policy.o policy_target.o ./.libs/libpolicy.a
    Nick> ./common/.libs/libpolic\ ycommon.a
    Nick> ../xrl/targets/.libs/libpolicybase.a
    Nick> ../xrl/interfaces/.libs/libpolic\ ybackendxif.a
    Nick> ../xrl/interfaces/.libs/libfindereventnotifierxif.a
    Nick> ../xrl/interf\ aces/.libs/libribxif.a
    Nick> ../libxipc/.libs/libxipc.a ../libcomm/.libs/libcomm.a ..\
    Nick> /libxorp/.libs/libxorp.a -lcrypto policy_target.o(.text+0x22):
    Nick> In function `PolicyTarget::PolicyTarget[not-in-cha\
    Nick> rge](XrlStdRouter&)': /usr/include/c++/3.3.3/bits/list.tcc:76:
    Nick> undefined reference to `ProtocolMap::P\
    Nick> rotocolMap[in-charge]()' policy_target.o(.text+0x1c0): In
    Nick> function `PolicyTarget::PolicyTarget[in-charge\
    Nick> ](XrlStdRouter&)':
    Nick> /home/feamster/xorp/policy/policy_target.cc:42: undefined
    Nick> reference to `Protoco\ lMap::ProtocolMap[in-charge]()'
    Nick> policy_target.o(.text+0x6cf): In function
    Nick> `PolicyTarget::set_proto_target(std::\ basic_string<char,
    Nick> std::char_traits<char>, std::allocator<char> > const&, std::\
    Nick> basic_string<char, std::char_traits<char>,
    Nick> std::allocator<char> > const&)':
    Nick> /home/feamster/xorp/policy/policy_target.cc:178: undefined
    Nick> reference to `Protoc\
    Nick> olMap::set_xrl_target(std::basic_string<char,
    Nick> std::char_traits<char>, std::allo\ cator<char> > const&,
    Nick> std::basic_string<char, std::char_traits<char>, std::allo\
    Nick> cator<char> > const&)'
    Nick> ./.libs/libpolicy.a(filter_manager.o)(.text+0x763): In
    Nick> function `FilterManager:\
    Nick> :update_tagmap(std::basic_string<char, std::char_traits<char>,
    Nick> std::allocator<c\
    har> > const&)':
    Nick> /home/feamster/xorp/policy/filter_manager.cc:109: undefined
    Nick> reference to `Proto\
    Nick> colMap::xrl_target(std::basic_string<char,
    Nick> std::char_traits<char>, std::allocat\ or<char> > const&)'
    Nick> ./.libs/libpolicy.a(filter_manager.o)(.text+0x975): In
    Nick> function `FilterManager:\ :flush_export_queue()':
    Nick> /home/feamster/xorp/policy/filter_manager.cc:140: undefined
    Nick> reference to `Proto\
    Nick> colMap::xrl_target(std::basic_string<char,
    Nick> std::char_traits<char>, std::allocat\ or<char> > const&)'
    Nick> ./.libs/libpolicy.a(filter_manager.o)(.text+0xa0e):/home/feamster/xorp/policy/f\
    Nick> ilter_manager.cc:145: undefined reference to
    Nick> `ProtocolMap::xrl_target(std::basi\ c_string<char,
    Nick> std::char_traits<char>, std::allocator<char> > const&)'
    Nick> ./.libs/libpolicy.a(filter_manager.o)(.text+0xb72): In
    Nick> function `FilterManager:\
    Nick> :flush_queue(std::map<std::basic_string<char,
    Nick> std::char_traits<char>, std::allo\ cator<char> >,
    Nick> std::basic_string<char, std::char_traits<char>,
    Nick> std::allocator<c\
    har> >, std::less<std::basic_string<char, std::char_traits<char>,
    Nick> std::allocato\ r<char> > >,
    Nick> std::allocator<std::pair<std::basic_string<char,
    Nick> std::char_traits<\
    char> , std::allocator<char> > const, std::basic_string<char,
    Nick> std::char_traits<c\
    har> , std::allocator<char> > > > >&, filter::Filter)':
    Nick> /home/feamster/xorp/policy/filter_manager.cc:176: undefined
    Nick> reference to `Proto\
    Nick> colMap::xrl_target(std::basic_string<char,
    Nick> std::char_traits<char>, std::allocat\ or<char> > const&)'
    Nick> ./.libs/libpolicy.a(filter_manager.o)(.text+0xc0a):/home/feamster/xorp/policy/f\
    Nick> ilter_manager.cc:181: undefined reference to
    Nick> `ProtocolMap::xrl_target(std::basi\ c_string<char,
    Nick> std::char_traits<char>, std::allocator<char> > const&)'
    Nick> ./.libs/libpolicy.a(filter_manager.o)(.text+0xd2e):/home/feamster/xorp/policy/f\
    Nick> ilter_manager.cc:205: more undefined references to
    Nick> `ProtocolMap::xrl_target(std\ ::basic_string<char,
    Nick> std::char_traits<char>, std::allocator<char> > const&)' fo\
    Nick> llow ./.libs/libpolicy.a(process_watch.o)(.text+0x4cd): In
    Nick> function `ProcessWatch::b\ irth(std::basic_string<char,
    Nick> std::char_traits<char>, std::allocator<char> > con\ st&)':
    Nick> /home/feamster/xorp/policy/process_watch.cc:67: undefined
    Nick> reference to `Protoco\ lMap::protocol(std::basic_string<char,
    Nick> std::char_traits<char>, std::allocator<c\
    har> > const&)'
    Nick> ./.libs/libpolicy.a(process_watch.o)(.text+0x52d): In function
    Nick> `ProcessWatch::d\ eath(std::basic_string<char,
    Nick> std::char_traits<char>, std::allocator<char> > con\ st&)':
    Nick> /home/feamster/xorp/policy/process_watch.cc:79: undefined
    Nick> reference to `Protoco\ lMap::protocol(std::basic_string<char,
    Nick> std::char_traits<char>, std::allocator<c\
    har> > const&)'
    Nick> collect2: ld returned 1 exit status


    Nick> On Sat, Oct 29, 2005 at 01:07:50AM -0700, Atanu Ghosh wrote:
    >> Hi,
    >> 
    >> I don't think that you have the latest code, I still see an
    >> Assertion in the trace (Assertion (do_dr_or_bdr()) failed).
    >> 
    >> Atanu.
    >> 
    >> >>>>> "Nick" == Nick Feamster <feamster@lcs.mit.edu> writes:
    >> 
    Nick> Spoke a bit too soon.  I'm still getting these error logs on
    Nick> p4: [ 2005/10/29 00:10:27 TRACE xorp_ospfv2 OSPF ]
    Nick> Event(DataDescriptionReceived-pse udo-event)
    Nick> Interface(eth0/eth0) Neighbour(128.31.1.15) State(ExStart) [
    Nick> 2005/10/29 00:10:27 TRACE xorp_ospfv2 OSPF ]
    Nick> Event(NegotiationDone) Interface( eth0/eth0)
    Nick> Neighbour(128.31.1.15) State(ExStart) [ 2005/10/29 00:10:27
    Nick> TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pse
    Nick> udo-event) Interface(eth0/eth0) Neighbour(128.31.1.15)
    Nick> State(Exchange) [ 2005/10/29 00:10:27 TRACE xorp_ospfv2 OSPF ]
    Nick> Event(ExchangeDone) Interface(eth 0/eth0)
    Nick> Neighbour(128.31.1.15) State(Exchange) [ 2005/10/29 00:10:27
    Nick> TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pse
    Nick> udo-event) Interface(eth0/eth0) Neighbour(128.31.1.13)
    Nick> State(Loading) [ 2005/10/29 00:10:27 TRACE xorp_ospfv2 OSPF ]
    Nick> Event(LoadingDone) Interface(eth0 /eth0)
    Nick> Neighbour(128.31.1.13) State(Loading) [ 2005/10/29 00:10:27
    Nick> FATAL xorp_ospfv2:2866 OSPF +914 peer.cc is_neighbour_DR_
    Nick> or_BDR ] Assertion (do_dr_or_bdr()) failed [ 2005/10/29
    Nick> 00:10:37 ERROR xorp_fea:2175 FEA +433
    Nick> fticonfig_entry_set_click.cc delete_entry ] User-level Click
    Nick> command error: 520-Write handler '_xorp_rt4.rem ove' error:
    Nick> 520 route '10.0.1.0/24 - -1' not found [ 2005/10/29 00:10:37
    Nick> ERROR xorp_fea:2175 FEA +71 fti_transaction.cc operation_
    Nick> result ] FTI transaction commit failed on DeleteEntry4: net =
    Nick> 10.0.1.0/24 nextho p = 0.0.0.0 ifname = vifname = metric = 0
    Nick> admin_distance = 0 xorp_route = fals e is_deleted = false
    Nick> is_unresolved = false is_connected_route = false [ 2005/10/29
    Nick> 00:10:37 ERROR xorp_fea:2175 FEA +433
    Nick> fticonfig_entry_set_click.cc delete_entry ] User-level Click
    Nick> command error: 520-Write handler '_xorp_rt4.rem ove' error:
    Nick> 520 route '10.0.2.0/24 - -1' not found [ 2005/10/29 00:10:37
    Nick> ERROR xorp_fea:2175 FEA +433 fticonfig_entry_set_click.cc
    Nick> delete_entry ] User-level Click command error: 520-Write
    Nick> handler '_xorp_rt4.rem ove' error: 520 route '10.0.3.0/24 -
    Nick> -1' not found [ 2005/10/29 00:10:37 WARNING xorp_fea
    Nick> XrlFeaTarget ] Handling method for redist
    Nick> _transaction4/0.1/commit_transaction failed: XrlCmdError 102
    Nick> Command failed Dele teEntry4: net = 10.0.1.0/24 nexthop =
    Nick> 0.0.0.0 ifname = vifname = metric = 0 ad min_distance = 0
    Nick> xorp_route = false is_deleted = false is_unresolved = false
    Nick> is_ connected_route = false
    >>
    Nick> On Fri, Oct 21, 2005 at 02:53:59AM -0700, Atanu Ghosh wrote:
    >> >> >>>>> "Nick" == Nick Feamster <feamster@lcs.mit.edu> writes:
    >> >> 
    Nick> On Wed, Oct 19, 2005 at 03:27:03PM -0700, Atanu Ghosh wrote:
    >> >> >> of the routers neighbours are the designated router or
    >> backup >> >> designated router. This method should only be called
    >> if the >> the >> link type is Broadcast or NBMA, as these are the
    >> only link >> types >> that perform DR election. I assume that the
    >> link-type is >> set to >> point-to-multipoint (p2m), in when case
    >> the assert is >> signalling >> a programming error. The OSPF
    >> process will have >> exited. A stack >> backtrace might yield
    >> some clues.
    >> >> 
    Nick> Yes, the link-type is p2m in our case, so perhaps this method
    Nick> should not be called?  It appears that the OSPF process dies
    Nick> completely as a result.  Sure, I will send along a backtrace.
    >> >> This problem is now fixed in CVS.
    >> >> 
    >> >> >> If the problem is reproducible with the latest code from
    >> CVS >> then >> the configuration files and some information about
    >> the >> topology >> would be useful.
    >> >> 
    Nick> Simple topology:
    >> >>
    Nick> A <-> B <-> C, where both links are p2m links.  I've attached
    Nick> the configuration files.
    >> >> I'v included a cut down configuration files that worked for >>
    >> me. I had to modify the prefix length from 32 to 24 on the first
    >> >> router. Also you shouldn't be setting discard to true on >>
    >> interfaces that you want to route traffic through.
    >> >> 
    >> >> >> If an attempt was made to add a route to the RIB and it
    >> failed >> >> you should error messages in the log.
    >> >> 
    Nick> How do I ensure that routes are in the RIB, then?  Here's what
    Nick> I see in the log.
    >> >> Use the show route command:
    Xorp> show route table ipv4 unicast ospf
    >> >> Network 128.31.1.15/32 Nexthop := 128.31.1.14 Metric := 10 >>
    >> Protocol := ospf Interface := eth0 Vif := eth0
    >> >> 
    >> >> To see the final table:
    Xorp> show route table ipv4 unicast final
    >> >> Network 128.31.1.0/24 Nexthop := 128.31.1.13 Metric := 0
    >> Protocol >> := connected Interface := eth0 Vif := eth0 Network
    >> 128.31.1.15/32 >> Nexthop := 128.31.1.14 Metric := 10 Protocol :=
    >> ospf Interface := >> eth0 Vif := eth0
    >> >> 
    >> >> Atanu.
    >> >> 
    >> 
    Nick> Content-Description: p3
    >> >> interfaces { interface eth0 { vif eth0 { address 128.31.1.13 {
    >> >> prefix-length: 24 } } } } protocols { ospf4 { router-id: >>
    >> 128.31.1.13
    >> >> 
    >> >> area 0.0.0.0 { interface eth0 { link-type: "p2m" vif eth0 { >>
    >> address 128.31.1.13 { interface-cost: 5 neighbour 128.31.1.14 {
    >> >> router-id: 128.31.1.14 } } } } } } } }
    >> 
    Nick> Content-Description: p4
    >> >> interfaces { interface eth0 { vif eth0 { address 128.31.1.14 {
    >> >> prefix-length: 24 } } } } protocols { ospf4 { router-id: >>
    >> 128.31.1.14
    >> >> 
    >> >> area 0.0.0.0 { interface eth0 { link-type: "p2m" vif eth0 { >>
    >> address 128.31.1.14 { interface-cost: 5 neighbour 128.31.1.13 {
    >> >> router-id: 128.31.1.13 } neighbour 128.31.1.15 { router-id: >>
    >> 128.31.1.15 } } } } } } } }
    >> 
    Nick> Content-Description: p5
    >> >> interfaces { interface eth0 { vif eth0 { address 128.31.1.15 {
    >> >> prefix-length: 24 } } } } protocols { ospf4 { router-id: >>
    >> 128.31.1.15
    >> >> 
    >> >> area 0.0.0.0 { interface eth0 { link-type: "p2m" vif eth0 { >>
    >> address 128.31.1.15 { interface-cost: 5 neighbour 128.31.1.13 {
    >> >> router-id: 128.31.1.13 } neighbour 128.31.1.14 { router-id: >>
    >> 128.31.1.14 } } } } } } } }

From feamster@lcs.mit.edu  Tue Nov  1 02:44:03 2005
From: feamster@lcs.mit.edu (Nick Feamster)
Date: Mon, 31 Oct 2005 21:44:03 -0500
Subject: [Xorp-users] Re: help establishing OSPF adjacencies
In-Reply-To: <75305.1130805719@tigger.icir.org>
References: <feamster@lcs.mit.edu> <20051101002122.GD29278@lcs.mit.edu> <75305.1130805719@tigger.icir.org>
Message-ID: <20051101024403.GA29541@lcs.mit.edu>

Yes, I do.  Here is the md5 of that file in my current tree:

#md5sum protocol_map.hh 
4a823174a886b441d8260caab2953d59  protocol_map.hh

On Mon, Oct 31, 2005 at 04:41:59PM -0800, Atanu Ghosh wrote:
> Hi,
> 
> We run regression tests on a variety of platforms every night and we
> haven't seen a compilation or test failure for a while.
> 
> The data structure that seems to be causing the problem ProtocolMap was
> introduced 8 days ago and is in xorp/policy/protocol_map.hh. Do you have
> this file in your source tree?
> 
>      Atanu.
> 
> >>>>> "Nick" == Nick Feamster <feamster@lcs.mit.edu> writes:
> 
>     Nick> Atanu, The latest code does not compile (I have been having
>     Nick> this error for a few days now, but didn't get around to
>     Nick> sending this until now...figured maybe I had a mid-update
>     Nick> version, but it appears not).
> 
>     Nick> thanks, -Nick
> 
>     Nick> g++ -g -W -Wall -Wwrite-strings -Wcast-qual -Werror
>     Nick> -Wpointer-arith -Wcast-alig\ n -Wstrict-prototypes
>     Nick> -Woverloaded-virtual -ftemplate-depth-25 -pipe -o xorp_po\
>     Nick> licy xorp_policy.o policy_target.o ./.libs/libpolicy.a
>     Nick> ./common/.libs/libpolic\ ycommon.a
>     Nick> ../xrl/targets/.libs/libpolicybase.a
>     Nick> ../xrl/interfaces/.libs/libpolic\ ybackendxif.a
>     Nick> ../xrl/interfaces/.libs/libfindereventnotifierxif.a
>     Nick> ../xrl/interf\ aces/.libs/libribxif.a
>     Nick> ../libxipc/.libs/libxipc.a ../libcomm/.libs/libcomm.a ..\
>     Nick> /libxorp/.libs/libxorp.a -lcrypto policy_target.o(.text+0x22):
>     Nick> In function `PolicyTarget::PolicyTarget[not-in-cha\
>     Nick> rge](XrlStdRouter&)': /usr/include/c++/3.3.3/bits/list.tcc:76:
>     Nick> undefined reference to `ProtocolMap::P\
>     Nick> rotocolMap[in-charge]()' policy_target.o(.text+0x1c0): In
>     Nick> function `PolicyTarget::PolicyTarget[in-charge\
>     Nick> ](XrlStdRouter&)':
>     Nick> /home/feamster/xorp/policy/policy_target.cc:42: undefined
>     Nick> reference to `Protoco\ lMap::ProtocolMap[in-charge]()'
>     Nick> policy_target.o(.text+0x6cf): In function
>     Nick> `PolicyTarget::set_proto_target(std::\ basic_string<char,
>     Nick> std::char_traits<char>, std::allocator<char> > const&, std::\
>     Nick> basic_string<char, std::char_traits<char>,
>     Nick> std::allocator<char> > const&)':
>     Nick> /home/feamster/xorp/policy/policy_target.cc:178: undefined
>     Nick> reference to `Protoc\
>     Nick> olMap::set_xrl_target(std::basic_string<char,
>     Nick> std::char_traits<char>, std::allo\ cator<char> > const&,
>     Nick> std::basic_string<char, std::char_traits<char>, std::allo\
>     Nick> cator<char> > const&)'
>     Nick> ./.libs/libpolicy.a(filter_manager.o)(.text+0x763): In
>     Nick> function `FilterManager:\
>     Nick> :update_tagmap(std::basic_string<char, std::char_traits<char>,
>     Nick> std::allocator<c\
>     har> > const&)':
>     Nick> /home/feamster/xorp/policy/filter_manager.cc:109: undefined
>     Nick> reference to `Proto\
>     Nick> colMap::xrl_target(std::basic_string<char,
>     Nick> std::char_traits<char>, std::allocat\ or<char> > const&)'
>     Nick> ./.libs/libpolicy.a(filter_manager.o)(.text+0x975): In
>     Nick> function `FilterManager:\ :flush_export_queue()':
>     Nick> /home/feamster/xorp/policy/filter_manager.cc:140: undefined
>     Nick> reference to `Proto\
>     Nick> colMap::xrl_target(std::basic_string<char,
>     Nick> std::char_traits<char>, std::allocat\ or<char> > const&)'
>     Nick> ./.libs/libpolicy.a(filter_manager.o)(.text+0xa0e):/home/feamster/xorp/policy/f\
>     Nick> ilter_manager.cc:145: undefined reference to
>     Nick> `ProtocolMap::xrl_target(std::basi\ c_string<char,
>     Nick> std::char_traits<char>, std::allocator<char> > const&)'
>     Nick> ./.libs/libpolicy.a(filter_manager.o)(.text+0xb72): In
>     Nick> function `FilterManager:\
>     Nick> :flush_queue(std::map<std::basic_string<char,
>     Nick> std::char_traits<char>, std::allo\ cator<char> >,
>     Nick> std::basic_string<char, std::char_traits<char>,
>     Nick> std::allocator<c\
>     har> >, std::less<std::basic_string<char, std::char_traits<char>,
>     Nick> std::allocato\ r<char> > >,
>     Nick> std::allocator<std::pair<std::basic_string<char,
>     Nick> std::char_traits<\
>     char> , std::allocator<char> > const, std::basic_string<char,
>     Nick> std::char_traits<c\
>     har> , std::allocator<char> > > > >&, filter::Filter)':
>     Nick> /home/feamster/xorp/policy/filter_manager.cc:176: undefined
>     Nick> reference to `Proto\
>     Nick> colMap::xrl_target(std::basic_string<char,
>     Nick> std::char_traits<char>, std::allocat\ or<char> > const&)'
>     Nick> ./.libs/libpolicy.a(filter_manager.o)(.text+0xc0a):/home/feamster/xorp/policy/f\
>     Nick> ilter_manager.cc:181: undefined reference to
>     Nick> `ProtocolMap::xrl_target(std::basi\ c_string<char,
>     Nick> std::char_traits<char>, std::allocator<char> > const&)'
>     Nick> ./.libs/libpolicy.a(filter_manager.o)(.text+0xd2e):/home/feamster/xorp/policy/f\
>     Nick> ilter_manager.cc:205: more undefined references to
>     Nick> `ProtocolMap::xrl_target(std\ ::basic_string<char,
>     Nick> std::char_traits<char>, std::allocator<char> > const&)' fo\
>     Nick> llow ./.libs/libpolicy.a(process_watch.o)(.text+0x4cd): In
>     Nick> function `ProcessWatch::b\ irth(std::basic_string<char,
>     Nick> std::char_traits<char>, std::allocator<char> > con\ st&)':
>     Nick> /home/feamster/xorp/policy/process_watch.cc:67: undefined
>     Nick> reference to `Protoco\ lMap::protocol(std::basic_string<char,
>     Nick> std::char_traits<char>, std::allocator<c\
>     har> > const&)'
>     Nick> ./.libs/libpolicy.a(process_watch.o)(.text+0x52d): In function
>     Nick> `ProcessWatch::d\ eath(std::basic_string<char,
>     Nick> std::char_traits<char>, std::allocator<char> > con\ st&)':
>     Nick> /home/feamster/xorp/policy/process_watch.cc:79: undefined
>     Nick> reference to `Protoco\ lMap::protocol(std::basic_string<char,
>     Nick> std::char_traits<char>, std::allocator<c\
>     har> > const&)'
>     Nick> collect2: ld returned 1 exit status
> 
> 
>     Nick> On Sat, Oct 29, 2005 at 01:07:50AM -0700, Atanu Ghosh wrote:
>     >> Hi,
>     >> 
>     >> I don't think that you have the latest code, I still see an
>     >> Assertion in the trace (Assertion (do_dr_or_bdr()) failed).
>     >> 
>     >> Atanu.
>     >> 
>     >> >>>>> "Nick" == Nick Feamster <feamster@lcs.mit.edu> writes:
>     >> 
>     Nick> Spoke a bit too soon.  I'm still getting these error logs on
>     Nick> p4: [ 2005/10/29 00:10:27 TRACE xorp_ospfv2 OSPF ]
>     Nick> Event(DataDescriptionReceived-pse udo-event)
>     Nick> Interface(eth0/eth0) Neighbour(128.31.1.15) State(ExStart) [
>     Nick> 2005/10/29 00:10:27 TRACE xorp_ospfv2 OSPF ]
>     Nick> Event(NegotiationDone) Interface( eth0/eth0)
>     Nick> Neighbour(128.31.1.15) State(ExStart) [ 2005/10/29 00:10:27
>     Nick> TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pse
>     Nick> udo-event) Interface(eth0/eth0) Neighbour(128.31.1.15)
>     Nick> State(Exchange) [ 2005/10/29 00:10:27 TRACE xorp_ospfv2 OSPF ]
>     Nick> Event(ExchangeDone) Interface(eth 0/eth0)
>     Nick> Neighbour(128.31.1.15) State(Exchange) [ 2005/10/29 00:10:27
>     Nick> TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pse
>     Nick> udo-event) Interface(eth0/eth0) Neighbour(128.31.1.13)
>     Nick> State(Loading) [ 2005/10/29 00:10:27 TRACE xorp_ospfv2 OSPF ]
>     Nick> Event(LoadingDone) Interface(eth0 /eth0)
>     Nick> Neighbour(128.31.1.13) State(Loading) [ 2005/10/29 00:10:27
>     Nick> FATAL xorp_ospfv2:2866 OSPF +914 peer.cc is_neighbour_DR_
>     Nick> or_BDR ] Assertion (do_dr_or_bdr()) failed [ 2005/10/29
>     Nick> 00:10:37 ERROR xorp_fea:2175 FEA +433
>     Nick> fticonfig_entry_set_click.cc delete_entry ] User-level Click
>     Nick> command error: 520-Write handler '_xorp_rt4.rem ove' error:
>     Nick> 520 route '10.0.1.0/24 - -1' not found [ 2005/10/29 00:10:37
>     Nick> ERROR xorp_fea:2175 FEA +71 fti_transaction.cc operation_
>     Nick> result ] FTI transaction commit failed on DeleteEntry4: net =
>     Nick> 10.0.1.0/24 nextho p = 0.0.0.0 ifname = vifname = metric = 0
>     Nick> admin_distance = 0 xorp_route = fals e is_deleted = false
>     Nick> is_unresolved = false is_connected_route = false [ 2005/10/29
>     Nick> 00:10:37 ERROR xorp_fea:2175 FEA +433
>     Nick> fticonfig_entry_set_click.cc delete_entry ] User-level Click
>     Nick> command error: 520-Write handler '_xorp_rt4.rem ove' error:
>     Nick> 520 route '10.0.2.0/24 - -1' not found [ 2005/10/29 00:10:37
>     Nick> ERROR xorp_fea:2175 FEA +433 fticonfig_entry_set_click.cc
>     Nick> delete_entry ] User-level Click command error: 520-Write
>     Nick> handler '_xorp_rt4.rem ove' error: 520 route '10.0.3.0/24 -
>     Nick> -1' not found [ 2005/10/29 00:10:37 WARNING xorp_fea
>     Nick> XrlFeaTarget ] Handling method for redist
>     Nick> _transaction4/0.1/commit_transaction failed: XrlCmdError 102
>     Nick> Command failed Dele teEntry4: net = 10.0.1.0/24 nexthop =
>     Nick> 0.0.0.0 ifname = vifname = metric = 0 ad min_distance = 0
>     Nick> xorp_route = false is_deleted = false is_unresolved = false
>     Nick> is_ connected_route = false
>     >>
>     Nick> On Fri, Oct 21, 2005 at 02:53:59AM -0700, Atanu Ghosh wrote:
>     >> >> >>>>> "Nick" == Nick Feamster <feamster@lcs.mit.edu> writes:
>     >> >> 
>     Nick> On Wed, Oct 19, 2005 at 03:27:03PM -0700, Atanu Ghosh wrote:
>     >> >> >> of the routers neighbours are the designated router or
>     >> backup >> >> designated router. This method should only be called
>     >> if the >> the >> link type is Broadcast or NBMA, as these are the
>     >> only link >> types >> that perform DR election. I assume that the
>     >> link-type is >> set to >> point-to-multipoint (p2m), in when case
>     >> the assert is >> signalling >> a programming error. The OSPF
>     >> process will have >> exited. A stack >> backtrace might yield
>     >> some clues.
>     >> >> 
>     Nick> Yes, the link-type is p2m in our case, so perhaps this method
>     Nick> should not be called?  It appears that the OSPF process dies
>     Nick> completely as a result.  Sure, I will send along a backtrace.
>     >> >> This problem is now fixed in CVS.
>     >> >> 
>     >> >> >> If the problem is reproducible with the latest code from
>     >> CVS >> then >> the configuration files and some information about
>     >> the >> topology >> would be useful.
>     >> >> 
>     Nick> Simple topology:
>     >> >>
>     Nick> A <-> B <-> C, where both links are p2m links.  I've attached
>     Nick> the configuration files.
>     >> >> I'v included a cut down configuration files that worked for >>
>     >> me. I had to modify the prefix length from 32 to 24 on the first
>     >> >> router. Also you shouldn't be setting discard to true on >>
>     >> interfaces that you want to route traffic through.
>     >> >> 
>     >> >> >> If an attempt was made to add a route to the RIB and it
>     >> failed >> >> you should error messages in the log.
>     >> >> 
>     Nick> How do I ensure that routes are in the RIB, then?  Here's what
>     Nick> I see in the log.
>     >> >> Use the show route command:
>     Xorp> show route table ipv4 unicast ospf
>     >> >> Network 128.31.1.15/32 Nexthop := 128.31.1.14 Metric := 10 >>
>     >> Protocol := ospf Interface := eth0 Vif := eth0
>     >> >> 
>     >> >> To see the final table:
>     Xorp> show route table ipv4 unicast final
>     >> >> Network 128.31.1.0/24 Nexthop := 128.31.1.13 Metric := 0
>     >> Protocol >> := connected Interface := eth0 Vif := eth0 Network
>     >> 128.31.1.15/32 >> Nexthop := 128.31.1.14 Metric := 10 Protocol :=
>     >> ospf Interface := >> eth0 Vif := eth0
>     >> >> 
>     >> >> Atanu.
>     >> >> 
>     >> 
>     Nick> Content-Description: p3
>     >> >> interfaces { interface eth0 { vif eth0 { address 128.31.1.13 {
>     >> >> prefix-length: 24 } } } } protocols { ospf4 { router-id: >>
>     >> 128.31.1.13
>     >> >> 
>     >> >> area 0.0.0.0 { interface eth0 { link-type: "p2m" vif eth0 { >>
>     >> address 128.31.1.13 { interface-cost: 5 neighbour 128.31.1.14 {
>     >> >> router-id: 128.31.1.14 } } } } } } } }
>     >> 
>     Nick> Content-Description: p4
>     >> >> interfaces { interface eth0 { vif eth0 { address 128.31.1.14 {
>     >> >> prefix-length: 24 } } } } protocols { ospf4 { router-id: >>
>     >> 128.31.1.14
>     >> >> 
>     >> >> area 0.0.0.0 { interface eth0 { link-type: "p2m" vif eth0 { >>
>     >> address 128.31.1.14 { interface-cost: 5 neighbour 128.31.1.13 {
>     >> >> router-id: 128.31.1.13 } neighbour 128.31.1.15 { router-id: >>
>     >> 128.31.1.15 } } } } } } } }
>     >> 
>     Nick> Content-Description: p5
>     >> >> interfaces { interface eth0 { vif eth0 { address 128.31.1.15 {
>     >> >> prefix-length: 24 } } } } protocols { ospf4 { router-id: >>
>     >> 128.31.1.15
>     >> >> 
>     >> >> area 0.0.0.0 { interface eth0 { link-type: "p2m" vif eth0 { >>
>     >> address 128.31.1.15 { interface-cost: 5 neighbour 128.31.1.13 {
>     >> >> router-id: 128.31.1.13 } neighbour 128.31.1.14 { router-id: >>
>     >> 128.31.1.14 } } } } } } } }

From atanu@ICSI.Berkeley.EDU  Tue Nov  1 02:50:16 2005
From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Mon, 31 Oct 2005 18:50:16 -0800
Subject: [Xorp-users] Re: help establishing OSPF adjacencies
In-Reply-To: Message from Nick Feamster <feamster@lcs.mit.edu>
 of "Mon, 31 Oct 2005 21:44:03 EST." <20051101024403.GA29541@lcs.mit.edu>
Message-ID: <319.1130813416@tigger.icir.org>

The next thing to check is that protocol_map.{cc,hh} are in the
generated Makefile, if they aren't you need to rerun configure.

      Atanu.

>>>>> "Nick" == Nick Feamster <feamster@lcs.mit.edu> writes:

    Nick> Yes, I do.  Here is the md5 of that file in my current tree:
    Nick> #md5sum protocol_map.hh 4a823174a886b441d8260caab2953d59
    Nick> protocol_map.hh

    Nick> On Mon, Oct 31, 2005 at 04:41:59PM -0800, Atanu Ghosh wrote:
    >> Hi,
    >> 
    >> We run regression tests on a variety of platforms every night and
    >> we haven't seen a compilation or test failure for a while.
    >> 
    >> The data structure that seems to be causing the problem
    >> ProtocolMap was introduced 8 days ago and is in
    >> xorp/policy/protocol_map.hh. Do you have this file in your source
    >> tree?
    >> 
    >> Atanu.
    >> 
    >> >>>>> "Nick" == Nick Feamster <feamster@lcs.mit.edu> writes:
    >> 
    Nick> Atanu, The latest code does not compile (I have been having
    Nick> this error for a few days now, but didn't get around to
    Nick> sending this until now...figured maybe I had a mid-update
    Nick> version, but it appears not).
    >>
    Nick> thanks, -Nick
    >>
    Nick> g++ -g -W -Wall -Wwrite-strings -Wcast-qual -Werror
    Nick> -Wpointer-arith -Wcast-alig\ n -Wstrict-prototypes
    Nick> -Woverloaded-virtual -ftemplate-depth-25 -pipe -o xorp_po\
    Nick> licy xorp_policy.o policy_target.o ./.libs/libpolicy.a
    Nick> ./common/.libs/libpolic\ ycommon.a
    Nick> ../xrl/targets/.libs/libpolicybase.a
    Nick> ../xrl/interfaces/.libs/libpolic\ ybackendxif.a
    Nick> ../xrl/interfaces/.libs/libfindereventnotifierxif.a
    Nick> ../xrl/interf\ aces/.libs/libribxif.a
    Nick> ../libxipc/.libs/libxipc.a ../libcomm/.libs/libcomm.a ..\
    Nick> /libxorp/.libs/libxorp.a -lcrypto policy_target.o(.text+0x22):
    Nick> In function `PolicyTarget::PolicyTarget[not-in-cha\
    Nick> rge](XrlStdRouter&)': /usr/include/c++/3.3.3/bits/list.tcc:76:
    Nick> undefined reference to `ProtocolMap::P\
    Nick> rotocolMap[in-charge]()' policy_target.o(.text+0x1c0): In
    Nick> function `PolicyTarget::PolicyTarget[in-charge\
    Nick> ](XrlStdRouter&)':
    Nick> /home/feamster/xorp/policy/policy_target.cc:42: undefined
    Nick> reference to `Protoco\ lMap::ProtocolMap[in-charge]()'
    Nick> policy_target.o(.text+0x6cf): In function
    Nick> `PolicyTarget::set_proto_target(std::\ basic_string<char,
    Nick> std::char_traits<char>, std::allocator<char> > const&, std::\
    Nick> basic_string<char, std::char_traits<char>,
    Nick> std::allocator<char> > const&)':
    Nick> /home/feamster/xorp/policy/policy_target.cc:178: undefined
    Nick> reference to `Protoc\
    Nick> olMap::set_xrl_target(std::basic_string<char,
    Nick> std::char_traits<char>, std::allo\ cator<char> > const&,
    Nick> std::basic_string<char, std::char_traits<char>, std::allo\
    Nick> cator<char> > const&)'
    Nick> ./.libs/libpolicy.a(filter_manager.o)(.text+0x763): In
    Nick> function `FilterManager:\
    Nick> :update_tagmap(std::basic_string<char, std::char_traits<char>,
    Nick> std::allocator<c\
    har> > const&)':
    Nick> /home/feamster/xorp/policy/filter_manager.cc:109: undefined
    Nick> reference to `Proto\
    Nick> colMap::xrl_target(std::basic_string<char,
    Nick> std::char_traits<char>, std::allocat\ or<char> > const&)'
    Nick> ./.libs/libpolicy.a(filter_manager.o)(.text+0x975): In
    Nick> function `FilterManager:\ :flush_export_queue()':
    Nick> /home/feamster/xorp/policy/filter_manager.cc:140: undefined
    Nick> reference to `Proto\
    Nick> colMap::xrl_target(std::basic_string<char,
    Nick> std::char_traits<char>, std::allocat\ or<char> > const&)'
    Nick> ./.libs/libpolicy.a(filter_manager.o)(.text+0xa0e):/home/feamster/xorp/policy/f\
    Nick> ilter_manager.cc:145: undefined reference to
    Nick> `ProtocolMap::xrl_target(std::basi\ c_string<char,
    Nick> std::char_traits<char>, std::allocator<char> > const&)'
    Nick> ./.libs/libpolicy.a(filter_manager.o)(.text+0xb72): In
    Nick> function `FilterManager:\
    Nick> :flush_queue(std::map<std::basic_string<char,
    Nick> std::char_traits<char>, std::allo\ cator<char> >,
    Nick> std::basic_string<char, std::char_traits<char>,
    Nick> std::allocator<c\
    har> >, std::less<std::basic_string<char, std::char_traits<char>,
    Nick> std::allocato\ r<char> > >,
    Nick> std::allocator<std::pair<std::basic_string<char,
    Nick> std::char_traits<\
    char> , std::allocator<char> > const, std::basic_string<char,
    Nick> std::char_traits<c\
    har> , std::allocator<char> > > > >&, filter::Filter)':
    Nick> /home/feamster/xorp/policy/filter_manager.cc:176: undefined
    Nick> reference to `Proto\
    Nick> colMap::xrl_target(std::basic_string<char,
    Nick> std::char_traits<char>, std::allocat\ or<char> > const&)'
    Nick> ./.libs/libpolicy.a(filter_manager.o)(.text+0xc0a):/home/feamster/xorp/policy/f\
    Nick> ilter_manager.cc:181: undefined reference to
    Nick> `ProtocolMap::xrl_target(std::basi\ c_string<char,
    Nick> std::char_traits<char>, std::allocator<char> > const&)'
    Nick> ./.libs/libpolicy.a(filter_manager.o)(.text+0xd2e):/home/feamster/xorp/policy/f\
    Nick> ilter_manager.cc:205: more undefined references to
    Nick> `ProtocolMap::xrl_target(std\ ::basic_string<char,
    Nick> std::char_traits<char>, std::allocator<char> > const&)' fo\
    Nick> llow ./.libs/libpolicy.a(process_watch.o)(.text+0x4cd): In
    Nick> function `ProcessWatch::b\ irth(std::basic_string<char,
    Nick> std::char_traits<char>, std::allocator<char> > con\ st&)':
    Nick> /home/feamster/xorp/policy/process_watch.cc:67: undefined
    Nick> reference to `Protoco\ lMap::protocol(std::basic_string<char,
    Nick> std::char_traits<char>, std::allocator<c\
    har> > const&)'
    Nick> ./.libs/libpolicy.a(process_watch.o)(.text+0x52d): In function
    Nick> `ProcessWatch::d\ eath(std::basic_string<char,
    Nick> std::char_traits<char>, std::allocator<char> > con\ st&)':
    Nick> /home/feamster/xorp/policy/process_watch.cc:79: undefined
    Nick> reference to `Protoco\ lMap::protocol(std::basic_string<char,
    Nick> std::char_traits<char>, std::allocator<c\
    har> > const&)'
    Nick> collect2: ld returned 1 exit status
    >>
    Nick> On Sat, Oct 29, 2005 at 01:07:50AM -0700, Atanu Ghosh wrote:
    >> >> Hi,
    >> >> 
    >> >> I don't think that you have the latest code, I still see an >>
    >> Assertion in the trace (Assertion (do_dr_or_bdr()) failed).
    >> >> 
    >> >> Atanu.
    >> >> 
    >> >> >>>>> "Nick" == Nick Feamster <feamster@lcs.mit.edu> writes:
    >> >> 
    Nick> Spoke a bit too soon.  I'm still getting these error logs on
    Nick> p4: [ 2005/10/29 00:10:27 TRACE xorp_ospfv2 OSPF ]
    Nick> Event(DataDescriptionReceived-pse udo-event)
    Nick> Interface(eth0/eth0) Neighbour(128.31.1.15) State(ExStart) [
    Nick> 2005/10/29 00:10:27 TRACE xorp_ospfv2 OSPF ]
    Nick> Event(NegotiationDone) Interface( eth0/eth0)
    Nick> Neighbour(128.31.1.15) State(ExStart) [ 2005/10/29 00:10:27
    Nick> TRACE xorp_ospfv2 OSPF ] Event(DataDescriptionReceived-pse
    Nick> udo-event) Interface(eth0/eth0) Neighbour(128.31.1.15)
    Nick> State(Exchange) [ 2005/10/29 00:10:27 TRACE xorp_ospfv2 OSPF ]
    Nick> Event(ExchangeDone) Interface(eth 0/eth0)
    Nick> Neighbour(128.31.1.15) State(Exchange) [ 2005/10/29 00:10:27
    Nick> TRACE xorp_ospfv2 OSPF ] Event(LinkStateUpdateReceived-pse
    Nick> udo-event) Interface(eth0/eth0) Neighbour(128.31.1.13)
    Nick> State(Loading) [ 2005/10/29 00:10:27 TRACE xorp_ospfv2 OSPF ]
    Nick> Event(LoadingDone) Interface(eth0 /eth0)
    Nick> Neighbour(128.31.1.13) State(Loading) [ 2005/10/29 00:10:27
    Nick> FATAL xorp_ospfv2:2866 OSPF +914 peer.cc is_neighbour_DR_
    Nick> or_BDR ] Assertion (do_dr_or_bdr()) failed [ 2005/10/29
    Nick> 00:10:37 ERROR xorp_fea:2175 FEA +433
    Nick> fticonfig_entry_set_click.cc delete_entry ] User-level Click
    Nick> command error: 520-Write handler '_xorp_rt4.rem ove' error:
    Nick> 520 route '10.0.1.0/24 - -1' not found [ 2005/10/29 00:10:37
    Nick> ERROR xorp_fea:2175 FEA +71 fti_transaction.cc operation_
    Nick> result ] FTI transaction commit failed on DeleteEntry4: net =
    Nick> 10.0.1.0/24 nextho p = 0.0.0.0 ifname = vifname = metric = 0
    Nick> admin_distance = 0 xorp_route = fals e is_deleted = false
    Nick> is_unresolved = false is_connected_route = false [ 2005/10/29
    Nick> 00:10:37 ERROR xorp_fea:2175 FEA +433
    Nick> fticonfig_entry_set_click.cc delete_entry ] User-level Click
    Nick> command error: 520-Write handler '_xorp_rt4.rem ove' error:
    Nick> 520 route '10.0.2.0/24 - -1' not found [ 2005/10/29 00:10:37
    Nick> ERROR xorp_fea:2175 FEA +433 fticonfig_entry_set_click.cc
    Nick> delete_entry ] User-level Click command error: 520-Write
    Nick> handler '_xorp_rt4.rem ove' error: 520 route '10.0.3.0/24 -
    Nick> -1' not found [ 2005/10/29 00:10:37 WARNING xorp_fea
    Nick> XrlFeaTarget ] Handling method for redist
    Nick> _transaction4/0.1/commit_transaction failed: XrlCmdError 102
    Nick> Command failed Dele teEntry4: net = 10.0.1.0/24 nexthop =
    Nick> 0.0.0.0 ifname = vifname = metric = 0 ad min_distance = 0
    Nick> xorp_route = false is_deleted = false is_unresolved = false
    Nick> is_ connected_route = false
    >> >>
    Nick> On Fri, Oct 21, 2005 at 02:53:59AM -0700, Atanu Ghosh wrote:
    >> >> >> >>>>> "Nick" == Nick Feamster <feamster@lcs.mit.edu>
    >> writes:
    >> >> >> 
    Nick> On Wed, Oct 19, 2005 at 03:27:03PM -0700, Atanu Ghosh wrote:
    >> >> >> >> of the routers neighbours are the designated router or
    >> >> backup >> >> designated router. This method should only be
    >> called >> if the >> the >> link type is Broadcast or NBMA, as
    >> these are the >> only link >> types >> that perform DR
    >> election. I assume that the >> link-type is >> set to >>
    >> point-to-multipoint (p2m), in when case >> the assert is >>
    >> signalling >> a programming error. The OSPF >> process will have
    >> >> exited. A stack >> backtrace might yield >> some clues.
    >> >> >> 
    Nick> Yes, the link-type is p2m in our case, so perhaps this method
    Nick> should not be called?  It appears that the OSPF process dies
    Nick> completely as a result.  Sure, I will send along a backtrace.
    >> >> >> This problem is now fixed in CVS.
    >> >> >> 
    >> >> >> >> If the problem is reproducible with the latest code from
    >> >> CVS >> then >> the configuration files and some information
    >> about >> the >> topology >> would be useful.
    >> >> >> 
    Nick> Simple topology:
    >> >> >>
    Nick> A <-> B <-> C, where both links are p2m links.  I've attached
    Nick> the configuration files.
    >> >> >> I'v included a cut down configuration files that worked for
    >> >> >> me. I had to modify the prefix length from 32 to 24 on the
    >> first >> >> router. Also you shouldn't be setting discard to true
    >> on >> >> interfaces that you want to route traffic through.
    >> >> >> 
    >> >> >> >> If an attempt was made to add a route to the RIB and it
    >> >> failed >> >> you should error messages in the log.
    >> >> >> 
    Nick> How do I ensure that routes are in the RIB, then?  Here's what
    Nick> I see in the log.
    >> >> >> Use the show route command:
    Xorp> show route table ipv4 unicast ospf
    >> >> >> Network 128.31.1.15/32 Nexthop := 128.31.1.14 Metric := 10
    >> >> >> Protocol := ospf Interface := eth0 Vif := eth0
    >> >> >> 
    >> >> >> To see the final table:
    Xorp> show route table ipv4 unicast final
    >> >> >> Network 128.31.1.0/24 Nexthop := 128.31.1.13 Metric := 0 >>
    >> Protocol >> := connected Interface := eth0 Vif := eth0 Network >>
    >> 128.31.1.15/32 >> Nexthop := 128.31.1.14 Metric := 10 Protocol :=
    >> >> ospf Interface := >> eth0 Vif := eth0
    >> >> >> 
    >> >> >> Atanu.
    >> >> >> 
    >> >> 
    Nick> Content-Description: p3
    >> >> >> interfaces { interface eth0 { vif eth0 { address
    >> 128.31.1.13 { >> >> prefix-length: 24 } } } } protocols { ospf4 {
    >> router-id: >> >> 128.31.1.13
    >> >> >> 
    >> >> >> area 0.0.0.0 { interface eth0 { link-type: "p2m" vif eth0 {
    >> >> >> address 128.31.1.13 { interface-cost: 5 neighbour
    >> 128.31.1.14 { >> >> router-id: 128.31.1.14 } } } } } } } }
    >> >> 
    Nick> Content-Description: p4
    >> >> >> interfaces { interface eth0 { vif eth0 { address
    >> 128.31.1.14 { >> >> prefix-length: 24 } } } } protocols { ospf4 {
    >> router-id: >> >> 128.31.1.14
    >> >> >> 
    >> >> >> area 0.0.0.0 { interface eth0 { link-type: "p2m" vif eth0 {
    >> >> >> address 128.31.1.14 { interface-cost: 5 neighbour
    >> 128.31.1.13 { >> >> router-id: 128.31.1.13 } neighbour
    >> 128.31.1.15 { router-id: >> >> 128.31.1.15 } } } } } } } }
    >> >> 
    Nick> Content-Description: p5
    >> >> >> interfaces { interface eth0 { vif eth0 { address
    >> 128.31.1.15 { >> >> prefix-length: 24 } } } } protocols { ospf4 {
    >> router-id: >> >> 128.31.1.15
    >> >> >> 
    >> >> >> area 0.0.0.0 { interface eth0 { link-type: "p2m" vif eth0 {
    >> >> >> address 128.31.1.15 { interface-cost: 5 neighbour
    >> 128.31.1.13 { >> >> router-id: 128.31.1.13 } neighbour
    >> 128.31.1.14 { router-id: >> >> 128.31.1.14 } } } } } } } }

From riccardo.sciaccaluga@tin.it" <riccardo.sciaccaluga@tin.it  Wed Nov  2 17:45:11 2005
From: riccardo.sciaccaluga@tin.it" <riccardo.sciaccaluga@tin.it (riccardo.sciaccaluga@tin.it)
Date: Wed, 2 Nov 2005 18:45:11 +0100 (GMT+01:00)
Subject: [Xorp-users] Why don't xorp bash changes take
Message-ID: <6217374.1130953511864.JavaMail.root@pswm14.cp.tin.it>

effect on the kernel routing table?
Mime-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_160959_26023039.1130953511801"
X-Originating-IP: 130.251.17.165

------=_Part_160959_26023039.1130953511801
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

My questions and the draw of my network is inside the attached file
------=_Part_160959_26023039.1130953511801
Content-Type: APPLICATION/MSWORD; name=1.doc
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=1.doc; size=32768

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAOgAAAAAAAAAA
EAAAPAAAAAEAAAD+////AAAAADsAAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////s
pcEAA2AQBAAA8BK/AAAAAAAAEAAAAAAABgAAphEAAA4AYmpiao/qj+oAAAAAAAAAAAAAAAAAAAAA
AAAQBBYANxwAAO2AAADtgAAApgkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA
AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAKQAAAAAAMADAAAAAAAAwAMAAMAD
AAAAAAAAwAMAAAAAAADAAwAAAAAAAMADAAAAAAAAwAMAABQAAAAAAAAAAAAAAPoDAAAkAgAAZgsA
AAAAAABmCwAAAAAAAGYLAAAAAAAAZgsAABQAAAB6CwAAFAAAAB4GAAAAAAAASyYAADIBAACaCwAA
BAAAAJ4LAAAAAAAAngsAAAAAAACeCwAAAAAAADIcAAAAAAAADR0AAAAAAAANHQAAAAAAAA0dAAAA
AAAAyiUAAAIAAADMJQAAAAAAAMwlAAAAAAAAzCUAAAAAAADMJQAAAAAAAMwlAAAAAAAAzCUAACQA
AAB9JwAAaAIAAOUpAAA4AAAA8CUAABUAAAAAAAAAAAAAAAAAAAAAAAAAwAMAAAAAAAANHQAAAAAA
AAAAAAAAAAAAAAAAAAAAAAANHQAAAAAAAA0dAAAAAAAADR0AAAAAAAANHQAAAAAAAPAlAAAAAAAA
AAAAAAAAAADAAwAAAAAAAMADAAAAAAAAngsAAAAAAAAAAAAAAAAAADIcAADbAAAABSYAABYAAAA5
HwAAAAAAADkfAAAAAAAAOR8AAAAAAAANHQAAKgEAAMADAAAAAAAAngsAAAAAAADAAwAAAAAAADIc
AAAAAAAAyiUAAAAAAAAAAAAAAAAAADkfAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAADR0AAAAAAADKJQAAAAAAAAAAAAAAAAAAOR8AAAAAAAA5HwAA
HgAAABYiAAAYAAAAwAMAAAAAAADAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYiIAAAAAAACeCwAAlBAAAI4LAAAMAAAAgLXPl9Tf
xQEAAAAAAAAAAGYLAAAAAAAANx4AANYAAAAuIgAACAAAAAAAAAAAAAAAviUAAAwAAAAbJgAAMAAA
AEsmAAAAAAAANiIAACwAAAAdKgAAAAAAAA0fAAAiAAAAHSoAABAAAABiIgAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAB0qAAAAAAAAAAAAAAAAAADAAwAAAAAAAGIiAABcAwAADR0AAAAAAAANHQAAAAAAADkf
AAAAAAAADR0AAAAAAAANHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADR0A
AAAAAAANHQAAAAAAAA0dAAAAAAAA8CUAAAAAAADwJQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAALx8AAAoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0dAAAA
AAAADR0AAAAAAAANHQAAAAAAAEsmAAAAAAAADR0AAAAAAAANHQAAAAAAAA0dAAAAAAAADR0AAAAA
AAAAAAAAAAAAAB4GAAAAAAAAHgYAAAAAAAAeBgAARAQAAGIKAAAEAQAAHgYAAAAAAAAeBgAAAAAA
AB4GAAAAAAAAYgoAAAAAAADUAwAAFAAAAOgDAAAOAAAA9gMAAAQAAADAAwAAAAAAAMADAAAAAAAA
wAMAAAAAAADAAwAAAAAAAMADAAAAAAAAwAMAAAAAAAD/////AAAAAAIADAEAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEkgdHJp
ZWQgdG8gc2V0IHVwIGEgbmV0d29yayBjb21wb3NlZCBieSBvbmx5IHR3byByb3V0ZXJzIChvLnIu
IEEgYW5kIEIpLCBib3RoIHdvcmtpbmcgd2l0aCBSSVAuIA1Nb3Jlb3ZlciwgSSBoYXZlIHVzZWQg
Ym90aCBhIENsaWNrIHRyYWZmaWMgZ2VuZXJhdG9yIGFuZCBhIG1lYXN1cmVyIHRvIHRlc3QgdGhl
IHJ1bm5pbmcgY29uZmlndXJhdGlvbi4NVGhlIG5ldHdvcmsgY2FuIGJlIHJlcHJlc2VudGVkIGFz
IGluIHRoZSBmb2xsb3dpbmc6IA1JbiB0aGlzIG5ldHdvcmsgdGhlcmUgaXMgOg0Nc291cmNlLS0t
LS0tLS0tLS0+by5yLkEtLS0tLS0tLS0tLS0tLS0+IG8uci5CDSAgICAgICAgICBpbnRlcmZhY2Uy
fCAgICAgICAgICAgICAgICAgICAgIHwgaW50ZXJmYWNlMyANICAgICAgICAgICAgICAgICAgICB8
ICAgICAgICAgICAgICAgICAgICAgfA0gICAgICAgICAgICAgICBwYXRoMXwtLS0tLS0tU1dJVENI
LS0tLS0tLS18IHBhdGgyDSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNICAgICAgICAg
ICAgICAgICAgICAgRGVzdGluYXRpb24gSG9zdA0NSSB3cm90ZSBhIGNvbmZpZy5ib290IGZpbGUg
b24gby5yLkEgd2l0aCB0aGUgZGVjbGFyYXRpb24gb2YgYWxsIHRoZSBpbnRlcmZhY2VzICxhbGwg
DW1hbmFnZWQgYnkgUklQIHByb3RvY29sLg1JIGRpZCAgdGhlIHNhbWUgZm9yIG8uci5CIHRvbyBh
bmQgaSB0cmllZCB0byBnZW5lcmF0ZSBJUCB0cmFmZmljIGZyb20gdGhlIHNvdXJjZSB0b3dhcmQg
dGhlIGRlc3RpbmF0aW9uLg1PYnZpb3VzbHkgcGFja2V0cyBmb2xsb3dlZCB0aGUgc2hvcnRlc3Qg
cGF0aCAocGF0aDEpIGFuZCBsb29raW5nIGF0IG8uci5CIGtlcm5lbCANcm91dGluZyB0YWJsZSBJ
IHNhdyB0aGVyZSB3YXMgYW4gZW50cnkgYWRkZWQgYnkgeG9ycCB0b3dhcmQgdGhlIHNvdXJjZSBu
ZXQgdGhyb3VnaCBvLnIuQS4uLi5zbyB4b3JwIFJJUCB3YXMgd29ya2luZy4NT24gdGhlIG90aGVy
IGVuZCBJIGRpZG4ndCBzZWUgaW4gby5yLkEga2VybmVsIHJvdXRpbmcgdGFibGUgdGhlIHJvdXRl
IHRvd2FyZHMgdGhlIGRlc3RpbmF0aW9uIG5vZGUgbmV0IHRocm91Z2ggby5yLkIgYnV0IEkgdGhp
bmsgdGhpcyBpcyBjb3JyZWN0IGJlY2F1c2UgdGhpcyBsYXN0IA1yb3V0ZSBpcyBub3QgdGhlIHNo
b3J0ZXN0IQ1TbyBJIHRyaWVkIHRvIHB1dCBkb3duIGludGVyZmFjZTIgYnkgdGhlIGtlcm5lbCBi
YXNoIGJ1dCB4b3JwIGRpZG4ndCByZWFsaXplIHRoZSBjaGFuZ2UgKEkgdGhpbmspIGFuZCBkaWRu
J3QgbWFrZSBhbnkgcmVmcmVzaCBvZiBpdHMgcm91dGluZyB0YWJsZSBnb2luZyBvbiB0cnlpbmcg
dG8gZm9yd2FyZCBJUCBwYWNrZXRzIHRocm91Z2ggaW50ZXJmYWNlMiggYW5kIGJlY2F1c2UgaW50
ZXJmYWNlMiB3YXMgZG93biBwYWNrZXRzIA13ZXJlIGZvcndhcmRlZCB0byB0aGUgbG9vcGJhY2sp
Lg1JIHRyaWVkIGEgc2Vjb25kIHdheSB0byB0ZXN0IGlmIHhvcnAgaXMgYWJsZSB0byByZWZyZXNo
IGl0cyByb3V0aW5nIHRhYmxlIHdoZW4gYSBsaW5rIHN0YXR1cyBjaGFuZ2VzLi4uLi5JIHRyaWVk
IHRvIGRlbGV0ZSB0aGUgcmlwIGludGVyZmFjZSBieSB0aGUgY29uZmlndXJhdGlvbiBtb2RlIG9m
IHRoZSB4b3JwIHNoZWxsIHVzaW5nIHRoZSBjb21tYW5kIGxpbmU6IA0iZGVsZXRlIHByb3RvY29s
cyByaXAgaW50ZXJmYWNlIGV0aFgiIA1hbmQgaXQgbG9va2VkIGxpa2UgdGhpcyByb3V0ZSB3YXMg
ZGVsZXRlZCBiZWNhdXNlIEkgY291bGRuJ3Qgc2VlIGFueW1vcmUgdGhlIA1pbnRlZmFjZTIgd2l0
aCB0aGUgY29tbWFuZCBsaW5lIG9uIHRoZSBjb25maWd1cmF0aW9uIG1vZGU6ICJzaG93IHByb3Rv
Y29scyByaXAgaW50ZXJmYWNlICIuDVRodXMsIEkgY2hlY2tlZCBvdXQgaWYgdGhpcyByb3V0ZSB3
YXMgZWZmZWN0aXZlbHkgZGVsZXRlZCBzd2l0Y2hpbmcgdG8gdGhlIG9wZXJhdGlvbmFsIG1vZGUg
b2YgeG9ycCBhbmQgdXNpbmcgOiANInNob3cgcm91dGUgdGFibGUgaXB2NCB1bmljYXN0IHJpcCIg
DWJ1dCB0aGUgaW50ZXJmYWNlIHN1cHBvc2VkIHRvIGJlIGRlbGV0ZWQgaXMgc2hvd24gc3RpbGwg
YXMgYSByaXAgcHJvdG9jb2wgbWFuYWdlZCBpbnRlcmZhY2UhIE1vcmVvdmVyLCBjaGVja2luZyBp
biB0aGUga2VybmVsIHJvdXRpbmcgdGFibGUgSSBoYXZlIG9idGFpbmVkIHRoZSBzYW1lIHJlc3Vs
dC4uLi50aGUgcm91dGUgY29udGludWVzIHRvIGFwcGVhci4NU28gSSBjYW4gc3VwcG9zZSB0aGF0
OiANeG9ycCBkb2Vzbid0IHJlYWxpemUgd2hlbiBhbiBpbnRlcmZhY2Ugc3RhdHVzIGNoYW5nZXM7
IA10aGUgY29uZmlndXJhdGlvbiBtb2RlIG9mIHhvcnAgZG9lc24ndCBlZmZlY3RpdmVseSB0YWtl
IGVmZmVjdCBvbiB0aGUgeG9ycCANcm91dGluZyBtYW5hZ2VtZW50Lg1JcyB0aGVyZSBhIG1vcmUg
YXBwcm9wcmlhdGVkIHdheSB0byBjaGFuZ2UgZWZmZWN0aXZlbHkgdGhlIGludGVyZmFjZSBzdGF0
dXMgaW4geG9ycD8gDQ0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAAwgAAF4I
AABfCAAA/QgAABkJAAAwCQAARwkAAFEJAABXCQAAcQkAAH4JAACTCQAAqwkAALoJAADUCQAA1QkA
AN0JAADxCQAAJAoAADEKAAAyCgAAMwoAADkKAAA6CgAAyAoAAMoKAABbCwAAXAsAAHQLAACUCwAA
wgsAANQLAAAgDAAAPAwAAIEMAACFDAAAqQwAAKoMAAC7DAAA2wwAABENAAAxDQAAtQ0AALgNAAC9
DQAAAg4AABUOAAA5DgAAaQ4AAGoOAACQDgAAkQ4AAJ4OAACfDgAApA4AAMQOAAAKDwAAEw8AADsP
AABBDwAAqw8AAKwPAADQDwAA0Q8AAN0PAAACEAAACRAAAAwQAAAOEAAALRAAAOvZ69nr2evZ69nr
2evZ69nr2evZ69nr2evH68frx+vH68frx+vH68frx+vH68frx+vH68frx+vH68frx+vH68frx+vH
67IAACgVaA4y/wAWaOxfRwBDShQAT0oDAFFKAwBeSgMAYUoUAG1ICQhzSAkIACIWaA4y/wBDShQA
T0oDAFFKAwBeSgMAYUoUAG1ICQhzSAkIACIWaOxfRwBDShQAT0oDAFFKAwBeSgMAYUoUAG1ICQhz
SAkIACgVaOxfRwAWaOxfRwBDShQAT0oDAFFKAwBeSgMAYUoUAG1ICQhzSAkIRgAGAABhCAAAyAgA
AP0IAAAYCQAAGQkAAEcJAAB/CQAAqwkAAN0JAAD9CQAAIwoAACQKAAB5CgAAkgoAAPsKAABNCwAA
wgsAAGYMAACBDAAAdw0AAJgNAABqDgAAkQ4AAN8OAAA7DwAArA8AANEPAACfEAAA9gAAAAAAAAAA
AAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2
AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAA
AAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAA
AAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAA
AAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAA
AAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA
9gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkAADckADgkAEgkAGdk7F9HAAAcAAYAAKYRAAD9AAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEBAABAQEtEAAAQBAAAF0QAABs
EAAAihAAAJ4QAACfEAAArxAAALQQAAC1EAAAthAAALcQAADDEAAAxBAAANIQAADTEAAA6xAAAOwQ
AADtEAAA7hAAAO8QAADyEAAA8xAAAPQQAAAAEQAAEREAABIRAAAUEQAANBEAAE0RAABOEQAATxEA
AKQRAAClEQAAphEAAO7Z7tnu2e7Z7tnu2e7Z7tnux9nu2e7Z7tnu2e7Zx7XHoJUAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
FBVoDjL/ABZoG1MTAG1ICQhzSAkIACgVaOxfRwAWaHYgcwBDShQAT0oDAFFKAwBeSgMAYUoUAG1I
CQhzSAkIACIWaOxfRwBDShQAT0oDAFFKAwBeSgMAYUoUAG1ICQhzSAkIACIWaHYgcwBDShQAT0oD
AFFKAwBeSgMAYUoUAG1ICQhzSAkIACgVaOxfRwAWaOxfRwBDShQAT0oDAFFKAwBeSgMAYUoUAG1I
CQhzSAkIACIWaA4y/wBDShQAT0oDAFFKAwBeSgMAYUoUAG1ICQhzSAkIIp8QAAC3EAAA7xAAADsR
AABPEQAApREAAKYRAAD2AAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAANwAAAAAAAAAAAAAAAD2AAAA
AAAAAAAAAAAA9gAAAAAAAAAAAAAAANoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAwAAAomAAtGAQA3JAA4JABIJABnZOxfRwAADAAA
CiYAC0YBADckADgkAEgkAGdkDjL/AAkAADckADgkAEgkAGdk7F9HAAAGNQASMAAcUAEAOnDsX0cA
H7DQLyCw4D0hsG4EIrBuBCOQiQUkkG4EJbAAABew0AIYsNACDJDQAgAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACGAg8AEgABAJwADwAEAAAA
AAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAABCAABA8f8CAEIADAQAAFw+WQAAAAcATgBvAHIAbQBhAGwAZQAAAAIAAAAYAENKGABfSAEE
YUoYAG1IEARzSBAEdEgQBAAAAAAAAAAAAAAAAAAAAAAAAEwAQUDy/6EATAAMBQAAAAAAAAAAGgBD
AGEAcgAuACAAcAByAGUAZABlAGYAaQBuAGkAdABvACAAcABhAHIAYQBnAHIAYQBmAG8AAAAAAFgA
aUDz/7MAWAAMBQAAAAAAAAAADwBUAGEAYgBlAGwAbABhACAAbgBvAHIAbQBhAGwAZQAAABwAF/YD
AAA01gYAAQoDbAA01gYAAQUDAABh9gMAAAIACwAAADQAa0D0/8EANAAABQAAAAAAAAAADQBOAGUA
cwBzAHUAbgAgAGUAbABlAG4AYwBvAAAAAgAAAAAAAAAAAAAApgkAABAAABwAAAwA/////wEAAAAE
IAAA//8BAKB6mQAAAAAAAAAAAKYJAAAAAAAAAAAAAAAAAAAAAGEAAADIAAAA/QAAABgBAAAZAQAA
RwEAAH8BAACrAQAA3QEAAP0BAAAjAgAAJAIAAHkCAACSAgAA+wIAAE0DAADCAwAAZgQAAIEEAAB3
BQAAmAUAAGoGAACRBgAA3wYAADsHAACsBwAA0QcAAJ8IAAC3CAAA7wgAADsJAABPCQAApQkAAKgJ
AAAAAgAA9CYAAPsxAgAAAgAA9CYAAPsxAgAAAQAA9CYAAPsxAgAAAQAA9CYAAPsxAgAAAQAA9CYA
APsxAgAAAQAA9CYAAPsxAgAAAQAA9CYAAPsxAgAAAQAA9CYAAPsxAgAAAQAA9CYAAPsxAgAAAQAA
9CYAAPsxAgAAAQAA9CYAAPsxAgAAAQAA9CYAAPsxAgAAAQAA9CYAAPsxAgAAAQAA9CYAAPsxAgAA
AgAA9CYAAPsxAgAAAQAA9CYAAPsxAgAAAgAA9CYAAPsxAgAAAgAA9CYAAPsxAgAAAQAA9CYAAPsx
AgAAAwAA9CYAAPsxAgAAAQAA9CYAAPsxAgAAAwAA9CYAAPsxAgAAAQAA9CYAAPsxAgAAAQAA9CYA
APsxAgAAAgAA9CYAAPsxAgAAAgAA9CYAAPsxAgAAAQAA9CYAAPsxAgAAAwAA9CYAAPsxAgAAAQAA
9CYAAPsxAgAAAQAA9CYAAPsxAgAAAQAA9CYAAPsxAgAAAQAA9CYAAPsxAgAAAgAA9CYAAPsxAgAA
AQAA9CYAAI2sAgAAAAAAYQAAAMgAAAD9AAAAGAEAABkBAABHAQAAfwEAAKsBAADdAQAA/QEAACMC
AAAkAgAAeQIAAJICAAD7AgAATQMAAMIDAABmBAAAgQQAAHcFAACYBQAAagYAAJEGAADfBgAAOwcA
AKwHAADRBwAAnwgAALcIAADvCAAAOwkAAE8JAAClCQAAqAkAAJgAAAAAMAAAAAAAAACAAAAAgAAA
AAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAA
AAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAA
AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAA
AAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA
AAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA
AAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA
AACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA
AJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA
mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY
AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA
AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA
AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA
ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAA
MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAABIAAw
AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAASAAMAEAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAA
AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAA
AAAAAACAAAAAgAAAAAAAAAAAAAAAAAAAGQEAAEcBAAB/AQAAqwEAAN0BAAA7CQAApQkAAKgJAADb
igAwABAAAAAAAAABAAAACQAAAAEAAACsB9IH24oAMAAAAAAAAAAAAQAAAAgAAAAAAAAAAACAB9uK
ADAAAAAAAAAAAAIAAAAGAAAAAAAAAAAAgAfbigAwADAAAAAAAAABAAAABAAAAAAAAAAAAIAH24oA
MAAwAAAAAAAAAQAAAAUAAAAAAAAAAACAB9uKADAAMAAAAAAAAAEAAAAFAAAAAQAAAKwH0gfbigAw
ADAAAAAAAAABAAAABAAAAAAAAAAAAIAHCgAAAAAwAAAAAAAAAAAAAAAABjAnrgEAAAAABwAGAAAt
EAAAphEAAAkAAAAMAAAAAAYAAJ8QAACmEQAACgAAAA0AAAAABgAAphEAAAsAAACmCQAA1AAAAP//
////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAA
AP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAA
AQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAA
AAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAA
AAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD/////////
/wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD/////
/////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD/
/////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEA
AAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAA
AAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAA
AAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8A
AAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA////////
//8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA////
//////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA
//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAAB
AAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAA
AAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAA
AAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////
AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////
////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//
////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAA
AP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAA
AQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAA
AAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAA
AAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD/////////
/wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD/////
/////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD/
/////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEA
AAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAA
AAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAA
AAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8A
AAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA////////
//8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA////
//////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA
//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAAB
AAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAA
AAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAA
AAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////
AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////
////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//
////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAA
AP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAA
AQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAA
AAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAA
AAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD/////////
/wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD/////
/////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD/
/////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEA
AAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAA
AAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAA
AAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8A
AAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA////////
//8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA////
//////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA
//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAAB
AAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAA
AAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAA
AAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////
AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////
////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//
////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAA
AP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAA
AQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAAAAAA
AAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD//////////wAA
AAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD/////////
/wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD/////
/////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEAAAD/
/////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAAAAEA
AAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAAAAAA
AAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8AAAAA
AAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA//////////8A
AAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA////////
//8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA////
//////8AAAAAAAAAAAEAAAD//////////wAAAAAAAAAAAQAAAP//////////AAAAAAAAAAABAAAA
//////////8AAAAAAAAAAAEAAAAPAADwOAAAAAAABvAYAAAAAgQAAAIAAAABAAAAAQAAAAEAAAAC
AAAAQAAe8RAAAAD//wAAAAD/AICAgAD3AAAQAA8AAvCSAAAAEAAI8AgAAAABAAAAAQQAAA8AA/Aw
AAAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAEAAAFAAAADwAE8EIA
AAASAArwCAAAAAEEAAAADgAAUwAL8B4AAAC/AQAAEADLAQAAAAD/AQAACAAEAwkAAAA/AwEAAQAA
ABHwBAAAAAEAAAAAAAAAOgAAAD0AAAArAQAAMAEAAEEBAABGAQAALgIAADkCAABCAgAARwIAAKYC
AACrAgAAtAIAALUCAAA/AwAARAMAAH0DAACBAwAAoAMAAKUDAACsAwAAsAMAAOMDAADoAwAAMQQA
ADYEAAC6BAAAvgQAAI0FAACVBQAAuAUAALwFAABGBgAASgYAAIoGAACOBgAAmgcAAJ4HAADDBwAA
ygcAALcIAAC7CAAACQkAAA0JAAA1CQAAOQkAAJ4JAACiCQAAqAkAAAcAHAAHABwABwAcAAcAHAAH
ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA
HAAHABwABwAcAAcAHAAHABwABwAcAAcAAAAAADoAAAA9AAAAPwAAAF8AAAATAQAAFwEAABkBAAAf
AQAAaAIAAHcCAAB5AgAAgAIAAJQCAACcAgAATQMAAFQDAABmBAAAawQAAHcFAAB7BQAAawYAAHEG
AACRBgAAlAYAAN8GAADoBgAAowcAAKoHAACtBwAAsQcAANEHAADUBwAAOwkAAEIJAACoCQAABwA6
AAcAOgAHADoABwA6AAcAOgAHADoABwA6AAcAOgAHADoABwA6AAcAOgAHADoABwA6AAcAOgAHADoA
BwA6AAcAOgAHAAAAAABqBgAAkAYAADsJAABOCQAAqAkAAAcABQAHAAUABwAAAAAAqAkAAAcAAQDm
BZ4yFBDEvv8P/w//D/8P/w//D/8P/w//DxAAAgAAABcAAAAAAAAAAAAAAAAAAAAAAAAAExgAAA+E
0AIRhJj+FcYFAAHQAgZehNACYISY/k9KAwBQSgAAUUoDAF5KAwBvKAABAC0AAQAAABeAAAAAAAAA
AAAAAAAAAAAAAAAAGRgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/k9KAwBRSgMAXkoDAG8oAIdo
AAAAAIhIAAABAG8AAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAAFRgAAA+EcAgRhJj+FcYFAAFwCAZe
hHAIYISY/k9KBABRSgQAbygAh2gAAAAAiEgAAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAV
GAAAD4RACxGEmP4VxgUAAUALBl6EQAtghJj+T0oBAFFKAQBvKACHaAAAAACISAAAAQC38AEAAAAX
gAAAAAAAAAAAAAAAAAAAAAAAABkYAAAPhBAOEYSY/hXGBQABEA4GXoQQDmCEmP5PSgMAUUoDAF5K
AwBvKACHaAAAAACISAAAAQBvAAEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAABUYAAAPhOAQEYSY/hXG
BQAB4BAGXoTgEGCEmP5PSgQAUUoEAG8oAIdoAAAAAIhIAAABAKfwAQAAABeAAAAAAAAAAAAAAAAA
AAAAAAAAFRgAAA+EsBMRhJj+FcYFAAGwEwZehLATYISY/k9KAQBRSgEAbygAh2gAAAAAiEgAAAEA
t/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAZGAAAD4SAFhGEmP4VxgUAAYAWBl6EgBZghJj+T0oD
AFFKAwBeSgMAbygAh2gAAAAAiEgAAAEAbwABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAVGAAAD4RQ
GRGEmP4VxgUAAVAZBl6EUBlghJj+T0oEAFFKBABvKACHaAAAAACISAAAAQCn8AEAAADmBZ4yAAAA
AAAAAAAAAAAA////////AQAAAAAA//8BAAAAEgDcgqTSAwAQBAUAEAQBABAEAwAQBAUAEAQBABAE
AwAQBAUAEATRAAAABAAAAAgAAADlAAAAAAAAANAAAAD/EwAASzsAABlaAADPCAIAJmgDAHIVBQCn
UgUAlXIFADwUBgBLGQgARysJAKVzCQDVJgoA6mcLAOpuCwCWJgwAJU4MAEQrDgCrZhIA0xATABtT
EwDzXhUAe3wVADo1FgAuLBcAn2wXAAMaGwCtBBwAuB0eAFhKHgC/PB8AB0QgAD5KIACEdyAAZSQh
AMAlIgCDOiMAbU8jAF8PJQDeGCcA9x0nACRnJwCIIygAmEIoAOBrKQC1ZSoAgBcsAIATLQAcCy4A
WVowACd/MgCKLjUAxE81ALVvNQBgDzcAzhM7AMcsPQCXLj8A3iRAAGREQABQbkEAbHZBAEN4QQA/
N0YA7F9HAIIeSABpTEgATmdKAJBkSwDyZ0wA52VNADEOUQDqA1MA8EBTAExJUwBZAFQAqUxUAFRx
VwD1bVgAXD5ZAP9hWwAJXlwAUC1dAGUoXgC2ZF8A31xgACpcYwCSA2YA4F9mACh4ZwD7eGcA/Hdr
AHYgcwBnd3MA2nl2AIJddwAjD3gAZz55AIVGeQCUcnkADXB6ADNCewCJE3wAPXp8AKctfQBSOH0A
z3N9ALUNfwDwOIAAAEiAAEoAgQDKMoEAU0eBADMwhABCdoQAaGuHAL5ZiwCcaYsAfQKPAPd3kACt
QJMAel2UAKUBlQDhdZYAyCWXALxAlwB6VZgA5UObAFMMoQDLDKEAPQaiAMI+ogAVHKMAf2ikAAJT
pQDiHKgAOCqpADI0rQBjFq8A8R2vAApisABvZbAApxKxAHA+sQBVa7YA1kW3AFl2twD/EbwA3Ry8
AI1zvwBLecEARwPFAKUaxgBSLscAu0jJACkUywBKOcsAFE7LADBQywCdZcsAMmLOADp+0ABWHdEA
YEfRAEBu1QCPAdYAFTLWAHYn1wBgR9cA0nvXAL8F2QArONoAewjbANED3QDyL90AAyLfAKoB4QDN
VOEAAyHiAK1+6AASYOoADVfsAO0R7gATNO8AIF3vAMt77wANfe8ATSrxAG8R8wBfN/MA7yv1AOog
9gAyK/YA+DP2AKB89gA3d/cAGDr4AAJn+AAOVPsABCL8ACAq/AAqXP0A1WD9AOAP/gA0FP4AoVv+
AHly/gDtc/4ADjL/AAAAAACoCQAAAAAAAP9AAwABAAAAAACmCQAAmJ2OEwEAAQAAAAAAAAAAAAAA
AAAAAAAAAhAAAAAAAAAApgkAAAABABAAQAAA//8BAAAABwBVAG4AawBuAG8AdwBuAP//AQAIAAAA
AAAAAAAAAAD//wEAAAAAAP//AAACAP//AAAAAP//AAACAP//AAAAAAUAAABHFpABAAACAgYDBQQF
AgMEhzoAIAAAAAAAAAAAAAAAAP8BAAAAAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4A
AAA1FpABAgAFBQECAQcGAgUHAAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAUwB5AG0AYgBvAGwAAAAz
JpABAAACCwYEAgICAgIEhzoAIAAAAAAAAAAAAAAAAP8BAAAAAAAAQQByAGkAYQBsAAAAPzWQAQAA
AgcDCQICBQIEBId6ACAAAACACAAAAAAAAAD/AQAAAAAAAEMAbwB1AHIAaQBlAHIAIABOAGUAdwAA
ADsGkAECAAUAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABXAGkAbgBnAGQAaQBuAGcA
cwAAACIABABxCIgYAPDEAgAAGwEAAAAAchSbZqkUm2YAAAAAAgAYAAAAcAEAADYIAAABAAQAAAAE
AAMQEQAAAHABAAA2CAAAAQAEAAAAEQAAAAAAAACxBADwEAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAABuBIkFtAC0AIGBMjQAAAAAAAAAAAAAAAAAAKIJAACiCQAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAEzg1EA
8BAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASFgAAAAAKfD/DwEAAT8AAOQEAAD///9/
////f////3////9/////f////3////9/XD5ZAAAAAAAyAAAAAAAAAAAAAAAAAAAAAAD//xIAAAAA
AAAAAQAxAAAAAAAAAAMAQwBPAE0AAwBDAE8ATQAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAGAAAA
AQAAAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAQIAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuR
CAArJ7PZMAAAAGQBAAARAAAAAQAAAJAAAAACAAAAmAAAAAMAAACkAAAABAAAALAAAAAFAAAAvAAA
AAYAAADIAAAABwAAANQAAAAIAAAA6AAAAAkAAAD0AAAAEgAAAAABAAAKAAAAIAEAAAwAAAAsAQAA
DQAAADgBAAAOAAAARAEAAA8AAABMAQAAEAAAAFQBAAATAAAAXAEAAAIAAADkBAAAHgAAAAQAAAAx
AAAAHgAAAAQAAAAAAAAAHgAAAAQAAABDT00AHgAAAAQAAAAAAAAAHgAAAAQAAAAAAAAAHgAAAAwA
AABOb3JtYWwuZG90AAAeAAAABAAAAENPTQAeAAAABAAAADIAAAAeAAAAGAAAAE1pY3Jvc29mdCBP
ZmZpY2UgV29yZAAAAEAAAAAAkE5aAwAAAEAAAAAAbIp2zd/FAUAAAAAAXnGW1N/FAQMAAAABAAAA
AwAAAHABAAADAAAANggAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAD+/wAABQECAAAAAAAAAAAAAAAAAAAAAAABAAAAAtXN1ZwuGxCTlwgAKyz5rjAA
AADwAAAADAAAAAEAAABoAAAADwAAAHAAAAAFAAAAgAAAAAYAAACIAAAAEQAAAJAAAAAXAAAAmAAA
AAsAAACgAAAAEAAAAKgAAAATAAAAsAAAABYAAAC4AAAADQAAAMAAAAAMAAAAzgAAAAIAAADkBAAA
HgAAAAgAAABESVNUAAAAAAMAAAARAAAAAwAAAAQAAAADAAAAogkAAAMAAAAIGQsACwAAAAAAAAAL
AAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAAAAIAAAAxAAwQAAACAAAAHgAAAAcAAABUaXRv
bG8AAwAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4A
AAD+////EAAAABEAAAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAA
AB0AAAAeAAAAHwAAACAAAAAhAAAAIgAAACMAAAAkAAAA/v///yYAAAAnAAAAKAAAACkAAAAqAAAA
KwAAACwAAAD+////LgAAAC8AAAAwAAAAMQAAADIAAAAzAAAANAAAAP7////9////NwAAAP7////+
/////v//////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//9SAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAFgAFAf//////////AwAAAAYJAgAAAAAAwAAAAAAAAEYAAAAAAAAAAAAAAAAQ6QGY
1N/FATkAAACAAAAAAAAAADEAVABhAGIAbABlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAIB/////wUAAAD/////AAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAADwAAAC0qAAAAAAAAVwBvAHIAZABEAG8AYwB1AG0AZQBuAHQAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgEBAAAA//////////8AAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANxwAAAAAAAAFAFMAdQBtAG0AYQBy
AHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQIA
AAAEAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACUAAAAAEAAAAAAA
AAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAA
AAAAAAAAAAA4AAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAALQAAAAAQAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAdQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////
////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AQAAAP7/////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////////////8B
AP7/AwoAAP////8GCQIAAAAAAMAAAAAAAABGIwAAAERvY3VtZW50byBkaSBNaWNyb3NvZnQgT2Zm
aWNlIFdvcmQACgAAAE1TV29yZERvYwAQAAAAV29yZC5Eb2N1bWVudC44APQ5snEAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFIA
bwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAWAAUB//////////8DAAAABgkCAAAAAADAAAAAAAAARgAAAAAAAAAAAAAAAACYuqTU38UB
PgAAAAACAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAA4AAgH/////BQAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAPAAAALSoAAAAAAABXAG8AcgBkAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAQEAAAD//////////wAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA3HAAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJ
AG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIBAgAAAAQA
AAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJQAAAAAQAAAAAAAAAQAA
AAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAD+////
EAAAABEAAAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAe
AAAAHwAAACAAAAAhAAAAIgAAACMAAAAkAAAA/v///yYAAAAnAAAAKAAAACkAAAAqAAAAKwAAACwA
AAD+////////////////////////////////////////////////////////////////////////
/z0AAAD9/////v////7////+////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////////8BAAAA
/v///wMAAAAEAAAABQAAAAYAAAAHAAAA/v//////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////////////wUARABv
AGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAA
AAA4AAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAA
AGgBAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAABIAAgD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAdQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////
////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQD+/wMK
AAD/////BgkCAAAAAADAAAAAAAAARiMAAABEb2N1bWVudG8gZGkgTWljcm9zb2Z0IE9mZmljZSBX
b3JkAAoAAABNU1dvcmREb2MAEAAAAFdvcmQuRG9jdW1lbnQuOAD0ObJxAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAD+/wAABQECAAAAAAAAAAAAAAAAAAAAAAACAAAAAtXN1ZwuGxCTlwgAKyz5rkQAAAAF
1c3VnC4bEJOXCAArLPmuNAEAAPAAAAAMAAAAAQAAAGgAAAAPAAAAcAAAAAUAAACAAAAABgAAAIgA
AAARAAAAkAAAABcAAACYAAAACwAAAKAAAAAQAAAAqAAAABMAAACwAAAAFgAAALgAAAANAAAAwAAA
AAwAAADOAAAAAgAAAOQEAAAeAAAACAAAAERJU1QAAAAAAwAAABEAAAADAAAABAAAAAMAAACiCQAA
AwAAAAgZCwALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAABAAAAAgAAADEADBAA
AAIAAAAeAAAABwAAAFRpdG9sbwADAAAAAQAAAAAAADQAAAADAAAAAAAAACAAAAABAAAAJAAAAAAA
AIAsAAAAAAAAAAIAAACwBAAAEwAAABAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
------=_Part_160959_26023039.1130953511801--


From pavlin@icir.org  Thu Nov  3 02:10:16 2005
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Wed, 02 Nov 2005 18:10:16 -0800
Subject: [Xorp-users] Why don't xorp bash changes take
In-Reply-To: Message from "riccardo.sciaccaluga@tin.it" <riccardo.sciaccaluga@tin.it>
 of "Wed, 02 Nov 2005 18:45:11 +0100." <6217374.1130953511864.JavaMail.root@pswm14.cp.tin.it>
Message-ID: <200511030210.jA32AGh0077535@possum.icir.org>

> effect on the kernel routing table?

Several comments:
 * Yesterday we committed the final changes for tracking the link
   state by the protocols and by RIB, so you should get the
   lastest code from CVS. Though, we haven't tested yet RIP and
   OSPF with that feature, so no guarantee it is really working for
   RIP.

 * If you want to take interfaces down while XORP is running you
   should use xorpsh ("set interfaces interface foo disable true").
   After the yesterday's changes, the interface status tracking
   _may_ work, but in general it was never the intention that XORP
   should track all changes you can do to your router by using external
   mechanisms. E.g., if you manually add or delete routes to your
   kernel by he UNIX "route add/delete" command, even though we can
   track those changes it is not clear what we should do with them
   inside XORP.
   Furthermore, by taking the interface down by using an UNIX
   command, then the XORP configuration and the kernel state are
   out-of-sync and you may see various side effects later.

 * Deleting the RIP interface should have removed the RIP routes.
   Please double-check it with running the lastest CVS code.
   If it still doesn't work then please submit a bugzilla entry.

Pavlin

P.S. Please send plain ASCII instead of DOC attachments, especially
if all the text inside the DOC file appears to be just ASCII :)


From riccardo.sciaccaluga@tin.it" <riccardo.sciaccaluga@tin.it  Thu Nov  3 16:09:35 2005
From: riccardo.sciaccaluga@tin.it" <riccardo.sciaccaluga@tin.it (riccardo.sciaccaluga@tin.it)
Date: Thu, 3 Nov 2005 17:09:35 +0100 (GMT+01:00)
Subject: [Xorp-users] Does xorp latest CVS have some problem with the export command?
Message-ID: <26039397.1131034175456.JavaMail.root@pswm9.cp.tin.it>

I upgraded my current xorp version at the latest CVS file and i tried 
to configure xorp with the same config.boot file i used with xorp.1-1.
It was a file configuring a totally rip working network but the lateste 
CVS look like if it didn't accept the export command giving to me the 
following error message and killing the booting of xorp:

[ 2005/11/04 
00:46:13  INFO xorp_rtrmgr:1195 RTRMGR +240 master_conf_tree.cc execute 
] Changed modules: interfaces, fea, rib, policy, rip
[ 2005/11/04 00:46:
13  INFO xorp_rtrmgr:1195 RTRMGR +484 module_manager.cc run ] Running 
module: interfaces (/root/Andrea/xorp/fea/xorp_fea)
[ 2005/11/04 00:46:
13 INFO xorp_fea MFEA ] MFEA enabled
[ 2005/11/04 00:46:13 INFO 
xorp_fea MFEA ] CLI enabled
[ 2005/11/04 00:46:13 INFO xorp_fea MFEA ] 
CLI started
[ 2005/11/04 00:46:15  INFO xorp_rtrmgr:1195 RTRMGR +484 
module_manager.cc run ] Running module: fea 
(/root/Andrea/xorp/fea/xorp_fea)
[ 2005/11/04 00:46:21  INFO 
xorp_rtrmgr:1195 RTRMGR +484 module_manager.cc run ] Running module: 
rib (/root/Andrea/xorp/rib/xorp_rib)
[ 2005/11/04 00:46:23  INFO 
xorp_rtrmgr:1195 RTRMGR +484 module_manager.cc run ] Running module: 
policy (/root/Andrea/xorp/policy/xorp_policy)
[ 2005/11/04 00:46:25  
INFO xorp_rtrmgr:1195 RTRMGR +484 module_manager.cc run ] Running 
module: rip (/root/Andrea/xorp/rip/xorp_rip)
[ 2005/11/04 00:46:27  
WARNING xorp_policy:1198 XrlPolicyTarget +513 policy_base.cc 
handle_policy_0_1_export ] Handling method for policy/0.1/export 
failed: XrlCmdError 102 Command failed Export of rip failed: exports: 
Protocol rip unknown
[ 2005/11/04 00:46:27  ERROR xorp_rtrmgr:1195 
RTRMGR +671 master_conf_tree.cc commit_pass2_done ] Commit failed: 102 
Command failed Export of rip failed: exports: Protocol rip unknown
[ 
2005/11/04 00:46:27  ERROR xorp_rtrmgr:1195 RTRMGR +252 
master_conf_tree.cc config_done ] Configuration failed: 102 Command 
failed Export of rip failed: exports: Protocol rip unknown
[ 2005/11/04 
00:46:27  INFO xorp_rtrmgr:1195 RTRMGR +2225 task.cc run_task ] No more 
tasks to run
[ 2005/11/04 00:46:27  INFO xorp_rtrmgr:1195 RTRMGR +247 
module_manager.cc terminate ] Terminating module: fea
[ 2005/11/04 00:
46:27  INFO xorp_rtrmgr:1195 RTRMGR +247 module_manager.cc terminate ] 
Terminating module: interfaces
[ 2005/11/04 00:46:27  INFO xorp_rtrmgr:
1195 RTRMGR +300 module_manager.cc terminate ] Killing module: 
interfaces (pid = 0x4ac)
[ 2005/11/04 00:46:27  INFO xorp_rtrmgr:1195 
RTRMGR +247 module_manager.cc terminate ] Terminating module: policy
[ 
2005/11/04 00:46:27  INFO xorp_rtrmgr:1195 RTRMGR +300 module_manager.
cc terminate ] Killing module: policy (pid = 0x4ae)
[ 2005/11/04 00:46:
27  INFO xorp_rtrmgr:1195 RTRMGR +247 module_manager.cc terminate ] 
Terminating module: rib
[ 2005/11/04 00:46:27  INFO xorp_rtrmgr:1195 
RTRMGR +300 module_manager.cc terminate ] Killing module: rib (pid = 
0x4ad)
[ 2005/11/04 00:46:27  INFO xorp_rtrmgr:1195 RTRMGR +247 
module_manager.cc terminate ] Terminating module: rip
[ 2005/11/04 00:
46:27  INFO xorp_rtrmgr:1195 RTRMGR +300 module_manager.cc terminate ] 
Killing module: rip (pid = 0x4af)
[ 2005/11/04 00:46:27  INFO 
xorp_rtrmgr:1195 RTRMGR +664 module_manager.cc killed ] Module killed 
during shutdown: policy
[ 2005/11/04 00:46:27  INFO xorp_rtrmgr:1195 
RTRMGR +664 module_manager.cc killed ] Module killed during shutdown: 
rib
[ 2005/11/04 00:46:27  INFO xorp_rtrmgr:1195 RTRMGR +664 
module_manager.cc killed ] Module killed during shutdown: interfaces
[ 
2005/11/04 00:46:27  INFO xorp_rtrmgr:1195 RTRMGR +664 module_manager.
cc killed ] Module killed during shutdown: rip


Is there a different 
syntax for export rip managed route or could it be a bug?

From atanu@ICSI.Berkeley.EDU  Thu Nov  3 16:21:00 2005
From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Thu, 03 Nov 2005 08:21:00 -0800
Subject: [Xorp-users] Does xorp latest CVS have some problem with the export command?
In-Reply-To: Message from "riccardo.sciaccaluga@tin.it" <riccardo.sciaccaluga@tin.it>
 of "Thu, 03 Nov 2005 17:09:35 +0100." <26039397.1131034175456.JavaMail.root@pswm9.cp.tin.it>
Message-ID: <34284.1131034860@tigger.icir.org>

Hi,

Previously RIP was using its one mechanism to import and export routes,
it now uses the unified policy framework.

It is now necessary to define a policy statement to capture what you
want to export.

To export the static routes:

----------------------------------------
First a policy statment:
policy {
    policy-statement export_static {
    term static {
        from {
	     protocol: "static"
        }
    }
}

Also:
protocols {
    rip {
    export: "export_static"
...
----------------------------------------

To export the connected routes:

----------------------------------------
First a policy statment:
policy {
    policy-statement export_connected {
    term rib {
        from {
	     protocol: "rib"
        }
    }
}

Also:
protocols {
    rip {
    export: "export_connected,export_static"
...
----------------------------------------

	Atanu.

>>>>> "riccardo" == riccardo  <riccardo.sciaccaluga@tin.it> writes:

    riccardo> I upgraded my current xorp version at the latest CVS file
    riccardo> and i tried to configure xorp with the same config.boot
    riccardo> file i used with xorp.1-1.  It was a file configuring a
    riccardo> totally rip working network but the lateste CVS look like
    riccardo> if it didn't accept the export command giving to me the
    riccardo> following error message and killing the booting of xorp:

    riccardo> [ 2005/11/04 00:46:13 INFO xorp_rtrmgr:1195 RTRMGR +240
    riccardo> master_conf_tree.cc execute ] Changed modules: interfaces,
    riccardo> fea, rib, policy, rip [ 2005/11/04 00:46: 13 INFO
    riccardo> xorp_rtrmgr:1195 RTRMGR +484 module_manager.cc run ]
    riccardo> Running module: interfaces
    riccardo> (/root/Andrea/xorp/fea/xorp_fea) [ 2005/11/04 00:46: 13
    riccardo> INFO xorp_fea MFEA ] MFEA enabled [ 2005/11/04 00:46:13
    riccardo> INFO xorp_fea MFEA ] CLI enabled [ 2005/11/04 00:46:13
    riccardo> INFO xorp_fea MFEA ] CLI started [ 2005/11/04 00:46:15
    riccardo> INFO xorp_rtrmgr:1195 RTRMGR +484 module_manager.cc run ]
    riccardo> Running module: fea (/root/Andrea/xorp/fea/xorp_fea) [
    riccardo> 2005/11/04 00:46:21 INFO xorp_rtrmgr:1195 RTRMGR +484
    riccardo> module_manager.cc run ] Running module: rib
    riccardo> (/root/Andrea/xorp/rib/xorp_rib) [ 2005/11/04 00:46:23
    riccardo> INFO xorp_rtrmgr:1195 RTRMGR +484 module_manager.cc run ]
    riccardo> Running module: policy
    riccardo> (/root/Andrea/xorp/policy/xorp_policy) [ 2005/11/04
    riccardo> 00:46:25 INFO xorp_rtrmgr:1195 RTRMGR +484
    riccardo> module_manager.cc run ] Running module: rip
    riccardo> (/root/Andrea/xorp/rip/xorp_rip) [ 2005/11/04 00:46:27
    riccardo> WARNING xorp_policy:1198 XrlPolicyTarget +513
    riccardo> policy_base.cc handle_policy_0_1_export ] Handling method
    riccardo> for policy/0.1/export failed: XrlCmdError 102 Command
    riccardo> failed Export of rip failed: exports: Protocol rip unknown
    riccardo> [ 2005/11/04 00:46:27 ERROR xorp_rtrmgr:1195 RTRMGR +671
    riccardo> master_conf_tree.cc commit_pass2_done ] Commit failed: 102
    riccardo> Command failed Export of rip failed: exports: Protocol rip
    riccardo> unknown [ 2005/11/04 00:46:27 ERROR xorp_rtrmgr:1195
    riccardo> RTRMGR +252 master_conf_tree.cc config_done ]
    riccardo> Configuration failed: 102 Command failed Export of rip
    riccardo> failed: exports: Protocol rip unknown [ 2005/11/04
    riccardo> 00:46:27 INFO xorp_rtrmgr:1195 RTRMGR +2225 task.cc
    riccardo> run_task ] No more tasks to run [ 2005/11/04 00:46:27 INFO
    riccardo> xorp_rtrmgr:1195 RTRMGR +247 module_manager.cc terminate ]
    riccardo> Terminating module: fea [ 2005/11/04 00: 46:27 INFO
    riccardo> xorp_rtrmgr:1195 RTRMGR +247 module_manager.cc terminate ]
    riccardo> Terminating module: interfaces [ 2005/11/04 00:46:27 INFO
    riccardo> xorp_rtrmgr: 1195 RTRMGR +300 module_manager.cc terminate
    riccardo> ] Killing module: interfaces (pid = 0x4ac) [ 2005/11/04
    riccardo> 00:46:27 INFO xorp_rtrmgr:1195 RTRMGR +247
    riccardo> module_manager.cc terminate ] Terminating module: policy [
    riccardo> 2005/11/04 00:46:27 INFO xorp_rtrmgr:1195 RTRMGR +300
    riccardo> module_manager.  cc terminate ] Killing module: policy
    riccardo> (pid = 0x4ae) [ 2005/11/04 00:46: 27 INFO xorp_rtrmgr:1195
    riccardo> RTRMGR +247 module_manager.cc terminate ] Terminating
    riccardo> module: rib [ 2005/11/04 00:46:27 INFO xorp_rtrmgr:1195
    riccardo> RTRMGR +300 module_manager.cc terminate ] Killing module:
    riccardo> rib (pid = 0x4ad) [ 2005/11/04 00:46:27 INFO
    riccardo> xorp_rtrmgr:1195 RTRMGR +247 module_manager.cc terminate ]
    riccardo> Terminating module: rip [ 2005/11/04 00: 46:27 INFO
    riccardo> xorp_rtrmgr:1195 RTRMGR +300 module_manager.cc terminate ]
    riccardo> Killing module: rip (pid = 0x4af) [ 2005/11/04 00:46:27
    riccardo> INFO xorp_rtrmgr:1195 RTRMGR +664 module_manager.cc killed
    riccardo> ] Module killed during shutdown: policy [ 2005/11/04
    riccardo> 00:46:27 INFO xorp_rtrmgr:1195 RTRMGR +664
    riccardo> module_manager.cc killed ] Module killed during shutdown:
    riccardo> rib [ 2005/11/04 00:46:27 INFO xorp_rtrmgr:1195 RTRMGR
    riccardo> +664 module_manager.cc killed ] Module killed during
    riccardo> shutdown: interfaces [ 2005/11/04 00:46:27 INFO
    riccardo> xorp_rtrmgr:1195 RTRMGR +664 module_manager.  cc killed ]
    riccardo> Module killed during shutdown: rip


    riccardo> Is there a different syntax for export rip managed route
    riccardo> or could it be a bug?
    riccardo> _______________________________________________ Xorp-users
    riccardo> mailing list Xorp-users@xorp.org
    riccardo> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users

From hkontos@gmail.com  Tue Nov  8 11:21:33 2005
From: hkontos@gmail.com (=?ISO-8859-1?Q?Hajnalka_K=F6nt=F6s?=)
Date: Tue, 8 Nov 2005 12:21:33 +0100
Subject: [Xorp-users] Fwd: how to forward a multicast message with pimsm?
In-Reply-To: <15c242670511080319q7641ea99m86352aeac0455a23@mail.gmail.com>
References: <15c242670511080319q7641ea99m86352aeac0455a23@mail.gmail.com>
Message-ID: <15c242670511080321m357373fdx958d137e511d04af@mail.gmail.com>

I wish to configure a simple pim-sm network to send my multicast
messages to the remote site. I use the liveCD with xorp. My multicast
messages do not arrive to the remote network. Will you please help me
why, or what should be done on another way?

My test network:
Host1-[net1]-Router1-[net0]-Router2-[net2]-Host2

where
- Router1, Router2: xorp routers, see config below
- Host1, Host2 are hosts on different sites that wish to exchange
multicast datagrams of IP 239.253.0.200.
- net0: 192.168.64.0/24
- net1: 10.7.7.0/24
- net2: 10.6.6.0/24

I have 'mtest' on both Hosts to register them to igmp multicast group
of 239.253.0.200. Then from Host1 I send udp messages to this
multicast address, which is expected to seen on Host2. I tried
bootstrap and static rp setting as well on the routers, but this
traffic does not arrive to Host2 or vice versa.

Tcpdump shows that routers see the 239.253.0.200 multicast traffic
coming in the inside interface (net1|net2), but router does not put
this multicast traffic to its outside inteface on net0.
What am I doing wrong?

Router1 is the RP
Router1: xorpsh -> configure -> show
-------------------------------
 interfaces {
        interface lnc0 {
            description: "lnc0"
            disable: false
            vif lnc0 {
                disable: false
                address 10.7.7.1 {
                    prefix-length: 24
                    broadcast: 10.7.7.255
                    disable: false
                }
            }
            discard: false
        }
        interface lnc1 {
            description: "lnc1"
            disable: false
            vif lnc1 {
                disable: false
                address 192.168.64.177 {
                    prefix-length: 24
                    broadcast: 192.168.64.255
                    disable: false
                }
            }
            discard: false
        }
        targetname: "fea"
    }
    fea {
        unicast-forwarding4 {
            disable: false
        }
        targetname: "fea"
    }
    plumbing {
        mfea4 {
            disable: false
            interface lnc0 {
                vif lnc0 {
                    disable: false
                }
            }
            interface lnc1 {
                vif lnc1 {
                    disable: false
                }
            }
            interface register_vif {
                vif register_vif {
                    disable: false
                }
            }
            traceoptions {
                flag {
                    all {
                        disable: false
                    }
                }
            }
            targetname: "MFEA_4"
        }
    }
    protocols {
        static {
            route4 10.6.6.0/24 {
                next-hop: 192.168.64.160
                metric: 1
            }
            mrib-route4 10.6.6.0/24 {
                next-hop: 192.168.64.160
                metric: 1
            }
            targetname: "static_routes"
            disable: true
        }
        igmp {
            disable: false
            interface lnc0 {
                vif lnc0 {
                    disable: false
                }
            }
            interface lnc1 {
                vif lnc1 {
                    disable: false
                }
            }
            traceoptions {
                flag {
                    all {
                        disable: false
                    }
                }
            }
            targetname: "IGMP"
        }
        pimsm4 {
            disable: false
            interface lnc0 {
                vif lnc0 {
                    disable: false
                    dr-priority: 1
                }
            }
            interface lnc1 {
                vif lnc1 {
                    disable: false
                    dr-priority: 1
                }
            }
            interface register_vif {
                vif register_vif {
                    disable: false
                    dr-priority: 1
                }
            }
            static-rps {
                rp 192.168.64.177 {
                    group-prefix 224.0.0.0/4 {
                        rp-priority: 192
                        hash-mask-len: 30
                    }
                    group-prefix 239.253.0.0/24 {
                        rp-priority: 192
                        hash-mask-len: 30
                    }
                }
            }
            switch-to-spt-threshold {
                disable: false
                interval-sec: 100
                bytes: 102400
            }
            traceoptions {
                flag {
                    all {
                        disable: false
                    }
                }
            }
            targetname: "PIMSM_4"
        }
        fib2mrib {
            disable: false
            targetname: "fib2mrib"
        }
    }
----------------------------------------

Router1:

Xorp> show pim interface
Interface    State    Mode   V PIMstate Priority DRaddr          Neighbors
lnc0         UP       Sparse 2 DR              1 10.7.7.1                0
lnc1         UP       Sparse 2 DR              1 192.168.64.177          1
register_vif UP       Sparse 2 DR              1 10.7.7.1                0

Xorp> show pim neighbors
Interface    DRpriority NeighborAddr    V Mode   Holdtime Timeout
lnc1                  1 192.168.64.160  2 Sparse      105      88

Xorp> show pim rps
RP              Type      Pri Holdtime Timeout ActiveGroups GroupPrefix
192.168.64.177  static    192       -1      -1            0 224.0.0.0/4
192.168.64.177  static    192       -1      -1            1 239.253.0.0/24

Xorp> show pim mrib
DestPrefix         NextHopRouter   VifName VifIndex MetricPref Metric
10.6.6.0/24        10.6.6.1        lnc0    0                 0      0
10.7.7.0/24        192.168.64.177  lnc1    1                 1      1
192.168.64.0/24    192.168.64.160  lnc1    1                 0      0

Xorp> show pim join
Group           Source          RP              Flags

Xorp> show pim mfc
Group           Source          RP


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

Router2:

Xorp> show pim interface
Interface    State    Mode   V PIMstate Priority DRaddr          Neighbors
lnc0         UP       Sparse 2 DR              1 10.6.6.1                0
lnc1         UP       Sparse 2 NotDR           1 192.168.64.177          1
register_vif UP       Sparse 2 DR              1 10.6.6.1                0

Xorp> show pim neighbors
Interface    DRpriority NeighborAddr    V Mode   Holdtime Timeout
lnc1                  1 192.168.64.177  2 Sparse      105      78

Xorp> show pim rps
RP              Type      Pri Holdtime Timeout ActiveGroups GroupPrefix
192.168.64.177  static    192       -1      -1            0 224.0.0.0/4
192.168.64.177  static    192       -1      -1            0 239.253.0.0/24

Xorp> show pim mrib
DestPrefix         NextHopRouter   VifName VifIndex MetricPref Metric
10.6.6.0/24        192.168.64.160  lnc1    1                 1      1
10.7.7.0/24        10.7.7.1        lnc0    0                 0      0
192.168.64.0/24    192.168.64.177  lnc1    1                 0      0

Xorp> show pim join
Group           Source          RP              Flags

Xorp> show pim mfc
Group           Source          RP



Thank you for any advice.
Hajni


From batkinson@virtc.com  Wed Nov  9 21:23:07 2005
From: batkinson@virtc.com (Brian Atkinson)
Date: Wed, 09 Nov 2005 16:23:07 -0500
Subject: [Xorp-users] Change metric for "connected" routes?
Message-ID: <437268BB.3030104@virtc.com>

Is there a way to change the "metric" value for "connected" routes?


From feamster@lcs.mit.edu  Wed Nov  9 22:20:00 2005
From: feamster@lcs.mit.edu (Nick Feamster)
Date: Wed, 9 Nov 2005 17:20:00 -0500
Subject: [Xorp-users] wanted: OSPF metrics per neighbor.  can vif help?
Message-ID: <20051109222000.GN3791@lcs.mit.edu>

--sdtB3X0nJg68CQEu
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hey guys, 

The OSPF implementation is really great.  Thanks!

I have a question/feature request.  I have an interface that is on a /8
subnet, with multiple other hosts on that subnet.  I'd like to set the
OSPF link metric *per neighbor* on that subnet, rather than per
interface.  Currently, interface aliases are not an option; I am
wondering if XORP's "vif" functionality can come to the rescue.

Perhaps the above functionality is already possible, or perhaps it
requires modification to the code.  Can you help me understand vifs and
how this might be possible?

Currently, the interface-cost can be set in the vif stanza, so I thought
it might be possible to give multiple vifs to an interface and then set
different interface costs per vif.  However, I've run into a few
roadblocks when trying this.

1.) How do I assign different vif names to a single interface?

    I have an interface called "tap0".  Assigning a vif with the name
    "tap0" is definitely possible.  However, configuring another vif
    with a different name inside interface "tap0" (e.g. interface named
    "tap0", vif named "tap1") appears to be illegal.

    What's the proper way to assign multiple vifs to an interface?

    Is this even what I want to solve my OSPF problem?


2.) How do I get a separate interface-cost per vif/neighbor?  Inside my
    OSPF stanza, I have something that looks as follows:

          area 0.0.0.0 {
                interface tap0 {
                    link-type: "p2m"
                    vif tap0 {
                       address 10.13.79.1 {
                           interface-cost: 5
                               /* planetlab02.cs.washington.edu */
                               neighbour 10.0.35.1 {
                                    router-id: 128.208.4.198
                               }

                        }
                    }

                    vif tap0 {
                       address 10.13.79.1 {
                           interface-cost: 1
                               /* planetlab2.arizona-gigapop.net */
                               neighbour 10.0.10.1 {
                                    router-id: 206.207.248.35
                               }

                        }
                    }

                }


   Note that I am trying to set a different interface cost per neighbor. 
   Now, when I look at "show ospf4 database detail", it looks like both  
   of these LSAs are getting a metric of 1, indicating
   that perhaps there is just a single data structure for the
   interface-cost per interface.  (I've attached this configuration file
   for reference.)

   It seems that there are two possible solutions:
	- If the data structure is per-vif name (e.g. "vif tap0"), I
	  need to figure out the answer to Question #1 above.

	- If the data structure is per-interface (e.g. "interface
	  tap0"), I guess some changes to the code are needed, yes?  If
	  this is the case, can I put in a feature request? :)  If you
	  like the idea but don't have time to implement, we can also
	  work on a patch, if you'd be willing to add it into the source
	  tree.

Thanks,
Nick

--sdtB3X0nJg68CQEu
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="planetlab2.info.ucl.ac.be.xorp"

/* XORP configuration automatically generated by build_ospf_configs.pl */

/* XORP configuration automatically generated by build_configs.pl */

interfaces {
    interface lo {
	description: "loopback interface";
	disable: false
	mac: 00:00:00:00:00:00
	default-system-config
    }
    interface tap0 {
        description: "virtual overlay interface";
        disable: false
	default-system-config
    }
    interface eth0 {
        description: "ethernet adapter"
        disable: false
        default-system-config
    }
}

fea {
    unicast-forwarding4 {
        disable: true
    }

    click {
        disable: false

        user-click {
            disable: false
            command-file: "/home/mit_rcp/demo/click"
            command-extra-arguments: "-R"
            command-execute-on-startup: true
            control-address: 127.0.0.1
            control-socket-port: 13654
            startup-config-file: "/home/mit_rcp/demo/planetlab2.info.ucl.ac.be.click"
        }
    }
}

    protocols {
	ospf4 {
	    router-id:  130.104.72.201
	    area 0.0.0.0 {
                interface tap0 {
                    link-type: "p2m"
                    vif tap0 {
                       address 10.13.79.1 {
			   interface-cost: 5
	                       /* planetlab02.cs.washington.edu */
	                       neighbour 10.0.35.1 {
	                            router-id: 128.208.4.198
	                       }

			}
		    }

                    vif tap0 {
                       address 10.13.79.1 {
			   interface-cost: 1
	                       /* planetlab2.arizona-gigapop.net */
	                       neighbour 10.0.10.1 {
	                            router-id: 206.207.248.35
	                       }

			}
		    }

                }


                interface eth0 {
                    vif eth0 {
                        address 130.104.72.201 {
                        }
                    }
                }
            }

            traceoptions {
                flag {
                    all {
                       disable: false
                    }
                }
            }
        }
    }

--sdtB3X0nJg68CQEu--

From M.Handley@cs.ucl.ac.uk  Wed Nov  9 22:28:12 2005
From: M.Handley@cs.ucl.ac.uk (Mark Handley)
Date: Wed, 9 Nov 2005 22:28:12 +0000
Subject: [Xorp-users] Change metric for "connected" routes?
In-Reply-To: <437268BB.3030104@virtc.com>
References: <437268BB.3030104@virtc.com>
Message-ID: <84a612dd0511091428x67b65b30nbf44873a1632e3f@mail.gmail.com>

On 11/9/05, Brian Atkinson <batkinson@virtc.com> wrote:
> Is there a way to change the "metric" value for "connected" routes?

Short answer: no.

Longer answer: normally connected routes win on admin distance. 
Metric can't override admin distance.  Thus this would only be a
relevant issue if you had more than one interface connected to the
same IP subnet.  In all other circumstances, it would not have any
effect anyway, even if you could set it.  Is that the scenario you're
concerned with?

 - Mark


From atanu@ICSI.Berkeley.EDU  Wed Nov  9 23:58:13 2005
From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Wed, 09 Nov 2005 15:58:13 -0800
Subject: [Xorp-users] wanted: OSPF metrics per neighbor. can vif help?
In-Reply-To: Message from Nick Feamster <feamster@lcs.mit.edu>
 of "Wed, 09 Nov 2005 17:20:00 EST." <20051109222000.GN3791@lcs.mit.edu>
Message-ID: <82787.1131580693@tigger.icir.org>

Hi,

The interface-cost is a per interface setting and it was a mistake in
the template file to require it to be set at the address level. It
should be set at the interface level with the link-type.

In the OSPF implementation the interface and vif are combined to form a
PeerOut (which is the equivalent of an OSPF interface). The PeerOut is
where the interface-cost is stored.

At the moment the FEA enforces that the interface and vif name are the
same. Which is why you haven't been able to change the vif name. There
have been some discussions on this issue over the last few days on
xorp-hackers.

If you can create a separate tap device per neighbour then you will be
able to set the interface cost with the current code.

The other option is add code to take the interface cost per neigbour in
a similar manor to the way that the neighbour router-id is
configured. If you make a bugzilla entry requesting the enhancement and
upload the patch that would be useful.

>From my reading of the specification all links from a particular
interface should all have the same link cost.

---------------------------------------- RFC 2328
		o   For each fully adjacent neighbor associated with the
		    interface, add an additional Type 1 link (point-to-
		    point) with Link ID set to the Router ID of the
		    neighboring router, Link Data set to the IP
		    interface address and cost equal to the interface's
		    configured output cost.
----------------------------------------

We would be slightly concerned about adding code that may violate the
standard, however, this seems like a useful feature.

	  Atanu.

>>>>> "Nick" == Nick Feamster <feamster@lcs.mit.edu> writes:

    Nick> Hey guys, 
    Nick> The OSPF implementation is really great.  Thanks!

    Nick> I have a question/feature request.  I have an interface that is on a /8
    Nick> subnet, with multiple other hosts on that subnet.  I'd like to set the
    Nick> OSPF link metric *per neighbor* on that subnet, rather than per
    Nick> interface.  Currently, interface aliases are not an option; I am
    Nick> wondering if XORP's "vif" functionality can come to the rescue.

    Nick> Perhaps the above functionality is already possible, or perhaps it
    Nick> requires modification to the code.  Can you help me understand vifs and
    Nick> how this might be possible?

    Nick> Currently, the interface-cost can be set in the vif stanza, so I thought
    Nick> it might be possible to give multiple vifs to an interface and then set
    Nick> different interface costs per vif.  However, I've run into a few
    Nick> roadblocks when trying this.

    Nick> 1.) How do I assign different vif names to a single interface?

    Nick> I have an interface called "tap0".  Assigning a vif with the name
    Nick> "tap0" is definitely possible.  However, configuring another vif
    Nick> with a different name inside interface "tap0" (e.g. interface named
    Nick> "tap0", vif named "tap1") appears to be illegal.

    Nick> What's the proper way to assign multiple vifs to an interface?

    Nick> Is this even what I want to solve my OSPF problem?


    Nick> 2.) How do I get a separate interface-cost per vif/neighbor?  Inside my
    Nick> OSPF stanza, I have something that looks as follows:

    Nick> area 0.0.0.0 {
    Nick> interface tap0 {
    Nick> link-type: "p2m"
    Nick> vif tap0 {
    Nick> address 10.13.79.1 {
    Nick> interface-cost: 5
    Nick> /* planetlab02.cs.washington.edu */
    Nick> neighbour 10.0.35.1 {
    Nick> router-id: 128.208.4.198
    Nick> }

    Nick> }
    Nick> }

    Nick> vif tap0 {
    Nick> address 10.13.79.1 {
    Nick> interface-cost: 1
    Nick> /* planetlab2.arizona-gigapop.net */
    Nick> neighbour 10.0.10.1 {
    Nick> router-id: 206.207.248.35
    Nick> }

    Nick> }
    Nick> }

    Nick> }


    Nick> Note that I am trying to set a different interface cost per neighbor. 
    Nick> Now, when I look at "show ospf4 database detail", it looks like both  
    Nick> of these LSAs are getting a metric of 1, indicating
    Nick> that perhaps there is just a single data structure for the
    Nick> interface-cost per interface.  (I've attached this configuration file
    Nick> for reference.)

    Nick> It seems that there are two possible solutions:
    Nick> - If the data structure is per-vif name (e.g. "vif tap0"), I
    Nick> need to figure out the answer to Question #1 above.

    Nick> - If the data structure is per-interface (e.g. "interface
    Nick> tap0"), I guess some changes to the code are needed, yes?  If
    Nick> this is the case, can I put in a feature request? :)  If you
    Nick> like the idea but don't have time to implement, we can also
    Nick> work on a patch, if you'd be willing to add it into the source
    Nick> tree.

    Nick> Thanks,
    Nick> Nick
    Nick> /* XORP configuration automatically generated by build_ospf_configs.pl */

    Nick> /* XORP configuration automatically generated by build_configs.pl */

    Nick> interfaces {
    Nick> interface lo {
    Nick> description: "loopback interface";
    Nick> disable: false
    Nick> mac: 00:00:00:00:00:00
    Nick> default-system-config
    Nick> }
    Nick> interface tap0 {
    Nick> description: "virtual overlay interface";
    Nick> disable: false
    Nick> default-system-config
    Nick> }
    Nick> interface eth0 {
    Nick> description: "ethernet adapter"
    Nick> disable: false
    Nick> default-system-config
    Nick> }
    Nick> }

    Nick> fea {
    Nick> unicast-forwarding4 {
    Nick> disable: true
    Nick> }

    Nick> click {
    Nick> disable: false

    Nick> user-click {
    Nick> disable: false
    Nick> command-file: "/home/mit_rcp/demo/click"
    Nick> command-extra-arguments: "-R"
    Nick> command-execute-on-startup: true
    Nick> control-address: 127.0.0.1
    Nick> control-socket-port: 13654
    Nick> startup-config-file: "/home/mit_rcp/demo/planetlab2.info.ucl.ac.be.click"
    Nick> }
    Nick> }
    Nick> }

    Nick> protocols {
    Nick> ospf4 {
    Nick> router-id:  130.104.72.201
    Nick> area 0.0.0.0 {
    Nick> interface tap0 {
    Nick> link-type: "p2m"
    Nick> vif tap0 {
    Nick> address 10.13.79.1 {
    Nick> interface-cost: 5
    Nick> /* planetlab02.cs.washington.edu */
    Nick> neighbour 10.0.35.1 {
    Nick> router-id: 128.208.4.198
    Nick> }

    Nick> }
    Nick> }

    Nick> vif tap0 {
    Nick> address 10.13.79.1 {
    Nick> interface-cost: 1
    Nick> /* planetlab2.arizona-gigapop.net */
    Nick> neighbour 10.0.10.1 {
    Nick> router-id: 206.207.248.35
    Nick> }

    Nick> }
    Nick> }

    Nick> }


    Nick> interface eth0 {
    Nick> vif eth0 {
    Nick> address 130.104.72.201 {
    Nick> }
    Nick> }
    Nick> }
    Nick> }

    Nick> traceoptions {
    Nick> flag {
    Nick> all {
    Nick> disable: false
    Nick> }
    Nick> }
    Nick> }
    Nick> }
    Nick> }

From feamster@lcs.mit.edu  Thu Nov 10 00:29:41 2005
From: feamster@lcs.mit.edu (Nick Feamster)
Date: Wed, 9 Nov 2005 19:29:41 -0500
Subject: [Xorp-users] wanted: OSPF metrics per neighbor. can vif help?
In-Reply-To: <82787.1131580693@tigger.icir.org>
References: <feamster@lcs.mit.edu> <20051109222000.GN3791@lcs.mit.edu> <82787.1131580693@tigger.icir.org>
Message-ID: <20051110002940.GC5023@lcs.mit.edu>

Atanu,

Thanks for the quick, clear reply.   A few comments inline...

On Wed, Nov 09, 2005 at 03:58:13PM -0800, Atanu Ghosh wrote:
> The interface-cost is a per interface setting and it was a mistake in
> the template file to require it to be set at the address level. It
> should be set at the interface level with the link-type.

That makes sense.  Is this fixed in the current CVS version of XORP? 

> In the OSPF implementation the interface and vif are combined to form a
> PeerOut (which is the equivalent of an OSPF interface). The PeerOut is
> where the interface-cost is stored.

I guess I am confused as to the point of the vif.  It isn't really
explained in the user's manual.  Why have it at all if I can't create
multiple virtual interfaces with different names on top of a single
phyiscal interface?

> At the moment the FEA enforces that the interface and vif name are the
> same. Which is why you haven't been able to change the vif name. There
> have been some discussions on this issue over the last few days on
> xorp-hackers.
> 
> If you can create a separate tap device per neighbour then you will be
> able to set the interface cost with the current code.

This option presently does not exist, so we are looking for workarounds.

> The other option is add code to take the interface cost per neigbour in
> a similar manor to the way that the neighbour router-id is
> configured. If you make a bugzilla entry requesting the enhancement and
> upload the patch that would be useful.
> 
> >From my reading of the specification all links from a particular
> interface should all have the same link cost.
> 
> ---------------------------------------- RFC 2328
> 		o   For each fully adjacent neighbor associated with the
> 		    interface, add an additional Type 1 link (point-to-
> 		    point) with Link ID set to the Router ID of the
> 		    neighboring router, Link Data set to the IP
> 		    interface address and cost equal to the interface's
> 		    configured output cost.
> ----------------------------------------
> 
> We would be slightly concerned about adding code that may violate the
> standard, however, this seems like a useful feature.

I understand what the RFC says, and sticking to standards seems like a
good idea in general.  If I could create multiple virtual interfaces
(vifs) on top of a single phyiscal interface (e.g., one vif per
neighbor) and subsequently set the interface cost per vif, then would
that not comply with the standard and give me the functionality we
want/need?

Cheers,
Nick

From pavlin@icir.org  Thu Nov 10 02:51:24 2005
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Wed, 09 Nov 2005 18:51:24 -0800
Subject: [Xorp-users] Fwd: how to forward a multicast message with pimsm?
In-Reply-To: Message from =?ISO-8859-1?Q?Hajnalka_K=F6nt=F6s?= <hkontos@gmail.com>
 of "Tue, 08 Nov 2005 12:21:33 +0100." <15c242670511080321m357373fdx958d137e511d04af@mail.gmail.com>
Message-ID: <200511100251.jAA2pO9m092588@possum.icir.org>

Hajni,

Your configuration looks fine.
However, for whatever reason Router2 hasn't sent PIM-SM Join message
toward Router1 (the RP).

Could you double-check that Host2 has really joined the multicast
group. On Router2 "show igmp group" inside xorpsh should show that
Host2 is a receiver.
If you don't see Host2 as a receiver, then on Host2 itself you could
run a command like "netstat -g" in case of FreeBSD to see the joined
multicast groups.
If, say, you see that Host2 has indeed joined the multicast group,
but Router2 doesn't list Host2 as a receiver, then use tcpdump on
both Host2 and Router2 to see whether they see the IGMP control
messages from each other.

Depends on the above results we can try to explore further where the
problem is.

Pavlin

P.S. This is not related to your problem, but don't forget that the
sender's TTL of the multicast packets should be large enough to
reach the receiver. Typically, the default TTL for multicast tools
is 1 so you may have to explicitly set it to some larger value.


> I wish to configure a simple pim-sm network to send my multicast
> messages to the remote site. I use the liveCD with xorp. My multicast
> messages do not arrive to the remote network. Will you please help me
> why, or what should be done on another way?
> 
> My test network:
> Host1-[net1]-Router1-[net0]-Router2-[net2]-Host2
> 
> where
> - Router1, Router2: xorp routers, see config below
> - Host1, Host2 are hosts on different sites that wish to exchange
> multicast datagrams of IP 239.253.0.200.
> - net0: 192.168.64.0/24
> - net1: 10.7.7.0/24
> - net2: 10.6.6.0/24
> 
> I have 'mtest' on both Hosts to register them to igmp multicast group
> of 239.253.0.200. Then from Host1 I send udp messages to this
> multicast address, which is expected to seen on Host2. I tried
> bootstrap and static rp setting as well on the routers, but this
> traffic does not arrive to Host2 or vice versa.
> 
> Tcpdump shows that routers see the 239.253.0.200 multicast traffic
> coming in the inside interface (net1|net2), but router does not put
> this multicast traffic to its outside inteface on net0.
> What am I doing wrong?
> 
> Router1 is the RP
> Router1: xorpsh -> configure -> show
> -------------------------------
>  interfaces {
>         interface lnc0 {
>             description: "lnc0"
>             disable: false
>             vif lnc0 {
>                 disable: false
>                 address 10.7.7.1 {
>                     prefix-length: 24
>                     broadcast: 10.7.7.255
>                     disable: false
>                 }
>             }
>             discard: false
>         }
>         interface lnc1 {
>             description: "lnc1"
>             disable: false
>             vif lnc1 {
>                 disable: false
>                 address 192.168.64.177 {
>                     prefix-length: 24
>                     broadcast: 192.168.64.255
>                     disable: false
>                 }
>             }
>             discard: false
>         }
>         targetname: "fea"
>     }
>     fea {
>         unicast-forwarding4 {
>             disable: false
>         }
>         targetname: "fea"
>     }
>     plumbing {
>         mfea4 {
>             disable: false
>             interface lnc0 {
>                 vif lnc0 {
>                     disable: false
>                 }
>             }
>             interface lnc1 {
>                 vif lnc1 {
>                     disable: false
>                 }
>             }
>             interface register_vif {
>                 vif register_vif {
>                     disable: false
>                 }
>             }
>             traceoptions {
>                 flag {
>                     all {
>                         disable: false
>                     }
>                 }
>             }
>             targetname: "MFEA_4"
>         }
>     }
>     protocols {
>         static {
>             route4 10.6.6.0/24 {
>                 next-hop: 192.168.64.160
>                 metric: 1
>             }
>             mrib-route4 10.6.6.0/24 {
>                 next-hop: 192.168.64.160
>                 metric: 1
>             }
>             targetname: "static_routes"
>             disable: true
>         }
>         igmp {
>             disable: false
>             interface lnc0 {
>                 vif lnc0 {
>                     disable: false
>                 }
>             }
>             interface lnc1 {
>                 vif lnc1 {
>                     disable: false
>                 }
>             }
>             traceoptions {
>                 flag {
>                     all {
>                         disable: false
>                     }
>                 }
>             }
>             targetname: "IGMP"
>         }
>         pimsm4 {
>             disable: false
>             interface lnc0 {
>                 vif lnc0 {
>                     disable: false
>                     dr-priority: 1
>                 }
>             }
>             interface lnc1 {
>                 vif lnc1 {
>                     disable: false
>                     dr-priority: 1
>                 }
>             }
>             interface register_vif {
>                 vif register_vif {
>                     disable: false
>                     dr-priority: 1
>                 }
>             }
>             static-rps {
>                 rp 192.168.64.177 {
>                     group-prefix 224.0.0.0/4 {
>                         rp-priority: 192
>                         hash-mask-len: 30
>                     }
>                     group-prefix 239.253.0.0/24 {
>                         rp-priority: 192
>                         hash-mask-len: 30
>                     }
>                 }
>             }
>             switch-to-spt-threshold {
>                 disable: false
>                 interval-sec: 100
>                 bytes: 102400
>             }
>             traceoptions {
>                 flag {
>                     all {
>                         disable: false
>                     }
>                 }
>             }
>             targetname: "PIMSM_4"
>         }
>         fib2mrib {
>             disable: false
>             targetname: "fib2mrib"
>         }
>     }
> ----------------------------------------
> 
> Router1:
> 
> Xorp> show pim interface
> Interface    State    Mode   V PIMstate Priority DRaddr          Neighbors
> lnc0         UP       Sparse 2 DR              1 10.7.7.1                0
> lnc1         UP       Sparse 2 DR              1 192.168.64.177          1
> register_vif UP       Sparse 2 DR              1 10.7.7.1                0
> 
> Xorp> show pim neighbors
> Interface    DRpriority NeighborAddr    V Mode   Holdtime Timeout
> lnc1                  1 192.168.64.160  2 Sparse      105      88
> 
> Xorp> show pim rps
> RP              Type      Pri Holdtime Timeout ActiveGroups GroupPrefix
> 192.168.64.177  static    192       -1      -1            0 224.0.0.0/4
> 192.168.64.177  static    192       -1      -1            1 239.253.0.0/24
> 
> Xorp> show pim mrib
> DestPrefix         NextHopRouter   VifName VifIndex MetricPref Metric
> 10.6.6.0/24        10.6.6.1        lnc0    0                 0      0
> 10.7.7.0/24        192.168.64.177  lnc1    1                 1      1
> 192.168.64.0/24    192.168.64.160  lnc1    1                 0      0
> 
> Xorp> show pim join
> Group           Source          RP              Flags
> 
> Xorp> show pim mfc
> Group           Source          RP
> 
> 
> ----------------------------------------
> 
> Router2:
> 
> Xorp> show pim interface
> Interface    State    Mode   V PIMstate Priority DRaddr          Neighbors
> lnc0         UP       Sparse 2 DR              1 10.6.6.1                0
> lnc1         UP       Sparse 2 NotDR           1 192.168.64.177          1
> register_vif UP       Sparse 2 DR              1 10.6.6.1                0
> 
> Xorp> show pim neighbors
> Interface    DRpriority NeighborAddr    V Mode   Holdtime Timeout
> lnc1                  1 192.168.64.177  2 Sparse      105      78
> 
> Xorp> show pim rps
> RP              Type      Pri Holdtime Timeout ActiveGroups GroupPrefix
> 192.168.64.177  static    192       -1      -1            0 224.0.0.0/4
> 192.168.64.177  static    192       -1      -1            0 239.253.0.0/24
> 
> Xorp> show pim mrib
> DestPrefix         NextHopRouter   VifName VifIndex MetricPref Metric
> 10.6.6.0/24        192.168.64.160  lnc1    1                 1      1
> 10.7.7.0/24        10.7.7.1        lnc0    0                 0      0
> 192.168.64.0/24    192.168.64.177  lnc1    1                 0      0
> 
> Xorp> show pim join
> Group           Source          RP              Flags
> 
> Xorp> show pim mfc
> Group           Source          RP
> 
> 
> 
> Thank you for any advice.
> Hajni
> 
> _______________________________________________
> Xorp-users mailing list
> Xorp-users@xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From kristian@juniks.net  Thu Nov 10 05:25:03 2005
From: kristian@juniks.net (Kristian Larsson)
Date: Thu, 10 Nov 2005 06:25:03 +0100
Subject: [Xorp-users] wanted: OSPF metrics per neighbor. can vif help?
In-Reply-To: <20051110002940.GC5023@lcs.mit.edu>
References: <feamster@lcs.mit.edu> <20051109222000.GN3791@lcs.mit.edu> <82787.1131580693@tigger.icir.org> <20051110002940.GC5023@lcs.mit.edu>
Message-ID: <20051110052503.GC12610@juniks.net>

On Wed, Nov 09, 2005 at 07:29:41PM -0500, Nick Feamster wrote:
> Atanu,
> 
> Thanks for the quick, clear reply.   A few comments inline...
> 
> On Wed, Nov 09, 2005 at 03:58:13PM -0800, Atanu Ghosh wrote:
> > The interface-cost is a per interface setting and it was a mistake in
> > the template file to require it to be set at the address level. It
> > should be set at the interface level with the link-type.
> 
> That makes sense.  Is this fixed in the current CVS version of XORP? 
No.
> > In the OSPF implementation the interface and vif are combined to form a
> > PeerOut (which is the equivalent of an OSPF interface). The PeerOut is
> > where the interface-cost is stored.
> 
> I guess I am confused as to the point of the vif.  It isn't really
> explained in the user's manual.  Why have it at all if I can't create
> multiple virtual interfaces with different names on top of a single
> phyiscal interface?
The genereal idea is to be able to create for
example VLAN interfaces though the code is not
there yet.
> 
> > At the moment the FEA enforces that the interface and vif name are the
> > same. Which is why you haven't been able to change the vif name. There
> > have been some discussions on this issue over the last few days on
> > xorp-hackers.
> > 
> > If you can create a separate tap device per neighbour then you will be
> > able to set the interface cost with the current code.
> 
> This option presently does not exist, so we are looking for workarounds.
> 
> > The other option is add code to take the interface cost per neigbour in
> > a similar manor to the way that the neighbour router-id is
> > configured. If you make a bugzilla entry requesting the enhancement and
> > upload the patch that would be useful.
> > 
> > >From my reading of the specification all links from a particular
> > interface should all have the same link cost.
> > 
> > ---------------------------------------- RFC 2328
> > 		o   For each fully adjacent neighbor associated with the
> > 		    interface, add an additional Type 1 link (point-to-
> > 		    point) with Link ID set to the Router ID of the
> > 		    neighboring router, Link Data set to the IP
> > 		    interface address and cost equal to the interface's
> > 		    configured output cost.
> > ----------------------------------------
> > 
> > We would be slightly concerned about adding code that may violate the
> > standard, however, this seems like a useful feature.
> 
> I understand what the RFC says, and sticking to standards seems like a
> good idea in general.  If I could create multiple virtual interfaces
> (vifs) on top of a single phyiscal interface (e.g., one vif per
> neighbor) and subsequently set the interface cost per vif, then would
> that not comply with the standard and give me the functionality we
> want/need?
Even if you could create several interfaces it
would not do you much good. How would you separate
the traffic between the interfaces?
I beleive it to be very difficult.

   Kristian.
> Cheers,
> Nick
> _______________________________________________
> Xorp-users mailing list
> Xorp-users@xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users

From feamster@lcs.mit.edu  Thu Nov 10 06:48:04 2005
From: feamster@lcs.mit.edu (Nick Feamster)
Date: Thu, 10 Nov 2005 01:48:04 -0500
Subject: [Xorp-users] wanted: OSPF metrics per neighbor. can vif help?
In-Reply-To: <20051110052503.GC12610@juniks.net>
References: <feamster@lcs.mit.edu> <20051109222000.GN3791@lcs.mit.edu> <82787.1131580693@tigger.icir.org> <20051110002940.GC5023@lcs.mit.edu> <20051110052503.GC12610@juniks.net>
Message-ID: <20051110064804.GN6027@lcs.mit.edu>

On Thu, Nov 10, 2005 at 06:25:03AM +0100, Kristian Larsson wrote:
> > I understand what the RFC says, and sticking to standards seems like a
> > good idea in general.  If I could create multiple virtual interfaces
> > (vifs) on top of a single phyiscal interface (e.g., one vif per
> > neighbor) and subsequently set the interface cost per vif, then would
> > that not comply with the standard and give me the functionality we
> > want/need?
> Even if you could create several interfaces it
> would not do you much good. How would you separate
> the traffic between the interfaces?
> I beleive it to be very difficult.

Easy: each vif would have a separate IP address on which traffic could
be demuxed.

-Nick

From kristian@juniks.net  Thu Nov 10 16:15:27 2005
From: kristian@juniks.net (Kristian Larsson)
Date: Thu, 10 Nov 2005 17:15:27 +0100
Subject: [Xorp-users] wanted: OSPF metrics per neighbor. can vif help?
In-Reply-To: <20051110064804.GN6027@lcs.mit.edu>
References: <feamster@lcs.mit.edu> <20051109222000.GN3791@lcs.mit.edu> <82787.1131580693@tigger.icir.org> <20051110002940.GC5023@lcs.mit.edu> <20051110052503.GC12610@juniks.net> <20051110064804.GN6027@lcs.mit.edu>
Message-ID: <20051110161527.GA9551@juniks.net>

On Thu, Nov 10, 2005 at 01:48:04AM -0500, Nick Feamster wrote:
> On Thu, Nov 10, 2005 at 06:25:03AM +0100, Kristian Larsson wrote:
> > > I understand what the RFC says, and sticking to standards seems like a
> > > good idea in general.  If I could create multiple virtual interfaces
> > > (vifs) on top of a single phyiscal interface (e.g., one vif per
> > > neighbor) and subsequently set the interface cost per vif, then would
> > > that not comply with the standard and give me the functionality we
> > > want/need?
> > Even if you could create several interfaces it
> > would not do you much good. How would you separate
> > the traffic between the interfaces?
> > I beleive it to be very difficult.
> 
> Easy: each vif would have a separate IP address on which traffic could
> be demuxed.
If you want separate ip adresses in different this
should be possible to solve via alias interface.
On linux:
ifconfig eth0 1.1.1.1 netmask 255.255.255.0
ifconfig eth0:1 2.2.2.2 netmask 255.255.255.0
though if you wan't them all in the same subnet it
would be hard. This was what I assumed but I
suppose I'm wrong.

  Kristian
> 
> -Nick

From feamster@lcs.mit.edu  Thu Nov 10 16:39:55 2005
From: feamster@lcs.mit.edu (Nick Feamster)
Date: Thu, 10 Nov 2005 11:39:55 -0500
Subject: [Xorp-users] wanted: OSPF metrics per neighbor. can vif help?
In-Reply-To: <20051110161527.GA9551@juniks.net>
References: <feamster@lcs.mit.edu> <20051109222000.GN3791@lcs.mit.edu> <82787.1131580693@tigger.icir.org> <20051110002940.GC5023@lcs.mit.edu> <20051110052503.GC12610@juniks.net> <20051110064804.GN6027@lcs.mit.edu> <20051110161527.GA9551@juniks.net>
Message-ID: <20051110163955.GY6027@lcs.mit.edu>

On Thu, Nov 10, 2005 at 05:15:27PM +0100, Kristian Larsson wrote:
> On Thu, Nov 10, 2005 at 01:48:04AM -0500, Nick Feamster wrote:
> > On Thu, Nov 10, 2005 at 06:25:03AM +0100, Kristian Larsson wrote:
> > > > I understand what the RFC says, and sticking to standards seems like a
> > > > good idea in general.  If I could create multiple virtual interfaces
> > > > (vifs) on top of a single phyiscal interface (e.g., one vif per
> > > > neighbor) and subsequently set the interface cost per vif, then would
> > > > that not comply with the standard and give me the functionality we
> > > > want/need?
> > > Even if you could create several interfaces it
> > > would not do you much good. How would you separate
> > > the traffic between the interfaces?
> > > I beleive it to be very difficult.
> > 
> > Easy: each vif would have a separate IP address on which traffic could
> > be demuxed.
> If you want separate ip adresses in different this
> should be possible to solve via alias interface.
> On linux:
> ifconfig eth0 1.1.1.1 netmask 255.255.255.0
> ifconfig eth0:1 2.2.2.2 netmask 255.255.255.0
> though if you wan't them all in the same subnet it
> would be hard. This was what I assumed but I
> suppose I'm wrong.

Yes, IP aliasing is the functionality I was referring to; I want to know
how to do this in *XORP*.  I don't want to do this in the kernel
because:

1. This is not possible on planetlab.
2. Even if it were, I want to configure vifs that correspond to those
   aliases.  This does not seem possible since the vif name would match the
   physical interface name.

Back to my original question and what I am trying to achieve:

Given one physical interface, can I configure multiple vifs and set an
interface-cost per vif?  I don't care if all vifs or what have you have
the same IP address, even, as long as I can set different OSPF interface
costs for each one.

-Nick

From kristian@juniks.net  Thu Nov 10 17:07:04 2005
From: kristian@juniks.net (Kristian Larsson)
Date: Thu, 10 Nov 2005 18:07:04 +0100
Subject: [Xorp-users] wanted: OSPF metrics per neighbor. can vif help?
In-Reply-To: <20051110163955.GY6027@lcs.mit.edu>
References: <feamster@lcs.mit.edu> <20051109222000.GN3791@lcs.mit.edu> <82787.1131580693@tigger.icir.org> <20051110002940.GC5023@lcs.mit.edu> <20051110052503.GC12610@juniks.net> <20051110064804.GN6027@lcs.mit.edu> <20051110161527.GA9551@juniks.net> <20051110163955.GY6027@lcs.mit.edu>
Message-ID: <20051110170704.GB9551@juniks.net>

On Thu, Nov 10, 2005 at 11:39:55AM -0500, Nick Feamster wrote:
> On Thu, Nov 10, 2005 at 05:15:27PM +0100, Kristian Larsson wrote:
> > On Thu, Nov 10, 2005 at 01:48:04AM -0500, Nick Feamster wrote:
> > > On Thu, Nov 10, 2005 at 06:25:03AM +0100, Kristian Larsson wrote:
> > > > > I understand what the RFC says, and sticking to standards seems like a
> > > > > good idea in general.  If I could create multiple virtual interfaces
> > > > > (vifs) on top of a single phyiscal interface (e.g., one vif per
> > > > > neighbor) and subsequently set the interface cost per vif, then would
> > > > > that not comply with the standard and give me the functionality we
> > > > > want/need?
> > > > Even if you could create several interfaces it
> > > > would not do you much good. How would you separate
> > > > the traffic between the interfaces?
> > > > I beleive it to be very difficult.
> > > 
> > > Easy: each vif would have a separate IP address on which traffic could
> > > be demuxed.
> > If you want separate ip adresses in different this
> > should be possible to solve via alias interface.
> > On linux:
> > ifconfig eth0 1.1.1.1 netmask 255.255.255.0
> > ifconfig eth0:1 2.2.2.2 netmask 255.255.255.0
> > though if you wan't them all in the same subnet it
> > would be hard. This was what I assumed but I
> > suppose I'm wrong.
> 
> Yes, IP aliasing is the functionality I was referring to; I want to know
> how to do this in *XORP*.  I don't want to do this in the kernel
> because:
You are going to do it in the kernel whether you
like it or not. XORP merely instructs the kernel
to set up another ip alias. Doing it via XORP is
no different from doing it via ifconfig, iproute2
or something else.
However the example given above does not work.
XORP does not seem to be able to handle alias
interfaces such as eth0:1...
> 
> 1. This is not possible on planetlab.
What is planetlab and why is it not possible?
> 2. Even if it were, I want to configure vifs that correspond to those
>    aliases.  This does not seem possible since the vif name would match the
>    physical interface name.
That was why I proposed the eth0:1 since then
creates another virtual interface, though as
stated above it does not work :/
> 
> Back to my original question and what I am trying to achieve:
> 
> Given one physical interface, can I configure multiple vifs and set an
> interface-cost per vif?  I don't care if all vifs or what have you have
> the same IP address, even, as long as I can set different OSPF interface
> costs for each one.
Vifs are as of today nothing more than internals
to XORP, you can't actually do anything with them.
You have to configure and can only configure _one_
vif per interface and thus to allow what you are
currently looking for ie setting cost per neighbor
you would need several interfaces. This could be
solved in at least two ways:
1. setup alias interfaces (eth0:1)
 As described above, XORP unfortunately does not
 support this :( so you're kinda down to:
2. one VLAN interface to each router
 this is however a pain in the a** since you would
 essentially have to full-mesh your ospf routers
 if you wan't to be able to set cost on each.

you could always tunnel or do something with black
magic... but basically you're full meshing with
vlans or waiting for per-neihbor cost in xorp.

Why is it you want to set different costs per
neighbor?

Hope it helps :)

   Kristian.

From feamster@lcs.mit.edu  Thu Nov 10 17:48:10 2005
From: feamster@lcs.mit.edu (Nick Feamster)
Date: Thu, 10 Nov 2005 12:48:10 -0500
Subject: [Xorp-users] wanted: OSPF metrics per neighbor. can vif help?
In-Reply-To: <20051110170704.GB9551@juniks.net>
References: <feamster@lcs.mit.edu> <20051109222000.GN3791@lcs.mit.edu> <82787.1131580693@tigger.icir.org> <20051110002940.GC5023@lcs.mit.edu> <20051110052503.GC12610@juniks.net> <20051110064804.GN6027@lcs.mit.edu> <20051110161527.GA9551@juniks.net> <20051110163955.GY6027@lcs.mit.edu> <20051110170704.GB9551@juniks.net>
Message-ID: <20051110174810.GD6027@lcs.mit.edu>

On Thu, Nov 10, 2005 at 06:07:04PM +0100, Kristian Larsson wrote:
> You are going to do it in the kernel whether you
> like it or not. XORP merely instructs the kernel
> to set up another ip alias. Doing it via XORP is
> no different from doing it via ifconfig, iproute2
> or something else.

Actually, I am using click for the FEA, so I wouldn't necessarily have
to touch the kernel.

> However the example given above does not work.
> XORP does not seem to be able to handle alias
> interfaces such as eth0:1...

Exactly.  That's the problem I was running into.  One of them, anyway.
:)

> Vifs are as of today nothing more than internals
> to XORP, you can't actually do anything with them.
> You have to configure and can only configure _one_
> vif per interface and thus to allow what you are
> currently looking for ie setting cost per neighbor
> you would need several interfaces. This could be
> solved in at least two ways:
> 1. setup alias interfaces (eth0:1)
>  As described above, XORP unfortunately does not
>  support this :( so you're kinda down to:
> 2. one VLAN interface to each router
>  this is however a pain in the a** since you would
>  essentially have to full-mesh your ospf routers
>  if you wan't to be able to set cost on each.
> 
> you could always tunnel or do something with black
> magic... but basically you're full meshing with
> vlans or waiting for per-neihbor cost in xorp.

OK, great.  That's my understanding, too.  

> Why is it you want to set different costs per
> neighbor?

It's a pretty standard piece of functionality.  Typically, you want to set a
different cost for each edge in a graph: for example, my SF->LA link
should not have the same cost as my SF->NY link.  On a "real" router,
setting a cost per edge can be done by interface, since there is often a
different physical interface for each link (edge in the graph).  That,
of course, is not the case with XORP running on a PC.

Thanks very much for the explanations!

-Nick

From ee05m204@elec.qmul.ac.uk  Thu Nov 10 06:09:54 2005
From: ee05m204@elec.qmul.ac.uk (faradayelec.qmul.ac.uk)
Date: Thu, 10 Nov 2005 14:09:54 +0800
Subject: [Xorp-users] questions about xorpsh
Message-ID: <000901c5e5bd$5f487190$b727258a@Yuan>

This is a multi-part message in MIME format.

------=_NextPart_000_0005_01C5E600.6CCCB270
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: base64

SGk6DQogIEkgYW0gd3JpdGluZyBhIHByb2dyYW0gdGhhdCBhdXRvbWF0ZXMgdGhlIGNvbW1hbmQg
bGluZSB5b3UgcHV0IGluIHhvcnBzaCwgY2FuIHlvdSB0ZWxsIG1lIGhvdyB0aGUgeG9ycHNoIGNv
bW11bmljYXRlIHdpdGggb3RoZXIgc29mdHdhcmU/IEkgY2FuIG5vdCBmaW5kIHRoZSBpbnRlcmZh
Y2UNClRoYW5rcw==

------=_NextPart_000_0005_01C5E600.6CCCB270
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu
dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w
MC4yODAwLjEyMjYiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8
Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj5IaTo8L0ZPTlQ+PC9ESVY+
DQo8RElWPjxGT05UIHNpemU9Mj4mbmJzcDsmbmJzcDtJIGFtIHdyaXRpbmcgYSBwcm9ncmFtIHRo
YXQgYXV0b21hdGVzIHRoZSBjb21tYW5kIA0KbGluZSB5b3UgcHV0IGluIHhvcnBzaCwgY2FuIHlv
dSB0ZWxsIG1lIGhvdyB0aGUgeG9ycHNoIGNvbW11bmljYXRlIHdpdGggb3RoZXIgDQpzb2Z0d2Fy
ZT8gSSBjYW4gbm90IGZpbmQgdGhlIGludGVyZmFjZTwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQg
c2l6ZT0yPlRoYW5rczwvRk9OVD48L0RJVj48L0JPRFk+PC9IVE1MPg0K

------=_NextPart_000_0005_01C5E600.6CCCB270--



From M.Handley@cs.ucl.ac.uk  Fri Nov 11 08:38:43 2005
From: M.Handley@cs.ucl.ac.uk (Mark Handley)
Date: Fri, 11 Nov 2005 08:38:43 +0000
Subject: [Xorp-users] questions about xorpsh
In-Reply-To: <000901c5e5bd$5f487190$b727258a@Yuan>
References: <000901c5e5bd$5f487190$b727258a@Yuan>
Message-ID: <84a612dd0511110038g2189db98ifce5da4caf8f1369@mail.gmail.com>

On 11/10/05, faradayelec.qmul.ac.uk <ee05m204@elec.qmul.ac.uk> wrote:
>
> Hi:
>   I am writing a program that automates the command line you put in xorpsh,
> can you tell me how the xorpsh communicate with other software? I can not
> find the interface

xorpsh has two modes, and they're handled differently.

 - operational mode, where you can monitor the state of the router.
 - configuration mode, where you can change the state of the router.

In operational mode, xorpsh reads xorp/etc/templates/*.cmds to
discover the commands to run to provide feedback to the user.  When
the user types the relevant command, xorpsh directly runs the
corresponding command.  For example, in fea.cmds:

show interfaces $(interfaces.interface.*) {
    %command: "fea/tools/show_interfaces -i $3" %help: HELP;
    %module: interfaces;
    %tag: HELP "Show information about a single network interface";
}

This states that the user can run the command "show interfaces" with
the third parameter taken from the set of configured interfaces:
$(interfaces.interface.*) refers to a set of nodes from the
configuration tree.

The actual program to run to provide the output is fea/tools/show_interfaces
and this command should only be available when the "interfaces" module
has been configured in the xorp configuration.



Configuration mode is much more complex.  To change the config, xorpsh
talks to the rtrmgr.  This process involves a login phase when xorpsh
starts up and authenticates the user to the rtrmgr, then it is sent
the current running config.  If the config changes in future (because
another user changes it), the rtrmgr will send deltas.  If xorpsh
wants to change the config, it sends deltas to the rtrmgr as a single
commit, and the rtrmgr will apply those changes, reconfigure the
routing processes, and report success or failure.

The XRLs by which this communication between rtrmgr and xorpsh takes
place are rtrmgr.xif (implemented by rtrmgr) and rtrmgr_client.xif
(implemented by xorpsh).  You can find these in xorp/xrl/interfaces

Most of this is documented in the rtrmgr design documentation, which
you can get from http://www.xorp.org/design_docs.html

Cheers,
Mark


From riccardo.sciaccaluga@tin.it" <riccardo.sciaccaluga@tin.it  Sat Nov 12 15:39:02 2005
From: riccardo.sciaccaluga@tin.it" <riccardo.sciaccaluga@tin.it (riccardo.sciaccaluga@tin.it)
Date: Sat, 12 Nov 2005 16:39:02 +0100 (GMT+01:00)
Subject: [Xorp-users] Question about ospf protocol implementation on XORP
Message-ID: <29958658.1131809942556.JavaMail.root@pswm1>

Hi
I have been reading all the exchanged mail about establishing ospf 
adiacences but i have a question.
Ospf is supposed to be a link state 
packet routing protocol; this means the protocol is able to build up 
its knowledge about the network topology by itself with hello packets 
exchange so the questiopn is:
Why in the config file sample exchanged 
inside the mail i have been looking at, there is the declaration of the 
neighbours id(adress) for each interface of the router?
Moreover how 
could it be a simple config file just to run ospf protocol on routers 
placed in a simple network topology A<-->B<-->C....i mean how could it 
be a simple config file that let the router exchanging hello packets 
and building up the network topology by themselves?
Thank in advance


From atanu@ICSI.Berkeley.EDU  Sat Nov 12 17:31:18 2005
From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Sat, 12 Nov 2005 09:31:18 -0800
Subject: [Xorp-users] wanted: OSPF metrics per neighbor. can vif help?
In-Reply-To: Message from Nick Feamster <feamster@lcs.mit.edu>
 of "Wed, 09 Nov 2005 19:29:41 EST." <20051110002940.GC5023@lcs.mit.edu>
Message-ID: <85398.1131816678@tigger.icir.org>

Hi,

We have been thinking about the interface-cost configuration change for
the last few days. In your configuration you were able to set the
interface-cost to two separate values but only one of the settings was
used. Your configuration was legal but I have restated it below to show
that all the neighbours belong to a single address block hence only one
interface-cost.
	
          area 0.0.0.0 {
                interface tap0 {
                    link-type: "p2m"
                    vif tap0 {
                       address 10.13.79.1 {
                           interface-cost: 5
                               /* planetlab02.cs.washington.edu */
                               neighbour 10.0.35.1 {
                                    router-id: 128.208.4.198
                               }
                               /* planetlab2.arizona-gigapop.net */
                               neighbour 10.0.10.1 {
                                    router-id: 206.207.248.35
                               }
                        }
                    }
	       }
	  }

At the moment an interface and vif combination can support only one
address, but in the future we may want to support more than one address
per interface. In which case we may want to set interface-cost and other
parameters per address, so we are going to leave the setting where it is
for now.

It seems that the only solution available to you is to add the ability
to change the interface-cost setting per neighbour.

The clean way to add the code is to add a new XRL to set the
interface-cost on a per neighbour basis. The fast hack would be to add
an interface-cost argument to the add_neighbour XRL
(xorp/xrl/interfaces/ospfv2.xif).

Also add the argument in ospf/xrl_target.{cc,hh} then follow the chain
of calls through to the peer code. Store the interface-cost in the
neighbour structure and make sure that the point-to-point and
point-to-multipoint use this interface-cost when building the router
links that go into a Router-LSA.

   Atanu.

>>>>> "Nick" == Nick Feamster <feamster@lcs.mit.edu> writes:

    Nick> Atanu, Thanks for the quick, clear reply.  A few comments
    Nick> inline...

    Nick> On Wed, Nov 09, 2005 at 03:58:13PM -0800, Atanu Ghosh wrote:
    >> The interface-cost is a per interface setting and it was a
    >> mistake in the template file to require it to be set at the
    >> address level. It should be set at the interface level with the
    >> link-type.

    Nick> That makes sense.  Is this fixed in the current CVS version of
    Nick> XORP?

    >> In the OSPF implementation the interface and vif are combined to
    >> form a PeerOut (which is the equivalent of an OSPF
    >> interface). The PeerOut is where the interface-cost is stored.

    Nick> I guess I am confused as to the point of the vif.  It isn't
    Nick> really explained in the user's manual.  Why have it at all if
    Nick> I can't create multiple virtual interfaces with different
    Nick> names on top of a single phyiscal interface?

    >> At the moment the FEA enforces that the interface and vif name
    >> are the same. Which is why you haven't been able to change the
    >> vif name. There have been some discussions on this issue over the
    >> last few days on xorp-hackers.
    >> 
    >> If you can create a separate tap device per neighbour then you
    >> will be able to set the interface cost with the current code.

    Nick> This option presently does not exist, so we are looking for
    Nick> workarounds.

    >> The other option is add code to take the interface cost per
    >> neigbour in a similar manor to the way that the neighbour
    >> router-id is configured. If you make a bugzilla entry requesting
    >> the enhancement and upload the patch that would be useful.
    >> 
    >> >From my reading of the specification all links from a particular
    >> interface should all have the same link cost.
    >> 
    >> ---------------------------------------- RFC 2328 o For each
    >> fully adjacent neighbor associated with the interface, add an
    >> additional Type 1 link (point-to- point) with Link ID set to the
    >> Router ID of the neighboring router, Link Data set to the IP
    >> interface address and cost equal to the interface's configured
    >> output cost.
    >> ----------------------------------------
    >> 
    >> We would be slightly concerned about adding code that may violate
    >> the standard, however, this seems like a useful feature.

    Nick> I understand what the RFC says, and sticking to standards
    Nick> seems like a good idea in general.  If I could create multiple
    Nick> virtual interfaces (vifs) on top of a single phyiscal
    Nick> interface (e.g., one vif per neighbor) and subsequently set
    Nick> the interface cost per vif, then would that not comply with
    Nick> the standard and give me the functionality we want/need?

    Nick> Cheers, Nick

From atanu@ICSI.Berkeley.EDU  Sat Nov 12 17:38:04 2005
From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Sat, 12 Nov 2005 09:38:04 -0800
Subject: [Xorp-users] Question about ospf protocol implementation on XORP
In-Reply-To: Message from "riccardo.sciaccaluga@tin.it" <riccardo.sciaccaluga@tin.it>
 of "Sat, 12 Nov 2005 16:39:02 +0100." <29958658.1131809942556.JavaMail.root@pswm1>
Message-ID: <87030.1131817084@tigger.icir.org>

On media such as ethernet it is possible to discover neighbours because
it is possible to multicast/broadcast packets. Some technologies do not
support multicast/broadcast in which case it is necessary to configure
the neighbour addresses, typically serial interfaces.

    Atanu.

>>>>> "riccardo" == riccardo  <riccardo.sciaccaluga@tin.it> writes:

    riccardo> Hi I have been reading all the exchanged mail about
    riccardo> establishing ospf adiacences but i have a question.  Ospf
    riccardo> is supposed to be a link state packet routing protocol;
    riccardo> this means the protocol is able to build up its knowledge
    riccardo> about the network topology by itself with hello packets
    riccardo> exchange so the questiopn is: Why in the config file
    riccardo> sample exchanged inside the mail i have been looking at,
    riccardo> there is the declaration of the neighbours id(adress) for
    riccardo> each interface of the router?  Moreover how could it be a
    riccardo> simple config file just to run ospf protocol on routers
    riccardo> placed in a simple network topology A<-->B<-->C....i mean
    riccardo> how could it be a simple config file that let the router
    riccardo> exchanging hello packets and building up the network
    riccardo> topology by themselves?  Thank in advance

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

From deathdealer@gmx.net  Sat Nov 12 21:05:03 2005
From: deathdealer@gmx.net (Patrick Preuss)
Date: Sat, 12 Nov 2005 22:05:03 +0100
Subject: AW: [Xorp-users] wanted: OSPF metrics per neighbor. can vif help?
In-Reply-To: <85398.1131816678@tigger.icir.org>
Message-ID: <000b01c5e7cc$c13667c0$1608000a@dedus737>

Hi 

Is this realy defind somewhere in the RFC. I have seen cost only per
interface yet. And for what reason I want to define this for the other peers
on one router as I can configure it on all tree routers so I will have the
difference I need? 

regards
   Patrick Marc   


-----Ursprüngliche Nachricht-----
Von: xorp-users-admin@xorp.org [mailto:xorp-users-admin@xorp.org] Im Auftrag
von Atanu Ghosh
Gesendet: Samstag, 12. November 2005 18:31
An: Nick Feamster
Cc: xorp-users@xorp.org; Andy Bavier; Jennifer Rexford
Betreff: Re: [Xorp-users] wanted: OSPF metrics per neighbor. can vif help? 

Hi,

We have been thinking about the interface-cost configuration change for
the last few days. In your configuration you were able to set the
interface-cost to two separate values but only one of the settings was
used. Your configuration was legal but I have restated it below to show
that all the neighbours belong to a single address block hence only one
interface-cost.
	
          area 0.0.0.0 {
                interface tap0 {
                    link-type: "p2m"
                    vif tap0 {
                       address 10.13.79.1 {
                           interface-cost: 5
                               /* planetlab02.cs.washington.edu */
                               neighbour 10.0.35.1 {
                                    router-id: 128.208.4.198
                               }
                               /* planetlab2.arizona-gigapop.net */
                               neighbour 10.0.10.1 {
                                    router-id: 206.207.248.35
                               }
                        }
                    }
	       }
	  }

At the moment an interface and vif combination can support only one
address, but in the future we may want to support more than one address
per interface. In which case we may want to set interface-cost and other
parameters per address, so we are going to leave the setting where it is
for now.

It seems that the only solution available to you is to add the ability
to change the interface-cost setting per neighbour.

The clean way to add the code is to add a new XRL to set the
interface-cost on a per neighbour basis. The fast hack would be to add
an interface-cost argument to the add_neighbour XRL
(xorp/xrl/interfaces/ospfv2.xif).

Also add the argument in ospf/xrl_target.{cc,hh} then follow the chain
of calls through to the peer code. Store the interface-cost in the
neighbour structure and make sure that the point-to-point and
point-to-multipoint use this interface-cost when building the router
links that go into a Router-LSA.

   Atanu.

>>>>> "Nick" == Nick Feamster <feamster@lcs.mit.edu> writes:

    Nick> Atanu, Thanks for the quick, clear reply.  A few comments
    Nick> inline...

    Nick> On Wed, Nov 09, 2005 at 03:58:13PM -0800, Atanu Ghosh wrote:
    >> The interface-cost is a per interface setting and it was a
    >> mistake in the template file to require it to be set at the
    >> address level. It should be set at the interface level with the
    >> link-type.

    Nick> That makes sense.  Is this fixed in the current CVS version of
    Nick> XORP?

    >> In the OSPF implementation the interface and vif are combined to
    >> form a PeerOut (which is the equivalent of an OSPF
    >> interface). The PeerOut is where the interface-cost is stored.

    Nick> I guess I am confused as to the point of the vif.  It isn't
    Nick> really explained in the user's manual.  Why have it at all if
    Nick> I can't create multiple virtual interfaces with different
    Nick> names on top of a single phyiscal interface?

    >> At the moment the FEA enforces that the interface and vif name
    >> are the same. Which is why you haven't been able to change the
    >> vif name. There have been some discussions on this issue over the
    >> last few days on xorp-hackers.
    >> 
    >> If you can create a separate tap device per neighbour then you
    >> will be able to set the interface cost with the current code.

    Nick> This option presently does not exist, so we are looking for
    Nick> workarounds.

    >> The other option is add code to take the interface cost per
    >> neigbour in a similar manor to the way that the neighbour
    >> router-id is configured. If you make a bugzilla entry requesting
    >> the enhancement and upload the patch that would be useful.
    >> 
    >> >From my reading of the specification all links from a particular
    >> interface should all have the same link cost.
    >> 
    >> ---------------------------------------- RFC 2328 o For each
    >> fully adjacent neighbor associated with the interface, add an
    >> additional Type 1 link (point-to- point) with Link ID set to the
    >> Router ID of the neighboring router, Link Data set to the IP
    >> interface address and cost equal to the interface's configured
    >> output cost.
    >> ----------------------------------------
    >> 
    >> We would be slightly concerned about adding code that may violate
    >> the standard, however, this seems like a useful feature.

    Nick> I understand what the RFC says, and sticking to standards
    Nick> seems like a good idea in general.  If I could create multiple
    Nick> virtual interfaces (vifs) on top of a single phyiscal
    Nick> interface (e.g., one vif per neighbor) and subsequently set
    Nick> the interface cost per vif, then would that not comply with
    Nick> the standard and give me the functionality we want/need?

    Nick> Cheers, Nick
_______________________________________________
Xorp-users mailing list
Xorp-users@xorp.org
http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users





From caddisconsulting@yahoo.com  Sun Nov 13 00:44:16 2005
From: caddisconsulting@yahoo.com (Mike Horn)
Date: Sat, 12 Nov 2005 17:44:16 -0700
Subject: [Bulk] [Xorp-users] Question about ospf protocol implementation on XORP
In-Reply-To: <29958658.1131809942556.JavaMail.root@pswm1>
Message-ID: <200511130044.jAD0iMpE092185@wyvern.icir.org>

Hi Riccardo,

Very good questions, I think you are mixing a few terms.  The fact that OSPF
uses the hello process to discover neighbors does not make it a link-state
routing protocol (RIP also uses hellos for neighbor discovery, but it is a
distance vector routing protocol).  In OSPF once a neighbor is discovered
there is a database exchange, this is how information about the network
topology is initially propogated, not by the hello messages themselves.
What makes OSPF a link-state routing protocol is that each router
contributes to the link-state database and routing updates are event driven
(change in link state) rather than being announce at a fixed interval like
RIP.

You are correct that you should be able to configure 2 XORP routers on a
broadcast network, like Ethernet, and have them automatically discover each
other.  Right now the OSPF code is pretty new, so it's not too surprising if
you are experiencing some issues.  I'll send you some working lab configs
next week.

-mike

-----Original Message-----
From: xorp-users-admin@xorp.org [mailto:xorp-users-admin@xorp.org] On Behalf
Of riccardo.sciaccaluga@tin.it
Sent: Saturday, November 12, 2005 8:39 AM
To: xorp-users@xorp.org
Subject: [Bulk] [Xorp-users] Question about ospf protocol implementation on
XORP

Hi
I have been reading all the exchanged mail about establishing ospf
adiacences but i have a question.
Ospf is supposed to be a link state
packet routing protocol; this means the protocol is able to build up its
knowledge about the network topology by itself with hello packets exchange
so the questiopn is:
Why in the config file sample exchanged inside the mail i have been looking
at, there is the declaration of the neighbours id(adress) for each interface
of the router?
Moreover how
could it be a simple config file just to run ospf protocol on routers placed
in a simple network topology A<-->B<-->C....i mean how could it be a simple
config file that let the router exchanging hello packets and building up the
network topology by themselves?
Thank in advance

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



From riccardo.sciaccaluga@tin.it" <riccardo.sciaccaluga@tin.it  Tue Nov 15 08:12:31 2005
From: riccardo.sciaccaluga@tin.it" <riccardo.sciaccaluga@tin.it (riccardo.sciaccaluga@tin.it)
Date: Tue, 15 Nov 2005 09:12:31 +0100 (GMT+01:00)
Subject: R: RE: [Bulk] [Xorp-users] Question about ospf protocol implementation on XORP
Message-ID: <10816209.1132042351650.JavaMail.root@pswm19.cp.tin.it>

Thanks mike it would be great to have some working lab configs just to 
help me getting use with ospf implementation on xorp.
I am handling my 
thesis on xorp and i specially need to handle ospf protocol so 
everything can help me it's welcome.
Thanks
Andrea

----Messaggio 
originale----
Da: caddisconsulting@yahoo.com
Data: 13-nov-2005 1.44 AM
A: <riccardo.sciaccaluga@tin.it>, <xorp-users@xorp.org>
Ogg: RE: [Bulk] 
[Xorp-users] Question about ospf protocol implementation on XORP

Hi 
Riccardo,

Very good questions, I think you are mixing a few terms.  
The fact that OSPF
uses the hello process to discover neighbors does 
not make it a link-state
routing protocol (RIP also uses hellos for 
neighbor discovery, but it is a
distance vector routing protocol).  In 
OSPF once a neighbor is discovered
there is a database exchange, this 
is how information about the network
topology is initially propogated, 
not by the hello messages themselves.
What makes OSPF a link-state 
routing protocol is that each router
contributes to the link-state 
database and routing updates are event driven
(change in link state) 
rather than being announce at a fixed interval like
RIP.

You are 
correct that you should be able to configure 2 XORP routers on a
broadcast network, like Ethernet, and have them automatically discover 
each
other.  Right now the OSPF code is pretty new, so it's not too 
surprising if
you are experiencing some issues.  I'll send you some 
working lab configs
next week.

-mike

-----Original Message-----
From: 
xorp-users-admin@xorp.org [mailto:xorp-users-admin@xorp.org] On Behalf
Of riccardo.sciaccaluga@tin.it
Sent: Saturday, November 12, 2005 8:39 
AM
To: xorp-users@xorp.org
Subject: [Bulk] [Xorp-users] Question about 
ospf protocol implementation on
XORP

Hi
I have been reading all the 
exchanged mail about establishing ospf
adiacences but i have a 
question.
Ospf is supposed to be a link state
packet routing protocol; 
this means the protocol is able to build up its
knowledge about the 
network topology by itself with hello packets exchange
so the questiopn 
is:
Why in the config file sample exchanged inside the mail i have been 
looking
at, there is the declaration of the neighbours id(adress) for 
each interface
of the router?
Moreover how
could it be a simple config 
file just to run ospf protocol on routers placed
in a simple network 
topology A<-->B<-->C....i mean how could it be a simple
config file 
that let the router exchanging hello packets and building up the
network topology by themselves?
Thank in advance

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


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




From riccardo.sciaccaluga@tin.it" <riccardo.sciaccaluga@tin.it  Wed Nov 16 06:52:28 2005
From: riccardo.sciaccaluga@tin.it" <riccardo.sciaccaluga@tin.it (riccardo.sciaccaluga@tin.it)
Date: Wed, 16 Nov 2005 07:52:28 +0100 (GMT+01:00)
Subject: [Xorp-users] Traffic engeneering
Message-ID: <20286696.1132123948984.JavaMail.root@pswm15.cp.tin.it>

Does the actual ospf development status on xorp support traffing 
engeneering ?
If not will it be implemented soon or not?
Thanks


From kristian@juniks.net  Wed Nov 16 07:27:33 2005
From: kristian@juniks.net (Kristian Larsson)
Date: Wed, 16 Nov 2005 08:27:33 +0100
Subject: [Xorp-users] Traffic engeneering
In-Reply-To: <20286696.1132123948984.JavaMail.root@pswm15.cp.tin.it>
References: <20286696.1132123948984.JavaMail.root@pswm15.cp.tin.it>
Message-ID: <20051116072733.GJ27036@juniks.net>

On Wed, Nov 16, 2005 at 07:52:28AM +0100, riccardo.sciaccaluga@tin.it wrote:
> Does the actual ospf development status on xorp support traffing 
> engeneering ?
Traffic engineering is often done with the use of
mpls which is not currently supported in XORP.
> If not will it be implemented soon or not?
If we're talking MPLS ...
There are experimental MPLS for Linux, none for
*BSD afaik. I'm not sure of it's current state.
When you got a working tag switching mechanism you
need TE extensions to OSPF and this is not one of
the primary goals of XORP right now although I'm
sure it will be implemented eventually.

If you're a hardcore hacker you could always
contribute :)
http://mpls-linux.sourceforge.net/

  Kristian

From caddisconsulting@yahoo.com  Thu Nov 17 16:31:10 2005
From: caddisconsulting@yahoo.com (Mike Horn)
Date: Thu, 17 Nov 2005 09:31:10 -0700
Subject: [Xorp-users] Traceoptions for routing protocols
Message-ID: <200511171631.jAHGVFXE084398@wyvern.icir.org>

This is a multi-part message in MIME format.

------=_NextPart_000_0250_01C5EB59.A5E915E0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Hi all,

I see that there are traceoptions available for multicast specific protocols
(igmp, mld, etc.) but none for other protocols like bgp, rip, etc.  Is this
intentional or am I missing something?

<<< AVAILABLE FOR MLD >>>

rl@DUT-2# create protocols mld ?
Possible completions:
  <[Enter]>       Execute this command
  disable         Disable the MLD protocol
  interface       Configure MLD on a network interface
  targetname      Set the target name
  traceoptions    Configure the tracing options  <--- traceoptions available
for mld
  {               enter text on multiple lines

<<< NOT SHOWN FOR BGP >>>

rl@DUT-2# create protocols bgp ?
Possible completions:
  <[Enter]>       Execute this command
  bgp-id          Set the BGP identifier (must be an IPv4 address)
  export          -- no help available --
  import          -- no help available --
  local-as        Set the Autonomous System (AS) number for this domain
  network4        -- no help available --
  network6        -- no help available --
  peer            Configure a peering session with another router.
  targetname      Set the target name
  {               enter text on multiple lines
rl@DUT-2# create protocols bgp

-mike

Mike Horn
Caddis Consulting




------=_NextPart_000_0250_01C5EB59.A5E915E0
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7036.0">
<TITLE>Traceoptions for routing protocols</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi all,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I see that there are traceoptions =
available for multicast specific protocols (igmp, mld, etc.) but none =
for other protocols like bgp, rip, etc.&nbsp; Is this intentional or am =
I missing something?</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&lt;&lt;&lt; AVAILABLE FOR MLD =
&gt;&gt;&gt;</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">rl@DUT-2# create protocols mld ?</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Possible completions:</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp; =
&lt;[Enter]&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Execute this =
command</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp; =
disable&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Disable the MLD =
protocol</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp; =
interface&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Configure MLD on a network =
interface</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp; =
targetname&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Set the target name</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp; traceoptions&nbsp;&nbsp;&nbsp; =
Configure the tracing options&nbsp; &lt;--- traceoptions available for =
mld</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp; =
{&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; enter text on multiple lines</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&lt;&lt;&lt; NOT SHOWN FOR BGP =
&gt;&gt;&gt;</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">rl@DUT-2# create protocols bgp ?</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Possible completions:</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp; =
&lt;[Enter]&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Execute this =
command</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp; =
bgp-id&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Set the BGP =
identifier (must be an IPv4 address)</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp; =
export&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- no help =
available --</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp; =
import&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- no help =
available --</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp; =
local-as&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Set the Autonomous =
System (AS) number for this domain</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp; =
network4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- no help available =
--</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp; =
network6&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- no help available =
--</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp; =
peer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Configure a peering session with another router.</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp; =
targetname&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Set the target name</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp; =
{&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; enter text on multiple lines</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">rl@DUT-2# create protocols bgp</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">-mike</FONT>
</P>

<P><FONT FACE=3D"Times New Roman">Mike Horn</FONT>

<BR><FONT FACE=3D"Times New Roman">Caddis Consulting</FONT>
</P>
<BR>
<BR>

</BODY>
</HTML>
------=_NextPart_000_0250_01C5EB59.A5E915E0--



From pavlin@icir.org  Fri Nov 18 21:58:02 2005
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Fri, 18 Nov 2005 13:58:02 -0800
Subject: [Xorp-users] Traceoptions for routing protocols
In-Reply-To: Message from "Mike Horn" <caddisconsulting@yahoo.com>
 of "Thu, 17 Nov 2005 09:31:10 MST." <200511171631.jAHGVFXE084398@wyvern.icir.org>
Message-ID: <200511182158.jAILw2a9014370@possum.icir.org>

> I see that there are traceoptions available for multicast specific protocols
> (igmp, mld, etc.) but none for other protocols like bgp, rip, etc.  Is this
> intentional or am I missing something?

This is unintentional. Eventually, in the future all protocols will
have traceoptions. BTW, OSPF also has traceoptions.

Pavlin

> 
> <<< AVAILABLE FOR MLD >>>
> 
> rl@DUT-2# create protocols mld ?
> Possible completions:
>   <[Enter]>       Execute this command
>   disable         Disable the MLD protocol
>   interface       Configure MLD on a network interface
>   targetname      Set the target name
>   traceoptions    Configure the tracing options  <--- traceoptions available
> for mld
>   {               enter text on multiple lines
> 
> <<< NOT SHOWN FOR BGP >>>
> 
> rl@DUT-2# create protocols bgp ?
> Possible completions:
>   <[Enter]>       Execute this command
>   bgp-id          Set the BGP identifier (must be an IPv4 address)
>   export          -- no help available --
>   import          -- no help available --
>   local-as        Set the Autonomous System (AS) number for this domain
>   network4        -- no help available --
>   network6        -- no help available --
>   peer            Configure a peering session with another router.
>   targetname      Set the target name
>   {               enter text on multiple lines
> rl@DUT-2# create protocols bgp

From caddisconsulting@yahoo.com  Mon Nov 21 15:25:58 2005
From: caddisconsulting@yahoo.com (Mike Horn)
Date: Mon, 21 Nov 2005 08:25:58 -0700
Subject: [Xorp-users] OSPF update
In-Reply-To: <20286696.1132123948984.JavaMail.root@pswm15.cp.tin.it>
Message-ID: <200511211526.jALFQ6Ro040592@wyvern.icir.org>

Hi Riccardo,

I didn't want you to think I forgot that I said I would send configurations.
The XORP developers are still doing a lot of great work on the OSPF code, so
make sure you run the latest code.  Below is a sample configuration that
automically discovers neighbors (Cisco routers) and forms a neighbor
adjacency, however there are 2 known issues:

1) the XORP router OSPF process is crashing (see XORP bug 371)
2) if the XORP router is the DR routes are not propogated to neighbors

I think the 2nd issue might be related to multicast issues, but I have not
investigated yet.  Hope this helps!

<<< XORP PROTOCOL CONFIG >>>

rl@DUT-1# show protocols
    ospf4 {
        router-id: 172.16.0.50
        area 25.0.0.0 {
            interface eth0 {
                vif eth0 {
                    address 10.0.0.50 {
                    }
                }
            }
        }
        area 0.0.0.0 {
            interface eth1 {
                vif eth1 {
                    address 172.16.0.50 {
                    }
                }
            }
        }
        export: "REDIST_STATIC"
    }
    static {
        route4 51.0.0.0/8 {
            next-hop: 10.0.0.50
        }
        route4 51.51.0.0/16 {
            next-hop: 172.16.0.50
        }
        route4 51.51.51.0/24 {
            next-hop: 10.0.0.50
        }
    }

[edit]
rl@DUT-1#


<<< XORP COMMANDS >>>

create protocols ospf4 router-id 172.16.0.50
create protocols ospf4 area 25.0.0.0 interface eth0 vif eth0 address
10.0.0.50
create protocols ospf4 area 0.0.0.0 interface eth1 vif eth1 address
172.16.0.50
create policy policy-statement REDIST_STATIC term 10 from protocol static
create policy policy-statement REDIST_STATIC term 10 then accept
create protocols ospf4 export REDIST_STATIC
create protocols static route4 51.0.0.0/8 next-hop 10.0.0.50
create protocols static route4 51.51.0.0/16 next-hop 172.16.0.50
create protocols static route4 51.51.51.0/24 next-hop 10.0.0.50



From Chris.Robson@nrl.navy.mil  Mon Nov 21 18:14:27 2005
From: Chris.Robson@nrl.navy.mil (Chris Robson NRL)
Date: Mon, 21 Nov 2005 13:14:27 -0500
Subject: [Xorp-users] Linux IPv6 PIM SM support
Message-ID: <6.2.1.2.2.20051121130946.021acea0@ginger.cmf.nrl.navy.mil>


What is the current state of fairs with PIM SM support for Linux?  About a 
year ago I did some work with Hoerdt's implementation.  Is this still the 
best route to go?

Thanks for your time....


Christopher L. Robson
GS-1550-NP-IV
(V/C) 202-404-3138
EMAIL: Chris.Robson@nrl.navy.mil
GIG-EF SIP: Chris.Robson@nrl.gigef.net
DoN, NRL, Code 5590
4555 Overlook Ave
Washington, D.C. 20375  


From pavlin@icir.org  Tue Nov 22 02:27:32 2005
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Mon, 21 Nov 2005 18:27:32 -0800
Subject: [Xorp-users] Linux IPv6 PIM SM support
In-Reply-To: Message from Chris Robson NRL <Chris.Robson@nrl.navy.mil>
 of "Mon, 21 Nov 2005 13:14:27 EST." <6.2.1.2.2.20051121130946.021acea0@ginger.cmf.nrl.navy.mil>
Message-ID: <200511220227.jAM2RWKR052987@possum.icir.org>

> What is the current state of fairs with PIM SM support for Linux?  About a 
> year ago I did some work with Hoerdt's implementation.  Is this still the 
> best route to go?

Recently there was a xorp-hackers ML thread about this:
http://mailman.icsi.berkeley.edu/pipermail/xorp-hackers/2005-October/thread.html
[Check the emails with subject "XORP PIMSM6 and IPv6 multicast
forwarding patch"].

To summarize, now the lastest XORP code in CVS can compile with
Hoerdt's IPv6 PIM-SM support for Linux with the caveat that
/usr/include/linux/mroute6.h needs to be installed by hand and
modified a bit. In the following email that is a patch with a quick
hack that comments-out the problematic definitions inside mroute6.h:
http://mailman.icsi.berkeley.edu/pipermail/xorp-hackers/2005-October/000582.html

Myself I was able to start the XORP IPv6 PIM-SM module on a Linux
kernel with the mods, and I could see the IPv6 multicast forwarding
interfaces installed in the kernel, but so far I haven't got the
time to perform more thoughtful tests (forwarding, etc).
FYI, I was using Fedora Core4 with Usagi's snapshot from the end of
October 2005, because the Usagi's tree already includes Hoerdt's
mods.

If you try the Linux IPv6 PIM-SM support, please send a summary of
your experience to the list.

Pavlin

From c-otto@gmx.de  Tue Nov 22 14:49:51 2005
From: c-otto@gmx.de (Carsten Otto)
Date: Tue, 22 Nov 2005 15:49:51 +0100
Subject: [Xorp-users] How to work with a bridge (br0)?
Message-ID: <20051122144951.GB13562@carsten-otto.halifax.rwth-aachen.de>

--AhhlLboLdkugWU4S
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hello!

I am a beginner with xorp, but have read the whole PDF (that does not mean I
understood everything).

I'd like to set up a simple multicast routing environment (details
later). The router in question has three interfaces, where two are
combined to form the bridge br0. The original meaning was to built a
cheap gigabit three-port switch. At the moment one port of the bridge is
not in use, so nothing is connected.

How do I have to setup the interfaces if this bridge is still present?

eth0 has several IPs (ifconfig shows eth0:0 and so on)
eth1 and eth2 are in br0, but have no IP
br0 has one (single) IP

I am not sure what the right thing is, although I did not find any
errors that might be caused by this bridge situation.

Details about the desired multicast routing:

The network connected to eth0 is the whole internet providing PIM-SM and
IGMP (thanks, university). eth1 (or better: br0) is connected to the
internal network. Here the kernel (not xorp) provides basic routing and
packet counting, firewalling, ... Additionally I'd like to route
multicast in both directions. We have several high bandwidth multicast
streams in the internal network that should be passed into the
university if someone needs this data (and not the whole time!).

Some related questions:

1) Is there any way to force xorp to be multicast IGMP querier (v2)? I have
some devices that feel the desire to be the querier, but cannot provide
the necessary bandwith (which is >>100MBit!). So it would be nice to "kick"
those devices out in the election process. At the moment (luckily) a device
is querier that has gigabit, but that was pure luck (I think).

2) [ 2005/11/22 15:40:56 WARNING xorp_fea MFEA ] proto_socket_read()
failed: RX packet from 134.130.49.250 to 224.0.0.1: no vif found

134.130.49.250 is the current IGMP querier in the internal network.
What is needed to handle this warning? Is this bridge-related?
In the network (where the querier resides) there are several multicast
devices in another IP range (that is not routed).

The full configuration can be seen here:
http://home.c-otto.de/xorp.conf.txt

Thanks for any answers,
--=20
Carsten Otto
c-otto@gmx.de
www.c-otto.de

--AhhlLboLdkugWU4S
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDgzAPjUF4jpCSQBQRAq7ZAJ43soiN9qwou/7sepo3lS2eU6fKNQCg7oY4
v0/2Rt62Yz8PrK4DDNnwp20=
=xHfQ
-----END PGP SIGNATURE-----

--AhhlLboLdkugWU4S--

From c-otto@gmx.de  Tue Nov 22 14:56:34 2005
From: c-otto@gmx.de (Carsten Otto)
Date: Tue, 22 Nov 2005 15:56:34 +0100
Subject: [Xorp-users] How to work with a bridge (br0)? (corrected version)
Message-ID: <20051122145634.GH2722@carsten-otto.halifax.rwth-aachen.de>

--X1xGqyAVbSpAWs5A
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

[Sorry, I messed up with the interface description. Now ethN are at the
right places, the problem remains the same]

Hello!

I am a beginner with xorp, but have read the whole PDF (that does not mean I
understood everything).

I'd like to set up a simple multicast routing environment (details
later). The router in question has three interfaces, where two are
combined to form the bridge br0. The original meaning was to built a
cheap gigabit three-port switch. At the moment one port of the bridge is
not in use, so nothing is connected.

How do I have to setup the interfaces if this bridge is still present?

eth0 has several IPs (ifconfig shows eth0:0 and so on)
eth1 and eth2 are in br0, but have no IP
br0 has one (single) IP

I am not sure what the right thing is, although I did not find any
errors that might be caused by this bridge situation.

Details about the desired multicast routing:

The network connected to eth1/br0 is the whole internet providing PIM-SM and
IGMP (thanks, university). eth0 connected to the
internal network. Here the kernel (not xorp) provides basic routing and
packet counting, firewalling, ... Additionally I'd like to route
multicast in both directions. We have several high bandwidth multicast
streams in the internal network that should be passed into the
university if someone needs this data (and not the whole time!).

Some related questions:

1) Is there any way to force xorp to be multicast IGMP querier (v2)? I have
some devices that feel the desire to be the querier, but cannot provide
the necessary bandwith (which is >>100MBit!). So it would be nice to "kick"
those devices out in the election process. At the moment (luckily) a device
is querier that has gigabit, but that was pure luck (I think).

2) [ 2005/11/22 15:40:56 WARNING xorp_fea MFEA ] proto_socket_read()
failed: RX packet from 134.130.49.250 to 224.0.0.1: no vif found

134.130.49.250 is the current IGMP querier in the internal network
(eth0).
What is needed to handle this warning? Is this bridge-related?
In the network (where the querier resides) there are several multicast
devices in another IP range (that is not routed).

The full configuration can be seen here:
http://home.c-otto.de/xorp.conf.txt

Thanks for any answers,
--=20
Carsten Otto
c-otto@gmx.de
www.c-otto.de

--X1xGqyAVbSpAWs5A
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDgzGijUF4jpCSQBQRAu3FAJ4o05Gu5QiBTpUx5CVNCwgEkMhg2QCfSqAm
2+4OTqMnoOyJbJolTeSJbC0=
=n1+9
-----END PGP SIGNATURE-----

--X1xGqyAVbSpAWs5A--

From jwsgong@comcast.net  Tue Nov 22 03:24:55 2005
From: jwsgong@comcast.net (John Gong)
Date: Mon, 21 Nov 2005 19:24:55 -0800
Subject: [Xorp-users] Setting BGP Timers
Message-ID: <575dd371270b1ea9cac01bd433b6b789@comcast.net>

When I perform a
show bgp peers detail in operation mode, I get a display like the 
following:


Peer 1: local 10.1.1.145/179 remote 10.1.1.3/179
   Peer ID: none
   Peer State: IDLE
   Admin State: START
   Negotiated BGP Version: n/a
   Peer AS Number: 100
   Updates Received: 0,  Updates Sent: 0
   Messages Received: 0,  Messages Sent: 0
   Time since last received update: n/a
   Number of transitions to ESTABLISHED: 1
   Time since last in ESTABLISHED state: 20756 seconds
   Retry Interval: 120 seconds
Hold Time: n/a,  Keep Alive Time: n/a
   Configured Hold Time: 120 seconds,  Configured Keep Alive Time: 40 
seconds
Minimum AS Origination Interval: 0 seconds
Minimum Route Advertisement Interval: 0 seconds



I seem to be unable to set the values for the  parameters:  Hold Time, 
Keep Alive Time, Minimum AS Origination Interval and  Minimum Route 
Advertisement Interval.

Is there any way to set them?

TIA,

John


From Chris.Robson@nrl.navy.mil  Tue Nov 22 12:06:13 2005
From: Chris.Robson@nrl.navy.mil (Chris Robson NRL)
Date: Tue, 22 Nov 2005 07:06:13 -0500
Subject: [Xorp-users] Linux IPv6 PIM SM support
In-Reply-To: <200511220227.jAM2RWKR052987@possum.icir.org>
References: <200511220227.jAM2RWKR052987@possum.icir.org>
Message-ID: <6.2.1.2.2.20051122065813.021bd6c8@ginger.cmf.nrl.navy.mil>

Pavlin

This is good news.  However, I am running into some difficulty compiling 
pim6sd-0.1b.  But based on what you just said maybe I should not be using 
this pim release at all.  I have managed to easily integrate the Hoerdt's 
changes into the latest Fedora Core 4 2.6.14-1.1637 updates.  The question 
then is, the pim6sd-0.1b code, is that not required anymore because all the 
PIM SM IPv6 exists in XORP now?  (by-the-by I did pull a CVS release 
yesterday prior to building xorp).

As for summaries, roger on that...........

Thanks for the help.......chris

At 09:27 PM 11/21/2005, Pavlin Radoslavov wrote:
> > What is the current state of fairs with PIM SM support for Linux?  About a
> > year ago I did some work with Hoerdt's implementation.  Is this still the
> > best route to go?
>
>Recently there was a xorp-hackers ML thread about this:
>http://mailman.icsi.berkeley.edu/pipermail/xorp-hackers/2005-October/thread.html
>[Check the emails with subject "XORP PIMSM6 and IPv6 multicast
>forwarding patch"].
>
>To summarize, now the lastest XORP code in CVS can compile with
>Hoerdt's IPv6 PIM-SM support for Linux with the caveat that
>/usr/include/linux/mroute6.h needs to be installed by hand and
>modified a bit. In the following email that is a patch with a quick
>hack that comments-out the problematic definitions inside mroute6.h:
>http://mailman.icsi.berkeley.edu/pipermail/xorp-hackers/2005-October/000582.html
>
>Myself I was able to start the XORP IPv6 PIM-SM module on a Linux
>kernel with the mods, and I could see the IPv6 multicast forwarding
>interfaces installed in the kernel, but so far I haven't got the
>time to perform more thoughtful tests (forwarding, etc).
>FYI, I was using Fedora Core4 with Usagi's snapshot from the end of
>October 2005, because the Usagi's tree already includes Hoerdt's
>mods.
>
>If you try the Linux IPv6 PIM-SM support, please send a summary of
>your experience to the list.
>
>Pavlin
>_______________________________________________
>Xorp-users mailing list
>Xorp-users@xorp.org
>http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users

Christopher L. Robson
GS-1550-NP-IV
(V/C) 202-404-3138
EMAIL: Chris.Robson@nrl.navy.mil
GIG-EF SIP: Chris.Robson@nrl.gigef.net
DoN, NRL, Code 5590
4555 Overlook Ave
Washington, D.C. 20375  


From atanu@ICSI.Berkeley.EDU  Tue Nov 22 18:40:57 2005
From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Tue, 22 Nov 2005 10:40:57 -0800
Subject: [Xorp-users] Setting BGP Timers
In-Reply-To: Message from John Gong <jwsgong@comcast.net>
 of "Mon, 21 Nov 2005 19:24:55 PST." <575dd371270b1ea9cac01bd433b6b789@comcast.net>
Message-ID: <11908.1132684857@tigger.icir.org>

Its possible to set the holdtime on a per peer basis. I believe the
keepalive time is derived from the holdtime and is 1/3 the holdtime.

Minimum AS Origination Interval and Minimum Route Advertisement Interval
can't be set as they assume that the implementation is based on a route
scanner, we should have got this removed from the RFC.

	 Atanu.

>>>>> "John" == John Gong <jwsgong@comcast.net> writes:

    John> When I perform a show bgp peers detail in operation mode, I
    John> get a display like the following:


    John> Peer 1: local 10.1.1.145/179 remote 10.1.1.3/179 Peer ID: none
    John> Peer State: IDLE Admin State: START Negotiated BGP Version:
    John> n/a Peer AS Number: 100 Updates Received: 0, Updates Sent: 0
    John> Messages Received: 0, Messages Sent: 0 Time since last
    John> received update: n/a Number of transitions to ESTABLISHED: 1
    John> Time since last in ESTABLISHED state: 20756 seconds Retry
    John> Interval: 120 seconds Hold Time: n/a, Keep Alive Time: n/a
    John> Configured Hold Time: 120 seconds, Configured Keep Alive Time:
    John> 40 seconds Minimum AS Origination Interval: 0 seconds Minimum
    John> Route Advertisement Interval: 0 seconds



    John> I seem to be unable to set the values for the parameters: Hold
    John> Time, Keep Alive Time, Minimum AS Origination Interval and
    John> Minimum Route Advertisement Interval.

    John> Is there any way to set them?

    John> TIA,

    John> John

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

From pavlin@icir.org  Tue Nov 22 19:05:16 2005
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Tue, 22 Nov 2005 11:05:16 -0800
Subject: [Xorp-users] Linux IPv6 PIM SM support
In-Reply-To: Message from Chris Robson NRL <Chris.Robson@nrl.navy.mil>
 of "Tue, 22 Nov 2005 07:06:13 EST." <6.2.1.2.2.20051122065813.021bd6c8@ginger.cmf.nrl.navy.mil>
Message-ID: <200511221905.jAMJ5Gwp065261@possum.icir.org>

> This is good news.  However, I am running into some difficulty compiling 
> pim6sd-0.1b.  But based on what you just said maybe I should not be using 
> this pim release at all.  I have managed to easily integrate the Hoerdt's 
> changes into the latest Fedora Core 4 2.6.14-1.1637 updates.  The question 
> then is, the pim6sd-0.1b code, is that not required anymore because all the 
> PIM SM IPv6 exists in XORP now?  (by-the-by I did pull a CVS release 
> yesterday prior to building xorp).

Yes, the core PIM-SM IPv6 functionality is included in XORP, so if
you are planning to run XORP then you don't need to run pim6sd as
well.

However, to be fair currently XORP doesn't implement MLDv2 (yet) so
if you have IPv6 SSM receivers, you would have to run pim6sd as the
last-hop routers connected to the receivers (the XORP routers should
be fine as intermediate PIM-SSM routers).

Pavlin


> 
> As for summaries, roger on that...........
> 
> Thanks for the help.......chris
> 
> At 09:27 PM 11/21/2005, Pavlin Radoslavov wrote:
> > > What is the current state of fairs with PIM SM support for Linux?  About a
> > > year ago I did some work with Hoerdt's implementation.  Is this still the
> > > best route to go?
> >
> >Recently there was a xorp-hackers ML thread about this:
> >http://mailman.icsi.berkeley.edu/pipermail/xorp-hackers/2005-October/thread.html
> >[Check the emails with subject "XORP PIMSM6 and IPv6 multicast
> >forwarding patch"].
> >
> >To summarize, now the lastest XORP code in CVS can compile with
> >Hoerdt's IPv6 PIM-SM support for Linux with the caveat that
> >/usr/include/linux/mroute6.h needs to be installed by hand and
> >modified a bit. In the following email that is a patch with a quick
> >hack that comments-out the problematic definitions inside mroute6.h:
> >http://mailman.icsi.berkeley.edu/pipermail/xorp-hackers/2005-October/000582.html
> >
> >Myself I was able to start the XORP IPv6 PIM-SM module on a Linux
> >kernel with the mods, and I could see the IPv6 multicast forwarding
> >interfaces installed in the kernel, but so far I haven't got the
> >time to perform more thoughtful tests (forwarding, etc).
> >FYI, I was using Fedora Core4 with Usagi's snapshot from the end of
> >October 2005, because the Usagi's tree already includes Hoerdt's
> >mods.
> >
> >If you try the Linux IPv6 PIM-SM support, please send a summary of
> >your experience to the list.
> >
> >Pavlin
> >_______________________________________________
> >Xorp-users mailing list
> >Xorp-users@xorp.org
> >http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
> 
> Christopher L. Robson
> GS-1550-NP-IV
> (V/C) 202-404-3138
> EMAIL: Chris.Robson@nrl.navy.mil
> GIG-EF SIP: Chris.Robson@nrl.gigef.net
> DoN, NRL, Code 5590
> 4555 Overlook Ave
> Washington, D.C. 20375  
> 
> _______________________________________________
> Xorp-users mailing list
> Xorp-users@xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From c-otto@gmx.de  Tue Nov 22 19:20:49 2005
From: c-otto@gmx.de (Carsten Otto)
Date: Tue, 22 Nov 2005 20:20:49 +0100
Subject: [Xorp-users] Tiny bit missing
Message-ID: <20051122192049.GB26727@carsten-otto.halifax.rwth-aachen.de>

--PmA2V3Z32TCmWXqI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hello!

I think I managed to configure quite a lot, but something is missing.

I get following messages from the internet:
20:16:31.450654 IP mr-leipzig2.g-win.dfn.de.496 > CISCO-RP-DISCOVERY.MCAST.=
NET.496:  auto-rp mapping Hold 3m RP mr-frankfurt2.g-win.dfn.de PIMv1+2 IET=
F-1-LOW-AUDIO.MCAST.NET/31,IETF-1-VIDEO.MCAST.NET/31,IETF-2-AUDIO.MCAST.NET=
/31,224.0.2.0/23,224.0.4.0/22,224.0.8.0/21[|autorp]

At some state I even managed that this mr-frankfurt node appeared inside
the "show pim rps" table. At the moment my router is elected as RP and
BSR, but the internet does not know this.

In conclusion I am quite confused and don't know exactly what exactly is
missing.
I would be _very_ happy if you point me to the right configuration directiv=
e,
best with Skype (my contact info is "carsten.otto").
ICQ (#13590083) would be nice too.

Thanks a lot,
--=20
Carsten Otto
c-otto@gmx.de
www.c-otto.de

--PmA2V3Z32TCmWXqI
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDg2+RjUF4jpCSQBQRAgm+AKDeAzHwszIwAdPu0sVKHpOcXg7shgCfQRjN
1/5fLkN87QPHO9zH1cQBEFA=
=kBrz
-----END PGP SIGNATURE-----

--PmA2V3Z32TCmWXqI--

From pavlin@icir.org  Tue Nov 22 20:51:32 2005
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Tue, 22 Nov 2005 12:51:32 -0800
Subject: [Xorp-users] How to work with a bridge (br0)? (corrected version)
In-Reply-To: Message from Carsten Otto <c-otto@gmx.de>
 of "Tue, 22 Nov 2005 15:56:34 +0100." <20051122145634.GH2722@carsten-otto.halifax.rwth-aachen.de>
Message-ID: <200511222051.jAMKpWpr066193@possum.icir.org>

> [Sorry, I messed up with the interface description. Now ethN are at the
> right places, the problem remains the same]
> 
> Hello!
> 
> I am a beginner with xorp, but have read the whole PDF (that does not mean I
> understood everything).
> 
> I'd like to set up a simple multicast routing environment (details
> later). The router in question has three interfaces, where two are
> combined to form the bridge br0. The original meaning was to built a
> cheap gigabit three-port switch. At the moment one port of the bridge is
> not in use, so nothing is connected.
> 
> How do I have to setup the interfaces if this bridge is still present?
> 
> eth0 has several IPs (ifconfig shows eth0:0 and so on)

The safest bet is to enable all IP addresses for eth0 by either:
(a) Adding "address" statement for each address in the "interfaces"
section.
OR 
(b) Removing the "vif" statements and using instead the
   "default-system-config" statement per each interface.
BTW, do those IP addresses belong to the same subnet?

> eth1 and eth2 are in br0, but have no IP
> br0 has one (single) IP
> 
> I am not sure what the right thing is, although I did not find any
> errors that might be caused by this bridge situation.

It looks like the setup is OK, but if you want to be sure there are
no issues, then I'd recommend to perform the following test:

1. Configure the XORP router to be the RP for some particular group
   range. The simplest way to do it is to use the "static-rps"
   statement.
2. Start receivers directly connected to each of the
   interfaces/segments: eth0, eth1, eth2.
3. Start a sender on each of the interfaces/segments (eth0, eth1,
   eth2) and verify that the receivers receive the data.

> Details about the desired multicast routing:
> 
> The network connected to eth1/br0 is the whole internet providing PIM-SM and
> IGMP (thanks, university). eth0 connected to the
> internal network. Here the kernel (not xorp) provides basic routing and
> packet counting, firewalling, ... Additionally I'd like to route
> multicast in both directions. We have several high bandwidth multicast
> streams in the internal network that should be passed into the
> university if someone needs this data (and not the whole time!).
> 
> Some related questions:
> 
> 1) Is there any way to force xorp to be multicast IGMP querier (v2)? I have
> some devices that feel the desire to be the querier, but cannot provide
> the necessary bandwith (which is >>100MBit!). So it would be nice to "kick"
> those devices out in the election process. At the moment (luckily) a device
> is querier that has gigabit, but that was pure luck (I think).

I'd say that you don't need to worry who is the IGMP querier,
because if a router is a querier it does not mean it will be the one
responsible for forwarding the multicast traffic.
At the PIM-SM level for example, you may care who is the DR
(Designated Router) on the LAN and you can affect that decision by
using the dr-priority statement per vif (inside the pimsm4
configuration block).
BTW, you cannot change who the IGMP querier is, because the election
is purely based on the IP address, and the IGMP protocol does not
provide priority-based election support.

> 2) [ 2005/11/22 15:40:56 WARNING xorp_fea MFEA ] proto_socket_read()
> failed: RX packet from 134.130.49.250 to 224.0.0.1: no vif found
>
> 134.130.49.250 is the current IGMP querier in the internal network
> (eth0).
> What is needed to handle this warning? Is this bridge-related?
> In the network (where the querier resides) there are several multicast
> devices in another IP range (that is not routed).

You should configure (inside XORP) the corresponding interface that
is directly connected to 134.130.49.250 with the corresponding IP
address that shares same subnet with 134.130.49.250 (see the first
paragraph in my reply with the (a)-(b) options).

> 
> The full configuration can be seen here:
> http://home.c-otto.de/xorp.conf.txt

You need to enable fib2mrib as well:

protocols {
    fib2mrib {
        disable: false
    }
}


Pavlin

From pavlin@icir.org  Tue Nov 22 21:09:36 2005
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Tue, 22 Nov 2005 13:09:36 -0800
Subject: [Xorp-users] Tiny bit missing
In-Reply-To: Message from Carsten Otto <c-otto@gmx.de>
 of "Tue, 22 Nov 2005 20:20:49 +0100." <20051122192049.GB26727@carsten-otto.halifax.rwth-aachen.de>
Message-ID: <200511222109.jAML9afR066294@possum.icir.org>

> I think I managed to configure quite a lot, but something is missing.
> 
> I get following messages from the internet:
> 20:16:31.450654 IP mr-leipzig2.g-win.dfn.de.496 > CISCO-RP-DISCOVERY.MCAST.=
> NET.496:  auto-rp mapping Hold 3m RP mr-frankfurt2.g-win.dfn.de PIMv1+2 IET=
> F-1-LOW-AUDIO.MCAST.NET/31,IETF-1-VIDEO.MCAST.NET/31,IETF-2-AUDIO.MCAST.NET=
> /31,224.0.2.0/23,224.0.4.0/22,224.0.8.0/21[|autorp]
> 
> At some state I even managed that this mr-frankfurt node appeared inside
> the "show pim rps" table. At the moment my router is elected as RP and
> BSR, but the internet does not know this.

It looks like your PIM-SM domain is using the Auto-RP mechanism to
propagate the RP-Set.
This mechanism is Cisco-specific and there is no RFC (or even an
Internet-Draft) that describes it.

XORP supports the following two mechanisms for
propagating/configuring the RP-Set: the Bootstrap mechanism, and
Static RPs.
If the rest of the network is not running the Bootstrap mechanism,
then you shouldn't use it either, because the main point of using
it is that all PIM-SM routers will have the same Cand-RP set.
Even if the rest of your network is using the Bootstrap mechanism,
in your case it would be safer if you don't configure your XORP
router as a Candidate-BSR or a Candidate-RP, unless you have good
reasons for that.

If you cannot convince the network admins to switch from Auto-RP to
the Bootstrap mechanism, then I am afraid you have to configure all
RPs in your XORP router using the static-rps mechanism.
For that you have to collect all rp-to-group mapping information, as
well as the rp-priority for each mapping entry. If the auto-rp
packets don't carry any rp-priority field, you can ignore the
priority in your config.

Then you have to add all rp-to-group mapping to the "static-rps"
configuration section: inside static-rps you can have multiple "rp"
statements (one per each RP), and you can have multiple
"group-prefix" statements per each RP.

Of course, if the Auto-RP mapping changes, then you have to update
immediately your static RP configuration.

If you feel creativite then you can write some script that uses
tcpdump to receive and decode the auto-rp control packets, and then
writes the corresponding static-rps XORP configuration.
If the configuration has changed, then the same script can invoke
xorpsh to reconfigure XORP on-the-fly with the new mapping.

Pavlin

> 
> In conclusion I am quite confused and don't know exactly what exactly is
> missing.
> I would be _very_ happy if you point me to the right configuration directiv=
> e,
> best with Skype (my contact info is "carsten.otto").
> ICQ (#13590083) would be nice too.
> 
> Thanks a lot,
> --=20
> Carsten Otto
> c-otto@gmx.de
> www.c-otto.de
> 
> --PmA2V3Z32TCmWXqI
> Content-Type: application/pgp-signature
> Content-Disposition: inline
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
> 
> iD8DBQFDg2+RjUF4jpCSQBQRAgm+AKDeAzHwszIwAdPu0sVKHpOcXg7shgCfQRjN
> 1/5fLkN87QPHO9zH1cQBEFA=
> =kBrz
> -----END PGP SIGNATURE-----
> 
> --PmA2V3Z32TCmWXqI--
> _______________________________________________
> Xorp-users mailing list
> Xorp-users@xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From Chris.Robson@nrl.navy.mil  Tue Nov 22 18:44:53 2005
From: Chris.Robson@nrl.navy.mil (Chris Robson NRL)
Date: Tue, 22 Nov 2005 13:44:53 -0500
Subject: [Xorp-users] Help with errors when starting up Xorp
Message-ID: <6.2.1.2.2.20051122133812.021c3220@ginger.cmf.nrl.navy.mil>

Everything runs but these 2 errors dump when I start XORP.  Any idea what 
this is?

[ 2005/11/22 11:56:53  WARNING xorp_rtrmgr:4296 XrlFinderTarget +406 
../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling 
method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed 
Target "PIMSM_4" does not exist or is not enabled

[ 2005/11/22 11:56:51  WARNING xorp_rtrmgr:4296 XrlFinderTarget +406 
../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling 
method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed 
Target "IGMP" does not exist or is not enabled





Christopher L. Robson
GS-1550-NP-IV
(V/C) 202-404-3138
EMAIL: Chris.Robson@nrl.navy.mil
GIG-EF SIP: Chris.Robson@nrl.gigef.net
DoN, NRL, Code 5590
4555 Overlook Ave
Washington, D.C. 20375  


From pavlin@icir.org  Wed Nov 23 01:18:29 2005
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Tue, 22 Nov 2005 17:18:29 -0800
Subject: [Xorp-users] Help with errors when starting up Xorp
In-Reply-To: Message from Chris Robson NRL <Chris.Robson@nrl.navy.mil>
 of "Tue, 22 Nov 2005 13:44:53 EST." <6.2.1.2.2.20051122133812.021c3220@ginger.cmf.nrl.navy.mil>
Message-ID: <200511230118.jAN1ITpG069367@possum.icir.org>

> Everything runs but these 2 errors dump when I start XORP.  Any idea what 
> this is?
> 
> [ 2005/11/22 11:56:53  WARNING xorp_rtrmgr:4296 XrlFinderTarget +406 
> ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling 
> method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed 
> Target "PIMSM_4" does not exist or is not enabled
> 
> [ 2005/11/22 11:56:51  WARNING xorp_rtrmgr:4296 XrlFinderTarget +406 
> ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling 
> method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed 
> Target "IGMP" does not exist or is not enabled

This is normal if there are 1-2 such errors (per module). Those are
transient errors during startup only (and eventually during
shutdown).

Only if you see many periodic errors like those above, then this
could be an issue.

Pavlin

From c-otto@gmx.de  Wed Nov 23 13:12:12 2005
From: c-otto@gmx.de (Carsten Otto)
Date: Wed, 23 Nov 2005 14:12:12 +0100
Subject: [Xorp-users] Tiny bit missing
In-Reply-To: <200511222109.jAML9afR066294@possum.icir.org>
References: <20051122192049.GB26727@carsten-otto.halifax.rwth-aachen.de> <200511222109.jAML9afR066294@possum.icir.org>
Message-ID: <20051123131212.GA655@carsten-otto.halifax.rwth-aachen.de>

--k1lZvvs/B4yU6o8G
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Nov 22, 2005 at 01:09:36PM -0800, Pavlin Radoslavov wrote:
> XORP supports the following two mechanisms for
> propagating/configuring the RP-Set: the Bootstrap mechanism, and
> Static RPs.
> If the rest of the network is not running the Bootstrap mechanism,
> then you shouldn't use it either, because the main point of using
> it is that all PIM-SM routers will have the same Cand-RP set.
> Even if the rest of your network is using the Bootstrap mechanism,
> in your case it would be safer if you don't configure your XORP
> router as a Candidate-BSR or a Candidate-RP, unless you have good
> reasons for that.

I managed to get it to work by using an old configuration from the
beginnings of this mailing list. I did not use a static RP or bootstrap.
--=20
Carsten Otto
c-otto@gmx.de
www.c-otto.de

--k1lZvvs/B4yU6o8G
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDhGqsjUF4jpCSQBQRAk/tAKCp8PKGjwSlBq2O+/TQWE9B47mxNwCaA6eD
pyw+u8CzRDm/WdApZZMGQEU=
=9ljj
-----END PGP SIGNATURE-----

--k1lZvvs/B4yU6o8G--

From pavlin@icir.org  Wed Nov 23 17:55:38 2005
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Wed, 23 Nov 2005 09:55:38 -0800
Subject: [Xorp-users] Tiny bit missing
In-Reply-To: Message from Carsten Otto <c-otto@gmx.de>
 of "Wed, 23 Nov 2005 14:12:12 +0100." <20051123131212.GA655@carsten-otto.halifax.rwth-aachen.de>
Message-ID: <200511231755.jANHtcMA002194@possum.icir.org>

> > XORP supports the following two mechanisms for
> > propagating/configuring the RP-Set: the Bootstrap mechanism, and
> > Static RPs.
> > If the rest of the network is not running the Bootstrap mechanism,
> > then you shouldn't use it either, because the main point of using
> > it is that all PIM-SM routers will have the same Cand-RP set.
> > Even if the rest of your network is using the Bootstrap mechanism,
> > in your case it would be safer if you don't configure your XORP
> > router as a Candidate-BSR or a Candidate-RP, unless you have good
> > reasons for that.
> 
> I managed to get it to work by using an old configuration from the
> beginnings of this mailing list. I did not use a static RP or bootstrap.

FYI, even if your configuration doesn't contain the "bootstrap"
section, your XORP PIM-SM router will still listen for and accept
the Bootstrap messages.

Hence, I guess after all your PIM-SM domain has been configured to
use the Bootstrap mechanism: you should see the received bootstrap
info by the "show pim bootstrap" xorpsh command.
If the output of this command is empty, then I am very curious where
the Cand-RP info is coming from ("show pim rps" should be not empty
after all), and what particular "old configuration" you are using.

Pavlin

From Chris.Robson@nrl.navy.mil  Wed Nov 23 13:55:57 2005
From: Chris.Robson@nrl.navy.mil (Chris Robson NRL)
Date: Wed, 23 Nov 2005 08:55:57 -0500
Subject: [Xorp-users] Help with errors when starting up Xorp
In-Reply-To: <200511230118.jAN1ITpG069367@possum.icir.org>
References: <200511230118.jAN1ITpG069367@possum.icir.org>
Message-ID: <6.2.1.2.2.20051123085013.021c0b60@ginger.cmf.nrl.navy.mil>

Hi Pavlin

still plugging away here trying to get XORP PIM working on a Fedora Core 4 
Kernel 2.6.14-1.1637 working.  I had to make some manual modifications to 
Hoerdt modified files which I will relay later to you.  But should I be 
concerned about these warnings?  By-the-by, which Hoerdt patch are you 
using 1a, 1b, 1c or 1d?  And just an FYI, we'll be testing this once we get 
a working PIM over a 6VPE (IPv6-Over-IPv4-MPLS) backbone.  thanks for the help

./configure output ........
configure: WARNING: linux/rtnetlink.h: present but cannot be compiled
configure: WARNING: linux/rtnetlink.h: check for missing prerequisite headers?
configure: WARNING: linux/rtnetlink.h: proceeding with the preprocessor's 
result
checking for linux/rtnetlink.h... yes
checking linux/types.h usability... yes
checking linux/types.h presence... yes
checking for linux/types.h... yes
checking linux/sockios.h usability... yes
checking linux/sockios.h presence... yes
checking for linux/sockios.h... yes
checking linux/mroute6.h usability... no
checking linux/mroute6.h presence... yes
configure: WARNING: linux/mroute6.h: present but cannot be compiled
configure: WARNING: linux/mroute6.h: check for missing prerequisite headers?
configure: WARNING: linux/mroute6.h: proceeding with the preprocessor's result
checking for linux/mroute6.h... yes


At 08:18 PM 11/22/2005, Pavlin Radoslavov wrote:
> > Everything runs but these 2 errors dump when I start XORP.  Any idea what
> > this is?
> >
> > [ 2005/11/22 11:56:53  WARNING xorp_rtrmgr:4296 XrlFinderTarget +406
> > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling
> > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed
> > Target "PIMSM_4" does not exist or is not enabled
> >
> > [ 2005/11/22 11:56:51  WARNING xorp_rtrmgr:4296 XrlFinderTarget +406
> > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling
> > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed
> > Target "IGMP" does not exist or is not enabled
>
>This is normal if there are 1-2 such errors (per module). Those are
>transient errors during startup only (and eventually during
>shutdown).
>
>Only if you see many periodic errors like those above, then this
>could be an issue.
>
>Pavlin

Christopher L. Robson
GS-1550-NP-IV
(V/C) 202-404-3138
EMAIL: Chris.Robson@nrl.navy.mil
GIG-EF SIP: Chris.Robson@nrl.gigef.net
DoN, NRL, Code 5590
4555 Overlook Ave
Washington, D.C. 20375  


From pavlin@icir.org  Wed Nov 23 18:14:07 2005
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Wed, 23 Nov 2005 10:14:07 -0800
Subject: [Xorp-users] Help with errors when starting up Xorp
In-Reply-To: Message from Chris Robson NRL <Chris.Robson@nrl.navy.mil>
 of "Wed, 23 Nov 2005 08:55:57 EST." <6.2.1.2.2.20051123085013.021c0b60@ginger.cmf.nrl.navy.mil>
Message-ID: <200511231814.jANIE7qq002373@possum.icir.org>

> still plugging away here trying to get XORP PIM working on a Fedora Core 4 
> Kernel 2.6.14-1.1637 working.  I had to make some manual modifications to 
> Hoerdt modified files which I will relay later to you.  But should I be 
> concerned about these warnings?  By-the-by, which Hoerdt patch are you 

No, you can safely ignore those warnings.

> using 1a, 1b, 1c or 1d?  And just an FYI, we'll be testing this once we get 
> a working PIM over a 6VPE (IPv6-Over-IPv4-MPLS) backbone.  thanks for the help

I am using the USAGI 2.6.14-rc5 kernel (from the end of October 2005
snapshot) which already contains Hoerdt's patch:
http://www.linux-ipv6.org/

I cannot say with sure which version is in the USAGI tree, but based
on the 1d's timestamp and the USAGI's integration date I believe it
contains the lastest 1d patch.

Pavlin

> 
> ./configure output ........
> configure: WARNING: linux/rtnetlink.h: present but cannot be compiled
> configure: WARNING: linux/rtnetlink.h: check for missing prerequisite headers?
> configure: WARNING: linux/rtnetlink.h: proceeding with the preprocessor's 
> result
> checking for linux/rtnetlink.h... yes
> checking linux/types.h usability... yes
> checking linux/types.h presence... yes
> checking for linux/types.h... yes
> checking linux/sockios.h usability... yes
> checking linux/sockios.h presence... yes
> checking for linux/sockios.h... yes
> checking linux/mroute6.h usability... no
> checking linux/mroute6.h presence... yes
> configure: WARNING: linux/mroute6.h: present but cannot be compiled
> configure: WARNING: linux/mroute6.h: check for missing prerequisite headers?
> configure: WARNING: linux/mroute6.h: proceeding with the preprocessor's result
> checking for linux/mroute6.h... yes
> 
> 
> At 08:18 PM 11/22/2005, Pavlin Radoslavov wrote:
> > > Everything runs but these 2 errors dump when I start XORP.  Any idea what
> > > this is?
> > >
> > > [ 2005/11/22 11:56:53  WARNING xorp_rtrmgr:4296 XrlFinderTarget +406
> > > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling
> > > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed
> > > Target "PIMSM_4" does not exist or is not enabled
> > >
> > > [ 2005/11/22 11:56:51  WARNING xorp_rtrmgr:4296 XrlFinderTarget +406
> > > ../xrl/targets/finder_base.cc handle_finder_0_2_resolve_xrl ] Handling
> > > method for finder/0.2/resolve_xrl failed: XrlCmdError 102 Command failed
> > > Target "IGMP" does not exist or is not enabled
> >
> >This is normal if there are 1-2 such errors (per module). Those are
> >transient errors during startup only (and eventually during
> >shutdown).
> >
> >Only if you see many periodic errors like those above, then this
> >could be an issue.
> >
> >Pavlin
> 
> Christopher L. Robson
> GS-1550-NP-IV
> (V/C) 202-404-3138
> EMAIL: Chris.Robson@nrl.navy.mil
> GIG-EF SIP: Chris.Robson@nrl.gigef.net
> DoN, NRL, Code 5590
> 4555 Overlook Ave
> Washington, D.C. 20375  
> 
> _______________________________________________
> Xorp-users mailing list
> Xorp-users@xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


From c-otto@gmx.de  Wed Nov 23 19:40:56 2005
From: c-otto@gmx.de (Carsten Otto)
Date: Wed, 23 Nov 2005 20:40:56 +0100
Subject: [Xorp-users] Tiny bit missing
In-Reply-To: <200511231755.jANHtcMA002194@possum.icir.org>
References: <20051123131212.GA655@carsten-otto.halifax.rwth-aachen.de> <200511231755.jANHtcMA002194@possum.icir.org>
Message-ID: <20051123194056.GC655@carsten-otto.halifax.rwth-aachen.de>

--yVhtmJPUSI46BTXb
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Nov 23, 2005 at 09:55:38AM -0800, Pavlin Radoslavov wrote:
> FYI, even if your configuration doesn't contain the "bootstrap"
> section, your XORP PIM-SM router will still listen for and accept
> the Bootstrap messages.

Right.

> Hence, I guess after all your PIM-SM domain has been configured to
> use the Bootstrap mechanism: you should see the received bootstrap
> info by the "show pim bootstrap" xorpsh command.
> If the output of this command is empty, then I am very curious where
> the Cand-RP info is coming from ("show pim rps" should be not empty
> after all), and what particular "old configuration" you are using.

Active zones:
BSR             Pri LocalAddress    Pri State           Timeout SZTimeout
188.1.42.50       0 0.0.0.0           0 AcceptPreferred     122 1292
Expiring zones:
BSR             Pri LocalAddress    Pri State           Timeout SZTimeout
Configured zones:
BSR             Pri LocalAddress    Pri State           Timeout SZTimeout
0.0.0.0           0 0.0.0.0           0 Init                 -1 -1
--=20
Carsten Otto
c-otto@gmx.de
www.c-otto.de

--yVhtmJPUSI46BTXb
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDhMXIjUF4jpCSQBQRAhxRAJ9q0Q/fIgoxwfbAYLT9ZR+FEFkCiwCffT3a
iiVfT6s6tywVfvLJU92O66Y=
=RFZk
-----END PGP SIGNATURE-----

--yVhtmJPUSI46BTXb--

From pavlin@icir.org  Wed Nov 23 20:06:32 2005
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Wed, 23 Nov 2005 12:06:32 -0800
Subject: [Xorp-users] Tiny bit missing
In-Reply-To: Message from Carsten Otto <c-otto@gmx.de>
 of "Wed, 23 Nov 2005 20:40:56 +0100." <20051123194056.GC655@carsten-otto.halifax.rwth-aachen.de>
Message-ID: <200511232006.jANK6WXm007395@possum.icir.org>

> Active zones:
> BSR             Pri LocalAddress    Pri State           Timeout SZTimeout
> 188.1.42.50       0 0.0.0.0           0 AcceptPreferred     122 1292
> Expiring zones:
> BSR             Pri LocalAddress    Pri State           Timeout SZTimeout
> Configured zones:
> BSR             Pri LocalAddress    Pri State           Timeout SZTimeout
> 0.0.0.0           0 0.0.0.0           0 Init                 -1 -1

This "0.0.0.0" configured zone with 0.0.0.0 local BSR address looks
like a misconfiguration to me.
Is your "bootstrap" section really empty? If yes, are you running
XORP-1.1 or the lastest code from CVS?

Pavlin

From c-otto@gmx.de  Wed Nov 23 20:21:09 2005
From: c-otto@gmx.de (Carsten Otto)
Date: Wed, 23 Nov 2005 21:21:09 +0100
Subject: [Xorp-users] Tiny bit missing
In-Reply-To: <200511232006.jANK6WXm007395@possum.icir.org>
References: <20051123194056.GC655@carsten-otto.halifax.rwth-aachen.de> <200511232006.jANK6WXm007395@possum.icir.org>
Message-ID: <20051123202109.GA29815@carsten-otto.halifax.rwth-aachen.de>

--qDbXVdCdHGoSgWSk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Nov 23, 2005 at 12:06:32PM -0800, Pavlin Radoslavov wrote:
> This "0.0.0.0" configured zone with 0.0.0.0 local BSR address looks
> like a misconfiguration to me.

Right. This disappeared after a crash/restart.

> Is your "bootstrap" section really empty? If yes, are you running
> XORP-1.1 or the lastest code from CVS?

CVS from yesterday.
--=20
Carsten Otto
c-otto@gmx.de
www.c-otto.de

--qDbXVdCdHGoSgWSk
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDhM81jUF4jpCSQBQRAqgHAJ97hp7C5trKxW+P+fvTb7uY7Dw0EACfeZv3
8gds6yCP0C8MUVnsbKL5H/s=
=PgVx
-----END PGP SIGNATURE-----

--qDbXVdCdHGoSgWSk--

From c-otto@gmx.de  Wed Nov 23 20:57:46 2005
From: c-otto@gmx.de (Carsten Otto)
Date: Wed, 23 Nov 2005 21:57:46 +0100
Subject: [Xorp-users] How to work with a bridge (br0)? (corrected version)
In-Reply-To: <200511222051.jAMKpWpr066193@possum.icir.org>
References: <20051122145634.GH2722@carsten-otto.halifax.rwth-aachen.de> <200511222051.jAMKpWpr066193@possum.icir.org>
Message-ID: <20051123205746.GB29815@carsten-otto.halifax.rwth-aachen.de>

--gj572EiMnwbLXET9
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Nov 22, 2005 at 12:51:32PM -0800, Pavlin Radoslavov wrote:
> 1. Configure the XORP router to be the RP for some particular group
>    range. The simplest way to do it is to use the "static-rps"
>    statement.
> 2. Start receivers directly connected to each of the
>    interfaces/segments: eth0, eth1, eth2.
> 3. Start a sender on each of the interfaces/segments (eth0, eth1,
>    eth2) and verify that the receivers receive the data.

What address should I enter as RP? Which of my own? I am confused.

The current (best) result is following:

1) Sender is inside the local network
2) This PC sends SAP announcements and data
3) SAP announcements can be seen university-wide
4) Data cannot be seen
5) Data sent to the SAP address (sap.mcast.net) can be seen (works
flawlessly!)

So I am quite confused. I think my xorp configuration is quite OK by
now. Sending works (with that address) and receiving works with all
addresses. Sending from the outer network (so next to xorp's external
interface) does not work with normal addresses - just the same as from
inside.

Should I ask my university? My university's provider? Is my
configuration incorrect? Am I using the wrong addresses? I tried
several, including 233.x.y.z where x and y are derived from my
university's AS number.

> I'd say that you don't need to worry who is the IGMP querier,
> because if a router is a querier it does not mean it will be the one
> responsible for forwarding the multicast traffic.
> At the PIM-SM level for example, you may care who is the DR
> (Designated Router) on the LAN and you can affect that decision by
> using the dr-priority statement per vif (inside the pimsm4
> configuration block).
> BTW, you cannot change who the IGMP querier is, because the election
> is purely based on the IP address, and the IGMP protocol does not
> provide priority-based election support.

Good.

> You should configure (inside XORP) the corresponding interface that
> is directly connected to 134.130.49.250 with the corresponding IP
> address that shares same subnet with 134.130.49.250 (see the first
> paragraph in my reply with the (a)-(b) options).

That problem is resolved.
--=20
Carsten Otto
c-otto@gmx.de
www.c-otto.de

--gj572EiMnwbLXET9
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDhNfKjUF4jpCSQBQRAs+DAJ0Z5WjeouXurJ3tMM6kp//oy07xpwCeILP4
IENa84XhHgRnZaXcUazr1kE=
=+PDt
-----END PGP SIGNATURE-----

--gj572EiMnwbLXET9--

From pavlin@icir.org  Wed Nov 23 21:12:55 2005
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Wed, 23 Nov 2005 13:12:55 -0800
Subject: [Xorp-users] How to work with a bridge (br0)? (corrected version)
In-Reply-To: Message from Carsten Otto <c-otto@gmx.de>
 of "Wed, 23 Nov 2005 21:57:46 +0100." <20051123205746.GB29815@carsten-otto.halifax.rwth-aachen.de>
Message-ID: <200511232112.jANLCtJ7010331@possum.icir.org>

> > 1. Configure the XORP router to be the RP for some particular group
> >    range. The simplest way to do it is to use the "static-rps"
> >    statement.
> > 2. Start receivers directly connected to each of the
> >    interfaces/segments: eth0, eth1, eth2.
> > 3. Start a sender on each of the interfaces/segments (eth0, eth1,
> >    eth2) and verify that the receivers receive the data.
> 
> What address should I enter as RP? Which of my own? I am confused.

It shouldn't matter which of your RP addresses you will enter.
Note that the whole purpose of the above test is to verify that you
send and receive across the XORP router. However, from your email
below it looks like you can perform a similar test using
senders/receivers spread across your domain so you can skip the test
I suggested.

> The current (best) result is following:
> 
> 1) Sender is inside the local network
> 2) This PC sends SAP announcements and data
> 3) SAP announcements can be seen university-wide
> 4) Data cannot be seen
> 5) Data sent to the SAP address (sap.mcast.net) can be seen (works
> flawlessly!)

Before doing anything, first double-check that the TTL of the data
is large enough, because the default multicast TTL is 1.

Then check the MFC entries ("show pim mfc") whether there is a
matching entry for your PC/sender and the group address for the
data that is missing. You could double-check by running the UNIX
"cat /proc/net/ip_mr_cache" command to see what exactly is installed
in the kernel.

If there is an entry, check that the iif and the oifs are
correct. If they are correct, then run tcpdump on one of the
expected outgoing interface and see whether the data is coming out
on that interface.
If there is no MFC entry, then use the "show pim join" command to
check what is the status of the corresponding (S,G) entry for this
directly connected source.

Further debugging of the problem will depend on the above results.

Pavlin

> 
> So I am quite confused. I think my xorp configuration is quite OK by
> now. Sending works (with that address) and receiving works with all
> addresses. Sending from the outer network (so next to xorp's external
> interface) does not work with normal addresses - just the same as from
> inside.
> 
> Should I ask my university? My university's provider? Is my
> configuration incorrect? Am I using the wrong addresses? I tried
> several, including 233.x.y.z where x and y are derived from my
> university's AS number.

From c-otto@gmx.de  Thu Nov 24 00:12:18 2005
From: c-otto@gmx.de (Carsten Otto)
Date: Thu, 24 Nov 2005 01:12:18 +0100
Subject: [Xorp-users] How to work with a bridge (br0)? (corrected version)
In-Reply-To: <200511232112.jANLCtJ7010331@possum.icir.org>
References: <20051123205746.GB29815@carsten-otto.halifax.rwth-aachen.de> <200511232112.jANLCtJ7010331@possum.icir.org>
Message-ID: <20051124001218.GA2307@carsten-otto.halifax.rwth-aachen.de>

--KsGdsel6WgEHnImy
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

First of all:

I noticed some (not several, but more than one) crashes in the last few
hours. xorp_rtrmgr does not react on ctrl+c and multicast routing is
stopped (I can't see any entries in my SAP list). Any ideas?

On Wed, Nov 23, 2005 at 01:12:55PM -0800, Pavlin Radoslavov wrote:
> Before doing anything, first double-check that the TTL of the data
> is large enough, because the default multicast TTL is 1.

Everything is set to 7. The university admin assured that the router in
question (next hop) drops packets with TTL < 8 on their way out into the
rest of the university and inside this router (to other dorms)
everything should work. PS: I doublechecked :)

> Then check the MFC entries ("show pim mfc") whether there is a
> matching entry for your PC/sender and the group address for the
> data that is missing. You could double-check by running the UNIX
> "cat /proc/net/ip_mr_cache" command to see what exactly is installed
> in the kernel.

224.2.127.254   134.130.49.253  193.174.74.254=20
    Incoming interface :      eth0
    Outgoing interfaces:      ..O

233.4.251.3     134.130.49.253  193.174.74.254=20
    Incoming interface :      eth0
    Outgoing interfaces:      ..O

FE7F02E0 FD318286 0     408531 74844745        0  2:1 =20
03FB04E9 FD318286 0     572670 769668480        0  2:1 =20

 0 eth0       -16448096 115388480  1249002710  890200 00000 0300120A 000000=
00
 1 eth1       1249701440  895632         0       0 00000 7277E289 00000000
 2 pimreg            0       0  -846962008 9313618 00004 0300120A 00000000

So I think FE...E0 which is sap.mcast.net should get routed to eth1,
which is the external network. Same with my data.

> If there is an entry, check that the iif and the oifs are
> correct. If they are correct, then run tcpdump on one of the
> expected outgoing interface and see whether the data is coming out
> on that interface.

This is a snippet of typical mcast traffic on the external network. All the=
se
233.4.251.x are streaming (wildly) in the internal network. I requested
233.4.251.1 some seconds before that (from the external network).

00:54:04.326977 IP 137.226.119.114 > PIM-ROUTERS.MCAST.NET: pim v2 Join/Pru=
ne upstream-neighbor=3Dc3750-sw23-wohnheime.noc.RWTH-Aachen.DE groups=3D1 h=
oldtime=3D3m30s (group0: 233.4.251.68 join=3D1 mr-frankfurt2.g-win.dfn.de(S=
WR) prune=3D1 ip2-253.halifax.rwth-aachen.de(SR))
00:54:04.595300 IP 137.226.119.114 > PIM-ROUTERS.MCAST.NET: pim v2 Join/Pru=
ne upstream-neighbor=3Dc3750-sw23-wohnheime.noc.RWTH-Aachen.DE groups=3D1 h=
oldtime=3D3m30s (group0: 233.4.251.33 join=3D1 mr-frankfurt2.g-win.dfn.de(S=
WR) prune=3D1 ip2-253.halifax.rwth-aachen.de(SR))
00:54:04.856084 IP 137.226.119.114 > PIM-ROUTERS.MCAST.NET: pim v2 Join/Pru=
ne upstream-neighbor=3Dc3750-sw23-wohnheime.noc.RWTH-Aachen.DE groups=3D1 h=
oldtime=3D3m30s (group0: 233.4.251.4 join=3D1 mr-frankfurt2.g-win.dfn.de(SW=
R) prune=3D1 ip2-253.halifax.rwth-aachen.de(SR))
00:54:05.539487 IP mr-frankfurt2.g-win.dfn.de > ALL-ROUTERS.MCAST.NET: igmp=
 pimv1 RP-reachable
00:54:05.711700 IP mr-frankfurt2.g-win.dfn.de > ALL-ROUTERS.MCAST.NET: igmp=
 pimv1 RP-reachable
00:54:06.120742 IP 137.226.119.114 > PIM-ROUTERS.MCAST.NET: pim v2 Join/Pru=
ne upstream-neighbor=3Dc3750-sw23-wohnheime.noc.RWTH-Aachen.DE groups=3D1 h=
oldtime=3D3m30s (group0: 233.4.251.1 join=3D1 mr-frankfurt2.g-win.dfn.de(SW=
R) prune=3D1 ip2-253.halifax.rwth-aachen.de(SR))
00:54:06.337234 IP 137.226.119.114 > PIM-ROUTERS.MCAST.NET: pim v2 Join/Pru=
ne upstream-neighbor=3Dc3750-sw23-wohnheime.noc.RWTH-Aachen.DE groups=3D1 h=
oldtime=3D3m30s (group0: 233.4.251.6 join=3D1 mr-frankfurt2.g-win.dfn.de(SW=
R) prune=3D1
00:54:06.337234 IP 137.226.119.114 > PIM-ROUTERS.MCAST.NET: pim v2 Join/Pru=
ne upstream-neighbor=3Dc3750-sw23-wohnheime.noc.RWTH-Aachen.DE groups=3D1 h=
oldtime=3D3m30s (group0: 233.4.251.6 join=3D1 mr-frankfurt2.g-win.dfn.de(SW=
R) prune=3D1 ip2-253.halifax.rwth-aachen.de(SR))
00:54:06.981602 IP mr-frankfurt2.g-win.dfn.de > ALL-ROUTERS.MCAST.NET: igmp=
 pimv1 RP-reachable
00:54:07.399725 IP mr-frankfurt2.g-win.dfn.de > ALL-ROUTERS.MCAST.NET: igmp=
 pimv1 RP-reachable
00:54:08.903671 IP 137.226.119.114 > PIM-ROUTERS.MCAST.NET: pim v2 Join/Pru=
ne upstream-neighbor=3Dc3750-sw23-wohnheime.noc.RWTH-Aachen.DE groups=3D1 h=
oldtime=3D3m30s (group0: 233.4.251.36 join=3D0 prune=3D1 mr-frankfurt2.g-wi=
n.dfn.de(SWR))
00:54:09.733380 IP 137.226.119.114 > PIM-ROUTERS.MCAST.NET: pim v2 Join/Pru=
ne upstream-neighbor=3Dc3750-sw23-wohnheime.noc.RWTH-Aachen.DE groups=3D1 h=
oldtime=3D3m30s (group0: 233.4.251.30 join=3D1 mr-frankfurt2.g-win.dfn.de(S=
WR) prune=3D1 ip2-253.halifax.rwth-aachen.de(SR))
00:54:10.535268 IP 137.226.119.114 > PIM-ROUTERS.MCAST.NET: pim v2 Join/Pru=
ne upstream-neighbor=3Dc3750-sw23-wohnheime.noc.RWTH-Aachen.DE groups=3D1 h=
oldtime=3D3m30s (group0: 233.4.251.94 join=3D0 prune=3D1 mr-frankfurt2.g-wi=
n.dfn.de(SWR))
00:54:10.561690 IP 137.226.119.114 > PIM-ROUTERS.MCAST.NET: pim v2 Join/Pru=
ne upstream-neighbor=3Dc3750-sw23-wohnheime.noc.RWTH-Aachen.DE groups=3D1 h=
oldtime=3D3m30s (group0: 233.4.251.92 join=3D0 prune=3D1 mr-frankfurt2.g-wi=
n.dfn.de(SWR))
00:54:10.586749 IP 137.226.119.114 > PIM-ROUTERS.MCAST.NET: pim v2 Join/Pru=
ne upstream-neighbor=3Dc3750-sw23-wohnheime.noc.RWTH-Aachen.DE groups=3D1 h=
oldtime=3D3m30s (group0: 233.4.251.46 join=3D0 prune=3D1 mr-frankfurt2.g-wi=
n.dfn.de(SWR))
00:54:10.595321 IP 137.226.119.114 > PIM-ROUTERS.MCAST.NET: pim v2 Join/Pru=
ne upstream-neighbor=3Dc3750-sw23-wohnheime.noc.RWTH-Aachen.DE groups=3D1 h=
oldtime=3D3m30s (group0: 233.4.251.61 join=3D0 prune=3D1 mr-frankfurt2.g-wi=
n.dfn.de(SWR))
00:54:10.647721 IP 137.226.119.114 > PIM-ROUTERS.MCAST.NET: pim v2 Join/Pru=
ne upstream-neighbor=3Dc3750-sw23-wohnheime.noc.RWTH-Aachen.DE groups=3D1 h=
oldtime=3D3m30s (group0: 233.4.251.7 join=3D0 prune=3D1 mr-frankfurt2.g-win=
=2Edfn.de(SWR))
00:54:11.130260 IP 137.226.119.114 > PIM-ROUTERS.MCAST.NET: pim v2 Hello (H=
old-time 1m45s) (LAN-Prune-Delay: T-bit=3D0 lan-delay=3D500ms override-inte=
rval=3D2500ms) (DR-Priority: 1) (Genid: 0x1496afd0)
00:54:14.717538 IP c3750-sw23-wohnheime.noc.RWTH-Aachen.DE > ALL-SYSTEMS.MC=
AST.NET: igmp query v2
00:54:14.835789 IP 137.226.119.114 > PIM-ROUTERS.MCAST.NET: igmp v2 report =
PIM-ROUTERS.MCAST.NET
00:54:14.840704 IP 137.226.119.114 > ALL-ROUTERS.MCAST.NET: igmp v2 report =
ALL-ROUTERS.MCAST.NET
00:54:18.668157 IP c3750-sw23-wohnheime.noc.RWTH-Aachen.DE > PIM-ROUTERS.MC=
AST.NET: pim v2 Hello (Hold-time 1m45s) (Genid: 0x00001a6b) (DR-Priority: 1=
) (State Refresh Capable; v1)
00:54:18.788893 IP 137.226.119.114 > PIM-ROUTERS.MCAST.NET: pim v2 Join/Pru=
ne upstream-neighbor=3Dc3750-sw23-wohnheime.noc.RWTH-Aachen.DE groups=3D31 =
holdtime=3D3m30s (group0: 233.4.251.67 join=3D1 mr-frankfurt2.g-win.dfn.de(=
SWR) prune=3D1 ip2-253.halifax.rwth-aachen.de(SR)) (group1: 233.4.251.62 jo=
in=3D1 ...)
00:54:18.951600 IP 137.226.119.114 > PIM-ROUTERS.MCAST.NET: pim v2 Bootstra=
p tag=3D2244 hashmlen=3D0 BSRprio=3D0 BSR=3Dmr-frankfurt2.g-win.dfn.de (gro=
up0: IETF-1-LOW-AUDIO.MCAST.NET/31 RPcnt=3D1 FRPcnt=3D1 RP0=3Dmr-frankfurt2=
=2Eg-win.dfn.de,holdtime=3D2m22s,prio=3D0) (group1: IETF-1-VIDEO.MCAST.NET/=
31 RPcnt=3D1 FRPcnt=3D1 RP0=3Dmr-frankfurt2.g-win.dfn.de,holdtime=3D2m24s,p=
rio=3D0)
00:54:23.572184 IP c3750-sw23-wohnheime.noc.RWTH-Aachen.DE > PIM-ROUTERS.MC=
AST.NET: pim v2 Bootstrap tag=3D1246 hashmlen=3D0 BSRprio=3D0 BSR=3Dmr-fran=
kfurt2.g-win.dfn.de (group0: IETF-1-LOW-AUDIO.MCAST.NET/31 RPcnt=3D1 FRPcnt=
=3D1 RP0=3Dmr-frankfurt2.g-win.dfn.de,holdtime=3D2m18s,prio=3D0) (group1: I=
ETF-1-VIDEO.MCAST.NET/31 RPcnt=3D1 FRPcnt=3D1 RP0=3Dmr-frankfurt2.g-win.dfn=
=2Ede,holdtime=3D2m21s,prio=3D0) (group2: ...)

> If there is no MFC entry, then use the "show pim join" command to
> check what is the status of the corresponding (S,G) entry for this
> directly connected source.

All groups in question are in MFC, but some more lines cannot hurt I hope.

224.2.127.254   0.0.0.0         193.174.74.254  WC  =20
    Upstream interface (RP):   eth1
    Upstream MRIB next hop (RP): 137.226.119.113
    Upstream RPF'(*,G):        137.226.119.113
    Upstream state:            Joined=20
    Join timer:                39
    Local receiver include WC: O..
    Joins RP:                  ...
    Joins WC:                  ...
    Join state:                ...
    Prune state:               ...
    Prune pending state:       ...
    I am assert winner state:  ...
    I am assert loser state:   ...
    Assert winner WC:          ...
    Assert lost WC:            ...
    Assert tracking WC:        OO.
    Could assert WC:           O..
    I am DR:                   OOO
    Immediate olist RP:        ...
    Immediate olist WC:        O..
    Inherited olist SG:        O..
    Inherited olist SG_RPT:    O..
    PIM include WC:            O..
233.4.251.1     0.0.0.0         193.174.74.254  WC  =20
    Upstream interface (RP):   eth1
    Upstream MRIB next hop (RP): 137.226.119.113
    Upstream RPF'(*,G):        137.226.119.113
    Upstream state:            Joined=20
    Join timer:                39
    Local receiver include WC: O..
    Joins RP:                  ...
    Joins WC:                  ...
    Join state:                ...
    Prune state:               ...
    Prune pending state:       ...
    I am assert winner state:  ...
    I am assert loser state:   ...
    Assert winner WC:          ...
    Assert lost WC:            ...
    Assert tracking WC:        OO.
    Could assert WC:           O..
    I am DR:                   OOO
    Immediate olist RP:        ...
    Immediate olist WC:        O..
    Inherited olist SG:        O..
    Inherited olist SG_RPT:    O..
    PIM include WC:            O..

Thanks a lot!
--=20
Carsten Otto
c-otto@gmx.de
www.c-otto.de

--KsGdsel6WgEHnImy
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDhQVijUF4jpCSQBQRAq8vAKDx2H2D3Ah3rMnYM0HvHjd6+X/z9QCgnd8L
b21T0OnpXX3LzMxaXilQxjY=
=m0E8
-----END PGP SIGNATURE-----

--KsGdsel6WgEHnImy--

From pavlin@icir.org  Thu Nov 24 00:45:34 2005
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Wed, 23 Nov 2005 16:45:34 -0800
Subject: [Xorp-users] How to work with a bridge (br0)? (corrected version)
In-Reply-To: Message from Carsten Otto <c-otto@gmx.de>
 of "Thu, 24 Nov 2005 01:12:18 +0100." <20051124001218.GA2307@carsten-otto.halifax.rwth-aachen.de>
Message-ID: <200511240045.jAO0jYht011993@possum.icir.org>

> I noticed some (not several, but more than one) crashes in the last few
> hours. xorp_rtrmgr does not react on ctrl+c and multicast routing is
> stopped (I can't see any entries in my SAP list). Any ideas?

Do you see the crashes (coredumps?) during normal operation or only
when you use Ctrl-C?

If the former please send a backtrace of the crashed process.
If the latter, then please submit a bugzilla entry with the log
messages before and after you used Ctrl-C.

> On Wed, Nov 23, 2005 at 01:12:55PM -0800, Pavlin Radoslavov wrote:
> > Before doing anything, first double-check that the TTL of the data
> > is large enough, because the default multicast TTL is 1.
> 
> Everything is set to 7. The university admin assured that the router in
> question (next hop) drops packets with TTL < 8 on their way out into the
> rest of the university and inside this router (to other dorms)
> everything should work. PS: I doublechecked :)
> 
> > Then check the MFC entries ("show pim mfc") whether there is a
> > matching entry for your PC/sender and the group address for the
> > data that is missing. You could double-check by running the UNIX
> > "cat /proc/net/ip_mr_cache" command to see what exactly is installed
> > in the kernel.
> 
> 224.2.127.254   134.130.49.253  193.174.74.254=20
>     Incoming interface :      eth0
>     Outgoing interfaces:      ..O
> 
> 233.4.251.3     134.130.49.253  193.174.74.254=20
>     Incoming interface :      eth0
>     Outgoing interfaces:      ..O
> 
> FE7F02E0 FD318286 0     408531 74844745        0  2:1 =20
> 03FB04E9 FD318286 0     572670 769668480        0  2:1 =20

The MFC entries look fine (I presume that eth0 is the interface
toward your source). It seems that the special register_vif is
the only oif. This is normal, and all data packets will be
encapsulated and unicast inside PIM Register messages to the RP.
Once the RP receives the Registers, it will decapsulate them and
send them natively (multicast) downstream to all receivers.

> 
>  0 eth0       -16448096 115388480  1249002710  890200 00000 0300120A 000000=
> 00
>  1 eth1       1249701440  895632         0       0 00000 7277E289 00000000
>  2 pimreg            0       0  -846962008 9313618 00004 0300120A 00000000
> 
> So I think FE...E0 which is sap.mcast.net should get routed to eth1,
> which is the external network. Same with my data.

Only if there is PIM Join message (or IGMP Join message) received on
eth1, then the XORP router should forward the data packets on eth1.

> > If there is an entry, check that the iif and the oifs are
> > correct. If they are correct, then run tcpdump on one of the
> > expected outgoing interface and see whether the data is coming out
> > on that interface.
> 
> This is a snippet of typical mcast traffic on the external network. All the=
> se
> 233.4.251.x are streaming (wildly) in the internal network. I requested
> 233.4.251.1 some seconds before that (from the external network).

If you tcpdump all PIM traffic (including unicast), then you should
see the PIM Register messages with your encapsulated data packet.

Then the next thing do check is whether both the SAP announcements
and the application's data are sent by PIM Registers to the (same)
RP, and why only the SAP PIM Registers make it to the RP and down to
the receivers.

<DEL>

> > If there is no MFC entry, then use the "show pim join" command to
> > check what is the status of the corresponding (S,G) entry for this
> > directly connected source.
> 
> All groups in question are in MFC, but some more lines cannot hurt I hope.

Did you have the directly connected sender running when you took the
snapshot below. If yes, then you should have a sender-specific SG
entry as well.

Pavlin

> 
> 224.2.127.254   0.0.0.0         193.174.74.254  WC  =20
>     Upstream interface (RP):   eth1
>     Upstream MRIB next hop (RP): 137.226.119.113
>     Upstream RPF'(*,G):        137.226.119.113
>     Upstream state:            Joined=20
>     Join timer:                39
>     Local receiver include WC: O..
>     Joins RP:                  ...
>     Joins WC:                  ...
>     Join state:                ...
>     Prune state:               ...
>     Prune pending state:       ...
>     I am assert winner state:  ...
>     I am assert loser state:   ...
>     Assert winner WC:          ...
>     Assert lost WC:            ...
>     Assert tracking WC:        OO.
>     Could assert WC:           O..
>     I am DR:                   OOO
>     Immediate olist RP:        ...
>     Immediate olist WC:        O..
>     Inherited olist SG:        O..
>     Inherited olist SG_RPT:    O..
>     PIM include WC:            O..
> 233.4.251.1     0.0.0.0         193.174.74.254  WC  =20
>     Upstream interface (RP):   eth1
>     Upstream MRIB next hop (RP): 137.226.119.113
>     Upstream RPF'(*,G):        137.226.119.113
>     Upstream state:            Joined=20
>     Join timer:                39
>     Local receiver include WC: O..
>     Joins RP:                  ...
>     Joins WC:                  ...
>     Join state:                ...
>     Prune state:               ...
>     Prune pending state:       ...
>     I am assert winner state:  ...
>     I am assert loser state:   ...
>     Assert winner WC:          ...
>     Assert lost WC:            ...
>     Assert tracking WC:        OO.
>     Could assert WC:           O..
>     I am DR:                   OOO
>     Immediate olist RP:        ...
>     Immediate olist WC:        O..
>     Inherited olist SG:        O..
>     Inherited olist SG_RPT:    O..
>     PIM include WC:            O..

From c-otto@gmx.de  Thu Nov 24 00:56:57 2005
From: c-otto@gmx.de (Carsten Otto)
Date: Thu, 24 Nov 2005 01:56:57 +0100
Subject: [Xorp-users] How to work with a bridge (br0)? (corrected version)
In-Reply-To: <200511240045.jAO0jYht011993@possum.icir.org>
References: <20051124001218.GA2307@carsten-otto.halifax.rwth-aachen.de> <200511240045.jAO0jYht011993@possum.icir.org>
Message-ID: <20051124005657.GA18875@carsten-otto.halifax.rwth-aachen.de>

--LQksG6bCIzRHxTLp
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Nov 23, 2005 at 04:45:34PM -0800, Pavlin Radoslavov wrote:
> Do you see the crashes (coredumps?) during normal operation or only
> when you use Ctrl-C?

I have no coredumps, sorry. Xorp stops working in the middle of
operation (after some configuration changes, but not directly after
that).

> If the former please send a backtrace of the crashed process.

How? I am not experienced here, sorry.

> The MFC entries look fine (I presume that eth0 is the interface
> toward your source). It seems that the special register_vif is
> the only oif. This is normal, and all data packets will be
> encapsulated and unicast inside PIM Register messages to the RP.
> Once the RP receives the Registers, it will decapsulate them and
> send them natively (multicast) downstream to all receivers.

Here might be the problem. I was told sending data outside the
university, perhaps including this encapsulated format, is bad and makes
problems. I was told something about wrong routes with multicast and so
on. So a local solution would be fine :)

> Only if there is PIM Join message (or IGMP Join message) received on
> eth1, then the XORP router should forward the data packets on eth1.

There was, but no data has been received.

> If you tcpdump all PIM traffic (including unicast), then you should
> see the PIM Register messages with your encapsulated data packet.

Okay, I will try that (tomorrow, 2am here).

> Then the next thing do check is whether both the SAP announcements
> and the application's data are sent by PIM Registers to the (same)
> RP, and why only the SAP PIM Registers make it to the RP and down to
> the receivers.

Right.

> Did you have the directly connected sender running when you took the
> snapshot below. If yes, then you should have a sender-specific SG
> entry as well.

The sender was running, but I don't have (S,G). I will recheck.
--=20
Carsten Otto
c-otto@gmx.de
www.c-otto.de

--LQksG6bCIzRHxTLp
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDhQ/ZjUF4jpCSQBQRAsKQAJ9HMcuLRtmne0eu7E31p/41hlWC6gCeKC9U
s/KZik4fo2ThASqRzeMAkJw=
=V0ma
-----END PGP SIGNATURE-----

--LQksG6bCIzRHxTLp--

From pavlin@icir.org  Thu Nov 24 01:08:27 2005
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Wed, 23 Nov 2005 17:08:27 -0800
Subject: [Xorp-users] How to work with a bridge (br0)? (corrected version)
In-Reply-To: Message from Carsten Otto <c-otto@gmx.de>
 of "Thu, 24 Nov 2005 01:56:57 +0100." <20051124005657.GA18875@carsten-otto.halifax.rwth-aachen.de>
Message-ID: <200511240108.jAO18SOi012246@possum.icir.org>

> On Wed, Nov 23, 2005 at 04:45:34PM -0800, Pavlin Radoslavov wrote:
> > Do you see the crashes (coredumps?) during normal operation or only
> > when you use Ctrl-C?
> 
> I have no coredumps, sorry. Xorp stops working in the middle of
> operation (after some configuration changes, but not directly after
> that).

Please send the log messages, because it is still not clear to me
what exactly is happening.

> > The MFC entries look fine (I presume that eth0 is the interface
> > toward your source). It seems that the special register_vif is
> > the only oif. This is normal, and all data packets will be
> > encapsulated and unicast inside PIM Register messages to the RP.
> > Once the RP receives the Registers, it will decapsulate them and
> > send them natively (multicast) downstream to all receivers.
> 
> Here might be the problem. I was told sending data outside the
> university, perhaps including this encapsulated format, is bad and makes
> problems. I was told something about wrong routes with multicast and so
> on. So a local solution would be fine :)

Are you part of your university PIM-SM domain or are you outside of
it? If the former, then all PIM-SM routers MUST share the same
RP-Set. Then, assuming your XORP router is not a Cand-RP for the
particular multicast group you are interested at, you have to rely
on the good will of the university's RP to accept and forward the
multicast traffic originated by your source.

> > Only if there is PIM Join message (or IGMP Join message) received on
> > eth1, then the XORP router should forward the data packets on eth1.
> 
> There was, but no data has been received.

If you see PIM Join messages for your sender's group coming on eth1,
then eth1 should have been added to the oif set. This is when you
need to look into the "show pim join" output to verify that. Note
that inside those Join messages the upstream-neighbor (from the
tcpdump output) should be your XORP router's address, otherwise
those Joins are for some other PIM-SM router on the shared LAN.

Pavlin

From c-otto@gmx.de  Thu Nov 24 09:33:10 2005
From: c-otto@gmx.de (Carsten Otto)
Date: Thu, 24 Nov 2005 10:33:10 +0100
Subject: [Xorp-users] How to work with a bridge (br0)? (corrected version)
In-Reply-To: <200511240108.jAO18SOi012246@possum.icir.org>
References: <20051124005657.GA18875@carsten-otto.halifax.rwth-aachen.de> <200511240108.jAO18SOi012246@possum.icir.org>
Message-ID: <20051124093310.GA18669@carsten-otto.halifax.rwth-aachen.de>

--Q68bSM7Ycu6FN28Q
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Nov 23, 2005 at 05:08:27PM -0800, Pavlin Radoslavov wrote:
> Please send the log messages, because it is still not clear to me
> what exactly is happening.

I have about 1 GB of logs with varies tries and configurations. You can
have them, but I did not document what exactly was configured. Perhaps
you can find the lines that tell you this information.

I will give you the addresses via E-Mail.

The new logfile has been initialized just now. I will put a recent
version online from time to time.

> Are you part of your university PIM-SM domain or are you outside of
> it? If the former, then all PIM-SM routers MUST share the same
> RP-Set. Then, assuming your XORP router is not a Cand-RP for the
> particular multicast group you are interested at, you have to rely
> on the good will of the university's RP to accept and forward the
> multicast traffic originated by your source.

What exactly does inside mean here? One interface is directly connected
to a router/switch that does IGMP and PIM-SM. The university explicitely
activated the mcast feature for our port. I can see various multicast
messages even without any Xorp running. That named router appears in my
neighbors section.

> If you see PIM Join messages for your sender's group coming on eth1,
> then eth1 should have been added to the oif set. This is when you
> need to look into the "show pim join" output to verify that. Note
> that inside those Join messages the upstream-neighbor (from the
> tcpdump output) should be your XORP router's address, otherwise
> those Joins are for some other PIM-SM router on the shared LAN.

At the moment the announcements from the internal network do not appear
in the external network. Manually starting the stream does not work, I
will analyze the packet flow later.

Thanks again for your help!
--=20
Carsten Otto
c-otto@gmx.de
www.c-otto.de

--Q68bSM7Ycu6FN28Q
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDhYjWjUF4jpCSQBQRAjkdAJ4widfKgOYf5e5ykE/ssDKZiyKwLgCfWCJu
bwIFbZIDciZCy8Pq9iA/kLo=
=mA0o
-----END PGP SIGNATURE-----

--Q68bSM7Ycu6FN28Q--

From c-otto@gmx.de  Thu Nov 24 10:50:58 2005
From: c-otto@gmx.de (Carsten Otto)
Date: Thu, 24 Nov 2005 11:50:58 +0100
Subject: [Xorp-users] How to work with a bridge (br0)? (corrected version)
In-Reply-To: <20051124093310.GA18669@carsten-otto.halifax.rwth-aachen.de>
References: <20051124005657.GA18875@carsten-otto.halifax.rwth-aachen.de> <200511240108.jAO18SOi012246@possum.icir.org> <20051124093310.GA18669@carsten-otto.halifax.rwth-aachen.de>
Message-ID: <20051124105058.GB22933@carsten-otto.halifax.rwth-aachen.de>

--Yylu36WmvOXNoKYn
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

New things to play with:

printk: 49208 messages suppressed.
mroute: pending queue full, dropping entries.
printk: 49008 messages suppressed.
mroute: pending queue full, dropping entries.
printk: 49443 messages suppressed.
mroute: pending queue full, dropping entries.

That does not sound good. Multicast-Routing does not work as it did
yesterday, too.

I renewed the config, http://home.c-otto.de/xorp.conf.txt

Ciao,
--=20
Carsten Otto
c-otto@gmx.de
www.c-otto.de

--Yylu36WmvOXNoKYn
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDhZsSjUF4jpCSQBQRArCeAKCkSbcxeceKubzGVgtyxGXKDhH8sACg0N7m
8T5oEiuU99kJPEz3/ATVDHE=
=SM5Z
-----END PGP SIGNATURE-----

--Yylu36WmvOXNoKYn--

From riccardo.sciaccaluga@tin.it" <riccardo.sciaccaluga@tin.it  Thu Nov 24 17:45:03 2005
From: riccardo.sciaccaluga@tin.it" <riccardo.sciaccaluga@tin.it (riccardo.sciaccaluga@tin.it)
Date: Thu, 24 Nov 2005 18:45:03 +0100 (GMT+01:00)
Subject: [Xorp-users] Is there a way to switch the e_bit value to 1?
Message-ID: <9991418.1132854303988.JavaMail.root@pswm8.cp.tin.it>

Thanks mike for the config file you sent to me.
Does anybody know how 
to change the e_bit value on xorp?
i mean it doesn't seem possible by 
xorp shell but is there a specific part of the source code to be 
modified to change that value to 1?
Thanks so much


From atanu@ICSI.Berkeley.EDU  Thu Nov 24 18:20:06 2005
From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Thu, 24 Nov 2005 10:20:06 -0800
Subject: [Xorp-users] Is there a way to switch the e_bit value to 1?
In-Reply-To: Message from "riccardo.sciaccaluga@tin.it" <riccardo.sciaccaluga@tin.it>
 of "Thu, 24 Nov 2005 18:45:03 +0100." <9991418.1132854303988.JavaMail.root@pswm8.cp.tin.it>
Message-ID: <64514.1132856406@tigger.icir.org>

The way to set the E bit value is in an export policy statement:

policy {
    policy-statement static {
	term export {
	    from {
		protocol: "static"
	    }
	    then {
		ebit: true	/* true for type 2 , false for type 1 */
	    }
	}
    }
}

protocols {
    ospf4 {
	export "static"
...

The default setting for the E bit value was changed from 0 to 1 earlier
this week.
<http://www.xorp.org/bugzilla/show_bug.cgi?id=368>

	Atanu.

>>>>> "riccardo" == riccardo  <riccardo.sciaccaluga@tin.it> writes:

    riccardo> Thanks mike for the config file you sent to me.  Does
    riccardo> anybody know how to change the e_bit value on xorp?  i
    riccardo> mean it doesn't seem possible by xorp shell but is there a
    riccardo> specific part of the source code to be modified to change
    riccardo> that value to 1?  Thanks so much

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

From pavlin@icir.org  Thu Nov 24 21:38:48 2005
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Thu, 24 Nov 2005 13:38:48 -0800
Subject: [Xorp-users] How to work with a bridge (br0)? (corrected version)
In-Reply-To: Message from Carsten Otto <c-otto@gmx.de>
 of "Thu, 24 Nov 2005 10:33:10 +0100." <20051124093310.GA18669@carsten-otto.halifax.rwth-aachen.de>
Message-ID: <200511242138.jAOLcmPZ048962@possum.icir.org>

> I have about 1 GB of logs with varies tries and configurations. You can
> have them, but I did not document what exactly was configured. Perhaps
> you can find the lines that tell you this information.

You don't expect me to analyze 1GB of logs, do you? :)

Well, I had a quick look, and it appears that the PIM Registers from
your XORP router are transmitted with src address from the private
address space 10.x.x.x.

There is some possibility that the RP may be dropping the 10.x.x.x PIM
Registers simply because (presumably) the RP doesn't have a route to
your 10.x subnet.

The reason that the XORP router is using the 10.x.x.x address is
because it has been chosen as the primary address on eth0 (simply
because it was the first on the list of IP addresses for eth0).
Unfortunately, currently there is no XORP configuration statement to
influence which particular address is chosen as primary.

You could try the following workarounds (for testing purpose).
Explicitly configure all addresses on eth0, but exclude the
private addresses like 10.x. However, note that then the multicast
senders/receivers from the same 10.x subnet will be excluded so in
your tests the senders/receivers should not use those addresses.

Pavlin

From pavlin@icir.org  Thu Nov 24 21:55:29 2005
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Thu, 24 Nov 2005 13:55:29 -0800
Subject: [Xorp-users] How to work with a bridge (br0)? (corrected version)
In-Reply-To: Message from Carsten Otto <c-otto@gmx.de>
 of "Thu, 24 Nov 2005 11:50:58 +0100." <20051124105058.GB22933@carsten-otto.halifax.rwth-aachen.de>
Message-ID: <200511242155.jAOLtTLL049102@possum.icir.org>

> printk: 49208 messages suppressed.
> mroute: pending queue full, dropping entries.
> printk: 49008 messages suppressed.
> mroute: pending queue full, dropping entries.
> printk: 49443 messages suppressed.
> mroute: pending queue full, dropping entries.
> 
> That does not sound good. Multicast-Routing does not work as it did
> yesterday, too.

Was your sender transmitting, and what was the transmitting bandwidth?
Given that everything is encapsulated in userspace as PIM Registers,
then the whole router probably cannot keep-up with the high bw
incoming traffic from your sender.
[FYI, *BSD supports kernel-land PIM Register encapsulation, but this
is not in Linux (yet)].

Typically (at least in case of Cisco RPs), once the sender starts
transmitting, the RP would send a source-specific join toward the
sender, and then the multicast traffic would be forwarded natively
toward the RP rather then being encapsulated. Eliminating the PIM
Registers should reduce the router load.

In general, while testing I'd recommend that you use some multicast
test program that can be controlled (the transmitting bw, the
sender/receiver IP address, etc). E.g., MGEN:
http://tang.itd.nrl.navy.mil/5522/mgen/mgen_index.html
Alternatively, you could use the msend/mrcv tools, but they are very
primitive:
http://netweb.usc.edu/pim/pimd/mtest.tar.gz

Pavlin

From atanu@ICSI.Berkeley.EDU  Thu Nov 24 22:47:58 2005
From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Thu, 24 Nov 2005 14:47:58 -0800
Subject: [Xorp-users] Is there a way to switch the e_bit value to 1?
In-Reply-To: Message from Hasso Tepper <hasso@estpak.ee>
 of "Thu, 24 Nov 2005 20:38:37 +0200." <200511242038.37939.hasso@estpak.ee>
Message-ID: <27524.1132872478@tigger.icir.org>

>>>>> "Hasso" == Hasso Tepper <hasso@estpak.ee> writes:

    Hasso> Atanu Ghosh wrote:

    >> The way to set the E bit value is in an export policy statement:
    >> 
    >> policy {
    >> policy-statement static {
    >> term export {
    >> from {
    >> protocol: "static"
    >> }
    >> then {
    >> ebit: true	/* true for type 2 , false for type 1 */
    >> }
    >> }
    >> }
    >> }

    Hasso> Btw, most of coworkers I asked from, found operating with
    Hasso> term "ebit" in this context confusing. All OSPF
    Hasso> implementations I know of operate with terms Type-1
    Hasso> vs. Type-2 external LSA's. Junos cli:

    Hasso> then {
    Hasso> external {
    Hasso> type 1;
    Hasso> }
    Hasso> accept;
    Hasso> }

We will be changing the command to set the E bit.

   Atanu.

From hasso@estpak.ee  Thu Nov 24 18:38:37 2005
From: hasso@estpak.ee (Hasso Tepper)
Date: Thu, 24 Nov 2005 20:38:37 +0200
Subject: [Xorp-users] Is there a way to switch the e_bit value to 1?
In-Reply-To: <64514.1132856406@tigger.icir.org>
References: <64514.1132856406@tigger.icir.org>
Message-ID: <200511242038.37939.hasso@estpak.ee>

Atanu Ghosh wrote:
> The way to set the E bit value is in an export policy statement:
> 
> policy {
>     policy-statement static {
> 	term export {
> 	    from {
> 		protocol: "static"
> 	    }
> 	    then {
> 		ebit: true	/* true for type 2 , false for type 1 */
> 	    }
> 	}
>     }
> }

Btw, most of coworkers I asked from, found operating with term "ebit" in
this context confusing. All OSPF implementations I know of operate with
terms Type-1 vs. Type-2 external LSA's. Junos cli:

    then {
        external {
            type 1;
        }
        accept;
    }


-- 
Hasso Tepper

From riccardo.sciaccaluga@tin.it" <riccardo.sciaccaluga@tin.it  Fri Nov 25 15:28:20 2005
From: riccardo.sciaccaluga@tin.it" <riccardo.sciaccaluga@tin.it (riccardo.sciaccaluga@tin.it)
Date: Fri, 25 Nov 2005 16:28:20 +0100 (GMT+01:00)
Subject: R: Re: [Xorp-users] Is there a way to switch the e_bit value to 1?
Message-ID: <25171913.1132932500522.JavaMail.root@pswm12.cp.tin.it>

HI
I updated my Xorp version at the latest CVS and i added to my config 
file the code lines you sent to me too;
Next i set up an ospf session 
between two Xorp router and i sniffed the traffic in between but the 
option field of network LSAs was still 0.
Checking by xorp bash command 
:"show policy policy-statement static term export then ebit" on 
configuration mode, i saw that ebit is 1 but it doesn't seem to have 
any effect on the real packet sent over the network.
 


----Messaggio 
originale----
Da: atanu@ICSI.Berkeley.EDU
Data: 24-nov-2005 7.20 PM
A: 
"riccardo.sciaccaluga@tin.it"<riccardo.sciaccaluga@tin.it>
Cc: <xorp-
users@xorp.org>
Ogg: Re: [Xorp-users] Is there a way to switch the 
e_bit value to 1? 

The way to set the E bit value is in an export 
policy statement:

policy {
    policy-statement static {
	term export 
{
	    from {
		protocol: "static"
	    }
	    then {
		ebit: true	/* 
true for type 2 , false for type 1 */
	    }
	}
    }
}

protocols {
    ospf4 {
	export "static"
...

The default setting for the E bit 
value was changed from 0 to 1 earlier
this week.
<http://www.xorp.
org/bugzilla/show_bug.cgi?id=368>

	Atanu.

>>>>> "riccardo" == 
riccardo  <riccardo.sciaccaluga@tin.it> writes:

    riccardo> Thanks 
mike for the config file you sent to me.  Does
    riccardo> anybody 
know how to change the e_bit value on xorp?  i
    riccardo> mean it 
doesn't seem possible by xorp shell but is there a
    riccardo> 
specific part of the source code to be modified to change
    riccardo> 
that value to 1?  Thanks so much

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



From atanu@ICSI.Berkeley.EDU  Fri Nov 25 18:39:44 2005
From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Fri, 25 Nov 2005 10:39:44 -0800
Subject: R: Re: [Xorp-users] Is there a way to switch the e_bit value to 1?
In-Reply-To: Message from "riccardo.sciaccaluga@tin.it" <riccardo.sciaccaluga@tin.it>
 of "Fri, 25 Nov 2005 16:28:20 +0100." <25171913.1132932500522.JavaMail.root@pswm12.cp.tin.it>
Message-ID: <63626.1132943984@tigger.icir.org>

Hi,

I think there has been some confusion here, I thought that you were
asking about the E-bit in an AS-External-LSA, not the E-bit in the
options field.

The E-bit in the options field is unconditionally set if the area is a
normal area i.e. not stub or nssa.

I just ran the same experiment that you did and ethereal shows me that
the E-bit is set.

Network LSA (Type: 2)
    LS Age: 1 seconds
    Options: 0x2 (E)
    LSA Type: 2 (Network LSA)
    Link State ID: 10.0.1.1
    Advertising Router: 0.0.0.20
    LS Sequence Number: 0x80000001
    LS Checksum: 16fe
    Length: 32
    Netmask: 255.255.0.0
    Attached Router: 10.0.1.6
    Attached Router: 0.0.0.20

Also from within the xorpsh:

Xorp> show ospf4 database network detail 
   OSPF link state database, Area 0.0.0.0
   OSPF link state database, Area 0.0.0.1
Network-LSA:
LS age  172 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link State ID 10.0.1.1 Advertising Router 0.0.0.20 LS sequence number 0x80000001 LS checksum 0x16fe length 32
        Network Mask 0xffff0000
        Attached Router 10.0.1.6
        Attached Router 0.0.0.20

Atanu.

>>>>> "riccardo" == riccardo  <riccardo.sciaccaluga@tin.it> writes:

    riccardo> HI I updated my Xorp version at the latest CVS and i added
    riccardo> to my config file the code lines you sent to me too; Next
    riccardo> i set up an ospf session between two Xorp router and i
    riccardo> sniffed the traffic in between but the option field of
    riccardo> network LSAs was still 0.  Checking by xorp bash command
    riccardo> :"show policy policy-statement static term export then
    riccardo> ebit" on configuration mode, i saw that ebit is 1 but it
    riccardo> doesn't seem to have any effect on the real packet sent
    riccardo> over the network.
 
    riccardo> ----Messaggio originale---- Da: atanu@ICSI.Berkeley.EDU
    riccardo> Data: 24-nov-2005 7.20 PM A:
    riccardo> "riccardo.sciaccaluga@tin.it"<riccardo.sciaccaluga@tin.it>
    riccardo> Cc: <xorp- users@xorp.org> Ogg: Re: [Xorp-users] Is there
    riccardo> a way to switch the e_bit value to 1?

    riccardo> The way to set the E bit value is in an export policy
    riccardo> statement:

    riccardo> policy { policy-statement static { term export { from {
    riccardo> protocol: "static" } then { ebit: true /* true for type 2
    riccardo> , false for type 1 */ } } } }

    riccardo> protocols { ospf4 { export "static" ...

    riccardo> The default setting for the E bit value was changed from 0
    riccardo> to 1 earlier this week.  <http://www.xorp.
    riccardo> org/bugzilla/show_bug.cgi?id=368>

    riccardo> 	Atanu.

>>>>> "riccardo" == 
    riccardo> riccardo <riccardo.sciaccaluga@tin.it> writes:

    riccardo> Thanks mike for the config file you sent to me.  Does
    riccardo> anybody know how to change the e_bit value on xorp?  i
    riccardo> mean it doesn't seem possible by xorp shell but is there a
    riccardo> 
    riccardo> specific part of the source code to be modified to change
    riccardo> 
    riccardo> that value to 1?  Thanks so much

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