Intelligent Linux Gateway (multihoming)

Intelligent Linux Gateway

On previous posts we already talked about hardware and processes that should be in place to ensure Internet access stability. This last post addresses reliability of access networks. Our goal is to describe a low cost, yet highly reliable internet access made of two DSL lines from different carriers. The setup that will be described can easily be adapted to Cable lines, which are even easier to work with.

The goal

Traffic segregation across two different lines with auto failover (aka protection switch) for both of them. Reliable internet access.

Beneficts

No interference between critical server/vpn traffic and the anything goes workstation traffic.
Access uptime numbers that could otherwise only be achieved with more expensive lines.

What we need

A Linux based router with 3 network interfaces (and iproute2, htb, iptables)
2 DSL lines with static IPs from different carriers
2 DSL modems (bridged mode)


Strategy

We will use one interface for each DSL modem and run PPPoE on it, so the Linux machine gets the public IPs. This way the port forwarding and routing configurations are independent of the DSL device.

One of these interfaces will be used for server related traffic (selected by LAN server IPs) while another one is used for Internet access from the internal workstations. The remaining one is used for connecting the two other interfaces to the internal networks.

For the router we use a Soekris Engineering net4501 board with Pyramid Linux, but any pc/server with a regular Linux distribution will do.

Implementation

Once developed, the implementation is quite simple and based upon a few scripts:

igw-iptables.sh

Configures traffic filtering and routing rules for the normal situation. Runs on startup.

igw-HTB_shaper_basic.sh

Configures QoS on the interfaces. Runs each time a PPPoE session is (re)started

igw-mon.sh

Monitors both connections and triggers the failover actions when necessary.

There is also an extra script, igw-common.sh that contains the common variables and functions. On this script the existing servers, interface names and IPs are defined.

The trickiest parts of the setup are the creation of two independent routing tables on igw-iptables.sh and the monitoring of the connection state plus the corresponding failover switch.

Routing is controlled by a small number of rules which revolve around the default routing table plus two specific routing tables created for the purpose of multihoming.

Each of the two specific routing tables is assigned to the IP of one interface, so that packets generated from that IP (eg, belonging to connections generated from the outside to that interface) are routed trough the corresponding ISP gateway.

ip rule add from $EXTIP table $EXTTABLE
ip route add 192.168.1.0/24 dev $INTIF src $EXTIP table $EXTTABLE
ip route add $EXTGW dev $EXTIF src $EXTIP table $EXTTABLE
ip route add default via $EXTGW table $EXTTABLE

The packets originated from internal server IPs are routed according to the specific table for servers.

for i in $SERVERS; do
ip rule add from $i table $SRVTABLE
done

Locally generated connections (usually none in the case of a pure gateway) are routed according to the default routing table, where a default gateway is set (can be from either of the interfaces).

ip route add default scope global nexthop via $EXTGW

A word about protection switch

Switching from the working situation to a protection situation takes some time in this setup for several reasons. First of all, the connection is checked at IP level by pinging other machines on the Internet. One could think of monitoring the first-hop ISP router but it may happen, that it answers the ping requests while not forwarding traffic (yes, it happens). On the other hand, pinging a single Internet host is not reliable as it may be down. Furthermore pinging a group of hosts has to be done carefully as if it's done during a PPPoE session restart (which happens regularly) it may trigger a false switch. Thus there are some retries and delays involved in the monitoring process which make it slower to react. If you're looking for the carrier grade less-than-50ms switch please look somewhere else :-) as it's not possible with DSL/IP .

It should also be noted that when the server line is down (see srv_switch2protection), the corresponding DNS entries should be pointed to the other line (ideally one should have only one A record plus some CNAMES) so that it accepts connections from the outside.

Final words

This is a setup that is working on the field with excellent results. It can be tweaked as desired by editing the scripts. If all you need is traffic separation this setup also works perfectly with two lines from the same carrier. However they're likely to fail simultaneously, since they share the same physical and logical paths.

If you have any questions, just leave a comment.

ping prt.sc

Estranhos tempos estes.

