Multicast RP's in different AS across an MPLS WAN

[fsebera]

Hi all, It appears Multicast redundancy is a little more challenging than expected.

If the primary rendezvous point (RP) is configured on the CE of a CE-PE BGP peering MPLS cloud,

can the redundant RP be located across the MPLS cloud in a different AS on the CE of the same MPLS cloud.

(all customer prefixes are known at every point in the WAN)?

[RP(CE)_AS100]-----PE__MPLS_(AS200)__cloud__PE------[CE(RP)_AS300]

:

Customer__A--------|---------MPLS------------|-------Customer__A

THANKS!!!!

Frank

[Peter Paluch]

Frank,

Technically, there should be no problem in configuring your RPs as you suggest. The question, however, is whether the MPLS cloud connecting your two sites is capable of natively carrying multicast streams. I assume you are using MPLS L3 VPN that interconnects your sites.

Also, how do you actually propose to configure a backup RP? Technically, there is only a single RP for a particular multicast group. There are applications of MSDP to provide for so-called AnycastRP, or you could use the BSR or AutoRP (yuck! ) to dynamically select an RP from a number of RP candidates.

Best regards,

Peter

[fsebera]

Peter,

You assumption is correct, we use MPLS L3 VPNs with eMBGP peering for IPv4/IPv6 UNICAST only.

We have 2 different multicast applications in use.

One-to-Many, typical video stream out to receivers

Many-to-Many, VTC conference style application where all talk and listen simultaneously (big party)

We currently don't have MBGP address-family ipv4 multicast enabled, perhaps this is one of our issues.

MSDP is not implemented and I think MSDP CE-PE peering is required to sync the RPs across MPLS cloud. --RIGHT?

The MPLS cloud is private AS 65000 while the remote sites are all different private ASNs. 

The MPLS cloud is setup with MDT Default 239.232.0.0 and 239.233.0.0 dynamic multipoint GRE tunnels to support our true hub and spoke environment.

Here's a sniblet of the PE1 router

:

sh derived-config

vrf defininition HQE

rd 10:1

!

address-familt ipv4

mdt default 239.232.0.0

route-target export 10:10

exit-adress-family

!

address-family ipv6

route-target export 10:10

!

vrf definition HQI

rd 10:0

!

address-family ipv4

mdt default 239.233.0.0

route-target import 30:30

route-target import 40:40

route-target import 20:20

exit-adress-family

!

--snip--

!

interface Tunnel0

ip unnumbered Loop0

tunnel source Loopback0

tunnel mode gre multipoint

no routing dynamic

!

interface tunnel1

ip unnumbered f0/0.10

tunnel source f0/0.10

tunnel destination 172.31.255.254

tunnel tos 192

tunnel vrf HQI

no routing dynamic

!

etc

etc

etc

All data traffic flows as expected and all prefixes from remote CE peers can be found at each CE router.

Thanks for assisting! Frank

[Peter Paluch]

Hello Frank,

I have quite a couple of observations/questions. I apologize if some of them are outright dumb - I need to understand the environment in which you operate. Please bear with me here.

• Who has the control over the MPLS cloud? Is it your cloud or ISP's cloud?
• Why is there a MVRF configuration present on the PE1 router (MDT definition in the VRFs) if according to your information, the MPLS cloud supports unicast routing only?
• Why do you have Tunnel interfaces if you are using MVRF configuration?
• If you tunnel your multicast traffic via Tunnel interfaces, have you statically modified the multicast routing table using the ip mroute command to allow the RPF check to work correctly?
• Once again, how exactly do you plan to implement the idea of primary and backup RP?

Best regards,

Peter

[fsebera]

Peter,

The telecom controls their PE routers but provide configurations to us.

The MPLS cloud supports multicast; IP pim sparse-mode is configured on all the revelent CE interfaces and BGP peering is only configured for UNICAST routing.

router bgp 65010

no sync

!

address-family ipv4 unicast

neighbor 172.16.10.2 remote-as 65000

!

address-family ipv6 unicast

neighbor 172:16:10::2 remote-as 65000

One HQ CE router is the RP and mapping agent for the entire network (300 remote sites).

When attempting to configure a second router -an MPLS remote site- CE router as a redundant RP and mapping agent, multicast fails.

