Neighbours with the lowest BGP router identifier will establish the connection to the remote peer via TCP port 179, the source port will be random. We can modify this behaviour with a few simple commands.

For example we want R1 to be a passive peer. That means that R2 and R3 will actively look to establish the session.

BGP

BGP

So from R1 if we leave everything as default then we can work out that R1 it the lowest router identifier, courtesy of a loop-back interface which is 10.4.1.1. So it will look to actively establish the connection with any configured peers.

R1#sh ip bgp summary
BGP router identifier 10.4.1.1, local AS number 500

We can verify this with the following command.

R1#sh ip bgp neighbors | i host
Local host: 150.1.1.2, Local port: 57717
Foreign host: 150.1.1.1, Foreign port: 179
Local host: 150.1.1.6, Local port: 63542
Foreign host: 150.1.1.5, Foreign port: 179

Lets modify this behaviour, use the commands.

router bgp 500
 neighbor 150.1.1.1 transport connection-mode passive
 neighbor 150.1.1.5 transport connection-mode passive

Then clear the BGP session with clear ip bgp *

Now use the same command as before.

R1#sh ip bgp neighbors | i host
Local host: 150.1.1.2, Local port: 179
Foreign host: 150.1.1.1, Foreign port: 34121
Local host: 150.1.1.6, Local port: 179
Foreign host: 150.1.1.5, Foreign port: 32711

This shows us that foreign host has established the bgp connection sourcing from random port to port 179 on our local router.

RFC4271 which is the holy grail for BGP-4 states that.

8.2.1
When a BGP speaker is configured as active,
it may end up on either the active or passive side of the connection
that eventually gets established.  Once the TCP connection is
completed, it doesn’t matter which end was active and which was passive.
The only difference is in which side of the TCP connection has port number 179.

There exists a period in which the identity of the peer on the other
end of an incoming connection is known, but the BGP identifier is not
known.  During this time, both an incoming and outgoing connection
may exist for the same configured peering.  This is referred to as a
connection collision.

Interesting.

RH

4-Byte Autonomous System Number provides us with 4.3billion unique ASN’s , going far beyond the original 2-Byte range of 65536.

So what happens when you have a router that doesn’t yet support 4-Byte ASN? I’ll show you what to do.

You wouldn’t necessarily be configuring all 3 routers in the real world.

First see the simple topology below

4-Byte ASN

4-Byte ASN

R3 in the middle is still using a 2-Byte ASN and the IOS doesn’t support 4-Byte ASN. So for this exact purpose IANA assigned a placeholder, AS23456 which is used by the older routers to communicate with new 4-Byte AS numbers.

This is achieved by using a transitive BGP attribute  NEW_AS_PATH and NEW_AGGREGATOR, much like the ATOMIC_AGGREGATOR used when summarising similar routes. This stores like a small note of the actual 4-Byte ASN which is then used by the 4-Byte capable router. Something you might want to note is the AS_PATH length is also maintained, I will demonstrate this.

This particular method is known as AS-PLAIN

So on R2 and R3 setup BGP, the only difference is on R3 instead of using the actual AS number use the placeholder AS23456.

R2#sh run | sec router bgp
router bgp 132678
 bgp log-neighbor-changes
 network 111.111.111.0 mask 255.255.255.0
 neighbor 192.168.5.1 remote-as 500
no auto-summary
!
R3#sh run | sec router bgp
router bgp 500
 no synchronization
 bgp log-neighbor-changes
 neighbor 192.168.1.1 remote-as 23456
 neighbor 192.168.5.2 remote-as 23456
 no auto-summary

Now on R1 I’ve used AS_PATH Prepend to demonstrate the fact that the AS_PATH length doesn’t change, On my route map I prepended the AS path 4 times

R1#sh run | sec router bgp
router bgp 131456
 bgp log-neighbor-changes
 network 222.222.222.0
 neighbor 192.168.1.2 remote-as 500
 neighbor 192.168.1.2 route-map prepend-AS out
