BGP network summary II

  1. When generate summarized route, if AS_PATH in all subnets routes are the same, the summarized route will keep the same AS_PATH,
    if subnet routes have different AS_PATH, in generated summarized route AS_PATH will be set as noll.
    In order to keep AS_PATH track in summarized route, AS_SET option can be used in the command:
    aggregate-address summary-only as-set
  2. BGP will select the best route to advertise to the peer. it follows the best route selection policy here:
    Local preference > AS_PATH > lowest Orignal code >the lowest multi-exit discriminator > eBGP route over iBGP > IGP metric to the BGP next hop > lowest router ID.

    First of all, routes need to be the valid route before it is qualified to best route selection. A valid route means that Router has route path towards the ip of NEXT_HOP

  3. eBGP will update NEXT_HOP will advertise the route to the peer, but iBGP will keep NEXT_HOP unchange. NEXT_HOP can be modified with command
    neighbor next-hop-self
  4. Back door, if network is learned from both eBGP and OSPF, since eBGP has lower AD, route learned from eBGP will be selected. This is not alway prefered. In that case,we can set backdoor as below
    network backdoor

    Network is treated as a local entry, but is not advertised as a normal network entry.  After this, will use the route learned from OSPF instead of eBGP.

  5. synchronization is enabled by default in order to avoid blackhole in the network.
    it pretends a learned routes from being advertised to other peers if the same route cannot be learned from IGP route.
    There are 2 ways to solve blackhole problem:
    1, synchronization and redistribute all eBGP learned route into IGP route. While synchronizaton pretends a learned routes from being advertised to other peers if the same route cannot be learned from IGP route.
    2, configure iBGP on each router of the network and all iBGP routers build a full mesh peer network.
    This will bring high performance load if the network is too big and each router need run iBGP to maintain a big routing table. This problem is addressed by two ways: Confederation and reflectors.
  6.  Default route

The default-information originate, redistribution from a different source, and network are all similar in the resulting effect: they will inject the default route into BGP RIB and it will be advertised to all BGP neighbors. The difference is in the origin of the default route that is injected into BGP:

  • default-information originate causes the default route to be artificially generated and injected into the BGP RIB, regardlessly of whether it is present in the routing table.
  • Redistribution and network will inject the default route into BGP only if the default route is currently present in the routing table, and additionally in the case of redistribution, if learned by a specific source protocol we are redistributing from.

The neighbor X.X.X.X default-originate is different in that the default route will be advertised only to this specific BGP neighbor and not to all existing BGP neighbors as with the previous approaches. The default route will not be present in the BGP RIB of the router that is configured with the neighbor X.X.X.X default-originate command and so it won’t be generally advertised to all BGP neighbors. At the same time, this command is similar to the default-information originate in that the default route is artificially generated and does not need to be present in the routing table.

BGP network summary

When auto summary enabled:

  •  route advitised by network command, both summarized route and subnet route will be advitised
    1, network command without net mask will be regarded as classified network, summariezed network route will be generated and send to peer,will be matched when there is a subnet route entry in the routing table.
    2, network command with net mask will be matched when there is a subnet route entry in the routing table.
  •  route advertised by redistribute, only summarized route will be advitised. no subnet route entry.

When auto summary disabled:

  • network command with net mask configured need to be used to match route entry in routing table, matching will be precisely for both prefix and network. Only the route that precisely matchs the network command will be advertised
  • redistribute route will following the same rule as network command

Use aggregate command to manually generate a summary net route:

Aggregate command can be used to manually advertise a summary net, when there is ‘summary-only’ configured, then only the summarized net route will be advertised, not any subnet route. But in order to be able to generate aggregate-address, there must be at least one subnet route available in the routing table.

  aggregate-address xx.0.0.0 summary-only

MAC address learning problem in Juniper EX switch

Juniper EX switche has one port configured as trunked ports, when there are two many mac address learned from that port,
some of mac address may failed to be learned by the port. This is due to hash index collision that can be fixed by changing the value
of mac-lookup-length

