An update to this article; there’s a method to get around the issue I ran into.  It is not well documented, and TAC knows nothing about it in my experience, but, as described at https://xrdocs.github.io/cloud-scale-networking/tutorials/ncs5500-routing-in-vrf/ you simply need to enable ‘label mode per-vrf’ for the BGP instance in the VRF; it will consume one lem entry instead of the full route table.

Two notes before we even begin:

1. Run this if you’re doing full internet tables on either the 5501 or 5501SE:

   hw-module fib ipv4 scale internet-optimized

   The manual / config guide doesn’t even mention it; had to find it on a Cisco employee’s blog.

2. (See my comment at the start of the article for a way around this issue if trying to do a full internet table in a VRF)  Next, don’t try to run full internet tables on a BGP instance in a VRF, the NCS will die a s̶l̶o̶w̶ fast death.  I tried to do this because I already had some config in place that was working and did not want internet mixing in with what was already defined.  Doesn’t matter if you’re running base 5501 or the ‘scale’ edition, 5501SE with the external tcam.  The issue is when BGP is in a VRF, all the incoming routes are no longer stored solely as IPv4 (and v6) prefixes, they’ve now become labeled routes since VRF’s use MPLS route distinguishers.  The end result is you’ll exhaust your ipnh table (check it via “show contr npu resources all location 0/0/CPU0”) almost as soon as the tables start to populate since it can only hold 100,000 entries.  If your router even stays up, one of mine kernel panic’d almost immediately, then your logs will fill up with this kind of thing:

LC/0/0/CPU0:Dec 16 19:33:28.972 : fib_mgr[128]: %ROUTING-FIB-3-PD_FAIL : FIB platform error: fib_leaf_ldi_lw_platform_update 626: PD action CREATE failed for lw_ldi 0x30c7847338 flags 0x8. Shared LDI 0x30c4d73698 num_slots 1 num_buckets 1 depth 3 ldi type 4 ldi protocol mpls flags 0x108441 pfx 203.199.41.0/24 : 0xaf9c0600 ‘DPA’ detected the ‘fatal’ condition ‘DPA Server – All FEC’s already allocated’ : fib_mgr : (PID=3443) : -Traceback= (TRUNCATED)

LC/0/0/CPU0:Dec 16 19:34:12.186 : fia_driver[285]: %PLATFORM-DPA-4-OOR_YELLOW : NPU 0, Table ipnhgroup

LC/0/0/CPU0:Dec 16 19:34:21.092 : fib_mgr[128]: %ROUTING-FIB-3-PLATF_UPD_FAIL : FIB platform update failed: Obj=DATA_TYPE_LDI_LW[ptr=0x30c7935fa0,refc=0x2,flags=0x8] Action=CREATE Proto=mpls. Cerr=’DPA’ detected the ‘fatal’ condition ‘DPA Server – All FEC’s already allocated’ : fib_mgr : (PID=3443) :

 

Assuming you’re not running full tables, and still want to proceed, it took a bit of work finding the right combination of directives to get BGP running in a VRF on this NCS5501(SE) with IOS XR 6.2.  I kept getting this annoying error when trying to commit, and then just general BGP not coming up:

!!% 'BGP' detected the 'warning' condition 'The address family has not been initialized'

Apparently the above issue was being caused by the fact that I was trying to run BGP in a VRF, not at the root level, and IOS XR not appreciating that certain config bits were not defined in the root ‘router bgp’ stanza when you’re trying to add your real config in a VRF.  The things I had to do to get BGP up for internal and external were:

• For either type of session, a missing route distinguisher at the BGP VRF level will keep it down.  If you’re not doing MPLS or a more complex deployment, you can probably just make this number up, such as 1:1.
• If you will have no BGP at the root (non-VRF) level, then an ‘address-family vpnv4 unicast’ and ‘address-family ipv4 unicast’ at the root level must be defined regardless.  So what you need to do is tweak the following to your site specifics:

  rd-set 1:1
  exit
  router bgp ASN
   address-family ipv4 unicast
  exit
   address-family vpnv4 unicast 
  exit
  commit
  
   vrf WHATEVER
   rd 1:1
   bgp router-id 192.0.2.2
   address-family ipv4 unicast
  exit
  commit
  

  Note that the ASN, VRF name, router id and route distinguisher will of course all differ from your implementation; the 192.0.2.2/32 is on my loop1 in vrf WHATEVER.  Obviously adjust as needed.

  That should make it happy and allow you to continue with adding neighbors.

• If you’re peering from a loop interface for iBGP, like you should so you can have path redundancy, then make sure to add an update source to the iBGP neighbor config on each side.
• On the eBGP side, you must have an in and out route-policy even if you don’t need one.  So, you could simply add:

  route-policy IN
   pass
  end-policy
  route-policy OUT
   pass
  end-policy
  
  router bgp ASN
   vrf WHATEVER
   neighbor 192.0.2.1
   address-family ipv4 unicast
    route-policy IN in
    route-policy OUT out
  commit

  Obviously you should create real route policies, including an equivalent to the old prefix-list to ensure you’re not advertising things you don’t intend to.