no auto-summary

Now lets confirm the configurations above, using the commands SH IP BGP” from R3. We will expect to see the placeholder ASN23456

   Network          Next Hop            Metric LocPrf Weight Path
*> 111.111.111.0/24 192.168.5.2              0             0 23456 i
*> 222.222.222.0    192.168.1.1              0             0 23456 23456 23456 23456 23456 i

Now  let’s do the same from R2 , we should now expect to see the 4-Byte ASN in the AS_PATH.

     Network          Next Hop            Metric LocPrf Weight Path
 *>  111.111.111.0/24 0.0.0.0                  0         32768 i
 *>  222.222.222.0    192.168.5.1                            0 500 131456 131456 131456 131456 131456 i

To see exactly what is sent between the router’s I’ve used Wireshark to capture the packets, you can see the message sent from R3, AS_PATH and NEW_AS_PATH

Wireshark Capture

Wireshark Capture

 

If you need to work out the ASDOT version of an ASPLAIN 4-Byte ASN use the examples below.

4-Byte ASN-194534
1. 194534 / 65535 = 2 (integer)
2. 194534 – ( 65535 * 2) = 63464
3. 63464 – 2 (integer) = 63462
4  ASDOT = 2.63462

Here is a different example this time with an even longer ASN

4-Byte ASN-2394951
1. 2394951 / 65535 = 36 (integer)
2. 2394951 -(65535*36) = 2394951-2359260 = 35691
3. 35691-36 (integer) = 35655
4. ASDOT =36.35655

RH

IPERF is a great tool for testing bandwidth between 2 computers either on the local LAN or across a WAN.

I wont go deep dive into the mecahnics of TCP and UDP packets.

One side is the client and one side is the server the, the -w switch is to set the TCP receive window size for the purpose of this discussion its 64KB

Here are the commands you need to get started, from the server side you only need a few commands these are below.

iperf -s -w 64KB -i 5

What this does is set the device as server , the tcp window size as 64KB and the interval at which to display the progress.
Hit return,  it will begin to listen for any connections, see below.

IPERF Server

IPERF Server

Now on the client side, this is where you set all your paramameters.

iperf -c [ip address of server] -w 64KB -t 40 -i 5

What this does is send the server data for 40 seconds and gives you a update on the progress every five seconds. like below.

IPERF Client

IPERF Client

You could also send the server a set amount, maybe 100MB of data with the following command

iperf -c [ip address of server] -w 64KB -n 100M -i 5

Another trick you can do is run parallel client threads to simulate more than one device using the link use the command below
to simulate 3 parallel threads

iperf -c [ip address of server] -w 64KB -n 100M -i 5 -P 3

If you add the -u switch this will send UDP packets instead of TCP and give you some valuable statistics like jitter and packet loss.
This time dont set a window size on client or server, you set the bandwidth on the client side ,  dont set this to more than your actual bandwidth otherwise you’ll drop packets.

iperf -c [ip address of server] -u -t 40 -i 5 -b [b/width in Megabits]

iperf -s -u -i 5.

See below outputs from client and server side.

IPERF UDP

IPERF UDP

IPERF UDP

IPERF UDP

For help on IPERF just type IPERF –help to see all the switches.

RH

This blog will cover setting up 2 Cisco ASA firewall’s Active / Standby, so if one of the firewalls has a power issue or hardware failure, the standby firewall will wait a set amount of time before taking over from the failed device and resuming the traffic as if nothing happened. You can use stateful failover to resume IPsec sessions, NAT xlate, TCP, UDP, ARP etc. From version 8.4 routing information is also replicated.

The first thing you should know is you only need to set up 1 individual firewall, so my recommendation would be to get a firewall fully functional with all the configuration necessary, then the secondary firewall only needs a few commands before taking an entire copy of the primary firewall’s config, and becoming a standby firewall.

