como reducir trafico rip muilticast

[ROGER FERNANDO MAJO ZACARIAS]

Saludos a todos.

Nos pueden indicar como reducir el trafico Muilticast 224.0.0.9 usado en RIP ADVERTISEMENT?

Tenemos unos cuantos enlaces en los cuales el nivel de trafico multicast UDP 224.0.0.9 es elevado en comparacion a otras conversaciones propias de cada segmento.

Pueden decirnos a que se debe  y como minimizar dicho volumen de trafico multicast.

LA configuracion estandard es:

router rip

vedrsion 2

redistribute connected metric 1 route-map SOLO_LAN

network 10.0.0.0

no uato-summary

Gracias a todos.

[Peter Paluch]

Hello,

I apologize for not replying in Spanish - I hope you will still be able to understand.

If you want the RIP to avoid using the multicast address then you can do it by a trick - declare all interfaces as passive interfaces and then define static neighbors. A passive interface in RIP never sends multicast RIP messages but still processes all received RIP messages, and also is allowed to send and receive unicast RIP advertisements.

The neighbors will thus be contacted by unicast and no multicast will be used. The downside of this solution is that you are losing the automatic neighbor discovery that is a direct consequence of using broadcasts/multicasts, and if you add a new neighbor into an existing multiaccess network, you will need to statically define it on all neighboring routers (and also define all neighbors on the added router as well).

router rip
 version 2
 no auto-summary
 redistribute connected metric 1 route-map SOLO_LAN
 network 10.0.0.0
 passive-interface default
 neighbor 10.A.B.C
 neighbor 10.D.E.F
 neighbor 10.G.H.I
 ! ... and so on

Best regards,

Peter

[ROGER FERNANDO MAJO ZACARIAS]

Peter,

I also speak english too.

The local area network subnet is: 10.203.0.0 / 16, so i have added the next command in the router rip:

router rip

ver 2

redistribute connected metric 1 route-map SOLO_ETHER

passive-interface Fasethernet 0/0

network 10.203.0.0

no auto-summary

The interface fastethernet is configured as follow:

int fastethernet 0/0

ip address 10.203.200.1 255.255.0.0

int serial 0/0 (this interface is connected to IPVPN Cloud)

ip address 10.145.1.34 255.255.255.252

ip flow ingress

encapsulation frame-relay

frame-relay traffic-shaping

frame-relay interface-dlci 16

    class VOIP384K

We are using a tool which analyze the flow traffic across the router. The interface analyzed is the serial 0/0.

The incoming traffic trough the interface serial 0/0 shows: router (520 UDP) 224.0.0.9 as the TOP 1 CONVERSATION. This traffic is coming from the IPVPN (to wich is connected all the remote site).

So the question is: Is it possible to reduce or limit this incomig multicast traffic from the IPVPN Cloud?

If we block or denegate this incoming traffic the router will lose connection to the other remote site, isn´t it?

This is the diagram:

                                                                                     router 2801

other remote sites -------- IPVPN -------------------- Int serial 0/0_int fastethernet 0/0

                                                       -----------> multicast traffic

                                                                     router (520 UDP) 224.0.0.9

Waiting your answer.

Best regardas.

[Peter Paluch · Accepted solution]

Roger,

So the question is: Is it possible to reduce or limit this incomig multicast traffic from the IPVPN Cloud?

Yes, by using the approach I have indicated in my original reply. Once again: the RIPv2 is using the 224.0.0.9 multicast IP address by default. We can prevent it from doing that but we will need to convert the multicast RIPv2 communication on your Frame Relay interface to a bundle of unicast RIPv2 sessions, one for each neighbor.

On your 2801, you need to configure your Serial0/0/0 (the Frame Relay) interface as passive interface under the RIP (you have declared the Fa0/0 as the passive interface but that won't help as it does not affect the Serial0/0/0 right now). Also, the other remote sites also must declare their Frame Relay interface as passive interface. In RIPv2, declaring an interface as passive will make it stop sending multicast RIP messages.

However, using just the passive interface would cause that the RIP would not be able to exchange routing information on your Frame Relay circuits. That is why we need in addition to define the individual RIPv2 neighbors statically using the command neighbor in the RIPv2 configuration. Using the neighbor command will instruct your RIPv2 to talk to that particular neighbor using unicast packets. These neighbors will have to be configured both on your central 2801 router and on the remote sites. By configuring this, you will stop the RIPv2 from using multicasts altogether on the Frame Relay interconnection, and instead, you will force it to talk to all explicitly specified Frame Relay neighbors via unicast. That is what you want.

Please let me know if this all is comprehensible.

Best regards,

Peter

[ROGER FERNANDO MAJO ZACARIAS]

Peter,

Yes, I understand you very well.

Your suggestion is good.

But we belong to a corporation conformed by about 100 companies.

Each of these companies are linked together trough an IPVPN/MPLS Cloud.

Each router at each companies uses; RIP V2 or BGP to communicate each other.

At the cloud (IPVPN/MPLS) exist other router (PE) which is handle by a carrier. This PE router communicate with the router at each company using RIPV2 or BGP, so if we make any change at router it must match the configuration at PE.

We are going to talk with our carrier to change the RIP V2 routing by BGP so we can avoid this multicast traffic from RIP.

Waiting your point of view and thanking you in advance.

Attentively.

Roger Fernando Majo Z.
Ing. Soporte NOC y Proyectos
Telefono: (511) 513-2960 Anexo: 52993
Celular: 996918812

RPM: #263689
Fax: (511) 221.0500
Direccion: Av. Camino Real 390. Piso 13
Torre Central Of.301. San Isidro, Lima-Peru
www.sitel.com.pe

[Peter Paluch]

Hello Roger,

I think we should approach the problem from a slightly different perspective for a while. You have indicated that the multicast traffic to 224.0.0.9 constitutes the majority of the multicast traffic on your VPN access links. However, is that a problem? Is there any reason, technical or administrative, that forces you to minimize the amount of the multicast traffic? Does the multicast traffic consume a significant portion of the total access link bandwidth? In simple words, what is the problem with having a multicast traffic on your access links?

All IGP routing protocols default to using multicast, and if you force them to unicast operation you will be logically forced to define the neighbors statically because their automatic discovery via multicast will no longer work. However, running the BGP is of the same, if not even greater, administrative burden because with BGP, you also need to define all neighbors statically, just as you need with RIPv2. In addition, the BGP machinery is more resource-demanding and its configuration more complex than, say, RIPv2. By migrating to BGP, you will avoid the multicasts but the migration to BGP and its subsequent maintenance is even more configurationally complex than migrating the RIPv2 to unicast operation. From this viewpoint, migration to BGP solves nothing.

Best regards,

Peter