Re: BGP - IP Blackhole
On 14 avril 2014 17:57:53 CEST, Tristan PILAT tristan.pi...@gmail.com wrote: match from any community 64514:888 set nexthop blackhole Hi, Make sure you dont accept from any but eg from group customers, make sure the address *does* belong to your customers space (to avoid a customer installing a blackhole route on a route you advertise). Make sure you do strip 64514:888 from other peers. ... And what about the client side ? Which command should he enter if he wishes to blackhole ip 1.2.3.4 eg Is it something like that ? bgpctl network add 1.2.3.4/32 community 64514:888 Exactly.
Re: Keeping a carp backup connected to the internet
Ted Bullock tbull...@northernartifex.com a écrit : CARP(ish) Question: I have a /30 transit network from my ISP, where there obviously isn't room for both routers in the carp setup to have a dedicated IP address in addition to the IP assigned to the carp interface. If it matters, I've assigned both routers private addresses in my network and can talk to them just fine on the local network. Anyway, I've noticed that the clock on the backup router is getting slowly out of sync. I figure it cannot initiate network sessions to the public ntp pool since it doesn't have an IP and a valid route to the internet while it's acting as the backup. I'd prefer to not run yet another service locally if at all possible though. I'm wondering what other folks do in this situation. Having your isp allocate a ipv6 /64 would be an option.
Re: OpenBGP Issues. :-(
Alex Mathiasen a...@mira.dk a écrit :
Dear recipients,
I have been using OpenBGP for a while with OpenBSD - And I am very
satisfied
with the performance and amazed by the ease of configuration.
My BGPD is configured against a Danish ISP called TDC - And we were
previously
configured to receive a full routing table.
However a few months ago I ran into an issue where my BGPD stopped
working
properly.
It appeared the BGPD kept receiving the routing tables, and then start
all
over.
Looking into the log files, it appeared BGPD received a certain route
in the
routing table, and then grumbled about the prefix, apparently for some
reason
the result was BGPD kept reloading when it reached this route. The
result was
of course my network was down.
As TDC (My ISP) couldn't resolve which route that caused this issue
(They told
me: That's what happened when you use third party software, so no
help
there...), we agreed that my connection would be set to Default
candidate,
instead of receiving a full routing table.
So now I have configured a static route to forward all my traffic to
this
route. However this is not the result I wanted, as I am about to have
one more
connection, so I have 2 connections outbound.
But the automatic failover switch / load balancing won't work, as long
as I
have my static route.
This is why I want to go back to receiving a full routing table.
Is there any way of configuring BGPD to ignore a specific route in case
of
corrupted prefix, so this won't happened again?
I hope that some of you have an answer for this...
Here you can see my bgpd.conf:
AS
router-id 000.000.000.000
network 000.000.000.00/00
neighbor 000.000.000.000 {
remote-as
descr TDC
local-address 000.000.000.000
passive
holdtime180
holdtime min3
tcp md5sig password 00
}
log updates
Hi,
Please have a look in archives for a similar thread i did initiate.
Re: CARP compatibility between 5.1 and 5.2
R0me0 *** knight@gmail.com a écrit : Hello misc, I've a OpenBSD 5.1 in production and I will put another OpenBSD 5.2 and then configure CARP. will I have some compatibility issue ? Thanks in advanced Hi I have such à setup running surtout issue. Cheers Laurent
Re: No route to host
Loïc BLOT loic.b...@frostsapphirestudios.com a écrit : Hello to OpenBSD users, i have a little problem, i think it's linked with PF, but i have no proofs. System is OpenBSD 5.1 but OpenBSD 5.2 get the same things (with different card, 5.1 uses bnx and 5.2 use em) I have a router with squid proxy, named and isc-dhcpd. The problem is, sometimes i get no route to host for some transmissions (often on the proxy), but randomly. Our connexion is perfectly stable (Renater 1Gbit fiber connection), and the routes are static and right. When squid says no route to host and i refresh the page, it works. I think it's a packet filter problem. Nmap has sometimes the same problem and says no route to host when i try to scan. Example: Starting Nmap 5.51 ( http://nmap.org ) at 2012-11-26 23:56 CET sendto in send_ip_packet_sd: sendto(4, packet, 44, 0, aaa.bbb.ccc.20, 16) = No route to host Offending packet: TCP xxx.yyy.zzz.1:42282 aaa.bbb.ccc.20:5200 S ttl=37 id=32702 iplen=44 seq=2453102157 win=2048 mss 1460 Sleeping 15 seconds then retrying This scan was realized in two differents networks, but in this capture, this is the same networks Starting Nmap 5.51 ( http://nmap.org ) at 2012-11-26 23:58 CET sendto in send_ip_packet_sd: sendto(4, packet, 44, 0, xxx.yyy.zzz.50, 16) = No route to host Offending packet: TCP xxx.yyy.zzz.1:49053 xxx.yyy.zzz.50:161 S ttl=52 id=62248 iplen=44 seq=3073961720 win=1024 mss 1460 Sleeping 15 seconds then retrying if don't have the problem with pf disabled. All my outgoing packets are allowed and somes are nated. Where do you think the problem comes ? Thanks for Advance. Lo��c Blot, UNIX systems engineer. Hello Loïc What does your ruleset look like ? Do.you have à.log of rejected packets (tcpdump on pflog 0)?
Re: OpenBGPd / Juniper 'bug' / BGP session flapping
Claudio Jeker cje...@diehard.n-r-g.com a écrit :
I would prefer something like this. Since then we ensure that we do not
forward crap (as in we regard the RFC and send nothing with reserved
bits
set). AFAIK there is nothing out there that started to use the reserved
bits so I'm curious how that happend again.
Only compile tested for now.
--
:wq Claudio
Index: rde.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde.c,v
retrieving revision 1.316
diff -u -p -r1.316 rde.c
--- rde.c 27 May 2012 18:52:07 - 1.316
+++ rde.c 6 Aug 2012 20:57:27 -
@@ -1382,7 +1382,7 @@ rde_update_withdraw(struct rde_peer *pee
} while (0)
#define CHECK_FLAGS(s, t, m) \
- (((s) ~(ATTR_EXTLEN | (m))) == (t))
+ (((s) ~(ATTR_DEFMASK | (m))) == (t))
int
rde_attr_parse(u_char *p, u_int16_t len, struct rde_peer *peer,
Index: rde.h
===
RCS file: /cvs/src/usr.sbin/bgpd/rde.h,v
retrieving revision 1.142
diff -u -p -r1.142 rde.h
--- rde.h 21 Sep 2011 08:59:01 - 1.142
+++ rde.h 6 Aug 2012 21:09:02 -
@@ -118,6 +118,9 @@ enum attrtypes {
#define ATTR_PARTIAL 0x20
#define ATTR_TRANSITIVE 0x40
#define ATTR_OPTIONAL 0x80
+#define ATTR_RESERVED 0x0f
+/* by default mask the reserved bits and the ext len bit */
+#define ATTR_DEFMASK (ATTR_RESERVED | ATTR_EXTLEN)
/* default attribute flags for well known attributes */
#define ATTR_WELL_KNOWN ATTR_TRANSITIVE
Index: rde_attr.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde_attr.c,v
retrieving revision 1.90
diff -u -p -r1.90 rde_attr.c
--- rde_attr.c 12 Apr 2012 17:27:20 - 1.90
+++ rde_attr.c 6 Aug 2012 21:14:39 -
@@ -37,12 +37,12 @@ attr_write(void *p, u_int16_t p_len, u_i
u_char *b = p;
u_int16_ttmp, tot_len = 2; /* attribute header (without len) */
+ flags = ~ATTR_DEFMASK;
if (data_len 255) {
tot_len += 2 + data_len;
flags |= ATTR_EXTLEN;
} else {
tot_len += 1 + data_len;
- flags = ~ATTR_EXTLEN;
}
if (tot_len p_len)
@@ -69,12 +69,12 @@ attr_writebuf(struct ibuf *buf, u_int8_t
{
u_char hdr[4];
+ flags = ~ATTR_DEFMASK;
if (data_len 255) {
flags |= ATTR_EXTLEN;
hdr[2] = (data_len 8) 0xff;
hdr[3] = data_len 0xff;
} else {
- flags = ~ATTR_EXTLEN;
hdr[2] = data_len 0xff;
}
@@ -322,6 +322,7 @@ attr_alloc(u_int8_t flags, u_int8_t type
fatal(attr_optadd);
rdemem.attr_cnt++;
+ flags = ~ATTR_DEFMASK; /* normalize mask */
a-flags = flags;
a-hash = hash32_buf(flags, sizeof(flags), HASHINIT);
a-type = type;
@@ -351,6 +352,7 @@ attr_lookup(u_int8_t flags, u_int8_t typ
struct attr *a;
u_int32_thash;
+ flags = ~ATTR_DEFMASK; /* normalize mask */
hash = hash32_buf(flags, sizeof(flags), HASHINIT);
hash = hash32_buf(type, sizeof(type), hash);
hash = hash32_buf(len, sizeof(len), hash);
Hi,
Thanks Claudio.
Gonna try the patch u did provide.
Since i needed a quick fix i did apply the patch I provided which allowed my
bgp sessions to come back up.
Cheers
Laurent
