Incorrect nexthop when processing routeviews
First reported to firstname.lastname@example.org (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: 126.96.36.199 AS2914 TO: 188.8.131.52 AS6447 ORIGIN: INCOMPLETE ASPATH: 2914 10888 3948 16517 MULTI_EXIT_DISC: 348 MP_REACH_NLRI(IPv4 Multicast) NEXT_HOP: 184.108.40.206 COMMUNITY: 2914:420 ANNOUNCE 220.127.116.11/16
(with -m) BGP4MP|1171158928|A|18.104.22.168|2914|22.214.171.124/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.