1. Home
  2. Cisco Systems
  3. OSFP router-id not appearing in traceroute (on 7204VXR)

OSFP router-id not appearing in traceroute (on 7204VXR)

I setup ospf routing with 3 routers in our network. All routers are part of Area 0, as they form the backbone.

| RTA |--------| RTB |--------| RTC |

  • RTA and RTB are Cisco 7204VXR * RTC is a Linux/Quagga Router * RTA and RTB are both members of Area 1 * RTC is only member of Area 2

The interfaces in between RTA, RTB and RTC have private IPs configured (RTA 10.0.0.1, RTB 10.0.0.2, RTC 10.0.0.3). The ospf processes have a router-id set. It's the IP of the first loopback interface, an official IP from a routeable aggregate (xx.xx.xx.65, xx.xx.xx.66 and xx.xx.xx.67). Also "maximum-paths 1" is set on all cisco routers.

When I trace the loopback IP of RTA from RTB, it looks like this:

RTB#traceroute xx.xx.xx.65

Type escape sequence to abort. Tracing the route to xx.xx.xx.65

1 10.0.0.1 [AS xxxx] 0 msec * 0 msec

But when I trace the loopback IP of RTC (linux box), it looks like this:

RTB#traceroute xx.xx.xx.67

Type escape sequence to abort. Tracing the route to xx.xx.xx.67

1 xx.xx.xx.67 0 msec 4 msec 0 msec

All routers are equally configured. The only difference is, that RTC is a linux box.

RTB# show ip ospf

O xx.xx.xx.65/32 [110/2] via 10.0.0.1, 13:59:39, FastEthernet3/0 O xx.xx.xx.67/32 [110/11] via 10.0.0.3, 13:59:39, FastEthernet3/0

RTB#show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface xx.xx.xx.65 100 FULL/BDR 00:00:37 10.0.0.1 FastEthernet3/0 xx.xx.xx.67 1 FULL/DR 00:00:37 10.0.0.3 FastEthernet3/0 xx.xx.xx.65 100 FULL/DR 00:00:37 192.168.100.1 FastEthernet0/0

  • Line 1: RTA area 0
  • Line 2: RTC area 0
  • Line 3: RTA area 1

What do I need to configure, in order to let RTA return it's router-id in the traceroute, but not the private IP?

Or would it be better to use official IPs only on the OSPF backbone interfaces?

I kept this example simple. RTA is also an ASBR, so a traceroute from the outside to .67 (RTB) also includes it's private ip 10.0.0.2 as last hop in the trace.

Any help or advice would be highly appreciated.

Thanks in advance,

Michael

Reply to
m.rennt
Loading thread data ...

traceroute in Cisco routers has no knowledge of OSPF.

Traceroute use ICMP echo and echo-reply messages.

The source IP address of the ICMP packet is the "nearest" interface IP address to the destination IP address being traced

While IOS provides the ability to change this behaviour in certain cases ( for example "ip ftp source-interface") AFAIK this is not possible for traceroute.

Reply to
Merv

I completely understand that. As there's a route to xx.xx.xx.65 via

10.0.0.1 it uses the local interfaces that is connected to 10.0.0.0/24.

O xx.xx.xx.65/32 [110/2] via 10.0.0.1, 13:59:39, FastEthernet3/0

What really bugs me, is that a traceroute to RTC (a linux machine) does return the actual loopback IP that is traced and not the private IP.

Why would RTA return 10.0.0.1 in the ICMP reply when the traceroute is actually directed to xx.xx.xx.65, which is configured on the loopback interface on RTA?

i.e.

--------------------------------- Traceroute to Cisco Router RTA

---------------------------------

RTB#traceroute xx.xx.xx.65

Type escape sequence to abort. Tracing the route to xx.xx.xx.65

1 10.0.0.1 [AS xxxx] 0 msec * 0 msec

--------------------------------- Traceroute to equally configured linux router RTC

---------------------------------

RTB#traceroute xx.xx.xx.67

Type escape sequence to abort. Tracing the route to xx.xx.xx.67

1 xx.xx.xx.67 0 msec 4 msec 0 msec
Reply to
mrennt

that tells me that the linux router is not building the ICMP time- exceeded message "correctly". One would expect the IP address of the ingress interface to be used not some logical interface on the box.

Reply to
Merv

The address displayed by traceroute is the source address returned in the ICMP time-exceeded packet.

In other words the issue is with the behaviour of the LINUX router.

Check to see if there are configuration option on the linux box.

The issue is NOT on the Cisco routers

Reply to
Merv

We're not talking about the ICMP time-exceeded packet produced by an intermediate gateway.

We're not talking about an ICMP echo-reply packet produced by the final destination.

We're not talking about an ICMP-based Windows style traceroute.

We're talking about a UDP-based Unix style traceroute

The question at hand is what source IP address is appropriate on the ICMP unreachable (port unreachable) datagram produced at the final destination when a UDP datagram arrives for a port on which no application is listening.

Reply to
briggs

ICMP or UDP it matters not - the expected behaviour is that the return packet will have the source IP address on which the packet was received by the device generating the return packet

Reply to
Merv

Nope.

With ICMP the echo reply packet will have the source IP address that was the destination address of the echo request.

With UDP the "port unreachable" report will tend to have the source IP address of the interface on which the UDP packet was received.

Note well the distinction here. With ICMP you get a reply. With UDP you get a non-delivery report. The distinction is important.

Test it. I did.

Reply to
briggs

I should correct myself here. It is, of course, the interface on which the outbound ICMP report is sent that matters, not the interface on which the inbound UDP packet is received.

However it remains the case that ICMP echo replies are conventionally sent with a source IP address that corresponds to the destination address of the inbound ICMP echo request.

Reply to
briggs

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.