1. ripencc
  2. bgpdump
  3. Issues
Issue #5 resolved

Incorrect nexthop when processing routeviews

Devin Bayer
created an issue

Version: libbgpdump-1.4.99.12

First reported to ris@ripe.net (RT#1005242)

We found a possible bug in the bgpdump cod when we processed some
routeviews updates. Below is an example output for the same update
with or without the -m option:

======= (without -m) TIME: 02/11/07 01:55:28 TYPE: BGP4MP/MESSAGE/Update FROM: 195.66.224.138 AS2914 TO: 195.66.225.222 AS6447 ORIGIN: INCOMPLETE ASPATH: 2914 10888 3948 16517 MULTI_EXIT_DISC: 348 MP_REACH_NLRI(IPv4 Multicast) NEXT_HOP: 195.66.224.138 COMMUNITY: 2914:420 ANNOUNCE 157.130.0.0/16

(with -m) BGP4MP|1171158928|A|195.66.224.138|2914|157.130.0.0/16|2914 10888
3948 16517|INCOMPLETE|255.255.255.255|0|348|2914:420|NAG|| ========

You can see that the nexthop field is incorrect when we use the -m
option. I notice that the first output has MP_REACH_NLRI (IPv4
Multicast), so my guess is that the code for the -m option didn't
retrieve the nexthop for the appropriate AFI/SAFI option.

Comments (1)

  1. Colin Petrie

    Fix incorrect nexthop in MP IPv4-AFI Use the MP nexthop, not the NEXT_HOP attr Some peers where MP IPv4 is used, do not set the NEXT_HOP These would result in 255.255.255.255 being printed for the nexthop Committed in 5aaa5a1

  2. Log in to comment