Começou o BRM do DIS29500. A Microsoft "abraça" convictamente o Open Source. O Paquistao bloqueia o Youtube para bem do Mundo.

Com tudo a correr tão bem, não tardará que Santana e Sócrates façam as pazes, que chegue a paz ao médio Oriente, a democracia a Cuba... e até Rui Seabra dará uma nova oportunidade a Marcos Santos.

E, é claro, cá estará o Print Screen para contar tudo em directo.

Neste primero post ligado ao grande ecran, quero agradecer as boas vindas dadas na mailing list e prometer (já que todos os novos ciclos se iniciam com promessas) algumas coisas no que respeita às contribuições deste blog.

Entre as promessas mais importantes, conta-se por exemplo não falar de gadgets da Apple nem de Futebol, salvo talvez para demonstrar como se arremessam gadgets da Apple em jogos de Futebol.

Outra promessa essencial é não fazer posts de uma linha só, excepto se se tratar de uma linha de mais de 800 caracteres sem line breaks e que não comece por http.

Uma promessa final, porventura a mais importante, é não dizer mal de Portugal. Se mal houvesse a dizer seria dos Portugueses pois Portugal, segundo sei, está bom e recomenda-se.

Assim sendo, estão reunidas as condições para avançarem os octectos open source. Convido-vos a ler o post inaugural e a dar o vosso feedback sempre que quiserem.

As letras miudinhas

No meio da tão aclamada nova estratégia de abertura da Microsoft para expandir a interoperabilidade parece importante salientar algumas das letras miudinhas:

Microsoft is providing a covenant not to sue open source developers for development or non-commercial distribution of implementations of these protocols. These developers will be able to use the documentation for free to develop products. Companies that engage in commercial distribution of these protocol implementations will be able to obtain a patent license from Microsoft, as will enterprises that obtain these implementations from a distributor that does not have such a patent license.

Ou seja, onde até agora sempre houve uma mistura saudável entre developers individuais e instituições no âmbito de desenvolvimento open source, pretende a Microsoft introduzir uma abordagem fracturante.

Vejamos: o developer individual poderá consultar a documentação técnica sem problemas e com isso melhorar a compatibilidade de um dado projecto com sistemas ou formatos da Microsoft. Oooppsss.... e quando alguém comercializar serviços sobre esse projecto? Aí há que negociar uma licença.

Pretende assim a Microsoft introduzir dependências nos outrora independentes projectos. Iremos ser ingénuos a este ponto?

Referências:

Press Release da ESOP
Divide and Conquer

SAM thing in the way (Sysadmin de microondas - II)

Não foi por acaso que já aqui falámos antes dos Sysadmin de Microndas (SAM). Essa espécie que não parece estar em vias de extinção (embora se espere que não esteja também em expansão) é passível de ser encontrada nas melhores "lojas da especialidade" em qualquer dos lados do balcão. Alguns dos exemplares mais típicos conseguem soletrar os Ghz do último processador lançado ontem à tarde em Taywan, muito embora não façam ideia do que seja DNS, LDAP, HTTP,... e acham que uma firewall é um programa que se instala no PC para proteger o utilizador de outros programas que se instalaram no PC sem ele saber.

