Hi,
> Actually in JUNOS you can specify a firewall such that it sends a
> 'host-unreachable' when rejecting a packet. Not sure about Cisco. When the
> other box is Juniper as well this could be the cause.
The other box is a cisco. Not sure which IOS it is using though.
>
> Is 10.254.1.2 maybe the loopback address of the other router?
It is not a loopback address, in fact it is the IP of another interface on
the same router as the unpingable IP(192.168.21.133 ).
This brings about the question: in what circumstances that the other
interface would reply with ICMP unreachable although I was pinging
192.168.21.133, the interface that is directly connected to me? Is there a
possibility that the router has no route to reach a directly connected
interface?
This really puzzles me...
sonny
>
> > -----Original Message-----
> > From: juniper-nsp-admin@puck.nether.net
> > [mailto:juniper-nsp-admin@puck.nether.net]On Behalf Of Guy Davies
> > Sent: donderdag 14 november 2002 19:00
> > To: 'Sonny I Franslay'; juniper-nsp@puck.nether.net
> > Subject: RE: [j-nsp] Need help on ping output
> >
> >
> > Hi Sonny,
> >
> > > Hi guy,
> > >
> > > Thanks for replying.
> > >
> > > > The address 10.254.1.2 is the source of the packets being
> > > sent back to
> > > > "router" with ICMP Destination Host Unreachable messages in
> > > them. That
> > > > means that your packets reached a router which had no route to the
> > > > destination host. I suggest that you identify the
> > location of that
> > > router.
> > >
> > > Is it possible that 10.254.1.2 is denying ICMP and thus
> > > return the ICMP Dest
> > > Host Unreachable? But it somehow allows other traffic
> > > (non-ICMP) through?
> >
> > Unlikely. Is 10.254.1.2 the same host as the far end of the link
> > (192.154.21.133?).
> >
> > > Could an ACL might cause this kind of ping reply?
> >
> > No, that would generate a different error.
> >
> > > In any case, what does each entry mean? (e.g Vr, HL .etc):
> > >
> > > 36 bytes from 10.254.1.2: Destination Host Unreachable
> > > Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
> > > 4 5 00 0054 e4db 0 0000 fe 01 2b8d 192.154.21.134
> > > 192.154.21.133
> >
> > Vr - Version (IPv4)
> > HL - Header Length?
> > TOS - Type of Service byte
> > Len - Length in bytes
> > ID - Fragment ID?
> > Flg - Flag (fragmentation?)
> > off - offset (from the beginning of the first fragment?)
> > TTL - Time to Live (255 in this case)
> > Pro - protocol? 1=ICMP
> > cks - checksum
> > Src - source
> > Dst - destination
> >
> > > > You need to check that the interface is actually up and
> > > you're not using
> > > > some alternative path to reach destinations "beyond" your
> > ATM link.
> > > >
> > > > I'd also suggest that you check your routing table and
> > > forwarding table to
> > > > see what the next hop for 192.168.21.133 is. If you don't
> > > see it using
> > > the
> > > > command "show route <blah>" then try "show route <blah>
> > > hidden extensive".
> > > > That might show you that the route is actually being
> > > filtered (perhaps
> > > > because 192.168.0.0/16 has been added to your martians?).
> > > If this is the
> > > > case, the packet may be using a default route to reach
> > > 10.254.1.2 but, if
> > > > that router is injecting the default, there will be no
> > > forwarding path
> > > from
> > > > there.
> > >
> > > There is no other path to reach 192.168.21.133. "show route
> > > <blah>" shows
> > > that the IP is learned via a connected subnet.
> > >
> > > router> show route 192.168.21.133
> > >
> > > inet.0:
> > > + = Active Route, - = Last Active, * = Both
> > >
> > > 192.168.21.132/30 *[Direct/0] 2d 17:54:22
> > > > via at-0/0/0.6
> > >
> > > I've checked that the route has not been added to the martian list.
> >
> > Strange.
> >
> > Guy
> >
> >
> > This e-mail is private and may be confidential and is for the intended
> > recipient only. If misdirected, please notify us by
> > telephone and confirm
> > that it has been deleted from your system and any copies
> > destroyed. If you
> > are not the intended recipient you are strictly prohibited from using,
> > printing, copying, distributing or disseminating this e-mail or any
> > information contained in it. We use reasonable endeavors to
> > virus scan all
> > e-mails leaving the Company but no warranty is given that
> > this e-mail and
> > any attachments are virus free. You should undertake your own virus
> > checking. The right to monitor e-mail communications through
> > our network is
> > reserved by us.
> >
> >
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp@puck.nether.net
> > http://puck.nether.net/mailman/listinfo/juniper-nsp
>
> Actually in JUNOS you can specify a firewall such that it sends a
> 'host-unreachable' when rejecting a packet. Not sure about Cisco. When the
> other box is Juniper as well this could be the cause.
The other box is a cisco. Not sure which IOS it is using though.
>
> Is 10.254.1.2 maybe the loopback address of the other router?
It is not a loopback address, in fact it is the IP of another interface on
the same router as the unpingable IP(192.168.21.133 ).
This brings about the question: in what circumstances that the other
interface would reply with ICMP unreachable although I was pinging
192.168.21.133, the interface that is directly connected to me? Is there a
possibility that the router has no route to reach a directly connected
interface?
This really puzzles me...
sonny
>
> > -----Original Message-----
> > From: juniper-nsp-admin@puck.nether.net
> > [mailto:juniper-nsp-admin@puck.nether.net]On Behalf Of Guy Davies
> > Sent: donderdag 14 november 2002 19:00
> > To: 'Sonny I Franslay'; juniper-nsp@puck.nether.net
> > Subject: RE: [j-nsp] Need help on ping output
> >
> >
> > Hi Sonny,
> >
> > > Hi guy,
> > >
> > > Thanks for replying.
> > >
> > > > The address 10.254.1.2 is the source of the packets being
> > > sent back to
> > > > "router" with ICMP Destination Host Unreachable messages in
> > > them. That
> > > > means that your packets reached a router which had no route to the
> > > > destination host. I suggest that you identify the
> > location of that
> > > router.
> > >
> > > Is it possible that 10.254.1.2 is denying ICMP and thus
> > > return the ICMP Dest
> > > Host Unreachable? But it somehow allows other traffic
> > > (non-ICMP) through?
> >
> > Unlikely. Is 10.254.1.2 the same host as the far end of the link
> > (192.154.21.133?).
> >
> > > Could an ACL might cause this kind of ping reply?
> >
> > No, that would generate a different error.
> >
> > > In any case, what does each entry mean? (e.g Vr, HL .etc):
> > >
> > > 36 bytes from 10.254.1.2: Destination Host Unreachable
> > > Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
> > > 4 5 00 0054 e4db 0 0000 fe 01 2b8d 192.154.21.134
> > > 192.154.21.133
> >
> > Vr - Version (IPv4)
> > HL - Header Length?
> > TOS - Type of Service byte
> > Len - Length in bytes
> > ID - Fragment ID?
> > Flg - Flag (fragmentation?)
> > off - offset (from the beginning of the first fragment?)
> > TTL - Time to Live (255 in this case)
> > Pro - protocol? 1=ICMP
> > cks - checksum
> > Src - source
> > Dst - destination
> >
> > > > You need to check that the interface is actually up and
> > > you're not using
> > > > some alternative path to reach destinations "beyond" your
> > ATM link.
> > > >
> > > > I'd also suggest that you check your routing table and
> > > forwarding table to
> > > > see what the next hop for 192.168.21.133 is. If you don't
> > > see it using
> > > the
> > > > command "show route <blah>" then try "show route <blah>
> > > hidden extensive".
> > > > That might show you that the route is actually being
> > > filtered (perhaps
> > > > because 192.168.0.0/16 has been added to your martians?).
> > > If this is the
> > > > case, the packet may be using a default route to reach
> > > 10.254.1.2 but, if
> > > > that router is injecting the default, there will be no
> > > forwarding path
> > > from
> > > > there.
> > >
> > > There is no other path to reach 192.168.21.133. "show route
> > > <blah>" shows
> > > that the IP is learned via a connected subnet.
> > >
> > > router> show route 192.168.21.133
> > >
> > > inet.0:
> > > + = Active Route, - = Last Active, * = Both
> > >
> > > 192.168.21.132/30 *[Direct/0] 2d 17:54:22
> > > > via at-0/0/0.6
> > >
> > > I've checked that the route has not been added to the martian list.
> >
> > Strange.
> >
> > Guy
> >
> >
> > This e-mail is private and may be confidential and is for the intended
> > recipient only. If misdirected, please notify us by
> > telephone and confirm
> > that it has been deleted from your system and any copies
> > destroyed. If you
> > are not the intended recipient you are strictly prohibited from using,
> > printing, copying, distributing or disseminating this e-mail or any
> > information contained in it. We use reasonable endeavors to
> > virus scan all
> > e-mails leaving the Company but no warranty is given that
> > this e-mail and
> > any attachments are virus free. You should undertake your own virus
> > checking. The right to monitor e-mail communications through
> > our network is
> > reserved by us.
> >
> >
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp@puck.nether.net
> > http://puck.nether.net/mailman/listinfo/juniper-nsp
>