PIM/IGMP dla IPTV na Nexusie 3064PQ i problemy

Wiadomość

tonyb · #16

I'm going to apologize in advance for any translation issues, I'm going to post my reply in English and the google translate version.

We are trying to migrate our multicast switching to a Nexus 3064T are are seeing a very similar issue. Have you had any luck with TAC?

We were setting random IGMP group drop or stop routing. We were also seeing DropPackets increase for the copp-s-ipmcmiss class.

We found that we had several multcast sources that had invalid/incorrect source addresses, so they were failing RPF. When that happens the traffic gets kicked to the control plane and counts against your pps for that policy. It was also generating a TON of IGMP assert messages for those sources. We did not see this behavior from the same sources when we had a 3750X doing the routing, so I think this might be a bug. We had a TAC case open but this is a production network so it is hard to do much testing.

We fixed all the multicast sources to have IPs that are in the same network as the SVI for there attached vlan and after that the counter stopped going up and we haven't had any issues. I don't like the idea that a typo in a source IP can cause so many issues though, so we are looking for a more permanent solution.

This command was very helpful in finding the traffic that was hitting the control plane:

Kod: Zaznacz cały

ethanalyzer local interface inbound-low limit-captured-frames 20 detail | inc Internet

You might also want to check bug CSCus43770

----

Ide do góry przepraszamy za wszelkie kwestie tlumaczen, mam zamiar pisac moja odpowiedz w jezyku angielskim i translate wersje.

Staramy sie przeniesc nasza przelaczania multicast do Nexus 3064T sa Obserwujemy bardzo podobny problem. Czy mial szczescia z TAC?

Bylismy ustawienie grupy IGMP losowych lub zatrzymac spadek routingu. Bylismy równiez widzac DropPackets zwiekszyc do Copp-s-ipmcmiss klasy.

Okazalo sie, ze mielismy kilka multcast zródel, które mialy nieprawidlowe / niepoprawne adresy zródlowe, wiec zostaly one braku RPF. Kiedy tak sie dzieje ruch zostanie wyrzucony do plaszczyzny sterowania i liczy sie ze swoimi pps dla tej polityki. Byl on równiez generowanie TONA IGMP dochodzic wiadomosci dla tych zródel. Nie widzielismy tego zachowania z tych samych zródel, kiedy mielismy 3750X robi routing, wiec mysle, ze moze to byc blad. Mielismy przypadek TAC otwarty, ale jest to siec produkcji, tak trudno jest zrobic wiele badan.

Rozwiazano wszystkie zródla multicast miec adresy IP, które sa w tej samej sieci co SVI tam dolaczone do sieci VLAN i po, ze licznik zatrzymal sie dzieje sie i nie mielismy zadnych problemów. Nie podoba mi sie pomysl, ze literówka w zródle IP moze powodowac wiele problemów, choc, wiec szukamy bardziej trwalego rozwiazania.

Kod: Zaznacz cały

ethanalyzer local interface inbound-low limit-captured-frames 20 detail | inc Internet

Warto równiez sprawdzic blad CSCus43770

spider59 · #17

Witam

Znacie rozwiązanie problemu ? Od początku stycznia mam migrować właśnie na tego nexusa, narazie podłączone testowo 3 stb i raczej problemu nie obserwuje..

jankad · #18

Po długiej walce udało nam się przekonać TAC, że problem jest w sprzęcie a nie w middleware, stb, jakości strumieni itd, itp.

Od tego czasu co kilka dni proszę o kolejne, inaczej robione testy. Nieoficjalnie usłyszałem, że to jakiś problem w control plane i że wypuszczą poprawkę w nowym sofcie... nie wiadomo kiedy.
Jak na razie poświęciliśmy kilka godzin na wykonywanie różnych testów a nie specjalnie widać postęp.

Po ok 2 tygodniach, żeby klienci nas nie zjedli, musieliśmy wdrożyć obejście problemu.
Teraz sytuacja jest taka, że wpisaliśmy ponad 300 grup multicastowych statycznie na wszystkich portach i we wszystkich VLANach. Na czas testów musimy zdejmować te wpisy (ponad 1500 linii) a potem z powrotem ładować.
Niestety w kilku miejscach sieci mamy przełączniki, które nie radzą sobie z taką ilością przychodzących strumieni i tam nie mogliśmy zrobić statycznych wpisów. Ok 100 klientów potencjalnie jest nadal narażonych na problemy. Potencjalnie, bo wpisanie statycznie wszystkich grup na innych portach powoduje, że na tych bez wpisów przez większość czasu wszystko działa ok. To moim zdaniem potwierdza, że problem jest w control plane.

felix · #19

