Been awhile since I've read this list, but saw this posting and figured I'd offer an alternative way of looking at this. I can recall a time when I had to make a move just like this, without knowning what the mix of devices was on that L2 network. If you don't need the original router for something extremely soon you can just move the IP address and keep an address with ip forwarding enabled on the depricated(historic) router. Policy routing on that interface works good when the historic router needs to carry on other tasks as well.
If you are moving service from R1 to a new router R2 do the following by connecting to those routers independantly of the moving address: R1: conf t int fa0/0 ip address R2: conf t int fa0/0 ip address Now you've got the hosts which have arp'ed or have fixed arp tables sending traffic to R2. You have stale arp entries with the MAC address of R1, which is receiving and handling traffic as before. You've got time to fix the host's arp tables via any number of different methods. You can watch the packet input rate on R1's interface and see which hosts are still not cleaned up. If the input rate doesn't match output then most of the packets coming in are probably junk of some sort dhcp or other broadcasts. As the volume drops you can probably use an inbound acl on the interface to log packets...there is likely some noise of packets which will be coming in and you want to make sure it's really noise and not a valid host still forwarding to R1. It would be advisable to finally shutdown R1's interface in a maintenance window just in case you missed something... A plus and minus depending upon how you look at it is R1 would now be issuing icmp redirects to the address those hosts thought they were sending things to anyway. The plus side is the admins of those hosts catch them in logs and think about it at which time you should have educated them already about what it is and to DO something about it before R1 gets shutdown. The minus side is some hosts's IP stacks insert permanent host records for each redirect they receive which means you could cause them cleanliness problems(memory, forwarding table size, ...). Consider turning off redirects on R1's interface if you haven't already turned it off everywhere. if you need to force traffic through R2 go back to R1 because R1's existing config can't support accepting the remaining traffic: access-list 100 permit ip any any (change this if you have other traffic entering this interface you don't want to force toward R2) route-map moveto-r2 match ip addr 100 set ip next-hop int fa0/0 ip policy route-map moveto-r2 A variation on other suggestions would be if R1 and R2 are both attached to the same switch getting L2 forwarding of R1's mac wouldn't be hard along with setting the MAC of R2's interface. Not sure if that'd work in your environment though. Good Luck, Darrell Newcomb Always looking for the next killer project.... darrell(at)hayaitacosnet ""John Neiberger"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > I'm planning on moving routing responsibilities from a router to our > 6513 and I *really* need to minimize downtime. I'll be moving an > interface IP address from one device to another and this is the default > gateway for all devices on that network. The problem is that all > devices on that subnet will have the wrong MAC address in their ARP > caches. I know that if I issue a unicast ping from the new router it > will force the end host to update its ARP cache but a broadcast ping > does not accomplish the same thing, probably because most devices ignore > a broadcast ping, and I don't feel like pinging every device > individually. > > I can't configure HSRP just to gain the benefit of gratuitous ARP; > simply configuring it will be disruptive and that's what I'm trying to > avoid. > > Any ideas? > > Thanks, > John Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=51803&t=51674 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
