OSPF question

happy420golucky

Okay, I don't want to sound dumb. But I am going to go ahead and ask this. Since maybe I am forgetting something or whatnot.
In order for two routers that are connecting to one another via a GRE tunnel, do the IP's of each sides tunnel, have to be within the same network to become ospf neighbors? Keep in mind that they are both going to be in area 0 and and both sources and destinations for each tunnel have static routes to each other.
The way I have been configuring ospf on my tunnels, is apply a loopback address that's in the same ospf subnet as per my area 0 router. But today, somebody was telling me that both tunnels don't have to be in the same subnet, just as long as they are in the same area. They will be ospf neighbors. Please any input would be appreciated.

dtlokee

The IP addresses of the tunnel interfaces will be exchanged as part of the hello packets. If the subnet addresses are not the same they will not form an adjacency between them. The addresses of the interfaces you use as the tunnel source do not need to be on the same subnet, but the tunnel interfaces do.

happy420golucky

dtlokee wrote:

The IP addresses of the tunnel interfaces will be exchanged as part of the hello packets. If the subnet addresses are not the same they will not form an adjacency between them. The addresses of the interfaces you use as the tunnel source do not need to be on the same subnet, but the tunnel interfaces do.

Ok, I am here at my shop just totally lost. here is what I have so far.


*****ROUTER A*****
interface Loopback0
no ip address
!
interface Loopback1
ip address 10.250.251.2 255.255.255.255
!
interface Tunnel105
bandwidth 11000
ip unnumbered FastEthernet0/0
ip mtu 1360
ip ospf hello-interval 30
tunnel source FastEthernet0/1
tunnel destination 22.6.9.37
!
interface FastEthernet0/0
description Server Segment
ip address 10.31.1.1 255.255.255.0
ip helper-address 10.31.3.0
no ip mroute-cache
duplex auto
speed auto
!
!
router ospf 1
log-adjacency-changes
redistribute static subnets route-map STATIC-TO-OSPF
passive-interface FastEthernet0/0
network 10.31.1.0 0.0.0.255 area 0
network 10.250.251.2 0.0.0.0 area 0
!
ip classless
ip route 0.0.0.0 0.0.0.0 22.6.9.6

no ip http server
ip ospf name-lookup
!
ip access-list standard STATIC-TO-OSPF
permit 10.16.67.192 0.0.0.7
deny any
!
logging 10.31.1.7
route-map STATIC-TO-OSPF permit 10
match ip address STATIC-TO-OSPF
!
*****ROUTER B*****
!
interface Tunnel5
bandwidth 11000
ip unnumbered FastEthernet0/0
ip mtu 1360
ip ospf hello-interval 30
tunnel source FastEthernet1/1
tunnel destination 22.6.9.5
!
!
interface FastEthernet0/0
ip address 22.6.21.1 255.255.255.0 secondary
ip address 10.31.3.1 255.255.255.0
ip ospf priority 10
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 22.6.9.37 255.255.255.252
duplex auto
speed auto
!
router ospf 1
log-adjacency-changes
area 9 authentication message-digest
redistribute connected subnets
passive-interface FastEthernet2/1
network 10.31.3.0 0.0.0.255 area 0
!


Both routers have static routes pointed to each others tunnel source. sorry forgot to paste that.

******************************

Ok, As I type I am now looking at two routers passing traffic to one another with different Tunnel IP's, but in the same area (area 0 backbone).
Like I said, I am in the mode of thinking that in order for both of them to talk, they have to be on the same subnet. . Another person was telling me that, since the gre tunnel is a point to point interface. The router will receive the hello packet, realize that "hey your not in my lsdb" and reply back since they are in the same area.
Then this leads me to another question. I have two routers that are connected to the same switch. And both interfaces connected to that switch are in the same area but have different address’s, and obviously will not talk/form adjacencies. What gives? I mean I know that the fastethernet interface is not a point to point. But whenever the routers are configured in the same network, with whatever routing protocol. They are seen as directly connected.
Yeah a little confused right now.

happy420golucky

Why so long for a reply back peoples? Iz everybody really busy?

dtlokee

Try labbing it up yourself to see what happens, the output of debug ip ospf events makes it pretty obvious what's wrong

=========== R1 ==========

interface FastEthernet0/0
 ip address 192.168.1.1 255.255.255.0
!
router ospf 1
 log-adjacency-changes
 network 192.168.1.1 0.0.0.0 area 0

=========== R2 ==========

interface FastEthernet0/0
 ip address 192.168.2.1 255.255.255.0
!
router ospf 1
 log-adjacency-changes
 network 192.168.2.1 0.0.0.0 area 0




