Inoltro multicast nel vPC in base alla posizione dell'origine

Opzioni per il download

  • PDF     (270.8 KB)
    Visualizza con Adobe Reader su diversi dispositivi
  • ePub     (126.5 KB)
    Visualizza in diverse app su iPhone, iPad, Android, Sony Reader o Windows Phone
  • Mobi (Kindle)     (134.5 KB)
    Visualizza su dispositivo Kindle o tramite app Kindle su più dispositivi
Aggiornato:27 febbraio 2019
ID documento:214140

Linguaggio senza pregiudizi

La documentazione per questo prodotto è stata redatta cercando di utilizzare un linguaggio senza pregiudizi. Ai fini di questa documentazione, per linguaggio senza di pregiudizi si intende un linguaggio che non implica discriminazioni basate su età, disabilità, genere, identità razziale, identità etnica, orientamento sessuale, status socioeconomico e intersezionalità. Le eventuali eccezioni possono dipendere dal linguaggio codificato nelle interfacce utente del software del prodotto, dal linguaggio utilizzato nella documentazione RFP o dal linguaggio utilizzato in prodotti di terze parti a cui si fa riferimento. Scopri di più sul modo in cui Cisco utilizza il linguaggio inclusivo.

Informazioni su questa traduzione

Cisco ha tradotto questo documento utilizzando una combinazione di tecnologie automatiche e umane per offrire ai nostri utenti in tutto il mondo contenuti di supporto nella propria lingua. Si noti che anche la migliore traduzione automatica non sarà mai accurata come quella fornita da un traduttore professionista. Cisco Systems, Inc. non si assume alcuna responsabilità per l’accuratezza di queste traduzioni e consiglia di consultare sempre il documento originale in inglese (disponibile al link fornito).

    Introduzione

    Questo documento spiega vari scenari di inoltro multicast quando una sorgente viene posizionata in un ambiente vPC

    Prerequisiti

    Requisiti

    Cisco raccomanda la conoscenza dei seguenti argomenti:

    Componenti usati

    Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:

    • Nexus 7000 con software 8.1(1)

    • Supervisor N7K-SUP2E

    • Scheda di linea N7K-M348XP-25L

    Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

    Topologia

    Configurazione

    Lo switch A e lo switch B sono peer VPC.

    Sender1 è connesso alla VLAN 50 (10.200.255.230, 239.3.0.2)

    Sender2 è collegato allo switch L3/router della VLAN 30 e noto al peer vpc tramite VLAN 25 (10.30.30.30, 239.3.0.2)

    Il ricevitore 1 è collegato a una porta orfana 4/1 sullo switch A

    Il ricevitore 2 è collegato a una porta orfana 4/1 sullo switch B

    Switch A

    Ip route 10.30.30.0/24 10.25.25.250
    ip pim rp-address 10.25.25.250 group-list 224.0.0.0/4
    ip pim ssm range 232.0.0.0/8
    ip pim pre-build-spt

    Switch B

    Ip route 10.30.30.0/24 10.25.25.250
    ip pim rp-address 10.25.25.250 group-list 224.0.0.0/4
    ip pim ssm range 232.0.0.0/8
    ip pim pre-build-spt

    Origine connessa alla VLAN vPC

    Il ricevitore 1 richiede continuamente il traffico proveniente dal gruppo 239.3.0.2 e registra (*, G) sullo switch A sulla VLAN 10.

    Lo switch B aggiunge la stessa voce con l'aiuto di CFS. Il ricevitore può essere collegato su una porta orfana o su una porta membro vpc in una vlan VPC.

    Poiché Sender1 è connesso al traffico VLAN del VPC inviato alla VLAN 50 ed entrambi i dispositivi Nexus aggiungono la voce OIF (S, G).

    Entrambi i dispositivi inoltrano il traffico in base all'algoritmo di inoltro interno PIM quando il mittente è connesso direttamente alla VLAN vPC.

    Switch A# show ip pim internal vpc rpf-source
    PIM vPC RPF-Source Cache for Context "default" - Chassis Role Secondary
    Source: 10.200.255.230
      Pref/Metric: 0/0
      Ref count: 1
      In MRIB: yes
      Is (*,G) rpf: no
      Source role: Primary
      Forwarding state: Win-force (forwarding)
    Switch B# show ip pim internal vpc rpf-source
    PIM vPC RPF-Source Cache for Context "default" - Chassis Role Secondary
    Source: 10.200.255.230
      Pref/Metric: 0/0
      Ref count: 1
      In MRIB: yes
      Is (*,G) rpf: no
      Source role: secondary
      Forwarding state: Win-force (forwarding)

    OIF viene popolato anche in entrambi i peer vpc.

    Switch A# show ip mroute

    (*, 232.0.0.0/8), uptime: 02:16:01, pim ip
      Incoming interface: Null, RPF nbr: 0.0.0.0
      Outgoing interface list: (count: 0)

    (*, 239.3.0.2/32), uptime: 01:42:35, igmp ip pim
      Incoming interface: Vlan10, RPF nbr: 10.10.10.251
      Outgoing interface list: (count: 1)
        Vlan10, uptime: 01:42:35, igmp, (RPF)

    (10.200.255.230/32, 239.3.0.2/32), uptime: 02:15:57, ip pim mrib
      Incoming interface: Vlan50, RPF nbr: 10.200.255.230
      Outgoing interface list: (count: 1)
        Vlan10, uptime: 01:42:35, mrib
    Switch B# sh ip mroute

    (*, 232.0.0.0/8), uptime: 02:03:17, pim ip
      Incoming interface: Null, RPF nbr: 0.0.0.0
      Outgoing interface list: (count: 0)

    (*, 239.3.0.2/32), uptime: 01:31:59, igmp ip pim
      Incoming interface: Null, RPF nbr: 0.0.0.0
      Outgoing interface list: (count: 1)
        Vlan10, uptime: 01:31:59, igmp

    (10.200.255.230/32, 239.3.0.2/32), uptime: 02:03:13, ip pim mrib
      Incoming interface: Vlan50, RPF nbr: 10.200.255.230
      Outgoing interface list: (count: 1)
        Vlan10, uptime: 01:31:59, mrib

    Il ricevitore 1 riceve lo streaming e, non appena il ricevitore 2 lo richiede per lo stesso gruppo, anche il ricevitore 2 lo riceve.

    Origine collegata al router L3

    Il mittente 2 invia il flusso all'FHRP, che è l3_switch nella VLAN 30, che in questo caso funziona anche come RP.

    L3_switch inoltrerà il flusso verso il peer VPC sulla VLAN 25. Questo traffico viene trattato come multicast su L3 e entrambi i peer VPC compileranno il flusso (S, G).

    Il ricevitore 1 e il ricevitore 2 richiedono il flusso multicast e (*, G) sono stati creati su entrambi i peer vpc.

    Poiché il flusso Mittente2 viene ricevuto tramite PIM sulla SVI 25 e non direttamente su VPC SVI, solo un dispositivo (DR) inoltrerà il traffico in base all'algoritmo di inoltro interno PIM, in quanto il mittente 2 non si trova direttamente sulla SVI VPC.

    Switch A# show ip pim internal vpc rpf-source
    Source: 10.30.30.30
      Pref/Metric: 1/0
      Ref count: 1
      In MRIB: yes
      Is (*,G) rpf: no
      Source role: primary
      Forwarding state: Tie (forwarding)
      MRIB Forwarding state: forwarding

    Switch B# sh ip pim internal vpc rpf-source
    Source: 10.30.30.30
      Pref/Metric: 1/0
      Ref count: 1
      In MRIB: yes
      Is (*,G) rpf: no
      Source role: secondary
      Forwarding state: Tie (not forwarding)
      MRIB Forwarding state: not forwarding

    Pertanto, OIF viene popolato solo su DR.

    Switch A# show ip mroute
    IP Multicast Routing Table for VRF "default"

    (*, 232.0.0.0/8), uptime: 02:37:29, pim ip
      Incoming interface: Null, RPF nbr: 0.0.0.0
      Outgoing interface list: (count: 0)

    (*, 239.3.0.2/32), uptime: 02:37:26, igmp ip pim
      Incoming interface: Vlan25, RPF nbr: 10.25.25.250
      Outgoing interface list: (count: 1)
        Vlan10, uptime: 02:37:26, igmp

    (10.30.30.30/32, 239.3.0.2/32), uptime: 02:37:26, ip mrib pim
      Incoming interface: Vlan25, RPF nbr: 10.25.25.250
      Outgoing interface list: (count: 1)
        Vlan10, uptime: 02:37:26, mrib
    Switch B# show ip mroute
    (*, 232.0.0.0/8), uptime: 02:38:15, pim ip
      Incoming interface: Null, RPF nbr: 0.0.0.0
      Outgoing interface list: (count: 0)

    (*, 239.3.0.2/32), uptime: 02:38:15, igmp ip pim
      Incoming interface: Vlan25, RPF nbr: 10.25.25.250
      Outgoing interface list: (count: 1)
        Vlan10, uptime: 02:38:15, igmp

    (10.30.30.30/32, 239.3.0.2/32), uptime: 02:38:15, ip mrib pim
      Incoming interface: Vlan25, RPF nbr: 10.25.25.250
      Outgoing interface list: (count: 1) >>>>>> no OIF

    In questo caso, quando il ricevitore 1 riceve lo streaming e il ricevitore 2 non lo riceve mai a causa di un'interfaccia OIF mancante sullo switch B. 

    Sorgente collegata tra VRF diverse

                                                                                                                                                                                                                             

    Il traffico multicast viene inoltrato a un solo ricevitore nella vlan10 collegata al peer vpc primario, mentre il ricevitore collegato al peer secondario non lo riceve.

    1. Il multicast inviato a fex sulla vlan 50 (vpc vlan), in questo caso, sia lo switch A che lo switch B hanno un'interfaccia OIF per la VRF B, in quanto l'origine è collegata direttamente a esso e si trova nella vlan del vpc.
    2. Questo traffico viene inoltrato alla vlan 51 verso il VRF A che si trova in un altro VDC e inviato all'RP. 
    3. Il VDC dispone della vlan 11 nella VRF A e della vlan 51 nella VRF predefinita.
    4. Il traffico viene ora inviato allo switch A vlan 11 nel VRF A.
    5. Solo uno degli switch A/switch B ha un'interfaccia OIF per il VRF A a causa della stessa limitazione menzionata nel caso del mittente 2 collegato al router L3.
    6. Il ricevitore 1 collegato allo switch A con OIF riceve il flusso multicast.

    Si tratta di una limitazione della progettazione.

    Il peer VPC può avere OIF installato su entrambi gli switch solo se il traffico viene inoltrato direttamente dal mittente nella VLAN VPC e non dal PIM.

    Pertanto, l'interfaccia OIF viene installata nel VRF A come mittente direttamente collegato al VRF A, ma non nel VRF B poiché è connesso tramite PIM.

    Per ottenere l'interfaccia OIF su entrambi i peer VPC, il mittente deve essere connesso direttamente alla VLAN del vpc.

    Questa funzionalità sarà implementata in seguito come parte della funzionalità "L3 over VPC"

    Riferimento

    Difetti noti

    CSCtq49254 VPC: Mcast non inoltrato quando ricevuto da VPC da L3-hop su VPC Sec.

    TAC Authored

    Contributo dei tecnici Cisco

    • Lovkesh Sharma
      Tecnico TAC

    Questo documento ti è stato utile?

    FeedbackFeedback

    Contattaci