This was a good opportunity to share experience and meet old and new friends.
A shot for my presentation:
domenica 21 novembre 2010
talking about CCIE
I recently talk about my experience in becoming CCIE Certified.
This was a good opportunity to share experience and meet old and new friends.
A shot for my presentation:
The link official url for the event and my presentation ( in italian )
This was a good opportunity to share experience and meet old and new friends.
A shot for my presentation:
lunedì 1 febbraio 2010
6VPE - ipv6 mpls VPN between cisco e junos
The spread of IPv6 in our networks is slow, but to refresh my IPv6 knowledge and use the LSPs configured in the previous post, I decided to configure an IPv6 mpls VPN between two sites.
This solution is called 6VPE and introduced on IOS a new configuration syntax for VRF.
Building the control plane
The operations are very similar to a IPv4 MPLS VPN: vpn prefix and label are signaled by mBGP while, LDP and/or RSVP ensure the label signaling necessary to forward MPLS packet throught the backbone.
The lab uses a virtual CE, realized exclusively with a loopback within each of the two PE involved. It thus avoids the entire PE-CE configuration as the purpose of the lab is to exercise on the MPLS component.
Peering mBGP
As vpnv6 signaling uses mBGP, we need to configure an iBGP peering between the two PE. The configuration proposed is minimal, and allows only the signaling of the vpnv6 AF (Address Family).
J2 Juniper PE
The BGP configuration necessarily require the use of a group (equivalent to a cisco peer-group) and the explicit peering type identification (internal vs. external). As previously mentioned only AF inet6-vpn unicast is enabled:
R6 PE Cisco
The IOS PE requires a global enable for ipv6 ed ipv6 cef. In the BGP part is avoided the exchange of IPv4 prefixes while vpnv6 peering with a complete community exchange is enabled for J2.
BGP session
It is always interesting to have a look at the communication capability negotiated BGP: The Open messages include the Multiprotocol Extension AFI (2) and SAFI (120) as indicated in the RFC:
Multiprotocol Extensions for BGP-4 rfc2858
Carrying Label Information in BGP-4 rfc3107
And as assigned by the IANA safi-namespace
The complete capture of BGP communication is here
VRF Configurations on Junos
Until now we have used the logical system of Junos isolating in its own stanza all the configuration statements for the virtual router realized.
The configuration of VRF rather intersects with the main routing instance ( or logical system ) which ensures the communication. The VRF is a particular routing-instance type in which the routing features are configured and the interfaced assigned, however the complete interface configuration remain global.
On J2 the IPv6 address fec0:cc1e:1::1/128 is configured on the new lo0 unit 102.
then the "red" VRF routing instance is created, with route distinguisher assigned as the 2:2 route-target and 100:100.
Finally the newly configured unit 102 of the lo0 interface is associated with the routing-instance
For those used to work with IOS there is no requirement to explicit configure the "redistribute connected" required to put the prefix in the mBGP table, all the prefix of the routing instance are automatically exported in mBGP.
this is the complete configuration in the usual form:
The "vrf-table-label" is not required in this case, but serves to ensure the operation of MPLS VPN in Olive, where the forwarding is not PFE assisted.
VRF Definition on IOS
The 6VPE feature introduce a new configuration syntax and keywords with address-family, in this case RD 1:1 is used, while it is necessary to enable the redistribution of connected routes in the BGP process:
Check if everything works as expected
In Junos the routing-instance routing table, are prefixed with the istance name, then the remote prefix fec0:cc1e:6::6/128 are installed in the table named “red.inet6.0”
With a single command I can get all necessary label details:
Top Label = 16 - first hop Transport allocated with RSVP
Inner Label = 32 - VPN Label allocated by mBGP
On the IOS side it is necessary to use multiple commands to collect all the label information, sometimes with misleading results... however this is mainly due to the fact that we only use RSVP and the usually Cisco proposed solutions involve LDP:
The powerful cef “hidden” IOS command
In IOS there is a hidden IOS command “show ipv6 cef internal” used to show a set information very useful for troubleshooting and to understand the solution mechanisms.
IPv4 to IPv6 Mappeed address
In the both cases there is a odd NEXT-HOP address indicated as ::FFFF:10.0.6.2 or ::FFFF:10.0.9.6. This is due to fact that the next-hop address required in the AFI/SAFI ipv6 is still an ipv6 address. In our case this is an IPv4 address ( the PE Loopback ) and this is replaced with IPv4 mapped IPv6 addess.
And in the end the ping...
This waste of energy to run a ping ... hope at least it works:
Conclusions
MPLS and BGP are confirmed two key tools in providing simple and efficient solutions, allowing the transport of any type of traffic without changes to the backbone infrastructure.
BGP session capture here
Final Juniper configuration here
Final R4 configuration here
Final R6 Configuration here
This solution is called 6VPE and introduced on IOS a new configuration syntax for VRF.
Building the control plane
The operations are very similar to a IPv4 MPLS VPN: vpn prefix and label are signaled by mBGP while, LDP and/or RSVP ensure the label signaling necessary to forward MPLS packet throught the backbone.
The lab uses a virtual CE, realized exclusively with a loopback within each of the two PE involved. It thus avoids the entire PE-CE configuration as the purpose of the lab is to exercise on the MPLS component.
Peering mBGP
As vpnv6 signaling uses mBGP, we need to configure an iBGP peering between the two PE. The configuration proposed is minimal, and allows only the signaling of the vpnv6 AF (Address Family).
J2 Juniper PE
The BGP configuration necessarily require the use of a group (equivalent to a cisco peer-group) and the explicit peering type identification (internal vs. external). As previously mentioned only AF inet6-vpn unicast is enabled:
protocols {
bgp {
group iBGP {
type internal;
family inet6-vpn {
unicast;
}
neighbor 10.0.9.6 {
local-address 10.0.6.2;
}
}
}
}
routing-options {
autonomous-system 1;
}[edit logical-systems J2]
nick@zion# show protocols | find mpls
mpls {
ipv6-tunneling; /* enable ipv6 transport */
label-switched-path J2-to-R6 {
to 10.0.9.6;
}
}
R6 PE Cisco
The IOS PE requires a global enable for ipv6 ed ipv6 cef. In the BGP part is avoided the exchange of IPv4 prefixes while vpnv6 peering with a complete community exchange is enabled for J2.
! ipv6 unicast-routing ipv6 cef ! router bgp 1 no bgp default ipv4-unicast neighbor 10.0.6.2 remote-as 1 neighbor 10.0.6.2 update-source Loopback0 ! address-family vpnv6 neighbor 10.0.6.2 activate neighbor 10.0.6.2 send-community both exit-address-family ! !
BGP session
It is always interesting to have a look at the communication capability negotiated BGP: The Open messages include the Multiprotocol Extension AFI (2) and SAFI (120) as indicated in the RFC:
Multiprotocol Extensions for BGP-4 rfc2858
Carrying Label Information in BGP-4 rfc3107
And as assigned by the IANA safi-namespace
The complete capture of BGP communication is here
VRF Configurations on Junos
Until now we have used the logical system of Junos isolating in its own stanza all the configuration statements for the virtual router realized.
The configuration of VRF rather intersects with the main routing instance ( or logical system ) which ensures the communication. The VRF is a particular routing-instance type in which the routing features are configured and the interfaced assigned, however the complete interface configuration remain global.
On J2 the IPv6 address fec0:cc1e:1::1/128 is configured on the new lo0 unit 102.
set logical-systems J2 interfaces lo0 unit 102 family inet6 address fec0:cc1e:1::1/128
then the "red" VRF routing instance is created, with route distinguisher assigned as the 2:2 route-target and 100:100.
set logical-systems J2 routing-instances red instance-type vrf
set logical-systems J2 routing-instances red route-distinguisher 2:2
set logical-systems J2 routing-instances red vrf-target target:100:100
Finally the newly configured unit 102 of the lo0 interface is associated with the routing-instance
set logical-systems J2 routing-instances red interface lo0.102
For those used to work with IOS there is no requirement to explicit configure the "redistribute connected" required to put the prefix in the mBGP table, all the prefix of the routing instance are automatically exported in mBGP.
this is the complete configuration in the usual form:
[edit logical-systems J2]
nick@zion# show interfaces lo0
unit 2 {
family inet {
address 10.0.6.2/32;
}
family iso {
address 49.0000.0000.0002.00;
}
}
unit 102 {
family inet6 {
address fec0:cc1e:1::1/128;
}
}
[edit logical-systems J2]
nick@zion# show | find routing-instance
routing-instances {
red {
instance-type vrf;
interface lo0.102;
route-distinguisher 2:2;
vrf-target target:100:100;
vrf-table-label;
}
}The "vrf-table-label" is not required in this case, but serves to ensure the operation of MPLS VPN in Olive, where the forwarding is not PFE assisted.
VRF Definition on IOS
The 6VPE feature introduce a new configuration syntax and keywords with address-family, in this case RD 1:1 is used, while it is necessary to enable the redistribution of connected routes in the BGP process:
R6#sh run vrf red Building configuration... Current configuration : 354 bytes ! vrf definition red rd 1:1 ! address-family ipv6 route-target export 100:100 route-target import 100:100 exit-address-family ! ! router bgp 1 ! address-family ipv6 vrf red redistribute connected metric 1 no synchronization exit-address-family ! interface Loopback106 vrf forwarding red no ip address ipv6 address FEC0:CC1E:6::6/128 end
Check if everything works as expected
In Junos the routing-instance routing table, are prefixed with the istance name, then the remote prefix fec0:cc1e:6::6/128 are installed in the table named “red.inet6.0”
With a single command I can get all necessary label details:
Top Label = 16 - first hop Transport allocated with RSVP
Inner Label = 32 - VPN Label allocated by mBGP
nick@zion> show route logical-system J2 protocol bgp table red.inet6.0 detail
red.inet6.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
fec0:cc1e:6::6/128 (1 entry, 1 announced)
*BGP Preference: 170/-101
Route Distinguisher: 1:1
Next hop type: Indirect
Next-hop reference count: 3
Source: 10.0.9.6
Next hop type: Router, Next hop index: 885
Next hop: 10.0.4.9 via fxp2.204 weight 0x1, selected
Label-switched-path J2-to-R6
Label operation: Push 32, Push 16(top)
Protocol next hop: ::ffff:10.0.9.6
Push 32
Indirect next hop: 8d98330 131070
State:
Local AS: 1 Peer AS: 1
Age: 27:26 Metric: 1 Metric2: 30
Task: BGP_1.10.0.9.6+20615
Announcement bits (1): 0-KRT
AS path: ?
Communities: target:100:100
Import Accepted
VPN Label: 32
Localpref: 100
Router ID: 10.0.9.6
Primary Routing Table bgp.l3vpn-inet6.0
On the IOS side it is necessary to use multiple commands to collect all the label information, sometimes with misleading results... however this is mainly due to the fact that we only use RSVP and the usually Cisco proposed solutions involve LDP:
R6#sh bgp vpnv6 unicast vrf red FEC0:CC1E:1::1/128
BGP routing table entry for [1:1]FEC0:CC1E:1::1/128, version 11
Paths: (1 available, best #1, table red)
Not advertised to any peer
Local, imported path from [2:2]FEC0:CC1E:1::1/128
::FFFF:10.0.6.2 (metric 30) from 10.0.6.2 (10.0.6.2)
Origin IGP, localpref 100, valid, internal, best
Extended Community: RT:100:100
mpls labels in/out nolabel/16
R6#sh ipv6 cef vrf red FEC0:CC1E:1::1/128 detail
FEC0:CC1E:1::1/128, epoch 0
recursive via 10.0.6.2 label 16
nexthop 10.0.6.2 Tunnel0
R6#sh mpls traffic-eng tunnels tunnel 0 | i Label
InLabel : -
OutLabel : FastEthernet0/0, 299776
The powerful cef “hidden” IOS command
In IOS there is a hidden IOS command “show ipv6 cef internal” used to show a set information very useful for troubleshooting and to understand the solution mechanisms.
R6#show ipv6 cef vrf red internal | b FEC0:CC1E:1::1/128
FEC0:CC1E:1::1/128, epoch 0, RIB[B], refcount 3, per-destination sharing
sources: RIB
feature space:
LFD: FEC0:CC1E:1::1/128 0 local labels
contains path extension list
label switch chain 0x66BA9888
IPRM: 0x00018000
ifnums: (none)
path 659EAE98, path list 659E05F0, share 1/1, type recursive, for IPv6, flags must-be-labelled
MPLS short path extensions: MOI flags = 0x4 label 16
recursive via 10.0.6.2[IPv4:Default] label 16, fib 65A2F590, 1 terminal fib
path 659EAF0C, path list 659E063C, share 1/1, type attached nexthop, for IPv4
MPLS short path extensions: MOI flags = 0x1 label implicit-null
nexthop 10.0.6.2 Tunnel0, adjacency IP midchain out of Tunnel0 65EF2C60
output chain: label 16 label implicit-null TAG midchain out of Tunnel0 65EF2AE0 label 299792 TAG adj out of FastEthernet0/0, addr 10.0.8.6 65EF2DE0
IPv4 to IPv6 Mappeed address
In the both cases there is a odd NEXT-HOP address indicated as ::FFFF:10.0.6.2 or ::FFFF:10.0.9.6. This is due to fact that the next-hop address required in the AFI/SAFI ipv6 is still an ipv6 address. In our case this is an IPv4 address ( the PE Loopback ) and this is replaced with IPv4 mapped IPv6 addess.
And in the end the ping...
This waste of energy to run a ping ... hope at least it works:
nick@zion> ping logical-system J2 routing-instance red fec0:cc1e:6::6on the cisco side:
PING6(56=40+8+8 bytes) fec0:cc1e:1::1 --> fec0:cc1e:6::6
16 bytes from fec0:cc1e:6::6, icmp_seq=0 hlim=64 time=16.438 ms
16 bytes from fec0:cc1e:6::6, icmp_seq=1 hlim=64 time=17.256 ms
16 bytes from fec0:cc1e:6::6, icmp_seq=2 hlim=64 time=11.247 ms
16 bytes from fec0:cc1e:6::6, icmp_seq=3 hlim=64 time=11.361 ms
^C
--- fec0:cc1e:6::6 ping6 statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 11.247/14.076/17.256/2.787 ms
R6#ping vrf red ipv6 fec0:cc1e:1::1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FEC0:CC1E:1::1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/12/20 ms
R6#
Conclusions
MPLS and BGP are confirmed two key tools in providing simple and efficient solutions, allowing the transport of any type of traffic without changes to the backbone infrastructure.
BGP session capture here
Final Juniper configuration here
Final R4 configuration here
Final R6 Configuration here
martedì 5 gennaio 2010
IS-IS and MPLS Integration between Junos and IOS devices
In recent years I have concentrated work and study on Cisco's MPLS platform, but wanting to deepen my knowledge of Junos and test the interoperability between the two platforms, I decided to incorporate a couple of Cisco routers in my lab. I replaced J4 and J6 with two Cisco 7200 routers running IOS version 12.2 SRC.
It's necessary to configure ISIS, forming adjacency, enable the carrying of Traffic Engineering extensions, enable RSVP and LSP signaling ( which in Cisco terminology are often called Traffic Engineering Tunnel ) and finally to enable the forwarding of MPLS Labeled packets.
Starting from my topology JNCIP delete on my Olive router "Zion" the two logical-system J4 and J6:
R4: IP address and IS-IS Routing
The IS-IS configuration is very simple, enable ISIS on the interfaces and set as a point-to-point link, (to avoid DIS election, speed-up and reduce the database).
In the IS-IS process specified the System ID ( "net" entry) define this as an only level-2 router and use the "wide style" mandatory metrics for the TE operation, and finally declare the loopback as passive to include in the topology.
The absence of adjacency depend on hello messages padding introduced for early detection of MTU problems.
The solution proposed is to reduce MTU just for the CLNS packet on the cisco side ( my hardware does not support changing interface MTU )
for example:
you must also enable the extensions required by RFC3784 necessary for TE information exchange, to control band allocation and label signaling via RSVP and finally the process of MPLS labeled packet:
globally enable LSP allocation
this is the complete R4 configuration:
LSP Setup
To verify the effective integration of the two platforms, let's configure two LSP (or TE Tunnels ), one from J2 to R6 and the simmetric from R6 to J2, reminding us that LSPs are always unidirectional.
We will not use any constraint, and hence the LSP will be allocated according to the best IGP metric the result should be:
LSP1 : J2 → R4 → R6 → J4
LSP2 : J5 → R4 → R6 → J2
The J2 configuration is simple:
the LSP is active:
in this type of tunnel there is no “tunnel source”
“autoroute announce” install in the routing table the destination through the tunnel
“path-option 10 dynamic” use just the IGP metric without costrain
IOS has just 1 table and this output can be disorienting (or the different Junos table :-) )
On Junos:
One further note for the Cisco platform that can misleading:
analizing LFIB (Label Forwarding Information Base) used for MPLS packet forwarding on R4 shows "Pop Label"
but this mean ( from Cisco documentation ) :
No Label - Means that there is no label for the destination from the next hop or that label switching is not enabled on the outgoing interface.
** Pop Label ** - Means that the next hop advertised an implicit NULL label for the destination and that the router popped the top label.
Aggregate - Means there are several prefixes for one local label. This entry is used when IPv6 is configured on edge routers to transport IPv6 traffic over an IPv4 MPLS network.
Nothing particularly exciting at this point, only a couple of suggestions like the hello padding ISIS and verification of proper implementation of the two LSPs, it is now time to think about what to do with this two LSPs...
final Zion Configuration here
final R4 Configuration here
final R6 Configuration here
It's necessary to configure ISIS, forming adjacency, enable the carrying of Traffic Engineering extensions, enable RSVP and LSP signaling ( which in Cisco terminology are often called Traffic Engineering Tunnel ) and finally to enable the forwarding of MPLS Labeled packets.
Starting from my topology JNCIP delete on my Olive router "Zion" the two logical-system J4 and J6:
and proceed with the configuration of two new Cisco router:[edit] nick@zion# delete logical-systems J4 [edit] nick@zion# delete logical-systems J6
R4: IP address and IS-IS Routing
The IS-IS configuration is very simple, enable ISIS on the interfaces and set as a point-to-point link, (to avoid DIS election, speed-up and reduce the database).
In the IS-IS process specified the System ID ( "net" entry) define this as an only level-2 router and use the "wide style" mandatory metrics for the TE operation, and finally declare the loopback as passive to include in the topology.
but the adjacencies never come up, remaining in the INIT state:interface Loopback0 ip address 10.0.3.4 255.255.255.255 ! interface FastEthernet0/0 ip address 10.0.4.9 255.255.255.252 ip router isis isis network point-to-point ! interface FastEthernet0/1 ip address 10.0.2.6 255.255.255.252 ip router isis isis network point-to-point ! interface FastEthernet1/0 ip address 10.0.2.10 255.255.255.252 ip router isis isis network point-to-point ! router isis net 49.0000.0000.0004.00 is-type level-2-only metric-style wide passive-interface Loopback0 !
there is a MTU mistmatch, the Zion interface has and CLNS (ISO) MTU of 1493:R4#sh clns neighbors System Id Interface SNPA State Holdtime Type Protocol 0000.0000.0002 Fa0/0 0050.8be3.eb2c Init 24 L2 IS-IS 0000.0000.0003 Fa0/1 0050.8be3.eb2d Init 23 L2 IS-IS 0000.0000.0005 Fa1/0 0050.8be3.eb2c Init 20 L2 IS-IS
nick@zion> show interfaces fxp2.204
Logical interface fxp2.204 (Index 82) (SNMP ifIndex 143)
Description: ------- link ptp J2 <-> J4 --
Flags: SNMP-Traps VLAN-Tag [ 0x8100.204 ] Encapsulation: ENET2
Bandwidth: 0
Input packets : 6673
Output packets: 6931
Protocol inet, MTU: 1496
Flags: None
Addresses, Flags: Is-Preferred Is-Primary
Destination: 10.0.4.8/30, Local: 10.0.4.10, Broadcast: 10.0.4.11
Protocol iso, MTU: 1493
Flags: None
Protocol mpls, MTU: 1484
Flags: None
The absence of adjacency depend on hello messages padding introduced for early detection of MTU problems.
The solution proposed is to reduce MTU just for the CLNS packet on the cisco side ( my hardware does not support changing interface MTU )
alternatively you can use the command "no hello padding" and all its variantsR4#conf t Enter configuration commands, one per line. End with CNTL/Z. R4(config)#int fast 0/0 R4(config-if)#clns mtu 1493 R4(config-if)#int fast 0/1 R4(config-if)#clns mtu 1493 R4(config-if)#int fast 1/0 R4(config-if)#clns mtu 1493 R4(config-if)#^Z
for example:
adjacency is now established and the database is populated ...R4(config)#router isis R4(config-router)#no hello padding point-to-point
R4#sh clns neighbors System Id Interface SNPA State Holdtime Type Protocol zion-J2 Fa0/0 0050.8be3.eb2c Up 25 L2 IS-IS zion-J3 Fa0/1 0050.8be3.eb2d Up 22 L2 IS-IS zion-J5 Fa1/0 0050.8be3.eb2c Up 20 L2 IS-IS
R4#sh ip route isis | B ^Ga
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 22 subnets, 3 masks
i L2 10.0.2.0/30 [115/20] via 10.0.2.9, FastEthernet1/0
[115/20] via 10.0.2.5, FastEthernet0/1
i L2 10.0.3.3/32 [115/10] via 10.0.2.5, FastEthernet0/1
...
you must also enable the extensions required by RFC3784 necessary for TE information exchange, to control band allocation and label signaling via RSVP and finally the process of MPLS labeled packet:
globally enable LSP allocation
enable on all PE facing interface RSVP and MPLS packet processing like:mpls traffic-eng tunnels
estabilish the router-id ( TLV 134 ) and allow the necessary TE TLV exchange on all Level-2 adjacenciesinterface FastEthernet0/0 ip rsvp bandwidth mpls traffic-eng tunnels
router isis mpls traffic-eng router-id Loopback0 mpls traffic-eng level-2
this is the complete R4 configuration:
the R6 configuration is similar and available at the end of this post.! hostname R4 ! mpls traffic-eng tunnels ! interface Loopback0 ip address 10.0.3.4 255.255.255.255 ! interface FastEthernet0/0 ip address 10.0.4.9 255.255.255.252 ip router isis mpls traffic-eng tunnels clns mtu 1493 isis network point-to-point ip rsvp bandwidth ! interface FastEthernet0/1 ip address 10.0.2.6 255.255.255.252 ip router isis mpls traffic-eng tunnels clns mtu 1493 isis network point-to-point ip rsvp bandwidth ! interface FastEthernet1/0 ip address 10.0.2.10 255.255.255.252 ip router isis mpls traffic-eng tunnels clns mtu 1493 isis network point-to-point ip rsvp bandwidth ! router isis net 49.0000.0000.0004.00 is-type level-2-only metric-style wide passive-interface Loopback0 mpls traffic-eng router-id Loopback0 mpls traffic-eng level-2 !
LSP Setup
To verify the effective integration of the two platforms, let's configure two LSP (or TE Tunnels ), one from J2 to R6 and the simmetric from R6 to J2, reminding us that LSPs are always unidirectional.
We will not use any constraint, and hence the LSP will be allocated according to the best IGP metric the result should be:
LSP1 : J2 → R4 → R6 → J4
LSP2 : J5 → R4 → R6 → J2
The J2 configuration is simple:
protocols {
mpls {
label-switched-path J2-to-R6 {
to 10.0.9.6;
}
}
the LSP is active:
the destination is installed in inet.3nick@zion> show mpls lsp ingress logical-system J2 Ingress LSP: 1 sessions To From State Rt P ActivePath LSPname 10.0.9.6 10.0.6.2 Up 0 * J2-to-R6 Total 1 displayed, Up 1, Down 0
nick@zion> show route 10.0.9.6 logical-system J2
inet.0: 21 destinations, 21 routes (21 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.9.6/32 *[IS-IS/18] 00:51:24, metric 30
> to 10.0.4.1 via fxp2.203
to 10.0.4.9 via fxp2.204
inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.9.6/32 *[RSVP/7] 00:49:32, metric 30
> to 10.0.4.9 via fxp2.204, label-switched-path J2-to-R6
nick@zion> show route 10.0.9.6 logical-system J2 table inet.3 extensive | match Label
Label-switched-path J2-to-R6
Label operation: Push 16
in IOS LSP is usually called “TE Tunnel” and configured as a tunnel interface: some notes about the configuration:interface Tunnel0 ip unnumbered Loopback0 tunnel destination 10.0.6.2 tunnel mode mpls traffic-eng tunnel mpls traffic-eng autoroute announce tunnel mpls traffic-eng path-option 10 dynamic !
in this type of tunnel there is no “tunnel source”
“autoroute announce” install in the routing table the destination through the tunnel
“path-option 10 dynamic” use just the IGP metric without costrain
show 2 tunnels “UP/UP”, one head and one tail.R6#sh mpls traffic-eng tunnels brief | b ^TU TUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROT R6_t0 10.0.6.2 - Fa0/0 up/up J2-to-R6 10.0.9.6 Fa0/0 - up/up Displayed 1 (of 1) heads, 0 (of 0) midpoints, 1 (of 1) tails
IOS has just 1 table and this output can be disorienting (or the different Junos table :-) )
R6#sh ip route 10.0.6.2
Routing entry for 10.0.6.2/32
Known via "isis", distance 115, metric 30, type level-2
Redistributing via isis
Last update from 10.0.6.2 on Tunnel0, 00:55:05 ago
Routing Descriptor Blocks:
* 10.0.6.2, from 10.0.6.2, via Tunnel0
Route metric is 30, traffic share count is 1
Also on the transit router can control the LSP allocatedR6#sh mpls traffic-eng tunnels tunnel 0 | i Label InLabel : - OutLabel : FastEthernet0/0, 299888
On Junos:
and on Cisco:nick@zion> show mpls lsp logical-system J5 Ingress LSP: 0 sessions Total 0 displayed, Up 0, Down 0 Egress LSP: 0 sessions Total 0 displayed, Up 0, Down 0 Transit LSP: 2 sessions To From State Rt Style Labelin Labelout LSPname 10.0.6.2 10.0.9.6 Up 1 1 SE 299888 17 R6_t0 10.0.9.6 10.0.6.2 Up 1 1 FF 299872 0 J2-to-R6 Total 2 displayed, Up 2, Down 0
In both cases the special label "implict-null" is used in place of PHP (Penultimate Hop Popping) because TE operations usually use the EXP Bit for traffic classification, which for some traffic reclassification may be different from the IP Precedence of the transported package ( and obviously also the traffic can not be IP... )R4#sh mpls traffic-eng tunnels brief | b ^TU TUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROT J2-to-R6 10.0.9.6 Fa0/0 Fa1/0 up/up R6_t0 10.0.6.2 Fa1/0 Fa0/0 up/up Displayed 0 (of 0) heads, 2 (of 2) midpoints, 0 (of 0) tails R4#sh mpls traffic-eng tunnels | i Tunnel|Label LSP Tunnel J2-to-R6 is signalled, connection is up InLabel : FastEthernet0/0, 16 OutLabel : FastEthernet1/0, 299872 LSP Tunnel R6_t0 is signalled, connection is up InLabel : FastEthernet1/0, 17 OutLabel : FastEthernet0/0, implicit-null
One further note for the Cisco platform that can misleading:
analizing LFIB (Label Forwarding Information Base) used for MPLS packet forwarding on R4 shows "Pop Label"
R4#sh mpls forwarding-table
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or VC or Tunnel Id Switched interface
16 299872 10.0.6.2 12053 [1] \
0 Fa1/0 10.0.2.9
17 Pop Label 10.0.9.6 0 [248] 0 Fa0/0 10.0.4.10
but this mean ( from Cisco documentation ) :
No Label - Means that there is no label for the destination from the next hop or that label switching is not enabled on the outgoing interface.
** Pop Label ** - Means that the next hop advertised an implicit NULL label for the destination and that the router popped the top label.
Aggregate - Means there are several prefixes for one local label. This entry is used when IPv6 is configured on edge routers to transport IPv6 traffic over an IPv4 MPLS network.
Nothing particularly exciting at this point, only a couple of suggestions like the hello padding ISIS and verification of proper implementation of the two LSPs, it is now time to think about what to do with this two LSPs...
final Zion Configuration here
final R4 Configuration here
final R6 Configuration here
Iscriviti a:
Post (Atom)