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 <juni...@iber-x.com> wrote: > Hello, > > I've just executed this comand on the shell and it appeared a lot of > routes: > > r...@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 <juni...@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 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@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 _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp