Multicast xconnect tunnel

Problemy związane z routingiem
Wiadomość
Autor
averon91
fresh
fresh
Posty: 6
Rejestracja: 10 wrz 2019, 13:53

Multicast xconnect tunnel

#1

#1 Post autor: averon91 »

Cześć wszystkim,
Mam następujący problem. Mam C892FSP-K9, portem 1 i 2 wchodzi mi ten sam multicast, następnie jest tunelowany poprzez xconnect i wychodzi portem 9.
Problem w tym że ruch z portu 1 + ruch z portu 2 nie równa się portu 9 - Na porcie 9 jest za mały.
Odbija się to na jakości dźwięku na nadajnikach - nie da się go wykorzystać.
Jeżeli wyłączę jeden port np. 1, to ruch z portu 2 równa się portowi 9 i jakość dźwięku jest prawidłowa.
Proszę o informację co jest tego powodem, czy i jak można to ewentualnie naprawić. Z góry dziękuję.

GigabitEthernet1 is up, line protocol is up
Hardware is Gigabit Ethernet, address is a023.9f07.e7ae (bia a023.9f07.e7ae)
Description: debica
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 3/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:01, output never, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops:0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 1341000 bits/sec, 227 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
64238299 packets input, 47314933668 bytes, 0 no buffer
Received 47981 broadcasts (64100512 multicasts)
0 runts, 0 giants, 0 throttles
1005 input errors, 897 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 0 multicast, 0 pause input
0 input packets with dribble condition detected
78594 packets output, 9401842 bytes, 0 underruns
0 output errors, 0 collisions, 2 interface resets
9388 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
2 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out



cisco-ost#show interfaces gigabitEthernet 2

GigabitEthernet2 is up, line protocol is up
Hardware is Gigabit Ethernet, address is a023.9f07.e7af (bia a023.9f07.e7af)
Description: czestochowa
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 3/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:01, output never, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 1342000 bits/sec, 227 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
64216586 packets input, 47292275448 bytes, 0 no buffer
Received 47992 broadcasts (64077983 multicasts)
0 runts, 0 giants, 0 throttles
929 input errors, 820 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 0 multicast, 0 pause input
0 input packets with dribble condition detected
65620 packets output, 7010885 bytes, 0 underruns
0 output errors, 0 collisions, 3 interface resets
9385 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out



cisco-ost#show interfaces gigabitEthernet 9

GigabitEthernet9 is up, line protocol is up
Hardware is PQ3_TSEC, address is a023.9f07.e7bf (bia a023.9f07.e7bf)
Internet address is 62.133.157.56/26
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full Duplex, 1Gbps, media type is RJ45
output flow-control is unsupported, input flow-control isunsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 1/75/0/0 (size/max/drops/flushes); Total output drops:665
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 1949000 bits/sec, 317 packets/sec
440569 packets input, 54265068 bytes, 0 no buffer
Received 212047 broadcasts (0 IP multicasts)
186 runts, 0 giants, 0 throttles
391 input errors, 391 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 9389 multicast, 0 pause input
89977049 packets output, 69448931867 bytes, 0 underruns
0 output errors, 0 collisions, 3 interface resets
9389 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
1 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out
_____________________________________________________________________________________________
Averon91

lbromirs
CCIE
CCIE
Posty: 4101
Rejestracja: 30 lis 2006, 08:44

Re: Multicast xconnect tunnel

#2

#2 Post autor: lbromirs »

Jeśli dobrze pamiętam 892FSP, pierwsze dwa porty są "prawdziwymi" portami L3, pozostałe są podłączone do przełącznika wewnętrznego. To co opisujesz, wygląda na problem z wydajnością przejścia między jednym a drugim portem. Znowu, nie pamiętam dokładnie, ale mam wrażenie że port między zabudowanym przełącznikiem a CPU był o przepustowości typu 10 albo 100Mbit/s.

Ale zanim pójdziemy w tą stronę, co robi CPU jak masz trzy porty aktywne? I po co w ogóle ten xconnect, skoro to jeden router?

averon91
fresh
fresh
Posty: 6
Rejestracja: 10 wrz 2019, 13:53

Re: Multicast xconnect tunnel

#3

#3 Post autor: averon91 »

Aktualnie na CPU:
CPU utilization for five seconds: 3%/0%; one minute: 2%; five minutes: 2%
_____________________________________________________________________________________________
Averon91

qrczak
wannabe
wannabe
Posty: 95
Rejestracja: 07 lis 2009, 17:36

Re: Multicast xconnect tunnel

#4

#4 Post autor: qrczak »

Też mam trochę tych routerów w sieci i faktycznie wydajność przełączania/routingu pomiędzy portami 0-7 a 8 i 9 była gorsza niż pomiędzy 8 a 9.
Z tunelowaniem multicastu też miałem problemy, ale u mnie w ogóle nie przechodził.

bodycount
fresh
fresh
Posty: 3
Rejestracja: 23 kwie 2013, 00:48

Re: Multicast xconnect tunnel

#5

#5 Post autor: bodycount »

Na pierwszy rzut oka widzę różnicę w BTW na portach, różnicę w DLY i dużą ilość błędów CRC.

ODPOWIEDZ