Beginning in software release 4.1 for the VSP 4000/8000, 4.2.1 for the VSP 7200, and release 4.0 for the VSP 9000, IS-IS accept policies for IPv4 is introduced. Prior to this release, the ISIS IPv4 routes received over the SPB cloud are installed directly into the routing table. There is no ability to filter those routes and apply incoming route policies to them. Hence, networks that are being migrated from other routing protocols to ISIS/SPB are vulnerable to routing loops. ISIS accept policy functionality provides a way to avoid such loops.
You can create an IS-IS accept policy for the Global Routing Table (GRT) or a Virtual Routing and Forwarding (VRF) instance. You can create an IS-IS accept policy on a switch that operates at a global default level or for a specific advertising BEB. You can also use the filter mechanism for ISIS accept policies to redistribute routes between different VRFs, or between a VRF and the GRT.
ISIS policies can also use either a service instance identifier (ISID) or an ISID list to filter incoming traffic. For inter-VRF route redistribution, an ISID value of 0 represents the GRT. For inter-VRF route redistribution between VRFs, the ISID is the source VRF (or remote VRF).
You can filter traffic with ISIS accept policies by:
- advertising BEB (nick-name)
- ISID or ISID list (ISID take precedence over an ISID list)
You can use IS-IS accept policies to apply at a global default level for all advertising Backbone Edge Bridges (BEBs) or for a specific advertising BEB.
IS-IS accept policies also allow you to use either a service instance identifier (ISID) or an ISID list to filter routes. The switch uses ISIDs to define Virtual Services Networks (VSNs). ISIDs identify and transmit virtualized traffic in an encapsulated SPBM frame. IS-IS accept policies can use ISIDs or ISID lists to filter the incoming virtualized traffic.
IS-IS accept policies can also apply route policies to determine what incoming traffic to accept into the routing table. With route policies the device can determine which routes to accept into the routing table based on the criteria you configure, which can give precedence to advertised routes from a particular protocol, route-source, route-type, or through other criteria.
Note: The ERS 8800 does not support ISIS accept policies.
o There is no way to prevent one border router from accepting ISIS routes from the other border router
o The solution is to make OSPF preferred over ISIS by assigning ISIS a higher route preference over OSPF
We can now use OSPF accept policies to prevent one border router from accepting OSPF external routes from another
In some situations a router may advertise routes into ISIS from OSPF and overwrite routes which are in OSPF. One option is to increase the IP route preference of ISIS from default value 7 to 130 which is higher than OSPF routes making OSPF more favourable.
ip route preference protocol spbm-level1 130
Alternatively, if the platform allows, use ISIS accept policy to control what is learnt. Increasing the ip route preference is required with ERS 8000 as it does not support ISIS accept policies. It can also be useful to change the route preference during migrations and set back to default when required.
Also, when using IP shortcuts and redistribution of ISIS and OSPF it is recommended to disable ip alternative-routes.
no ip alternative-route
It is sometimes necessary to suppress the IST subnet when redistributing direct into ISIS on the cluster routers.
ip prefix-list “ist” 10.199.1.0/30 id 1 ge 30 le 30
route-map “suppress-ist” 1
match network “ist”
route-map “suppress-ist” 2
redistribute direct route-map “suppress-ist”
redistribute direct enable
isis apply redistribute direct
It is sometimes necessary to control which routes are advertised from OSPF into ISIS. This can be achieved by using a route-map when redistributing OSPF into ISIS.
ip prefix-list “access-nets” 0.0.0.0/0 id 2 ge 0 le 32
ip prefix-list “access-nets” 192.168.10.0/24 id 2 ge 24 le 24
ip prefix-list “access-nets” 192.168.20.0/24 id 2 ge 24 le 24
route-map “announce-access-nets” 1
match network “access-nets”
set injectlist “access-nets”
set metric-type type2
redistribute ospf route-map “announce-access-nets”
redistribute ospf enable
isis apply redistribute ospf
It is possible for the cluster routers to advertise an ISIS route into OSPF and overwrite the ISIS learnt routes on the peer router. To avoid this from occurring use a route map to reject routes from the peer OSPF router-ID.
R1 and R2:
route-map “reject” 1
accept adv-rtr 10.255.0.2 enable route-map “reject”
ip ospf apply accept adv-rtr 10.255.0.2
accept adv-rtr 10.255.0.1 enable route-map “reject”
ip ospf apply accept adv-rtr 10.255.0.1
Ever wondered why certain routes do not appear in the OSPF LSDB? The GRT shows routes but you do not see them when check the LSDB. In the example topology below R1 and R2 have learnt OSPF_INTRA (preference 20) and OSPF_E2 (preference 125) routes from R3. Checking the OSPF LSDB we see the ASExternal routes but not the OSPF_INTRA routes.
R3 has several loopback / CLIP addresses to simulate external networks. CLIP 2 192.168.10.1/24 and CLIP 4 192.168.30.1/24 have IP OSPF Enabled and CLIP 3 192.168.20.1/24 does not have IP OSPF Enabled. OSPF redistributes direct into OSPF.
This means we have some OSPF_INTRA routes and OSPF_E2 routes advertised by R3.
On R1 or R2 type show ip ospf lsdb adv-rtr 10.255.0.6 detail to see Router Link LSAs and ASExternal LSAs.