3.12.8 Providers and Peers configuration

Providers can be added and modified via “Configuration → Providers”.

Figure 3.12.24: Configuration editor: Providers configuration

The sections below describe the most common groups of provider configuration parameters. Some parameters are repeated on more than one of these groups for convenience.

3.12.8.1 Providers configuration #

• General settings: #

  →  Provider name (peer.X.shortname)
  →  Router (peer.X.bgp_peer)
  →  Provider description (peer.X.description)
  →  Provider’s routing domain (peer.X.rd)
  →  Maximum load per interface (peer.X.limit_load)
  →  Flow agents (peer.X.flow_agents)
  →  Circuit issues detection (peer.X.circuit.control) indicating how IRP should react to excessive persistent loss over a particular provider.
  →  Use of BMP data (BMP monitoring station settings)

Figure 3.12.25: Configuration editor: Adding a new provider, General settings

• IPv4 / IPv6 settings: #

  →  IPv4 / IPv6 diagnostic hops (peer.X.ipv4.diag_hop, peer.X.ipv6.diag_hop)
  →  Probing IPv4 / IPv6 address (peer.X.ipv4.master_probing, peer.X.ipv6.master_probing)
  →  Remote provider ASN (peer.X.ipv4.next_hop_as), used by the AS-Path restoration algorithm (bgpd.as_path)
  →  Router next-hop address (peer.X.ipv4.next_hop), that sets the next-hop value for injected routes related to this provider
  →  Provider’s alternative IPv4 address for PBR tests (peer.X.ipv4_pbr_check)

Figure 3.12.26: Configuration editor: Adding a new provider, IPv4 / IPv6 settings

• Commit Control configuration: #

  →  Provider cost per Mbps (peer.X.cost)
  →  Provider 95th percentile (peer.X.95th)
  →  Provider inbound 95th percentile (peer.X.95th.in)
  →  Provider 95th calculation mode for inbound traffic
  →  Provider billing day (peer.X.95th.bill_day)
  →  Commit Control status for this provider (peer.X.cc_disable)
  →  CC provider precedence – used for Commit Control and grouping (peer.X.precedence)
  →  Centile value (peer.X.95th.centile)
  →  Performance/Cost improvements within provider group toggle in case the peer load balancing is configured, (peer.X.improve_in_group, peer.X.precedence)

Figure 3.12.27: Configuration editor: Adding a new provider, Commit Control

• SNMP-related settings: #

Figure 3.12.28: Configuration editor: Adding a new provider, SNMP settings

• External Monitor settings: #

  →  External monitor status toggles for IPv4 / IPv6 (peer.X.mon.ipv4.external.state, peer.X.mon.ipv6.external.state)
  →  ICMP/UDP ping monitored IPv4 / IPv6 addresses (peer.X.ipv4.mon, peer.X.ipv6.mon)

Figure 3.12.29: Configuration editor: Adding a new provider, External Monitor

• Internal Monitor settings: #

  →  Internal monitor status toggles for IPv4 / IPv6 (peer.X.mon.ipv4.internal.state, peer.X.mon.ipv6.internal.state)
  →  BGP session monitoring IPv4 / IPv6 addresses (peer.X.mon.ipv4.bgp_peer, peer.X.mon.ipv6.bgp_peer)
  →  BGP MIBs for IPv4 / IPv6 (peer.X.mon.ipv4.internal.mode, peer.X.mon.ipv6.internal.mode)
  →  SNMP host for BGP Internal Monitor (peer.X.mon.snmp)

Figure 3.12.30: Configuration editor: Adding a new provider, Internal Monitor

• SNMP v3 uses additional parameters depending on security services used for monitoring:

• Inbound: #

  →  Base community for inbound improvements (peer.X.inbound.community_base)
  Inbound optimization improvements advertise larger or smaller counts of prepends to be announced to different providers. IRP instances use BGP session to communicate to routers and relies on BGP communities to communicate the improvements. Each provider is assigned a base community which represents zero prepends. Additional prepends are represented by incrementing accordingly the right-side part of the provider’s community.
  IRP instances use 8 prepend levels. This means that base community should be chosen to allow additional 7 values without intersecting with other community values.

Figure 3.12.31: Configuration editor: Adding a new provider, Inbound

• Flowspec: #

  →  IPv4 / IPv6 Redirect community (peer.X.flowspec.ipv4.redirect_community and peer.X.flowspec.ipv6.redirect_community)

Figure 3.12.32: Configuration editor: Adding a new provider, Flowspec

• Blackholing: #

  →  Blackholing Routers
  →  Blackholing community

Figure 3.12.33: Provider Blackholing configuration details

3.12.8.2 Internet Exchanges configuration  #

It is recommended that Noction systems engineers guide you through Exchange configuration process.