Before we begin lets take a look at the diagram, I used GNS3 but if you require to do this in real-life you would use crossover cables between the failover interfaces.This diagram depicts a single point of failure as the LAN switch but this is not the point of the blog, You would have more than one switch within your core design.

Active-Standby

We will just use the basic config of the firewall, in my setup i have an IPsec tunnel between my ASA and R3, I used this to confirm that IPsec tunnel failover was working as expected.
You will need to decide beforehand which address space you will use for your failover interfaces, and your standby IP’s must be another useable IP within your primary IP subnet.

On ASA 1 use a console or SSH session and input the following commands. Be sure to use “no shutdown” on any interfaces you decide to use.

interface GigabitEthernet1
 nameif inside
 security-level 100
 ip address 192.168.1.1 255.255.255.0 standby 192.168.1.2
!
interface GigabitEthernet0
 nameif outside
 security-level 0
 ip address 172.16.1.1 255.255.255.0 standby 172.16.1.2
!
failover lan interface lan_fail1 gig3
failover interface ip lan_fail1 10.2.2.1 255.255.255.252 standby 10.2.2.2
!
failover link stateful_fail2 gig2
failover interface ip stateful_fail2 10.1.1.1 255.255.255.252 standby 10.1.1.2
!
failover key cisco123
!
failover lan unit primary
!
failover replication http
!
prompt hostname priority state
!
failover

Once that is complete, you can now configure the secondary firewall, you can use the command “clear config all” on the secondary firewall to clear all config before you input the commands below. This is the absolute minimum you require to get the secondary firewall up and running, again be sure to use “no shutdown” on any interfaces you need.

interface gig3
no shutdown
!
failover lan interface lan_fail1 gig3
failover interface ip lan_fail1 10.2.2.1 255.255.255.252 standby 10.2.2.2
!
failover key cisco123
!
failover lan unit secondary
!
failover

After you enter the commands you will see the message “detected and active mate” this will confirm the 2 firewalls can see each other. The firewalls will begin to synchronise their configurations, the primary ASA will send over the configuration to the secondary. You will notice the prompt changes to ASA1/sec/stby# we use the command “prompt hostname priority state” for this purpose, so we can be sure which firewall is which.
The primary firewall prompt will be ASA1/pri/act#.

After this point you only need to make changes to the primary unit and any changes to the configuration and “write memory” you do on the primary will also be replicated to the standby unit.

The command “show failover” will provide you with all the necessary information you require should you need to troubleshoot or confirm your configuration is working as expected.

To manually failover the devices you can use the command “no failover active” on the active firewall or from the standby you can use ” failover active” note that when the primary unit recovers from a failure it does not automatically assume the active role.

You can have the ASA alert you when a failover has taken place by setting up email alerts.

logging mail critical
logging from-address asa1@yourdomain.com
logging recipient-address rh@mydomain.com
smtp-server x.x.x.x

This was one of my favourite blogs to write because the with the Cisco ASA everything just “works”

RH.

This lab is setup for Multicast Source Discovery Protocol (MSDP) I will also be applying Source Active (SA) filtering on our Rendezvous Points (RP). On this occasion I will use Auto-RP to discover RP on each domain then use MSDP to enable us to share SA messages about our multicast sources. The SA filtering will be applied to R2 and R3. When using MSDP setup a multicast boundary, imagine a line between domains where you create an access-list which permits or allows any multicast address which you specify.

The reason I am using Auto-RP is to show the significance of using the multicast boundary, we will block the Auto-RP multicast address of 224.0.1.39 and 224.0.1.40 this will guarantee the boundaries between our domains, but not limited to only that purpose.

The main commands you will need are “ip msdp peer [ip address] connect-source [interface]” for SA filtering use the command “ip msdp sa-filter in | out [peer ip] list [access-list]” for the multicast boundary under interface use the command “ip multicast boundary [access-list] in | out filter-autorp” My previous blog “Multicast Notes” will provide a little more detail, and also some examples of access-lists.

MSDP Topology

