Juniper MPLS Best Practice: Configuring LDP, RSVP-Signalled LSP, LDP Tunneling, and LSP Routing Table Integration

Juniper MPLS Best Practice
Part 2
Configuring LDP, RSVP-Signalled LSP, LDP Tunneling, and
LSP routing table integration
Febrian Setiadi
MPLS overview (cont’d)
• Label-switched Path  The predetermined paths that make MPLS works, this is
unidirectional path through the networks
• Label Switching routers
• Ingress : an entry point of an LSP
• Transit : any router in the middle of LSP
• Penultimate : The second-to-last router in the LSP
• Egress : an exit point for the LSP
• LSP Signalling Protocols
• RSVP
• Well-known signaling protocol, which is extended to support Traffic- Eng
• Supports explicit paths and bandwidth reservation
• Label allocated only along the defined LSP path
• LDP
• Uses the same shortest-path as IGP for forwarding
• Label allocated and exchanged between neighbors
• LDP Tunnelling
• Permits establishments of and LDP session across an RSVP network by tunneling
the LDP traffic within RSVP-based LSPs.
Lab Topology
LDP Configuration
1. Configure the interface to support the MPLS family
btm@lab:Batam> show configuration interfaces
em1 {
unit 7 {
vlan-id 7;
family inet {
address 10.0.7.1/30;
}
family mpls;
}
unit 10 {
vlan-id 10;
family inet {
address 10.0.10.1/30;
}
family mpls;
}
unit 90 {
vlan-id 90;
family inet {
address 10.0.90.1/30;
}
family mpls;
}
unit 100 {
vlan-id 100;
family inet {
address 100.100.100.1/30;
}
}
}
LDP Configuration
2. Enable MPLS protocol on the interface
btm@lab:Batam> show configuration protocols
mpls {
interface all;
}
3. Turn on LDP as the signalling Protocol

