Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Hostname support for BGP/other protocols #2135

Closed
leleobhz opened this issue Apr 28, 2018 · 8 comments
Closed

Feature Request: Hostname support for BGP/other protocols #2135

leleobhz opened this issue Apr 28, 2018 · 8 comments

Comments

@leleobhz
Copy link

Hello,

I'm using FRR inside docker environment and inside the same docker bridge. Everything works well, but docker, to make things easier, set a hostname with the name the container with the internal IP atributed to him.

This IP address vary each time container runs and the hostname is the default way of docker images to reach each other. But FRR only supports IP address as neighbour, not supporting hostname as a valid config.

That said, its possible to deploy hostname support for neighbours in FRRouting?

Thanks!

@leleobhz
Copy link
Author

Just for reference, I've also registered the issue #2024 related to Docker images too. I'm using the new version of the image effectively to register this issue.

@ajones-rvbd
Copy link
Contributor

Looking through the cisco manual, I don't see name-lookup support for BGP. @lelobhz, do you know any routers which support this feature?

I'm also a little confused about the problem here. docker-compose let's you set the IP address of the service using something like:

services:
frr:
cap_add:
- NET_ADMIN
networks:
site1:
ipv4_address: 192.168.1.2

And by defining the network in the file below. Does that solve this issue?

@donaldsharp
Copy link
Member

why not use interface based neighbors

@ajones-rvbd
Copy link
Contributor

ajones-rvbd commented Apr 28, 2018

Currently, interfaces are not correctly ordered in docker. Though there is a patch in the works to fix that.

@ajones-rvbd
Copy link
Contributor

See: moby/libnetwork#2132 for details

@leleobhz
Copy link
Author

Hello @ajones-rvbd

Not a bad idea, although this demand a new network setup. Using networks in composer requires CAP_NET_ADMIN?

I'll try to do this way and return this issue. I think maybe a good idea include this setup in a docker-composer.yml example file too - if it works well.

Thanks!

@ajones-rvbd
Copy link
Contributor

Hi @leleobhz -- NET_ADMIN was left over in the copy+paste which was from a router service, it's not necessary in order to setup the IP address...

I see what you're looking for and it makes sense, I'm still pretty new to routers and they do seem arcane to me at times -- but it also seems like if there is a simple work-around for this one, we should try to use it...

I think of the hand crafted IP addresses in docker compose as a kind of IGP -- and that, from the outside, there will be some sort of ingress translation (similar to: https://kubernetes.io/docs/concepts/services-networking/ingress/) that hopefully doesn't know about these internal addresses and references the services by "name". This is not 100% sorted out yet, though, AFAICT...

@donaldsharp
Copy link
Member

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants