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

RSTP already incorporates the functionality of UplinkFast and BackboneFast (although not implemented exactly in the way the UplinkFast and BackboneFast implement it), and when you activate RSTP, you get UplinkFast-like and BackboneFast-like functionality.

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 a blocked port in the switch that just 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 & Bridge assurance

When loop guard enabled, a blocked port on the switch that has been receiving BPDU message suddenly stops receiving BPDU, this port will be put in loop-inconsistent state.

When loop guard is not enabled, the blocked port on the switch that has been receiving and sending BPDU message suddenly stops receiving BPDU, the port will think it is safe to move the status from blocking to listening, learning, and forwarding. In the following case this will bring L2 network loop:

  • That one direction of fiber link is broken, the the other direction of the fiber link is still in operation.

Below is the relationship between port status and BPDU sending/receiving:

Port states:

  • Blocking: State where the switch port can receive BPDU, but can not forwarding user traffic or BPDUs.
  • Listening: State where the switch port can send & receive BPDU, but can not forwarding user traffic.
  • Learning: State where the switch port can learn MAC address, send and receive BPDU, but not forwarding user traffic.
  • Forwarding: State where the switch port can learn MAC address, send and receive BPDU, and forwarding user traffic.


  • Blocked – Doesn’t send BPDU’s, but is receiving them.
  • Designated – Send BPDU’s and Receives BPDU’s.
  • Root – Doesn’t send BPDU’s, but is receiving them. (Root port can send TCN (topology change) BPDU up to the upper switch.)

There are a few scenarios where LoopGuard would not be effective at detecting loops and/or unidirectional links.
– can only be enabled on root & alternate ports. it CANNOT run on ‘designated ports’.
– ineffective at detecting a port that has been unidirectional since link-up.

Bridge Assurance is enabled by default and can only be disabled globally. Also, Bridge Assurance is enabled only on spanning tree network ports that are point-to-point links. Finally, both ends of the link must have Bridge Assurance enabled. If the device on one side of the link has Bridge Assurance enabled and the device on the other side either does not support Bridge Assurance or does not have this feature enabled, the connecting port is blocked.

With Bridge Assurance enabled, BPDUs are sent out on all operational network ports, including alternate and backup ports, for each hello time period. If the port does not receive a BPDU for a specified period, the port moves into an inconsistent state (blocking). and is not used in the root port calculation. Once that port receives a BPDU, it resumes the normal spanning tree transitions.

Bridge assurance works only under MST and PVST+


Fundimental of rapid spanning tree

Basic concepts of rapid spanning tree

1, BPDU is the packet that used for communication between switches
2, Root bridge is the switch which has lowest value of priority, mac address
3, Switch port can be root port, designated port, alternative port and backup port; in Switch ports can be categorized also as edge-port(port-fast in classic spanning tree) and point-to-point port.
4, ports statues: discarding, learning, forwarding
5, hello interval is by default 2 secs, max age is 3 * hello interval, thus 6 sec by default
6, when TCN received,switch will immediately timeout its CAM (mac address table), and put all of its none-edge ports in sync mode.
7, During sync, each port will negotiate its new statue with the peer, switch who has the superior BPDU will put port into designated port.

8, Every bridge generate and send BPDU every hello time interval, but only designated port will send out BPDU, not alternative and backup port.
9, Not like classic stp,in rstp bridge will not relay BDPU from root bridge, instead, it will generate its own BPDU with its own BID and Root ID from root bridge. Thus all bridge will know RootID.

10, The sync process is used to determine if  I m agree with you about the root bridge. sync process start with sending/receiving proposal BPDU and end by receiving/sending agreement BPDU

Topology change in rapid spanning tree

Scenario 1:Topology change on edge port (up or down)
It will not generate topology change in the network

Scenario 2: Topology chanage on NONROOT switch, linkup on designated port in switch A
1, At first both switches’s ports are in blocking mode until they received each other’s BPDU. If switch A received a inferior bpdu, it will send out BPDU proposal, after got BPDU agreement from peer side, switch A will put port into forwarding state.
2, If switch A received a inferior bpdu, it will send out BPDU proposal, after got BPDU agreement from peer side, switch A will put port into forwarding state.
3, If switch A received a superior BPDU, it will realized that peer switch should be root bride, A will start RPST convergence:
a) Peer switch will send BPDU proposal for negotiation, switch A will block all its none-edge ports, put them into sync mode, age-out CAM (MAC address table) immediately, then reply peer switch BPDU agreement. After that, switch A and peer are forwarding the traffic;
b)All of the none-edge ports in switch A will send out proposal BPDU towards their peer side, and the peer side switch will repeat the step a) for port negotiation.

