HP A-Series (H3C) BGP configuration basic examples

As I finally had the opportunity to have a look at HP Networking (HPN) product lines with the basic BGP/MPLS configuration, I thought of creating a little summary of configuration on the A-Series that is formerly a H3C/3Com brand.

Basic BGP peering

Starting with the most basic config, let’s have a two peer neighbor created:

#Router A:
 bgp 100
  peer 220.1.1.2 as-number 101
#Router B:
 bgp 101
  peer 220.1.1.1 as-number 100

 

As you might figure out, this is not much flexible and as most of us like to do neighbors on loopback, this is how to do it (the ebgp-max-hop command is not needed for IBGP sessions):

#Router A:
 ip route-static 220.1.256.10 32 220.1.1.2
 ip route-static 220.1.256.10 32 220.1.1.6
 bgp 100
  peer 220.1.254.10 as-number 101
  peer 220.1.254.10 ebgp-max-hop 2
  peer 220.1.254.10 connect-interface loopback 0
#Router B:
 ip route-static 220.1.256.1 32 220.1.1.1
 ip route-static 220.1.256.1 32 220.1.1.5
 bgp 101
  peer 220.1.254.1 as-number 100
  peer 220.1.254.1 ebgp-max-hop 2
  peer 220.1.254.1 connect-interface loopback 0

 

 

Importing subnets to BGP process:

Fully dynamic import from IGP protocol

Simply using “import” command that is essentially the same as “redistribute” command in Cisco IOS CLI. As this command is different for every IGP protocol and quite easy to complete using the “?” functions. Just one example here importing OSPF to BGP with default settings

bgp 200
 import ospf

Semi-dynamic import using network statement

This is actually only using the “network” command to specify a subnet to be placed to the BGP database just as you know with Cisco. So the general story is that BGP process goes through the used active routes in the routing table and if it finds exactly the specified subnet, it places it to the BGP database and advertises. However, HPN likes to call this “semi-dynamic” import and devides it to two ways, I think you can spot the difference:

semi-dynamic import
 bgp 200
  network 18.0.0.0 8

static import
 ip static-route 18.0.0.0 255.0.0.0.0 1.2.3.4
 bgp 200
  network 18.0.0.0 8

As you correctly see this is nothing new to majority of readers, but wanted to mention the new “terminology” HPN uses.

Router ID

As usual, the Router ID is chosen as the highest IP on active loopbacks, if no loopbacks then the highest on active interfaces. But the most best way from my point of view is to configure it manually before the first session is configured (otherwise session restart is needed for the router-ID to take effect).

Route Filtering

HPN A-Series support 4 types of BGP route filter types and I must say this is basically the same as in Cisco just with different names:

• Based on ACL
• Based on IP Prefix
• Based on AS Path filtering
• Based on Routing Policy

Also the filters can be applied as OUTBOUND, INBOUND and during IMPORT from other protocol.

#ACL example:
 acl number 3000 name BGPFilter
  rule 10 deny ip source 10.0.0.0 0.255.255.255
  rule 20 permit ip
 bgp 200
  peer 1.2.3.4 filter-policy 3000

or you can also use ACLs to filter during redistribution:

bgp 200
 filter-policy 3000 [import|export]

#IP Prefix lists example:
 ip ip-prefix abc index 10 deny 10.1.0.0 16
 ip ip-prefix abc index 20 permit 0.0.0.0 0 less-equal 32
 bgp200
  peer 1.2.3.4 ip-prefix abc [export|import]

#AS-Patch filter example:
 as-path 1 permit .*200.*
 as-path 1 deny .*99$
 bgp 200
  peer 1.2.3.4 as-path-acl 1 [export|import]

Routing Policy Filtering

This one is a little more complex as this is essentially the same as when you create route-maps on Cisco. Routing policy is composed of one or more nodes, each node contains the “if-match clauses” and “apply rules”. Every node can be type “permit” or “deny”. If you wan the apply rules to be applied to a traffic, it must match the corresponding “permit” and not match any “deny” rule before reaching the expected “permit” rule.

Also inside a single node, all the if-match clauses are in the logical AND relationship.

So lets start with a little example we want a route-policy that filter all routes that come with tag of 5858, if a route matches as-path filter “1” and access-list “3000”, the local-preference of this route should be changed to 150 and all other routes should simply pass unmodified:

route-policy TestPolicy deny node 10
 if-match tag 5858
route-policy TestPolicy permit node 20
 if-match acl 3000
 if-match as-path 1
 apply local-preference 150
route-policy TestPolicy permit node 30

Then we can apply this route filter o a peer as

peer 1.2.3.4 route-policy TestPolicy [import|export]

Route Aggregation

BGP can carry a lot of routes/prefixes. This is fine to a certain point when you simply should consider making the routes a little more elegan and summarize. By default, both HPN and Cisco routers summarize to the network class boundary and on HPN, you can disable this by using

