Host Route Being Generated by OSPF...WHY?

Unanswered Question
Feb 5th, 2010

Why is the hub router generating a host route for its mGRE interface?

Also, why is the LSA for that host route a "summary" route?

See below's database output.

GREoIPSec Spoke configuration and information - Take note of the 10.40.16.1 host route (/32) for the GRE Hub (nhs). The spoke is learning a host route from the hub for the Hub's mGRE interface.

Current configuration : 681 bytes
!
interface Tunnel1
description Point-to-Point VPN connection to TT-VPN01
bandwidth 10000
ip address 10.40.16.113 255.255.252.0
ip mtu 1420
ip nhrp authentication xxx
ip nhrp map multicast dynamic
ip nhrp map 10.40.16.1 138.69.152.3
ip nhrp map multicast 138.69.152.3
ip nhrp network-id 77
ip nhrp holdtime 300
ip nhrp nhs 10.40.16.1 <-----------------------------HUB TUNNEL INTERFACE
no ip route-cache cef
no ip route-cache
no ip mroute-cache
ip ospf message-digest-key 1 md5 7 xxx
ip ospf network point-to-multipoint
ip ospf priority 0
delay 1000
tunnel source FastEthernet0
tunnel destination 138.69.152.3
tunnel key 100001
tunnel protection ipsec profile DMVPN-RL
end

VPN01#
VPN01#
VPN01#sh ip ro 10.40.16.1
Routing entry for 10.40.16.1/32
  Known via "ospf 1", distance 110, metric 10, type intra area
  Last update from 10.40.16.1 on Tunnel1, 00:00:07 ago
  Routing Descriptor Blocks:
  * 10.40.16.1, from 138.69.96.2, 00:00:07 ago, via Tunnel1
      Route metric is 10, traffic share count is 1

VPN01#

VPN01#sh ip ro 10.40.16.0
Routing entry for 10.40.16.0/22
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Routing Descriptor Blocks:
  * directly connected, via Tunnel1
      Route metric is 0, traffic share count is 1

VPN01#

HUB Router's Config and information - I dont see the configuration commands that are causing the Hub to advertise a host route to the spoke for its tunnel interface. The odr subnets have nothing to do with it and neither does the route-map.You can see the ospf database LSA for that host route in the hub's database (see below).

interface Tunnel0
description THIS TUNNEL SUPPORTS MULTIPLE SITE-TO-SITE VPN TUNNELS
ip address 10.40.16.1 255.255.252.0
ip verify unicast source reachable-via any
no ip redirects
ip mtu 1420
ip nhrp authentication xxx
ip nhrp map multicast dynamic
ip nhrp network-id 77
ip nhrp holdtime 300
no ip route-cache cef
no ip route-cache
ip ospf message-digest-key 1 md5 7 xxx
ip ospf network point-to-multipoint
ip ospf cost 100
ip ospf priority 255
no ip mroute-cache
cdp enable
tunnel source Loopback100
tunnel mode gre multipoint
tunnel key 100001
tunnel protection ipsec profile DMVPN-RL
end

TT-VPN01#

router ospf 2005
router-id 138.69.96.2
ispf
log-adjacency-changes
area 0 authentication message-digest
area 1 authentication message-digest
area 1 nssa no-summary
redistribute static metric 1 metric-type 1 subnets route-map RL-static-routes
redistribute odr subnets
passive-interface default
no passive-interface Tunnel0
no passive-interface Tunnel1
network 10.40.1.0 0.0.0.3 area 1
network 10.40.16.0 0.0.3.255 area 1
network 10.40.32.0 0.0.0.255 area 1
network 138.69.96.2 0.0.0.0 area 0
distribute-list TunnelRoutes in

TT-VPN01#sh ip osp database summary 10.40.16.1

            OSPF Router with ID (138.69.152.3) (Process ID 2004)

            OSPF Router with ID (138.69.96.2) (Process ID 2005)

                Summary Net Link States (Area 0)

  LS age: 191
  Options: (No TOS-capability, DC, Upward)
  LS Type: Summary Links(Network)
  Link State ID: 10.40.16.1 (summary Network Number)
  Advertising Router: 138.69.96.2
  LS Seq Number: 8000C298
  Checksum: 0x3B32
  Length: 28
Network Mask: /32
        TOS: 0  Metric: 0

TT-VPN01#

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (6 ratings)
Loading.
Edison Ortiz Fri, 02/05/2010 - 19:44

"ip ospf network point-to-multipoint" generates a /32 by default.

