4.5 OSPF | GRE Tunnel Sw2 to R5 ?!?!

Hi guys,

I'm trying to get this section work, and I thought of configuring a gre tunnel between Sw2 and R5, as it does not break the statements.

Here is the confg :

Sw2 :

interface Tunnel58
 ip address 144.58.58.8 255.255.255.0
 ip ospf 1 area 0
 tunnel source 144.4.78.8
 tunnel destination 144.4.15.5
end

 

R5 :

interface Tunnel58
 ip address 144.58.58.5 255.255.255.0
 ip ospf 1 area 0
 tunnel source 144.4.15.5
 tunnel destination 144.4.78.8
end

As I was getting recursive errors, I filtered tunnel destination, inbound direction on both R5 and Sw2 :

R5 :

ip prefix-list TUNN_DEST: 2 entries
   seq 5 deny 144.4.78.0/24
   seq 10 permit 0.0.0.0/0 le 32

RSRack4R5#sh run | s r ospf
router ospf 1
 log-adjacency-changes
 network 144.4.5.5 0.0.0.0 area 0
 network 144.4.15.5 0.0.0.0 area 0
 distribute-list prefix TUNN_DES in Tunnel58

 

Sw2 :

ip prefix-list TUNN_DEST: 2 entries
   seq 5 deny 144.4.15.0/24
   seq 10 permit 0.0.0.0/0 le 32

RSRack4SW2#sh run | b r ospf
router ospf 1
 log-adjacency-changes
 network 144.4.78.8 0.0.0.0 area 1
 network 150.4.8.8 0.0.0.0 area 1
 network 192.10.4.8 0.0.0.0 area 51
 distribute-list prefix TUNN_DEST in Tunnel58

 

NOW, the ospf adjcency between R5 and Sw2 is flapping, and I can't realize why.

 

RSRack4R5#
Oct  6 02:41:26.523: %OSPF-5-ADJCHG: Process 1, Nbr 150.4.8.8 on Tunnel58 from LOADING to FULL, Loading Done
RSRack4R5#
Oct  6 02:41:56.627: %OSPF-5-ADJCHG: Process 1, Nbr 150.4.8.8 on Tunnel58 from LOADING to FULL, Loading Done
RSRack4R5#
Oct  6 02:42:26.555: %OSPF-5-ADJCHG: Process 1, Nbr 150.4.8.8 on Tunnel58 from LOADING to FULL, Loading Done

 

I see it's on a 30 seconds basis, any ideas ??

Please provide your thoughts.

Thank you,

Ciprian.

Comments

  • Hi,

    Actually, the interface tunnel 58 itself is bouncing :

     

    *Mar  1 04:32:36.073: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel58, changed state to down
    *Mar  1 04:32:36.073: %OSPF-5-ADJCHG: Process 1, Nbr 150.4.5.5 on Tunnel58 from FULL to DOWN, Neighbor Down: Interface down or detached
    RSRack4SW2#
    *Mar  1 04:32:46.081: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel58, changed state to up
    *Mar  1 04:32:46.584: %OSPF-5-ADJCHG: Process 1, Nbr 150.4.5.5 on Tunnel58 from LOADING to FULL, Loading Done

     

    Any ideas ?

    Ciprian.

  • Hi,

    So I see that without OSPF configured on the tunnels, tunnels remain UP, so it has to be related to OSPF, the routes it learns through OSPF ...

    I'll do some more digging now ...

    Ciprian.

  • Hi Ciprian,

    I think your filtering with distribute-list is not working properly. Please try filtering specific prefix .i.e. 144.4.78.8/32 on R5 & same configuration for Sw1 as well. You can view "show ip route" in order to find what prefixe length you are are learning.

    If your tunnel is not stable then its not possible for you to have sable OSPF neighborship. So, probably it could be due to recursive routing or else.

    Hope this helps!

  • Hi,

    Please check for the filtering you are doing on both the devices.

    HTH

  • Hi,

    So I see that without OSPF configured on the tunnels, tunnels remain UP, so it has to be related to OSPF, the routes it learns through OSPF ...

    I'll do some more digging now ...

    Ciprian.

    Hi Ciprian,

    I believe you were getting recursive routing issue which was causing your tunnel interface to flap. So, in order to avoid such an issue, you have various options like AD manipulation, route filtering etc. I think you had some issues when filtering that particular prefix from entering into the OSPF domain. Try avoiding that particular prefix from being installed into OSPF routing table, it will work fine.

    Good luck!

  • Hi,

    I got a strange (I say strange because I don't understand what's really happening :) ) result while testing :

    So I got it working by configuring on Sw2 an ip route to the tunnel destination :

    ip route 144.4.15.5 255.255.255.255 144.4.78.7

    but I did't have to configure a static route on R5 also.

    Regarding the filtering, I have configured on both sides to deny tunnel destination and permit everything else , should it be configured this way ? Basically, I denied a /24 route as this is what's being propagated.

    One more thing I observed ... and I know it's important but can't really understand why it's happening :

    after ospf is UP on tunnel also, I loose route on SW2 toward 144.4.15.5 which I think this is why the static route solved the question, as I see it's not a recursive error anymore.

    So I think this is the key, why isn't the subnet between R1-R5 getting to Sw2  when OSPF neighbor relationship between Sw2 and R5 is UP ?

    Any ideas ?

    Thanks,

    Ciprian.

  • I would try static routing as this should resolve your recursive routing issues. Distribute-lists mean a totally different thing when working with OSPF, it works with EIGRP, though.

Sign In or Register to comment.