[j-nsp] RPD event M20
Juniper
juniper at iber-x.com
Tue May 4 13:18:16 EDT 2010
Hi,
In this router, we have configured 2 logical router. In the 'physical'
we have only one provider (one full-routing) and in the logical one we
are connected to 2 providers (2 full-routing). Are these events for both
logical routers? They are differents providers, why should I configure
always-compare-med? Although we have a redundance session BGP with one
of these provider in other router in our AS.
Would you recommend us to use this sentence in the configurations? We
are not sure because we have implemented to filter the routes
'communities' and 'local-preferences' but we don't use always-compare-med.
These configuration is applied since a lot of years, almost 5 years and
we never had these events in our log.
My apologies about asking you so many questions but we never had these
type of logs in our Juniper M20 and we have to understand first to apply
this parameter in our configuration.
Thanks a lot for your time,
Matthew
El 04/05/2010 17:10, Ihsan Junaidi Ibrahim escribió:
> Looks like there's a persistent oscillation in your routing topology.
> If you see routes i.e. 195.240.208.0 that comes from different peer
> ASes, you might want to configure always-compare-med in your bgp
> path-selection statement. By default, it will only compare routes that
> come from the same peer AS.
>
> On 4 May 2010 23:54, Juniper <juniper at iber-x.com
> <mailto:juniper at iber-x.com>> wrote:
>
> Hello,
>
> I've just executed this comand on the shell and it appeared a lot
> of routes:
>
> root at eg01% rtsockmon -t rpd
> sender flag type op
> [17:30:29] rpd P route add inet6 2401:ee00::
> tid=2 plen=32 type=user flags=0x10 nh=indr nhflags=0x4
> nhidx=262144 filtidx=0
> [17:30:29] rpd P route add inet6
> 2401:ee00:1c1c::2001:668 tid=0 plen=32 type=user flags=0x0 nh=ucst
> nhflags=0x1 nhidx=591 filtidx=0
> [17:30:29] rpd P route change inet6
> 2401:ee00:1c1c::2001:668 tid=2 plen=32 type=user flags=0x10
> nh=indr nhflags=0x4 nhidx=262151 filtidx=0
> [17:30:29] rpd P route add inet6
> 2400:6800:1c1c::2001:668 tid=0 plen=32 type=user flags=0x0 nh=ucst
> nhflags=0x1 nhidx=591 filtidx=0
> [17:30:29] rpd P route add inet6
> 2400:6800:1c1c::2001:668 tid=2 plen=32 type=user flags=0x10
> nh=indr nhflags=0x4 nhidx=262151 filtidx=0
> [17:30:29] rpd P route add inet6
> 2404:8000:f:0:1c1c:: tid=0 plen=48 type=user flags=0x0 nh=ucst
> nhflags=0x1 nhidx=591 filtidx=0
> [17:30:29] rpd P route add inet6
> 2404:8000:5:0:1c1c:: tid=0 plen=48 type=user flags=0x0 nh=ucst
> nhflags=0x1 nhidx=591 filtidx=0
> [17:30:29] rpd P route add inet6
> 2404:8000:c:0:1c1c:: tid=0 plen=48 type=user flags=0x0 nh=ucst
> nhflags=0x1 nhidx=591 filtidx=0
> [...]
> [17:30:31] rpd P route change inet 195.140.208.0
> tid=0 plen=22 type=user flags=0x0 nh=indr nhflags=0x4 nhidx=262147
> filtidx=0
> [17:30:31] rpd P route change inet 85.197.112.0
> tid=0 plen=20 type=user flags=0x0 nh=indr nhflags=0x4 nhidx=262147
> filtidx=0
> [17:30:31] rpd P route change inet 195.225.208.0
> tid=0 plen=22 type=user flags=0x0 nh=indr nhflags=0x4 nhidx=262147
> filtidx=0
> [17:30:31] rpd P route change inet 195.158.54.0
> tid=0 plen=24 type=user flags=0x0 nh=indr nhflags=0x4 nhidx=262147
> filtidx=0
> [17:30:31] rpd P route change inet 195.158.54.0
> tid=2 plen=24 type=user flags=0x0 nh=ucst nhflags=0x1 nhidx=573
> filtidx=0
> [17:30:31] rpd P route change inet 85.197.112.0
> tid=2 plen=20 type=user flags=0x0 nh=ucst nhflags=0x1 nhidx=573
> filtidx=0
> [17:30:31] rpd P route change inet 195.140.208.0
> tid=2 plen=22 type=user flags=0x0 nh=ucst nhflags=0x1 nhidx=573
> filtidx=0
> [17:30:31] rpd P route change inet 195.225.208.0
> tid=2 plen=22 type=user flags=0x0 nh=ucst nhflags=0x1 nhidx=573
> filtidx=0
> [17:30:31] rpd P route change inet 148.247.205.0
> tid=2 plen=24 type=user flags=0x0 nh=ucst nhflags=0x1 nhidx=583
> filtidx=0
> [17:30:31] rpd P route change inet 148.247.22.0
> tid=2 plen=24 type=user flags=0x0 nh=ucst nhflags=0x1 nhidx=583
> filtidx=0
> [..]
>
> The output is very long ( I had to stopped after 3 minutes) and we
> don't know if that is normal o no. What should we do? Is it
> possible to clean this routes?
>
> Thanks a lot for your help,
>
> Matthew
>
>
> El 04/05/2010 15:14, Ihsan Junaidi Ibrahim escribió:
>> you can check for persistent routing updates i.e. flaps by
>> running rtsockmon -t rpd on the shell.
>>
>> On 4 May 2010 22:04, Juniper <juniper at iber-x.com
>> <mailto:juniper at iber-x.com>> wrote:
>>
>> Hello there,
>>
>> This message has appeared in the log of our M20. It is not
>> the first time it occurs and we are quite worried. The
>> average CPU consumption is 4% and just at the time the
>> message appeared on the log, we found increases up to 100%
>> and an increase in temperature of 6 º in the routing-engine
>> 0. This router works with two logical routers and receive
>> full-routing of three different providers. We also have
>> configured and IS-IS and IBGP sessions.
>>
>> May 4 11:43:03 xxx01.yyy2.abc-d.net
>> <http://xxx01.yyy2.abc-d.net> LEV[2625]: RPD_SCHED_SLIP: 7
>> sec scheduler slip, user: 3 sec 306043 usec, system: 0 sec,
>> 5732 usec
>>
>> We do not know what could be the problem because we have not
>> detected any event bgp, routing update, addition of new
>> machines, etc.
>> Do you have any idea what may be the reason for this high cpu
>> usage?
>>
>> Thanks in advance,
>>
>> Matthew
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> <mailto:juniper-nsp at puck.nether.net>
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>>
>>
>>
>> --
>> Thank you for your time,
>> Ihsan Junaidi Ibrahim
>
>
>
>
> --
> Thank you for your time,
> Ihsan Junaidi Ibrahim
More information about the juniper-nsp
mailing list