Hubs / switches que substituem os switches?

Question

Aqui está o problema ... nós temos uma rede com muitos switches da Cisco.

Alguém conectou um hub na rede e, em seguida, começamos a ver um comportamento "estranho"; erros na comunicação entre clientes e servidores, ou tempos limites de rede, queda de conexões de rede, etc. Parecia que, de alguma forma, esse hub (ou switch SOHO) estava particularmente enlouquecendo nossos switches da série Cisco 3700.

Desconecte o hub ou o switch SOHO do tipo netgear e as coisas se acalmarem novamente.

Estamos no processo de tentar obter um servidor de registro centralizado para SNMP e gerenciamento, etc., para ver se podemos interceptar erros ou restringir quando alguém faz esse tipo de coisa sem o nosso conhecimento, porque as coisas parecem funcionar na maioria das vezes, sem problemas, só temos incidentes excêntricos esquisitos em interruptores específicos que parecem não ter nenhuma explicação até descobrirmos que alguém decidiu tomar as coisas em suas próprias mãos para expandir as portas disponíveis em seu quarto.

Sem entrar em alterações de procedimento ou bloqueio de portas ou "em nossa organização eles seriam demitidos" respostas, alguém pode explicar por que adicionar um pequeno switch ou hub, não necessariamente um roteador SOHO (mesmo um hub estúpido aparentemente causou o 3700 enlouquecer) enviando a solicitação DHCP, causará problemas? O chefe disse que é porque a Cisco está ficando confusa porque o hub / switch desonesto está unindo vários MAC's / IPs em uma porta nos switches da Cisco e eles apenas engasgam com isso, mas eu achei que as tabelas de roteamento deles seriam capazes de lidar com várias máquinas para o porto. Alguém vê esse comportamento antes e tem uma explicação mais clara do que está acontecendo?

Gostaria de saber para solução de problemas futura e melhor compreensão de que apenas acenando minha mão e dizendo "você simplesmente não pode".

Aqui está um show executado

Current configuration : 25591 bytes

!

version 12.2

no service pad

service timestamps debug datetime msec

service timestamps log datetime msec

service password-encryption

!

hostname ###########

!

boot-start-marker

boot-end-marker

!

enable secret 5 ############

!

!

!

no aaa new-model

switch 1 provision ws-c3750g-24ps

switch 2 provision ws-c3750-48ts

switch 3 provision ws-c3750-48ts

switch 4 provision ws-c3750-48ts

switch 5 provision ws-c3750-48ts

system mtu routing 1500

authentication mac-move permit

ip subnet-zero

ip routing

!

!

!

mls qos map policed-dscp 24 26 46 to 0

mls qos map cos-dscp 0 8 16 24 32 46 48 56

mls qos srr-queue input bandwidth 90 10

mls qos srr-queue input threshold 1 8 16

mls qos srr-queue input threshold 2 34 66

mls qos srr-queue input buffers 67 33

mls qos srr-queue input cos-map queue 1 threshold 2 1

mls qos srr-queue input cos-map queue 1 threshold 3 0

mls qos srr-queue input cos-map queue 2 threshold 1 2

mls qos srr-queue input cos-map queue 2 threshold 2 4 6 7

mls qos srr-queue input cos-map queue 2 threshold 3 3 5

mls qos srr-queue input dscp-map queue 1 threshold 2 9 10 11 12 13 14 15

mls qos srr-queue input dscp-map queue 1 threshold 3 0 1 2 3 4 5 6 7

mls qos srr-queue input dscp-map queue 1 threshold 3 32

mls qos srr-queue input dscp-map queue 2 threshold 1 16 17 18 19 20 21 22 23

mls qos srr-queue input dscp-map queue 2 threshold 2 33 34 35 36 37 38 39 48

mls qos srr-queue input dscp-map queue 2 threshold 2 49 50 51 52 53 54 55 56

mls qos srr-queue input dscp-map queue 2 threshold 2 57 58 59 60 61 62 63

mls qos srr-queue input dscp-map queue 2 threshold 3 24 25 26 27 28 29 30 31

mls qos srr-queue input dscp-map queue 2 threshold 3 40 41 42 43 44 45 46 47

mls qos srr-queue output cos-map queue 1 threshold 3 5

mls qos srr-queue output cos-map queue 2 threshold 3 3 6 7

mls qos srr-queue output cos-map queue 3 threshold 3 2 4

mls qos srr-queue output cos-map queue 4 threshold 2 1

mls qos srr-queue output cos-map queue 4 threshold 3 0

mls qos srr-queue output dscp-map queue 1 threshold 3 40 41 42 43 44 45 46 47

mls qos srr-queue output dscp-map queue 2 threshold 3 24 25 26 27 28 29 30 31