In a multipoint design, all devices reside on the same subnet but do not have a direct connectivity, for instance a frame-relay environment where the hub and spokes share the same IP subnet but spokes aren't directly connected to each other, they connect via the hub.

The /32 allows you have this type of design.

lamav Fri, 02/05/2010 - 20:24

Hi, Edison:

I hear you on the challenges regarding NBMA networks and OSPF. The p2mp network type allows all the links to be treated as point-to-point links, no DR/BDR has to be elected, and each neighbor sends unicast updates to their neighbor.

But I dont see how the /32 mask on the hub's tunnel interface facilitates anything.

Moreover, the spoke has a backup tunnel to another hub as part of a separate DMVPN environment. That hub's tunnel interface is also configured as an OSPF p2mp network type, yet the spoke is not receiving a /32 host route from that hubs tunnel interface.

HUB

interface Tunnel0
description THIS TUNNEL SUPPORTS MULTIPLE SITE-TO-SITE VPN TUNNELS
ip address 10.40.20.1 255.255.252.0
ip verify unicast source reachable-via any
no ip redirects
ip mtu 1420
ip nhrp authentication xxx
ip nhrp map multicast dynamic
ip nhrp network-id 77
ip nhrp holdtime 300
no ip route-cache cef
no ip route-cache
ip ospf message-digest-key 1 md5 7 xxx
ip ospf network point-to-multipoint
ip ospf cost 10000
ip ospf priority 255
no ip mroute-cache
cdp enable
tunnel source Loopback100
tunnel mode gre multipoint
tunnel key 100002
tunnel protection ipsec profile DMVPN-RL


SPOKE

VPN01#sh ip ro 10.40.20.1
Routing entry for 10.40.20.0/22
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Routing Descriptor Blocks:
  * directly connected, via Tunnel2
      Route metric is 0, traffic share count is 1

VPN01#

VPN01#sh ip ospf data
VPN01#sh ip ospf database summ
VPN01#sh ip ospf database summary 10.40.20.1    <------------NO SUMMARY LSA with a /32 mask for the hub interface

            OSPF Router with ID (138.69.96.43) (Process ID 1)
VPN01#

Edison Ortiz Sat, 02/06/2010 - 10:32

But I dont see how the /32 mask on the hub's tunnel interface facilitates anything.

I'm not familiar with your design requirements to understand the configuration option for OSPF network point-to-multipoint.

If you've configured a mesh topology and every router must belong to the same subnet, you either need broadcast, non-broadcase or point-to-multipoint for the OSPF network type.

If you've chosen point-to-multipoint, it will generate a /32 automatically. There is no workaround as it is following the RFC.

You mentioned about the hub lacking this summary /32 in the database.

Well, I don't see the hub OSPF configuration, but the spoke has the GRE interface in another area (area 1) and the summary is seen on the OSPF database on (area 0).

This is a typical OSPF behavior where links assigned to a different area are seen as summaries in the backbone area.

Giuseppe Larosa Sat, 02/06/2010 - 12:26

Hello Victor,

on previuos posts you had this line inside OSPFprocess:

area 1 nssa no-summary

so as Edison has noted second DMVPN cloud is in area 1 that is a totally stub NSSA area.

This might explain the difference.

Hope to help

Giuseppe

lamav Sat, 02/06/2010 - 14:05

Edison/Giuseppe:

At first, I couldnt figure out why the spoke had a /32 route for the hub's tunnel interface. So I posted the question.

After Edison pointed out that the /32 is a result of the p2mp config under the tunnel interface on the HUB, I responded to Edison with another question, but I also researched it on my own. I found a pretty good website that has some examples and explanations.

I understand now that the generation of a /32 host route for the HUB's tunnel interface address is the default behavior of a router when the ospf network type is configured for p2mp.

However, I still cant really appreciate the value or the necessity of the /32 host route. I dont mean with regard to my network, per se, but in general. The p2mp config must act this way for a reason...

For example, lets create a scenario in which there is a hub router and two spokes.

If the ospf network type were configured for broadcast (ip ospf network broadcast) under the tunnel inteface of the HUB, the spokes will see a route to the other spoke's LAN with a next hop of the spoke's tunnel interface.

If, however, the ospf network type were configured for p2mp under the tunnel inteface of the HUB, the spokes will see a route to the other spoke's LAN, but this time with a next hop of the HUB's tunnel interface - the /32 host route.

So, what's the qualitative difference?? Whats the value of the /32 host route?

