Vlan-based filtering - IPv6 problem.

[pjeter]

Witam.

Zaczalem na 3560 standartowo (celem testow i usystematyzowania wiedzy). Cel: vlan-filtering filtrujacy ICMP na vlanie z drop any na koncu - jest to trudniejsze podejscie bo trzeba pozwolic poszczegolnym protokolom.
Niby ogolnie prosta sprawa, a jednak..
No wiec zaczalem tak (vlan miedzy dwoma routerami):

Kod: Zaznacz cały

mac access-list extended ARP
 permit any any 0x806 0x0             ! IP ARP
 permit any any lsap 0x4242 0x101     ! STP
 permit any any lsap 0xFEFE 0x101     ! CLNS
 permit any any 0x86DD 0x0            ! IPv6 (RFC 2464)
!
vlan access-map IP 10
 action forward
 match mac address ARP
vlan access-map IP 20
 action forward
 match ip address IP
vlan access-map IP 30
 action drop
vlan filter IP vlan-list 46
!
ip acce ex IP
 deny icmp any any
 per ip any any

Wyglada w porzadku. Wiec szybka weryfikacja czy dziala.
Usunalem
permit any any lsap 0xFEFE 0x101
pstryk. CLNS stracil neigbora.
usunalem
permit any any 0x806 0x0
nie rozwiazuja sie ARPy. So far so good.
No to IPv6 - tutaj lezy moj problem.
Po usunieciu IPv6 ( permit any any 0x86DD 0x0) z drugiej warstwy - dalej dziala.
No to pewnie IP go puszcza. Wiec seq 20 action drop. Pinguje sie. Rozwiazuje adresy (ICMPv6 ND dziala jak gdyby nigdy nic).
Skonczylem z taka konfiguracja - nic nie powinno przechodzic:

Kod: Zaznacz cały

mac access-list extended ARP
 deny   any any
!
vlan access-map IP 10
 action forward
 match mac address ARP
vlan access-map IP 20
 action drop
 match ip address IP
vlan access-map IP 30
 action drop
vlan filter IP vlan-list 46
!
ip acce ex IP
 per ip any any

Cala komunikacja lezy a IPv6 hula :))).
Wnioski: Nie wiem czy to nie zalezy od tego ze 3560 obsluguje juz IPv6 (dopiero po "sdm prefer ipv6-dual-costam"). Ja pracowalem na sdm standard desktop co powinno(?) spowodowac traktowanie IPv6 jako zwyklego ruchu non-IP.
Czy moze jakas pierdola ktorej nie zauwazam ?

A przede wszystkim: Moze ktos przetestowac powyzsze na 3550 ?
Idea moich testow: zdjecie "permit any any 0x86DD 0x0" powinno zaczac dropowac IPv6
Aha - na 3550 AFAIK po kazdej zmianie policy nalezy sciagnac i ponownie zaaplikowac "vlan filter" (oczywiscie probowalem tak rowniez u siebie).
Dzieki.

PJ

[manius]

hmm... ciekawy przypadek, przelabuje to wkrotce (o ile jeszcze nie znalazles rozwiazania) i dam znac

[gubit]

Mam 3550 więc zabrałem się do przelabowania. Sorki, że dopiero.

Kod: Zaznacz cały

mac access-list extended ARP
 permit any any 0x806 0x0             ! IP ARP
 permit any any lsap 0x4242 0x101     ! STP
 permit any any lsap 0xFEFE 0x101     ! CLNS
 permit any any 0x86DD 0x0            ! IPv6 (RFC 2464)
!
vlan access-map IP 10
 action forward
 match mac address ARP
vlan access-map IP 20
 action forward
 match ip address IP
vlan access-map IP 30
 action drop
vlan filter IP vlan-list 46
!
ip acce ex IP
 deny icmp any any
 per ip any any

