Activity log for bug #1471637

Date Who What changed Old value New value Message
2015-07-06 03:07:54 Nischal Sheth bug added bug
2015-07-06 03:08:06 Nischal Sheth information type Proprietary Public
2015-07-06 03:08:14 Nischal Sheth nominated for series juniperopenstack/r2.20
2015-07-06 03:08:14 Nischal Sheth bug task added juniperopenstack/r2.20
2015-07-06 03:08:14 Nischal Sheth nominated for series juniperopenstack/trunk
2015-07-06 03:08:14 Nischal Sheth bug task added juniperopenstack/trunk
2015-07-06 03:08:21 Nischal Sheth juniperopenstack/r2.20: importance Undecided Medium
2015-07-06 03:08:30 Nischal Sheth juniperopenstack/r2.20: assignee Sachin Bansal (sbansal)
2015-07-06 03:08:34 Nischal Sheth juniperopenstack/r2.20: milestone r2.21
2015-07-06 03:08:55 Nischal Sheth summary Support configurable mode for VN Implement configurable mode for VN
2015-07-06 03:12:09 Nischal Sheth description Should support a configurable mode for VN. The 3 modes to be supported are: 1. L2+ L3 mode: This is currently supported in 2.20 and newer releases and will be the default mode for a VN. Intra subnet traffic is bridged and inter- subnet traffic is routed. 2. L2 only mode: This is required for certain applications that need pure L2 forwarding capabilities e.g. Junosphere. Even though there may be a subnet configured for the VN, the ports/VMIs do not use addresses from the subnet. Proxy ARP is disabled and all ARP packets are flooded - the endpoints are responsible for responding to ARP requests. Similarly, DHCP and DNS are also disabled. The vRouter should not advertise any IP addresses in MAC routes. 3. L3 only mode: This is the classic mode that was supported in 1.x releases before BMS and and IRB support was implemented. The vRouter responds to all ARP requests with the VRRP MAC address. DNS and DHCP are also supported. The vRouter should not advertise any EVPN routes for MACs. In addition to supporting a mode per VN, it might also be worth making it configurable in the global system config and allowing the user to override it on a per VN basis. Should support configurable mode for VN. The 3 modes to be supported are: 1. L2+ L3 mode: This is currently supported in 2.20 and newer releases. It should be the default mode for a VN. Intra subnet traffic is bridged and inter-subnet traffic is routed. 2. L2 only mode: This is required for certain applications that need pure L2 forwarding capabilities e.g. Junosphere. Even though there could be a subnet configured for the VN, the ports/VMIs do not use addresses from the subnet. Proxy ARP is disabled and all ARP packets are flooded - endpoints are responsible for responding to ARP requests. Similarly, DHCP and DNS are also disabled. The vRouter should not advertise any IP addresses in MAC routes. 3. L3 only mode: This is the classic mode supported in 1.x releases before BMS and and IRB support was implemented. The vRouter responds to all ARP requests with the VRRP MAC address. DNS and DHCP are also supported. The vRouter should not advertise any EVPN routes for MACs. In addition to supporting a mode per VN, it might also be worth making it configurable in the global system config and allowing the user to override it on a per VN basis.
2015-07-06 03:40:50 Nischal Sheth description Should support configurable mode for VN. The 3 modes to be supported are: 1. L2+ L3 mode: This is currently supported in 2.20 and newer releases. It should be the default mode for a VN. Intra subnet traffic is bridged and inter-subnet traffic is routed. 2. L2 only mode: This is required for certain applications that need pure L2 forwarding capabilities e.g. Junosphere. Even though there could be a subnet configured for the VN, the ports/VMIs do not use addresses from the subnet. Proxy ARP is disabled and all ARP packets are flooded - endpoints are responsible for responding to ARP requests. Similarly, DHCP and DNS are also disabled. The vRouter should not advertise any IP addresses in MAC routes. 3. L3 only mode: This is the classic mode supported in 1.x releases before BMS and and IRB support was implemented. The vRouter responds to all ARP requests with the VRRP MAC address. DNS and DHCP are also supported. The vRouter should not advertise any EVPN routes for MACs. In addition to supporting a mode per VN, it might also be worth making it configurable in the global system config and allowing the user to override it on a per VN basis. Should support configurable mode for VN. The 3 modes to be supported are: 1. L2+ L3 mode: This is currently supported in 2.20 and newer releases. It should be the default mode for a VN. Intra subnet traffic is bridged and inter-subnet traffic is routed. 2. L2 only mode: This is required for certain applications that need pure L2 forwarding capabilities e.g. Junosphere. Even though there could be a subnet configured for the VN, the ports/VMIs do not use addresses from the subnet. Proxy ARP is disabled and all ARP packets are flooded - endpoints are responsible for responding to ARP requests. Similarly, DHCP and DNS are also disabled. The vRouter should not advertise any IP addresses in MAC routes. There's a known limitation with nova compute wherein it requires an IP address for a port. Instead of forcing the user to configure a subnet for L3 only networks in order to satisfy nova compute, we should consider creating all L2 only networks with 0.0.0.0/8 subnet, which is reserved by IANA for the "Current Network". An address from this subnet can only be used a a source address, not as a destination. This should be OK for L2 only networks since we don't expect these addresses to even be used as source addresses. 3. L3 only mode: This is the classic mode supported in 1.x releases before BMS and and IRB support was implemented. The vRouter responds to all ARP requests with the VRRP MAC address. DNS and DHCP are also supported. The vRouter should not advertise any EVPN routes for MACs. In addition to supporting a mode per VN, it might also be worth making it configurable in the global system config and allowing the user to override it on a per VN basis.
2015-07-06 15:40:08 Nischal Sheth description Should support configurable mode for VN. The 3 modes to be supported are: 1. L2+ L3 mode: This is currently supported in 2.20 and newer releases. It should be the default mode for a VN. Intra subnet traffic is bridged and inter-subnet traffic is routed. 2. L2 only mode: This is required for certain applications that need pure L2 forwarding capabilities e.g. Junosphere. Even though there could be a subnet configured for the VN, the ports/VMIs do not use addresses from the subnet. Proxy ARP is disabled and all ARP packets are flooded - endpoints are responsible for responding to ARP requests. Similarly, DHCP and DNS are also disabled. The vRouter should not advertise any IP addresses in MAC routes. There's a known limitation with nova compute wherein it requires an IP address for a port. Instead of forcing the user to configure a subnet for L3 only networks in order to satisfy nova compute, we should consider creating all L2 only networks with 0.0.0.0/8 subnet, which is reserved by IANA for the "Current Network". An address from this subnet can only be used a a source address, not as a destination. This should be OK for L2 only networks since we don't expect these addresses to even be used as source addresses. 3. L3 only mode: This is the classic mode supported in 1.x releases before BMS and and IRB support was implemented. The vRouter responds to all ARP requests with the VRRP MAC address. DNS and DHCP are also supported. The vRouter should not advertise any EVPN routes for MACs. In addition to supporting a mode per VN, it might also be worth making it configurable in the global system config and allowing the user to override it on a per VN basis. Should support configurable mode for VN. The 3 modes to be supported are: 1. L2+ L3 mode: This is currently supported in 2.20 and newer releases. It should be the default mode for a VN. Intra subnet traffic is bridged and inter-subnet traffic is routed. 2. L2 only mode: This is required for certain applications that need pure L2 forwarding capabilities e.g. Junosphere. Even though there could be a subnet configured for the VN, the ports/VMIs do not use addresses from the subnet. Proxy ARP is disabled and all ARP packets are flooded - endpoints are responsible for responding to ARP requests. Similarly, DHCP and DNS are also disabled. The vRouter should not advertise any IP addresses in MAC routes. There's a known limitation with nova compute wherein it requires an IP address for a port. Instead of forcing the user to configure a subnet for L3 only networks in order to satisfy nova compute, we should consider creating all L2 only networks with 0.0.0.0/8 subnet, which is reserved by IANA for the "Current Network". An address from this subnet can only be used a a source address, not as a destination. This should be OK for L2 only networks since we don't expect these addresses to even be used as source addresses. Further, we should not add subnet, default gateway or dns server routes to the VRF. 3. L3 only mode: This is the classic mode supported in 1.x releases before BMS and and IRB support was implemented. The vRouter responds to all ARP requests with the VRRP MAC address. DNS and DHCP are also supported. The vRouter should not advertise any EVPN routes for MACs. In addition to supporting a mode per VN, it might also be worth making it configurable in the global system config and allowing the user to override it on a per VN basis.
2015-07-06 15:41:11 Nischal Sheth description Should support configurable mode for VN. The 3 modes to be supported are: 1. L2+ L3 mode: This is currently supported in 2.20 and newer releases. It should be the default mode for a VN. Intra subnet traffic is bridged and inter-subnet traffic is routed. 2. L2 only mode: This is required for certain applications that need pure L2 forwarding capabilities e.g. Junosphere. Even though there could be a subnet configured for the VN, the ports/VMIs do not use addresses from the subnet. Proxy ARP is disabled and all ARP packets are flooded - endpoints are responsible for responding to ARP requests. Similarly, DHCP and DNS are also disabled. The vRouter should not advertise any IP addresses in MAC routes. There's a known limitation with nova compute wherein it requires an IP address for a port. Instead of forcing the user to configure a subnet for L3 only networks in order to satisfy nova compute, we should consider creating all L2 only networks with 0.0.0.0/8 subnet, which is reserved by IANA for the "Current Network". An address from this subnet can only be used a a source address, not as a destination. This should be OK for L2 only networks since we don't expect these addresses to even be used as source addresses. Further, we should not add subnet, default gateway or dns server routes to the VRF. 3. L3 only mode: This is the classic mode supported in 1.x releases before BMS and and IRB support was implemented. The vRouter responds to all ARP requests with the VRRP MAC address. DNS and DHCP are also supported. The vRouter should not advertise any EVPN routes for MACs. In addition to supporting a mode per VN, it might also be worth making it configurable in the global system config and allowing the user to override it on a per VN basis. Should support configurable mode for VN. The 3 modes to be supported are: 1. L2+ L3 mode: This is currently supported in 2.20 and newer releases. It should be the default mode for a VN. Intra subnet traffic is bridged and inter-subnet traffic is routed. 2. L2 only mode: This is required for certain applications that need pure L2 forwarding capabilities e.g. Junosphere. Even though there could be a subnet configured for the VN, the ports/VMIs do not use addresses from the subnet. Proxy ARP is disabled and all ARP packets are flooded - endpoints are responsible for responding to ARP requests. Similarly, DHCP and DNS are also disabled. The vRouter should not advertise any IP addresses in MAC routes. There's a known limitation with nova compute wherein it requires an IP address for a port. Instead of forcing the user to configure a subnet for L3 only networks in order to satisfy nova compute, we should consider creating all L2 only networks with 0.0.0.0/8 subnet, which is reserved by IANA for the "Current Network". An address from this subnet can only be used a a source address, not as a destination. This should be OK for L2 only networks since we don't expect these addresses to even be used as source addresses. Further, we should not add subnet, default gateway or dns server routes to the VRF. 3. L3 only mode: This is the classic mode supported in 1.x releases before BMS and and IRB support was implemented. The vRouter responds to all ARP requests with the VRRP MAC address. DNS and DHCP are also supported. The vRouter should not advertise any EVPN routes for MACs. In addition to supporting a mode per VN, it might also be worth making it configurable in the global system config and allowing the user to override it on a per VN basis. In this case, the default mode for a VN will be the value from the global system config, which can then we overridden by a per VN mode.
2015-07-08 16:14:42 Nischal Sheth summary Implement configurable mode for VN Implement configurable forwarding mode for VN
2015-07-08 16:17:13 Nischal Sheth description Should support configurable mode for VN. The 3 modes to be supported are: 1. L2+ L3 mode: This is currently supported in 2.20 and newer releases. It should be the default mode for a VN. Intra subnet traffic is bridged and inter-subnet traffic is routed. 2. L2 only mode: This is required for certain applications that need pure L2 forwarding capabilities e.g. Junosphere. Even though there could be a subnet configured for the VN, the ports/VMIs do not use addresses from the subnet. Proxy ARP is disabled and all ARP packets are flooded - endpoints are responsible for responding to ARP requests. Similarly, DHCP and DNS are also disabled. The vRouter should not advertise any IP addresses in MAC routes. There's a known limitation with nova compute wherein it requires an IP address for a port. Instead of forcing the user to configure a subnet for L3 only networks in order to satisfy nova compute, we should consider creating all L2 only networks with 0.0.0.0/8 subnet, which is reserved by IANA for the "Current Network". An address from this subnet can only be used a a source address, not as a destination. This should be OK for L2 only networks since we don't expect these addresses to even be used as source addresses. Further, we should not add subnet, default gateway or dns server routes to the VRF. 3. L3 only mode: This is the classic mode supported in 1.x releases before BMS and and IRB support was implemented. The vRouter responds to all ARP requests with the VRRP MAC address. DNS and DHCP are also supported. The vRouter should not advertise any EVPN routes for MACs. In addition to supporting a mode per VN, it might also be worth making it configurable in the global system config and allowing the user to override it on a per VN basis. In this case, the default mode for a VN will be the value from the global system config, which can then we overridden by a per VN mode. Should support configurable forwarding mode for VN. The 3 modes to be supported are: 1. L2+ L3 mode: This is currently supported in 2.20 and newer releases. It should be the default mode for a VN. Intra subnet traffic is bridged and inter-subnet traffic is routed. 2. L2 only mode: This is required for certain applications that need pure L2 forwarding capabilities e.g. Junosphere. Even though there could be a subnet configured for the VN, the ports/VMIs do not use addresses from the subnet. Proxy ARP is disabled and all ARP packets are flooded - endpoints are responsible for responding to ARP requests. Similarly, DHCP and DNS are also disabled. The vRouter should not advertise any IP addresses in MAC routes. There's a known limitation with nova compute wherein it requires an IP address for a port. Instead of forcing the user to configure a subnet for L3 only networks in order to satisfy nova compute, we should consider creating all L2 only networks with 0.0.0.0/8 subnet, which is reserved by IANA for the "Current Network". An address from this subnet can only be used a a source address, not as a destination. This should be OK for L2 only networks since we don't expect these addresses to even be used as source addresses. Further, we should not add subnet, default gateway or dns server routes to the VRF. Need to figure out a way to allow multiple VNs in same project to use the same 0.0.0.0/8 subnet. 3. L3 only mode: This is the classic mode supported in 1.x releases before BMS and and IRB support was implemented. The vRouter responds to all ARP requests with the VRRP MAC address. DNS and DHCP are also supported. The vRouter should not advertise any EVPN routes for MACs. In addition to supporting a mode per VN, it might also be worth making it configurable in the global system config and allowing the user to override it on a per VN basis. In this case, the default mode for a VN will be the value from the global system config, which can then we overridden by a per VN mode.
2015-07-08 17:25:18 Qasim Arham bug added subscriber Qasim Arham
2015-07-09 21:39:17 Vinay Mahuli juniperopenstack/trunk: status New In Progress
2015-07-10 18:02:11 Sachin Bansal juniperopenstack/trunk: assignee Sachin Bansal (sbansal) Rahul (rahuls)
2015-07-13 17:00:49 Vinay Mahuli juniperopenstack/r2.20: status New In Progress
2015-07-13 17:00:49 Vinay Mahuli juniperopenstack/r2.20: assignee Sachin Bansal (sbansal) Rahul (rahuls)
2015-07-14 16:22:42 Nischal Sheth tags config ui vrouter config quench ui vrouter
2015-08-03 12:39:15 Rahul juniperopenstack/r2.20: assignee Rahul (rahuls) asbalaji (asbalaji)
2015-08-03 12:39:27 Rahul juniperopenstack/trunk: assignee Rahul (rahuls) asbalaji (asbalaji)
2015-08-20 06:26:51 OpenContrail Admin juniperopenstack/r2.20: status In Progress Fix Committed
2015-09-19 19:30:45 Vinay Mahuli juniperopenstack/r2.20: status Fix Committed In Progress
2015-09-21 12:55:03 Vinay Mahuli juniperopenstack/r2.20: status In Progress Fix Committed
2015-10-21 08:25:18 Rahul juniperopenstack/trunk: assignee asbalaji (asbalaji) Rahul (rahuls)
2016-01-28 19:59:43 Rahul juniperopenstack/trunk: status In Progress Fix Committed