bgpd/bgp_debug.c | 7 +++---- bgpd/bgp_packet.c | 6 ------ ospf6d/ospf6_spf.c | 22 +++++----------------- ripd/rip_debug.c | 24 +++++++++--------------- ripd/rip_debug.h | 1 - 5 files changed, 17 insertions(+), 43 deletions(-)
New commits: commit 0fa0335316ce14a79ea4bbb0c40e1322c9941dd3 Author: Andrew J. Schorr <[email protected]> Date: Thu Feb 24 13:52:14 2011 +0300 ripd: resolve debug statements issue (bug 442) ...A nasty bug, if you forgot to disable debugging, stored the config and reboot your machine - if you really depend on ripd, then the machine will not fully come back on the network, because ripd fails. commit 6e22b9017e1ae2ce61c383b1b2b63973207704ac Author: David Ward <[email protected]> Date: Mon Jan 17 10:58:52 2011 +0300 bgpd: VTY string fixes for debug commands * bgpd/bgp_debug.c: fix VTY strings for BGP debug commands to match correct syntax commit c7aa8abd8788c3607ad0131f02e892cf92221e40 Author: Dmitrij Tejblum <[email protected]> Date: Fri Jan 14 18:27:05 2011 +0300 bgpd: fix handling of "Unsupported Capability" * bgp_packet.c: (bgp_notify_receive) justify the difference between BGP_NOTIFY_OPEN_UNSUP_PARAM and BGP_NOTIFY_OPEN_UNSUP_CAPBL cases, as it is explained in RFC5492, page 3, paragraph 1. "Unsupported Capability" error does not mean, that the peer doesn't support capabilities advertisement -- quite the opposite (if the peer would not support capabilities advertisement, the code would be "Unsupported Optional Parameter"). Thus there is no reason to mark the peer as one non-supporting capabilities advertisement. Example: suppose the peer is in fact IPv6-only, but we didn't configure anything address-family specific for it. Then, the peer would refuse the session with "Unsupported Capability" code. If we internally set the peer as non-supporting capabilities advertisement after that, we will not be able to establish the session with it ever, even with a fixed configuration -- IPv6-only BGP session cannot be established without capabilities. In practice an edge case would be seen as the same IPv6 peer working with its "neighbor" block read from bgpd.conf, but not working, when slowly input in "conf t" mode. commit 403138e189c24f6867824c4eeb668d11564e1ca0 Author: Dmitrij Tejblum <[email protected]> Date: Thu Jan 13 18:25:40 2011 +0300 ospf6d: fix crash in SPF calculation * ospf6_spf.c: Don't replace a node with another node with a lower number of hops, instead get them from the queue in the correct order. (Actually, the replacement crashed the ospf6d daemon rather than worked.) http://suva.vyatta.com/git/?p=vyatta-quagga.git;a=commitdiff;h=0fa0335316ce14a79ea4bbb0c40e1322c9941dd3 http://suva.vyatta.com/git/?p=vyatta-quagga.git;a=commitdiff;h=6e22b9017e1ae2ce61c383b1b2b63973207704ac http://suva.vyatta.com/git/?p=vyatta-quagga.git;a=commitdiff;h=c7aa8abd8788c3607ad0131f02e892cf92221e40 http://suva.vyatta.com/git/?p=vyatta-quagga.git;a=commitdiff;h=403138e189c24f6867824c4eeb668d11564e1ca0 _______________________________________________ svn mailing list [email protected] http://mailman.vyatta.com/mailman/listinfo/svn
