Would the preferred-source-address statement work in your situation? >From the link Madood posted: interfaces { lo0 { unit 0 { family inet { address 2.2.2.1/32; address 3.3.3.1/32; } } } } interfaces { ge-4/0/0 { unit 0 { family inet {unnumbered-address lo0.0 preferred-source-address 3.3.3.1; } } } } On 11 Jan 2015 07:06, "Mihai" <mihaigabr...@gmail.com> wrote:
> Thank you for your response.If the document is true,then all ARPs should > be originated with the primary address and as you can see this is not the > case (tested on multiple platforms with different codes,Cisco included). > One workaround i found is to delete/add the static route,but it doesn't > work in all cases. > > > On 01/11/2015 02:13 AM, Masood Ahmad Shah wrote: > >> AFAIK, router uses the preferred source address when it is configured >> for an unnumbered Eth interface, for arp requests and replies. arp >> requests need to match the preferred source address, which is by default >> primary interfaces >> >> lo0 { >> unit 55 { >> family inet { >> address 5.5.5.5/32 <http://5.5.5.5/32> { //That >> would be this in your case. >> primary; >> } >> address 10.10.10.1/24 <http://10.10.10.1/24>; >> address 20.20.20.1/24 <http://20.20.20.1/24>; >> } >> } >> } >> >> More here: >> http://www.juniper.net/documentation/en_US/junos13.2/ >> topics/usage-guidelines/interfaces-configuring-an- >> unnumbered-interface.html >> >> Cheers, >> Masood >> >> On Sun, Jan 11, 2015 at 2:34 AM, Mihai <mihaigabr...@gmail.com >> <mailto:mihaigabr...@gmail.com>> wrote: >> >> Hello, >> >> After the migration of a large network from a Cisco 7600 to a >> MX104 a lot of users started to have random problems with their >> connection. >> The setup is based on unnumbered interfaces and /32 static routes >> through IFLs. >> Basically, all clients with Cisco routers will have at some point a >> missing ARP entry for their default gateway because the MX is >> changing the ARP source address from the gw_addr to the primary >> address.On Cisco i see the well known 'wrong cable' error. >> Does anyone have a clue why is this happening beside a bug? I've >> made some tests on MX960,MX480 and MX5 and didn't see this behavior. >> This is a lab simulation: >> >> >> mx# show >> >> interfaces { >> ge-1/1/8 { >> unit 55 { >> vlan-id 55; >> proxy-arp unrestricted; >> family inet { >> unnumbered-address lo0.55; >> } >> } >> unit 56 { >> vlan-id 56; >> proxy-arp unrestricted; >> family inet { >> unnumbered-address lo0.55; >> } >> } >> } >> lo0 { >> unit 55 { >> family inet { >> address 5.5.5.5/32 <http://5.5.5.5/32> { >> primary; >> } >> address 10.10.10.1/24 <http://10.10.10.1/24>; >> address 20.20.20.1/24 <http://20.20.20.1/24>; >> } >> } >> } >> } >> routing-options { >> static { >> route 20.20.20.2/32 <http://20.20.20.2/32> { >> qualified-next-hop ge-1/1/8.55; >> } >> route 10.10.10.2/32 <http://10.10.10.2/32> { >> qualified-next-hop ge-1/1/8.56; >> } >> } >> router-id 5.5.5.5; >> } >> >> mx> monitor traffic interface ge-1/1/8.55 detail no-resolve matching >> arp >> Address resolution is OFF. >> Listening on ge-1/1/8.55, capture size 1514 bytes >> >> 17:28:11.105586 Out arp who-has 20.20.20.2 tell 20.20.20.1 >> 17:28:11.106100 In arp reply 20.20.20.2 is-at 00:1e:4a:fc:44:84 >> 17:29:20.504891 Out arp who-has 20.20.20.2 tell 20.20.20.1 >> 17:29:20.505375 In arp reply 20.20.20.2 is-at 00:1e:4a:fc:44:84 >> 17:30:30.104188 Out arp who-has 20.20.20.2 tell 20.20.20.1 >> 17:30:30.104632 In arp reply 20.20.20.2 is-at 00:1e:4a:fc:44:84 >> >> ..... >> >> 17:53:01.790690 Out arp who-has 20.20.20.2 tell 5.5.5.5 >> 17:54:05.690056 Out arp who-has 20.20.20.2 tell 5.5.5.5 >> >> Thanks! >> _________________________________________________ >> juniper-nsp mailing list juniper-nsp@puck.nether.net >> <mailto:juniper-nsp@puck.nether.net> >> https://puck.nether.net/__mailman/listinfo/juniper-nsp >> <https://puck.nether.net/mailman/listinfo/juniper-nsp> >> >> >> _______________________________________________ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp