Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Mladen
Participant

Mulitcast configuration CP3600 R81 without RP router

Hi everyone,

I have a scenario when 2 directly connected PC/Servers to a CP 3600 R81 Security Gateway send multicast traffic that is supposed to be received on 3rd directly connected server, but to no success.

I have an error log that sais: "IP multicast routing failed (missing OS route)" while Static Multicast Default route is edited so it points to the 3rd server IP.

PIM enabled with IGMP v2 but still no go.

There is no Rendezvous Point (or any other device in between Security Gateway and PC/Servers) - this is testing enviroment.

Any help is appreciated.

Thank you

0 Kudos
13 Replies
Mladen
Participant

Update:

Just as I enabled Bootstrap router option with no other configurables, my error changed to 

"IP multicast routing failed (too many packets received before route was resolved)".

As mentioned above, multicast route exists as described.

Any help.

0 Kudos
Chris_Atkinson
Employee Employee
Employee

Is PIM enabled on the in & out interface?

Does the security policy have rules allowing the multicast traffic?

Refer also sk169612

CCSM R77/R80/ELITE
0 Kudos
Mladen
Participant

Hi Chris,

Thanks for the reply.

Yes PIM is enabled on all 3 interfaces. Eth1 and 2 are the source interfaces while Eth3 is the OUT interface. All IGMP versions are matching (V2 - no other configurations done here).

As for the rules, it is a testing scenario and the request is such that only one-way multicast traffic is allowed, so rule is in place that allows all interfaces to send to multicast range 224.0.0.0 - 239.255.255.255 (cleanup rule is changed to allow also in this initial phase).

I cant find anywhere a simple setup as mine as an example.

Thank you in advance 

0 Kudos
Mladen
Participant

Also, basic connectivity is working. I can ping each interface.

0 Kudos
Mladen
Participant

Hi everyone,

Still no change but one interesting thing, in an output from fw monitor -e "net(239.0.0.0, 8), accept;"

I get just the 'i' when it come to FW layer, no 'I' 'o' 'O'

 

eth1:i[44]: 10.41.8.4 -> 239.0.1.2 (UDP) len=58 id=12938
UDP: 59286 -> 20480
[vs_0][fw_2] eth1:i[44]: 10.41.8.4 -> 239.0.1.2 (UDP) len=58 id=12941
UDP: 59286 -> 20480
[vs_0][fw_2] eth1:i[44]: 10.41.8.4 -> 239.0.1.2 (UDP) len=58 id=12944
UDP: 59286 -> 20480
[vs_0][fw_2] eth1:i[44]: 10.41.8.4 -> 239.0.1.2 (UDP) len=58 id=12948
UDP: 59286 -> 20480
[vs_0][fw_2] eth1:i[44]: 10.41.8.4 -> 239.0.1.2 (UDP) len=58 id=12951
UDP: 59286 -> 20480
[vs_0][fw_0] eth3:i[28]: 10.10.101.2 -> 239.255.255.250 (2) len=28 id=13778

[vs_0][fw_0] eth3:I[28]: 10.10.101.2 -> 239.255.255.250 (2) len=28 id=13778

[vs_0][fw_2] eth1:i[44]: 10.41.8.4 -> 239.0.1.2 (UDP) len=58 id=12954
UDP: 59286 -> 20480
[vs_0][fw_1] eth3:i[28]: 10.10.101.2 -> 239.0.1.2 (2) len=28 id=45232

[vs_0][fw_1] eth3:I[28]: 10.10.101.2 -> 239.0.1.2 (2) len=28 id=45232

[vs_0][fw_2] eth1:i[44]: 10.41.8.4 -> 239.0.1.2 (UDP) len=58 id=12956
UDP: 59286 -> 20480
[vs_0][fw_2] eth1:i[44]: 10.41.8.4 -> 239.0.1.2 (UDP) len=58 id=12930
UDP: 59286 -> 20480
[vs_0][fw_2] eth1:i[44]: 10.41.8.4 -> 239.0.1.2 (UDP) len=58 id=12958
UDP: 59286 -> 20480
[vs_0][fw_2] eth1:i[44]: 10.41.8.4 -> 239.0.1.2 (UDP) len=58 id=12960
UDP: 59286 -> 20480
[vs_0][fw_2] eth1:i[44]: 10.41.8.4 -> 239.0.1.2 (UDP) len=58 id=12962
UDP: 59286 -> 20480
[vs_0][fw_2] eth1:i[44]: 10.41.8.4 -> 239.0.1.2 (UDP) len=58 id=12964
UDP: 59286 -> 20480
[vs_0][fw_2] eth1:i[44]: 10.41.8.4 -> 239.0.1.2 (UDP) len=58 id=12968
UDP: 59286 -> 20480
[vs_0][fw_2] eth1:i[44]: 10.41.8.4 -> 239.0.1.2 (UDP) len=58 id=12971
UDP: 59286 -> 20480
^C monitor: caught sig 2
monitor: unloading

Any thoughts?

 

 

0 Kudos
the_rock
Legend
Legend

Do fw up_execute command on the firewall for src, dst and protocol and see what it shows.

https://sc1.checkpoint.com/documents/R81/WebAdminGuides/EN/CP_R81_CLI_ReferenceGuide/Topics-CLIG/FWG...

