Re: ip u
- From
- Yuri Selivanov (2:5020/400)
- To
- Andre Sidko
- Date
- 2006-02-10T11:16:04Z
- Area
- RU.CISCO
From: Yuri Selivanov <uri@tomsknet.ru>
Andre Sidko <Andre.Sidko@f77.n4641.z2.fidonet.org> wrote:
[snip]
> Хм. Если я на s0/2.98 ввожу ip unnumbered тем самым отказываясь от
> использования ip на подинтерфейсе, то каким образом он будет "знать" куда
> отправляь пакеты? По dlci? А если есть свитчинг и номера не совпадают?
Давай подойдем к проблеме с другой стороны, принцип unnumbered
основан на том, что для передачи ip-трафика через ptp-link вовсе не обязательно
наличие на нем *ip-адресации*, переходя на примитивизмы, у него один выход
и попав в него, у трафика нет другого пути, кроме как попасть на входящий
интерфейс downstream-раутера. Маршрутизация в данном случае, может быть
осуществлена посредством нескольких методов:
- статики непосредственно в интерфейс -- ip route <dest/mask> Serial0/2.98
- динамики -- протоколы маршрутизации нормально понимают unnumbered (ospf,
например, интерпретирует unnumbered-интерфейсы как stub и в type1 lsa
подставляет его соответствующий ifIndex вместо ip-адреса).
http://www.cisco.com/en/US/tech/tk365/technologies_configuration_example09186a00801ec9e0.shtml
- при помощи ppp ipcp (это используется при предоставлении массового
доступа dial-up, pppoe... etc, когда выделение /30 или /31 на каждое
подключение приводит к неэффективному расходу адресного пространства).
Но это не значит, что на интерфейс не надо ставить ip-адрес вообще,
т.к. ios воспринимает отсутствие ip-адреса на интерфейсе, как *неактивность*
этого интерфейса с точки зрения протокола ip, а значит, использовать его
для форвардинга пакетов нельзя. Плюс ко всему, в случае, когда раутер
сам становится источником ip-пакетов (отсылка тех же апдейтов протоколов
маршрутизации, cli telnet/ssh-сессии, cli ping/traceroute) ему необходимо
что-то подставить в поле source address исходящих через этот интерфейс
ip-пакетов. Поэтому, ip unnumbered <iface>, указывает раутеру использовать
в качестве исходящего адреса, адрес с соответствующего интерфейса.
По большому счету, раутеру сугубо фиолетово, с какого интерфейса брать
адрес, но лучше, чтобы он был всегда активен. Поэтому, наиболее логично
под это использовать loopback. Так что все, что необходимо для работы такой
схемы -- это обеспечить доступность интерфейсов, на которые делается
unnumbered с обоих сторон (опять же статика/динамика).
http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a0080094e8d.shtml
P.S. На первый взгляд, схема кажется немного нелогичной и напрашивается
мысль об использовании приватной (rfc1918) адресации, но как уже сказал
Maxim Basunov, это приведет к некрасивой картине traceroute в случае
межпровайдерского прохождения трафика, а также, вероятно, к проблемам с
с быстрым определением узких мест в случае path mtu discovery.
> Registered Linux User #347376
> UIN 21089807
> truly your, Andre.
--
Best Regards,
Yuri Selivanov [URI2-RIPE]
--- ifmail v.2.15dev5.3
* Origin: Tomsktelecom - Digital Networks (2:5020/400)
SEEN-BY: 46/50 50/203 520 400/814 450/159 186 1024 451/30 461/43 640 465/11
SEEN-BY: 469/999 4616/3 4625/8 4626/6 4627/10 4641/444 5000/76 5000 5001/5001
SEEN-BY: 5006/1 5007/1 5010/70 5011/13 5015/28 221 5019/31 5020/175 400 545
SEEN-BY: 5020/639 715 758 830 937 982 1042 1057 1169 1523 1604 1630 1909 1922
SEEN-BY: 5020/2020 2238 4441 5021/3 29 5022/128 5025/3 750 5026/14 45 49
SEEN-BY: 5027/12 5030/49 115 436 473 500 966 1063 1900 5034/13 5036/1 5040/47
SEEN-BY: 5042/13 5045/7 5049/1 36 5051/15 5053/16 5054/1 4 8 9 28 30 35 36 37
SEEN-BY: 5054/67 72 75 81 5057/1 5060/88 5061/15 5062/1 10 5063/3 5066/18
SEEN-BY: 5070/1222 5071/166 5075/5 5077/70 5080/80 1003 5081/2 5082/6 5083/21
SEEN-BY: 5085/13 5090/108 5093/57 5095/20 5096/18 6000/1 12 6001/3 10 6009/1
PATH: 5020/400 4441 545 5054/1 37