Moreover, it is confusing as hell with the p2mp setup. Take a look at this routing table.

SPOKE ROUTER IN MARYLAND (MD)

MDBALPARKHTS_RL01#sh ip ro 10.40.209.0 <---------Another spoke's local LAN
Routing entry for 10.40.209.0/29
  Known via "ospf 1", distance 110, metric 111, type intra area
  Last update from 10.40.16.1 on Tunnel1, 2d01h ago
  Routing Descriptor Blocks:
  * 10.40.16.1, from 138.69.96.43, 2d01h ago, via Tunnel1 <---------The HUB, 10.40.16.1, is the next hop to reach 10.40.209.0 from the MD router

MDBALPARKHTS_RL01#sh ip ro 10.40.16.1
Routing entry for 10.40.16.1/32 <-----------------------------------------------Our friend, the /32 host address of the HUB's tunnel interface
  Known via "ospf 1", distance 110, metric 10, type intra area
  Last update from 10.40.16.1 on Tunnel1, 2d01h ago
  Routing Descriptor Blocks:
  * 10.40.16.1, from 138.69.96.2, 2d01h ago, via Tunnel1 <------------------The route to 10.40.16.1/32 is through 10.40.16.1...!!!! HUH??

As for the SUMMARY LSA question, forget it. I was confusing myself.....It makes perfect sense.

Edison Ortiz Sat, 02/06/2010 - 17:00

Reference 'Routing TCP/IP Vol1' - Page 351

"On Broadcast and Point-to-Point network types, Hellos are multicast to AllSPFRouters (224.0.0.5).

On NBMA, Point-to-Multipoint, and virtual link network types, Hellos are unicast to individual neighbors.

The implication of unicasting is that the router must first learn of the existence of its neighbors either

through manual configuration or an underlying mechanism such as Inverse ARP."

P.S. Right about now, an old friend named Victor Lama was screaming for points.

lamav Sat, 02/06/2010 - 18:16

lol...Edison, my man!

Rated your previous posts, papi chulo...

Anyway, I did see that...I also saw this contradictory statement on page 450-451 from the same book:

"...OSPF packets are multicast to the neighbors." He's speaking of p2mp.

Seems like he is contradicting himself.

Giuseppe Larosa Sun, 02/07/2010 - 05:37

Hello Victor,

from my study notes:

point to multipoint treats the network as a collection of point to point links and multicast hellos discover neighbors dynamically (no neigh command is needed).

From RFC 2328:

12.4.1.4.  Describing Point-to-MultiPoint interfaces

                For operational Point-to-MultiPoint interfaces, one or
                more link descriptions are added to the router-LSA as
                follows:

                o   A single Type 3 link (stub network) is added with
                    Link ID set to the router's own IP interface
                    address, Link Data set to the mask 0xffffffff
                    (indicating a host route), and cost set to 0.
               
                    For each fully adjacent neighbor associated with the
                    interface, add an additional Type 1 link (point-to-
                    point) with Link ID set to the Router ID of the
                    neighboring router, Link Data set to the IP
                    interface address and cost equal to the interface's
                    configured output cost.






Comments:
being treated as a collection of point to point links the /32 host route
acts as an anchor for link state SPF.
Each point-to-point that is built with neighbors is described by a point-to-point
link descriptor and it is logically tied to the host route.
This is somewhat similar to what happens on a broadcast segment where DR creates the LSA type2
for the segment and lists connected routers.
So I see this /32 host route as an OSPF internal data structure that is useful to draw a correct
SPF for this kind of topology.

About the use in a DMVPN context: one of most important design decisions is to allow or
to not allow dynamic spoke to spoke channels.
So seeing the next-hop as the hub should inhibit the creation
of spoke to spoke dynamic tunnel.
if the next-hop is the other spoke the dynamic spoke to spoke tunnel is set up
when needed

Hope to help
Giuseppe
lamav Sun, 02/07/2010 - 19:19

Thank you, once again, my friend..slowly but surely, the fog is clearing :-)

I'll study your answer and have it all make sense to me....

Victor

lamav Tue, 02/09/2010 - 08:56

Edison....buddy.....

Giuseppe....amici.....

One more question...lol

OK, check it out...

Same scenario...

DMVPN with GREoIPSec....ospf m2mp...

OK, one of the spokes advertises a router LSA with 6 links, one of the links is its Tunnel interface -- and it advertises it with a /32 mask. OK...fine..

The HUB receives it...fine, again..

