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
