subject:"маршрутизация"

23 апреля 2009 г. 14:22 пользователь Elena Egorova j...@satgate.net написал:
 Hi all,

 Alex Petrov wrote:

 ## uplink2
 iface eth1 inet static
        address 213.7.50.121
        netmask 255.255.255.248
        post-up ip route add 213.7.50.126/32 dev eth1 src 213.7.50.121
 table uplink2
        post-up ip route add default via 213.7.50.126 table uplink2
        post-up ip rule add from 213.7.50.121 table uplink2
        post-down ip rule del from 213.7.50.121 table uplink2


 при такой маске сети (/29) хост 213.7.50.126 и так считается непосредственно
 подключенным к eth1, роут на него писать не нужно (возможно, из-за этого не
 резолвится mac через arp).

 Еще можно посмотреть arp-таблицу, если 213.7.50.126 так и не запингуется.

 --
 Elena Egorova


 --
 To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact
 listmas...@lists.debian.org



Роут убрал (post-up ip route add 213.7.50.126/32 dev eth1 src 213.7.50.121
 table uplink2) на обоих аплинках, которые не видны. В таблице по прежнему 
 не видит шлюз.

arp -n:
213.7.50.126(incomplete)  eth1

ip route list:
10.130.128.1 dev ppp0  proto kernel  scope link  src 212.3.45.162
81.16.115.128/29 dev eth3  proto kernel  scope link  src 81.16.115.130
213.7.50.120/29 dev eth1  proto kernel  scope link  src 213.7.50.121
192.168.5.0/24 dev eth0  proto kernel  scope link  src 192.168.5.224
192.168.1.0/24 via 192.168.5.1 dev eth0
192.168.203.0/24 dev eth0  proto kernel  scope link  src 192.168.203.224
default via 212.3.45.162 dev ppp0  scope link

ip route list table uplink2:
default via 213.7.50.126 dev eth1

ip route list table uplink3:
default via 81.16.15.134 dev eth3

ip route list table uplink1:
пустой. Это основной сейчас мой провайдер, через него все у меня
ходит. Поднимается через ppp


-- 
С уважением, Алексей

Re: Маршрутизация чере з нескольких провайдеров

Hello!

On Fri, Apr 24, 2009 at 11:36:41AM +0400, Alex Petrov wrote:
arp -n:
213.7.50.126(incomplete) eth1

Собственно, проблема в этом, а не в policy routing.
Чтобы что-то перенаправить на этот гейт - он для начала должен быть
доступен.

Т.е. адрес гейта не резолвится по arp. Похоже на то, что либо
нет/поломана физика между вами и провайдером, либо с его стороны
прописан не .126 в к-ве гейта.

mii-tool/ethtool что говорят, линк eth1 вообще UP?

ip route list:
10.130.128.1 dev ppp0 proto kernel scope link src 212.3.45.162
81.16.115.128/29 dev eth3 proto kernel scope link src 81.16.115.130
213.7.50.120/29 dev eth1 proto kernel scope link src 213.7.50.121
192.168.5.0/24 dev eth0 proto kernel scope link src 192.168.5.224
192.168.1.0/24 via 192.168.5.1 dev eth0
192.168.203.0/24 dev eth0 proto kernel scope link src 192.168.203.224
default via 212.3.45.162 dev ppp0 scope link

ip route list table uplink2:
default via 213.7.50.126 dev eth1

ip route list table uplink3:
default via 81.16.15.134 dev eth3

ip route list table uplink1:
пустой. Это основной сейчас мой провайдер, через него все у меня
ходит. Поднимается через ppp

С настройками сети, похоже, все в порядке. Раут к 213.7.50.120/29
корректен.

--
WBR,
Alex

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Маршрутизация чере з нескольких провайдеров

Hello!

On Fri, Apr 24, 2009 at 01:06:00PM +0300, Alex wrote:
 Hello!
 
 On Fri, Apr 24, 2009 at 01:54:55PM +0400, Alex Petrov wrote:
  Понимаю, что не резолвится по arp. Не понимаю почему.
  
  линк приходит на SDSL модем - от него в свич - идут провода на 2
  компьютера. На другом шлюз пингуется, все видно, на этом хосте все так
  же, шлюз не пингуется, arp incomplit. Провода нормальные, интерфейс
  поднят. лампочки на сетевой моргают.
 
 А что видно на интерфейсе?
 
 arp -d 213.7.50.126
 tcpdump -i eth1 -n arp

Тут еще ping 213.7.50.126, конечно, чтобы arp ушел.

 arp запрос уходит?
 
 Если да, то свич управляемый? Может, VLAN'ы на порту не те?
 
 -- 
 WBR,
 Alex
 
 
 -- 
 To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 

-- 
WBR,
Alex


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Маршрутизация через неско льких провайдеров

24 апреля 2009 г. 14:06 пользователь Alex a...@localhost.org.ua написал:
 Hello!

 On Fri, Apr 24, 2009 at 01:54:55PM +0400, Alex Petrov wrote:
 Понимаю, что не резолвится по arp. Не понимаю почему.

 линк приходит на SDSL модем - от него в свич - идут провода на 2
 компьютера. На другом шлюз пингуется, все видно, на этом хосте все так
 же, шлюз не пингуется, arp incomplit. Провода нормальные, интерфейс
 поднят. лампочки на сетевой моргают.

 А что видно на интерфейсе?

 arp -d 213.7.50.126
 tcpdump -i eth1 -n arp

 arp запрос уходит?

Тут происходит вот что:

plak...@phantom:~$ sudo tcpdump -i eth1 -n arp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
14:30:33.099076 arp who-has 213.7.50.126 tell 213.7.50.121
14:30:34.098975 arp who-has 213.7.50.126 tell 213.7.50.121
14:30:35.098883 arp who-has 213.7.50.126 tell 213.7.50.121
14:30:36.350754 arp who-has 213.7.50.126 tell 213.7.50.121
14:30:36.562733 arp who-has 213.7.50.125 tell 212.3.45.162
14:30:37.350658 arp who-has 213.7.50.126 tell 213.7.50.121
14:30:37.562637 arp who-has 213.7.50.125 tell 212.3.45.162
14:30:38.350564 arp who-has 213.7.50.126 tell 213.7.50.121
14:30:38.562543 arp who-has 213.7.50.125 tell 212.3.45.162
14:30:41.254287 arp who-has 213.7.50.126 tell 213.7.50.121
14:30:42.254190 arp who-has 213.7.50.126 tell 213.7.50.121
14:30:43.254094 arp who-has 213.7.50.126 tell 213.7.50.121

А почему тут появляется 212.3.45.162? Я что-то не понимаю?

 Если да, то свич управляемый? Может, VLAN'ы на порту не те?

Свич самый простой, неуправляемый.


 --
 WBR,
 Alex




-- 
С уважением, Алексей

Re: Маршрутизация чере з нескольких провайдеров

Hello!

On Fri, Apr 24, 2009 at 02:35:58PM +0400, Alex Petrov wrote:
Тут происходит вот что:

plak...@phantom:~$ sudo tcpdump -i eth1 -n arp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
14:30:33.099076 arp who-has 213.7.50.126 tell 213.7.50.121
14:30:34.098975 arp who-has 213.7.50.126 tell 213.7.50.121
14:30:35.098883 arp who-has 213.7.50.126 tell 213.7.50.121
14:30:36.350754 arp who-has 213.7.50.126 tell 213.7.50.121
14:30:36.562733 arp who-has 213.7.50.125 tell 212.3.45.162
14:30:37.350658 arp who-has 213.7.50.126 tell 213.7.50.121
14:30:37.562637 arp who-has 213.7.50.125 tell 212.3.45.162
14:30:38.350564 arp who-has 213.7.50.126 tell 213.7.50.121
14:30:38.562543 arp who-has 213.7.50.125 tell 212.3.45.162
14:30:41.254287 arp who-has 213.7.50.126 tell 213.7.50.121
14:30:42.254190 arp who-has 213.7.50.126 tell 213.7.50.121
14:30:43.254094 arp who-has 213.7.50.126 tell 213.7.50.121