ldp {
interface all;
}
4. On the transit and egress routers, turn on MPLS and LDP in a similar fashion, e.g :
Semarang
smg@lab:Semarang> show configuration interfaces em2 {
em1 { unit 1 {
unit 0 { vlan-id 1;
vlan-id 0; family inet {
family inet { address 10.0.1.2/30;
address 10.0.0.1/30; }
} family mpls;
family mpls; }
} unit 7 {
unit 3 { vlan-id 7;
vlan-id 3; family inet {
family inet { address 10.0.7.2/30;
address 10.0.3.1/30; }
} family mpls;
family mpls; }
} }
LDP Configuration
• Once LDP is turned on on all the routers, the protocol automatically builds
multipoint-to-point LSPs, each ending on a different router in the network.
btm@lab:Batam> show ldp interface
Interface Label space ID Nbr count Next hello
lo0.4 192.168.4.1:0 1 0
em1.7 192.168.4.1:0 1 4
em1.10 192.168.4.1:0 1 2
em1.90 192.168.4.1:0 1 1
smg@lab:Semarang> show ldp interface

Interface Label space ID Nbr count Next hello
em1.0 192.168.16.1:0 1 1
em1.3 192.168.16.1:0 1 0
em1.11 192.168.16.1:0 1 4
em2.1 192.168.16.1:0 1 0
em2.7 192.168.16.1:0 1 3
lo0.16 192.168.16.1:0 0 0
LDP Configuration
• You see that each LDP interface is operational and has learned about one neighbor.
btm@lab:Batam> show ldp session

Address State Connection Hold time
192.168.8.1 Operational Open 20
smg@lab:Semarang> show ldp session

LDP Configuration
• Use the detail form of this command to see the session parameters: (omitted)
jkt@lab:Jakarta> show ldp session detail
Address: 192.168.4.1, State: Operational, Connection: Open, Hold
time: 21
Session ID: 192.168.8.1:0--192.168.4.1:0
Next keepalive in 1 seconds
Active, Maximum PDU: 4096, Hold time: 30, Neighbor count: 1
Neighbor types: discovered
Keepalive interval: 10, Connect retry interval: 1
Local address: 192.168.8.1, Remote address: 192.168.4.1
Up for 05:31:12
Local - Restart: disabled, Helper mode: enabled
Remote - Restart: disabled, Helper mode: enabled
Local maximum recovery time: 240000 msec
Nonstop routing state: Not in sync
Next-hop addresses received:
10.0.7.1
10.0.10.1
10.0.90.1
192.168.4.1
100.100.100.1
RSVP Configuration
• We’ll setup RSVP from Batam to Ambon
RSVP Configuration
1. Configure the interface to support the MPLS family
btm@lab:Batam> show configuration interfaces
em1 {
unit 7 {
vlan-id 7;
family inet {
address 10.0.7.1/30;
}
family mpls;
}
unit 10 {
vlan-id 10;
family inet {
address 10.0.10.1/30;
}
family mpls;
}
unit 90 {
vlan-id 90;
family inet {
address 10.0.90.1/30;
}
family mpls;
}
unit 100 {
vlan-id 100;
family inet {
address 100.100.100.1/30;
}
}
}
RSVP Configuration
2. Turn on RSVP as the signalling protocol
rsvp {
interface all;
}
3. On the transit and egress routers, turn on MPLS and RSVP in a similar fashion.
e.g : Surabaya as the Egress Router
sby@lab:Surabaya> show configuration protocols
rsvp {
interface all;
}
mpls {
interface all;
}
RSVP Configuration
4. Finally set up a return LSP from Ingress to Egress so that the LSP is bidirectional
and traffic can travel from the egress router back to the ingress router:
btm@lab:Batam> show configuration protocols mpls
label-switched-path Batam-to-Ambon {
to 192.168.48.1;
no-cspf;
}
5. Use show mpls lsp command to confirm configuration on Ingress, Transit, and
Egress router.
btm@lab:Batam> show mpls lsp ingress
Ingress LSP: 1 sessions
To From State Rt ActivePath P LSPname
192.168.48.1 192.168.4.1 Up 0 * Batam-to-Ambon
Total 1 displayed, Up 1, Down 0
smg@lab:Semarang> show mpls lsp transit
Transit LSP: 1 sessions
To From State Rt Style Labelin Labelout LSPname
192.168.48.1 192.168.4.1 Up 1 1 FF 100288 100288 Batam-to-Ambon
sby@lab:Surabaya> show mpls lsp transit
Transit LSP: 1 sessions
192.168.48.1 192.168.4.1 Up 1 1 FF 100288 3 Batam-to-Ambon
amb@lab:Ambon> show mpls lsp egress
Egress LSP: 1 sessions
192.168.48.1 192.168.4.1 Up 0 1 FF 3 - Batam-to-Ambon
RSVP Configuration
• Installing LSPs into the Unicast Routing Table (inet.0)
• Before
btm@lab:Batam> show route 192.168.48.1
inet.0: 37 destinations, 37 routes (36 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.48.1/32 *[OSPF/10] 00:00:53, metric 3

> to 10.0.7.2 via em1.7
to 10.0.10.2 via em1.10

192.168.48.1/32 *[RSVP/7] 00:00:08, metric 3

> to 10.0.10.2 via em1.10, label-switched-path Batam-to-Ambon
[LDP/9] 00:00:07, metric 1
• Use traffic-engineering bgp-igp or installing additional prefixes per LSP

with install prefix active
traffic-engineering bgp-igp;
to 192.168.48.1;
no-cspf;
}
RSVP Configuration
• After installing LSP into the Unicast Routing Table

192.168.48.1/32 *[RSVP/7] 00:27:22, metric 3

[LDP/9] 00:27:22, metric 1
[OSPF/10] 00:27:27, metric 3
> to 10.0.7.2 via em1.7
to 10.0.10.2 via em1.10
• While performs traceroute, mpls label will be appeared

btm@lab:Batam> traceroute 192.168.48.1
traceroute to 192.168.48.1 (192.168.48.1), 30 hops max, 40 byte packets
1 SMG (10.0.7.2) 2.153 ms 0.703 ms 0.798 ms
MPLS Label=100320 CoS=0 TTL=1 S=1
2 SBY (10.0.0.2) 1.048 ms 0.995 ms 1.007 ms
3 AMB (192.168.48.1) 1.377 ms 1.401 ms 1.442 ms
Placing Routing constraints on RSVP
• Using Bandwidth Reservation
• Using Named-Path
• Using Explicit Route Object
• Strict : Must be directly attached to previous hop
• Loose : Not always be adjacencied
• Allowing IGP traffic to use an LSP
• As a next-hop in static route
• Configure OSPF or IS-IS so that the LSP is advertised into the IGP
Placing Routing constraints on RSVP
• Using Bandwidth Reservation
to 192.168.48.1;
ldp-tunneling;
bandwidth 500m;
no-cspf;
}
• Verifying bandwidth on an LSP

