Jump to content
Калькуляторы

dmvy

VIP
  • Content Count

    1417
  • Joined

  • Last visited

Everything posted by dmvy


  1. медные SFP в оптическом 6850 работают только на 1000мбит. на ниже скоростях не заведутся. У нас работали модуля SNR
  2. Для графиков по SNMP не проще будет собирать стандартную статистику в какой-нибудь Cacti и подобных? Или "хочется странного"? В какти конечно есть скрипты для автоматического создания хоста, но это не то :-). По идее с sflow телодвижений должно быть в разы меньше. Зачем-то же придумали sflow, надо разобраться зачем :-). Затем же, зачем и NetFlow - собирать статистику по соединениям и трафику. Только с SFlow она будет с большой погрешностью, т.к. захватываются не все пакеты. Мы сейчас пишем свой сборщик с хранением в БД для анализа профиля трафика по портам и протоколам + разбор DDoS атак на полосе 20Гбит. 10 дней всех flow в БД занимает 60Гб. 13:25:41 total2 Speed 10606Mb/s Samples/s 669 Flows: 17240 Statistics by destination ip address and bytes: ===== IP: 92.157.41.209 Speed: 103 Mbit/s Flows:4 ===== IP: 92.157.87.151 Speed: 90 Mbit/s Flows:32 ===== IP: 82.224.161.204 Speed: 89 Mbit/s Flows:90 ===== IP: 92.31.148.33 Speed: 87 Mbit/s Flows:19 ===== IP: 82.224.206.156 Speed: 82 Mbit/s Flows:22 Statistics by source ip address and bytes: ===== IP: 95.142.201.66 Speed: 179 Mbit/s Flows:172 ===== IP: 95.142.201.67 Speed: 162 Mbit/s Flows:175 ===== IP: 31.13.72.53 Speed: 149 Mbit/s Flows:255 Еще в отличии от NetFlow нельзя отследить начало/конец TCP-сессии.
  3. не совсем понимаю схему для чего это нужно, но не лучше ли сделать зеркалирование на основе ACL? Чтобы зеркалировалось только то, что попало под правила?
  4. посмотрите рекомендации по обновлению, сразу прыгнуть на 13й релиз не получится с 11.4 успешно обновились до 13.3R8.7. Но роутер чистый MX80
  5. STP? при topology change пакеты дропаются. бебаг включить - порбовать там выловить ошибки, отправив на syslog все сообщения для парсинга.
  6. при 20килопакетах 400 ошибок ерунда. не в этом причина
  7. DGS-3000-28SC Возможности продукта: Управляемый стекируемый коммутатор 2 уровня с 20 портами 100/1000Base-X SFP, 4 комбо-портами 10/100/1000Base-T/SFP и 4 портами 10GBase-X SFP+ Или у Вас коммутатор агрегации - это медный коммутатор?
  8. что в вашем понимании "серверный коммутатор"? какой функционал? что недолговечного в том dlink, который используете?
  9. DGS-3120 и DGS-3420 неплохо заменяются серией DGS-3000.
  10. Слишком дорого, мне проще тогда брать Eltex 1124 есть low-cost серия Des-1210-10/ME.
  11. Как мне сообщали, такой функционал есть на 7210 7710 sr c12 этот сможет? в любом уважающем себя роутере есть bridge domain.
  12. да. итого будет занято 2*[количество VLAN] портов. Можно использовать для таких петель другой более дешевый коммутатор.
  13. не видел в даташите и мануале такого функционала. вероятно только физическими перемычками.
  14. может клиент тогда сам поднимет multihop сессию с апстримом 4 и получит FV, а вы только default возьмите от него. в этом случае трафик других клиентов не пойдет туда.
  15. Причем весьма небезразмерный... Сильно мне так кажется, что малтипас его забьет, как и врф. Даже 4 аплинка вообще удивило. Моё на этом процессором при флапе минут 20 по полке загрузки ходить начинало. multipath не забивает FIB. У нас 3 FV жило совсем без проблем. Не вижу причин почему 4 FW не взлетит. По расчетам 4/0.6 влезет и 6 FV. MX80 FIB Capacity IPv4: 1Mil MX80 FIB Capacity IPv6: 512k MX80 RIB Capacity IPv4: 4Mil MX80 RIB Capacity IPv6: 3Mil По теме: с community нужно еще сделать PBR через firewall filter для данного интерфейса, если необходимо весь трафик заворачивать исходящий. +1 Маркировка комьюнити это хорошо , но я так понимаю что трафик должен следлвать за анонсами. В интернете очень часто встречаются несимметричные маршруты. Диагностировать при деградации сложнее, но никто еще не умер от этого. Так что можете не обращать внимание на это и реализовать только BGP community и сказать клиенту "на изучай, делай анонсы как удобно".
  16. нужен старый конфиг. а вышестоящие операторы делали диагностику? покажите sh ip bgp neighbors 10.211.34.18 может анонсировать не префикс листом, а route-map?
  17. это не всегда удобно например роутмап может быть универсальным для модификации атрибутов маршрутов, а префикс-лист можно делать отдельный на каждого пира судя по названию роут-мапа там как раз локал-преф модифицируется, а префикс-лист работает по назначению Если требуется только фильтрация анонсов по ip, то пользуетесь prefix-list, если нужна фильтрафция по атрибутам, то вставляете prefix-list в route-map и пользуетесь только route-map. Так проще и понятнее, потому как логика фильтрации будет описана в route-map и не нужно будет думать, где же ошибка. Мы делали route-map для каждого пира. А что дает filter-list 2 out?
  18. а что с загрузкой CPU? может control plane не все пакеты получил?
  19. с производства да, но не с поддержки. б/у SCE наверное даже дешевле СКАТ. а резать полосу по абонентам можно и на брасе и на DPI. Или как говорил красить на DPI, а резать на BRAS.
  20. я бы поставил в разрыв SCE8000, на которой бы красил трафик по DSCP. А на брасе уже в нужные очереди клал... А разве не дешевле иметь широкий канал, чтобы не заниматься этой ерундой с подрезанием в ЧНН? Еще можно выборочно отправлять в DPI абонентов, кто больше всех качает для подрезки torrent.
  21. Ericsson SSR давно продвигается. удельная производительность гораздо выше плат SE600. + виртуальная CPE. я бы взял... И конфиг перенесете 1:1. А какой функционал софтовый вы хотите?
  22. У Вас действительно куплена лицензия на эту функцию? Или удалось запустить в обход?
  23. даже с дефолтными таймерами клиент перейдет на broadcast renew до init. init будет если только долго на broadcast Никто не ответит.
  24. а вы на dhcp-сервере не принимайте такие пакеты. только от relay. или даже на extreme блокируйте. через некоторый интервал клиент снова broadcast request отправит Можно подкрутить таймеры, чтобы сразу broadcast запрашивал https://tools.ietf.org/html/rfc2131#section-4.4.4 https://tools.ietf.org/html/rfc2131#section-4.4.5 4.4.4 Use of broadcast and unicast The DHCP client broadcasts DHCPDISCOVER, DHCPREQUEST and DHCPINFORM messages, unless the client knows the address of a DHCP server. The client unicasts DHCPRELEASE messages to the server. Because the client is declining the use of the IP address supplied by the server, the client broadcasts DHCPDECLINE messages. When the DHCP client knows the address of a DHCP server, in either INIT or REBOOTING state, the client may use that address in the DHCPDISCOVER or DHCPREQUEST rather than the IP broadcast address. The client may also use unicast to send DHCPINFORM messages to a known DHCP server. If the client receives no response to DHCP messages sent to the IP address of a known DHCP server, the DHCP client reverts to using the IP broadcast address. 4.4.5 Reacquisition and expiration The client maintains two times, T1 and T2, that specify the times at which the client tries to extend its lease on its network address. T1 is the time at which the client enters the RENEWING state and attempts to contact the server that originally issued the client's network address. T2 is the time at which the client enters the REBINDING state and attempts to contact any server. T1 MUST be earlier than T2, which, in turn, MUST be earlier than the time at which the client's lease will expire. To avoid the need for synchronized clocks, T1 and T2 are expressed in options as relative times [2]. At time T1 the client moves to RENEWING state and sends (via unicast) a DHCPREQUEST message to the server to extend its lease. The client sets the 'ciaddr' field in the DHCPREQUEST to its current network address. The client records the local time at which the DHCPREQUEST message is sent for computation of the lease expiration time. The client MUST NOT include a 'server identifier' in the DHCPREQUEST message. Any DHCPACK messages that arrive with an 'xid' that does not match the 'xid' of the client's DHCPREQUEST message are silently discarded. When the client receives a DHCPACK from the server, the client computes the lease expiration time as the sum of the time at which the client sent the DHCPREQUEST message and the duration of the lease in the DHCPACK message. The client has successfully reacquired its network address, returns to BOUND state and may continue network processing. If no DHCPACK arrives before time T2, the client moves to REBINDING state and sends (via broadcast) a DHCPREQUEST message to extend its lease. The client sets the 'ciaddr' field in the DHCPREQUEST to its current network address. The client MUST NOT include a 'server identifier' in the DHCPREQUEST message. Times T1 and T2 are configurable by the server through options. T1 defaults to (0.5 * duration_of_lease). T2 defaults to (0.875 * duration_of_lease). Times T1 and T2 SHOULD be chosen with some random "fuzz" around a fixed value, to avoid synchronization of client reacquisition. A client MAY choose to renew or extend its lease prior to T1. The server MAY choose to extend the client's lease according to policy set by the network administrator. The server SHOULD return T1 and T2, and their values SHOULD be adjusted from their original values to take account of the time remaining on the lease. In both RENEWING and REBINDING states, if the client receives no response to its DHCPREQUEST message, the client SHOULD wait one-half of the remaining time until T2 (in RENEWING state) and one-half of the remaining lease time (in REBINDING state), down to a minimum of 60 seconds, before retransmitting the DHCPREQUEST message. If the lease expires before the client receives a DHCPACK, the client moves to INIT state, MUST immediately stop any other network processing and requests network initialization parameters as if the client were uninitialized. If the client then receives a DHCPACK allocating that client its previous network address, the client SHOULD continue network processing. If the client is given a new network address, it MUST NOT continue using the previous network address and SHOULD notify the local users of the problem. ... https://tools.ietf.org/html/rfc1533 9.9. Renewal (T1) Time Value This option specifies the time interval from address assignment until the client transitions to the RENEWING state. The value is in units of seconds, and is specified as a 32-bit unsigned integer. The code for this option is 58, and its length is 4. Code Len T1 Interval +-----+-----+-----+-----+-----+-----+ | 58 | 4 | t1 | t2 | t3 | t4 | +-----+-----+-----+-----+-----+-----+ 9.10. Rebinding (T2) Time Value This option specifies the time interval from address assignment until the client transitions to the REBINDING state. The value is in units of seconds, and is specified as a 32-bit unsigned integer. The code for this option is 59, and its length is 4. Code Len T2 Interval +-----+-----+-----+-----+-----+-----+ | 59 | 4 | t1 | t2 | t3 | t4 | +-----+-----+-----+-----+-----+-----+