IOS XE 15.5
IOS XR 5.3
The topology for this demo:
In this post we will be looking at configuring a TE tunnel on the headend router, in this case this is R3. We'll cover TE tunnel creation on XR in another post. A TE tunnel itself is a unidirectional tunnel that starts at the headend router and terminates at the destination which is the tailend, not necessarily another PE, could be a P router. You can create TE tunnels to connect PE-PE, PE-P and P-P. The reason you may choose to connect from the PE to the P is you may be running H-VPLS.
In regards to the "unidirectional" aspect this means that from the headend to the tailend, the LSP that flows over the TE tunnel flows from the headend to the tailend. On the return path, that may not be the same, the return path may use LDP labels and not TE labels. If you need to have bi-directional TE tunneling, then headend to tailend and tailend to headend tunnels are required. To clarify, the tailend is always the exit point of a TE tunnel. If the return path is to use a TE tunnel, then the tailend router would then be configured to be a headend router for the return path. A router can be both a headend and tailend at the same time.
The headend router is the end that initiates RSVP signaling, the PATH message and specifies the tunnel level constraints. Interface level constraints can be specified as well, like link affinity. We'll configure a simple TE tunnel on R3, giving it the most basic configuration required for the TE tunnel to function.
R3
interface Tunnel1
ip unnumbered Loopback0
tunnel mode mpls traffic-eng
tunnel destination 192.168.1.1
tunnel mpls traffic-eng path-option 1 dynamic
The above configuration breakdown:
"ip unnumbered loopback0" is needed because the TE tunnel itself is not running IP but needs to be identifiable in the TE database
"tunnel mode mpls traffic-eng" is needed to identify the encapsulation to signal for, we are telling the control plane via RSVP, we need to allocate labels via RSVP-TE and not via LDP
"tunnel destination x.x.x.x" like a GRE tunnel, a destination is required to know where in the network will the tunnel terminate.
"tunnel mpls traffic-eng path-option 1 dynamic" this is command that tells the TE process to use IGPs SPF path to the destination address. You can specify an explicit path, covered later.
Next we'll take a look some debug outputs, I'll identify the debug and it's output to keep things easy to follow.
R3#debug mpls traffic-eng tunnels signalling
Next bounce the tunnel1 interface.
TE-SIG-HE: Tunnel1 [0]: Attempting to activate
TE-SIG-HE: Tunnel1 [67]->192.168.1.1: RSVP head-end open
TE-SIG-HE: Tunnel1 [67]: Activation succeeded
TE-SIG-LM: 192.168.1.3_67->192.168.1.1_1 {7}: received ADD RESV request
TE-SIG-LM: 192.168.1.3_67->192.168.1.1_1 {7}: path next hop is 10.14.3.14 (GigabitEthernet1.143)
TE-SIG: Installed up_tag 4294967294
TE-SIG: Installed down_tag 24001
TE-SIG-LM: 192.168.1.3_67->192.168.1.1_1 {7}: sending ADD RESV reply
TE-SIG-HE: Tunnel1 [67]->192.168.1.1: received RESV CREATE
TE-SIG-HE: Tunnel1 [67]->192.168.1.1: notified of new label information
GigabitEthernet1.143, nhop 10.14.3.14, frame, 24001
TE-SIG-HE: Tunnel1 [67]->192.168.1.1: label information Changed
*Jan 23 15:00:52.870: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up
R3#debug ip rsvp signalling
RSVP: 192.168.1.3_69->192.168.1.1_1[Src] {7}: Received Path message from 127.0.0.1 (on sender host)
RSVP: new path message passed parsing, continue...
RSVP: 192.168.1.3_69->192.168.1.1_1[Src] {7}: [rsvp_examine_and_mark_md_events] Incoming PSB MD = Ignore
RSVP: 192.168.1.3_69->192.168.1.1_1[Src] {7}: [rsvp_examine_and_mark_tspec_events] Incoming PSB TSpec = Ignore
RSVP: Triggering outgoing Path due to incoming Path change or new Path
RSVP: Triggering outgoing Path refresh
RSVP: 192.168.1.3_69->192.168.1.1_1[Src] {7}: Path refresh, Event: rmsg not enabled or ack rcvd, State: trigger to normal
RSVP: 192.168.1.3_69->192.168.1.1_1[Src] {7}: Path refresh (msec), config: 30000 curr: 30000 xmit: 30000
RSVP: Triggering outgoing Path due to incoming Path change or new Path
RSVP: Triggering outgoing Path refresh
RSVP: 192.168.1.3_69->192.168.1.1_1[Src] {7}: Path refresh, Event: rmsg not enabled or ack rcvd, State: trigger to normal
RSVP: 192.168.1.3_69->192.168.1.1_1[Src] {7}: Path refresh (msec), config: 30000 curr: 30000 xmit: 30000
RSVP: 192.168.1.3_69->192.168.1.1_1[Src] {7}: Sending Path message to 10.14.3.14
RSVP: 192.168.1.3_69->192.168.1.1_1[Src] {7}: building hop object with src addr: 10.14.3.3
RSVP: session 192.168.1.1_1[192.168.1.3] (7): Received Resv message from 10.14.3.14 (on GigabitEthernet1.143)
RSVP: 192.168.1.3_69->192.168.1.1_1[Src] {7}: Successfully parsed Resv message from 10.14.3.14 (on GigabitEthernet1.143)
RSVP: 192.168.1.3_69->192.168.1.1_1[Src] {7}: reservation not found--new one
RSVP-RESV: Admitting new reservation: 7EFF4C038B90
RSVP-RESV: reservation (RSB 0x7EFF4C038B90) was installed on GigabitEthernet1.143
*Jan 23 15:03:54.808: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up
R3#debug mpls traffic-eng path spf
TE-PCALC-SPF: Begin SPF for tunnel1 to dest 192.168.1.1
TE-PCALC-SPF: Added 192.168.1.3 to tent list (aw 0, min_bw 18446744073709551615, prev_node(NULL))
Says that the "aw 0" which is the administrative weight and the "min_bw" is the minimum bandwidth and doesn't have a value specified.
TE-PCALC-SPF: Moved 192.168.1.3 to path list
R3 has now been added to the path list, since it is the local router and the beginning or headend device.
TE-PCALC-SPF: Added 10.14.3.14 to tent list (aw 1, min_bw 750000, prev_node(192.168.1.3))
TE-PCALC-SPF: Added 10.3.4.4 to tent list (aw 1, min_bw 750000, prev_node(192.168.1.3))
TE-PCALC-SPF: rrr_pcalc_dump_tentative list:
10.3.4.4: (aw=1, min_bw=750000, hops=1)
10.14.3.14: (aw=1, min_bw=750000, hops=1)
TE-PCALC-SPF: Moved 10.3.4.4 to path list
Now we move onto XR4 - it is moved to the tentative list, the admin weight is 1, being 1 hop away, the minimum BW is 750 Mbps, which is 75% of the 1 gig capacity, it know the "previous node" is R3. Since the AW and the min BW both meet the constraints and XR4 is added to the path list for the XR4 to R3 connection. TE PATH and TE RESV are done per hop. This process repeats itself for all the hops, R3 > XR4 > XR1 > R1; R3 > R4 > XR5 > R1; R3 > XR4 > XR5 > R1. I've limited the output to this node for brevity.
RSVP: 192.168.1.3_72->192.168.1.1_1[Src] {7}: Received Path message from 127.0.0.1 (on sender host)
RSVP: new path message passed parsing, continue...
RSVP: 192.168.1.3_72->192.168.1.1_1[Src] {7}: [rsvp_examine_and_mark_md_events] Incoming PSB MD = Ignore
RSVP: 192.168.1.3_72->192.168.1.1_1[Src] {7}: [rsvp_examine_and_mark_tspec_events] Incoming PSB TSpec = Ignore
RSVP: Triggering outgoing Path due to incoming Path change or new Path
RSVP: Triggering outgoing Path refresh
RSVP: 192.168.1.3_72->192.168.1.1_1[Src] {7}: Path refresh, Event: rmsg not enabled or ack rcvd, State: trigger to normal
RSVP: 192.168.1.3_72->192.168.1.1_1[Src] {7}: Path refresh (msec), config: 30000 curr: 30000 xmit: 30000
RSVP: Triggering outgoing Path due to incoming Path change or new Path
RSVP: Triggering outgoing Path refresh
RSVP: 192.168.1.3_72->192.168.1.1_1[Src] {7}: Path refresh, Event: rmsg not enabled or ack rcvd, State: trigger to normal
RSVP: 192.168.1.3_72->192.168.1.1_1[Src] {7}: Path refresh (msec), config: 30000 curr: 30000 xmit: 30000
RSVP: 192.168.1.3_72->192.168.1.1_1[Src] {7}: Sending Path message to 10.14.3.14
RSVP: 192.168.1.3_72->192.168.1.1_1[Src] {7}: building hop object with src addr: 10.14.3.3
RSVP: session 192.168.1.1_1[192.168.1.3] (7): Received Resv message from 10.14.3.14 (on GigabitEthernet1.143)
RSVP: 192.168.1.3_72->192.168.1.1_1[Src] {7}: Successfully parsed Resv message from 10.14.3.14 (on GigabitEthernet1.143)
RSVP: 192.168.1.3_72->192.168.1.1_1[Src] {7}: reservation not found--new one
RSVP-RESV: Admitting new reservation: 7EFF4BFFC258
RSVP-RESV: reservation (RSB 0x7EFF4BFFC258) was installed on GigabitEthernet1.143
*Jan 23 15:06:45.256: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up
Now we need to verify the traffic-eng tunnels database.
The first thing to take notice on is that the "path:valid" and "signalling:connected". This means that the path is valid and that singalling was good, if there was an issue somewhere in the path between R3 and R1, the "oper: up" would be down and there would be an output for a failure.
The config parameters section is unique as well, no bandwidth was specified which is the "0" output, the priority is 7 7, which is the lowest variable, the first 7 is the setup priority and second 7 is it's preemption priority. The setup value is to bring up the tunnel as long as 1, there isn't another tunnel with a higher priority claiming more bandwidth, 2, if this tunnel is up and another tunnel comes up with a higher priority and this tunnel is reserving bandwidth the other tunnel needs, this tunnel can be brought down based on priority in favor of the other tunnel.
No affinity is being specified and the TE metric is being used and not the IGP metric.
Auto route lockdown disable means that either reoptimization or preemption could override this tunnel, with disabled, that wouldn't be possible.
R3#sh mpls traffic-eng tunnels tunnel 1
Name: R3_t1 (Tunnel1) Destination: 192.168.1.1
Status:
Admin: up Oper: up Path: valid Signalling: connected
path option 1, type dynamic (Basis for Setup, path weight 3)
Config Parameters:
Bandwidth: 0 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF
Metric Type: TE (default)
AutoRoute: disabled LockDown: disabled Loadshare: 0 [0] bw-based
auto-bw: disabled
Active Path Option Parameters:
State: dynamic path option 1 is active
BandwidthOverride: disabled LockDown: disabled Verbatim: disabled
InLabel : -
OutLabel : GigabitEthernet1.143, 24001
Next Hop : 10.14.3.14
RSVP Signalling Info:
Src 192.168.1.3, Dst 192.168.1.1, Tun_Id 1, Tun_Instance 72
RSVP Path Info:
My Address: 10.14.3.3
Explicit Route: 10.14.3.14 10.11.14.14 10.11.14.11 10.1.11.11
10.1.11.1 192.168.1.1
Record Route: NONE
Tspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits
RSVP Resv Info:
Record Route: NONE
Fspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits
Shortest Unconstrained Path Info:
Path Weight: 3 (TE)
Explicit Route: 10.14.3.3 10.14.3.14 10.11.14.14 10.11.14.11
10.1.11.11 10.1.11.1 192.168.1.1
As it sits right now, the "explicit" route is 6 interface ip hops. where the Shortest unconstrained path is showing 7 interface ip hops. As it sits now, we aren't mapping VPN traffic to the TE tunnel, so we have just calculated a path, but we're not using it.
Now that we have at least one tunnel up, i can begin to show how all these pieces fit together, adding in add'l content as we go. I plan on breaking down the individual components down, as TE has a lot of knobs to turn.
Thanks for stopping by!
Rob Riker, CCIE #50693
No comments:
Post a Comment