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:[email protected]] > Sent: Saturday, June 20, 2009 2:51 PM > To: [email protected] > 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 :) _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