btm@lab:Batam> show rsvp interface
RSVP interface: 4 active
Active Subscr- Static Available Reserved Highwater
Interface State resv iption BW BW BW mark
em1.7 Up 1 100% 1000Mbps 500Mbps 500Mbps 500Mbps
em1.90 Up 0 100% 1000Mbps 1000Mbps 0bps 500Mbps
smg@lab:Semarang> show rsvp interface
em1.11 Up 0 100% 1000Mbps 1000Mbps 0bps 0bps
sby@lab:Surabaya> show rsvp interface
em1.9 Up 0 100% 1000Mbps 1000Mbps 0bps 0bps
Using naming path with ERO
• We’ll setup Primary and Secondary path from Batam
to Ambon
• Path Shortest  this will be the Secondary
Will traverse along Batam – Semarang – Surabaya – Ambon
• Path Furthest  this will be the Primary
Will traverse along Furthest Path :
Batam – Jakarta – Bandung – Denpasar – Surabaya –
Semarang – Banjarmasin – Pontianak – Balikpapan –
Ambon
• Defining path Shortest :

to 192.168.48.1;
bandwidth 500m;
no-cspf;
}
path Shortest {
192.168.16.1 loose; // Semarang
192.168.36.1 loose; // Surabaya
}
• Defining path Furthest :

path Furthest {
10.0.90.2 strict; // Jakarta
10.0.80.2 strict; // Bandung
10.0.70.2 strict; // Denpasar
10.0.60.2 strict; // Makasar
10.0.9.1 strict; // Surabaya
10.0.0.1 strict; // Semarang
10.0.1.1 strict; // Banjarmasin
10.0.5.1 strict; // Pontianak
10.0.20.2 strict; // Balikpapan
10.0.30.2 strict; // Ambon
}
• Named Path configuration
to 192.168.48.1;
bandwidth 500m;
no-cspf;
primary Furthest;
secondary Shortest;
}
path Shortest {
192.168.16.1 loose;
192.168.36.1 loose;
}
path Furthest {
10.0.90.2 strict;
10.0.80.2 strict;
10.0.70.2 strict;
10.0.60.2 strict;
10.0.9.1 strict;
10.0.0.1 strict;
10.0.1.1 strict;
10.0.5.1 strict;
10.0.20.2 strict;
10.0.30.2 strict;
}
• Traceroute result
btm@lab:Batam> traceroute 192.168.48.1
traceroute to 192.168.48.1 (192.168.48.1), 30 hops max, 40
byte packets
1 JKT (10.0.90.2) 0.758 ms 0.827 ms 0.510 ms
2 BDG (10.0.80.2) 1.042 ms 1.521 ms 0.965 ms
3 DPS (10.0.70.2) 1.523 ms 1.341 ms 1.459 ms
4 MKS (10.0.60.2) 1.771 ms 2.494 ms 4.011 ms
5 SBY (10.0.9.1) 1.605 ms 2.153 ms 1.700 ms
6 SMG (10.0.0.1) 1.749 ms 1.795 ms 1.783 ms
7 BJM (10.0.1.1) 3.818 ms 2.259 ms 5.182 ms
8 PON (10.0.5.1) 2.363 ms 2.252 ms 2.221 ms
9 BPP (10.0.20.2) 3.291 ms 3.385 ms 4.967 ms
10 AMB (192.168.48.1) 4.495 ms 4.450 ms 4.498 ms
Allowing IGP traffic to use an LSP
• As a next-hop in static route
After we created LSP, next task is to make sure that all traffic destined to Ambon
travels through the LSP we have created. We have to specify all LSP bound-
traffic use the LSP as the next-hop and allow all forwarding decisions.
btm@lab:Batam> show configuration routing-options
static {
route 192.168.48.1/32 {
lsp-next-hop Batam-to-Ambon;
}
}

