Mailing List Archive

On 27/Jan/20 08:05, Hank Nussbacher wrote:

> As many of us run full routing tables on our ASR9000s, we have just
> found popping up in our logs:
> gp[1058]: %ROUTING-BGP-5-MAXPFX : No. of IPv4 Unicast prefixes
> received from xxx.xxx.220.91 has reached 786433, max 1048576
> Reference:
> https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r5-3/routing/configuration/guide/b_routing_cg53xasr9k/b_routing_cg53xasr9k_chapter_010.html
>
> The undefined default for maximum-prefix on ASR9000s (IOS-XR) is 1048576.
> Recommendation: increase maximum-prefix to 1500000

Known issue since IOS XR launched back in the day.

For as far back as I can remember (probably 2010 or earlier), we always
had the below line as standard configuration in all our IOS XR platforms
for BGP sessions that did not require a prefix limit:

       maximum-prefix 4294967295 75

Doesn't affect only the ASR9000, but all IOS XR platforms.

Mark.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Hello,

On Mon, 27 Jan 2020 at 08:14, Mark Tinka <mark.tinka@seacom.mu> wrote:
> On 27/Jan/20 08:05, Hank Nussbacher wrote:
>
> > As many of us run full routing tables on our ASR9000s, we have just
> > found popping up in our logs:
> > gp[1058]: %ROUTING-BGP-5-MAXPFX : No. of IPv4 Unicast prefixes
> > received from xxx.xxx.220.91 has reached 786433, max 1048576
> > Reference:
> > https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r5-3/routing/configuration/guide/b_routing_cg53xasr9k/b_routing_cg53xasr9k_chapter_010.html
> >
> > The undefined default for maximum-prefix on ASR9000s (IOS-XR) is 1048576.
> > Recommendation: increase maximum-prefix to 1500000
>
> Known issue since IOS XR launched back in the day.
>
> For as far back as I can remember (probably 2010 or earlier), we always
> had the below line as standard configuration in all our IOS XR platforms
> for BGP sessions that did not require a prefix limit:
>
> maximum-prefix 4294967295 75
>
> Doesn't affect only the ASR9000, but all IOS XR platforms.

For people running full tables with labels (BGP-LU or
Internet-in-a-VRF), it's probably a good time to start thinking about
their label consumption, if a label is allocated per-prefix (default
in Cisco land at least for MPLS VPNs).

Running out of label space (with is limited to 1M, you can't stuff
more in a 20-bit label) is gonna be bad experience. While with the
6500/7600 TCAM issue only those particular nodes were affected, this
is not a question of obsolete HW, SW or TCAM partitioning on a
particular node and will affect all vendors in a per-prefix label
allocation configuration.

We are running Internet-in-a-VRF on both IOS-XE and IOS-XR, in per-ce
(meaning per next-hop) label allocation mode. It was buggy initially
in IOS-XE, but after a few rounds of bug-fixing a few years ago things
are running smoothly now. I like the fact that I'm only doing one L3
lookup on the ingress-PE, which is why I avoid per-VRF label
allocation mode.


cheers,
lukas
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

On Mon, 27 Jan 2020 at 11:24, Lukas Tribus <lists@ltri.eu> wrote:

> For people running full tables with labels (BGP-LU or
> Internet-in-a-VRF), it's probably a good time to start thinking about
> their label consumption, if a label is allocated per-prefix (default
> in Cisco land at least for MPLS VPNs).

You need to go all the way to 6.5.1 (CSCvf15291) for per-ce to IPv4,
IPv6 has had it always.

--
++ytti
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Hello,

On Mon, 27 Jan 2020 at 11:15, Saku Ytti <saku@ytti.fi> wrote:
> > For people running full tables with labels (BGP-LU or
> > Internet-in-a-VRF), it's probably a good time to start thinking about
> > their label consumption, if a label is allocated per-prefix (default
> > in Cisco land at least for MPLS VPNs).
>
> You need to go all the way to 6.5.1 (CSCvf15291) for per-ce to IPv4,
> IPv6 has had it always.

I'm confused; I'm running Internet in a MPLS VPNs with per-ce label
allocation on ASR9k since 2016, for both address-families.