jankad pisze:Po długiej walce udało nam się przekonać TAC, że problem jest w sprzęcie a nie w middleware, stb, jakości strumieni itd, itp.

Od tego czasu co kilka dni proszę o kolejne, inaczej robione testy. Nieoficjalnie usłyszałem, że to jakiś problem w control plane i że wypuszczą poprawkę w nowym sofcie... nie wiadomo kiedy.
Jak na razie poświęciliśmy kilka godzin na wykonywanie różnych testów a nie specjalnie widać postęp.

Po ok 2 tygodniach, żeby klienci nas nie zjedli, musieliśmy wdrożyć obejście problemu.
Teraz sytuacja jest taka, że wpisaliśmy ponad 300 grup multicastowych statycznie na wszystkich portach i we wszystkich VLANach. Na czas testów musimy zdejmować te wpisy (ponad 1500 linii) a potem z powrotem ładować.
Niestety w kilku miejscach sieci mamy przełączniki, które nie radzą sobie z taką ilością przychodzących strumieni i tam nie mogliśmy zrobić statycznych wpisów. Ok 100 klientów potencjalnie jest nadal narażonych na problemy. Potencjalnie, bo wpisanie statycznie wszystkich grup na innych portach powoduje, że na tych bez wpisów przez większość czasu wszystko działa ok. To moim zdaniem potwierdza, że problem jest w control plane.

Hej. Korzystam z tego przełącznika od ponad roku. Poza unicastem mamy na tym PIM+OSFP, około 200 grup z dwóch różnych źródeł, 2000 STB, ok. 300 vlanów. Nie zauważyłem do tej porty żadnych problemów. Może problemem jest jakaś specyficzna konfiguracja lub specyficzna topologia sieci ?

BTW. Limit 400 pps dla ruchu igmp to chyba sporo.

jankad · #20

Ani topologia, ani konfiguracja nie wydają mi się jakieś specjalnie wymyślne.

W dużym skrócie do Nexusa podłączona jest transmisja dostawcy (SGT) z jednej strony oraz przełączniki dostępowe i OLT GPON z drugiej.

Nexus jest routerem PIM, w stronę dostawy jest skonfigurowany ip pim sparse-mode. Wygląda to tak:

Kod: Zaznacz cały

interface Vlan201
  description sgt
  no shutdown
  ip address 10.200.42.10/30
  ip pim sparse-mode

W stronę klientów konfiguracja wygląda tak:

Kod: Zaznacz cały

interface Vlan216
  description stb-chr17
  no shutdown
  no ip redirects
  ip address 10.200.128.1/26
  ip pim sparse-mode
  ip dhcp relay address 10.200.200.31

Do tego konfiguracja VLANów:

Kod: Zaznacz cały

vlan configuration 201,216
 ip igmp snooping version 2

Do porów Nexusa wpięte są linki do przełączników dostępowych oraz OLTa GPON.
Konfiguracja portu wygląda np tak:

Kod: Zaznacz cały

interface Ethernet1/6
  speed 1000
  description chr17
  switchport mode trunk
  switchport trunk allowed vlan 10,200,216
  load-interval counter 1 5

Przełączniki dostępowe to D-Linki serii DES-3028, DES-3526, DES-3528, OLT to Huawei MA5600T.
STB do przełączników dostępowych są wpięte za pomocą różnego typu RHG a do OLTa poprzez ONTy Huawei HG8245.
Dekodery to cała gama obsługiwanego przez SGT sprzętu, czyli Motorole, Zyxele, MAGi, Arisy.
Problem w przypadku Nexusa występuje w każdym miejscu sieci bez wzgl. na technologie, sprzęt po drodze i użyte dekodery.
Jak w miejsce Nexusa wraca Extreme, problem znika.

Obecnie Nexus pracuje z takim softem:

Kod: Zaznacz cały

Software
  BIOS:      version 3.4.0
  loader:    version N/A
  kickstart: version 6.0(2)U6(4)
  system:    version 6.0(2)U6(4)

Tak jak pisałem problem udało się obejść poprzez statyczne dodanie wszystkich grup multicastowych na wszystkich portach i we wszystkich VLANach... poza tymi, w których pracują przełączniki DES-3028 - jak się okazało te przełączniki nie radzą sobie z obsługą wszystkich grup

Dzięki temu, że na portach, do których jest wpięta zdecydowana większość STB (jakieś 80%) mamy statycznie włączone wszystkie grupy, problem z losowym wolnym przełączaniem kanałów przestał być dotkliwy również dla tych 20% STB za przełącznikami DES-3028.
Tyle, że to obejście a nie rozwiązanie problemu.

Rzeczywiście 400pps IGMP Snooping to chyba dużo - pojedyncze drupy pojawiły się dopiero jak zmniejszyłem limit w CoPP do 50pps.

