Secondary IP Addresses and Multicast

Unanswered Question
Nov 4th, 2008

Are there any issues I should be concerned about with receiving multicast on interfaces with secondary IP addresses?

Thanks,

Mike

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Richard Burts Wed, 11/05/2008 - 08:35

Mike

I am not aware of any issues with receiving multicast on interfaces with secondary addresses. The processing of multicast and access to multicast is dependent on the broadcast domain. So whether the interface has a single unicast address or has more than one unicast address (through the secondary address) should not impact multicast.

Is there some particular reason for asking? Is there some specific thing that you are trying to address?

HTH

Rick

mikepinto Wed, 11/05/2008 - 10:10

Rick,

Thanks for the reply. It doesn't work on secondary addresses in the configuration I have. I was looking to see if it might be a code issue or can't be done. The secondary IP Address never gets put into being a PIM interface.

Mike

Richard Burts Wed, 11/05/2008 - 10:40

Mike

I am a bit confused. Are you saying that if you configure an interface with ip pim that it does not become a PIM interface if it has a secondary?

Or are you saying that when you have configured the interface with PIM that it identifies the interface using the primary address and not the secondary address?

Perhaps it would help if you would post the interface configuration and what you expect it to do that it is not doing.

HTH

Rick

mikepinto Wed, 11/05/2008 - 10:56

The secondary IP address does not become a PIM interface. I am connecting from a 6504 to 2 seperate routers. The 2 routers are on seperate subnets, but in same vlan. So under the interface VLAN X, the config has a primary ip address going to 'Router 1' and a secondary IP address going to 'Router 2'. The RP and source of the multicast is off of 'Router 2'. This configuration does not work. Multicast traffic does not come down the link of 'Router 2'.

Richard Burts Wed, 11/05/2008 - 11:14

Mike

Would you post the configuration of the interface on Router 2 and of the VLAN interface? It would also help if you would post the output of show ip pim interface.

HTH

Rick

Richard Burts Wed, 11/05/2008 - 14:24

Mike

Thanks for the additional information. Your comment that if you swap primary <-> secondary that it works is interesting and helpful. It is best practice when configuring secondary addresses on router interfaces that routers that connect to each other should both use the same subnet as the primary address. In your current config they are mismatched and when you swap them then they match (for router 2) for the PIM upstream.

Most of the routing protocols need their neighbors to be in the same subnet that they are in. Apparently PIM also has that requirement.

HTH

Rick

mikepinto Wed, 11/05/2008 - 18:18

Rick,

Thanks for the response. I guess then there is no way to provide redundancy in this case without manual configuration changes.

Mike

mlund Thu, 11/06/2008 - 04:36

Hi Mike

The routers are connected in the same vlan but with differnet subnets. Have you thought of moving the secondary address to a new vlan, so it will be the primary address on that. Then it will work.

/Mikael

Richard Burts Thu, 11/06/2008 - 04:37

Mike

A big part of the issue is the implementation that has the connection to router 1 in one subnet and the connection to router 2 in a different subnet but has them both in the same VLAN. Is there a reason why it needs to be that way? Would it be possible to have a separate VLAN per subnet?

HTH

Rick

mikepinto Thu, 11/06/2008 - 06:00

Rick,

The VLAN has to be the same. We have no control over that.

Mike

gnijs Thu, 11/06/2008 - 11:42

You are experiencing a typical problem with secundary addresses. Running multiple subnets on the same VLAN is a bad idea and generates only problems (DHCP, IGP neighbors,etc..), i can say from experience, but i know: it is so easy to add extra ip addresses, no ?

What you could try. Do you have another port that you can configure as router port ?

I know it is messy, but you could try the following:

current situation

int x/x

ip add

ip add secundary

ip pim sparse-mode

suggestion:

int x/x

no switchport

ip add

îp pim sparse-mode

int x/x+1

no switchport

ip add

ip pim sparse-mode

and you connect BOTH interfaces to a switch where you put both interfaces in the same vlan for example.

mikepinto Thu, 11/06/2008 - 12:29

First, i understand the design is flawed, but it can't be changed. I agree with your suggestion, but it can't be done in our case because the links to 'Router 1' and 'Router 2' are trunks.

gnijs Thu, 11/06/2008 - 13:02

Trunks...mmm...another over-the-edge suggestion.

This should resemble your current config:

int vlan 10

ip address 1

ip address 2 secundary

int 1/1 (to router 1)

switchport trunk

switchport allowed vlans 10,12

int 1/2 (to router 2)

switchport trunk

switchport allowed vlans 10,14

==================================

if you have 1 routed interface and 1 switchport interface:

int vlan 10

ip add 1

int 1/3

no switchport

ip add 2

ip pim sparse-dense-mode

int 1/4

switchport access vlan 10

then connect int 1/3 and 1/4 back-to-back with crossed cable ?

mikepinto Thu, 11/06/2008 - 14:26

Thanks for the suggestion. will definitely go with that way as we have no other solution.

Giuseppe Larosa Thu, 11/06/2008 - 11:42

Hello Mike,

I see just the opposite:

ddress Interface Ver/ Nbr Query DR DR

Mode Count Intvl Prior

X.170.X.185 Vlan10 v2/S 2 30 1 X.171.X.190

the Neighbor Count is two so it isn't PIM the issue here the switch has two PIM neighbors but only one of the three devices is elected PIM DR on the segment.

I would look at the unicast routing protocol you use between the switch and the two routers. PIM relies on unicast routing protocol for RPF check.

The problem could be an RPF check failure:

If the switch thinks that unicast traffic directed to the source should be sent to R1 it shouldn't accept traffic from R2.

This can easily happens for example if you use OSPF that doesn't support secondary addresses to build adjacencies.

so verify on switch with:

sh ip route group.source

sh ip rpf group.source

Hope to help

Giuseppe

mikepinto Thu, 11/06/2008 - 12:31

Giuseppe,

You are correct, you do see a neighbor count of 2 on the sh ip pim interface command, but that is from the primary address. The secondary address does not show up as a PIM interface, and thus has no neighbors.

Mike

Actions

This Discussion