1 votos

¿Qué significa "tc mirred to Houston" y cómo lo soluciono?

Estoy usando una vieja linux portatil como un router, con una bastante reciente compilación de Bunsenlabs.

Linux grasshopper 4.9.0-0.bpo.5-686 #1 SMP Debian 4.9.65-3+deb9u2~bpo8+1 (2017-01-05) i686

Tengo dos enlaces de subida.

La primera es una conexión de adsl que estoy utilizando a través de PPPoE, con la actual interfaz eth1:

ppp0      Link encap:Point-to-Point Protocol
          inet addr:x.x.x.x  P-t-P:y.y.y.y  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1
          RX packets:10739 errors:0 dropped:0 overruns:0 frame:0
          TX packets:12796 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3

eth1      Link encap:Ethernet  HWaddr a0:ce:c8:12:eb:2b
          inet6 addr: fe80::a2ce:c8ff:fe12:eb2b/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:16805 errors:0 dropped:0 overruns:0 frame:0
          TX packets:21366 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:8199226 (7.8 MiB)  TX bytes:5372980 (5.1 MiB)

El segundo es un LTE hotspot de Cáliz (se ejecuta en la red de Sprint) de que el portátil se conecta a través de wifi:

wlan0     Link encap:Ethernet  HWaddr 00:15:af:b6:43:c0
          inet6 addr: fe80::215:afff:feb6:43c0/64 Scope:Link
          inet6 addr: 2600:1:9719:50b7:215:afff:feb6:43c0/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:321 errors:0 dropped:0 overruns:0 frame:0
          TX packets:422 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:44098 (43.0 KiB)  TX bytes:54526 (53.2 KiB)

Estoy usando un script en Ruby para manejar el enrutamiento a través de multi-wan - https://github.com/drsound/fault_tolerant_router

Mi config para que:

#see https://github.com/drsound/fault_tolerant_router for a complete parameter
#description

#add as many uplinks as needed, in this example ppp0 is used as default route only if both eth1 and eth2 are down
uplinks:
- interface: wlan0
  type: static
  ip: 192.168.128.2
  gateway: 192.168.128.1
  description: LTE Hotspot
  priority_group: 1
  #optional parameter
  weight: 100
- interface: ppp0
  type: ppp
  description: DSL
  priority_group: 1
  #optional parameter
  weight: 10

downlinks:
  lan: eth0
  #leave blank if you have no DMZ
  dmz:

tests:
  #an array of IP addresses to ping to verify the uplinks state. You can add as
  #many as you wish. 
  ips:
  - www.google.com
  - www.bing.com
  - www.yahoo.com
  - www.sprint.com
  - 8.8.8.8
  - 4.2.2.2
  #number of successfully pinged IP addresses to consider an uplink to be
  #functional
  required_successful: 4
  #number of ping retries before giving up on an IP
  ping_retries: 1
  #seconds between a check of the uplinks and the next one
  interval: 15

log:
  file: "/var/log/fault_tolerant_router.log"

email:
  send: true <snip>

#base IP route table number, just need to change if you are already using
#multiple routing tables
base_table: 1

#just need to change if you are already using ip policy routing, to avoid
#overlapping, must be higher than 32767 (the default routing table priority,
#see output of "ip rule" command)
base_priority: 40000

#just need to change if you are already using packet marking, to avoid
#overlapping
base_fwmark: 1

Cuando funciona, funciona muy bien. Sin embargo, he encontrado que es necesario configurar un cron job para reiniciar todas las noches, como a lo largo del tiempo la red se vuelve menos estable. Reiniciar cada noche ayuda, pero no siempre.

Cuando se baja durante el día, la frecuencia de verificación dmesg para ver lo que está pasando. Con frecuencia, voy a ver el mismo mensaje varias veces por segundo durante horas y horas, con la limitación de velocidad:

Jun 29 14:51:11 grasshopper kernel: [1490667.334171] tc mirred to Houston: device ifb4eth1 is down
Jun 29 14:51:11 grasshopper kernel: [1490667.493910] tc mirred to Houston: device ifb4eth1 is down
Jun 29 14:51:11 grasshopper kernel: [1490667.653151] tc mirred to Houston: device ifb4eth1 is down
Jun 29 14:51:12 grasshopper kernel: [1490667.813661] tc mirred to Houston: device ifb4eth1 is down
Jun 29 14:51:12 grasshopper kernel: [1490667.973401] tc mirred to Houston: device ifb4eth1 is down
Jun 29 14:51:12 grasshopper kernel: [1490668.133407] tc mirred to Houston: device ifb4eth1 is down
Jun 29 14:51:12 grasshopper kernel: [1490668.293656] tc mirred to Houston: device ifb4eth1 is down

A veces es mi conexión wifi hotspot, a veces es la conexión ethernet para el dsl "módem".

Dos preguntas:

  1. ¿Qué significa el mensaje de error significa? He buscado y sólo se encuentran enlaces a un archivo en la fuente de linux: https://github.com/torvalds/linux/blob/2ee22a90c7afac265bb6f7abea610b938195e2b8/net/sched/act_mirred.c#L152 lo que me da muy poco para ir.
  2. ¿Cuáles son ifb4eth1 y ifb4wlan0? Están causando el problema? Puedo eliminarlos? Experimenté con listas negras de la ifb y act_mirred módulos, sino que se carga de todos modos.

0voto

Sanael Puntos 148

Según https://wiki.linuxfoundation.org/networking/ifb , ifb4eth1 significa clase 1: 4 de la interfaz eth1, y parece que está inactivo (¿ya no existe? ¿La interfaz está inactiva?)

En tu secuencia de comandos, ¿cuál es la clase 1: 4? ¿Puedes mostrarnos para que podamos intentar ayudar?

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: