Pull to refresh
16
0

Network Professional

Send message
С доставкой прямо до двери!

При потряхивании посылки издавались необычные звуки (супруга распереживалась, что содержимое разбилось — было такое в один из АДМ'ов), но я-то чувствовал, что так и задумано!
Под катом именной (!) супер-пупер-Хабра-бубен, заряженный строго под мои интересы (с подсветкой для ночных танцев), набор вкусняшек (сына едва дождался окончания фотографирования) и в кадр не попала тёплая ламповая открытка :).
Тынц!
image
Большое спасибо, Хабра-Дедушка!

P.S. А ещё дедушка заморочился с поиском моих интересов, т.к. я ни в одном месте не указывал весь набор целиком :).

А можно чуть больше информации по термосу? Я, кажется, захотел себе такой :)

iCTPEJlOK и kafeman

Может уже предлагали такую идею — что если добавить опциональное поле «Мобильный телефон»?

А то при отправке курьерскими службами нужен телефон как при оформлении заказа, так и для отправки смс о готовности посылки или курьеру может потребоваться созвониться с получателем…
Кто не хочет — пусть не заполняет, а я оба раза не указывал (хоть мне и не жалко было) и приходилось потом АДМ'ам досылать через чат, один раз точно у АПП спрашивал, а можно было сразу отправить :).
Хабра-олени подоспели к очередному внуку!

Спасибо Хабра-Дедушке
за новогодний подарок и отдельное спасибо за змея!

Давненько думал над покупкой ламповой книги по Python, а тут такая радость :)
Ура-ура-ура, вот и мой подарочек приехал!

Дедушка раскусил эту вашу (мою?) анонимность в два счёта и прислал чёрную супер-кружку, которая при нагреве проявляет загадочные символы и лого Хабра (с обратной стороны)! Большущее спасибо за столь уникальный подарок!

Кроме того, огромное спасибо дедушке за:
— вкусные конфеты ручной работы;
— гирлянду (супруга как раз ещё одну просила :));
— согревающий ирландский напиток;
— загадочную (во всяком случае для меня) шляпку на зажимах-крокодильчиках;
— холодильный и открыточный приветы из Брянска :).

Так себе фото подарков от АДМ
habra-adm

К моему глубокому огорчению доблестные почтари отделили ручку от кружки :'(. Посоветуйте, пожалуйста, чем (может есть провереный клей?) лучше всего восстановить если не справедливость, то хотя бы ручку?
бит принимает значение «8»
O_o? :-)

Максимальное время жизни сообщения (Max Age) — это поле отвечает, как раз, за максимальное время жизни. Превысив его, коммутатор отбрасывает кадр.
Вот хорошее описание работы данного таймера: http://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/12014-18.html
Оно поможет исправить: "Один из портов коммутатора Switch 3 находится в состоянии Blocking. Вот он слушает BPDU и никого не трогает. Но если вдруг отвалится где-то линк или произойдет изменение топологии, он сразу переходит в состояние Listening или Прослушивание."

Раз Switch 1 становится корневым, то он сразу переводит все свои интерфейсы в режим «Designated».
Теоретически может случиться Backup

Это не критика, а помощь в том, что успел прочитать :-).
Если интересно, то могу по мере возможности консультировать.

Рисовалка встроена в EVE-NG. С её помощью и собирается топология.

Комментарии к исходникам просто превосходны :).

Я в итоге закрыл на домашнем астере доступ на 5060 извне, оставив только OpenVPN-порт на сертификатах. Теперь и с NAT'ом не надо воевать, и "левые" товарищи не ломятся на астер.

… тут вообще интересный вопрос, к какому уровню его отнести.
Вот полностью соглашусь: не вижу огромного смысла относить ВСЕ протоколы к какому-то конкретному уровню :).
Рейтлимит дхцп запросов таки глупость в плане защиты, разве что от дос.
Я выше так и написал – это от DoS.

и проверки что мак адрес в заголовке эзернет пакета совпадает с макс адресом в дхцп пакете обычно нет.
Команда ip dhcp snooping verify mac-address включена по умолчанию и как раз выполнят проверку (снова процессором) на соответствие MAC-адреса в Ethernet-заголовке MAC-адресу в DHCP-запросе. Т.е. при port security + DHCP snooping исчерпать DHCP-пул не получится, а задосить – можно. Тут и приходит на помощь limit rate.

