OSPF question

happy420goluckyhappy420golucky Member Posts: 78 ■■□□□□□□□□
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. :)
Every passing minute is a chance to turn it all around.

Comments

  • dtlokeedtlokee Member Posts: 2,378 ■■■■□□□□□□
    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.
    The only easy day was yesterday!
  • happy420goluckyhappy420golucky Member Posts: 78 ■■□□□□□□□□
    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.
    Every passing minute is a chance to turn it all around.
  • happy420goluckyhappy420golucky Member Posts: 78 ■■□□□□□□□□
    Why so long for a reply back peoples? Iz everybody really busy?
    Every passing minute is a chance to turn it all around.
  • dtlokeedtlokee Member Posts: 2,378 ■■■■□□□□□□
    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
    
    The only easy day was yesterday!
  • happy420goluckyhappy420golucky Member Posts: 78 ■■□□□□□□□□
    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?
    Every passing minute is a chance to turn it all around.
  • networker050184networker050184 Mod Posts: 11,962 Mod
    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.
    An expert is a man who has made all the mistakes which can be made.
  • happy420goluckyhappy420golucky Member Posts: 78 ■■□□□□□□□□
    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.
    Every passing minute is a chance to turn it all around.
  • networker050184networker050184 Mod Posts: 11,962 Mod
    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.
    An expert is a man who has made all the mistakes which can be made.
  • rossonieri#1rossonieri#1 Member Posts: 799 ■■■□□□□□□□
    hi,

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

    cheers :)
    the More I know, that is more and More I dont know.
  • dtlokeedtlokee Member Posts: 2,378 ■■■■□□□□□□
    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).
    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.
    The only easy day was yesterday!
  • happy420goluckyhappy420golucky Member Posts: 78 ■■□□□□□□□□
    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).
    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
    Every passing minute is a chance to turn it all around.
  • rossonieri#1rossonieri#1 Member Posts: 799 ■■■□□□□□□□
    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 icon_cool.gif

    cheers...
    the More I know, that is more and More I dont know.
  • happy420goluckyhappy420golucky Member Posts: 78 ■■□□□□□□□□
    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 icon_cool.gif

    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.
    Every passing minute is a chance to turn it all around.
  • NetstudentNetstudent Member Posts: 1,693 ■■■□□□□□□□
    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 icon_cool.gif

    cheers...

    They usually are!
    There is no place like 127.0.0.1 BUT 209.62.5.3 is my 127.0.0.1 away from 127.0.0.1!
  • ITdudeITdude Member Posts: 1,181 ■■■□□□□□□□
    I'll drink to that! :)icon_wink.gif
    I usually hang out on 224.0.0.10 (FF02::A) and 224.0.0.5 (FF02::5) when I'm in a non-proprietary mood.

    __________________________________________
    Simplicity is the ultimate sophistication.
    (Leonardo da Vinci)
  • whoflungdung88whoflungdung88 Member Posts: 15 ■□□□□□□□□□
    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. icon_wink.gif
    uummmmm yeah
  • dtlokeedtlokee Member Posts: 2,378 ■■■■□□□□□□
    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. icon_wink.gif

    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 icon_eek.gif

    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.
    The only easy day was yesterday!
  • whoflungdung88whoflungdung88 Member Posts: 15 ■□□□□□□□□□
    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! icon_wink.gif
    uummmmm yeah
  • dtlokeedtlokee Member Posts: 2,378 ■■■■□□□□□□
    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 icon_wink.gif
    The only easy day was yesterday!
Sign In or Register to comment.