[j-nsp] RPD event M20
juniper at iber-x.com
juniper at iber-x.com
Wed May 5 10:30:59 EDT 2010
Thanks, we're going to try these steps out and I will let you know.
El 05/05/2010 4:30, Ihsan Junaidi Ibrahim escribió:
> without studying your topology in detail, i think the best reason that
> can be explained by your rtsockmon output is there is spurious routing
> updates in your topology. these updates are typically triggered by
> link flaps or bgp flaps by way of MED selection or there could be
> others as well. i think you can check monitoring a specific route in
> your RR see whether that the updates are being caused by MED calculation.
>
> On 5 May 2010 01:18, Juniper <juniper at iber-x.com
> <mailto:juniper at iber-x.com>> wrote:
>
> 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
>
>
>
>
> --
> Thank you for your time,
> Ihsan Junaidi Ibrahim
More information about the juniper-nsp
mailing list