|
| 1.4, Leap42 (?), 13:14, 16/11/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
так и не понял за всей этой мишурой маркетингового булщита, чем оно лучше ospf и isis
| | |
| 1.13, zanswer CCNA RS and S (?), 15:00, 16/11/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Не очень понятно, как именно позиционируется данный новый протокол?! Придумать более расширяемого протокола динамической маршрутизации чем ISO IS-IS сложно, да и не ясно зачем? К тому же для тех, кому не нравится IS-IS с его OSI специфичными частями, есть не менее прекрасный IETF OSPFv2/OSPFv3.
| | |
| |
| 2.19, Аноним (19), 18:02, 16/11/2017 [^] [^^] [^^^] [ответить]
| +/– |
 1)написано что оно умеет еще и пропускную способность как то мониторить.
2)имхо удобно для бэкенда что бы не только сеть, но и аппликейшн/дб связки контролировать
| | |
| |
| 3.21, McLoud (??), 20:39, 16/11/2017 [^] [^^] [^^^] [ответить]
| +/– |
Так это давно уже все придумано, как бы трафик инжениринг бы работал. OSPF lsa type 10. Для ISIS тоже есть LSP.
| | |
| |
| 4.39, zanswer CCNA RS and S (?), 11:22, 17/11/2017 [^] [^^] [^^^] [ответить]
| +/– | |
Хотя многие источники ставят знак равенства между LSA=LSP, а ряд так же между LSU=LSP, ссылаясь на то, что хотя LSA используют собственные заголовки, а TLV один общий, тем не менее, они выполняют схожую операцию, объявление о топологии, префиксах, соседях и так далее.
Но, тем не менее, ISO/IEC 10589-2002 даёт такое определение LSP:
"LSP - Link State Protocol Data Unit"
А RFC 1195: Use of OSI IS-IS for Routing in TCP/IP and Dual Environments такое:
"LSP - Link State Packet (a type of packet used by the IS-IS protocol)"
И при этом RFC 2328: OSPF Version 2 такое:
"A.3.5 The Link State Update packet
Link State Update packets are OSPF packet type 4. These packets
implement the flooding of LSAs. Each Link State Update packet
carries a collection of LSAs one hop further from their origin.
Several LSAs may be included in a single packet."
Но, с другой стороны, соавтор ряда RFC по IS-IS Manav Bhatia, тоже сравнивает LSP с LSA, в контексте объявления состояния каналов, но при этом же указывает, что LSP сравним с LSU в контексте передачи самих пакетов через сеть.
Поэтому я внесу коррективу в сказанное мною выше, что я не исправляю вас, а дополняю, поскольку в данном случае, LSP можно рассматривать и в рамках LSA, и в рамках LSU в зависимости от точки обзора.
| | |
|
| 3.22, McLoud (??), 20:39, 16/11/2017 [^] [^^] [^^^] [ответить]
| +/– |
Так это давно уже все придумано, как бы трафик инжениринг бы работал. OSPF lsa type 10. Для ISIS тоже есть LSP.
| | |
|
| 2.20, пох (?), 20:23, 16/11/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
забавно что чувак, гордо пихающий в юзернейм свой "ccna", не понимает совершеннейшей омерзительности что мертворожденного osi-проекта и его единственного искусственно-оживленного выкидыша isis, что, тем более, ospf, придуманного ради копеечной экономии, когда лишние 64k памяти в роутер было очень-очень дорого.
Нет, я понимаю, до книжек где рассказывают, зачем (и как) в _локальных_ сетях используют bgp с кучей костыликов и подпорочек (ибо совершенно он не задумывался для них) ты еще не дорос, это и ccnp затрагивают-то только по верхам, но про eigrp-то тебя должны были заставить прочитать, или как ты умудрился свой RS сдать (S понятно, авторы asa его ниасилили, впрочем, они и ospf-то ниочень)?
В этих агитках, конечно, правды только половина, но все, что написано про недостатки альтернативных решений - правда.
| | |
| |
| 3.23, McLoud (??), 20:43, 16/11/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
У ISIS есть свои плюсы, ознакомьтесь с предметом. Если циска его не освещала раньше это означает только о заблуждениях циски. Сейчас в треке RS он есть
| | |
| |
| 4.34, zanswer CCNA RS and S (?), 08:23, 17/11/2017 [^] [^^] [^^^] [ответить]
| +/– | |
Cisco является одним из контрибютеров в IS-IS и одной из первых кто реализовал его в своих маршрутизаторах, к тому же IS-IS, всегда был в SP треке, да и в RS треке тоже, кроме CCNA RS.
Да и вообще Cisco например рекомендует использовать именно IS-IS в рамках SD-Access к примеру, ага прямо в корпоративном секторе, и прямо вместе с SDN.
Поэтому Cisco прекрасно осведомлена о преимуществах IS-IS и всячески его рекомендует, просто в корпоративном секторе он не особо популярен по объективным причинам.
| | |
|
| 3.30, leap42 (ok), 03:12, 17/11/2017 [^] [^^] [^^^] [ответить]
| +/– |
 > ospf, придуманного ради копеечной экономии
