Funny stuff. 

Played with it a bit and unfortunately debug is useless and documentation 
doesn't list any prerequisites or restrictions for that matter. 
Route tracking is obviously broken in 4.3.4. 
However if you indeed would like to track based on the 8.0.0.0/8 rather than 
the /9 than you can track based on 8.128.0.0/8 -which is outside of the 
8.0.0.0/9. 
This will change the state of the tracked object Up. 

It almost appears that that the logic behind tracking is that if you enter 
"track ipv4 8.0.0.0/8" XR tries to find "8.0.0.1" and figures out that the 
tracked 8.0.0.0/8 is not the best path for "8.0.0.1" so it puts the object to 
Down. 
Notice how in each example they are using host routes not network routes for 
tracking, maybe to avoid the random host route selection :) 



adam
> -----Original Message-----
> From: cisco-nsp [mailto:[email protected]] On Behalf Of
> Aivars
> Sent: Monday, June 02, 2014 9:30 PM
> To: [email protected]
> Subject: [c-nsp] IOS XR object tracking route reachability
> 
>   I am trying to achieve conditional default route injection in VRF on
>   ASR9k running 4.3.4. Similar configuration works on 7600 perfectly.
>   I configured default static to null and attached track to it. When I
>   started to configure tracks on 9k, I noticed that all of them are
>   down. By the customer request I am tracking some classfull routes
>   like 4.0.0.0/8 and 8.0.0.0/8. The configuration seemed to be pretty
>   straight forward at first:
> 
> track 100
>  type route reachability
>   vrf x
>   route ipv4 4.0.0.0/8
> !
> track 101
>  type route reachability
>   vrf x
>   route ipv4 8.0.0.0/8
> 
>   As I mentioned, both are down, however I see the corresponding
>   routes in the routing table:
> 
>   Routing entry for 4.0.0.0/8
>     Known via "bgp xxxx", distance 200, metric 0
>     Tag xxxx, type internal
>     Installed Jun  2 08:03:36.518 for 07:17:30
>     Routing Descriptor Blocks
>       x.x.x.x, from x.x.x.x
>         Nexthop in Vrf: "default", Table: "default", IPv4 Unicast, Table Id:
> 0xe0000000
>         Route metric is 0
>     No advertising protos.
> 
> Routing entry for 8.0.0.0/8
>   Known via "bgp xxxx", distance 200, metric 0
>   Tag xxxx, type internal
>   Installed Jun  2 13:58:48.932 for 01:23:29
>   Routing Descriptor Blocks
>     x.x.x.x, from x.x.x.x
>       Nexthop in Vrf: "default", Table: "default", IPv4 Unicast, Table Id:
> 0xe0000000
>       Route metric is 0
>   No advertising protos.
> 
>   Then I copied the configuration on one track to another 9k and got
>   the same result - down. When playing around I changed the tracked
>   prefix mask to /9 and got state UP. This is really confusing. I have
>   both 8.0.0.0/8 and 8.0.0.0/9 in the routing table towards the same
>   next hop and same metrics:
> 
> Routing entry for 8.0.0.0/8
>   Known via "bgp xxxxx", distance 20, metric 0
>   Tag xxxx, type external
>   Installed Jun  2 02:03:09.123 for 19:49:09
>   Routing Descriptor Blocks
>    x.x.250.145, from x.x.250.145, BGP external
>       Route metric is 0
>       Label: None
>       Tunnel ID: None
>       Extended communities count: 0
>   Route version is 0xab (171)
>   No local label
>   IP Precedence: Not Set
>   QoS Group ID: Not Set
>   Route Priority: RIB_PRIORITY_RECURSIVE (8) SVD Type
> RIB_SVD_TYPE_LOCAL  Download Priority 3, Download Version 1129312968
>   No advertising protos.
> RP/0/RSP0/CPU0:BIP-P3#sh route vrf INET 8.0.0.0/9 detail Mon Jun  2
> 21:52:43.134 EEST
> 
> Routing entry for 8.0.0.0/9
>   Known via "bgp xxxxx", distance 20, metric 0
>   Tag 3356, type external
>   Installed Jun  2 02:03:09.123 for 19:49:34
>   Routing Descriptor Blocks
>     x.x.250.145, from x.x.250.145, BGP external
>       Route metric is 0
>       Label: None
>       Tunnel ID: None
>       Extended communities count: 0
>   Route version is 0xab (171)
>   No local label
>   IP Precedence: Not Set
>   QoS Group ID: Not Set
>   Route Priority: RIB_PRIORITY_RECURSIVE (8) SVD Type
> RIB_SVD_TYPE_LOCAL  Download Priority 3, Download Version 1129312956
>   No advertising protos.
> 
>   Can someone please tell me where is the catch?
> 
> _______________________________________________
> cisco-nsp mailing list  [email protected]
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list  [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Reply via email to