Espelhamento de Discos em Servidores Debian GNU/Linux

Olá Pessoal,

Uma prática bastante comum em servidores é a combinação de múltiplos discos físicos em arranjos lógicos denominados RAID (Redundant Array of Independent Discs), principalmente para fins de disponibilidade dos dados aramazenados em mais de um disco e também para fins de desempenho, uma vez que dados armazenados em múltiplos discos implicam em maior velocidade de leitura. 

Há diversas modalidades de RAID, sendo a mais simples delas o RAID-1 que faz o espelhamento de discos, ou seja, mantém em um segundo disco físico uma cópia exata do primeiro disco físico. Em caso de falha de um dos discos, o conteúdo continua disponível através do outro disco e o administrador pode providenciar a troca do disco defeituoso para que haja sincronização total do conteúdo no novo disco.

O RAID normalmente é implementado através de hardware, sendo gerenciado por uma controladora de discos que pode ser configurada através da BIOS (ou UEFI) da máquina antes mesmo do início de instalação do sistema operacional. Essa é a opção mais recomendada porque apresenta melhor desempenho, no entanto só está disponível em hardware particularmente desenvolvido para servidores. Como o Linux se trata de um sistema operacional aberto e gratuito, ele acaba sendo a opção natural em ambientes menores que não têm recursos para aquisição de hardware adequado para seus servidores. Nesses casos, frequentemente são utilizados computadores tradicionais que não possuem hardware apropriado com uma controladora que suporte a implementação de RAID na BIOS/UEFI.

Apesar dessa limitação de equipamento, a boa notícia é que também existe a opção de configurar o RAID por software através dos sistemas operacionais modernos, ainda que o desempenho seja pior que a solução profissional implementada por hardware. Especificamente no caso do Debian GNU/Linux, a configuração de RAID pode ser facilmente implementada durante o próprio processo de instalação do servidor, desde que a máquina tenha pelo menos dois discos físicos.

A configuração de RAID-1 na instalação do Debian consiste basicamente em criar partições idênticas nos dois discos físicos e em marcá-las com o rótulo "physical volume for RAID", ao invés de escolher um sistema de arquivos (figura 1). Depois disso é possível acessar a opção "Configure Software RAID" na própria ferramenta de particionamento do Debian e selecionar as duplas partições que serão agrupadas em RAID-1. Ao terminar de criar os agrupamentos, será possível observar o(s) novo(s) disco(s) lógico(s) do RAID na tabela de partições, onde o administrador deverá fazer a indicação do sistema de arquivos e dos pontos de montagem (figura 2).

Figura 1. Indicação de RAID em 2 Discos Físicos (Antes)

Figura 2. Particionamento de Disco Lógico RAID-1 (Depois)

A implementação do RAID-1 na instalação do Debian GNU/Linux é bastante simples, mas como lidar com o sistema operacional em caso de falha de um dos discos? Como fazer a inserção do novo disco no arranjo lógico e sincronizar os dados em ambos os discos? O objetivo desse artigo é listar as ações necessárias para recompor o RAID em caso de falha de um disco. 

Consideremos um servidor que possui dois HDs (/dev/sda e /dev/sdb) arranjados em RAID-1, cada um deles contendo 3 partições com capacidade de armazenamento apenas simbólica conforme apresentado nas figuras acima. Abaixo trago novamente o esquemático das partições:

/dev/sda1 > +/- 0.6 GB (SWAP)

/dev/sda2 > +/- 7.0 GB (/)

/dev/sda3 > +/- 1.0 GB (/home)

/dev/sdb1 > +/- 0.6 GB (SWAP)

/dev/sdb2 > +/- 7.0 GB (/)

/dev/sdb3 > +/- 1.0 GB (/home)

O RAID-1 de ambos os HDs foi configurado durante o processo de instalação do servidor Linux Debian, através da ferramenta de partição do próprio instalador (na opção Configure Software RAID), dando origem aos seguintes arranjos lógicos do tipo multi-disk (/dev/mdX):

/dev/md0 = /dev/sda1 + /dev/sdb1 (SWAP)

/dev/md1 = /dev/sda2 + /dev/sdb2 (/)

/dev/md2 = /dev/sda3 + /dev/sdb3 (/home)

Enquanto os discos estão operando normalmente, o arranjo lógico dos discos físicos em RAID-1 será responsável por realizar o espelhamento de todo o conteúdo armazenado no primeiro disco também no segundo disco, garantindo que sempre exista uma cópia de segurança dos dados. Caso haja pane em qualquer um dos discos, será necessário repor fisicamente o HD defeituoso e inserí-lo manualmente no arranjo lógico do RAID-1 para que todo o conteúdo do disco em operação possa ser sincronizado novamente no novo HD. 

Por exemplo, em caso de pane no segundo HD (/dev/sdb) será necessário:

1) Reparticionar o novo HD (/dev/sdb) com o mesmo esquema do disco em operação (/dev/sda)

root@Linux:/# sfdisk -d /dev/sda | sfdisk /dev/sdb

Feito isso, é sempre prudente verificar se o novo HD possui as mesmas partições do original:

root@Linux:/# fdisk -l /dev/sda

root@Linux:/# fdisk -l /dev/sdb

2) Adicionar as partições do novo HD (/dev/sdX#) ao RAID (/dev/mdX):

root@Linux:/# mdadm --manage /dev/md0 --add /dev/sdb1 

root@Linux:/# mdadm --manage /dev/md1 --add /dev/sdb2

root@Linux:/# mdadm --manage /dev/md2 --add /dev/sdb3

Feito isso, é possível verificar que o RAID será ressincronizado (espelhamento dos discos), de forma que o novo HD seja preenchido com uma cópia exata do conteúdo armazenado no HD original:

root@Linux:/# cat /proc/mdstat

Personalities : [raid1]
md2  :  active raid1 sda3[0] sdb3[1]
        965056 blocks super 1.2 [2/2] [UU]

md1  :  active raid1 sda2[0] sdb2[1]
        6832128 blocks super 1.2 [2/2] [UU]

md0  :  active (auto-read-only) raid 1 sda1[0] sdb1[1]
        584128 blocks super 1.2 [2/2] [UU]

A saída exibe o status de cada arranjo lógico do tipo multi-disk, sendo que o conteúdo dos colchetes destacados em amarelo exibem o status individual de cada um dos discos físicos. Por exemplo, a saída [UU] indica que ambos os HDs estão em operação, enquanto que a saída [U_] indicaria que o segundo disco físico não está em operação. 

Façam seus testes...

Samuel. 

Configuração de Ether-Channel e Trunk em Roteadores Cisco

Olá Pessoal,

Assim como a configuração de agregação de interfaces físicas é uma prática comum em links tronco (trunk) de switches para fins de disponibilidade e balanceamento de carga, essa mesma configuração é igualmente importante em roteadores que fazem roteamento inter-VLAN. Para exemplificar a configuração de uma agregação de links em roteadores Cisco, utilizarei o cenário apresentado na figura abaixo em que é necessário configurar roteamento inter-VLAN entre duas sub-redes compostas por máquinas de duas VLANs diferentes, de maneira similar ao exemplo que trago no Lab06 (intitulado Configuração de Switches e VLANs) do livro Laboratórios de Tecnologias Cisco.

A diferença é que no laboratório do livro o roteador está conectado ao switch através de uma única interface física, enquanto que nesse exemplo será configurada uma agregação lógica em duas interfaces físicas do roteadores. Essa prática não só é recomendada para fins de disponibilidade em caso de falha de um dos links, mas também para obter melhor desempenho porque múltiplas VLANs estão atreladas a um único trunk entre o switch e o roteador naquilo que chamamos de router on a stick. 

Nas linhas abaixo trago as configurações necessárias no roteador para que o roteamento inter-VLAN funcione no cenário proposto, com destaques em amarelo para aqueles comandos que remetem à configuração da agregação propriamente dita. 

Router# configure terminal

Router(config)# interface port-channel 1

Router(config-if)# exit

Router(config)# interface range g0/0 - 1

Router(config-if-range)# channel-group 1

Router(config-if-range)# no shut

Router(config-if(range)# exit
Router(config)# interface po1.10
Router(config-subif)# encapsulation dot1q 10
Router(config-subif)# ip address 192.168.10.254 255.255.255.0
Router(config-subif)# exit
Router(config)# interface po1.20
Router(config-subif)# encapsulation dot1q 20
Router(config-subif)# ip address 192.168.20.254 255.255.255.0
Router(config-sub-if)# exit 

Router(config)# 

Para completar esse laboratório, abaixo trago as configurações do switch:

Switch# configure terminal

Switch(config)# vlan 10
Switch(config-vlan)# name VERDE
Switch(config-vlan)# exit
Switch(config)# vlan 20
Switch(config-vlan)# name VERMELHO
Switch(config-vlan)# exit
Switch(config)# interface range f0/1 - 3
Switch(config-if-range)# switchport access vlan 10
Switch(config-if-range)# exit
Switch(config)# interface range f0/4 - 6
Switch(config-if-range)# switchport access vlan 20
Switch(config-if-range)# exit
Switch(config)# interface range g0/1 - 2
Switch(config-if-range)# switchport mode trunk
Switch(config-if-range)# channel-group 1 mode on
Switch(config-if-range)# exit
Switch(config)# 

Façam seus testes...

Samuel. 

Servidores DHCP Redundantes em Dispositivos Cisco

Olá Pessoal.

Uma prática útil para prover redundância no serviço de configuração automática de endereços IP é a inserção de um servidor DHCP adicional na rede que possa garantir a disponibilidade do serviço mesmo em caso de queda do servidor principal, além de dividir a carga de trabalho.

Basicamente essa tarefa pode ser implementada de duas maneiras: (a) através da divisão manual dos escopos configurados nos dois servidores DHCP, de maneira que os endereços providos por um servidor não conflitem com os endereços providos pelo outro; (b) através do protocolo DHCP Failover que viabiliza a coordenação das ações de ambos os servidores, feature suportada pelo ISC-DHCP no Linux Debian e também a partir do Windows Server 2012.

O método manual é suportado em qualquer caixa ou Sistema Operacional por ser o mais simples e não envolver nenhum protocolo específico, no entanto não há uma coordenação das atividades dos dois servidores, de maneira que as tabelas de leases dos dois servidores são totalmente independentes, o que não permite gerenciamento centralizado dos leases ou manutenção das reservas em caso de queda de um dos servidores. Apesar dessas limitações, ainda assim trata-se de uma opção muito comum e funcional para assegurar a disponibilidade do serviço de configuração automática de IPs.

Pois bem, neste breve artigo trago um exemplo bastante simples de configuração de dois roteadores Cisco (poderiam ser switches). Na figura abaixo existem dois roteadores que fazem parte de um grupo HSRP e que respondem pelo IP Virtual 192.168.0.10 (gateway).  Na figura abaixo o leitor pode observar a configuração de ambos os roteadores como servidor DHCP.

Em cada roteador foi definido um escopo denominado ESCOPO para distribuição de endreços na rede 192.168.0.0/24. No roteador DHCP-SRV1 excluímos a faixa inicial dos primeiros dez endereços para fins de atribuição estática e toda a segunda metade dos endereços da rede (de 192.168.0.129 até 192.168.0.254), ou seja, ele irá distribuir endereços que variam de 192.168.0.11 até 192.168.0.128. No roteador DHCP-SRV2 fizemos o processo inverso, ou seja, excluímos toda a primeira metade dos endereços da rede (de 192.168.0.1 até 192.168.0.128). Ao fazer isso, eliminamos qualquer possibilidade de conflito na distribuição de endereços a partir dos dois servidores DHCP presentes na rede.

Obs.: Aqueles interessados na tecnologia HSRP podem recorrer ao Laboratório 26 da segunda edição do livro Laboratórios de Tecnologias Cisco em Infraestrutura de Redes, que traz um exemplo de configuração de Alta Disponibilidade em Cluster de Roteadores.

Façam seus testes...

Samuel.

Tecnologia StackPower em Switches Catalyst 3750-X

Olá Pessoal.

Os Switches Cisco Catalyst 3750-X e Catalyst 3560-X (os novos modelos de ambas as famílias) permitem que duas fontes de força sejam acopladas no equipamento, o que provê redundância em caso de falha e que a carga consumida seja distribuída entre elas. Cabe ressaltar que a característica de balanceamento de carga com apenas duas fontes não é possível naqueles modelos de 48 portas que têm suporte a PoE+ (802.3at) por causa da demanda de 30 Watts por porta (total de 1440W).

Fonte: Cisco Systems (www.cisco.com)

Especificamente na família Catalyst 3750-X existe um recurso bem interessante denominado StackPower, viabilizando que as fontes de força de até 4 switches sejam compartilhadas entre os equipamentos de um empilhamento. Assim o sistema empilhado com StackPower pode conter até 8 fontes, sendo 2 instaladas no chassis de cada switch, além da possibilidade de inserção de fontes externas ao sistema empilhado. 

Para formar o sistema StackPower os switches são empilhados através de cabos próprios para esse fim (stack cables), permitindo o gerenciamento de um sistema lógico único composto pelo total das capacidades de carga das fontes individuais. Os switches são empilhados de 2 em 2, normalmente formando uma topologia física de anel (vide figuras abaixo).

Fonte: Cisco Systems (www.cisco.com)

Fonte: Cisco Systems (www.cisco.com)

Um diferencial é que o sistema tem inteligência para fazer o balanceamento de carga entre todas as fontes pensando não somente em maior disponibilidade, mas também na otimização do consumo de energia. Como assim maior otimização de energia? Acontece que as fontes de força apresentam maior eficiência energética quando trabalham entre 30% a 90% da sua capacidade máxima. Dessa forma, ao invés de sobrecarregar uma ou algumas fontes, é mais eficiente distribuir a carga entre todas elas a manter os níveis de carga nessas faixas, ação que reflete em economia no consumo de energia elétrica e que certamente será apreciada pela política ambiental da empresa (TI Verde). 

Outra vantagem é que em caso de falha de qualquer fonte de força do sistema, a substituição da peça pode ser realizada sem que haja interrupção na operação dos switches porque a carga total demandada pelo sistema é redistribuída entre as demais fontes operacionais. Naturalmente que é necessário que haja a carga necessária nas demais fontes para a devida manutenção do sistema empilhado. O sistema é inteligente, não faz mágica! ;-)

A carga total do sistema como um todo pode ser facilmente gerenciada através da linha de comando, especificamente com o comando "show power inline" que exibe o total de energia disponível e o total de energia consumida. Ainda através da linha de comando o sistema PowerStack pode ser setado para operar de duas maneiras, a saber:

• Modo Compartilhado (Power-Sharing Mode) - Em modo compartilhado o total equivalente à soma das capacidades individuais de cada fonte fica disponível para ser compartilhado pelo sistema, através da visão única de uma fonte lógica de força. Nesse modo nenhuma reserva de energia é feita para mitigar eventuais falhas do sistema, de maneira que a falha de uma fonte pode ocasionar na interrupção do fornecimento de energia para alguns equipamentos, caso a carga total esteja esgotada.

• Modo Redundante (Redundant Mode) - Nesse modo a carga energética da fonte com maior capacidade é subtraída do total do sistema, o que implica em menor carga disponível para alimentação dos equipamentos. No entanto, essa carga subtraída fica reservada especificamente para uso em caso de falha, o que elimina o risco de pane na alimentação dos dispositivos.

Um comando útil para gerenciamento do sistema é: "show stack-power". Esse comando exibe a topologia de switches empilhados, permitindo que o status dos seus membros seja visualizado através da referência aos seus respectivos endereços físicos (MAC). Por exemplo, o modo de operação de um empilhamento StackPower pode ser configurado através das seguintes linhas de comando:

Switch(config)# stack-power stack NOME

Switch(config-stackpower)# mode {redundant | power-sharing}

Switch(config-stackpower)# exit

Switch(config)# show stack-power

Outro recurso útil para gerenciamento é definir a prioridade dos switches ou equipamentos ligados em portas PoE. Através do comando "power priority {switch|high|low}" é possível explicitar quais switches têm maior importância sobre outros (parâmetro switch). Além disso, especificamente para os modelos com suporte a PoE, as portas podem ser classificadas com prioridade high ou low (o padrão é low). É obrigatório que os valores de prioridade do parâmetro switch sejam menores que os do parâmetro high que, por sua vez, têm que ser menores que os do parâmetro low. 

Através do comando "power inline port priority {high|low}" no sub-modo de configuração de interface é possível definir individualmente quais portas são menos importantes e, portanto, os dispositivos que serão desligados em caso de falta de energia no "banco" do sistema. O valor da prioridade pode variar de 1 a 27, sendo que números menores têm maior prioridade. 

Para entender melhor como funciona a prioridade trago um pequeno exemplo de configuração em que temos um empilhamento denominado NOME com 4 switches com os seguintes nomes e prioridades:

Switch-01: Prioridade = 1

Switch-02: Prioridade = 2

Switch-03: Prioridade = 3

Switch-04: Prioridade = 4

Queremos definir que o Switch-02 tem menor prioridade em relação aos demais e, dessa forma, deve ser desligado em caso de falta de energia no "banco" disponível no sistema, para tanto estaremos aumentando sua prioridade para o valor 5, ou seja, o menos importante dos switches. Também vamos setar o valor padrão da prioridade high para 15 e da prioridade low para 25 (apenas nesse switch).

Switch(config)# stack-power switch 2

Switch(config-stackpower)# stack NOME

Switch(config-stackpower)# power-priority switch 5

Switch(config-stackpower)# power-priority high 15

Switch(config-stackpower)# power-priority low 25

Switch(config-stackpower)# end

Samuel.

VSS no Agrupamento Lógico de Switches de Agregação

Olá Pessoal.

No desenho/projeto de redes é muito comum a interligação por pares de equipamentos redundantes para fins de disponibilidade, principalmente nas camadas mais importantes (núcleo e distribuição) que fazem a agregação das camadas mais baixas que são responsáveis pela interligação dos equipamentos terminais do usuário (camada de acesso), prática ilustrada na figura abaixo.

Apesar de essa ser uma "boa prática" de projeto extremamente importante de ser levada em consideração, ela traz consigo maior complexididade ao desenho e operação da rede, afinal são dois equipamentos redudantes e mais cabos para interligar as camadas, conforme pode ser observado no lado esquerdo (a) da figura abaixo.

O VSS (Virtual Switching System) é uma tecnologia desenvolvida especificamente para equipamentos das camadas de agregação (núcleo e distribuição) que permite combinar pares de switches físicos redundantes, criando a abstração de uma única entidade lógica do ponto de vista de gestão e operação, conforme pode ser observado no lado direito (b) da figura abaixo.

A consequência da abstração lógica do VSS é que há uma simplificação relevante na quantidade de switches físicos e também em suas ligações através de cabos. Em topologias com interligação layer-3 entre o par de switches há simplificação nas vizinhanças de roteamento e em topologias com interligação layer-2 entre os switches há garantia de inibição de loops (loop-free). As ligações entre o par VSS são feitas através de links especiais denominados Virtual Switch Link (VSL) que operam em 10Gbps ou 40Gbps, sendo comum a agregação de dois links de 10Gbps (total de 20Gbps).

O interessante dessa tecnologia é que os switches de acesso passam a enxergar o par de switches de agregação como uma única entidade lógica, independente da interligação física dos cabos. Dessa forma o switche de acesso é interligado fisicamente a ambos os switches de agregação, mas é configurado através de uma porta lógica agregada (port-channel). Do ponto de vista do par de switches de agregação, é utilizado o recurso MEC (Multichassis Ether-Channel) para associar portas físicas em diferentes switches a um único canal lógico (link agregado) e cabe à tecnologia VSS fazer o geranciamento do balanceamento de carga e da disponibilidade entre essas ligações físicas.

Ao criar um "par" VSS os switches físicos negociam seus papéis no agrupamento lógico, de forma que um assume o status de master e outro o de standby. A partir daí, do ponto de vista de gerenciamento de operação deixam de existir os dois switches físicos e passa a existir apenas uma única entidade lógica, de forma que o switch master controla o "par" VSS. Embora as funções de encaminhamento (plano de dados) continuem independentes em cada switch, o tráfego de controle que chega no switch standby é repassado para o switch master - o responsável pelo plano de controle.

Aqueles que tiverem interesse em obter mais detalhes técnicos da solução VSS podem recorrer ao Guia Oficial de Configuração da Cisco (clique no link e você será redirecionado). Esse link traz exemplos de como configurar o par de switches físicos par ativar o VSS.

Abraço.

Samuel.

Rotas Flutuantes no Ambiente Corporativo

Olá Pessoal.

Hoje recebi um e-mail de um aluno com um problema comumente encontrado em empresas e achei por bem que seria interessante compartilhar a solução com todos, já que essa é uma dúvida recorrente! O e-mail apresentava a seguinte situação:

"

Brito, Bom Dia.

Veja se você consegue me dar uma luz. Em um Switch-Core chegam dois links, um MPLS e outro LAN-2-LAN (Clear Channel). O link MPLS é o principal, com isso colocamos uma rota default apontando para ele no SW-Core, só que quando o link principal cai, por ter uma rota default para ele, o link LAN-2-LAN não assume o tráfego. Para o link LAN-2-LAN assumir o tráfego temos que tirar a rota default para o link principal (manualmente). Tem alguma maneira de automatizar a retirada da rota quando o link principal cair?

Desde já agradeço.

" 

E a resposta é: Sim, a solução existe e não é muito complicada. Antes de discutir a solução do problema, vamos visualizar uma imagem simplificada do cenário. A interface f0/0 está conectada na rede local, a interface f1/0 recebe o link MPLS e a interface f2/0 recebe o link LAN-2-LAN:

A princípio, uma solução imediata para o problema seria adicionar duas rotas default com custos diferentes, uma saindo por cada interface:

SW-Core(config)# ip route 0.0.0.0 0.0.0.0 f1/0 1

SW-Core(config)# ip route 0.0.0.0 0.0.0.0 f2/0 2

Mas isso não funcionaria! O problema dessa "solução" é que os links MPLS e LAN-2-LAN são diretamente conectados ao Switch-Core através de interfaces fast-ethernet e, por isso, quando o link cai, a interface mantém seu status como up. Então para resolver o problema é necessário monitorar a alcançabilidade IP via "track" com "IP SLA". A solução consiste nas seguintes etapas:

1) Criar o seguinte monitoramento ao gateway MPLS:

