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

cMex

Пользователи
  • Content Count

    54
  • Joined

  • Last visited

About cMex

  • Rank
    Абитуриент
  1. Мде. :) Антон, а вы случаем к составлению договоров и юридической стороне нашего многогранного российского телекома не имеете прямого отношения? Если да, то я бы вам в личку написал бы.
  2. SNEG, а какой документ описывает услугу "передача данных"? Когда наступает событие её предоставления? А есть здесь кто-нибудь, кто упрощал процесс (официально) процесс сдачи узла связи с учетом расположения оборудования связи в легальном датацентре (читай "узле связи")? Я просто читал здесь же, на НАГе, что процесс упрощения взаимоотношений возможен, при условии содействия при подготовке проекта узла связи со стороны владельца арендуемого датацентра (он, дескать, пишет некие письма в Россвязьнадзор и ФСБ).
  3. Всем привет. Вопросы лицензирования в принципе достаточно ясны, для обычного хостинга (веб, еще что-то) нужна как минимум лицензия на ТУС. А вот такой вопрос: оборудование устанавливается в стороннем "белом" (полностью легальном) датацентре, все лицензии на него есть, сдан узел связи, все нормально. Дальше пользователи, подключаясь к моим серверам используют услуги хостинга приложений, при этом одним из пунктов является доступ по RDP к терминальным службам. Дело в том, что в этом случае пользователи получают возможность использовать Интернет через удаленный рабочий стол по схеме "пользователь <-> мое оборудование <-> интернет-канал владельца датацентра", причем деньги за доступ в Интернет брать не планируется, но в условиях договора описать, что скорость доступа к внешним сетям через удаленные рабоиче столы будет ограничиваться, что покажет "наружу", что доступ к Интернет я все же предоставляю. В этом случае, как я понимаю, хочешь не хочешь, но придется получать лицензию на услуги передачи данных? Что это повлечет за собой еще: сдача узла связи, взаимодействие с ФСБ по СОРМ и т. д.? Спасибо за ответы и потраченное на меня время. Не сочтите за рекламу, нашел достаточно развернутые ответы здесь и здесь. Буду очень рад, если кто-то подкованный в этих вопросах прокомментирует неоговоренные или ошибочные сведения.
  4. У меня к счастью, тоже небольшой. Врядли это повлияет на что-то, кроме увеличенной латентности трафика. Будем рыть по проблеме, благо возможность есть пока маршрутизатор не перезагружать.
  5. Да, действительно, так оно и есть. Временно проблему костылем решил. Спасибо! А пока что буду искать решения. А чем чревато увеличением по сути на два порядка входящей очереди? Я поставил 1024. Кстати: #sh buffers input-interface vlan 4 Header DataArea Pool Rcnt Size Link Enc Flags Input Output Header DataArea Pool Rcnt Size Original Flags caller_pc Public particle pools: Private particle pools:
  6. Добрый день. Объявилась проблемка с изучением маршрутизатором IP ARP. Может не бага, которая лечится перезагрузкой и кто-нибудб встречался? Есть Cisco 7600, на неё есть Vlan 4, в который входит 4 порта, SVI - 192.168.0.1. К одному из портов (Gi1/27) подключен хост с адресом 192.168.0.2. Беда в том, что Cisco не может выучить ip arp запись на устройство 192.168.0.2. При этом, когда пытаюсь пинговать с маршрутизатора хост, вижу, что на хост приходят ARP-REQUEST, хост отдает ARP-REPLY; когда же с хоста пингую маршрутизатор от хоста уходят ARP-REQUEST, но ARP-REPLY не приходят от маршрутизатора. Если прописываю руками на маршрутизаторе и на хосте статические ip arp записи, то форвардинг через маршрутизатор трафика от хоста начинает работать нормально, но сам маршрутизатор так и не пингуется. Пока эта проблемка всплыла только на этом Vlan, при чем ночью, когда естественно никто ничего там не конфигурировал. Из того, что относиться к таблицам ARP и MAC включено только mac-address-table notification mac-move. Версия софта: Cisco IOS Software, c7600rsp72043_rp Software (c7600rsp72043_rp-IPSERVICESK9-M), Version 12.2(33)SRD, RELEASE SOFTWARE (fc2) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2008 by Cisco Systems, Inc. Compiled Thu 23-Oct-08 19:10 by prod_rel_team Вот конфиги VLAN и порта: interface GigabitEthernet1/27 switchport switchport trunk encapsulation dot1q switchport trunk native vlan 4 switchport trunk allowed vlan 4 switchport mode trunk end interface Vlan4 ip address 192.168.0.1 255.255.255.248 no ip proxy-arp end А вот show с них: #sh int gi1/27 GigabitEthernet1/27 is up, line protocol is up (connected) Hardware is C7600 1Gb 802.3, address is 0022.9078.2292 (bia 0022.9078.2292) MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 1000Mb/s input flow-control is off, output flow-control is off Clock mode is auto ARP type: ARPA, ARP Timeout 04:00:00 Last input never, output never, output hang never Last clearing of "show interface" counters 9w5d Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 1299 packets input, 244066 bytes, 0 no buffer Received 168 broadcasts (49 multicasts) 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 0 multicast, 0 pause input 0 input packets with dribble condition detected 8434 packets output, 2782726 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier, 0 pause output 0 output buffer failures, 0 output buffers swapped out #sh int vlan 4 Vlan4 is up, line protocol is up Hardware is EtherSVI, address is 001f.9ed2.d300 (bia 001f.9ed2.d300) Internet address is 192.168.0.1/29 MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive not supported ARP type: ARPA, ARP Timeout 04:00:00 Last input 11:45:55, output 00:02:19, output hang never Last clearing of "show interface" counters 9w5d Input queue: 76/75/61071/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 249000 bits/sec, 179 packets/sec 5 minute output rate 198000 bits/sec, 177 packets/sec L2 Switched: ucast: 2466445 pkt, 233869865 bytes - mcast: 4487 pkt, 303536 bytes L3 in Switched: ucast: 1715124253 pkt, 1184631568007 bytes - mcast: 0 pkt, 0 bytes mcast L3 out Switched: ucast: 1300851877 pkt, 189149964600 bytes mcast: 0 pkt, 0 bytes 1720190812 packets input, 1186977944560 bytes, 0 no buffer Received 4416 broadcasts (0 IP multicasts) 0 runts, 0 giants, 33684 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 1302626842 packets output, 189331487902 bytes, 0 underruns 0 output errors, 2 interface resets 0 output buffer failures, 0 output buffers swapped out # sh ip int vlan 4 Vlan4 is up, line protocol is up Internet address is 192.168.0.1/29 Broadcast address is 255.255.255.255 Address determined by setup command MTU is 1500 bytes Helper address is not set Directed broadcast forwarding is disabled Outgoing access list is not set Inbound access list is not set Proxy ARP is disabled Local Proxy ARP is disabled Security level is default Split horizon is enabled ICMP redirects are always sent ICMP unreachables are always sent ICMP mask replies are never sent IP fast switching is enabled IP Flow switching is disabled IP CEF switching is enabled IP CEF switching turbo vector IP Null turbo vector Associated unicast routing topologies: Topology "base", operation state is UP IP multicast fast switching is enabled IP multicast distributed fast switching is disabled IP route-cache flags are Fast, CEF Router Discovery is disabled IP output packet accounting is disabled IP access violation accounting is disabled TCP/IP header compression is disabled RTP/IP header compression is disabled Probe proxy name replies are disabled Policy routing is disabled Network address translation is disabled BGP Policy Mapping is disabled Input features: CASA, MCI Check Output features: HW Shortcut Installation Post encapsulation features: HW Shortcut Installation Sampled Netflow is disabled IP Routed Flow creation is disabled in netflow table IP Bridged Flow creation is disabled in netflow table WCCP Redirect outbound is disabled WCCP Redirect inbound is disabled WCCP Redirect exclude is disabled IP multicast multilayer switching is disabled
  7. http://forum.sysfaq.ru/index.php?showtopic=5137 У 7301 поменьше будет.
  8. IP 192.168.201.26 в маршруте?

    Я предполагаю, что этот адрес наличествует в вашей серой сети и поэтому пингуется.
  9. Попробуйте tcpdump -i eth1 -s 0 -n -w /home/unknown.cap и потом загрузите этот файл в свежий Wireshark. Вероятно, станет понятно, что это такое.
  10. hc.ru

    visir, вы сейчас о чем пишите? Я разве где-то написал, что менял анонсы? После полутора лет безотказной работы и неизменении с моей стороны конфигов, я же могу расчитывать на то, что третья сторона уберет у себе причину петли маршрутизации или хотя бы где-то повесит объявление, что с текущего момента при приеме спецификов мы организуем вам назло петли, ага?
  11. hc.ru

    Я вас не понял. /17 + /18, это не 2, а 3 /18. А если вы имели в виду анонсировать вместо 2 x /24 один раз /23, например, то таким образом балансируется входящий трафик. Это неверное решение, но ему есть причины, не всегда можно отдать агрегированные маршруты. Ну а с hc.ru все приходит более-менее в русло понимания, ждем понедельника, когда смогут отреагировать их системные администраторы с запрососм в RUNNet. traceroute 1.2.3.4 traceroute to 1.2.3.4 (1.2.3.4), 64 hops max, 40 byte packets 1 dsw-3 (79.174.72.1) 0.583 ms 0.542 ms 0.535 ms 2 bgw-m9 (91.189.112.1) 0.921 ms 0.728 ms 0.713 ms 3 m9-1-gw.msk.runnet.ru (194.190.255.249) 0.814 ms 0.764 ms 0.769 ms 4 tv11-1-gw.msk.runnet.ru (194.85.40.38) 1.066 ms 1.051 ms 0.982 ms 5 m9-2-gw.msk.runnet.ru (194.85.40.53) 1.222 ms 1.490 ms 1.113 ms 6 tv11-1-gw.msk.runnet.ru (194.85.40.54) 1.354 ms 1.350 ms 1.377 ms 7 m9-2-gw.msk.runnet.ru (194.85.40.53) 1.345 ms 3.158 ms 1.610 ms 8 tv11-1-gw.msk.runnet.ru (194.85.40.54) 1.486 ms 1.547 ms 1.484 ms 9 m9-2-gw.msk.runnet.ru (194.85.40.53) 1.735 ms 1.734 ms 1.620 ms 10 tv11-1-gw.msk.runnet.ru (194.85.40.54) 1.835 ms 1.989 ms 1.955 ms 11 m9-2-gw.msk.runnet.ru (194.85.40.53) 1.978 ms 1.758 ms 1.727 ms 12 tv11-1-gw.msk.runnet.ru (194.85.40.54) 2.113 ms 2.078 ms 1.861 ms 13 m9-2-gw.msk.runnet.ru (194.85.40.53) 2.002 ms 3.193 ms 4.583 ms 14 tv11-1-gw.msk.runnet.ru (194.85.40.54) 2.239 ms 2.229 ms 2.105 ms 15 m9-2-gw.msk.runnet.ru (194.85.40.53) 2.612 ms 2.589 ms 2.361 ms 16 tv11-1-gw.msk.runnet.ru (194.85.40.54) 2.708 ms 2.525 ms 2.484 ms 17 m9-2-gw.msk.runnet.ru (194.85.40.53) 2.478 ms 2.602 ms 2.716 ms 18 tv11-1-gw.msk.runnet.ru (194.85.40.54) 2.729 ms 2.717 ms 2.698 ms 19 m9-2-gw.msk.runnet.ru (194.85.40.53) 2.604 ms 2.751 ms 2.624 ms 20 tv11-1-gw.msk.runnet.ru (194.85.40.54) 3.096 ms 3.082 ms 3.028 ms 21 m9-2-gw.msk.runnet.ru (194.85.40.53) 2.930 ms 3.039 ms 3.106 ms 22 tv11-1-gw.msk.runnet.ru (194.85.40.54) 3.130 ms 3.184 ms 3.366 ms 23 m9-2-gw.msk.runnet.ru (194.85.40.53) 3.360 ms 3.166 ms 3.129 ms ...
  12. hc.ru

    Проблемы с чем именно, вы имеете в виду?
  13. hc.ru

    C'est la vie. Нормальные методы по многим причинам пока не подходили, хотя я тоже тремя руками за агрегированные маршруты. В скором времени я смогу убрать специфики, но проблему с hc решать надо уже сейчас, а не потом.
  14. hc.ru

    Кто-нибудь заметил уже не прекратившуюся еще проблему у hc.ru, которая, как я понял, массово коснулась провайдеров, анонсирующих аплинкам префиксы разной длины (порезанные, для баласировки по каналам)? Часть Рунета, соотвественно, стала недоступной, а еще точнее — вся та часть, что хостится на hc.ru.