In case you are encoutering the problem that
1, eth port of the host failed to work, and that host is connecting to a switch trunk port via hub/vmware platform,
2, switch port is showing up/up
3, switch port has learned massive mac address from that port, and a lot of learned mac addresses from different vlans are exactly identical

You should consider this may be hash index collision problem that has been reported by Juniper as PR842439. ”

For EX3200, EX4200, EX4500, EX4550, EX6200 and EX8200 Series switches, hash index collisions were causing problems with the learning of MAC addresses in the forwarding database (FDB). You can now increase the maximum number of searchable hash indexes in increments of 4, from 4 to a maximum of 32 entries, using the CLI command "set ethernet-switching-options mac-lookup-length".

By checking it, you may use command
> show system statistics bridge | match “learning failures”
the real problems occur in a repeated Learn log followed immediately by a Deleted log in the mac-learning log:
> show ethernet-switching mac-learning-log

Solution is indicated as the link below:

To summarize:
change mac-lookup-length to a number (8 or 12) higher than default 4

Useful F5 commands

1, When copy configuration from one unit to the other unit, or creating a lot of vips at the same time, it would be easier to do it via CLI:
a) Edit the configuration on editor
b) Copy and paste the configuration throught F5 cli terminal
user@(xxx)(cfg-sync In Sync)(/S1-green-P:Active)(/partition)(tmos)# load sys config from-terminal merge
Enter configuration. Press CTRL-D to submit or CTRL-C to cancel.

2, ssldump for trouble ssl session
a) use find to find the path of keyfile
[user@xxx:/S1-green-P:Active:In Sync] / # find -iname *.key*
for example
b) ssldump -A -d -k <key file> -n -i <capture VLAN> <traffic expression>
-A Print all fields
-d Show application data when private key is provided via -k
-k Private key file, found in /config/ssl/ssl.key/; the key file can be located under client SSL profile
-n Do not try to resolve PTR records for IP addresses
-i The capture VLAN name is the ingres VLAN for the TLS traffic
For example:
[user@xxx:/S1-green-P:Active:Changes Pending] / # ssldump -A -k ./config/filestore/files_d/partition_d/certificate_key_d/ -i 0.0 host and port 443

3, Use command biptop on cli to check all currenct connections
For example:
[user@xxx:/S1-green-P:Active:In Sync] ~ # bigtop
QUERYING… | bits since | bits in prior | current
| Mar 4 00:16:03 | 0 seconds | time
BIG-IP ACTIVE |—In—-Out—Conn-|—In—-Out—Conn-| 14:28:57 691.0T 1.418P 8.543G 0 0 0

VIRTUAL ip:port |—In—-Out—Conn-|—In—-Out—Conn-|-Nodes Up–
/partition/ 668.2T 213.5T 704.4M 0 0 0 0

4, You can use the openssl command to verify the client certificate against the Trusted Certificate Authority bundle prior to importing it onto the BIG-IP system. For example, the following openssl command verifies the client certificate, client.crt, against the Trusted Certificate Authority bundle:

openssl verify -purpose sslclient -CAfile /path/to/trusted-ca-bundle.crt /path/to/client.crt

If the chain of trust can be established for the server certificate using the specified chain, the command returns output similar to the following example:

