You can open a bug for this request. But currently that is not a priority. You could also submit a fix.
Regards -Harshad > On Oct 21, 2015, at 4:24 PM, Dan Houtz <[email protected]> wrote: > > After sending my last reply I realized I might not have thought it out > thoroughly. I guess I could define the real subnets with the IP allocation > pool limited to the IP's I would like assigned to IRB interfaces; then also > add a fake subnet. When adding physical ports to the VN I could then specify > to put it in the fake subnet. Is this what you were thinking? > > I guess this would work though it seems like a hack as I now need to assign, > track, and configure subnets that I don't really need and Contrail now needs > to track state of all these port attributes that aren't really needed. > > -Dan > >> On Wed, Oct 21, 2015 at 6:12 PM, Dan Houtz <[email protected]> wrote: >> I believe I still need to specify the proper subnets for the VN so that my >> IRB's are configured properly on MX gateways. It seems like maybe we'll >> require additional functionality to completely disable IPAM, aside from >> configuring gateways? >> >> -Dan >> >> >>> On Wed, Oct 21, 2015 at 6:05 PM, Harshad Nakil <[email protected]> wrote: >>> If you are managing all IPAM outside of contrail and you are only using L2 >>> from contrail, then you can have fake subnets in the VN. >>> >>> Regards >>> -Harshad >>> >>> >>>> On Oct 21, 2015, at 3:45 PM, Dan Houtz <[email protected]> wrote: >>>> >>>> Nischal, >>>> >>>> Related to the above discussion, is it possible to have Contrail NOT >>>> allocate IP addresses for each TOR port I add to a VN? I noticed this when >>>> creating an allocation pool of 3 IP addresses, enough for TSN and 2 >>>> gateways. Because I added the physical device interfaces to the VN first, >>>> the IP's were no longer available in the IP pool to assign to the MX's >>>> when I later extended the networks. >>>> >>>> -Dan >>>> >>>>> On Tue, Oct 20, 2015 at 2:50 PM, Dan Houtz <[email protected]> wrote: >>>>> Sure, here is an example with IPs sanitized: >>>>> >>>>> { >>>>> "virtual-network": { >>>>> "display_name": "DefaultPublic", >>>>> "floating_ip_pools": [ >>>>> { >>>>> "href": >>>>> "http://10.10.10.4:8082/floating-ip-pool/220e690a-58e3-48f9-8986-cb111964c55a";, >>>>> "to": [ >>>>> "default-domain", >>>>> "admin", >>>>> "DefaultPublic", >>>>> "default" >>>>> ], >>>>> "uuid": "220e690a-58e3-48f9-8986-cb111964c55a" >>>>> } >>>>> ], >>>>> "flood_unknown_unicast": true, >>>>> "fq_name": [ >>>>> "default-domain", >>>>> "admin", >>>>> "DefaultPublic" >>>>> ], >>>>> "href": >>>>> "http://10.10.10.4:8082/virtual-network/6fb241e1-80e9-4097-b1d6-ad736e1ad8dc";, >>>>> "id_perms": { >>>>> "created": "2015-10-14T21:52:48.697076", >>>>> "creator": null, >>>>> "description": null, >>>>> "enable": true, >>>>> "last_modified": "2015-10-17T01:53:28.523888", >>>>> "permissions": { >>>>> "group": "KeystoneAdmin", >>>>> "group_access": 7, >>>>> "other_access": 7, >>>>> "owner": "admin", >>>>> "owner_access": 7 >>>>> }, >>>>> "user_visible": true, >>>>> "uuid": { >>>>> "uuid_lslong": 12814620501009422556, >>>>> "uuid_mslong": 8048567920850714775 >>>>> } >>>>> }, >>>>> "is_shared": false, >>>>> "name": "DefaultPublic", >>>>> "network_ipam_refs": [ >>>>> { >>>>> "attr": { >>>>> "ipam_subnets": [ >>>>> { >>>>> "addr_from_start": true, >>>>> "allocation_pools": [], >>>>> "default_gateway": "10.10.10.225", >>>>> "dhcp_option_list": { >>>>> "dhcp_option": [ >>>>> { >>>>> "dhcp_option_name": "6", >>>>> "dhcp_option_value": "0.0.0.0" >>>>> } >>>>> ] >>>>> }, >>>>> "dns_server_address": "10.10.10.226", >>>>> "enable_dhcp": false, >>>>> "host_routes": { >>>>> "route": [] >>>>> }, >>>>> "subnet": { >>>>> "ip_prefix": "10.10.10.224", >>>>> "ip_prefix_len": 28 >>>>> }, >>>>> "subnet_uuid": >>>>> "83dab1c7-d7b2-4252-8dfa-53424cba75ca" >>>>> } >>>>> ] >>>>> }, >>>>> "href": >>>>> "http://10.10.10.4:8082/network-ipam/023d5322-daef-4323-986e-f45b4b2e6284";, >>>>> "to": [ >>>>> "default-domain", >>>>> "default-project", >>>>> "default-network-ipam" >>>>> ], >>>>> "uuid": "023d5322-daef-4323-986e-f45b4b2e6284" >>>>> } >>>>> ], >>>>> "parent_href": >>>>> "http://10.10.10.4:8082/project/c12b460d-4a4d-472e-b931-82d6e45bcde2";, >>>>> "parent_type": "project", >>>>> "parent_uuid": "c12b460d-4a4d-472e-b931-82d6e45bcde2", >>>>> "physical_router_back_refs": [ >>>>> { >>>>> "attr": null, >>>>> "href": >>>>> "http://10.10.10.4:8082/physical-router/7036a9e9-e4b5-42c5-8b7a-c54f3d9b7518";, >>>>> "to": [ >>>>> "default-global-system-config", >>>>> "gw1.ord6" >>>>> ], >>>>> "uuid": "7036a9e9-e4b5-42c5-8b7a-c54f3d9b7518" >>>>> } >>>>> ], >>>>> "route_target_list": {}, >>>>> "router_external": true, >>>>> "routing_instances": [ >>>>> { >>>>> "href": >>>>> "http://10.10.10.4:8082/routing-instance/62318c53-f534-433a-984a-f00f251adbbb";, >>>>> "to": [ >>>>> "default-domain", >>>>> "admin", >>>>> "DefaultPublic", >>>>> "DefaultPublic" >>>>> ], >>>>> "uuid": "62318c53-f534-433a-984a-f00f251adbbb" >>>>> } >>>>> ], >>>>> "uuid": "6fb241e1-80e9-4097-b1d6-ad736e1ad8dc", >>>>> "virtual_machine_interface_back_refs": [ >>>>> { >>>>> "attr": null, >>>>> "href": >>>>> "http://10.10.10.4:8082/virtual-machine-interface/89dda3c1-6ac9-433a-92db-71749b90b692";, >>>>> "to": [ >>>>> "default-domain", >>>>> "admin", >>>>> "89dda3c1-6ac9-433a-92db-71749b90b692" >>>>> ], >>>>> "uuid": "89dda3c1-6ac9-433a-92db-71749b90b692" >>>>> } >>>>> ], >>>>> "virtual_network_network_id": 5, >>>>> "virtual_network_properties": { >>>>> "allow_transit": false, >>>>> "forwarding_mode": "l2_l3", >>>>> "vxlan_network_identifier": 10000 >>>>> } >>>>> } >>>>> } >>>>> >>>>> >>>>> >>>>>> On Tue, Oct 20, 2015 at 12:19 PM, Nischal Sheth <[email protected]> >>>>>> wrote: >>>>>> >>>>>> Hi Dan, >>>>>> >>>>>> Understand your requirement. >>>>>> Can you share the configuration you're using for these VNs? >>>>>> >>>>>> -Nischal >>>>>> >>>>>>> On Oct 18, 2015, at 12:59 PM, Dan Houtz <[email protected]> wrote: >>>>>>> >>>>>>> Hi Nischal, >>>>>>> >>>>>>> I can not ping the TSN but I can confirm that I see ARP for it. >>>>>>> >>>>>>> I don't see any reason why the TSN should have an IP address assigned >>>>>>> if we're not using DNS or DHCP functionality. I understand that this >>>>>>> isn't much of an issue for those who are configuring private /24's on >>>>>>> VNs but even wasting 1 IP address is unacceptable when configuring a VN >>>>>>> with a /29 or /28 of public address space. >>>>>>> >>>>>>> At the end of the day, we really just need Contrail to build us L2 >>>>>>> networks between TOR ports and configure MX's to act as a gateway. We >>>>>>> don't expect or even want the TSN to do anything more then flood BUM >>>>>>> traffic. >>>>>>> >>>>>>> I think 2.21 has brought us really close to meeting our initial use >>>>>>> cases so I want to thank everyone for their work on this. >>>>>>> >>>>>>> -Dan >>>>>>> >>>>>>> >>>>>>>> On Sat, Oct 17, 2015 at 1:31 PM, Nischal Sheth <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hi Dan, >>>>>>>> >>>>>>>> Can you arp/ping the .2 address to check if the TSN responds to it? >>>>>>>> >>>>>>>> -Nischal >>>>>>>> >>>>>>>> Sent from my iPhone >>>>>>>> >>>>>>>> On Oct 17, 2015, at 10:45 AM, Dan Houtz <[email protected]> wrote: >>>>>>>> >>>>>>>>> Hi Nischal, >>>>>>>>> >>>>>>>>> Thank you for the info. Is there anyway to override the ".2 for DNS" >>>>>>>>> behavior or should I consider opening a feature request? When >>>>>>>>> creating an external network with public IP's losing even 1 of these >>>>>>>>> to an unused service is a bit tough to swallow considering the state >>>>>>>>> of IP availability on the Internet. We're not currently planning to >>>>>>>>> use any of the DNS or DHCP functionality within Contrail; in fact I >>>>>>>>> would like to operate without any concept of IPAM if at all possible >>>>>>>>> :) >>>>>>>>> >>>>>>>>> -Dan >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Sat, Oct 17, 2015 at 12:34 PM, Nischal Sheth <[email protected]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Hi Dan, >>>>>>>>>> >>>>>>>>>> The .2 address is set aside for use as DNS server at the TSN, >>>>>>>>>> irrespective of whether DNS is enabled or not. >>>>>>>>>> >>>>>>>>>> I think you should be able to control assignment of the MX irb >>>>>>>>>> addresses by creating an allocation pool. The pool could have the >>>>>>>>>> first 4 addresses in your case. The rest of the addresses in the >>>>>>>>>> subnet can be owned by your DHCP server. >>>>>>>>>> >>>>>>>>>> -Nischal >>>>>>>>>> >>>>>>>>>> Sent from my iPhone >>>>>>>>>> >>>>>>>>>> On Oct 17, 2015, at 9:25 AM, Dan Houtz <[email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> Hi fellow Contrailers, >>>>>>>>>>> >>>>>>>>>>> The 2.21 release adds functionality to configure redundant MX >>>>>>>>>>> gateways using the virtual-gateway-address knob. Is anyone able to >>>>>>>>>>> explain the logic of the per router IP assignments? Are these able >>>>>>>>>>> to be set in a deterministic way or must we rely on Contrail to >>>>>>>>>>> choose them at random from the subnet? >>>>>>>>>>> >>>>>>>>>>> For example, I created a network using 10.10.10.0/24 with .1 as the >>>>>>>>>>> gateway. Contrail configured mx1 with and address of .3 and mx2 >>>>>>>>>>> with an address of .4. >>>>>>>>>>> >>>>>>>>>>> I don't quite understand why .2 is skipped. At least in our >>>>>>>>>>> environment where we'll probably only have 2 MX's for a VN, we >>>>>>>>>>> would prefer that the first 3 usable IP addresses in the subnet >>>>>>>>>>> ALWAYS be used for each router and the virtual gateway address. >>>>>>>>>>> >>>>>>>>>>> I'm also concerned about what happens if you remove a physical >>>>>>>>>>> router temporarily. In my case above, I removed mx1 and then >>>>>>>>>>> re-added it to the VN. When doing this, mx1 was then assigned a new >>>>>>>>>>> IP address - this time .7. So if seems like, over, time it will >>>>>>>>>>> cycle through the entire IP block. What happens if it chooses an IP >>>>>>>>>>> that a host is already using? >>>>>>>>>>> >>>>>>>>>>> Again, I would much prefer if I could control this assignment so I >>>>>>>>>>> can make sure it gets the same IP address. Removing/Adding a >>>>>>>>>>> physical router to a VN might not be super common but I could see >>>>>>>>>>> it happening for testing, troubleshooting, and maintenance . >>>>>>>>>>> >>>>>>>>>>> Thanks! >>>>>>>>>>> Dan >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Dev mailing list >>>>>>>>>>> [email protected] >>>>>>>>>>> http://lists.opencontrail.org/mailman/listinfo/dev_lists.opencontrail.org >>>> >>>> _______________________________________________ >>>> Dev mailing list >>>> [email protected] >>>> http://lists.opencontrail.org/mailman/listinfo/dev_lists.opencontrail.org >
_______________________________________________ Dev mailing list [email protected] http://lists.opencontrail.org/mailman/listinfo/dev_lists.opencontrail.org
