ru.unix.bsd

 
 - RU.UNIX.BSD ------------------------------------------------------------------
 From : alex help kushnaryov                 2:4627/10      23 Jul 2003  10:58:47
 To : All
 Subject : zebra, вернее multicast -
 -------------------------------------------------------------------------------- 
 

 всё собирается, ставится, и даже отлично работает, если бы только
 не один нюанс - почему-то multicast-пакеты, которые она вещает по её
 утверждению там, где им и положено вещаться - на эйзернете fxp0,
 на этом эйзернете ни фига не видны, а идут они почему-то на один из
 ppp - ppp2. более детально (неинформативная часть строк логов
 местами почикана для предотвращения переносов):
 
 11:03 root@ns.panda:~# ifconfig
 fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
         inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255
         ether 00:02:b3:8b:25:4d
         media: Ethernet autoselect (100baseTX <full-duplex>)
         status: active
 fxp1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
         inet 172.27.1.194 netmask 0xfffffff0 broadcast 172.27.1.207
         ether 00:90:27:8d:32:b2
         media: Ethernet autoselect (100baseTX <full-duplex>)
         status: active
 lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
         inet 127.0.0.1 netmask 0xff000000
         inet 195.238.41.23 netmask 0xffffffff
 ppp0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
         inet 192.168.0.2 --> 192.168.1.5 netmask 0xffffff00
 ppp1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
         inet 192.168.0.2 --> 192.168.1.10 netmask 0xffffff00
 ppp2: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
         inet 192.168.0.2 --> 192.168.1.1 netmask 0xffffff00
 
 в логах зебры, включен дебаг пакетов:
 
 2003/07/23 11:09:02 ... Hello sent to [224.0.0.5] via [fxp0:192.168.0.2].
 2003/07/23 11:09:12 ... Hello sent to [224.0.0.5] via [fxp0:192.168.0.2].
 2003/07/23 11:09:22 ... Hello sent to [224.0.0.5] via [fxp0:192.168.0.2].
 2003/07/23 11:09:32 ... Hello sent to [224.0.0.5] via [fxp0:192.168.0.2].
 
 смотрим на fxp0 (tcpdump -i fxp0 net 224):
 
 11:09:06.119483 cisco.panda > OSPF-ALL.MCAST.NET: OSPFv2-hello 44:
  backbone dr cisco.panda [tos 0xc0]  [ttl 1]
 11:09:16.120873 cisco.panda > OSPF-ALL.MCAST.NET: OSPFv2-hello 44:
  backbone dr cisco.panda [tos 0xc0]  [ttl 1]
 11:09:26.123350 cisco.panda > OSPF-ALL.MCAST.NET: OSPFv2-hello 44:
  backbone dr cisco.panda [tos 0xc0]  [ttl 1]
 11:09:36.124488 cisco.panda > OSPF-ALL.MCAST.NET: OSPFv2-hello 44:
  backbone dr cisco.panda [tos 0xc0]  [ttl 1]
 
 cisco.panda - это киска, с которой и нужно поднять ospf. киску видим,
 себя нет.. что ж, в рулесах ipfw есть у нас правило в верхних
 строках,  pass log ospf from any to any, смотрим лог:
 
 Jul 23 11:09:02 ... 700 Accept P:89 192.168.0.2 224.0.0.5 out via ppp2
 Jul 23 11:09:06 ... 700 Accept P:89 192.168.0.3 224.0.0.5 in via fxp0
 Jul 23 11:09:12 ... 700 Accept P:89 192.168.0.2 224.0.0.5 out via ppp2
 Jul 23 11:09:16 ... 700 Accept P:89 192.168.0.3 224.0.0.5 in via fxp0
 Jul 23 11:09:22 ... 700 Accept P:89 192.168.0.2 224.0.0.5 out via ppp2
 Jul 23 11:09:26 ... 700 Accept P:89 192.168.0.3 224.0.0.5 in via fxp0
 Jul 23 11:09:32 ... 700 Accept P:89 192.168.0.2 224.0.0.5 out via ppp2
 Jul 23 11:09:36 ... 700 Accept P:89 192.168.0.3 224.0.0.5 in via fxp0
 
 проверяем (tcpdump -i ppp2 net 224), и убеждаемся:
 
 11:09:02.073383 ns.panda > OSPF-ALL.MCAST.NET: OSPFv2-hello 44:
  backbone dr ns.panda [ttl 1]
 11:09:12.084786 ns.panda > OSPF-ALL.MCAST.NET: OSPFv2-hello 44:
  backbone dr ns.panda [ttl 1]
 11:09:22.096624 ns.panda > OSPF-ALL.MCAST.NET: OSPFv2-hello 44:
  backbone dr ns.panda [ttl 1]
 11:09:32.107550 ns.panda > OSPF-ALL.MCAST.NET: OSPFv2-hello 44:
  backbone dr ns.panda [ttl 1]
 
 не отходя от кассы, смотрим что про это думает зебра:
 
 ns# sh int fxp0
 Interface fxp0
   index 1 metric 1 mtu 1500 <UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST>
   HWaddr: 00:02:b3:8b:25:4d
   inet 192.168.0.2/24 broadcast 192.168.0.255
     input packets 9617646, bytes 3561485044, dropped 0,
          multicast packets 18221
     input errors 0
     output packets 8924110, bytes 3824831754, multicast packets 37
     output errors 2
     collisions 0
 ns# sh int ppp2
 Interface ppp2
   index 6 metric 1 mtu 1500 <UP,POINTOPOINT,RUNNING,MULTICAST>
   inet 192.168.0.2/24 pointopoint 192.168.1.1
     input packets 777625, bytes 53581115, dropped 0,
          multicast packets 0
     input errors 9925
     output packets 760054, bytes 419308491, multicast packets 0
     output errors 0
     collisions 0
 
 и что про это думает сама фряха (статистика почикана):
 
 11:39 root@ns.panda:~# netstat -i -na
 Name  Mtu   Network       Address
 fxp0  1500  <Link#1>    00:02:b3:8b:25:4d
                         01:00:5e:00:00:01
 fxp0  1500  192.168.0     192.168.0.2
                         224.0.0.1
 fxp1  1500  <Link#2>    00:90:27:8d:32:b2
                         01:00:5e:00:00:01
 fxp1  1500  172.27.1.192/ 172.27.1.194
                         224.0.0.1
 lo0   16384 <Link#3>
 lo0   16384 127           127.0.0.1
                         224.0.0.1
 lo0   16384 195.238.41.23 195.238.41.23
                         224.0.0.1
 ppp0  1500  <Link#4>
 ppp0  1500  192.168.0     192.168.0.2
                         224.0.0.1
 ppp1  1500  <Link#5>
 ppp1  1500  192.168.0     192.168.0.2
                         224.0.0.1
 ppp2  1500  <Link#6>
 ppp2  1500  192.168.0     192.168.0.2
                         224.0.0.6
                         224.0.0.5
                         224.0.0.1
 
 зебра убеждена, на выход прошло 37 малтикастовых пакетов (а это ospf,
 потому что прочий малтикаст отсутствует) через fxp0 и ни одного через
 ppp2, хотя в действительности всё диаметрально наоборот.
 малтикастовый роутинг в ядро не вкомпилён, в таблицу маршрутизации
 средствами самой зебры при старте загоняется маршрут на 224.0.0.0/24
 через 127.0.0.1 (пробовалось также через fxp0 - эффекта нет),
 last resort маршрут смотрит на fxp1, через который выход в мир.
 
 самый главный нюанс - до zebra пробовал для этих же целей использовать
 gated - результат тот же, то есть это явно не глюк zebra или gated -
 скорее, что-то не срослось у меня в системе.
 
 кто что может подсказать, почему так и как пофиксить?
 -- 
 Best regards, alex 'help' kushnaryov, [help@skryabin.org.ua][icq#6127905]
 ISP "Panda Ltd.", system administrator.  [2:4627/10@fidonet][HELP10-RIPE]
 
 --- Mutt-1.5.1i/BSD
  * Origin: help @ work (2:4627/10)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор