X-Istence

Recommendation for aliases on an interface is to use 255.255.255.255 as the netmask on FreeBSD.

For example to add extra interfaces to lo0 on FreeBSD you may use:

  ipv4_addrs_lo0="127.0.0.2-5/8"

in rc.conf

And now those addresses are automatically assigned to lo0, the netmask will be set to 255.255.255.255 automatically for all but the first in that range (.2). Since 127.0.0.1 is unconditionally assigned to lo0, you could also use:

  ipv4_addrs_lo0="127.0.0.2-5/32"

This is what I do on FreeBSD.

Unfortunately accidents happen, I have a feeling that some insurance company somewhere is going to end up paying for the damages...

Adding any type of compile time switch adds extra maintenance burden and adds one more thing to test, one more thing that needs to be checked for regressions. One more thing may not seem like much, but increasing the maintenance burden on a project that had nothing to do with the reason something was broken in the first place seems incredibly one-sided and wrong.

If you have per-user sub-domains, just get a wildcard cert, pay for it, and cover all your users all at once. Why do you need want to go through LE for that purpose?

Sure wish I had a couple million lying around to go buy a helicopter! :P

In this case you are using BGP only for it's ability to send routes from one place to another.

This isn't complicated, it's config management. You can ignore 99% of what BGP can do in this use case.

Wait what? How else should we be exchanging routes? Should we shove them into a distributed key value store and then having each of the nodes pull out the routes and installing them?

> As an admin that's just another mess of processes and communication to worry about.

Yet we fully expect admins to understand and build HA redundant clusters for databases, or how to manage and update all the machines under their control, and a variety of other tasks.

There is nothing inherently different about running a BGP speaking daemon. It's all config.

I don't have a heavy networking background at all. I'm a software engineer that's currently working as a system architect, but even I can understand something as simple as a route distribution system.

Why is BGP complex? What makes BPG complex? The only complex thing about BGP is the fact that you can have it talk to the rest of the world if necessary and deal with traffic balancing and all that fun stuff, dealing with getting routes from multiple locations and a variety of other tasks and topics that are not "BGP" so much as network engineering.

That's not required here.

If you give me 10 machines on a L2 domain, I can set up a private network on top of those 10 machines, and advertise what IP is where to each of them by sharing a routing table... I can of course manually add routes saying a /24 is located on Host 1, and another /24 is on Host 2, or...

What better way to share a routing table than with a route distribution protocol of some sort?

So plop BIRD with BGP on all of the machines, peer em, and have them pull routes out of the Linux routing table and insert routes as necessary.

Now if I spin up a container on Host 1, I advertise a /32 for that IP, and Host 2-10 can all know to forward packets for that /32 to Host 1. If I move that container or IP to Host 2, BGP announces it to all the other hosts and traffic starts flowing there instead.

There is no requirement that Calico (or BIRD rather) peer with any existing BGP infrastructure... you can of course do that, but there is no requirement.

Stop making BGP sound like it's some bad evil thing that's difficult to understand.

Calico is installing routes in the Linux kernel. Those routes are pulled out and distributed using BIRD. BIRD can do OSPF instead if you'd like.

All Calico cares about is that routes are distributed across various systems, they don't necessarily care how you do it (configure BIRD however you'd like).

BGP is surprisingly simple and easy to set up with BIRD. Setting up a route reflector with local hosts on the same L2 all peering with each other and suddenly you can route whatever IP's you want by announcing them to your peers.

Why do people think BGP is complicated?

> (Sorry, I don't use docker so I can't actually make a constructive comment telling you what the canonical/right way of doing it is, but I can assure you, this is not it.)

And you are categorically wrong. This is a very good way to do it.

Calico uses BIRD, and Calico just programs routes into the Linux kernel, BIRD then picks those up.

BIRD supports OSPF, so if you'd like to import/export routes using OSPF you can.

As the current maintainer of WebOb it pains me to see Google App Engine shipping 1.1.1 by default, and 1.2.3 as one that the user can select.

The Pylons Project is a larger organisation that maintains a lot of open source software, including webtest, Pylons is ALSO a web framework, but that is also unrelated to webtest.

In the authors case, webtest should have been installed separately, rather than using it from within the cherrypy source code, which seems to vendor webtest.

