Re: [Euro-ix-rs-vwg] New release 1.2.0
On Mon, Jan 25, 2010 at 07:12:50PM +0300, Mikhail A. Grishin wrote:
Ondrej Zajicek ?????:
On Mon, Jan 25, 2010 at 03:15:14PM +0300, Mikhail A. Grishin wrote:
Yes, we had some filters on pipes for every client. Upon your explanation, we transfered filters from pipes to the "protocol bgp" section of the config.
Now "show protocols all" output shows all needed information.
Just a note that moving filters from pipes to bgp protocols have several other consequences, some positive, some negative:
1) You see just what is accepted and you cannot directly see rejected routes (but they can be seen in log, if enabled).
Yes, we planned for that case temporary transfer filters back to pipes for some peer... But if it could be done by logs, may be you can show an example?
You can use 'debug { filters }' in a bgp protocol section and it will log all routes in filters of that bgp protocol.
Very valuable info for us! In general, we want to minimize causes of restarting BGP sessions with our clients. Is this task (new behavior of 'configure' command) have a good priority for developers?
Other IXes that use BIRD use (AFAIK) 'configure soft' and 'reload' approach, so it was not a big demand for this change yet. But it should not be hard to do that change and i would like to have this change soon.
One more question, about routes with "no-export" community == ((65535,65281))
We need to transparently advertise such routes through RS to RS clients.
We try to transparently advertise, these routes seen in 'show routes all', and in 'show routes all table Tanother_peer', but peer 'another_peer' doesn't receive routes with community (65535,65281).
Handling of no-export community is hardcoded in BIRD, so such routes are not exported to the external neighbors, as it is expected. I can send you a patch that causes BIRD to ignore well-known communities (and leaves such behavior to configured filters) and we will make this behavior configurable in the next version. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Ondrej Zajicek пишет:
On Mon, Jan 25, 2010 at 07:12:50PM +0300, Mikhail A. Grishin wrote:
Ondrej Zajicek ?????:
On Mon, Jan 25, 2010 at 03:15:14PM +0300, Mikhail A. Grishin wrote:
Yes, we had some filters on pipes for every client. Upon your explanation, we transfered filters from pipes to the "protocol bgp" section of the config.
Now "show protocols all" output shows all needed information. Just a note that moving filters from pipes to bgp protocols have several other consequences, some positive, some negative:
1) You see just what is accepted and you cannot directly see rejected routes (but they can be seen in log, if enabled). Yes, we planned for that case temporary transfer filters back to pipes for some peer... But if it could be done by logs, may be you can show an example?
You can use 'debug { filters }' in a bgp protocol section and it will log all routes in filters of that bgp protocol.
Very valuable info for us! In general, we want to minimize causes of restarting BGP sessions with our clients. Is this task (new behavior of 'configure' command) have a good priority for developers?
Other IXes that use BIRD use (AFAIK) 'configure soft' and 'reload' approach, so it was not a big demand for this change yet. But it should not be hard to do that change and i would like to have this change soon.
One more question, about routes with "no-export" community == ((65535,65281))
We need to transparently advertise such routes through RS to RS clients.
We try to transparently advertise, these routes seen in 'show routes all', and in 'show routes all table Tanother_peer', but peer 'another_peer' doesn't receive routes with community (65535,65281).
Handling of no-export community is hardcoded in BIRD, so such routes are not exported to the external neighbors, as it is expected. I can send you a patch that causes BIRD to ignore well-known communities (and leaves such behavior to configured filters) and we will make this behavior configurable in the next version.
Yes, it would be nice, please send me a patch. We expected that we could choose, which well-known communities must go through RS, which is not. Right now we only interested in transparency for "no-export". -- Mikhail A. Grishin E-mail: magr@ripn.net
On Wed, Jan 27, 2010 at 04:49:45PM +0300, Mikhail A. Grishin wrote:
Handling of no-export community is hardcoded in BIRD, so such routes are not exported to the external neighbors, as it is expected. I can send you a patch that causes BIRD to ignore well-known communities (and leaves such behavior to configured filters) and we will make this behavior configurable in the next version.
Yes, it would be nice, please send me a patch. We expected that we could choose, which well-known communities must go through RS, which is not. Right now we only interested in transparency for "no-export".
Here is the patch that removes hardcoded handling of well-known communities. If you want the other well-known communities to work, you have to add appropriate code to export filters. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Ondrej Zajicek пишет:
On Wed, Jan 27, 2010 at 04:49:45PM +0300, Mikhail A. Grishin wrote:
Handling of no-export community is hardcoded in BIRD, so such routes are not exported to the external neighbors, as it is expected. I can send you a patch that causes BIRD to ignore well-known communities (and leaves such behavior to configured filters) and we will make this behavior configurable in the next version.
Yes, it would be nice, please send me a patch. We expected that we could choose, which well-known communities must go through RS, which is not. Right now we only interested in transparency for "no-export".
Here is the patch that removes hardcoded handling of well-known communities. If you want the other well-known communities to work, you have to add appropriate code to export filters.
Hi, First of all, thank you for patch and for fast respond! After applying both patches (date patch and well-known communities) on production server, we got some strange errors: Jan 28 12:02:04 msk-rsm2 bird: R34485x1: Error: Finite state machine error Jan 28 12:02:17 msk-rsm2 bird: R13174x1: Error: Finite state machine error Jan 28 12:02:28 msk-rsm2 bird: R3218x1: Error: Finite state machine error Jan 28 12:02:30 msk-rsm2 bird: R41842x1: Error: Finite state machine error Jan 28 12:03:09 msk-rsm2 bird: R34485x1: Error: Finite state machine error Jan 28 12:03:26 msk-rsm2 bird: R41842x1: Error: Finite state machine error Jan 28 12:03:29 msk-rsm2 bird: R13174x1: Error: Finite state machine error Jan 28 12:03:37 msk-rsm2 bird: R3218x1: Error: Finite state machine error What does it mean? These peers worked fine before applying the patches. Debug: =================== Jan 28 12:40:17 msk-rsm2 bird: R41842x1: Incoming connection from 193.232.246.200 (port 20880) rejected Jan 28 12:40:19 msk-rsm2 bird: R41842x1: Started Jan 28 12:40:19 msk-rsm2 bird: R41842x1: Connect delayed by 60 seconds Jan 28 12:40:36 msk-rsm2 bird: R41842x1: Incoming connection from 193.232.246.200 (port 33675) accepted Jan 28 12:40:36 msk-rsm2 bird: R41842x1: Sending OPEN(ver=4,as=8631,hold=180,id=c1e8f664) Jan 28 12:40:36 msk-rsm2 bird: R41842x1: Got OPEN(as=41842,hold=180,id=4df660a0) Jan 28 12:40:36 msk-rsm2 bird: R41842x1: Sending KEEPALIVE Jan 28 12:40:36 msk-rsm2 bird: R41842x1: Got UPDATE Jan 28 12:40:36 msk-rsm2 bird: R41842x1: Error: Finite state machine error Jan 28 12:40:36 msk-rsm2 bird: R41842x1: Sending NOTIFICATION(code=5.0) Jan 28 12:40:36 msk-rsm2 bird: R41842x1: Down Jan 28 12:40:36 msk-rsm2 bird: R41842x1: Starting Jan 28 12:40:36 msk-rsm2 bird: R41842x1: Startup delayed by 300 seconds ===================== Config for one of that peers: #--------------------------------------------------------- # Client 'media', AS 41842 table T41842; filter bgp_in_AS41842 prefix set allnet; # AS_PATH filter is temporary disabled #int set allas; { if ! (avoid_martians()) then reject; if (bgp_path.first != 41842 ) then reject; # AS_PATH filter is temporary disabled # allas = [ 47445, 45018, 44522, 45029, 44597, 42728, 42139, 42385 ]; # if ! (bgp_path.last ~ allas) then reject; allnet = [ 62.105.32.0/19, 62.105.48.0/20, 62.109.0.0/20, 62.109.0.0/21, 62.109.8.0/21, 62.109.16.0/21, 62.109.24.0/22, 62.109.28.0/22, 77.236.224.0/19, 77.236.224. 0/20, 77.236.240.0/21, 77.236.248.0/21, 77.246.96.0/21, 77.246.104.0/21, 77.246.144.0/21, 77.246.148.0/22, 78.24.216.0/21, 79.98.136.0/21, 79.174.32.0/19, 79.174.32.0 /20, 79.174.48.0/20, 80.244.224.0/20, 80.253.30.0/24, 80.253.31.0/24, 82.114.96.0/19, 82.114.96.0/20, 82.114.99.0/24, 82.114.112.0/21, 82.114.120.0/21, 82.146.32.0/21 , 82.146.37.0/24, 82.146.40.0/21, 82.146.48.0/21, 82.146.56.0/21, 85.249.0.0/21, 87.255.0.0/23, 87.255.2.0/23, 87.255.2.0/24, 87.255.3.0/24, 87.255.4.0/22, 87.255.8.0 /22, 87.255.8.0/24, 87.255.9.0/24, 87.255.9.252/30, 87.255.10.0/23, 87.255.12.0/22, 87.255.16.0/21, 87.255.24.0/21, 88.210.52.0/22, 89.255.64.0/21, 89.255.68.0/22, 89 .255.72.0/21, 89.255.80.0/22, 89.255.94.0/23, 89.255.95.0/24, 91.192.244.0/22, 91.200.28.0/22, 91.200.28.0/23, 91.200.30.0/23, 91.204.108.0/22, 91.206.14.0/23, 91.210 .84.0/22, 91.210.228.0/22, 91.210.228.0/23, 91.210.230.0/24, 91.210.231.0/24, 92.63.96.0/21, 92.63.104.0/22, 92.63.108.0/22, 92.63.108.0/24, 93.92.32.0/21, 93.186.48. 0/20, 94.28.112.0/22, 94.28.116.0/22, 94.158.160.0/20, 94.158.160.0/21, 94.158.168.0/21, 94.159.0.0/17, 95.128.176.0/22, 95.128.178.0/23, 188.120.32.0/20, 188.120.32. 0/21, 188.120.40.0/22, 188.120.44.0/22, 188.120.224.0/20, 188.120.240.0/21, 188.120.248.0/21, 188.133.136.0/21, 188.133.152.0/21, 193.169.32.0/23, 193.169.96.0/23, 19 3.169.174.0/23, 193.192.128.0/20, 193.192.144.0/20, 193.192.144.0/24, 193.192.144.0/25, 193.192.145.0/24, 194.9.224.0/20, 194.54.176.0/22, 194.107.23.0/24, 194.110.25 3.0/24, 195.62.62.0/23, 195.62.62.0/24, 195.62.63.0/24, 195.88.92.0/23, 195.88.170.0/23, 195.88.170.0/24, 195.88.171.0/24, 195.216.241.0/24, 195.218.134.0/24, 212.16. 0.0/19, 212.16.0.0/20, 212.16.16.0/20, 213.5.184.0/21, 213.33.198.0/24, 213.79.0.0/19, 213.79.0.0/20, 213.79.16.0/23, 213.79.18.0/24, 213.79.19.0/24, 213.79.20.0/22, 213.79.24.0/21, 213.108.128.0/21, 213.221.4.128/26, 217.78.176.0/20, 217.117.112.0/20, 217.117.127.0/24 ]; if ! (net ~ allnet) then reject; bgp_next_hop = 193.232.246.200; accept; } protocol pipe P41842 { table master; mode transparent; peer table T41842; import filter bgp_in_AS41842; export where bgp_out(41842); } protocol bgp R41842x1 { local as myas; neighbor 193.232.246.200 as 41842; hold time 180; startup hold time 180; # connect retry time 120; # path metric 1; # Prefer routes with shorter paths (like Cisco does) # default bgp_med 0; # MED value we use for comparison when none is defined # default bgp_local_pref 0; # The same for local preference import all; export all; table T41842; rs client; start delay time 60; } #--------------------------------------------------------- ... # BGP output filter (based on communities) function bgp_out(int peeras) { if ! (source = RTS_BGP ) then return false; if (0,peeras) ~ bgp_community then return false; if (myas,peeras) ~ bgp_community then return true; if (0, myas) ~ bgp_community then return false; return true; } #--------------------------------------------------------- -- Mikhail A. Grishin E-mail: magr@ripn.net
On Thu, Jan 28, 2010 at 12:54:03PM +0300, Mikhail A. Grishin wrote:
First of all, thank you for patch and for fast respond!
After applying both patches (date patch and well-known communities) on production server, we got some strange errors:
Jan 28 12:02:04 msk-rsm2 bird: R34485x1: Error: Finite state machine error Jan 28 12:02:17 msk-rsm2 bird: R13174x1: Error: Finite state machine error Jan 28 12:02:28 msk-rsm2 bird: R3218x1: Error: Finite state machine error Jan 28 12:02:30 msk-rsm2 bird: R41842x1: Error: Finite state machine error Jan 28 12:03:09 msk-rsm2 bird: R34485x1: Error: Finite state machine error Jan 28 12:03:26 msk-rsm2 bird: R41842x1: Error: Finite state machine error Jan 28 12:03:29 msk-rsm2 bird: R13174x1: Error: Finite state machine error Jan 28 12:03:37 msk-rsm2 bird: R3218x1: Error: Finite state machine error
What does it mean?
This error messages mean that BIRD received BGP messages (packets) that were unexpected with regard to the current state of the BGP session. According to the debug log you sent, it seems that the neighbor sent UPDATE message immediately after it sent OPEN message, but it should send KEEPALIVE message first. I have no idea how such problem might be caused by these patches. Is this problem related to just a small number of neighbors and other neighbors work well? -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Ondrej Zajicek пишет:
On Thu, Jan 28, 2010 at 12:54:03PM +0300, Mikhail A. Grishin wrote:
First of all, thank you for patch and for fast respond!
After applying both patches (date patch and well-known communities) on production server, we got some strange errors:
Jan 28 12:02:04 msk-rsm2 bird: R34485x1: Error: Finite state machine error Jan 28 12:02:17 msk-rsm2 bird: R13174x1: Error: Finite state machine error Jan 28 12:02:28 msk-rsm2 bird: R3218x1: Error: Finite state machine error Jan 28 12:02:30 msk-rsm2 bird: R41842x1: Error: Finite state machine error Jan 28 12:03:09 msk-rsm2 bird: R34485x1: Error: Finite state machine error Jan 28 12:03:26 msk-rsm2 bird: R41842x1: Error: Finite state machine error Jan 28 12:03:29 msk-rsm2 bird: R13174x1: Error: Finite state machine error Jan 28 12:03:37 msk-rsm2 bird: R3218x1: Error: Finite state machine error
What does it mean?
This error messages mean that BIRD received BGP messages (packets) that were unexpected with regard to the current state of the BGP session. According to the debug log you sent, it seems that the neighbor sent UPDATE message immediately after it sent OPEN message, but it should send KEEPALIVE message first.
I have no idea how such problem might be caused by these patches. Is this problem related to just a small number of neighbors and other neighbors work well?
Hi, We found that "Finite state machine error" problem is not related to your patches. It randomly occurs on our production server at the time of daemon startup :(( The problem is occurs on small number of peers. (2 or 3 or 4 from ~280) Some problem peers are the same at next startup, some - not. On test server with small number of active peers (and same config) we doesn't see this issue. What can be done? Right now we see the problem on pure 1.2.0 release... About "UPDATE message immediately after it sent OPEN" - we ask one of our customers (which hit that problem) to collect debug from his side. See the attachments (3 files). One more, after applying the "well-known communities" patch, the BIRD goes to .core two times ( 5-30 seconds after startup):( Do you need the last core file? Without "well-known communities" patch we doesn't see this. (yet) -- Mikhail A. Grishin E-mail: magr@ripn.net Phone: +7 (495) 737-0685 MSK-IX & Russian Institute for Public Networks Phone: +7 (499) 192-9179 Network Operations Center c7606s-m9-1#show version Cisco IOS Software, c7600rsp72043_rp Software (c7600rsp72043_rp-ADVIPSERVICESK9-M), Version 12.2(33)SRB4, RELEASE SOFTWARE (fc3) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2008 by Cisco Systems, Inc. Compiled Wed 23-Jul-08 19:23 by prod_rel_team ROM: System Bootstrap, Version 12.2(33r)SRB4, RELEASE SOFTWARE (fc1) c7606s-m9-1 uptime is 27 weeks, 2 days, 1 hour, 45 minutes Uptime for this control processor is 27 weeks, 2 days, 2 hours, 19 minutes Time since c7606s-m9-1 switched to active is 27 weeks, 2 days, 2 hours, 21 minutes System returned to ROM by s/w reset (SP by bus error at PC 0x8273DCC, address 0x0) System restarted at 11:48:30 MSD Tue Jul 21 2009 System image file is "bootdisk:c7600rsp72043-advipservicesk9-mz.122-33.SRB4.bin" Last reload type: Normal Reload Jan 28 13:02:43.008: BGP: ses global 193.232.246.100 (0) act read request no-op .Jan 28 13:02:43.008: BGP: ses global 193.232.246.100 (0) act Adding topology IPv4 Unicast:base .Jan 28 13:02:43.008: BGP: 193.232.246.100 active went from Active to OpenSent .Jan 28 13:02:43.008: BGP: 193.232.246.100 active sending OPEN, version 4, my as: 41842, holdtime 180 ID 4DF660A0seconds .Jan 28 13:02:43.008: BGP: 193.232.246.100 active send message type 1, length (incl. header) 50 .Jan 28 13:02:43.008: BGP: 193.232.246.100 active rcv message type 1, length (excl. header) 26 .Jan 28 13:02:43.008: BGP: 193.232.246.100 active rcv OPEN, version 4, holdtime 180 seconds .Jan 28 13:02:43.008: BGP: 193.232.246.100 active rcv OPEN w/ OPTION parameter len: 16 .Jan 28 13:02:43.008: BGP: 193.232.246.100 active rcvd OPEN w/ optional parameter type 2 (Capability) len 14 .Jan 28 13:02:43.008: BGP: 193.232.246.100 active OPEN has CAPABILITY code: 1, length 4 .Jan 28 13:02:43.008: BGP: 193.232.246.100 active OPEN has MP_EXT CAP for afi/safi: 1/1 .Jan 28 13:02:43.008: BGP: 193.232.246.100 active OPEN has CAPABILITY code: 2, length 0 .Jan 28 13:02:43.008: BGP: 193.232.246.100 active OPEN has ROUTE-REFRESH capability(new) for all address-families .Jan 28 13:02:43.008: BGP: 193.232.246.100 active OPEN has CAPABILITY code: 65, length 4 .Jan 28 13:02:43.008: BGP: 193.232.246.100 active unrecognized capability code: 65 - ingored .Jan 28 13:02:43.008: BGP: nbr global 193.232.246.100 neighbor does not have IPv4 MDT topology activated .Jan 28 13:02:43.008: BGP: nbr global 193.232.246.100 BGP nbr does not have BGP_AF_IPv4MDT topology activated .Jan 28 13:02:43.008: BGP: ses global 193.232.246.100 (0) act IPv4 Unicast:base mdt prepare old peer: BGP_MDT_STYLE_NONE or Internal Problem .Jan 28 13:02:43.008: BGP: 193.232.246.100 active rcvd OPEN w/ remote AS 8631 .Jan 28 13:02:43.008: BGP: 193.232.246.100 active went from OpenSent to OpenConfirm .Jan 28 13:02:43.008: BGP: ses global 193.232.246.100 (0) act IPv4 Unicast:base write request no-op .Jan 28 13:02:43.008: BGP: 193.232.246.100 active went from OpenConfirm to Established .Jan 28 13:02:43.008: BGP: ses global 193.232.246.100 (1) act IPv4 Unicast:base Assigned ID .Jan 28 13:02:43.008: BGP: mark 193.232.246.100(base) as a new member of update-group 6 .Jan 28 13:02:43.008: %BGP-5-ADJCHANGE: neighbor 193.232.246.100 Up .Jan 28 13:02:43.008: BGP: ses global 193.232.246.100 (1) IPv4 Unicast:base Setting keepalive timer to 60 seconds. .Jan 28 13:02:44.792: BGP: ses global 193.232.246.100 (1) IPv4 Unicast:base Setting keepalive timer to 60 seconds. .Jan 28 13:02:44.796: BGP: ses global 193.232.246.100 (1) IPv4 Unicast:base Setting keepalive timer to 60 seconds. .Jan 28 13:02:44.796: BGP: ses global 193.232.246.100 (1) IPv4 Unicast:base Remote close. .Jan 28 13:02:44.796: BGP: ses global 193.232.246.100 (1) IPv4 Unicast:base Reset (Peer closed the session). .Jan 28 13:02:44.796: BGP: tbl IPv4 Unicast:base Service reset requests Syslog logging: enabled (0 messages dropped, 31 messages rate-limited, 0 flushes, 0 overruns, xml disabled, filtering disabled) No Active Message Discriminator. No Inactive Message Discriminator. Console logging: disabled Monitor logging: level debugging, 2572 messages logged, xml disabled, filtering disabled Buffer logging: level debugging, 10925 messages logged, xml disabled, filtering disabled Exception Logging: size (4096 bytes) Count and timestamp logging messages: disabled Persistent logging: disabled No active filter modules. Trap logging: level debugging, 9580 message lines logged Log Buffer (40960 bytes): -prefix 77.246.96.125/32 : out of version range .Jan 28 13:03:18.992: BGP(0): sub-prefix 77.246.96.126/32 : out of version range .Jan 28 13:03:18.992: BGP(0): sub-prefix 77.246.96.192/30 : out of range .Jan 28 13:03:18.992: BGP(0): Need not be re-aggregated .Jan 28 13:03:18.992: BGP(0): For aggregate 77.246.100.160/28 .Jan 28 13:03:18.992: BGP(0): 77.246.100.160/28 subtree has an entry 77.246.100.160/28 .Jan 28 13:03:18.992: BGP(0): 77.246.100.160/28 subtree has another entry 77.246.100.161/32 .Jan 28 13:03:18.992: BGP(0): sub-prefix 77.246.100.161/32 : out of version range .Jan 28 13:03:18.992: BGP(0): sub-prefix 77.246.100.162/32 : out of version range .Jan 28 13:03:18.992: BGP(0): sub-prefix 77.246.100.163/32 : out of version range .Jan 28 13:03:18.992: BGP(0): sub-prefix 77.246.100.164/32 : out of version range .Jan 28 13:03:18.992: BGP(0): sub-prefix 77.246.100.166/32 : out of version range .Jan 28 13:03:18.992: BGP(0): sub-prefix 77.246.100.167/32 : out of version range .Jan 28 13:03:18.992: BGP(0): sub-prefix 77.246.100.168/32 : out of version range .Jan 28 13:03:18.992: BGP(0): sub-prefix 77.246.100.169/32 : out of version range .Jan 28 13:03:18.992: BGP(0): sub-prefix 77.246.100.170/32 : out of version range .Jan 28 13:03:18.992: BGP(0): sub-prefix 77.246.100.171/32 : out of version range .Jan 28 13:03:18.992: BGP(0): sub-prefix 77.246.100.172/32 : out of version range .Jan 28 13:03:18.992: BGP(0): sub-prefix 77.246.100.173/32 : out of version range .Jan 28 13:03:18.992: BGP(0): sub-prefix 77.246.100.174/32 : out of version range .Jan 28 13:03:18.992: BGP(0): sub-prefix 77.246.100.175/32 : out of version range .Jan 28 13:03:18.992: BGP(0): sub-prefix 77.246.100.176/30 : out of range .Jan 28 13:03:18.992: BGP(0): Need not be re-aggregated .Jan 28 13:03:18.992: BGP(0): For aggregate 77.246.100.176/28 .Jan 28 13:03:18.992: BGP(0): 77.246.100.176/28 subtree has an entry 77.246.100.176/30 .Jan 28 13:03:18.992: BGP(0): sub-prefix 77.246.100.176/30 : out of version range .Jan 28 13:03:18.992: BGP(0): sub-prefix 77.246.100.176/28 : out of version range .Jan 28 13:03:18.992: BGP(0): sub-prefix 77.246.100.180/30 : out of version range .Jan 28 13:03:18.992: BGP(0): sub-prefix 77.246.100.184/30 : out of version range .Jan 28 13:03:18.992: BGP(0): sub-prefix 77.246.100.188/30 : out of version range .Jan 28 13:03:18.992: BGP(0): sub-prefix 77.246.104.0/21 : out of range .Jan 28 13:03:18.992: BGP(0): Need not be re-aggregated .Jan 28 13:03:20.016: BGP: tbl IPv4 Unicast:base Service reset requests .Jan 28 13:03:20.016: BGP: tbl VPNv4 Unicast:base Service reset requests .Jan 28 13:03:20.016: BGP: tbl IPv4 Multicast:base Service reset requests Jan 28 13:03:27.188: BGP_Router: unhandled major event code 128, minor 0 Jan 28 13:03:30.200: BGP: Regular scanner timer event Jan 28 13:03:30.200: BGP: Performing BGP general scanning Jan 28 13:03:30.200: BGP: topo global:IPv4 Unicast:base Scanning routing tables Jan 28 13:03:30.200: BGP: tbl IPv4 Unicast:base Performing BGP Nexthop scanning for general scan Jan 28 13:03:30.200: BGP(0): Future scanner version: 271508, current scanner version: 271507 Jan 28 13:03:30.960: BGP: topo global:VPNv4 Unicast:base Scanning routing tables Jan 28 13:03:30.980: BGP: topo vrf-ipv4u-svaoix:VPNv4 Unicast:base Scanning routing tables Jan 28 13:03:30.980: BGP: tbl VPNv4 Unicast:base Performing BGP Nexthop scanning for general scan Jan 28 13:03:30.980: BGP(4): Future scanner version: 271510, current scanner version: 271509 Jan 28 13:03:30.980: BGP: topo global:IPv4 Multicast:base Scanning routing tables Jan 28 13:03:30.980: BGP: tbl IPv4 Multicast:base Performing BGP Nexthop scanning for general scan Jan 28 13:03:30.980: BGP(6): Future scanner version: 271510, current scanner version: 271509 Jan 28 13:03:34.560: BGP: 193.232.246.100 active went from Idle to Active Jan 28 13:03:34.560: BGP: 193.232.246.100 open active, local address 193.232.246.200 Jan 28 13:03:34.560: BGP: ses global 193.232.246.100 (0) act read request no-op Jan 28 13:03:34.560: BGP: ses global 193.232.246.100 (0) act Adding topology IPv4 Unicast:base Jan 28 13:03:34.560: BGP: 193.232.246.100 active went from Active to OpenSent Jan 28 13:03:34.560: BGP: 193.232.246.100 active sending OPEN, version 4, my as: 41842, holdtime 180 ID 4DF660A0seconds Jan 28 13:03:34.560: BGP: 193.232.246.100 active send message type 1, length (incl. header) 50 Jan 28 13:03:34.560: BGP: ses global 193.232.246.100 (0) act IPv4 Unicast:base read request no-op Jan 28 13:03:34.560: BGP: ses global 193.232.246.100 (0) act IPv4 Unicast:base Remote close. Jan 28 13:03:34.560: BGP: tbl IPv4 Unicast:base Service reset requests Jan 28 13:03:34.764: BGP: ses global 193.232.246.100 (0) act IPv4 Unicast:base read request no-op Jan 28 13:03:34.764: BGP: ses global 193.232.246.100 (0) act IPv4 Unicast:base Remote close. Jan 28 13:03:35.196: BGP: tbl VPNv4 Unicast:base Service reset requests Jan 28 13:03:35.196: BGP: tbl IPv4 Multicast:base Service reset requests Jan 28 13:03:35.196: BGP: nbr_topo global 193.232.246.100 IPv4 Unicast:base (0) NSF no stale paths state is NSF not active Jan 28 13:03:35.196: BGP: nbr_topo global 193.232.246.100 IPv4 Unicast:base (0) Resetting ALL counters. Jan 28 13:03:35.196: BGP: 193.232.246.100 active closing Jan 28 13:03:35.196: BGP: nbr_topo global 193.232.246.100 IPv4 Unicast:base (0) Resetting ALL counters. Jan 28 13:03:35.196: BGP: 193.232.246.100 active went from OpenSent to Idle Jan 28 13:03:35.196: BGP: nbr global 193.232.246.100 Open active delayed 16384ms (35000ms max, 60% jitter) Jan 28 13:03:38.664: BGP: tbl IPv4 Unicast:base Service reset requests Jan 28 13:03:38.664: BGP: tbl VPNv4 Unicast:base Service reset requests Jan 28 13:03:38.664: BGP: tbl IPv4 Multicast:base Service reset requests Jan 28 13:03:38.752: BGP: tbl IPv4 Unicast:base Service reset requests Jan 28 13:03:38.752: BGP: tbl VPNv4 Unicast:base Service reset requests Jan 28 13:03:38.752: BGP: tbl IPv4 Multicast:base Service reset requests Jan 28 13:03:39.680: BGP: tbl IPv4 Unicast:base Service reset requests Jan 28 13:03:39.680: BGP: tbl VPNv4 Unicast:base Service reset requests Jan 28 13:03:39.680: BGP: tbl IPv4 Multicast:base Service reset requests Jan 28 13:03:40.800: BGP: tbl IPv4 Unicast:base Service reset requests Jan 28 13:03:40.800: BGP: tbl VPNv4 Unicast:base Service reset requests Jan 28 13:03:40.800: BGP: tbl IPv4 Multicast:base Service reset requests Jan 28 13:03:46.084: BGP: Regular scanner timer event Jan 28 13:03:46.084: BGP(4): Import timer expired. Walking from 159954 to 159954 Jan 28 13:03:49.920: BGP: aggregate timer expired Jan 28 13:03:49.920: BGP(0): Aggregate processing for IPv4 Unicast Jan 28 13:03:49.920: BGP(0): For aggregate 77.246.96.96/27 Jan 28 13:03:49.920: BGP(0): 77.246.96.96/27 subtree has an entry 77.246.96.96/27 Jan 28 13:03:49.920: BGP(0): 77.246.96.96/27 subtree has another entry 77.246.96.99/32 Jan 28 13:03:49.920: BGP(0): sub-prefix 77.246.96.99/32 : out of version range Jan 28 13:03:49.920: BGP(0): sub-prefix 77.246.96.100/32 : out of version range Jan 28 13:03:49.920: BGP(0): sub-prefix 77.246.96.101/32 : out of version range Jan 28 13:03:49.920: BGP(0): sub-prefix 77.246.96.102/32 : out of version range Jan 28 13:03:49.920: BGP(0): sub-prefix 77.246.96.103/32 : out of version range Jan 28 13:03:49.920: BGP(0): sub-prefix 77.246.96.104/32 : out of version range Jan 28 13:03:49.920: BGP(0): sub-prefix 77.246.96.105/32 : out of version range Jan 28 13:03:49.920: BGP(0): sub-prefix 77.246.96.106/32 : out of version range Jan 28 13:03:49.920: BGP(0): sub-prefix 77.246.96.107/32 : out of version range Jan 28 13:03:49.920: BGP(0): sub-prefix 77.246.96.108/32 : out of version range Jan 28 13:03:49.920: BGP(0): sub-prefix 77.246.96.109/32 : out of version range Jan 28 13:03:49.920: BGP(0): sub-prefix 77.246.96.112/32 : out of version range Jan 28 13:03:49.920: BGP(0): sub-prefix 77.246.96.116/32 : out of version range Jan 28 13:03:49.920: BGP(0): sub-prefix 77.246.96.118/32 : out of version range Jan 28 13:03:49.920: BGP(0): sub-prefix 77.246.96.122/32 : out of version range Jan 28 13:03:49.920: BGP(0): sub-prefix 77.246.96.123/32 : out of version range Jan 28 13:03:49.920: BGP(0): sub-prefix 77.246.96.125/32 : out of version range Jan 28 13:03:49.920: BGP(0): sub-prefix 77.246.96.126/32 : out of version range Jan 28 13:03:49.920: BGP(0): sub-prefix 77.246.96.192/30 : out of range Jan 28 13:03:49.920: BGP(0): Need not be re-aggregated Jan 28 13:03:49.920: BGP(0): For aggregate 77.246.100.160/28 Jan 28 13:03:49.920: BGP(0): 77.246.100.160/28 subtree has an entry 77.246.100.160/28 Jan 28 13:03:49.920: BGP(0): 77.246.100.160/28 subtree has another entry 77.246.100.161/32 Jan 28 13:03:49.920: BGP(0): sub-prefix 77.246.100.161/32 : out of version range Jan 28 13:03:49.920: BGP(0): sub-prefix 77.246.100.162/32 : out of version range Jan 28 13:03:49.920: BGP(0): sub-prefix 77.246.100.163/32 : out of version range Jan 28 13:03:49.920: BGP(0): sub-prefix 77.246.100.164/32 : out of version range Jan 28 13:03:49.920: BGP(0): sub-prefix 77.246.100.166/32 : out of version range Jan 28 13:03:49.920: BGP(0): sub-prefix 77.246.100.167/32 : out of version range Jan 28 13:03:49.920: BGP(0): sub-prefix 77.246.100.168/32 : out of version range Jan 28 13:03:49.920: BGP(0): sub-prefix 77.246.100.169/32 : out of version range Jan 28 13:03:49.920: BGP(0): sub-prefix 77.246.100.170/32 : out of version range Jan 28 13:03:49.920: BGP(0): sub-prefix 77.246.100.171/32 : out of version range Jan 28 13:03:49.920: BGP(0): sub-prefix 77.246.100.172/32 : out of version range Jan 28 13:03:49.920: BGP(0): sub-prefix 77.246.100.173/32 : out of version range Jan 28 13:03:49.920: BGP(0): sub-prefix 77.246.100.174/32 : out of version range Jan 28 13:03:49.920: BGP(0): sub-prefix 77.246.100.175/32 : out of version range Jan 28 13:03:49.920: BGP(0): sub-prefix 77.246.100.176/30 : out of range Jan 28 13:03:49.920: BGP(0): Need not be re-aggregated Jan 28 13:03:49.920: BGP(0): For aggregate 77.246.100.176/28 Jan 28 13:03:49.920: BGP(0): 77.246.100.176/28 subtree has an entry 77.246.100.176/30 Jan 28 13:03:49.920: BGP(0): sub-prefix 77.246.100.176/30 : out of version range Jan 28 13:03:49.920: BGP(0): sub-prefix 77.246.100.176/28 : out of version range Jan 28 13:03:49.920: BGP(0): sub-prefix 77.246.100.180/30 : out of version range Jan 28 13:03:49.920: BGP(0): sub-prefix 77.246.100.184/30 : out of version range Jan 28 13:03:49.920: BGP(0): sub-prefix 77.246.100.188/30 : out of version range Jan 28 13:03:49.920: BGP(0): sub-prefix 77.246.104.0/21 : out of range Jan 28 13:03:49.920: BGP(0): Need not be re-aggregated Jan 28 13:03:50.944: BGP: 193.232.246.100 active went from Idle to Active Jan 28 13:03:50.944: BGP: 193.232.246.100 open active, local address 193.232.246.200 Jan 28 13:03:50.944: BGP: ses global 193.232.246.100 (0) act read request no-op Jan 28 13:03:50.944: BGP: ses global 193.232.246.100 (0) act Adding topology IPv4 Unicast:base Jan 28 13:03:50.944: BGP: 193.232.246.100 active went from Active to OpenSent Jan 28 13:03:50.944: BGP: 193.232.246.100 active sending OPEN, version 4, my as: 41842, holdtime 180 ID 4DF660A0seconds Jan 28 13:03:50.944: BGP: 193.232.246.100 active send message type 1, length (incl. header) 50 Jan 28 13:03:50.944: BGP: ses global 193.232.246.100 (0) act IPv4 Unicast:base read request no-op Jan 28 13:03:50.944: BGP: ses global 193.232.246.100 (0) act IPv4 Unicast:base Remote close. Jan 28 13:03:50.944: BGP: tbl IPv4 Unicast:base Service reset requests Jan 28 13:03:51.144: BGP: ses global 193.232.246.100 (0) act IPv4 Unicast:base read request no-op Jan 28 13:03:51.144: BGP: ses global 193.232.246.100 (0) act IPv4 Unicast:base Remote close. Jan 28 13:03:51.580: BGP: tbl VPNv4 Unicast:base Service reset requests Jan 28 13:03:51.580: BGP: tbl IPv4 Multicast:base Service reset requests Jan 28 13:03:51.580: BGP: nbr_topo global 193.232.246.100 IPv4 Unicast:base (0) NSF no stale paths state is NSF not active Jan 28 13:03:51.580: BGP: nbr_topo global 193.232.246.100 IPv4 Unicast:base (0) Resetting ALL counters. Jan 28 13:03:51.580: BGP: 193.232.246.100 active closing Jan 28 13:03:51.580: BGP: nbr_topo global 193.232.246.100 IPv4 Unicast:base (0) Resetting ALL counters. Jan 28 13:03:51.580: BGP: 193.232.246.100 active went from OpenSent to Idle Jan 28 13:03:51.580: BGP: nbr global 193.232.246.100 Open active delayed 22528ms (35000ms max, 60% jitter) Jan 28 13:03:57.208: BGP: tbl IPv4 Unicast:base Service reset requests Jan 28 13:03:57.208: BGP: tbl VPNv4 Unicast:base Service reset requests Jan 28 13:03:57.208: BGP: tbl IPv4 Multicast:base Service reset requests Jan 28 13:03:59.508: BGP_Router: unhandled major event code 128, minor 0 Jan 28 13:04:00.168: BGP: tbl IPv4 Unicast:base Service reset requests Jan 28 13:04:00.168: BGP: tbl VPNv4 Unicast:base Service reset requests Jan 28 13:04:00.168: BGP: tbl IPv4 Multicast:base Service reset requests Jan 28 13:04:00.404: BGP: tbl IPv4 Unicast:base Service reset requests Jan 28 13:04:00.404: BGP: tbl VPNv4 Unicast:base Service reset requests Jan 28 13:04:00.404: BGP: tbl IPv4 Multicast:base Service reset requests Jan 28 13:04:01.084: BGP: Regular scanner timer event Jan 28 13:04:01.084: BGP(4): Import timer expired. Walking from 159954 to 159954 Jan 28 13:04:04.740: BGP_Router: unhandled major event code 128, minor 0 Jan 28 13:04:08.760: BGP_Router: unhandled major event code 128, minor 0 .Jan 28 13:04:11.285: BGP_Router: unhandled major event code 128, minor 0 .Jan 28 13:04:11.505: BGP_Router: unhandled major event code 128, minor 0 .Jan 28 13:04:13.473: BGP: 193.232.246.100 active went from Idle to Active .Jan 28 13:04:13.473: BGP: 193.232.246.100 open active, local address 193.232.246.200 .Jan 28 13:04:13.473: BGP: ses global 193.232.246.100 (0) act read request no-op .Jan 28 13:04:13.473: BGP: ses global 193.232.246.100 (0) act Adding topology IPv4 Unicast:base .Jan 28 13:04:13.473: BGP: 193.232.246.100 active went from Active to OpenSent .Jan 28 13:04:13.473: BGP: 193.232.246.100 active sending OPEN, version 4, my as: 41842, holdtime 180 ID 4DF660A0seconds .Jan 28 13:04:13.473: BGP: 193.232.246.100 active send message type 1, length (incl. header) 50 .Jan 28 13:04:13.473: BGP: ses global 193.232.246.100 (0) act IPv4 Unicast:base read request no-op .Jan 28 13:04:13.473: BGP: ses global 193.232.246.100 (0) act IPv4 Unicast:base Remote close. .Jan 28 13:04:13.473: BGP: tbl IPv4 Unicast:base Service reset requests .Jan 28 13:04:13.673: BGP: ses global 193.232.246.100 (0) act IPv4 Unicast:base read request no-op .Jan 28 13:04:13.673: BGP: ses global 193.232.246.100 (0) act IPv4 Unicast:base Remote close. .Jan 28 13:04:14.113: BGP: tbl VPNv4 Unicast:base Service reset requests .Jan 28 13:04:14.113: BGP: tbl IPv4 Multicast:base Service reset requests .Jan 28 13:04:14.113: BGP: nbr_topo global 193.232.246.100 IPv4 Unicast:base (0) NSF no stale paths state is NSF not active .Jan 28 13:04:14.113: BGP: nbr_topo global 193.232.246.100 IPv4 Unicast:base (0) Resetting ALL counters. .Jan 28 13:04:14.113: BGP: 193.232.246.100 active closing .Jan 28 13:04:14.113: BGP: nbr_topo global 193.232.246.100 IPv4 Unicast:base (0) Resetting ALL counters. .Jan 28 13:04:14.113: BGP: 193.232.246.100 active went from OpenSent to Idle .Jan 28 13:04:14.113: BGP: nbr global 193.232.246.100 Open active delayed 21504ms (35000ms max, 60% jitter) .Jan 28 13:04:15.505: BGP_Router: unhandled major event code 128, minor 0 .Jan 28 13:04:15.521: BGP: tbl IPv4 Unicast:base Service reset requests .Jan 28 13:04:15.521: BGP: tbl VPNv4 Unicast:base Service reset requests .Jan 28 13:04:15.521: BGP: tbl IPv4 Multicast:base Service reset requests .Jan 28 13:04:16.085: BGP: Regular scanner timer event .Jan 28 13:04:16.085: BGP(4): Import timer expired. Walking from 159954 to 159954 .Jan 28 13:04:18.601: BGP: tbl IPv4 Unicast:base Service reset requests .Jan 28 13:04:18.601: BGP: tbl VPNv4 Unicast:base Service reset requests .Jan 28 13:04:18.601: BGP: tbl IPv4 Multicast:base Service reset requests .Jan 28 13:04:20.641: BGP: aggregate timer expired .Jan 28 13:04:20.641: BGP(0): Aggregate processing for IPv4 Unicast .Jan 28 13:04:20.641: BGP(0): For aggregate 77.246.96.96/27 .Jan 28 13:04:20.641: BGP(0): 77.246.96.96/27 subtree has an entry 77.246.96.96/27 .Jan 28 13:04:20.641: BGP(0): 77.246.96.96/27 subtree has another entry 77.246.96.99/32 .Jan 28 13:04:20.641: BGP(0): sub-prefix 77.246.96.99/32 : out of version range .Jan 28 13:04:20.641: BGP(0): sub-prefix 77.246.96.100/32 : out of version range .Jan 28 13:04:20.641: BGP(0): sub-prefix 77.246.96.101/32 : out of version range .Jan 28 13:04:20.641: BGP(0): sub-prefix 77.246.96.102/32 : out of version range .Jan 28 13:04:20.641: BGP(0): sub-prefix 77.246.96.103/32 : out of version range .Jan 28 13:04:20.641: BGP(0): sub-prefix 77.246.96.104/32 : out of version range .Jan 28 13:04:20.641: BGP(0): sub-prefix 77.246.96.105/32 : out of version range .Jan 28 13:04:20.641: BGP(0): sub-prefix 77.246.96.106/32 : out of version range .Jan 28 13:04:20.641: BGP(0): sub-prefix 77.246.96.107/32 : out of version range .Jan 28 13:04:20.641: BGP(0): sub-prefix 77.246.96.108/32 : out of version range .Jan 28 13:04:20.641: BGP(0): sub-prefix 77.246.96.109/32 : out of version range .Jan 28 13:04:20.641: BGP(0): sub-prefix 77.246.96.112/32 : out of version range .Jan 28 13:04:20.641: BGP(0): sub-prefix 77.246.96.116/32 : out of version range .Jan 28 13:04:20.641: BGP(0): sub-prefix 77.246.96.118/32 : out of version range .Jan 28 13:04:20.641: BGP(0): sub-prefix 77.246.96.122/32 : out of version range .Jan 28 13:04:20.641: BGP(0): sub-prefix 77.246.96.123/32 : out of version range .Jan 28 13:04:20.641: BGP(0): sub-prefix 77.246.96.125/32 : out of version range .Jan 28 13:04:20.641: BGP(0): sub-prefix 77.246.96.126/32 : out of version range .Jan 28 13:04:20.641: BGP(0): sub-prefix 77.246.96.192/30 : out of range .Jan 28 13:04:20.641: BGP(0): Need not be re-aggregated .Jan 28 13:04:20.641: BGP(0): For aggregate 77.246.100.160/28 .Jan 28 13:04:20.641: BGP(0): 77.246.100.160/28 subtree has an entry 77.246.100.160/28 .Jan 28 13:04:20.641: BGP(0): 77.246.100.160/28 subtree has another entry 77.246.100.161/32 .Jan 28 13:04:20.641: BGP(0): sub-prefix 77.246.100.161/32 : out of version range .Jan 28 13:04:20.641: BGP(0): sub-prefix 77.246.100.162/32 : out of version range .Jan 28 13:04:20.641: BGP(0): sub-prefix 77.246.100.163/32 : out of version range .Jan 28 13:04:20.641: BGP(0): sub-prefix 77.246.100.164/32 : out of version range .Jan 28 13:04:20.641: BGP(0): sub-prefix 77.246.100.166/32 : out of version range .Jan 28 13:04:20.641: BGP(0): sub-prefix 77.246.100.167/32 : out of version range .Jan 28 13:04:20.641: BGP(0): sub-prefix 77.246.100.168/32 : out of version range .Jan 28 13:04:20.641: BGP(0): sub-prefix 77.246.100.169/32 : out of version range .Jan 28 13:04:20.641: BGP(0): sub-prefix 77.246.100.170/32 : out of version range .Jan 28 13:04:20.641: BGP(0): sub-prefix 77.246.100.171/32 : out of version range .Jan 28 13:04:20.641: BGP(0): sub-prefix 77.246.100.172/32 : out of version range .Jan 28 13:04:20.641: BGP(0): sub-prefix 77.246.100.173/32 : out of version range .Jan 28 13:04:20.641: BGP(0): sub-prefix 77.246.100.174/32 : out of version range .Jan 28 13:04:20.641: BGP(0): sub-prefix 77.246.100.175/32 : out of version range .Jan 28 13:04:20.641: BGP(0): sub-prefix 77.246.100.176/30 : out of range .Jan 28 13:04:20.641: BGP(0): Need not be re-aggregated .Jan 28 13:04:20.641: BGP(0): For aggregate 77.246.100.176/28 .Jan 28 13:04:20.641: BGP(0): 77.246.100.176/28 subtree has an entry 77.246.100.176/30 .Jan 28 13:04:20.641: BGP(0): sub-prefix 77.246.100.176/30 : out of version range .Jan 28 13:04:20.641: BGP(0): sub-prefix 77.246.100.176/28 : out of version range .Jan 28 13:04:20.641: BGP(0): sub-prefix 77.246.100.180/30 : out of version range .Jan 28 13:04:20.641: BGP(0): sub-prefix 77.246.100.184/30 : out of version range .Jan 28 13:04:20.641: BGP(0): sub-prefix 77.246.100.188/30 : out of version range .Jan 28 13:04:20.641: BGP(0): sub-prefix 77.246.104.0/21 : out of range .Jan 28 13:04:20.641: BGP(0): Need not be re-aggregated .Jan 28 13:04:20.961: BGP_Router: unhandled major event code 128, minor 0 .Jan 28 13:04:21.733: BGP_Router: unhandled major event code 128, minor 0 .Jan 28 13:04:25.041: BGP: tbl IPv4 Unicast:base Service reset requests .Jan 28 13:04:25.041: BGP: tbl VPNv4 Unicast:base Service reset requests .Jan 28 13:04:25.041: BGP: tbl IPv4 Multicast:base Service reset requests .Jan 28 13:04:30.161: BGP: tbl IPv4 Unicast:base Service reset requests .Jan 28 13:04:30.161: BGP: tbl VPNv4 Unicast:base Service reset requests .Jan 28 13:04:30.161: BGP: tbl IPv4 Multicast:base Service reset requests .Jan 28 13:04:31.085: BGP: Regular scanner timer event .Jan 28 13:04:31.085: BGP: Performing BGP general scanning .Jan 28 13:04:31.085: BGP: topo global:IPv4 Unicast:base Scanning routing tables .Jan 28 13:04:31.085: BGP: tbl IPv4 Unicast:base Performing BGP Nexthop scanning for general scan .Jan 28 13:04:31.085: BGP(0): Future scanner version: 271509, current scanner version: 271508 .Jan 28 13:04:31.821: BGP: topo global:VPNv4 Unicast:base Scanning routing tables .Jan 28 13:04:31.821: BGP: topo vrf-ipv4u-svaoix:VPNv4 Unicast:base Scanning routing tables .Jan 28 13:04:31.821: BGP: tbl VPNv4 Unicast:base Performing BGP Nexthop scanning for general scan .Jan 28 13:04:31.821: BGP(4): Future scanner version: 271511, current scanner version: 271510 .Jan 28 13:04:31.821: BGP: topo global:IPv4 Multicast:base Scanning routing tables .Jan 28 13:04:31.821: BGP: tbl IPv4 Multicast:base Performing BGP Nexthop scanning for general scan .Jan 28 13:04:31.821: BGP(6): Future scanner version: 271511, current scanner version: 271510 .Jan 28 13:04:32.957: BGP: tbl IPv4 Unicast:base Service reset requests .Jan 28 13:04:32.957: BGP: tbl VPNv4 Unicast:base Service reset requests .Jan 28 13:04:32.957: BGP: tbl IPv4 Multicast:base Service reset requests .Jan 28 13:04:34.997: BGP: 193.232.246.100 active went from Idle to Active .Jan 28 13:04:34.997: BGP: 193.232.246.100 open active, local address 193.232.246.200 .Jan 28 13:04:34.997: BGP: ses global 193.232.246.100 (0) act read request no-op .Jan 28 13:04:34.997: BGP: ses global 193.232.246.100 (0) act Adding topology IPv4 Unicast:base .Jan 28 13:04:34.997: BGP: 193.232.246.100 active went from Active to OpenSent .Jan 28 13:04:34.997: BGP: 193.232.246.100 active sending OPEN, version 4, my as: 41842, holdtime 180 ID 4DF660A0seconds .Jan 28 13:04:34.997: BGP: 193.232.246.100 active send message type 1, length (incl. header) 50 .Jan 28 13:04:34.997: BGP: tbl IPv4 Unicast:base Service reset requests .Jan 28 13:04:34.997: BGP: tbl VPNv4 Unicast:base Service reset requests .Jan 28 13:04:34.997: BGP: tbl IPv4 Multicast:base Service reset requests .Jan 28 13:04:35.001: BGP: ses global 193.232.246.100 (0) act IPv4 Unicast:base read request no-op .Jan 28 13:04:35.001: BGP: ses global 193.232.246.100 (0) act IPv4 Unicast:base Remote close. .Jan 28 13:04:35.001: BGP: tbl IPv4 Unicast:base Service reset requests .Jan 28 13:04:35.205: BGP: ses global 193.232.246.100 (0) act IPv4 Unicast:base read request no-op .Jan 28 13:04:35.205: BGP: ses global 193.232.246.100 (0) act IPv4 Unicast:base Remote close. .Jan 28 13:04:35.633: BGP: tbl VPNv4 Unicast:base Service reset requests .Jan 28 13:04:35.633: BGP: tbl IPv4 Multicast:base Service reset requests .Jan 28 13:04:35.633: BGP: nbr_topo global 193.232.246.100 IPv4 Unicast:base (0) NSF no stale paths state is NSF not active .Jan 28 13:04:35.633: BGP: nbr_topo global 193.232.246.100 IPv4 Unicast:base (0) Resetting ALL counters. .Jan 28 13:04:35.633: BGP: 193.232.246.100 active closing .Jan 28 13:04:35.633: BGP: nbr_topo global 193.232.246.100 IPv4 Unicast:base (0) Resetting ALL counters. .Jan 28 13:04:35.633: BGP: 193.232.246.100 active went from OpenSent to Idle .Jan 28 13:04:35.633: BGP: nbr global 193.232.246.100 Open active delayed 17408ms (35000ms max, 60% jitter) .Jan 28 13:04:46.925: BGP: Regular scanner timer event .Jan 28 13:04:46.925: BGP(4): Import timer expired. Walking from 159954 to 159954 .Jan 28 13:04:47.293: BGP: tbl IPv4 Unicast:base Service reset requests .Jan 28 13:04:47.293: BGP: tbl VPNv4 Unicast:base Service reset requests .Jan 28 13:04:47.293: BGP: tbl IPv4 Multicast:base Service reset requests .Jan 28 13:04:47.569: BGP: tbl IPv4 Unicast:base Service reset requests .Jan 28 13:04:47.569: BGP: tbl VPNv4 Unicast:base Service reset requests .Jan 28 13:04:47.569: BGP: tbl IPv4 Multicast:base Service reset requests .Jan 28 13:04:51.381: BGP: aggregate timer expired .Jan 28 13:04:51.381: BGP(0): Aggregate processing for IPv4 Unicast .Jan 28 13:04:51.381: BGP(0): For aggregate 77.246.96.96/27 .Jan 28 13:04:51.381: BGP(0): 77.246.96.96/27 subtree has an entry 77.246.96.96/27 .Jan 28 13:04:51.381: BGP(0): 77.246.96.96/27 subtree has another entry 77.246.96.99/32 .Jan 28 13:04:51.381: BGP(0): sub-prefix 77.246.96.99/32 : out of version range .Jan 28 13:04:51.381: BGP(0): sub-prefix 77.246.96.100/32 : out of version range .Jan 28 13:04:51.381: BGP(0): sub-prefix 77.246.96.101/32 : out of version range .Jan 28 13:04:51.381: BGP(0): sub-prefix 77.246.96.102/32 : out of version range .Jan 28 13:04:51.381: BGP(0): sub-prefix 77.246.96.103/32 : out of version range .Jan 28 13:04:51.381: BGP(0): sub-prefix 77.246.96.104/32 : out of version range .Jan 28 13:04:51.381: BGP(0): sub-prefix 77.246.96.105/32 : out of version range .Jan 28 13:04:51.381: BGP(0): sub-prefix 77.246.96.106/32 : out of version range .Jan 28 13:04:51.381: BGP(0): sub-prefix 77.246.96.107/32 : out of version range .Jan 28 13:04:51.381: BGP(0): sub-prefix 77.246.96.108/32 : out of version range .Jan 28 13:04:51.381: BGP(0): sub-prefix 77.246.96.109/32 : out of version range .Jan 28 13:04:51.381: BGP(0): sub-prefix 77.246.96.112/32 : out of version range .Jan 28 13:04:51.381: BGP(0): sub-prefix 77.246.96.116/32 : out of version range .Jan 28 13:04:51.381: BGP(0): sub-prefix 77.246.96.118/32 : out of version range .Jan 28 13:04:51.381: BGP(0): sub-prefix 77.246.96.122/32 : out of version range .Jan 28 13:04:51.381: BGP(0): sub-prefix 77.246.96.123/32 : out of version range .Jan 28 13:04:51.381: BGP(0): sub-prefix 77.246.96.125/32 : out of version range .Jan 28 13:04:51.381: BGP(0): sub-prefix 77.246.96.126/32 : out of version range .Jan 28 13:04:51.381: BGP(0): sub-prefix 77.246.96.192/30 : out of range .Jan 28 13:04:51.381: BGP(0): Need not be re-aggregated .Jan 28 13:04:51.381: BGP(0): For aggregate 77.246.100.160/28 .Jan 28 13:04:51.381: BGP(0): 77.246.100.160/28 subtree has an entry 77.246.100.160/28 .Jan 28 13:04:51.381: BGP(0): 77.246.100.160/28 subtree has another entry 77.246.100.161/32 .Jan 28 13:04:51.381: BGP(0): sub-prefix 77.246.100.161/32 : out of version range .Jan 28 13:04:51.381: BGP(0): sub-prefix 77.246.100.162/32 : out of version range .Jan 28 13:04:51.381: BGP(0): sub-prefix 77.246.100.163/32 : out of version range .Jan 28 13:04:51.381: BGP(0): sub-prefix 77.246.100.164/32 : out of version range .Jan 28 13:04:51.381: BGP(0): sub-prefix 77.246.100.166/32 : out of version range .Jan 28 13:04:51.381: BGP(0): sub-prefix 77.246.100.167/32 : out of version range .Jan 28 13:04:51.381: BGP(0): sub-prefix 77.246.100.168/32 : out of version range .Jan 28 13:04:51.381: BGP(0): sub-prefix 77.246.100.169/32 : out of version range .Jan 28 13:04:51.381: BGP(0): sub-prefix 77.246.100.170/32 : out of version range .Jan 28 13:04:51.381: BGP(0): sub-prefix 77.246.100.171/32 : out of version range .Jan 28 13:04:51.381: BGP(0): sub-prefix 77.246.100.172/32 : out of version range .Jan 28 13:04:51.381: BGP(0): sub-prefix 77.246.100.173/32 : out of version range .Jan 28 13:04:51.381: BGP(0): sub-prefix 77.246.100.174/32 : out of version range .Jan 28 13:04:51.381: BGP(0): sub-prefix 77.246.100.175/32 : out of version range .Jan 28 13:04:51.381: BGP(0): sub-prefix 77.246.100.176/30 : out of range .Jan 28 13:04:51.381: BGP(0): Need not be re-aggregated .Jan 28 13:04:51.381: BGP(0): For aggregate 77.246.100.176/28 .Jan 28 13:04:51.381: BGP(0): 77.246.100.176/28 subtree has an entry 77.246.100.176/30 .Jan 28 13:04:51.381: BGP(0): sub-prefix 77.246.100.176/30 : out of version range .Jan 28 13:04:51.381: BGP(0): sub-prefix 77.246.100.176/28 : out of version range .Jan 28 13:04:51.381: BGP(0): sub-prefix 77.246.100.180/30 : out of version range .Jan 28 13:04:51.381: BGP(0): sub-prefix 77.246.100.184/30 : out of version range .Jan 28 13:04:51.381: BGP(0): sub-prefix 77.246.100.188/30 : out of version range .Jan 28 13:04:51.381: BGP(0): sub-prefix 77.246.104.0/21 : out of range .Jan 28 13:04:51.381: BGP(0): Need not be re-aggregated .Jan 28 13:04:52.081: BGP_Router: unhandled major event code 128, minor 0 .Jan 28 13:04:52.405: BGP: 193.232.246.100 active went from Idle to Active .Jan 28 13:04:52.405: BGP: 193.232.246.100 open active, local address 193.232.246.200 .Jan 28 13:04:52.405: BGP: ses global 193.232.246.100 (0) act read request no-op .Jan 28 13:04:52.405: BGP: ses global 193.232.246.100 (0) act Adding topology IPv4 Unicast:base .Jan 28 13:04:52.405: BGP: 193.232.246.100 active went from Active to OpenSent .Jan 28 13:04:52.405: BGP: 193.232.246.100 active sending OPEN, version 4, my as: 41842, holdtime 180 ID 4DF660A0seconds .Jan 28 13:04:52.405: BGP: 193.232.246.100 active send message type 1, length (incl. header) 50 .Jan 28 13:04:52.405: BGP: ses global 193.232.246.100 (0) act IPv4 Unicast:base read request no-op .Jan 28 13:04:52.405: BGP: ses global 193.232.246.100 (0) act IPv4 Unicast:base Remote close. .Jan 28 13:04:52.405: BGP: tbl IPv4 Unicast:base Service reset requests .Jan 28 13:04:52.605: BGP: ses global 193.232.246.100 (0) act IPv4 Unicast:base read request no-op .Jan 28 13:04:52.605: BGP: ses global 193.232.246.100 (0) act IPv4 Unicast:base Remote close. .Jan 28 13:04:53.037: BGP: tbl VPNv4 Unicast:base Service reset requests .Jan 28 13:04:53.041: BGP: tbl IPv4 Multicast:base Service reset requests .Jan 28 13:04:53.041: BGP: nbr_topo global 193.232.246.100 IPv4 Unicast:base (0) NSF no stale paths state is NSF not active .Jan 28 13:04:53.041: BGP: nbr_topo global 193.232.246.100 IPv4 Unicast:base (0) Resetting ALL counters. .Jan 28 13:04:53.041: BGP: 193.232.246.100 active closing .Jan 28 13:04:53.041: BGP: nbr_topo global 193.232.246.100 IPv4 Unicast:base (0) Resetting ALL counters. .Jan 28 13:04:53.041: BGP: 193.232.246.100 active went from OpenSent to Idle .Jan 28 13:04:53.041: BGP: nbr global 193.232.246.100 Open active delayed 16384ms (35000ms max, 60% jitter) .Jan 28 13:04:55.477: BGP: tbl IPv4 Unicast:base Service reset requests .Jan 28 13:04:55.477: BGP: tbl VPNv4 Unicast:base Service reset requests .Jan 28 13:04:55.477: BGP: tbl IPv4 Multicast:base Service reset requests .Jan 28 13:04:59.573: BGP: aggregate timer expired .Jan 28 13:04:59.573: BGP(0): Aggregate processing for IPv4 Unicast .Jan 28 13:04:59.573: BGP(0): For aggregate 77.246.96.96/27 .Jan 28 13:04:59.573: BGP(0): 77.246.96.96/27 subtree has an entry 77.246.96.96/27 .Jan 28 13:04:59.573: BGP(0): 77.246.96.96/27 subtree has another entry 77.246.96.99/32 .Jan 28 13:04:59.573: BGP(0): sub-prefix 77.246.96.99/32 : out of version range .Jan 28 13:04:59.573: BGP(0): sub-prefix 77.246.96.100/32 : out of version range .Jan 28 13:04:59.573: BGP(0): sub-prefix 77.246.96.101/32 : out of version range .Jan 28 13:04:59.573: BGP(0): sub-prefix 77.246.96.102/32 : out of version range .Jan 28 13:04:59.573: BGP(0): sub-prefix 77.246.96.103/32 : out of version range .Jan 28 13:04:59.573: BGP(0): sub-prefix 77.246.96.104/32 : out of version range .Jan 28 13:04:59.573: BGP(0): sub-prefix 77.246.96.105/32 : out of version range .Jan 28 13:04:59.573: BGP(0): sub-prefix 77.246.96.106/32 : out of version range .Jan 28 13:04:59.573: BGP(0): sub-prefix 77.246.96.107/32 : out of version range .Jan 28 13:04:59.573: BGP(0): sub-prefix 77.246.96.108/32 : out of version range .Jan 28 13:04:59.573: BGP(0): sub-prefix 77.246.96.109/32 : out of version range .Jan 28 13:04:59.573: BGP(0): sub-prefix 77.246.96.112/32 : out of version range .Jan 28 13:04:59.573: BGP(0): sub-prefix 77.246.96.116/32 : out of version range .Jan 28 13:04:59.573: BGP(0): sub-prefix 77.246.96.118/32 : out of version range .Jan 28 13:04:59.573: BGP(0): sub-prefix 77.246.96.122/32 : out of version range .Jan 28 13:04:59.573: BGP(0): sub-prefix 77.246.96.123/32 : out of version range .Jan 28 13:04:59.573: BGP(0): sub-prefix 77.246.96.125/32 : out of version range .Jan 28 13:04:59.573: BGP(0): sub-prefix 77.246.96.126/32 : out of version range .Jan 28 13:04:59.573: BGP(0): sub-prefix 77.246.96.192/30 : out of range .Jan 28 13:04:59.573: BGP(0): Need not be re-aggregated .Jan 28 13:04:59.573: BGP(0): For aggregate 77.246.100.160/28 .Jan 28 13:04:59.573: BGP(0): 77.246.100.160/28 subtree has an entry 77.246.100.160/28 .Jan 28 13:04:59.573: BGP(0): 77.246.100.160/28 subtree has another entry 77.246.100.161/32 .Jan 28 13:04:59.573: BGP(0): sub-prefix 77.246.100.161/32 : out of version range .Jan 28 13:04:59.573: BGP(0): sub-prefix 77.246.100.162/32 : out of version range .Jan 28 13:04:59.573: BGP(0): sub-prefix 77.246.100.163/32 : out of version range .Jan 28 13:04:59.573: BGP(0): sub-prefix 77.246.100.164/32 : out of version range .Jan 28 13:04:59.573: BGP(0): sub-prefix 77.246.100.166/32 : out of version range .Jan 28 13:04:59.573: BGP(0): sub-prefix 77.246.100.167/32 : out of version range .Jan 28 13:04:59.573: BGP(0): sub-prefix 77.246.100.168/32 : out of version range .Jan 28 13:04:59.573: BGP(0): sub-prefix 77.246.100.169/32 : out of version range .Jan 28 13:04:59.573: BGP(0): sub-prefix 77.246.100.170/32 : out of version range .Jan 28 13:04:59.573: BGP(0): sub-prefix 77.246.100.171/32 : out of version range .Jan 28 13:04:59.573: BGP(0): sub-prefix 77.246.100.172/32 : out of version range .Jan 28 13:04:59.573: BGP(0): sub-prefix 77.246.100.173/32 : out of version range .Jan 28 13:04:59.573: BGP(0): sub-prefix 77.246.100.174/32 : out of version range .Jan 28 13:04:59.573: BGP(0): sub-prefix 77.246.100.175/32 : out of version range .Jan 28 13:04:59.573: BGP(0): sub-prefix 77.246.100.176/30 : out of range .Jan 28 13:04:59.573: BGP(0): Need not be re-aggregated .Jan 28 13:04:59.573: BGP(0): For aggregate 77.246.100.176/28 .Jan 28 13:04:59.573: BGP(0): 77.246.100.176/28 subtree has an entry 77.246.100.176/30 .Jan 28 13:04:59.573: BGP(0): sub-prefix 77.246.100.176/30 : out of version range .Jan 28 13:04:59.573: BGP(0): sub-prefix 77.246.100.176/28 : out of version range .Jan 28 13:04:59.573: BGP(0): sub-prefix 77.246.100.180/30 : out of version range .Jan 28 13:04:59.573: BGP(0): sub-prefix 77.246.100.184/30 : out of version range .Jan 28 13:04:59.573: BGP(0): sub-prefix 77.246.100.188/30 : out of version range .Jan 28 13:04:59.573: BGP(0): sub-prefix 77.246.104.0/21 : out of range .Jan 28 13:04:59.573: BGP(0): Need not be re-aggregated .Jan 28 13:05:01.925: BGP: Regular scanner timer event .Jan 28 13:05:01.925: BGP(4): Import timer expired. Walking from 159954 to 159954 .Jan 28 13:05:07.765: BGP: aggregate timer expired .Jan 28 13:05:07.765: BGP(0): Aggregate processing for IPv4 Unicast .Jan 28 13:05:07.765: BGP(0): For aggregate 77.246.96.96/27 .Jan 28 13:05:07.765: BGP(0): 77.246.96.96/27 subtree has an entry 77.246.96.96/27 .Jan 28 13:05:07.765: BGP(0): 77.246.96.96/27 subtree has another entry 77.246.96.99/32 .Jan 28 13:05:07.765: BGP(0): sub-prefix 77.246.96.99/32 : out of version range .Jan 28 13:05:07.765: BGP(0): sub-prefix 77.246.96.100/32 : out of version range .Jan 28 13:05:07.765: BGP(0): sub-prefix 77.246.96.101/32 : out of version range .Jan 28 13:05:07.765: BGP(0): sub-prefix 77.246.96.102/32 : out of version range .Jan 28 13:05:07.765: BGP(0): sub-prefix 77.246.96.103/32 : out of version range .Jan 28 13:05:07.765: BGP(0): sub-prefix 77.246.96.104/32 : out of version range .Jan 28 13:05:07.765: BGP(0): sub-prefix 77.246.96.105/32 : out of version range .Jan 28 13:05:07.765: BGP(0): sub-prefix 77.246.96.106/32 : out of version range .Jan 28 13:05:07.765: BGP(0): sub-prefix 77.246.96.107/32 : out of version range .Jan 28 13:05:07.765: BGP(0): sub-prefix 77.246.96.108/32 : out of version range .Jan 28 13:05:07.765: BGP(0): sub-prefix 77.246.96.109/32 : out of version range .Jan 28 13:05:07.765: BGP(0): sub-prefix 77.246.96.112/32 : out of version range .Jan 28 13:05:07.765: BGP(0): sub-prefix 77.246.96.116/32 : out of version range .Jan 28 13:05:07.765: BGP(0): sub-prefix 77.246.96.118/32 : out of version range .Jan 28 13:05:07.765: BGP(0): sub-prefix 77.246.96.122/32 : out of version range .Jan 28 13:05:07.765: BGP(0): sub-prefix 77.246.96.123/32 : out of version range .Jan 28 13:05:07.765: BGP(0): sub-prefix 77.246.96.125/32 : out of version range .Jan 28 13:05:07.765: BGP(0): sub-prefix 77.246.96.126/32 : out of version range .Jan 28 13:05:07.765: BGP(0): sub-prefix 77.246.96.192/30 : out of range .Jan 28 13:05:07.765: BGP(0): Need not be re-aggregated .Jan 28 13:05:07.765: BGP(0): For aggregate 77.246.100.160/28 .Jan 28 13:05:07.765: BGP(0): 77.246.100.160/28 subtree has an entry 77.246.100.160/28 .Jan 28 13:05:07.765: BGP(0): 77.246.100.160/28 subtree has another entry 77.246.100.161/32 .Jan 28 13:05:07.765: BGP(0): sub-prefix 77.246.100.161/32 : out of version range .Jan 28 13:05:07.765: BGP(0): sub-prefix 77.246.100.162/32 : out of version range .Jan 28 13:05:07.765: BGP(0): sub-prefix 77.246.100.163/32 : out of version range .Jan 28 13:05:07.765: BGP(0): sub-prefix 77.246.100.164/32 : out of version range .Jan 28 13:05:07.765: BGP(0): sub-prefix 77.246.100.166/32 : out of version range .Jan 28 13:05:07.765: BGP(0): sub-prefix 77.246.100.167/32 : out of version range .Jan 28 13:05:07.765: BGP(0): sub-prefix 77.246.100.168/32 : out of version range .Jan 28 13:05:07.765: BGP(0): sub-prefix 77.246.100.169/32 : out of version range .Jan 28 13:05:07.765: BGP(0): sub-prefix 77.246.100.170/32 : out of version range .Jan 28 13:05:07.765: BGP(0): sub-prefix 77.246.100.171/32 : out of version range .Jan 28 13:05:07.765: BGP(0): sub-prefix 77.246.100.172/32 : out of version range .Jan 28 13:05:07.765: BGP(0): sub-prefix 77.246.100.173/32 : out of version range .Jan 28 13:05:07.765: BGP(0): sub-prefix 77.246.100.174/32 : out of version range .Jan 28 13:05:07.765: BGP(0): sub-prefix 77.246.100.175/32 : out of version range .Jan 28 13:05:07.765: BGP(0): sub-prefix 77.246.100.176/30 : out of range .Jan 28 13:05:07.765: BGP(0): Need not be re-aggregated .Jan 28 13:05:07.765: BGP(0): For aggregate 77.246.100.176/28 .Jan 28 13:05:07.765: BGP(0): 77.246.100.176/28 subtree has an entry 77.246.100.176/30 .Jan 28 13:05:07.765: BGP(0): sub-prefix 77.246.100.176/30 : out of version range .Jan 28 13:05:07.765: BGP(0): sub-prefix 77.246.100.176/28 : out of version range .Jan 28 13:05:07.765: BGP(0): sub-prefix 77.246.100.180/30 : out of version range .Jan 28 13:05:07.765: BGP(0): sub-prefix 77.246.100.184/30 : out of version range .Jan 28 13:05:07.765: BGP(0): sub-prefix 77.246.100.188/30 : out of version range .Jan 28 13:05:07.765: BGP(0): sub-prefix 77.246.104.0/21 : out of range .Jan 28 13:05:07.765: BGP(0): Need not be re-aggregated .Jan 28 13:05:07.773: BGP: tbl IPv4 Unicast:base Service reset requests .Jan 28 13:05:07.773: BGP: tbl VPNv4 Unicast:base Service reset requests .Jan 28 13:05:07.773: BGP: tbl IPv4 Multicast:base Service reset requests .Jan 28 13:05:08.873: BGP: 193.232.246.100 active went from Idle to Active .Jan 28 13:05:08.873: BGP: 193.232.246.100 open active, local address 193.232.246.200 .Jan 28 13:05:08.881: BGP: ses global 193.232.246.100 (0) act read request no-op .Jan 28 13:05:08.881: BGP: ses global 193.232.246.100 (0) act Adding topology IPv4 Unicast:base .Jan 28 13:05:08.881: BGP: 193.232.246.100 active went from Active to OpenSent .Jan 28 13:05:08.881: BGP: 193.232.246.100 active sending OPEN, version 4, my as: 41842, holdtime 180 ID 4DF660A0seconds .Jan 28 13:05:08.885: BGP: ses global 193.232.246.100 (0) act IPv4 Unicast:base read request no-op .Jan 28 13:05:08.885: BGP: 193.232.246.100 active send message type 1, length (incl. header) 50 .Jan 28 13:05:08.885: BGP: ses global 193.232.246.100 (0) act IPv4 Unicast:base Remote close. .Jan 28 13:05:08.885: BGP: tbl IPv4 Unicast:base Service reset requests .Jan 28 13:05:09.097: BGP: ses global 193.232.246.100 (0) act IPv4 Unicast:base read request no-op .Jan 28 13:05:09.097: BGP: ses global 193.232.246.100 (0) act IPv4 Unicast:base Remote close. Jan 28 13:06:17.145: %PARSER-3-URLOPENFAIL: cannot open file for redirection 'Transfer aborted'
On Thu, Jan 28, 2010 at 04:40:54PM +0300, Mikhail A. Grishin wrote:
We found that "Finite state machine error" problem is not related to your patches. It randomly occurs on our production server at the time of daemon startup :((
The problem is occurs on small number of peers. (2 or 3 or 4 from ~280) Some problem peers are the same at next startup, some - not.
On test server with small number of active peers (and same config) we doesn't see this issue.
What can be done? Right now we see the problem on pure 1.2.0 release...
About "UPDATE message immediately after it sent OPEN" - we ask one of our customers (which hit that problem) to collect debug from his side. See the attachments (3 files).
I will look at it.
One more, after applying the "well-known communities" patch, the BIRD goes to .core two times ( 5-30 seconds after startup):( Do you need the last core file?
Yes, if you could send me core file and bird binary. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
On Thu, Jan 28, 2010 at 04:40:54PM +0300, Mikhail A. Grishin wrote:
Hi,
We found that "Finite state machine error" problem is not related to your patches. It randomly occurs on our production server at the time of daemon startup :((
The problem is occurs on small number of peers. (2 or 3 or 4 from ~280) Some problem peers are the same at next startup, some - not.
On test server with small number of active peers (and same config) we doesn't see this issue.
What can be done? Right now we see the problem on pure 1.2.0 release...
This might be a buggy version of firmware in the neighbor, as well as some strange bug in BIRD.
About "UPDATE message immediately after it sent OPEN" - we ask one of our customers (which hit that problem) to collect debug from his side. See the attachments (3 files).
I can't find the KEEPALIVE message in the log, but i don't know Cisco enough to be sure (perhaps it just does not log it). The best thing would be to run on route server: tcpdump -i eth0 -s 0 -v -n ip host 192.168.1.1 > logfile (with appropriate network device and IP address of one of problematic neighbors) and send me that logfile. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Ondrej Zajicek пишет:
On Thu, Jan 28, 2010 at 04:40:54PM +0300, Mikhail A. Grishin wrote:
Hi,
We found that "Finite state machine error" problem is not related to your patches. It randomly occurs on our production server at the time of daemon startup :((
The problem is occurs on small number of peers. (2 or 3 or 4 from ~280) Some problem peers are the same at next startup, some - not.
On test server with small number of active peers (and same config) we doesn't see this issue.
What can be done? Right now we see the problem on pure 1.2.0 release...
This might be a buggy version of firmware in the neighbor, as well as some strange bug in BIRD.
About "UPDATE message immediately after it sent OPEN" - we ask one of our customers (which hit that problem) to collect debug from his side. See the attachments (3 files).
I can't find the KEEPALIVE message in the log, but i don't know Cisco enough to be sure (perhaps it just does not log it).
The best thing would be to run on route server:
tcpdump -i eth0 -s 0 -v -n ip host 192.168.1.1 > logfile
See attach (dump with another peer, 193.232.246.198, R34485x1) As far as I see, the first one from 193.232.246.198 (18:15:06.785501) is Update, the second one (18:15:06.788230) is Keepalive But why at another daemon run the session is up with the same peer? Direction of session establishing make sense?
(with appropriate network device and IP address of one of problematic neighbors)
and send me that logfile.
-- Mikhail A. Grishin E-mail: magr@ripn.net Phone: +7 (495) 737-0685 MSK-IX & Russian Institute for Public Networks Phone: +7 (499) 192-9179 Network Operations Center 18:15:06.782511 IP (tos 0xc0, ttl 64, id 9139, offset 0, flags [DF], proto TCP (6), length 44) 193.232.246.100.179 > 193.232.246.198.29675: S, cksum 0x711b (incorrect (-> 0xf6c2), 1674454884:1674454884(0) ack 791544152 win 65535 <mss 1460> 18:15:06.784043 IP (tos 0xc0, ttl 1, id 48499, offset 0, flags [DF], proto TCP (6), length 40) 193.232.246.198.29675 > 193.232.246.100.179: ., cksum 0xce7f (correct), ack 1 win 16384 18:15:06.784227 IP (tos 0xc0, ttl 1, id 9140, offset 0, flags [DF], proto TCP (6), length 85) 193.232.246.100.179 > 193.232.246.198.29675: P, cksum 0x7144 (incorrect (-> 0x52f9), 1:46(45) ack 1 win 65535: BGP, length: 45 Open Message (1), length: 45 Version 4, my AS 8631, Holdtime 180s, ID 193.232.246.100 Optional parameters, length: 16 Option Capabilities Advertisement (2), length: 14 Multiprotocol Extensions (1), length: 4 AFI IPv4 (1), SAFI Unicast (1) 18:15:06.785012 IP (tos 0xc0, ttl 1, id 48500, offset 0, flags [DF], proto TCP (6), length 90) 193.232.246.198.29675 > 193.232.246.100.179: P, cksum 0x8384 (correct), 1:51(50) ack 1 win 16384: BGP, length: 50 Open Message (1), length: 50 Version 4, my AS 34485, Holdtime 180s, ID 89.16.63.3 Optional parameters, length: 21 Option Capabilities Advertisement (2), length: 6 Multiprotocol Extensions (1), length: 4 AFI IPv4 (1), SAFI Unicast (1) Option Capabilities Advertisement (2), length: 2 Route Refresh (Cisco) (128), length: 0 Option Capabilities Advertisement (2), length: 2 Route Refresh (2), length: 0 Option Capabilities Advertisement (2), length: 3 Unknown (131), length: 1 no decoder for Capability 131 0x0000: 00 18:15:06.785501 IP (tos 0xc0, ttl 1, id 48501, offset 0, flags [DF], proto TCP (6), length 1450) 193.232.246.198.29675 > 193.232.246.100.179: ., cksum 0xe348 (correct), 51:1461(1410) ack 1 win 16384: BGP, length: 1410 [|BGP Update] 18:15:06.785516 IP (tos 0xc0, ttl 1, id 9144, offset 0, flags [DF], proto TCP (6), length 59) 193.232.246.100.179 > 193.232.246.198.29675: P, cksum 0x712a (incorrect (-> 0x094e), 46:65(19) ack 1461 win 64290: BGP, length: 19 Keepalive Message (4), length: 19 18:15:06.787400 IP (tos 0xc0, ttl 1, id 48502, offset 0, flags [DF], proto TCP (6), length 1500) 193.232.246.198.29675 > 193.232.246.100.179: ., cksum 0xb370 (correct), 1461:2921(1460) ack 65 win 16320: BGP, length: 1460 18:15:06.788230 IP (tos 0xc0, ttl 1, id 48503, offset 0, flags [DF], proto TCP (6), length 1280) 193.232.246.198.29675 > 193.232.246.100.179: P, cksum 0x4f34 (correct), 2921:4161(1240) ack 65 win 16320: BGP, length: 1240 [|BGP] Keepalive Message (4), length: 19 18:15:06.788243 IP (tos 0xc0, ttl 1, id 9145, offset 0, flags [DF], proto TCP (6), length 40) 193.232.246.100.179 > 193.232.246.198.29675: ., cksum 0x7117 (incorrect (-> 0x0233), ack 4161 win 64460 18:15:06.788346 IP (tos 0xc0, ttl 1, id 9146, offset 0, flags [DF], proto TCP (6), length 61) 193.232.246.100.179 > 193.232.246.198.29675: P, cksum 0x712c (incorrect (-> 0xfac8), 65:86(21) ack 4161 win 65535: BGP, length: 21 Notification Message (3), length: 21, Finite State Machine Error (5) 18:15:06.788359 IP (tos 0xc0, ttl 1, id 9147, offset 0, flags [DF], proto TCP (6), length 40) 193.232.246.100.179 > 193.232.246.198.29675: F, cksum 0x7117 (incorrect (-> 0xfde9), 86:86(0) ack 4161 win 65535 18:15:06.789957 IP (tos 0xc0, ttl 1, id 48504, offset 0, flags [DF], proto TCP (6), length 40) 193.232.246.198.29675 > 193.232.246.100.179: ., cksum 0xbe3e (correct), ack 87 win 16299 18:15:06.790548 IP (tos 0xc0, ttl 1, id 48505, offset 0, flags [DF], proto TCP (6), length 1500) 193.232.246.198.29675 > 193.232.246.100.179: ., cksum 0x88e9 (correct), 4161:5621(1460) ack 87 win 16299: BGP, length: 1460 [|BGP Update] 18:15:06.790561 IP (tos 0xc0, ttl 64, id 9154, offset 0, flags [DF], proto TCP (6), length 40) 193.232.246.100.179 > 193.232.246.198.29675: R, cksum 0x7117 (incorrect (-> 0x3ebc), 1674454971:1674454971(0) win 0 18:15:06.790772 IP (tos 0xc0, ttl 1, id 48506, offset 0, flags [DF], proto TCP (6), length 1500) 193.232.246.198.29675 > 193.232.246.100.179: ., cksum 0x612f (correct), 5621:7081(1460) ack 87 win 16299: BGP, length: 1460 18:15:06.790782 IP (tos 0xc0, ttl 64, id 9155, offset 0, flags [DF], proto TCP (6), length 40) 193.232.246.100.179 > 193.232.246.198.29675: R, cksum 0x7117 (incorrect (-> 0x3ebc), 1674454971:1674454971(0) win 0 18:15:06.791011 IP (tos 0xc0, ttl 1, id 48507, offset 0, flags [DF], proto TCP (6), length 1500) 193.232.246.198.29675 > 193.232.246.100.179: ., cksum 0xec9b (correct), 7081:8541(1460) ack 87 win 16299: BGP, length: 1460 [|BGP] [|BGP Update] 18:15:06.791020 IP (tos 0xc0, ttl 64, id 9156, offset 0, flags [DF], proto TCP (6), length 40) 193.232.246.100.179 > 193.232.246.198.29675: R, cksum 0x7117 (incorrect (-> 0x3ebc), 1674454971:1674454971(0) win 0
On Thu, Jan 28, 2010 at 06:26:38PM +0300, Mikhail A. Grishin wrote:
I can't find the KEEPALIVE message in the log, but i don't know Cisco enough to be sure (perhaps it just does not log it).
The best thing would be to run on route server:
tcpdump -i eth0 -s 0 -v -n ip host 192.168.1.1 > logfile
See attach (dump with another peer, 193.232.246.198, R34485x1)
As far as I see, the first one from 193.232.246.198 (18:15:06.785501) is Update, the second one (18:15:06.788230) is Keepalive
Yes, that is pretty clear.
But why at another daemon run the session is up with the same peer? Direction of session establishing make sense?
Perhaps direction, or perhaps the different daemon is less strict with regard to state changes and accept this even if it is contrary to the BGP specification. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
On Thu, Jan 28, 2010 at 07:02:46PM +0100, Ondrej Zajicek wrote:
But why at another daemon run the session is up with the same peer? Direction of session establishing make sense?
Perhaps direction, or perhaps the different daemon is less strict with regard to state changes and accept this even if it is contrary to the BGP specification.
Here is a patch that will cause BIRD to be less strict and accept such behavior. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Ondrej Zajicek пишет:
On Thu, Jan 28, 2010 at 07:02:46PM +0100, Ondrej Zajicek wrote:
But why at another daemon run the session is up with the same peer? Direction of session establishing make sense? Perhaps direction, or perhaps the different daemon is less strict with regard to state changes and accept this even if it is contrary to the BGP specification.
Here is a patch that will cause BIRD to be less strict and accept such behavior.
Hi Ondrej, After applying the patch this error disappeared. Thanks again! However, startup process of the daemon still unstable. It could crash in period 5-40 seconds. After that time (if not crashed) all seems to be fine. Do you need latest core file and latest binary? I think that may be this problem isn't related to patches. Pure 1.2.0-release version we started only few times on the production server and may be that was just lucky attempts... -- Mikhail A. Grishin E-mail: magr@ripn.net
On Fri, Jan 29, 2010 at 06:17:43PM +0300, Mikhail A. Grishin wrote:
However, startup process of the daemon still unstable. It could crash in period 5-40 seconds. After that time (if not crashed) all seems to be fine.
Do you need latest core file and latest binary?
I cannot get useful info from the core you sent me. The best thing would be to: 1) use unstripped binary of bird - i don't know whether stripping is a part of 'make install' or you just stripped it explicitly, but it should be sufficient to not use 'make install' and just copy bird binary after 'make' to the final destination. You can see a size difference between unstripped and stripped binary. 2) enable all logging in bird.conf using 'debug protocols all;' global option. This is probably too much logging for production usage, but it would be useful to analyze the crash. Then, after some crash, send me the (unstripped) binary, the core and the bird log.
I think that may be this problem isn't related to patches.
I would also expect that. Especially the community patch was too simple to break anything. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Ondrej Zajicek пишет:
On Fri, Jan 29, 2010 at 06:17:43PM +0300, Mikhail A. Grishin wrote:
However, startup process of the daemon still unstable. It could crash in period 5-40 seconds. After that time (if not crashed) all seems to be fine.
Do you need latest core file and latest binary?
I cannot get useful info from the core you sent me. The best thing would be to:
1) use unstripped binary of bird - i don't know whether stripping is a part of 'make install' or you just stripped it explicitly, but it should be sufficient to not use 'make install' and just copy bird binary after 'make' to the final destination. You can see a size difference between unstripped and stripped binary.
2) enable all logging in bird.conf using 'debug protocols all;' global option. This is probably too much logging for production usage, but it would be useful to analyze the crash.
Then, after some crash, send me the (unstripped) binary, the core and the bird log.
I think that may be this problem isn't related to patches.
I would also expect that. Especially the community patch was too simple to break anything.
We'll try to reproduce that behavior and to collect debug at time of enabling the BIRD on another our route server. I hope that will be on this week. -- Mikhail A. Grishin E-mail: magr@ripn.net
participants (2)
-
Mikhail A. Grishin -
Ondrej Zajicek