MSDP Topology

 

Attached are the config’s for each router (Router Configs). As I’m using GNS3 I had to enter commands “no ip route-cache” and “no ip mroute-cache” on each PIM interface. Also add “no ip cef”. You won’t need this for physical routers.

Verify our msdp peers with the command “show ip msdp summary” from R3 shows we have 2 MSDP peers, both show as UP. All is looking good at this point.

R3#sh ip msdp summary
MSDP Peer Status Summary
Peer Address     AS   State   Uptime/  Reset    SA   Peer Name
Downtime Count  Count
10.255.255.2     2     Up         00:09:29      0          0            ?
10.255.255.6     6     Up         00:10:19      0          0            ?

We can also use the command “show ip msdp peer 10.255.255.2” from R3 to show us is if any SA filtering is being applied and also how many SA messages received from the peer. In our example we have received 1 SA message from our peer 10.255.255.2 highlighted in red, and we are filtering inbound SA messages, also highlighted in red.

MSDP Peer 10.255.255.2 (?), AS 2
Connection status:
State: Up, Resets: 0, Connection source: Loopback1 (10.255.255.3)
Uptime(Downtime): 00:17:41, Messages sent/received: 18/19
Output messages discarded: 0
Connection and counters cleared 00:19:31 ago
SA Filtering:
Input (S,G) filter: 101, route-map: none
Input RP filter: none, route-map: none
Output (S,G) filter: none, route-map: none
Output RP filter: none, route-map: none
SA-Requests:
Input filter: none
Peer ttl threshold: 0
SAs learned from this peer: 1
Input queue size: 0, Output queue size: 0
Message counters:
RPF Failure count: 0
SA Messages in/out: 1/0
SA Requests in: 0
SA Responses out: 0
Data Packets in/out: 0/0

To display any SA messages the router has received we use the command “show ip msdp sa-cache” this will display the source tree entry for any multicast sources our neighbour is aware of, bearing in mind all SA messages are flooded to MSDP neighbours unless filtered by an SA-filtering

R3#sh ip msdp sa-cache
MSDP Source-Active Cache – 1 entries
(74.74.74.5, 239.4.4.4), RP 2.2.2.2, BGP/AS 2, 00:01:50/00:05:04, Peer 10.255.255.2

Now let’s consider SA-filtering, as per my multicast notes blog I will use this to filter messages sent from R2 to R3. The scenario is as follows, R5 is the multicast source of 239.4.4.4 and 232.8.8.8 but R7 doesn’t need to receive multicast traffic from R5 on 232.8.8.8 only traffic from R5 239.4.4.4 is required. So on R2 which is the nearest RP to R5 I will filter outbound messages to R3. In reverse we could do an inbound filter on R2. Configuration is as follows on R2.

access-list 101 permit ip host 74.74.74.5 host 239.4.4.4
!
ip msdp sa-filter out 10.255.255.3 list 101

Let’s test this with a ping to the multicast address.

R5#ping 239.4.4.4 rep 3
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 239.4.4.4, timeout is 2 seconds:
Reply to request 0 from 74.74.74.1, 28 ms
Reply to request 0 from 17.17.17.7, 156 ms
Reply to request 1 from 74.74.74.1, 52 ms
Reply to request 1 from 17.17.17.7, 180 ms
Reply to request 2 from 74.74.74.1, 48 ms
Reply to request 2 from 17.17.17.7, 176 ms

R5#ping 232.8.8.8 rep 3
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 232.8.8.8, timeout is 2 seconds:
Reply to request 0 from 74.74.74.1, 52 ms
Reply to request 1 from 74.74.74.1, 48 ms
Reply to request 2 from 74.74.74.1, 40 ms

So as you can see above R7 replies to 239.4.4.4 but not 232.8.8.8, so the filter works as expected.

Also on R2 I used an inbound SA-Filter this does the opposite from an outbound filter. So the commands will only accepts SA-messages from peer 10.255.255.3 with (10.10.10.4 , 232.8.8.8).