But why does the HUB's RIB entry for that Tunnel interface not reflect a /32 host route, but instead uses its directly connected route...?

The other spokes, on the other hand, DO use the /32..

see below

HUB:

VPN01#sh ip ospf database router 138.69.96.43

            OSPF Router with ID (138.69.152.3) (Process ID 2004)

            OSPF Router with ID (138.69.96.2) (Process ID 2005)

                Router Link States (Area 1)

  LS age: 1128
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 138.69.96.43  <--------------------------------Spoke router's Router-ID
  Advertising Router: 138.69.96.43
  LS Seq Number: 800003B6
  Checksum: 0xC6A5
  Length: 96
  Number of Links: 6

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 138.69.96.43
     (Link Data) Network Mask: 255.255.255.255
      Number of TOS metrics: 0
       TOS 0 Metrics: 1

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 10.40.209.0
     (Link Data) Network Mask: 255.255.255.248
      Number of TOS metrics: 0
       TOS 0 Metrics: 1

    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 138.69.96.3
     (Link Data) Router Interface address: 10.40.20.113
      Number of TOS metrics: 0
       TOS 0 Metrics: 100

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 10.40.20.113  <----------------- /32
     (Link Data) Network Mask: 255.255.255.255
      Number of TOS metrics: 0
       TOS 0 Metrics: 0

    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 138.69.96.2
     (Link Data) Router Interface address: 10.40.16.113
      Number of TOS metrics: 0
       TOS 0 Metrics: 10

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 10.40.16.113  <-------------- /32
     (Link Data) Network Mask: 255.255.255.255
      Number of TOS metrics: 0
       TOS 0 Metrics: 0


VPN01#sh ip ro 10.40.16.113
Routing entry for 10.40.16.0/22 <--------------------- /22
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Redistributing via ospf 2004
  Routing Descriptor Blocks:
  * directly connected, via Tunnel0
      Route metric is 0, traffic share count is 1


VPN01#sh ip ro 10.40.20.113
Routing entry for 10.40.0.0/16 <------------------------ /16
  Known via "ospf 2004", distance 110, metric 0, type intra area
  Routing Descriptor Blocks:
  * directly connected, via Null0
      Route metric is 0, traffic share count is 1

VPN01#


Thanks!

Edison Ortiz Tue, 02/09/2010 - 13:24

Link connected to: a Stub Network
     (Link ID) Network/subnet number: 10.40.20.113  <----------------- /32
     (Link Data) Network Mask: 255.255.255.255
      Number of TOS metrics: 0
       TOS 0 Metrics: 0

        Link connected to: a Stub Network
     (Link ID) Network/subnet number: 10.40.16.113  <-------------- /32
     (Link Data) Network Mask: 255.255.255.255
      Number of TOS metrics: 0
       TOS 0 Metrics: 0

TOS 0 Metrics: 0 is an indicator these routes are local to this router and they will not be seen as OSPF routes on the local router, they will be seen as 'connected'.

If you do a show ip os int brief or show ip int brief | ex una those interfaces will be listed on the router as local interfaces.

  Link connected to: a Stub Network
     (Link ID) Network/subnet number: 138.69.96.43
     (Link Data) Network Mask: 255.255.255.255
      Number of TOS metrics: 0
       TOS 0 Metrics: 1

This stub network for instance, was learned from a router that is 1 OSPF metric away.

Regards

Edison

lamav Wed, 02/10/2010 - 08:09

Edison:

Not to sound like a jerk, but Im not sure thats the answer.

Check it out...

Here is another spoke. It, too, sees the metric as 0, however, it sees the hub tunnel interface as the next hop. It does not see the hub, though, as a directly connected route.

VPN02#sh ip ospf data router 138.69.96.43

            OSPF Router with ID (138.69.96.44) (Process ID 1)

                Router Link States (Area 1)

  LS age: 1044
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 138.69.96.43
  Advertising Router: 138.69.96.43
  LS Seq Number: 800003E0
  Checksum: 0x72CF
  Length: 96
  Number of Links: 6

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 138.69.96.43
     (Link Data) Network Mask: 255.255.255.255
      Number of TOS metrics: 0
       TOS 0 Metrics: 1

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 10.40.209.0
     (Link Data) Network Mask: 255.255.255.248
      Number of TOS metrics: 0
       TOS 0 Metrics: 1

    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 138.69.96.3
     (Link Data) Router Interface address: 10.40.20.113
      Number of TOS metrics: 0
       TOS 0 Metrics: 100

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 10.40.20.113
     (Link Data) Network Mask: 255.255.255.255
      Number of TOS metrics: 0
       TOS 0 Metrics: 0

    Link connected to: another Router (point-to-point)
     (Link ID) Neighboring Router ID: 138.69.96.2
     (Link Data) Router Interface address: 10.40.16.113
      Number of TOS metrics: 0
       TOS 0 Metrics: 10

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 10.40.16.113

     (Link Data) Network Mask: 255.255.255.255
      Number of TOS metrics: 0
       TOS 0 Metrics: 0