mls qos srr-queue output dscp-map queue 2 threshold 3 48 49 50 51 52 53 54 55

mls qos srr-queue output dscp-map queue 2 threshold 3 56 57 58 59 60 61 62 63

mls qos srr-queue output dscp-map queue 3 threshold 3 16 17 18 19 20 21 22 23

mls qos srr-queue output dscp-map queue 3 threshold 3 32 33 34 35 36 37 38 39

mls qos srr-queue output dscp-map queue 4 threshold 1 8

mls qos srr-queue output dscp-map queue 4 threshold 2 9 10 11 12 13 14 15

mls qos srr-queue output dscp-map queue 4 threshold 3 0 1 2 3 4 5 6 7

mls qos queue-set output 1 threshold 1 138 138 92 138

mls qos queue-set output 1 threshold 2 138 138 92 400

mls qos queue-set output 1 threshold 3 36 77 100 318

mls qos queue-set output 1 threshold 4 20 50 67 400

mls qos queue-set output 2 threshold 1 149 149 100 149

mls qos queue-set output 2 threshold 2 118 118 100 235

mls qos queue-set output 2 threshold 3 41 68 100 272

mls qos queue-set output 2 threshold 4 42 72 100 242

mls qos queue-set output 1 buffers 10 10 26 54

mls qos queue-set output 2 buffers 16 6 17 61

mls qos

!

!

!

!

!

spanning-tree mode pvst

spanning-tree etherchannel guard misconfig

spanning-tree extend system-id

!

vlan internal allocation policy ascending

!

!

class-map match-all AutoQoS-VoIP-RTP-Trust

match ip dscp ef

class-map match-all AutoQoS-VoIP-Control-Trust

match ip dscp cs3 af31

!

!

policy-map AutoQoS-Police-CiscoPhone

class AutoQoS-VoIP-RTP-Trust

set dscp ef

police 320000 8000 exceed-action policed-dscp-transmit

class AutoQoS-VoIP-Control-Trust

set dscp cs3

police 32000 8000 exceed-action policed-dscp-transmit

!

!

!

!

interface GigabitEthernet1/0/1

switchport trunk encapsulation dot1q

switchport trunk native vlan 11

switchport mode trunk

spanning-tree portfast

!

!

!

interface GigabitEthernet5/0/1

!

interface GigabitEthernet5/0/2

!

interface GigabitEthernet5/0/3

!

interface GigabitEthernet5/0/4

!

interface Vlan1

ip address ############## 255.255.0.0

!

ip classless

ip route 0.0.0.0 0.0.0.0 ##############

no ip http server

no ip http secure-server

!

!

ip sla enable reaction-alerts

!

!

!

line con 0

line vty 0 4

password 7 ############

login

line vty 5 15

password 7 ############

login

!

end

    

Answer 1

Operamos algumas implementações de rede nas quais conexões de terceiros são vinculadas a um backbone centralizado da Cisco (por exemplo, configuração de multilocação). Eu posso dizer que vi vários dispositivos (bem, guetos) conectados à plataforma Catalyst, e se há uma coisa que eu aprendi, é que a plataforma Cisco é incrivelmente resistente a esses tipos de coisas.

Existe um calcanhar de Aquiles, no entanto: - Um hub barato na configuração certa pode facilmente derrubar uma rede inteira com uma tempestade de transmissão, e nem é culpa da plataforma Cisco. Descobri isso em uma configuração de produção, e a única pesquisa real que fiz foi encontrar a lata de lixo mais próxima para esse hub, mas eis como aconteceu:

1. Conecte o hub ao switch Cisco normalmente, com a porta de uplink
2. Conecte uma estação de trabalho a uma porta de hub (no nosso caso, executando o sistema operacional Windows XP, mas não importa)
3. Conecte duas outras portas juntas no hub (diretamente, com um único CAT5 ou indiretamente por outro hub).

Tudo funciona perfeitamente até que a estação de trabalho envia um anúncio de transmissão. Embora o hub e a Cisco sejam inteligentes o suficiente para evitar uma tempestade de transmissão em outros pacotes de transmissão, o hub não é inteligente o suficiente para detectar que duas de suas portas estão conectadas entre si e consumirá quase 100% de sua capacidade de processamento. para transmitir esse pacote em um loop infinito para frente e para trás, bem como todas as outras portas (ou seja, o uplink para o seu Cisco).

Se este for o caso em sua configuração, você notará que, em toda a sua rede, todas as portas naquela VLAN de transmissão ficarão malucas, até que o hub não consiga sustentar a capacidade e deixe cair o pacote de looping mágico (poderia alguns minutos, dependendo do tráfego concorrente), e então tudo volta ao normal.