Порознь каждая из «фич» может и так себе, но вместе – сила ;).
arp это уже не л2, это л3 протокол
Согласно Вики ARP работает всё-таки на канальном уровне. Да, анализ содержимого фрэймов/пакетов/сегментов (тот же DHCP Snooping) выходит за пределы L2, но я всё же думаю, что автор поста имел в виду функционал, поддерживаемый L2-коммутаторами для защиты от атак реализуемых в рамках L2-участка сети.

Касательно рейтлимита на дхцп запросы — глупость полная: никто не мешает атакующему спокойно выжирать весь пул адресов даже на низкой скорости, подумаешь вместо нескольких секунд всё закончится за пару минут.
Limit rate нисколько не глупость. Чтобы атакующий не смог «выжрать» пул нужен port security (а не limit rate, на заметку автору поста), тогда с одним MAC-адресом атакующий сможет «выжрать» всего один адрес. А вот «задосить» процессор коммутатора с помощью большого количества DHCP-запросов (эта обработка не перекладывается в ASIC'и) атакующий может без особых проблем, вот тут и приходит на помощь limit rate.

Dynamic ARP inspection — провайдеры (те те это массово использует) не хвалили, бывают глюки.
Вроде нигде не говорилось о провайдерах. При упоминании Cisco я бы, в первую очередь, подумал о корпоративном секторе. К слову, о проблеме DAI – может получиться пичалька, если коммутатор хранить ip dhcp binding в RAM, а не на ftp/tftp/flash (ip dhcp snooping database). В этом случае после перезагрузки список binding'ов пуст и легитимные ARP-запросы невинных пользователей будут дропаться до тех пор, пока DHCP-клиент не обновит себе адрес.
ИМХО так себе аргумент. Получается как-то так:
Провайдер: И толку? Зачем IPv6, если клиентов/серверов мало?
Админы: И толку? Зачем IPv6, если клиентов/провайдеров мало?
Клиенты: И толку? Зачем IPv6, если провайдеров/серверов мало?
Добавлю статистики:
Ping statistics for 8.8.8.8: Minimum = 61ms, Maximum = 65ms, Average = 62ms
Ping statistics for 77.88.8.7: Minimum = 61ms, Maximum = 69ms, Average = 63ms
Ping statistics for 208.67.222.222: Minimum = 98ms, Maximum = 146ms, Average = 104ms

Ну и DNS от Yandex работает без регистрации и смс (сам, правда, пользуюсь bind'ом, а не готовыми внешними сервисами), да ещё и в v6 резолвит :):
> nslookup xxx.com 77.88.8.7
Server: family.dns.yandex.ru
Address: 77.88.8.7

Non-authoritative answer:
Name: xxx.com
Addresses: 2a02:6b8::b10c:babe
93.158.134.250
Была аналогичная ситуация (пример 1), до сути не докопались, в качестве workaround настроили пинговалку провайдерского адреса (IP SLA) :-).
EEM – это, конечно, классно, только для проверки нескольких track'ов одновременно, есть решение проще и удобнее:

track 1 list boolean {and | or}
 object 2
 object 3 [not]

Или в 2010-ом IOS ещё не поддерживал?
Так и не убрали Frame Relay, который пропал в CCNA и CCIE
В CCNA всё ещё присутствует.
Увы, несколько сложнее :).

Конфигурация для случая с dial-peer типа VOIP:
application
 service NAME_OF_SERVICE flash:/vxml_script.vxml
!
dial-peer voice 1 voip
 service NAME_OF_SERVICE out-bound
 destination-patter ^2100$
 session target ipv4:1.1.1.1

Session target можно указать любой, он нужен только для того, чтобы этот outbound dial-peer пришел в состояние UP.

Можно почитать текст и посмотреть видео про вариант VXML здесь: alakinalexandr.blogspot.com
Я – желающий :)

Information

Rating
Does not participate
Location
Алматы (Алма-Ата), Алма-Атинская обл., Казахстан
Registered
Activity