192.168.48.1/32 *[Static/5] 00:00:11

Allowing IGP traffic to use an LSP
• Configure OSPF or IS-IS so that the LSP is advertised into the IGP
We want to configure OSPF so they can also use the LSPs on the ingress
router.
btm@lab:Batam> show configuration protocols ospf
area 0.0.0.0 {
interface all;
interface em1.100 {
disable;
}
label-switched-path Batam-to-Ambon;
}

192.168.48.1/32 *[Static/5] 00:03:04

[OSPF/10] 00:00:06, metric 1
> to 10.0.90.2 via em1.90, label-switched-path Bata
Ambon
Label Stacking : LDP Tunneling
• We’ll use LDP through an RSVP network
JuOS software permits the establishment of an LDP session across an
RSVP network by tunneling the LDP traffic within RSVP-based
LSPs
It requires 2 RSVP signaled LSP to exist between the LDP neighbors 
one in each direction
• Current LDP session on Batam
• Current LDP session on Ambon
amb@lab:Ambon> show ldp session

• Enabling LDP Tunneling on Batam’s LSP
to 192.168.48.1;
ldp-tunneling;
bandwidth 500m;
no-cspf;
primary Furthest;
secondary Shortest;
}
• Enabling LDP Tunneling on Ambon’s LSP
amb@lab:Ambon> show configuration protocols mpls

label-switched-path Ambon-to-Batam {
to 192.168.4.1;
ldp-tunneling;
no-cspf;
}
• After LDP Tunneling configured on Batam
• After LDP Tunneling configured on Ambon
amb@lab:Ambon> show ldp session

At this point, the LDP neighbor relationship is formed and the routers exchange
LDP initialization messages, as displayed on LDP session at each routers.
LSP and Routing Table Integration
• Mapping BGP next-hops to LSPs
• Routes associated with signaled LSPs are installed in the inet.3 routing
table
• Only BGP can view the contents of inet.3
• BGP tries to resolve its next hop through LSPs in the inet.3
• BGP installs an LSP as the physical next-hop for transit destinations
• Internal destinations aren’t associated with a BGP next-hop and
therefore don’t LSPs by default
• BGP first look in inet.3 table when attempting to resolve the BGP next-
hop associated with given prefix
• We’ll demonstrate how BGP install next-hop from inet.3 table

• Route Resolution Example
• We begin by examining how traffic is forwarded to the
118.96.0/16 from the perspective of ASN 17974
• 118.96.0/16 is being learned by Ambon router through

EBGP session to Hongkong, Jakarta router then learns
about 118.96.0/16 through its IBGP session to Ambon,
Jakarta installs prefix 118.96.0/16 then readvertises it to
the Singapore router, using EBGP session.
• In this example. Routers in Singapore begin sending traffic

to 118.96.0/16 prefixes through Batam, when this transit
traffic arrives at the Batam router, it must decide how to
forward this transit traffic to 118.98.0/16
• BGP configuration in Batam
btm@lab:Batam> show configuration protocols bgp
group EBGP-to-SG {
type external;
local-address 100.100.100.1;
peer-as 4657;
local-as 7713;
neighbor 100.100.100.2;
}
group IBGP {
type internal;
neighbor 192.168.48.1;
}
• BGP configuration in Ambon
amb@lab:Ambon> show configuration protocols bgp
group EBGP-to-HK {
type external;
peer-as 38154;
local-as 7713;
neighbor 200.200.200.2;
}
group IBGP {
type internal;
neighbor 192.168.4.1;
}
• Advertisement from Ambon
amb@lab:Ambon> show bgp summary
Groups: 2 Peers: 2 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0 1 1 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|
#Active/Received/Damped...
192.168.4.1 7713 647 655 0 2 4:16:08 0/0/0
0/0/0
200.200.200.2 38154 664 659 0 0 4:56:03 1/1/0
amb@lab:Ambon> show route receive-protocol bgp 200.200.200.2