IRP needs one ACL and one PBR rule for each Peering Partner on an Exchange. Internet Exchanges can have hundreds of Peering Partners. Ensure that the number of Access Lists, Access List entries and PBR entries will not exceed router hardware limitations.

• Once the Exchange is setup via GMI, an IRP instance will retrieve the routing table on the router in order to setup Exchange peering partners. IRP will require access to the router in order to do so.

When configuring an Exchange its Diag Hop parameter must be provided. Diag Hop for an Exchange represents the list of direct-connected networks configured on the router’s interface towards the Exchange network. This parameter is labeled “IPv4 diagnostic hop” on IRP Frontend.

• Probing IPs for Exchanges no longer require one IP address per peering partner since this number might be impractically big. Instead a combination of probing IP and DSCP value is used to configure the PBRs. A single probing IP in conjunction with DSCP can cover up to 64 peering partners. A sufficient number of probing IPs will be required in order to cover all peering partners on your exchange.

As a rule of thumb it is better to list the PBR rules for transit providers before the (large number of) rules for Internet Exchange peers. If the many PBR rules assigned to peers on a large Internet Exchange are placed at the beginning of the PBR list some routers evaluate all of them before finding the terms for transit providers and this consumes valuable router CPU resources.

Figure 3.12.34: An Internet Exchange is similar to a provider and it requires configuration of the Router, the Probing IPs and the other usual attributes

• Once the Exchange is configured, the IRP instance will need to reset its BGP session towards the router interconnecting with the Exchange in order to retrieve the required routing table information about all peering partners. Once the BGP session is restarted IRP instance will start fetching Exchange routing tables.

Allow sufficient time (~10 minutes) to fetch Exchange routing tables before continuing configuration.

• Peering partner autoconfiguration function is available. It retrieves the list of Next Hops (peering partners) on the Exchange with the corresponding list of prefixes individual peers accept.

Figure 3.12.35: The list of peering partners for the Exchange shows details about each of them and offers access to Autoconfiguration feature and PBR ruleset generator for the router

• Use the Autoconfiguration feature to create an initial configuration for an IRP instance. Review Exchange peering partners before starting the Exchange. Consider enabling periodic auto re-configurations for selected IX in order to update periodically the value of BGP session monitoring IPv4 address from the Exchange and to add new peering partners.
  Refer global.exchanges.auto_config_interval and peer.X.auto_config.

Keep in mind that Autoconfiguration might tamper with all the changes you’ve made directly within IRP instance config files for peering partners. So, use Autoconfiguration sparingly after you’ve applied manual changes or try avoiding direct configuration file changes altogether.

• Once the Exchange is configured correctly, you will need to apply the PBR rules on the router(s). There is a functionality to generate PBR rules for different router vendors. You will need to review the generated ruleset and apply it on the router manually.
• It is possible that the Autoconfiguration feature on the Exchange has been run with incomplete routing tables or that new peering partners have been connected. This is especially true for very big Exchanges. In this case it is possible that some peering partners are neither in IRP nor router configurations. When such a case is detected, a warning about newly discovered peering partners gets raised. At this stage you will need to both re-autoconfigure IRP instance and extract the PBRs for the router.
• After its creation and up to its complete configuration the Exchange is kept in a Stopped state. When both IRP and the Router PBRs are configured, particular IRP instance is ready to start optimizing Exchange traffic too. Keep in mind that starting the Exchange will require a BGP session restart.

We must mention that before applying changes to IRP instance configuration the changes are validated. If errors are detected these will be flagged and the previous good configuration will be kept intact so you will have the option to review the erroneous data and correct.

3.12.8.3 Switching a provider from one router to another #

1. Suspend the provider using GMI Frontend “Providers and Peers” particular IRP configuration section. IRP instance withdraws all existing and stops new improvements towards shutdown provider(s)
2. You can remove traffic from the provider (by denying incoming/outgoing announces in the BGP configuration) and then physically re-cable the provider from one router to another. Then configure BGP session towards the provider on new router
3. The PBR rule for the provider should be configured on new router (move provider’s PBR settings from the old router to the new one)
4. Change IRP box local PBR rules if any
5. Check if PBR works properly using traceroute tool
6. Modify (/etc/noction/irp.conf) assigned router for the provider (refer to peer.X.bgp_peer)
7. Modify (/etc/noction/irp.conf) SNMP interface/IP/community for the provider (refer to SNMP Host, peer.X.snmp.interfaces, peer.X.mon.snmp)
8. Reload Bgpd configuration (affected BGP sessions could be reset)
9. Re-activate the provider using GMI Frontend “Providers and Peers” IRP instance of choice configuration section
10. Check IRP BGP Internal and External monitor states. They must be UP.