Wyglada w porzadku. Wiec szybka weryfikacja czy dziala.
Usunalem
permit any any lsap 0xFEFE 0x101
pstryk. CLNS stracil neigbora.
usunalem
permit any any 0x806 0x0
nie rozwiazuja sie ARPy. So far so good.

Zgadza się. ARP i IS-IS zachowują się tak samo.

No to IPv6 - tutaj lezy moj problem.
Po usunieciu IPv6 (permit any any 0x86DD 0x0) z drugiej warstwy - dalej dziala.

A u mnie tu już nie działa. Prefix z RIPng znika z "sh ipv ro". Za to po usunieciu tylko 0x806 0x0 (ARP) prefix z RIPng dalej jest w "sh ipv ro" i jest pingowalny. Prefixy z IPv4 (RIP i IS-IS) są też dalej w tabilcy routingu, ale oczywiście nie są pingowalne.
[Tak na marginesie ciekawe jak zrobić taki sam efekt z IPv6 - aby prefixy były w tab. routingu, ale aby nie były pingowalne. Pewnie deny IPv6 ARP co?]

No to pewnie IP go puszcza. Wiec seq 20 action drop. Pinguje sie.

Gdy zrobię tylko IP drop (czyli dodam znowu IPv6 i ARP) to prefix z RIPng jest dalej w "sh ipv ro" i jest pingowalny. Tracę za to prefixy z RIP IPv4 ale mam dalej sąsiedztwo IS-IS i prefixy z IS-IS. Ale prefixy te oczywiście nie są pingowalne.

Idea moich testow: zdjecie "permit any any 0x86DD 0x0" powinno zaczac dropowac IPv6

Zgadza się. U mnie tak to działa.
1. Twój przypadek - trudniejszy - z drop na końcu.
Musi być "permit any any 0x86DD 0x0". Inaczej IPv6 nie chodzi.
2. Przypadek łatwiejszy - z forward na końcu.
Gdy zrobię:

mac access-list extended ARP
permit any any 0x86DD 0x0 ! IPv6 (RFC 2464)
!
vlan access-map IP 10
action drop
match mac address ARP
vlan access-map IP 20
action forward

IPv6 nie działa. Prefix RIPng znika z "sh ipv ro".

Aha - na 3550 AFAIK po kazdej zmianie policy nalezy sciagnac i ponownie zaaplikowac "vlan filter" (oczywiscie probowalem tak rowniez u siebie).
Dzieki.
PJ

Tak, podczas testów często zdejmowałem i zakładałem "vlan filter" jak też często używałem "cle ip ro *" i "cle ipv ro *".

[manius]

gubit - testy robiles na tym samym sdm'ie co pjeter ?

[gubit]

gubit - testy robiles na tym samym sdm'ie co pjeter ?

Nie używałem polecenia "sdm prefer", więc moje testy były na domyślnym na 3550.
Polecenie "show sdm prefer" pokazuje: "The current template is the default template".

manius jak masz 3550 i kumasz te sdm'y, to też potestuj.
Ja muszę poczytać o tych sdm'ach i wtedy będę mógł to zmieniać. Bo narazie za mało o tym wiem.

[pjeter]

Wiec po kolei:

Mam 3550 więc zabrałem się do przelabowania. Sorki, że dopiero.

No to IPv6 - tutaj lezy moj problem.
Po usunieciu IPv6 (permit any any 0x86DD 0x0) z drugiej warstwy - dalej dziala.

A u mnie tu już nie działa. Prefix z RIPng znika z "sh ipv ro".

1. Super to byl cel mojego testu i wyglada na to ze 3550 zachowuje sie w tym wzgledzie deterministycznie.
1a. Czy druga strona IPv6 sie pinguje ? (wg. mnie nie powinna)

Za to po usunieciu tylko 0x806 0x0 (ARP) prefix z RIPng dalej jest w "sh ipv ro" i jest pingowalny. Prefixy z IPv4 (RIP i IS-IS) są też dalej w tabilcy routingu, ale oczywiście nie są pingowalne.

