From: Scott Vermillion (scott_ccie_list@it-ag.com)
Date: Sat Jan 03 2009 - 17:44:32 ARST
Hi Again Wouter,
>yes, or other topics ;)
LOL! True that. So true.
OK, now I understand the question actually being asked! First, let's have a
quick look at the RFC again:
"2.4. Efficient Operation over Extended LANs
Sending IP packets on a multiaccess LAN requires mapping from an IP
address to a MAC address. The use of the virtual router MAC address
in an extended LAN employing learning bridges can have a significant
effect on the bandwidth overhead of packets sent to the virtual
router. If the virtual router MAC address is never used as the
source address in a link level frame then the station location is
never learned, resulting in flooding of all packets sent to the
virtual router. To improve the efficiency in this environment the
protocol should: 1) use the virtual router MAC as the source in a
packet sent by the Master to trigger station learning; 2) trigger a
message immediately after transitioning to Master to update the
station learning; and 3) trigger periodic messages from the Master to
maintain the station learning cache."
Now in light of that, let's have a look at a couple of captures (two routers
are 10.0.13.1 and 10.0.13.3 (the master) with 10.0.13.254 as the virtual
IP). Here is the traffic that conforms to the above text:
No. Time Source Destination Protocol
Info
1 6.685782 IETF-VRRP-virtual-router-VRID_01 Broadcast
ARP Gratuitous ARP for 10.0.13.254 (Reply)
Frame 1 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: IETF-VRRP-virtual-router-VRID_01 (00:00:5e:00:01:01), Dst:
Broadcast (ff:ff:ff:ff:ff:ff)
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Source: IETF-VRRP-virtual-router-VRID_01 (00:00:5e:00:01:01)
Type: ARP (0x0806)
Trailer: 000000000000000000000000000000000000
Address Resolution Protocol (reply/gratuitous ARP)
Hardware type: Ethernet (0x0001)
Protocol type: IP (0x0800)
Hardware size: 6
Protocol size: 4
Opcode: reply (0x0002)
Sender MAC address: IETF-VRRP-virtual-router-VRID_01 (00:00:5e:00:01:01)
Sender IP address: 10.0.13.254 (10.0.13.254)
Target MAC address: Broadcast (ff:ff:ff:ff:ff:ff)
Target IP address: 10.0.13.254 (10.0.13.254)
Naturally, it's necessary that the >source< MAC address be unicast and not
mcast. So now here is a hello capture so that we can see the destination
address employed by the VRRP master:
Frame 2 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: IETF-VRRP-virtual-router-VRID_01 (00:00:5e:00:01:01), Dst:
IPv4mcast_00:00:12 (01:00:5e:00:00:12)
Destination: IPv4mcast_00:00:12 (01:00:5e:00:00:12)
Address: IPv4mcast_00:00:12 (01:00:5e:00:00:12)
.... ...1 .... .... .... .... = IG bit: Group address
(multicast/broadcast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Source: IETF-VRRP-virtual-router-VRID_01 (00:00:5e:00:01:01)
Address: IETF-VRRP-virtual-router-VRID_01 (00:00:5e:00:01:01)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Type: IP (0x0800)
Trailer: 000000000000
Internet Protocol, Src: 10.0.13.3 (10.0.13.3), Dst: 224.0.0.18 (224.0.0.18)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0xc0 (DSCP 0x30: Class Selector 6; ECN:
0x00)
Total Length: 40
Identification: 0x0000 (0)
Flags: 0x00
Fragment offset: 0
Time to live: 255
Protocol: VRRP (0x70)
Header checksum: 0xc390 [correct]
Source: 10.0.13.3 (10.0.13.3)
Destination: 224.0.0.18 (224.0.0.18)
Virtual Router Redundancy Protocol
Version 2, Packet type 1 (Advertisement)
0010 .... = VRRP protocol version: 2
.... 0001 = VRRP packet type: Advertisement (1)
Virtual Rtr ID: 1
Priority: 100 (Default priority for a backup VRRP router)
Count IP Addrs: 1
Auth Type: No Authentication (0)
Adver Int: 1
Checksum: 0x62fe [correct]
IP Address: 10.0.13.254 (10.0.13.254)
Of course 01:00:5e:00:00:12 corresponds to the >destination< IP address of
224.0.0.18. So whenever you see a reference to the virtual MAC, they're
talking about the source MAC (which makes sense when you consider that the
virtual IP is of course also a source and not a destination). The
destination MAC is nothing unique in that it follows standard IP to MAC
mapping, as you yourself expected to see!
Scott
From: Wouter Prins [mailto:wp@null0.nl]
Sent: Saturday, January 03, 2009 11:51 AM
To: Scott Vermillion
Cc: Cisco certification
Subject: Re: two vrrp questions
Hi Scott :-)
2009/1/3 Scott Vermillion <scott_ccie_list@it-ag.com>
Hi Wouter,
We get so caught up in Cisco documentation and vendor training material, we
sometimes forget about RFCs!
yes, or other topics ;)
In answer to question one, from RFC 3768:
"7.3. Virtual Router MAC Address
The virtual router MAC address associated with a virtual router is an IEEE
802 MAC Address in the following format:
00-00-5E-00-01-{VRID} (in hex in internet standard bit-order)
The first three octets are derived from the IANA's OUI. The next two octets
(00-01) indicate the address block assigned to the VRRP protocol. {VRID} is
the VRRP Virtual Router Identifier. This mapping provides for up to 255
VRRP routers on a network."
Why did they pick the unicast OUI range for VRRP and not the multicast OUI
range (its a multicast ip address)? See
http://www.iana.org/assignments/ethernet-numbers it might be me but i still
dont understand it somehow? :)
In answer to question 2, it's a security feature:
"Independent of any authentication type VRRP includes a mechanism (setting
TTL=255, checking on receipt) that protects against VRRP packets being
injected from another remote network. This limits most vulnerabilities to
local attacks."
What this is saying is that if VRRP routers were to merely validate that TTL
was "1" inbound, then somebody n hops away could initialize TTL such that it
was 1 inbound when it reached the target of the attack. Whereas if VRRP
routers are configured to look for "255" inbound, then an attacker would
somehow have to figure out how to get intermediate routers to not decrement
TTL, which seems fairly unlikely!
Thanks, i couldnt see the reason behind the use of the TTL of 255, but with
this explanation i do. :)
Blogs and organic groups at http://www.ccie.net
This archive was generated by hypermail 2.1.4 : Sun Mar 01 2009 - 09:43:36 ARST