Re: Host Route Being Generated by OSPF...WHY? - Page 2

lamav · ‎02-05-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#

Edison Ortiz · ‎02-10-2010

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 · ‎02-10-2010

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 · ‎02-10-2010

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 · ‎02-10-2010

Thanks, Edison.

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

Victor

Edison Ortiz · ‎02-11-2010

Hi Victor,

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