2. Czyli znow zachowuje sie tak jak powinien. Wycielismy ARPy, wiec brak mapowania L3-L2 dla IP.
RIPng bedzie chodzil bo korzysta z 0x86DD. RIP zwykly tez bedzie chodzil bo korzysta z IP - 0x0800.
2a. Druga strona IPv6 sie pinguje bo uzywa 0x86DD do rozwiazania mapowan (wiecej ponizej)

[Tak na marginesie ciekawe jak zrobić taki sam efekt z IPv6 - aby prefixy były w tab. routingu, ale aby nie były pingowalne. Pewnie deny IPv6 ARP co?]

3. Nie da sie. Przynajmniej nie EtherType'ami.
IP uzywa dwoch EtherType'ow 0x0800 dla pakietow IP oraz 0x0806 dla ARPa w celu rozwiazania mapowan L3-L2.
IPv6 uzywa tylko jednego EtherType'u dla calej komunikacji.
W przypadku IPv6 do rozwiazywania mapowan L2-L3 uzywane sa _multicasty_ IPv6 -> ICMPv6 Neighbor Discovery, ktore uzywaja tego samego typu ramki (0x86DD) na drugiej warstwie co regularny ruch IPv6.

Gdy zrobię tylko IP drop (czyli dodam znowu IPv6 i ARP) to prefix z RIPng jest dalej w "sh ipv ro" i jest pingowalny. Tracę za to prefixy z RIP IPv4 ale mam dalej sąsiedztwo IS-IS i prefixy z IS-IS. Ale prefixy te oczywiście nie są pingowalne.

4. Fair one.
Wycielismy IP - czyli ruch IP oraz RIPa IPv4.
Zostaje IPv6 w tym RIPng (IPv6 FF02::9) oraz mapowania IPv6 L3-L2.

Idea moich testow: zdjecie "permit any any 0x86DD 0x0" powinno zaczac dropowac IPv6

Zgadza się. U mnie tak to działa.
1. Twój przypadek - trudniejszy - z drop na końcu.
Musi być "permit any any 0x86DD 0x0". Inaczej IPv6 nie chodzi.

Super. Ciesze sie ze moje zalozenia byly poprawne.

2. Przypadek łatwiejszy - z forward na końcu.
Gdy zrobię:

mac access-list extended ARP
permit any any 0x86DD 0x0 ! IPv6 (RFC 2464)
!
vlan access-map IP 10
action drop
match mac address ARP
vlan access-map IP 20
action forward

IPv6 nie działa. Prefix RIPng znika z "sh ipv ro".

No tak to chyba logiczne. Cale IPv6 (w tym RIPng) zostaja wyciete.

Dzieki za przelabowanie tego. Wyniki sa dokladnie takie jakich sie spodziewalem.

Podsumowywujac:
0x0800 - IP (w tym np. RIP IPv4, OSPF itp.)
0x0806 - IP ARP (tylko rozwiazywania mapowan IP L3-L2)
0x86DD - IPv6 (wraz z dynamicznymi protokolami routingu i rozwiazywniem mapowan - czyli CALE IPv6)

PJ

[gubit]

1. Super to byl cel mojego testu i wyglada na to ze 3550 zachowuje sie w tym wzgledzie deterministycznie.
1a. Czy druga strona IPv6 sie pinguje ? (wg. mnie nie powinna)

Mówisz o pingowaniu interfejsu połączeniowego po 2 stronie tak?
A no nie pinguje się.
Czyli - po zabraniu IPv6 (permit any any 0x86DD 0x0) znika RIPng i nie pingujemy drugiego końca połączenia.

2. Czyli znow zachowuje sie tak jak powinien. Wycielismy ARPy, wiec brak mapowania L3-L2 dla IP.
RIPng bedzie chodzil bo korzysta z 0x86DD. RIP zwykly tez bedzie chodzil bo korzysta z IP - 0x0800.
2a. Druga strona IPv6 sie pinguje bo uzywa 0x86DD do rozwiazania mapowan (wiecej ponizej)

