My questions are:

Should we setup on our core network switch OSPF with a router ID of 1.1.1.1 and then not set any OSPF settings on any other switch?

OSPF is not necessary for this implementation.

Would PIM Sparse Mode only need to be enabled on the core switches or on all of the switches in the network?

Pim-SM needs to be enabled on each L3 interface on which you want to allow the multicast traffic. For example, if you wish to contain the traffic to Vlans 15 and 14, you would have to do the following on your core:

configure
ip multicast
ip igmp
ip pim sparse
interface vlan 14
ip igmp
ip pim
interface vlan 15
ip igmp
ip pim
exit

If you want the traffic to traverse all Vlans, then you will need the appropriate interface configuration under each Vlan. Your L2 switches will need IGMP snooping turned on (ideally on all interfaces via the global configuration).

configure
ip igmp snooping 
bridge multicast filtering

For a very basic multicast setup like this, these should be the only features that you would need.

The two Windstream Routers each have an MPLS port:

• 192.168.1.2 = Host MPLS
• 192.168.2.2 = Remote MPLS

The Windstream routers also each have an open internet port to which I have attached a Firewall Router for filtering the internet, making the internet gateways:

• 192.168.1.1 = Host Gateway
• 192.168.2.1 = Remote Gateway

Problem Summary

Your problem is that you've got multiple routers on the same subnet:

• The Internet gateway at 192.168.1.1
• The Windstream MPLS router at 192.168.1.2

This is a faulty design; I completely understand that it "seems like" there is nothing wrong with this, but as you're discovering, this is a hard way to build the network.

Following up on our chat discussion, the exact problem is that SAINTJOSEPH's TCP SYN packets are delivered correctly; however, stateful inspection on your PaloAlto firewall drops SAINTSERVIUS' TCP SYN-ACK response, due to asymmetric routing in your environment. This is illustrated in the two following diagrams.

TCP SYN from SAINTJOSEPH to SAINTSERVIUS:

Your PaloAlto firewall drops the TCP SYN-ACK from SAINTSERVIUS to SAINTJOSEPH:

This tracert makes it very clear that SAINTSERVIUS defaults through 192.168.1.1 (the PaloAlto firewall):

Long Term Solutions

You should only have a single router next-hop for every subnet; however, you currently have two. This results in the drops shown in your wireshark screen capture (which indicates that TCP SYN-ACK packets never reach Windstream's MPLS network).

These are two long-term solutions which we discussed... I'm also including the quick hack we did to validate that the problem is stateful packet drops on the PaloAltos. I am assuming you are using multiple interfaces on the PaloAlto.

• Option A: Keep the PaloAlto firewalls inline with your interoffice connections (more maintenance)
• Option B: Move the PaloAlto firewalls in front of the internet connections (less maintenance, but also less comfortable)
• Option C: Quick Windows static routing hack

Better Design, Option A (MPLS re-addressing required)

This is a another way to lay out the subnet for SAINTSERVIUS (retaining your numbering scheme with /23 subnets, although it's not required...). This option keeps interoffice routing on the PaloAlto firewalls, which feels more familiar to you right now.

This is a long-term solution. You would have to work with Windstream to readdress your infrastructure. This is a lot of work. In my opinion, keeping the firewalls in the middle of your interoffice traffic is less preferable.

Better Design, Option B (MPLS re-addressing required)

This is a another way to lay out the subnet for SAINTSERVIUS (retaining your numbering scheme with /23 subnets, although it's not required...). This option offloads interoffice LAN routing to your PowerConnect switches, and relies on the PaloAlto firewalls to protect against internet threats.

This is a long-term solution. You would have to work with Windstream to readdress your infrastructure. This is a lot of work, but it offers the advantage of not having to deal with firewalls for your interoffice communication.

Suboptimal Workaround, Option C (what you used after our chat)

Open a cmd.exe window and add this route on SAINTSERVIUS as the Administrator:

route ADD 192.168.2.0 MASK 255.255.254.0 192.168.1.2

Closing remarks

I should mention that you are one of the few people who followed through with sufficient details about your question When you started, we didn't have enough details to answer the question. Now, the issues are very clear; thank you for putting the time / effort into documenting the problem well.

Personal note: If you would like an electronic copies of the diagrams as SVG / Inkscape format, please feel free to contact me at my personal email (listed in my user profile).