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 via bgp
transparent-as yes
dump all in "/tmp/all-in-dump-%H%M" 300
dump all out "/tmp/all-out-dump-%H%M" 300
group "peers-rs-v6" {
announce IPv6 unicast
announce IPv4 none
softreconfig in yes
enforce neighbor-as yes
set nexthop no-modify
local-address 2001:7F8:1::A500:6777:4
neighbor 2001:7f8:1::A500:1200:1 {
descr "AS1200-v6-01"
remote-as 1200
announce all
passive
}
}
The comment about the gracefull restart lead me to think about the
following setting:
announce capabilities (yes|no)
If set to no, capability negotiation is disabled during
the es-
tablishment of the session. This can be helpful to connect to
old or broken BGP implementations. The default is yes.
Doesn't this troggle the graceful update? While reading the announce
part of the manual, I noticed the following:
announce (all|none|self|default-route)
If set to none, no UPDATE messages will be sent to the
neighbor.
If set to default-route, only the default route will be
announced
to the neighbor. If set to all, all generated UPDATE messages
will be sent to the neighbor. This is usually used for
transit
AS's and IBGP peers. The default value for EBGP peers is
self,
which limits the sent UPDATE messages to announcements of
the lo-
cal AS. The default for IBGP peers is all.
I also have announce all, in my configuration, because it is a route
server I'm working on. Could this be the setting that is responsible for
the UPDATE?
Arnoud
On 3/7/09 6:39 PM, Henning Brauer wrote:
> 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 why I
> can't find an error wrt the EoR-marker :)
>
> hrm.<
>
> * Arnoud Vermeer<arnoud.verm...@ams-ix.net> [2009-03-06 17:23]:
>
>> 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 withdrawn routes for that
>> <AFI, SAFI>."
>>
>> The minimal length of BGPD-4 is 23 bytes.
>>
>> So were using IPv6 unicast so the UPDATE should contain a
>> MP_UNREACH_NLRI attribute. Here's the wireshark export of the UPDATE
>> message:
>>
>> No. Time Source Destination Protocol
>> Info
>> 114 42.464461 2001:7f8:1::a500:6777:4 2001:7f8:1::a503:4763:1
>> BGP UPDATE Message
>>
>> Frame 114 (115 bytes on wire, 115 bytes captured)
>> Ethernet II, Src: Dell_36:ca:9f (00:1e:4f:36:ca:9f), Dst: Cisco_53:c4:1c
>> (00:05:00:53:c4:1c)
>> Internet Protocol Version 6
>> Transmission Control Protocol, Src Port: bgp (179), Dst Port: 53076
>> (53076), Seq: 207, Ack: 1, Len: 41
>> Border Gateway Protocol
>> UPDATE Message
>> Marker: 16 bytes
>> Length: 41 bytes
>> Type: UPDATE Message (2)
>> Unfeasible routes length: 0 bytes
>> Total path attribute length: 0 bytes
>>
>> 0000 00 05 00 53 c4 1c 00 1e 4f 36 ca 9f 86 dd 60 08 ...S....O6....`.
>> 0010 14 2b 00 3d 06 01 20 01 07 f8 00 01 00 00 00 00 .+.=.. .........
>> 0020 a5 00 67 77 00 04 20 01 07 f8 00 01 00 00 00 00 ..gw.. .........
>> 0030 a5 03 47 63 00 01 00 b3 cf 54 61 e2 4d 63 51 ce ..Gc.....Ta.McQ.
>> 0040 f6 d1 50 18 43 80 7b dd 00 00 ff ff ff ff ff ff ..P.C.{.........
>> 0050 ff ff ff ff ff ff ff ff ff ff 00 29 02 00 00 00 ...........)....
>> 0060 00 *12 80 0f 0f 00 02 01 2a 02 00 10 01 03 20 20* ........*.....
>> 0070 *01 00 00*
>>
>> So it says the total path attribute length is 0 bytes, but I have 18
>> bits of 'unsolved matterial' at the end of the packet '*12 80 0f 0f 00
>> 02 01 2a 02 00 10 01 03 20 20 **01 00 00*'.
>>
>> So for a IPv4 unicast 'END-of RIB'-marker it is invalid because of the
>> junk at the end, and for the IPv6 unicast family the update attribute is
>> missing the MP_UNREACH_NLRI attribute.
>>
>> So the conclusion is, that this isn't a (valid) 'END-of-RIB'-marker.
>>
>> On 2/26/09 4:52 PM, Henning Brauer wrote:
>>
>>> * 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 notification of a malformed attribute.
>>>>
>>>> The route server also sends an empty update to the other foundry router
>>>> (XSNEWS), wich crashes there session, because they don't advertise
>>>> Graceful restart:
>>>>
>>>>
>>> an empty UPDATE is valid no matter what, wether graceful restart was
>>> advertised or not.
