tags 492345 + upstream found 492345 0.99.5-5etch3 forwarded 492345 http://bugzilla.quagga.net/show_bug.cgi?id=445 stop
Hello John You better ask again on the quagga-dev/user mailing list for a comment on this bug and, if you have time, add some examples how a Cisco would act or what the RFCs say etc. My knowledge of BGP is too limited to judge the report, let alone to patch around in the source code :) bye, -christian- On 2008-07-25 John Morrissey wrote: > Package: quagga > Version: 0.99.5-5etch3horde1 > Severity: normal > > I reported this bug upstream a few months ago and haven't been able to get > any response, though this seems broken in a fairly obvious manner(?). > > It's probably too late to have any fix make the lenny freeze, but I'm > hoping that giving this bug more exposure might help bring it to the > attention of the right people. Christian, I'm sure you know the quagga > source better than I do, and maybe you know someone who hacks on Quagga > that might be interested in looking at this? > > > http://marc.info/?l=quagga-users&m=120576712714935&w=2 > http://bugzilla.quagga.net/show_bug.cgi?id=445 > > I'm running IBGP over a GRE tunnel: > > [EMAIL PROTECTED]:pts/5 ~> ifconfig gre1 > gre1 Link encap:UNSPEC HWaddr > AC-10-41-02-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:172.17.65.2 > P-t-P:172.17.65.1 Mask:255.255.255.255 > > zebra gets the endpoints right: > > boost# sh int gre1 > Interface gre1 is up, line protocol detection is disabled > index 18 metric 1 mtu 1476 > flags: <UP,POINTOPOINT,RUNNING,NOARP> > HWaddr: ac:10:41:02 > inet 172.17.65.2/32 pointopoint 172.17.65.1 > 374 input packets (0 multicast), 30117 bytes, 0 dropped > 0 input errors, 0 length, 0 overrun, 0 CRC, 0 frame > 0 fifo, 0 missed > 544 output packets, 47274 bytes, 0 dropped > 3 output errors, 0 aborted, 3 carrier, 0 fifo, 0 heartbeat > 0 window, 0 collisions > > as does bgpd, but it detects the wrong end of the tunnel as the nexthop > (i.e., it sees itself as the only legitimate nexthop instead of the > opposite end of the tunnel): > > boost# sh ip bgp nei > [...] > Local host: 172.17.65.2, Local port: 36205 > Foreign host: 172.17.65.1, Foreign port: 179 > Nexthop: 172.17.65.2 > > Since I have 'set nexthop self' in the peer (OpenBSD bgpd(8)), quagga bgpd > rejects all of its announcements: > > 172.17.65.1 rcvd UPDATE about 192.168.197.16/28 -- DENIED due to: martian > next-hop; > > If I remove the bgp_nexthop_self() check: > > --- quagga-0.99.5.orig/bgpd/bgp_route.c > +++ quagga-0.99.5/bgpd/bgp_route.c > @@ -1934,8 +1934,7 @@ > > /* Next hop must not be 0.0.0.0 nor Class E address. Next hop > must not be my own address. */ > - if (bgp_nexthop_self (afi, &new_attr) > - || new_attr.nexthop.s_addr == 0 > + if (new_attr.nexthop.s_addr == 0 > || ntohl (new_attr.nexthop.s_addr) >= 0xe0000000) > { > reason = "martian next-hop;"; > > the announcements are accepted and have the correct next hop: > > [EMAIL PROTECTED]:pts/5 ~> netstat -rn > [...] > 192.168.197.16 172.17.65.1 255.255.255.240 UG 0 0 0 > gre1 > > > Shouldn't BGP neighbor output be showing the opposite end of the GRE tunnel > as the next hop, not itself? > > -- System Information: > Debian Release: 4.0 > APT prefers stable > APT policy: (500, 'stable') > Architecture: alpha > Shell: /bin/sh linked to /bin/bash > Kernel: Linux 2.6.18-6-alpha-smp > Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) > > Versions of packages quagga depends on: > ii adduser 3.102 Add and remove users and > groups ii debconf [debconf-2.0] 1.5.11etch1 Debian configuration > management sy ii iproute 20061002-3 Professional > tools to control the ii libc6.1 2.3.6.ds1-13etch5 GNU C > Library: Shared libraries ii libcap1 1:1.10-14 > support for getting/setting POSIX. ii libpam0g > 0.79-5 Pluggable Authentication Modules l ii > libreadline5 5.2-2 GNU readline and history > libraries ii logrotate 3.7.1-3 Log rotation utility > > quagga recommends no packages. > > -- debconf information: > * quagga/really_stop: true > >
signature.asc
Description: PGP signature
