MULTICAST BGP EXTENSION

First Question you need to know is why?
why we need BGP extension for Multicast?
the answer is simply we need to connect and multicast between two or more Domains "Autonomous systems" and BGP uses unicast to connect to its neighbors, so you have to use AF for Multicast in order to enable the multicast via BGP.


we will work on the topology below:

Important things to have before configuring mBGP-Multicast extension are:
1.FULL IGP routing table exchanged between routers and reach-ability
2. Interfaces on order Router facing EBGP neighbor should be passive for IGP
3. run EBGP border Routers or neighboring AS
4. run iBGP and make sure from Full BGP neighbor-ship and routes exchange
till the last router in your AS but using Confederations or Route-Reflectors in our case we will
use R6 and R1 from each side to be point of reflection for incoming iBGP routes learned from Border
Routers {don't forget to make border routers to act as next-hop for all the iBGP neighbors
5. configure BGP address-family for multicasting and this will require activating commands
6.redistribution point will be the border routers in order to bring reachability between
the two domains
7. use peer groups when needed to ease up configuration
8. choose the PIM mode you have been tasked to use Standard or Cisco
9. sparse mode is the common mode used and enable MSDP
NOTE: MSDP is used because RP's are in two different domains and in order to learn about sources in other domains we will use MSDP.
10. Verify your configuration by joining one router to multicast group and ping it from the remote site
11. use #show bgp ipv4 multicast summary to see the activated neighbors
12. use #show ip mroute x.x.x.x for the group
13. use #show ip rpf
14. use #show ip pim rp mapping  to verify your RP in each domain

GRE over IPSEC

Q-Why we will use IPSEC for transporting GRE payload?
A- our scenario is to connect two remote sites that are running OSPF AREA 0
discontinuously, we will connect the two peers using GRE over IPSEC

       R-A <------>R-B <-----> R-d <----->R-e <-----> R-F <------>R-Z

let's say R-B link to R-A is in OSPF AREA 0
R-F link to R-Z is in OSPF AREA 0 

the underlying routing protocol between R-B to R-F is [EIGRP]

so back to the question why we will use IPSEC for GRE transport, the reason is GRE doesn't support  Dynamic Routing protocols because GRE is used as normal Point-to-Point.

points to focus on:
1. reachability between R-B to R-F [loopbacks included]
2. reachability between R-B to R-A and R-F to R-Z [on OSPF]


steps: 
create GRE interface [ IP address, source, destination ] use the loopback for source and destination, this will help in reroute through alternative links in case of link failures.
GRE tunnel will be have the IP MTU reduced and TCP MSS changed as well.

GRE Tunnel will run OSPF in AREA 0 to be the link between the two discontiguous Area 0 

Configure the IPSEC tunnel:
1. configure ISAKMP "phase 1"
2. configure IPSEC "phase 2"

in ISAKMP which is phase 1, we need  following that both peers must have identical :
1. authentication   [pre-shared, PKI]
2. encryption type  [AES, 3DES, DES]
3. hashing type  [ MD5, SHA, SHA256, SHA384, ...etc]
4. Diffie Hellman group  [1, 14, 15, ....etc] how many bits your router can handle
5. Life time  [this is optional you can have different on peers]

in IPSEC which is phase 2, we have the following to configure:
1. configure the peer who you will connect  with
#set peer x.x.x.x
2. configure the data you are allowed over the IPSEC by using Access-list
#permit ip source destination
if you are using tunnel mode, you will have the links between R-B to R-A and R-F to R-Z in the access list, if you are using transport mode you will have to make the source is the router loopback to destination remote router loopback, in our scenario we will use transport mode. 

3. configure the transform set which is the way you will treat your data as encryption, by data we mean the data allowed in access list.
according to your ios version it may differs for the supported :

then you will match the access list using #match address acl-name
then set the transform set #set transform set  [for the matched acl]


now that you have everything configured

you should differentiate between GRE over IPSEC and IPSEC over GRE
in GRE over IPSEC you will have to configure the CRYPTO MAP on the physical interface or interfaces while on IPSEC over GRE you will need to configure CRYPTO MAP on the tunnel interface of the GRE.


so, after you applied the CRYPTO MAP on the physical interface you can start checking and verifying the configuration for each part, so let's start :

verify reachability on the loopback interface of the two peers
Router#ping 150.1.7.7 so lo0
Sending 5, 100-byte ICMP Echos to 150.1.7.7, timeout is 2 seconds:
Packet sent with a source address of 150.1.8.8 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 7/7/8 ms
this ICMP carried via EIGRP.



verify the GRE tunnel is up and running:

verify the  ISAKMP, Quick-Mode and status is active:

verify IPSEC security association which you have parameters to check:

a. SPI outbound/inbound

b. ENCAP/DECAP and Digest values [they should be increased when you even send ICMP]

c. check the ACL or "proxy identity" for local ident and remote ident. lines

NOTE: ACL's on both sides must be mirrored.

Verify Transform set:

it must be identical on both sides:

NOTE: we are using ESP.

verify the IP Route for OSPF and you should receive routes for remote peers through the tunnel interface:

the above output shows route from R-B to R-Z and coming via tunnel 0.

traffic destined to 150.1.9.9/32 will go to tunnel0, then tunnel0 will hand it over to the source of the tunnel which is loopback0, loopback0 will use the EIGRP as underlying protocol to go to remote site loopback0, when the router choose the exit interface the packets on that interface is encrypted because we have the CRYPTO map applied on it, by the way we will have the data encrypted and sent to the remote site.