August 2018 - Bird-users

route server appears to be selecting preferred routes and not all routes
by Stephen Fromm 21 Aug '18

21 Aug '18

We are running bird as a route server to support a small IX. The challenge we are having is that it appears that bird is selecting a preferred route from what is advertised to the route servers and then advertising back out only the preferred route to all members, instead of advertising all routes received for a given network. Included below are relevant configuration snippets, logs, and some show commands. How do I configure bird to keep the routes learned from all peers and advertise those back out to the members and not select a preferred route? In the following example, the following prefix is just one example. It is true for all prefixes learned from as11537. At some point, bird appears to select a preferred route and then only advertise that to as3701. The goal is to have bird advertise 128.164.0.0/16 via 198.32.165.125 and 198.32.165.126 to all IXP members. >From bird: ,---- | # birdc | BIRD 1.6.2 ready. | bird> show route 128.164.0.0/16 | 128.164.0.0/16 via 198.32.165.126 on eth0 [11537:1:Internet2-RE-PORT 16:06:17] * (100) [AS11039i] | via 198.32.165.125 on eth0 [11537:1:Internet2-RE-SUNN 15:31:43] (100) [AS11039i] | bird> show route 128.164.0.0/16 export '3701:1:NERO' | 128.164.0.0/16 via 198.32.165.126 on eth0 [11537:1:Internet2-RE-PORT 16:06:17] * (100) [AS11039i] `---- On the other side of the peering with 3701, this is the only route it sees from the route server: ,---- | # show bgp ipv4 uni 128.164.0.0/16 | Path #3: Received by speaker 0 | Not advertised to any peer | 11537 4901 11039 | 198.32.165.126 from 198.32.165.67 (198.32.165.67) | Origin IGP, metric 10, localpref 1090, valid, external | Received Path ID 0, Local Path ID 0, version 0 | Community: 3701:391 | Origin-AS validity: not-found `---- The following are logs from when peering was reestablished with both as11537 peers. It shows bird choosing 198.32.165.125 as the best path to 128.164.0.0/16. After the peering to 198.32.165.126 is established, bird then chooses it as the preferred path to 128.164.0.0/16. ,---- | 2018-08-17 15:31:42 <TRACE> 11537:1:Internet2-RE-SUNN > added [best] 128.164.0.0/16 via 198.32.165.125 on eth0 | 2018-08-17 15:31:42 <TRACE> 11537:1:Internet2-RE-SUNN < rejected by protocol 128.164.0.0/16 via 198.32.165.125 on eth0 | 2018-08-17 15:31:45 <TRACE> 11537:1:Internet2-RE-PORT < added 128.164.0.0/16 via 198.32.165.125 on eth0 | 2018-08-17 15:31:49 <TRACE> 11537:1:Internet2-RE-PORT > added [best] 128.164.0.0/16 via 198.32.165.126 on eth0 | 2018-08-17 15:31:49 <TRACE> 11537:1:Internet2-RE-SUNN < added 128.164.0.0/16 via 198.32.165.126 on eth0 | 2018-08-17 15:31:49 <TRACE> 11537:1:Internet2-RE-PORT < rejected by protocol 128.164.0.0/16 via 198.32.165.126 on eth0 | 2018-08-17 15:32:05 <TRACE> 3701:1:NERO < added 128.164.0.0/16 via 198.32.165.126 on eth0 `---- Configuration is below. #+BEGIN log "/var/log/bird.log" all; log syslog all; debug protocols { states, routes, filters, interfaces, events }; router id 198.32.165.67; define myasn = 4600; protocol device {}; # This function excludes martians and other odd networks function avoid_martians() prefix set martians; { martians = [ 169.254.0.0/16+, 172.16.0.0/12+, 192.168.0.0/16+, 10.0.0.0/8+, 0.0.0.0/32- ]; if net ~ martians then return false; return true; } # BGP peers configuration table master sorted; protocol bgp '3701:1:NERO' { description "NERO, peer 198.32.165.70"; neighbor 198.32.165.70 as 3701; local as 4600; rs client; passive on; add paths tx; secondary; interpret communities off; export all; import keep filtered; import limit 500000 action restart; import filter { if ! ( avoid_martians() ) then reject "prefix is a bogon - REJECTING ", net; # route servers peering with route servers is bad. if ( bgp_path.first != 3701 ) then reject "invalid left-most ASN [", bgp_path.first, "] - REJECTING ", net; # skip if last asn in path not affiliated with peer if ! ( bgp_path.last ~ [ 3701, 4201, 3582, 46159, 10876, 6366, 6377, 62474, 394271, 394826 ] ) then reject "origin ASN [", bgp_path.last, "] not in allowed asnlist - REJECTING ", net; # skip if network not associated with peer asn if ! ( net ~ [ 64.112.160.0/20, 128.193.0.0/16, 128.223.0.0/16, 131.252.0.0/16, 140.211.0.0/16, 157.246.0.0/16, 158.165.0.0/16, 163.41.0.0/16, 163.41.128.0/17, 184.171.0.0/17, 192.68.202.0/24, 192.135.183.0/24, 198.98.8.0/22, 198.98.12.0/24, 198.237.0.0/20, 198.237.32.0/20, 198.237.64.0/19, 198.237.96.0/20, 198.237.120.0/21, 198.237.128.0/20, 199.79.32.0/20, 199.165.177.0/24, 199.201.139.0/24, 204.27.190.0/24, 204.87.204.0/24, 205.167.76.0/23, 207.98.0.0/18, 207.98.64.0/18, 207.98.72.0/21 ] ) then reject "prefix not in configured client prefix list - REJECTING ", net; # add the following communities bgp_community.add((4600,537)); bgp_community.add((4600,4600)); # accept what is left accept; }; } protocol bgp '11537:1:Internet2-RE-PORT' { description "Internet2-RE-PORT, peer 198.32.165.126"; neighbor 198.32.165.126 as 11537; local as 4600; rs client; passive on; add paths tx; secondary; interpret communities off; export filter { if ( bgp_community ~ [ (4600,54101) ] ) then bgp_community.add((11537,140)); accept; }; import keep filtered; import limit 500000 action restart; import filter { if ! ( avoid_martians() ) then reject "prefix is a bogon - REJECTING ", net; # route servers peering with route servers is bad. if ( bgp_path.first != 11537 ) then reject "invalid left-most ASN [", bgp_path.first, "] - REJECTING ", net; # accept all asn from peer # accept all networks from peer # add the following communities bgp_community.add((4600,537)); bgp_community.add((4600,503)); # accept what is left accept; }; } protocol bgp '11537:1:Internet2-RE-SUNN' { description "Internet2-RE-SUNN, peer 198.32.165.125"; neighbor 198.32.165.125 as 11537; local as 4600; rs client; passive on; add paths tx; secondary; interpret communities off; export filter { if ( bgp_community ~ [ (4600,50301) ] ) then bgp_community.add((11537,140)); accept; }; import keep filtered; import limit 500000 action restart; import filter { if ! ( avoid_martians() ) then reject "prefix is a bogon - REJECTING ", net; # route servers peering with route servers is bad. if ( bgp_path.first != 11537 ) then reject "invalid left-most ASN [", bgp_path.first, "] - REJECTING ", net; # accept all asn from peer # accept all networks from peer # add the following communities bgp_community.add((4600,537)); bgp_community.add((4600,541)); # accept what is left accept; }; } #+END Thanks, -- Stephen Fromm Network for Education and Research in Oregon

