IP Helper between VRF (again)

lpassmore · ‎03-27-2013

Hi team

I see there has been several discussions around the use of the IP Helper-address command to direct broadcast traffic between VRF instances; most to do with DHCP. I have a similar question (not about DHCP for a change) but would just like clarification please.

I have the following configuration on some 4900M switches running version 15.1(2)SG

Int VLAN 100

ip vrf forwarding Prod-Client

ip address 192.168.1.2 255.255.255.0

standby ip 192.168.1.1

ip directed-broadcast

ip helper-address vrf Mobile-Client 192.168.2.255

ip pim sparse-mode

Int VLAN 200

ip vrf forwarding Test-Client

ip address 192.168.2.2 255.255.255.0

standby ip 192.168.2.1

ip directed-broadcast

ip pim sparse-mode

I also have the appropriate ip forward-protocol command configured (that escapes me for the moment).

The intent is to get a particular broadcast packet from the Prod-Client VRF into the Test-Client VRF, but it is imperative that no other traffic is able to be transmitted between the two environments. In fact no traffic is permitted out of the environments (with the exception of the particular broadcast).

During testing we found that this would work correctly if we placed the Prod-Client VLAN into the global VRF (ie no ip vrf forwarding statement). In this case the broadcast was successfully received within the Test-Client Network. When we place the Prod-Client VLAN back into a separate VRF, this stops working.

There is no requirement to get return traffic as a result of the broadcast. We are really trying to save the cost of purchasing a second (very expensive) device but wish to use the information it generates within the Test environment.

The ip pim... statements are required because there are also multicast streams present within the environments. The multicast streams are separate within each VRF and are not required to span the environments. Multicast is not the issue but I have included in case it is somehow relevant,

Can I get a statement from somebody who knows whether this should work or whether I am trying to do something that cannot be made to work?

Many Thanks

LP

blau grana · ‎03-27-2013

Hello,

Int VLAN 100

ip vrf forwarding Prod-Client

ip address 192.168.1.2 255.255.255.0

standby ip 192.168.1.1

ip directed-broadcast

ip helper-address vrf Mobile-Client 192.168.2.255

ip pim sparse-mode

Int VLAN 200

ip vrf forwarding Test-Client

ip address 192.168.2.2 255.255.255.0

standby ip 192.168.2.1

ip directed-broadcast

ip pim sparse-mode

What are you exactly trying to achieve? I see that you have configured 3 VRFs [Test-Client, Mobile-Client, Prod-Client]. Also you have used broadcast address with ip helper command -> ip helper-address vrf Mobile-Client 192.168.2.255

I have tested scenario with two VRFs. I managed to send broadcast from one VRF to another, but I was not able to send traffic back.

I used this router and software:

Cisco IOS Software, 3700 Software (C3725-ADVIPSERVICESK9-M), Version 12.4(25b), RELEASE SOFTWARE (fc1)

Best Regards

Please rate all helpful posts and close solved questions

Best Regards Please rate all helpful posts and close solved questions

lpassmore · ‎03-27-2013

Hi and thanks for spotting the deliberate typo. The correct code is below, and this does not seem to work on the 4900M platform.

Int VLAN 100

ip vrf forwarding Prod-Client

ip address 192.168.1.2 255.255.255.0

standby ip 192.168.1.1

ip directed-broadcast

ip helper-address vrf Test-Client 192.168.2.255

ip pim sparse-mode

Int VLAN 200

ip vrf forwarding Test-Client

ip address 192.168.2.2 255.255.255.0

standby ip 192.168.2.1

ip directed-broadcast

ip pim sparse-mode

The exact aim is to get a particular broadcast packet from VLAN 100 (vrf Prod-Client) into VLAN 200 (vrf Test-Client).

It is interesting that the command works on a 3725 although they are quite old now so maybe Cisco have changed the way this command is intended to work.

blau grana · ‎03-28-2013

Hello,

I have not available c4900, so I tried it with:

SW2#sh ver | i IOS

Cisco IOS Software, C3560 Software (C3560-IPSERVICESK9-M), Version 12.2(55)SE5, RELEASE SOFTWARE (fc1)

And result was the same as with 3725, broadcast is relayed from one vrf to other, but nothing goes back.

One more time, 192.168.2.255 is broadcast for VLAN200, is this typo again or did you do it on purpose?

Int VLAN 100

ip vrf forwarding Prod-Client

ip address 192.168.1.2 255.255.255.0

standby ip 192.168.1.1

ip directed-broadcast

ip helper-address vrf Test-Client 192.168.2.255

ip pim sparse-mode

Best Regards

Please rate all helpful posts and close solved questions

Best Regards Please rate all helpful posts and close solved questions

lpassmore · ‎04-01-2013

Thanks for your testing blau grana. You seem to be going an extra step to help and it is much appreciated. So it works on a 3725 and 3560, but still not on our 4900M. I guess this maybe pointe to a bug in the 4900M software or an unsupported feature that has been implemented differently on different platforms.

192.168.2.255 is not a typo. The idea is to get the broadcast from the 192.168.1.x network and re-broadcast it into the 192.168.2.x network (as a broadcast).

Wouldn't mind hearing from Cisco to see if it is a supported configuration, or perhaps from somebody who has access to a 4900M or perhaps 4500 series to see if it works on their equipment.

blau grana · ‎04-01-2013

I see, I thought you would like to forward broadcast to specific host, not as broadcast to another network. I am afraid that this can not be done with ip helper-address, because it forwards broadcast as unicast to specific IP, so configuring broadcast address as destination probably will not be supported.

Try this, maybe it will work with your VRF scenario:

http://www.netcontractor.pl/blog/?p=945

Best Regards

Please rate all helpful posts and close solved questions

Best Regards Please rate all helpful posts and close solved questions

lpassmore · ‎04-02-2013

Many thanks again for trying to help.

fyi, though, you certainly can use the ip helper-address command to send to the broadcast address and it does work - just not between VRF instances it seems. It is working beautifully between interfaces within the same VRF, and it also worked when we tried from the global VRF into an instance; just not between 2 different VRF instances.

Never mind. I will raise TAC case and see if they have anything to say.

Cheers

LP