Since my last email bounced.
At this point I believe FRR is sending data that is not properly
formatted at this point in time. This problem is actively being
worked at this point in time.
donald
On Thu, Jul 11, 2019 at 10:58 AM Ondrej Zajicek wrote:
>
> On Thu, Jul 11, 2019 at 04:23:18PM
On Thu, Jul 11, 2019 at 04:23:18PM +0200, Ondrej Zajicek wrote:
> On Thu, Jul 11, 2019 at 04:01:19PM +0200, Hansen, Christoffer wrote:
> > Derrick,
> >
> > Donald is right. Ignore earlier comment. (rfc4760[0], p. 5)
> >
> > > From the pcap this looks like FRR is sending an empty NLRI and
> > >
On Thu, Jul 11, 2019 at 04:01:19PM +0200, Hansen, Christoffer wrote:
> Derrick,
>
> Donald is right. Ignore earlier comment. (rfc4760[0], p. 5)
>
> > From the pcap this looks like FRR is sending an empty NLRI and
> > according to RFC 2858:
> >
> >An UPDATE message that carries no NLRI,
Derrick,
Donald is right. Ignore earlier comment. (rfc4760[0], p. 5)
From the pcap this looks like FRR is sending an empty NLRI and
according to RFC 2858:
An UPDATE message that carries no NLRI, other than the one encoded in
the MP_REACH_NLRI attribute, should not carry the NEXT_HOP
Derrick,
Possible a missing next-hop attribute can be the case?
From [0]:
attribute EBGPIBGP
ORIGIN mandatory mandatory
AS_PATHmandatory mandatory
NEXT_HOP mandatory