4 3

ospf between bird (accel pppoe server) and mikrotik
by Alexandrino Neto 17 Aug '18

17 Aug '18

Hi guys, I'm using bird on a pppoe server (accel) connected directly to a mikrotik and I need ospf between them to advertise the prefixes of the pppoe clients. The accel server is already receiving the mikrotik routes through ospf but can not send the route with the clients prefix to mikrotik, I thought of creating a blackhole route and advertise using "redistribute connected" but it did not work, just putting the exit filter with "redistribute connected" but also did not work. Could someone help me get my server to send the routes to mikrotik by ospf? Best Regards. eth0 is connected to mikrotik and eth1 for clients My conf file: protocol device { scan time 10; } protocol kernel { metric 64; import all; export all; } protocol static pool_pppoe { route 177.XX.XX.0/24 blackhole; # my public pool to clientes } router id 10.200.100.1; filter ospf_export { if ( source = RTS_DEVICE ) then { print "net accepted:", net; ospf_metric2 = 20; accept; } if ( source = RTS_STATIC_DEVICE ) then { print "net accepted:", net; ospf_metric2 = 20; accept; } } protocol ospf { export filter ospf_export; area 0.0.0.0 { interface "eth0" { cost 10; type pointopoint; hello 10; retransmit 5; wait 10; dead 40; }; }; area 0.0.0.1 { interface "eth1" { }; stub yes; }; }