What is CSCvf15291 about exactly (it's not public).


Thanks,

Lukas
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

On Mon, 27 Jan 2020 at 12:54, Lukas Tribus <lists@ltri.eu> wrote:

> I'm confused; I'm running Internet in a MPLS VPNs with per-ce label
> allocation on ASR9k since 2016, for both address-families.
>
> What is CSCvf15291 about exactly (it's not public).

IPv4 unicast, everything else had it since day1(?).

--
++ytti
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

On Mon, 27 Jan 2020 at 12:21, Saku Ytti <saku@ytti.fi> wrote:
>
> On Mon, 27 Jan 2020 at 12:54, Lukas Tribus <lists@ltri.eu> wrote:
>
> > I'm confused; I'm running Internet in a MPLS VPNs with per-ce label
> > allocation on ASR9k since 2016, for both address-families.
> >
> > What is CSCvf15291 about exactly (it's not public).
>
> IPv4 unicast, everything else had it since day1(?).

Makes sense, thanks for clarifying.

I guess IPv4 labeled unicast deployments are much more common than
Internet-in-a-VRF configurations, so the 6.5.1 requirement is
important indeed.


thanks,
lukas
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

> Mark Tinka
> Sent: Monday, January 27, 2020 7:14 AM
>
> On 27/Jan/20 08:05, Hank Nussbacher wrote:
>
> > As many of us run full routing tables on our ASR9000s, we have just
> > found popping up in our logs:
> > gp[1058]: %ROUTING-BGP-5-MAXPFX : No. of IPv4 Unicast prefixes
> > received from xxx.xxx.220.91 has reached 786433, max 1048576
> > Reference:
> >
> https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r
> > 5-3/routing/configuration/guide/b_routing_cg53xasr9k/b_routing_cg53xas
> > r9k_chapter_010.html
> >
> > The undefined default for maximum-prefix on ASR9000s (IOS-XR) is
> 1048576.
> > Recommendation: increase maximum-prefix to 1500000
>
> Known issue since IOS XR launched back in the day.
>
> For as far back as I can remember (probably 2010 or earlier), we always had
> the below line as standard configuration in all our IOS XR platforms for BGP
> sessions that did not require a prefix limit:
>
> maximum-prefix 4294967295 75
>
Have you tested what happens with an XR BGP when a valid peer sends you ~2,147,483,647 prefixes please?

My guess is the BGP runs out of memory and restarts -what happens to the FIB on all line-cards I'm not even guessing...
And then the RRs pushing 2bilions of prefixes to all other PEs in the AS...
I actually haven't tested so would be interested to know.

Anyways I'd rather have the offending internet peer/peers reset at around 1M or so -while BGP and line-cards can still cope with the load.
Of course VPN customers have lower thresholds.

adam



_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

On 3/Feb/20 23:15, adamv0025@netconsultings.com wrote:

> Have you tested what happens with an XR BGP when a valid peer sends
> you ~2,147,483,647 prefixes please?
> My guess is the BGP runs out of memory and restarts -what happens to the FIB on all line-cards I'm not even guessing...
> And then the RRs pushing 2bilions of prefixes to all other PEs in the AS...
> I actually haven't tested so would be interested to know.

So we only set the maximum value for this on iBGP sessions for our IOS
XR boxes. Which makes sense.

On eBGP sessions with peers, we impose a pre-defined maximum value
which, generally, is a couple hundred prefixes for IPv4/IPv6, unless
specifically advised by the external peer.

Mark.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

> Have you tested what happens with an XR BGP when a valid peer sends you
> ~2,147,483,647 prefixes please?
>
> My guess is the BGP runs out of memory and restarts -what happens to the
> FIB on all line-cards I'm not even guessing...
> And then the RRs pushing 2bilions of prefixes to all other PEs in the AS...
> I actually haven't tested so would be interested to know.
>
> Anyways I'd rather have the offending internet peer/peers reset at around
> 1M or so -while BGP and line-cards can still cope with the load.
> Of course VPN customers have lower thresholds.
>
> adam
>

I had some maintenance to perform on an ASR9001 (32bit IOS-XR) - there was a point in time during the maintenance where it only had installed routes from our RRs.

Device#sh bgp all unicast summary wide
Wed Feb 12 13:48:14.246 UTC

Address Family: IPv4 Unicast
----------------------------

BGP router identifier xxxxxxxx, local AS number 38195
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe0000000 RD version: 7020912
BGP main routing table version 7020912
BGP NSR Initial initsync version 9 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs

BGP is operating in STANDALONE mode.


Process RcvTblVer bRIB/RIB LabelVer ImportVer SendTblVer StandbyVer
Speaker 7020912 7020912 7020912 7020912 7020912 0

Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd
rr-ip 0 38195 384291 158 7020912 0 0 00:23:06 2297554
rr-ip 0 38195 384189 157 7020912 0 0 00:22:58 2297548
rr-ip 0 38195 384858 157 7020912 0 0 00:22:58 2297550


Address Family: IPv6 Unicast
----------------------------

BGP router identifier xxxxxxxx, local AS number 38195
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe0800000 RD version: 841464
BGP main routing table version 841464
BGP NSR Initial initsync version 6 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs

BGP is operating in STANDALONE mode.


Process RcvTblVer bRIB/RIB LabelVer ImportVer SendTblVer StandbyVer
Speaker 841464 841463 841464 841463 841463 0

Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd
rr-ip 0 38195 104261 145 841463 0 0 00:23:06 249910
rr-ip 0 38195 104244 143 841463 0 0 00:22:48 249910
rr-ip 0 38195 104322 145 841463 0 0 00:23:06 249910


Happy to report that it didn't explode.

Thanks
Tim.
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Hello Tim,

Our routine on ASR9001-S - 3M.

ASR9001-S#show route summary
Thu Feb 13 10:20:55
Route Source Routes Backup Deleted Memory(bytes)
connected 41 1 0 6720
local 42 0 0 6720
static 43 0 0 6880
ospf 300 1 0 0 160
bgp xxx 3016494 2 0 482639360
dagr 0 0 0 0
Total 3016621 3 0 482659840


On Wed, 12 Feb 2020 22:58:51 +0000
Tim Warnock <timoid@timoid.org> wrote:

> I had some maintenance to perform on an ASR9001 (32bit IOS-XR) - there was a point in time during the maintenance where it only had installed routes from our RRs.

--
Alexandr
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/