R1#debug ip ospf events
OSPF events debugging is on
R1#
*Mar 11 00:52:14.891: OSPF: Rcv pkt from 192.168.2.1, FastEthernet0/0, area 0.0.0.0 : src not on the same network
R1#
*Mar 11 00:52:18.699: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 192.168.1.1
R1#
*Mar 11 00:52:24.891: OSPF: Rcv pkt from 192.168.2.1, FastEthernet0/0, area 0.0.0.0 : src not on the same network
R1#q
*Mar 11 00:52:28.699: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 192.168.1.1
R1#und all
All possible debugging has been turned off

happy420golucky

dtlokee wrote:

Try labbing it up yourself to see what happens, the output of debug ip ospf events makes it pretty obvious what's wrong

=========== R1 ==========

interface FastEthernet0/0
 ip address 192.168.1.1 255.255.255.0
!
router ospf 1
 log-adjacency-changes
 network 192.168.1.1 0.0.0.0 area 0

=========== R2 ==========

interface FastEthernet0/0
 ip address 192.168.2.1 255.255.255.0
!
router ospf 1
 log-adjacency-changes
 network 192.168.2.1 0.0.0.0 area 0




R1#debug ip ospf events
OSPF events debugging is on
R1#
*Mar 11 00:52:14.891: OSPF: Rcv pkt from 192.168.2.1, FastEthernet0/0, area 0.0.0.0 : src not on the same network
R1#
*Mar 11 00:52:18.699: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 192.168.1.1
R1#
*Mar 11 00:52:24.891: OSPF: Rcv pkt from 192.168.2.1, FastEthernet0/0, area 0.0.0.0 : src not on the same network
R1#q
*Mar 11 00:52:28.699: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 192.168.1.1
R1#und all
All possible debugging has been turned off

Yeah, I see your debug output. But, I configured two gre tunnels to talk via ospf. Their ip's are( ip unnumbered fa0/0 ) and those interfaces have area 0 ospf statements. Both of the tunnels on each side are using the fastethernet 0/1 interfaces as their tunnel sources. I was in a discussion with another person. He was going into explanation saying that the key to why ospf is working between the two routers is because I am using gre tunnels. I really don't fully understand why. I mean, i indeed set up my own lab with two routers connected to a switch and it obviously doesnt work and is exactly like your output code as posted above. I just simply don't fully understand why thes two routers work with the gre tunnels configured. What you think am I missing dude?

networker050184

The tunnel addresses need to be in the same subnet in order to form neighbor relationship. You have 10.31.1.1 and 10.31.3.1 both with 255.255.255.0 subnet mask. If you change the the tunnel addresses to 10.31.1.1 and 10.31.1.2 with subnet mask 255.255.255.0 they should form neighbor relationship considering everything else is configured right.

happy420golucky

networker050184 wrote:

The tunnel addresses need to be in the same subnet in order to form neighbor relationship. You have 10.31.1.1 and 10.31.3.1 both with 255.255.255.0 subnet mask. If you change the the tunnel addresses to 10.31.1.1 and 10.31.1.2 with subnet mask 255.255.255.0 they should form neighbor relationship considering everything else is configured right.

Well I disagree. I have the tunnels working with ospf full adjacencies in the configuration that I have posted above. I guess nobody has an answer why on here.

networker050184

I don't have an answer sorry. The only reason I can think of is because of the ip unumbered command. I use ipunumered with loopback addresses for my point to point serial links, and these are not in the same subnet, but do form adjacencies. The gre tunnels I use are all in the same subnet with ip addresses on the tunnel its self and not using the ip unumbered command.

rossonieri#1

hi,

well -- let us see the debug, so we can analyze where the adj build from.
i'm interested.

cheers

dtlokee

The encapsulation has nothing to do with it, the fact that it is a point to point link has nothing to do with it, it's all about the "ip unnumbered" command. When the ip unnumbered command is used the hello packets are sourced from 0.0.0.0 and sent to 224.0.0.5 (since both sides think they're using 0.0.0.0 as the source, there's no conflict regarding the subnet address)

