Modelagem básica de saída do Catalyst 3560


8

Temos um provedor de serviços (e não podemos mudar de provedor) que está nos oferecendo uma conexão no estilo "metro ethernet" entre dois de nossos locais. Em cada extremidade, conectamos uma porta Ethernet no switch de um provedor e eles enviam os quadros de um lado para outro. Nós obtemos uma certa largura de banda com eles e eles estão descartando pacotes que estouram sobre a largura de banda.

Tenho certeza de que uma boa maneira de não ultrapassar seu limite e evitar a queda de pacotes é modelar nosso tráfego para que caiba abaixo do limite. Acho que estou muito perto de entender como fazer isso, mas é bem complicado. Temos um Cisco Catalyst 3560X em cada lado da conexão.

Se eu quiser diminuir o tráfego para 50 Mbps no túnel, parece que a maneira certa (talvez apenas?) De fazê-lo é usar a modelagem nas filas de saída das portas usadas para o link em cada um dos nossos 3560s. Não precisamos marcar nem classificar nenhum tráfego, apenas queremos moldar tudo para 50 Mbps. Aqui está um exemplo de configuração de porta agora:

interface GigabitEthernet0/1
 speed auto 10 100
 spanning-tree portfast disable

Eu sei que vou querer fazer mls qosno modo de configuração global. Então eu deveria ver algo assim:

[Switch name]# show mls qos int gig0/1 queueing
GigabitEthernet0/1 
Egress Priority Queue : disabled
Shaped queue weights (absolute) :  25 0 0 0
Shared queue weights  :  25 25 25 25
The port bandwidth limit : 100  (Operational Bandwidth:100.0)
The port is mapped to qset : 1

Até agora, meu entendimento é o seguinte, sinta-se à vontade para me corrigir:

  • Todo o tráfego será CoS 0 / não marcado e, por padrão, entrará na fila de saída 2.
  • A fila de saída 2 está compartilhando a largura de banda igualmente com a fila 3 e 4, e o peso da fila 1 é ignorado.
  • A fila de saída 1 é modelada em 1/25 da largura de banda da interface, portanto, 4 Mbps neste caso.

Então, eu entendo que as filas 2 a 4 têm 33% da largura de banda garantida (33 Mbps, certo?) E a fila 1 tem formato de 4 Mbps. Minha primeira pergunta é:

Com essa configuração padrão, se apenas a fila 2 for usada , quanta largura de banda será obtida? 100 Mbps? E se todas as filas fossem totalmente utilizadas, a fila 1 teria 4 Mbps e as filas 2 a 4 teriam 32 Mbps (100 - 4 = 96/3 = 32)?

E agora a verdadeira questão:

Para moldar todo o tráfego de saída não classificado para caber em 50 Mbps, posso simplesmente entrar
srr-queue bandwidth shape 0 2 0 0na interface em questão e pronto?

Parece que os limites de compartilhamento e modelagem de filas não são garantidos, portanto, talvez seja necessário diminuir para 45 Mbps nominais na fila de saída, se for necessário evitar estourar mais de 50 Mbps. Posso fazer isso executando apenas srr-queue bandwidth limit 90combinando com a configuração acima? Seria o mesmo usar:

srr-queue bandwidth shape 0 1 0 0
srr-queue bandwidth limit 45

Essa forma ficaria na fila de 2 a 45 Mbps (em uma interface de 100 Mbps)?

Depois que eu entendo isso, acho que minha próxima parada é classificar alocações e limites de buffer, para que minha configuração caia o menor número possível de pacotes, certo? Essa pode ser uma pergunta separada, se necessário, mas, na verdade, isso parece fazer muito mais sentido até agora.


11
Uma observação secundária à sua pergunta: com base na experiência com o metro ethernet, convém colocar roteadores de cada lado e executar um protocolo de roteamento e BFD. Quando o link for desativado, os dois lados acharão que ainda está ativo, pois a conexão com o equipamento de telecomunicações ainda estará ativa. Isso nos deu muita frustração no passado.
Ron Maupin

@RonMaupin Já faz parte do plano, obrigado pela dica! Como parte do plano, não inseriremos equipamentos, usaremos a capacidade da camada 3 dos comutadores para rotear de um local para outro. Não queremos que um grande domínio de broadcast atravesse um link WAN relativamente mais lento.
Todd Wilcox

ESTÁ BEM. Não sei se você pode executar o BFD nesses switches. Essa é realmente a única solução que encontramos para descobrir o link em pouco tempo. Os protocolos de roteamento levarão um tempo para perceber que não há conexão com a outra extremidade, pois os links ainda aparecerão como ativos / inativos no equipamento.
Ron Maupin

