ODR - On-Demand Routing & Dynamic Routing

Hi all,

I see this statement "For ODR to be functional, there should be no dynamic routing protocol configured on spokes."

Is this saying there should be no dynamic protocol over the link where ODR is running? What is meant by functional, as I have run dynamic routing and it all works ok.

 

I have the following setup,

{R6}-OSPF-{R1}--ODR--{R5}-OSPF-{R8}

R5 is the hub configured wiht "router odr",

R1 is the Spoke (there are other spojes to not shown).

OSPF is running at the other side of hte deivces & all work ok, pings are fine.

 

I then enabled OSPF over the R1--R5 link, so we have ODR and OSPF together from hub to spoke & its all working ok;

 

I know this is 1 task, prob not even in the lab, I just need to satify myself with an answer on this :)

 

Outputs

R1#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
150.1.5.5         0   FULL/  -        00:00:33    155.1.0.5       Tunnel0
150.1.5.5         1   FULL/DR         00:00:36    169.254.100.5   FastEthernet0/0.100
150.1.6.6         1   FULL/DR         00:00:39    155.1.146.6     FastEthernet0/0.146

 

R1#show ip route

Gateway of last resort is 155.1.0.5 to network 0.0.0.0

o*    0.0.0.0/0 [160/1] via 155.1.0.5, 00:13:58, Tunnel0
      150.1.0.0/32 is subnetted, 4 subnets
C        150.1.1.1 is directly connected, Loopback0
O        150.1.5.5 [110/2] via 169.254.100.5, 00:00:28, FastEthernet0/0.100
O        150.1.6.6 [110/2] via 155.1.146.6, 00:11:22, FastEthernet0/0.146
O        150.1.8.8 [110/3] via 169.254.100.5, 00:00:28, FastEthernet0/0.100
      155.1.0.0/16 is variably subnetted, 12 subnets, 2 masks
C        155.1.0.0/24 is directly connected, Tunnel0
L        155.1.0.1/32 is directly connected, Tunnel0
O        155.1.5.0/24 [110/2] via 169.254.100.5, 00:00:28, FastEthernet0/0.100
O        155.1.8.0/24 [110/3] via 169.254.100.5, 00:00:28, FastEthernet0/0.100
C        155.1.13.0/24 is directly connected, FastEthernet0/0.13
L        155.1.13.1/32 is directly connected, FastEthernet0/0.13
O        155.1.45.0/24
           [110/2] via 169.254.100.5, 00:00:29, FastEthernet0/0.100
O        155.1.58.0/24
           [110/2] via 169.254.100.5, 00:00:29, FastEthernet0/0.100
O        155.1.67.0/24 [110/2] via 155.1.146.6, 00:11:23, FastEthernet0/0.146
O        155.1.108.0/24
           [110/3] via 169.254.100.5, 00:00:29, FastEthernet0/0.100
C        155.1.146.0/24 is directly connected, FastEthernet0/0.146
L        155.1.146.1/32 is directly connected, FastEthernet0/0.146
      169.254.0.0/16 is variably subnetted, 2 subnets, 2 masks
C        169.254.100.0/24 is directly connected, FastEthernet0/0.100
L        169.254.100.1/32 is directly connected, FastEthernet0/0.100

 

Ping to other hub, routed via ODR

R1(config-router)#do ping 150.1.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 108/129/148 ms

 


R1(config-router)#do show ip cef 150.1.2.2 inter
0.0.0.0/0, epoch 0, RIB[O], refcount 5, per-destination sharing
  sources: RIB, DRH
  feature space:
   IPRM: 0x00058000
  ifnums:
   Tunnel0(9): 155.1.0.5
  path 687779C4, path list 686F25A8, share 1/1, type attached nexthop, for IPv4
  nexthop 155.1.0.5 Tunnel0, adjacency IP midchain out of Tunnel0, addr 155.1.0.5 67320840
  output chain: IP midchain out of Tunnel0, addr 155.1.0.5 67320840 IP adj out of FastEthernet0/0.100, addr 169.254.100.5 673206E0