Prefix Nexthop MED Lclpref AS path
* 118.96.0.0/16 200.200.200.2 38154 I
mpls.0: 16 destinations, 16 routes (16 active, 0 holddown, 0 hidden)
amb@lab:Ambon> show route advertising-protocol bgp 192.168.4.1

Prefix Nexthop MED Lclpref AS path
* 118.96.0.0/16 200.200.200.2 100 38154 I
0/0/0
• What Batam sees
btm@lab:Batam> show bgp summary
Groups: 2 Peers: 2 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0 1 0 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|
#Active/Received/Damped...
100.100.100.2 4657 576 579 0 2 4:18:34 0/0/0 0/0/0
192.168.48.1 7713 576 575 0 2 4:18:34 0/1/0 0/0/0
btm@lab:Batam> show route receive-protocol bgp 192.168.48.1
mpls.0: 16 destinations, 16 routes (16 active, 0 holddown, 0 hidden)
No route received, thus no BGP route installed, why?

• Unusable next-hop
btm@lab:Batam> show route 118.96.0.0/16 all extensive

118.96.0.0/16 (1 entry, 0 announced)
BGP Preference: 170/-101
Next hop type: Unusable
Next-hop reference count: 1
State: <Hidden Int Ext>
Local AS: 7713 Peer AS: 7713
Age: 4:20:12
Task: BGP_7713.192.168.48.1+51648
AS path: 38154 I
Localpref: 100
Router ID: 192.168.48.1
Indirect next hops: 1
Protocol next hop: 200.200.200.2
Indirect next hop: 0 -
Batam router can not resolve it’s next-hop (200.200.200.2)

• Typical solutions, by using next-hop self
amb@lab:Ambon> show configuration policy-options
policy-statement nhs {
then {
next-hop self ;
}
}
amb@lab:Ambon> show configuration protocols bgp group IBGP

type internal;
export nhs;
neighbor 192.168.4.1;
• Resolved, from Batam router, next-hop is 192.168.48.1

btm@lab:Batam> show route 118.96.0/16

118.96.0.0/16 *[BGP/170] 00:04:09, localpref 100, from 192.168.48.1

AS path: 38154 I
to 10.0.7.2 via em1.7
> to 10.0.10.2 via em1.10
• LSP configured Batam-to-Ambon
to 192.168.48.1
no-cspf;
}

192.168.48.1/32 *[OSPF/10] 00:00:05, metric 3

to 10.0.7.2 via em1.7
> to 10.0.10.2 via em1.10

192.168.48.1/32 *[RSVP/7] 00:03:21, metric 3

Prefix 192.168.48.1 installed in inet.3, lowest preference wins, but BGP

will use information in table inet.3
• BGP installs LSP as next-hop
btm@lab:Batam> show route 118.96.0.0/16

118.96.0.0/16 *[BGP/170] 00:00:35, localpref 100, from 192.168.48.1

AS path: 38154 I
The results of BGP next-hop resolution through the inet.3 table results in the
Batam-to-Ambon LSP being installed as the forwarding next-hop for traffic
associated with 118.96.0/16 prefix.
• What actually happened ?
btm@lab:Batam> show route table inet.3 detail

192.168.48.1/32 (1 entry, 1 announced)
State: <FlashAll>
*RSVP Preference: 7
Next hop type: Router, Next hop index: 1058
Next-hop reference count: 7
Next hop: 10.0.90.2 via em1.90 weight 0x1, selected
Label-switched-path Batam-to-Ambon
Label operation: Push 100560
State: <Active Int>
Local AS: 7713
Age: 6:26 Metric: 3
Task: RSVP
Announcement bits (1): 3-Resolve tree 2
AS path: I
• Ingress Resolves BGP next-hop
• BGP performs recursive lookup to resolve BGP next hop
• BGP also looks in the inet.3 MPLS routing table
• BGP looks in the inet.0 IP routing table
• BGP selects route with lowest preference

192.168.48.1/32 *[OSPF/10] 00:16:38, metric 3

to 10.0.7.2 via em1.7
> to 10.0.10.2 via em1.10

192.168.48.1/32 *[RSVP/7] 00:11:29, metric 3