felix · #21

U mnie wygląda to podobnie i nie rejestruje żadnych problemów z podłączaniem pod grupy:

Jedyna różnica:

Kod: Zaznacz cały

Software
  BIOS:      version 1.5.0
  loader:    version N/A
  kickstart: version 5.0(3)U3(2a)
  system:    version 5.0(3)U3(2a)

PatrykW · #22

I though that it is english forum ? hmmm ?

jankad · #23

I didn't noticed that. My original topic was in Technologia/Switching forum which is polish, I suppose.

spider59 · #24

Witam

A nie myślałeś żeby zrobić localne pim routery, np na OLTach ?
Co wygolę myślicie o tym rozwiązaniu ?

kgb · #25

Nadal nie udało się rozwiązać problemu?

W jaki sposób wystawiacie statycznie multicast? Każdy stream to jedna linia:
ip igmp static-oif x.x.x.x
czy router poprzez route-map?

jankad · #26

Tak, każdy strumień to osobna linia... w każdym VLANie i dla każdego portu.
Wygenerowaliśmy je oczywiście ze skryptu.

Wygląda na to, że supportowi udało się znaleźć skuteczne rozwiązanie.
Pomogła zmiana parametru:
hardware profile multicast soak-interval
na 50ms.

Testujemy to od tygodnia i wygląda dobrze.

kgb · #27

nie ma u mnie nic takiego:

Kod: Zaznacz cały

# hardware profile ?
  buffer        System buffer
  front         Port 1 QSFP/SFP+ settings
  multicast     Multicast settings
  openflow      Openflow
  parity-error  Change actions on detecting parity-error
  pfc           System level priority-flow-control settings
  portmode      QSFP port mode setting
  tcam          Configure tcam parameters
  ucast6        Unicast ipv6 settings
  unicast       Unicast settings

ver 6.0(2)U2(9Z)

felix · #28

jankad pisze:Tak, każdy strumień to osobna linia... w każdym VLANie i dla każdego portu.
Wygenerowaliśmy je oczywiście ze skryptu.

Wygląda na to, że supportowi udało się znaleźć skuteczne rozwiązanie.
Pomogła zmiana parametru:
hardware profile multicast soak-interval
na 50ms.

Testujemy to od tygodnia i wygląda dobrze.

W oprogramowaniu, które posiadam u siebie w ogóle nie ma tego parametru. Istnieje więc możliwość, że w nowej wersji przesadzili z tą 1s jako parametr default.

Kod: Zaznacz cały

hardware profile multicast soak-interval

To set the interval for multicast routes to be programmed into the hardware, use the hardware profile multicast soak-interval command.


Note Beginning in Release 7.0(3)I2(1), the hardware profile multicast soak-interval command is no longer necessary and has been removed.

soak-interval

Skoro już temat tego NEXUS`a i padły stwierdzenia, że to niekoniecznie dobry wybór, to co proponujcie w podobnej konfiguracji portów 48x10G + uplinki 40G lub 100G jako przełącznik corowy/dysrybucyjny obsługujący ruch mutlicast + igmp i około 10Gbps unicast w sieci operatora. Potrzebny ospf, pim, vrf-lite.

kgb · #29

felix pisze:
jankad pisze:Skoro już temat tego NEXUS`a i padły stwierdzenia, że to niekoniecznie dobry wybór, to co proponujcie w podobnej konfiguracji portów 48x10G + uplinki 40G lub 100G jako przełącznik corowy/dysrybucyjny obsługujący ruch mutlicast + igmp i około 10Gbps unicast w sieci operatora. Potrzebny ospf, pim, vrf-lite.

Ja w cale nie uważam, że to zły wybór, wg mnie bije o głowę extreme x670, chociaż przyznam, że ten drugi też radzi sobie dobrze i posiada wszystko to co wymieniłeś, a nowsza wersja ma też uplinki 40G zamienne na porty 10G

konradrz · #30

felix pisze:to co proponujcie w podobnej konfiguracji portów 48x10G + uplinki 40G lub 100G jako przełącznik corowy/dysrybucyjny obsługujący ruch mutlicast + igmp i około 10Gbps unicast w sieci operatora. Potrzebny ospf, pim, vrf-lite.

Żeby zachować dobry stosunek cena/jakość (i cały czas mieć 100G), zainteresuj się słiczami z czipem Tomahawk. Np Nexus 3200 albo Juniper QFX5200
A taki Trident-2 (starsze słicze, np wspomniany Nexus 31xx czy inne Aristy, Junipery, HPE, Extreme, ... - każdy dziś Tridentów używa) da Ci od groma 40G (które da się 'skleić' w 100G), i jeszcze mniej zapłacisz.