Mladen
Participant

Hi, thank you for your reply, I did the command and here is the output: (both src -> multicast and src -> dst (listener))

[Expert@CIMACT_FW:0]# fw up_execute src=10.41.8.4 dst=239.0.1.2 ipp=103
Rulebase execution ended successfully.
Overall status:
----------------
Active clob mask: 0
Required clob mask: 0
Match status: MATCH
Match action: Accept

Per Layer:
------------
Layer name: CIMACT_policy_package Network
Layer id: 0
Match status: MATCH
Match action: Accept
Matched rule: 5
Possible rules: 5 6 16777215

[Expert@CIMACT_FW:0]# fw up_execute src=10.41.8.4 dst=10.10.101.2 ipp=103
Rulebase execution ended successfully.
Overall status:
----------------
Active clob mask: 0
Required clob mask: 0
Match status: MATCH
Match action: Accept

Per Layer:
------------
Layer name: CIMACT_policy_package Network
Layer id: 0
Match status: MATCH
Match action: Accept
Matched rule: 2
Possible rules: 2 3 6 16777215

Everything looks OK but multicast still doesnt go through.

Im guessing that my scenario somehow doesnt reflect any of the PIM on Gaia manual, since I have no routers as Rendezvous Points on both sides. i followed the Single GW on Static RP environment as it best describes my need and setup. I tried to add RPs as the IPs of my source and listener, but to no success.

Any help please

0 Kudos
the_rock
Legend
Legend

That makes sense. Do you see any drops if you do fw zdebug and grep for those IP addresses?

0 Kudos
Mladen
Participant

Will try that later and post, thank you for your help, really appreciate it.

But still I cant believe that CP cant route that traffic on its own, without RPs!?

Ill try setting IPs of CP interfaces on both sides as RPs and I'll post that too.

Thank you again.

the_rock
Legend
Legend

You can also run command ip r g and then ip address, see if output makes sense. 

example -> ip r g 8.8.8.8

Mladen
Participant

Hi,

I tried fw ctl zdebug but I didnt get any output (tried without ctl - syntax error).

When I tried the other command (ip r g) all is ok when I use IPs Unicast, but when I use 239.0.1.2 (Singlewire Multicast testing tool) - no output.

But there is something new, I changed scenario to 

Single Gateway as Candidate Rendezvous Point and Bootstrap Router

and when I do fw monitor -e "net(239.0.0.0, 8), accept;" I do get 'i' and 'I' on the eth1 (incoming) but it goes nowhere with the error log "too many packets received before route was resolved".

Thanks again. 

0 Kudos
Mladen
Participant

Hi all, new update

I have changed my PIM interfaces to be in DENSE mode since RPs and Bootstrap router setup IPs are confusing me in this simple setup (it seems like SPARSE mode setup scenario is more when networks are inbetween Secure Gateway and sources and listeners), all accordingly to manual.

Some command outputs:

CIMACT_FW> show pim summary

Instance ID is 0
Instance is running dense mode with state refresh
Address family of the interface is IPV4
Number of join/prune entries: 2

CIMACT_FW> show pim st
CIMACT_FW> show pim stats

PacketType Transmit Received TxErrors RxErrors
Hello 260 0 0 0
Register 0 0 0 0
RegisterStop 0 0 0 0
JoinPrune 9 0 0 0
Bootstrap 14 0 0 0
Assert 29 0 0 0
Graft 0 0 0 0
Graft Ack 0 0 0 0
Candidate RP 0 0 0 0
StateRefresh 0 0 0 0

CIMACT_FW> show igmp

IGMP State
Interfaces enabled 2
Next group age in 60 seconds
Multicast traceroute enabled
CIMACT_FW> show igmp summ
CIMACT_FW> show igmp summary

IGMP State
Interfaces enabled 2
Next group age in 54 seconds
Multicast traceroute enabled
CIMACT_FW> show mfc

Multicast Forwarding Cache State
Number of interfaces enabled: 2
Number of cache entries: 2
Kernel forwarding entry limit: unlimited
Number of kernel forwarding entries: 2
Cache entry average lifetime: 300 seconds
Prune average lifetime: 7200 seconds
Cache age cycle: 10 seconds
Next cache age: 3
Datarate update interval: 10 seconds
Multicast Protocol(Instance): PIM(0)

CIMACT_FW> show static-mroute

Static Multicast Routes:

0.0.0.0/0 via 10.10.101.2, eth3, cost 0, age 4191

On Log view i get drops with intermitten error varies from "too many packet received before route was resolved" and other "missing OS route".

On fw monitor -e "net(239.0.0.0, 8), accept;" all is the same, I can see just 'i' on eth1 interface.

Any new thoughts?

0 Kudos
Mladen
Participant

Ok, just to update things. Turns out all is good with the config, removed the static multicast route and re-enabled the listening interface and lab started working right away, even after shuting down everything.

But after installing the production, traffic didnot pass through firewall, multicast group and pim joins are empty, ip mroute also.

After I did tcpdump on the incoming interface I see again just the 'i' and 'I', but what got me is that we are sending data on 224.0.0.3 and I see IGMP sending query/report on the same IP Multicast, could that be the issue?

Any help, can someone confirm with certainty that this is what is interfering with my setup?

Thanks in advance

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events