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

Reply via email to