Advertising Router 10.0.0.1 LS
sequence number 0x80000001 LS checksum 0xc de5 length 72
[ 2006/02/07 21:14:16 TRACE xorp_ospfv2 OSPF ] Ack for LSA not in
retransmission list.
LS age 91 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link
State ID 10.1.0.13 Advertising Router 10.0.0.1 LS sequence number 0x80000001
LS checksum 0xdc45 len gth 32
Link State Acknowledgement Packet:
Version 2
Type 5
Router ID 10.0.0.2
Area ID 0.0.0.0
Auth Type 0
LS age 91 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2
Link State ID 10.1.0.13 Advertising Router 10.0.0.1 LS sequence number
0x80000001 LS checksum 0x dc45 length 32
[ 2006/02/07 21:14:21 FATAL xorp_ospfv2:7261 OSPF +471 routing_table.cc
add_entry ] Assertion (0 == _entries.count(area)) failed
[ 2006/02/07 21:14:21 ERROR xorp_rtrmgr:7256 RTRMGR +736 module_manager.cc
done_cb ] Command "/usr/local/xorp/ospf/xorp_ospfv2": terminated with signal
6.
[ 2006/02/07 21:14:21 INFO xorp_rtrmgr:7256 RTRMGR +286 module_manager.cc
module_exited ] Module abnormally killed: ospf4
[ 2006/02/07 21:14:21 INFO xorp_rib RIB ] Received death event for protocol
ospfv2 shutting down -------
OriginTable: ospf
IGP
next table = Redist:ospf
[ 2006/02/07 21:14:21 INFO xorp_rib RIB ] Received death event for protocol
ospfv2 shutting down -------
OriginTable: ospf
IGP
next table = Redist:ospf
[ 2006/02/07 21:14:21 INFO xorp_rib RIB ] Received death event for protocol
ospfv2 shutting down -------
OriginTable: ospf
IGP
next table = Redist:ospf
[ 2006/02/07 21:14:21 INFO xorp_rib RIB ] Received death event for protocol
ospfv2 shutting down -------
OriginTable: ospf
IGP
next table = Redist:ospf
I've attached all four router configs in case it helps.
Any ideas?
Tim:>
------=_NextPart_000_00E9_01C62C92.108002F0
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hi Tim,
This looks similar to, but is not the same as =
XORP bug=20
383. I would suggest opening a new bug in Bugzilla so that the =
XORP team=20
can investigate.
If these are the only routers running OSPF on =
this network,=20
then there might be some sort of race condition related to DR =
election. =20
This might explain why it happens when you enable all four at the same =
time=20
rather than one at a time. I only have 2 routers running XORP =
here, but=20
I'll see if I can reproduce the issue.
-mike
I've been having ongoing OSPF death problems with my simple =
fully=20
meshed four router test bed.
If I bring all four routers up at =
the same=20
time, OSPF quickly dies. If I bring them up one at a time, sometimes =
they will=20
stay up and stable.
The event is:
[ 2006/02/07 =
21:11:40 =20
INFO xorp_rtrmgr:7256 RTRMGR +2228 task.cc run_task ] No more tasks to =
run
[=20
2006/02/07 21:11:40 TRACE xorp_rtrmgr RTRMGR ] apply_config_change_done: =
status:=20
1 response: target: xorpsh-7257-xen1
[ 2006/02/07 21:12:45 =
TRACE=20
xorp_ospfv2 OSPF ] Ack for LSA not in retransmission list.
LS=20
age 1 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 =
LS type=20
0x1 Link State ID 10.0.0.1 Advertising =
Router 10.0.0.1 LS sequence number 0x80000001 LS =
checksum=20
0xcde5 leng th 72
Link State Acknowledgement=20
Packet:
Version=20
2
Type=20
5
Router ID 10.1.0.2
&n=
bsp; =20
Area ID 0.0.0.0
&nbs=
p; =20
Auth Type 0
LS=20
age 1 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 =
LS type=20
0x1 Link State ID 10.0.0.1 Advertising =
Router 10.0.0.1 LS sequence number 0x80000001 LS =
checksum=20
0xc de5 length 72
[ 2006/02/07 21:14:16 TRACE xorp_ospfv2 OSPF ] Ack =
for LSA=20
not in retransmission list.
LS age 91 Options 0x2 =
DC: 0 EA:=20
0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link State ID 10.1.0.13 Advertising Router 10.0.0.1 LS sequence number 0x80000001 LS =
checksum=20
0xdc45 len gth 32
Link State Acknowledgement=20
Packet:
Version=20
2
Type=20
5
Router ID 10.0.0.2
&n=
bsp; =20
Area ID 0.0.0.0
&nbs=
p; =20
Auth Type 0
LS =
age =20
91 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link =
State ID 10.1.0.13 Advertising Router 10.0.0.1 LS sequence number 0x80000001 LS =
checksum 0x=20
dc45 length 32
[ 2006/02/07 21:14:21 FATAL xorp_ospfv2:7261 =
OSPF +471=20
routing_table.cc add_entry ] Assertion (0 =3D=3D _entries.count(area)) =
failed
[=20
2006/02/07 21:14:21 ERROR xorp_rtrmgr:7256 RTRMGR +736 =
module_manager.cc=20
done_cb ] Command "/usr/local/xorp/ospf/xorp_ospfv2": terminated with =
signal=20
6.
[ 2006/02/07 21:14:21 INFO xorp_rtrmgr:7256 RTRMGR +286=20
module_manager.cc module_exited ] Module abnormally killed: ospf4
[=20
2006/02/07 21:14:21 INFO xorp_rib RIB ] Received death event for =
protocol ospfv2=20
shutting down -------
OriginTable: ospf
IGP
next table =3D=20
Redist:ospf
[ 2006/02/07 21:14:21 INFO xorp_rib RIB ] Received death =
event=20
for protocol ospfv2 shutting down -------
OriginTable: =
ospf
IGP
next=20
table =3D Redist:ospf
[ 2006/02/07 21:14:21 INFO xorp_rib RIB ] =
Received death=20
event for protocol ospfv2 shutting down -------
OriginTable:=20
ospf
IGP
next table =3D Redist:ospf
[ 2006/02/07 21:14:21 INFO =
xorp_rib=20
RIB ] Received death event for protocol ospfv2 shutting down=20
-------
OriginTable: ospf
IGP
next table =3D =
Redist:ospf
I've=20
attached all four router configs in case it helps.
Any=20
ideas?
Tim:>
------=_NextPart_000_00E9_01C62C92.108002F0--
From atanu@ICSI.Berkeley.EDU Fri Feb 10 03:17:48 2006
From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Thu, 09 Feb 2006 19:17:48 -0800
Subject: [Xorp-hackers] OSPF Failures
In-Reply-To: Message from Tim Durack
of "Tue, 07 Feb 2006 21:52:57 EST." <9e246b4d0602071852sd937ccdw411ae1c2578d0c2@mail.gmail.com>
Message-ID: <87806.1139541468@tigger.icir.org>
Hi,
I have just checked in a possible fix.
Atanu.
1.198 +19 -2; commitid: d04543ec04fa7ea6; xorp/ospf/area_router.cc
1.49 +18 -1; commitid: d04543ec04fa7ea6; xorp/ospf/routing_table.cc
1.38 +12 -2; commitid: d04543ec04fa7ea6; xorp/ospf/routing_table.hh
>>>>> "Tim" == Tim Durack writes:
Tim> I've been having ongoing OSPF death problems with my simple
Tim> fully meshed four router test bed. If I bring all four routers
Tim> up at the same time, OSPF quickly dies. If I bring them up one
Tim> at a time, sometimes they will stay up and stable.
From imipak@yahoo.com Sat Feb 11 00:58:35 2006
From: imipak@yahoo.com (Jonathan Day)
Date: Fri, 10 Feb 2006 16:58:35 -0800 (PST)
Subject: [Xorp-hackers] Questions on next release, puzzles and mysteries
Message-ID: <20060211005835.11562.qmail@web31502.mail.mud.yahoo.com>
Hi,
First off, any idea when the next release is likely to
be? The roadmap (as all roadmaps are wont to be) is
off, but would I be right in assuming it'll be
reasonably soon?
Second, the more I look at network routing protocols,
the more protocols I find. It would be handy if there
was a page listing existant protocols, their
real-world scope, and their priority for being
implemented (NIN being for protocols that won't be
implemented in this lifetime, even if threatened with
a Tandy TRS-80.)
Finally, there is MIT's Click project, which (I seem
to remember) can interact with Xorp. Neither site
seems to list how such interactions occur or, indeed,
why. (I really like to know what I'm doing! :) More
documentation on what Xorp can interoperate with would
be wonderful.
Thoughts?
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
From pavlin@icir.org Thu Feb 16 00:11:34 2006
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Wed, 15 Feb 2006 16:11:34 -0800
Subject: [Xorp-hackers] Questions on next release, puzzles and mysteries
In-Reply-To: Message from Jonathan Day
of "Fri, 10 Feb 2006 16:58:35 PST." <20060211005835.11562.qmail@web31502.mail.mud.yahoo.com>
Message-ID: <200602160011.k1G0BYKE036812@possum.icir.org>
> First off, any idea when the next release is likely to
> be? The roadmap (as all roadmaps are wont to be) is
> off, but would I be right in assuming it'll be
> reasonably soon?
Hopefully very soon there will be a release candidate.
Typically, two weeks after the release candidate is the release
itself.
> Second, the more I look at network routing protocols,
> the more protocols I find. It would be handy if there
> was a page listing existant protocols, their
> real-world scope, and their priority for being
> implemented (NIN being for protocols that won't be
> implemented in this lifetime, even if threatened with
> a Tandy TRS-80.)
This is outside the scope of XORP. Implementing even a single
protocol is very time consuming so for the time being we have our
hands tied with the must-have protocols like OSPF, etc.
> Finally, there is MIT's Click project, which (I seem
> to remember) can interact with Xorp. Neither site
> seems to list how such interactions occur or, indeed,
> why. (I really like to know what I'm doing! :) More
> documentation on what Xorp can interoperate with would
> be wonderful.
>From XORP's perspective, Click can be used as a very powerful
forwarding plane (though, you can use Click for more than this).
The FEA knows how to interact with Click so you could enable the Click
forwarding path and the rest of XORP will continue to work as-is.
The xorp/rtrmgr/config.boot.sample file contains the Click-related
configuration statements that can be used to enable Click.
If you are familiar with Click, there is not much more you need to
know from XORP perspective.
Unfortunately, the XORP documentation doesn't describe the
Click-related configuration, but it should be included in the 1.2
release.
If you have any specific questions feel free to ask them now.
Those questions can be helpful when it comes to writing the
documentation itself :)
Pavlin
From imipak@yahoo.com Sat Feb 18 06:22:58 2006
From: imipak@yahoo.com (Jonathan Day)
Date: Fri, 17 Feb 2006 22:22:58 -0800 (PST)
Subject: [Xorp-hackers] Questions on next release, puzzles and mysteries
In-Reply-To: <200602160011.k1G0BYKE036812@possum.icir.org>
Message-ID: <20060218062258.2681.qmail@web31501.mail.mud.yahoo.com>
--- Pavlin Radoslavov wrote:
> > Second, the more I look at network routing
> protocols,
> > the more protocols I find. It would be handy if
> there
> > was a page listing existant protocols, their
> > real-world scope, and their priority for being
> > implemented (NIN being for protocols that won't be
> > implemented in this lifetime, even if threatened
> with
> > a Tandy TRS-80.)
>
> This is outside the scope of XORP. Implementing even
> a single
> protocol is very time consuming so for the time
> being we have our
> hands tied with the must-have protocols like OSPF,
> etc.
I can understand that, certainly, although some kind
of central list might help encourage third-parties to
provide the additional code. Mind you, it might also
scare them off, knowing the full magnitude of the
problem space!
With most software routing abandoned, I'd rather the
XORP team focus on what can be done, rather than to
attempt the impossible.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
From krn@krn.dk Mon Feb 20 16:58:50 2006
From: krn@krn.dk (Kristen Nielsen)
Date: Mon, 20 Feb 2006 17:58:50 +0100
Subject: [Xorp-hackers] XORT-NAT: Proposal for NAT interface XIF and a config file syntaks
Message-ID: <43F9F54A.9020909@krn.dk>
This is a multi-part message in MIME format.
--------------040204020303010209060700
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi XORP Hackers.
After a long time of considerations and working on specifying a
configuratoin syntax and a XIF file for a NAT module, I am hereby
sending this proposal to the list for comments.
(Re my mail from oct 16 2005 with subject: NAT support for XORP)
20060200-NAT-interface-descr.txt file contains the syntax and a few
samples of use of the configuration format.
The nat.xif file has kdoc documentation documenting the various
functions and parameters.
The idea is to provice a common interface for the NAT module, with a
defined syntax, and then use either the native (FreeBSD natd/or the
similar functionality in linux) daemon, or a click module, with a rule
of thumb something like this:
If the nat configuration is possible to implement with the native module
this can be used, else the user must switch to the click nat module to
achieve the wanted functionality.
I have designed with the use of IP-realms (aka different ip domains)
which I am aware of is not possible to use in the standard ip stack of
Freebsd/Linux, but if one make configurations with non overlapping ip
ranges it will actually be possible to implement theese in the existing
kernel / ip stacks. The realm stuff is kept entirely in the nat config
area of the config file.
I would apreaciate comments on this, as I would like to continue
planning and coding soon.
I would also like to have ideas / comments about how to add more
datatypes to the idl generator scripts. (for the port type, and an
eventually ipv4-range type (which I here has made with 2 ipv4 ip-addresses.)
Sincerely
Mr. Kristen Nielsen
University of Copenhagen
Copenhagen
Denmark
kristen@diku.dk / krn@krn.dk
phone +4540466221 (gmt -1)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (FreeBSD)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFD+fVJe7tFxipD00wRApbiAJ9p3KmXx/FN7EUjdmMh7hi0szs4hgCgmTNb
fzLck6xcwnqSfqA3uYgrphA=
=wZHj
-----END PGP SIGNATURE-----
--------------040204020303010209060700
Content-Type: text/plain;
name="20060220-NAT-interface-descr.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="20060220-NAT-interface-descr.txt"
* Short description of the config file format for the xorp NAT module.
* Examples of configurations with alike FreeBSD natd commandline.
* Syntax of the port statement.
protocols {
nat {
disable {disabled:bool}
nat-realm {
interface vif {
description
default-vif-address:
ip-address:
tag:
interface-alias {
description:
alias-address: /* alt to more interface-alias clauses */
tag:
}
}
/* Address pool maps to the create/delete/get_nat_realm4 function) */
address-pool {
description:
ip-address:
ip-range: -
ipnet:
tag:
}
}
static-nat {
map {
description:
source {
realm:
ip-address:
ip-range: -
ipnet:
tag:
port:
}
destination {
realm:
ip-address:
ip-range: -
ipnet:
tag:
port:
}
}
}
dynamic-nat {
map {
description:
source {
realm:
ip-address:
ip-range: -
ipnet:
tag:
port:
}
destination {
realm:
ip-address:
ip-range: -
ipnet:
tag:
port:
binding:
}
}
ls-nat {
map {
description:
source {
realm:
ip-address:
ip-range: -
ipnet:
tag:
port:
}
destination {
realm:
ip-address:
ip-range: -
ipnet:
tag:
port:
}
}
}
}
}
The "port:" parameter is used to set the ports in use for an actual translation.
Syntax:
::= ports:
::=
::= [, ]...
::= |
::= tcp | udp
::=
service-name ::= ...
digits ::= ...
digit ::= <0|1|2|3|4|5|6|7|8|9>
letters ::= ...
letter ::=
Example:
ports: tcp 22,33,44-55, udp 22,33,66-77, 88
Sample configurations with similar FreeBSD natd mappings.
The FreeBSD
"natd -redirect_port tcp 172.17.16.15/telnet 6666"
command with the global ip address equal to 80.10.10.10 is expressed in XORP NAT configuration files as:
protocols {
NAT {
realm "global" {
ip: 80.10.1010
}
realm "local" {
ip: 172.17.16.15
}
static-map {
source { ip-address: 80.10.10.10
ports: tcp 6666
}
destination {
ip-address: 172.17.16.15
ports: tcp telnet
}
}
}
}
The configline:
"natd -interface em0"
Creation of a dynamic mapping from 172.17.16/24 to global address of em0 interface = ip 80.10.10.10 is expressed as:
protocols {
NAT{
realm "global" {
ip: 80.10.10.10
tag "globalip"
}
realm "local" {
ipnet: 172.17.16.0/24
tag: "localnet"}
dynamic-map {
source {tag: "localnet"
}
destination {
tag: "globalip"
}
}
}
}
Written by
Kristen Nielsen
Computer Science dept
University of Copenhagen, Denmark
kristen@diku.dk / KrN@KrN.dk
--------------040204020303010209060700
Content-Type: text/plain;
name="nat.xif"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="nat.xif"
/* xorp/xrl/interfaces/nat.xif file by KrN@KrN.DK 20060220 */
/* Suggestion to a nat interface for xorp. */
/* The following interfaces exists for the xorp nat module */
/**
* Network address translation (NAT) interface.
* The NAT module consists of the following configuration elements:
*
* set_nat_disable and get_nat_disable:
* sets and returns the status of the nat module
*
* nat_realm:
* Manages (creates/deletes/get) realms for use in nat mappings.
* Before realms can be used in configurations, they must
* be created.
*
* nat_realm_vif4:
* Manages (creates/delete/lists) vif addresses for nat use
* in nat mappings.
*
* nat_realm_alias4:
* Manages (creates/deletes/lists) alias ipv4 addresses for vif
* interfaces for use in nat mappings.
*
* nat_realm4:
* Defines ip4 addresses, ip4 networks and ip4 address ranges
* for use in nat mappings. Addresses are not directly connected
* to any vif on the xorp router. Addresses are reachable
* via the realm / vif interface stated. (This will probably be
* changed to be the interface pointed out by the next-hop entry
* in the rib.)
*
* nat_static_map4:
* Defines static NAT table mappings
* From the realm and ip definitions in the nat_realm_* group
* Tcp and/or udp port definitions can be defined here.
*
* nat_dynamic_map4:
* Defines dynamic NAT table mappings (triggers)
* From the definitions in the nat_real_* group
* Tcp and/or udp port definitions can be defined here.
*
* nat_lsnat_map4:
* Defines Load Sharing NAT mappings
* From the definitions in the nat_real_* group
* Tcp and/or udp port definitions can be defined here.
*
*/
interface nat/0.1 {
/**
* set nat disable (and enable) function
*
* @param disabled sets the status of the nat module true = disabled,
* false = enabled
* @param disabledstatus returns the status of the module,
* true = disabled, false = enabled
*/
set_nat_disable ? disabled:bool -> disabledstatus:bool
/**
* get nat status function
*
* @param disabledstatus returns the status of the module, (as the
* set_nat_disable function) true = disabled, false = enabled
*/
get_nat_disable -> disabledstatus:bool
/**
* create_nat_realm - creates a nat realm.
*
* @param realm holds the name of the realm to be created. The name
* must not exist when the call is made.
* @param descr is the textual description of the realm.
*/
create_nat_realm ? realm:txt & descr:txt
/**
* delete_nat_realm - deletes a nat realm.
*
* @param realm holds the name of the realm to be deleted. The name
* must exist when the call is made.
*/
delete_nat_realm ? realm:txt
/**
* get_nat_realm - lists nat realms.
*
* @param realm holds the name of the realm to be deleted.
* If the parameter is NULL, all existing realms is returned.
*/
get_nat_realm ? realm:txt -> realms:list
/**
* create_nat_realm_vif4 - creates an entry for the base ipv4 address
* of a virtual interface.
* Any virtual interface can at most be a member of one realm.
* Virtual interfaces must be in the same realm as the ip addresses
* passing the vif interface.
*
* @param realm is an existing realm that the vif is mapped to.
* @param ifname is the name of the physical interface where the
* vif is defined.
* @param vifname is the name of the virtual interface to be mapped.
* @param tag is a textlabel that the mapping is labeled with.
* @param description textual description of the mapping.
*/
create_nat_realm_vif4 ? realm:txt & ifname:txt & vifname:txt & \
tag:txt & description:txt
/**
* delete_nat_realm_vif4 - removes an entry for a base ipv4 (vif)
* address of virtual interface from a nat realm.
* The definitions matching all the supplied parameters is deleted.
* Wild card parameters must be set to NULL.
*
* @param realm all vif4 definitions to this realm is deleted.
* @param ifname all definitions with this ifname is deleted.
* @param vifname all mappings to this vifname is deleted
* @param tag all mappings with this tag is deleted.
*/
delete_nat_realm_vif4 ? realm:txt & ifname:txt & vifname:txt & \
tag:txt
/**
* update_nat_realm_vif4 - updates an existing vif mapping with its
* new ipv4 address.
* The vif4 mapping is updated when the vif get a new ipv4 address.
*/
update_nat_realm_vif4 ? ifname:txt & vifname:txt & ip:ipv4
/**
* get_nat_realm_vif4 - lists nat_realm_vif4 definitions.
*
* get_nat_realm_vif4 returns a list of all nat_realm_vif4
* interfaces in the router matching the realm supplied.
* @param realm specifies the realm to return interfaces for.
* If NULL then all defined nat_realm_vif4 interfaces are returned.
*/
get_nat_realm_vif4 ? realm:txt -> nat_realm_vif4s:list
/**
* create_nat_realm_alias4 - creates a mapping to the nat_realm
* definitions. Manipulates ipv4 address aliases of an interface
* (vif) for in/out going nat gateways. Aliases are not the base
* ipv4 address of the virtual interface, but ipv4 addresses in
* the same subnet as the vif. (see nat_realm_vif)
*
* Any aliases, aliased to a vif must be in the same realm as the
* vif itself.
*
* @param realm specifies the realm that the IP address belongs to.
* @param ifname is the physical interfaces for this interface
* @param vifname is the virtual interface name to add this alias to.
* @param tag is a label for grouping definitions.
* @param description is a textual description of this alias.
* @param ipaddr is the ipv4 alias address added to the vif.
*/
create_nat_realm_alias4 ? realm:txt & ifname:txt & vifname:txt & \
tag:txt & description:txt & ipaddr:ipv4
/**
* delete_realm_alias4 function
* Deletes ipv4 realm_alias4 address from the virtuel interface (vif).
*
* The alias4 mappings matching the supplied parameters are deleted.
* Parameters that are not defined (=not matched against) must be NULL.
*
* @param realm the alias4 mappings in the same realm is deleted.
* @param ifname all alias4 mappings defined for this interface is
* deleted.
* @param vifname all alias4 mappings defined under this vif is
* deleted.
* @param tag all alias4 mappings with tag is deleted.
* @param ipaddr the alias4 mapping with this ipv4 address is deleted.
*/
delete_nat_realm_alias4 ? realm:txt & ifname:txt & vifname:txt & \
tag:txt & ipaddr:ipv4
/**
* get_nat_realm_alias4 returns a nat_realm_alias4 list with matching
* alias4 elements. Wildcard parameters shuld be set to NULL.
*
* @param realm specifies the realm of the alias4 addresses to be
* returned.
* @param ifname specifies the physical interfaces to match.
* @param vifname specifies the virtual interfaces to match.
* @param tag specifies the tag of the definitions to match.
* @param ipaddr specifies the ipv4 addr of the alias4 to match.
* @param nat_realm_alias4s is the list of the matching aliases
* defined.
*/
get_nat_realm_alias4 ? realm:txt & ifname:txt & vifname:txt & \
tag:txt & ipaddr:ipv4 \
-> nat_realm_alias4s:list
/**
* create_nat_realm - create definitions of ipv4 addresses/ipv4/
* networks/ipv4 ip ranges to the nat_realm list.
*
* The ipv4 addresses / ipv4 networks / ipv4 address ranges / tagged
* list of definitions, are all ip-addresses not directly attached
* to any physical/virtual interface on the xorp router.
*
* The function have the following way of interpreting the address
* arguments:
* All function calls must have theese parameters defined:
* , where realm specifies the actural realm.
* ifname and vifname the interfaces to route these addresses through.
* (If the ifname and vifname is possible to acquire via the routing
* info, these parameters might disappear during implementation)
*
* To specify a tag for the definition, supply the parameter.
*
* To specify an single ipv4 address supply ONLY the parameter.
*
* To specify an ipv4 network supply ONLY the parameter.
*
* To specify an ipv4 range supply ONLY the and parameters.
* is the lowest ip address and ipto is the highest ip address
* in the range.
*
* The 3 types of definitions above can not be mixed in a single call
* to the function. Grouping is done with defining more of the 3
* first classes with the same tag.
*
* create_nat_realm4 create an ipv4 address/ipv4network/ipv4-range/tag
* at the nat map list.
*
* @param realm specifies the realm to which the mapping belong.
* @param tag maps the definition with this tag.
* @param description a textual description of this alias.
* @param ip is the ip address or the lowest bound of an ip range.
* @param ipto is the highest bound of a range.
* @param ipnet specifies an ipv4 network (ip address + subnetmask)
*/
create_nat_realm4 ? realm:txt & \
tag:txt & description:txt & \
ip:ipv4 & ipto:ipv4 & \
ipnet:ipv4net
/**
* delete_nat_realm4 deletes all nat_realm4 mappings, matching
* all supplied parameters. Wild card parameters must be set to NULL.
* (For further doc see add_nat_realm4)
*
* @param realm all nat_realm4 with this realm is deleted.
* @param tag all nat_realm4 definitions with this tag is deleted.
* @param ip the ipv4 address mapping is deleted. (see ipto param too)
* @param ipto the range defined together with the ip parameter is
* deleted.
* @param ipnet the ipv4network defined is deleted.
*
* If more parameters are defined, only the definitions that match
* ALL the supplied parameters is deleted.
*/
delete_nat_realm4 ? realm:txt & \
tag:txt & \
ip:ipv4 & ipto:ipv4 & \
ipnet:ipv4net
/**
* get_nat_realm4 function - returns the list of defined elements
* that matches the supplied parameters.
* (For further doc on the use see add_nat_realm4 the doc.)
* Wildcard parameters must be set to NULL.
*
* @param realm returns the list of realm4 definitions for this realm.
* @param tag returns the list of definitions tagged with this tag.
* @param ip returns the list of definitions with this ipv4 address.
* @param ipto returns the list of definitions with this ipv4 range.
* @param ipnet returns the list of ipv4 networks defined.
* @param nat_realm4s is a list of the matched definitions.
*/
get_nat_realm4 ? realm:txt & \
tag:txt & description:txt & \
ip:ipv4 & ipto:ipv4 & \
ipnet:ipv4net -> nat_realm4s:list
/**
* create_nat_static_map4
*
* create_nat_static_map4 - defines static NAT table entries from the
* ip definitions from the nat_realm* functions.
*
* The nat_static_map functions defines static nat mappings between
* ip addresses at the source side realm and the ip addresses of
* the destination side realm.
* If the ip sizes of the ranges on either side of the mapping is not
* equal, then the mappings must go from the source side realm
* (aka local realm) to the destination side realm (aka global realm).
* ip addresses that is used for TCP/UDP port mapping
* (port overloading) must always be defined at the destination side.
*
* The nat_static_map function has more sub functions dependent of
* the supplied parameters. The parameters can define either a single
* ip address, a contiguous range of ip addresses or a sub net, or a
* tagged set of definitions. The ip addresses and realm used in a map
* statement must be defined in a nat_realm* clause.
* The source and destination side of a mapping can take all 4 forms
* from the following definitions.
*
* To specify a single ip address the ip parameter is used. The
* ipto paramter must be NULL.
*
* To specify a contiguous range of IP addresses, the ip and ipto
* parameters are used. The ipnet parameter must be NULL.
*
* To specify an ipnetwork, the ipnet parameters must be specified.
* The ipnet takes a subnet-address and a submet-mask. The ip and ipto
* parameters must be NULL.
*
* To use a tag from the nat_realm definitions, specify the tag at
* the tag parameter. The ip, ipto and ipnet parameters must be NULL.
*
* @param srcrealm specifies the realm for the source side of the map.
*
* @param destrealm specifies the realm for the destination side
* of the map.
*
* @param srcip is the ipv4 source ip address of a mapping.
*
* @param srcipto is the source ipv4 address that forms the upper
* bound of an ip range.
*
* @param srcipnet is the ipv4 network which forms the source mapping.
* bound of an ip range.
*
* @param srctag maps all nat_realm definitions with the same tag as
* the source definition.
*
* @param srcport is the range of ports used to this mapping.
*
* @param destip is the ipv4 destination address of the mapping
*
* @param destipto is the ipv4 address that forms the upper bound of
* the destination ip range.
*
* @param destipnet is the ipv4 network that is the destination ip
* addresses for the mapping.
*
* @param desttag maps all nat_realm definitions with the same tag as
* the destination definition.
*
* @param destport is a list of tcp and/or udp ports used at the
* destination addresses.
*
*/
create_nat_static_map4 ? description:txt & \
srcrealm:txt & \
srcip:ipv4 & srcipto:ipv4 & \
srcipnet:ipv4net & \
srctag:txt & \
srcport:ipv4ports & \
destrealm:txt & \
destip:ipv4 & destipto:ipv4 & \
destipnet:ipv4net & \
desttag:txt & \
destport:ipv4ports
/**
* delete_nat_static_map4
*
* delete_nat_static_map4 - delete static nat table entries from the
* ip definitions from the nat_static_map4 functions.
*
* The function deletes the nat_static_map4 entries that matches
* all the supplied parameters. (for more information about the
* interfaces see create_nat_static_map4 documentation)
*
* The selected ranges must be fully matching sets from the
* create_nat_static_map4 definition. No internal ranges can be deleted.
*
* @param srcrealm specifies the source realm to be deleted. All
* nat_static_map4 definitions with the same realm is selected.
*
* @param destrealm specifies the realm for the destination side
* to be deleted. All nat_static_map4 definitions with the same realm
* is selected.
*
* @param srcip is the ipv4 source ip address to be deleted.
*
* @param srcipto is together with the srcip parameter defines the
* source ip range to be deleted.
*
* @param srcipnet is the ipv4 network source mapping to be deleted.
*
* @param srctag maps selects the source tags to be deleted.
*
* @param srcport is the range of tcp and/or udp ports to be deleted.
*
* @param destip is the ipv4 destination address to be deleted.
*
* @param destipto is together with the destip parameter defines
* the destination ip range to be deleted.
*
* @param destipnet is the ipv4 network to be deleted.
*
* @param desttag maps defines the destination tags to be deleted.
*
* @param destport is a list of tcp and/or udp ports to be deleted.
*/
delete_nat_static_map4 ? srcrealm:txt & \
srcip:ipv4 & srcipto:ipv4 & \
srcipnet:ipv4net & \
srctag:txt & \
srcport:ipv4ports & \
destrealm:txt & \
destip:ipv4 & destipto:ipv4 & \
destipnet:ipv4net & \
desttag:txt & \
destport:ipv4ports
/**
* get_nat_static_map4 - lists nat_static_map4 entries.
*
* get_nat_static_map4 - lists static NAT table entries that matches
* the supplied parameters.
*
* The function deletes the nat_static_map4 entries that is matches
* all the supplied parameters.
* (for more information about the interfaces see
* create_nat_static_map4 documentation)
*
* @param srcrealm specifies the source realm to be listed.
*
* @param destrealm specifies the realm for the destination side
* to be listed.
*
* @param srcip is the ipv4 source ip address to be listed.
*
* @param srcipto is together with the srcip parameter defines the
* source ip range to be listed.
*
* @param srcipnet is the ipv4 network source to be listed.
*
* @param srctag maps selects the srctags to be listed.
*
* @param srcport is the range of tcp and/or udp ports to be delted.
*
* @param destip is the ipv4 destination address to be listed.
*
* @param destipto is together with the destip parameter defines
* the destination ip range to be listed.
*
* @param destipnet is the ipv4 network to be listed.
*
* @param desttag maps defines the destination tags to be listed.
*
* @param nat_static_map4s contains the list of matched elements.
*
* @param destport is a list of tcp and/or udp ports to be matched.
*/
get_nat_static_map4 ? description:txt & \
srcrealm:txt & \
srcip:ipv4 & srcipto:ipv4 & \
srcipnet:ipv4net & \
srctag:txt & \
srcport:ipv4ports & \
destrealm:txt & \
destip:ipv4 & destipto:ipv4 & \
destipnet:ipv4net & \
destport:ipv4ports & \
desttag:txt -> nat_static_map4s:list
/**
* create_nat_dynamic map definitions.
*
* The nat_static_map functions defines static mappings between
* IP addresses at the source side realm and the IP addresses of
* the destination side realm.
* If the IP sizes of the ranges on either side is not equal,
* then the mappings must go from the source side realm
* (aka local realm) and the destination side realm (aka global realm).
* IP addresses that is used for TCP/UDP port mapping
* (port overloading) must be defined on the destination side.
*
* @param srcrealm specify the network realm for the source part
* of the mapping.
*
* @param srctag maps the nat_realm* definitions with this tag as
* the source side of the mapping. The tagged definitions must belong
* to the same realm as stated in srcrealm. If the special meaning
* tag "all" is given then all the definitions in the nat_realm
* with the same realm as stated in srcrealm is matched.
*
* Src or dest definitions defults to "all" which is all addresses
* in the matching (src/dest) realm as defined in nat_realm_* group.
*
* @param srcip is the ipv4 source ip address of a mapping.
*
* @param srcipnet is the ipv4 network which forms the source mapping.
*
* @param scrip is the source ipv4 address that forms the lower bound
* of an ip range.
*
* @param srcipto is the source ipv4 address that forms the upper
* bound of an ip range.
*
* @param srcport is the range of tcp and/or udp ports to be used in
* the mapping.
*
* @param destip is the ipv4 destination address of the mapping
*
* @param destipnet is the ipv4 network that is the destination ip
* addresses for the mapping.
*
* @param destip is the ipv4 address that forms the lower bound of the
* destination ip range.
*
* @param destipto is the ipv4 address that forms the upper bound of
* the destination ip range.
*
* @param desttag maps the nat_realm* definitions with this tag as
* the destination side of the mapping. The tagged definitions must
* belong to the same realm as stated in srcrealm. If the special
* meaning tag "all" is given then all the definitions in the nat_realm
* with the same realm as stated in srcrealm is matched.
*
* @param destport is a list of tcp and/or udp ports to use for the
* dynamic mapping.
*
* @param binding This argument can be "dynamic" (default) or "fixed"
* Dynamic can be a new mapping each time the mapping is used for a
* new connection (from src side). "fixed" is using the same source
* and destination mapping each time the src ip/port is connecting.
*/
create_nat_dynamic_map4 ? description:txt & \
srcrealm:txt & \
srcip:ipv4 & srcipto:ipv4 & \
srcipnet:ipv4net & \
srctag:txt & \
srcport:ipv4ports & \
destrealm:txt & \
destip:ipv4 & destipto:ipv4 & \
destipnet:ipv4net & \
desttag:txt & \
destport:ipv4ports & \
binding:txt
/**
* delete_nat_dynamic_map4
*
* The delete_nat_dynamic_map4 function deletes the elements from the
* nat_dynamic_map4 table that matches the supplied parameters.
*
* @param srcrealm matches source realm parameter of mappings.
*
* @param srctag matches the source tag paramter of the mappings to
* be deleted.
* If the special meaning tag "all" is given then all the definitions
* with this tag on the source side is matched. With the same realm
* as stated in srcrealm is matched.
*
* @param srcip matches the ipv4 source ip, or the lower bound of an
* ipv4 ip-range to be deleted.
*
* @param srcipto matches the source ipv4 address that forms the upper
* bound of an ip range to be deleted.
*
* @param srcipnet matches the source ipv4 network to be deleted.
*
* @param srcport is the tcp and/or udp port range to be deleted.
*
* @param destip matches the ipv4 destination address of the mapping
* or the ipv4 address that forms the lower bound of the destination
* ip range.
*
* @param destipto matches the destination ipv4 address to be deleted.
*
* @param destipnet matches the destination ipv4 network.
*
* @param desttag maps the mappings with this tag as the destination
* side of the mapping. The tagged definitions must belong to the
* same realm as stated in srcrealm. If the special
* meaning tag "all" is given then all the definitions in the
* nat_dynamic_realm with the same source realm as stated in srcrealm
* is matched.
*
* @param destport is a list of tcp and/or udp ports to be deleted.
*
* @param binding This argument can be "dynamic" (default) or "fixed"
* Dynamic can be a new mapping each time the mapping is used for a
* new connection (from src side). "fixed" is using the same source
* and destination mapping each time the src ip/port is connecting.
*/
delete_nat_dynamic_map4 ? srcrealm:txt & \
srcip:ipv4 & srcipto:ipv4 & \
srcipnet:ipv4net & \
srctag:txt & \
srcport:ipv4ports & \
destrealm:txt & \
destip:ipv4 & destipto:ipv4 & \
destipnet:ipv4net & \
desttag:txt & \
destport:ipv4ports & \
binding:txt
/**
* get_nat_dynamic_map4
*
* The get_nat_dynamic_map4 function returns the elements from the
* nat_dynamic_map4 table that matches all the supplied parameters.
*
* @param srcrealm matches source realm parameter of the mappings.
*
* @param srctag matches the source tag parameter of the mappings.
* If the special meaning tag "all" is given then all the definitions
* with this tag on the source side is matched. With the same realm
* as stated in srcrealm is matched.
*
* @param srcip matches the ipv4 source ip, or the lower bound of an
* ipv4 ip-range.
*
* @param srcipto matches the source ipv4 address that forms the upper
* bound of an ip range.
*
* @param srcipnet matches the source ipv4 network.
*
* @param srcport is the tcp and/or udp range to be returned.
*
* @param destip matches the ipv4 destination address of the mapping
* or the ipv4 address that forms the lower bound of the destination
* ip range.
*
* @param destipto matches the destination ipv4 address.
*
* @param destipnet matches the destination ipv4 network.
*
* @param desttag maps the mappings with this tag as the destination
* side of the mapping. The tagged definitions must belong to the
* same realm as stated in srcrealm. If the special
* mening tag "all" is given then all the definitions in the
* nat_dynamic_realm with the same source realm as stated in srcrealm
* is matched.
*
* @param destport is a list of tcp and/or udp ports to be returned.
*
* @param binding This argument can be "dynamic" (default) or "fixed"
* Dynamic can be a new mapping each time the mapping is used for a
* new connection (from src side). "fixed" is using the same source
* and destination mapping each time the src ip/port is connecting.
*/
get_nat_dynamic_map4 ? description:txt & \
srcrealm:txt & \
srcip:ipv4 & srcipto:ipv4 & \
srcipnet:ipv4net & \
srctag:txt & \
srcport:ipv4ports & \
destrealm:txt & \
destip:ipv4 & destipto:ipv4 & \
destipnet:ipv4net & \
desttag:txt & \
destport:ipv4ports & \
binding:txt -> nat_dynamic_map4s:list
/**
* lsnat_map functions - define Load Sharing NAT (LSNAT) functionality.
*
* lsnat_map defines hosts at the destination side which is to be
* loadshared when accesses via a common global address and port,
* defined at the source side.
*
* The lsnat_map function has a range of ways to define ipv4 addresses,
* ipv4 networks and ipv4 ip address ranges.
* The parameters can define either a single ip address, a contigous
* range of IP addresses or a subnet, or a tag.
* The source and destination side of a mapping can each take all
* 4 forms.
*
* To specify an single ip address the ip parameter is used. The
* ipto paramter must be NULL.
*
* To specify a contiguous range of IP addresses, the ip and ipto
* parameters are used. The ipnet parameter must be NULL.
*
* To specify an ipnetwork, the ipnet parameters must be specified.
* The ipnet takes a sub net-address and a sub net-mask. The ip and ipto
* parameters must be NULL.
*
* To use a named tag from the nat_realm definitions, specify the tag
* at the tag parameter. The ip, ipto and ipnet parameters must be
* NULL. Tags with the special value "all" matches all defined
* addresses in the same realm as the tag.
*
* @param srcrealm defines which realm the source addresses belongs
* to. The common ip addresses to access the load shared services must
* be load shared must be connected to the source side of the map.
*
* @param destrealm defines which realm the destination addresses
* belongs to (host network realm). The ip addresses of the hosts
* with the services to be load shared is on this realm.
*
* @param srcip is the ipv4 source ip address of a mapping.
*
* @param srcipto is the source ipv4 address that forms the upper
* bound of an ip range.
*
* @param srcipnet is the ipv4 network which forms the source mapping.
* bound of an ip range.
*
* @param srctag maps all nat_realm definitions with the same tag as
* the source definition. The special tag value "all" matches all
* definitions from the nat_realm with the same realm.
*
* @param srcport is the list of tcp and/or udp ports to created.
*
* @param destip is the ipv4 destination address of the mapping
*
* @param destipto is the ipv4 address that forms the upper bound of
* the destination ip range.
*
* @param destipnet is the ipv4 network that is the destination ip
* addresses for the mapping.
*
* @param desttag maps all nat_realm definitions with the same tag as
* the destination definition. The special tag value "all" matches all
* definitions from the nat_realm with the same realm.
*
* @param destport is the tcp and/or udp port to load share.
*
* @param lsalgorithm defines the load sharing algorithm, and takes
* the values: round-robin, random, (more ?), ...
*
*/
/**
* create_lsnat_map4 function -
* Creates a lsnat_map4 table entry to the nat mappings.
*/
create_lsnat_map4 ? description:txt & \
srcrealm:txt & \
srcip:ipv4 & srcipto:ipv4 & \
srcipnet:ipv4net & \
srctag:txt & \
srcport:ipv4ports & \
destrealm:txt & \
destip:ipv4 & destipto:ipv4 & \
destipnet:ipv4net & \
desttag:txt & \
destport:ipv4ports & \
lsalgorithm:txt
/**
* delete_lsnat_map4 function -
* Deletes the lsnat_map4 tableentries from the nat mappings that
* matches all the defined parameters.
*/
delete_lsnat_map4 ? srcrealm:txt & \
srcip:ipv4 & srcipto:ipv4 & \
srcipnet:ipv4net & \
srctag:txt & \
srcport:ipv4ports & \
destrealm:txt & \
destip:ipv4 & destipto:ipv4 & \
destipnet:ipv4net & \
desttag:txt & \
destport:ipv4ports & \
/**
* get_lsnat_map4 function -
* Lists lsnat_map4 table entries that matches all the defined the
* parameters.
*/
get_lsnat_map4 ? description:txt & \
srcrealm:txt & \
srcip:ipv4 & srcipto:ipv4 & \
srcipnet:ipv4net & \
srctag:txt & \
srcport:ipv4ports & \
destrealm:txt & \
destip:ipv4 & destipto:ipv4 & \
destipnet:ipv4net & \
desttag:txt & \
destport:ipv4ports & \
lsalgorithm:txt -> lsnat_map4s:list
}
--------------040204020303010209060700--
From pavlin@icir.org Tue Feb 21 20:17:33 2006
From: pavlin@icir.org (Pavlin Radoslavov)
Date: Tue, 21 Feb 2006 12:17:33 -0800
Subject: [Xorp-hackers] Questions on next release, puzzles and mysteries
In-Reply-To: Message from Jonathan Day
of "Fri, 17 Feb 2006 22:22:58 PST." <20060218062258.2681.qmail@web31501.mail.mud.yahoo.com>
Message-ID: <200602212017.k1LKHXNb096545@possum.icir.org>
> > > Second, the more I look at network routing
> > protocols,
> > > the more protocols I find. It would be handy if
> > there
> > > was a page listing existant protocols, their
> > > real-world scope, and their priority for being
> > > implemented (NIN being for protocols that won't be
> > > implemented in this lifetime, even if threatened
> > with
> > > a Tandy TRS-80.)
> >
> > This is outside the scope of XORP. Implementing even
> > a single
> > protocol is very time consuming so for the time
> > being we have our
> > hands tied with the must-have protocols like OSPF,
> > etc.
>
> I can understand that, certainly, although some kind
> of central list might help encourage third-parties to
> provide the additional code. Mind you, it might also
> scare them off, knowing the full magnitude of the
> problem space!
>
> With most software routing abandoned, I'd rather the
> XORP team focus on what can be done, rather than to
> attempt the impossible.
Probably I am misunderstanding your original question, but there is
already a "Contributing" web page that lists various suggestions for
code contribution: http://www.xorp.org/contributing.html
In addition, below is the list of protocols we are planning to work
on in the fiture (in no particular order):
* IS-IS
* IGMPv3/MLDv2
* Bidirectional PIM-SM
FYI, this info was on the Roadmap web page, but it is temporarily
commented-out until various other things are sorted-out.
Please let us know if the above information does not answer your
question or if you prefer, say, that the Roadmap contains some more
specific info (including long-term plans).
Pavlin
From atanu@ICSI.Berkeley.EDU Thu Feb 23 04:01:13 2006
From: atanu@ICSI.Berkeley.EDU (Atanu Ghosh)
Date: Wed, 22 Feb 2006 20:01:13 -0800
Subject: [Xorp-hackers] Announcing XORP Release Candidate 1.2
Message-ID: <85266.1140667273@tigger.icir.org>
On behalf of the entire XORP team, I'm delighted to announce the XORP
1.2 Release Candidate, which is now available from .
Once the release candidate has proven to be stable, the actual 1.2
release will be prepared. This is planned to occur in the next two
weeks. In the intervening period we will be fixing minor problems and
updating the documentation.
There are still a number of non-critical bugs that we know about which
will not be addressed until the 1.3 release; these are documented in
the errata section below.
In general, to test XORP, we run automated regression tests on a daily
basis with various operating systems and compilers. We also run a
number of PCs as XORP routers. We have enabled as many protocols as
feasible on those routers to test protocol interactions (for example a
BGP IPv6 multicast feed being used by PIM-SM). In addition, automated
scripts are run to externally toggle BGP peerings. Finally, we have
automated scripts that interact directly with the xorpsh to change the
configuration settings.
We have put significant effort into testing but obviously we have not
found all the problems. This is where you can help us to make XORP
more stable, by downloading and using it!
As always we'd welcome your comments - xorp-users@xorp.org is the
right place for general discussion, and private feedback to the XORP
core team can be sent to feedback@xorp.org.
- The XORP Team
P.S.
Release notes and errata are included below.
------------------------------------------------------------------
XORP RELEASE NOTES
Release 1.2-RC (2006/02/22)
=========================
ALL:
[Note: this is XORP-1.2-RC release candidate and not all documentation
is up to date. Also, the list below with the changes since the XORP-1.1
release is incomplete.]
- Many improvements, bug fixes and cleanup.
- The third-party ospfd implementation is replaced with a new
OSPF implementation developed from scratch.
CONFIGURATION:
- Addition of new interface related configuration statement:
* restore-original-config-on-shutdown:
This optional statement is used to enable the restoring of the
original network interface information on shutdown.
- Addition of new PIM-SM related configuration statements:
* enable-ip-router-alert-option-check:
This optional statement is used to enable the IP Router Alert option
check per virtual interface.
* cand-bsr-by-vif-addr:
and
* cand-rp-by-vif-addr:
Those optional statements are used together with cand-bsr-by-vif-name
and cand-rp-by-vif-name respectively to specify the particular
IP address on the configured vif. If they are omitted, a domain-wide
address (if exists) that belongs to that interface is chosen by the
router itself.
* hello-period:
This optional statement is used to configure the PIM Hello messages
period (in seconds).
* hello-triggered-delay:
This optional statement is used to configure the randomized triggered
delay of the PIM Hello messages (in seconds).
- Addition of new MLD/IGMP related configuration statements:
* version:
This optional statement is used to configure the MLD/IGMP
protocol version per virtual interface.
* enable-ip-router-alert-option-check:
This optional statement is used to enable the IP Router Alert option
check per virtual interface.
* query-interval:
This optional statement is used to specify (per virtual interface)
the interval between general queries.
* query-last-member-interval:
This optional statement is used to specify (per virtual interface)
the maximum response time inserted into group-specific queries sent
in response to leave group messages.
* query-response-interval:
This optional statement is used to specify (per virtual interface)
the maximum response time inserted into the periodic general queries.
* robust-count:
This optional statement is used to specify (per virtual interface)
the robustness variable count that allows tuning for the expected
packet loss on a subnet.
- Addition of support for user environmental variables CFLAGS_END and
CXXFLAGS_END. Those variables can be used to specify the compiler
flags (for the C and C++ compiler respectively) that must be after
all other flags.
LIBXORP:
- Various improvements in the RunCommand implementation.
LIBXIPC:
- No significant changes.
LIBFEACLIENT:
- No significant changes.
XRL:
- No significant changes.
RTRMGR:
- Generalization of the %mandatory keyword syntax so now it can
be used to specify any node or variable (multi-value nodes excluded)
in the configuration tree. Previously it could be used to specify
only configuration child nodes or variables.
- Addition of support for read-only, permanent and user-hidden nodes
(specified respectively by the new %read-only, %permanent and
%user-hidden template commands).
- Modification of the %allow and %allow-range semantics so a help string
can be supplied for each allowed value or range.
- Removal of the mechanism for specifying the hook for saving
a configuration file (the "-s " command-line argument).
The mechanism is broken and is superseded by the rtrmgr template
support for running external programs.
- Various other improvements and bug fixes.
XORPSH:
- Addition of support to run xorpsh in non-interactive mode.
- Modification of the configurational mode "show" command
so now it displays parameters only if their value is not
same as the default value.
- Addition of command "show -all" that shows the complete configuration
including the parameters with default values.
- Modification to the "show" command output: in configuration mode
all deleted (and uncommitted) entries are prefixed with "-".
- Modification of the default operational and configuration mode
prompts to "user@hostname> " and "user@hostname# " respectively.
- Addition of support to modify the operational and configuration
mode prompts by environmental variables
XORP_PROMPT_OPERATIONAL and XORP_PROMPT_CONFIGURATION
respectively.
- Addition of support for command-line completion for allowed values.
- Various other improvements and bug fixes.
POLICY:
- Several bug fixes.
FEA/MFEA:
- Addition of RawSocket{4,6} generic abstraction that is not
multicast-specific.
RIB:
- Addition of support for displaying the routing tables in brief,
detailed and terse format. The default format is "brief".
RIP:
- The syntax for configuring the authentication mechanism has changed:
OLD:
authentication {
type: "plaintext"
password: "FOO"
}
OR
authentication {
type: "md5"
password: "FOO"
}
NEW:
authentication {
simple-password: "FOO"
}
OR
authentication {
md5 1 { /* KeyID: [0, 255] */
password: "FOO"
start-time: "YYYY-MM-DD.HH:MM"
end-time: "YYYY-MM-DD.HH:MM"
}
}
- Several bug fixes.
OSPF:
- Initial implementation of OSPF that replaces the third-party ospfd.
BGP:
- The network4/network6 directives have been deprecated.
If you wish to inject static routes into BGP, you must now add
these routes to the static_routes protocol block, and then configure
the policy engine to redistribute them to BGP.
- Proper support for policy filters.
- Addition of support for route flap damping.
- Addition of support for route aggregation.
- Addition of support for route reflection.
- Addition of support for confederations.
- Bug fix to correctly handle connection collisions.
- Addition of default support for NO_EXPORT, NO_ADVERTISE, and
NO_EXPORT_SUBCONFED well-known communities.
- Addition of the capability to reconfigure a peering (e.g., from IBGP to
EBGP) which requires re-configuring the default filters.
- Numerous bug fixes that should greatly improve stability.
STATIC_ROUTES:
- Several bug fixes.
MLD/IGMP:
- No significant changes.
PIM-SM:
- Updated to support the lastest PIM-SM specification
(draft-ietf-pim-sm-v2-new-11.{ps,txt}).
- Addition of support to disable the "wrong iif" kernel upcall on
interfaces we don't need to monitor.
- Bug fix related to the handling of the deleted MRIB entries.
- Bug fix related to transmitting AssertCancel message when
a PIM configured interface is gracefully shutdown.
FIB2MRIB:
- No significant changes.
CLI:
- Various improvements and bug fixes.
SNMP:
- No significant changes.
------------------------------------------------------------------
XORP ERRATA
ALL:
- Parallel building (e.g., "gmake -j 4") may fail on multi-CPU machines.
The simplest work-around is to rerun gmake or not to use the -j flag.
- The following compiler is known to be buggy, and should not be used
to compile XORP:
gcc34 (GCC) 3.4.0 20040310 (prerelease) [FreeBSD]
A newer compiler such as the following should be used instead:
gcc34 (GCC) 3.4.2 20040827 (prerelease) [FreeBSD]
- If you run BGP, RIB, FIB2MRIB, and PIM-SM at the same time,
the propagation latency for the BGP routes to reach the kernel
is increased. We are investigating the problem.
LIBXORP:
- No known issues.
LIBXIPC:
- No known issues.
LIBFEACLIENT:
- No known issues.
XRL:
- No known issues.
RTRMGR:
- There are several known issues, but none of them is considered critical.
The list of known issues is available from
http://www.xorp.org/bugzilla/query.cgi
- Using the rtrmgr "-r" command-line option to restart processes that
have failed does not work if a process fails while being reconfigured
via xorpsh. If that happens, the rtrmgr itself may coredump.
Therefore, using the "-r" command-line option is not recommended!
Also, note that a process that has been killed by SIGTERM or SIGKILL
will not be restarted (this is a feature rather than a bug).
Ideally, we want to monitor the processes status using the finder
rather than the forked children process status, therefore in
the future when we have a more robust implementation the "-r"
switch will be removed and will be enabled by default.
XORPSH:
- There are several known issues, but none of them is considered critical.
The list of known issues is available from
http://www.xorp.org/bugzilla/query.cgi
FEA/MFEA:
- On Linux with kernel 2.6 (e.g., RedHat FC2 with kernel 2.6.5-1.358),
some of the tests may fail (with or without an error message),
but no coredump image. Some of those failures can be contributed
to a kernel problem. E.g., running "dmesg can show kernel
"Oops" messages like:
Unable to handle kernel NULL pointer dereference at virtual address 00000000
printing eip:
02235532
*pde = 00000000
Oops: 0000 [#15]
CPU: 0
EIP: 0060:[<02235532>] Not tainted
EFLAGS: 00010202 (2.6.5-1.358)
EIP is at __dev_get_by_index+0x14/0x2b
eax: 022db854 ebx: 1ae7aef8 ecx: 00000001 edx: 00000000
esi: 00000000 edi: 00008910 ebp: fee43e9c esp: 1ae7aef0
ds: 007b es: 007b ss: 0068
Process test_finder_eve (pid: 2026, threadinfo=1ae7a000 task=1406d7b0)
Stack: 022365c7 00000000 009caffc 009cc780 0969ef28 fee43edc 00000001 009cc780
0969ef28 fee43ed8 00008910 00000000 00008910 fee43e9c 02236e50 fee43e9c
07aa4e00 3530355b 5d303637 00000000 0227a55b 021536b6 022cfa00 00000001
Call Trace:
[<022365c7>] dev_ifname+0x30/0x66
[<02236e50>] dev_ioctl+0x83/0x283
[<0227a55b>] unix_create1+0xef/0xf7
[<021536b6>] alloc_inode+0xf9/0x175
[<0227c090>] unix_ioctl+0x72/0x7b
[<022301a5>] sock_ioctl+0x268/0x280
[<0223054f>] sys_socket+0x2a/0x3d
[<0214ea0e>] sys_ioctl+0x1f2/0x224
Code: 0f 18 02 90 2d 34 01 00 00 39 48 34 74 08 85 d2 89 d0 75 ea
This appears to be a kernel bug triggered by ioctl(SIOCGIFNAME)
which itself is called by if_indextoname(3). Currently, there
is no known solution of the problem except to use a kernel that does
not have the problem (at this stage it is not known whether all
2.6 Linux kernels are affected or only specific versions).
It seems that a very similar problem has been reported to the
Linux kernel developers, but the problem is still unsolved:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121697
- The mechanism for tracking the network interface link status
may not work for the following OS-es because the kernel for those
systems does not provide a mechanism for asynchronous notification
of userland programs when the link status changes:
FreeBSD-5.2 and earlier and MacOS X (note: if the Windows kernel
supports this feature, it is not used yet in XORP).
Though, for those systems the link status should be read
properly on startup.
RIB:
- In some rare cases, the RIB may fail to delete an existing route
(See http://www.xorp.org/bugzilla/show_bug.cgi?id=62).
We are aware of the issue and will attempt to fix it in the future.
RIP:
- No known issues.
OSPF:
- There are several known issues, but none of them is considered critical.
The list of known issues is available from
http://www.xorp.org/bugzilla/query.cgi
BGP:
- If the RIB bug above (failure to delete an existing route) is
triggered by BGP, then the deletion failure error received by
BGP from the RIB is considered by BGP as a fatal error.
This is not a BGP problem, but a RIB problem that will be fixed
in the future.
- The BGP configuration mandates that an IPv4 nexthop must be supplied.
Unfortunately it is necessary to provide an IPv4 nexthop even for an
IPv6 only peering. Even more unfortunately it is not possible to force
the IPv6 nexthop.
- It is *essential* for an IPv6 peering that an IPv6 nexthop is provided.
Unfortunately the configuration does not enforce this requrement.
This will be fixed in the future.
STATIC_ROUTES:
- No known issues.
MLD/IGMP:
- If MLD/IGMP is started with a relatively large number of interfaces
(e.g., on the order of 20), then it may fail with the following error:
[ 2004/06/14 12:58:56 ERROR test_pim:16548 MFEA +666
mfea_proto_comm.cc join_multicast_group ] Cannot join group 224.0.0.2
on vif eth8: No buffer space available
The solution is to increase the multicast group membership limit.
E.g., to increase the value from 20 (the default) to 200, run as a root:
echo 200 > /proc/sys/net/ipv4/igmp_max_memberships
PIM-SM:
- If the kernel does not support PIM-SM, or if PIM-SM is not enabled
in the kernel, then running PIM-SM will fail with the following
error message:
[ 2004/06/12 10:26:41 ERROR xorp_fea:444 MFEA +529 mfea_mrouter.cc
start_mrt ] setsockopt(MRT_INIT, 1) failed: Operation not supported
- On Linux, if the unicast Reverse Path Forwarding information is
different from the multicast Reverse Path Forwarding information,
the Reverse Path Filtering should be disabled. E.g., as root:
echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
OR
echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/eth1/rp_filter
...
Otherwise, the router will ignore packets if they don't arrive on
the reverse-path interface.
For more information about Reverse Path Filtering see
http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.kernel.rpf.html
- Currently, the PIM-SM implementation does not support unnumbered
point-to-point links. Furthermore, even on numbered point-to-point
links the next-hop information in the routing entries should use
an IP address instead of an interface name. For example,
if we have a GRE tunnel on Linux and if we want to add a route
that uses that tunnel, we should use a command like:
route add -net gw
instead of
route add -net
FIB2MRIB:
- No known issues.
CLI:
- No known issues.
SNMP:
- On some versions of Linux, there are some bugs in net-snmp versions
5.0.8 and 5.0.9, which prevent dynamic loading from working.
See http://www.xorp.org/snmp.html for links to the net-snmp patches
that solve the problems.
- Version 5.1 of net-snmp requires a simple modification, otherwise
XORP will fail to compile.
See http://www.xorp.org/snmp.html for a link to the net-snmp patch
that solves the problems.
From hasso@linux.ee Thu Feb 23 13:11:22 2006
From: hasso@linux.ee (Hasso Tepper)
Date: Thu, 23 Feb 2006 15:11:22 +0200
Subject: [Xorp-hackers] Some performance numbers
Message-ID: <200602231511.22908.hasso@linux.ee>
I have played with BGP full feed during last days and found out that
unfortunately performance isn't acceptable for real world usage. Tests
have been done with 1.8 Pentium M (speed-step off) laptop 512MB memory.
One eBGP multihop peer announcing full table. For nexthop resolving static
the default route is entered into Xorp.
Peer up without static default route (no routes installed into RIB):
********************************************************************
It takes about 4 seconds to receive full table, xorp_bgp takes about 90MB
of memory after this. Not very bad IMHO.
Peer up with static default route (routes installed into RIB and FIB):
**********************************************************************
It takes about 60 seconds to receive full table and to put routes into
RIB/FIB, xorp_bgp takes about 100MB of memory after this. Memory usage is
still acceptable, but 60 seconds is certainly very far from being
acceptable.
Peer down with static default route (routes removed from RIB and FIB):
**********************************************************************
Just entered "disable: true" into peer config and committed. It takes
about 4 minutes and 40 seconds to remove all routes from RIB and FIB.
This isn't acceptable at all of course.
I wouldn't expect from Xorp instant failover and peer up/down times like
hardware router vendors can achieve. They have many tricks in use which
are not available for software routers. But it should be certainly happen
during max some seconds, not minutes.
Questions ... Is anyone aware of problem? Is it BGP or RIB or IPC or ...
problem? Is it worth of effort to open bugreport regarding this? Can I
help with something? I'm not familiar enough with design of XORP and C++
coding yet to solve design related problems though yet. But I have
environment and can profile (direction, please?), test patches etc.
regards,
--
Hasso Tepper
From zec@icir.org Fri Feb 24 18:41:11 2006
From: zec@icir.org (Marko Zec)
Date: Fri, 24 Feb 2006 19:41:11 +0100
Subject: [Xorp-hackers] Some performance numbers
In-Reply-To: <200602231511.22908.hasso@linux.ee>
References: <200602231511.22908.hasso@linux.ee>
Message-ID: <200602241941.11934.zec@icir.org>
On Thursday 23 February 2006 14:11, Hasso Tepper wrote:
> I have played with BGP full feed during last days and found out that
> unfortunately performance isn't acceptable for real world usage.
> Tests have been done with 1.8 Pentium M (speed-step off) laptop 512MB
> memory. One eBGP multihop peer announcing full table. For nexthop
> resolving static the default route is entered into Xorp.
>
> Peer up without static default route (no routes installed into RIB):
> ********************************************************************
> It takes about 4 seconds to receive full table, xorp_bgp takes about
> 90MB of memory after this. Not very bad IMHO.
Unfortunately at the moment we are roughly an order of magnitude slower
than this, something must went wrong with your measurements. On a 3.4
GHz Pentium 4 receiving ~180k routes into xorp_bgp (while not
propagating any of them to the RIB/FIB) lasts around 42 seconds. The
OS is FreeBSD 4.11 FWIW.
> Peer up with static default route (routes installed into RIB and
> FIB):
> *********************************************************************
>* It takes about 60 seconds to receive full table and to put routes
> into RIB/FIB, xorp_bgp takes about 100MB of memory after this. Memory
> usage is still acceptable, but 60 seconds is certainly very far from
> being acceptable.
>
> Peer down with static default route (routes removed from RIB and
> FIB):
> *********************************************************************
>* Just entered "disable: true" into peer config and committed. It
> takes about 4 minutes and 40 seconds to remove all routes from RIB
> and FIB. This isn't acceptable at all of course.
>
> I wouldn't expect from Xorp instant failover and peer up/down times
> like hardware router vendors can achieve. They have many tricks in
> use which are not available for software routers. But it should be
> certainly happen during max some seconds, not minutes.
>
> Questions ... Is anyone aware of problem? Is it BGP or RIB or IPC or
> ... problem? Is it worth of effort to open bugreport regarding this?
While it looks like our IPC is quite inefficient at the moment and
contributes most to the overall system slowness, there's also
significant room for improvement inside the BGP implementation itself,
such as path attributes handling code. We have some minor tweaks in
the pipeline waiting for a stable release to be rolled out first, but
are just starting to track down the IPC issues.
> Can I help with something? I'm not familiar enough with design of
> XORP and C++ coding yet to solve design related problems though yet.
> But I have environment and can profile (direction, please?), test
> patches etc.
Just for the begining could you tell us more about your testing
environment and methodology, since I'm regularly obtaining
significantly worse results than what you reported.
Cheers,
Marko
From zec@icir.org Fri Feb 24 18:41:11 2006
From: zec@icir.org (Marko Zec)
Date: Fri, 24 Feb 2006 19:41:11 +0100
Subject: [Xorp-hackers] Some performance numbers
In-Reply-To: <200602231511.22908.hasso@linux.ee>
References: <200602231511.22908.hasso@linux.ee>
Message-ID: <200602241941.11934.zec@icir.org>
On Thursday 23 February 2006 14:11, Hasso Tepper wrote:
> I have played with BGP full feed during last days and found out that
> unfortunately performance isn't acceptable for real world usage.
> Tests have been done with 1.8 Pentium M (speed-step off) laptop 512MB
> memory. One eBGP multihop peer announcing full table. For nexthop
> resolving static the default route is entered into Xorp.
>
> Peer up without static default route (no routes installed into RIB):
> ********************************************************************
> It takes about 4 seconds to receive full table, xorp_bgp takes about
> 90MB of memory after this. Not very bad IMHO.
Unfortunately at the moment we are roughly an order of magnitude slower
than this, something must went wrong with your measurements. On a 3.4
GHz Pentium 4 receiving ~180k routes into xorp_bgp (while not
propagating any of them to the RIB/FIB) lasts around 42 seconds. The
OS is FreeBSD 4.11 FWIW.
> Peer up with static default route (routes installed into RIB and
> FIB):
> *********************************************************************
>* It takes about 60 seconds to receive full table and to put routes
> into RIB/FIB, xorp_bgp takes about 100MB of memory after this. Memory
> usage is still acceptable, but 60 seconds is certainly very far from
> being acceptable.
>
> Peer down with static default route (routes removed from RIB and
> FIB):
> *********************************************************************
>* Just entered "disable: true" into peer config and committed. It
> takes about 4 minutes and 40 seconds to remove all routes from RIB
> and FIB. This isn't acceptable at all of course.
>
> I wouldn't expect from Xorp instant failover and peer up/down times
> like hardware router vendors can achieve. They have many tricks in
> use which are not available for software routers. But it should be
> certainly happen during max some seconds, not minutes.
>
> Questions ... Is anyone aware of problem? Is it BGP or RIB or IPC or
> ... problem? Is it worth of effort to open bugreport regarding this?
While it looks like our IPC is quite inefficient at the moment and
contributes most to the overall system slowness, there's also
significant room for improvement inside the BGP implementation itself,
such as path attributes handling code. We have some minor tweaks in
the pipeline waiting for a stable release to be rolled out first, but
are just starting to track down the IPC issues.
> Can I help with something? I'm not familiar enough with design of
> XORP and C++ coding yet to solve design related problems though yet.
> But I have environment and can profile (direction, please?), test
> patches etc.
Just for the begining could you tell us more about your testing
environment and methodology, since I'm regularly obtaining
significantly worse results than what you reported.
Cheers,
Marko
From hasso@linux.ee Sat Feb 25 07:29:13 2006
From: hasso@linux.ee (Hasso Tepper)
Date: Sat, 25 Feb 2006 09:29:13 +0200
Subject: [Xorp-hackers] Some performance numbers
In-Reply-To: <200602241941.11934.zec@icir.org>
References: <200602231511.22908.hasso@linux.ee> <200602241941.11934.zec@icir.org>
Message-ID: <200602250929.13817.hasso@linux.ee>
Marko Zec wrote:
> On Thursday 23 February 2006 14:11, Hasso Tepper wrote:
> > Questions ... Is anyone aware of problem? Is it BGP or RIB or IPC or
> > ... problem? Is it worth of effort to open bugreport regarding this?
>
> While it looks like our IPC is quite inefficient at the moment and
> contributes most to the overall system slowness, there's also
> significant room for improvement inside the BGP implementation itself,
> such as path attributes handling code. We have some minor tweaks in
> the pipeline waiting for a stable release to be rolled out first, but
> are just starting to track down the IPC issues.
After writing this I realised that there were some IPC performance numbers
in the NSDI paper. So yes, inefficient IPC explains 60 seconds "put into
RIB/FIB" time. And while looking at it, all - bgp, rib and fea - are
equally busy during this 60 seconds. In "peer down" case bgp itself is
the only process which is really busy though.
> > Can I help with something? I'm not familiar enough with design of
> > XORP and C++ coding yet to solve design related problems though yet.
> > But I have environment and can profile (direction, please?), test
> > patches etc.
>
> Just for the begining could you tell us more about your testing
> environment and methodology, since I'm regularly obtaining
> significantly worse results than what you reported.
Just guess - because I'm using optimised binaries without debug info? I
have modified configure script to use -O3 instead of -O2 and configured
with --disable-debug --enable-optimize. -O3 isn't probably significantly
better than -O2, I just wanted to be sure that it works (no warnings)
with release. I'm using gcc-4.1 (in release candidate state) in Debian
unstable.
regards,
--
Hasso
From hasso@linux.ee Mon Feb 27 19:33:41 2006
From: hasso@linux.ee (Hasso Tepper)
Date: Mon, 27 Feb 2006 21:33:41 +0200
Subject: [Xorp-hackers] Re: [Xorp-cvs] XORP cvs commit: xorp/etc/templates xorp/ospf xorp/xrl/interfaces xorp/xrl/targets
In-Reply-To: <87001.1141031847@tigger.icir.org>
References: <87001.1141031847@tigger.icir.org>
Message-ID: <200602272133.41802.hasso@linux.ee>
Atanu Ghosh wrote:
> Hasso> And this allows to configure to originate default into
> Hasso> backbone area as well? And disable summary origination into
> Hasso> backbone area? Junos have these options available only in
> Hasso> case of nssa and stub areas - ie. nssa and stub are nodes in
> Hasso> area:
>
> The "default-lsa" configuration only applies if the area is stub or
> nssa. I tried to make this clear in the help text.
>
> XORP# create ?
> Possible completions:
> default-lsa Originate default route in stub or not-so-stubby
> areas summaries Generate summaries into stub or not-so-stubby
> areas
>
> Hasso> hasso@lab-junos1# show nssa { default-lsa { default-metric
> Hasso> 10; type-7; } no-summaries; }
>
> Hasso> [edit protocols ospf area 10.10.10.10] hasso@lab-junos1#
>
> I looked at the Juniper stub and nssa configuration and it is difficult
> for us to emulate. I haven't actually tried it but I assume that the
> stub and nssa configuration blocks are mutually exclusive on a Juniper,
Yes, they are.
> I don't think its possible for us to enforce that requirement in a
> template file. I stayed with a single variable to select the area type
> and a "default-lsa" configuration block from which values could be used
> if appropriate.
Maybe we need something like "conflicts" keyword to define nodes which
conflicts with each other?
> Hasso> Note, that it allows to configure type-7 default only in
> Hasso> case of nssa area as well (bugzilla #555).
>
> Looking at RFC 3101 again it seems that the type of the default LSA is
> based on the summary state. If summaries are enabled then the default
> LSA is a Type-7 LSA, if summaries are disabled then the default LSA is
> a Type-3 LSA. The Juniper type-7 is a backward compatibility switch to
> allow a Type-3 default LSA if summaries are disabled.
>
> The options are:
> 1) To use the summary state to determine that type of the LSA as
> specified in RFC 3101. Thus requiring no further switches.
>
> 2) Add a type-7 variable so the type of the default LSA is user
> selectable.
Yes, Juniper developers implemented Type-3 default only at first (note,
that there is "should be" in sentence about Type-7 default in RFC3101, so
Type-7 default isn't really must be) and implemented Type-7 later with
switch for backward compatibility. I'd say that option 1 should be way to
go for Xorp.
regards,
--
Hasso Tepper
From kristian@juniks.net Mon Feb 27 21:31:44 2006
From: kristian@juniks.net (Kristian Larsson)
Date: Mon, 27 Feb 2006 22:31:44 +0100
Subject: [Xorp-hackers] Vyatta
Message-ID: <20060227213144.GA14541@juniks.net>
I'm sure most have gotten the news of this new
'routing platform'. They have done some nice
additions to xorp and I would like to know what
the XORP community thinks of backporting these
into XORP. What I had in mind was the iptables <->
XORP integration and system authentication
integration. How far should XORP go? should is
just remain as a routing software or should it
expand offer the possibility to configure an
entire router, ie with services such as NTP and
the like?
I look forward to being able to configure
everything I need in my router from within xorpsh.
Kristian.
From M.Handley@cs.ucl.ac.uk Mon Feb 27 22:39:35 2006
From: M.Handley@cs.ucl.ac.uk (Mark Handley)
Date: Mon, 27 Feb 2006 22:39:35 +0000
Subject: [Xorp-hackers] Vyatta
In-Reply-To: <20060227213144.GA14541@juniks.net>
References: <20060227213144.GA14541@juniks.net>
Message-ID: <84a612dd0602271439t41929ce5vb4f81816ccf33342@mail.gmail.com>
The goal has always been to produce a complete router software suite.
We just started with the routing protocols first :-)
The limitation is of course time, so we've concentrated on doing
things that we thought we could do right, rather than integrate code
we can't support. As a case in point, I had a very good undergraduate
student who did a decent first pass at an IS-IS implementation for
XORP. We have his code, but we haven't integrated it yet, as we
haven't had anyone up to speed on it to support it and fix bugs.
My personal view is we should integrate as many features as can into
the XORP core, so long as they're useful to a fair number of people,
and so long as we have good people with time and energy to maintain
and improve them.
- Mark
On 2/27/06, Kristian Larsson wrote:
> I'm sure most have gotten the news of this new
> 'routing platform'. They have done some nice
> additions to xorp and I would like to know what
> the XORP community thinks of backporting these
> into XORP. What I had in mind was the iptables <->
> XORP integration and system authentication
> integration. How far should XORP go? should is
> just remain as a routing software or should it
> expand offer the possibility to configure an
> entire router, ie with services such as NTP and
> the like?
> I look forward to being able to configure
> everything I need in my router from within xorpsh.
>
> Kristian.
>
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers@icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
>