А почему тут появляется 212.3.45.162? Я что-то не понимаю?

ARP запросы шлются на ethernet broadcast адрес. Это значит, что где-то в
этой же ethernet сети есть устройство с адресом 212.3.45.162, которое
пытается отрезолвить mac ip адреса 213.7.50.125.

Если модем стоит в режиме моста, то не исключено что этот arp-запрос приходит
вообще от провайдера.

Если да, то свич управляемый? Может, VLAN'ы на порту не те?
Свич самый простой, неуправляемый.

Похоже, что проблема находится за пределами этого сервера и/или
конфликтует с его настройками.

Попробуйте включить DSL модем напрямую в ethernet-порт сервера. Появятся
ли arp'ы, видимость гейта?

Если да, то проблема между сервером и модемом, т.е. где-то в районе
свича. Попробуйте включить пачкорд, который работает в порт сервера,
где наблюдаются проблемы.

Если нет, то возможно со стороны провайдера применяется что-то вроде
port-security, т.е. вы протестили канал с другого сервера, мак-адрес
того сервера запомнился на оборудовании провайдера и на другие маки
оно не реагирует. Но это предположение.

--
WBR,
Alex

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Маршрутизация ч ерез нескольких провайдеров

2009-04-24 Пенетрантность Peter Pentchev

On Fri, Apr 24, 2009 at 01:48:21PM +0300, Alex wrote:
 Hello!
 
 On Fri, Apr 24, 2009 at 02:35:58PM +0400, Alex Petrov wrote:
  Тут происходит вот что:
  
  plak...@phantom:~$ sudo tcpdump -i eth1 -n arp
  tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
  listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
  14:30:33.099076 arp who-has 213.7.50.126 tell 213.7.50.121
  14:30:34.098975 arp who-has 213.7.50.126 tell 213.7.50.121
  14:30:35.098883 arp who-has 213.7.50.126 tell 213.7.50.121
  14:30:36.350754 arp who-has 213.7.50.126 tell 213.7.50.121
  14:30:36.562733 arp who-has 213.7.50.125 tell 212.3.45.162
  14:30:37.350658 arp who-has 213.7.50.126 tell 213.7.50.121
  14:30:37.562637 arp who-has 213.7.50.125 tell 212.3.45.162
  14:30:38.350564 arp who-has 213.7.50.126 tell 213.7.50.121
  14:30:38.562543 arp who-has 213.7.50.125 tell 212.3.45.162
  14:30:41.254287 arp who-has 213.7.50.126 tell 213.7.50.121
  14:30:42.254190 arp who-has 213.7.50.126 tell 213.7.50.121
  14:30:43.254094 arp who-has 213.7.50.126 tell 213.7.50.121
  
  А почему тут появляется 212.3.45.162? Я что-то не понимаю?
 
 ARP запросы шлются на ethernet broadcast адрес. Это значит, что где-то в
 этой же ethernet сети есть устройство с адресом 212.3.45.162, которое
 пытается отрезолвить mac ip адреса 213.7.50.125.

Мммм, если я не очень ошибаюсь, это значит, что где-то в сети есть
устройство с адресом 213.7.50.121, которое пытается отреьолвить mac
ip адреса 213.7.50.126 - а не наоборот :)

Всего лучшего,
Петр

-- 
Peter Pentchev  r...@ringlet.netr...@space.bgr...@freebsd.org
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E  DF9E ED18 B68D 1619 4553
You have, of course, just begun reading the sentence that you have just 
finished reading.


pgpVWkVPfr9Hy.pgp
Description: PGP signature

Re: Маршрутизация чере з нескольких провайдеров

Hello!

On Fri, Apr 24, 2009 at 01:53:13PM +0300, Peter Pentchev wrote:
  On Fri, Apr 24, 2009 at 02:35:58PM +0400, Alex Petrov wrote:
   Тут происходит вот что:
   
   plak...@phantom:~$ sudo tcpdump -i eth1 -n arp
   tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
   listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
   14:30:33.099076 arp who-has 213.7.50.126 tell 213.7.50.121
   14:30:34.098975 arp who-has 213.7.50.126 tell 213.7.50.121
   14:30:35.098883 arp who-has 213.7.50.126 tell 213.7.50.121
   14:30:36.350754 arp who-has 213.7.50.126 tell 213.7.50.121
   14:30:36.562733 arp who-has 213.7.50.125 tell 212.3.45.162
   14:30:37.350658 arp who-has 213.7.50.126 tell 213.7.50.121
   14:30:37.562637 arp who-has 213.7.50.125 tell 212.3.45.162
   14:30:38.350564 arp who-has 213.7.50.126 tell 213.7.50.121
   14:30:38.562543 arp who-has 213.7.50.125 tell 212.3.45.162
   14:30:41.254287 arp who-has 213.7.50.126 tell 213.7.50.121
   14:30:42.254190 arp who-has 213.7.50.126 tell 213.7.50.121
   14:30:43.254094 arp who-has 213.7.50.126 tell 213.7.50.121
   
   А почему тут появляется 212.3.45.162? Я что-то не понимаю?
  
  ARP запросы шлются на ethernet broadcast адрес. Это значит, что где-то в
  этой же ethernet сети есть устройство с адресом 212.3.45.162, которое
  пытается отрезолвить mac ip адреса 213.7.50.125.
 
 Мммм, если я не очень ошибаюсь, это значит, что где-то в сети есть
 устройство с адресом 213.7.50.121, которое пытается отреьолвить mac
 ip адреса 213.7.50.126 - а не наоборот :)

Там 2 арп-запроса:
от 213.7.50.121 резолв адреса 213.7.50.126
от 212.3.45.162 резолв адреса 213.7.50.125

У топикстартера был вопрос, откуда взялся второй запрос с адреса,
лежащего за пределами его /29 подсети.



-- 
WBR,
Alex


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Маршрутизация через неско льких провайдеров

24 апреля 2009 г. 14:53 пользователь Peter Pentchev r...@ringlet.net написал:
 On Fri, Apr 24, 2009 at 01:48:21PM +0300, Alex wrote:
 Hello!

 On Fri, Apr 24, 2009 at 02:35:58PM +0400, Alex Petrov wrote:
  Тут происходит вот что:
 
  plak...@phantom:~$ sudo tcpdump -i eth1 -n arp
  tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
  listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
  14:30:33.099076 arp who-has 213.7.50.126 tell 213.7.50.121
  14:30:34.098975 arp who-has 213.7.50.126 tell 213.7.50.121
  14:30:35.098883 arp who-has 213.7.50.126 tell 213.7.50.121
  14:30:36.350754 arp who-has 213.7.50.126 tell 213.7.50.121
  14:30:36.562733 arp who-has 213.7.50.125 tell 212.3.45.162
  14:30:37.350658 arp who-has 213.7.50.126 tell 213.7.50.121
  14:30:37.562637 arp who-has 213.7.50.125 tell 212.3.45.162
  14:30:38.350564 arp who-has 213.7.50.126 tell 213.7.50.121
  14:30:38.562543 arp who-has 213.7.50.125 tell 212.3.45.162
  14:30:41.254287 arp who-has 213.7.50.126 tell 213.7.50.121
  14:30:42.254190 arp who-has 213.7.50.126 tell 213.7.50.121
  14:30:43.254094 arp who-has 213.7.50.126 tell 213.7.50.121
 
  А почему тут появляется 212.3.45.162? Я что-то не понимаю?

 ARP запросы шлются на ethernet broadcast адрес. Это значит, что где-то в
 этой же ethernet сети есть устройство с адресом 212.3.45.162, которое
 пытается отрезолвить mac ip адреса 213.7.50.125.

 Мммм, если я не очень ошибаюсь, это значит, что где-то в сети есть
 устройство с адресом 213.7.50.121, которое пытается отреьолвить mac
 ip адреса 213.7.50.126 - а не наоборот :)

Ну 121 - это мой IP, 126 - шлюз провайдера. К MAC-адресу он не
привязывается, все работало у меня на этой карте несколько лет. Я
грешу на то что криво маршрутизация настроена.. втыкаю в ноутбут - все
работает. и на втором и на третьем аплинке. Тут не может достучаться.


