crank Опубликовано 19 июля, 2018 · Жалоба 25 минут назад, catalist сказал: Сделал, потери ушли Попингуйте что-нибудь из ресурсов 4-го аплинка, чтобы быть уверенным, что трафик к вам через роутер 2 идёт. К примеру можно попинговать is-telecom.ru и лучше ещё у них спросить трассировку до вас, чтобы быть точно уверенным (в 99% и без этого от них трафик к вам напрямую идёт). Уж очень мало трафика у вас на порту этого аплинка. Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
catalist Опубликовано 19 июля, 2018 · Жалоба Сделал трейс до из сайта, трафик к ним идет через первый роутер а аборатно видимо через второй, потерь нету при этом, но совернешенно не понятно в чем дело то? Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Atlant Опубликовано 19 июля, 2018 · Жалоба Сдается мне, что проблема находится где-то в пределах W-IX. В который включен AS29196 (ISTELECOM) и другие... Попробуйте принять FullView от 4-го аплинка, но на входе зафильтровать по ASPATH-ацл, например: neighbor 195.69.217.136 route-map 4TH-UPLINK-IN in ip as-path access-list 33 permit _8369_ ip as-path access-list 33 deny .* route-map 4TH-UPLINK-IN deny 10 match as-path 33 route-map 4TH-UPLINK-IN permit 20 Тогда потери уйдут? Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
crank Опубликовано 19 июля, 2018 · Жалоба Вопрос. Аплинки подключены напрямую в бордеры или между аплинками и бордерами есть какой-то коммутатор? Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
VolanD666 Опубликовано 20 июля, 2018 · Жалоба Физический доступ к железу есть? Встаньте на миррор порт и смотрите что теряется на нем. Либо можно подсеть клиентскую прописать на роутере и смотреть где и что теряется. Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
catalist Опубликовано 20 июля, 2018 · Жалоба 13 часов назад, crank сказал: Вопрос. Аплинки подключены напрямую в бордеры или между аплинками и бордерами есть какой-то коммутатор? нет между ними коммутаторов нет 1 час назад, VolanD666 сказал: Физический доступ к железу есть? Встаньте на миррор порт и смотрите что теряется на нем. Либо можно подсеть клиентскую прописать на роутере и смотреть где и что теряется. да физический доступ есть, есть даже порты для зеркалинга подключенные. На каком порту смотреть то? В сторону аплинка или в сторону первой цыски? или на первой цыске смотреть? 14 часов назад, Atlant сказал: Сдается мне, что проблема находится где-то в пределах W-IX. В который включен AS29196 (ISTELECOM) и другие... Попробуйте принять FullView от 4-го аплинка, но на входе зафильтровать по ASPATH-ацл, например: neighbor 195.69.217.136 route-map 4TH-UPLINK-IN in ip as-path access-list 33 permit _8369_ ip as-path access-list 33 deny .* route-map 4TH-UPLINK-IN deny 10 match as-path 33 route-map 4TH-UPLINK-IN permit 20 Тогда потери уйдут? Спасибо, попробую, только эксперименты могу вечером проводить когда трафика мало. Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
VolanD666 Опубликовано 20 июля, 2018 · Жалоба Ну вы посмотрите как по схеме у вас трафик ходит. Втыкаете два ноута, один ближе к абоненту, другой ближе к аплинку. Смотрите сколько пришло, сколько ушло. Дальше локализуете проблему, будет понятно где искать. Я бы так сделал Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
catalist Опубликовано 20 июля, 2018 · Жалоба в том то и дело что внутри сети потериь нет! они начинаются только когда пингаем внешний адрес. Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
VolanD666 Опубликовано 20 июля, 2018 (изменено) · Жалоба 3 минуты назад, catalist сказал: в том то и дело что внутри сети потериь нет! они начинаются только когда пингаем внешний адрес. Ну т.е. вы уверены на 146%, что у вас из сети вылетает, допустим 50 icmp запросов, а возвращается в AS (заметить, в AS) только 25 ? Изменено 20 июля, 2018 пользователем VolanD666 Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
catalist Опубликовано 20 июля, 2018 · Жалоба я уже не уверен не вчем, долбанная магия, получается такая ситуация: до бордера потерь нет. но если делать при этом паралельную трассировку то в ней они есть и начинаются именно на бордере. (см картинки трейсов) и еще если воткнуть 4го аплника в первый бордер то проблемы нет вообще.... Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
catalist Опубликовано 20 июля, 2018 · Жалоба 15 часов назад, Atlant сказал: Сдается мне, что проблема находится где-то в пределах W-IX. В который включен AS29196 (ISTELECOM) и другие... Попробуйте принять FullView от 4-го аплинка, но на входе зафильтровать по ASPATH-ацл, например: neighbor 195.69.217.136 route-map 4TH-UPLINK-IN in ip as-path access-list 33 permit _8369_ ip as-path access-list 33 deny .* route-map 4TH-UPLINK-IN deny 10 match as-path 33 route-map 4TH-UPLINK-IN permit 20 Тогда потери уйдут? Я сделал так, трафик через второй бордер не пошел, а пошел с первого сразу в инет, потерь при этом небыло Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Atlant Опубликовано 20 июля, 2018 · Жалоба 3 hours ago, catalist said: Я сделал так, трафик через второй бордер не пошел, а пошел с первого сразу в инет, потерь при этом небыло Должен был какой-то трафик наружу все же пойти. Любой кроме как на _8369_. Бесты же были с нейбора (4-го аплинка)? Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
catalist Опубликовано 20 июля, 2018 · Жалоба я бестов не видел в первом приближении Трафик может и какой то шел но жалобы были только до конкретного узла.... 6 часов назад, VolanD666 сказал: Ну т.е. вы уверены на 146%, что у вас из сети вылетает, допустим 50 icmp запросов, а возвращается в AS (заметить, в AS) только 25 ? судя по трассивке в win mtr да. Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
catalist Опубликовано 21 июля, 2018 · Жалоба Продолжаю ковыряние. Подскажите плиз почему при отсутствии фильтров с двух сторон с первого роутера я получаю фулл в сторону второго, а со второго только локальный префикс? Выглядит это так: на первой цыске: C7609S-I#sh ip bgp vpnv4 vrf INET neighbors 172.16.50.234 received-routes BGP table version is 171198752, local router ID is 10.10.1.34 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 43031:1 (default for vrf INET) * i 0.0.0.0 172.16.50.234 0 100 0 i * i 85.202.0.0/20 172.16.50.234 0 100 0 i Total number of prefixes 2 на второй цыске: C7606S-II#sh ip bgp vpnv4 vrf INET neighbor 172.16.50.134 received-routes BGP table version is 5516953, local router ID is 192.168.0.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 43031:1 (default for vrf INET) * i 1.0.0.0/24 172.16.50.134 0 100 0 3216 2914 13335 i * i 1.0.4.0/24 172.16.50.134 0 100 0 3216 6939 4826 38803 56203 i * i 1.0.4.0/22 172.16.50.134 0 100 0 3216 6939 4826 38803 56203 i * i 1.0.5.0/24 172.16.50.134 0 100 0 3216 6939 4826 38803 56203 i * i 1.0.6.0/24 172.16.50.134 0 100 0 3216 6939 4826 38803 56203 i * i 1.0.7.0/24 172.16.50.134 0 100 0 3216 6939 4826 38803 56203 i * i 1.0.16.0/24 172.16.50.134 0 100 0 3216 1273 2497 2519 i При этом на обоих цысках разные аплинки и загружен полный фул. По идее я на первой должен видеть фулл от второй? разве нет? вот если что конфиги пиров: CORE-I router bgp 43031 bgp always-compare-med no bgp enforce-first-as bgp log-neighbor-changes bgp bestpath compare-routerid ! address-family ipv4 vrf INET network 85.202.0.0 mask 255.255.240.0 network 85.202.0.0 mask 255.255.248.0 network 85.202.8.0 mask 255.255.248.0 neighbor 172.16.50.234 remote-as 43031 neighbor 172.16.50.234 description C7606S-II neighbor 172.16.50.234 activate neighbor 172.16.50.234 soft-reconfiguration inbound CORE-II router bgp 43031 bgp always-compare-med no bgp enforce-first-as bgp log-neighbor-changes bgp bestpath compare-routerid ! address-family ipv4 vrf INET network 85.202.0.0 mask 255.255.240.0 network 85.202.0.0 mask 255.255.248.0 network 85.202.8.0 mask 255.255.248.0 neighbor 172.16.50.134 remote-as 43031 neighbor 172.16.50.134 description C7609S-I neighbor 172.16.50.134 activate neighbor 172.16.50.134 default-originate neighbor 172.16.50.134 soft-reconfiguration inbound хм, частично ответ есть, нет анонсов в сторону первой цыски, но почему? C7606S-II#sh ip bgp vpnv4 vrf INET neighbor 172.16.50.134 advertised-routes BGP table version is 5517747, local router ID is 192.168.0.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Originating default network 0.0.0.0 Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 43031:1 (default for vrf INET) *> 85.202.0.0/20 0.0.0.0 0 32768 i ведь таблица полная и тут свой отдельный аплинк со своими бестами..... Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
catalist Опубликовано 21 июля, 2018 · Жалоба Положил на первой цыске все аплинки, в таблице первого роутера остался только дефолт от второй цыски: C7609S-I#sh ip route vrf INET Routing Table: INET Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP a - application route + - replicated route, % - next hop override Gateway of last resort is 172.16.50.234 to network 0.0.0.0 B* 0.0.0.0/0 [200/0] via 172.16.50.234, 00:05:30 При этом в трассировках вот такая жопа: tracert 80.255.95.142 Трассировка маршрута к 80.255.95.142 с максимальным числом прыжков 30 1 <1 мс <1 мс <1 мс 10.0.0.100 2 1 ms * 1 ms 192.168.0.1 3 3 ms 2 ms 3 ms core.sp-com.ru [85.202.2.1] 4 2 ms 9 ms 4 ms 172.16.200.1 (это первый роутер) 5 * * * Превышен интервал ожидания для запроса. 6 * * * Превышен интервал ожидания для запроса. 7 * * ^C tracert -d 87.250.250.242 Трассировка маршрута к 87.250.250.242 с максимальным числом прыжков 30 1 <1 мс <1 мс <1 мс 10.0.0.100 2 * 1 ms * 192.168.0.1 3 1 ms 1 ms 2 ms 85.202.2.1 4 10 ms 2 ms 3 ms 172.16.200.1 (это первый роутер) 5 * * * Превышен интервал ожидания для запроса. 6 * * ^C Тоесть получается что дальше первой цыски трейс не шел, хотя есть вторая которая доступна и имела бгп наружу При этом делаю пинг с первой на вторую во время этого и получаю что все ок: C7609S-I#ping vrf INET 172.16.50.234 repeat 1000 source 172.16.50.134 Type escape sequence to abort. Sending 1000, 100-byte ICMP Echos to 172.16.50.234, timeout is 2 seconds: Packet sent with a source address of 172.16.50.134 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!! Success rate is 100 percent (1000/1000), round-trip min/avg/max = 1/1/4 ms Тоесть почему теряется трассировка да вообще пинги не ходят, ума не приложу. Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Mitya Опубликовано 21 июля, 2018 · Жалоба 2 часа назад, catalist сказал: Продолжаю ковыряние. Подскажите плиз почему при отсутствии фильтров с двух сторон с первого роутера я получаю фулл в сторону второго, а со второго только локальный префикс? Выглядит это так: на первой цыске: C7609S-I#sh ip bgp vpnv4 vrf INET neighbors 172.16.50.234 received-routes BGP table version is 171198752, local router ID is 10.10.1.34 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 43031:1 (default for vrf INET) * i 0.0.0.0 172.16.50.234 0 100 0 i * i 85.202.0.0/20 172.16.50.234 0 100 0 i Total number of prefixes 2 на второй цыске: C7606S-II#sh ip bgp vpnv4 vrf INET neighbor 172.16.50.134 received-routes BGP table version is 5516953, local router ID is 192.168.0.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 43031:1 (default for vrf INET) * i 1.0.0.0/24 172.16.50.134 0 100 0 3216 2914 13335 i * i 1.0.4.0/24 172.16.50.134 0 100 0 3216 6939 4826 38803 56203 i * i 1.0.4.0/22 172.16.50.134 0 100 0 3216 6939 4826 38803 56203 i * i 1.0.5.0/24 172.16.50.134 0 100 0 3216 6939 4826 38803 56203 i * i 1.0.6.0/24 172.16.50.134 0 100 0 3216 6939 4826 38803 56203 i * i 1.0.7.0/24 172.16.50.134 0 100 0 3216 6939 4826 38803 56203 i * i 1.0.16.0/24 172.16.50.134 0 100 0 3216 1273 2497 2519 i При этом на обоих цысках разные аплинки и загружен полный фул. По идее я на первой должен видеть фулл от второй? разве нет? вот если что конфиги пиров: хм, частично ответ есть, нет анонсов в сторону первой цыски, но почему? ведь таблица полная и тут свой отдельный аплинк со своими бестами..... А можете показать show ip bgp 80.255.80.0/20 с core2? Поглядеть какой он best. Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
catalist Опубликовано 21 июля, 2018 · Жалоба Вопрос по отсутсвующим анонсам между цысками снимается. Заметили вот такую фигню, что если добавить статику через 4го аплинка на второй цыске то потери уходят. Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
catalist Опубликовано 21 июля, 2018 · Жалоба Проблему удалось решить сделав откат иоса на c7600rsp72043-adventerprisek9-mz.122-33.SRE12.bin Спасибо Atlant Что странно так как на первом роутере стоит иос c7600rsp72043-adventerprisek9-mz.154-3.S6.bin и этот же иос стоял на второй в момент глюка. Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...