Multicast Routing Between Sites 3

[Jimtron26]

Hi all,

I am having problems with routing multicast traffic between three sites. Two of the sites (BFD/ FOR) are connected back to the third (RIV) using 100Mb connections as follows:

BFD-----RIV-----FOR

The connections between sites were originally Layer 2 and we had a nightmare with all multicast and broadcast traffic traversing the link and flooding to each sites. To prevent this, I enabled Layer 3 point to point routing between them which works fine. However, I now have a problem whereby I cannot route specific multicast traffic between sites which is required for Paging on an IP telephone system the customer uses. I need to send Pages across from BFD to RIV and FOR on Multicast address 224.0.1.41, however, despite hours spent researching, I cannot get my head around how to do it... What is more annoying is I am sure I have done this somewhere but can`t remember it/ where/ find documentation etc!!!

Configs.... (please ignore the non-RFC IP on BFD, its not my network ))

BFD SWITCH
Building configuration...

Current configuration : 2824 bytes
!
version 12.1
no service pad
service timestamps debug uptime
service timestamps log datetime
service password-encryption
service sequence-numbers
no service dhcp
!
hostname BFD
!
enable secret level ******
enable secret ******
!
username ****** password ******
!
ip subnet-zero
ip routing
!
spanning-tree mode pvst
spanning-tree extend system-id
!
interface FastEthernet0/1
switchport mode dynamic desirable
!
interface FastEthernet0/2
switchport mode dynamic desirable
!
******OUTPUT OMITTED******
!
interface FastEthernet0/22
switchport mode dynamic desirable
!
interface FastEthernet0/23
switchport mode dynamic desirable
!
interface FastEthernet0/24
description LINK TO RIV
no switchport
ip address 172.16.1.6 255.255.255.252
speed 100
duplex full
!
interface GigabitEthernet0/1
switchport mode dynamic desirable
!
interface GigabitEthernet0/2
switchport mode dynamic desirable
!
interface Vlan1
ip address 192.0.0.3 255.255.0.0
!
interface Vlan2
no ip address
!
ip classless
ip route 0.0.0.0 0.0.0.0 192.0.0.230
ip route 10.10.0.0 255.255.0.0 172.16.1.5
ip route 192.168.0.0 255.255.0.0 172.16.1.5
ip http server
!
snmp-server community ****** RW
!
end

RIV SWITCH
Building configuration...

Current configuration : 3053 bytes
!
version 12.1
no service pad
service timestamps debug uptime
service timestamps log datetime
service password-encryption
service sequence-numbers
no service dhcp
!
hostname RIV
!
aaa new-model
aaa authentication login HUB_AUTH local
enable secret ******
!
username ****** password ******

clock timezone GMT 0
clock summer-time GMT recurring last Sun Mar 1:00 last Sun Oct 2:00
ip subnet-zero
ip routing
!
!
spanning-tree mode pvst
spanning-tree extend system-id
!
interface FastEthernet0/1
switchport mode dynamic desirable
!
interface FastEthernet0/2
switchport mode dynamic desirable
!

******OUTPUT OMITTED******

!
interface FastEthernet0/21
switchport mode dynamic desirable
!
interface FastEthernet0/22
switchport mode dynamic desirable
!
interface FastEthernet0/23
description Link To BFD
no switchport
ip address 172.16.1.5 255.255.255.252
speed 100
duplex full
!
interface FastEthernet0/24
description Link To FOR
no switchport
ip address 172.16.1.1 255.255.255.252
speed 100
duplex full
!
interface GigabitEthernet0/1
description Uplink To Core
switchport mode dynamic desirable
!
interface GigabitEthernet0/2
switchport mode dynamic desirable
!
interface Vlan1
ip address 10.10.27.3 255.255.0.0
!
interface Vlan2
no ip address
!
ip default-gateway 10.10.27.2
ip classless
ip route 0.0.0.0 0.0.0.0 10.10.10.32
ip route 192.0.0.0 255.255.0.0 172.16.1.6
ip route 192.168.0.0 255.255.0.0 172.16.1.2
ip http server
ip http authentication local
!
snmp-server community ****** RW
!
end

FOR SWITCH
Building configuration...

Current configuration : 2820 bytes
!
version 12.2
no service pad
service timestamps debug uptime
service timestamps log uptime
service password-encryption
!
hostname FOR

enable secret ******
!
username ****** privilege 15 password ******
aaa new-model
aaa authentication login FORAUTHEN local
aaa authorization network FORAUTHEN local
!
aaa session-id common
ip subnet-zero
ip routing
no ip domain-lookup
!
!
!
!
no file verify auto
spanning-tree mode pvst
spanning-tree extend system-id
!
vlan internal allocation policy ascending
!
interface FastEthernet0/1
!
interface FastEthernet0/2
!
interface FastEthernet0/3

******OUTPUT OMITTED******

interface FastEthernet0/45
!
interface FastEthernet0/46
!
interface FastEthernet0/47
!
interface FastEthernet0/48
description Link to RIV
no switchport
ip address 172.16.1.2 255.255.255.252
speed 100
duplex full
!
interface GigabitEthernet0/1
!
interface GigabitEthernet0/2
!
interface GigabitEthernet0/3
!
interface GigabitEthernet0/4
!
interface Vlan1
ip address 192.168.3.3 255.255.0.0
!
ip classless
ip route 0.0.0.0 0.0.0.0 10.10.10.32
ip route 10.10.0.0 255.255.0.0 172.16.1.1
ip route 192.0.0.0 255.255.0.0 172.16.1.1
ip http server
!
snmp-server community ****** RW
radius-server source-ports 1645-1646
!
control-plane
!
end

Thank you all in advance for any help provided.

Jim

 

[unclerico]

you need to enable multicast routing on each switch:

Switch(config)# ip multicast-routing

Then on each interface you want to route the multicast traffic you need to enable PIM. The easiest thing to do in this situation is to enable sparse-dense-mode. You need to do this on every layer 3 interface:

BFD(config)# int f0/24
BFD(config-if)# ip pim sparse-dense-mode
BFD(config)# int vlan 1
BFD(config-if)# ip pim sparse-dense-mode

RIV(config)# int range f0/23 - 24
RIV(config-if)# ip pim sparse-dense-mode 
RIV(config)# int vlan 1
RIV(config-if)# ip pim sparse-dense-mode

FOR(config)# int f0/48
FOR(config-if)# ip pim sparse-dense-mode
FOR(config)# int vlan 1
FOR(config-if)# ip pim sparse-dense-mode

You can also use just sparse mode or just dense mode if you like, but sparse mode requires more configuration. Sparse-dense mode will use dense mode by default if no rendezvous-points or bootstrap routers are configured. I hope I'm not confusing you.

I hate all Uppercase... I don't want my groups to seem angry at me all the time! =)
- ColdFlame (vbscript forum)

 

[Jimtron26]

Hi Unclerico

Thank you for your response and no, that is fine and makes sense.

Will this config forward all multicast traffic between sites? I am hoping to restrict it to 224.0.1.41 only

Kind regards

Jim

 

[unclerico]

Yes as it is it will route all multicast traffic. You can do something called source-specific multicast to limit it to what sources are allowed as long as your switches have an IOS that supports IGMPv3, which requires as least 12.1(5)T.

To configure SSM, in addition to the above config, do the following (do the first two commands on all switches):

Switch(config)# access-list 1 permit 224.0.1.41
Swtich(config)# ip pim ssm range 1

BFD(config)# int f0/24
BFD(config-if)# ip igmp version 3
BFD(config)# int vlan 1
BFD(config-if)# ip igmp version 3

RIV(config)# int range f0/23 - 24
RIV(config-if)# ip igmp version 3 
RIV(config)# int vlan 1
RIV(config-if)# ip igmp version 3

FOR(config)# int f0/48
FOR(config-if)# ip igmp version 3
FOR(config)# int vlan 1
FOR(config-if)# ip igmp version 3

This should work just fine for you.

I hate all Uppercase... I don't want my groups to seem angry at me all the time! =)
- ColdFlame (vbscript forum)

 

[Jimtron26]

Nice one unclerico, thank you very much for this! Most appreciated.

I will give it a try and let you know the outcome

Jim

 

[burtsbees]

What does BFD stand for?lol

Burt

 

[ADB100]

IGMP v3 is a host thing isn't it and it needs to be implemented in the hosts IP stack? Hosts send IGMP v3 membership reports (joins) that include source(s) they wish to receive the mcast traffic from. Simply enabling IGMP v3 on your interfaces won't enable SSM unless the hosts are IGMP v3 capable, plus the hosts need to send v3 specific joins.

I would also steer away from Dense-Mode as you will get periodic floods of multicast traffic to all multicast enabled interfaces due to the way dense-mode works. If that is what you were trying to avoid....

Andy

 

[unclerico]

Andy, you are correct. I guess I just assumed that Jim's hosts were running newer OS's that support IGMPv3 (XP and up are set to use v3 by default, not 100% sure about Linux hosts though). You also bring up another good point, sparse-mode is required to run SSM, I totally spaced on that.

Jim, since your environment is pretty small I would configure a static rendezvous point (if your environment grows it would be best to do auto-rp):

BFD(config)# ip pim rp-add 172.16.1.6

RIV(config)# ip pim rp-add 172.16.1.6

FOR(config)# ip pim rp-add 172.16.1.6

Did I forget anything else?? LOL

I hate all Uppercase... I don't want my groups to seem angry at me all the time! =)
- ColdFlame (vbscript forum)

 

[Jimtron26]

Cheers for the contributions Andy/ unclerico, I am checking with the manufacturers of the voip system to determine what version of IGMP the hosts run.... and yes, thanks, Andy, I am trying to avoid lots of multicast traffic traversing the WAN

Can the RP address be any address unclerico, or is that just an example?

Burt - BFD stands for Bradford... a delightfully quaint little town in Yorkshire, UK.... ;o)

Thank you all

Jim

 

[unclerico]

The RP *should* be the most centrally located router in your topology.

I'm gonna chuck a star at Andy now lol

I hate all Uppercase... I don't want my groups to seem angry at me all the time! =)
- ColdFlame (vbscript forum)

 

[ADB100]

Bradford, Rivington & Formby? If it is then your not for from me

With regards to SSM & IGMP v3 it requires a bit more than just making sure the hosts are running a stack that supports it. URLs and applications must be coded to make use of IGMP v3. I'd suggest reading up on it ...

With regards to RP placement, it really depends on where the sources & receivers are, plus the bandwidth used by the mcast streams. In a WAN environment like yours I would recommend a core router, however don't take this as a hard and fast rule.
Since this is VoIP and the mcast address is for H.323 Gatekeeper Discovery this is very minimal traffic. Is it an Ericsson/Aastra deployment by any chance?

Andy

 

[Jimtron26]

Thank you both again

All sites located in Bradford and Leeds! The other two are names of buildings (I think!!). Lol good guess though!

I will do some further research now I know what I am looking at, spent hours looking at the wrong thing!

The VoIP system is a SpliceCom Maximiser, the hosts are the IP hardphones and the multicast address is used to send pages/ tannoys to from one site to another. GK discovery and registration is also to this address as is BLF, however, this is done locally at each site (one server per site).

The traffic will only be apparent when someone pages from one site to another which, I think, happens only a couple of times a day but is considered a mission critical feature!

 

[ADB100]

Be careful with sharing and overlapping multicast addresses.... You shouldn't really be using the same multicast address for two applications - namely H.323 Gatekeeper Discovery and your tannoy system. This will result in your hosts receiving multicast traffic they don't require - i.e. a H.323 terminal trying to discover the H.323 Gatekeeper will receive your tannoy traffic.

For a bit of background:
Addresses in the range 224.0.0.0/24 are link local (i.e. they should never be transmitted with a TTL greater than 1. Their official title is 'Local Network Control Block' and are used for things like routing protocols (OSPF, EIGRP) and when sending to 'all multicast routers' or 'all multicast hosts'. Multicast range 224.0.1.0/24 are considered 'Internetwork Control Block'. These are fixed addresses that you should use only if you are implementing the particular protocol - in your case H.323 Gatekeeper Discovery on 224.0.1.41.

For your tannoy system you should really be using a completely different range such as 239.10.10.0/24. Really you should put together a multicast addressing design as in big multicast networks the addressing is equally as important as the unicast IP addressing.
You also need to be careful with the overlapping MAC address issue in Layer-2 switched networks:

When calculating a Multicast MAC address from the Layer-3 IP address there isn't a one-to-one mapping, I won't explain the history behind this but basically there are only 23-bits of the 48-bit MAC address to play with. The first 25-bits are reserved. All 48-bit IP Multicast MAC addresses begin with the binary bits:

00000001 00000000 01011110 0xxxxxxx xxxxxxxx xxxxxxxx

01:00:5e:x in hex - The 'x' being the 1st bit of the byte being set to '0'.

You then map the last 3 octets of the IP address to the last 3 octets of the MAC but ignoring the 1st bit. This results in each Multicast MAC address mapping to 32 IP Multicast Addresses:

224.1.1.1
224.128.1.1
225.1.1.1
225.128.1.1
.
.
.
238.1.1.1
238.128.1.1
239.1.1.1
239.128.1.1

All these multicast IP Address map to the multicast MAC address 0x0100.5e01.0101 so applications or addressing not chosen well can have undesired effects.

HTH

Andy

 

[burtsbees]

That's not what I had in mind for BFD...lol

Burt

 

[Jimtron26]

Ran Wireshark from PC running the softphone App, IGMP version on this system is version 2 (

Is there any other method of achieving what I need?

Many thanks

Jim

 

[Jimtron26]

Cheers for info Andy, had fun bending my brain around Multicast MAC to IP mapping for BSCI!

Unfortunately, whilst I understand the warnings for using the same address for multiple functions, the address allocated is done by the manufacturer and is (as far as I know at least!) out of my control

Many thanks

Jim

 

[ADB100]

Unfortunately, whilst I understand the warnings for using the same address for multiple functions, the address allocated is done by the manufacturer and is (as far as I know at least!) out of my control

In Cisco CallManager the music on hold feature can use multicast and the address range & port numbers can be changed, I am not sure about any paging features though as CCM isn't really my bag. However I'd be a bit surprised if the manufacturer made the tannoy multicast clash with H.323 gatekeeper discovery by design?

Andy

 

[Jimtron26]

Lol unfortunately this appears to be the case...!

MoH uses 224.0.1.51, which at least, is different from the H.323 gatekeeper discovery address...

Re: IGMP version 2 is used by hosts on the system, is there another way I can route specific Multicast traffic between sites? I doubt very much they will change this for my particular problem...

 

[Jimtron26]

I have done some more digging... the 224.0.1.41 address is used for H323 registration requests, BLF info and paging. H3232 registration requests use port 1716, BLF uses port 1717 and paging is various dynamic ports.

Going back to unclerico`s post

Switch(config)# access-list 1 permit 224.0.1.41
Swtich(config)# ip pim ssm range 1

Would it be possible to use an extended ACL to prevent the registration and BLF info from traversing the WAN?

Switch(config)# access-list 101 deny udp host 224.0.1.41 any eq 1716
Switch(config)# access-list 101 deny udp host 224.0.1.41 any eq 1717
Switch(config)# access-list 101 permit ip host 224.0.1.41 any
Swtich(config)# ip pim ssm range 1

Or something similar.....?

 

[ADB100]

No, because you are not using IGMP v3 (SSM is integral to IGMP v3). You could configure some IP filtering on your WAN routers to stop that specific traffic if you are that worried about it. How much traffic are we talking about? Is it really an issue?

Andy