When a single RP is enabled, multicast flows to all receivers and all functions just fine, but when a second RP is configured, multicast no longer makes it to many remote sites. Removing the 2nd RP config and all works well again.

I was thinking the CE-PE BGP peering configurations should include BGP address-family ipv4 multicast; peering between CE-PE along with MSDP  which would be used to sync both RPs. What do you think?

We use anycast with auto-rp to enable dynamic RPs.

Thanks again for your help

Frank

[fsebera]

Also, no static mroutes are configured, multicast uses the MDT default within the MPLS cloud.

As far as how do I plan on implementing the RP and the redundant RP, are you looking for the actual configs?

Thanks

Frank

[Peter Paluch · Accepted solution]

Hello Frank,

Alright, so now I understand better, I hope - you are saying that the MPLS cloud itself is capable of carrying the multicast traffic, it is just your CE-based BGP configuration that is not using multicast address family, right?

In any case, adding the multicast address family to BGP is not the solution here in my opinion. You have indicated that you are using "anycast" - I assume you are referring the Anycast-RP.

What probably happens is that the Anycast-RP is not deployed properly, effectively segmenting your entire network into regions, each of them using its own closest RP, without the RPs actually informing themselves about the multicast sources located in their "catchment area".

Here, you will definitely need to use the MSDP to peer your candidate RP's together. Are you familiar with the following document? Please check it and let me know. Just for the sake of MSDP configuration, you will need to use the ip msdp default peer instead of ip msdp peer - as you are not going to use BGP for multicast source information dissemination, and MSDP otherwise likes to use that for RPF checks.

http://www.cisco.com/en/US/docs/ios/solutions_docs/ip_multicast/White_papers/anycast.html

As far as how do I plan on implementing the RP and the redundant RP, are you looking for the actual configs?

Yes, seeing the configs would definitely be helpful.

Thank you!

Best regards,

Peter

[fsebera]

Hey Peter,

OK, . . . now we are enjoying multicast much more!!!

As you indicated, MSDP is the solution here for this setup. The problem I was running into with my previous configurations -- I was sourcing from the wrong local address on the RP/MSDP peering WAN CE routers.