-- 
С уважением, Алексей

Re: Маршрутизация чере з нескольких провайдеров

Hello!

On Fri, Apr 24, 2009 at 02:58:02PM +0400, Alex Petrov wrote:
 Ну 121 - это мой IP, 126 - шлюз провайдера. К MAC-адресу он не
 привязывается, все работало у меня на этой карте несколько лет. Я
 грешу на то что криво маршрутизация настроена.. втыкаю в ноутбут - все
 работает. и на втором и на третьем аплинке. Тут не может достучаться.

Попробуйте, все же, включить модем напрямую в сетевую сервера.

Если не поможет, то я бы сделал еще такой эксперимент:

Настроил бы на лэптопе адрес .126/29 и включил его в интерфейс сервера.
Если адрес .126 запингуется, то это полностью исключит вероятность того,
что на сервере проблемные настройки.

-- 
WBR,
Alex


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Маршрутизация чере з нескольких провайдеров

Hello!

On Fri, Apr 24, 2009 at 02:59:59PM +0400, Alex Petrov wrote:
 Потому как 212.3.45.162 - это шлюз другого провайдера. Выходит трафик
 идет не по тому маршруту, по какому ему правильно было бы идти? С моей
 стороны.

А что за адрес 213.7.50.125 тогда? Почему шлюз второго провайдера его
пытается резолвить?
.125 еще у вас нигде не прописан случайно?

-- 
WBR,
Alex


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Маршрутизация через неско льких провайдеров

24 апреля 2009 г. 14:56 пользователь Alex a...@localhost.org.ua написал:
 Hello!

 On Fri, Apr 24, 2009 at 01:53:13PM +0300, Peter Pentchev wrote:
  On Fri, Apr 24, 2009 at 02:35:58PM +0400, Alex Petrov wrote:
   Тут происходит вот что:
  
   plak...@phantom:~$ sudo tcpdump -i eth1 -n arp
   tcpdump: verbose output suppressed, use -v or -vv for full protocol 
   decode
   listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
   14:30:33.099076 arp who-has 213.7.50.126 tell 213.7.50.121
   14:30:34.098975 arp who-has 213.7.50.126 tell 213.7.50.121
   14:30:35.098883 arp who-has 213.7.50.126 tell 213.7.50.121
   14:30:36.350754 arp who-has 213.7.50.126 tell 213.7.50.121
   14:30:36.562733 arp who-has 213.7.50.125 tell 212.3.45.162
   14:30:37.350658 arp who-has 213.7.50.126 tell 213.7.50.121
   14:30:37.562637 arp who-has 213.7.50.125 tell 212.3.45.162
   14:30:38.350564 arp who-has 213.7.50.126 tell 213.7.50.121
   14:30:38.562543 arp who-has 213.7.50.125 tell 212.3.45.162
   14:30:41.254287 arp who-has 213.7.50.126 tell 213.7.50.121
   14:30:42.254190 arp who-has 213.7.50.126 tell 213.7.50.121
   14:30:43.254094 arp who-has 213.7.50.126 tell 213.7.50.121
  
   А почему тут появляется 212.3.45.162? Я что-то не понимаю?
 
  ARP запросы шлются на ethernet broadcast адрес. Это значит, что где-то в
  этой же ethernet сети есть устройство с адресом 212.3.45.162, которое
  пытается отрезолвить mac ip адреса 213.7.50.125.

 Мммм, если я не очень ошибаюсь, это значит, что где-то в сети есть
 устройство с адресом 213.7.50.121, которое пытается отреьолвить mac
 ip адреса 213.7.50.126 - а не наоборот :)

 Там 2 арп-запроса:
 от 213.7.50.121 резолв адреса 213.7.50.126
 от 212.3.45.162 резолв адреса 213.7.50.125

 У топикстартера был вопрос, откуда взялся второй запрос с адреса,
 лежащего за пределами его /29 подсети.

Потому как 212.3.45.162 - это шлюз другого провайдера. Выходит трафик
идет не по тому маршруту, по какому ему правильно было бы идти? С моей
стороны.


-- 
С уважением, Алексей

Re: Маршрутизация через неско льких провайдеров

24 апреля 2009 г. 15:17 пользователь Alex a...@localhost.org.ua написал:
Hello!

On Fri, Apr 24, 2009 at 03:14:58PM +0400, Alex Petrov wrote:
А что за адрес 213.7.50.125 тогда? Почему шлюз второго провайдера его
пытается резолвить?
.125 еще у вас нигде не прописан случайно?

Прописан. Это мой второй IP, с которого на другой машине нормально все
работает и пингуется шлюз (.50.126).
Первый IP из этой же подсети - .50.121.

Хмм.. а 121 не забит где-то у провайдера случайно?
Попробуйте прописать .124 вместо .121 на проблемном сервере.

Ничего не изменилось?

Все так же. И при попытке на лаптопе прописать адрес шлюза и
соединисть их кабелем - та же ситуация. В обе стороны ничего нет. Я
подозреваю, может быть конфликт прерываний какой-то есть, PCI слотов
всего 3 и все они забиты сейчас сетевыми картами. Там же обычно
последний порт делит с каким-то из других прерывание на сколько я
помню. Попробую остановить сервер и вытащить карту, может быть
проблема в этом кроется?

--
С уважением, Алексей

Re: Маршрутизация через неско льких провайдеров

 Мда.. Так и есть, карту из последнего слота вытащи - все заработало,
 как и должно было. Вот же.. Интересно, другая карта какая-нибудь
 заработает там? Очень бы хотелось. Что подскажете?

 Ну что могу сказать, кроме как попробуйте :) У меня жили конфигурации
 с 3-4-мя картами. Правда не помню, в последних слотах они были или нет.
 Мне кажется, что должно заработать по идее.

Вот надо же столько мучаться, а проблема не в том была. Я уже думал
совсем мозг потерял, настроено правильно, а не ходит никуда.. Буду
пробовать с другими картами, вдруг заработает. Всем спасибо!


-- 
С уважением, Алексей

Re: Маршрутизация через неско льких провайдеров

24 апреля 2009 г. 15:04 пользователь Alex a...@localhost.org.ua написал:
 Hello!

 On Fri, Apr 24, 2009 at 02:59:59PM +0400, Alex Petrov wrote:
 Потому как 212.3.45.162 - это шлюз другого провайдера. Выходит трафик
 идет не по тому маршруту, по какому ему правильно было бы идти? С моей
 стороны.

 А что за адрес 213.7.50.125 тогда? Почему шлюз второго провайдера его
 пытается резолвить?
 .125 еще у вас нигде не прописан случайно?

Прописан. Это мой второй IP, с которого на другой машине нормально все
работает и пингуется шлюз (.50.126).
Первый IP из этой же подсети - .50.121.


-- 
С уважением, Алексей

Re: Маршрутизация чере з нескольких провайдеров

Hello!

On Fri, Apr 24, 2009 at 03:29:50PM +0400, Alex Petrov wrote:
24 апреля 2009 г. 15:17 пользователь Alex a...@localhost.org.ua написал:
Хмм.. а 121 не забит где-то у провайдера случайно?
Попробуйте прописать .124 вместо .121 на проблемном сервере.

Ничего не изменилось?

Все так же. И при попытке на лаптопе прописать адрес шлюза и
соединисть их кабелем - та же ситуация. В обе стороны ничего нет.

В обе стороны? Т.е. видно что arp уходит в интерфейс, но не приходит на
laptop?

Еще предположение: в iptables случайно ничего не прописано/или
недописано касательно этого нового 3-го интерфейса?

Я
подозреваю, может быть конфликт прерываний какой-то есть, PCI слотов
всего 3 и все они забиты сейчас сетевыми картами. Там же обычно
последний порт делит с каким-то из других прерывание на сколько я
помню. Попробую остановить сервер и вытащить карту, может быть
проблема в этом кроется?

Можно попробовать. А то варианты начинают заканчиваться.

--
WBR,
Alex

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Маршрутизация через неско льких провайдеров

24 апреля 2009 г. 11:44 пользователь Alex a...@localhost.org.ua написал:
Hello!

