Routing issue.

[andrea.meconi]

I’m using OSPF and route static redistribution between four nodes: two VPN concentrators and two Catalyst 3550.

A static route on the switches is also applied for network 192.17.176.0/20 to 172.31.224.254.

ip route 192.17.176.0 255.255.240.0 172.31.224.254

sw-extranet11#sh ip route 192.17.176.21

Routing entry for 192.17.176.0/20

  Known via "static", distance 1, metric 0

  Redistributing via ospf 172

  Routing Descriptor Blocks:

  * 172.31.224.254

      Route metric is 0, traffic share count is 1

When I try with a trace to a host, the switch sends all packets to the concentrator, also ignoring the ICMP redirect.

sw-extranet11#trace 192.17.176.21

Type escape sequence to abort.

Tracing the route to 192.17.176.21

  1 172.31.253.250 4 msec 0 msec 0 msec

ICMP: redirect rcvd from 172.31.253.250-- for 172.31.224.254 use gw 172.31.224.254

Any suggestions are appreciated!

Regards.

Andrea

[andrea.meconi]

Any ideas!?

Thanks.

Andrea

[Reza Sharifi]

Hi Andrea,

ICMP redirect messages are used by routers to notify the hosts on the data link that a better route is available for a particular destination.

Have a look at this paper explaining ICMP redirect:

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094702.shtml

HTH

Reza

[andrea.meconi]

Hello Reza and many thanks for your help.

It sounds good! But I don't understand why the 3550 ignores the routing table and try to send packet to the concentrator, and ignores the redirect message from concentrator also!

sw-extranet11#clear ip route *

sw-extranet11#sh ip route 192.17.176.0

Routing entry for 192.17.176.0/20

  Known via "static", distance 1, metric 0

  Redistributing via ospf 172

  Routing Descriptor Blocks:

  * 172.31.224.254

      Route metric is 0, traffic share count is 1

sw-extranet11#trace 192.17.176.21

Type escape sequence to abort.

Tracing the route to 192.17.176.21

  1 172.31.253.249 0 msec

    172.31.253.250 0 msec

    172.31.253.249 4 msec

  2  *  *  *

Regards.

Andrea

[Giuseppe Larosa]

Hello Andrea,

the switch should use the next-hop specified in the static route not the other one.

so or a local policy command is present on the C3550 to send packets overriding the IP routing table or something has gone wrong with CEF.

I would start by looking at the configuration

sh run | inc policy

if nothing is found I would try to refresh the CEF table

clear ip route *

Hope to help

Giuseppe

[andrea.meconi]

Hello Giuseppe and many thanks for your help.

I don't use any policy on 3550.

I don't understand why the 3550 ignores the routing table and try to send packet to the concentrator, and ignores the redirect message from concentrator also!

sw-extranet11#clear ip route *sw-extranet11#sh ip route 192.17.176.0Routing entry for 192.17.176.0/20  Known via "static", distance 1, metric 0  Redistributing via ospf 172  Routing Descriptor Blocks:  * 172.31.224.254      Route metric is 0, traffic share count is 1sw-extranet11#trace 192.17.176.21Type escape sequence to abort.Tracing the route to 192.17.176.21  1 172.31.253.249 0 msec    172.31.253.250 0 msec    172.31.253.249 4 msec  2  *  *  * Regards.Andrea

[lamav · Accepted solution]

Andrea, can you post the device's entire config as well as the cef entry for the route?

Thx

[andrea.meconi]

Hello Lamav and many thanks for your help.
Sorry but I cannot post the configuration.
About CEF...

sw-extranet11#sh ip cef 192.17.176.0 255.255.240.0
192.17.176.0/20
  nexthop 172.31.253.249 Vlan510
  nexthop 172.31.253.250 Vlan510
sw-extranet11#

Multi-path may be an OSPF misconfiguration.

I have another question.
Yesterday, I have isolated one concentrator with a

interface f0/x
shutdown

and lost my SSH session with the switch.
Why? I'm using a PAT with firewall's IP when connecting to the switch

sw-extranet11#sh users
    Line       User       Host(s)              Idle       Location
*  1 vty 0     ameconi    idle                 00:00:00 172.31.224.254

  Interface      User        Mode                     Idle     Peer Address

sw-extranet11#

Maybe the same main cause!?
Regards.
Andrea

[Giuseppe Larosa]

Hello Andrea,

Victor has had a good idea:

we see that sh ip route and sh ip cef output are not in agreement:

sw-extranet11#sh ip cef 192.17.176.0 255.255.240.0
192.17.176.0/20
  nexthop 172.31.253.249 Vlan510
  nexthop 172.31.253.250 Vlan510
sw-extranet11#

! CEF has the two OSPF routes

sw-extranet11#sh ip route 192.17.176.0

Routing entry for 192.17.176.0/20

  Known via "static", distance 1, metric 0

  Redistributing via ospf 172

  Routing Descriptor Blocks:

  * 172.31.224.254

! IP routing table has the static route entry

This explains the behaviour of the switch.

Hope to help

Giuseppe

[andrea.meconi]

Sorry Giuseppe!

I understand that routing table and CEF cache are different.

But I don't understand how I can solve this behaviour!

Thanks.

Andrea

[andrea.meconi]

Hello.

After some investigations I believe that this inconsistency comes from OSPF. I am considering to filter incoming routes.
Regards.

Andrea

[andrea.meconi]

Hello Giuseppe.

Applying this incoming filter

access-list 77 permit 172.31.224.0 0.0.0.255

route-map incoming-filter deny 10
match ip address 77
route-map incoming-filter permit 20

router ospf 172
distribute-list route-map incoming-filter in

I'm able to correct the CEF inconsistency.

sw-extranet11#sh ip cef 192.17.176.0 255.255.240.0
192.17.176.0/20
  nexthop 172.31.224.254 Vlan510
sw-extranet11#

I found a mismatch configuration on VPN Concentrator: an invalid and redistribuited static route to 172.31.224.0/24 via 172.31.224.254

Regards.

Andrea

[Giuseppe Larosa]

Hello Andrea,

this is good news.

I was sure you could find out the issue

if I've understood correctly the VPN concentrators were redistributing an unwanted prefix in OSPF that was more specific then the legitimate static route.

>> nvalid and redistribuited static route to 172.31.224.0/24 via  172.31.224.254

But that is the same IP subnet as next-hop 172.31.224.254 that should appear as a connected also on the multilayer switch, isn't it?

Anyway, you have solved this issue and this is what really counts.

You have been kind to provide feedback, it makes this a complete case useful also for other people.

Best Regards

Giuseppe