Routing issue.

Answered Question

/* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0cm 5.4pt 0cm 5.4pt; mso-para-margin-top:0cm; mso-para-margin-right:0cm; mso-para-margin-bottom:10.0pt; mso-para-margin-left:0cm; line-height:115%; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"Times New Roman"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin;}

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

Attachment: 
Correct Answer by lamav about 7 years 1 day ago

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


Thx

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.

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 Thu, 02/25/2010 - 10:51

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

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.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
Correct Answer
lamav Fri, 02/26/2010 - 01:12

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


Thx

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 Fri, 02/26/2010 - 05:55

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

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 Tue, 03/02/2010 - 04:03

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

Actions

This Discussion