Routing problem ?

[cbouraoui]

Hello,

We are facing a situation on our inter-sites network. The concerned sites are represented in the visio file attached into this email.

For a brief description of the inter-sites connections (please refer to the schema attached) :

• 3 sites are concerned :   
  • A (Cisco 6500 in VSS mode as a core network)
  • B (2 x Cisco 6500 as cores network working in HSRP)
  • C (2 x Cisco 4500 as cores network working in HSRP)
  • We have our own WAN (internal WAN provider)
  • A is connected to   
    • the WAN through 2 routers working in VRRP (so just 1 is represented on the schema)
    • B through a GRE Tunnel
    • B is connected to   
      • the WAN through 2 routers working in VRRP (so just 1 is represented on the schema)
      • C trough 2 x MAN links (each core network is directly connected to 1 remote-site core network)
      • A through a GRE Tunnel
      • C is connected to  
        • B through 2 x MAN links (each core network is directly connected to 1 remote-site core network)

Our issue can be resume as bellow :

• C core #1 (C-Core1) failed to reach the GRE Tunnel interface on A (A-Core1) through its own MAN link attached to B core#1
• C core#2 (C-Core2) succeed to reach the GRE Tunnel interface on A through its own MAN link attached to B core#2
• The odd part is that B core#2 routes the traffic to B#1 to reach the GRE Tunnel interface on A with succeed
• B core#1 and #2 succeed to reach any remote interfaces
• All routes are correctly announced to the remote sites in OSPF, or correctly installed in the routing table

We did a bunch of traceroutes to understand at what point the packet failed. These tests are resumed on the top of the shema (please refer on it).

The routing tables of each core are extracted only with the routes concerned on the process. 

Last detail, no ACL are applied on the inter-sites connection.

[cadet alain]

Hi,

for people not having Visio could you repost your config as jpg or pdf please.

Regards.

Alain.

[Vaibhava Varma]

Hi cbouraoui

Here is what I think might be happening looking at the setup. We are trying to ping the Tunnel interface IP on A_Cor1 and we do not have any reverse routes via the Tunnel Interface on A_Core1 pointing to B_Core1 Tunnel IP 215.50.195.145. Though we have a default route present pointing to the WAN connectviity so routing will work fine but again this is certainly assymetric routing.

Now since C_Core1 can Ping A_Core1 Tunnel IP means on the Site A WAN router somehow reachability information for 215.50.95.48/30 Subnet is there and even same is present on the Site B_WAN Router . But Site B WAN Router as well as Site A WAN routers do not have reverse route for 215.50.95.44/30 ie for C_Core1 Subnet.

Can you put a Static Route in A-COre1 router for 215.50.95.44/30 Subnet pointing to Tunnel Next hop-IP on B_Core_1 ie 215.50.195.145 and check once if the issue is resolved ?

Hope this helps something in finding solution for this issue.

Regards

Varma

[Kishore Chennupati]

Hi,

1. Are you sure you only have a default route on CoreA1 routing table and nothing else?

There should be a return route or something  on CoreA otherwise you wont be able to get success from CoreC2. Maybe a static route like this.

ip route 215.50.195.48 255.255.255.252 215.50.195.145

2. If you want CoreC1 to ping CoreA then on CoreA just add a static route

ip route 215.50.95.44 255.255.255.252 215.50.195.145

This should fix your issues

HTH,

Regards

Kishore

Edit: Also you need to make sure to check which source ip address you are using to ping the CoreA. if for eg: from CoreC2 when you just type

ping  215.50.195.146  it will use the physical interface of the interface through which it learned that ip . In your case it will be 215.50.95.50.

So once you put the static route  ip route 215.50.95.44 255.255.255.252 215.50.195.145 on CoreA. this means that you can use ping  215.50.195.146 on CoreC1. If you try to use any other source ip address on CoreC1 router it willl fail.

[cbouraoui]

Hi,

first of all, thank you for your answers.

But, even if it's asymetric routing, it should works fine because the subnet 215.50.95.44/30 is know as part of Site B by the operator.

i'm trying to understand why this won't work.

Any idea ?

PS : i joined the schema as jpg file. Thanks

Thanks

[Vaibhava Varma]

Hi cbouraoui

Are we sure that we have a reverse route for 215.50.95.44/30 all across the Path from A_Core1 to WAN_Router_A_to_WAN_Router_B to B_Core1.

Can you please share a trace originating from A_Core 1 to 215.50.95.45.

Anyways did putting up the Reverse Route via Tunnel Interface solved the issue or not ?

Regards

Varma

[cbouraoui]

Hi,

Stangely, when i ping A-Core1 from B-Core1 with source 215.50.95.45 and it works.

This topology is on production, so i can't do changes, i will try next week to put the reverse route.

But sincerely, i want just to understand why we can't reach A-Core1 from C-Core1

Thanks

[Vaibhava Varma]

Hicbouraoui

Thats really not an expected behaviour at all if the B-Core1 can ping to A-Core_1 Tunnel IP 215.50.195.146 with Source as C_Core1 215.50.95.44/30.

However did you check the trace originating from A_Core 1 to 215.50.95.45 with source as 215.50.195.146 that where does it stop ?

Regards

Varma

[Kishore Chennupati]

Hi Varma,

He is pinging using the source address of  215.50.95.45  which is on CoreB and its acceptable. It would work if they have a route back to that ip on CoreA.

cbouraoui,

Can you please post the ping results here? and also the routing table of CoreA.?

Once you add (ip route 215.50.95.44 255.255.255.252 215.50.195.145) on CoreA  it should work from CoreC1 too.

HTH

Regards

Kishore