TE Tunnel with Conditional Attributes
Load mpls.te.base.config.with.ospf.and.affinity.cfg
#IOS-XE
config replace flash:mpls.te.base.config.with.ospf.and.affinity.cfg
#IOS-XR
configure
load bootflash:mpls.te.base.config.with.ospf.and.affinity.cfg
commit replace
y
Configure a bidirectional tunnel between CSR8 and XR11 that achieves the following:
Uses signalled bandwidth of 100M and only BLUE links
If 100M isn’t available, then the path should attempt to come up with 0 bandwidth
If BLUE links aren’t available, the path should attempt to come up with 0 bandwidth and no affinity constraints
Answer
Explanation
The LSP attribute set feature allows you to apply attributes to individual path-options instead of to the TE tunnel as a whole. This allows you to do complex logic such as “if the previous path-option is not valid, try with affinity set to <value>.” You can have the router try to remove constraints as previous path-options fail. This can allow the TE tunnel to always be up, even if, for example, someone accidentally removes affinity values from a router in the network.
On IOS-XE, this is accomplised using the following configuration:
IOS-XE also allows you to specify only the bandwidth attribute without needing a separate attribute set. Note that when you use this, if the associated path-option is active, the router will attempt to reoptimize the tunnel every 30 seconds to try to satisfy the original bandwidth constraint. This allows for the tunnel to at least be up in case bandwidth cannot be satisfied, but to actually reserve the bandwidth as soon as possible when it becomes available again.
On IOS-XR, this is accomplished similarly using an attribute-set. Note that IOS-XR doesn’t support as many features with the attribute-set. The major ones are just signalled-bandwidth and affinity.
To meet the task requirements, we set the affinity and bandwidth for the tunnel to 0x4/0x4 and 100M. Path-option 1 attempts to calculate a dynamic path. Path-option 2 uses zero bandwidth. Path-option 3 uses 0x0/0x0 affinity and zero bandwidth.
Verification
When all links are up, CSR8 should be able to use the first path-option:
If we change all of CSR8’s interfaces to only have 50M available bandwidth, path-option 1 should fail, and path-option 2 should succeed. Notice below that the requested bandwidth on the tunnel when path-option 2 is used is now zero.
Lastly, we can change CSR8’s local interfaces no not belong to affinity “BLUE” (0x4). This should cause path-option 2 to fail and path-option 3 should be used. Notice below that the affinity has changed to 0x0/0x0.
We can also test this on XR11. By default, path-option 1 is used.
If we change XR11’s available bandwidth on all local interfaces to less than 100M, path-option 1 should fail.
If we remove XR11’s BLUE affinity from local links, path-option 2 should fail and path-option 3 should be used.
Last updated