Scribd Logo
Upload

Welcome to Scribd!

  • 91 views

    BGP Peer Templates

    Uploaded by

    Ivan Machuza
    This document discusses BGP peer templates, which were introduced by Cisco to simplify the configuration of BGP neighbors that share similar routing policies. Peer templates allow administrators to define reusable blocks of configuration (templates) and inherit settings from one template to another to avoid redundancy. This provides a more flexible and hierarchical approach to peer configuration compared to traditional peer groups. The document provides an example configuration that demonstrates how templates can be defined and inherited to efficiently configure multiple neighbors.

    Copyright:

    © All Rights Reserved
    Download as DOCX, PDF, TXT or read online from Scribd

    BGP Peer Templates

    Uploaded by

    Ivan Machuza
    91 views11 pages
    This document discusses BGP peer templates, which were introduced by Cisco to simplify the configuration of BGP neighbors that share similar routing policies. Peer templates allow administrators to define reusable blocks of configuration (templates) and inherit settings from one template to another to avoid redundancy. This provides a more flexible and hierarchical approach to peer configuration compared to traditional peer groups. The document provides an example configuration that demonstrates how templates can be defined and inherited to efficiently configure multiple neighbors.

    Original Title

    BGP peer templates

    Copyright

    © © All Rights Reserved

    Available Formats

    DOCX, PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    This document discusses BGP peer templates, which were introduced by Cisco to simplify the configuration of BGP neighbors that share similar routing policies. Peer templates allow administrators to define reusable blocks of configuration (templates) and inherit settings from one template to another to avoid redundancy. This provides a more flexible and hierarchical approach to peer configuration compared to traditional peer groups. The document provides an example configuration that demonstrates how templates can be defined and inherited to efficiently configure multiple neighbors.

    Copyright:

    © All Rights Reserved
    Download as DOCX, PDF, TXT or read online from Scribd
    Download as docx, pdf, or txt
    91 views11 pages

    BGP Peer Templates

    Uploaded by

    Ivan Machuza
    This document discusses BGP peer templates, which were introduced by Cisco to simplify the configuration of BGP neighbors that share similar routing policies. Peer templates allow administrators to define reusable blocks of configuration (templates) and inherit settings from one template to another to avoid redundancy. This provides a more flexible and hierarchical approach to peer configuration compared to traditional peer groups. The document provides an example configuration that demonstrates how templates can be defined and inherited to efficiently configure multiple neighbors.

    Copyright:

    © All Rights Reserved
    Download as DOCX, PDF, TXT or read online from Scribd
    Download as docx, pdf, or txt
    of 11

    BGP peer templates

    When Cisco introduced peer groups for BGP neighbors, their intention was to associate
    neighbors which shared routing policies in an effort to optimize CPU utilization. A side
    effect of peer-group configuration is reduced syntax. For example, consider the
    following verbose configuration:

    neighbor 192.168.0.1 remote-as 100


    neighbor 192.168.0.1 ttl-security hops 1
    neighbor 192.168.0.1 timers 30 300
    neighbor 192.168.0.2 remote-as 100
    neighbor 192.168.0.2 ttl-security hops 1
    neighbor 192.168.0.2 timers 30 300
    neighbor 192.168.0.3 remote-as 100
    neighbor 192.168.0.3 ttl-security hops 1
    neighbor 192.168.0.3 timers 30 300
    neighbor 192.168.0.4 remote-as 100
    neighbor 192.168.0.4 ttl-security hops 1
    neighbor 192.168.0.4 timers 30 300

    These twelve lines become only eight after implementing a peer group, removing much
    redundancy from the original configuration:

    neighbor MyGroup peer-group


    neighbor MyGroup remote-as 100
    neighbor MyGroup ttl-security hops 1
    neighbor MyGroup timers 30 300
    neighbor 192.168.0.1 peer-group MyGroup
    neighbor 192.168.0.2 peer-group MyGroup
    neighbor 192.168.0.3 peer-group MyGroup
    neighbor 192.168.0.4 peer-group MyGroup

    Unfortunately, because simplified syntax was never the primary goal of peer groups,
    they can still be rather unwieldy when attempting to configure neighbors with similar, but
    not identical, routing policies.

    In IOS 12.0(24)S, Cisco introduced dynamic update peer groups, a feature which


    essentially enables the software to automatically group BGP neighbors into peer groups
    and generate update messages accordingly. Although this new feature effectively
    obsoleted manually defined peer groups, they have stuck around as many
    administrators appreciate the convenience they offer in configuration.

    Around the same time dynamic update peer groups were introduced, Cisco also
    debuted BGP peer templates. With the burden of CPU optimization delegated to
    dynamic update peer groups, peer templates introduced a much more flexible,
    hierarchical peer configuration scheme. There are two types of peer templates: session
    templates and policy templates.

    Session templates affect the actual BGP session with a neighboring router, whereas
    policy templates affect protocol-specific (NLRI) policy (e.g. IPv4 versus IPv6). The
    following table lists which parameters are defined in each type of template (as of IOS
    12.4T):

    Session Templates Policy Templates


     advertisement-
    interval
     allowas-in
     allowas-in  as-override
     description  capability
     disable-connected-  default-originate
    check  distribute-list
     ebgp-multihop  dmzlink-bw
     fall-over  filter-list
     local-as  maximum-prefix
     password  next-hop-self
     remote-as  next-hop-unchanged
     shutdown  prefix-list
     timers  remove-private-as
     translate-update  route-map
     transport  route-reflector-client
     ttl-security  send-community
     update-source  send-label
     version  soft-reconfiguration
     soo
     unsuppress-map
     weight
    To illustrate how peer templates work, consider the following peer group configuration:

    router bgp 65200


    no synchronization
    bgp router-id 10.0.0.3
    bgp log-neighbor-changes
    neighbor IBGP-Peers peer-group
    neighbor IBGP-Peers remote-as 65200
    neighbor IBGP-Peers timers 30 300
    neighbor EBGP-Peers peer-group
    neighbor EBGP-Peers ttl-security hops 1
    neighbor EBGP-Peers timers 30 300
    neighbor 10.0.1.1 remote-as 65101
    neighbor 10.0.1.1 peer-group EBGP-Peers
    neighbor 10.0.1.2 remote-as 65102
    neighbor 10.0.1.2 peer-group EBGP-Peers
    neighbor 10.0.2.4 peer-group IBGP-Peers
    neighbor 10.0.2.5 peer-group IBGP-Peers
    no auto-summary

    Two peer groups have been created: one for IBGP neighbors, and one for EBGP
    neighbors. Each group defines some unique session characteristics, but they both also
    have one in common (the BGP timers configuration). Because of the way peer groups
    work (again, they were originally intended only for CPU optimization), common
    attributes must be replicated across peer groups, introducing redundancy in the
    configuration.

    Peer templates embrace a hierarchical approach to combat such redundancy. We can


    create one template for session parameters common to all BGP neighbors, and then
    create more-specific templates which inherit those parameters. Templates are created
    under the BGP routing process:

    R3(config)# router bgp 65200


    R3(config-router)# template ?
    peer-policy Template configuration for policy parameters
    peer-session Template configuration for session parameters

    R3(config-router)# template peer-session BGP-All


    R3(config-router-stmp)# timers 30 300
    R3(config-router-stmp)# exit-peer-session
    R3(config-router)#

    The BGP-All template holds the timers configuration line we want to apply to all peers.


    Next we'll create separate IBGP and EBGP templates, both of which will inherit
    parameters from the BGP-All template using the inherit peer-session command.

    The completed configuration looks like this:

    router bgp 65200


    template peer-session BGP-All
    timers 30 300
    exit-peer-session
    !
    template peer-session IBGP
    remote-as 65200
    inherit peer-session BGP-All
    exit-peer-session
    !
    template peer-session EBGP
    ttl-security hops 1
    inherit peer-session BGP-All
    exit-peer-session
    !
    no synchronization
    bgp router-id 10.0.0.3
    bgp log-neighbor-changes
    neighbor 10.0.1.1 remote-as 65101
    neighbor 10.0.1.1 inherit peer-session EBGP
    neighbor 10.0.1.2 remote-as 65102
    neighbor 10.0.1.2 inherit peer-session EBGP
    neighbor 10.0.2.4 inherit peer-session IBGP
    neighbor 10.0.2.5 inherit peer-session IBGP
    no auto-summary

    Admittedly, with only four neighbors and only two significant classifications (EBGP and IBGP), the
    improvement might not seem all that drastic. But consider the efficiency afforded when configuring
    dozens of BGP peers in a similar matter.

    The above example demonstrates peer session templates at work. As you might have guessed,
    peer policytemplates work very similarly:

    R3(config-router)# template peer-policy BGP-All


    R3(config-router-ptmp)# prefix-list DENY-MARTIANS in
    R3(config-router-ptmp)# exit-peer-policy
    R3(config-router)# neighbor 10.0.1.1 inherit peer-policy BGP-All

    Policy template inheritance works the same way, but with the inherit peer-
    policy command.

    Finally, the show ip bgp template command can be used to verify template


    inheritance:
    R3# show ip bgp template peer-session
    Template:BGP-All, index:1
    Local policies:0x20, Inherited polices:0x0
    *Inherited by Template IBGP, index= 2
    *Inherited by Template EBGP, index= 3
    Locally configured session commands:
    timers 30 300
    Inherited session commands:

    Template:IBGP, index:2
    Local policies:0x1, Inherited polices:0x20
    This template inherits:
    BGP-All index:1 flags:0x0
    Locally configured session commands:
    remote-as 65200
    Inherited session commands:
    timers 30 300

    Template:EBGP, index:3
    Local policies:0x800, Inherited polices:0x20
    This template inherits:
    BGP-All index:1 flags:0x0
    Locally configured session commands:
    ttl-security hops 1
    Inherited session commands:
    timers 30 300

    R3# show ip bgp template peer-policy


    Template:BGP-All, index:1.
    Local policies:0x40, Inherited polices:0x0
    Locally configured policies:
    prefix-list DENY-MARTIANS in
    Inherited policies:
    BGP – Peer Templates

    Some networks have a lot of BGP neighbors. This may sound like a service provider
    problem, but it affects the enterprise as well. Think of the newer data center
    technologies that use a spine/leaf topology. These include VxLAN/EVPN
    and Fabricpath. Each point-to-point network in the topology has a BGP neighbor
    relationship configured. This can result in a lot of neighbor configuration.

    The way to improve on this is to group neighbors together. There are three ways to
    group neighbors:

    1. Peer-Groups
    2. Dynamic Update Peer-Groups
    3. Peer-Templates 

    Peer-groups were the original solution. Although designed to lower CPU usage,


    reduced configuration was an added bonus. Unfortunately, this wasn’t very effective at
    creating neighbor groups. The configuration was often similar, but not identical.

    Dynamic-Update Peer-Groups improved on this idea. The router would see neighbors


    that were similar and group them. This saved resources as the neighbors would share
    BGP update messages. This is great, but the purpose is to save resources, and does
    not help with simplifying BGP config.

    The good news is that peer-templates are here to save the day! They were designed
    with config reduction in mind. A template is a block of reusable configuration. One
    template can inherit settings from another template. This solves the issue of having
    neighbors with similar config. Each peer can have one template assigned. Template
    inheritance creates a hierarchy of settings. If there is a need to vary from the template
    hierarchy, use manual configuration. Manual settings always override template settings.

    Templates may not decrease the number of lines of config. It depends on how complex
    the environment it. Even so, they can help improve the structure of the configuration. 

    There are two types of peer template:

     Session Template – Controls neighbor settings, such as TTL security, timers and
    so on
     Policy Template – Controls address family settings

    Configuration

    To see templates in action, we’re going to create a lab. Take a look at the topology
    below. There is a core router, which needs to peer with five different routers. For
    simplicity, all routers are in the same Autonomous System (65535).

    R1, R2, and R3 are ‘Service Provider-1’ routers. Routers R4 and R5 belong to ‘Service
    Provider-2’. These descriptions should be added to the neighbor config. Service
    provider 1 uses 10/30s timers, while Service provider 2 uses 20/60s timers.

    Each peer needs:

     Remote-as
     Local-as
     Description
     Timers

    To keep the lab below simple, the routers are pre-configured, and the core router needs
    to be configured. The core router already has its interfaces configured.
     Without Peer-Templates

    Let’s take a look at how this would be configured without templates. 

    Without a Peer Template


    router bgp 65000
    neighbor 10.10.10.2 remote-as 65535
    neighbor 10.10.10.2 local-as 65535
    neighbor 10.10.10.2 description Provider-1
    neighbor 10.10.10.2 timers 10 30
    neighbor 10.10.20.2 remote-as 65535
    neighbor 10.10.20.2 local-as 65535
    neighbor 10.10.20.2 description Provider-1
    neighbor 10.10.20.2 timers 10 30
    neighbor 10.10.30.2 remote-as 65535
    neighbor 10.10.30.2 local-as 65535
    neighbor 10.10.30.2 description Provider-1
    neighbor 10.10.30.2 timers 10 30
    neighbor 10.10.40.2 remote-as 65535
    neighbor 10.10.40.2 local-as 65535
    neighbor 10.10.40.2 description Provider-2
    neighbor 10.10.40.2 timers 20 60
    neighbor 10.10.50.2 remote-as 65535
    neighbor 10.10.50.2 local-as 65535
    neighbor 10.10.50.2 description Provider-2
    neighbor 10.10.50.2 timers 20 60
     

    With Peer-Templates

    The config has a better structure with a peer-template for all the common features.

    With a Peer-Template
    Core#sh run | sec router
    router bgp 65000
    template peer-session MyTemplate
    remote-as 65535
    local-as 65535
    exit-peer-session
    !
    bgp log-neighbor-changes
    neighbor 10.10.10.2 inherit peer-session MyTemplate
    neighbor 10.10.10.2 description Provider-1
    neighbor 10.10.10.2 timers 10 30
    neighbor 10.10.20.2 inherit peer-session MyTemplate
    neighbor 10.10.20.2 description Provider-1
    neighbor 10.10.20.2 timers 10 30
    neighbor 10.10.30.2 inherit peer-session MyTemplate
    neighbor 10.10.30.2 description Provider-1
    neighbor 10.10.30.2 timers 10 30
    neighbor 10.10.40.2 inherit peer-session MyTemplate
    neighbor 10.10.40.2 description Provider-2
    neighbor 10.10.40.2 timers 20 60
    neighbor 10.10.50.2 inherit peer-session MyTemplate
    neighbor 10.10.50.2 description Provider-2
    neighbor 10.10.50.2 timers 20 60
     

    Inheritance

    The structure is improved further by adding inheritable templates. In the case below,
    there are now three templates:

     My Template – Settings common to all neighbors


     Provider-1 – Setting common to Service Provider 1. This inherits the settings
    from My Template
     Provider-2 – Setting common to Service Provider 2. This inherits the settings
    from My Template. 

    As you can see, this doesn’t always decrease the number of lines of config. It does
    make things more structured and orderly. 

    Template Inheritance

    Core#sh run | sec router


    router bgp 65000
    template peer-session MyTemplate
    remote-as 65535
    local-as 65535
    exit-peer-session
    !
    template peer-session Provider-1
    description Provider-1
    timers 10 30
    inherit peer-session MyTemplate
    exit-peer-session
    !
    template peer-session Provider-2
    description Provider-2
    timers 20 60
    inherit peer-session MyTemplate
    exit-peer-session
    !
    bgp log-neighbor-changes
    neighbor 10.10.10.2 inherit peer-session Provider-1
    neighbor 10.10.20.2 inherit peer-session Provider-1
    neighbor 10.10.30.2 inherit peer-session Provider-1
    neighbor 10.10.40.2 inherit peer-session Provider-2
    neighbor 10.10.50.2 inherit peer-session Provider-2

    You might also like