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
