Multicast for Hub and Spoke VPN

[chintan-shah]

Hi,

Can we have Multicast VPN ( draft-rosen ) for Hub and Spoke based VPN ?

As of now we can not configure two VRF with same MDT Default and MDT Data MDT Multicast Group , which is required for HUB and SPOKE topology speically when I have both HUB  and SPOKE Site on same PE.

Is there any alternate solution ?

Regards,

Chintan

[Mohamed Sobair]

Hi Chintan,

Its indeed not supported to have two VRFs with the Same MDT-Default and Data for Multicast VPN.

Do you mean you need to control the Multicast traffic from the HUB and Which Spoke can recieve it? Do you intent to have Fully meshed Multicast between your HUB and Spokes? May you elaborate more on  your exact requirement?

Regards,

Mohamed

[Vaibhava Varma]

Hi Chintan

Yes we can MVPN for Hun and Spoke VPNs whereby we are using 2 logical peerings with the HUB_CE ie one for Ingress_Routes from Spoks and other for Egress_Routes to Spokes. Here we will have separate MDTs for the 2 Ingress/Egress VRFs and still the Spokes can communicate to each other via the Hub-CE on the Multicast layer without any issues. The Ingress_MDT would be used to send the multicast routes to the Hub_CE and the Egress_MDT would be used to advertise those multicast routes back to the Spoke PEs.

For the Spoke which could be colocated on the same PE as the HUB_CE the multicast communication would still work fine.

Regards

Varma

[chintan-shah]

Hi Varma,

Thanks for your response. Can I ask you favor with sample diagram +configuration example to have better understanding ?

Many thanks,

Chintan

[Vaibhava Varma]

Hi Chintan

Lets take below setup

                                       -----------------------Spoke_PE1---------Spoke2_CE

              -------------

Hub_CE               Hub_PE

            --------------- !          -----------------------Spoke_PE2---------Spoke3_CE

                            !

                            !

                     Spoke1_CE                                                               

Now on HUB_PE we create two VRFs HUB_Ingress and HUB_Egress respectively

ip vrf HUB_Egress

rd 64513:2

route-target export 64513:100

mdt default 239.2.2.2

!

ip vrf HUB_Ingress

rd 64513:1

route-target import 64513:200

route-target import 64513:300

mdt default 239.1.1.1

Now we bind the respective VRFs to the HUB_CE L3 Links for Ingress(from spoke) and Egress(to spoke) routes

interface FastEthernet3/0

description HUB_Ingress

ip vrf forwarding HUB_Ingress

ip address 172.16.1.1 255.255.255.252

ip pim sparse-dense-mode

duplex auto

speed auto

!

interface FastEthernet3/1

description HUB_Egress

ip vrf forwarding HUB_Egress

ip address 172.16.1.5 255.255.255.252

ip pim sparse-dense-mode

duplex auto

speed auto

The Local Spoke1 is also kept as part of Hub_Egress VRF

interface FastEthernet4/0

description SPOKE1

ip vrf forwarding HUB_Egress

ip address 172.16.2.1 255.255.255.252

ip pim sparse-dense-mode

duplex auto

speed auto

EBGP is ised as the PE-CE ROuting Protocol..HUB_CE is made Auto-RP for CE-Domain

address-family ipv4 vrf HUB_Ingress

redistribute connected

neighbor 172.16.1.2 remote-as 64514

neighbor 172.16.1.2 activate

neighbor 172.16.1.2 soft-reconfiguration inbound

no synchronization

exit-address-family

!

address-family ipv4 vrf HUB_Egress

neighbor 172.16.1.6 remote-as 64514

neighbor 172.16.1.6 activate

neighbor 172.16.1.6 allowas-in 5

neighbor 172.16.1.6 soft-reconfiguration inbound

neighbor 172.16.2.2 remote-as 64515

neighbor 172.16.2.2 activate

neighbor 172.16.2.2 soft-reconfiguration inbound

no synchronization

exit-address-family

Spoke2 and Spoke4 VRFs are configured as

SPOKE2

ip vrf SPOKE2

rd 64513:3

route-target export 64513:200

route-target import 64513:100

mdt default 239.1.1.1

SPOKE3

ip vrf SPOKE3

rd 64513:4

route-target export 64513:300

route-target import 64513:100

mdt default 239.1.1.1

This config would achieve us the required Hub and Spoke Topology for Unicast as well as Multicast VPN Traffic.

Regards

Varma

[chintan-shah]

Hi Varma,

Thanks for very quick response , I really appreciate it.

Do we really need to configure HUB_Ingress VRF with default MDT ( 239.2.2.2) ?

Because MDT between PE over core is through 239.1.1.1 , so that PIM Join from spokes will be over this MDT ( i.e. come on VRF HUB_Ingress unlike unicast which will be on HUB_egress ) and same time from Hub CPE traffic will go over same MDT.

Multicast between Hub and spoke sites with in PE will be any way part of now same VRF(routing table)so that should be now fine. Right ?

Regards,

Chintan