Scenario3: Topology change on NONROOT switch, linkdown on designated port in switch
1, Swich will stop receiving BPDU from peer side, after 3 x hello interval, switch will think link is down;
2, If the BPDU the switch stopped receiving is inferior BPDU, switch has no need to do anything;
3, If the BPDU the switch stopped receiving is superior BPDU, switch will take that root bridge is lost, if switch has a backup port, that port will immediately be forwarding, it switch has not a backup port, it will start RSTP convergence process. It starts as a wave of handshakes rippling outwards towards the periphery of the network.

Fundimental of spanning tree

Basic concepts

Basic concepts of spanning tree:
1, BPDU is the packet that used to communicated between switches
2, Root bridge is the switch which has lowest number of priority, mac address
3, Switch port can be root port, designated port, when a port is not a designated or root port it will be in blocking mode
4, ports statues: blocking, listening, learning, forwarding
5, hello interval is by default 2 secs, max age is 10 * hello interval, thus 20 sec by default,listening period: 15 sec; learning period: 15 sec
6, when tcn (topology change notification) happened,a blocking port will take 30 secs to 50 secs to turn to forwarding state depending on the topology change scenario

It is not always that a topology change will cause stp recalculation(root bridge re-selections), but all bridge who received tcn packet will age-out its CAM(mac address table) in 15 secs, in the meanwhile, blocked ports on the bridge will take 30 sec to 50 secs to go to forwarding state ( but not all blocked ports can necessarily go to forwarding state, it is possible that some blocked port will stay blocked even after topology change).

Spanning tree convergence

1, each switch declare self as root bridge by sending its own hello BPDU, BPDU will include bridge ip, priorty
2, Once switch received superior BPDU from peer, it will stop sending its own BPDU, instead it will relay this superior BPDU (with lower valude of priority.mac) by adding cost of interface.
interface cost 100M:19 10M:100
3, After root bridge is selected, root bridge will generate BPDU packet every 2 sec by default, other switches will relay this packet by adding cost.
4, The port from which BPDU is received will be selected as root port. If there are more than one ports receiving BPDU packets, the port that has the lowest cost (shortest path) will be selected as root port, the the other port will be blocked (alternative port)

Topology change in spanning tree

Topology change will in most cases not cause stp algorithm recalculation, only when root bridge is lost stp recalculation is triggered.

Scenario 1:Topology change on port-fast port (up or down)
Switch will not send out TCN (topology change notification)

Scenario 2: Topology chanage on NONROOT switch, linkdown on designate port in switch A
1, switch A will generate TCN bpdu packet, the send TSN through its root port
2, NONROOT switches who received TCN will send TCN up via its root port, and send TCA(acknowledge) back to the orignal port; at the same time, these switches will set cam timeout to 15sec (learning period)
3, Finally Root bridge will received TCN packet, it will generate topology change BPDU, and flood to the rest of the switches who has not got TCN packets yet.
4, All switches who received topology change packet will reset its CAM timeout to 15 sec (remove mac address from the table after 15 secs)
5, MAC address will be relearned immediately in most cases.

Scenario 3: Topology chanage on NONROOT switch,linkdown on root port in switch B
1, Switch B will delare it is root bridge by sending hello packets out to the rest of the ports.
2, The rest of the switches that is connecting to B but no other link towards root bridge will received BPDU from switch B, but no more BPDU from root bridge will be relayed to them. After MAX age timeout (10 * hello packet interval) 20 secs by default, these switches will acknowledge that root bridge is losted, they will restart spanning tree convergence. It will take max age (secs) + listening (15 secs) + learning (15 secs) for new convergence is in place.

spanning tree features

BPDU guard: Switch will set interface to err state when switch received BPDU from that interface

BPDU filter: Switch will drop the BPDU from the interface where BPDU filter in enabled, but will not put interface into err state

Root guard: Switch will put interface to err state when switch received BPDU from that interface, which is superior than the current root bridge.

portfast: Switch will not send TCS message when the interface with port-fast enabled has change from up to down or from down to up.

UPlinkfast & Backbone fast, will be described in separated page

loop guard will be described in separated page

Fundimental of multicast

In order to make multicast work we need to study the following 3 areas:

1, multicast address (ip and mac)
2, IGMP protocal (to make host join or leave a multicast group)
3, IP mulicast routing protocal (PIM is mostly used)

1, Multicast address

IP multicast address - are all multicast address, especially The All Hosts multicast group addresses all hosts on the same network segment. The All Routers multicast group addresses all routers on the same network segment. This address is used in the Distance Vector Multicast Routing Protocol (DVMRP) to address multicast routers. The Open Shortest Path First (OSPF) All OSPF Routers address is used to send Hello packets to all OSPF routers on a network segment. The OSPF All Designated Routers “”(DR)”” address is used to send OSPF routing information to designated routers on a network segment. The Routing Information Protocol (RIP) version 2 group address is used to send routing information to all RIP2-aware routers on a network segment. The Enhanced Interior Gateway Routing Protocol (EIGRP) group address is used to send routing information to all EIGRP routers on a network segment. Protocol Independent Multicast (PIM) Version 2 Virtual Router Redundancy Protocol (VRRP)–21 IS-IS over IP Internet Group Management Protocol (IGMP) version 3[2] Hot Standby Router Protocol version 2 (HSRPv2) / Gateway Load Balancing Protocol (GLBP)

MAC multicast address range of 01-00-5E-00-00-00 to 01-00-5E-7F-FF-FF
The limitation of number of MAC multicast address require that MAC to IP map for multicast is 32/2^5 to 1 maping. especially, the last 23 bits of IP or MAC address will be match.


IGMP will be used to make host able to join and leave multicast group
IGMP v1: to types of message : membership query and membership report
especially, router will send out membership query towards multicast ip And host will send membership report towards the mulicast ip that host want to join.
Once router receives membership report from host via interface x, router will add interface x into the mroute table. Mroute table item can be timeout after, for example, 3 mins, if host does not want to join multicast group any longer host will stop sending membership report.The router will keep forwarding multicast traffic to the hosts until the timer expires.

IGMP v2:
Host is able to send membership leave message instead of letting multicast timeout in the router. Memembership leave message will be sent to general multicast ip
When hostx send membership leave message to router, router will issue a specific membership query message towards the interface where hostx sent leave message. This specific memebership query message will be sent towards the specific multicast address instead of generic address.
when there is multiple routers in one network segment, there will be one router with lowest ip selected as active router to send membership query message

IGMP snooping:
This feature will be used in switches, so switches will snoop IGMP traffic between hosts and routers, maintain a mulicast table (CAM table), each item in the table will contain multicast dest MAC adress and interfaces that should get traffic wich that multicast dest MAC.
On the switch, all multicast traffic that is IGMP traffic will be sent to core of switches to process, realtime mulicast traffic (not IGMP traffic) will not be forwarded to switch core, this will reduce the burden of switches core

In the scenario where there is no Router, in order to get multicast work, we can
1, configure one of the svi interface on the switch to send member query message
2, configure svi interface with pim sparse mode
3, use broadcast instead of multicast by disable igmp snoopint
4, configure static mrouter port
5, configure Static multicast entry

3, IP multicast routing protocol

There are 2 mode of multicast dense mode and sparse mode
dense mode:
mulitcast traffic will send to all of the interfaces of the router except for the interface where the traffic come in. If the other routers do not want the traffic (not get membership report message),routers need send ‘no this mutlicast traffic’ back to the orignal router

There are a number of dense mode routing protocols:
DVMRP (Distance Vector Multicast Routing Protocol)
MOSPF (Multicast OSPF)
PIM Dense Mode ( This is mostly used)

PIM Dense mode will do RPF check (reverse path forwarding). router will check the source ip of the multicast traffic, if the source ip A is supposed to come in from portX on the router, the incoming traffic that comes from portY with source ip A will be dropped. The source path check is using unicast routing table, in the case that the reverse path for the source is different with that in the unicast routing table, a static mroute can be configured. RPF check will check static mroute table first, then go to unicast routing table.

PIM sparse mode:
Dense mode floods multicast traffic until a router asks you to stop.
Sparse mode sends multicast traffic only when a router requests
In sparse mode, there will be a RP (Rendezvous Point), router who receives IGMP membership report message will send PIM join message to RP. Routers will find RP by static configuration or by dynamic learning. If no RP configured in the router which only enabled PIM spars mode, the multicast will not function.

For those routers who are not interested in multicast traffic and filter out all multicast traffic on the router.

There are 2 protocols that can be used for dynamic RP configuration:Auto RP and BSR(Bootstrap router). Auto RP is Cisco proprietary protocol and BSR is standard procotol.

When there are more than one RP configured for a group, MSDP (multicast Discovery protocol) will be used to setup tcp session between those RPs, so that they can share the joined member information with each other.

4, MLD and MLD snooping

According to wikipedia “Multicast Listener Discovery (MLD) is a component of the Internet Protocol Version 6 (IPv6) suite. MLD is used by IPv6 routers for discovering multicast listeners on a directly attached link, much like Internet Group Management Protocol (IGMP) is used in IPv4. The protocol is embedded in ICMPv6 instead of using a separate protocol. MLDv1 is similar to IGMPv2 and MLDv2 similar to IGMPv3. The protocol is described in RFC 3810 which has been updated by RFC 4604.”

MLD snooping is for IPv6 multicast, like IGMP snooping for IPv4 multicast traffic.