On Fri, Apr 24, 2009 at 11:36:41AM +0400, Alex Petrov wrote:
arp -n:
213.7.50.126 (incomplete)
eth1

Понимаю, что не резолвится по arp. Не понимаю почему.

линк приходит на SDSL модем - от него в свич - идут провода на 2
компьютера. На другом шлюз пингуется, все видно, на этом хосте все так
же, шлюз не пингуется, arp incomplit. Провода нормальные, интерфейс
поднят. лампочки на сетевой моргают.

plak...@phantom:~$ ifconfig eth1
eth1 Link encap:Ethernet HWaddr 00:10:5A:2E:36:7F
inet addr:213.7.50.121 Bcast:213.7.50.127 Mask:255.255.255.248
inet6 addr: fe80::210:5aff:fe2e:367f/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:267405 errors:0 dropped:0 overruns:0 frame:0
TX packets:159065 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:16845009 (16.0 MiB) TX bytes:9695158 (9.2 MiB)
Interrupt:177 Base address:0xac00

mii-tool/ethtool что говорят, линк eth1 вообще UP?

plak...@phantom:~$ sudo mii-tool
eth0: negotiated 100baseTx-FD flow-control, link ok
eth1: negotiated 100baseTx-FD, link ok
eth2: negotiated 100baseTx-FD, link ok
eth3: negotiated 100baseTx-FD, link ok

ip route list table uplink2:
default via 213.7.50.126 dev eth1

ip route list table uplink3:
default via 81.16.15.134 dev eth3

ip route list table uplink1:
пустой. Это основной сейчас мой провайдер, через него все у меня
ходит. Поднимается через ppp

С настройками сети, похоже, все в порядке. Раут к 213.7.50.120/29
корректен.

Вот и я не пойму, вроде бы все должно работать, не пойму, ничего не
менял кардинально..

--
WBR,
Alex

--
С уважением, Алексей

Re: Маршрутизация чере з нескольких провайдеров

2007-10-10 Пенетрантность Dmitry E. Oboukhov

Hello!

On Fri, Apr 24, 2009 at 01:54:55PM +0400, Alex Petrov wrote:
 Понимаю, что не резолвится по arp. Не понимаю почему.
 
 линк приходит на SDSL модем - от него в свич - идут провода на 2
 компьютера. На другом шлюз пингуется, все видно, на этом хосте все так
 же, шлюз не пингуется, arp incomplit. Провода нормальные, интерфейс
 поднят. лампочки на сетевой моргают.

А что видно на интерфейсе?

arp -d 213.7.50.126
tcpdump -i eth1 -n arp

arp запрос уходит?

Если да, то свич управляемый? Может, VLAN'ы на порту не те?

-- 
WBR,
Alex


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Маршрутизация ч ерез нескольких провайдеров

2009-04-24 Пенетрантность Peter Pentchev

On Fri, Apr 24, 2009 at 01:56:09PM +0300, Alex wrote:
 Hello!
 
 On Fri, Apr 24, 2009 at 01:53:13PM +0300, Peter Pentchev wrote:
   On Fri, Apr 24, 2009 at 02:35:58PM +0400, Alex Petrov wrote:
Тут происходит вот что:

plak...@phantom:~$ sudo tcpdump -i eth1 -n arp
tcpdump: verbose output suppressed, use -v or -vv for full protocol 
decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
14:30:33.099076 arp who-has 213.7.50.126 tell 213.7.50.121
14:30:34.098975 arp who-has 213.7.50.126 tell 213.7.50.121
14:30:35.098883 arp who-has 213.7.50.126 tell 213.7.50.121
14:30:36.350754 arp who-has 213.7.50.126 tell 213.7.50.121
14:30:36.562733 arp who-has 213.7.50.125 tell 212.3.45.162
14:30:37.350658 arp who-has 213.7.50.126 tell 213.7.50.121
14:30:37.562637 arp who-has 213.7.50.125 tell 212.3.45.162
14:30:38.350564 arp who-has 213.7.50.126 tell 213.7.50.121
14:30:38.562543 arp who-has 213.7.50.125 tell 212.3.45.162
14:30:41.254287 arp who-has 213.7.50.126 tell 213.7.50.121
14:30:42.254190 arp who-has 213.7.50.126 tell 213.7.50.121
14:30:43.254094 arp who-has 213.7.50.126 tell 213.7.50.121

А почему тут появляется 212.3.45.162? Я что-то не понимаю?
   
   ARP запросы шлются на ethernet broadcast адрес. Это значит, что где-то в
   этой же ethernet сети есть устройство с адресом 212.3.45.162, которое
   пытается отрезолвить mac ip адреса 213.7.50.125.
  
  Мммм, если я не очень ошибаюсь, это значит, что где-то в сети есть
  устройство с адресом 213.7.50.121, которое пытается отреьолвить mac
  ip адреса 213.7.50.126 - а не наоборот :)
 
 Там 2 арп-запроса:
 от 213.7.50.121 резолв адреса 213.7.50.126
 от 212.3.45.162 резолв адреса 213.7.50.125
 
 У топикстартера был вопрос, откуда взялся второй запрос с адреса,
 лежащего за пределами его /29 подсети.

Ой.  Извините, сплю.

Всего лучшего,
Петр

-- 
Peter Pentchev  r...@ringlet.netr...@space.bgr...@freebsd.org
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E  DF9E ED18 B68D 1619 4553
I am jealous of the first word in this sentence.


pgpKgtrshvBid.pgp
Description: PGP signature

Re: Маршрутизация через неско льких провайдеров

2009-04-23 Пенетрантность Alex Petrov

Уважаемые, никто не подскажет, что поковырять?

21 апреля 2009 г. 14:52 пользователь Alex Petrov plak...@gmail.com написал:
 Здравствуйте, уважаемые специалисты.

 Столкнулся с сабжевой проблемой. До недавнего времени было у меня 2
 провайдера, настроена маршрутизация, чтобы пакет с определенным
 адресом источника маршрутизировался через соответствующий интерфейс,




-- 
С уважением, Алексей

Re: Маршрутизация чере з нескольких провайдеров

2009-04-23 Пенетрантность Alex

Hello!

On Tue, Apr 21, 2009 at 02:52:31PM +0400, Alex Petrov wrote:
 ## uplink2
 iface eth1 inet static
 address 213.7.50.121
 netmask 255.255.255.248
 post-up ip route add 213.7.50.126/32 dev eth1 src 213.7.50.121
 table uplink2
^
По-моему в этом нет необходимости, сеть и так directly connected.

 post-up ip route add default via 213.7.50.126 table uplink2
 post-up ip rule add from 213.7.50.121 table uplink2
 post-down ip rule del from 213.7.50.121 table uplink2
 

 ip neigh show
 
 показывает
 213.7.50.126 dev eth1  INCOMPLETE
 Это шлюз провайдера.

А 213.7.50.126 пингуется вообще? Связь с ним есть?

Покажите 
ip route list
ip route list table uplink1
ip route list table uplink2
ip route list table uplink3


-- 
WBR,
Alex


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Маршрутизация чере з нескольких провайдеров

2009-04-23 Пенетрантность Alex

Hello!

On Thu, Apr 23, 2009 at 12:59:02PM +0300, Alex wrote:
  ip neigh show
  
  показывает
  213.7.50.126 dev eth1  INCOMPLETE
  Это шлюз провайдера.
 
 А 213.7.50.126 пингуется вообще? Связь с ним есть?

Глупый вопрос сам задал. Конечно, не пингуется, связи нет.
ARP incomplete.

Чтобы решить проблему - сначала добейтесь видимости по пиринговому линку
между вами и провайдером. Сейчас шлюз провайдера не отвечает на arp.

-- 
WBR,
Alex


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Маршрутизация чер ез нескольких провайд еров

2009-04-23 Пенетрантность Elena Egorova


Hi all,

Alex Petrov wrote:


