Junos OS

I have attached the basic network layout that these questions are based upon.

I will receive the full internet routing table on the London and Swindon PEs. Internally I am utilisng ISIS as the IGP. All internal routing is fine and I have an Established eBGP relationship between the PEs and the upstream ISP. The upstream ISPs are separate entities.

I need to achieve the following:

1: If the upstream connection goes down on one of the sites I need the routing to dynamically cross the X-Connects to the opposing site and utilise that route (iBGP is configured between the loopbacks of London PE and Swindon PE and is established).

2: I am assuming, with regards to question 1 that there must be a default route there somewhere, so would the following achive those requirements or is there more configuration required?

set policy-options policy-statement isis-default term ipv4 from protocol static
set policy-options policy-statement isis-default term ipv4 from route-filter 0.0.0.0/0 exact
set policy-options policy-statement isis-default term ipv4 then accept

set protocols bgp group external-peers export isis-default

Or a little advice on the best way to achieve this.

Apologies for asking, I have configured this a few years ago but cannot find my notes and am brushing up on forgotten configurations.

Thanks

Hi adgwytc,

There is a good configuration example on juniper website on how to achieve this.

https://www.juniper.net/documentation/en_US/junos/topics/example/policy-default-static-route.html

You can tweak the policy to match your condition but the idea remains the same

Please let me know if you have further query.

PS: Please accept my response as solution if it answers your query, kudos are appreciated too!

Thanks

Vishal

Hi Vishal,

Thank you for the quick response.

So, if I take the London site as the first example, the following configuration would do the trick:

set protocols bgp group external-peers type external
set protocols bgp group external-peers local-address 192.168.1.252 (lo0)
set protocols bgp group external-peers log-updown
set protocols bgp group external-peers family inet unicast
set protocols bgp group external-peers authentication-key-chain bgp-auth
set protocols bgp group external-peers export bgp-aggr (aggregated advertised routes)
set protocols bgp group external-peers export isis-default
set protocols bgp group external-peers peer-as 50094
set protocols bgp group external-peers neighbor 192.168.1.246 multihop ttl 1 (Upstream lo0)

set protocols isis export bgp-isis
set protocols isis export isis-default

set policy-options policy-statement isis-default term ipv4 from protocol static
set policy-options policy-statement isis-default term ipv4 from route-filter 0.0.0.0/0 exact
set policy-options policy-statement isis-default term ipv4 then accept

set policy-options policy-statement bgp-isis from protocol bgp
set policy-options policy-statement bgp-isis from prefix-list bgp-isis
set policy-options policy-statement bgp-isis then accept

It looks to me like the "discard" statement should be on the actual upstream ISP PE router.

So, does this configuration mean that if I lose the link to the London upstream ISP that the route will failover to the Swindon upstream ISP?

Hello,

---

@adgwytc wrote:

 

I will receive the full internet routing table on the London and Swindon PEs.

 

---

---

@adgwytc wrote:

there must be a default route there somewhere

 

---

If You ask Your providers to send You a default route together with full table, Your design would be so  much simpler.

There is no technical reason for Your providers NOT to do this, other Juniper UK customers I am aware of already using such setup.

HTH

Thx

Alex

Hi Alex,

Thanks for the response.

Let me try and explain a little better (taking note of the diagram I attached).

Upstream ISP at London - GTT (Example)

Upstream ISP at Swindon - Cogent (Example)

I have a subscriber, whether that be DSL from the CPE end or an Ethernet subscriber attached to the Core. Let's use London side as the example:

They use the London upstream ISP for the link to the outside World on port ge-0/0/3. They do not use Swindon upstream ISP.

If, for some reason, the connection on port ge-0/0/3 goes down, the route needs to then go over the X-Connects between the two sites and exit via the Swindon upstream ISP, but that should only occur if the ge-0/0/3 link fails on the London side.