SW-Core(config)# ip sla monitor 1
SW-Core(config-sla-monitor)# type echo protocol ipIcmpEcho 11.11.11.1 source-interface f1/0
SW-Core(config-sla-monitor)# timeout 500
SW-Core(config-sla-monitor)# frequency 3
SW-Core(config-sla-monitor)# exit
SW-Core(config)# ip sla monitor schedule 1 life forever start-time now

Agora o dispositivo fará 3 tentativas de ping (echo requests) de meio em meio segundo (500ms) para o seu gateway da interface f1/0 (o link MPLS). Lembrei o aluno para não esquecer de substituir o ip 11.11.11.1 pelo endereço do gateway MPLS que eles possuem na empresa. 

Também disse ao aluno para ter em mente que essa estratégia vai consumir mais recursos do SW-Core porque ativamos um monitoramento que irá gerar tráfego com frequência para monitorar a alcançabilidade do destino. No entanto, não há outra forma de conseguir esse resultado já que a interface fast-ethernet não cai com a ausência de conectividade do link.

2) Criar um objeto de rastreabilidade (track) associado ao "SLA Monitor 1":

SW-Core(config)# track 1 rtr 1

Obs.: Em versões mais recentes do IOS pode ser que você tenha que substituir esse comando por: "track 1 ip sla 1 reachability". O recurso SLA já foi previamente denominado SAA e RTR, daí a menção rtr no comando.