## uplink2
iface eth1 inet static
address 213.7.50.121
netmask 255.255.255.248
post-up ip route add 213.7.50.126/32 dev eth1 src 213.7.50.121
table uplink2
post-up ip route add default via 213.7.50.126 table uplink2
post-up ip rule add from 213.7.50.121 table uplink2
post-down ip rule del from 213.7.50.121 table uplink2



при такой маске сети (/29) хост 213.7.50.126 и так считается 
непосредственно подключенным к eth1, роут на него писать не нужно 
(возможно, из-за этого не резолвится mac через arp).


Еще можно посмотреть arp-таблицу, если 213.7.50.126 так и не запингуется.

--
Elena Egorova


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Маршрутизация через несколь ких провайдеров

2009-04-21 Пенетрантность Alex Petrov

Здравствуйте, уважаемые специалисты.

Столкнулся с сабжевой проблемой. До недавнего времени было у меня 2
провайдера, настроена маршрутизация, чтобы пакет с определенным
адресом источника маршрутизировался через соответствующий интерфейс,
все работало. Понадобилось поменять одного из них. Пошел по пути
наименьших проблем: добавил еще сетевую карту, решил временно с тем,
что есть сделать 3-й внешний интерфейс. Настроил интерфейс, все
прописано, вроде бы ничего не упустил.
Но работает только через основного провайдера. Если меняю маршрут по
умолчанию на шлюзы других - Destination Host Unreachable. Подскажите
куда ткнуться, запутался. От uplink2 имеется подсеть адресов. На
соседнем сервере все работает, т.е. проблем с линком и роутином нет.
На том сервере где я пытаюсь настроить - не могу добиться работы.

/etc/iproute2/rt_tables:

#
# reserved values
#
255 local
254 main
253 default
0   unspec
#
# local
#
#1  inr.ruhep
200 uplink2
201 uplink1
202 uplink3

/etc/network/interfaces:

auto lo
iface lo inet loopback

# The primary network interface
auto eth0 eth0:0 eth1 eth3
iface eth0 inet static
address 192.168.203.224
netmask 255.255.255.0
network 192.168.203.0
broadcast 192.168.203.255

iface eth0:0 inet static
address 192.168.5.224
netmask 255.255.255.0
network 192.168.5.0
broadcast 192.168.5.255

## uplink2
iface eth1 inet static
address 213.7.50.121
netmask 255.255.255.248
post-up ip route add 213.7.50.126/32 dev eth1 src 213.7.50.121
table uplink2
post-up ip route add default via 213.7.50.126 table uplink2
post-up ip rule add from 213.7.50.121 table uplink2
post-down ip rule del from 213.7.50.121 table uplink2

## uplink1
iface eth2 inet static
address 212.3.45.162
netmask 255.255.255.224

## uplink3
iface eth3 inet static
address 81.16.15.130
netmask 255.255.255.248
post-up ip route add 81.16.15.134/32 dev eth3 src 81.16.15.130
table uplink3
post-up ip route add default via 81.16.15.134 table uplink3
post-up ip rule add from 81.16.15.130 table uplink3
post-down ip rule del from 81.16.15.130 table uplink3

auto dsl-provider
iface dsl-provider inet ppp
 provider dsl-provider
# please do not modify the following line
 pre-up /sbin/ifconfig eth2 up # line maintained by pppoeconf
 post-up ip rule add from 212.3.45.162 table uplink1
 post-down ip rule del from 212.3.45.162 table uplink1

ip rule:

0:  from all lookup 255
32762:  from 81.16.15.130 lookup uplink3
32763:  from 212.3.45.162 lookup uplink1
32765:  from 213.7.50.121 lookup uplink2
32766:  from all lookup main
32767:  from all lookup default

ip neigh show

показывает
213.7.50.126 dev eth1  INCOMPLETE
Это шлюз провайдера.

Подскажите, куда смотреть.


-- 
С уважением, Алексей

Статическая маршрутизация

 если юзается up, то хорошо и симметричный
 down писать
 
 зачем?
 маршруты и так удалятся при опускании
 интерфейса.
 если не делать down, то толи network reload толи
 network restart будет
 глючить, не помню точно
 network restart глючит. ifdown спасает.
дык если симметричный up'у down прописать то ничего глючить не будет
почему бы не прописать?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Статическая маршрутизация

2007-10-03 Пенетрантность Artem Chuprina

Шестаков Николай - debian-russian  @ Wed, 03 Oct 2007 14:08:46 +0600:

 ШН Подскажите, пожалуйста, где правильно прописывать статические
 ШН маршруты подымаемые при загрузке системы.

В /etc/network/interfaces

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

Нажатие на кнопку Запомнить пароль не поможет ВАМ запомнить пароль.
http://bash.org.ru/quote.php?num=101483


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Статическая маршрутизация

2007-10-03 Пенетрантность Dmitry E. Oboukhov

 Подскажите, пожалуйста, где правильно
 прописывать статические маршруты
 подымаемые при загрузке системы.
/etc/network/interfaces

в опцияз gateway или up

если юзается up, то хорошо и симметричный down писать


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Статическая маршрутизация

2007-10-03 Пенетрантность Dmitry E. Oboukhov

 Подскажите, пожалуйста, где правильно
 прописывать статические маршруты
 подымаемые при загрузке системы.
 
 /etc/network/interfaces
 
 в опцияз gateway или up
 
 если юзается up, то хорошо и симметричный
 down писать

 зачем?
 маршруты и так удалятся при опускании
 интерфейса.
если не делать down, то толи network reload толи network restart будет
глючить, не помню точно


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: маршрутизация по пор ту назначения + stateful nat

2007-04-19 Пенетрантность Vladi Lemurov



А точно NAT у вас делается средствами iproute?


да, не средствами iproute.  Делается так:
1. все пиринговые сети идут через ppp0 (командой route add)
	2. default gateway делаем спутниковое vpn соединение (тоже командой 
route)


а маршрутизацию по порту назначения добавляем с пом. iproute


Скорее всего, мешает пакетам вернуться включенный rp_filter, т.к. его
интеллектуальные возможности весьма ограничены, поэтому его стоит
отключать в случаях, когда в таблицах маршрутизации более одного шлюза
по умолчанию.
В /etc/sysctl.conf: net.ipv4.conf.default.rp_filter=0




Спасибо, помогло!


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: маршрутизация по п орту назначения + stateful nat

2007-04-19 Пенетрантность Alexey Zbinyakov

На Wed, 18 Apr 2007 13:39:12 +0700
Vladi Lemurov [EMAIL PROTECTED] записано:


VL 
VL 2. Маршрутизировать по портам назначения. Филиал сообщает
VL нам айпи, мы забиваем его в radmin и цепляемся (порт
VL одинаковый, для всех, поэтому не нужно каждый раз цепляться
VL к линуксу и добавлять маршрут). Порывшись в интернете,
VL нашли доку по iproute2, там такое есть. Помечаем пакеты в
VL iptables (mangle), потом добавляем правило, которое будет
VL ловить эти пакеты и заворачивать на определенную цепочку.
VL Сделано так: ip rule add fwmark 4899 table dsl-link
VL (таблица dsl-link создана ранее) ip route add default via
VL ip нашего наземного соединения ppp0 dev ppp0 table
VL dsl-link
Попробуй порыть в сторону CONNMARK, должно помочь, там есть две функции которые 
преобразуют CONNMARK в fwmark и наоборот. 
-- 
Alexey Zbinyakov
Technical Support Engineer
USONyX.NET.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

маршрутизация по порту назначения + stateful nat

2007-04-18 Пенетрантность Vladi Lemurov

День добрый!

Вопрос такой - можно ли в зависимости от порта назначения направлять
пакеты через различные интерфейсы и nat'ить stateful на обоих?

Вот более развернутая ситуация :)

