[c-nsp] ipv4 link-local for eigrp

[Ivan Pepelnjak]

You could use unnumbered Ethernet VLAN subinterfaces assuming your IOS
release supports them (or you could get your gear upgraded to a release that
does ... I am utterly confused when faced with Catalyst IOS releases):

http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gtunvlan.html

Ivan
 
http://www.ioshints.info/about
http://blog.ioshints.info/

> -----Original Message-----
> From: Alexander Clouter [mailto:alex at digriz.org.uk] 
> Sent: Saturday, June 20, 2009 2:51 PM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] ipv4 link-local for eigrp
> 
> 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).  

[...]

> 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 :)