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.127.116.11 as-number 101 #Router B: bgp 101 peer 18.104.22.168 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 22.214.171.124 ip route-static 220.1.256.10 32 126.96.36.199 bgp 100 peer 188.8.131.52 as-number 101 peer 184.108.40.206 ebgp-max-hop 2 peer 220.127.116.11 connect-interface loopback 0 #Router B: ip route-static 220.1.256.1 32 18.104.22.168 ip route-static 220.1.256.1 32 22.214.171.124 bgp 101 peer 126.96.36.199 as-number 100 peer 188.8.131.52 ebgp-max-hop 2 peer 184.108.40.206 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 220.127.116.11 8
static import ip static-route 18.104.22.168 255.0.0.0.0 22.214.171.124 bgp 200 network 126.96.36.199 8
As you correctly see this is nothing new to majority of readers, but wanted to mention the new “terminology” HPN uses.
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).
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 188.8.131.52 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 184.108.40.206 ip-prefix abc [export|import]
#AS-Patch filter example: as-path 1 permit .*200.* as-path 1 deny .*99$ bgp 200 peer 220.127.116.11 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 18.104.22.168 route-policy TestPolicy [import|export]
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
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.
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 22.214.171.124 bgp 200 peer 126.96.36.199 reflect-client
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 188.8.131.52 as-number 65536 peer 184.108.40.206 as-number 65535 peer 220.127.116.11 as-number 100
Peer 18.104.22.168 will be a simulated EBGP between confederation AS, peer 22.214.171.124 is IBGP inside confederation AS and peer 126.96.36.199 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.
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
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.