Есть локальная сеть и шлюз с маршрутом по умолчанию (через тоннель
спутникового провайдера). Есть филиалы (в другиих городах и областях) с
установленным radmin. Если нужно к ним цепляться - добавляется маршрут
(через наземный канал, т.к. он более быстрый, а трафик интерактивный) и
всё работает. Для некоторых областей удалось установить статический ip
адрес, для некоторых смогли выяснить диапазоны адресов модемных пулов. А
для некоторых - не удалось ни того ни другого. В таких случаях филиалы
сообщают нам айпи по интернету, мы прописываем маршрут и работаем. Очень
неудобно получается. Выхода пока видится 2:
1. установить на клиентских машинах vpn. Они цепляются к нам, получают
статический айпи и мы к ним заходим радмином. Неплохое решение, сервак
openvpn уже поднят :) Одна загвоздка - не удалось запустить openvpn под
обычным пользователем (не администратором), т.к. windows не позволяет
добавить маршруты под пользователем. Может и можно обойти, но пока затею
бросили, появился вариант №2.

2. Маршрутизировать по портам назначения. Филиал сообщает нам айпи, мы
забиваем его в radmin и цепляемся (порт одинаковый, для всех, поэтому не
нужно каждый раз цепляться к линуксу и добавлять маршрут).
Порывшись в интернете, нашли доку по iproute2, там такое есть.
Помечаем пакеты в iptables (mangle), потом добавляем правило, которое
будет ловить эти пакеты и заворачивать на определенную цепочку. Сделано так:
ip rule add fwmark 4899 table dsl-link (таблица dsl-link создана ранее)
ip route add default via ip нашего наземного соединения ppp0 dev ppp0
table dsl-link

все добавляется. Начинаем цепляться (с машины внутри сети, за шлюзом),
пакеты идут в филиал как надо, т.е. не через спутниковый тоннель, а по
наземке, через ppp0. От филиала пакеты возвращаются обратно, но внутрь
сети не проходят. Получается они не проходят через нат. Начал рыть,
выходит, что с пом. iproute2 можно сделать только stateless nat.
Выходит, цепляться можно будет только с одной машины в сети, а это очень
неудобно, т.к. доступ нужен то админу, то одному из программистов.
Подскажите пожалуйста, как можно решить проблему?
Владимир.

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

маршрутизация по порту назначения + stateful nat

2007-04-18 Пенетрантность Vladi Lemurov

День добрый!

Вот более развернутая ситуация :)

Порывшись в интернете, нашли доку по iproute2, там такое есть.
Помечаем пакеты в iptables (mangle), потом добавляем правило, которое
будет ловить эти пакеты и заворачивать на определенную цепочку. Сделано так:

ip rule add fwmark 4899 table dsl-link (таблица dsl-link создана ранее)
ip route add default via ip нашего наземного соединения ppp0 dev ppp0
table dsl-link

Владимир.

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: маршрутизация по по рту назначения + stateful nat

2007-04-18 Пенетрантность Alexey Trunyov

On Wed, 18 Apr 2007 13:39:12 +0700
Vladi Lemurov [EMAIL PROTECTED] wrote:

Да.

А точно NAT у вас делается средствами iproute?

Скорее всего, мешает пакетам вернуться включенный rp_filter, т.к. его
интеллектуальные возможности весьма ограничены, поэтому его стоит
отключать в случаях, когда в таблицах маршрутизации более одного шлюза
по умолчанию.
В /etc/sysctl.conf: net.ipv4.conf.default.rp_filter=0

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

простая маршрутизация

2006-08-30 Пенетрантность Timur Elzhov

Привет!

Простая вроде задача, но туплю ужасно :(

Имеется мини-свич, подключенный к инету, с внутренним адресом
192.168.0.1/8  Еще имеется сервер с двумя сетевухами и установленным
Debian Sarge. Имеется несколько PC-шек. Нужно все PC-шки подключить
к свичу *через этот сервер* с Дебианом. Соединяем сервер с мини-свичом
через первую сетевую карту, во вторую карту втыкаем большой свич со всеми
PC-шками.

Чего только не делал с таблицей маршрутов, и 7-битную маску выставлял,
и 8-битную - все равно ничего не выходит. ip_forward включал. Может
кто-нибудь подсказать, как сконфигурить сеть? Лучше, думаю, не через
DHCP, а статически. Чувствую, что все тривиально должно быть, а вожусь
уже не первый день. Я не админ ни разу, просто прогаю в Линуксе :-/

Большое спасибо!


-- 
Best regards,
Timur Elzhov
Warelex LLC


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: простая маршрутизация

2006-08-30 Пенетрантность Nikolay

В сообщении от Среда 30 августа 2006 19:07 Timur Elzhov написал(a):
 On Wed, Aug 30, 2006 at 03:14:04PM +0400, Олег Анисимов wrote:
  1-е Маски /8 для сети 192.168.0.0 быть не может.
  максимум /16 а вообще-то /24.

   ^
 Это пять :-) Вообще, если я правильно понимаю, адрес сети с последнми
 16 нулевыми битами может свободно означать сетку с маской от 1 до 16
 бит. У нас 8. И как может быть 24, кстати, если второй старший байт
 ненулевой?


ip/16 означает что в маске 16 едениц в начале, а не 16 нулей в конце

Re: простая маршрутизация

2006-08-30 Пенетрантность Artem Chuprina

Timur Elzhov - debian-russian@lists.debian.org @ Wed, 30 Aug 2006 17:07:36
+0400:

3-е все, что надо сделать - воткнуть во вторую карту коммутатор с РС-шками
и сделать NAT или MASQUERADE при помощи iptables на сервере.

TE То есть любой маршрутизатор - это обязательно трансляция адресов?

Не любой. Но тут каков вопрос - таков ответ. Есть два варианта - либо
на втором интерфейсе ты делаешь другую сеть и в интернет пускаешь
NAT'ом, либо на втором интерфейсе ты делаешь ту же самую сеть и
обеспечиваешь ее всю proxy arp'ом точка нафиг. Теоретически три, но
практически, как я подозреваю, твой свитч не умеет собственных таблиц
маршрутизации. NAT, в общем, получается дешевле.

TE В принципе нам 255 (или сколько там позволительно) хватило бы за
TE глаза. И даже вдвое меньше (с 7-битной маской) - тоже хватило
TE бы. Просто не очень понятно, почему без нее (трансляции) нельзя.

А почему можно - понятно? А объяснить сможешь?

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

Ходячая энциклопедия - это девушка, которая пытается многознанием
компенсировать отсутствие мыслительных навыков (С)энта

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: простая маршрутизация

2006-08-30 Пенетрантность Artem Chuprina

Alexey Lobanov - debian-russian@lists.debian.org @ Wed, 30 Aug 2006 18:15:43
+0400:

Private сети в нормальные могут попадать только через NAT.

AL ...но при правильной организации корпоративного (или кооперативного :-)
AL межсетевого экрана это попадалово нафиг не надо. Поскольку в Интернет
AL (нормальные сети) должны уходить не соединения от внутренних машин, а
AL протоколы более высокого уровня, прошедшие через прикладные прокси на
AL гейт-сервере.

Ага, SSL и SSH, например... Больше тому гейт-серверу делать нечего, как
с одной стороны на другую шифрованные пакетики перекладывать... Ядро,
типа, само не справляется...

По нешифрованному соединению с моей рабочей машины в инет и обратно
ходит дай бог если треть трафика. HTTP и anonymous FTP. Да, ее,
конечно, можно завернуть через сквида, и даже не бессмысленно будет. Но
остальным двум третям на более высоком уровне делать отчетливо нечего.

--
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

А вы поподробнее, поподробнее. А заодно и быстрее будет...

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: простая маршрутизация

2006-08-30 Пенетрантность Mikhail A Antonov

On Wednesday 30 August 2006 18:43 Artem Chuprina wrote:
 Ага, SSL и SSH, например...  Больше тому гейт-серверу делать нечего, как
 с одной стороны на другую шифрованные пакетики перекладывать...  Ядро,
 типа, само не справляется...
 
Думаю речь шла о gre, можно даже без шифрования.
ИМХО, через него правильнее объединять офисные локалки
(ненормальные сети без реальных IP-адресов.)

-- 
Best regards,
 Mikhail
Bart-mdv- @ SolarNet
IRC: irc.solarnet.ru
WWW: http://www.solarnet.ru/

--
Сделать компьютер значительно проще и дешевле, чем заставить его что-то делать.

Re: простая маршрутизация

2006-08-30 Пенетрантность abraham shapirus

