2009/7/22 Boudewijn Visser <bvisser-nlnog at xs4all.nl>
[knip IPV6, HSRPv2, link-local gateway adres, ND,RA]
Hieruit concludeer ik dus voorzichtig dat je HSRP gewoon veilig met linklocals kan gebruiken en aangezien die toch altijd op basis van het MAC adres zijn je net zo goed het 'autoconfig' keyword kunt gebruiken (autoconfig fabriekt zelf het link-local op basis van de prefix en het mac adres).
Dat lijkt me ook. Als je kiest voor autoconfig zou ik het wel combineren met Router Advertisement (dwz: dat de clients automagisch dat gateway adres leren). Denk denk... Als je het (link-local dus) gateway adres vast configureert op de clients en je wisselt router hardware (nic of hele router) moet je de clients ook weer langs. (Of op dat moment niet vergeten om het vorige auto-gegenereerde link local adres op dat moment hard op de HSRP groep te zetten). Check check. Ah, link-local is by default derived van het *virtual* mac adres gereserveerd voor hsrp v2, wat weer gekoppeld is aan de HSRP groep. Ok, dus geen afhankelijkheid van router/interface hardware dus. Boudewijn
Arjan
2009/7/22 Boudewijn Visser bvisser-nlnog at xs4all.nl:
Hieruit concludeer ik dus voorzichtig dat je HSRP gewoon veilig met linklocals kan gebruiken en aangezien die toch altijd op basis van het MAC adres zijn je net zo goed het 'autoconfig' keyword kunt gebruiken (autoconfig fabriekt zelf het link-local op basis van de prefix en het mac adres). Dat lijkt me ook. Als je kiest voor autoconfig zou ik het wel combineren met Router Advertisement (dwz: dat de clients automagisch dat gateway adres leren).
Check, maar in dit stukje 'core' wil ik helemaal geen RA en autoconfig hebben.
Als je het (link-local dus) gateway adres vast configureert op de clients en je wisselt router hardware (nic of hele router) moet je de clients ook weer langs. (Of op dat moment niet vergeten om het vorige auto-gegenereerde link local adres op dat moment hard op de HSRP groep te zetten). Dit is een stukje vaste infra waar dit allemaal minder relevant is. Ik had laatst met MarcoH ook al een discussie over het al dan niet gebruiken van EUI-64 (en RA's) op P2P's binnen je core etc. Wat ik zo links en rechts verneem is erg stelling: in je core gewoon geen RA en EUI-64 gebruiken, dat is voorbehouden (als je het al wil) aan de access laag.
Inmiddels draait eea, er is ook nog een stukje feedback van een Cisco SE gekomen: "Because of ICMP redirects... they only work for LL addresses. Also the entry in the RA section 4.2 of RFC4861 tells that it has to be LL address" De uiteindelijke config (for future reference) van een gecombineerde IPv4 en IPv6 HSRP setup ziet er nu zo uit: interface GigabitEthernet1/3.1103 encapsulation dot1Q 1103 ip address <ipv4> <subnetmask> no ip redirects no ip proxy-arp ipv6 address <prefix>/64 standby version 2 standby 1 ip <ipv4 virtual IP) standby 1 priority 110 standby 1 preempt standby 1 authentication <password> standby 1 name <name> standby 10 ipv6 FE80::5:73FF:FEA0:A standby 10 priority 110 standby 10 preempt standby 10 authentication <password> standby 10 name <name> Je kunt ook "standby 10 ipv6 autoconfig" gebruiken, de machine genereert het link-local adres dan zelf op basis van het virtuele MAC adres. In mijn geval heb ik dat adres overgenomen en hard in de config gezet, om te voorkomen dat het later om welke reden dan ook eens zou wijzigen. De client (in dit geval de ASA) die eraan hangt heeft FE80::5:73FF:FEA0:A als default gekregen. Arjan
participants (2)
-
arjan@vanderoest.net -
bvisser-nlnog@xs4all.nl