I configured this before a couple of years ago and all worked fine, but I am stumped as to how I achieved this apart from configuring the iBGP between the two core routers (which I have already completed) and injecting default routes (as I have not done this again since, and as they say "If you don't use it, you lose it, so I am brushing up before booking my JNCIE-SP).

This is the only section that I just cannot remember how I achieved the results. I know there is a default route on the LNS pointing towards the Core, but there is something missing that will allow the transition if the ge-0/0/3 link fails.

I guess, from an eBGP perspective, if that link fails then somewhere upstream there will need to be a re-calibration of eBGP to show that reaching the subscribers on the London side has to then go via the Swindon core and from there to the London core and the LNS/Ethernet subscribers.

Hopefully that explains it a little better.

Hello,

---

@adgwytc wrote:

 

I have a subscriber, whether that be DSL from the CPE end or an Ethernet subscriber attached to the Core. Let's use London side as the example:

 

They use the London upstream ISP for the link to the outside World on port ge-0/0/3. They do not use Swindon upstream ISP..

---

According to Your diagram, for OUTBOUND-from-Your ASN trafic this is only possible if a specific route to the destination on Lnd-core-pe is always preferred.

This can only happen if provider sends full tables to Lnd-core-pe and Swi-core-pe, and You don't exchange full tables over iBGP between these 2 routers. Otherwise the shortest AS_PATH would win and Your sub attached to Lnd-core-pe COULD use Swi-core-pe for upload-to-internet traffic.

For INBOUND-to-Your-ASN traffic, this is more difficult to achieve - You need to do some deaggregation and/or prepending, but I guess this is not Your top concern at the moment.

---

@adgwytc wrote:

 

If, for some reason, the connection on port ge-0/0/3 goes down, the route needs to then go over the X-Connects between the two sites and exit via the Swindon upstream ISP, but that should only occur if the ge-0/0/3 link fails on the London side.

 

---

This is quite easy to achieve if :

1/ provider sends You 0/0 + ::/0 together with full tables and

2/ Lnd-core-pe and Swi-core-pe exchange _ONLY_ 0/0 and ::/0 via iBGP between themselves

---

@adgwytc wrote:

I know there is a default route on the LNS pointing towards the Core, but there is something missing that will allow the transition if the ge-0/0/3 link fails.

 

Again, this is quite easy to achieve if:

1/ provider sends You 0/0 + ::/0 together with full tables and

2/ Lnd-core-pe and Swi-core-pe send _ONLY_ 0/0 and ::/0 via iBGP to LNSes ; OR

3/ Lnd-core-pe and Swi-core-pe export _ONLY_ 0/0 and ::/0 into ISIS - I would not recommend this though, iBGP is the best option

---

@adgwytc wrote:

 

I guess, from an eBGP perspective, if that link fails then somewhere upstream there will need to be a re-calibration of eBGP to show that reaching the subscribers on the London side has to then go via the Swindon core and from there to the London core and the LNS/Ethernet subscribers.

 

If the Lnd-core-pe' ge-0/0/3 link fails then Your subnet advertisements from Lnd-core-pe will be invalidated on provider side and provider will withdraw them from wider Internet. Your  subnet advertisements from Swi-core-pe will be the only ones remaining on the wider Internet.

HTH

Thx

Alex

Hi Alex,

I'm getting there. I have one weird resolution I am trying to cure now and then I think it is resolved. Here is the final issue and current topology:

Dummy node --> Upstream ISP test --> London core (one side)

Dummy node --> Upstream ISP test --> Swindon core (other side)

The two Core systems are connecte via ae0 as shown below:

London-Core (ae0) --> (ae0) Swindon-Core

And then the rest of the topology is shown above that.

I have configured an lo0 interface on each dummy node to simulate the internet IPv4 BGP routing table advertised into the core.

Here is the problem, with both core systems configured the same (remembering I will be receiving the same routing table from different upstream ISPs). The loopback interface pn both systems is configured with 10.10.10.1/32 and advertised into our core.

Here is the output from the "show route 10.10.10.1 from both Core's:

London-Core:

root@london-core-mx# run show route 10.10.10.1

inet.0: 15 destinations, 16 routes (14 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both

10.10.10.0/24 *[BGP/170] 01:25:40, localpref 100, from 192.168.1.246
AS path: 50094 I, validation-state: unverified
> to 192.168.1.30 via ge-0/0/3.0

This is correct. I should only see it available from here and not via the Swindon core.

Now here is the Swindon core:

root@swindon-core-mx# run show route 10.10.10.1

inet.0: 14 destinations, 16 routes (13 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both

10.10.10.0/24 *[IS-IS/160] 01:13:07, metric 20
> to 192.168.1.5 via ae0.0
[BGP/170] 00:48:29, localpref 100, from 192.168.1.242
AS path: 50060 I, validation-state: unverified
> to 192.168.1.58 via ge-0/0/2.0

This is incorrect as I am also seeing 10.10.10.1 via isis through ae0 and to the other ISP.

The config on both systems is very basic and the same, so I cannot tell where the issue is:

London Core:

set security authentication-key-chains key-chain bgp-auth key 0 secret "$9$q.T36/tOIcCtxds4DjCtu0BE"
set security authentication-key-chains key-chain bgp-auth key 0 start-time "2020-3-22.14:00:00 +0000"
set interfaces ge-0/0/0 unit 0 description london-lns-mx
set interfaces ge-0/0/0 unit 0 family inet address 192.168.1.2/30
set interfaces ge-0/0/0 unit 0 family iso
set interfaces ge-0/0/1 description group-ae0
set interfaces ge-0/0/1 gigether-options 802.3ad ae0
set interfaces ge-0/0/2 unit 0 description to-london-srx-ng
set interfaces ge-0/0/2 unit 0 family inet address 192.168.1.22/30
set interfaces ge-0/0/2 unit 0 family iso
set interfaces ge-0/0/3 unit 0 family inet address 192.168.1.29/30
set interfaces ge-0/0/4 description group-ae0
set interfaces ge-0/0/4 gigether-options 802.3ad ae0
set interfaces ae0 unit 0 description to-swindon-core
set interfaces ae0 unit 0 family inet address 192.168.1.5/30
set interfaces ae0 unit 0 family iso
set interfaces lo0 unit 0 family inet address 192.168.1.252/32
set interfaces lo0 unit 0 family iso address 49.0001.1921.6801.0252.00
set routing-options static route 192.168.1.246/32 next-hop 192.168.1.30
set routing-options static route 0.0.0.0/0 next-hop 192.168.1.6
set routing-options aggregate route 172.16.0.0/16
set routing-options autonomous-system 40099
set protocols bgp group external-peers type external
set protocols bgp group external-peers local-address 192.168.1.252
set protocols bgp group external-peers log-updown
set protocols bgp group external-peers family inet unicast
set protocols bgp group external-peers authentication-key-chain bgp-auth
set protocols bgp group external-peers export export-route
set protocols bgp group external-peers peer-as 50094
set protocols bgp group external-peers neighbor 192.168.1.246 multihop ttl 1
set protocols bgp group internal-peers type internal
set protocols bgp group internal-peers local-address 192.168.1.252
set protocols bgp group internal-peers export ebgp-default-route
set protocols bgp group internal-peers peer-as 40099
set protocols bgp group internal-peers neighbor 192.168.1.253
set protocols isis export isis-default
set protocols isis export bgp-isis
set protocols isis level 1 authentication-key "$9$QzElz/tu0IcrvBIwgJDmPBIEhSe"
set protocols isis level 1 authentication-type md5
set protocols isis level 2 authentication-key "$9$e7ZKLNdVYoZjwYF/tOcSwYg4aU"
set protocols isis level 2 authentication-type md5
set protocols isis interface ge-0/0/0.0
set protocols isis interface ge-0/0/2.0
set protocols isis interface ae0.0
set protocols isis interface lo0.0
set policy-options prefix-list default 0.0.0.0/0
set policy-options policy-statement bgp-isis from protocol bgp
set policy-options policy-statement bgp-isis then accept
set policy-options policy-statement deny-all then reject
set policy-options policy-statement ebgp-default-route term 1 from route-filter 0.0.0.0/0 exact
set policy-options policy-statement ebgp-default-route term 1 then next-hop self
set policy-options policy-statement ebgp-default-route term 1 then accept
set policy-options policy-statement ebgp-default-route term reject then reject
set policy-options policy-statement export-route from protocol aggregate
set policy-options policy-statement export-route then accept
set policy-options policy-statement isis-default term ipv4 from protocol static
set policy-options policy-statement isis-default term ipv4 from route-filter 0.0.0.0/0 exact
set policy-options policy-statement isis-default term ipv4 then accept

Swindon Core:

set security authentication-key-chains key-chain bgp-auth key 0 secret "$9$/cVN9u1REyKWxcyoGi.zFcylevL"
set security authentication-key-chains key-chain bgp-auth key 0 start-time "2020-3-22.14:00:00 +0000"
set interfaces ge-0/0/0 unit 0 description to-swindon-lns
set interfaces ge-0/0/0 unit 0 family inet address 192.168.1.9/30
set interfaces ge-0/0/0 unit 0 family iso
set interfaces ge-0/0/1 description group-ae0
set interfaces ge-0/0/1 gigether-options 802.3ad ae0
set interfaces ge-0/0/2 unit 0 description to-internet-cloud-1-mx
set interfaces ge-0/0/2 unit 0 family inet address 192.168.1.57/30
set interfaces ge-0/0/4 description group-ae0
set interfaces ge-0/0/4 gigether-options 802.3ad ae0
set interfaces ae0 unit 0 description to-london-core
set interfaces ae0 unit 0 family inet address 192.168.1.6/30
set interfaces ae0 unit 0 family iso
set interfaces lo0 unit 0 family inet address 192.168.1.253/32
set interfaces lo0 unit 0 family iso address 49.0001.1921.6801.0253.00
set routing-options static route 192.168.1.242/32 next-hop 192.168.1.58
set routing-options static route 0.0.0.0/0 next-hop 192.168.1.5
set routing-options aggregate route 172.16.0.0/16
set routing-options autonomous-system 40099
set protocols bgp group internal-peers type internal
set protocols bgp group internal-peers local-address 192.168.1.253
set protocols bgp group internal-peers export ebgp-default-route
set protocols bgp group internal-peers peer-as 40099
set protocols bgp group internal-peers neighbor 192.168.1.252
set protocols bgp group external-peers type external
set protocols bgp group external-peers local-address 192.168.1.253
set protocols bgp group external-peers log-updown
set protocols bgp group external-peers family inet unicast
set protocols bgp group external-peers authentication-key-chain bgp-auth
set protocols bgp group external-peers export export-route
set protocols bgp group external-peers peer-as 50060
set protocols bgp group external-peers neighbor 192.168.1.242 multihop ttl 1
set protocols isis export isis-default
set protocols isis export bgp-isis
set protocols isis level 1 authentication-key "$9$z0NdF9p0ORSlM1Rs4ZjPf1RhcyK"
set protocols isis level 1 authentication-type md5
set protocols isis level 2 authentication-key "$9$B0b1clKvLNVYWLHmT3tpWLx7-w"
set protocols isis level 2 authentication-type md5
set protocols isis interface ge-0/0/0.0
set protocols isis interface ge-0/0/2.0
set protocols isis interface ae0.0
set protocols isis interface lo0.0
set policy-options prefix-list default 0.0.0.0/0
set policy-options policy-statement bgp-isis from protocol bgp
set policy-options policy-statement bgp-isis then accept
set policy-options policy-statement deny-all then reject
set policy-options policy-statement ebgp-default-route term 1 from route-filter 0.0.0.0/0 exact
set policy-options policy-statement ebgp-default-route term 1 then next-hop self
set policy-options policy-statement ebgp-default-route term 1 then accept
set policy-options policy-statement ebgp-default-route term reject then reject
set policy-options policy-statement export-route from protocol aggregate
set policy-options policy-statement export-route then accept
set policy-options policy-statement isis-default term ipv4 from protocol static
set policy-options policy-statement isis-default term ipv4 from route-filter 0.0.0.0/0 exact
set policy-options policy-statement isis-default term ipv4 then accept

Any ideas why one side works as should and the other does not?

I cannot start the disconnetion of ports to test the failover until I have resolved this issue.

Thanks

Hello,

---

@adgwytc wrote:

set protocols isis export bgp-isis

set policy-options policy-statement bgp-isis from protocol bgp
set policy-options policy-statement bgp-isis then accept

Well, according to the above config, You are injecting FULL BGP TABLE into ISIS.

Please PLEASE never EVER do it. Period. 

As for explanation "why it works on one router and not on another" - remember that JUNOS exports only active route. So, the 1st router where the above config is committed, exports 10.10.10.0/24 into ISIS. The 2nd router sees than 10.10.10.0/24 comes from ISIS and makes previously-active BGP route 10.10.10.0/24 inactive, so it is not exported into ISIS on this 2nd router.

HTH

Thx

Alex 

Hi Alex,

Thanks for the response.

Seems strange that the full BGP routing table is not seen any further than the PE (Core in this case) with that policy. I can remove the policy and see what happens.

I also understand the routing action but that does not explain, when the exact same config is on both systems why one side sees it only in BGP (Which is exactly what should happen) but the other sees it in ISIS and BGP? Surely you would get the same result both sides?

Let me remove the policy and see what the results are. Will get back to you... thanks again.

Hi Alex,

Now I can see the workings a little better. So, here is the result if I remove that policy from both systems:

London-Core:

root@london-core-mx# run show route 10.10.10.1

inet.0: 15 destinations, 16 routes (14 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both

10.10.10.0/24 *[BGP/170] 02:50:43, localpref 100, from 192.168.1.246
AS path: 50094 I, validation-state: unverified
> to 192.168.1.30 via ge-0/0/3.0

[edit]
root@london-core-mx# run ping 10.10.10.1
PING 10.10.10.1 (10.10.10.1): 56 data bytes
64 bytes from 10.10.10.1: icmp_seq=0 ttl=63 time=6.330 ms
64 bytes from 10.10.10.1: icmp_seq=1 ttl=63 time=3.635 ms
64 bytes from 10.10.10.1: icmp_seq=2 ttl=63 time=5.122 ms

This is correct:

Swindon-Core:

root@swindon-core-mx# run show route 10.10.10.1

inet.0: 14 destinations, 15 routes (13 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both

10.10.10.0/24 *[BGP/170] 02:25:58, localpref 100, from 192.168.1.242
AS path: 50060 I, validation-state: unverified
> to 192.168.1.58 via ge-0/0/2.0

[edit]
root@swindon-core-mx# run ping 10.10.10.1
PING 10.10.10.1 (10.10.10.1): 56 data bytes
64 bytes from 10.10.10.1: icmp_seq=0 ttl=63 time=128.100 ms
64 bytes from 10.10.10.1: icmp_seq=1 ttl=63 time=27.703 ms

This is also now correct.

Awesome, thanks. However, I won't close it just yet as I now need to see if the route flips across the X-Connect if I disable an upstream port. Will update again.

Hi Alex,

So, just need to overcome the last part and all is good  🙂

When I turn off the London-Upstream-ISP connectivity, the route for 10.10.10.1 flips over and I have the following in the routing table:

[edit]
root@london-core-mx# run show route 10.10.10.1

inet.0: 14 destinations, 15 routes (13 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0 *[Static/5] 2d 23:41:59
> to 192.168.1.6 via ae0.0
[BGP/170] 18:15:34, localpref 100, from 192.168.1.253
AS path: I, validation-state: unverified
> to 192.168.1.6 via ae0.0

[edit]

root@london-core-mx# run ping 10.10.10.1
PING 10.10.10.1 (10.10.10.1): 56 data bytes

So the route to 10.10.10.1 is now showing as via ae0, which is exactly what should happen, but I cannot ping the said address from either Swindon-Core or London-Core having removed the policy suggested.

A default route is being injected, as it must be, but without the other policy nothing is pinging anymore (even though the routes are showing okay).

Here is the upstream-internet-cloud configuration that is attached by ge-0/0/2 to the Swindon-Core router:

Upstream ISP:

set security authentication-key-chains key-chain bgp-auth key 0 secret "$9$h8UceWLX-w2a7-PQnCB17-Vbs4"
set security authentication-key-chains key-chain bgp-auth key 0 start-time "2020-3-22.14:00:00 +0000"
set interfaces ge-0/0/0 unit 0 description to-swindon-dummy-system
set interfaces ge-0/0/0 unit 0 family inet address 172.16.16.5/30
set interfaces ge-0/0/2 unit 0 description to-swindon-core-mx
set interfaces ge-0/0/2 unit 0 family inet address 192.168.1.58/30
set interfaces lo0 unit 0 family inet address 192.168.1.242/32
set routing-options static route 192.168.1.253/32 next-hop 192.168.1.57
set routing-options static route 10.10.10.1/32 next-hop 172.16.16.6
set routing-options static route 0.0.0.0/0 next-hop 192.168.1.57
set routing-options aggregate route 10.10.10.0/24
set routing-options autonomous-system 50060
set protocols bgp group external-isp-peers type external
set protocols bgp group external-isp-peers local-address 192.168.1.242
set protocols bgp group external-isp-peers log-updown
set protocols bgp group external-isp-peers family inet unicast
set protocols bgp group external-isp-peers authentication-key-chain bgp-auth
---(backing up)---
set version 18.2R1.9
set system root-authentication encrypted-password "$6$LZdpAJMv$nU9CwHBuRnQXny1pkBxnUJdknH2PcVOi8t2WubsnMSS5uMMW7LgnT/LFIhnStcyrUBgKMhwVFCMFiZb/Po0ZI1"
set system host-name internet-cloud-1-mx
set security authentication-key-chains key-chain bgp-auth key 0 secret "$9$h8UceWLX-w2a7-PQnCB17-Vbs4"
set security authentication-key-chains key-chain bgp-auth key 0 start-time "2020-3-22.14:00:00 +0000"
set interfaces ge-0/0/0 unit 0 description to-swindon-dummy-system
set interfaces ge-0/0/0 unit 0 family inet address 172.16.16.5/30
set interfaces ge-0/0/2 unit 0 description to-swindon-core-mx
set interfaces ge-0/0/2 unit 0 family inet address 192.168.1.58/30
set interfaces lo0 unit 0 family inet address 192.168.1.242/32
set routing-options static route 192.168.1.253/32 next-hop 192.168.1.57
set routing-options static route 10.10.10.1/32 next-hop 172.16.16.6
set routing-options static route 0.0.0.0/0 next-hop 192.168.1.57
set routing-options aggregate route 10.10.10.0/24
set routing-options autonomous-system 50060
set protocols bgp group external-isp-peers type external
set protocols bgp group external-isp-peers local-address 192.168.1.242
set protocols bgp group external-isp-peers log-updown
set protocols bgp group external-isp-peers family inet unicast
set protocols bgp group external-isp-peers authentication-key-chain bgp-auth
set protocols bgp group external-isp-peers export export-route
set protocols bgp group external-isp-peers peer-as 40099
set protocols bgp group external-isp-peers neighbor 192.168.1.253 multihop ttl 1
set policy-options policy-statement ebgp-default-route term 1 from route-filter 0.0.0.0/0 exact
set policy-options policy-statement ebgp-default-route term 1 then next-hop self
set policy-options policy-statement ebgp-default-route term 1 then accept
set policy-options policy-statement ebgp-default-route term reject then reject
set policy-options policy-statement export-route from protocol aggregate
set policy-options policy-statement export-route then accept
set policy-options policy-statement isis-default term ipv4 from protocol static
set policy-options policy-statement isis-default term ipv4 from route-filter 0.0.0.0/0 exact
set policy-options policy-statement isis-default term ipv4 then accept

Cheers

Hello,

---

@adgwytc wrote:

 

root@london-core-mx# run ping 10.10.10.1
PING 10.10.10.1 (10.10.10.1): 56 data bytes

 

So the route to 10.10.10.1 is now showing as via ae0, which is exactly what should happen, but I cannot ping the said address from either Swindon-Core or London-Core having removed the policy suggested.

 

This is most likely due to the fact that You are NOT explicitly choosing the source-address for this ping and JUNOS picks this source address as the IP of outgoing interface which would be AE0.

If You are not advertising AE0 subnet out to eBGP peers then You'd get no reply.

Please ping again with explicit "source-address" knob picking the IP that (a) exists on London-core and (b) is from the CIDR block that is advertised out to eBGP peers.

HTH

Thx
Alex

Hi Alex,

Thanks. I have discovered where the issue may be, and it is a very starnge one:

Using "eve-ng" and connectivity between the upstream-ISP and the Dummy-Node is as follows:

upstream-isp ge-0/0/0 (172.16.16.5/30)  <--> (172.16.16.6/30) ge-0/0/0 Dummy-Node

Weird results as shown below:

root@internet-cloud-1-mx# run show route 172.16.16.6

inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

172.16.16.4/30 *[Direct/0] 20:56:48
> via ge-0/0/0.0

This is correct.

Dummy-Node:

set interfaces ge-0/0/0 unit 0 description to-swindon-internet-cloud-1
set interfaces ge-0/0/0 unit 0 family inet address 172.16.16.6/30
set interfaces lo0 unit 0 family inet address 10.10.10.1/32
set routing-options static route 0.0.0.0/0 next-hop 172.16.16.5

root@swindon-dummy-system# run show route 172.16.16.5

Nothing. Directly connected yet shows no route to the upstream-ISP...

How strange. No wonder it doesn't work  🙂

No route in the inet.0 table for a directly connected interface.

Need to work that one out  🙂

Seems all the ge interfaces have disappeared. It's a simple configuration so will remove the node from eve-ng and re-apply

Hi Alex,

Seems like eve-ng messed up. I removed the dummy-system completely, setup a new one and configured and everything works as should. See below for the correct results from the London-core:

root@london-core-mx# run show route 10.10.10.1

inet.0: 17 destinations, 18 routes (16 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0 *[Static/5] 3d 02:20:17
> to 192.168.1.6 via ae0.0
[BGP/170] 20:53:52, localpref 100, from 192.168.1.253
AS path: I, validation-state: unverified
> to 192.168.1.6 via ae0.0

root@london-core-mx# run ping 10.10.10.1
PING 10.10.10.1 (10.10.10.1): 56 data bytes
64 bytes from 10.10.10.1: icmp_seq=0 ttl=62 time=5.551 ms
64 bytes from 10.10.10.1: icmp_seq=1 ttl=62 time=794.376 ms
64 bytes from 10.10.10.1: icmp_seq=2 ttl=62 time=461.443 ms
64 bytes from 10.10.10.1: icmp_seq=3 ttl=62 time=63.383 ms

So the issue was not with the config but with eve-ng.

Thanks for the help.