COAURORA-RL-VPN02#sh ip ro 10.40.16.113
Routing entry for 10.40.16.113/32
  Known via "ospf 1", distance 110, metric 110, type intra area
  Last update from 10.40.16.1 on Tunnel1, 00:00:05 ago
  Routing Descriptor Blocks:
  * 10.40.16.1, from 138.69.96.43, 00:00:05 ago, via Tunnel1
      Route metric is 110, traffic share count is 1

VPN02#

lamav Wed, 02/10/2010 - 08:35

Edison/Giuseppe:

Just a thought...

I think the best way to look at OSPF p2mp networks is the following way:

The /32s are generated by each spoke in an OSPF p2mp topology so that it can be re-advertised by the HUB with the HUB itself as the next hop, because this is indeed not a broadcast network and the spokes may or may not have direct connectivity (pure hub and spoke or partial mesh) to each other.

Parenthetically, this is actually similar to the way iBGP behaves in an NBMA environment when you use the next-hop self command. The HUB, knowing that the spokes dont have direct connectivity to each other, advertises itself as the next hop to each spoke for inter-spoke communications.

On the other hand, as far as the HUBs RIB is concerned, the built-in intelligence of OSPF in a p2mp network realizes that the HUB does have connectivity to each spoke, so it just falls back to the typical behavior of directly connected routes, even though it does receive the /32 LSA from each spoke. In other words, it does not use the /32 for its own purposes, but only to advertise them to the spokes...

Or someting like that....

Does this make sense?

Edison Ortiz Wed, 02/10/2010 - 08:40

No, the /32 is created for the hello transmission between neighbors.

Hellos are sent via unicast not via multicast on a P2MP implementation.

P.S. I did a quick test to confirm the statement above and it does not seem to be the case.

On P2MP, it still uses multicast for the hello packets but if you change it to P2MP Non-broadcast and configure the neighbor under OSPF, it will use unicast. It seems Doyle's book needs some revision..

Router#sh run int f0/0
Building configuration...

Current configuration : 134 bytes
!
interface FastEthernet0/0
ip address 192.168.12.1 255.255.255.0
ip ospf network point-to-multipoint
duplex auto
speed auto
end

Router#sh run | sec router ospf
router ospf 1
log-adjacency-changes
network 192.168.12.1 0.0.0.0 area 0

*Feb 10 12:35:33.383: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 192.168.12.1

Router(config)#int f0/0
Router(config-if)#ip os ne point-to-multipoint non
Router(config-if)#router os 1
Router(config-router)#neighbor 192.168.12.2
Router(config-router)#do debug ip os hel
OSPF hello events debugging is on
Router(config-router)#end
Router#
*Feb 10 12:36:33.147: %SYS-5-CONFIG_I: Configured from console by console
Router#
*Feb 10 12:36:49.631: OSPF: Send hello to 192.168.12.2 area 0 on FastEthernet0/0 from 192.168.12.1

Edison Ortiz Wed, 02/10/2010 - 08:37

Victor,

As I stated on my previous post, those links are local to the router you are querying.

Per your commands:

VPN02#sh ip ospf data router 138.69.96.43

It's not the same router as the command being executed from:

OSPF Router with ID (138.69.96.44) (Process ID 1)

Find, what router is 138.69.96.43 and that's the one with the interface 10.40.16.113

Try typing

VPN02#sh ip ospf data router 138.69.96.44

lamav Wed, 02/10/2010 - 10:27

Edison:


Nice work on the proof of concept thing...appreciae it very much....I agree, Doyle needs ot be updated.


As for the outputs I sent you...


VPN01:


RID 138.69.96.43

Tunnel: 10.40.16.113


VPN01#sh ip int br | ex una
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0              67.102.58.58    YES NVRAM  up                    up
Loopback0                  138.69.96.43    YES NVRAM  up                    up
Tunnel1                    10.40.16.113    YES NVRAM  up                    up
Tunnel2                    10.40.20.113    YES NVRAM  up                    up
Vlan1                      10.40.209.6     YES NVRAM  up                    up
VPN01#



