ip multicast boundary filter-autorp

[manius]

poniewaz widac dla GS temat jest zbyt banalny (cusik nie widac odpowiedzi) moze w szanownym gronie ktos wesprze rada - co kilka glow to nie jedna

chodzi nie tyle o samo boundary i zasade dzialania bo ta jest dobrze mi znana - bardziej o nowy ficzer dostepny od 12.2(13)T a wiec prawdopodobny cel laba.

Pytanie - gdzie to cholerstwo umieszczac ? Wedlug doco ficzer filtruje wszelkie announcements & discovery scope'a administracyjnego (czyli 239.0.0.0 255.0.0.0) wysylane przez auto-rp. Poniewaz dodane jest to do komendy boundary , no - oczekiwalbym ze dziala na zasadzie - filtruj auto-rp na granicach mojej domeny mcastowej, czyli trzymaj auto-rp w moim ogrodku. Jednakze zastosowanie tego na routerze granicznym nie powoduje bynajmniej zatrzymania przesylania announcements/discovery. Jak lecialy tak leca poza domene. Jak odpalam to na RP - tutaj dziala bez pudla. Jednak chyba to nie powinno byc miejsce stosowania tego ficzera - no chyba ze znowu patrze nie w ta strone
Ktos to moze testowal i moze sie podzielic spostrzezeniami ?

Any comments , greatly appreciated.

[pjeter]

Pytanie - gdzie to cholerstwo umieszczac ? Wedlug doco ficzer filtruje wszelkie announcements & discovery scope'a administracyjnego (czyli 239.0.0.0 255.0.0.0) wysylane przez auto-rp. Poniewaz dodane jest to do komendy boundary , no - oczekiwalbym ze dziala na zasadzie - filtruj auto-rp na granicach mojej domeny mcastowej, czyli trzymaj auto-rp w moim ogrodku. Jednakze zastosowanie tego na routerze granicznym nie powoduje bynajmniej zatrzymania przesylania announcements/discovery. Jak lecialy tak leca poza domene. Jak odpalam to na RP - tutaj dziala bez pudla. Jednak chyba to nie powinno byc miejsce stosowania tego ficzera - no chyba ze znowu patrze nie w ta strone

Nie testowalem, ale uwaznie przeczytalem doca.

If you configure the filter-autorp keyword, the administratively scoped boundary also __examines__ Auto-RP discovery and announcement messages and __removes any Auto-RP group range__ announcements from the Auto-RP packets that are denied by the boundary ACL.
An Auto-RP group range announcement is permitted and passed by the boundary only if all addresses in the Auto-RP group range are permitted by the boundary ACL. If any address is not permitted, the entire group range is filtered and removed from the Auto-RP message before the Auto-RP message is forwarded.

Czyli nie filtruje bezposrednio Auto-rp, tylko sprawdza czy announcy mieszcza sie w ACLach, jesli tak przepuszcza, jesli nie usuwa filtrowane grupy z announcow.

Do wyfiltrowania AutoRP nalezy uzyc raczej:
access-list 1 deny 224.0.1.39 0.0.0.0
access-list 1 deny 224.0.1.40 0.0.0.0
access-list 1 permit 224.0.0.0 15.255.255.255
interface ethernet 0
ip multicast boundary 1

A miejsce zastosowania ficzera.hmm..
mysle ze powinno brzmiec: nie wypuszczac grupy X poza okreslony router Y i dodatkowo zapewnic ze auto-rp nie bedzie rozglaszac tej grupy poza router Y. Natomiast Auto-rp ma dzialac nawet poza miejscem filtrowania.

Pozdrawiam
PJ

[manius]

dzieki pjeter za odpowiedz.

zmylil mnie opis w doco :

An Auto-RP group range announcement is permitted and passed by the boundary only if all addresses in the Auto-RP group range are permitted by the boundary ACL. If any address is not permitted, the entire group range is filtered and removed from the Auto-RP message before the Auto-RP message is forwarded.

niestety z prob wynika jednoznacznie ze nie do konca jest tak jak mowia.

Poligon :
======

R2 (RP) ------- R3 (MA) -------- R8

na RP rozglaszane sa grupy :
z loop0 : 239.2.2.2, 239.2.2.3 , 239.2.2.4
z loop1 : 239.3.3.0 255.255.255.0

na MA przyjmuje wszystko jak leci bez zadnych ograniczen
na MA w kierunku R8 (fa0/0) ustawiam boundary :

ip multicast boundary GRUPA239 filter-autorp
gdzie:
ip access-list standard GRUPA239
deny 239.2.2.2
permit any

zgodnie z doco , wyciecie jednego adresu z rozglaszanego scope'a powinno wyciac caly zakres rozglaszany z danego RP czyli 239.2.2.2 .3 oraz .4