Juniper MPLS Best Practice: Configuring LDP, RSVP-Signalled LSP, LDP Tunneling, and LSP Routing Table Integration

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Juniper MPLS Best Practice: Configuring LDP, RSVP-Signalled LSP, LDP Tunneling, and LSP Routing Table Integration

Загружено:

Авторское право:

Доступные форматы

Juniper MPLS Best Practice

3. Turn on LDP as the signalling Protocol

smg@lab:Semarang> show ldp interface

btm@lab:Batam> show ldp session

smg@lab:Semarang> show ldp session

192.168.48.1/32 *[OSPF/10] 00:00:53, metric 3

inet.3: 11 destinations, 13 routes (10 active, 0 holddown, 2 hidden)

192.168.48.1/32 *[RSVP/7] 00:00:08, metric 3

• Use traffic-engineering bgp-igp or installing additional prefixes per LSP

inet.0: 37 destinations, 48 routes (36 active, 0 holddown, 1 hidden)

192.168.48.1/32 *[RSVP/7] 00:27:22, metric 3

• While performs traceroute, mpls label will be appeared

• Verifying bandwidth on an LSP

btm@lab:Batam> show configuration protocols mpls

btm@lab:Batam> show configuration protocols mpls

btm@lab:Batam> show route 192.168.48.1

inet.0: 37 destinations, 49 routes (36 active, 0 holddown, 1 hidden)

192.168.48.1/32 *[Static/5] 00:00:11

btm@lab:Batam> show route 192.168.48.1

inet.0: 37 destinations, 49 routes (36 active, 0 holddown, 1 hidden)

192.168.48.1/32 *[Static/5] 00:03:04

• Current LDP session on Ambon

amb@lab:Ambon> show ldp session

amb@lab:Ambon> show configuration protocols mpls

• After LDP Tunneling configured on Ambon

amb@lab:Ambon> show ldp session

• We’ll demonstrate how BGP install next-hop from inet.3 table

• 118.96.0/16 is being learned by Ambon router through

• In this example. Routers in Singapore begin sending traffic

amb@lab:Ambon> show route receive-protocol bgp 200.200.200.2

inet.0: 37 destinations, 48 routes (37 active, 0 holddown, 0 hidden)

inet.3: 2 destinations, 2 routes (0 active, 0 holddown, 2 hidden)

mpls.0: 16 destinations, 16 routes (16 active, 0 holddown, 0 hidden)

amb@lab:Ambon> show route advertising-protocol bgp 192.168.4.1

inet.0: 37 destinations, 48 routes (37 active, 0 holddown, 0 hidden)

btm@lab:Batam> show route receive-protocol bgp 192.168.48.1

inet.0: 37 destinations, 49 routes (36 active, 0 holddown, 1 hidden)

mpls.0: 16 destinations, 16 routes (16 active, 0 holddown, 0 hidden)

No route received, thus no BGP route installed, why?

inet.0: 37 destinations, 49 routes (36 active, 0 holddown, 1 hidden)

Batam router can not resolve it’s next-hop (200.200.200.2)

amb@lab:Ambon> show configuration protocols bgp group IBGP

• Resolved, from Batam router, next-hop is 192.168.48.1

inet.0: 37 destinations, 37 routes (37 active, 0 holddown, 0 hidden)

118.96.0.0/16 *[BGP/170] 00:04:09, localpref 100, from 192.168.48.1

btm@lab:Batam> show route 192.168.48.1

inet.0: 37 destinations, 37 routes (37 active, 0 holddown, 0 hidden)

192.168.48.1/32 *[OSPF/10] 00:00:05, metric 3

inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

192.168.48.1/32 *[RSVP/7] 00:03:21, metric 3

Prefix 192.168.48.1 installed in inet.3, lowest preference wins, but BGP

inet.0: 37 destinations, 37 routes (37 active, 0 holddown, 0 hidden)

118.96.0.0/16 *[BGP/170] 00:00:35, localpref 100, from 192.168.48.1

inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

btm@lab:Batam> show route 192.168.48.1

inet.0: 37 destinations, 37 routes (37 active, 0 holddown, 0 hidden)

192.168.48.1/32 *[OSPF/10] 00:16:38, metric 3

inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

192.168.48.1/32 *[RSVP/7] 00:11:29, metric 3

Вам также может понравиться