Mailing List Archive

Hi Sonny,

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.

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.

Hope that gives you a few ideas.

Regards,

Guy
>
> Hi all,
>
> Recently I've just upgraded our M5 to Junos 5.3R3.4 from 5.0. Peculiar
> thing is that one of our ATM pt-pt interface started to behave
> strangely when we try to ping the neighboring interface. But
> traffic is
> still able to transverse via the ATM PVC link normally.
>
> Below is the ping output:
>
> router> ping interface at-0/0/0.6 192.168.21.133
> PING 192.168.21.133 (192.168.21.133): 56 data bytes
> 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 bc38 0 0000 fe 01 5430 192.168.21.134
> 192.168.21.133
>
> 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 bc79 0 0000 fe 01 53ef 192.168.21.134
> 192.168.21.133
>
> 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 bc81 0 0000 fe 01 53e7 192.168.21.134
> 192.168.21.133
>
> ^C
> --- 192.168.21.133 ping statistics ---
> 7 packets transmitted, 0 packets received, 100% packet loss
>
>
> No changes were done on the interface config after the junos upgrade.
> There is no firewall filter configured on the interface either.
>
> The config of the interface:
>
> [edit]
> router# show interfaces at-0/0/0 unit 6
> encapsulation atm-snap;
> vci 1.40;
> oam-period 10;
> family inet {
> address 192.168.21.134/30;
> }
> family mpls;
>
> [edit]
>
> I was hoping someone could help me decipher the meaning of
> the ping output
> and what is the IP 10.254.1.2 signify?
>
> Many thanks in advance.
>
>
> /sonny
>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/juniper-nsp
>


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.

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?

Could an ACL might cause this kind of ping reply?

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

>
> 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.


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.

sonny

> > Hi all,
> >
> > Recently I've just upgraded our M5 to Junos 5.3R3.4 from 5.0. Peculiar
> > thing is that one of our ATM pt-pt interface started to behave
> > strangely when we try to ping the neighboring interface. But
> > traffic is
> > still able to transverse via the ATM PVC link normally.
> >
> > Below is the ping output:
> >
> > router> ping interface at-0/0/0.6 192.168.21.133
> > PING 192.168.21.133 (192.168.21.133): 56 data bytes
> > 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 bc38 0 0000 fe 01 5430 192.168.21.134
> > 192.168.21.133
> >
> > 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 bc79 0 0000 fe 01 53ef 192.168.21.134
> > 192.168.21.133
> >
> > 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 bc81 0 0000 fe 01 53e7 192.168.21.134
> > 192.168.21.133
> >
> > ^C
> > --- 192.168.21.133 ping statistics ---
> > 7 packets transmitted, 0 packets received, 100% packet loss
> >
> >
> > No changes were done on the interface config after the junos upgrade.
> > There is no firewall filter configured on the interface either.
> >
> > The config of the interface:
> >
> > [edit]
> > router# show interfaces at-0/0/0 unit 6
> > encapsulation atm-snap;
> > vci 1.40;
> > oam-period 10;
> > family inet {
> > address 192.168.21.134/30;
> > }
> > family mpls;
> >
> > [edit]
> >
> > I was hoping someone could help me decipher the meaning of
> > the ping output
> > and what is the IP 10.254.1.2 signify?
> >
> > Many thanks in advance.
> >
> >
> > /sonny
> >
> >
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp@puck.nether.net
> > http://puck.nether.net/mailman/listinfo/juniper-nsp
> >
>
>
> 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.
>
>

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.

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.

Is 10.254.1.2 maybe the loopback address of the other router?

cheers,
Eduard

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

Eduard,

On Fri, 15 Nov 2002, Eduard Metz wrote:

> 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

If the firewall has action "reject", it will send back an ICMP message
(I'm not sure if it is unreachable or administrative prohibited).

It the action is "discard" it will drop the packet silently.

> other box is Juniper as well this could be the cause.
k

On Fri, 2002-11-15 at 18:41, German Martinez wrote:
> Eduard,
>
> On Fri, 15 Nov 2002, Eduard Metz wrote:
>
> > 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
>
> If the firewall has action "reject", it will send back an ICMP message
> (I'm not sure if it is unreachable or administrative prohibited).

Actually, with the "reject" action you can select what ICMP message the
router sends in return, both host unreachable and administrative
prohibited are of course among the possibilities (as well as some quite
rarely used ones that you can really get unsuspecting engineers to
scratch their heads over :)

/leg