On Wed, 30 Aug 2006, Timur Elzhov wrote:

TE  Медленно и печально идем вкуривать что такое Организация подсетей
TE  Хотя бы сюда 
http://www.opennet.ru/docs/HOWTO-RU/mini/IP-Subnetworking.html
TE 
TE Ну. Там в конце секции 3.3:
TE 
TE   Имеются также специальные адреса, которые зарезервированы для 
'несвязанных'
TE   сетей - которые является сетями, использующими IP, но не связаны с 
Internet,
TE   Эти адреса:
TE 
TE * Одна сеть класса A 10.0.0.0
TE * 16 сетей класса B 172.16.0.0 - 172.31.0.0
TE * 256 сетей класса C 192.168.0.0 - 192.168.255.0 
TE 
TE Если я не окончательно туп, то /8 означает сеть класса С ...

/8 -- это класс A.

TE  Затем что такое CIDR сюда http://www.opennet.ru/docs/RUS/ip_povest/
TE  После этого чтивища много думаем.
TE 
TE А там:
TE 
TE   Класс  Количество сетей  Количество узлов Десятичный диапазон
TE A2^7 - 2 (126) 2^24 - 2 (2 147 483 648) 1.ххх.ххх.ххх - 
126.ххх.ххх.ххх
TE B2^14 (16 384) 2^16 - 2 (65 534)128.0.ххх.ххх - 
191.255.ххх.ххх
TE C2^21 (2 097 152)  2^8  - 2 (254)   192.0.0.ххх   - 
223.255.255.ххх
TE 
TE то есть наша сеть (192.168.0.0/8) ничему не противоречит. Я опять не прав?
Приватные сети входят в диапазон 192.168.0.0/16. В нем 256 сетей класса
C вида 192.168.x.0/24. А 192.168.0.0/8 захватывает и здоровый кусок
глобальных адресов.

Re: простая маршрутизация

2006-08-30 Пенетрантность Artem Chuprina

Timur Elzhov - debian-russian@lists.debian.org  @ Wed, 30 Aug 2006 19:19:42 
+0400:

  Медленно и печально идем вкуривать что такое Организация подсетей
  Хотя бы сюда http://www.opennet.ru/docs/HOWTO-RU/mini/IP-Subnetworking.html

 TE Ну. Там в конце секции 3.3:

 TE   Имеются также специальные адреса, которые зарезервированы для 
'несвязанных'
 TE   сетей - которые является сетями, использующими IP, но не связаны с 
Internet,
 TE   Эти адреса:

 TE * Одна сеть класса A 10.0.0.0
 TE * 16 сетей класса B 172.16.0.0 - 172.31.0.0
 TE * 256 сетей класса C 192.168.0.0 - 192.168.255.0 

 TE Если я не окончательно туп, то /8 означает сеть класса С ...

Окончательно.  /8 означает сеть класса A.

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

Сильмарил тебе в почки! (c)JB


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: простая маршрутизация

2006-08-30 Пенетрантность Mikhail A Antonov

   Класс  Количество сетей  Количество узлов Десятичный диапазон
 A2^7 - 2 (126) 2^24 - 2 (2 147 483 648) 1.ххх.ххх.ххх - 
 126.ххх.ххх.ххх
 B2^14 (16 384) 2^16 - 2 (65 534)128.0.ххх.ххх - 
 191.255.ххх.ххх
 C2^21 (2 097 152)  2^8  - 2 (254)   192.0.0.ххх   - 
 223.255.255.ххх
 
 то есть наша сеть (192.168.0.0/8) ничему не противоречит. Я опять не прав?
/8 это 255.0.0.0.0
/16 это 255.255.0.0
/24 это 255.255.255.0
поставь ipcalc и посмотри что он скажет на 192.168.0.0/8 по поводу масок
и количества IP-адресов

-- 
Best regards,
 Mikhail
Bart-mdv- @ SolarNet
IRC: irc.solarnet.ru
WWW: http://www.solarnet.ru/

--
Даже y плохого модератора есть свои плюсы...

Re: простая маршрутизация

2006-08-30 Пенетрантность Sergei Stolyarov

On Wednesday 30 August 2006 18:02, Timur Elzhov wrote:
Привет!

Простая вроде задача, но туплю ужасно :(

Имеется мини-свич, подключенный к инету, с внутренним адресом
192.168.0.1/8 Еще имеется сервер с двумя сетевухами и установленным
Debian Sarge. Имеется несколько PC-шек. Нужно все PC-шки подключить
к свичу *через этот сервер* с Дебианом. Соединяем сервер с мини-свичом
через первую сетевую карту, во вторую карту втыкаем большой свич со всеми
PC-шками.

Чего только не делал с таблицей маршрутов, и 7-битную маску выставлял,
и 8-битную - все равно ничего не выходит. ip_forward включал. Может
кто-нибудь подсказать, как сконфигурить сеть? Лучше, думаю, не через
DHCP, а статически. Чувствую, что все тривиально должно быть, а вожусь
уже не первый день. Я не админ ни разу, просто прогаю в Линуксе :-/

Недавно столкнулся с подобной задачей - необходимо было поднять шлюз, на
котором устроить NAT. На машине два интерфейса - внешний eth0 с айпишником,
выданным провайдером, и внутрений eth1 192.168.0.1 с подсетью 255.255.255.0.

Вся настройка свелась исключительно к установке пакета ipmasq, который сделал
ВСЮ нужную работу - включил нужные параметры сети, настроил iptables. И сразу
же стало можно нормально работать.

К внутреннему интерфейсу можно подключить свич/wifi точку доступа и нормально
работать.
--
Sergei Stolyarov

Re: маршрутизация

2006-06-18 Пенетрантность Dmitry E. Oboukhov

  DEO причин зависаний не знаю, но как мне кажется это связано с тем что оба
  DEO интерфейса выходят на один адрес 1.1.1.1. возможно я не прав.
 
 Совершенно не прав.
есть мысли?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: маршрутизация

2006-06-18 Пенетрантность Artem Chuprina

Dmitry E. Oboukhov - debian-russian@lists.debian.org  @ Sun, 18 Jun 2006 
11:18:49 +0400:

   DEO причин зависаний не знаю, но как мне кажется это связано с тем что оба
   DEO интерфейса выходят на один адрес 1.1.1.1. возможно я не прав.
  
  Совершенно не прав.
 DEO есть мысли?

Мысли тебе уже сообщили.  Но даже если бы их не было, это не повод
валить вину на первое попавшееся явление, по недостатку образования
показавшееся тебе странным.

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

русская народная глупость
Кнышев


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: маршрутизация

2006-06-18 Пенетрантность Dmitry E. Oboukhov

DEO причин зависаний не знаю, но как мне кажется это связано с тем что 
 оба
DEO интерфейса выходят на один адрес 1.1.1.1. возможно я не прав.
   
   Совершенно не прав.
  DEO есть мысли?
 
 Мысли тебе уже сообщили.  Но даже если бы их не было, это не повод
 валить вину на первое попавшееся явление, по недостатку образования
 показавшееся тебе странным.
я пробовал выгрузить модули iptables не помогло. других мыслей мне не
сообщали. образования - да, возможно недостаток, мысли есть у тех у кого
его избыток? ;)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: маршрутизация

2006-06-17 Пенетрантность Artem Chuprina

Dmitry E. Oboukhov - debian-russian@lists.debian.org  @ Tue, 13 Jun 2006 
15:17:36 +0400:

 DEO причин зависаний не знаю, но как мне кажется это связано с тем что оба
 DEO интерфейса выходят на один адрес 1.1.1.1. возможно я не прав.

Совершенно не прав.

-- 
Artem Chuprina
RFC2822: ran{}ran.pp.ru Jabber: [EMAIL PROTECTED]

kernel bug (англ.) - ядрёна вошь


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: маршрутизация

2006-06-15 Пенетрантность Dmitry E. Oboukhov

Это подземный стук какой-то. Провайдер тут ни при чём. В любом случае
машина виснуть не должна.
   Может она не виснет, а просто ssh отваливается? ;-)
  я ж говорил что на ноуте пробовал
  полный глухой вис. железной консоли тоже не становится :-\
 Вполне себе нормально. Ядро какое? Какие модуля iptablesов загруженны?
