[c-nsp] annoying vrrp code changes

[Jon Lewis]

I did a long overdue code upgrade on a pair of 6509s today and ran into a 
few unexpected hiccups.  I guess cisco's VRRP implementation in 6500 
122-18.SXD7b was non-RFC compliant.  I had many VLANs with VRRP group 0 
configured.  Under 12.2 SXI (and according to the RFC), the VRID field 
(what I assume IOS calls the VRRP group number) is 1-255.  That was 
obvious and easy to fix.  All the vrrp 0's were rejected by the config 
parser at bootup.

Neither obvious, nor quite as trivial to fix, in the older implementation, 
it was possible to migrate a customer from a single gateway to a VRRP 
gateway without using any more of their IPs by putting the two gateway 
router physical interfaces into a different subnet than the VRRP IP.  i.e.

router1:
int vlan100
  ip address 10.0.0.1/30
  vrrp 1 ip 192.168.0.1
  ...
ip route 192.168.0.0 255.255.255.224 vlan100

router2:
int vlan100
  ip address 10.0.0.2/30
  vrrp 1 ip 192.168.0.1
  ...
ip route 192.168.0.0 255.255.255.224 vlan100

In the SXI implementation, VRRP configured this way doesn't get past 
"State Init".  Apparently, if you don't have a VRRP IP in the same subnet 
as the phys interface IP, VRRP won't work.  If you do have a VRRP IP in 
the phys interface subnet, you can also have secondary VRRP IPs outside 
the phys interface subnet, using the above trick of routing the foriegn 
subnet to the interface.  So, the workaround for the above situation is to 
renumber the physical interfaces into at least a /29, create an otherwise 
unnecessary VRRP IP in the /29, and then configure the customer's VRRP 
gateway as a secondary.

----------------------------------------------------------------------
  Jon Lewis, MCP :)           |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________