From s8066410@kmitl.ac.th Sun Feb 5 10:00:41 2006 From: s8066410@kmitl.ac.th (s8066410@kmitl.ac.th) Date: Sun, 5 Feb 2006 17:00:41 +0700 (ICT) Subject: [Xorp-hackers] How to connect XORP with PHP Message-ID: <1153.161.246.49.41.1139133641.squirrel@161.246.49.41> To xorp-hacker I will implement to connect XORP router with PHP webbase, but I don,t know how to do it. Please tell me how will do. Chatree Chalothorn s8066410@kmitl.ac.th From pavlin@icir.org Tue Feb 7 03:42:29 2006 From: pavlin@icir.org (Pavlin Radoslavov) Date: Mon, 06 Feb 2006 19:42:29 -0800 Subject: [Xorp-hackers] How to connect XORP with PHP In-Reply-To: Message from s8066410@kmitl.ac.th of "Sun, 05 Feb 2006 17:00:41 +0700." <1153.161.246.49.41.1139133641.squirrel@161.246.49.41> Message-ID: <200602070342.k173gTvT068987@possum.icir.org> > I will implement to connect XORP router with PHP webbase, but I don,t know > how to do it. Please tell me how will do. Please be more specific what exactly you need to do. Pavlin From tdurack@gmail.com Wed Feb 8 02:52:57 2006 From: tdurack@gmail.com (Tim Durack) Date: Tue, 7 Feb 2006 21:52:57 -0500 Subject: [Xorp-hackers] OSPF Failures Message-ID: <9e246b4d0602071852sd937ccdw411ae1c2578d0c2@mail.gmail.com> ------=_Part_924_27671142.1139367177345 Content-Type: multipart/alternative; boundary="----=_Part_925_4469158.1139367177345" ------=_Part_925_4469158.1139367177345 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I've been having ongoing OSPF death problems with my simple fully meshed four router test bed. If I bring all four routers up at the same time, OSPF quickly dies. If I bring them up one at a time, sometimes they will stay up and stable. The event is: [ 2006/02/07 21:11:40 INFO xorp_rtrmgr:7256 RTRMGR +2228 task.cc run_task = ] No more tasks to run [ 2006/02/07 21:11:40 TRACE xorp_rtrmgr RTRMGR ] apply_config_change_done: status: 1 response: target: xorpsh-7257-xen1 [ 2006/02/07 21:12:45 TRACE xorp_ospfv2 OSPF ] Ack for LSA not in retransmission list. LS age 1 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link State ID 10.0.0.1 Advertising Router 10.0.0.1 LS sequence number 0x80000001 LS checksum 0xcde5 leng th 72 Link State Acknowledgement Packet: Version 2 Type 5 Router ID 10.1.0.2 Area ID 0.0.0.0 Auth Type 0 LS age 1 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link State ID 10.0.0.1 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 0x8000000= 1 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 =3D=3D _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 signa= l 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 =3D 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 =3D 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 =3D 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 =3D Redist:ospf I've attached all four router configs in case it helps. Any ideas? Tim:> ------=_Part_925_4469158.1139367177345 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I've been having ongoing OSPF death problems with my simple fully meshed fo= ur router test bed.

If I bring all four routers up at the same time,= OSPF quickly dies. If I bring them up one at a time, sometimes they will s= tay up and stable.

The event is:

[ 2006/02/07 21:11:40  INFO xorp_rtrmgr:7= 256 RTRMGR +2228 task.cc run_task ] No more tasks to run
[ 2006/02/07 21= :11:40 TRACE xorp_rtrmgr RTRMGR ] apply_config_change_done: status: 1 respo= nse:  target: xorpsh-7257-xen1
[ 2006/02/07 21:12:45 TRACE xorp_ospfv2 OSPF ] Ack for LSA not in retra= nsmission list.
LS age    1 Options  0x2 DC: 0 EA: 0= N/P: 0 MC: 0 E: 1 LS type 0x1 Link State ID 10= .0.0.1 Advertising Router=20 10.0.0.1 LS sequence number 0x80000001 LS c= hecksum 0xcde5 leng th 72
Link State Acknowledgement Packet:
 &n= bsp;      Version 2
    &nb= sp;   Type 5
        Router= ID 10.1.0.2
        Area ID 0.0.0.0
      &nbs= p; Auth Type 0

        LS age&nbs= p;   1 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x= 1 Link State ID 10.0.0.1 Advertising Router 10.0.0.1 LS sequenc= e 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&= nbsp;  91 Options  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 = Link State ID=20 10.1.0.13 Advertising Router 10.0.0.1 LS sequence number 0x80000001 LS checksum 0xdc4= 5 len gth 32