Não é por acaso que ao superavit de administradores Windows que temos em Portugal, corresponde um deficit de administradores Unix/Linux/BSD hardline. Também não é por acaso que os dois mundos quase não se tocam. Um administrador Windows é em muitos, muitos casos (não sempre) um SAM++ (que tal um SAM# ??!). Ou seja, existe uma correlação entre abundância de SAMs e a quota de mercado Microsoft.

Mas porquê é que é assim?

A resposta está nas curvas de aprendizagem. O sistemas Microsoft são de facto fáceis de utilizar o que é bom para os utilizadores. Ora quando um utilizador habituado a facilidades se quer converter num sysadmin habituado a facilidades, o único caminho a seguir é este. E de certo modo funciona.... é muito mais rápido aprender a "fazer coisas" neste tipo de plataforma. Num país com tradição em técnicas de lucro fácil e rápido enriquecimento esta é uma receita campeã.

Vejamos a seguinte figura:


Quando apita o microondas, quem é que está mais avançado na aprendizagem?

Claramente é o administrador Windows, porque o aprendiz de Jedi Linux, foi obrigado a seguir pelo caminho das pedras e ainda se encontra perdido a marrar entre tails, greps, awks e seds. Mas a médio/longo prazo o GUI fechado dos sitemas Windows torna-se um factor limitante que impede um natural aprofundar de conhecimentos e o administrador Linux entra num ritmo rápido de aprendizagem que as bases que tanto lhe custaram a adquir lhe conferem. Os nutrientes de absorção lenta, como capacidade de scripting, agilidade a consultar logs, rapidez de consulta de documentação e muitos outros começam pois a pesar vantajosamente.

Em resumo, "fast, good and cheap: pick two!"

Na aprendizagem de administração de sistemas Linux, ficamos com o good and cheap: o fast está fora de questão. Mas tem mesmo que ser assim, porque a matéria é complexa e como toda a gente sabe: a excelência dá trabalho.

Redes de acesso - III

Hardware that works

Na sequência dos artigos anteriores, em que foi debatida a importância da fiabilidade do hardware, fica aqui a nossa recomendação de hardware para serviços com uptime "ilimitado".

Modem ADSL Huawei Smartax MT882 - pacote Clix (25 EUR)
(usado em bridged mode)



Gateway Soekris Engineering net4501 (~300 EUR)
(usado com Pyramid Linux + scripts)

A combinação destes dois componentes de hardware permite implementar um acesso ADSL extremamente estável a custos bastante reduzidos. A gateway net4501 funciona com um flash card, ficando o sistema operativo read-only após terminada a configuração.

Apagão

A interrupção/degradação de serviço originada por cortes em 3 cabos submarinos tem dado bastante que falar (CNN,BBC), desde notícias ocasionais nos media mainstream a curiosas teorias de conspiração. Segundo várias fontes os três cabos afectados por este incidente foram:

FLAG Europe-Asia
FLAG Falcon
SEA-ME-WE 4

tendo sido parte do tráfego redireccionado via SEA-ME-WE 3 entre outros. Na origem do problema, estiveram supostas tentativas de ancoragem de navios, inicialmente perto do Egipto (FLAG Europe-Asia e SEA-ME-WE4) e posteriormente ao largo do Dubai (FLAG Falcon), causadas pelo mau tempo.

Este tipo de situação vem lembrar-nos o quão importante é a redundância nos acessos internacionais, dada a dependência das economias desenvolvidas nas comunicações fixas. De facto, com a tecnologia actual, em que uma única fibra pode chegar a transportar débitos da ordem de 1.6Tbs (ex: 160x10Gbps), um simples corte numa secção critica de cabo multi-fibra poderia na ausência de redundância eficaz levar à paralização de economias. A redundância torna-se assim uma necessidade não só técnica, mas também política, como garantia do não isolamento de um país no caso de um acidente/incidente de tipo.

Já o mesmo não acontece nos países menos desenvolvidos. Conta quem habitualmente viaja para África que as condições de acesso degradado originadas por este triplo incidente em certos países do Mediterrâneo e Médio Oriente, são o estado "normal" das comunicações de alguns dos PALOP. Serviços esses que estão disponíveis a custos que qualquer Europeu acharia impensáveis. Note-se que as telecomunicações em África são essencialmente alimentadas por acessos via satélite e pelo cabo SAT-3, sobre o qual há muito paira uma acesa controvérsia.

Referências:

Submarine Communications Cable (Wikipedia)
Mapa global de cabos submarinos (Alcatel)
Effects of Fibre Outage through Mediterranean
Shuttleworth urges telecoms reform
WDM

XML hell

Although it's somewhat tempting to just tell the world in bold letters what's been going on with the CT173 Technical Comitee in the last months we feel our energy is better employed on working along with the few participants who, with different views and opinions, have technical contributions to come up with.

As a wrap up of the last meeting brainstorming we put together this informal presentation which summarizes our views as of pre-BRM period. There's still a lot to be done concerning the analysis since, according to Alex Brown, countries should have an opinion on all dispositions of comments.