Routing

Hi All

 

My router MX240 connect to another MX240 via submarine cable and 2 GRE over two upstream provider.

 

 

The information as follow is routing table . xe-1/3/2.1 is 10G of submarine cable , and gr-1/1/0.3 is GRE over upstream provider(ISP1).

But I have another GRE over upstream provider(ISP2) , it's interface is gr-2/3/0.2.

 

My question is how to let gr-2/3/0.2 have higher priority than gr-1/1/0.3 both on protocol LDP & OSPF ?

Althought I set gr-1/1/0.3 as higher metric on OSPF , but the backup path is still gr-1/1/0.3, not gr-2/3/0.2.

LDP seems have no way to controll.

 

192.168.145.2/32   *[LDP/9] 23:01:02, metric 10

                               > to 192.168.147.34 via xe-1/3/2.1, Push 313776

                                  via gr-1/1/0.3

                                [OSPF/10] 23:01:02, metric 10

                               > to 192.168.147.34 via xe-1/3/2.1

                                  via gr-1/1/0.3

 

>show configuration protocols ldp

track-igp-metric;

interface gr-1/1/0.3;

interface xe-1/2/2.1 {

    link-protection;

}

interface xe-1/3/2.1 {

    link-protection;

}

interface gr-2/3/0.2;

 

> show configuration protocols ospf

traffic-engineering;

area 0.0.0.0 {

    interface xe-1/3/2.1 {

        interface-type p2p;

        link-protection;

        metric 5;

        bfd-liveness-detection {

            minimum-interval 100;

        }

    }

    interface gr-2/3/0.2 {

        interface-type p2p;

        metric 25;

        bfd-liveness-detection {

            minimum-interval 100;

        }

    }

    interface gr-1/1/0.3 {

        interface-type p2p;

        metric 100;

        bfd-liveness-detection {

            minimum-interval 100;

        }

     }

}

#LDPMetric
#OSPFMetric

Can you please explain this?

My question is how to let gr-2/3/0.2 have higher priority than gr-1/1/0.3 both on protocol LDP & OSPF ?
Althought I set gr-1/1/0.3 as higher metric on OSPF , but the backup path is still gr-1/1/0.3, not gr-2/3/0.2.

Do you want to use gr-2/3/0.2 as a primary and gr-1/1/0.3 as a secondary?

Also, could you confirm if both tunnels are using xe-1/3/2.1 as a source?

Hi

For first question , not all.
I hope xe-1/3/2.1 is primary, gr-2/3/0.2 is second and gr-1/1/0.3 is thirth.

For second question, both tunnel source IP are not on xe-1/3/2.1.
Their source IP are different interface what connect to global upstream provider.

BTW, xe-1/3/2.1 is connected to other router directly via submarine cable as point to point.

Thanks for your reply.

Can you share your configuration?

I understand you can't share the configuraiton as you mention so forgive me if this is obvious stuff you have already checked.

 

Since you are using OSPF with LDP, I assume you have RSVP signaling for the sessions and OSPF traffic engineering is turned on.  Your path selection will be limited by two additional factors in addition to the standard OSPF cost.

 

EROs or explict hops that get configured on the LSP associated with the LDP session.

 

CSPF calculations on all the available paths unless you have turned CSPF off on the LSP or globally.

 

Hi Spuluka

 

Thanks for reply . 

 

My question is still on why OSPF select gr-1/1/0.1 as backup , not gr-2/3/0.2 , even I set gr-1/1/0.1 as higher metric . Should we have any command to show why OSPF select it as backup ?

 

As follow is my configuration.

> show configuration interfaces gr-2/3/0.2
tunnel {
source 122.255.91.14;
destination 116.51.28.146;
}
family inet {
mtu 8800;
address 192.168.145.41/30;
}
family mpls {
mtu 8800;
}

 

> show configuration interfaces gr-1/1/0.1
tunnel {
source 63.222.40.198;
destination 63.216.143.194;
}
family inet {
mtu 1476;
tcp-mss 1436;
address 192.168.147.42/30;
}
family mpls {
mtu 1476;
}

 

> show configuration protocols ospf
traffic-engineering;