Link State Acknowledgement Packet:
   &nb= sp;    Version 2
        Type 5
   &nbs= p;    Router ID 10.0.0.2
=         Area ID 0.0.0.0
        Auth Type 0
        LS age   91 Optio= ns  0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x2 Link State ID=20 10.1.0.13 Advertising Router 10.0.0.1 LS sequence number 0x80000001 LS checksum 0x dc= 45 length 32
[ 2006/02/07 21:14:21  FATAL xorp_ospfv2:7261 OSPF +47= 1 routing_table.cc add_entry ] Assertion (0 =3D=3D _entries.count(area)) fa= iled
[ 2006/02/07 21:14:21  ERROR xorp_rtrmgr:7256 RTRMGR +736 module_m= anager.cc done_cb ] Command "/usr/local/xorp/ospf/xorp_ospfv2": t= erminated with signal 6.
[ 2006/02/07 21:14:21  INFO xorp_rtrmgr:72= 56 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 prot= ocol ospfv2 shutting down -------
OriginTable: ospf
IGP
next table= =3D Redist:ospf
[ 2006/02/07 21:14:21 INFO xorp_rib RIB ] Received deat= h event for protocol ospfv2 shutting down -------
OriginTable: ospf
IGP
next table =3D Redist:ospf
[ 2006/02/07 = 21:14:21 INFO xorp_rib RIB ] Received death event for protocol ospfv2 shutt= ing down -------
OriginTable: ospf
IGP
next table =3D Redist:ospf<= br> [ 2006/02/07 21:14:21 INFO xorp_rib RIB ] Received death event for protocol= ospfv2 shutting down -------
OriginTable: ospf
IGP
next table =3D= Redist:ospf


I've attached all four router configs in case it he= lps.

Any ideas?

Tim:>
------=_Part_925_4469158.1139367177345-- ------=_Part_924_27671142.1139367177345 Content-Type: application/octet-stream; name=xen1.config Content-Transfer-Encoding: 7bit X-Attachment-Id: f_ejf1qev9 Content-Disposition: attachment; filename="xen1.config" /*XORP Configuration File, v1.0*/ rtrmgr { load-http-command: "curl" config-directory: "" load-file-command: "fetch" load-file-command-args: "-o" load-ftp-command: "fetch" load-ftp-command-args: "-o" load-http-command-args: "-o" load-tftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'" load-tftp-command-args: "" save-file-command: "sh -c 'echo Not implemented 1>&2 && exit 1'" save-file-command-args: "" save-ftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'" save-ftp-command-args: "" save-http-command: "sh -c 'echo Not implemented 1>&2 && exit 1'" save-http-command-args: "" save-tftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'" save-tftp-command-args: "" } fea { unicast-forwarding4 { disable: false } } plumbing { rib { } } interfaces { interface dummy0 { vif dummy0 { address 10.0.0.1 { prefix-length: 32 disable: false } disable: false } disable: false discard: false description: "" } interface tun0 { vif tun0 { address 10.0.0.5 { prefix-length: 30 disable: false } disable: false } disable: false discard: false description: "" mtu: 1476 } interface tun1 { vif tun1 { address 10.1.0.9 { prefix-length: 30 disable: false } disable: false } disable: false discard: false description: "" mtu: 1476 } interface tun2 { vif tun2 { address 10.1.0.13 { prefix-length: 30 disable: false } disable: false } disable: false discard: false description: "" mtu: 1476 } restore-original-config-on-shutdown: false } protocols { ospf4 { router-id: 10.0.0.1 ip-router-alert: false area 0.0.0.0 { interface tun0 { vif tun0 { address 10.0.0.5 { disable: false priority: 128 hello-interval: 10 router-dead-interval: 40 interface-cost: 1 transit-delay: 1 retransmit-interval: 5 passive: false } } link-type: "broadcast" } interface dummy0 { vif dummy0 { address 10.0.0.1 { disable: false priority: 128 hello-interval: 10 router-dead-interval: 40 interface-cost: 1 transit-delay: 1 retransmit-interval: 5 passive: false } } link-type: "broadcast" } interface tun1 { vif tun1 { address 10.1.0.9 { disable: false priority: 128 hello-interval: 10 router-dead-interval: 40 interface-cost: 1 transit-delay: 1 retransmit-interval: 5 passive: false } } link-type: "broadcast" } interface tun2 { vif tun2 { address 10.1.0.13 { disable: false priority: 128 hello-interval: 10 router-dead-interval: 40 interface-cost: 1 transit-delay: 1 retransmit-interval: 5 passive: false } } link-type: "broadcast" } area-type: "normal" } } } ------=_Part_924_27671142.1139367177345 Content-Type: application/octet-stream; name=xen2.config Content-Transfer-Encoding: 7bit X-Attachment-Id: f_ejf1rd2f Content-Disposition: attachment; filename="xen2.config" /*XORP Configuration File, v1.0*/ rtrmgr { load-http-command: "curl" config-directory: "" load-file-command: "fetch" load-file-command-args: "-o" load-ftp-command: "fetch" load-ftp-command-args: "-o" load-http-command-args: "-o" load-tftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'" load-tftp-command-args: "" save-file-command: "sh -c 'echo Not implemented 1>&2 && exit 1'" save-file-command-args: "" save-ftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'" save-ftp-command-args: "" save-http-command: "sh -c 'echo Not implemented 1>&2 && exit 1'" save-http-command-args: "" save-tftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'" save-tftp-command-args: "" } fea { unicast-forwarding4 { disable: false } } plumbing { rib { } } interfaces { interface dummy0 { vif dummy0 { address 10.0.0.2 { prefix-length: 32 disable: false } disable: false } disable: false discard: false description: "" } interface tun0 { vif tun0 { address 10.0.0.6 { prefix-length: 30 disable: false } disable: false } mtu: 1476 disable: false discard: false description: "" } interface tun1 { vif tun1 { address 10.1.0.17 { prefix-length: 30 disable: false } disable: false } mtu: 1476 disable: false discard: false description: "" } interface tun2 { vif tun2 { address 10.1.0.21 { prefix-length: 30 disable: false } disable: false } mtu: 1476 disable: false discard: false description: "" } restore-original-config-on-shutdown: false } protocols { ospf4 { router-id: 10.0.0.2 ip-router-alert: false area 0.0.0.0 { interface tun0 { vif tun0 { address 10.0.0.6 { disable: false priority: 128 hello-interval: 10 router-dead-interval: 40 interface-cost: 1 transit-delay: 1 retransmit-interval: 5 passive: false } } link-type: "broadcast" } interface dummy0 { vif dummy0 { address 10.0.0.2 { disable: false priority: 128 hello-interval: 10 router-dead-interval: 40 interface-cost: 1 transit-delay: 1 retransmit-interval: 5 passive: false } } link-type: "broadcast" } interface tun1 { vif tun1 { address 10.1.0.17 { disable: false priority: 128 hello-interval: 10 router-dead-interval: 40 interface-cost: 1 transit-delay: 1 retransmit-interval: 5 passive: false } } link-type: "broadcast" } interface tun2 { vif tun2 { address 10.1.0.21 { disable: false priority: 128 hello-interval: 10 router-dead-interval: 40 interface-cost: 1 transit-delay: 1 retransmit-interval: 5 passive: false } } link-type: "broadcast" } area-type: "normal" } } } ------=_Part_924_27671142.1139367177345 Content-Type: application/octet-stream; name=xen3.config Content-Transfer-Encoding: 7bit X-Attachment-Id: f_ejf1ri00 Content-Disposition: attachment; filename="xen3.config" /*XORP Configuration File, v1.0*/ rtrmgr { load-http-command: "curl" config-directory: "" load-file-command: "fetch" load-file-command-args: "-o" load-ftp-command: "fetch" load-ftp-command-args: "-o" load-http-command-args: "-o" load-tftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'" load-tftp-command-args: "" save-file-command: "sh -c 'echo Not implemented 1>&2 && exit 1'" save-file-command-args: "" save-ftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'" save-ftp-command-args: "" save-http-command: "sh -c 'echo Not implemented 1>&2 && exit 1'" save-http-command-args: "" save-tftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'" save-tftp-command-args: "" } fea { unicast-forwarding4 { disable: false } } plumbing { rib { } } interfaces { interface dummy0 { vif dummy0 { address 10.1.0.1 { prefix-length: 32 disable: false } disable: false } disable: false discard: false description: "" } interface tun0 { vif tun0 { address 10.1.0.5 { prefix-length: 30 disable: false } disable: false } mtu: 1476 disable: false discard: false description: "" } interface tun1 { vif tun1 { address 10.1.0.10 { prefix-length: 30 disable: false } disable: false } mtu: 1476 disable: false discard: false description: "" } interface tun2 { vif tun2 { address 10.1.0.18 { prefix-length: 30 disable: false } disable: false } mtu: 1476 disable: false discard: false description: "" } restore-original-config-on-shutdown: false } protocols { bgp { bgp-id: 10.1.0.1 local-as: 65001 peer "10.1.0.2" { as: 65001 peer-port: 179 local-port: 179 local-ip: "10.1.0.1" holdtime: 90 client: false confederation-member: false disable: false ipv4-unicast: true ipv4-multicast: false ipv6-unicast: false ipv6-multicast: false next-hop: 10.1.0.2 delay-open-time: 0 } export: "connected" } ospf4 { router-id: 10.1.0.1 ip-router-alert: false area 0.0.0.0 { interface dummy0 { vif dummy0 { address 10.1.0.1 { disable: false priority: 128 hello-interval: 10 router-dead-interval: 40 interface-cost: 1 transit-delay: 1 retransmit-interval: 5 passive: false } } link-type: "broadcast" } interface tun0 { vif tun0 { address 10.1.0.5 { disable: false priority: 128 hello-interval: 10 router-dead-interval: 40 interface-cost: 1 transit-delay: 1 retransmit-interval: 5 passive: false } } link-type: "broadcast" } interface tun1 { vif tun1 { address 10.1.0.10 { disable: false priority: 128 hello-interval: 10 router-dead-interval: 40 interface-cost: 1 transit-delay: 1 retransmit-interval: 5 passive: false } } link-type: "broadcast" } interface tun2 { vif tun2 { address 10.1.0.18 { disable: false priority: 128 hello-interval: 10 router-dead-interval: 40 interface-cost: 1 transit-delay: 1 retransmit-interval: 5 passive: false } } link-type: "broadcast" } area-type: "normal" } } } policy { policy-statement connected { term one { from { protocol: "connected" prefix-length4 == 24..24 } then { nexthop4: 10.1.0.1 } } } } ------=_Part_924_27671142.1139367177345 Content-Type: application/octet-stream; name=xen4.config Content-Transfer-Encoding: 7bit X-Attachment-Id: f_ejf1rmhu Content-Disposition: attachment; filename="xen4.config" /*XORP Configuration File, v1.0*/ rtrmgr { load-http-command: "curl" config-directory: "" load-file-command: "fetch" load-file-command-args: "-o" load-ftp-command: "fetch" load-ftp-command-args: "-o" load-http-command-args: "-o" load-tftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'" load-tftp-command-args: "" save-file-command: "sh -c 'echo Not implemented 1>&2 && exit 1'" save-file-command-args: "" save-ftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'" save-ftp-command-args: "" save-http-command: "sh -c 'echo Not implemented 1>&2 && exit 1'" save-http-command-args: "" save-tftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'" save-tftp-command-args: "" } fea { unicast-forwarding4 { disable: false } } plumbing { rib { } } interfaces { interface dummy0 { vif dummy0 { address 10.1.0.2 { prefix-length: 32 disable: false } disable: false } disable: false discard: false description: "" } interface tun0 { vif tun0 { address 10.1.0.6 { prefix-length: 30 disable: false } disable: false } mtu: 1476 disable: false discard: false description: "" } interface tun1 { vif tun1 { address 10.1.0.14 { prefix-length: 30 disable: false } disable: false } mtu: 1476 disable: false discard: false description: "" } interface tun2 { vif tun2 { address 10.1.0.22 { prefix-length: 30 disable: false } disable: false } mtu: 1476 disable: false discard: false description: "" } restore-original-config-on-shutdown: false } protocols { ospf4 { router-id: 10.1.0.2 ip-router-alert: false area 0.0.0.0 { interface dummy0 { vif dummy0 { address 10.1.0.2 { disable: false priority: 128 hello-interval: 10 router-dead-interval: 40 interface-cost: 1 transit-delay: 1 retransmit-interval: 5 passive: false } } link-type: "broadcast" } interface tun0 { vif tun0 { address 10.1.0.6 { disable: false priority: 128 hello-interval: 10 router-dead-interval: 40 interface-cost: 1 transit-delay: 1 retransmit-interval: 5 passive: false } } link-type: "broadcast" } interface tun1 { vif tun1 { address 10.1.0.14 { disable: false priority: 128 hello-interval: 10 router-dead-interval: 40 interface-cost: 1 transit-delay: 1 retransmit-interval: 5 passive: false } } link-type: "broadcast" } interface tun2 { vif tun2 { address 10.1.0.22 { disable: false priority: 128 hello-interval: 10 router-dead-interval: 40 interface-cost: 1 transit-delay: 1 retransmit-interval: 5 passive: false } } link-type: "broadcast" } area-type: "normal" } } bgp { bgp-id: 10.1.0.2 local-as: 65001 peer "10.1.0.1" { as: 65001 peer-port: 179 local-port: 179 local-ip: "10.1.0.2" holdtime: 90 client: false confederation-member: false disable: false ipv4-unicast: true ipv4-multicast: false ipv6-unicast: false ipv6-multicast: false next-hop: 10.1.0.1 delay-open-time: 0 } export: "connected" } } policy { policy-statement connected { term one { from { protocol: "connected" prefix-length4 == 24..24 } then { nexthop4: 10.1.0.2 } } } } ------=_Part_924_27671142.1139367177345-- From caddisconsulting@yahoo.com Wed Feb 8 16:28:47 2006 From: caddisconsulting@yahoo.com (Mike Horn) Date: Wed, 8 Feb 2006 09:28:47 -0700 Subject: [Bulk] [Xorp-hackers] OSPF Failures In-Reply-To: <9e246b4d0602071852sd937ccdw411ae1c2578d0c2@mail.gmail.com> Message-ID: <00e801c62ccc$bcdedaf0$6402a8c0@caddisconsulting.com> This is a multi-part message in MIME format. ------=_NextPart_000_00E9_01C62C92.108002F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Tim, This looks similar to, but is not the same as XORP bug 383. I would suggest opening a new bug in Bugzilla so that the XORP team can investigate. If these are the only routers running OSPF on this network, then there might be some sort of race condition related to DR election. This might explain why it happens when you enable all four at the same time rather than one at a time. I only have 2 routers running XORP here, but I'll see if I can reproduce the issue. -mike _____ From: xorp-hackers-admin@icir.org [mailto:xorp-hackers-admin@icir.org] On Behalf Of Tim Durack Sent: Tuesday, February 07, 2006 7:53 PM To: xorp-hackers@xorp.org Subject: [Bulk] [Xorp-hackers] OSPF Failures I've been having ongoing OSPF death problems with my simple fully meshed four router test bed. If I bring all four routers up at the same time, OSPF quickly dies. If I bring them up one at a time, sometimes they will stay up and stable. The event is: [ 2006/02/07 21:11:40 INFO xorp_rtrmgr:7256 RTRMGR +2228 task.cc run_task ] No more tasks to run [ 2006/02/07 21:11:40 TRACE xorp_rtrmgr RTRMGR ] apply_config_change_done: status: 1 response: target: xorpsh-7257-xen1 [ 2006/02/07 21:12:45 TRACE xorp_ospfv2 OSPF ] Ack for LSA not in retransmission list. LS age 1 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link State ID 10.0.0.1 Advertising Router 10.0.0.1 LS sequence number 0x80000001 LS checksum 0xcde5 leng th 72 Link State Acknowledgement Packet: Version 2 Type 5 Router ID 10.1.0.2 Area ID 0.0.0.0 Auth Type 0 LS age 1 Options 0x2 DC: 0 EA: 0 N/P: 0 MC: 0 E: 1 LS type 0x1 Link State ID 10.0.0.1 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


From: xorp-hackers-admin@icir.org=20 [mailto:xorp-hackers-admin@icir.org] On Behalf Of Tim=20 Durack
Sent: Tuesday, February 07, 2006 7:53 PM
To:=20 xorp-hackers@xorp.org
Subject: [Bulk] [Xorp-hackers] OSPF=20 Failures

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 >