Size: a a a

2020 July 14

ПК

Паша Калугин... in ntwrk
*   Trying 87.250.250.242:80...
* Connected to ya.ru (87.250.250.242) port 80 (#0)
> GET / HTTP/1.1
> Host: ya.ru
> User-Agent: curl/7.71.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 302 Found
< Cache-Control: no-cache,no-store,max-age=0,must-revalidate
< Content-Length: 0
< Date: Tue, 14 Jul 2020 08:01:34 GMT
< Expires: Tue, 14 Jul 2020 08:01:35 GMT
< Last-Modified: Tue, 14 Jul 2020 08:01:35 GMT
< Location: https://ya.ru/
< P3P: policyref="/w3c/p3p.xml", CP="NON DSP ADM DEV PSD IVDo OUR IND STP PHY PRE NAV UNI"
< Set-Cookie: yandexuid=2621531571594713694; Expires=Fri, 12-Jul-2030 08:01:34 GMT; Domain=.ya.ru; Path=/
< X-Content-Type-Options: nosniff
< X-Cache: MISS from localhost
< X-Cache-Lookup: MISS from localhost:3128
< Via: 1.1 localhost (squid/3.5.27)
< Connection: keep-alive
<
* Connection #0 to host ya.ru left intact
источник

AD

Anton Danilov in ntwrk
Паша Калугин
роутер не мой, доступа к нему нет
ну если трассировка с хоста в локалке, то значит, что на роутере настроено что-то наподобие
REDIRECT
из
iptables
, которое заворачивает пакеты на какой-то локальный прокси. В противном случае (например, при фин блокировке провайдера) первым бы хостом в трассировке был серый адрес самого шлюза. Обращайся к тому, у кого есть доступ к шлюзу. Можно ещё сделать
traceroute -n mail.google.com
и посмотреть, отличается ли она от той, что сделана с помощью tcp-трафика.
источник

RM

Roman Melnyk in ntwrk
Всем привет.
Есть extreme x670-48x, некоторые порты не поднимаються, а точнее первых 4, все остальные работают.
Но, если включить их перемычкой, rx <-> tx замкнуть между собой - линк есть. Это стенд на столе, включаем его в lb6m прошитую в брокейд, даками cisco.
Так же пробовали sfp+ модуля от intel - результат тот же.
Ещё момент, если вот эти 4 порта включить не в брокейд а в другой свитч, dell powerconnect 5548 - линк есть.
источник

S

Stanislav in ntwrk
там порты случаем не зажаты в 1 гиг? а то я видел такое, после того как гиговый модуль воткнули, экстрим решил запомнить что на 1гиг порт работает. при этом порт в 10ж поднимался, но трафик выше 1 гиг не проходил)
источник

ПК

Паша Калугин... in ntwrk
источник

RM

Roman Melnyk in ntwrk
Нет, порты в 10г
источник

RM

Roman Melnyk in ntwrk
Так и прикол в том что в другом свиче эти 4 порта поднимаються нормально
источник

RM

Roman Melnyk in ntwrk
Прошивка Extreme XOS 16.2.5.4 (16.2.5.4-patch1-5 Sep 26 2018)
источник

S

Stanislav in ntwrk
ну ты покажи sh ports 1-4 conf
источник

ПК

Паша Калугин... in ntwrk
Anton Danilov
ну если трассировка с хоста в локалке, то значит, что на роутере настроено что-то наподобие
REDIRECT
из
iptables
, которое заворачивает пакеты на какой-то локальный прокси. В противном случае (например, при фин блокировке провайдера) первым бы хостом в трассировке был серый адрес самого шлюза. Обращайся к тому, у кого есть доступ к шлюзу. Можно ещё сделать
traceroute -n mail.google.com
и посмотреть, отличается ли она от той, что сделана с помощью tcp-трафика.
pavelthebest@ppc ~> traceroute -n mail.google.com
traceroute to mail.google.com (64.233.185.19), 30 hops max, 60 byte packets
1  10.21.128.5  2.972 ms  3.069 ms  3.533 ms
2  188.170.214.33  4.722 ms  5.389 ms  5.918 ms
3  188.170.214.65  6.010 ms  6.127 ms  6.889 ms
4  78.25.77.17  6.705 ms  7.311 ms  7.427 ms
5  10.222.23.201  37.282 ms  37.324 ms 10.222.23.57  37.286 ms
6  * * *
7  * * *
8  10.222.36.133  35.488 ms 10.222.36.129  35.392 ms  35.233 ms
9  83.169.204.113  34.559 ms  34.439 ms  34.056 ms
10  178.176.152.61  34.036 ms 37.29.3.250  34.456 ms 178.176.152.61  37.821 ms
11  108.170.250.113  34.388 ms 108.170.250.83  41.788 ms 108.170.250.146  33.257 ms
12  209.85.250.112  53.977 ms 209.85.249.238  53.982 ms 209.85.250.112  53.949 ms
13  209.85.142.51  66.197 ms  65.622 ms 172.253.50.211  70.468 ms
14  216.239.47.100  72.567 ms 172.253.51.198  73.360 ms 216.239.47.206  72.955 ms
15  172.253.66.30  76.128 ms 209.85.254.120  76.360 ms 172.253.66.14  75.788 ms
16  108.170.237.243  81.601 ms 209.85.245.231  82.551 ms 108.170.234.119  83.035 ms
17  172.253.65.164  204.801 ms 142.250.59.180  202.538 ms 142.250.59.182  199.366 ms
18  108.170.236.133  199.042 ms 142.250.57.138  188.016 ms 172.253.71.184  176.211 ms
19  216.239.48.6  175.752 ms  170.205 ms 216.239.48.9  163.134 ms
20  216.239.40.118  172.435 ms 216.239.40.130  203.638 ms  201.466 ms
21  209.85.240.202  203.367 ms 108.170.230.65  200.828 ms 108.170.230.92  200.891 ms
22  216.239.48.63  203.094 ms 216.239.47.117  203.112 ms 209.85.253.101  203.532 ms
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
источник

A

Alexey in ntwrk
трейс с марса?
источник

RM

Roman Melnyk in ntwrk
Stanislav
ну ты покажи sh ports 1-4 conf
источник

RM

Roman Melnyk in ntwrk
А вот это 9й порт который поднимаеться нормально
источник

RM

Roman Melnyk in ntwrk
Ну и вывод debug hal
источник

ПК

Паша Калугин... in ntwrk
Anton Danilov
ну если трассировка с хоста в локалке, то значит, что на роутере настроено что-то наподобие
REDIRECT
из
iptables
, которое заворачивает пакеты на какой-то локальный прокси. В противном случае (например, при фин блокировке провайдера) первым бы хостом в трассировке был серый адрес самого шлюза. Обращайся к тому, у кого есть доступ к шлюзу. Можно ещё сделать
traceroute -n mail.google.com
и посмотреть, отличается ли она от той, что сделана с помощью tcp-трафика.
А почему может ломаться только у меня?
источник

S

Stanislav in ntwrk
а если лаг разобрать?
источник

S

Stanislav in ntwrk
у меня ни разу не было такого, чтобы линк не поднимался до куда-либо на x670, и модули он все жрал
источник

RM

Roman Melnyk in ntwrk
Разбирал, так же
источник

VA

Vladimir Antipov in ntwrk
так тут даки
источник

ПК

Паша Калугин... in ntwrk
Тут входящий трафик тоже включён
источник