interface gr-2/3/0.2 {
interface-type p2p;
metric 25;
bfd-liveness-detection {
minimum-interval 100;
}

interface gr-1/1/0.1 {
interface-type p2p;
metric 100;
bfd-liveness-detection {
minimum-interval 100;
}

> show configuration protocols ldp

track-igp-metric;

interface gr-1/1/0.3;

interface gr-2/3/0.2;

session-protection;

 

> show ospf neighbor

Address          Interface              State     ID               Pri  Dead

192.168.145.49   gr-1/1/0.3             Full      192.168.145.2    128    38

192.168.145.42   gr-2/3/0.2             Full      192.168.145.2    128    34

 

> show ospf backup neighbor

192.168.145.2 via: Direct

  Neighbor to Self Metric: 10

  Self to Neighbor Metric: 10

  Direct next-hop: gr-1/1/0.3

  Direct next-hop: gr-2/3/0.2

 

> show route 192.168.145.2

inet.0: 669031 destinations, 3902164 routes (668778 active, 9 holddown, 314 hidden)
+ = Active Route, - = Last Active, * = Both

192.168.145.2/32 *[LDP/9] 3d 17:19:35, metric 10
> to 1192.168.147.34 via xe-1/3/2.1, Push 313776
via gr-1/1/0.3
[OSPF/10] 3d 17:19:35, metric 10
> to 192.168.147.34 via xe-1/3/2.1
via gr-1/1/0.3

 

> show ospf interface gr-2/3/0.2 extensive
Interface State Area DR ID BDR ID Nbrs
gr-2/3/0.2 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
Type: P2P, Address: 0.0.0.0, Mask: 0.0.0.0, MTU: 8800, Cost: 25
Adj count: 1
Hello: 10, Dead: 40, ReXmit: 5, Not Stub
Auth type: None
Protection type: None
Topology default (ID 0) -> Cost: 25
gr-2/3/0.2 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 0
Type: P2P, Address: 103.198.145.41, Mask: 255.255.255.252, MTU: 8800, Cost: 25
Adj count: 0, Passive
Hello: 10, Dead: 40, ReXmit: 5, Not Stub
Auth type: None
Protection type: None
Topology default (ID 0) -> Passive, Cost: 25

> show ospf interface gr-1/1/0.3 detail
Interface State Area DR ID BDR ID Nbrs
gr-1/1/0.3 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
Type: P2P, Address: 0.0.0.0, Mask: 0.0.0.0, MTU: 1476, Cost: 100
Adj count: 1
Hello: 10, Dead: 40, ReXmit: 5, Not Stub
Auth type: None
Protection type: None
Topology default (ID 0) -> Cost: 100
gr-1/1/0.3 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 0
Type: P2P, Address: 103.198.145.50, Mask: 255.255.255.252, MTU: 1476, Cost: 100
Adj count: 0, Passive
Hello: 10, Dead: 40, ReXmit: 5, Not Stub
Auth type: None
Protection type: None
Topology default (ID 0) -> Passive, Cost: 100

Sorry for the delay, I am on the road this week and don't have access to my lab to confirm some tests.

 

What I think is happening is traffic engineering is overriding what you would expect as the default OSPF route selection here driven by the RSVP signaled LDP session for the LSP.

 

Not sure if it has anything to do with RSVP here.

 

He seems to be using RLFA and it looks like there's a config issue. 

 

can you paste the output of "show ospf backup spf" ?

Hello there,

---

@Cloud wrote:

 

 

The information as follow is routing table . xe-1/3/2.1 is 10G of submarine cable , and gr-1/1/0.3 is GRE over upstream provider(ISP1).

But I have another GRE over upstream provider(ISP2) , it's interface is gr-2/3/0.2.

 

My question is how to let gr-2/3/0.2 have higher priority than gr-1/1/0.3 both on protocol LDP & OSPF ?

Althought I set gr-1/1/0.3 as higher metric on OSPF , but the backup path is still gr-1/1/0.3, not gr-2/3/0.2.

 

---

Please show us the OSPF LSDB as received from 192.168.145.42:

 

show ospf database advertising-router 192.168.145.42 extensive | no-more

If 192.168.145.42 does not send You  LSA for 192.168.145.2, then ge-2/3/0.2 will not be selected as LFA backup, no matter the metric.

 

---

@Cloud wrote:

 

LDP seems have no way to controll.

 

---

LDP follows IGP, so if You don't receive OSPF LSA for 192.168.145.2/32 via gr-2/3/0.2, then no amount of LDP configuration can help.

HTH

Thx

Alex

Hi All

 

Thanks fisrt for your patience and kindness to help me.

 

I ever turned up RSVP and disable it for a long time. So I think LDP should follow OSPF.

But I don't find out why OSPF will choose the higher metric of interface as backup path.

Maybe I miss some configuration and hope to correct it .

 

As attachment is information about "show OSPF .....".

 

Best regards,

Cloud

 

 

> show configuration protocols rsvp
##
## inactive: protocols rsvp
##
apply-groups GR-LSP;
inactive: interface xe-1/3/2.1;
interface rlt0.0;
interface gr-2/3/0.1;
interface gr-2/3/0.2;
interface gr-1/1/0.1;
interface gr-1/1/0.3;

 

Hello,

Thanks for providing the outputs.

Your link metrics are not the same as Your neighbor metric and hence You are confusing the LFA algorithm since it checks the reverse metrics too.

 

> show ospf neighbor
Address          Interface    State  ID               Pri  Dead
192.168.145.49   gr-1/1/0.3   Full   192.168.145.2    128    38   <--your metric 100,
                                                                  neighbor metric 30
192.168.145.42   gr-2/3/0.2   Full   192.168.145.2    128    34   <--your metric 25,
                                                                  neighbor metric 20

Neighbor OSPF LSDB details:
  id 192.168.147.2, data 192.168.145.49, Type PointToPoint (1)
    Topology count: 0, Default metric: 30
  id 192.168.145.48, data 255.255.255.252, Type Stub (3)
    Topology count: 0, Default metric: 30

