Gå til innhold

Anbefalte innlegg

Hei,

 

Kjører auto-rp og har 2 mapping agents, som er mapping agents for 2 forskjellige grupper, 224.56.56.0/24 på MA1 og 224.78.78.0/24 på MA2. Noen som har vært borti at disse ikke lærer hverandres mappings?

Det at de er mapping agents skal ikke skru av muligheten for å fortsatt lytte til 224.0.1.40..

 

*Nov 13 23:43:11.242: Auto-RP(0): Received RP-discovery, from 172.27.20.2, ignored.

Lenke til kommentar
Videoannonse
Annonse

Ja. Kan du beskrive topologien og paste inn konfigen?

 

Er auto-rp listener lagt inn? ip pim autorp listener. Den faar sparse mode interface til aa behandle gruppene som dense. Er det redundans du har tenkt med to mapping agents? Hvis ikke bor du filtrere. Men skal du ha dette i produksjon hadde jeg gaatt over til BSR(hvis du har mulighet) som kjorer over med unicast og du slipper storre problemer.

 

Pleier aa starte nedenifra med aa sjekke PIM neighbors, RPF failures (det ma ogsa sjekkes mot RPs), saa om mappingen er i orden, mroute og vanskelige tilfeller debugging. Men av meldingen sa faar du jo pakker med adress 224.0.1.40.

Endret av VictorOsborn
Lenke til kommentar

Her er oppsettet for R6 (MA1) som er pa samme ethernet segment som R1 (MA2). De mottar begge alle RP-announcement pakkene pa 224.0.1.39. Disse tas inn og filteres som folger:

 

ip pim send-rp-announce Loopback0 scope 20 group-list ALLOW_MC_GROUPS

ip pim send-rp-discovery Loopback0 scope 20

ip pim rp-announce-filter rp-list ALLOW_RP_R5 group-list ALLOW_MC_GROUPS

ip pim rp-announce-filter rp-list ALLOW_RP_R6 group-list ALLOW_MC_GROUPS

ip pim rp-announce-filter rp-list PERMIT_ANY_RP group-list DENY_ALL_MC_GROUPS

 

ip access-list standard ALLOW_MC_GROUPS

permit 224.56.56.0 0.0.0.255

permit 224.65.65.0 0.0.0.255

ip access-list standard ALLOW_RP_R5

permit 190.11.5.5

ip access-list standard ALLOW_RP_R6

permit 172.27.6.6

ip access-list standard DENY_ALL_MC_GROUPS

deny any

ip access-list standard PERMIT_ANY_RP

deny 190.11.5.5

deny 172.27.6.6

permit any

 

Dette gjor bare at gruppene filtreres strikt sa ikke begge MAene blir MA for hverandre. Problemet er som sagt at de ignorerer RP-Disocery fra hverandre. Har lest noe litteratur om at man bor ha konsistent informasjon pa redundante MAer, men ser ikke noe i RFC eller annen litteratur om at det ikke skal ga. Helt klart er BSR et bedre valg, men er en ccie-prep, skulle gjerne ha funnet ut av det, annoying a ikke vite:)

Lenke til kommentar

Vel, dette er core i Multicast og skal ikke se bort i fra at du noe lignende naar du tar labben. Skal labbe det opp naar jeg kommer tilbake fra ferie.

 

Litteratur:

Du registrere deg paa gratis v-seminar paa mulicast: http://www.internetworkexpert.com/free_ccie_vseminar.htm

 

Da er dem innom filtrering tror jeg. Filtering er spesielt, feks RP og MA maa matches helt etc, kun permits statements pa RPs etc. Du maa ogsa kunne filtere vekk rouge RPs som her etc.

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...