The (Unofficial) CCNP-SP Study Guide
  • About
    • About the Author
    • About This Study Guide
  • MPLS
    • LDP
      • LDP Transport Address
      • LDP Conditional Advertisement
      • LDP Authentication
      • LDP/IGP Sync
      • LDP Session Protection
    • MPLS-TE
      • MPLS-TE Basics, Pt. 1 (TED)
      • MPLS-TE Basics, Pt.2 (RSVP)
      • MPLS-TE Basics, Pt.3 (CSPF)
      • MPLS-TE Basics, Pt.4 (Routing)
      • MPLS-TE Fast Reroute (FRR)
      • MPLS-TE with OSPF
    • Unified MPLS
    • Segment Routing
      • Introduction, Theory Pt.1
      • Introduction, Lab (OSPF) Pt.2
      • Introduction, Lab (ISIS) Pt. 3
      • Multi-Area/Level Segment Routing
      • Segment Routing using BGP
      • Migrating LDP to SR
      • LDP/SR Interworking
      • TI-LFA Pt. 1 (Theory)
      • TI-LFA Pt. 2 (Implementation)
      • TI-LFA Pt. 3 (Node and SRLG Protection)
      • SR-TE Pt. 1 (Overview)
      • SR-TE Pt. 2 (Creating an SR-TE Policy)
      • SR-TE Pt. 3 (Using a PCE)
      • SR-TE Pt. 4 (Automated Steering)
      • SR-TE Pt. 5 (On-Demand Nexthop)
      • SR-TE Pt. 6 (Flex Algo)
    • MPLS OAM
      • Classic Traceroute Behavior in MPLS Networks
      • LSP Ping
      • LSP Traceroute
  • Routing
    • BGP
      • BGP Synchronization
      • BGP Load Sharing (Multipath)
      • An Intuitive Look at Path Attributes
      • AS Path Prepending on XE and XR
      • RPL
    • BGP Security
      • BGP TTL Security, Pt. 1
      • BGP TTL Security, Pt. 2 (IOS-XE)
      • BGP TTL Security, Pt. 3 (IOS-XR)
      • BGP MD5 Authentication
      • BGP Maximum Prefixes
      • BGP RFD (Route Flap Dampening)
      • RTBH
      • Flowspec
      • BGPsec
    • L3VPN
      • An In-Depth Look at RD and RT, Pt. 1
      • An In-Depth Look at RD and RT, Pt. 2
      • An In-Depth Look at RD and RT, Pt. 3
      • An In-Depth Look at RD and RT, Pt. 4
      • Inter-AS L3VPN Pt. 1, Overview
      • Inter-AS L3VPN Pt. 2, Option A
      • Inter-AS L3VPN Pt. 3, Option B
      • Inter-AS L3VPN Pt. 4, Option C
      • CSC (Carrier Supporting Carrier)
      • PE NAT
    • OSPF
      • Type 7 to Type 5 Translation
      • OSPF Authentication
      • Troubleshooting OSPF Adjacencies
      • OSPFv3 LSA Types
      • OSPFv3 LSAs Example (Single Area)
    • ISIS
      • The Potential for Asymmetric Routing with Multi-Area ISIS
      • Interarea Routing is Distance-Vector
      • Basic ISIS - LSPDB
      • Multitopology
      • What is the role of CLNS and CLNP in ISIS?
      • Troubleshooting ISIS Adjacencies
    • IPv6 Transition
      • Overview
      • NAT64
      • 6to4
      • 6RD (IPv6 Rapid Deployment)
      • DS Lite (Dual Stack Lite)
      • MAP (Mapping of Address and Port)
      • Tunneling IPv6 Dynamic Routing Protocols over IPv4
    • Multicast
      • Introduction
      • IP and MAC Addressing
      • Tree Formation and Packet Forwarding
      • IGMP
      • PIM-DM (Dense Mode)
      • PIM-SM (Sparse Mode)
      • PIM-SM SPT Switchover
      • PIM-SM Tunnel Interfaces
      • PIM DR and the Assert Message
      • PIM-SM RP Discovery
      • PIM-BiDir
      • PIM-SSM (Source-Specific Multicast)
      • Interdomain Multicast (PIM-SM)
      • IPv6 Multicast
      • mVPN Introduction
      • mVPN Profile 0
      • mVPN Profile 1
      • Multicast Routing on IOS-XR
  • L2VPN & Ethernet
    • IOS-XE Ethernet Services
      • Service Instances
      • E-Line
      • E-LAN (VPLS)
      • E-Tree
      • E-Access
      • VPLS with BGP Autodiscovery
      • Martini/Kompella Circuits
    • EVPN
      • Introduction to EVPN
      • Learning EVPN VXLAN First
      • E-Line (EVPN VPWS)
      • E-Line (EVPN VPWS) on IOS-XR
      • E-Line (EVPN VPWS) Multi-Homed
      • E-LAN (EVPN Single-Homed)
    • Carrier Ethernet
      • 802.1ah (MAC-in-MAC)
      • 802.3ah (Ethernet OAM)
      • 802.1ag (CFM)
      • Cisco REP (Resilient Ethernet Protocol)
      • ITU G.8032 ERPS (Ethernet Ring Protection Switching)
  • Security
    • CoPP (Control Plane Policing)
    • LPTS (Local Packet Transport Services)
  • Misc
    • QoS
      • QoS Introduction (Part 1)
      • QoS Tools Overview and QoS Models (Part 2)
      • QoS Classification and Marking (Part 3)
      • QoS Queuing/Congestion Management (Part 4)
      • QoS Shaping and Policing (Part 5)
      • QoS for IPv6
      • MPLS QoS Basics
      • MPLS QoS Modes
      • MPLS TE QoS (DS-TE)
      • MPLS TE CBTS/PBTS
    • Automation and Assurance
      • NSO
      • NSO Command Cheat Sheet
      • Intro to YANG/NETCONF
      • YANG In-Depth
      • NETCONF In-Depth
      • RESTCONF
      • Model-Driven Telemetry
      • Automation Tool Comparison
      • Netflow
      • SNMP
    • Virtualization
      • NFV (Network Function Virtualization)
      • OpenStack
    • Transport
      • xPON
      • SONET/SDH
      • WDM
      • 4G and 5G RAN
    • High Availability (HA)
      • NSF/GR
      • NSR
      • NSF/NSR Whitepapers
      • BFD
      • Link Aggregation on IOS-XE
      • Link Aggregation on IOS-XR
    • IOS Software Overview
  • Labs
    • Lab Challenges
      • How to Use These Labs
      • Basic LDP
      • Advanced LDP
      • BGP Security
      • Unified MPLS
      • BGP Fundamentals
      • Ethernet Services
      • L3VPN Extranet
      • Multicast
      • Inter-area OSPF
      • ISIS
      • MPLS-TE
      • Control Plane Policing
      • QoS