If you use an IP addresses with mismatched subnets on the tunnel interfaces it will work just as the debugs I already posted(or more correctly, it won't work).

happy420golucky wrote:

networker050184 wrote:
The tunnel addresses need to be in the same subnet in order to form neighbor relationship. You have 10.31.1.1 and 10.31.3.1 both with 255.255.255.0 subnet mask. If you change the the tunnel addresses to 10.31.1.1 and 10.31.1.2 with subnet mask 255.255.255.0 they should form neighbor relationship considering everything else is configured right.


Well I disagree. I have the tunnels working with ospf full adjacencies in the configuration that I have posted above. I guess nobody has an answer why on here.

There's your answer. Before you continue to disagree with everyone, lab it up and try it, the answer will be right there. The tunnels work because you're using unnumbered, and therefore use a source of 0.0.0.0, no magic, not tricks.

happy420golucky

dtlokee wrote:

The encapsulation has nothing to do with it, the fact that it is a point to point link has nothing to do with it, it's all about the "ip unnumbered" command. When the ip unnumbered command is used the hello packets are sourced from 0.0.0.0 and sent to 224.0.0.5 (since both sides think they're using 0.0.0.0 as the source, there's no conflict regarding the subnet address)

If you use an IP addresses with mismatched subnets on the tunnel interfaces it will work just as the debugs I already posted(or more correctly, it won't work).

happy420golucky wrote:

networker050184 wrote:
The tunnel addresses need to be in the same subnet in order to form neighbor relationship. You have 10.31.1.1 and 10.31.3.1 both with 255.255.255.0 subnet mask. If you change the the tunnel addresses to 10.31.1.1 and 10.31.1.2 with subnet mask 255.255.255.0 they should form neighbor relationship considering everything else is configured right.


Well I disagree. I have the tunnels working with ospf full adjacencies in the configuration that I have posted above. I guess nobody has an answer why on here.

There's your answer. Before you continue to disagree with everyone, lab it up and try it, the answer will be right there. The tunnels work because you're using unnumbered, and therefore use a source of 0.0.0.0, no magic, not tricks.

I was basically disagreeing because one was saying the configuration that I was posting shouldn't work. When in fact it does,but simply didn't fully understand why. Since I have been in networking, I have always stuck with keeping your interfaces or loopbacks in the same subnet you are connecting your other router too. And thus leading me to ask someone on here that might have experience in the situation I was in. Thanks

rossonieri#1

rossonieri#1 wrote:

hi,

well -- let us see the debug, so we can analyze where the adj build from.
i'm interested.

cheers

actually that was for happy420golucky - did you do your homelab?

dtlokee wrote:

The encapsulation has nothing to do with it, the fact that it is a point to point link has nothing to do with it, it's all about the "ip unnumbered" command. When the ip unnumbered command is used the hello packets are sourced from 0.0.0.0 and sent to 224.0.0.5 (since both sides think they're using 0.0.0.0 as the source, there's no conflict regarding the subnet address)

dtlokee - that was a CLASS A high grade answer

cheers...

happy420golucky

rossonieri#1 wrote:

rossonieri#1 wrote:

hi,

well -- let us see the debug, so we can analyze where the adj build from.
i'm interested.

cheers

actually that was for happy420golucky - did you do your homelab?

dtlokee wrote:

The encapsulation has nothing to do with it, the fact that it is a point to point link has nothing to do with it, it's all about the "ip unnumbered" command. When the ip unnumbered command is used the hello packets are sourced from 0.0.0.0 and sent to 224.0.0.5 (since both sides think they're using 0.0.0.0 as the source, there's no conflict regarding the subnet address)

dtlokee - that was a CLASS A high grade answer

cheers...

Yeah, I finally had a chance to bring my home lab back up and test it out. The debug output is as dtlokee had written, and finally makes sense to me now. And to put it simply, I am sure I will never forget it. Being how I ran into this situation on a live network and was totally puzzled. I give him thanks for his reply too.

Netstudent

rossonieri#1 wrote:

rossonieri#1 wrote:

hi,

well -- let us see the debug, so we can analyze where the adj build from.
i'm interested.

cheers

actually that was for happy420golucky - did you do your homelab?

dtlokee wrote:

The encapsulation has nothing to do with it, the fact that it is a point to point link has nothing to do with it, it's all about the "ip unnumbered" command. When the ip unnumbered command is used the hello packets are sourced from 0.0.0.0 and sent to 224.0.0.5 (since both sides think they're using 0.0.0.0 as the source, there's no conflict regarding the subnet address)

dtlokee - that was a CLASS A high grade answer

cheers...

They usually are!

ITdude

I'll drink to that!

whoflungdung88

dtlokee wrote:

The IP addresses of the tunnel interfaces will be exchanged as part of the hello packets. If the subnet addresses are not the same they will not form an adjacency between them. The addresses of the interfaces you use as the tunnel source do not need to be on the same subnet, but the tunnel interfaces do.

Yeah, I give him a B for his answer. Since originally he either didn't read happy420golucky's question right, or didn't really know the answer himself and tried to give an answer that he thought was right off the top of his head.

dtlokee

whoflungdung88 wrote:

dtlokee wrote:

The IP addresses of the tunnel interfaces will be exchanged as part of the hello packets. If the subnet addresses are not the same they will not form an adjacency between them. The addresses of the interfaces you use as the tunnel source do not need to be on the same subnet, but the tunnel interfaces do.

Yeah, I give him a B for his answer. Since originally he either didn't read happy420golucky's question right, or didn't really know the answer himself and tried to give an answer that he thought was right off the top of his head.

heh, go back and re-read the first post, it said nothing about using unnumbered interfaces that's why I answered the way I did

He seemed to think that it was related to using GRE that caused it to work, my point was that GRE had no effect on the operation and that the IP addresses on both ends still needed to be in the same subnet if assigned an IP address to the interface.

whoflungdung88

happy420golucky wrote:

dtlokee wrote:

The IP addresses of the tunnel interfaces will be exchanged as part of the hello packets. If the subnet addresses are not the same they will not form an adjacency between them. The addresses of the interfaces you use as the tunnel source do not need to be on the same subnet, but the tunnel interfaces do.

Ok, I am here at my shop just totally lost. here is what I have so far.


*****ROUTER A*****
interface Loopback0
no ip address
!
interface Loopback1
ip address 10.250.251.2 255.255.255.255
!
interface Tunnel105
bandwidth 11000
ip unnumbered FastEthernet0/0
ip mtu 1360
ip ospf hello-interval 30
tunnel source FastEthernet0/1
tunnel destination 22.6.9.37
!
interface FastEthernet0/0
description Server Segment
ip address 10.31.1.1 255.255.255.0
ip helper-address 10.31.3.0
no ip mroute-cache
duplex auto
speed auto
!
!
router ospf 1
log-adjacency-changes
redistribute static subnets route-map STATIC-TO-OSPF
passive-interface FastEthernet0/0
network 10.31.1.0 0.0.0.255 area 0
network 10.250.251.2 0.0.0.0 area 0
!
ip classless
ip route 0.0.0.0 0.0.0.0 22.6.9.6

no ip http server
ip ospf name-lookup
!
ip access-list standard STATIC-TO-OSPF
permit 10.16.67.192 0.0.0.7
deny any
!
logging 10.31.1.7
route-map STATIC-TO-OSPF permit 10
match ip address STATIC-TO-OSPF
!
*****ROUTER B*****
!
interface Tunnel5
bandwidth 11000
ip unnumbered FastEthernet0/0
ip mtu 1360
ip ospf hello-interval 30
tunnel source FastEthernet1/1
tunnel destination 22.6.9.5
!
!
interface FastEthernet0/0
ip address 22.6.21.1 255.255.255.0 secondary
ip address 10.31.3.1 255.255.255.0
ip ospf priority 10
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 22.6.9.37 255.255.255.252
duplex auto
speed auto
!
router ospf 1
log-adjacency-changes
area 9 authentication message-digest
redistribute connected subnets
passive-interface FastEthernet2/1
network 10.31.3.0 0.0.0.255 area 0
!


Both routers have static routes pointed to each others tunnel source. sorry forgot to paste that.

******************************

Ok, As I type I am now looking at two routers passing traffic to one another with different Tunnel IP's, but in the same area (area 0 backbone).
Like I said, I am in the mode of thinking that in order for both of them to talk, they have to be on the same subnet. . Another person was telling me that, since the gre tunnel is a point to point interface. The router will receive the hello packet, realize that "hey your not in my lsdb" and reply back since they are in the same area.
Then this leads me to another question. I have two routers that are connected to the same switch. And both interfaces connected to that switch are in the same area but have different address’s, and obviously will not talk/form adjacencies. What gives? I mean I know that the fastethernet interface is not a point to point. But whenever the routers are configured in the same network, with whatever routing protocol. They are seen as directly connected.
Yeah a little confused right now.

dtlokee wrote:
Try labbing it up yourself to see what happens, the output of debug ip ospf events makes it pretty obvious what's wrong

Code:

=========== R1 ==========

interface FastEthernet0/0
ip address 192.168.1.1 255.255.255.0
!
router ospf 1
log-adjacency-changes
network 192.168.1.1 0.0.0.0 area 0

=========== R2 ==========

interface FastEthernet0/0
ip address 192.168.2.1 255.255.255.0
!
router ospf 1
log-adjacency-changes
network 192.168.2.1 0.0.0.0 area 0




R1#debug ip ospf events
OSPF events debugging is on
R1#
*Mar 11 00:52:14.891: OSPF: Rcv pkt from 192.168.2.1, FastEthernet0/0, area 0.0.0.0 : src not on the same network
R1#
*Mar 11 00:52:18.699: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 192.168.1.1
R1#
*Mar 11 00:52:24.891: OSPF: Rcv pkt from 192.168.2.1, FastEthernet0/0, area 0.0.0.0 : src not on the same network
R1#q
*Mar 11 00:52:28.699: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 192.168.1.1
R1#und all
All possible debugging has been turned off

Well, I guess your right .......since his configuration he posted had not in any way explained the use of ip unnumbered for the tunnels. Cheers!

dtlokee

Now you're quoting different posts to make your point, his first post (the one you first quoted when you gave me a "B") said nothing about unnumbered.

His next post seemed to indicate that he had a question about neighbors over a FastEthernet connection, then I posted the debugs.

Well it's good to see that you attempted to answer the man's questions. Oh wait, no you criticized the person that did.

Cheers