Comments

  • Hi,

    Probably it refers to running ODR and not being "overlapped" by other IGPs, as it has a high AD (160) compared to the others.

  • Hiya Criprian,

    I see where your going, but I cant accept that as an answer. I say this as if I go with that logic then we can say the same for all the protocols.

    For OSPF/EIGRP/RIP to be functional, there should be no dynamic routing protocol configured on spokes.

    And we all know we can tune AD's to play ball with the scenarios, so I am again going to put it to the people to define the functional role.

    Dont get me rong, i appricate the input, I just need to satify my own mind :)

    Sam

     

    .....edit as my next post was not allowed (this post needs moderator blah....)

    Ok the ODR FAQ's shows this:

     

    Q.
    Can I enable ODR and a dynamic routing protocol on the spoke
    routers?


    A. No. When you enable any dynamic routing protocol in a spoke router, ODR
    does not work. When a spoke router sends its subnets to the hub through CDP, it
    checks to see if any routing protocol is enabled on the router. If it finds any
    dynamic routing protocol, it stops advertising its subnets.

     

    Whcih is odd, as I saw ODR and OSPF running together in my lab.

    I am going to re run my scenario and report back.

  • A quick google in the FAQ's for ODR shows this:

     

    Q.
    Can I enable ODR and a dynamic routing protocol on the spoke
    routers?


    A. No. When you enable any dynamic routing protocol in a spoke router, ODR
    does not work. When a spoke router sends its subnets to the hub through CDP, it
    checks to see if any routing protocol is enabled on the router. If it finds any
    dynamic routing protocol, it stops advertising its subnets.

     

    Which I find odd, as I did not see this as the case, ODR & OSPF ran side by side.....

     

    I am going to re-run this scenario. Please hold................

  • Ok, FAQ's & INE are right "For ODR to be functional, there should be no dynamic routing protocol configured on spokes."

    Here is why (I am using INES V5 topology):

     

     

    • First lets check we have cdp neihgborships to run ODR over the link:

    R5#show cdp neighbors
    Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
                      S - Switch, H - Host, I - IGMP, r - Repeater

    Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
    R3               Tunnel0            137           R       7206VXR   Tunnel0
    R1               Tunnel0            133           R       7206VXR   Tunnel0

     

    • After enabling ODR we can see it's learning routing information from it's neighbours,,

    R5#show ip protocols

    Routing Protocol is "odr"
      Sending updates every 60 seconds, next due in 24 seconds
      Invalid after 180 seconds, hold down 0, flushed after 240
      Outgoing update filter list for all interfaces is not set
      Incoming update filter list for all interfaces is not set
      Maximum path: 4
      Routing Information Sources:
        Gateway         Distance      Last Update
        155.1.0.3            160      00:00:05
        155.1.0.1            160      00:00:09

      Distance: (default is 160)

     

    • And we have thier connected routes advertised to us.

    R5#show ip route odr

          150.1.0.0/32 is subnetted, 3 subnets
    o        150.1.1.1 [160/1] via 155.1.0.1, 00:00:33, Tunnel0
    o        150.1.3.3 [160/1] via 155.1.0.3, 00:00:28, Tunnel0
          155.1.0.0/16 is variably subnetted, 11 subnets, 2 masks
    o        155.1.13.0/24 [160/1] via 155.1.0.3, 00:00:28, Tunnel0
                           [160/1] via 155.1.0.1, 00:00:33, Tunnel0
    o        155.1.37.0/24 [160/1] via 155.1.0.3, 00:00:28, Tunnel0
    o        155.1.146.0/24 [160/1] via 155.1.0.1, 00:00:33, Tunnel0

     

    • On the spokes we can see they have just a default route as expected, this is from the hub.

    R1#show ip rout odr

    Gateway of last resort is 155.1.0.5 to network 0.0.0.0

    o*    0.0.0.0/0 [160/1] via 155.1.0.5, 00:00:35, Tunnel0

    • Now I enable OSPF on all three devices,
    • *side note. The network type was set to Point-To-Multipoint as the tunnel defaults to Point-To-Point, which will not allow multiple neighbours on this interface type.)

    !!R1-R2-R5
    conf t
     router ospf 1
      network 0.0.0.0 0.0.0.0 area 0
      passive fas 0/0.100
      !
      int tun 0
      ip ospf network point-to-multipoint
    !

     

    • A quick verification on the hub that were ok

    R5#show ip ospf neighbor


    Neighbor ID     Pri   State           Dead Time   Address         Interface
    150.1.3.3         0   FULL/  -        00:01:34    155.1.0.3       Tunnel0
    150.1.1.1         0   FULL/  -        00:01:33    155.1.0.1       Tunnel0

     

     

    • On inspectipon of the HUBS routing table for OSR, we see nohing as expected. This is due to OSPF's AD being lower tha ODR (170 vs 110)

    R5#show ip route odr
    -nothing


    • On the Spoke we still see the default route from the HUB.


    R3#show ip route odr
    Gateway of last resort is 155.1.0.5 to network 0.0.0.0

    o*    0.0.0.0/0 [160/1] via 155.1.0.5, 00:03:42, Tunnel0



    • Ok so lets revisit the problem, accoring to the Cisco FAQ's on ODR the following is true
    • "When a spoke router sends its subnets to the hub through CDP, it checks to see if any routing protocol is enabled on the router. If it finds any dynamic routing protocol, it stops advertising its subnets."
    • So lets try to lower the AD on the HUB for OSPF & see if we learn the routes & OSPF is just superseeding them with it's better AD.

    On Router 5 I lowered the AD for OSPF to make it higher th ODR's 170.

    conf t
     router ospf 1
      distance 180
      !

    Then just a quick bounce of the interfaces to get things converging quickly.


    !!ALL (R1-R3-R5)
    conf t
     int tun 0
      shut
      no shut



    R5#show ip route odr
     nothing


    • Ok, so the SPOKES are not advertising to the hub, & if we were to look on the spokes they no longer have or a default route.

     

    • The defaults that were there from ODR when we had both OSPD & ODR running were the old values aging out of the routing table.


    If i remove OSPF we will learn our ODR routes again.

     

    Thanks for tuning in,

    Sam

  • Ok, so that's what ODR functional keyword is all about. Missed this one, thanks !

  • Hi,

    I came across this weird behavior that the default route would not be installed when received on physical interface. I enabled CDP on the subinterface G1.100 iand physical interface G1 instead of the tunnel interface. For some reason the default route will not be installed when CDP runs over subinterfaces. No routing protocols are running on the spokes. CDP packets will only be sent over the physical interface.

    R5#debug
    cdp packets

    CDP packet
    info debugging is on

    CDP-PA:
    Packet received from R2 on interface Tunnel0

    **Entry  found in cache**

    CDP-PA:
    version 2 packet sent out on GigabitEthernet1

    CDP-PA:
    Packet received from R2 on interface GigabitEthernet1

    **Entry  found in cache**

    All
    possible debugging has been turned off

     

    R5#sh cdp
    int

    GigabitEthernet1
    is up, line protocol is up

      Encapsulation 802.1Q Virtual LAN, Vlan
    ID  1.

      Sending CDP packets every 60 seconds

      Holdtime is 180 seconds

    GigabitEthernet1.100
    is up, line protocol is up

      Encapsulation 802.1Q Virtual LAN, Vlan
    ID  100.

      Sending CDP packets every 60 seconds

      Holdtime is 180 seconds

    Tunnel0 is
    up, line protocol is up

      Encapsulation TUNNEL

      Sending CDP packets every 60 seconds

      Holdtime is 180 seconds

     cdp enabled interfaces : 3

     interfaces up          : 3

     interfaces down        : 0

     

    Even though the default route is missing on the spokes, all loopback interfaces are present on the hub

     

    o        150.1.1.1/32 [160/1] via 169.254.100.1, 00:00:40

                          [160/1] via 155.1.0.1, 00:00:40, Tunnel0

    o        150.1.2.2/32 [160/1] via 169.254.100.2, 00:00:10

                          [160/1] via 155.1.0.2, 00:00:28, Tunnel0

    o        150.1.3.3/32 [160/1] via 169.254.100.3, 00:00:37

    o        150.1.4.4/32 [160/1] via 169.254.100.4, 00:00:47

    o        150.1.33.33/32 [160/1] via 169.254.100.3, 00:00:37

    o        150.1.44.44/32 [160/1] via 169.254.100.4, 00:00:47

     

    R2               Tunnel0           157              R I   CSR1000V  Tunnel0

    R2               Gig 1             172              R I   CSR1000V  Gig 1

    R3               Gig 1             168              R I   CSR1000V  Gig 1

    R1               Tunnel0           151              R I   CSR1000V  Tunnel0

    R1               Gig 1             122              R I   CSR1000V  Gig 1

    R6               Gig 1             155              R I   CSR1000V  Gig 1

    R4               Gig 1             142              R I   CSR1000V  Gig 1

     

    R1#sh ip route odr

    o*    0.0.0.0/0 [160/1] via 155.1.0.5, 00:00:16, Tunnel0

    vs.

    R3#sh ip route odr

    Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP

    R3#

     

    Hope this is helpful

     

     

Sign In or Register to comment.