cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
960
Views
0
Helpful
1
Replies

Is speific route is required for SRTE ODN ?

samarjit dutta
Level 1
Level 1

Trying to learn Segment routing :)

 

I am trying to setup a SRTE ODN scenario as per the following topology

ODN_Toplogy.PNG

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Currently

  • AGG routers are receiving remote AGG vpnv4 routes with BGP next hop as remote AGG's loopback
  • Local AGG routers has no routes to reach remote AGG loopback
  • AGG routers are able to create SRTE ODN tunnel to remote AGG with the help of PCE controller
  • As route to reach the next hop is not present in RT, BGP is not selecting the path as valid best path

Is it required to have a non-default route in RT to reach the remote AGG in order to make ODN working?

Here are the CLI output to present the scenario

No route to remote AGG (10.10.10.10) from local AGG (10.9.9.9)

 

RP/0/0/CPU0:AGG01#show route ipv4 unicast 10.10.10.10
Sun Dec  8 11:28:58.623 UTC

% Network not in table

VPNV4 routes are received by AGG with next-hop unchanged

 

 

RP/0/0/CPU0:AGG01#show bgp vrf A | be Network
Sun Dec  8 11:29:41.690 UTC
   Network            Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 100:1 (default for vrf A)
*> 20.1.0.0/30        0.0.0.0                  0         32768 ?
*                     20.1.0.2                 0             0 200 ?
*> 20.1.100.0/24      20.1.0.2                 0             0 200 ?
*> 20.1.101.0/24      20.1.0.2                 0             0 200 ?
* i20.3.0.0/30        10.10.10.10 C:111
                                               0    100      0 ?
* i20.3.100.0/24      10.10.10.10 C:111
                                               0    100      0 200 ?
* i20.3.101.0/24      10.10.10.10 C:111
                                               0    100      0 200 ?

Processed 6 prefixes, 7 path

SRTE ODN tunnel is triggered

 

 

RP/0/0/CPU0:AGG01#show bgp vrf A 20.3.100.0/24
Sun Dec  8 11:30:50.625 UTC
BGP routing table entry for 20.3.100.0/24, Route Distinguisher: 100:1
Versions:
  Process           bRIB/RIB  SendTblVer
  Speaker                 78          78
Last Modified: Dec  8 08:44:13.324 for 02:46:37
Paths: (1 available, no best path)
  Not advertised to any peer
  Path #1: Received by speaker 0
  Not advertised to any peer
  200
    10.10.10.10 C:111 (bsid:24012) (inaccessible) from 10.5.5.5 (10.10.10.10)
      Received Label 24007
      Origin incomplete, metric 0, localpref 100, valid, internal, import-candidate, imported
      Received Path ID 0, Local Path ID 0, version 0
      Extended community: Color:111 RT:100:1
      Originator: 10.10.10.10, Cluster list: 10.5.5.5, 10.11.11.11, 10.7.7.7
      SR policy color 111, up, registered, bsid 24012, if-handle 0x00000070

      Source AFI: VPNv4 Unicast, Source VRF: A, Source Route Distinguisher: 100:1
RP/0/0/CPU0:AGG01#


RP/0/0/CPU0:AGG01#show mpls forwarding labels 24012 detail
Sun Dec  8 11:31:56.891 UTC
Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes
Label  Label       or ID              Interface                    Switched
------ ----------- ------------------ ------------ --------------- ------------
24012  Pop         No ID              srte_c_111_e point2point     0
     Updated: Dec  6 16:07:23.276
     Version: 25, Priority: 2
     Label Stack (Top -> Bottom): { Unlabelled Imp-Null }
     NHID: 0x0, Encap-ID: N/A, Path idx: 0, Backup path idx: 0, Weight: 0
     MAC/Encaps: 0/0, MTU: 0
     Outgoing Interface: srte_c_111_ep_10.10.10.10 (ifhandle 0x00000070)
     Packets Switched: 0

RP/0/0/CPU0:AGG01# 

 

SRTE policy status

 

RP/0/0/CPU0:AGG01#show segment-routing traffic-eng policy color 111
Sun Dec  8 11:33:00.136 UTC

SR-TE policy database
---------------------

Color: 111, End-point: 10.10.10.10
  Name: srte_c_111_ep_10.10.10.10
  Status:
    Admin: up  Operational: up for 1d19h (since Dec  6 16:07:23.276)
  Candidate-paths:
    Preference: 200 (BGP ODN) (shutdown)
      Requested BSID: dynamic
      Dynamic (invalid)
    Preference: 100 (BGP ODN) (active)
      Requested BSID: dynamic
      PCC info:
        Symbolic name: bgp_c_111_ep_10.10.10.10_discr_100
        PLSP-ID: 1
      Dynamic (pce 10.12.12.12) (valid)
        Metric Type: IGP,   Path Accumulated Metric: 5
          16005 [Prefix-SID, 10.5.5.5]
          16007 [Prefix-SID, 10.7.7.7]
          16010 [Prefix-SID, 10.10.10.10]
  Attributes:
    Binding SID: 24012
    Forward Class: 0
    Steering BGP disabled: no
    IPv6 caps enable: yes

 CEF entry

