Hi Steven,
Some responses in-line.
- Why the RP multicast only configured in two IPN devices, why not configure over 4 IPN devices?
You can have as many phantom RPs as you like. Most example configs show 2 as they typically only have 2 IPN devices in lab environments.
- Do we configure RP on two IPN devices in POD-1 or 2 or better to configure one of device in POD-1 and another one in POD-2? What is the best?
Think about redundancy. If you have only two pods and will never grow then it probably doesn't matter as you don't need multicast to work if you lose Pod 1, but what if you expand to a third pod. In this case you will want your RPs spread across sites.
- How can I decide the RP is primary or secondary, is it through specific subnet as mentioned in the attached (/32 prefer than /30)?
Typically we use Phantom RP, and the Phantom IP address is in a subnet that all RPs have configured as a loopback interface (with OSPF network type point-to-point). The length of the mask determines who is the RP for this multicast group range. Long match wins. (When I say is the RP, they are really just the shared reference point for the tree, it isn't PIM Sparse Mode with registers, shared tree, SPT etc).
- In Cisco live document, they recommend to increase the OSPF cost, Do we need increase the cost for all the interface faced the spines?
This would be talking about the fact that the spines are not PIM routers participating in our PIM BiDir. They are IGMP clients and they will not forward multicast between IPN facing interfaces. Therefore you need to increase the OSPF cost on these links to avoid traffic attempting to route between IPN nodes back via a spine. So yes, I would increase the cost on all IPN to spine links to something higher than every possible path between IPN nodes.
- Regarding DHCP relay ip address “ip dhcp relay address 10.101.0.2” how I can get this IP address?
This is the IP of an APIC in Pod 1. The Pod 2 spine needs to have it's DHCP forwarded to an APIC in pod 1 to complete discovery.
- Regarding Vlan4, if the servers used Vlan 4 how can use it for multi-POD in the same time?
VLANs are significant to the switch by default, and the spine is not going to have any of your leaf encap VLANs deployed on it.
Create a new static VLAN Pool with VLAN 4 in it, assign it to a new Routed Domain, assign that to an AEP, and assign that to the Policy Group attached to the Spine interface profile's interface selector. VLAN 4 used for multi-pod will not clash with VLAN 4 being used on a leaf.
