08-13-2021 01:45 AM - edited 08-13-2021 07:19 AM
Hi,
We are using a vrf called inet for all peerings ("Internet in a VRF").
We have the following issue with BGP.
When we issue the command show bgp vrf inet ipv4 unicast inconsistent-as we receive the following error:
% Failed to retrieve data from EDM server: 'BGP' detected the 'fatal' condition 'Internal Error'
... line repeats 10 times.
On the same platform where we don't have the full bgp table this behaviour is not present.
Our BGP neighbors look like this (edited for privacy):
#show bgp vrf inet ipv4 unicast summary wide | begin ^Neighbor
Neighbor AS Up/Down St/PfxRcd
100.126.95.217 100 07:21:31 2669
100.231.184.233 100 07:21:55 839573
100.245.24.46 101 07:15:03 838233
100.68.252.48 102 07:21:30 836713
#show bgp vrf inet ipv6 unicast summary wide | begin ^Neighbor
Neighbor AS Up/Down St/PfxRcd
2001::418 101 07:14:46 120860
2001::506 102 03:27:52 118358
2a02::2f 100 07:21:59 125513
2a02::5 100 07:21:37 123
We are not installing multipath, but just the best path.
Any idea would be appreciated.
Thanks
PS: Edited show bgp for better reading.
Solved! Go to Solution.
04-11-2023 12:37 AM
Just to update this thread.
Under 6.8.2 with SP1, it appears to be solved.
08-13-2021 11:48 PM
Looking at cef records in this vrf we see the following problem:
#sh cef vrf inet ipv6 2a00:1450:4001:827::200e hardware ingress here 2 tbl_id:0x0 2a00:1450:4001::/48, version 1350991, out-of-resource, internal 0x1000001 0x0 (ptr 0x9f7d9278) [1], 0x0 (0x0), 0x0 (0x0) Updated Aug 13 16:22:41.891 Prefix Len 48, traffic index 0, precedence n/a, priority 3 via 2001::418/128, 5 dependencies, recursive, bgp-ext [flags 0x6020] path-idx 0 NHID 0x0 [0x9e8e5530 0x0] next hop 2001::418/128 via 2001::418/128 #sh cef vrf inet ipv4 142.250.186.174 hardware ingress here 2 tbl_id:0x0 142.250.0.0/15, version 8403414, out-of-resource, internal 0x1000001 0x0 (ptr 0xa5720cec) [1], 0x0 (0x0), 0x0 (0x0) Updated Aug 13 16:48:53.522 Prefix Len 15, traffic index 0, precedence n/a, priority 3 via 100.68.252.48/32, 5 dependencies, recursive, bgp-ext [flags 0x6020] path-idx 0 NHID 0x0 [0x9e8b1df8 0x0] next hop 100.68.252.48/32 via 100.68.252.48/31
Looking at cef resources, all looks normal:
#show cef vrf inet resource Sat Aug 14 06:44:40.003 UTC CEF resource availability summary state: GREEN CEF will work normally ipv4 shared memory resource: GREEN ipv6 shared memory resource: GREEN mpls shared memory resource: GREEN common shared memory resource: GREEN #show cef vrf inet resource | exclude GREEN CEF will work normally
Any ideas why CEF would show out-of-resource for entries in this VRF?
Is it a bad idea to have Internet table in a VRF in ASR 9001?
Thanks
08-14-2021 02:41 AM
But even after moving everything to GRT we still see the same EDM server error:
#sh bgp ipv4 unicast inconsistent-as % Failed to retrieve data from EDM server: 'BGP' detected the 'fatal' condition 'Internal Error' message repeats 10 times #sh bgp ipv6 unicast inconsistent-as % Failed to retrieve data from EDM server: 'BGP' detected the 'fatal' condition 'Internal Error' message repeats 10 times
What can be the problem?
Should be ignored? Is it safe?
08-17-2021 08:21 AM
Nobody?
08-14-2021 02:09 AM
As this is preproduction router, we moved everything in GRT.
Effect:
1) No more out-of-resource in cef
2) When bgp attribute-download is specified under address-family ipv4/6 unicast, no more OOR state: RED and now stays at GREEN.
So the question that remains is why if ASR9001 has Typhoon card supporting 4M credits is behaving like this?
Total prefixes were 840k IPv4 and 130k IPv6, which means (840k + 130k * 2) * 2 (being in vrf) = 2.2M which is < 4M.
Also another question is why is OOR State: RED when we have bgp attribute-download under address-family ipv4 under vrf inet, but is GREEN when is under default vrf?
We have in admin config the following scale (even though we know is only for Trident cards):
hw-module profile scale l3xl hw-module profile feature default
Thanks
08-14-2021 02:26 AM
What we are trying to achieve is implementation based on this design guide:
https://xrdocs.io/design/blogs/latest-peering-fabric-hld
The Internet in a VRF is a very good idea for isolating underlying SR-MPLS infrastructure
https://xrdocs.io/design/blogs/latest-peering-fabric-hld#internet-and-peering-in-a-vrf
If ASR9001 cannot support it we will be forced (without liking it) to use ASR9001 as leafs without participating in SR-MPLS and have the peerings in GRT.
The design guide is specifying the leaf router (NCS-5501-SE) which supports 2M IPv4 FIB scale and we read it as smaller than ASR9001.
Anyone could help with an idea about using ASR9001 as leaf with Internet in a vrf?
Thank you!
08-18-2021 05:49 AM
Hi,
Can you open a tac case for this? we can take a look at it.
Thanks
08-18-2021 11:47 PM
Unfortunately, support contract is expired and I don't believe I can open without one... Can I?
04-11-2023 12:37 AM
Just to update this thread.
Under 6.8.2 with SP1, it appears to be solved.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide