15:13:27 #startmeeting bgpvpn 15:13:28 Meeting started Tue Nov 15 15:13:27 2016 UTC and is due to finish in 60 minutes. The chair is tmorin. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:13:30 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:13:32 The meeting name has been set to 'bgpvpn' 15:13:35 hi everyone 15:13:39 tmorin: hi 15:13:46 hi bobmel 15:13:55 tmorin: thx for your comments 15:14:12 tmorin: review comment 15:14:13 hi doude, eon`, lewo, matrohon, pcarver, timirnich 15:14:21 you're welcome :) 15:14:28 thanks for working on this ! 15:14:52 tmorin: I have some follow up questions but perhaps we can take those here after this meeting 15:15:41 we sure can, during of after, depending what else we cover 15:16:56 tmorin: ok, great 15:18:05 hmm 15:18:13 we aren't many :) 15:18:36 some people may still be on DST... 15:19:11 bobmel: let's discuss the point you have about the tempest scenario testing 15:19:29 we can still cover other topics when/if more people come up 15:19:43 Ok, yes we might as well do that since nobody else seems to be around 15:20:13 So I have my single node devstack setup with bpgvpn up (bagpipe driveR) 15:20:58 Now, in the scenario test outlines with the two networks/subnets attached to the vpn 15:21:42 Should that vpn instance forward packets between the vms on those two networks/subnets 15:21:44 ? 15:22:47 in a single node setup, the one OVS will forward the packets between the VMs on those two networks 15:23:28 the traffic path will be br-int -> br-tun -> br-mpls -> br-tun -> br-int 15:23:50 with the internal vlan id changed by br-mpls 15:24:05 does it answer your question ? 15:24:37 Yes think so. 15:25:19 Is it the bagpipe agent driver that will create the ovs rules to make that vlan change? 15:26:10 bagpipe_bgpvpn extension inside the agent will receive BGPVPN information in RPCs and pass them to bagpipe-bgp via its local REST API 15:26:16 At the moment i have not been able to ping between the two VMs 15:26:30 and its bagpipe-bgp that will (a) exchange BGP VPN routes and (b) populate br-mpls 15:26:58 Aha, ok, I see. 15:27:01 (b) above include rule that change the vlan id 15:27:07 rules 15:27:28 traffic is processed in a given VRF based on its local vlan id 15:28:15 if the prefix matched in the VRF is on the same compute, the packet is resubmitted to appear as incoming MPLS traffic, and matched in the destination VRF 15:28:47 this destination VRF pops the MPLS label, sets the destination local vlan id, and passes the packet to br-tun 15:29:14 these diagrams may help: http://docs.openstack.org/developer/networking-bgpvpn/bagpipe/index.html 15:29:29 (to some degree only, as they don't have all details) 15:31:12 Yes I have had a look at that one. 15:31:59 So what you wrote above describes what should happen in the single node setup? 15:33:20 yes 15:34:48 in a multinode setup, the path would be : node A [ br-int -> br-tun -> br-mpls ] --> -- (phy or GRE) --> node B [ br-mpls -> br-tun -> br-int] 15:37:45 I wonder if it is maybe the route targets config that prevents the ping to work 15:38:31 can you do a "bagpipe-looking-glass -r" and put the output on paste.openstack.org ? 15:40:14 on sec 15:42:22 http://paste.openstack.org/show/589301/ 15:44:09 The devstack host IP is 172.16.6.20 15:45:14 vpns / instances is empty 15:45:32 Lots of those OpenWaitTimeout messages in hte log 15:45:38 it means that the bagpipe_bgpvpn agent extension passed no BGP VPN attachement information to bagpipe-bgp 15:46:31 you can ignore these OpenWaitTimeout message: bagpipe-bgp is trying to connect its default BGP peer, but we don't need any in a single node setup (I think we should actually get rid of this default BGP peer setup) 15:46:54 Ok, got it. 15:46:57 so its likely that the bagpipe_bgpvpn agent extension has no BGPVPN attachement information 15:47:05 do you see warnings in q-agt.log ? 15:47:12 Let me check 15:49:37 No warnings 15:49:55 I see lines like this: 15:49:56 bagpipe-bgp client request: GET ping [None 15:50:07 bagpipe-bgp returns [200:96867148709979766103418085043297248131] 15:50:25 bagpipe-bgp PING response received with sequence number 96867148709979766103418085043297248131 f 15:50:31 it simply means that bagpipe_bgpvpn extension can properly talk to bagpipe-bgp 15:50:52 Ok 15:50:53 the sequence number is used to let the agent extension know when/if bagpipe-bgp restarts 15:51:22 if you grep for 'bagpipe' in q-agt.log, you should see RPCs about BGP VPNs 15:51:32 assuming that Neutron is actually sending thos 15:52:08 those 15:52:27 but you could first confirm that (checking about warnings/errors in q-svc.log, grepping for bagpipe) 15:55:02 Here's some output from the q-agt log 15:55:03 http://paste.openstack.org/show/589303/ 15:55:50 based on these logs you should have vpn attachment defined in bagpipe-bgp 15:56:42 "bagpipe-looking-glass summary vpn_instances_count" should give you something different from 0 15:56:47 so it should be visible in the looking glass? 15:56:54 but you had zero in the output you sent earlier 15:56:55 yes 15:57:30 it return 0 15:57:32 odd 15:59:15 RPC to the q-agent for bagpipe driver, is that triggered when a network is attached to the vpn? 15:59:25 yes 15:59:59 Is there a way to restart bagpipe itself? 15:59:59 or when a Port goes active 16:00:11 Ok, got it. 16:00:17 in screen, b-bgp tab, stop restart 16:00:18 yes 16:00:51 is the q-agt.log that you sent complete, I'm surprised to see nothing after the last line 16:01:08 No, it was a subset of it 16:01:26 time to wrap up? 16:01:40 #endmeeting bgpvpn