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 2001:db8:1::
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 fuck
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
(XSN
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 cou
* Arnoud Vermeer [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 kidding?
this is on OpenBS
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 && peer->capa_
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 && peer->capa_announced.restart)
peer_send_eor(peer, afi, safi);
This is the only pl
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
nex
* Arnoud Vermeer [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
> listen on 195.69.1
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
wow.
I can't see where this could happen, code seems straightforward. but
I'll keep digging...
the strange thing beeing - restart (and thus sending of the EoR marker)
is disabled unless you changed the code. if you didn't, this is some
genuine bug and not the EoR-marker at all. which would explain
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 [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 notification of a malformed a
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 c
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" {
>
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
softreconf
* Stuart Henderson [2009-01-30 17:59]:
> On 2009-01-29, Arnoud Vermeer 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 leadi
On 2009-01-29, Arnoud Vermeer 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 see, frame 19 is an
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
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
* tico [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 sure. Either
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 s
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 starts
23 matches
Mail list logo