bgp 200
 undo summary automatic

But you can also use manual summary like this:

bgp 200
 aggregate 172.16.0.0 255.255.240.0

However, when you do it like this, the router sill send this aggregated route and also all the subnets, so no benefit to routing table size yet, but this can be usefull in some situations. To really supress all the smaller subnets, you have to extend this command to this.

bgp 200
 aggregate 172.16.0.0 255.255.240.0 detail-suppressed

Route Reflector

You might remember that BGP send to an IBGP peer only prefixes that is has from EBGP peers on not other IBGP peers. This rule means that the original intention was to have a full mesh of IBGP sessions inside a single AS. However this is not really scalable so well because then you have to have [n*(n-1)]/2 sessions established and you can calculate how many sessions that is for even a medium size network.

This is where something called Route Reflector (RR) come to play. RR removes the full mesh requirement by creating a router hierarchy and allows re-advertisment of IBGP routes to other IBGP peers. The RR and its clients are referenced as “cluster“.

One single RR in you network can enable you to have a logical star topology where all the IBGP sessions are simply only established to the RR and the BGP will function properly. However for redundancy, in many network more than one RR exists either in a single cluster (then all RRs in one cluster must be configured with the same CLUSTER_ID) or multiple RR clusters in a single network (a unique CLUSTER_ID must be configured for every cluster). Also the rule is that when you have multiple RRs in a single cluster, all clients must have a session to all the RRs in that cluster.

To avoid creating loops, BGP came with a similar logic similar to avoiding routing loops with AS-Path, but using the CLUSTER_ID. The rules is simple.

First when the prefix enters an AS, first RR that gets this prefix puts it’s CLUSTER_ID to the field called ORIGINATOR_ID. Rule is that RR will never send a route back to the router specified in the ORIGINATOR_ID.

Second every route carries a CLUSTER_LIST that is a sequence of CLUSTER_IDs via which the route was mirrored inside a single AS with RRs. Rule is that RR discards a route if it see it’s CLUSTER_ID already on the CLUSTER_LIST.

Configuration example:

To make an RR, you should configure all it’s peers as “reflect-client”, no configuration is done on the clients inside a cluster.

reflect between-clients
 reflector cluster-id 11.22.33.44
 bgp 200
 peer 1.2.3.4 reflect-client

Confederation

Alternative solution to the scalability issue to RR is to create a confederation that is a group of smaller locally hidden EBGP AS systems inside a public unigue AS system. This issue is a little complex to put into a single paregraph, but this is an example how to configure confederation on HPN. In this example we have a big AS 200 that we want to scale down to three smaller AS 65535/65536/65537 and still appear as AS200 to the outside world.

bgp 65535
 confederation id 200
 confederation peer-as 65536 65537

then if you designate a peer as either 655536 or 65537, it will use EBGP logic despite it is part of a global 200 AS.

 peer 1.2.3.4 as-number 65536
 peer 5.6.7.8 as-number 65535
 peer 9.10.11.12 as-number 100

Peer 1.2.3.4 will be a simulated EBGP between confederation AS, peer 5.6.7.8 is IBGP inside confederation AS and peer 9.10.11.12 is public EBGP session towards which all confederation AS numbers will be replaced by the AS 200 in both peering and all route AS-Patch attributes.

Route dampening

Then a route becomes unstable, ergo it is being distributed/withdrawn/distributed/withdrawn continuously, it is a good idea to suppress this route for a time period until it becomes stable again.

In essence, whenever a route flaps, it gets a penalty of 1000 points. You can configure dampening to manage how quickly these points will get lower and at what thresholds to re-use and suppress the route.  The points get lower with logarithmic scale as shown on the graph below so what you configure is after how many minutes the penalty points should get to half to original value.

In the following example we configure the dampening to some basic values, the command “?” provides explanation better than I could:

[H3C-bgp]dampening ?
 INTEGER<1-45>  Half-life time (in minutes) for the penalty when reachable

[H3C-bgp]dampening 15 ?
 INTEGER<1-45>  Half-life time (in minutes) for the penalty when unreachable

[H3C-bgp]dampening 15 15 ?
 INTEGER<1-20000>  Value to start reusing a route

[H3C-bgp]dampening 15 15 1000 ?
 INTEGER<1-20000>  Value to start suppressing a route

[H3C-bgp]dampening 15 15 1000 2000 ?
 INTEGER<1001-20000>  Ceiling of the penalty

[H3C-bgp]dampening 15 15 1000 2000 10000

Summary

Basic BGP is identicall to nearly any networking product I worked with including Cisco/Alcatel/Mikrotik and now as you might have notices also HPN A-Series (or H3C).
I really hope you enjoyed this quick overview. Next in line I have BGP with MPLS L3 VPNs on HPN devices.