Junos OS

Expand all | Collapse all

Failover within BGP/ISIS Environment

Jump to Best Answer
  • 1.  Failover within BGP/ISIS Environment

     
    Posted 04-10-2020 08:13
      |   view attached

    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

     



  • 2.  RE: Failover within BGP/ISIS Environment

     
    Posted 04-10-2020 09:34

    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



  • 3.  RE: Failover within BGP/ISIS Environment

     
    Posted 04-10-2020 10:27

    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?



  • 4.  RE: Failover within BGP/ISIS Environment

    Posted 04-10-2020 22:41

    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



  • 5.  RE: Failover within BGP/ISIS Environment

     
    Posted 04-11-2020 00:41

    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.



  • 6.  RE: Failover within BGP/ISIS Environment

    Posted 04-11-2020 06:30

    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



  • 7.  RE: Failover within BGP/ISIS Environment

     
    Posted 04-19-2020 07:09

    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



  • 8.  RE: Failover within BGP/ISIS Environment
    Best Answer

    Posted 04-19-2020 08:23

    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 



  • 9.  RE: Failover within BGP/ISIS Environment

     
    Posted 04-19-2020 08:28

    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.

     



  • 10.  RE: Failover within BGP/ISIS Environment

     
    Posted 04-19-2020 08:34

    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.

     



  • 11.  RE: Failover within BGP/ISIS Environment

     
    Posted 04-20-2020 00:40

    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



  • 12.  RE: Failover within BGP/ISIS Environment

    Posted 04-20-2020 01:34

    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



  • 13.  RE: Failover within BGP/ISIS Environment

     
    Posted 04-20-2020 02:48

    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

     



  • 14.  RE: Failover within BGP/ISIS Environment

     
    Posted 04-20-2020 03:12

    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.