3) Criar as seguintes rotas default rastreando o link primário:

SW-Core(config)# ip route 0.0.0.0 0.0.0.0 f1/0 track 1 1
SW-Core(config)# ip route 0.0.0.0 0.0.0.0 f2/0 2

Pronto! Assim vai funcionar independente do status da interface porque o dispositivo irá monitorar o sucesso do ping ao gateway na camada 3!!! Apenas para confirmar que a solução funciona, vamos visualizar a tabela de roteamento e o objeto "track 1" do SW-Core quando o link MPLS está ativo:

SW-Core#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is 0.0.0.0 to network 0.0.0.0

     22.0.0.0/30 is subnetted, 1 subnets
C       22.22.22.0 is directly connected, FastEthernet2/0
     11.0.0.0/30 is subnetted, 1 subnets
C       11.11.11.0 is directly connected, FastEthernet1/0
C    192.168.0.0/24 is directly connected, FastEthernet0/0
S*   0.0.0.0/0 is directly connected, FastEthernet1/0

SW-Core#

SW-Core#show track 1
Track 1
  Response Time Reporter 1 state
  State is Up
    2 changes, last change 00:00:59
  Latest operation return code: OK
  Latest RTT (millisecs) 16
  Tracked by:
    STATIC-IP-ROUTING 0

Reparem que a rota default sai pela interface f1/0 do link MPLS. Também repare que o objeto "track 1" está com status UP. Agora vou simular uma queda no link MPLS derrubando a interface do roteador que representa a operadora e vajamos o resultado:

SW-Core#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is 0.0.0.0 to network 0.0.0.0

     22.0.0.0/30 is subnetted, 1 subnets
C       22.22.22.0 is directly connected, FastEthernet2/0
     11.0.0.0/30 is subnetted, 1 subnets
C       11.11.11.0 is directly connected, FastEthernet1/0
C    192.168.0.0/24 is directly connected, FastEthernet0/0
S*   0.0.0.0/0 is directly connected, FastEthernet2/0
SW-Core#
SW-Core#show track 1
Track 1
  Response Time Reporter 1 state
  State is Down
    3 changes, last change 00:00:09
  Latest operation return code: Timeout
  Tracked by:
    STATIC-IP-ROUTING 0

Problema resolvido!

Espero que essa postagem seja útil também para outras pessoas! ;-)
 
Abraço.

Samuel.