I am not an expert on this, I just wanted to document a problem I had and a solution I found today, in a concise way. Comments correcting me or suggesting better ways are very welcome.
I have a network running OSPF internally, and advertising routes to the upstream ISP over BGP at two separate edge routers (multi-homed, single ISP). We discovered last night that internally bringing down any of the subnets we advertise results in the dropping of those routes from the tables of the edge routers (as expected). This drops the advertisements. What we did NOT expect was that flap damping from upstream of us then null-routes that subnet for up to a few hours.
So, how do we retain our adaptive internal routing (OSPF) while avoiding route flap? I was a bit stumped about this, but I found a more complex article that describes a multi-homed BGP setup. A key part of that setup was a little trick to avoid this problem. Nameley, set up a static, black hole route for the subnet on the edge router, with maximum distance. This way, even if the OSPF route disappears, the router still “knows” a route to the subnet and won’t drop the advertisement.
For example, if you want to advertise the subnet 220.127.116.11/24, you should add a static route like
/ip route add dst-address=18.104.22.168/24 type=blackhole distance=254 comment="prevent flapping of the route over BGP"
I’ve tested it and it seems to work as expected. The route is not active as long as the OSPF route is in the routing table. If it disappears, the black hole route becomes active.
It seems like every time guns are in the news someone misuses terminology, usually in the name of making something sound scary. I’m posting these here so I can refer back to this later.
- Semi-automatic = loads another round after a round is fired, requires a trigger pull for each shot. Basically any modern gun that’s not break-action, lever action, pump action, or revolver.
- Fully automatic = can fire multiple shots with one trigger pull
- Assault rifle = fully automatic rifle
- Assault weapon = anti-gun term made up to make semi-automatic weapons sound more scary
- Magazine = holds bullets
- Clip = holds your pen in your shirt pocket (mostly)
If you, like me, live in Gnome Terminal all day and have been frustrated with the recent color scheme changes (particularly, that that the active tab is nearly impossible to distinguish), you will probably find this handy. Worked great for me.
Highlighting the active tab in Gnome Terminal.
If you want to be able to pass VLANs along to your linux guests from a linux KVM host, there’s a trick.
The most common way is to create special bridges for each vlan you want to pass, but that’s a big pain. Such an approach is detailed here.
After a surprisingly large amount of searching, I came across this article, which details the first way, and then another — the way to trunk vlans to KVM guests. Here’s the key quote that made me understand what I needed to do:
The difference is that when subinterfaces are defined on eth0, as noted previously Linux will strip the vlan tag, but when defined on the bridge, the vlan tags are kept.
Basically, if you put the vlans on the ethernet device, the tags will get stripped and not pass through the bridge to the guests. If you put the vlans on the bridge, the tags get passed through to the guest. So, a brief example.
You make a bridge br0 with eth0 on the kvm host. You then set up your guest to use br0 as its network interface (eth0 in the guest). You’d expect at this point that vlan tags would be passed. They won’t. However, if you want to pass vlan 2 through to the guest, then you add vlan 2 to br0 on the host (host: br0.2). Then, you add vlan 2 to eth0 on the guest (eth0.2). Boom. The vlan tag 2 is being passed through to eth0.2 on the guest.
Thanks so much to David Vassallo for figuring this out and posting it on his blog. Here’s hoping I can amplify the signal to help future seekers of this information.
I bought some cheap Acer c710 chromebooks, used, off of eBay for WISP use. One as a loaner for customers complaining of speed problems, when we suspect their systems may be the culprit.
The other I’m testing as a field laptop for use in the WISP. We keep the management interfaces of our equipment on a separate VLAN (802.1q), and frequently need to access that VLAN in the field. I couldn’t find any information online about whether this is supported in Linux.
Once I got the chromebooks, I put one in developer mode, and found that the 8021q kernel module is already available. That’s good, because it means I can keep running ChromeOS and get VLAN tagging, I don’t have to install a full-blown Linux system.
Using crouton, it’s possible to add a vlan to the ethernet port, and configure it. Once that’s done, the crouton chroot can actually be exited and unmounted and the vlan will continue to function correctly until the device is rebooted.
Now I just need to figure out how to automate the process of setting up the normal vlan(s) I use.