лол-кек-чебурек: ospf держит в памяти всю зону (а то и несколько зон), какой большой она не будь, и жрёт гораздо больше главного конкурента eigrp, который держит только соседей (вот он экономит память, да)
ps: is-is няшка
| | |
| |
| 4.33, zanswer CCNA RS and S (?), 08:13, 17/11/2017 [^] [^^] [^^^] [ответить]
| +/– |
>> ospf, придуманного ради копеечной экономии
> лол-кек-чебурек: ospf держит в памяти всю зону (а то и несколько зон),
> какой большой она не будь, и жрёт гораздо больше главного конкурента
> eigrp, который держит только соседей (вот он экономит память, да)
> ps: is-is няшка
Не согласен с вами, что главный конкурент OSPF это EIGRP, хотя смотря конечно в каком сегменте, если корпоративном сегменте, то согласен с вами, а если в ISP/TELCO, то там IS-IS, вечный, заклятый враг OSPF.
И если скажем, OSPFv2 имел объективные недостатки, по отношению к IS-IS, например в виде LSA type 1/2 содержащих и информацию о топологии, и информацию о префиксах, что приводило к тому, что в SPF дереве префиксы были представлены узлами, а не листьями, как у IS-IS, что автоматически ставило крест на Incremental SPF в большинстве случаев, то в OSPFv3 IETF исправила эти недостатки.
Правда и IS-IS не стоит на месте, у него тоже были проблемы в прошлом, к примеру с количество point-to-point интерфейсов, точнее с тем, сколько интерфейсов может быть описано в TLV и опять же благодаря усилиям IETF данную проблему исправили. Или например проблема с two-way handshake для point-to-point Hello, которую благодаря опять же IETF исправили, заменив на three-way handshake всё для того же P-t-P Hello, решив такую проблему, как не консистентное состояние LSDB при потери части LSP пакетов во время синхронизации. При этом полный reflooding мог произойти только через 18 часов, максимальное время жизни LSP. И IETF исправила данную проблему, вообще говоря оба протокола сейчас развиваются под крылом IETF, каждый в рамках своей WG.
| | |
| 4.42, пох (?), 16:41, 17/11/2017 [^] [^^] [^^^] [ответить]
| +/– | |
> и жрёт гораздо больше главного конкурента eigrp
ну так нашел с чем сравнивать. "у протокола ipx только один недостаток - он принадлежит фирме novell" (c)ранний MS.
igrp (из которого потом вышел eigrp) писали тоже во времена острой нужды в байтиках (а вот процессоры у циски уже были получше). Но он не только память экономит, он еще много чего хорошего делает, что и сегодня актуально. Если не лезть в mpls, конечно, для которого по тем самым причинам и непригоден.
Недостаток один, но совершенно фатальный - принадлежит не той фирме. Поэтому умирает, и скоро умрет совсем. Товарищу, любителю заковыристых аббревиатур, предлагалось не про сам eigrp почитать, а про то, чего ради его пришлось изобретать при уже поддерживаемом всеми распрекрасном isis - оно там в учебниках для юных падаванов вполне понятными буквами разжевывается.
| | |
| |
| 5.59, zanswer CCNA RS and S (?), 10:35, 18/11/2017 [^] [^^] [^^^] [ответить]
| +/– | |
Любитель заковыристых аббревиатур, должен сказать, что IS-IS впервые был представлен в IOS в 1993 году, тогда же, когда и EIGRP, то есть в один год. RFC 1195: Use of OSI IS-IS for Routing in TCP/IP and Dual Environments, было представлено в 1990 году.
Основная цель реализации EIGRP по отношению к IGRP был переход на без классовую маршрутизацию, CIDR, - classless interdomain routing, представленный всё в том же 1993 году. IGRP поддерживал только классовую маршрутизацию, как и RIPv1, что потребовало его переориентации, а после вышел ещё и EIGRP for IPv6. А всё потому, что в отличие от IS-IS, OSPF, RIP, EIGRP, требуют переориентации для каждого нового протокола, в той или иной степени, даже, если это просто новая версия IP протокол, а не скажем Shortest Path Bridging какой-нибудь.
Я с радостью послушаю вашу точку зрения или ту, что изложена в тех книгах, что вы читали, по какой причине появился EIGRP, при имеющемся IGRP и отсутствующем у Cisco IS-IS до 1993 года, вообще.
| | |
|
|
| 3.32, zanswer CCNA RS and S (?), 08:00, 17/11/2017 [^] [^^] [^^^] [ответить]
| +/– | |
Даже не знаю, что и сказать, EIGRP дистанционно-векторный протокол и памяти, как и ресурсов CPU он потребляет меньше, чем OSPF, который является протоколом с отслеживанием состояния-каналов, а значит должен хранить информацию о топологии всей сети, в отличие от EIGRP, который хранит информацию о топологии только смежных маршрутизаторов.
IS-IS является наиболее широко используемым generic протоколом, кроме IGP в сетях провайдеров, как основа для MPLS, он ещё и используется в Control Plane таких протоколов, как TRILL, SPB, FSPF. Что не умоляет достоинств OSPF, который в ряде случаев может быть более предпочтительным, например ATM/FR, DMVPN, хотя в последнем EIGRP и лучше подходит.
Что же касается BGP, то в качестве IGP протокола, никто iBGP не использует, по крайней мере я такого ещё не слышал. MPLS L3VPN, BGP TE, Multicast BGP, да, но, как замена IGP протоколам, таким, как OSPF/IS-IS это что-то новенькое. Или может быть вы из тех, кто используется eBGP с private AS внутри внутри одной AS, чтобы избавиться от требования наличия full-mesh для iBGP или использования route reflector/confederation?
P/S/ Сдал оба экзамена на уровне ~930 баллов, менее чем за час из отведённых 90 минут. Про ваши достижения не спрашиваю, мне не интересно это в контексте обсуждения протоколов динамической маршрутизации.
| | |
| |
| 4.36, Leap42 (?), 09:24, 17/11/2017 [^] [^^] [^^^] [ответить]
| +/– | |
> никто iBGP не использует
вы у себя в дефолт ситях не видели, что местечковые russia-телекомы творят: мне как-то от них досталось ~100 SRXов и на каждом был ibgp с редистрибуцией в ospf (сетка простая, одного ospf хватило за глаза, зачем ребята вообще тащили bgp в простенький VPN так и осталось загадкой). разбираться со всем этим делом я не стал и просто сменил работу.
| | |
| |
| 5.37, zanswer CCNA RS and S (?), 09:29, 17/11/2017 [^] [^^] [^^^] [ответить]
| +/– | |
Я живу в маленьком Сибирском городке, какие там дефолт сити. :)
Что касается наличия iBGP с перераспределением маршрутов в OSPF, на каждом маршрутизаторе, это и правда выглядит странно. Интересно было бы узнать, какие цели преследовали авторы, данного решения, но похоже увы.
| | |
| |
| 6.46, пох (?), 17:17, 17/11/2017 [^] [^^] [^^^] [ответить]
| +/– |
> Что касается наличия iBGP с перераспределением маршрутов в OSPF, на каждом маршрутизаторе,
> это и правда выглядит странно. Интересно было бы узнать, какие цели
> преследовали авторы, данного решения, но похоже увы.
я тебе неглядя расскажу, какие - bgp для фильтрации, ospf - для сходимости (bfd у них либо не поддерживается, либо не работает, либо они до этой страницы еще не дочитали)
это совершенно типичное решение для ситуации, когда уперлись в родовые травмы ospf, а eigrp как раз ниасилен, потому что не циска или учились не по той книжке и начитались вредных агиток.
i - потому что bgp где-то еще и внешний тоже есть, mpls опять же ниасилен, не поддерживается или не работает, как и vrf-lite, чаще всего еще и использует белую райповсккую AS, одну на всех.
фильтрация, ну конечно же, будет сделана аксесс-листами, в лучшем случае - префиксами.
Если тебе в такой сети дан карт-бланш на изменения - привести в порядок можно за пару дней. Если ты младший падаван, то да, только валить нахрен оттуда. Потому что ты и будешь тем неудачником, который полезет по _всем_ железкам добавлять новую строчку в эти acl, смотри ничего не пропусти и не опечатайся.
| | |
| |
| 7.57, zanswer CCNA RS and S (?), 08:25, 18/11/2017 [^] [^^] [^^^] [ответить]
| +/– | |
Как у вас получилось сравнить BFD и OSPF в рамках механизма обеспечивающего быструю сходимость всей сети?
Bidirectional Forwarding Detection протокол не может заменить IGP, поскольку кроме факта sub-second обнаружения сбоя соседа, он нечего больше предложить не может.
BGP протокол от этого не станет сходиться быстрее, хоть с BFD, хоть без него, по отношению к любому IGP, кроме RIP конечно.
P/S/ Единственное, что мне не нравится в беседах с вами, ваша мания величия. Вы так пренебрежительно говорите о других, будто вы по меньшей мере автор десятка RFC или CCAr, а вокруг одни неучи. Это вас совершенно не красит.
| | |
| 7.60, t28 (?), 14:19, 18/11/2017 [^] [^^] [^^^] [ответить]
| +/– | |
> привести в порядок можно за пару дней
Напоминает влажные мячты нашего руководства.
Обычно после заявлений вроде: "Это можно сделать за 15 минут" сервисы подымать приходится минимум месяц, а из клиентов делать дураков. Особенно тяжко приходится в такие периоды support'у…
| | |
|
|
| 5.44, пох (?), 17:04, 17/11/2017 [^] [^^] [^^^] [ответить]
| +/– | |
> вы у себя в дефолт ситях не видели, что местечковые russia-телекомы творят:
скорее всего - скопипастили с чьей-то mpls-сетки, не вникая в детали (иначе был бы eBGP).
> ibgp с редистрибуцией в ospf (сетка простая, одного ospf хватило за
> глаза, зачем ребята вообще тащили bgp в простенький VPN так и
затем, что в нем есть фильтрация. И нет совершенно идиотской проблемы с multiarea, которая у циски решается избранными железками и тоже через задницу, нестандартным расширением, а все остальные городят паразитные петли. Или вовсе живут в одной area0 - ни фильтров, ни хотя бы агрегатов.
Где-нибудь на другом конце города один унылый юзер к концентратору подключился - анонс его ценнейшей /32 побежал по тысчонке устройств. Ну или применительно к мордокниге - свитчнулась нагрузка на хост, анонсирующий свой сервис таким образом - с тем же результатом.
Вот такое - действительно лечению не поддается. А банальная схема, позаимствованная у кого-то побольше, хоть и без понимания, для чего придумана - вполне.
> осталось загадкой). разбираться со всем этим делом я не стал и
пугливый какой. было б с чем разбираться-то...
RP/0/RSP0/CPU0#sh run router ospf | utility wc -l
72
RP/0/RSP0/CPU0#sh run router isis | utility wc -l
182
(это не дефолт-сити, ма-а-а-ахонькая сеточка)
| | |
|
|
| 3.35, zanswer CCNA RS and S (?), 08:26, 17/11/2017 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
> выкидыша isis, что, тем более, ospf, придуманного ради копеечной экономии, когда
> лишние 64k памяти в роутер было очень-очень дорого.
> Нет, я понимаю, до книжек где рассказывают, зачем (и как) в _локальных_
> сетях используют bgp с кучей костыликов и подпорочек (ибо совершенно он
> не задумывался для них) ты еще не дорос, это и ccnp
> затрагивают-то только по верхам, но про eigrp-то тебя должны были заставить
> прочитать, или как ты умудрился свой RS сдать (S понятно, авторы
> asa его ниасилили, впрочем, они и ospf-то ниочень)?
> В этих агитках, конечно, правды только половина, но все, что написано про
> недостатки альтернативных решений - правда.
И ещё забыл добавить, конечно же ASA поддерживает EIGRP и OSPF, в полном объёме, как и BGP.
| | |
| |
| 4.49, пох (?), 17:39, 17/11/2017 [^] [^^] [^^^] [ответить]
| +/– |
> И ещё забыл добавить, конечно же ASA поддерживает EIGRP и OSPF, в
> полном объёме, как и BGP.
в полном объеме - три хаха. Попробуй его совместить с асиным vpn (в обоих вариантах, там один смешнее другого) и удивись результату. Потом не будешь удивляться, когда увидишь асу, используемую только для шифрования туннелей, проброшенных сквозь нее с более вменяемых коробок.
а eigrp там добавили, помнится, в аж девятой, что-ли, версии, и такой, что пользоваться им вообще невозможно.
| | |
| |
| 5.50, zanswer CCNA RS and S (?), 18:18, 17/11/2017 [^] [^^] [^^^] [ответить]
| +/– |
EIGRP появился в ASA 7, относительно маршрутизации через VPN, то если подробнее напишите, что через что сделать, то попробую, почему бы и нет.
| | |
| |
| 6.52, пох (?), 19:51, 17/11/2017 [^] [^^] [^^^] [ответить]
| +/– | |
две совершенно типичнейшие (в жизни, а не в учебниках ccna) задачи (обычно нерешаемые в рамках одной асы в принципе ;)
- site2site ipsec. оба сайта неплоские, или просто большие, статика не катит
в случае единственного пира ты решишь эту проблему за счет ручного указания его адреса. Если их два через один интерфейс- опа, приехали, эти настройки у нас на интерфейсах.
- dynamic ipsec (та гадина за натом и статический туннель строить вообще не на чем)
во что оно превращается, если еще и пытаться использовать асу как файрвол (вдруг кто-то с дуба рухнул ;) - отдельная история.
| | |
| |
| 7.55, zanswer CCNA RS and S (?), 08:01, 18/11/2017 [^] [^^] [^^^] [ответить]
| +/– | |
И так, site-to-site VPN, с несколькими пирами, через один физический интерфейс, так?
При этом в туннеле должен быть EIGRP?
С пиром за NAT, очевидно, что инициировать туннель прийдётся второй стороне.
| | |
| |
| 8.63, пох (?), 19:36, 18/11/2017 [^] [^^] [^^^] [ответить] | +/– | при этом должна быть хоть какая-то работающая маршрутизация Полагаю, в реальном... текст свёрнут, показать | | |
|
| 7.58, zanswer CCNA RS and S (?), 09:07, 18/11/2017 [^] [^^] [^^^] [ответить]
| +/– | |
Относительно site-to-site IPSec, не какой проблемы не обнаружил, IPSec VTI реализует поддержку передачи multicast трафика, в том числе и на ASA.
Классический IPSec туннель негде не способен обеспечить передачу multicast пакетов, ввиду чего требуется Unicast neighbor в случае EIGRP и point-to-multipoint neighbor в случае OSPF.
Про случай с NAT, можно сделать стенд, поскольку такая конфигурация в принципе для site-to-site не нормальна, для Remote Access вполне нормальна, да.
А вообще ASA заменяется сейчас активно на Firepower Threat Defense, который в будущем полностью заменит ASA, избавив от необходимости держать ASA и Firepower services раздельно в рамках одного устройства.
| | |
| |
| 8.64, пох (?), 19:47, 18/11/2017 [^] [^^] [^^^] [ответить] | +/– | она не то что нормальна , она скоро станет единственно-возможной Потому что ад... текст свёрнут, показать | | |
|
|
|
|
|
|
|
| |
| 2.54, Аноним (-), 21:40, 17/11/2017 [^] [^^] [^^^] [ответить]
| +/– |
А в cjbdns - dht+свич. Не такое уж плохое комбо, хотя свич переусложненный и билдсистема странная.
| | |
|
| |
| 2.48, пох (?), 17:27, 17/11/2017 [^] [^^] [^^^] [ответить]
| +/– |
>> ... для обмена сообщениями между узлами - шина ZeroMQ.
> вот балбесы.
у пехепешников так принято. Я его слепила из тех модулей что было.
На самом деле - для _этой_ задачи - почему бы и нет. Главное, не оказаться тем неудачником, который будет там искать проблемы.
| | |
|
| 1.31, Аноним (-), 04:55, 17/11/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Я так и не понял на каком оборудовании все это работает. Помоему протоколов для Mesh уже написано уйма, а вот оборудования так и нет.
| | |
| |
| 2.41, zanswer CCNA RS and S (?), 12:22, 17/11/2017 [^] [^^] [^^^] [ответить]
| +/– | |
Судя по новости на Wedge 100, который является Top Of Rack коммутатором, что при этом у них применяется на Spine/Core, вообще не ясно. Сказано, что ещё Arista EOS и Juniper JunOS может использоваться, но, что имеется ввиду, сложно понять из текста новости.
И вообще похоже, что речь идёт о Data Center специфичном протоколе, там где живут TRILL, SPB и прочие, в которых IS-IS основа Control Plane.
| | |
| |
| 3.43, xv (??), 16:49, 17/11/2017 [^] [^^] [^^^] [ответить]
| +/– | |
Вот это применяется на spine/super-spine: https://code.facebook.com/posts/864213503715814/introducing-backpack-our-secon
Плюс какое-то количество вайтбоксов циски-джунипера-аристы-проч.
Никакого ядра нет: https://en.wikipedia.org/wiki/Clos_network
ФБ, как и Гугл, использует SDN во внутренних сетях уже который год, так что традиционные протоколы маршрутизации для них — ненужное легаси, которое разработано не для того, что действительно нужно (минимальные и предсказуемые задержки на постоянно перестраивающейся сети).
Вот, например, как развивалась сеть Гугла: https://www.nextplatform.com/2015/06/19/inside-a-decade-of-google-homegrown-da
| | |
| |
| |
| 5.53, пох (?), 19:53, 17/11/2017 [^] [^^] [^^^] [ответить]
| +/– | |
> Спасибо, почитаю.
будешь читать - обрати внимание, что _внутри_ свитча у них - bgp. А не ospf, хотя, казалось бы, тут-то ему самое место ;-)
| | |
| |
| 6.56, zanswer CCNA RS and S (?), 08:07, 18/11/2017 [^] [^^] [^^^] [ответить]
| +/– |
>> Спасибо, почитаю.
> будешь читать - обрати внимание, что _внутри_ свитча у них - bgp.
> А не ospf, хотя, казалось бы, тут-то ему самое место ;-)
У Facebook кастомное решение, в котором по их мнению iBGP с route reflector это отличная идея.
Почему по-вашему там должен быть именно OSPF?
| | |
| |
| 7.65, пох (?), 19:51, 18/11/2017 [^] [^^] [^^^] [ответить]
| +/– | |
> Почему по-вашему там должен быть именно OSPF?
правильный вопрос - где у нас вообще останется ospf, если даже внутрисвитчевая маршрутизация почему-то "отличная идея" не на нем.
А на протоколе, изначально вообще-то рассчитанном на медленные линки и "подумаешь, потеряем пару тыщ пакетиков, пока сойдется".
| | |
|
|
|
| 4.51, zanswer CCNA RS and S (?), 18:58, 17/11/2017 [^] [^^] [^^^] [ответить]
| +/– | |
Про Google очень интересно было, хоть и мало пригодно для кого-то, кто не Google.
SDN для DC имеют многие вендоры, но в масштабах Google и их специфике наверное никто бы не смог предложить им лучше решения, чем созданной ими самими.
| | |
|
|
| 2.47, пох (?), 17:26, 17/11/2017 [^] [^^] [^^^] [ответить]
| +/– | |
> Я так и не понял на каком оборудовании все это работает.
на своем, мордокнижном-наколеночном.
"зато дешевенькое".
оборудования для sdn как раз полным-полно, но мордокнижка во-первых не хочет за это платить, ей дешевле даже заказное, но из дешевых деталей и без патентов циски/жунипера в комплекте, во-вторых, как раз под ее запросы оно не факт что хорошо подходит.
как кто-то удачно выразился в стертом тредике - это sdn, придуманная php'шниками. Для себя, любимых.
| | |
|
|