client.crt: OK
5, Use tcpdump to show more tmm information,
for example, to check routed vip:
tcpdump -vs0 -i 0.0:nnn host
it shows below, the red part showed routed vip when received request from client.
16:28:44.474154 IP (tos 0x0, ttl 255, id 37043, offset 0, flags [DF], proto: TCP (6), length: 52) vip.http > host.38934: ., cksum 0x4282 (incorrect (-> 0x8e1f), ack 159 win 4297 <nop,nop,timestamp 913578425 3245706819> out slot1/tmm2 lis=/partition/xxxhttp-vip flowtype=64 flowid=5701C0361D00 peerid=5

Fundentimental of BGP

Find neighbour:

1, From idle to active: router will initiate tcp connection first via port 169.
2, From active to connected: router finished 3way handshake of TCP. If no 3 way handshake finished, router will go back to step 169
3, From connected to open send: router will send hello packets in order to find neighbour
4, From open send to open confirm: received reply from peer for open send message
5, Established: received KEEP ALIVE from peer

Advertise networks:

BGP can advertise networks to peer in the ways as below:
1, Use redistribute method to redistribute routes from other routing protocal into BGP. Route will only be redistributed if it is in the routing table
2, Use network command to advertise routes into BGP. Router will first check if the route existed in the routing table, if not, network can not be advertised, also using network command to advertize route need match exactly (prefix, mask) the route in the routing table. But if auto summary enabled, network command advertised route does not have to match exactly the route prefix/mast in the routing table, if at least one subnet existed in the routing table, network command can successfully advertize the whole network into BGP peer.
3, When autosummary used, BGP will advertize only classful route for all locally originated routes. If the redistributed routes are not classful network, BGP will use the mostly matched classful network and then advertise it. The same to network command advertised routes.


There are several ways that BGP use to filter the routes that will be advertised to the peer:
1, Filter-list with AS PATH access-list. use route map
2, prefix list filter
3, distribution list, not very scalable solution, not recommend when there is much ip range for filering
4, no export community

route map is mostly used and recommended for BGP filter


Community can be used to mark the advertised/received routes, so this routes can be treated in desired way (increase preference, etc)
There are 3 common community for BGP:
no export: routes will not be advertised outside of the local AS
no advertise: route will not be advertised to any iBGP or EBGP peer
local AS: The local AS community is a well known BGP community and can be used for BGP confederations. It’s basically the same as the no export community but this one works for within the sub-AS of a confederation

Notice in configuration

1, BGP x, x should match ASN number, or sub AS number if confederation is used

Uplinkfast & backbonefast

Both uplinkfast and backbonefast are features for classic spanning tree, not for rstp.

1, uplink fast should be applied on the switch, not on the interface
2, uplink fast will bring blocked port into forwarding immediately when it meets 2 conditions :
a) root port has lost connection from peer side
b) there is blocked port in this switch that lost root port
3, without uplink fast, when switch lost root port, the blocked port will have to go through listening (15 secs) and learning (15 secs) period before going to forwarding state; with uplink fast enabled, switch will save 30 secs to move blocked port into forwarding state.

Backbone fast
1, backbone fast is used to speed up recovering for INDIRECTED LINK FAILURE. Indirected link failure means that switch has received TCN from peer switch A because switch A has lost root port (link towards root bridge failed).
2,  Assume that port A on switch has received inferior BPDUs from peer switch A, it will ignore this BPDU because it is inferior BPDUs, instead it will continue waiting for root bridge BPDUs from peer switch A until max-age (20 secs by default) timed out. After that port A can go to listening and learning period.
3, With backbone fast enabled, As soon as switch receives an inferior BPDU it will send a root link query on its root port and non-designated ports to check if the root bridge is still available. Thus it will save 20 secs for recovery
4, Backbone fast is a global command, can not be configured in interface level.

Spanning tree loop guard

Spanning tree loop guard feature says that when a switch is sending but not receiving BPDUs on the interface, LoopGuard will place the interface in the loop-inconsistent state and block all traffic.

Sometimes this description may be confusing because we know that in classic spanning tree, only root bridge can generate BPDUs and the other bridge can only relay these BPDUs, in another words, root ports and blocked ports will not send BPDUs. Blocked ports will not send BPDUs in rapid spanning tree neither, although in RSTP all bridges will generate and send its own BPDU to peer switches via designated or root port.

To understand this we must realize during spanning tree convergence period ‘root bridge, selection, root port selection, etc’, each switch DOES send out and receive BPDUs from peer side. Therefore loop-guard will be in action during convergence period. In some cases convergence does not necessarily need reselect root bridge or root port on the switch, but it is convergence process on this specific blocked port, it will go through the whole convergence period (blocking,listening, learning, forwarding)