[c-nsp] slow convergence on edge BGP routers
jure brkljacic
zblajhani at gmail.com
Mon Mar 2 04:33:09 EST 2015
Hi,
Thanks for all the suggestions.I made a simple lab for test. To get the
backup/repair routes on EDGE1 router (pointing to EDGE2) into the rib/fib i
have to use bgp advertise best-external on EDGE2 and bgp additional-paths
install on EDGE1
the output:
0.0.0.0 0.0.0.0 0 i
*> 2.32.0.0/19 13.13.13.3 0 1000 0 65447 ?
*bi 12.12.12.2 0 100 0 65447 ?
*> 7.128.0.0/9 13.13.13.3 0 1000 0 65447 ?
*bi 12.12.12.2 0 100 0 65447 ?
*> 8.190.0.0/21 13.13.13.3 0 1000 0 65447 ?
*bi 12.12.12.2 0 100 0 65447 ?
*> 10.10.10.10/32 192.168.11.10 0 0 65404 ?
*bi 12.12.12.2 0 100 0 65404 ?
r> 13.13.13.0/24 13.13.13.3 0 1000 0 65447 ?
*> 13.32.136.0/21 13.13.13.3 0 1000 0 65447 ?
*bi 12.12.12.2 0 100 0 65447 ?
*> 16.129.13.128/25 13.13.13.3 0 1000 0 65447 ?
*bi 12.12.12.2 0 100 0 65447 ?
*> 17.128.0.0/9 13.13.13.3 0 1000 0 65447 ?
*bi 12.12.12.2 0 100 0 65447 ?
*> 18.64.0.0/11 13.13.13.3 0 1000 0 65447 ?
*bi 12.12.12.2 0 100 0 65447 ?
*> 18.178.224.0/23 13.13.13.3 0 1000 0 65447 ?
*bi 12.12.12.2 0 100 0 65447 ?
*> 20.180.216.0/24 13.13.13.3 0 1000 0 65447 ?
*bi 12.12.12.2 0 100 0 65447 ?
*> 22.32.0.0/11 13.13.13.3 0 1000 0 65447 ?
*bi 12.12.12.2 0 100 0 65447 ?
It`s safe to put this into the production? We are using RP2 with 8GB RAM
and ESP 40
show platform software status control-processor brief
Load Average
Slot Status 1-Min 5-Min 15-Min
RP0 Healthy 0.06 0.02 0.00
ESP0 Healthy 0.00 0.00 0.00
SIP0 Healthy 0.00 0.00 0.00
SIP1 Healthy 0.00 0.00 0.00
Memory (kB)
Slot Status Total Used (Pct) Free (Pct) Committed (Pct)
RP0 Healthy 8097788 3814360 (47%) 4283428 (53%) 5606388 (69%)
ESP0 Healthy 8097768 1334420 (16%) 6763348 (84%) 1052564 (13%)
SIP0 Healthy 471832 266384 (56%) 205448 (44%) 234540 (50%)
SIP1 Healthy 969080 330776 (34%) 638304 (66%) 648872 (67%)
**************************************************************
show platform hardware cpp active tcam resource-manager usage
QFP TCAM Usage Information
80 Bit Region Information
--------------------------
Name : Leaf Region #0
Number of cells per entry : 1
Current 80 bit entries used : 0
Current used cell entries : 0
Current free cell entries : 0
160 Bit Region Information
--------------------------
Name : Leaf Region #1
Number of cells per entry : 2
Current 160 bits entries used : 16
Current used cell entries : 32
Current free cell entries : 4064
320 Bit Region Information
--------------------------
Name : Leaf Region #2
Number of cells per entry : 4
Current 320 bits entries used : 0
Current used cell entries : 0
Current free cell entries : 0
Total TCAM Cell Usage Information
----------------------------------
Name : TCAM #0 on CPP #0
Total number of regions : 3
Total tcam used cell entries : 32
Total tcam free cell entries : 524256
Threshold status : below critical limit
Thanks
On Sat, Feb 28, 2015 at 12:55 PM, Adam Vitkovsky <Adam.Vitkovsky at gamma.co.uk
> wrote:
> Well that's a complex problem
>
> You can eliminate the egress traffic loss completely by using features
> like: "prefix independent convergence" to avoid the need for slow FIB
> programing, "advertise best external" to have a backup path available at
> the primary AS-EXIT and the local repair capability of "BGP PIC EDGE" to
> reroute all 530K+ prefixes towards the backup AS-EXIT in several hundreds
> of microseconds (yup not even a millisecond).
>
> However on ingress you need to wait till all AS-es connected to your
> primary upstream get the withdraw and rely it to their customers or other
> AS- es hanging off of them (and possibly all these folks need to wait some
> more till they all receive an alternate route from their local ASBRs if a
> given remote AS or your upstream is not using "advertise best external"
> feature).
>
> 15s is fine if you consider that the default BGP advertisement interval
> for eBGP sessions is 30s.
> Although I have never monitored this or tried in the lab.
> -has anyone seen this type of behaviour on a rush network where multiple
> updates and withdraws take place in a 30s interval do you actually see this
> update pacing in effect please?
>
>
> adam
>
> > -----Original Message-----
> > From: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of
> > jure brkljacic
> > Sent: 27 February 2015 01:43
> > To: cisco-nsp at puck.nether.net
> > Subject: [c-nsp] slow convergence on edge BGP routers
> >
> > Hi,
> >
> > We have two bgp routers with full bgp table. All traffic is forced over
> > router EDGE1(from EDGE2 and "internal" router).
> >
> > When i shutdown the "upstream link" on EDGE1 all the traffic is rerouted
> to
> > EDGE 2 router, but i see 15sec complete outage. (the path the end system
> > takes in "internal router" ->>EDGE1->>EDGE2)
> >
> > a.) BFD enabled on all interfaces (bgp neighbor is immediately torn down)
> > b.) no input queues on EDGE 1 during the convergence
> > c.)EDGE routers are ASR1004 with RSP2
> >
> >
> > how to minimize the traffic loss?
> >
> >
> > | |
> > | |
> > | |
> > +-----+-----+ +-----+-----+
> > | | | |
> > | EDGE1 ----------------EDGE2 |
> > | | | |
> > +----+------+ +--------+--+
> > | |
> > | |
> > | |
> > | |
> > | |
> > | |
> > | |
> > | +----------+ |
> > | | | |
> > | | | |
> > +--------+Router+--------+
> > | |
> > | |
> > +----------+
> > _______________________________________________
> > cisco-nsp mailing list cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>
> ------------------------------
> This email has been scanned for email related threats and delivered safely
> by Mimecast.
> For more information please visit http://www.mimecast.com
> ------------------------------
>
More information about the cisco-nsp
mailing list