Configuration PIMD avec tunnel GRE over IPSEC

Support Debian
,
Tags: #<Tag:0x00007f63f31bcf70> #<Tag:0x00007f63f31bcde0>
#1

Bonjour,

J’ai mis en place un contexte qui relie deux réseaux avec une liaison VPN. (voir schéma).
image

Dans mon contexte, la machine Cliente communique avec mon serveur seulement en multicast. Cependant, le serveur lui répond en unicast.

J’ai configuré le tunnel GRE over IPSEC et il est fonctionnel.
Lorsque j’effectue un ping entre le client et le serveur, ça fonctionne correctement. Pour le multicast, j’ai mis en place le service PIMD sur les deux routeurs debian. J’ai configuré PIMD sur les deux routeurs (comme j’ai pu, très peu de documentation sur le service sur internet). Le problème c’est que, quand je lance la communication entre les deux machines, le client envoie bien les données au groupe de multicast, le premier routeur (10.137.1.254) le reçoit puis le redirige dans le tunnel. L’interface du tunnel du second routeur réceptionne bien les données (capture de trame, ok).
Mon problème est qu’il le renvoie pas sur le réseau 10.136.1.0/24.

J’ai fait pas mal d’essais comme ajouter une route sur le second routeur :

route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0

C’est pas non plus un problème de TTL car il est de 255.

Il faut savoir que de chaque côté, les switchs sont « Querier » et ils gerent les groupe de diffusion dans chacun des réseaux.

Si vous avez besoin de plus d’informations, n’hesitez pas ^^

Merci d’avance pour votre aide.

#2

Voici la configuration de mon second routeur (10.136.1.254) :

pimd -r

image

#3

ip mroute

image

Le groupe de diffusion n’est pas toujours le même, à chaque connexion CIP, il change.

#4

fichier /etc/pimd.conf

# Example configuration file for pimd, the original PIM-SM router
#
# See the pimd(8) man page for details on all the settings.  This file
# only gives very brief examples and is intended as a quick start.
#
# NOTE: The order of the settings matter!
#
##
default-route-distance 101
default-route-metric   1024
# hello-interval         <30-18724>
#
# igmp-query-interval  <SEC>
# igmp-querier-timeout <SEC>
#

phyint tun0 dr-priority 1

phyint eth0 igmp

phyint eth1 dr-priority 100

#bsr-candidate tun0

# phyint <local-addr | ifname>
#        [disable | enable] [igmpv2 | igmpv3]
#        [dr-priority <1-4294967294>]
#        [ttl-threshold <1-255>] [distance <1-255>] [metric <1-1024>]
#        [altnet <network> [/<masklen> | masklen <masklen>]]
#        [scoped <network> [/<masklen> | masklen <masklen>]]
#
# bsr-candidate [local-addr | ifname] [priority <0-255>]
# rp-candidate  [local-addr | ifname] [priority <0-255> ] [time <10-16383>]
#                group-prefix <group-addr>[/<masklen> | masklen <masklen>]
#                group-prefix <group-addr>[/<masklen> | masklen <masklen>]
#                   .
#                   .
#                group-prefix <group-addr>[/<masklen> | masklen <masklen>]
# rp-address    <local-addr> [<group-addr>[/<masklen> | masklen <masklen>]
#
# spt-threshold [rate <KBPS> | packets <NUM> | infinity] [interval <SEC>]
##
#
# By default PIM is activated on all interfaces.  Use `phyint disable`
# on interfaces where PIM should not run.  You can also use the `-N,
# --disable-vifs` command line option along with `enable` to get the
# inverse behavior.
#
# The routing protocol admin distance (or metric preference per the RFC)
# is used in PIM Assert elections to elect the forwarder of multicast.
# Currently pimd cannot obtain distance and metric from the underlying
# routing protocols, so a default distance may need to be configured per
# interface.  If left out, the default-route-distance is used for the
# phyint.  In PIM assert elections the router advertising the lowest
# preference (distance) will be selected as forwarder (upstream router)
# for that LAN.  An admin distance of 101 should be sufficiently high so
# that asserts from Cisco or GateD routers are prefered over poor-little
# pimd.
#
# It is reccommended that preferences (admin distance) be set such that
# metrics are never consulted.  However, default metrics may also be set
# and default to 1024.
#
# A phyint directive can use either the interface name, ifname, or the
# IP address.  The distance and metric settings define administrative
# distance and metric, respectively, for PIM Assert messages sent on
# that interface.  Usually you do not need this, but if you do, think of
# them like distance and metric defined on an inbound interface (iif),
# but used by PIM Asserts on the outbound interfaces (oifs).
#
# If you want to add "alternative (sub)net" to a physical interface,
# e.g., if you want to make incoming traffic with a non-local source address
# to appear as it is coming from a local subnet, then use the command:
#
#   phyint <local-addr | ifname> altnet <net-addr> masklen <len>
#
# NOTE: if you use this command, make sure you know what you are doing!
#
# If you want administratively scoped multicast filtering, use the
# following command:
#
#   phyint <local-addr | ifname> scoped <net-addr> masklen <masklen>
#
# This allows interfaces to be configured as an administrative boundary
# for the specified scoped address, or address range.  Packets belonging
# to the scoped range will not be forwarded.  Use `--enable-scoped-acls`
# flag to the configure script to activate this at build time.
#
# Both rp-candidate and bsr-candidate are enabled in the default config,
# below.  Disabling them for all PIM capable routers is a bad idea. At
# least one PIM router in the backbone must act as a bootstrap router.
# The optional local-addr or ifname arguments after the rp-candidate and
# bsr-candidate settings specify the local address to be used in the
# Cand-RP and Cand-BSR messages.  In case ifname is given as argument,
# the first IPv4 address of that interface is used.  If either is
# unspecified, the largest local IP address will be used, excluding
# phyint interfaces where PIM has been disabled.
#
# The time argument to rp-candidate specifies how often to send Cand-RP
# messages.  The default value is 30 seconds.  Use smaller values for
# faster convergence.
#
# The group-prefix setting is the prefix(es) advertised if rp-candidate.
# It is possible to set up to 255 group-prefix records.
#
# Using the rp-address setting it is possible to set a static rendezvous
# point.  The argument can be either a unicast or a multicast address
# followed by an optional group address and optional masklen to that.
#
# The spt-threshold specifies the minimum rate in kbps before the last
# hop router initiates a switch to the shortest path.  The `packets`
# argument is an alternative notation, `infinity` means to never switch,
# and `interval` specifies the interval for periodical testing of the
# threshold.  Currently, `interval` must be at least 5 (seconds)
#
# Interface defaults, like default-route-distance and -metric must be
# set before the phyint section -- the .conf parser is not clever.
#default-route-distance	  101      # smaller is better
#default-route-metric     1024     # smaller is better
#hello-interval           30       # Don't set lower than 30

