Re: BGP in a containers
These days I think the idea is to use unnumbered or dynamic neighbors so most of the configuration complexity goes away: https://docs.cumulusnetworks.com/display/DOCS/Border+Gateway+Protocol+-+BGP#BorderGatewayProtocol-BGP-ConfiguringBGPUnnumberedInterfaces In this case, your container would peer directly with the switch. --Doug On Mon, Jun 18, 2018 at 2:13 PM, Jeff Walter wrote: > Years back I ran ExaBGP inside a Docker container (when it wasn't > "production ready") to anycast a contained service both within a datacenter > and across them. To make routing work correctly I had to also run another > BGP daemon on the Docker host machine; I can't remember if I used bird for > this, but it seems like what I'd use since I didn't need programmatic > control of prefixes. > > Would I do it that way today? Not a chance. How would I do it? That would > really depend on two things: what I'm trying to accomplish with BGP and > what the service is. If you just want portability of a service (not > redundancy/balancing via anycast) is BGP really the best option? I'd make a > strong case for OSPF due to it needing far less config. The same need for a > routing instance on the Docker host would apply, but you wouldn't need to > manage configuration for neighbors as containers come up and go down (since > the IP will likely change). Sure, you could just add neighbor config for > every IP Docker might use, however-- ouch. > > Jeff Walter > > On Mon, Jun 18, 2018 at 8:45 AM, Hugo Slabbert wrote: > > > > > On Sat 2018-Jun-16 00:51:15 -0500, Jimmy Hess wrote: > > > > > >> Running the BGP application in a container on a shared storage system > >> managed by > >> a host cluster would also make it easier to start the service up on a > >> different host when > >> the first host fails or requires maintenance. > >> > >> On the other hand, running directly on a host, suggests that > >> individual hosts need > >> to be backed up again, and some sort of manual restore of local > >> files from the lost host > >> will be required to copy the non-containerized application to a new > host. > >> > > > > Even if the BGP speaker is running right on the host, the shared storage > > or backups thing doesn't click for me. What about your BGP speaker will > > need persistent storage? At least in our environment, everything unique > > about the BGP speaker is config injected at startup or can be derived at > > startup. This might be based on differences in how we're using them (BGP > > daemon per container host in our case, rather than "I need X number of > BGP > > speakers; schedule them somewhere"), I guess. > > > > > > -- > > Hugo Slabbert | email, xmpp/jabber: h...@slabnet.com > > pgp key: B178313E | also on Signal > > >
Re: Yet another Quadruple DNS?
On Thu, Mar 29, 2018 at 9:07 AM, Chip Marshallwrote: > I think the real question is "when are we going to get some memorable > IPv6 public recursive DNS servers?" > > 2001:4860:4860:: or 2620:fe::fe just aren't quite as catchy as > 8.8.8.8 or 9.9.9.9. >From https://1.1.1.1/: For IPv6: *2001:2001::* and/or *2001:2001:2001::* Those are pretty catchy. --Doug
Re: Another day, another illicit SQUAT - WebNX (AS18450) 103.11.67.0/24
How does one get ARIN to register resources to come up with this result? https://whois.arin.net/rest/nets;q=103.11.67.105 The /16 is APNIC but there are 2 subnets that appear to be allocated from ARIN. Having just typed 'whois 103.11.67.105' I completely missed the fact that the supernet was APNIC until I checked the web interface. --Doug On Fri, Oct 28, 2016 at 5:40 PM, Ronald F. Guilmettewrote: > > > I just got a spam from 103.11.67.105. The containing /24 appears to > be unallocated APNIC space. > > RIPE tools seem to say that AS18450 has been routing this block since > around May 23rd. > > I see this kind of stuff almost every day now, it seems. And you know, > there are days when I really do start to wonder "Has the Internet gone > mad?" > > I'm going to call these turkeys right now and just ask them, point > blank, what the bleep they think they're doing, routing unallocated > APNIC space. But if history is any guide, this is probably going to > turn out to be another one of these "absentee landlord" kinds of ASes, > where all they have is an answering machine. > > I have to either laugh or cry when I see people posting here about the > non-functionality of abuse@ email addresses, and then see other people > saying "Well, this is why all ASes also have phone numbers." > > I wish I had a dollar for every AS I had ever tried to contact where > -neither- the abuse@ address -nor- the phone number got me to any > actual human being. > > > Regards, > rfg >
Re: Android (lack of) support for DHCPv6
On Tue, Jun 9, 2015 at 4:27 PM, Joel Maslak jmas...@antelope.net wrote: Agreed - apparently the solution is to implement SLAAC + DNS advertisements *AND* DHCPv6. Because you need SLAAC + DNS advertisements for Android, and you need DHCPv6 for Windows. Am I the only one that thinks this situation is stupid? If you think this is stupid, look in to the situation for modern WiFi and Android. https://code.google.com/p/android/issues/detail?id=17972 https://code.google.com/p/android/issues/detail?id=59502 https://code.google.com/p/android/issues/detail?id=62076 Summary: - No 802.11k (though 802.11r in barely new devices) - No DFS Channel support in Nexus-branded units, due to Google's resistance to certification. - Most WPA2-Enterprise schemes are sullied with warnings about traffic being monitored as a response to private CAs being installed. Windows support for enterprise features is downright stellar in comparison. --Doug
Re: Do you obfuscate email headers when reporting spam issues to clients?
On Wed, Nov 6, 2013 at 4:45 PM, William Herrin b...@herrin.us wrote: Incidentally, I'd suggest that an ounce of prevention is worth a pound of cure. Simply block outbound tcp port 25 for new hosting customers on a tell me if you want it open basis. Or to thwart those clever spammers, block inbound SYN/ACK packets with a source port of 25. This catches the ones who send SYNs out other providers with your network's source addresses which bypasses most simple ACLs. --Doug