VPN02:


RID: 138.69.96.44

Tunnel: 10.40.16.112


VPN02#sh ip int br | ex una
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0              72.244.34.186   YES NVRAM  up                    up
Loopback0                  138.69.96.44    YES NVRAM  up                    up
Tunnel1                    10.40.16.112    YES NVRAM  up                    up
Tunnel2                    10.40.20.112    YES NVRAM  up                    up
Vlan1                      10.40.209.14    YES NVRAM  up                    up
VPN02#



So, the point I am making is that the spokes will have routes to other spokes' tunnel interfaces with the HUB as the next hop. Each spoke will leverage the /32 LSA generated by each spoke to create a routing table entry to that tunnel interface -- HOWEVER, the next hop will be the HUB router because of the OSPF p2mp configuration. In other words, the HUB will treat the p2mp as a collection of p2p links and readvertise the /32 LSA it rceives from each hub, BUT it will advertise itself as the next hop


VPN02#sh ip ro 10.40.16.113
Routing entry for 10.40.16.113/32
  Known via "ospf 1", distance 110, metric 110, type intra area
  Last update from 10.40.16.1 on Tunnel1, 00:00:15 ago
  Routing Descriptor Blocks:
* 10.40.16.1, from 138.69.96.43, 00:00:15 ago, via Tunnel1
Notice the source of the LSA in the spoke that owns 10.40.16.113, but the next hop is the HUB, 10 40 16.1
      Route metric is 110, traffic share count is 1


VPN02#


===========================================================


VPN01#sh ip ro 10.40.16.112
Routing entry for 10.40.16.112/32
  Known via "ospf 1", distance 110, metric 110, type intra area
  Last update from 10.40.16.1 on Tunnel1, 00:00:07 ago
  Routing Descriptor Blocks:
  * 10.40.16.1, from 138.69.96.44, 00:00:07 ago, via Tunnel1 
Notice the source of the LSA in the spoke that owns 10.40.16.112, but the next hop is the HUB, 10 40 16.1
      Route metric is 110, traffic share count is 1


===================================================================================


HUB:


HUB#sh ip ro 10.40.16.112
Routing entry for 10.40.16.0/22
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Redistributing via ospf 2004
  Routing Descriptor Blocks:
  * directly connected, via Tunnel0
      Route metric is 0, traffic share count is 1



HUB#sh ip ro 10.40.16.113
Routing entry for 10.40.16.0/22
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Redistributing via ospf 2004
  Routing Descriptor Blocks:
  * directly connected, via Tunnel0
      Route metric is 0, traffic share count is 1


HUB#


Notice how the HUB seees the route to the tunnel interfaces as directly connected and does not leverage the advertisement of the /32 LSA from each spoke to create a RIB entry. Instead, it falls back to the typical IP routing behavior in which routes to address that logically reside on the same network as one of its interfaces as directly connected.


Now, is my interpretation maing sense? Please go back to the post where I explained my thoughts on this...2 posts ago....


Thanks!!

Edison Ortiz Wed, 02/10/2010 - 12:27

So, the point I am making is that the spokes will have routes to other spokes' tunnel interfaces with the HUB as the next hop. Each spoke will leverage the /32 LSA generated by each spoke to create a routing table entry to that tunnel interface -- HOWEVER, the next hop will be the HUB router because of the OSPF p2mp configuration.

Agreed. That's how the reachability is formed on a same subnet scenario where there isn't a direct connectivity between spokes.

In other words, the spokes do not form an OSPF adjacency with each other so they need to reach the remote spoke via the HUB.

Notice how the HUB seees the route to the tunnel interfaces as directly connected and does not leverage the advertisement of the /32 LSA from each spoke to create a RIB entry. Instead, it falls back to the typical IP routing behavior in which routes to address that logically reside on the same network as one of its interfaces as directly connected.

That output has me wondering if this behavior is due to the DMVPN design you have as I can't replicate it on a FR environment (hub and spoke) with P2MP.

The hub should receive the /32s from the spokes. I don't know much DMVPN so I can't say what is causing this..

lamav Wed, 02/10/2010 - 19:09

Thanks, Edison.

I really appreciate all the time and attention you gave me on this one....hate to have bugged you.

Victor

Edison Ortiz Thu, 02/11/2010 - 06:27

Hi Victor,

Not at all, your questions were very challenging (as always) and it was a great learning experience

Actions

This Discussion