ядра пробовал 2.6.8 и 2.4.27


uvw.ru:[/home/dimka]# lsmod|grep ipt 
ipt_MASQUERADE  3968  20 
ipt_REDIRECT2208  20 
iptable_nat25156  3 ipt_MASQUERADE,ipt_REDIRECT
ipt_state   2080  4 
ip_conntrack   35756  4
ipt_MASQUERADE,ipt_REDIRECT,iptable_nat,ipt_state
iptable_filter  2880  1 
ip_tables  18464  5
ipt_MASQUERADE,ipt_REDIRECT,iptable_nat,ipt_state,iptable_filter


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: маршрутизация

2006-06-15 Пенетрантность Andrey Melnikoff

Dmitry E. Oboukhov [EMAIL PROTECTED] wrote:
 Это подземный стук какой-то. Провайдер тут ни при чём. В любом случае
 машина виснуть не должна.
Может она не виснет, а просто ssh отваливается? ;-)
   я ж говорил что на ноуте пробовал
   полный глухой вис. железной консоли тоже не становится :-\
  Вполне себе нормально. Ядро какое? Какие модуля iptablesов загруженны?
 ядра пробовал 2.6.8 и 2.4.27
Дистрибутивные?

 uvw.ru:[/home/dimka]# lsmod|grep ipt 
 ipt_MASQUERADE  3968  20 
 ipt_REDIRECT2208  20 
 iptable_nat25156  3 ipt_MASQUERADE,ipt_REDIRECT
 ipt_state   2080  4 
 ip_conntrack   35756  4
 ipt_MASQUERADE,ipt_REDIRECT,iptable_nat,ipt_state
 iptable_filter  2880  1 
 ip_tables  18464  5
 ipt_MASQUERADE,ipt_REDIRECT,iptable_nat,ipt_state,iptable_filter

Выгрузи ipt_state и ip_conntrack без них. Я натыкался на такое, на 2.4.x +
gre/pptp хелпер из patch-o-matic. Висло намертво.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: маршрутизация

2006-06-14 Пенетрантность Mihail A Antonov

On Wednesday 14 June 2006 09:38 Slava Astashonok wrote:
 Это подземный стук какой-то. Провайдер тут ни при чём. В любом случае
 машина виснуть не должна.
Может она не виснет, а просто ssh отваливается? ;-)

-- 
Best regards,
 Mihail
Bart-mdv- @ SolarNet
IRC: irc.solarnet.ru
WWW: http://www.solarnet.ru/

--
Йестэрдэй... Ол май траффик симед со фар авэй...

Re: маршрутизация

2006-06-14 Пенетрантность Dmitry E. Oboukhov

  Это подземный стук какой-то. Провайдер тут ни при чём. В любом случае
  машина виснуть не должна.
 Может она не виснет, а просто ssh отваливается? ;-)
я ж говорил что на ноуте пробовал

полный глухой вис. железной консоли тоже не становится :-\


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: маршрутизация

2006-06-14 Пенетрантность Dmitry E. Oboukhov

 Да, пожалуй, это решение.
я ж писал выше
оба ppp подымаю с nodefaultroute а роутинг даже не успеваю покрутить оно
раньше вешается :-\


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: маршрутизация

2006-06-14 Пенетрантность Andrey Melnikoff

Dmitry E. Oboukhov [EMAIL PROTECTED] wrote:
   Это подземный стук какой-то. Провайдер тут ни при чём. В любом случае
   машина виснуть не должна.
  Может она не виснет, а просто ssh отваливается? ;-)
 я ж говорил что на ноуте пробовал
 полный глухой вис. железной консоли тоже не становится :-\
Вполне себе нормально. Ядро какое? Какие модуля iptablesов загруженны?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: маршрутизация

2006-06-13 Пенетрантность Dmitry E. Oboukhov

On 6/13/06, Dmitry E. Oboukhov [EMAIL PROTECTED] wrote:

имеется задачка

провайдер. раздает инет по pptp (ну это довольно типично)

при соединении имеем следующий вид соединения

нам выделяется ip и он соответствует нашему ppp0, а на противоположной
стороне ip всегда один - 1.1.1.1

$ /sbin/ifconfig ppp0
ppp0 Link encap:Point-to-Point Protocol
inet addr:81.9.63.169 P-t-P:1.1.1.1 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:43155145 errors:0 dropped:0 overruns:0 frame:0
TX packets:50099764 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:1907985745 (1.7 GiB) TX bytes:1927428066 (1.7 GiB)

теперь возникает некоторая задачка. хочется получить второй IP от
провайдера. и вывесить на один серверы которые должны работать 24/7 а
через другой роутинг настроить для домашней сетки.

но вот беда (я так думаю! (ц) Мимино), у второго ppp-соединения
удаленный хост будет тоже 1.1.1.1 и не знаю, возможно из за этого,
возможно из за какой-то другой причины, но при поднятии второго
ppp-интерфейса система наглухо зависает, никаких записей в логах не
оставляя, ничего...
причем повторяемость 100%: попробовал я с ноута выйти на два ppp
соединения - та же картинка. по отдельности ppp0 или ppp1 можно поднять,
а вместе - глухой висяк.
кернел 2.6.8, с 2.4.27 тоже пробовал (sarge) другие ядра не испытывал.

с железом полный порядок. до этого сервак работал со 100-200 дневными
аптаймами...
настройка ppp отличается только одной опцией: в одном прописан
defaultroute, а в другом нет. пробовал nodefaultroute в обоих итп - не
помогает.
причин зависаний не знаю, но как мне кажется это связано с тем что оба
интерфейса выходят на один адрес 1.1.1.1. возможно я не прав.

у кого нибудь есть аналогичная описанной конфигурация сети в рабочем
состоянии?

в общем интересуют мысли что можно попробовать/куда поглядеть/чем
порулить...

Два адреса на одном интерфейсе? Тогда правильней будет алиасами, ИМХО.

--
С уважением,
Константин Матюхин

Re: маршрутизация

 Два адреса на одном интерфейсе? Тогда правильней будет алиасами, ИМХО.
не очень понял мысли :)

два интерфейса ppp у которых один и тот же удаленный адрес :D


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: маршрутизация

2006-06-13 Пенетрантность Dmitry E. Oboukhov


два интерфейса ppp у которых один и тот же удаленный адрес :D


--- начало текста для медитации
Point to Point Protocol Point To Point Protocol
Point to Point Protocol Point To Point Protocol
Point to Point Protocol Point To Point Protocol
...
--- конец текста для медитации

--
С уважением,
Константин Матюхин

Re: маршрутизация

2006-06-13 Пенетрантность Sergey


Dmitry E. Oboukhov пишет:

Два адреса на одном интерфейсе? Тогда правильней будет алиасами, ИМХО.


не очень понял мысли :)

два интерфейса ppp у которых один и тот же удаленный адрес :D

  
А что тут смешного. Вот например установке связи по GPRS с мобилы 
(Megafone, Nokia 6021)  присваивается удалённый IP 10.6.6.6.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: маршрутизация

 два интерфейса ppp у которых один и тот же удаленный адрес :D
 
 --- начало текста для медитации
 Point to Point Protocol Point To Point Protocol
 Point to Point Protocol Point To Point Protocol
 Point to Point Protocol Point To Point Protocol
 ...
 --- конец текста для медитации
ага, а конструктивно чего-нидь можно предложить?
понятно что point to point предполагает одну связь, а тут две.
сейчас сдалал примерно следующее:

сервер до провайдера делает один ppp
а второй сервер до него же делает второй
и первый сервер на второй делает еще один ppp

но так как второй сервак в общем-то не сервак, то сие временное
:-\


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: маршрутизация


ага, а конструктивно чего-нидь можно предложить?

а что тут предложишь? по условиям задачи провайдер предоставляет
только PPP


понятно что point to point предполагает одну связь, а тут две.

а две - это уже не PPP, это что-то другое

--
С уважением,
Константин Матюхин

Re: маршрутизация