On Tue, Mar 10, 2009 at 02:46:56PM +0100, Arnoud Vermeer wrote:
Hi,
Elisa and I were looking at the production-pilot logs last night and
noticed the following:
I finally found some time to look into this and your dumps. The problem is
actually with withdraws that are still totaly fucked
Hi,
The patch is working. I have patched both the local testing setup and
the production pilot. I tcpdumped the interface and got a nice IPv6
withdraw-packet:
No. TimeSourceDestination Protocol
Info
101 27.955719 2001:db8:1::a500:6777:1
Hi,
Elisa and I were looking at the production-pilot logs last night and
noticed the following:
Mar 10 04:41:45 radix-new bgpd[25100]: neighbor 2001:7f8:1::a501:6265:2
(LEASEWEB-v6-02) AS16265: withdraw 2001:1af8::/32
Mar 10 04:41:45 radix-new bgpd[12120]: neighbor 2001:7f8:1::a504:8345:1
On Mon, Mar 09, 2009 at 12:25:12PM +0100, Arnoud Vermeer wrote:
We commented out the following lines, to test if it is indeed an
End-of-RIB-marker that is acting up, and it turns out it isn't.
in rde.c line 2613 we commented out this:
if (peer-capa_received.restart
* Arnoud Vermeer arnoud.verm...@ams-ix.net [2009-03-08 22:54]:
No, this is not the only session. Here is the full config, I hope it helps:
Things start going wrong when I add the following to a v6 session:
tcp md5sig password hondjes
wait. removing tcpmd5 fixes the problem? you gotta be
Hi Henning and Claudio,
Claudio Jeker wrote:
Btw. does this only happen with full IPv6 feeds or are a few
announcements already enough?
We have two test setups. One actually includes real peers, none sending
a full table though. The other one is a setup in our lab, with various
routers we
I didn't modify the source code in any way. I'm running the latest
version from CVS on an amd64 machine and an i386 machine.
I have the following configuration:
AS 6777
router-id 195.69.145.245
fib-update no
log updates
listen on 195.69.145.245
listen on 2001:7F8:1::A500:6777:4
nexthop qualify
* Arnoud Vermeer arnoud.verm...@ams-ix.net [2009-03-08 21:06]:
I didn't modify the source code in any way. I'm running the latest
version from CVS on an amd64 machine and an i386 machine.
I have the following configuration:
AS 6777
router-id 195.69.145.245
fib-update no
log updates
No, this is not the only session. Here is the full config, I hope it helps:
Things start going wrong when I add the following to a v6 session:
tcp md5sig password hondjes
--
AS 6777
router-id 195.69.145.245
fib-update no
log updates
listen on 195.69.145.245
listen on 2001:7F8:1::A500:6777:4
Ok, so this is what the RFC4724, section 2 states:
For the IPv4 unicast address family, the End-of-RIB
marker is an UPDATE message with the minimum length [BGP-4]. For any
other address family, it is an UPDATE message that contains only the
MP_UNREACH_NLRI attribute [BGP-MP] with no
* Arnoud Vermeer arnoud.verm...@ams-ix.net [2009-02-26 16:21]:
Foundry advertises the route refresh capability ( RFC2918 ), and not the
ability for Graceful Restart Mechanism for BGP ( RFC4724 ). In Frame 75
the route server sends AS1200 a big update. AS1200 responds in frame 87
with a
On Mon, Feb 23, 2009 at 02:11:38PM +0100, Arnoud Vermeer wrote:
I found a different way to replicate the bug, this time it crashes ALL
the IPv6 sessions connected to multiple Foundry switches (cisco seems
fine). I have setup a v6 session with a tcp md5sig like so:
group peers-rs-v6 {
Hi Claudio,
I've attached both the MRT session dumps and a tcpdump capture.
Kind regards,
Arnoud Vermeer
Claudio Jeker schreef:
On Mon, Feb 23, 2009 at 02:11:38PM +0100, Arnoud Vermeer wrote:
I found a different way to replicate the bug, this time it crashes ALL
the IPv6 sessions
I found a different way to replicate the bug, this time it crashes ALL
the IPv6 sessions connected to multiple Foundry switches (cisco seems
fine). I have setup a v6 session with a tcp md5sig like so:
group peers-rs-v6 {
announce IPv6 unicast
announce IPv4 none
* Stuart Henderson s...@spacehopper.org [2009-01-30 17:59]:
On 2009-01-29, Arnoud Vermeer arnoud.verm...@ams-ix.net wrote:
While looking in to the problem, we found out that OpenBGPD sends a
empty UPDATE, on which quagga responds by terminating the process.
...
While doing a tcpdump we
Hi Tico,
The problem is limited to quagga it seems. I have setup a juniper and
cisco session and they both come up fine. Only the quagga routers seem
to hang on the empty update.
I have the following in my bgpd.conf:
group peers-rs-v6 {
announce IPv6 unicast
announce IPv4 none
On Fri, Jan 30, 2009 at 03:14:00PM +0100, Arnoud Vermeer wrote:
Hi Tico,
The problem is limited to quagga it seems. I have setup a juniper and
cisco session and they both come up fine. Only the quagga routers seem
to hang on the empty update.
...
The quagga log shows the following:
On 2009-01-29, Arnoud Vermeer arnoud.verm...@ams-ix.net wrote:
While looking in to the problem, we found out that OpenBGPD sends a
empty UPDATE, on which quagga responds by terminating the process.
...
While doing a tcpdump we found the following packets leading to a
NOTIFICATION. As you can
Hi,
I found a bug while working on a route server implementation based on
OpenBGPD. I have a IPv6 session from OpenBGPD 4.4 (on OpenBSD 4.4,
routeertnix) to Quagga 0.99.5 (laborantix).
I have multiple IPv4 peers, and multiple IPv6 peers in the setup. When I
start the BGP daemon, everything
Arnoud Vermeer wrote:
Hi,
I found a bug while working on a route server implementation based on
OpenBGPD. I have a IPv6 session from OpenBGPD 4.4 (on OpenBSD 4.4,
routeertnix) to Quagga 0.99.5 (laborantix).
Hello Arnoud,
I'm running a native IPv6 session from OpenBGPD 4.4 to a Foundry of
* tico tico-o...@raapid.net [2009-01-29 18:53]:
The only time I've had a session get hung down is once or twice when
running 4.3 and having made several bgpd.conf changes and issuing
bgpctl reload several times -- I believe it was regarding changing an
MD5 secret but I can't remember for
21 matches
Mail list logo
