Closed rburkholder closed 8 years ago
Hi @rburkholder :smiley:
First, traditional Cisco gear is quite different from Linux, so using loopback as is done there does not always apply. Even though some concepts used by them can be really handy.
Now, you figured out that you need to set the MULTICAST
flag on loopback, so that's a start. But pimd
(currently) does not allow /32's ... yeah, I don't think it's needed but there's a lot of legacy code in there I haven't dared to touch yet. The configure
script supports a --disable-masklen-check
flag that you can try out, but I don't think you really need this anyway, see further down.
Now, when using a multicast routing daemon like pimd
, mrouted
, or smcroute
you don't need to bother with setting up unicast routes to 224.0.0.0/4. The multicast routers have their own routing tables that work with VIFs, virtual interfaces that map on top of physical interfaces (phyints). With the former two multicast routes are installed in the kernel dynamically and with the latter smcroute routes are installed statically. The former two are therefore more suitable for resilient setups.
However, I'm afraid I don't understand fully what it is you want to do or how much experience you have with PIM. But in most cases you just need to fire up pimd
with the default pimd.conf
as argument (see -h
for syntax) and you're off, basically.
For a crash course you need:
pimd
to dynamically install a multicast route into the kernel.Use the tools pimd -r
, cat /proc/net/ip_mr_vif
, and cat
/proc/net/ip_mr_cacheto see what your PIM daemon does and what it installs in the kernel. The latter can be parsed by a regular human using the
ip mroute` tool.
Thank you for your response.
I am just getting started with pimd, so I am doing a lot of 'brute force and ignorance' style of testing to get something working. I do have something working now. An outline of the configuration can be found at Linux VXLAN with pimd, Quagga, and openvswitch.
I am going to have to spend some quality time and watch traces to build up my comfort with the group registrations.
For the routing, as outlined in my blog item, I have a default route going to a management interface, rather than towards the core. I need to fix that, and then maybe the multicast will work properly without the specific route. The multicast group woudn't work without that multicast route in place.
I also used an openvswitch vlan to act as a residence for the RP on each of the two core devices. I will need to tune how groups are associated with each RP, and may obtain a bit of load balancing in the process.
Thank you for pointing out the compile time flag for the mask checking. I will keep that in mind for future testing.
In the end, I was able to build a test rig to simulate your 'crash course'. I was pleased with the results. Things worked well.
Thanx for pointing out the mapping of 'ip mroute' and 'cat /proc/net/ip_mr_cache'.
No problem, good luck mate! :smiley:
I have pimd 2.3.1, kernel 4.3.5 on debian amd64.
To get routing in the right direction, I have a route like:
I noticed via netstat -g, that a multicast source will register against a specific interface. If that interface goes down, the source won't move to another interface.
So try a different a form of resiliency, independent of the exit interface, I looked at alternate options.
At LCM, they show a route to the loopback. Which makes sense. I would like my RPs on the loopback, much like what can be done on Cisco devices. I can add the following route, and it shows in the routing table.
I can do the following to get multicast on the loopback:
I even have an additional ip address on the loopback, and confirms multicast is set:
I have phyint in pimd.conf:
Pimd seems to pick up physical interfaces, but I can't seem to get it to recognize the lo device. The following debug doesn't indicate why it doesn't pick up lo. lo won't show up in the vif table.
Also, I notice that I am unable to use the 'rp-candidate local-addr' with an interface with a /32 address. So that eliminates the lo as a suitable source of an rp location. Is that by design? It seems possible in cisco land though.
Is this a pimd or a kernel issue? Bug / feature?
Are there other ways to obtain some resiliency on the exit interfaces?
Thanx.