Powered by GitBook
On this page
  • Lab
  • Real world use
  • IOS-XR Differences
  1. Routing
  2. BGP Security

BGP Maximum Prefixes

In the SPCOR blueprint, section 1.5.c is “BGP prefix suppression.” It is unclear to me whether this refers to the max prefixes feature, which limits the maximum number of prefixes the router will accept from a peer, or whether it refers to the route flap dampening feature, which penalizes routes if they flap up/down too many times in a given interval.

I think it is worth covering both features, so we will start with maximum prefixes first.

The maximum prefix feature prevents a malicious peer from advertising millions of routes in an attempt to exhaust the local router’s resources. The administrator defines a set number of maximum prefixes it is willing to learn from the peer, and the action to take when the peer exceeds that limit.

The following actions can take place when the maximum number of prefixes is exceeded:

  • The session is reset. An admin must manually re-establish the peering session using clear ip bgp.

  • The session is reset and then automatically re-established after a configured time interval.

  • The session is kept intact, routes are still installed in the table as normal, but a warning syslog message is generated for every prefix received over the max prefixes limit.

For all actions, you can configure a warning syslog message at a certain percent interval, such as 80%.

The configuration command looks like this:

neighbor 1.1.1.1 maximum-prefix num-prefixes [warning-threshold-percentage] [restart restart-interval-in-mins] [warning-only]

For example, this would limit the peer 1.1.1.1 to advertising 100 prefixes, and restart the session after 30 minutes. If the peer advertises 101 prefixes, the BGP session will be brought down, and then automatically restarted after 30 minutes. If the peer is still advertising 101 prefixes upon restart, the cycle of down/restart will continue.

neighbor 1.1.1.1 maximum-prefix 100 restart 30

This would continue to accept all prefixes, but generate a warning for every prefix that after the 100th prefix:

