12-27-2005 07:21 AM - edited 03-03-2019 11:18 AM
Please
How can i configure ospf between 2 routers via routers doesn't run ospf ?
Best regards.
Solved! Go to Solution.
12-28-2005 12:59 PM
The problem that you are experiencing is recursive routing. It is a fairly common problem with GRE tunnels. The problem occurs when the tunnel end point gets advertised in the routing protocol over the tunnel.
Before you added redistribute connected your tunnels worked because they got to the tunnel end point (tunnel destination) using the default route that was configured. When you added redistribute connected then the tunnel end point address was advertised in OSPF over the tunnel. Now the router is trying to get to the end point of the tunnel by going through the tunnel instead of by going through a physical interface. Either remove the redistribute connected or use a filter on the redistribute connected so that the tunnel end point is not advertised through the tunnel.
HTH
Rick
12-27-2005 07:35 AM
Hi
As u have mentioned in the heading itself u can make use of GRE tunnels established between the remote end router to have routing info exchanged with it.
http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a00800a43f6.shtml
would suggest to check this link if u havent seen it already which disucsses the same kinda scenario but with PIX in between the routers..
regds
12-27-2005 09:23 AM
I try this example not with but with an intermediate router.It does'nt work,the both router can't be neighbor.
There is debug tunnel result from first host :
08:17:46: Tunnel0: GRE/IP encapsulated 10.0.0.254->195.24.215.13 (linktype=7, le
n=88)
There is debug tunnel result from second host :
soccabail#
5w6d: Tunnel0: GRE/IP encapsulated 10.1.1.1->192.168.100.3 (linktype=7, len=88)
5w6d: Tunnel0: GRE/IP encapsulated 10.1.1.1->192.168.100.3 (linktype=7, len=88)
5w6d: Tunnel0: GRE/IP encapsulated 10.1.1.1->192.168.100.3 (linktype=7, len=88)
5w6d: Tunnel0: GRE/IP encapsulated 10.1.1.1->192.168.100.3 (linktype=7, len=88)
There is show ip ospf result from both router
Router#show ip ospf neighbor
Router#
Any suggestion will be appreciated
Best regards.
12-27-2005 02:09 PM
Have you included a network statement covering the ip address of the tunnel interface?
If so, you should try a "deb ip ospf adj" to find out why the adjacency doesn't come up.
Hope this helps,
12-28-2005 02:14 AM
i try "debug ip ospf adj"
OSPF adjacency events debugging is on
Router#
I have no generation of log message.
there is configuration:
RTA
interface Loopback0
ip address 2.2.2.1 255.255.255.0
!
interface Loopback1
ip address 11.11.11.1 255.255.255.0
!
interface Tunnel0
ip address 172.16.1.1 255.255.255.0
tunnel source FastEthernet0/0
tunnel destination 195.24.215.13
!
interface FastEthernet0/0
ip address 192.168.100.3 255.255.255.0
ip nat outside
duplex auto
speed auto
!
interface Serial0/0
no ip address
shutdown
no fair-queue
!
interface FastEthernet0/1
ip address 10.0.0.254 255.255.255.0
ip nat inside
duplex auto
speed auto
pppoe enable
!
interface Virtual-Template1
ip unnumbered FastEthernet0/1
ip mtu 1492
ip nat inside
peer default ip address pool surf
ppp authentication chap
!
router ospf 1
log-adjacency-changes
network 2.2.2.0 0.0.0.255 area 0
network 172.16.1.0 0.0.0.255 area 0
!
ip local pool surf 10.0.0.1 10.0.0.251
ip nat inside source list 100 interface FastEthernet0/0 overload
ip classless
ip route 0.0.0.0 0.0.0.0 192.168.100.4
ip route 9.9.9.0 255.255.255.0 Tunnel0
no ip http server
!
access-list 100 permit ip 10.0.0.0 0.0.0.255 any
RTB
interface Loopback0
ip address 3.3.3.1 255.255.255.0
!
interface Loopback1
ip address 9.9.9.1 255.255.255.0
!
interface Tunnel0
ip address 172.16.1.2 255.255.255.0
tunnel source FastEthernet0/1
tunnel destination 192.168.100.3
!
interface FastEthernet0/0
description LAN
ip address 195.24.215.13 255.255.255.192
ip nat outside
ip route-cache flow
speed auto
full-duplex
!
interface Serial0/0
no ip address
shutdown
!
interface FastEthernet0/1
ip address 126.27.1.135 255.255.255.0 secondary
ip address 10.1.1.1 255.255.255.0
ip nat inside
speed auto
full-duplex
!
router ospf 1
log-adjacency-changes
network 3.3.3.0 0.0.0.255 area 0
network 172.16.1.0 0.0.0.255 area 0
!
ip nat pool natpool 195.24.215.13 195.24.215.13 netmask 255.25
ip nat inside source list 1 pool natpool overload
ip flow-export source FastEthernet0/0
ip flow-export version 5
ip flow-export destination 192.168.100.13 2055
ip classless
ip route 0.0.0.0 0.0.0.0 195.24.215.1
ip route 11.11.11.0 255.255.255.0 Tunnel0
ip route 195.24.215.28 255.255.255.255 10.1.1.3
no ip http server
!
access-list 1 permit 126.27.1.0 0.0.0.255
access-list 1 permit 10.1.1.0 0.0.0.255
access-list 101 deny udp any any eq 24749
access-list 101 permit ip any any
The router RTA with 192.168.100.3 can pin RTB which has 195.24.215.13
Best regards
12-28-2005 02:42 AM
Hi
Can u confirm the mtu size being used on both the sides under the tunnel interface ?
can u manually make them the same on both the ends if they are of different value ?
regds
12-28-2005 03:30 AM
There is mtu size below:
RTB
soccabail#show int tu 0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Internet address is 172.16.1.2/24
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive set (10 sec)
Tunnel source 10.1.1.1 (FastEthernet0/1), destination 192.168.100.3
Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled
Tunnel TTL 255
Checksumming of packets disabled, fast tunneling enabled
Last input 01:21:50, output 00:00:03, output hang never
Last clearing of "show interface" counters never
Queueing strategy: fifo
Output queue 0/0, 0 drops; input queue 0/75, 0 drops
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
0 packets input, 0 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
554 packets output, 48752 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
soccabail#
RTA
Router#show int tunnel 0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Internet address is 172.16.1.1/24
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive set (10 sec)
Tunnel source 192.168.100.3 (FastEthernet0/0), destination 195.24.215.13
Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled
Checksumming of packets disabled, fast tunneling enabled
Last input never, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Queueing strategy: fifo
Output queue 0/0, 0 drops; input queue 0/75, 0 drops
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
0 packets input, 0 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
571 packets output, 87872 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
Best regards
12-28-2005 03:37 AM
Hi
can you change the tunnel source ip to 195.24.215.13 in ur RTB (occabail) ??
At present ur trying to use the inside ip whichs 10.1.1.1(fa0/1)
regds
12-28-2005 07:03 AM
Thank, it is good at now.The both can see its neighbor.I add ospf redistribute connect, the interface tunnel 0 for RTA is flaping down to up and up to down.I don't know why.
Router#
06:27:37: %TUN-5-RECURDOWN: Tunnel0 temporarily disabled due to recursive routin
g
06:27:38: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state
to down
06:27:38: OSPF: Interface Tunnel0 going Down
06:27:38: OSPF: 192.168.100.3 address 172.16.1.1 on Tunnel0 is dead, state DOWN
06:27:38: OSPF: 10.10.10.1 address 172.16.1.2 on Tunnel0 is dead, state DOWN
06:27:38: %OSPF-5-ADJCHG: Process 1, Nbr 10.10.10.1 on Tunnel0 from FULL to DOWN
, Neighbor Down: Interface down or detached
06:27:38: OSPF: Build router LSA for area 0, router ID 192.168.100.3, seq 0x8000
002C
06:28:38: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state
to up
06:28:38: OSPF: Interface Tunnel0 going Up
06:28:38: OSPF: Build router LSA for area 0, router ID 192.168.100.3, seq 0x8000
002D
06:28:40: OSPF: 2 Way Communication to 10.10.10.1 on Tunnel0, state 2WAY
06:28:40: OSPF: Send DBD to 10.10.10.1 on Tunnel0 seq 0x2395 opt 0x42 flag 0x7 l
en 32
06:28:40: OSPF: Rcv DBD from 10.10.10.1 on Tunnel0 seq 0x1380 opt 0x42 flag 0x7
len 32 mtu 1476 state EXSTART
06:28:40: OSPF: First DBD and we are not SLAVE
06:28:40: OSPF: Rcv DBD from 10.10.10.1 on Tunnel0 seq 0x2395 opt 0x42 flag 0x2
len 152 mtu 1476 state EXSTART
06:28:40: OSPF: NBR Negotiation Done. We are the MASTER
06:28:40: OSPF: Send DBD to 10.10.10.1 on Tunnel0 seq 0x2396 opt 0x42 flag 0x3 l
en 152
06:28:40: OSPF: Database request to 10.10.10.1
06:28:40: OSPF: sent LS REQ packet to 172.16.1.2, length 12
06:28:40: OSPF: Rcv DBD from 10.10.10.1 on Tunnel0 seq 0x2396 opt 0x42 flag 0x0
len 32 mtu 1476 state EXCHANGE
06:28:40: OSPF: Send DBD to 10.10.10.1 on Tunnel0 seq 0x2397 opt 0x42 flag 0x1 l
en 32
06:28:40: OSPF: Rcv DBD from 10.10.10.1 on Tunnel0 seq 0x2397 opt 0x42 flag 0x0
len 32 mtu 1476 state EXCHANGE
06:28:40: OSPF: Exchange Done with 10.10.10.1 on Tunnel0
06:28:40: OSPF: Synchronized with 10.10.10.1 on Tunnel0, state FULL
06:28:40: %OSPF-5-ADJCHG: Process 1, Nbr 10.10.10.1 on Tunnel0 from LOADING to F
ULL, Loading Done
06:28:44: OSPF: Build router LSA for area 0, router ID 192.168.100.3, seq 0x8000
002E
Best regards.
12-28-2005 12:59 PM
The problem that you are experiencing is recursive routing. It is a fairly common problem with GRE tunnels. The problem occurs when the tunnel end point gets advertised in the routing protocol over the tunnel.
Before you added redistribute connected your tunnels worked because they got to the tunnel end point (tunnel destination) using the default route that was configured. When you added redistribute connected then the tunnel end point address was advertised in OSPF over the tunnel. Now the router is trying to get to the end point of the tunnel by going through the tunnel instead of by going through a physical interface. Either remove the redistribute connected or use a filter on the redistribute connected so that the tunnel end point is not advertised through the tunnel.
HTH
Rick
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide