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
