Re: OpenBGPd success question
Claudio Jeker wrote: But your right we need AS path regex support... Funny you should mention that, I've just been speaking with Henning about the exact same thing - Although more for classifying routes on ingress than for pure TE alone. Cheers, Karl
OpenBGPD OPEN Error
Hi, I've just upgraded a box to the 3.9 Snapshot from 30th January and now whenever bgpd tries to open a session with a Extreme BlackDiamond it reports the following: received notification: error in OPEN message, optional parameter error This was all working fine with a 3.8 snapshot before. Anyone else had similar issue, a Google and Newsnet didn't turn up anything and I don't recall seeing anything on-list either. I'm aware that the BD is probably doing something it shouldn't be in terms of sticking to the RFCs, but non-the-less, it did work before. Thanks, Karl
Re: OpenBGPD OPEN Error
Henning Brauer wrote: * Karl Austin [EMAIL PROTECTED] [2006-02-06 11:39]: Hi, I've just upgraded a box to the 3.9 Snapshot from 30th January and now whenever bgpd tries to open a session with a Extreme BlackDiamond it reports the following: received notification: error in OPEN message, optional parameter error This was all working fine with a 3.8 snapshot before. Anyone else had similar issue, a Google and Newsnet didn't turn up anything and I don't recall seeing anything on-list either. I'm aware that the BD is probably doing something it shouldn't be in terms of sticking to the RFCs, but non-the-less, it did work before. we are announcing something to the BD it does not like. a tcpdump (increase snaplen, like, tcpdump -vvv -n -s 1500 port 179) would help, and you can play with announce IPv6/IPv6 in the config, and, as last resort, announce capabilities no. But I'd really prefer to debug this properly, maybe we need to change something in he way we announce capabilites by default. also, check logs on the other side. Just trying to get the BD to give me something remotely useful about it. Reading back what I typed, wasn't all that clear in my first message, it's OpenBGPD giving the error, not the BD. tcpdump: # tcpdump -i ti1 -vvv -n -s 1500 port 179 and host 192.168.1.5 tcpdump: listening on ti1, link-type EN10MB 11:09:46.794102 192.168.1.5.1381 192.168.1.6.179: S [tcp sum ok] 3055653480:3055653480(0) win 3600 mss 1460 [tos 0xc0] (ttl 30, id 43716, len 44) 11:09:46.794121 192.168.1.6.179 192.168.1.5.1381: S [tcp sum ok] 2689756459:2689756459(0) ack 3055653481 win 16384 mss 1460 (DF) (ttl 64, id 15313, len 44) 11:09:46.795217 192.168.1.5.1381 192.168.1.6.179: . [tcp sum ok] 1:1(0) ack 1 win 3600 [tos 0xc0] (ttl 30, id 43717, len 40) 11:09:46.795340 192.168.1.6.179 192.168.1.5.1381: F [tcp sum ok] 1:1(0) ack 1 win 17520 (DF) (ttl 64, id 18823, len 40) 11:09:46.795747 192.168.1.5.1381 192.168.1.6.179: . [tcp sum ok] 1:1(0) ack 2 win 3600 [tos 0xc0] (ttl 30, id 43718, len 40) 11:09:47.087864 192.168.1.5.1381 192.168.1.6.179: P [tcp sum ok] 1:30(29) ack 2 win 3600: BGP (OPEN: Version 4, AS #65535, Holdtime 180, ID 192.168.1.1, Option length 0) [tos 0xc0] (ttl 30, id 43720, len 69) 11:09:47.087877 192.168.1.6.179 192.168.1.5.1381: R [tcp sum ok] 2689756461:2689756461(0) win 0 (DF) (ttl 64, id 22030, len 40) 11:09:47.088335 192.168.1.5.1381 192.168.1.6.179: F [tcp sum ok] 30:30(0) ack 2 win 3600 [tos 0xc0] (ttl 30, id 43721, len 40) 11:09:47.088342 192.168.1.6.179 192.168.1.5.1381: R [tcp sum ok] 2689756461:2689756461(0) win 0 (DF) (ttl 64, id 25445, len 40) Tried with: announce IPv6 none and: announce capabilities no but neither make any difference. Thanks, Karl
Re: OpenBGPD OPEN Error
Karl Austin wrote: Tried with: announce IPv6 none and: announce capabilities no but neither make any difference. Thanks, Karl Just tried again, shut the session down at both sides for a few minutes and waited, then brought them back up, and it seems that announce capabilities no did the trick in establishing the session again - But like yourself, I'd rather get to the bottom of it. Thanks, Karl
Re: OpenBGPD OPEN Error
Henning Brauer wrote: wait, I think I see a bug and announce capabilities no doesn't work :) please try this diff. Index: session.c === RCS file: /cvs/src/usr.sbin/bgpd/session.c,v retrieving revision 1.243 diff -u -p -r1.243 session.c --- session.c 24 Jan 2006 10:08:16 - 1.243 +++ session.c 6 Feb 2006 12:01:08 - @@ -1200,7 +1200,7 @@ session_open(struct peer *p) if (p-capa.ann.refresh) op_len += 2 + 0;/* 1 code + 1 len, no data */ - if (op_len 0) + if (p-conf.announce_capa op_len 0) optparamlen = sizeof(op_type) + sizeof(op_len) + op_len; len = MSGSIZE_OPEN_MIN + optparamlen; however, after receiving a Optional Parameter Error notofcation, OpenBGPD should quickly retry without any capabilites announced (and thus optional parameters) on its own. did you wait for the second trial? Just tried from CVS with the patch applied and still the same :( I do have what I believe is the open packet as sent to the BD, unfortunately it's not top drawer at logging these things, logged in hex: 02/06/2006 15:06.21 DBUG:KERN 0x08815b0fd0: 00 * 02/06/2006 15:06.21 DBUG:KERN 0x08815b0fc0: 00 21 01 04 78 d5 00 5a c1 97 7c 06 04 02 02 02 *!**x**Z**|* 02/06/2006 15:06.21 DBUG:KERN 0x08815b0fb0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Thanks, Karl
Re: BGP (was Re: Two Isp Fault Tollerance Help)
Claudio Jeker wrote: On Fri, Oct 07, 2005 at 04:35:51PM +0200, Olivier Mehani wrote: On Fri, 7 Oct 2005 16:09:28 +0200 Lio Goehrs [EMAIL PROTECTED] wrote: The address space can be given by one of the provider. But then, I understand that the route to these addresses will go through the address-providing ISP. Correct ? No. You need provider independent address space for such setups plus a AS number. At least for IPv4 it goes this way. In IPv6 land it is no longer possible to get provider independent address space and so multihoming is broken and this makes IPv6 unusable in the real life. You don't have to have PI space at all, many providers will let you punch a hole in their PA allocation if you do not have your own PA allocation (Not technically a great practice, but it adds the same extra NLRI to the routing table as PI space would). However I am guessing in this situation that BGP is going to be overkill and the providers wouldn't configure it unless we're talking about leased lines/E1, T1 etc. etc. Thanks, Karl Austin
Re: Compatibility question for the New Sun X4100 server with 4FastEthernet as possible BGP routers, or stick with HP DL-145 G2?
Daniel Ouellet wrote: Looking at the less then complete technical information on the Sun server, I don't see the details of the chip set use in that server, network card, etc. So, I can't search to see if OpenBSD may work on it or not. Google haven't return query with the X4100 and OpenBSD yet on this as well. To new most likely. I know this doesn't answer your compatability question, but as far as I am aware (So Sun told me yesterday) the new Opteron servers won't actually be shipping till end of October/Early November. Thanks, Karl Austin
Re: bgpctl
tony sarendal wrote: I've started to test bgpd to see if I can use if for a future project. Are there any plans to make bgpctl show communities, originator-id and cluster-list ? Any plans of adding route-refresh to bgpctl ? Something like bgpctl nei peer clear (in|out) ? Although I miss a few features it is really nice to use, it is starting to give me the same feeling as pf. I got a 10 router bgp-only test network up and running in just a few hours, most of the time was spent installing the boxes. /Tony S You've read my mind, that was going to be my next question if my issue about having multiple communities per route was addressed (I tried -current and it doesn't work). Soft reset, and more route information from bgpctl are sorely needed. Thanks, Karl
Re: bgpctl
tony sarendal wrote: On 06/09/05, Karl Austin [EMAIL PROTECTED] wrote: You've read my mind, that was going to be my next question if my issue about having multiple communities per route was addressed (I tried -current and it doesn't work). Soft reset, and more route information from bgpctl are sorely needed. I also ran into the problem with multiple communities but I haven't had time to look closer at it. Have you seen any changes in bgpd since you tried -current ? I was going to give it a go tonight if I manage to stay awake. /Tony Not been any changes in the last 3 weeks as far as I can see from CVS Web. At least I've found someone else having the same problem now, was begining to think I was loosing the plot. Thanks, Karl
OpenBGPD - Setting Multiple Communities
Hi,
I'm just testing out OpenBGPD here, and am trying to set multiple
communities for a BGP peer, however it appears that no matter what I
try, only the very last community specified gets set, overwriting those
previous. I've scoured Google and the lists and can't seem to see this
addressed anywhere. Is it just that the setting of multiple communities
is not supported, or am I missing something obvious?
I've tried:
neighbor 192.168.1.1 {
set community 65400:100
set community 65400:200
set community 65400:300
}
and also tried match statements e.g.
match from 192.168.1.1 set { community 65400:100, community 65400:200,
community 65400:300 }
along with separate match lines for each community.
Thanks,
Karl Austin
Re: OpenBGPD - Setting Multiple Communities
Claudio Jeker wrote:
On Fri, Sep 02, 2005 at 01:53:03PM +0100, Karl Austin wrote:
Hi,
I'm just testing out OpenBGPD here, and am trying to set multiple
communities for a BGP peer, however it appears that no matter what I
try, only the very last community specified gets set, overwriting those
previous. I've scoured Google and the lists and can't seem to see this
addressed anywhere. Is it just that the setting of multiple communities
is not supported, or am I missing something obvious?
I've tried:
neighbor 192.168.1.1 {
set community 65400:100
set community 65400:200
set community 65400:300
}
and also tried match statements e.g.
match from 192.168.1.1 set { community 65400:100, community 65400:200,
community 65400:300 }
along with separate match lines for each community.
Which version of OpenBGPD are you useing?
This problem should be fixed in -current.
I've just updated to the latest Snapshot available from FTP and it still
seems to only set a single community (the last one specified). I've
checked on two different peers running two different BGPDs and both of
them only show the final community in the list as being sent.
Thanks,
Karl Austin
