The error “Can’t assign requested address” indicates that the device could not source traffic from the address that was specified.
This is usually caused by forgetting to specify the relevant routing instance or logical system, or by making a typo in the source address. Another cause can be trying to source traffic from an interface that’s status is down.
The error is typically resolved by specifying the appropriate routing instance or outgoing interface.
The examples below are based on the following lab setup.
- 1 vMX router configured with 2 routing instances of type virtual-router
- 1 x link net between the two routing instances
- Each routing instance has a loopback address assigned
- Each routing instance has a static route configured to the other instance’s loopback address.
Forgetting To Specify Routing Instance Or Interface
In the following example, we have not specified the routing instance. The base or default routing instance of the router does not have an address configured that matches the source address, and therefore cannot source the traffic from that address
lab@vMX-1> ping 192.168.0.2 source 192.168.0.1 count 5
ping: bind: Can't assign requested address
lab@vMX-1> This can be fixed by specifying the routing instance or the outgoing interface.
lab@vMX-1> ping 192.168.0.2 source 192.168.0.1 count 5 routing-instance VR-A
PING 192.168.0.2 (192.168.0.2): 56 data bytes
64 bytes from 192.168.0.2: icmp_seq=0 ttl=64 time=2.144 ms
64 bytes from 192.168.0.2: icmp_seq=1 ttl=64 time=1.643 ms
64 bytes from 192.168.0.2: icmp_seq=2 ttl=64 time=1.938 ms
64 bytes from 192.168.0.2: icmp_seq=3 ttl=64 time=1.543 ms
64 bytes from 192.168.0.2: icmp_seq=4 ttl=64 time=1.558 ms
--- 192.168.0.2 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.543/1.765/2.144/0.237 ms
lab@vMX-1> ping 192.168.0.2 source 192.168.0.1 count 5 interface lt-0/0/0.1
PING 192.168.0.2 (192.168.0.2): 56 data bytes
64 bytes from 192.168.0.2: icmp_seq=0 ttl=64 time=30.965 ms
64 bytes from 192.168.0.2: icmp_seq=1 ttl=64 time=1.508 ms
64 bytes from 192.168.0.2: icmp_seq=2 ttl=64 time=1.911 ms
64 bytes from 192.168.0.2: icmp_seq=3 ttl=64 time=1.397 ms
64 bytes from 192.168.0.2: icmp_seq=4 ttl=64 time=1.927 ms
--- 192.168.0.2 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.397/7.542/30.965/11.714 ms
lab@vMX-1>Trying To Source Traffic From The Wrong Address
In this example we make a typo in the source address. Although the router knows what routing instance to use, it still cannot assign an address that is not configured on an interface within the routing instance. In this case, we have tried the source address 192.168.0.10 instead of 192.168.0.1.
lab@vMX-1> ping 192.168.0.2 source 192.168.0.10 count 5 interface lt-0/0/0.1
ping: bind: Can't assign requested address
lab@vMX-1> Trying To Source Traffic From A Down Interface
This example is a little bit contrived, due to the way the lab is set up. First, we show which interfaces are up before sourcing the ping traffic from the logical tunnel (lt) interface in VR-A.
lab@vMX-1> show interfaces terse routing-instance VR-A
Interface Admin Link Proto Local Remote
lt-0/0/0.1 up up inet 172.16.0.1/30
lo0.1 up up inet 192.168.0.1 --> 0/0
lab@vMX-1> ping 192.168.0.2 source 172.16.0.1 count 5 routing-instance VR-A
PING 192.168.0.2 (192.168.0.2): 56 data bytes
64 bytes from 192.168.0.2: icmp_seq=0 ttl=64 time=1.978 ms
64 bytes from 192.168.0.2: icmp_seq=1 ttl=64 time=1.545 ms
64 bytes from 192.168.0.2: icmp_seq=2 ttl=64 time=6.439 ms
64 bytes from 192.168.0.2: icmp_seq=3 ttl=64 time=1.548 ms
64 bytes from 192.168.0.2: icmp_seq=4 ttl=64 time=366.521 ms
--- 192.168.0.2 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.545/75.606/366.521/145.469 ms
lab@vMX-1> Next, we shut that interface down and try the ping again to show the error message.
[edit]
lab@vMX-1# show | compare
[edit interfaces lt-0/0/0 unit 1]
+ disable;
[edit]
lab@vMX-1# commit and-quit
commit complete
Exiting configuration mode
lab@vMX-1> show interfaces terse routing-instance VR-A
Interface Admin Link Proto Local Remote
lt-0/0/0.1 down up inet 172.16.0.1/30
lo0.1 up up inet 192.168.0.1 --> 0/0
lab@vMX-1> ping 192.168.0.2 source 172.16.0.1 count 5 routing-instance VR-A
PING 192.168.0.2 (192.168.0.2): 56 data bytes
ping: sendto: Can't assign requested address
ping: sendto: Can't assign requested address
ping: sendto: Can't assign requested address
ping: sendto: Can't assign requested address
ping: sendto: Can't assign requested address
--- 192.168.0.2 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss
lab@vMX-1>To show the difference between sourcing the ping from the down interface, and an interface that is still up in the same routing instance, we try sourcing the ping from the loopback interface. This time we get no route to host, which is correct since the link net to VR-B is down.
lab@vMX-1> ping 192.168.0.2 source 192.168.0.1 count 5 routing-instance VR-A
PING 192.168.0.2 (192.168.0.2): 56 data bytes
ping: sendto: No route to host
ping: sendto: No route to host
ping: sendto: No route to host
ping: sendto: No route to host
ping: sendto: No route to host
--- 192.168.0.2 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss
lab@vMX-1>Can’t Assign Requested Address Error Seen In Log File
Sometimes the error message “Can’t assign requested address” will be seen in a log file, rather than the output of a CLI command. The core issue remains the same, for whatever reason the device is unable to source traffic from a specific IP address.
The key thing to check is that whatever log or daemon is reporting the issue has been set to use the correct routing instance, and to check the address is assigned to an interface within that instance.
Conclusion
Can’t assign requested address issues are commonly caused by three issues:
- Not adding the correct routing instance and/or logical system reference, or interface
- Not specifying the correct source address
- The interface of the source address is in a down state
If this post was helpful, you may like getting start with Junos.
Configuration
If you would like to try this out yourself, below is the configuration that was used in the examples above. It makes use of a logical tunnel (lt) interface. As long as the device you have supports this type of interface, this config should work. You may need to update the logical tunnel interface numbering to reflect the device you are using. This was tested on a vMX with tunnel-services configured on fpc 0, pic 0.
Note: Before applying, always make sure this won’t impact anything that is already configured. The below should paste in fine with a ‘load merge terminal’. If you are not using an MX or vMX device, the chassis stanza can be ignored.
chassis {
fpc 0 {
pic 0 {
tunnel-services;
}
}
}
interfaces {
lt-0/0/0 {
unit 1 {
encapsulation ethernet;
peer-unit 2;
family inet {
address 172.16.0.1/30;
}
}
unit 2 {
encapsulation ethernet;
peer-unit 1;
family inet {
address 172.16.0.2/30;
}
}
}
lo0 {
unit 1 {
family inet {
address 192.168.0.1/32;
}
}
unit 2 {
family inet {
address 192.168.0.2/32;
}
}
}
}
routing-instances {
VR-A {
routing-options {
static {
route 192.168.0.2/32 next-hop 172.16.0.2;
}
}
instance-type virtual-router;
interface lt-0/0/0.1;
interface lo0.1;
}
VR-B {
routing-options {
static {
route 192.168.0.1/32 next-hop 172.16.0.1;
}
}
instance-type virtual-router;
interface lt-0/0/0.2;
interface lo0.2;
}
}