ip msdp sa-filter in 10.255.255.3 list 102
access-list 102 permit ip host 10.10.10.4 host 232.8.8.8

Below you can see some packet captures on the routers showing the source active messages being sent from R2 to R3 and also from from R3 to R6.

MSDP SA from R2 -> R3

MSDP SA from R2 -> R3

MSDP SA from R3 -> R6

MSDP SA from R3 -> R6

RH

This lab is set up for Source Specific Multicast (SSM) for this to work we need to enable our PIM interfaces for IGMPv3 as this supports source filtering which is fundamental for SSM. The IANA have reserved the 232.0.0.0/8 for SSM. With SSM we don’t require a RP.
SSM is enabled on your router with the command “ip pim ssm default” you can specify a range but if you choose default then the 232.0.0.0/8 range will apply. Then on each interface participating in PIM we use the command under interface configuration “ip igmp version 3”

 

SSM Topology

SSM Topology

 

Attached are the config’s for each router (Router Configs). As I’m using GNS3 I had to enter commands “no ip route-cache” and “no ip mroute-cache” on each PIM interface. Also add “no ip cef”. You won’t need this for physical routers.

We can verify the IGMP groups from the DR to do this we use the command “show ip igmp membership x.x.x.x” on R3, in our case we can see SSM entries for 232.1.1.1

