Bug 214481 - net/quagga: ipv6 routes fail in quagga
Summary: net/quagga: ipv6 routes fail in quagga
Status: Closed Overcome By Events
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-ports-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-11-13 16:57 UTC by dgilbert
Modified: 2024-10-23 16:54 UTC (History)
5 users (show)

See Also:
bugzilla: maintainer-feedback? (pi)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description dgilbert 2016-11-13 16:57:43 UTC
After upgrading to 10.3p12 and messing about a bit, I found something else strange.  On another mpd router, the ipv6 route was showing up as being on an unused port (bce1, in this case).  I have the port connected to the switch (so it's up) but I'm not using it.  So... I ifconfig'd down bce0.  Then, quagga claims:

my.other.router.ca# sh ipv6 route 1001:abcd:1::1
Routing entry for 1001:abcd:1::/64
  Known via "kernel", distance 0, metric 0, tag 0, vrf 0, best, fib
  >* fe80::212:3fff:fe41:72fd, via lo0

... which is somewhat ridiculous.



On Sun, Nov 13, 2016 at 12:51 AM, Zaphod Beeblebrox <zbeeble@gmail.com> wrote:

    I have an if-up mpd5 rule that says:

    route -n6 add $route -iface $interface

    where $route is something like 1001:abcd:1::/64 and $interface is something like ng2.

    When I go into quagga, I see:

    my.router.ca# sh ipv6 route 1001:abcd:1::1
    Routing entry for 1001:abcd:1::/64
      Known via "kernel", distance 0, metric 0, tag 0, vrf 0, best, fib
      >* fe80::212:3fff:fe41:72fd, via bge0

    ... now there's two things wrong with this.  It's not a kernel route and it's not via bge0.  This leads the ospf6 advertisement of this route to be:

    my.router.ca# sh ipv6 ospf6 route 1001:abcd:1::1
    Destination: ::/0
    Destination type: Network
    Installed Time: 00:13:29 ago
      Changed Time: 00:13:29 ago
    Lock: 2 Flags: BA--
    Memory: prev: 0x0 this: 0x7026f0 next: 0x704dd0
    Associated Area: 0.0.0.0
    Path Type: External-1
    LS Origin: AS-External Id: 0.0.0.0 Adv: 1.2.3.4
    Options: --|-|-|--|-|--
    Router Bits: --------
    Prefix Options: xxx
    Metric Type: 1
    Metric: 20 (0)
    Nexthop:
      fe80::21a:64ff:fe79:3348 bge0.401

    ... which leads other ospf6 routers on the network to not see the route at all (invalid?)
Comment 1 Kurt Jaeger freebsd_committer freebsd_triage 2017-01-24 16:45:10 UTC
There was a mention of

https://bugzilla.quagga.net/show_bug.cgi?id=870

which is still open in 1.1.1.
Comment 2 dgilbert 2017-01-24 17:24:11 UTC
TBH, I've been looking at bird.  I've used zebra/quagga since 1999-ish, and it's always been a _bit_ buggy, but another FreeBSD ISP and I have been talking on and off the FreeBSD lists (we know who we are) and quagga's bugs seem worse, not better.

Right now, the 1.1.0 version of quagga has indeterminate ipv6 bugs (ospf6d also crashes relatively often) and some eBGP/iBGP bugs, to name a couple.
Comment 3 Mathieu Arnold freebsd_committer freebsd_triage 2017-01-24 18:09:32 UTC
I've been wondering about adding a quagga10 port for the latest working 1.0 version, I have one on in my local poudriere...
Comment 4 Kurt Jaeger freebsd_committer freebsd_triage 2017-03-14 20:49:26 UTC
Bug still in 1.2.1 8-(
Comment 5 mike 2017-08-30 13:58:36 UTC
Does ports/net/frr/ show the same bug ?
Comment 6 Kurt Jaeger freebsd_committer freebsd_triage 2017-10-08 11:13:17 UTC
Testcase reported by Alexander Magliovany

R1: IPv6 - 2002:2222::1/64

router bgp 1111
  bgp router-id 1111
  neighbor 2002:2222::2  remote-as 2222
  no neighbor 2002:2222::2  activate
!
  address-family ipv6
  network 2002:1111::/32
  neighbor 2002:2222::2 activate
  exit-address-family
!


R2: IPv6 - 2002:2222::2

router bgp 2222
  bgp router-id 2222
  neighbor 2002:2222::1  remote-as 1111
  no neighbor 2002:2222::1  activate
!
  address-family ipv6
  neighbor 2002:2222::1 activate
  exit-address-family
!

On R2 run:

vtysh -c "sh ipv6 route"

where all received routes will be inactive and 'netstat -6rn' will not 
have the 2002:1111::/32 preffix via 2002:2222::2
Comment 7 Chuck Anderson 2017-11-09 07:59:56 UTC
(In reply to Kurt Jaeger from comment #6)

I'm having the same exact issue as Kurt.  

lab-router# show ipv6 bgp 2000::/3
BGP routing table entry for 2000::/3
Paths: (2 available, no best path)
  Not advertised to any peer
  65001
    fc00:f5c0:8040:670::1 (inaccessible) from fc00:f5c0:8040:670::1 (10.215.0.33)
    (fe80::8271:1f01:9cc6:67f0)
      Origin IGP, metric 1, localpref 100, invalid, external
      Last update: Thu Nov  9 02:28:43 2017

  65001
    fc00:f5c0:8040:174::1 (inaccessible) from fc00:f5c0:8040:174::1 (10.215.0.34)
    (fe80::2e21:7201:a068:ff0)
      Origin IGP, metric 1, localpref 100, invalid, external
      Last update: Thu Nov  9 02:23:18 2017

lab-router# show ipv6 route
Codes: K - kernel route, C - connected, S - static, R - RIPng,
       O - OSPFv6, I - IS-IS, B - BGP, A - Babel, N - NHRP,
       > - selected route, * - FIB route

K * ::/0 via fc00:f5c0:8040:670::1 inactive
K>* ::/96 via ::1, lo0, rej
C>* ::1/128 is directly connected, lo0
K>* ::ffff:0.0.0.0/96 via ::1, lo0, rej
C>* fc00:f5c0:8040:174::/126 is directly connected, vlan416
C>* fc00:f5c0:8040:670::/126 is directly connected, vlan412
S>* fc00:f5c0:8040:670::1/128 [1/0] is directly connected, vlan412
C>* fc00:f5c0:8040:a08a::1/128 is directly connected, lo0
C>* fc00:f5c0:8040:a08a::2/128 is directly connected, lo0
C>* fc00:f5c0:8040:a08a::3/128 is directly connected, lo0
C>* fc00:f5c0:8040:a08a::21/128 is directly connected, lo0
C>* fc00:f5c0:8040:a08a::22/128 is directly connected, lo0
K>* fe80::/10 via ::1, lo0, rej
C * fe80::/64 is directly connected, vlan412
C * fe80::/64 is directly connected, vlan1005
C * fe80::/64 is directly connected, vlan416
C * fe80::/64 is directly connected, lagg0
C * fe80::/64 is directly connected, lo0
C * fe80::/64 is directly connected, em2
C * fe80::/64 is directly connected, em1
C>* fe80::/64 is directly connected, em0
K>* ff02::/16 via ::1, lo0, rej

lab-router# show ipv6 route fc00:f5c0:8040:670::1 
Routing entry for fc00:f5c0:8040:670::/126
  Known via "connected", distance 0, metric 1, tag 0, vrf 0, best, fib
  >* directly connected, vlan412

lab-router# ping ipv6 fc00:f5c0:8040:670::1    
PING6(56=40+8+8 bytes) fc00:f5c0:8040:670::2 --> fc00:f5c0:8040:670::1
16 bytes from fc00:f5c0:8040:670::1, icmp_seq=0 hlim=64 time=0.674 ms
16 bytes from fc00:f5c0:8040:670::1, icmp_seq=1 hlim=64 time=0.579 ms
16 bytes from fc00:f5c0:8040:670::1, icmp_seq=2 hlim=64 time=0.681 ms
^C
--- fc00:f5c0:8040:670::1 ping6 statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.579/0.645/0.681/0.047 ms

lab-router# show bgp summ

IPv4 Unicast Summary:
---------------------
BGP router identifier 10.215.41.34, local AS number 65000
RIB entries 12, using 1344 bytes of memory
Peers 4, using 36 KiB of memory

Neighbor        V         AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.215.0.113    4 65001     143     143        0    0    0 00:23:15        4
10.215.0.117    4 65001     149     143        0    0    0 00:28:41        4
fc00:f5c0:8040:174::1
                4 65001     122     129        0    0    0 00:28:41        0
fc00:f5c0:8040:670::1
                4 65001     117     126        0    0    0 00:23:16        0

Total number of neighbors 4

Total num. Established sessions 4
Total num. of routes received     8
...

#sh run 
...
interface lo0
 ip address 10.215.41.1/32
 ip address 10.215.41.2/32
 ip address 10.215.41.3/32
 ip address 10.215.41.34/32
 ipv6 address fc00:f5c0:8040:a08a::1/128
 ipv6 address fc00:f5c0:8040:a08a::2/128
 ipv6 address fc00:f5c0:8040:a08a::22/128
 ipv6 address fc00:f5c0:8040:a08a::3/128
...
!
interface vlan412
 ip address 10.215.0.114/30
 ipv6 address fc00:f5c0:8040:670::2/126
 no link-detect
!
interface vlan416
 ip address 10.215.0.118/30
 ipv6 address fc00:f5c0:8040:174::2/126
 no link-detect
!
...
router bgp 65000
 bgp router-id 10.215.41.34
 network 10.215.41.1/32
 network 10.215.41.2/32
 network 10.215.41.3/32
 network 10.215.41.34/32
 neighbor 10.215.0.113 remote-as 65001
 neighbor 10.215.0.113 soft-reconfiguration inbound
 neighbor 10.215.0.113 prefix-list DEFAULT in
 neighbor 10.215.0.113 prefix-list ORIGINATE out
 neighbor 10.215.0.117 remote-as 65001
 neighbor 10.215.0.117 soft-reconfiguration inbound
 neighbor 10.215.0.117 prefix-list DEFAULT in
 neighbor 10.215.0.117 prefix-list ORIGINATE out
 neighbor fc00:f5c0:8040:174::1 remote-as 65001
 neighbor fc00:f5c0:8040:670::1 remote-as 65001
!
 address-family ipv6
 network fc00:f5c0:8040:a08a::1/128
 network fc00:f5c0:8040:a08a::2/128
 network fc00:f5c0:8040:a08a::3/128
 network fc00:f5c0:8040:a08a::22/128
 neighbor fc00:f5c0:8040:174::1 activate
 neighbor fc00:f5c0:8040:174::1 soft-reconfiguration inbound
 neighbor fc00:f5c0:8040:174::1 prefix-list DEFAULT in
 neighbor fc00:f5c0:8040:174::1 prefix-list ORIGINATE out
 neighbor fc00:f5c0:8040:670::1 activate
 neighbor fc00:f5c0:8040:670::1 soft-reconfiguration inbound
 neighbor fc00:f5c0:8040:670::1 prefix-list DEFAULT in
 neighbor fc00:f5c0:8040:670::1 prefix-list ORIGINATE out
 exit-address-family
 exit
!
ip prefix-list DEFAULT seq 10 permit 0.0.0.0/0
ip prefix-list DEFAULT seq 20 permit 0.0.0.0/1
ip prefix-list DEFAULT seq 30 permit 128.0.0.0/1
ip prefix-list DEFAULT seq 40 permit 128.0.0.0/2
ip prefix-list DEFAULT seq 50 permit 192.0.0.0/3
ip prefix-list ORIGINATE seq 10 permit 10.215.41.34/32
ip prefix-list ORIGINATE seq 20 permit 10.215.41.1/32
ip prefix-list ORIGINATE seq 30 permit 10.215.41.2/32
ip prefix-list ORIGINATE seq 40 permit 10.215.41.3/32
!
ipv6 prefix-list DEFAULT seq 10 permit ::/0
ipv6 prefix-list DEFAULT seq 20 permit ::/1
ipv6 prefix-list DEFAULT seq 30 permit 2000::/3
ipv6 prefix-list DEFAULT seq 40 permit 8000::/1
ipv6 prefix-list ORIGINATE seq 10 permit fc00:f5c0:8040:a08a::22/128
ipv6 prefix-list ORIGINATE seq 20 permit fc00:f5c0:8040:a08a::1/128
ipv6 prefix-list ORIGINATE seq 30 permit fc00:f5c0:8040:a08a::2/128
ipv6 prefix-list ORIGINATE seq 40 permit fc00:f5c0:8040:a08a::3/128
!
Comment 8 Kurt Jaeger freebsd_committer freebsd_triage 2017-11-09 08:29:14 UTC
Please test net/frr to see if it solves that problem. It's config
is pretty much compatible (make a copy, quagga probably won't like the frr config).
Comment 9 commit-hook freebsd_committer freebsd_triage 2017-12-19 15:29:03 UTC
A commit references this bug:

Author: pi
Date: Tue Dec 19 15:28:10 UTC 2017
New revision: 456724
URL: https://svnweb.freebsd.org/changeset/ports/456724

Log:
  net/quagga: add patches to fix IPv6, multi-segment AS_PATH UPDATE fix

  - For the IPv6 problem description see also:
    https://bugzilla.quagga.net/show_bug.cgi?id=870
    https://lists.quagga.net/pipermail/quagga-dev/2017-December/033309.html
  - Another part of the multi-segment AS_PATH UPDATE
    message length calculation fix

  PR:		214481
  Reported by:	dgilbert@eicat.ca

Changes:
  head/net/quagga/Makefile
  head/net/quagga/files/patch-bgpd_bgp__aspath.c
  head/net/quagga/files/patch-bgpd_bgp__nht.c
  head/net/quagga/files/patch-configure
  head/net/quagga/files/patch-doc_bgpd.8
Comment 10 Kurt Jaeger freebsd_committer freebsd_triage 2018-03-03 18:56:29 UTC
TODO: testing, if quagga-1.2.4 still has this problem
Comment 11 Kurt Jaeger freebsd_committer freebsd_triage 2022-12-27 20:46:23 UTC
I no longer use quagga.
Comment 12 dgilbert 2022-12-27 21:15:10 UTC
Oi.  I'll throw my hat in this ring.  If nobody more qualified steps up, I'll maintain.  Attesting to my qualifications is an AS (AS30528) and a full feed of IPv4 and IPv6 routes.
Comment 13 mike 2022-12-28 13:54:13 UTC
net/frr8 is very actively maintained / developed. Quagga kinda feels like abandonware at this point no ?
Comment 14 dgilbert 2022-12-28 18:08:06 UTC
so... didn't fully read everything.  Yeah... Quagga's kinda dead.  Been following this tree through thick and thin since it was Zebra.
Comment 15 mike 2022-12-28 18:13:51 UTC
(In reply to dgilbert from comment #14)

Same for me, re: since zebra. I am sure there are new frr users who wonder, "why the heck is there a daemon called.... 'zebra' ... in the frr routing suite ?" :)
Comment 16 Daniel Engberg freebsd_committer freebsd_triage 2022-12-31 13:48:08 UTC
Marked as deprecated as of https://cgit.freebsd.org/ports/commit/?id=d496ebd9a5de472c99f36179cbef35079ee0c9a4

Most distros have already dropped it, https://repology.org/project/quagga/versions
Comment 17 Eugene Grosbein freebsd_committer freebsd_triage 2023-01-03 07:39:55 UTC
I assumed maintainership of our quagga port.
Is this problem still actual for you?
Comment 18 Zsolt Udvari freebsd_committer freebsd_triage 2024-10-23 16:54:13 UTC
No reaction for more than a year. Closing.