NOW, videos are being sourced and received just fine and to verify redundancy, I manually shut down the primary RP loopback address [(since there is no redundant link to the cloud as Mohamed pointed out (I didn't include to much detail as it would get very confusing very quickly), there is redundancy but that is through a different MPLS cloud] -killing the primary RP--, forcing the redundant RP to start new sessions. I then attempted to start a new video sessions (receivers) at several remote sites. Works like a champ!!

One questions though - my video setup is One-to-Many, using PIM sparse-mode, Anycast-RP, Auto-RP and now correctly running MSDP peering to educate the other down stream RPs of the active sources.  My other multicast applications is Many-to-Many using Bidir-PIM sparse-mode, Auto-RP and Phantom-RP. All configured on the same two routers at this point. While I understand there is no load sharing or load balancing with Bidir-PIM and all active many-to-many data streams always run though one RP for the duration of the session (unless the primary RP fails), with the correctly configured MSDP peering - my many-to-many applications is operating just fine as well. Oh sorry, here is my question - Is Bidir-PIM and Phantom-RP compatible with MSDP?

As far as the configs go, what would you like to see?

THANKS SO MUCH!!!

Frank

[Peter Paluch · Accepted solution]

Hello Frank,

You are very much welcome - but I honestly believe that you've found the solution yourself, I wasn't that much of a help.

Is Bidir-PIM and Phantom-RP compatible with MSDP?

The fun with Bidir-PIM is that the RP is not a device or a function - but merely a direction of multicast flow to reach the so-called RP Link which is a network segment where the RP address sits from the IP routing point of view. However, this IP address does not need to be truly assigned to any device because this device is not performing any special task whatsoever, as opposed to the RP function in PIM-SM. This follows from the different notion of data flow in a Bidir-PIM constructed multicast distribution tree: multicast traffic can flow both up and down all branches of a single distribution tree, thereby creating a true single shared tree for an arbitrary number of senders.

This all in turn means that if there is no real device with the function of RP, there is nothing to do here with MSDP

Because the Anycast-RP is built around the notion of having multiple RPs work in parallel (and thereby back up each other), it not really applicable to Bidir-PIM. In addition, it is probably not a good idea to provide redundancy in Bidir-PIM by advertising the same IP address from multiple routers because that will lead to differently rooted distribution trees and possible issues in multicast stream delivery. The solution here appears to be what Cisco calls Phantom-RP with different netmasks which is nicely described in this document:

http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6552/ps6592/prod_white_paper0900aecd80310db2.pdf

So to sum it up, Anycast-RP using the same IP address and netmask advertised from multiple routers is not an option for Bidir-PIM. The Phantom-RP, on the other hand, is exactly the solution suggested for Bidir-PIM.

Best regards,

Peter

[fsebera]

Hey Peter,

Here is WAN1s' full config.

Comments welcome.

!

Thanks again for your assistance.

Frank

:

WAN1#sh run

Building configuration...

Current configuration : 11979 bytes

!

!

Last configuration change at 14:46:11 EDT Mon Jul 16 2012

!

NVRAM config last updated at 14:46:11 EDT Mon Jul 16 2012

!

configuration mode exclusive auto version 12.4

no service pad

service tcp-keepalives-in

service tcp-keepalives-out

service timestamps debug datetime localtime

service timestamps log datetime localtime

service password-encryption

service sequence-numbers

no service dhcp

!

hostname WAN1

!

security passwords min-length 14

logging buffered 51200 debugging

logging rate-limit console 10

logging console critical

!

clock timezone EST -5

clock summer-time EDT recurring

no ip source-route

no ip gratuitous-arps ip cef

!

ip nbar pdlm flash:bittorrent.pdlm

ip nbar pdlm flash:citrix.pdlm

ip nbar pdlm flash:edonkey.pdlm

ip nbar pdlm flash:sap-app.pdlm

ip nbar pdlm flash:sap-msg.pdlm

ip nbar pdlm flash:winmx.pdlm

!

policy-map CONTROL-PLANE-POLICY

class COPP_2

     police 512000 8000 conform-action transmit

  exceed-action transmit class COPP_4

     police 256000 4000 conform-action transmit

  exceed-action drop class COPP_6

     police 128000 2000 conform-action transmit

  exceed-action drop class COPP_7

     police 8000 1000 conform-action drop

  exceed-action drop class class-default

     police 64000 1000 conform-action transmit

  exceed-action drop

!

!

!

no ip bootp server

no ip domain lookup

ip domain name --removed--

ip multicast-routing

ip multicast auto-enable

ip multicast multipath

ip auth-proxy max-nodata-conns 3

ip admission max-nodata-conns 3

login block-for 65535 attempts 3 within 1800

login quiet-mode access-class LOGIN

login on-failure log

login on-success log

!

ipv6 unicast-routing

ipv6 host WAN3-624 2002:AC10:1E03::1

ipv6 host PE1 172:17:10::2

ipv6 host PE2 172:17:20::2

ipv6 host PE3 172:17:30::2

ipv6 host WAN1-624 2002:AC10:A03::1

ipv6 cef

!

password encryption aes

!

!

ip tcp selective-ack

ip tcp synwait-time 10

ip ssh time-out 30

ip ssh source-interface Loopback0

ip ssh version 2

!

track 500 ip route 172.16.1.0 255.255.255.0 reachability

delay down 5 up 45

!

no crypto isakmp enable

!

!

interface Loopback0

description MGT

ip address 172.16.10.2 255.255.255.255

ip pim sparse-mode

ipv6 address xxxx:xxxx:4F:FFFF:FFFF:FFFF:FFFF:F/128

ipv6 ospf 1 area 0

!

interface Loopback1 description 6to4 ip address 172.16.10.3 255.255.255.255

!

interface Loopback3 description 6TO4 no ip address ipv6 address xxxx:xxxx:4F:FF80::1/60 ipv6 ospf 1 area 0 !

interface Loopback64 description 6TO4 no ip address ipv6 address xxxx:xxxx:4F:FFE1::1/64 ipv6 ospf network point-to-point ipv6 ospf 1 area 0

!

interface Loopback90

ip address 172.31.255.254 255.255.255.255

ip pim sparse-mode

!

interface Loopback99

ip address 172.16.0.98 255.255.255.252

ip pim sparse-mode

ip ospf network point-to-point

!

interface Tunnel2002

description Dynamic 6to4 Tunnel

no ip address

no ip redirects

ipv6 address 2002:AC10:A03::1/128

ipv6 ospf 1 area 0

tunnel source Loopback1

tunnel mode ipv6ip 6to4

!

interface FastEthernet0/0

description DO NOT SHUT

no ip address

load-interval 30

!

interface FastEthernet0/0.5

description BACKUP

encapsulation dot1Q 5

ip address 172.18.250.1 255.255.255.252

ip nbar protocol-discovery

ip pim sparse-mode

ipv6 address 172:18:250::1/126

!

interface FastEthernet0/0.6

description MGT

encapsulation dot1Q 6 native

ip address 192.168.1.1 255.255.255.0

!

interface FastEthernet0/0.10

description To MPLS cloud

encapsulation dot1Q 10

ip address 172.17.10.1 255.255.255.252

ip nbar protocol-discovery

ip pim sparse-mode

ipv6 address 172:17:10::1/126

!

interface FastEthernet0/0.16

description From MPLS cloud

encapsulation dot1Q 16

ip address 172.17.16.1 255.255.255.252

ip nbar protocol-discovery

ip pim sparse-mode

ipv6 address 172:17:16::1/126

!

interface FastEthernet0/0.100

description To CORE1

encapsulation dot1Q 100

ip address 172.16.10.254 255.255.255.252

ip nbar protocol-discovery

ip pim sparse-mode

ip ospf priority 0

ipv6 address xxxx:xxxx:4F:FFFF:FFFF:FFFF:FFFF:1/127

ipv6 ospf 1 area 0

!

router ospf 10

router-id 172.16.10.2

log-adjacency-changes

redistribute connected subnets

redistribute bgp 10 subnets

passive-interface default

no passive-interface FastEthernet0/0.100

network 172.16.0.96 0.0.0.3 area 0

network 172.16.10.2 0.0.0.0 area 0

network 172.16.10.3 0.0.0.0 area 0

network 172.16.10.252 0.0.0.3 area 0

network 172.17.10.0 0.0.0.3 area 0

network 172.31.255.254 0.0.0.0 area 0

!

router bgp 10

bgp router-id 172.16.10.2

no bgp default ipv4-unicast

bgp log-neighbor-changes

neighbor 172:17:10::2 remote-as 65535

neighbor 172:17:16::2 remote-as 65535

neighbor 172:18:250::2 remote-as 20

neighbor 172:18:250::2 description WAN2 via Backup link

neighbor 172:18:250::2 password --removed--

neighbor 2002:AC10:1E03::1 remote-as 30

neighbor 2002:AC10:1E03::1 description 6to4 Tunnel, WAN3

neighbor 2002:AC10:1E03::1 ebgp-multihop 3

neighbor 2002:AC10:1E03::1 password --removed--

neighbor 172.17.10.2 remote-as 65535

neighbor 172.17.16.2 remote-as 65535

neighbor 172.18.250.2 remote-as 20

neighbor 172.18.250.2 description WAN2 via Backup link

neighbor 172.18.250.2 password --removed--

!

address-family ipv4

   redistribute connected

   redistribute ospf 10

   neighbor 172.17.10.2 activate

   neighbor 172.17.10.2 soft-reconfiguration inbound

   neighbor 172.17.10.2 route-map DEFAULT in

   neighbor 172.17.16.2 activate

   neighbor 172.17.16.2 soft-reconfiguration inbound

   neighbor 172.18.250.2 activate

   neighbor 172.18.250.2 soft-reconfiguration inbound

   neighbor 172.18.250.2 route-map BACKUP in

   no auto-summary

   no synchronization

   network 0.0.0.0

   network 172.16.10.0 mask 255.255.255.0

exit-address-family

!

address-family ipv6

   neighbor 172:17:10::2 activate

   neighbor 172:17:10::2 default-originate

   neighbor 172:17:10::2 soft-reconfiguration inbound

   neighbor 172:17:10::2 prefix-list SITESUM out

   neighbor 172:17:10::2 filter-list 1 in

   neighbor 172:17:16::2 activate

   neighbor 172:17:16::2 default-originate

   neighbor 172:18:250::2 activate

   neighbor 172:18:250::2 default-originate

   neighbor 172:18:250::2 soft-reconfiguration inbound

   neighbor 172:18:250::2 prefix-list SITESUM out

   neighbor 172:18:250::2 route-map WAN2-PREPEND in

   neighbor 172:18:250::2 filter-list 2 in

   neighbor 2002:AC10:1E03::1 activate

   neighbor 2002:AC10:1E03::1 prefix-list 6TO4 out

   aggregate-address xxxx:xxxx:4F:FFC0::/58 as-set summary-only

   redistribute connected

   redistribute ospf 1 include-connected

   no synchronization exit-address-family

!

no ip forward-protocol nd

no ip forward-protocol udp netbios-ns

no ip forward-protocol udp netbios-dgm

no ip forward-protocol udp tacacs

ip route 0.0.0.0 0.0.0.0 172.16.10.253 20 track 500

ip route 172.16.10.0 255.255.255.0 Null0

!

ip as-path access-list 1 permit ^65535_ ip as-path access-list 2 permit _20$

!

no ip http server

no ip http secure-server

ip pim bidir-enable

no ip pim dm-fallback

ip pim autorp listener

ip pim send-rp-announce 172.16.0.97 scope 255 group-list MTM bidir

ip pim send-rp-announce Loopback90 scope 255 group-list OTM

ip pim send-rp-discovery FastEthernet0/0.100 scope 255

ip msdp peer 172.16.20.2 connect-source Loopback0

ip msdp default-peer 172.16.20.2 prefix-list OTM-MSDP-PEERS

ip msdp originator-id Loopback0

!

ip access-list standard ADMIN

permit 192.168.xxx.xxx log

permit 192.168.xxx.xxx log

permit 192.168.xxx.xxx log

permit 192.168.xxx.xxx log

permit 192.168.xxx.xxx log deny  any log

ip access-list standard ANY permit any

ip access-list standard LOGIN

permit 192.168.xxx.xxx deny  any log

ip access-list standard MTM

permit 239.255.0.16 0.0.0.15

ip access-list standard NO-ZERO

deny  0.0.0.0

ip access-list standard OTM

permit 239.255.0.0 0.0.0.15

ip access-list extended CRITICAL

remark _____________________________

permit tcp host 172.17.30.1 host 172.17.30.2 eq bgp

permit tcp host 172.17.30.2 host 172.17.30.1 eq bgp

remark Include MFR packets deny

  ip any any ip access-list extended DEFAULT

permit ip any any

ip access-list extended IMPORTANT

remark _____________________________

permit udp host 192.168.xxx.xxx 172.16.xxx.xxx 0.0.xxx.xxx eq snmp

permit ip host 192.168.xxx.xxx 192.168.xxx.xxx 0.0.xxx.xxx

permit udp host 192.168.xxx.xxx 172.16.xxx.xxx 0.0.xxx.xxx eq snmp

permit ip host 192.168.xxx.xxx 192.168.xxx.xxx 0.0.xxx.xxx

permit udp host 192.168.xxx.xxx 172.16.xxx.xxx 0.0.xxx.xxx eq snmp

permit ip host 192.168.xxx.xxx 192.168.xxx.xxx 0.0.xxx.xxx

permit udp host 192.168.xxx.xxx 192.168.xxx.xxx 0.0.xxx.xxx eq snmp

permit udp host 192.168.xxx.xxx 192.168.xxx.xxx 0.0.xxx.xxx eq snmp

permit icmp host 192.168.xxx.xxx 192.168.xxx.xxx 0.0.xxx.xxx

permit icmp host 192.168.xxx.xxx 192.168.xxx.xxx 0.0.xxx.xxx

permit udp host 192.168.xxx.xxx 192.168.xxx.xxx 0.0.xxx.xxx eq ntp

permit pim any any deny  ip any any ip access-list standard WAN2-NETS

permit 172.16.20.0 0.0.0.255 permit 172.16.2.0 0.0.0.255

remark Use the Backup link "Vlan-5" to reach WAN2, if Backup link down, use MPLS Cloud

ip access-list standard ZERO

permit 0.0.0.0

ip access-list extended NET-WK-MGT

permit tcp 192.168.x.x 0.0.x.x 172.x.x.x 0.x.x.x eq 8008

permit tcp 192.168.x.x 0.0.x.x 172.x.x.x 0.x.x.x range 48000 48020

permit icmp host 192.168.xxx.xxx any echo

permit icmp 192.168.x.x 0.0.x.x any echo-reply

permit udp host 192.168.x.x any eq snmp log

permit udp host 192.168.x.x any eq snmptrap log

permit udp host 192.168.x.x any eq snmp log

permit udp host 192.168.x.x any eq snmptrap log

permit udp host 192.168.x.x any eq snmp log

permit udp host 192.168.x.x any eq snmptrap log

permit udp 192.168.x.x 0.0.x.x any eq ntp

permit udp any any eq domain

deny  udp any any eq 5355 log

deny  ip any any log

ip access-list extended NORMAL

remark _____________________________

permit icmp any any echo

permit icmp any any echo-reply

deny  ip any any

ip access-list extended UNDESIRABLE

remark _____________________________

permit udp any any eq ntp

permit udp any any eq snmptrap

permit tcp any any eq 22

permit tcp any any eq telnet

permit eigrp any any

permit ospf any any

permit udp any any eq rip

deny  ip any any

!

!

ip prefix-list OTM-MSDP-PEERS seq 20

permit 172.16.20.2/32

logging history debugging

logging facility syslog

logging source-interface Loopback0

logging 192.x.x.x

logging 192.x.x.x

access-list 1

permit 172.x.x.x 0.x.x.x

access-list 1

deny  any

log snmp-server engineID local xxxxxxxxxxxxxxxx

snmp-server group --snipped-- v3 priv match exact read --gone-- access --removed--

snmp-server view --omitted-- internet included

snmp-server enable traps tty

ipv6 route 2002:AC10:1E03::1/128 Tunnel2002

ipv6 route xxxx:xxxx:4F:FFC0::/58 Null0

ipv6 router ospf 1

router-id 172.16.10.2

log-adjacency-changes

default-information originate always

passive-interface default

no passive-interface FastEthernet0/0.100

!

!

ipv6 prefix-list 6TO4 seq 20 permit 2002:AC10:A03::1/128

ipv6 prefix-list 6TO4 seq 30 permit xxxx:xxxx:4F:FF80::/60

!

ipv6 prefix-list SITESUM seq 20

permit xxxx:xxxx:4F:FFC0::/58

route-map BACKUP permit 10

description Perfer WAN2 nets over backup link. "Permit 20" accepts all other nets.

match ip address WAN2-NETS

set local-preference 150

!

route-map BACKUP permit 15

description Set 0/0 from WAN2 2nd, 1st is from CORE1

match ip address ZERO

set metric 25

set local-preference 50

!

route-map BACKUP permit 20

description Accept all other nets without changing LP match ip address ANY

!

route-map WAN2-PREPEND permit 10

match ipv6 address WAN2-PREPEND

set as-path prepend 10 10 10 10

!

route-map NO-ZERO permit 10

description Don't redistribure 0/0 into OSPF from BGP match ip address NO-ZERO

!

route-map NO-ZERO permit 20

description Redistribure all other nets from BGP into OSPF!

match ip address ANY

!

route-map DEFAULT permit 10

description Set 0/0 from MPLS 3rd, 2nd is WAN2, 1st is from CORE1

match ip address ZERO

set metric 150

set local-preference 10

!

route-map DEFAULT permit 20

description Accept all other nets

match ip address ANY

!

!

ipv6 access-list WAN2-PREPEND

permit ipv6 xxxx:xxxx:4F:FF40::/58 any

!

control-plane

service-policy input CONTROL-PLANE-POLICY

! !

line con 0

exec-timeout 0 1

privilege level 15

logging synchronous

login

line aux 0

access-class 1 in

exec-timeout 0 1

no exec

speed 300

line vty 0 4

session-timeout 5

  output access-class 1 in

exec-timeout 5 0

password --missing--

logging synchronous

login transport input ssh

transport output none

line vty 5 15

session-timeout 5

  output access-class 1 in

exec-timeout 5 0

password --gone--

logging synchronous

login

transport input ssh

transport output none

!

ntp logging

ntp authentication-key --removed-- md5 --deleted--

ntp authenticate

ntp trusted-key --missing--

ntp source FastEthernet0/0.6

ntp server 192.x.x.x

ntp server 172.x.x.x

end

[Peter Paluch]

Hello Frank,

I am writing to ensure you I will have a look at the config you have posted here in a few hours Don't worry, I haven't forgotten you.

Best regards,

Peter

[fsebera]

Hi Peter,

No need to hurry . . . we are enjoying the successful changes with multicast - it's party time!!!

I understand MSDP and Bi-dir PIM are "ships in the night" type technologies. I have read in several different Cisco docs, the two are incompatible however, in our environment (MPLS Hub and Spoke topology) if MSDP fails due to an incorrect configuration not only does "One-to-Many" PIM sparse-mode, Auto-RP and Anycast-RP fail, it really kills our Many-to-Many, Bidir PIM sparse-mode, Auto-RP, Phantom-RP setup as-well.

In summary, both multicast implementations are now operational.

Both are fully (logically) and partially physically redundant.

Failing the primary RP (either Anycast-RP or Phantom-RP) failover functions perfectly, and mostly without end-users noticing.

If you are ready, I can rate and close this request for help!!!

Thanks again for your help.

Frank

[Peter Paluch]

Hello Frank,

So, finally

if MSDP fails due to an incorrect configuration not only does  "One-to-Many" PIM sparse-mode, Auto-RP and Anycast-RP fail, it really  kills our Many-to-Many, Bidir PIM sparse-mode, Auto-RP, Phantom-RP setup  as-well.

I wonder why this should be the case. As MSDP should not influence the operation of your Bidir-PIM at all, I do not see how the failure of MSDP should impact your many-to-many multicast application. Probably I am missing something here...

Regarding the configuration:

• Your BGP configuration uses soft-reconfiguration inbound for several BGP neighbors. In majority of cases, this is not necessary, as all modern BGP implementations support so-called Route Refresh. This "soft-reconfiguration inbound" causes your router to store an unfiltered BGP database, increasing your memory footprint unnecessarily.  I suggest removing it. As a safety precaution, you may issue the show ip bgp neighbor X.X.X.X to find out detailed information about a particular BGP neighbor - look for a line saying "Route refresh: advertised and received". You may find more about the Route Refresh functionality here and here and here
• Your ACL NO-ZERO and route-map NO-ZERO are not designed properly. The ACL should do permit instead of deny. Subsequently, the action of the route-map NO-ZERO block 10 should be changed to deny instead of permit

ip access-list standard NO-ZERO

  permit 0.0.0.0

!

route-map NO-ZERO deny 10

  match ip address NO-ZERO

!

route-map NO-ZERO permit 20

Apart from this, I have no further comments on the current configuration - especially when it works

Best regards,

Peter

[Mohamed Sobair]

Hello Frank & Peter,

I would like to just add one comment to the previous post.

In AnyCast-RP , you Cant have Two different IP Addresses on the Two RPs for the Same Multicast Groups, Therfore, Frank needs to perform the following:

1- Assign a Unique Loopback Address and configure it on both CE routers, So that Both RPs announce themselves with the same Address. the Intended Multicast Recievers chooses the Shortest path RP to create a Shared Based Tree.

2- Having MSDP peering betweeen both RPs (Through Different Interfaces (Addresses) To Synch both Multicast Sources for the Same Groups.

This Setup would work, However, I dont See a benefit of Having AnyCast-RP Connected on different ASs , Specially if there is Only one Single exit point to the MPLS Cloud as Shown by Frank drawing. This is because if One RP fails, the Entire Local domain fails, since the Local Groups will not be able to Reach the redundant RP.

Regards,

Mohamed

[Peter Paluch]

Hello Mohamed,

Hey old friend, how have you been? Haven't seen you posting for a long time. Thanks for joining!

I agree with what you suggest. In fact, I was - up to this point - trying to understand the environment setup Frank is using. I am not sure how Frank configured the AutoRP and the AnycastRP and I am hoping that the configurations will be posted here - so no comments about the configurations until I see them.

Best regards,

Peter