2 1

Arista Switch BFD issue - custom port
by Jakub Nowacki 16 Aug '18

16 Aug '18

Hi, I'm running BIRD on Arista which allows access to Linux bash. I'm having issue with running multihop BFD session on it and I believe it's related to port being already binded. > bash-4.3# netstat -tulpen | grep 4784 > udp6 0 0 :::4784 :::* > 0 4269 - Above is netstat output from bash on Arista (there is no BFD configured on switch). When I try to run *nc -ul4 4784* I'm getting > Ncat: bind to 0.0.0.0:4784: Address already in use. QUITTING. I couldn't find any configuration option for BFD to change port being used, but maybe there is one? Perhaps anyone run into similar issue and have a workaround? -- Kuba Nowacki Senior NetOps M: +(48) 605 508 118 E: jnowacki(a)greywizard.com GreyWizard Sp. z o.o. ul. Palacza 113 60-273 Poznań, Poland NIP: 779-24-22-423 Regon: 302744400 KRS: 0000512326 greywizard.com support(a)greywizard.com +48 22 201 33 13 Sąd Rejonowy w Poznaniu, VIII Wydział Gospodarczy Krajowego Rejestru Sądowego. Kapitał zakładowy 10000 PLN.

2 2

BFD socket bind error upon reboot
by J. Kendzorra 15 Aug '18

15 Aug '18

Hi, upon a reboot of a system running BFD I recently noticed BFD breaking with error "Cannot assign requested address" once the system came back. Restarting the BFD protocol in question solved the problem. Hence, apparently the system's network wasn't fully up and running at the time bird started; according to systemd documentation (https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/) one possible fix is to change bird.service from After=network.target to After=network-online.target Wants=network-online.target Alternatively, IP_FREEBIND on the BFD tx socket would allow binding to an IP address that does not (yet) exist which seems more elegant since it doesn't need to take into account that different systems may define "online" differently. I'm wondering whether there's something I'm missing as to why IP_FREEBIND shouldn't be used? Thanks, J.

2 3

[PATCH RFC 0/2] Adding HMAC support to the Babel protocol
by Toke Høiland-Jørgensen 15 Aug '18

15 Aug '18

The Babel IETF working group is in the process of specifying an extension to the Babel protocol that adds HMAC authentication of messages. The current draft proposal is available as draft-do-babel-hmac-00: https://tools.ietf.org/html/draft-do-babel-hmac-00 This patch adds an implementation of this draft to Babel in Bird. The draft is a way from being finalised, so it is premature to merge the code. Instead, this should be seen as a call for feedback on both the implementation and the draft specification. The proof of concept implementation of HMAC for babeld is available in the hmac-challenge branch of this repository: https://github.com/wkolod/babeld With this patch, Bird can successfully exchange HMAC-authenticated messages with babeld in the above repo. -Toke --- Toke Høiland-Jørgensen (2): babel: Define helper macro for looping through TLVs babel: Add HMAC support proto/babel/babel.c | 80 +++++++++ proto/babel/babel.h | 58 ++++++ proto/babel/config.Y | 34 ++++ proto/babel/packets.c | 439 +++++++++++++++++++++++++++++++++++++++++++++---- 4 files changed, 567 insertions(+), 44 deletions(-)

3 14

Strange behavior, cannot reach 4th hop
by TI2015: Kulesza, Dawid 14 Aug '18

14 Aug '18

