| Age | Commit message (Collapse) | Author |
|---|
|
|
|
in zebra.h to make it compile in debian.
|
|
* Merge of zebra privileges
|
|
lib/debug.{c,h}: glibc backtrace printing function (from the glibc info page)
configure.ac: check for glibc backtrace and set define
lib/zebra.h: glibc backtrace support
|
|
|
|
|
|
|
|
|
|
|
|
|
|
same idea as in lib/distribute.c to allow extract.pl to pick up commands
for vtysh.
|
|
Subject: solaris compile patch
types defined for SUNOS_5 were already defined in config.h
|
|
|
|
Reported by Anil Madhavapeddy to bug-zebra.
|
|
ensure only interfaces that are inactive or do not exist can be deleted
|
|
Add the 'no interface' command to all the daemons and vtysh. now it's
possible to delete interface from routeing daemons as well only if it
doesn't exist in os.
http://hasso.linux.ee/zebra/ht-no_interface_fix.patch
|
|
|
|
|
|
http://hasso.linux.ee/zebra/ht-no_interface-23052003.patch
Add the 'no interface' command to all the daemons and vtysh.
|
|
|
|
|
|
asm/types.h is required for netlink.
Later glibc's seem to have resolved the warning.
|
|
|
|
Linux capabilities enabled (if libcap is enabled).
|
|
Subject: [zebra 19097] HAVE_ASM_TYPES
does anyone know why lib/zebra.h has:
#ifdef HAVE_ASM_TYPES_H
#include <asm/types.h>
#endif /* HAVE_ASM_TYPES_H */
There's no need for it that i can see (least not on linux) and it
causes compile warnings. Is it needed? If so, why?
|
|
|
|
Subject: [zebra 19019] [PATCH] daemons -A option
Works now. Patch attached. Not tested for IPv6, but should work there too.
|
|
http://hasso.linux.ee/zebra/ht-distribute-18042003.patch
Allows to extract.pl to pickup "distribute-list ..." commands for vtysh
(ripngd and ripd).
|
|
http://hasso.linux.ee/zebra/ht-ifrmap-14042003.patch
Allows to extract.pl to pickup "route-map xxx in/out dev" commands for vtysh
(ripngd). As lib/if_rmap.[c|h] are used in ripngd only, I moved them to the
ripngd/ directory.
|
|
Add ospfclient to ospfclient/.cvsignore
|
|
Developers working with the repository should have the appropriate tools.
Out-of-sync files cause far too many problems with users as well as auto*
scripts not being half as portable across systems as they ought to be.
make-dist exists for a reason.
Todo: make the CVS snapshot script do make-dist, and use the resulting
tarball as the snapshot.
|
|
* Sync to Zebra CVS
* Fix lib/thread.h leak
* Fix small Opaque LSA leak
* Do not configure OSPF interfaces for secondary addresses
* vtysh fixes from Hasso
* Dave Watson's missing ntohs fix
|
|
|
|
* sync to latest zebra CVS
* spec file: updated and added define for ospf-api/client
NB: OSPF-API has been broken by the zebra.org changes, which
has added struct ospf * as a new arg to many functions
|
|
|
|
--------------------------------
I've attached a small patch for zebra-pj, which adds the installation of
libospf.a libzebra.a, libospfapi.a and the needed headers for ospfapi
clients. the headers get installed to /usr/include/ospfd/* and
/usr/include/ospfapi.
|
|
No doubt builds will now break for everyone. (works here - autoconf 2.13)
|
|
|
|
|
|
|
|
|
|
describing original patch and a shorter email describing changes to an
updated patch, the one which is applied:
From havanna_moon@gmx.net Sat Jan 18 00:37:13 2003
Date: Mon, 9 Dec 2002 05:32:58 +0100 (CET)
From: Yon Uriarte <havanna_moon@gmx.net>
To: "the list(tm) Zebra" <zebra@zebra.org>
Subject: [zebra 16671] [PATCH] CLI extensions.
Hi,
this patch adds 2 improvements to the CLI (lib/command.c):
#1) When in subconfig mode (router XXX, interface XXX, ...) commands that
fail for that node are tried on the main CONFIG_NODE. This is great for
configuring interfaces or changing the sub-config mode quickly, without
the need to type 'exit' between commands:
ospfd(config)# int eth1
ospfd(config-if)# ip ospf cost 9
ospfd(config-if)# ip ospf prio 101
ospfd(config-if)# router ospf
ospfd(config-router)# network 1.1.1.0/24 area 51
ospfd(config-router)# int eth2
ospfd(config-if)# ip ospf authentication message-digest
ospfd(config-if)# ^Z
ospfd#
Is this IOS-like or does IOS try to walk up the tree of config sub-modes
instead of directly trying the command on CONFIG_NODE?
CAVEATS: "?" and "TAB" don't work. IIRC IOS doesnt show that help
neither.
NON-CAVEATS: This wont break much, as config_from_file() already does
try a failed command on the parent node of the actual vty->node. If
changing the code to walk the node tree instead of directly trying
the command on the ENABLE_NODE the same semantics would be in use
and no future bugs could creep in.
#2) When in config or subconfig mode use the "do " prefix to execute
commans of the ENABLE_NODE. "?" and "TAB" work. The space after the
"do" is needed:
ospfd(config-router)# do<?>
% There is no matched command.
ospfd(config-router)# do <?>
clear Reset functions
configure Configuration from vty interface
copy Copy configuration
debug Debugging functions (see also 'undebug')
disable Turn off privileged mode command
end End current mode and change to enable mode.
exit Exit current mode and down to previous mode
help Description of the interactive help system
list Print command list
no Negate a command or set its defaults
quit Exit current mode and down to previous mode
show Show running system information
terminal Set terminal line parameters
who Display who is on vty
write Write running configuration to memory, network, or terminal
ospfd(config-router)# do sho<TAB>
ospfd(config-router)# do show me<TAB>
ospfd(config-router)# do show memory r<TAB>
ospfd(config-router)# do show memory rip
RIP structure : 0
RIP route info : 0
RIP interface : 0
RIP peer : 0
RIP offset list : 0
RIP distance : 0
ospfd(config-router)# ^Z
ospfd#
CAVEATS: I don't have access to an IOS with this feature, so I implemented
it from the comments on this mailing list (in fact my personal motivation
was to implement feature #1, which I missed on zebra. But #2 sounded like
a nice one to have, and xemacs was already parked on command.c ...).
Is this IOS-like or are there differences?
I will happily change this patch to mimick IOS or the mailing-list
consensus on CLI-usability.
regards,
yon
From havanna_moon@gmx.net Sat Jan 18 01:13:11 2003
Date: Sat, 11 Jan 2003 23:36:51 +0100 (CET)
From: Yon Uriarte <havanna_moon@gmx.net>
To: zebra@zebra.org
Subject: [zebra 17218] Re: [PATCH] CLI extensions.
Hi,
[redacted]
> I prefer the IOS way for the node "up walking".
This patch should walk the tree upwards:
bgpd(config)# router bgp 1
bgpd(config-router)# address-family ipv4 multicast
bgpd(config-router-af)# access-list 1 remark hola que tal
bgpd(config)#
I cant test all combinations, so I cant rule out some bugs. I'd love to
get (long and explicit) bug reports.
[redacted]
|
|
be off:
From havanna_moon@gmx.net Sat Jan 18 00:37:13 2003
Date: Mon, 9 Dec 2002 05:32:58 +0100 (CET)
From: Yon Uriarte <havanna_moon@gmx.net>
To: "the list(tm) Zebra" <zebra@zebra.org>
Subject: [zebra 16671] [PATCH] CLI extensions.
Hi,
this patch adds 2 improvements to the CLI (lib/command.c):
#1) When in subconfig mode (router XXX, interface XXX, ...) commands that
fail for that node are tried on the main CONFIG_NODE. This is great for
configuring interfaces or changing the sub-config mode quickly, without
the need to type 'exit' between commands:
ospfd(config)# int eth1
ospfd(config-if)# ip ospf cost 9
ospfd(config-if)# ip ospf prio 101
ospfd(config-if)# router ospf
ospfd(config-router)# network 1.1.1.0/24 area 51
ospfd(config-router)# int eth2
ospfd(config-if)# ip ospf authentication message-digest
ospfd(config-if)# ^Z
ospfd#
Is this IOS-like or does IOS try to walk up the tree of config sub-modes
instead of directly trying the command on CONFIG_NODE?
CAVEATS: "?" and "TAB" don't work. IIRC IOS doesnt show that help
neither.
NON-CAVEATS: This wont break much, as config_from_file() already does
try a failed command on the parent node of the actual vty->node. If
changing the code to walk the node tree instead of directly trying
the command on the ENABLE_NODE the same semantics would be in use
and no future bugs could creep in.
#2) When in config or subconfig mode use the "do " prefix to execute
commans of the ENABLE_NODE. "?" and "TAB" work. The space after the
"do" is needed:
ospfd(config-router)# do<?>
% There is no matched command.
ospfd(config-router)# do <?>
clear Reset functions
configure Configuration from vty interface
copy Copy configuration
debug Debugging functions (see also 'undebug')
disable Turn off privileged mode command
end End current mode and change to enable mode.
exit Exit current mode and down to previous mode
help Description of the interactive help system
list Print command list
no Negate a command or set its defaults
quit Exit current mode and down to previous mode
show Show running system information
terminal Set terminal line parameters
who Display who is on vty
write Write running configuration to memory, network, or terminal
ospfd(config-router)# do sho<TAB>
ospfd(config-router)# do show me<TAB>
ospfd(config-router)# do show memory r<TAB>
ospfd(config-router)# do show memory rip
RIP structure : 0
RIP route info : 0
RIP interface : 0
RIP peer : 0
RIP offset list : 0
RIP distance : 0
ospfd(config-router)# ^Z
ospfd#
CAVEATS: I don't have access to an IOS with this feature, so I implemented
it from the comments on this mailing list (in fact my personal motivation
was to implement feature #1, which I missed on zebra. But #2 sounded like
a nice one to have, and xemacs was already parked on command.c ...).
Is this IOS-like or are there differences?
I will happily change this patch to mimick IOS or the mailing-list
consensus on CLI-usability.
regards,
yon
|
|
Date: Sat, 11 Jan 2003 23:26:28 +0100 (CET)
From: Yon Uriarte <havanna_moon@gmx.net>
To: "the list(tm) Zebra" <zebra@zebra.org>
Subject: [zebra 17217] [PATCH] show thread CPU
Hi,
a little patch from the 'stupid preprocessor tricks' collection to record
thread statistics.
Usage: "show thread cpu [r][w][t][e][x]"
Output Fields: self explaining I hope. Type is one of RWTEX for:
Read, Write (fd threads), Timer, Event, Execute.
Overhead vs. vanilla zebra: almost nothing. Vanilla CVS zebra already
collects thread run times.
Caveats: Under linux getrusage has a granularity of 10ms, which is almost
useless in this case. Run ./configure, edit config.h and comment out
"#define HAVE_RUSAGE", this way it will use getimeofday which has a much
better granularity. IMHO this is better, as cooperative threads are
effectively running during all that wall time (dont care if CPU
utilization was 3% or 99% during the time the thread was running (an
effective rusage combined with getimeofday could give that info)).
Maybe someone can give tips for other platforms on API granularity.
TODO: change some of the calls to thread_add_$KIND to
funcname_thread_add_$KIND with a meaningfull funcname, so users will get a
better idea of what's going on.
F.ex. (AFAIK):
ospf_spf_calculate_timer -> "Routes Step 1, areas SPF"
ospf_ase_calculate_timer -> "Routes Step 2, externals"
Could this be added to the unofficial patch collection?
Could someone with BGP keepalive problems run their bgpd with this patch
and post the results?
TIA, HTH, HAND, regards
yon
Example output:
--------------------------------
ospfd# show thread cpu
Runtime(ms) Invoked Avg uSecs Max uSecs Type Thread
14.829 31 478 585 T ospf_ase_calculate_timer
82.132 9838 8 291 EX ospf_nsm_event
0.029 1 29 29 E ospf_default_originate_timer
0.254 9 28 34 T ospf_db_desc_timer
0.026 7 3 11 T ospf_wait_timer
669.015 523 1279 490696 R vty_read
4.415 45 98 173 TE ospf_network_lsa_refresh_timer
15.026 31 484 588 T ospf_spf_calculate_timer
29.478 1593 18 122 E ospf_ls_upd_send_queue_event
0.173 1 173 173 T vty_timeout
4.173 242 17 58 E ospf_ls_ack_send_event
637.767 121223 5 55 T ospf_ls_ack_timer
39.373 244 161 2691 R zclient_read
12.169 98 124 726 EX ospf_ism_event
0.226 2 113 125 R vty_accept
537.776 14256 37 3813 W ospf_write
4.967 41 121 250 T ospf_router_lsa_timer
0.672 1 672 672 E zclient_connect
7.901 1658 4 26 T ospf_ls_req_timer
0.459 2 229 266 E ospf_external_lsa_originate_timer
3.203 60 53 305 T ospf_maxage_lsa_remover
108.341 9772 11 65 T ospf_ls_upd_timer
33.302 525 63 8628 W vty_flush
0.101 1 101 101 T ospf_router_lsa_update_timer
0.016 1 16 16 T ospf_router_id_update_timer
26.970 407 66 176 T ospf_lsa_maxage_walker
381.949 12244 31 69 T ospf_hello_timer
0.114 22 5 14 T ospf_inactivity_timer
34.290 1223 28 310 T ospf_lsa_refresh_walker
470.645 6592 71 665 R ospf_read
3119.791 180693 17 490696 RWTEX TOTAL
ospfd#
bgpd# sh t c TeX
Runtime(ms) Invoked Avg uSecs Max uSecs Type Thread
21.504 476 45 71 T bgp_keepalive_timer
17.784 1157 15 131 T bgp_reuse_timer
29.080 193 150 249 T bgp_scan
23.606 995 23 420 E bgp_event
317.734 28572 11 69 T bgp_routeadv_timer
0.084 1 84 84 E zlookup_connect
0.526 1 526 526 E zclient_connect
1.348 13 103 147 T bgp_start_timer
19.443 142 136 420 T bgp_connect_timer
16.032 772 20 27 T bgp_import
447.141 32322 13 526 TEX TOTAL
bgpd#
bgpd# show thread cpu rw
Runtime(ms) Invoked Avg uSecs Max uSecs Type Thread
155.043 7 22149 150659 R bgp_accept
129.638 180 720 53844 R vty_read
1.734 56 30 129 R zclient_read
0.255 2 127 148 R vty_accept
58.483 983 59 340 R bgp_read
171.495 29190 5 245 W bgp_write
13.884 181 76 2542 W vty_flush
530.532 30599 17 150659 RW TOTAL
bgpd#
--------------------------------
|
|
[zebra 16681] OSPF NSSA Patches
|
|
[zebra 16671] [PATCH] CLI extensions.
|
|
|
|
|
|
subnet handling
|
|
|
