[c-nsp] ipv4 link-local for eigrp
Alexander Clouter
alex at digriz.org.uk
Sat Jun 20 08:50:43 EDT 2009
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.
More information about the cisco-nsp
mailing list