ale tak sie nie dzieje co widac na zalaczonym obrazku :
R8#
*Mar 2 22:57:42.760: Auto-RP: Received RP-discovery, from 172.16.103.1, RP_cnt 2, ht 181
*Mar 2 22:57:42.764: Auto-RP: Update (239.2.2.2/32, RP:172.16.22.1), PIMv2 v1
*Mar 2 22:57:42.768: Auto-RP: Update (239.2.2.3/32, RP:172.16.22.1), PIMv2 v1
*Mar 2 22:57:42.772: Auto-RP: Update (239.2.2.4/32, RP:172.16.22.1), PIMv2 v1
*Mar 2 22:57:42.780: Auto-RP: Update (239.3.3.0/24, RP:172.16.102.1), PIMv2 v1

jednakze zmiana filtracji na R3 na nastepujacą :
ip access-list standard GRUPA239
deny 239.2.2.0 0.0.0.7
permit any

powoduje juz wlasciwe zachowanie czyli :

R3(config-if)#
*Mar 2 22:38:36.840: %AUTORP-4-OVERLAP: AutoRP Announcement packet, group 224.0.0.0 with mask 240.0.0.0 removed because of multicast boundary for 239.2.2.0 with mask 255.255.255.0


R8#
*Mar 2 22:40:00.164: Auto-RP: Received RP-discovery, from 172.16.103.1, RP_cnt 1, ht 181
*Mar 2 22:40:00.168: Auto-RP: Update (239.3.3.0/24, RP:172.16.102.1), PIMv2 v1

any ideas ?

[garfield]

Szukałem dzisiaj wyjaśnienia co robi autorp-filter i natknąłęm się na ten post

Przeklikałem sobie dzisiaj sporo tego i się podzielę wnioskami może się komuś przyda

Topologię mam taką samą blokowanie robię w tym samym miejscu co kolega powyżej tylko grupy multicastowe są inne

Po1)
z tymi range'ami jest trochę inaczej

Kod: Zaznacz cały

*Mar 2 22:57:42.764: Auto-RP: Update (239.2.2.2/32, RP:172.16.22.1), PIMv2 v1
*Mar 2 22:57:42.768: Auto-RP: Update (239.2.2.3/32, RP:172.16.22.1), PIMv2 v1
*Mar 2 22:57:42.772: Auto-RP: Update (239.2.2.4/32, RP:172.16.22.1), PIMv2 v1 

nie jest jednym range'em - na co wskazuje maska

to:

Kod: Zaznacz cały

*Mar 2 22:57:42.780: Auto-RP: Update (239.3.3.0/24, RP:172.16.102.1), PIMv2 v1

jest to range 254 członkowy

Po2)
Nie wystarczy ze zdefiniujemy kilka grup multicastowych na RP za pomocą group-list zeby powstala grupa

W moim przykładzie mam takie coś (to jest własnie definicja range'a):

Kod: Zaznacz cały

ip pim send-rp-announce Loopback0 scope 16 group-list 3
access-list 3 permit 227.1.1.0 0.0.0.255

jak teraz na którymś routerze spróbuje uciąć za pomocą filter-autorp np

Kod: Zaznacz cały

access-list 55 deny 227.1.1.1 0.0.0.128

to dostanę:

Kod: Zaznacz cały

*Mar  1 08:17:55.893: %AUTORP-4-OVERLAP: AutoRP Discovery packet, group 227.1.1.0 with mask 255.255.255.0 
removed because of multicast boundary for 227.1.1.1 with mask 255.255.255.127

Po3)
Czyli to co piszę w docu jest prawdą ponieważ widać że chciałem zablokować tylko część "grupy" - maska w blokadzie jest dłuższa niż ta w ogłoszeniu od RP

Po4)
Jest to trochę dziwne i najwygodniej poprostu robić tak żeby wychodziło wszędzie w updatach "/32"
Wtedy pojedyńczo możemy wycinać update'y ponieważ range jest jedno członkowy i nie da się zrobić maski większej niż /32


NP:

Kod: Zaznacz cały

ip multicast boundary 55 filter-autorp

access-list 55 deny 227.1.1.1
access-list 55 permit any

PRZED:
*Mar  1 08:25:45.329: Auto-RP(0): Update (227.1.1.1/32, RP:4.4.4.4), PIMv2 v1
*Mar  1 08:25:45.333: Auto-RP(0): Update (227.1.1.2/32, RP:4.4.4.4), PIMv2 v1
*Mar  1 08:25:45.349: Auto-RP(0): Update (227.1.1.3/32, RP:4.4.4.4), PIMv2 v1

PO:
*Mar  1 08:26:00.345: Auto-RP(0): Update (227.1.1.2/32, RP:4.4.4.4), PIMv2 v1
*Mar  1 08:26:00.349: Auto-RP(0): Update (227.1.1.3/32, RP:4.4.4.4), PIMv2 v1

Generalnie trzeba uważać na maski ponieważ u kolegi powyżej widać że prawie wszędzie domyślnie jest przyjmowana maska 240.0.0.0 a więc typowa multicastowa a taką łatwo niechcąco wyciąć i wszystko w niej

PS Teraz zauważyłem - to chyba rekord na posta odpisać po 4 latach ;P

[manius]

dzieki Marcin za odpowiedz i pm'a - odnosnie odpowiedzi po 4 latach - ja bym raczej powiedzial ze jest to doskonaly przyklad jak nalezy zglebiac temat