They actually provide it. They have some documents on how: https://www.ovh.co.uk/anti-ddos/

There is a new trend, especially with virtualisation, whereby you push Layer 3 all the way down to the host.

In my case, at $WORK, we use a product called Calico with OpenStack. Calico turns our standard Linux machine into a router with BGP to advertise the IP's of the VM's running on it to the rest of the network.

We use BFD on the edge to detect failures other than link down (for example, if for some odd reason the SFP is still inserted and link is still considered up, yet the ToR is deadlocked and no longer routing traffic).

Pushing layer 3 down further means we no longer have large VLAN's spanning multiple switches and having a huge broadcast domain, it provides us with more flexibility in where workloads live, and traffic can be sent to the end nodes using ECMP and other types of load balancing.

Our network guys love it, they already know how to traffic engineer using BGP, this makes it even simpler.

DNS result "compression" is crap though...

I once heard from a traffic engineer that certain speed bumps are made to be gone over at 20+ Mph faster than suggested so that ambulances and emergency personnel can travel over them with little to no trouble.

I've noticed this myself in certain areas, the speed bumps taken at higher speeds cause less issues, but it still of course increases wear and tear on motor vehicles, in most cases unnecessarily so.

There's I-10 that cuts through Phoenix east-west, I-70 that is north-south, and then they have built three highway loops that circle the city. The 101 is for the north/west part of the city, the 202 is for the south/east part of the city, and then the 303 is for the north/west part (way out there...).

https://www.google.com/maps/place/Phoenix,+AZ/@33.5083959,-1...

It was pretty nice when I lived there, because getting places using the highway was fast, and then the grid pattern for the rest of it made it incredibly easy to navigate.

Tap and hold the message you sent over iMessage. Click send as sms.

Remember remember

the fifth of November

the gun powder treason and plot.

I know of no reason

the gunpowder treason

should ever be forgot!

Very recently being when?

I don't remember anytime where I've used a Java Applet on any single banking site.

You are replying to the CEO of Gitlab... :P

Gitlab has the ability to do that.

http://doc.gitlab.com/ce/workflow/merge_when_build_succeeds....

Yes.

Interesting, here is an older article that shows the same is true for Subaru's: http://moojohn.com/subaru/extract.pdf

Was hit head on in my Subaru Impreza while turning left. I was going 15 Mph, the guy that hit me is estimated to have been driving at around 55 - 65 Mph, a Nissan Titan pickup truck, which already had about 2000 lbs on my car, on top of the stuff in the truck bed. I was shot back 40 ft from where the impact happened, here are the pictures of the aftermath:

http://imgur.com/a/nIMOP

The entire passenger compartment is completely intact. All doors still opened, front-end was completely destroyed, everything worked as it needed to. The engine dropped, the transmission shot underneath the car, drivetrain collapsed, front crumpled, dash shifted up and out of the way, airbags deployed, seatbelt caught me. But everything from the A frame to the C frame was completely intact. Doors opened without issues, and if you looked from the back you'd almost say it was a minor accident.

I walked away from the accident, much to the surprise of first responders that arrived on the scene and saw the carnage of my cars front-end.

I went back and bought another one, just a model year newer as soon as insurance sorted everything out. Modern cars are cages designed to protect their occupants, and I am very happy that is the case!

Sometimes they do, if chain laws are in effect and the weather is getting really bad...

Also, if you don't have them and you get into an accident, it's expensive fine time :P

Tests have shown that the Autosock actually works better than chains in almost all situations. Here in Colorado you'll see big rigs carrying goods with auto sock's on rather than chains.

https://www.youtube.com/watch?v=WtBzXVbE3Rc

This shows the various tests that they did, and the auto sock comes out of the tests very well.

1. Same thing, ban the entire /64, or /48. Now it's similar to banning an IPv4 address.

2. Hacked device on the other side of the firewall has been an issue even with NAT. NAT + firewall is not some magic unicorn, if someone gains access to a device behind your NAT + firewall they are still on your local network. No change there.

3. Most users will use Wifi at home, thus have an IP address that can be tracked. My exit IP for my T-Mobile phone is almost always the same too when I am in the same location...

No, that is not how NAT64/DNS64 works...