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.
>
--
Henning Brauer, h...@bsws.de, henn...@openbsd.org
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