Nesta situação, o SNMP não o ajudará, pois all as portas nessa VLAN ficam loucas pelo tráfego. No entanto, o Wireshark é seu amigo aqui, já que é fácil capturar qual IP (e às vezes o nome da máquina, se for um pacote de broadcast) causou o loop e localizar rapidamente o dispositivo ofensivo.

Pode não ser o caso exato em que você está passando, mas isso nos incomoda e pode lhe dar algumas ideias para pesquisar sua situação.

    

Answer 2

Pontos triviais, mas ainda não os vi mencionados:

Certifique-se de que suas portas de switch não sejam forçadas a full duplex, pois elas não funcionarão com hubs, se forem. Venha para pensar sobre isso - se o seu duplex ou as suas velocidades são forçadas, eles provavelmente não se conectarão corretamente a um switch do tipo Netgear que deseja negociar automaticamente

Certifique-se de que seus usuários não conectem o comutador a duas saídas de rede "para duplicar sua largura de banda".

Os switches da Cisco usados (e talvez ainda o façam - estou sem esse negócio agora) possuem um recurso chamado "Faststart". Para qualquer porta com Faststart ativada, o comutador não faria uma análise de árvore de abrangência completa e, ativando o recurso que o administrador "prometeu", não conectaria um comutador ou hub a essa porta. A razão para isso foi evitar o tempo limite de solicitação DHCP do PC cliente antes que a Cisco decidisse que era seguro ativar a porta. Você pode querer olhar para isso também. (Se eu me lembrei totalmente de tudo isso, peço desculpas antecipadas e espero que alguém com um conhecimento mais atualizado me corrija)

    

Answer 3

Se você estiver usando segurança de porta nas portas, você acabará com problemas sempre que houver mais do que o número esperado de MACs em uma determinada porta. Os principais problemas com furar hubs em uma rede comutada é que você acaba com domínios de colisão maiores (em vez de "switch + end unit", você acaba com "switch + all downstream no hub"), você pode causar loops de comutação ( se um hub estiver conectado a dois switches) e você pode acabar com uma rede grande o suficiente para que o domínio de broadcast seja "muito largo" (há uma necessidade absoluta de uma LAN ser pequena o suficiente para que os pacotes de um extremo ao outro será visto dentro do padrão Ethernet, já que os hubs tendem a ser piores ao deixar os pacotes no ritmo (sendo mais barato e tudo), que podem acabar sendo violados).

Se você tiver um domínio de colisão maior, qualquer coisa que tentar falar com / daquele domínio de colisão acabará tendo uma taxa de transferência menor.

Se você tiver loops de comutação, corre o risco de que tempestades e portas de transmissão aleatoriamente não encaminhem o tráfego, pois a Spanning Tree encerra as portas de encaminhamento.

Se você tiver um domínio de transmissão muito amplo, acabará tendo retransmissões falsas ao obter colisões atrasadas.

    

Answer 4

este é um problema clássico de comutação.
se você fizer o cisco ccnp ou apenas estudar o protocolo spanning tree, a resposta se tornará óbvia.

spanning tree impede loops- > ele faz isso determinando inicialmente uma "bridge raiz" - >
isso é determinado pela prioridade de switch mais baixa - > se houver um empate, os endereços mac dos switches serão comparados - > interruptor muitas vezes antigo equivale a menor mac endereço- > todo o tráfego na rede passa pelo antigo switch !!!! = acidente corrigido, definindo o seu comutador mais rápido / mais centralmente conectado com uma prioridade codificada que é mais baixa que o padrão.

por padrão cisco use per-vlan-spanning-tree (pvst +) comando: spanning-tree vlan 1-666 prioridade 24576

eu recomendo o uso do "spanning-tree mode rapid-pvst" de árvore de abrangência rápida que basicamente acelera muito as coisas

da wikipedia ( link )

A bridge raiz da spanning tree é a ponte com o menor ID de ponte (menor). Cada bridge tem um identificador único (ID) e um número de prioridade configurável; o ID da ponte contém os dois números. Para comparar dois IDs de ponte, a prioridade é comparada primeiro. Se duas pontes tiverem prioridade igual, os endereços MAC serão comparados. Por exemplo, se os switches A (MAC = 0200.0000.1111) e B (MAC = 0200.0000.2222) tiverem prioridade de 10, o switch A será selecionado como bridge raiz. Se os administradores de rede quiserem que o switch B se torne a bridge raiz, eles devem configurar sua prioridade para menos de 10.

    

Answer 5

Eu tive isso acontecendo em um ambiente não-Cisco. Um hub foi conectado a uma porta de rede que tinha três computadores conectados a ele. Um usuário, sem problemas. Quando todos os outros jogadores entraram para jogar, começaram a matar as conexões RDP com o Terminal Server. Puxe o hub para fora e o problema desaparece.