[chintan-shah]

Oops, my question was : Do we really need to configure Multicast MDT ( in this case 239.1.1.1) on HUB_Egress VRF ? ☺

Regards,

Chintan

[Vaibhava Varma · Accepted solution]

Hi Chintan

No default mdt won't be needed for HUB_Egress VRF..Multicast Traffic would flow via HUB_Ingress VRF.

Sample output for above topology :-)

224.1.1.1 at SPoke1; 224.2.2.2 at Spoke2; 224.3.3.3 at Spoke3 and 224.4.4 at Hub_CE..everything works fine

Spoke3#mtrace 172.16.51.1 172.16.251.1 224.1.1.1

Type escape sequence to abort.

Mtrace from 172.16.51.1 to 172.16.251.1 via group 224.1.1.1

From source (?) to destination (?)

Querying full reverse path...

0  172.16.251.1

-1  172.16.251.1 PIM  [172.16.51.1/32]

-2  0.0.0.0 None Prune sent upstream !RPF!172.16.2.9 [default]

-3  0.0.0.0 PIM Prune sent upstream [default]

-4  172.16.1.2 PIM Reached RP/Core [172.16.51.1/32]

Spoke3#mtrace 172.16.151.1 172.16.251.1 224.1.1.1

Type escape sequence to abort.

Mtrace from 172.16.151.1 to 172.16.251.1 via group 224.1.1.1

From source (?) to destination (?)

Querying full reverse path...

0  172.16.251.1

-1  172.16.251.1 PIM  [172.16.151.1/32]

-2  0.0.0.0 None Prune sent upstream !RPF!172.16.2.9 [default]

-3  0.0.0.0 PIM Prune sent upstream [172.16.151.1/32]

-4  172.16.1.2 PIM Reached RP/Core [172.16.151.1/32]

Spoke3#ping 224.1.1.1 source lo0

Type escape sequence to abort.

Sending 1, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:

Packet sent with a source address of 172.16.251.1

Reply to request 0 from 172.16.2.2, 716 ms

Reply to request 0 from 172.16.2.2, 796 ms

Spoke3#ping 224.2.2.2 source lo0

Type escape sequence to abort.

Sending 1, 100-byte ICMP Echos to 224.2.2.2, timeout is 2 seconds:

Packet sent with a source address of 172.16.251.1

Reply to request 0 from 172.16.2.6, 788 ms

Reply to request 0 from 172.16.2.6, 952 ms

Spoke3#

Regards

Varma

[chintan-shah]

Perfect – Many thanks.

Regards,

Chintan

[chintan-shah]

Hi Vaibhava,

I see one caveat for spoke sites on same PE where Primary Hub site configured but Hub is Multihomed to two PE.

In case primary Hub site fails, there is an issue for multicast/unicast for from backup Hub site (PE) for spoke sites which were on primary PE because those spoke sites are part of VRF which only does RT export hence no remote routes for unicast and no mdt default for multicast.

Regards,

Chintan

[Vaibhava Varma]

Hi Chintan

If such is the case then we can use an additional different RT say 64513:500 for HUB_Egress VRF also which will be only exported imported between the 2 PEs terminating the HUB_CE for proividng reachability to Co-located Spoke.

Regards

Varma

[chintan-shah]

Hi Varma,

So you also suggest to configure different MDT on HUB_Egress VRF between 2 PE terminating HUB_CE so that it also take cares of multicast across PE for collocated spokes. Right ?

Regards,

Chintan

[Vaibhava Varma]

Hi CHintan

Yes we would need different MDT e.g 239.2.2.2 on HUB_Egress_VRF for making the multicast communication up between the co-located Spoke on HUB_PE1 to the backup link on HUB_PE2 connecting to HUB_CE otherwise we would loose multicast traffic between the co-located spoke on HUB_PE1 to the HUB_CE in case of primary link failure.

Regards

Varma

[chintan-shah]

Hi Varma,

Thanks for confirmation ☺

Regards,

Chintan

[chintan-shah]

Hi Mohamed,

The customer ask Hub and spoke L3 MPLS VPN. At the same time, customer also require Multicast over VPN.

I can configure normal Hub and spoke based MPLS VPN to support unicast traffic.

I can also configure multicast default and data mdt in customer VRF on each PE although it will form PIM across all PE ( i.e. Mesh). No issue so far at least to have Multicast working.

Correct me, If I am wrong till this part.

Now, I have situation where on same PE I will have Hub and some of spoke sites ( this is not avoidable all time due to various reasons like last mile , same city etc ), So I will have one VRF for Hub and another VRF for all spoke sites for Hub and spoke requirements. How do I switch Multicast ( PIM Join for RP etc) from one VRF(hub)to another VRF (Spoke) ? I even can’t configure same mdt default and data MDT in both VRF since they are on same PE. This is a problem and I am not sure if today we have any solution with draft-rosen based mVPN.

Hope I am able to make requirement more clear , let me know if you still have any further question.

Thanks in advance for help,

Regards,

Chintan