I've two sites connect with cisco 878 (sdsl) in bridging mode. At the main office site I have a ts cluster with a virtual mac adres with ip 10.0.5.30. Here I can connect to this IP. At the remote site I can connect to each ts server but not to the IP address of the cluster. Appearantly the problem is the virtual mac address is not distributed. How can this be solved so I can connect from the remote office using the cluster address with the virtual mac address ?
If the "virtual MAC" is from a Microsoft NLB cluster set for IGMP Multicast (01:00:5e:...), then you may need to configure static MAC address entries in the bridges.
This is a tough one...I would try and monitor the traffic. Try to generate some traffic from remote location and see if the remote switch is flooding the frames to all the ports, debug on remote router and see what the router does with the frames it receives from the remote PC.
Make sure the remote router sends the packet to the ATM interface. Debug on the local router and check if that router is receiving frames from the WAN and sends it to the LAN.
Post the debugs and we'll see if we can pinpoint the cause of why traffic is not going through.
Default behavior for WLBS is to mask the source MAC of the cluster and force switches to flood the traffic to all the ports, this is the reason you do not see the source vmac in any bridging tables.
Any options of moving the TS cluster to a routed subnet locally? This will prevent sending unknown unicast frames across the WAN.
Yes, the WLBS was flooding all ports so I configured the 3560 switch ( main site ) with a static mac address bound to the correct Gi ports. At the remote site there is no traffic going to the ATM interface when using the cluster IP address. The ARP table is showing the IP and mac address of the WLBS. Can the bridge be configured with mac address forwarding ? Another problem is that the telco is managing the 878 routers and they have no idea themselves.
I'm not sure if you can configure bridge with static MAC...never seen this config on the router...
Can you configure remote switch with static MAC bound to the router port to make sure the router gets the traffic? I hope if it gets it should flood it to the WAN...
At the Catalyst 500 : there is also a wireless access point. In the access point I look at the arp table. There is no reference to my cluster ip address. After doing a ping ( with no result ) the IP address and mac address is in the arp table. So this address is coming from the catalyst 500 and the C500 is receiving it from the 878 router. But it seems to stop at the ethernet port and not being relayed to the atm port.
This is a nice piece of information... the issue here is that when the access point receives the MAC address in the PAYLOAD of the ARP reply from the cluster, the reply frame source MAC address is masked to make sure that the traffic to the cluster is flooded. So your 500 switch has no clue about the source MAC of the arp reply. When the access point is sending ping with destination of MAC from the ARP cache the switch has to flood the traffic to all the ports so in theory the router should get that frame but we do not know for sure... Can you capture traffic on any other pc at the site to see if it sees the flooded traffic?
Note When the local router must send a packet to the virtual IP address, the local router uses address resolution protocol (ARP) to determine the virtual IP's MAC address. WLBS replies to these ARP requests. When you mask the source MAC address, the ARP response from WLBS has a substitute source MAC address in the Ethernet frame, but contains the correct cluster MAC address in the ARP header. Some routers cannot make this ARP mapping and must make a static ARP entry in the router. For additional information about static ARP requirements, click the following article number to view the article in the Microsoft Knowledge Base:
197862 (http://support.microsoft.com/kb/197862/) WLBS cluster is unreachable from outside networks
The cluster uses a multicast MAC address that is mapped to a unicast IP address. The switch does not associate the multicast MAC addresses to a port, so the switch sends frames to this MAC address on all the ports. IP Multicast pruning implementations cannot limit the port flooding, therefore you must use a virtual LAN. Multicast provides no advantage over unicast from the switches perspective. The increased multicast processing overhead for routers and switches may lead to slower performance. Carefully analyze the effect on your network when you uses multicast to avoid congesting other network devices.