Hello, few days ago I struggled with bird configuration over openvpn. It's working now. I can see, that every host has proper routes and with birdc show ospf topology I can see, that every router sees everyone else. I have following setting. CLIENT A 192.168.21.1/28 l l l 192.168.21.5/28 ROUTER X 192.168.21.25/28 l l l 192.168.21.17/28 CLIENT B (with openvpn tunnet to server) 10.29.0.4/22 l l l 10.29.0.1/22 SERVER The connection from CLIENT B to SERVER is over internet, but it shouldn't matter here. Now the issue is as following: - I can ping from ROUTER X the SERVER - I can ping from CLIENT A the address (CLIENT B) 10.29.0.4 (and with traceroute I can see, that it's going correctly) - I cannot ping from CLIENT A the SERVER and the same in opposite direction: - I can ping from SERVER the address 192.168.21.25 (Router X) - I cannot ping the address 192.168.21.5 For me it seems like it has something to do with time to live (TTL), because the packets cannot reach 4th hop, but I didn't find anything about it in internet. Do you have some ideas what could be wrong? Best regards Dawid Output from ospf topology on server: BIRD 1.6.3 ready. area 0.0.0.0 router 10.29.0.1 distance 0 network 10.29.0.0/22 metric 100 router 192.168.21.1 distance 115 network 192.168.21.0/28 metric 5 router 192.168.21.5 distance 105 network 192.168.21.16/28 metric 10 network 192.168.21.0/28 metric 10 router 192.168.21.17 distance 100 network 192.168.21.16/28 metric 5 network 10.29.0.0/22 metric 100 network 10.29.0.0/22 dr 10.29.0.1 distance 100 router 10.29.0.1 router 192.168.21.17 network 192.168.21.0/28 dr 192.168.21.5 distance 115 router 192.168.21.5 router 192.168.21.1 network 192.168.21.16/28 dr 192.168.21.5 distance 105 router 192.168.21.5 router 192.168.21.17 route -n on server 2.2.2.2 10.29.0.4 255.255.255.255 UGH 17 0 0 tun0 1.1.1.1 192.168.20.94 255.255.255.255 UGH 17 0 0 eth1 3.3.3.3 10.29.0.4 255.255.255.255 UGH 17 0 0 tun0 192.168.21.16 10.29.0.4 255.255.255.240 UG 17 0 0 tun0 192.168.21.0 10.29.0.4 255.255.255.240 UG 17 0 0 tun0 192.168.20.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 10.29.0.0 0.0.0.0 255.255.252.0 U 0 0 0 tun0 XXXXXXXX 0.0.0.0 255.255.0.0 U 1002 0 0 eth1 0.0.0.0 YYYYYYYY 0.0.0.0 UG 0 0 0 eth1

2 2

Looking for a complete examples of BIRD as a BGP Router
by Felipe N. Oliva 13 Aug '18

13 Aug '18

Hello List! I'm new here, let me explain a little about me. I've been using FreeBSD + OpenBGPd for a long time as a BGP Router, but there are a lot of problems with de port, because it is very old(just in FreeBSD, okay?). Now I'm looking for to learn BIRD, OpenBGPd was very easy and intuitive, so I need help. I'm looking for complete examples of BIRD as a BGP Router. Somebody? Thank you. (I'm sorry for any problem with the English language) -- Felipe N. Oliva NetAdmin/SysAdmin BSDA BSDDCG-ID: 2016144190112430459

5 7

BGP resolvable issue
by Arvin Gan 13 Aug '18

13 Aug '18

Hi all, In RFC4271, If the NEXT_HOP attribute of a BGP route depicts an address that is not resolvable, or if it would become unresolvable if the route was installed in the routing table, the BGP route MUST be excluded from the Phase 2 decision function. Actually, BGP protocol is implemented this option. I notice that resolvable is checked with "rt->attrs->dest == RTD_UNICAST" , that mean the check is depend on the reachability of route for NEXT_HOP. However, NEXT_HOP is a host address, not a subnet address, the resolvable checking in VRF is depending on ARP/NDP result for NEXT_HOP, if NEXT_HOP cannot be resolved for MAC, it should be unresolved. The description of RFC4271 for "resolvable", I am confused whether it includes only route reachable, not includes host address reachable, does anyone clearly understand it? My test case: BGP4----------------------------------------------------------BGP4 peer set next hop:1560::28 BGP1 peer route table : 1560::/64 unicast [direct2 09:03:52.007] * (250) dev A6IF1 --------------------------------------------------------the address of interface is 1560::15/64 generate direct route unicast [bgp4 09:24:36.872 from 1560::26] (200) [?] via 1560::28 on A6IF1 -------------------------------------------------------the route is resolved in BGP4 peer based in brid, but the address the interface of BGP4 peer is 1560::15, not 1560::28, NDP is not successful. Thanks Arvin

1 0

Public git server migrated
by Ondrej Filip 10 Aug '18

10 Aug '18

Dear BIRD users, please note, that access to a public git repository was changed. If you want to get a copy of the project source code please use: git clone https://gitlab.labs.nic.cz/labs/bird.git Cheers! Ondrej

2 2

bird.network.cz HTTPS does not verify on some systems
by Leon Meßner 09 Aug '18

09 Aug '18

Hi, since lately Debian9 has problems fetching the bird repository here. I suppose this is because bird.network.cz does not send the Let's Encrypt certificate and http redirects to https now. Output of openssl is below[1]. If you run the same command against helloworld.letsencrypt.org it verifies correctly. I assume because LE's cert is also sent. Using a web browser, bird.network.cz works because of some magic. Regards, Leon [1]: openssl s_client -verify 5 -host bird.network.cz -port 443 CONNECTED(00000003) --- Certificate chain 0 s:/CN=trubka.network.cz i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 --- Server certificate -----BEGIN CERTIFICATE----- MIIGHjCCBQagAwIBAgISBP4LGoUGP5l81RdhMqoieW+4MA0GCSqGSIb3DQEBCwUA MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0xODA2MTQyMTAwMTNaFw0x ODA5MTIyMTAwMTNaMBwxGjAYBgNVBAMTEXRydWJrYS5uZXR3b3JrLmN6MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAs167eO/VgX3zZyKtlhObqnANKpxm l+LTG1QX2KCyn3qJeNcicZ/M8PUs+69x+ZPfnIdxEwfZrzGg11yLvQnUAaoHpNve Ro/iuO8uTM2r/Z8Ezc6UcFNrQwzll6kuSfGMnM4ybXwOHit3RGSRrwEDPWFBD/UO 982tn0P1TJur3Q4kR+V4xj9Fm6S7Y4dJin/CqjYVsj4W4adzKEpTVOEH/BGQ2IKJ 3ymQczLb2ubk7RfKBU/Q3srKCxlEi1J8Ywbs+4M2sdTVP0QUToIbfimS37XU3WNE MEjaBpS1PY8vlqpvkk2wab2AYo6Ebv2CENbYEzKBAdyi3vHbfENgvnj5CQIDAQAB o4IDKjCCAyYwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggr BgEFBQcDAjAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBSgPnFxv8QSbGhLofscEjTS qCnvaTAfBgNVHSMEGDAWgBSoSmpjBH3duubRObemRWXv86jsoTBvBggrBgEFBQcB AQRjMGEwLgYIKwYBBQUHMAGGImh0dHA6Ly9vY3NwLmludC14My5sZXRzZW5jcnlw dC5vcmcwLwYIKwYBBQUHMAKGI2h0dHA6Ly9jZXJ0LmludC14My5sZXRzZW5jcnlw dC5vcmcvMC0GA1UdEQQmMCSCD2JpcmQubmV0d29yay5jeoIRdHJ1YmthLm5ldHdv cmsuY3owgf4GA1UdIASB9jCB8zAIBgZngQwBAgEwgeYGCysGAQQBgt8TAQEBMIHW MCYGCCsGAQUFBwIBFhpodHRwOi8vY3BzLmxldHNlbmNyeXB0Lm9yZzCBqwYIKwYB BQUHAgIwgZ4MgZtUaGlzIENlcnRpZmljYXRlIG1heSBvbmx5IGJlIHJlbGllZCB1 cG9uIGJ5IFJlbHlpbmcgUGFydGllcyBhbmQgb25seSBpbiBhY2NvcmRhbmNlIHdp dGggdGhlIENlcnRpZmljYXRlIFBvbGljeSBmb3VuZCBhdCBodHRwczovL2xldHNl bmNyeXB0Lm9yZy9yZXBvc2l0b3J5LzCCAQQGCisGAQQB1nkCBAIEgfUEgfIA8AB2 ACk8UZZUyDlluqpQ/FgH1Ldvv1h6KXLcpMMM9OVFR/R4AAABZABQNF0AAAQDAEcw RQIgVcoX61l0XSOMCvzPBTv2u8cO7oyNBDj9IWku74NwngUCIQDedkTRbe3PCvaq jM4xV3NFgawt6JIrtUzaiqaXNGegcgB2ANt0r+7LKeyx/so+cW0s5bmquzb3hHGD x12dTze2H79kAAABZABQNIcAAAQDAEcwRQIgML48N4VM1PeN6diunYt/X6NQrHj2 2avg1yyONjos8IcCIQDtSVYatJVvikyZAO1Q4sc7hCfwg5Drs2+qRLXA2rI63zAN BgkqhkiG9w0BAQsFAAOCAQEAJaWpxMV9a69QwxQEc28YMmi1ytMT0IOwBID0d5fv kTOf8eRAiIePMPcvtX2sTw5WAxX5NeRteNioS6/UWiQxSUZgRig1XqVsYZIIZmyE 8m/YfLHtAsTH9OnP4tgx7Ys02xAqiexhvA2eL3Kv6VMcPng6UPZsqwuvhUh/bxEj psPvNGkid+vsG7v7n1koY5qDhrNu2nSBsJlVSUP7VMmaZma7fE4iFJhOJWTh15v/ Z3Q2sp3tJA9an/TiNc8wLivntS9AoxsajltiSozfw67JjrVJH+bnCEQSJ9LFpPO3 jsrxaWvY/l0MnEfMxPt5riHpgyFT3nQ3KPZP6Ifrs3M7WA== -----END CERTIFICATE----- subject=/CN=trubka.network.cz issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 --- No client certificate CA names sent Peer signing digest: SHA512 Server Temp Key: X25519, 253 bits --- SSL handshake has read 2227 bytes and written 269 bytes Verification error: unable to verify the first certificate --- New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Session-ID: 48FBE690BAB54A4EF0BCF647D3EC40F771EF070B92B2ADA82BBC78495A0E28A9 Session-ID-ctx: Master-Key: 4BF3560B6E3542C49A2E40534746B31AB97C1751C195C6A453B6B3C5687AAD7B48DA17D20FA8D4765BD627095BB0AF93 PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 300 (seconds) TLS session ticket: 0000 - 05 e6 6b 5b d2 a0 81 8d-e0 16 45 6f 44 d8 b0 86 ..k[......EoD... 0010 - b6 d9 24 8b 5f e3 e9 24-74 3c 77 55 98 cc 1a cf ..$._..$t<wU.... 0020 - 41 6e d3 41 48 c1 dc 8a-c9 b9 5c 67 e4 bb a0 bb An.AH.....\g.... 0030 - 1f 64 10 48 14 1c 38 75-18 f7 33 2f 22 9e 3d eb .d.H..8u..3/".=. 0040 - 8d 7d aa e4 1b 7d d4 94-b1 ba d9 6c 1e d9 f5 0d .}...}.....l.... 0050 - 5e af de 8f 33 31 b2 b0-fa 62 02 5b 9b c6 a0 a7 ^...31...b.[.... 0060 - f2 0b 7f d9 2e ae 24 b6-91 e6 62 5d 8d f6 c5 02 ......$...b].... 0070 - 38 05 25 75 90 51 0a 0a-47 67 79 08 89 b1 dd 3a 8.%u.Q..Ggy....: 0080 - 92 3c d5 9d b9 1a 38 34-12 d0 09 07 30 60 d6 0e .<....84....0`.. 0090 - 5f f6 8a 04 10 11 94 29-75 99 94 2d eb 1f 7f 03 _......)u..-.... 00a0 - a9 fb 77 85 07 43 35 25-a1 de d4 d7 b3 50 b3 bb ..w..C5%.....P.. 00b0 - 06 90 9d a0 49 02 64 0a-66 47 88 ac 38 10 a1 ea ....I.d.fG..8... Start Time: 1533827231 Timeout : 7200 (sec) Verify return code: 21 (unable to verify the first certificate) Extended master secret: yes ---

2 2