Channel/Group                 Reporter       Uptime   Exp. Flags Interface
/*,232.1.1.1                   10.10.10.4     03:16:22 stop 3MA   Fa0/0
15.15.15.2,232.1.1.1                           03:16:22 02:44 RA     Fa0/0
56.56.56.1,232.1.1.1                           03:16:22 02:44 RA     Fa0/0

To verify our SSM is working correctly let’s generate some traffic from the specific source in the above output. I will source traffic from 15.15.15.2 to 232.1.1.1 and we should see some replies.

R2#ping 232.1.1.1 source 15.15.15.2 rep 3
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 232.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 15.15.15.2

Reply to request 0 from 10.10.10.4, 32 ms
Reply to request 1 from 10.10.10.4, 80 ms
Reply to request 2 from 10.10.10.4, 68 ms

Now let’s source the traffic from the same router but a different interface source address and see what happens………………… no replies.

R2#ping 232.1.1.1 source 56.56.56.2 rep 3
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 232.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 56.56.56.2

Running a packet capture on the DR router shows the IGMPv3 membership report / Join Group from R4. This is sent to the multicast address of 224.0.0.22. This lists the group record for our multicast address and the sources from which we want to receive.

PCAP IGMPv3

PCAP IGMPv3

Some other points to mention, when we use source specific multicast we can re-use an existing address an example would be as above the group 232.1.1.1 is used twice as it’s from a different source this is sometimes referred to as channels. For example (15.15.15.2 , 232.1.1.1) is a different SSM “channel” from (56.56.56.1 , 232.1.1.1).

With SSM the last hop router will continue to send (S , G) join messages if they still exist on the receivers side, therefore the shortest path tree (SPT) from host to source will be maintained even if the source is no longer sending traffic.

RH

This lab is set up for the bootstrap protocol, for this to work we specify the candidate BSR router (C-BSR) and the candidate RP (C-RP). I have set the same router to provide both functions.
The command “ip pim bsr-candidate [interface] [0-32] [0-255]” sets the router as candidate BSR, the 0-32 is the hash mask value, and the 0-255 is the priority. The hash value can be used to distribute group addresses evenly among multiple C-RP. The next command needed is “ip pim rp-candidate [interface]” this allows the router to send candidate rp advertisements to the BSR.

BSR Topology

The C-BSR will send bootstrap messages to all PIMv2 on address 224.0.0.13, once the C-RP’s receive this they unicast their C-RP messages to the BSR. The BSR doesn’t select the RP it just lists them and the PIMv2 routers choose the RP. See the picture below from a packet capture the BSR sends the bootstrap message to all PIMv2 routers with the group and C-RP’s. This is how the Bootstrap Protocol differs from Auto-RP.

BSR Message

BSR Message

I’ve used an access-list in my example to show that we can distribute certain groups among multiple RP’s. For example I’ve only allowed this C-RP to become RP for the groups 232.1.1.1 and 232.4.4.4.

Attached are the config’s for each router (Router-Configs). As I’m using GNS3 I had to enter commands “no ip route-cache” and “no ip mroute-cache” on each PIM interface. Also add “no ip cef”. You won’t need this for physical routers.

Now let’s confirm configurations with some well-known commands

Run “debug ip pim bsr” from R3 this will show us the C-RP announcing to the BSR that it has 2 prefix’s and its IP address. Next the BSR sends out the message to set the RP for each of the RP’s prefix’s, it also sends the originating address.

*Mar 1 01:40 PIM-BSR(0): Build v2 Candidate-RP advertisement for 10.10.10.3 priority 0, holdtime 150
*Mar 1 01:40 PIM-BSR(0): Candidate RP’s group prefix 232.1.1.1/32
*Mar 1 01:40 PIM-BSR(0): Candidate RP’s group prefix 232.4.4.4/32
*Mar 1 01:40 PIM-BSR(0): Send Candidate RP Advertisement to 10.10.10.3
*Mar 1 01:40 PIM-BSR(0): RP 10.10.10.3, 2 Group Prefixes, Priority 0, Holdtime 150
!
*Mar 1 01:40 PIM-BSR(0): RP-set for 232.1.1.1/32
*Mar 1 01:40 PIM-BSR(0):   RP(1) 10.10.10.3, holdtime 150 sec priority 0
*Mar 1 01:40 PIM-BSR(0): RP-set for 232.4.4.4/32
*Mar 1 01:40 PIM-BSR(0):   RP(1) 10.10.10.3, holdtime 150 sec priority 0
*Mar 1 01:40 PIM-BSR(0): Bootstrap message for 10.10.10.3 originated

From R2 use the command “show ip pim rp mapping” this will show us the group address and the RP responsible for that group, also listed is via bootstrap. You may wonder what the (?) is for? All this means is that the router cannot resolve a DNS name for the IP.

Group(s) 232.1.1.1/32
RP 10.10.10.3 (?), v2
Info source: 10.10.10.3 (?), via bootstrap, priority 0, holdtime 150
Uptime: 01:43:43, expires: 00:02:13
Group(s) 232.4.4.4/32
RP 10.10.10.3 (?), v2
Info source: 10.10.10.3 (?), via bootstrap, priority 0, holdtime 150
Uptime: 01:43:43, expires: 00:02:13

From R3 run the command “show ip pim bsr”, this will show all the information regarding our bootstrap setup, including the BSR, C-RP, uptime and any ACL’s associated.

PIMv2 Bootstrap information
This system is the Bootstrap Router (BSR)
BSR address: 10.10.10.3 (?)
Uptime:     01:46:19, BSR Priority: 0, Hash mask length: 0
Next bootstrap message in 00:00:45
Candidate RP: 10.10.10.3(FastEthernet0/0)
Holdtime 150 seconds
Advertisement interval 60 seconds
Next advertisement in 00:00:22
Group acl: 20

Generate some traffic from the source R1 to the groups listed then you can use the “show ip mroute” command from a PIM enable router and see the source tree entry.

(*, 232.4.4.4), 00:00:15/stopped, RP 10.10.10.3, flags: SPF
Incoming interface: FastEthernet0/1, RPF nbr 15.15.15.3
Outgoing interface list: Null

(56.56.56.1, 232.4.4.4), 00:00:15/00:03:21, flags: FT
Incoming interface: FastEthernet0/0, RPF nbr 56.56.56.1
Outgoing interface list: FastEthernet0/1, Forward/Sparse, 00:00:15/00:03:16

RH