# The phyint settings currently *MUST BE* ordered after the default
# source preference and metric settings, but before everything else.

# By default, all non-loopback multicast capable interfaces are enabled.
# If you want to use loopback, set the interface multicast flag on it.
#phyint eth0 disable

 # IGMP default query interval and querier timeout.  The latter should
# per RFC always be (robustness * interval) + (query-response / 2), for
# pimd this means: (3 * 12) + (10 / 2) = 41, we've rounded it up to
# honor the late Douglas Adams.  You can set it to a higher value, but
# it is not recommended to set it lower.
#igmp-query-interval  12
#igmp-querier-timeout 42

# Bigger value means  "higher" priority
bsr-candidate priority 5

# Smaller value means "higher" priority
rp-candidate time 30 priority 20

# Candidate for being RP of complete IPv4 multicast range
group-prefix 224.0.0.0 masklen 4

# Static rendez-vous point
rp-address 172.16.1.1 224.0.0.0/4

# Switch to shortest-path tree after first packet, but only after 100 sec.
spt-threshold packets 0 interval 100
#5

Bonjour,
Sur le schema le serveur n’a pas la bonne adresse (137 au lieu de 136).
pense à faire plutot des copier coller, c’est mieux que les images (et les commentaires seront complets :wink: )

Juste pour savoir, pourquoi juste du multicast? pour quelle utilité?

#6

Effectivement, je me suis trompé sur le schéma ^^
Je travaille dans un environnement de test, et je dois faire communiquer deux équipements industriels à distance, qui normalement communiquent en local. Ils sont configurés comme ça de base et je ne peux pas le modifier.

Je vais edit les messages juste avant et mettre des copier coller afin d’avoir l’ensemble

#7

pourquoi ne pas faire directement le tunnel entre le serveur et le client, ou à minima entre le serveur et le routeur du client? tu gagnes une étape

#8

Je ne peux pas modifier la configuration des deux appareils, du coup je developpe mon contexte autour de leurs configurations. Je suis dans un environnement de test et il se peut que, une fois mis en place, je l’utilise avec des équipements déjà en service et donc impossible à modifier. Je dois pouvoir ajouter, côté client, différents appareils sans modifier leur configuration. Le « client » est en réalité un écran de bord (sous linux) et le « serveur » un calculateur (sous linux aussi). Mais le problème ne vient pas du VPN mais du routage multicast avec PIMD ^^

#9

Finalement, j’ai utilisé le service smcroute afin de mettre en place des routes multicast statiques et ça fonctionne.