Oh, eu não estava pensando tanto em resiliência quanto em roteamento, em vez de transmitir. Atualmente, não temos nada a que fazer failover. Se isso acontecer, acho que o EIGRP pode ser suficiente. De qualquer forma, está mais longe no futuro a partir de onde estamos agora.
Todd Wilcox

ESTÁ BEM. Eu estava apenas tentando transmitir alguma experiência [ruim] com o metro ethernet. Isso também é um problema com outras operadoras ethernet. Algumas delas são realmente sobre circuitos TDM, e os circuitos terminam em equipamentos portadores que são ativados / desativados, mesmo quando o circuito TDM está inoperante. O BFD realmente ajuda nisso, mas é limitado nos dispositivos que podem usá-lo.
Ron Maupin

Respostas:


6

E agora a verdadeira questão:

Para moldar todo o tráfego de saída não classificado para caber em 50 Mbps, posso simplesmente entrar srr-queue bandwidth shape 0 2 0 0na interface em questão e pronto?

Parece que os limites de compartilhamento e modelagem de filas não são garantidos, portanto, talvez seja necessário diminuir para 45 Mbps nominais na fila de saída, se for necessário evitar estourar mais de 50 Mbps. Posso fazer isso executando apenas srr-queue bandwidth limit 90combinando com a configuração acima?

Resposta curta: Sim, isso é tudo o que é necessário para fazer a modelagem de saída.

Obviamente, mls qos devem ser inseridos, mas, uma vez configurados, a modelagem de saída em uma porta é tão simples quanto:

  1. Ajuste a taxa da linha, se necessário ( speed 10 100 1000)
  2. Defina o limite da largura de banda, se necessário ( srr-queue bandwidth limit 10-90, o último argumento é a porcentagem da taxa de linha para limitar a largura de banda)
  3. Insira o peso de modelagem para a fila 2 na interface ( srr-queue bandwidth shape 0 x 0 0onde o limite da largura de banda (se aplicado) ou a taxa da linha (se não houver limite) dividida por xé a largura de banda para a qual o tráfego é configurado)

Fonte:
Hoje, peguei 3560 extra, coloquei um computador extra em cada uma das duas portas e comecei a fazer alterações na configuração enquanto copiava os arquivos entre os dois computadores, observando a taxa estimada de cópias e fazendo algumas contas para confirmar os números combinar.


0

É bem fácil. Se você possui RTP ou algum LLQ, pode ser necessário executar uma política aninhada, mas se não:

class-map match-any myRate
 match any

policy-map myRatePolicy
 class myRate
  shape average 50m

interface GigabitEthernet0/1
 service-policy output myRatePolicy

Você pode explicar se esse método de modelagem funciona de maneira diferente do método da minha resposta? Além disso, você sabe em quais plataformas isso é suportado?
Todd Wilcox

Parece que no Catalyst 3560, match anynão é um subcomando válido de mapa de classe, mas acho que match protocol ipfaz a mesma coisa. O shapesubcomando de mapa de classe de mapa de políticas não está disponível no meu Catalyst 3560. Portanto, essas são boas informações que não respondem à minha pergunta. Obrigado por responder, no entanto.
22416 Todd Wilcox

O suporte ao recurso @ToddWilcox é um bom ponto. Certo, o 3560 ( não está mais sendo vendido ) não suporta esse estilo mais recente de configuração do IOS-XE. Além disso, uma rápida pesquisa no Google mostra alguns problemas relatados com a configuração desse comutador antigo. Você pode se beneficiar da atualização.
22616 Ronnie Royston

Temos nove 3560 em serviço e um orçamento que precisamos atender e muitas outras necessidades na categoria de equipamentos de rede. Além disso, o único "problema relatado" que posso encontrar nesse link é a ressalva de que ele não se limita à porcentagem exata que você especificar, mas sim em incrementos de 6 .. um .. kbps? Algo parecido. Então você tem que deixar um pouco de espaço extra. Mas a diferença é realmente relatada pela saída de, show mls qos int <type><#> queueingassim você não precisa adivinhar.
21416 Todd Wilcox

Além disso, apesar de ter feito meus testes em uma EoL 3560E, tenho certeza de que sua configuração é compatível com o 3560CX , que ainda está em produção e é o comutador real que temos a caminho para esse aplicativo, pois precisamos apenas de uma baixa switch de borda de contagem de portas para interface com nosso provedor.
21416 Todd Wilcox
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.