neighbor 1.1.1.1 maximum-prefix 100 warning-only

This would do the same as the first example, but also generate a warning at 80 messages (80% of 100):

neighbor 1.1.1.1 maximum-prefix 100 80 restart 30

By default, the warning threshold is 75% if none is specified.

Lab

We’ll reuse our peering session between R4 and XR5 to test this feature.

Your peering session should still be Established, but we’ll need to add a route-policy to XR5 to accept/advertise prefixes. In the previous article, I omitted this step, because it wasn’t necessary to establish the peering session, which is all we were trying to do in the MD5 Authentication article.

On XR5, if we look at bgp sum, we can see an exclamation mark (!) next to the prefixes received. This lets us know that the neighbor does not have an RPL applied to it. Inbound/Outbound policies are necessary for eBGP neighbors on IOS-XR.

RP/0/0/CPU0:XR5(config)#route-policy PASS
RP/0/0/CPU0:XR5(config-rpl)#pass
RP/0/0/CPU0:XR5(config-rpl)#end-policy 
RP/0/0/CPU0:XR5(config)#router bgp 65002
RP/0/0/CPU0:XR5(config-bgp)#neighbor 10.4.5.4
RP/0/0/CPU0:XR5(config-bgp-nbr)#address-family ipv4 uni
RP/0/0/CPU0:XR5(config-bgp-nbr-af)#route-policy PASS in
RP/0/0/CPU0:XR5(config-bgp-nbr-af)#route-policy PASS out
RP/0/0/CPU0:XR5(config-bgp-nbr-af)#commit

On R4, we’ll limit the XR5 peer to a maximum of 3 advertised prefixes:

#R4
router bgp 65001
 neighbor 10.4.5.5 maximum-prefix 3

Let’s look at the neighbor parameters to verify the configuration worked:

R4#show bgp neighbors 10.4.5.5
<snip>
 For address family: IPv4 Unicast
<snip>
  Maximum prefixes allowed 3
  Threshold for warning message 75%

By default, BGP will bring down the neighbor when 4 prefixes are received, and not automatically restart the session.

On XR5, let’s create some prefixes and advertise them.

XR5#
int lo0
 ip address 5.5.5.5/32
int lo1
 ip address 5.5.5.6/32
int lo2
 ip address 5.5.5.7/32
int lo3
 ip address 5.5.5.8/32
!
router bgp 65002
 address-family ipv4 unicast
  network 5.5.5.5/32
  network 5.5.5.6/32
  network 5.5.5.7/32

R4 generates a warning that its peer has advertised the maximum number of prefixes permitted. However, the session is not down yet. The maximum has been reached but not exceeded.

R4#show bgp sum
<snip>
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.4.5.5        4        65002    3281    3610        4    0    0 2d06h           3

R4#
*Jul 14 03:01:33.241: %SYS-5-CONFIG_I: Configured from console by console
R4#
*Jul 14 03:01:34.023: %BGP-4-MAXPFX: Number of prefixes received from 10.4.5.5 (afi 0) reaches 3, max 3

Let’s advertise one more prefix on XR5

router bgp 65002
 address-family ipv4 unicast
  network 5.5.5.8/32

R4 lets us know that the maximum number of prefixes has been exceeded and brings down the session

R4#
*Jul 14 03:03:34.251: %BGP-3-MAXPFXEXCEED: Number of prefixes received from 10.4.5.5 (afi 0): 4 exceeds limit 3
*Jul 14 03:03:34.251: %BGP-3-NOTIFICATION: sent to neighbor 10.4.5.5 6/1 (Maximum Number of Prefixes Reached) 7 bytes 00010100 000003
R4#
*Jul 14 03:03:34.251: %BGP-5-NBR_RESET: Neighbor 10.4.5.5 reset (Peer over prefix limit)
*Jul 14 03:03:34.252: %BGP-5-ADJCHANGE: neighbor 10.4.5.5 Down Peer over prefix limit
*Jul 14 03:03:34.252: %BGP_SESSION-5-ADJCHANGE: neighbor 10.4.5.5 IPv4 Unicast topology base removed from session  Peer over prefix limit

In the BGP summary output, we can conviently see the reason that the peer is in Idle. PfxCt stands for Prefix Count.

R4#show bgp sum
<snip>
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.4.5.5        4        65002       0       0        1    0    0 00:00:41 Idle (PfxCt)