A no właśnie to 2a to bardzo ważna rzecz.

3. Nie da sie. Przynajmniej nie EtherType'ami.
IP uzywa dwoch EtherType'ow 0x0800 dla pakietow IP oraz 0x0806 dla ARPa w celu rozwiazania mapowan L3-L2.
IPv6 uzywa tylko jednego EtherType'u dla calej komunikacji.
W przypadku IPv6 do rozwiazywania mapowan L2-L3 uzywane sa _multicasty_ IPv6 -> ICMPv6 Neighbor Discovery, ktore uzywaja tego samego typu ramki (0x86DD) na drugiej warstwie co regularny ruch IPv6.

A widzisz do jakiego ciekawego pytania mnie doprowadziłeś. Zastanawiałem się nad IPv6 ARP... A tu proszę.
Temat Neighbor Discovery znałem (widać za słabo), ale nie połączyłem tego z tak ważnym faktem: "IPv6 uzywa tylko jednego EtherType'u dla calej komunikacji."

4. Fair one.
Wycielismy IP - czyli ruch IP oraz RIPa IPv4.
Zostaje IPv6 w tym RIPng (IPv6 FF02::9) oraz mapowania IPv6 L3-L2.

Tak, zostaje IPv6 no i IS-IS został. Sąsiedztwo mam i prefix z IS-IS mam. Pingować go nie można, bo IP wycięte.

Podsumowywujac:
0x0800 - IP (w tym np. RIP IPv4, OSPF itp.)
0x0806 - IP ARP (tylko rozwiazywania mapowan IP L3-L2)
0x86DD - IPv6 (wraz z dynamicznymi protokolami routingu i rozwiazywniem mapowan - czyli CALE IPv6)
PJ

Super podsumowanie. 0x86DD - CALE IPv6!
Wyjaśniło mi się fajne zagadnienie, które tak na marginesie przy testach mi się wymyśliło.

[manius]

Super podsumowanie. 0x86DD - CALE IPv6!

ipv6 over Eth owszem uzywa 0x86DD
ipv6 over ATM AAL5 SNAP takze uzywa 0x86DD
ipv6 over HDLC uzywa 0x86 | 0xDD
ipv6 over PPP (IPv6CP) uzywa 0x8057

[gubit]

ipv6 over Eth owszem uzywa 0x86DD
ipv6 over ATM AAL5 SNAP takze uzywa 0x86DD
ipv6 over HDLC uzywa 0x86 | 0xDD
ipv6 over PPP (IPv6CP) uzywa 0x8057

Manius pewne info?
Skąd masz?
Masz może już książkę IPv6 CiscoPress w wer. elektronicznej?

[manius]

info z : Cisco Self-Study: Implementing Cisco IPv6 Networks By Regis Desmeules.

polecam - lepsza niz Syngress

[gubit]

info z : Cisco Self-Study: Implementing Cisco IPv6 Networks By Regis Desmeules.
polecam - lepsza niz Syngress

Dzięki za info skąd info.
Domyślam się, że lepsza bo CiscoPress to CiscoPress.
Ale nie odpowiedziałeś na pytanie, czy masz tą książkę w wer. elektron.
Bo prosiłem Cię kiedyś o info, jak będziesz miał.

[manius]

qpilem sobie papier bo nigdzie nie widzialem el.

pozdro

[gubit]

qpilem sobie papier bo nigdzie nie widzialem el.
pozdro

Aha spoko.
Teraz u mnie mały odpoczynek - urlop czyli.
Ale po urlopie dalej ostra jazda będzie i też planuję jakoś dorwać tą knigę.
Też cały czas mam w planach kupić kilka książek CiscoPress i wkurzam się, że człowieka nie stać.

Też pozdrawiam.