Problema de rede no vsat

3

Na minha arquitetura servidor-cliente, eu multicast 100 MB para muitos clientes do servidor via link de satélite. Passagem de rede é através de 5 saltos. Eu tenho o link de largura de banda de 10 Mbps (ou seja, 1250 Kilo Byte por segundo).

Quando eu faço multicast do primeiro arquivo para muitos clientes, o primeiro salto é que a velocidade de entrada é de ~ 9,0 mbps, mas o receptor tem velocidade de apenas ~ 4,2 mbps. Todos os clientes são 10MB half duplex.

Eu posso ver, há baixo uso de rede; Mas eu não sei exatamente onde. Se o servidor estiver enviando na velocidade de ~ 9,0 mbps, o cliente deve ter a mesma velocidade.

Estou usando o UDP confiável para multicast.

Existe alguma maneira de descobrir qual é o uso de largura de banda de entrada e saída de cada salto (para uma porta específica)? Existe alguma ferramenta / utilitário / aplicativo que possa servir ao propósito.

Todos os saltos estão em local remoto, então não é possível ir até lá.

    
por SHW 09.06.2012 / 13:46

2 respostas

1

Ferramentas

Is there any way to find out, what is the incoming and outgoing bandwidth usage of each hop (for a particular port.)?

A menos que você possua o elemento de rede, ou o provedor de WAN de terceiros divulgue as informações, você só poderá estimar a largura de banda de entrada e saída de ponta a ponta ao longo de um caminho de rede. Veja abaixo.

Is there exist any tool/utility/application who can serve the purpose.

  • Para o caminho "estimativa de largura de banda disponível" que mencionei acima, você deve revisar o arquivo de TCP de ponta a ponta de Sally Floyd / Ferramentas de estimativa de largura de banda IP . Estou mais familiarizado com yaz , que é baseado em pacotes UDP unicast.
  • Para ver se você está descartando pacotes em qualquer determinado roteador hop (que é o seu problema final), você pode usar mtr ; Há também um cliente win-mtr , que suporta o Windows. Para ver um exemplo simples de como eu normalmente soluciono problemas de pacotes, veja minha resposta no Superusuário . Essa técnica é mais eficiente em fornecer visibilidade aos pacotes no primeiro ponto em que eles acontecem (já que mtr não dá muita visibilidade a quedas posteriores além desse ponto até que você corrija o primeiro).

Uma técnica simples para obter uma estimativa aproximada de onde estão suas gotas é instalar mtr no seu servidor e depois Execute uma sessão mtr para rastrear a perda de pacotes para um único cliente multicast enquanto estiver transferindo seu arquivo 100M. Para medições mais precisas, você pode usar iperf para saturar a rede em vez do arquivo 100M (contanto que você coordene o tempo de inatividade da WAN apropriadamente com outros grupos da empresa).

Diagrama

O resto da minha resposta vai usar o seguinte diagrama para referência:

Nodiagrama:

  • R1aR5sãoroteadoresIP
  • S1eS5sãocomutadoresEthernet
  • Oservidorazulem172.16.1.0/24representaseuservidormulticast.
  • C51aC55sãoexemplosdereceptoresmulticast(podeserqualquernúmerodereceptores)

OsdetalhesdaWANentreR1eR5geralmentenãoimportammuito,sóprecisamosdeumatopologiadelinhadebase,entãoestamosnamesmapágina.

Peloqueeupossodizer,vocêestádizendoqueainterfacedoR1em172.16.1.0/24mostracercade9Mbpsenquantovocêestáenviandooarquivode100MBeainterfacedoR5em172.16.5.0/24mostracercade4.2MbpsquandoosclientesestãorecebendoviamulticastUDPconfiável.Quandovocêdizconfiável,presumoquesignificaqueexistealgumtipodeseqüenciamentodepacotesembutidonoserviçomulticast,eoaplicativoclientesabecomosolicitarumaretransmissãodoservidor.

Diagnóstico

Seestadescriçãoestivercorreta,existemalgumascausasprováveis:

  1. VinculeocongestionamentoaalgumlugardepoisdeR1,comovocêafirmouemsuapergunta.
  2. LimitaçõesdedesempenhodequalquerdispositivoRxnocaminho,incluindoR1eR5(comoatingirumlimitededesempenhodereplicaçãomulticast)
  3. Vocêestáatingindoumalimitaçãodetaxadetransferênciadeethernethalf-duplexde10M.

Ascausas1ou2serãoreveladasusando mtr . No entanto, a causa 3 é digna de um pouco mais de discussão. Os links de 10 M / meia fornecem um máximo de 10 Mbps para uma transferência unidirecional . Se você estiver enviando tráfego bidirecional em um link de 10 M / meia, normalmente verá substancialmente menos de 10 Mbps devido à dinâmica de CSMA / CD da ethernet . Em um link half-duplex, a ethernet não pode transmitir e receber simultaneamente; se as estações tentarem fazer isso, seus quadros irão colidir, e ambas as estações atrasarão a retransmissão por um tempo aleatório.

Eu testo redes para ganhar a vida. Quando testei throughput bidirecional efetivo de links de 10M / half, geralmente vejo entre 3Mbps e 4Mbps. Os números que você compartilha acima são muito parecidos. Eu não tenho provas suficientes para fazer uma acusação, mas eu não ficaria surpreso se seus links 10M / half forem o problema; particularmente se o link entre R5 e S5 for 10M / half.

    
por 13.06.2012 / 14:57
0

Supondo que você possa acessar remotamente (e ter uma conta privilegiada) em cada máquina, você pode tentar o utilitário iftop .

Algo como iftop -f udp -F "port <port> and host <previous hop>" deve fornecer todo o tráfego udp do host fornecido na porta especificada. Veja as man pages para mais informações sobre a construção de filtros. (Também de nota: supondo que você tenha acesso à rede, você também pode monitorar toda a rede especificando a rede / máscara de rede da seguinte forma: -F 10.0.0.0/255.0.0.0 )

Se você não quer / não pode instalar o iftop, mas tem acesso ao iptables, você também pode fazer com que ele registre seu tráfego e use-o para calcular a largura de banda.

Primeiro, configure uma cadeia para seu aplicativo e encaminhe todo o tráfego de entrada / saída:

iptables -N $CHAIN && iptables -A FORWARD

Em seguida, configure uma regra para envio / download separado:

# Downloads
iptables -A FORWARD -d $PREVIOUSHOP -j $CHAIN

# Town A Uploads
iptables -A FORWARD -s $PREVIOUSHOP -j $CHAIN'

Agora, veja o uso de tráfego para cada cadeia: iptables -L -v -n

    
por 12.06.2012 / 21:46