BGPD filter issue?
I believe I've stumbled across an issue with filters in -current
This seems to have only bitten since updating from 4.2 release to -
current anyway ...
80.252.124.20 is in group "switches"
yet ...
[EMAIL PROTECTED] bgpctl sh rib nei 80.252.124.20 out
flags: * = Valid, > = Selected, I = via IBGP, A = Announced
origin: i = IGP, e = EGP, ? = Incomplete
flags destination gateway lpref med aspath origin
[EMAIL PROTECTED] bgpctl sh rib nei 80.252.124.20 out
flags: * = Valid, > = Selected, I = via IBGP, A = Announced
origin: i = IGP, e = EGP, ? = Incomplete
flags destination gateway lpref med aspath origin
*>192.88.83.0/24 80.252.125.2 200 0 9179 i
*>193.195.141.0/2480.252.125.2 200 0 9179 i
*>213.170.0.0/19 80.252.125.2 200 0 9179 i
from bgpd.conf
my_nets = "{ 80.252.112.0/20, 84.246.192.0/21, 194.70.36.0/24 }"
allow to group switches community 8282:400
allow to group switches prefix $my_nets
bgpd -nv reports (abbreviated, full details available if necessary)
allow to group "switches" community 8282:400
allow to group "switches" prefix 194.70.36.0/24
allow to group "switches" prefix 84.246.192.0/21
allow to group "switches" prefix 80.252.112.0/20
[EMAIL PROTECTED] bgpctl sh rib community 8282:400
flags: * = Valid, > = Selected, I = via IBGP, A = Announced
origin: i = IGP, e = EGP, ? = Incomplete
flags destination gateway lpref med aspath origin
I*> 193.25.188.0/23 84.246.195.68 200 0 8276 3 i
I*> 194.116.160.0/2384.246.195.68 200 0 8276 i
*>213.170.0.0/19 80.252.125.2 200 0 9179 i
*>193.195.141.0/2480.252.125.2 200 0 9179 i
*>192.88.83.0/24 80.252.125.2 200 0 9179 i
I*213.170.0.0/19 80.252.125.2 200 0 9179 i
I*193.195.141.0/2480.252.125.2 200 0 9179 i
I*192.88.83.0/24 80.252.125.2 200 0 9179 i
a) I would expect to see "my nets" in the exports, and b) I would
expect to see the whole of 8282:400 and not just a fraction
The receiving end seems to match what is being exported
core-2-b1#sh ip bg neighbors 80.252.124.2 received-routes
BGP table version is 1823, local router ID is 194.70.36.252
Status codes: s suppressed, d damped, h history, * valid, > best, i -
internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next HopMetric LocPrf Weight Path
* i192.88.83.0 80.252.124.2 200 0 9179 i
* i193.195.141.080.252.124.2 200 0 9179 i
* i213.170.0.0/19 80.252.124.2 200 0 9179 i
Total number of prefixes 3
Re: bgpd and multihop
On 29 Jun 2007, at 11:12, Stuart Henderson wrote: I know ... whether it's just something that has now cropped up because it's the first time these several of these boxes have been rebooted in months ... The addition of nexthop qualify via bgp seems to have overcome things .. however the next hops should be learnt by ospf and are reachable (otherwise the bgp sessions wouldn't actually be up, which they are) Are the nexthops in subnets where you receive the same exact prefixes by both BGP and OSPF? I have found ospfd sometimes doesn't overwrite routes installed by bgpd. That's not new though.. Yup .. most likely ... certainly qualifying via bgp seems to have solved things for the time being
Re: bgpd and multihop
On 29 Jun 2007, at 08:47, Henning Brauer wrote: * Jon Morby <[EMAIL PROTECTED]> [2007-06-29 02:56]: I've just updated one of our routers from an end of May snapshot to a Jun 28th snapshot and have noticed that we seem to be having problems with our multihop sessions since the upgrade. errr... I'm inlcined to say "impossible", since there weren't many changes at all in bgpd since then, and nothing that remotely touches nexthop verification. check your routes, something must be different. bgpctl sh nex on both machines might give insight I know ... whether it's just something that has now cropped up because it's the first time these several of these boxes have been rebooted in months ... The addition of nexthop qualify via bgp seems to have overcome things .. however the next hops should be learnt by ospf and are reachable (otherwise the bgp sessions wouldn't actually be up, which they are) Regards, Jon Morby FidoNet Registration Services Ltd web: www.fido.net tel: +44 (0) 845 004 3050 fax: +44 (0) 845 004 3051
bgpd and multihop
I've just updated one of our routers from an end of May snapshot to a Jun 28th snapshot and have noticed that we seem to be having problems with our multihop sessions since the upgrade. [EMAIL PROTECTED] bgpctl -n s rib 80.252.127.0/24 flags: * = Valid, > = Selected, I = via IBGP, A = Announced origin: i = IGP, e = EGP, ? = Incomplete flags destination gateway lpref med aspath origin I 80.252.127.0/24 84.246.195.116 200 0 65123 i 80.252.127.0/24 84.246.195.116 200 0 65123 i [EMAIL PROTECTED] bgpctl -n s rib det 80.252.127.0/24 BGP routing table entry for 80.252.127.0/24 65123 Nexthop 84.246.195.116 (via ?) from 80.252.124.1 (80.252.124.1) Origin IGP, metric 0, localpref 200, internal Last update: 00:19:45 ago Community: 8282:200 8282:400 NO_EXPORT BGP routing table entry for 80.252.127.0/24 65123 Nexthop 84.246.195.116 (via ?) from 84.246.195.116 (84.246.195.116) Origin IGP, metric 0, localpref 200, external Last update: 00:20:10 ago Community: 8282:400 NO_EXPORT where as on our older "trusty" box [EMAIL PROTECTED] bgpctl -n s rib 80.252.127.0/24 flags: * = Valid, > = Selected, I = via IBGP, A = Announced origin: i = IGP, e = EGP, ? = Incomplete flags destination gateway lpref med aspath origin *>80.252.127.0/24 84.246.195.116 200 0 65123 i [EMAIL PROTECTED] bgpctl -n s rib det 80.252.127.0/24 BGP routing table entry for 80.252.127.0/24 65123 Nexthop 84.246.195.116 (via 80.252.119.2) from 84.246.195.116 (84.246.195.116) Origin IGP, metric 0, localpref 200, external, valid, best Last update: 5d21h14m ago Community: 8282:400 NO_EXPORT -- Jon Morby FidoNet Registration Services Ltd tel: 0845 004 3050 / fax: 0845 004 3051 web: http://www.fido.net/
Re: FYI: fixed in -current (Was: openbgp not exporting ipv6 to routing tables)
On 5 Jun 2007, at 08:42, OndEej SurC= wrote:
Henning Brauer pm9e v So 21. 04. 2007 v 15:38 +0200:
* Ond??ej Sur?? <[EMAIL PROTECTED]> [2007-04-21 14:58]:
Hi,
Jon Morby pm9e v So 21. 04. 2007 v 12:13 +0100:
Not sure if you're still trying to fix this, or if you're
sorted
but if you're still having problems
What does your filters section look like ?
It's very simple now - none. But filters just modify prefixes
accepted
and not coupling. I do receive IPv6 prefixes they are just not
coupled
into kernel.
i guess there is some bug.
since i have no v6 here it is a bit hard to reproduce and fix
Just FYI. I prepared -current for testing and found out, that IPv6
works just fine on current -current :-). However it's broken in
4.1 due
bug in setting IPv6 options which I found fix for in some list.
Ondrej
I've been having similar problems here, however updating to the
latest June snapshot (17th) hasn't fixed things for me. (although I
have now overcome the regular kernel panic I was seeing which was
apparently caused by a corrupted disklabel on wd0)
Whilst I receive the prefixes via iBGP on our internal routers, the
routes are not inserted into the fib ... however they are when
received by eBGP and are in the rib
[EMAIL PROTECTED] uname -a
OpenBSD l2-c1.access.fido.net 4.1 GENERIC#1118 amd64
[EMAIL PROTECTED] bgpctl s rib det 2001:610::/32
BGP routing table entry for 2001:610::/32
3257 1103
Nexthop 2a01:2c0::3 (via 2a01:2c0::3) from 2a01:2c0::3
(80.252.124.3)
Origin IGP, metric 14, localpref 100, internal, valid, best
Last update: 02:16:50 ago
Community: 8282:602 8282:600 3257:3370 3257:3371 3257:5031
[EMAIL PROTECTED] route -n get -inet6 2001:610::1
route: writing to routing socket: No such process
[EMAIL PROTECTED] bgpctl sh fib 2001:610::1
flags: * = valid, B = BGP, C = Connected, S = Static
N = BGP Nexthop reachable via this route
r = reject route, b = blackhole route
flags destination gateway
*B2001:610::/322a01:2c0::3
[EMAIL PROTECTED] route -n get -inet6 2a01:2c0::3
route to: 2a01:2c0::3
destination: 2a01:2c0::3
interface: vlan544
if address: fe80::230:48ff:fe88:9348%vlan544
flags:
use hopcount mtuexpire
720 0 0 0
[EMAIL PROTECTED] ping6 2a01:2c0::3
PING6(56=40+8+8 bytes) 2a01:2c0::2 --> 2a01:2c0::3
16 bytes from 2a01:2c0::3, icmp_seq=0 hlim=64 time=0.371 ms
16 bytes from 2a01:2c0::3, icmp_seq=1 hlim=64 time=0.341 ms
^C
--- 2a01:2c0::3 ping6 statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.341/0.356/0.371/0.015 ms
whilst on our border (June 9th sources)
[EMAIL PROTECTED] bgpctl s rib det 2001:610::/32
BGP routing table entry for 2001:610::/32
3257 1103
Nexthop 2001:7f8:2:1::3 (via 2001:7f8:2:1::3) from Tiscali
(213.200.87.23)
Origin IGP, metric 14, localpref 100, external, valid, best
Last update: 6d09h17m ago
Community: 8282:600 3257:3370 3257:3371 3257:5031
BGP routing table entry for 2001:610::/32
1752 1299 20965 1103
Nexthop 2001:7f8:2:1::1 (via 2001:7f8:2:1::1) from BT Exact
(213.121.24.91)
Origin IGP, metric 0, localpref 100, external, valid
Last update: 6d09h17m ago
Community: 8282:600
BGP routing table entry for 2001:610::/32
3344 30071 3549 1103
Nexthop 2001:7f8:5::6334:2 (via 2001:7f8:5::6334:2) from Kewlio
(85.116.0.23)
Origin IGP, metric 0, localpref 100, external, valid
Last update: 3d23h31m ago
Community: 8282:600 3344:63300 30071:57052
[EMAIL PROTECTED] route -n get -inet6 2001:610::1
route to: 2001:610::1
destination: 2001:610::
mask: :::
gateway: 2001:7f8:2:1::3
interface: vlan303
if address: 2001:7f8:2:1::21
flags:
use hopcount mtuexpire
0 0 0 0
and one of our downstream test boxes in AS65123
[EMAIL PROTECTED] bgpctl s rib det 2001:610::/32
BGP routing table entry for 2001:610::/32
8282 3257 1103
Nexthop 2a01:2c0:a0:1::1 (via 2a01:2c0:a0:1::1) from
2a01:2c0:a0:1::1 (80.252.124.3)
Origin IGP, metric 0, localpref 100, external, valid, best
Last update: 3d06h08m ago
Community: 65123:601 8282:600 3257:3370 3257:3371 3257:5031
[EMAIL PROTECTED] route -n get -inet6 2001:610::1
route to: 2001:610::1
destination: 2001:610::
mask: :::
gateway: 2a01:2c0:a0:1::1
interface: gif0
if address: 2a01:2c0:a0:1::2
flags:
use hopcount mtuexpire
0 0 0 0
So clients of l3 via eBGP seem ok, but clients in the same AS/iBGP
cloud don't seem to insert the routes
Does anyone else see this ... is it just something stupid I'm doing
in my filters (which are I though fairly basic) or is it a bug in bgpd?
filters on l2-c1 are basically
allow from any inet6
match to group "internalv6" set { nexthop self }
bgpd: update errors
Apologies for being quiet the last few weeks, I've been away and only just got back to the grind stone I performed a cvs sync last night and have now rebuilt our lab router and 2 of our border routers to the latest cvs snapshot. All seemed to be working well with the lab talking to the borders before the roll out .. and the borders are talking to each other fine since the roll out, however the lab router talking to our borders is now failing with v4 although v6 routes are being received. May 27 12:47:10 l3-c1 bgpd[14258]: neighbor 84.246.195.116 (PI - hostnic): received notification: error in UPDATE message, attribute length wrong 84.246.195.116 is AS65123 and on the borders we have match from any source-as 65123 set community NO_EXPORT This was working with the March/April snapshots .. I haven't made any configuration changes beyond updating to -current source and rebuilding. What do you need debug wise? [EMAIL PROTECTED] bgpctl -n s | grep 65123 84.246.195.116 65123 63 198657 0 00:12:27 Idle 2a01:2c0:a0:1::2 65123 214786 7197 0 00:19:09 1 [EMAIL PROTECTED] bgpctl s Neighbor AS MsgRcvdMsgSentOutQ Up/Down State/PrfRcvd 2a01:2c0:a0:1::1 8282736 15986 0 00:10:41 803 80.252.124.3 8282 18310 14 0 00:04:01 Active 80.252.124.2 8282 0 6 0 Never Active 80.252.124.1 8282 0 6 0 Never Active Regards, Jon Morby FidoNet Registration Services Ltd web: www.fido.net tel: +44 (0) 845 004 3050 fax: +44 (0) 845 004 3051
Re: openbgp not exporing ipv6 to routing tables
On 21 Apr 2007, at 14:38, Henning Brauer wrote: > * Ond??ej Sur?? <[EMAIL PROTECTED]> [2007-04-21 14:58]: >> Hi, >> >> Jon Morby pm9e v So 21. 04. 2007 v 12:13 +0100: >>> Not sure if you're still trying to fix this, or if you're >>> sorted >>> but if you're still having problems >>> >>> What does your filters section look like ? >> >> It's very simple now - none. But filters just modify prefixes >> accepted >> and not coupling. I do receive IPv6 prefixes they are just not >> coupled >> into kernel. > > i guess there is some bug. > since i have no v6 here it is a bit hard to reproduce and fix > I must admit I'm starting to notice some weirdness mostly anecdotal at this stage, however it seems that with "announce IPv4 none" but a "global" filter allowing export of v4 prefixes we're still announcing / saying we have v4 addresses - we're finding some peers rejecting sessions from us when we have "announce all" and "allow to any community :yyyy" I'm trying to throw enough hardware into a pool to be able to test this in more detail. You're welcome to accounts on them if necessary for testing / etc if it will help ? -- Jon Morby FidoNet Registration Services Ltd tel: 0845 004 3050 / fax: 0845 004 3051 web: http://www.fido.net/
Re: OSPF and IPv6
On 1 Mar 2007, at 07:13, Esben Norby wrote: > On Wednesday 28 February 2007 14:58:49 Jon Morby wrote: >> Unless I'm missing something OpenOSPFD doesn't currently seem to >> support IPv6 ? > > IPv6 is not supported currently, and I think it will be a while > before that > happens. > > /Esben > What would it take to get this feature bumped up the queue? I'm trying to resist going back to Quagga ... I really don't want to have to do it, but we need dynamic routing which encompasses IPv6 support :( -- Jon Morby FidoNet Registration Services Ltd tel: 0845 004 3050 / fax: 0845 004 3051 web: http://www.fido.net/
Re: bgpd crash
On 30 Apr 2007, at 10:51, Claudio Jeker wrote: On Sun, Apr 29, 2007 at 04:39:07AM +0100, Jon Morby wrote: I've updated to the latest snapshot and am seeing the following from bgpd Apr 29 03:35:18 l3-c1 bgpd[28142]: fatal in RDE: aspath_count: bula bula Apr 29 03:35:18 l3-c1 bgpd[30043]: Lost child: route decision engine exited Apr 29 03:35:18 l3-c1 bgpd[765]: fatal in SE: pipe write error: Broken pipe As far as I can tell there have been no major changes to bgpd.conf in between upgrades Any ideas? The latest snapshot has the preliminary 4-byte AS support in it. I guess you triggered a not yet known bug. Can you isolate the case when this is happening? e.g during startup or if a specific neighbor session is brought up. I reverted the 4-byte patches and we haven't seen a crash since so it does seem to be the 4-byte patch that is at issue. I had the snapshot running on 2 routers which were talking to each other as part of our ibgp mesh. The fault only appeared on one of the two routers .. this box happened to have a number of IPv6 configurations/peering sessions. I tried disabling the IPv6 configs within bgpd.conf but the crashes still occurred the problem seemed to be half way through loading routes from the 2nd box I've not been able to replicate the problem in our lab as yet .. it only appeared once the code was rolled out to our live service (which was obviously sub-optimal :) The crash generally occurred within 90 seconds or so of starting bgpd ... every time .. In the meantime I try to figure out how it is possible to hit that fatal. -- :wq Claudio
bgpd crash
I've updated to the latest snapshot and am seeing the following from bgpd Apr 29 03:35:18 l3-c1 bgpd[28142]: fatal in RDE: aspath_count: bula bula Apr 29 03:35:18 l3-c1 bgpd[30043]: Lost child: route decision engine exited Apr 29 03:35:18 l3-c1 bgpd[765]: fatal in SE: pipe write error: Broken pipe As far as I can tell there have been no major changes to bgpd.conf in between upgrades Any ideas? Regards, Jon Morby FidoNet Registration Services Ltd web: www.fido.net tel: +44 (0) 845 004 3050 fax: +44 (0) 845 004 3051
Re: openbgp not exporing ipv6 to routing tables
Not sure if you're still trying to fix this, or if you're sorted but if you're still having problems What does your filters section look like ? On 16 Apr 2007, at 16:28, OndEej SurC= wrote: > > I have configured openbgpd on openbsd 4.0 (upgraded from 3.8) and > there > seems to be problem with IPv6. I have tried google and irc, but > without > success. > > I am receiving IPv6 prefixes just fine (791 from upstream transit, 140 > from local IX), but they are not exported to kernel routing tables.
Kernel tuning on routers
A quick google hasn't been very helpful ... are there any guides to tuning OpenBSD kernel in 4.x for optimum performance on routers? We're starting to see some bizarre behaviour and memory issues on some of our busier border routers Things such as (note the minus 59% usage) [EMAIL PROTECTED] netstat -m 9637 mbufs in use: 9557 mbufs allocated to data 74 mbufs allocated to packet headers 6 mbufs allocated to socket names and addresses 9546/15752/32768 mbuf clusters in use (current/peak/max) 34148 Kbytes allocated to network (-59% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines [EMAIL PROTECTED] netstat -m 7336 mbufs in use: 7256 mbufs allocated to data 74 mbufs allocated to packet headers 6 mbufs allocated to socket names and addresses 7242/15752/32768 mbuf clusters in use (current/peak/max) 34036 Kbytes allocated to network (47% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines and also things like this appear in dmesg WARNING: mclpool limit reached; increase kern.maxclusters (which we've done) These boxes tend to have 3 or 4 full copies of the routing table as well as 150-200 peering sessions with an average of 20 prefixes on each [EMAIL PROTECTED] bgpctl s r me RDE memory statistics 217634 IPv4 network entries using 6.6M of memory 1 IPv6 network entries using 44B of memory 1951183 prefix entries using 59.5M of memory 363941 BGP path attribute entries using 26.4M of memory 118297 BGP AS-PATH attribute entries using 3.5M of memory, and holding 363941 references 12390 BGP attributes entries using 290K of memory and holding 408122 references 12389 BGP attributes using 444K of memory RIB using 96.8M of memory [EMAIL PROTECTED] bgpctl s r me RDE memory statistics 217589 IPv4 network entries using 6.6M of memory 671 IPv6 network entries using 28.8K of memory 672388 prefix entries using 20.5M of memory 128149 BGP path attribute entries using 9.3M of memory 48874 BGP AS-PATH attribute entries using 1.4M of memory, and holding 128149 references 4066 BGP attributes entries using 95.3K of memory and holding 126566 references 4065 BGP attributes using 25.0K of memory RIB using 38.0M of memory -- Jon Morby fido.net - the internet made simple!
Re: IPv6 and OpenBGPD - Protocol not available
Nope ... seems to result in a LOT of these
received notification: Cease, max-prefix exceeded
for all our v4 peers / etc
On 27 Mar 2007, at 19:25, Claudio Jeker wrote:
On Tue, Mar 27, 2007 at 07:12:50PM +0100, Jon Morby wrote:
Thanks Claudio ... you guys are super stars! :)
Seems to be working a treat
Now to work out the filters :(
/etc/bgpd.conf:796: king bula sez: AF_INET only
796:allow quick to any prefix 2a01:2c0::/32
What's the correct way to ensure your AF_INET6 prefixes are properly
exported?
Oops looks like some very old leftovers. Could you give this one
here a
whril? I think that's enough to make the filtering of IPv6 prefixes
possible but as you may guess I have no real IPv6 sessions running.
--
:wq Claudio
Index: parse.y
===
RCS file: /cvs/src/usr.sbin/bgpd/parse.y,v
retrieving revision 1.201
diff -u -p -r1.201 parse.y
--- parse.y 6 Mar 2007 16:52:48 - 1.201
+++ parse.y 27 Mar 2007 18:20:59 -
@@ -1027,13 +1027,6 @@ encspec : /* nada */{
filterrule : action quick direction filter_peer_h filter_match_h
filter_set
{
struct filter_rule r;
- struct filter_prefix_l *l;
-
- for (l = $5.prefix_l; l != NULL; l = l->next)
- if (l->p.addr.af && l->p.addr.af != AF_INET) {
- yyerror("king bula sez: AF_INET only");
- YYERROR;
- }
bzero(&r, sizeof(r));
r.action = $1;
Re: IPv6 and OpenBGPD - Protocol not available
Thanks Claudio ... you guys are super stars! :)
Seems to be working a treat
Now to work out the filters :(
/etc/bgpd.conf:796: king bula sez: AF_INET only
796:allow quick to any prefix 2a01:2c0::/32
What's the correct way to ensure your AF_INET6 prefixes are properly
exported?
On 27 Mar 2007, at 18:24, Claudio Jeker wrote:
> Try this diff. It seems to solve the problem for me.
>
> --
> :wq Claudio
>
> Index: session.c
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/session.c,v
> retrieving revision 1.271
> diff -u -p -r1.271 session.c
> --- session.c 16 Mar 2007 14:06:57 - 1.271
> +++ session.c 27 Mar 2007 17:10:07 -
> @@ -1162,7 +1162,7 @@ session_setup_socket(struct peer *p)
>
> if (p->conf.ebgp && p->conf.remote_addr.af == AF_INET6)
> /* set hoplimit to foreign router's distance */
> - if (setsockopt(p->fd, IPPROTO_IPV6, IPV6_HOPLIMIT, &ttl,
> + if (setsockopt(p->fd, IPPROTO_IPV6, IPV6_UNICAST_HOPS, &ttl,
> sizeof(ttl)) == -1) {
> log_peer_warn(&p->conf,
> "session_setup_socket setsockopt hoplimit");
IPv6 and OpenBGPD - Protocol not available
.. and probably me doing something wrong but I can't spot it
I am trying to setup a native IPv6 BGP session to BT Exact
I have the interface setup as v6 only
[EMAIL PROTECTED] cat /etc/hostname.vlan303
up vlan 303 vlandev trunk0 description UK6x
inet6 2001:7f8:2:1::21 64
[EMAIL PROTECTED] cat /etc/hostname.trunk0
trunkport bge0 trunkport bge1 up
and can ping their end of the link fine
[EMAIL PROTECTED] ping6 -c 3 2001:7f8:2:1::1
PING6(56=40+8+8 bytes) 2001:7f8:2:1::21 --> 2001:7f8:2:1::1
16 bytes from 2001:7f8:2:1::1, icmp_seq=0 hlim=64 time=0.367 ms
16 bytes from 2001:7f8:2:1::1, icmp_seq=1 hlim=64 time=0.293 ms
16 bytes from 2001:7f8:2:1::1, icmp_seq=2 hlim=64 time=0.447 ms
--- 2001:7f8:2:1::1 ping6 statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.293/0.369/0.447/0.063 ms
OpenBGPD is configured thusly (500 line bgpd.conf cut down to basic
essentials)
AS 8282
network 194.70.36.0/24
network 84.246.192.0/21
network 80.252.112.0/20
network 2a01:2c0::/32
group IPvSix {
set nexthop self
softreconfig in yes
softreconfig out yes
set community 8282:600
# announce IPv4 none
announce IPv6 unicast
neighbor 2001:7f8:2:1::1 {
multihop 3
local-address 2001:7f8:2:1::21
remote-as 1752
}
}
Sessions however won't initiate
(they've also tried with/without override-capability-neg on their end)
Mar 27 16:27:46 l3-c1 bgpd[32629]: SE reconfigured
Mar 27 16:27:55 l3-c1 bgpd[32629]: neighbor 2001:7f8:2:1::1: state
change Idle -> Active, reason: Start
Mar 27 16:27:55 l3-c1 bgpd[32629]: neighbor 2001:7f8:2:1::1:
session_setup_socket setsockopt hoplimit: Protocol not available
Mar 27 16:27:55 l3-c1 bgpd[32629]: neighbor 2001:7f8:2:1::1: state
change Active -> Idle, reason: Fatal error
Their debug output shows the following
Mar 27 15:36:51.347 BST: BGP: 2001:7F8:2:1::21 open active, local
address 2001:7F8:2:1::1
Mar 27 15:36:51.347 BST: BGPNSF: Building graceful restart capability
for 2001:7F8:2:1::21
Mar 27 15:36:51.347 BST: BGP: 2001:7F8:2:1::21 went from Active to
OpenSent
Mar 27 15:36:51.347 BST: BGP: 2001:7F8:2:1::21 sending OPEN, version
4, my as: 1752, holdtime 360 seconds
Mar 27 15:36:51.347 BST: BGP: 2001:7F8:2:1::21 send message type 1,
length (incl. header) 51
Mar 27 15:36:51.431 BST: BGP: 2001:7F8:2:1::21 remote close, state
CLOSED
Mar 27 15:36:51.431 BST: BGP: 2001:7F8:2:1::21 -reset the session
Mar 27 15:36:51.431 BST: BGPNSF state: 2001:7F8:2:1::21 went from
nsf_not_active to nsf_not_active
Mar 27 15:36:51.431 BST: BGP: 2001:7F8:2:1::21 went from OpenSent to
Idle
Mar 27 15:36:51.431 BST: BGP: 2001:7F8:2:1::21 closing
Mar 27 15:36:51.439 BST: BGP: 2001:7F8:2:1::21 went from Idle to Active
Mar 27 15:36:51.439 BST: BGP: 2001:7F8:2:1::21 open active delayed
28351ms (35000ms max, 28% jitter)
I haven't tried restarting bgpd completely as this is on a production
server ... but I'm hoping it's just a stupid config error somewhere
that can easily resolved ?
This is on -current as of a week ago
Any ideas?
--
Jon Morby
FidoNet Registration Services Ltd
tel: 0845 004 3050 / fax: 0845 004 3051
web: http://www.fido.net/
Re: OpenBGPD and private-as
On 20 Mar 2007, at 10:03, Claudio Jeker wrote: On Mon, Mar 19, 2007 at 04:25:25PM +, Jon Morby wrote: Might be a dumb question, but what's the equivalent of neighbor remove-private-as in OpenBGPD I've just noticed we're advertising prefixes 65xxx to our upstream providers when we should be stripping them from our advertisements. OpenBGPD can not strip AS numbers from AS pathes at the moment. Is it enough to remove only one particular AS or do you realy need to use the heavy artillery? Well was hoping there would be a catch all ... but removal of individual ones that we know about is fine ... until we find one we don't know about :) -- :wq Claudio
OpenBGPD and private-as
Might be a dumb question, but what's the equivalent of neighbor remove-private-as in OpenBGPD I've just noticed we're advertising prefixes 65xxx to our upstream providers when we should be stripping them from our advertisements. -- Jon Morby FidoNet Registration Services Ltd tel: 0845 004 3050 / fax: 0845 004 3051 web: http://www.fido.net/
Re: ospfctl reload problem
On 17 Mar 2007, at 16:41, Stuart Henderson wrote: > On 2007/03/17 16:13, Stuart Henderson wrote: >> On 2007/03/17 15:08, Jon Morby wrote: >>>> Checking tcpdump it seems that the password is being passed but >>>> truncated as 7 characters plus a null character instead of the full >>>> 8 character password >> >> try this .. > > ok claudio's is probably a better idea .. (works for me) > Yup looks to make more sense, and definitely works here Thanks guys! -- Jon Morby FidoNet Registration Services Ltd tel: 0845 004 3050 / fax: 0845 004 3051 web: http://www.fido.net/
Re: ospfctl reload problem
On 17 Mar 2007, at 15:42, Claudio Jeker wrote: > > Can you try this diff? > > -- > :wq Claudio Yup that did the tric Thanks! -- Jon Morby FidoNet Registration Services Ltd tel: 0845 004 3050 / fax: 0845 004 3051 web: http://www.fido.net/
Re: ospfctl reload problem
On 17 Mar 2007, at 14:48, Jon Morby wrote:
> Doing an ospfctl reload seems to result in problems with simple
> authentication enabled
>
> Mar 17 14:44:14 l2-c1 ospfd[7096]: recv_packet: authentication
> error, interface vlan544
> Mar 17 14:44:45 l2-c1 last message repeated 213 times
>
> Checking tcpdump it seems that the password is being passed but
> truncated as 7 characters plus a null character instead of the full
> 8 character password
>
> This is with -current
>
Apologies, I forgot to paste the config and results from our lab machine
15:04:59.942992 0:d:93:4e:30:8a 1:0:5e:0:0:5 0800 78: 84.246.195.116
> 224.0.0.5: OSPFv2-hello 44: backbone auth "passwor^@" E mask
255.255.255.248 int 10 pri 1 dead 40 dr 84.246.195.116 nbrs [tos
0xc0] [ttl 1] (id 51672, len 64)
Mar 17 15:02:29 stats ospfd[4412]: recv_packet: authentication error,
interface gem0
Mar 17 15:03:09 stats last message repeated 4 times
Mar 17 15:05:19 stats last message repeated 13 times
ospfd.conf
area 0.0.0.0 {
interface gem0 {
auth-type simple
auth-key password
}
}
If I pkill ospfd and run ospfd from cold everything sync's fine.
It's just when we do an ospfctl reload
>
>
>
> --
> Jon Morby
> FidoNet Registration Services Ltd
> tel: 0845 004 3050 / fax: 0845 004 3051
> web: http://www.fido.net/
ospfctl reload problem
Doing an ospfctl reload seems to result in problems with simple authentication enabled Mar 17 14:44:14 l2-c1 ospfd[7096]: recv_packet: authentication error, interface vlan544 Mar 17 14:44:45 l2-c1 last message repeated 213 times Checking tcpdump it seems that the password is being passed but truncated as 7 characters plus a null character instead of the full 8 character password This is with -current -- Jon Morby FidoNet Registration Services Ltd tel: 0845 004 3050 / fax: 0845 004 3051 web: http://www.fido.net/
Re: bgpctl show, performance and softreconfig in -current
On 12 Mar 2007, at 10:31, Claudio Jeker wrote: ... and here is the patch to fix the issue. Yup does indeed seem to have solved the problem! Thanks Claudio / guys! -- Jon Morby FidoNet Registration Services Ltd tel: 0845 004 3050 / fax: 0845 004 3051 web: http://www.fido.net/
bgpctl show, performance and softreconfig in -current
77644 BGP path attribute entries using 5.6M of memory
34162 BGP AS-PATH attribute entries using 1.0M of memory,
and holding 77644 references
3978 BGP attributes entries using 93.2K of memory
and holding 91791 references
3977 BGP attributes using 25.5K of memory
RIB using 26.3M of memory
--
Jon Morby
FidoNet Registration Services Ltd
tel: 0845 004 3050 / fax: 0845 004 3051
web: http://www.fido.net/
Re: Question about IP
On 11 Mar 2007, at 12:37, Philip Guenther wrote: > On 3/11/07, Jon Morby <[EMAIL PROTECTED]> wrote: >> On 10 Mar 2007, at 14:58, Akin Nomad wrote: >> >> > c: 2001:16c8:ffd7::b:33.255.3.2 >> >> I would say this one on the basis that (notation of) IPv6 >> addresses are colon separated and IPv4 addresses are period separated >> and this uses a mixture of colon an period > > No, that's a valid form. The authoritative reference is RFC 2373. On > OpenBSD systems, the inet_pton(3) manpage summarizes the accepted > forms. *doh* Ok ... so learn something new every day ... :) Yup .. looks like a badly worded / translated question ... oh well back to Sunday lunch :) > > Philip Guenther -- Jon Morby FidoNet Registration Services Ltd tel: 0845 004 3050 / fax: 0845 004 3051 web: http://www.fido.net/
Re: Question about IP
On 10 Mar 2007, at 14:58, Akin Nomad wrote: c: 2001:16c8:ffd7::b:33.255.3.2 I would say this one on the basis that (notation of) IPv6 addresses are colon separated and IPv4 addresses are period separated and this uses a mixture of colon an period But I could be wrong. -- Jon Morby FidoNet Registration Services Ltd tel: 0845 004 3050 / fax: 0845 004 3051 web: http://www.fido.net/
Re: OSPF and IPv6
Ok thanks for that .. guess it's time to dig out quagga again :( Cheers On 1 Mar 2007, at 07:13, Esben Norby wrote: On Wednesday 28 February 2007 14:58:49 Jon Morby wrote: Unless I'm missing something OpenOSPFD doesn't currently seem to support IPv6 ? IPv6 is not supported currently, and I think it will be a while before that happens. /Esben
OSPF and IPv6
Unless I'm missing something OpenOSPFD doesn't currently seem to support IPv6 ? Are there any recommendations as to what we should use to manage dynamic routing of IPv6 addresses within a WAN? (or am I missing something obvious?) -- Jon Morby FidoNet Registration Services Ltd tel: 0845 004 3050 / fax: 0845 004 3051 web: http://www.fido.net/
Re: DHCP server issues.
Hi Bray
What do the logs say?
Also, try running dhcpd with -d -f
-d Force dhcpd to log to stderr. This can be useful for
debugging,
and also at sites where a complete log of all dhcp
activity must
be kept, but syslogd(8) is not reliable or otherwise
cannot be
used. Normally, dhcpd will log all output using the
syslog(3)
function with the log facility set to LOG_DAEMON.
-f Run dhcpd as a foreground process, rather than allowing
it to run
as a daemon in the background. This is useful when
running dhcpd
under a debugger, or when running it out of inittab on
System V
systems.
On 26 Feb 2007, at 00:45, Bray Mailloux wrote:
I've been toying with the DHCP server options but cannot seem to
bring up the process; everytime I run ps there is no dhcpd process
to be found and no computers on my network are pulling down
addresses from the server.
My DHCPD.conf file looks as such.
-bash-3.1# nano /etc/dhcpd.conf
GNU nano 1.2.5File: /etc/dhcpd.conf
# $OpenBSD: dhcpd.conf,v 1.1 1998/08/19 04:25:45 form Exp $
#
# DHCP server options.
# See dhcpd.conf(5) and dhcpd(8) for more information.
#
# Network: 192.168.1.0/255.255.255.0
# Domain name: none
# Name servers: 68.94.156.1 and 68.94.157.1
# Default router: 192.168.1.1
# Addresses:192.168.1.20 - 192.168.1.35
#
shared-network LOCAL-NET {
option domain-name "example.com";
option domain-name-servers 68.94.156.1, 68.94.157.1;
subnet 192.168.1.0 netmask 255.255.255.0 {
option routers 192.168.1.1;
range 192.168.1.20 192.168.1.35;
}
}
And my interfaces are configured as such.
cat /etc/hostname.rl0 < External interface
inet 192.168.1.2255.255.255.0 NONE
cat /etc/hostname.rl1 < Internal Interface
192.168.1.3 255.255.255.0
nano rc.conf.local reads as such
dhcpd_flags=""
ospfd problems in -current
I'm having problems with ospfd in -current
Up until about 2 weeks ago this was working however since updating to
more recent snapshots (including last night's build) ospfd no longer
seems to recognise link on the vlan interface at boot up
[EMAIL PROTECTED] ospfctl sh in
Interface AddressState HelloTimer Linkstate Uptime
nc ac
vlan544 80.252.124.3/24DOWN stoppedno carrier
00:00:00 0 0
[EMAIL PROTECTED] pkill ospfd
[EMAIL PROTECTED] ospfd
[EMAIL PROTECTED] ospfctl sh in
Interface AddressState HelloTimer Linkstate Uptime
nc ac
vlan544 80.252.124.3/24WAIT 00:00:07 active
00:00:03 1 0
As you'll see if I kill and restart ospfd the link shows as active
and everything seems to work as it should.
The logs don't show much ...
Feb 25 03:13:55 l3-c1 ospfd[28113]: if_act_reset: error leaving group
224.0.0.5, interface vlan544
Feb 25 03:13:55 l3-c1 ospfd[28113]: ospf engine exiting
This was definitely working with the same config with January
snapshots .. but checking logs on source-changes I can't really see
anything "obvious" that would explain this.
The config we have here on this particular router is a little
complex ... I've not had chance to try this on a simpler config as yet.
bge0 and bge1 are configured as trunk0
vlan544 then uses trunk0 as its vlandev
If I revert to the earlier snapshot ospfd comes up fine on reboot
without manual intervention.
dmesg follows
OpenBSD 4.1-beta (GENERIC) #1406: Sat Feb 24 12:33:46 MST 2007
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Pentium(R) 4 CPU 3.00GHz ("GenuineIntel" 686-class)
3.01 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,
CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,CNXT-
ID,xTPR
real mem = 1063743488 (1038812K)
avail mem = 963207168 (940632K)
using 4278 buffers containing 53309440 bytes (52060K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+ BIOS, date 04/07/05, BIOS32 rev. 0 @
0xfa000, SMBIOS rev. 2.3 @ 0xf0800 (49 entries)
bios0: Supermicro P8SCT
apm0 at bios0: Power Management spec V1.2
apm0: AC on, battery charge unknown
apm0: flags 70102 dobusy 1 doidle 1
pcibios0 at bios0: rev 3.0 @ 0xf/0xcb84
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfca20/336 (19 entries)
pcibios0: PCI Exclusive IRQs: 5 9 10 12
pcibios0: PCI Interrupt Router at 000:31:0 ("Intel 82801FB LPC" rev
0x00)
pcibios0: PCI bus #5 is the last bus
bios0: ROM list: 0xc/0x9400!
acpi at mainbus0 not configured
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 "Intel E7221 MCH Host" rev 0x05
ppb0 at pci0 dev 1 function 0 "Intel E7221 PCIE" rev 0x05
pci1 at ppb0 bus 1
ppb1 at pci1 dev 0 function 0 "Intel PCIE-PCIE" rev 0x09
pci2 at ppb1 bus 2
"Intel IOxAPIC" rev 0x09 at pci1 dev 0 function 1 not configured
vga1 at pci0 dev 2 function 0 "Intel E7221 Video" rev 0x05: aperture
at 0xd030, size 0x800
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
ppb2 at pci0 dev 28 function 0 "Intel 82801FB PCIE" rev 0x03
pci3 at ppb2 bus 3
bge0 at pci3 dev 0 function 0 "Broadcom BCM5721" rev 0x11, BCM5750 B1
(0x4101): irq 12, address 00:30:48:83:39:c4
brgphy0 at bge0 phy 1: BCM5750 10/100/1000baseT PHY, rev. 0
ppb3 at pci0 dev 28 function 1 "Intel 82801FB PCIE" rev 0x03
pci4 at ppb3 bus 4
bge1 at pci4 dev 0 function 0 "Broadcom BCM5721" rev 0x11, BCM5750 B1
(0x4101): irq 10, address 00:30:48:83:39:c5
brgphy1 at bge1 phy 1: BCM5750 10/100/1000baseT PHY, rev. 0
uhci0 at pci0 dev 29 function 0 "Intel 82801FB USB" rev 0x03: irq 5
usb0 at uhci0: USB revision 1.0
uhub0 at usb0
uhub0: Intel UHCI root hub, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhci1 at pci0 dev 29 function 1 "Intel 82801FB USB" rev 0x03: irq 10
usb1 at uhci1: USB revision 1.0
uhub1 at usb1
uhub1: Intel UHCI root hub, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
uhci2 at pci0 dev 29 function 2 "Intel 82801FB USB" rev 0x03: irq 9
usb2 at uhci2: USB revision 1.0
uhub2 at usb2
uhub2: Intel UHCI root hub, rev 1.00/1.00, addr 1
uhub2: 2 ports with 2 removable, self powered
uhci3 at pci0 dev 29 function 3 "Intel 82801FB USB" rev 0x03: irq 12
usb3 at uhci3: USB revision 1.0
uhub3 at usb3
uhub3: Intel UHCI root hub, rev 1.00/1.00, addr 1
uhub3: 2 ports with 2 removable, self powered
ehci0 at pci0 dev 29 function 7 "Intel 82801FB USB" rev 0x03: irq 5
usb4 at ehci0: USB revision 2.0
uhub4 at usb4
uhub4: Intel EHCI root hub, rev 2.00/1.00, addr 1
uhub4: 8 ports with 8 removable, self powered
ppb4 at pci0 dev 30 function 0 "Intel 82801BA AGP" rev 0xd3
pci5 at ppb4 bus 5
ichpcib0 at pci0 dev 31 function 0 "Intel 82801FB LPC" rev 0x03: PM
disabled
pciide0 at pci0 dev 31 function 1 "Intel 82801FB IDE" rev 0x03: DMA,
channel 0 configured to compatibility,
Re: Port trunking/bonding
On 12 Feb 2007, at 14:31, Claudio Jeker wrote: Roundrobin may increase packet reordering which in turn reduces the tcp window size because tcp thinks it is a network congestion. In the worst case one connection may run slower over two link trunk than over a single link. You need a real multilink capable L2 portocol (like ppp) to fully use the bandwith of the additional link. Ethernet was not designed for that and so bonding/trunking of interfaces give you a sub-optimal performance improvement. -- :wq Claudio Thanks That explains a lot I guess until we can afford / source / upgrade to 10Gig capable infrastructure, we're stuck with bonding and the issues that you describe. It's certainly going to be better than the packet loss we'd see trying to squeeze 1.6Gbit of traffic down a 1Gbit connection I guess - even if we have to bond 3 GigE links together to ensure we allow for over head Cheers -- Jon Morby FidoNet Registration Services Ltd tel: 0845 004 3050 / fax: 0845 004 3051 web: http://www.fido.net/
Re: Port trunking/bonding
Actually .. maybe I'm expecting too much from this ... With 1 of the ports disabled, and roundrobin specified - transfer speeds dropped from 1.2MB/s to about 780KB/s Certainly at GigE speeds the graphs look a little more as I would expect, so it could also be an artefact of testing at 10baseT I guess -- Jon Morby FidoNet Registration Services Ltd tel: 0845 004 3050 / fax: 0845 004 3051 web: http://www.fido.net/
Re: Port trunking/bonding
On 12 Feb 2007, at 13:18, Stuart Henderson wrote: On 2007/02/12 12:44, Jon Morby wrote: My problem is that graphs of the 2 cisco ports show traffic is only going via the 1 port and not being balanced across both ports as I would have expected. loadbalance hashes the header to determine which link to use; you might want round-robin instead? check trunk(4) for descriptions. I should have said, I have also tried with roundrobin and also removing the channel-group from the switch. The only real performance increase I've seen is with the channel- group removed in which case we do see some traffic across both ports, but we still only get about 1.4MB/sec and not the 1.8MB/s-2.2MB/s I would have expected to see from scp transfers. (graphs show 8Mbit which matches what I'm seeing from scp) With the ports set to GigE we see a major speed increase, so it's not a bottle neck on the sending machines as far as I can ascertain. -- Jon Morby FidoNet Registration Services Ltd tel: 0845 004 3050 / fax: 0845 004 3051 web: http://www.fido.net/
Port trunking/bonding
Hi I'm trying to run an experiment (initially) with regards bonding/ trunking ethernet ports under OpenBSD (current) .. but I'm hitting a snag and I haven't been able to google my way out of it as yet ... I have 2 x Broadcom NICS set at 10mbit full duplex (for the purposes of the test .. in real life these will be either 2 or 4 x GigE ports) bonded together using trunk(4) (it's likely to be some time before we can afford 10 Gig infrastructure, but need more than 1Gig between certain segments of our network) My problem is that graphs of the 2 cisco ports show traffic is only going via the 1 port and not being balanced across both ports as I would have expected. What I need is what I believe is referred to as "link aggregation" .. ie traffic equal to the sum of all members of the "trunk(4)" and not just the one interface. Helpful pointers gratefully received! OpenBSD 4.0-current (GENERIC) #1: Sun Feb 11 23:29:59 GMT 2007 brgphy1 at bge1 phy 1: BCM5750 10/100/1000baseT PHY, rev. 0 bge0 at pci3 dev 0 function 0 "Broadcom BCM5721" rev 0x11, BCM5750 B1 (0x4101): irq 12, address 00:30:48:83:39:c4 brgphy0 at bge0 phy 1: BCM5750 10/100/1000baseT PHY, rev. 0 bge1 at pci4 dev 0 function 0 "Broadcom BCM5721" rev 0x11, BCM5750 B1 (0x4101): irq 10, address 00:30:48:83:39:c5 cat /etc/hostname.trunk0 up trunkproto loadbalance trunkport bge0 trunkport bge1 cat /etc/hostname.bge0 up cat /etc/hostname.bge1 up ifconfig trunk0 trunk0: flags=8843 mtu 1500 lladdr 00:30:48:83:39:c4 trunk: trunkproto loadbalance trunkport bge1 active trunkport bge0 master,active groups: trunk media: Ethernet autoselect status: active inet6 fe80::230:48ff:fe83:39c4%trunk0 prefixlen 64 scopeid 0x6 I have a cisco 3750 set with the 2 ports in their own channel interface Port-channel1 switchport trunk encapsulation dot1q switchport mode trunk ! interface GigabitEthernet1/0/1 description router-trunk switchport trunk encapsulation dot1q switchport mode trunk duplex full speed auto 10 channel-group 1 mode on spanning-tree portfast trunk ! interface GigabitEthernet1/0/2 description router-trunk switchport trunk encapsulation dot1q switchport mode trunk duplex full speed auto 10 channel-group 1 mode on spanning-tree portfast trunk sh ether 1 s Flags: D - downP - in port-channel I - stand-alone s - suspended H - Hot-standby (LACP only) R - Layer3 S - Layer2 U - in use f - failed to allocate aggregator u - unsuitable for bundling w - waiting to be aggregated d - default port Number of channel-groups in use: 2 Number of aggregators: 2 Group Port-channel ProtocolPorts --+-+--- +--- 1 Po1(SU) -Gi1/0/1(P) Gi1/0/2(P) I have a host configured on a GigE port connected directly to the 3750 and the OpenBSD box setup as a router vlan309: flags=8843 mtu 1500 lladdr 00:30:48:83:39:c4 vlan: 309 priority: 0 parent interface: trunk0 groups: vlan inet6 fe80::230:48ff:fe83:39c4%vlan309 prefixlen 64 scopeid 0x8 inet 80.252.126.1 netmask 0xff00 broadcast 80.252.126.255 -- Jon Morby FidoNet Registration Services Ltd tel: 0845 004 3050 / fax: 0845 004 3051 web: http://www.fido.net/
