Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug
report.
http://bugzilla.quagga.net/show_bug.cgi?id=377
------- Additional Comments From eugen@grosbein.pp.ru 2007-06-20 07:24 -------
In short: quagga-0.99.7 erroneously marks a prefix inactive if it is received
from eBGP peer and this prefix has nexthop that was announced by (another) eBGP
peer.
This is a real configuration that one of biggest national Network Operators
in Russia offers for BGP peering with Autonomous Systems in East Siberian
region in case of eBGP multihop (ip addresses are mangled):
1) Our AS has 1.1.1.1/30 on the external ethernet link
2) eBGP peer 2.2.2.2 of Network Operator is reachable through 1.1.1.2,
hence this static route:
ip route 2.2.2.2/32 1.1.1.2
The peer 2.2.2.2 obtains our announces and announces the only prefix to us:
3.3.3.3/32 with nexthop 2.2.2.2
3) 3.3.3.3 is another our eBGP peer (the same Network Operator's), it announces
default route to us with nexthop 3.3.3.3. quagga marks this default route as
inactive.
The workaround is to filter out incoming BGP announce 3.3.3.3/32 from 2.2.2.2
and use static route instead:
ip route 3.3.3.3/32 1.1.1.2
Then quagga does not mark this route as inactive and all works just fine.
I've tracked the problem till zebra/zebra_rib.c, function nexthop_active_ipv4()
and found that it contains special processing for BGP-received prefixes,
the logic implemented there seems to be broken. It's where from the beginning.
------- Additional Comments From paul@dishone.st 2007-06-25 11:43 -------
Can we see:
bgpd: show ip bgp <bgp route>
zebra: show ip route <bgp route>
show ip route <bgp route nexthop>
?
This sounds like a misconfig, but need more information to say.
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
_______________________________________________
Quagga-bugs mailing list
Quagga-bugs@lists.quagga.net
http://lists.quagga.net/mailman/listinfo/quagga-bugs
comments should be made in the comments box of this bug
report.
http://bugzilla.quagga.net/show_bug.cgi?id=377
------- Additional Comments From eugen@grosbein.pp.ru 2007-06-20 07:24 -------
In short: quagga-0.99.7 erroneously marks a prefix inactive if it is received
from eBGP peer and this prefix has nexthop that was announced by (another) eBGP
peer.
This is a real configuration that one of biggest national Network Operators
in Russia offers for BGP peering with Autonomous Systems in East Siberian
region in case of eBGP multihop (ip addresses are mangled):
1) Our AS has 1.1.1.1/30 on the external ethernet link
2) eBGP peer 2.2.2.2 of Network Operator is reachable through 1.1.1.2,
hence this static route:
ip route 2.2.2.2/32 1.1.1.2
The peer 2.2.2.2 obtains our announces and announces the only prefix to us:
3.3.3.3/32 with nexthop 2.2.2.2
3) 3.3.3.3 is another our eBGP peer (the same Network Operator's), it announces
default route to us with nexthop 3.3.3.3. quagga marks this default route as
inactive.
The workaround is to filter out incoming BGP announce 3.3.3.3/32 from 2.2.2.2
and use static route instead:
ip route 3.3.3.3/32 1.1.1.2
Then quagga does not mark this route as inactive and all works just fine.
I've tracked the problem till zebra/zebra_rib.c, function nexthop_active_ipv4()
and found that it contains special processing for BGP-received prefixes,
the logic implemented there seems to be broken. It's where from the beginning.
------- Additional Comments From paul@dishone.st 2007-06-25 11:43 -------
Can we see:
bgpd: show ip bgp <bgp route>
zebra: show ip route <bgp route>
show ip route <bgp route nexthop>
?
This sounds like a misconfig, but need more information to say.
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
_______________________________________________
Quagga-bugs mailing list
Quagga-bugs@lists.quagga.net
http://lists.quagga.net/mailman/listinfo/quagga-bugs