On Sun, 27 Jun 2004, Stephen J. Wilcox wrote:
Hi Jon, I currently have a few .255/32s with Cisco and Foundry products and have various windows/linux/OSX machines that access them without problems..
I'm pretty confident this is a classful/classless bug in 12.1T. I just got into the customer's router that was sending what looked like replies to a broadcast ping, and that's just what it was. Here's the output from debug ip packet on the CPE that was replying when I pinged 209.208.6.255 from the 7206. IP: s=209.208.6.xyz (Serial0.2), d=255.255.255.255, len 100, rcvd 2 IP: s=209.208.6.xyz (Serial0.2), d=255.255.255.255, len 100, rcvd 2 IP: s=209.208.6.xyz (Serial0.2), d=255.255.255.255, len 100, rcvd 2 Checked with an ACL on the input side of the CPE's serial subint, *Mar 3 08:40:19: %SEC-6-IPACCESSLOGDP: list test permitted icmp 209.208.6.xyZ (Serial0.2 DLCI 100) -> 255.255.255.255 (0/0), 1 packet where 209.208.6.xyz is the customer's serial IP, and 209.208.6.xyZ is the 7206's serial IP. Both ends to have no ip directed-broadcast.
I found some time ago that my home DSL connected network could not reach (telnet, ping, etc.) that router's loopback. Our monitoring system could, and several iBGP peers could, so I didn't notice the issue until one night when trying to do some work from home.
I could see the problem with DSL's where the provider may be interfering.. surprised about your monitoring tho...
No...I said the monitoring system didn't have a problem with it. It fortunately doesn't have to transit the affected router which only handles T1 & DSL aggregation (including my home DSL).
#sh ip ro 209.208.6.255 Routing entry for 209.208.6.255/32 Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 4 Last update from 209.208.16.29 on FastEthernet0/0.1, 00:46:47 ago Routing Descriptor Blocks: * 209.208.16.29, from 209.208.6.255, 00:46:47 ago, via FastEthernet0/0.1 Route metric is 20, traffic share count is 1
#sh ip cef 209.208.6.255 209.208.6.255/32, version 12215105, cached adjacency 209.208.16.29 0 packets, 0 bytes tag information set, shared local tag: 398 fast tag rewrite with Fa0/0.1, 209.208.16.29, tags imposed: {114} via 209.208.16.29, FastEthernet0/0.1, 0 dependencies next hop 209.208.16.29, FastEthernet0/0.1 valid cached adjacency tag rewrite with Fa0/0.1, 209.208.16.29, tags imposed: {114} #sh tag-switching forwarding-table 209.208.6.255 detail Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 398 114 209.208.6.255/32 0 Fa0/0.1 209.208.16.29 MAC/Encaps=18/22, MTU=1520, Tag Stack{114} 0001638B90000005DC493400810000018847 00072000 No output feature configured Per-packet load-sharing It knows the next hop is another 7206 with connections to the rest of our network. Why is it sending this out as a broadcast ping instead of routing (tag switching) it? I know...wrong list. I'll ask on cisco-nsp, but the operational lesson here is that it's not just the junk from Redmond that may have classful/classless IP routing issues. Even your core routers might, depending on IOS versions. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________