Hi Prabhjot, Can you confirm if the following is the correct procedure:
Install / Init the ovs-pki package Run 'ovs-pki req+sign vtep switch' to generate the cert and private key for the switch Copy the above generated files as well as controllerca/cacert.pem to /var/db/certs on the switch In my testbed.py, set env.ca_cert_file to point to switchca/cacert.pem' Run fab add_tor_agent to configure tor agent I'm not totally clear on the controllerca vs switchca directories. Reading through http://git.openvswitch.org/cgi-bin/gitweb.cgi?p=openvswitch;a=blob_plain;f=INSTALL.SSL;hb=HEAD as Contrail doesn't really have much documentation on this. On Sat, Jul 11, 2015 at 10:39 PM, Prabhjot Singh Sethi <[email protected] > wrote: > Dan, > Passive connection is supposed to be used only for debug going forward, so > it should be still present as hidden configuration. > > For SSL, please check that you are using the correct CA certificate on > ToR Agent, > vtep cert present on ToR should be signed using cacert provided to ToR > Agent for SSL to work. > While generating it using ovs-pki it must be under switchca (not > controller ca) > > — > Prabhjot > > From: Users <[email protected]> on behalf of Dan > Houtz <[email protected]> > Date: Sunday, 12 July 2015 3:52 am > To: "[email protected]" <[email protected]> > Subject: [Users] Problem getting OVSDB/SSL working on latest Junos / > Contrail 2.2 > > Hi, > > I just updated our QFX TOR switches to the latest version of Junos > (14.1X53-D27.3). This version seems to remove the option to do passive > connections for OVSDB where the TOR agent connects to the switch. Because > of this I'm trying to reconfigure OVSDB to connect to Contrail 2.2 version > of TOR agent using SSL. Thus far I am not having any luck. > > Steps I took: > > 1. ovs-pki init > > 2. ovs-pki req+sign vtep > > 3. Updated testbed.py with: > 'tor_ovs_port':'10002' > 'tor_ovs_protocol':'pssl' > env.ca_cert_file = '/var/lib/openvswitch/pki/controllerca/cacert.pem' > > 4. Ran fab to reconfigure TOR agent > > 5. Started tor agent and confirmed it is listening on 100002: > root@contrail-ctrl2:/etc/contrail/ssl/certs# netstat -ln | grep 10002 > tcp 0 0 0.0.0.0:10002 0.0.0.0:* LISTEN > > 6. Copied the following files from contrail to /var/db/certs/ on QFX: > /etc/contrail/ssl/certs/tor.2.cert.pem > /etc/contrail/ssl/private/tor.2.privkey.pem > > 7. Named as follows on QFX (Im not sure if names matter): > root@leaf2z0:RE:0% ls /var/db/certs/ | grep vtep > vtep-cert.pem > vtep-privkey.pem > > 8. Configured OVSDB Controller on QFX: > root@leaf2z0> ...ocols ovsdb controller 10.10.210.140 > protocol { > ssl port 10002; > } > inactivity-probe-duration 10000; > > 9. Rebooted QFX for good measure > > 10. Confirm QFX is sending packets to TOR agent on port 10002: > root@contrail-ctrl2:/etc/contrail/ssl/certs# tcpdump -n -i eth0 port > 10002 > tcpdump: WARNING: eth0: no IPv4 address assigned > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes > 17:13:47.778414 IP 10.10.214.66.57274 > 10.10.210.140.10002: Flags [.], > seq 1429429490:1429430938, ack 1204172480, win 33304, options [nop,nop,TS > val 1921693 ecr 167060864], length 1448 > 17:13:47.778442 IP 10.10.214.66.57274 > 10.10.210.140.10002: Flags [P.], > seq 1448:2579, ack 1, win 33304, options [nop,nop,TS val 1921693 ecr > 167060864], length 1131 > 17:13:47.778518 IP 10.10.210.140.10002 > 10.10.214.66.57274: Flags [.], > ack 2579, win 280, options [nop,nop,TS val 167060902 ecr 1921693], length 0 > 17:13:47.778784 IP 10.10.210.140.10002 > 10.10.214.66.57274: Flags [F.], > seq 1, ack 2579, win 280, options [nop,nop,TS val 167060902 ecr 1921693], > length 0 > 17:13:47.784788 IP 10.10.214.66.57274 > 10.10.210.140.10002: Flags [.], > ack 2, win 33304, options [nop,nop,TS val 1921700 ecr 167060902], length 0 > 17:13:47.785373 IP 10.10.214.66.57274 > 10.10.210.140.10002: Flags [F.], > seq 2579, ack 2, win 33304, options [nop,nop,TS val 1921700 ecr 167060902], > length 0 > 17:13:47.785425 IP 10.10.210.140.10002 > 10.10.214.66.57274: Flags [.], > ack 2580, win 280, options [nop,nop,TS val 167060903 ecr 1921700], length 0 > 17:13:48.785723 IP 10.10.214.66.54529 > 10.10.210.140.10002: Flags [S], > seq 601732230, win 65535, options [mss 8960,nop,wscale 1,nop,nop,TS val > 1922701 ecr 0,sackOK,eol], length 0 > 17:13:48.785806 IP 10.10.210.140.10002 > 10.10.214.66.54529: Flags [S.], > seq 4032879902, ack 601732231, win 28960, options [mss 1460,sackOK,TS val > 167061153 ecr 1922701,nop,wscale 7], length 0 > > 11. See Controller status as down: > root@leaf2z0> show ovsdb controller > VTEP controller information: > Controller IP address: 10.10.210.140 > Controller protocol: ssl > Controller port: 10002 > Controller connection: down > Controller seconds-since-connect: 0 > Controller seconds-since-disconnect: 0 > Controller connection status: backoff > > 12. OVSDB Traceoptions on QFX: > Jul 11 22:15:45 C(1843-vgd_ovs_client_connect_recv_cb): received data of > length = 325 > Jul 11 22:15:45 C(1843-vgd_vteprec_delete_manager): Delete manager > ssl:10.10..210.140:10002 > Jul 11 22:15:45 C(1843-vgd_core_fsm): NOTHING TO PROCESS > Jul 11 22:15:45 C(1843-vgd_core_fsm): Current event :4 > Jul 11 22:15:45 C(1843-vgd_core_fsm): State change from VGD_STATE_FULL to > VGD_STATE_ADD > Jul 11 22:15:45 C(1843-vgd_controller_add_queue): Update controller > ipaddr XXXXXXXXXXXX to state VGD_STATE_ADD > Jul 11 22:15:45 C(1843-vgd_vteprec_update_manager): Update manager > ssl:10.10..210.140:10002 > Jul 11 22:15:45 C(1843-vgd_vteprec_extract_manager): Extract controller > ipaddr XXXXXXXXXXXX protocol 1 port 10002 max_backoff 1000 inactivity_probe > 10000 > Jul 11 22:15:45 C(1843-vgd_controller_add): Add controller ipaddr > XXXXXXXXXXXX protocol 1 port 10002 max_backoff 1000 inactivity_probe 10000 > Jul 11 22:15:45 C(1843-vgd_core_fsm): NOTHING TO PROCESS > Jul 11 22:15:45 C(1843-vgd_core_fsm): Current event :3 > Jul 11 22:15:45 C(1843-vgd_core_fsm): State change from VGD_STATE_ADD to > VGD_STATE_FULL > Jul 11 22:15:45 C(1843-vgd_controller_update): Update controller ipaddr > XXXXXXXXXXXX to state VGD_STATE_FULL > Jul 11 22:15:45 C(1843-vgd_vteprec_update_global_row): tunnel Adding > global row > Jul 11 22:15:45 C(1843-vgd_vteprec_update_global_row): tunnel adding > physical switch > Jul 11 22:15:45 C(1843-vgd_vteprec_update_global_row): tunnel no tunnel ip > present > Jul 11 22:15:45 C(1843-vgd_core_fsm): Current state VGD_STATE_FULL has > nothing to process > Jul 11 22:15:45 C(1843-vgd_core_fsm): Current event :5 > Jul 11 22:15:45 C(1843-vgd_core_fsm): State change from VGD_STATE_FULL to > VGD_STATE_FULL > Jul 11 22:15:45 C(1843-vgd_controller_update): Update controller > ipaddr XXXXXXXXXXXX to state VGD_STATE_FULL > Jul 11 22:15:45 C(1843-vgd_ovs_client_complete_txn): ending the bulk > transaction.bulk count 0 > Jul 11 22:15:45 C(1843-vgd_ovs_client_error_handler): Error Handler Update > :VGD_TXN_SUCCESS > Jul 11 22:15:50 C(1843-vgd_ovs_client_connect_recv_cb): received data of > length = 325 > Jul 11 22:15:50 C(1843-vgd_vteprec_delete_manager): Delete manager > ssl:10.10..210.140:10002 > Jul 11 22:15:50 C(1843-vgd_core_fsm): NOTHING TO PROCESS > Jul 11 22:15:50 C(1843-vgd_core_fsm): Current event :4 > Jul 11 22:15:50 C(1843-vgd_core_fsm): State change from VGD_STATE_FULL to > VGD_STATE_ADD > Jul 11 22:15:50 C(1843-vgd_controller_add_queue): Update controller ipaddr > XXXXXXXXXXXX to state VGD_STATE_ADD > Jul 11 22:15:50 C(1843-vgd_vteprec_update_manager): Update manager > ssl:10.10..210.140:10002 > Jul 11 22:15:50 C(1843-vgd_vteprec_extract_manager): Extract controller > ipaddr XXXXXXXXXXXX protocol 1 port 10002 max_backoff 1000 inactivity_probe > 10000 > Jul 11 22:15:50 C(1843-vgd_controller_add): Add controller > ipaddr XXXXXXXXXXXX protocol 1 port 10002 max_backoff 1000 inactivity_probe > 10000 > Jul 11 22:15:50 C(1843-vgd_core_fsm): NOTHING TO PROCESS > Jul 11 22:15:50 C(1843-vgd_core_fsm): Current event :3 > Jul 11 22:15:50 C(1843-vgd_core_fsm): State change from VGD_STATE_ADD to > VGD_STATE_FULL > Jul 11 22:15:50 C(1843-vgd_controller_update): Update controller ipaddr > XXXXXXXXXXXX to state VGD_STATE_FULL > Jul 11 22:15:50 C(1843-vgd_vteprec_update_global_row): tunnel Adding > global row > Jul 11 22:15:50 C(1843-vgd_vteprec_update_global_row): tunnel adding > physical switch > Jul 11 22:15:50 C(1843-vgd_vteprec_update_global_row): tunnel no tunnel ip > present > Jul 11 22:15:50 C(1843-vgd_core_fsm): Current state VGD_STATE_FULL has > nothing to process > Jul 11 22:15:50 C(1843-vgd_core_fsm): Current event :5 > Jul 11 22:15:50 C(1843-vgd_core_fsm): State change from VGD_STATE_FULL to > VGD_STATE_FULL > Jul 11 22:15:50 C(1843-vgd_controller_update): Update controller ipaddr > XXXXXXXXXXXX to state VGD_STATE_FULL > Jul 11 22:15:50 C(1843-vgd_ovs_client_complete_txn): ending the bulk > transaction.bulk count 0 > > I suspect maybe I didn't do something correctly with the SSL certs but > nothing in logs/traceoptions that I can find to confirm that. OVSDB was > working on this switch previously before upgrading to latest Junos and > needing to switch to SSL. > > Anyone else run into this? > > Thanks! > Dan >
_______________________________________________ Users mailing list [email protected] http://lists.opencontrail.org/mailman/listinfo/users_lists.opencontrail.org
