Re: BGP in a containers

[Doug Clements]

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?

[Doug Clements]

On Thu, Mar 29, 2018 at 9:07 AM, Chip Marshall  wrote:

> 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

[Doug Clements]

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. Guilmette 
wrote:

>
>
> 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

[Doug Clements]

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?

[Doug Clements]

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