Let’s remove that fourth prefix from XR5.

XR5#
router bgp 65002
 address-family ipv4 unicast
  no network 5.5.5.8/32

Remember that the neighborship will not restart on its own. We must manually clear the session.

R4#
clear ip bgp 10.4.5.5

*Jul 14 03:07:08.235: %BGP-5-ADJCHANGE: neighbor 10.4.5.5 Up 
R4#
*Jul 14 03:07:13.259: %BGP-4-MAXPFX: Number of prefixes received from 10.4.5.5 (afi 0) reaches 3, max 3

Let’s change our maximum-prefixes setting on this peer to automatically restart after 60 seconds. See if you can figure out the command on your own before proceeding.

R4#
router bgp 65001
 neighbor 10.4.5.5 maximum-prefix 3 restart 1

R4#show bgp neighbors 10.4.5.5
<snip>
 For address family: IPv4 Unicast
<snip>
  Maximum prefixes allowed 3
  Threshold for warning message 75%, restart interval 1 min

Remember that the restart interval is in minutes! I kind of tricked you by giving you the value in seconds.

If we add the fourth prefix again on XR5, what will happen? The session will be brought down on R4, but after one minute, the session will restart again automatically. If we remove that fourth prefix in that period of time, the session should go Established on its own. Let’s try it out.

XR5#
router bgp 65002
 address-family ivp4 unicast
   network 5.5.5.8/32

R4#
*Jul 14 03:12:34.143: %BGP-3-MAXPFXEXCEED: Number of prefixes received from 10.4.5.5 (afi 0): 4 exceeds limit 3
*Jul 14 03:12:34.144: %BGP-3-NOTIFICATION: sent to neighbor 10.4.5.5 6/1 (Maximum Number of Prefixes Reached) 7 bytes 00010100 000003
R4#show bgp sum
<snip>
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.4.5.5        4        65002       0       0        1    0    0 00:00:00 Idle (PfxCt)

R4#
*Jul 14 03:12:34.144: %BGP-5-NBR_RESET: Neighbor 10.4.5.5 reset (Peer over prefix limit)
*Jul 14 03:12:34.146: %BGP-5-ADJCHANGE: neighbor 10.4.5.5 Down Peer over prefix limit
*Jul 14 03:12:34.146: %BGP_SESSION-5-ADJCHANGE: neighbor 10.4.5.5 IPv4 Unicast topology base removed from session  Peer over prefix limit

XR5#
router bgp 65002
 address-family ivp4 unicast
   no network 5.5.5.8/32

R4#
*Jul 14 03:13:40.517: %BGP-5-ADJCHANGE: neighbor 10.4.5.5 Up 
R4#
*Jul 14 03:13:45.542: %BGP-4-MAXPFX: Number of prefixes received from 10.4.5.5 (afi 0) reaches 3, max 3

The session went Established on its own this time, because we used the restart interval parameter.

Real world use

You probably wouldn’t want to set such a low max-prefix limit in the real world. This was obviously for demostration purposes. In the real world you would use this feature on your internet peers, limiting IPv4 counts to something like 1 million. You might also limit your L3VPN customers to something like 10,000, so they don’t accidentally send you a full table.

IOS-XR Differences

IOS-XR has one additional configuration parameter option, which is discard-extra-paths. This is sort of a compromise between warning-only, which will still accept all routes (even past the maximum), and the default action, which will reset the neighborship completely. With discard-extra-paths, the session stays up as normal, but the router drops any additional paths over the maximum count.

IOS-XR also has maxium prefix automatically enabled on all BGP peers (iBGP and eBGP). Each address family has a different maximum prefixes default count:

AFI

Count

IPv4 Unicast

1048576

IPv6 Unicast

524288

IPv4 and IPv6 Multicast

131072

VPNv4 Unicast

2097152

VPNv6 Unicast

1048576

We can see this default in place on XR5 right now, because we have not set any maximum-prefixes on XR5 for its peer, R4.

RP/0/0/CPU0:XR5#show bgp ipv4 unicast neighbors 10.4.5.4 
Thu Jul 14 03:32:33.944 UTC
<snip>
For Address Family: IPv4 Unicast
  
  Threshold for warning message 75%, restart interval 0 min
PreviousBGP MD5 AuthenticationNextBGP RFD (Route Flap Dampening)

Last updated 2 years ago