[c-nsp] ipv4 link-local for eigrp

[Alexander Clouter]

Hi,

After an organisational switch refresh last year we have been 
fortunately enough to end up with surrounded by nothing but 3750 stacks 
(c3750-ipbasek9-mz.122-50.SE1.bin) at the edge of the network; the core 
is made up by a pair of 6509's (s72033-ipservicesk9-mz.122-33.SXI.bin).  
As we were overhauling the network we decided to have some fun and 
rollout L3 to the edge to obliterate spanning-tree where-ever we can.  
As Cisco boxen are a pain and don't let you have true 'hybrid' L2+L3 
links (we still have some L2 action at the edge) and assign IP addresses 
to trunk links we use 'native' VLAN's to route the L3 stuff through the 
link.

This all works great and we are happy with it, however now things are 
working, I hoping to now have a 'lessons learned' fixup of the bits that 
niggle at me.  This ties in with the IPv6 rollout we are doing over the 
next few months and I thought it's worth fixing up the IPv4 stuff at the 
same time.

The biggest issue is all the rfc1918 usage used in the /30 used to force 
the L3 routes out to the edge of the network which make traceroutes 
ugly.  I really do not want to put aside publicly routable addresses 
that are just used to pass EIGRP data around, as that would involve 
soaking up over 50 /30's, a bit of a waste.

So what to use, I am pretty keen to use link-local IPv4 addresses 
(169.254.0.0/16) much like I plan to for IPv6 to build up the L3 
point-to-point links and they are perfect for this situation.  The 
downside is that I run into the following issues:
 1. 169.254.0.0/16 can start to appear in the distributed EIGRP listings
 2. traceroutes have 169.254.0.0/16 addresses in them
 3. 169.254.0.0/16 is pingable by edge hosts as the switch they are
        plugged into knows of at least one 169.254.0.0/16 address.
	These addresses should never escape the local subnet

Now apparently I can solve the first issue by properly fixing up the way 
we use EIGRP, possibly involving liberal use of 'ip prefix-list' 
filtering or something similar?

There is *very* little online about if the second issue can even be 
solved on Cisco kit, but I did stumble on a suggestion to use 
NAT/route-map's (that would work perfectly for us as the Loopback0 
interface on are kit is a non-rfc1918 address):

https://cisco.hosted.jivesoftware.com/message/4910

I could not get this to work, but I was only tinkering with it for a 
couple of hours.  If only IOS had a 'ip icmp source interface...' 
command :)

I do have no idea on how I could fix the third issue or if it is even 
possible.  I would have hoped the kit would have a way to say "don't 
route where the source, or dest, IP address is in this ACL list".  I 
guess I could build ACL lists and place them on all the edge switches 
and just throw these packets into oblivion, however that would not be a 
global setting, instead a messy per-vlan settings surely?

So, I'm hoping someone can make any suggestions on how I could go about 
doing this.  Suggestions on how to tackle all three issues would be 
great as I'm not 100% on that I do know how to solve the first two 
issues.  Has anyone else done or heard of anyone using local-link 
addresses for routing between...erm...routers and then fixed the ICMP 
issue.

Even if the advice is "well if you had xy software you could do z".

Thanks in advance for any clue you can impart onto me.

Cheers

-- 
Alexander Clouter
.sigmonster says: The life of a repo man is always intense.