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