   id 192.168.147.2, data 192.168.145.42, Type PointToPoint (1)
    Topology count: 0, Default metric: 20
  id 192.168.145.40, data 255.255.255.252, Type Stub (3)
    Topology count: 0, Default metric: 20

 

 

Please align Your OSPF metrics with Your neighbor's metric and report back.

HTH

Thx
Alex

Hello,

 

I corrected the metric as the same value both on two routers. But the backup path has no change.

As below is my OSPF configuration and the attachment will show more information.

 

Thanks a lot.

 

> show configuration protocols ospf
traffic-engineering;
export EXPORT-TO-OSPF;
area 0.0.0.0 {
interface lo0.0;
interface xe-1/3/2.1 {
interface-type p2p;
link-protection;
metric 5;
bfd-liveness-detection {
minimum-interval 100;
}
}
interface gr-2/3/0.2 {
interface-type p2p;
metric 20;
bfd-liveness-detection {
minimum-interval 100;
}
}
interface gr-1/1/0.3 {
interface-type p2p;
metric 100;
bfd-liveness-detection {
minimum-interval 100;
}
}
interface xe-1/2/2.1 {
interface-type p2p;
link-protection;
metric 5;
bfd-liveness-detection {
minimum-interval 100;
}
}
}

Hello,

Right, it looks like You haven't changed the default LFA backup selection algorithm which is random

https://www.juniper.net/documentation/en_US/junos/topics/concept/backup-selection-ospf-overview.html

The selection of LFA is done randomly by selecting any matching LFA to progress
to the given destination

To change that, please add the following line:

set routing-options backup-selection destination 192.168.145.2/32 interface all metric-order root

HTH

Thx

Alex

 

Hello,

 

Thanks for reply. I think this should be the answer what I want. 

 

But I have last question. According to document from Juniper website, it will only affect the backup path if I set this command,right ?

 

Best regards,

Cloud 

Hello,

Yes, the clue is in the command itself

backup-selection

Which means it affects the order of evaluation in LFA backup interface/path selection algo.

You can verify with 

show backup-selection

It won't show anything before You add the command line I suggested earlier but after You add it, You should be able to see the steps the algorithm takes to arrive at the LFA backup interface selection result.

HTH

Thx
Alex

Hello,

 

Thanks for your help. This problem is resovled .

 

> show backup-selection
Prefix: 0.0.0.0/0
Interface: all
Protection Type: Link, Downstream Paths Only: Disabled, SRLG: Loose, B/w >= Primary: Disabled,
Root-metric: lowest, Dest-metric: lowest
Metric Evaluation Order: Dest-metric, Root-metric
Policy Evaluation Order: Metric