RP/0/0/CPU0:AGG01#show cef vrf A 20.3.100.1
Sun Dec  8 11:33:45.393 UTC
0.0.0.0/0, version 0, proxy default, default route handler, drop adjacency, internal 0x1001011 0x0 (ptr 0xa14153c4) [1], 0x0 (0xa13f8238), 0x0 (0x0)
 Updated Dec  6 16:00:02.726
 Prefix Len 0, traffic index 0, precedence n/a, priority 15
   via 0.0.0.0/32, 7 dependencies, weight 0, class 0 [flags 0x0]
    path-idx 0 NHID 0x0 [0xa0ee2148 0x0]
    next hop 0.0.0.0/32
     drop adjacency
RP/0/0/CPU0:AGG01#

Now, If I forcefully put one route in RT of local AGG to reach remote AGG, BGP start selecting the path and traffic is flowing as per the expectation.

I have achieved that by doing the following .........

 

RP/0/0/CPU0:AGG01(config-static)#address-family ipv4 unicast
RP/0/0/CPU0:AGG01(config-static-afi)#0.0.0.0/1 null 0
RP/0/0/CPU0:AGG01(config-static-afi)#commit

Results:

 

RP/0/0/CPU0:AGG01#show bgp vrf A | be Network
Sun Dec  8 11:35:56.974 UTC
   Network            Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 100:1 (default for vrf A)
*> 20.1.0.0/30        0.0.0.0                  0         32768 ?
*                     20.1.0.2                 0             0 200 ?
*> 20.1.100.0/24      20.1.0.2                 0             0 200 ?
*> 20.1.101.0/24      20.1.0.2                 0             0 200 ?
*>i20.3.0.0/30        10.10.10.10 C:111
                                               0    100      0 ?
*>i20.3.100.0/24      10.10.10.10 C:111
                                               0    100      0 200 ?
*>i20.3.101.0/24      10.10.10.10 C:111
                                               0    100      0 200 ?
Processed 6 prefixes, 7 paths
RP/0/0/CPU0:AGG01#

RP/0/0/CPU0:AGG01#show cef vrf A 20.3.100.1 detail
Sun Dec  8 11:36:52.720 UTC
20.3.100.0/24, version 33, internal 0x5000001 0x0 (ptr 0xa1416c60) [1], 0x0 (0x0), 0x208 (0xa1757554)
 Updated Dec  8 11:35:13.736
 Prefix Len 24, traffic index 0, precedence n/a, priority 3
  gateway array (0xa1350128) reference count 3, flags 0x2038, source rib (7), 0 backups
                [1 type 1 flags 0x48441 (0xa1773718) ext 0x0 (0x0)]
  LW-LDI[type=0, refc=0, ptr=0x0, sh-ldi=0x0]
  gateway array update type-time 1 Dec  8 11:35:13.736
 LDI Update time Dec  8 11:35:13.736
   via local-label 24012, 3 dependencies, recursive [flags 0x6000]
    path-idx 0 NHID 0x0 [0xa17cbfcc 0x0]
    recursion-via-label
    next hop VRF - 'default', table - 0xe0000000
    next hop via 24012/0/21
     next hop srte_c_111_e labels imposed {ImplNull 24007}

    Load distribution: 0 (refcount 1)

    Hash  OK  Interface                 Address
    0     Y   recursive                 24012/0
RP/0/0/CPU0:AGG01#

Is it required to have a non-default route in RT to reach the remote AGG in order to make ODN working?

IOS Version:

 

RP/0/0/CPU0:AGG01#show ver brief | in VersSun Dec  8 11:24:46.940 UTC
Cisco IOS XR Software, Version 6.6.2[Default]
ROM: GRUB, Version 1.99(0), DEV RELEASE

 

 

Thanks in advance for support me to learn

 

 

1 Reply 1

pigallo
Cisco Employee
Cisco Employee

 

@samarjit dutta  hello,

 

yes, indeed, for SR ODN to work, the less specific length for next-hop resolution is >= 1.
Default route does not validate it.
This should have a meaning though, especially for BGP NLRI, to avoid next-hop resolution via default route. BGP selective next-hop address tracking has similar purpose but with increased filtering options.

 

 

Regards