In recent years, the concepts of Artificial Intelligence (AI) and Machine Learning (ML)...
1.2.4 IRP Operating modes
The IRP platform can operate in two modes, which can be used at different stages of the deployment process. During the initial installation and configuration, it is recommended for the system not to inject any improvements into the network until the configuration is completed.
After running several route propagation tests, the system can be switched to the full Intrusive mode.
1.2.4.1 Non-intrusive mode #
1.2.4.2 Intrusive mode #
1.2.4.3 Going Intrusive #
The highlights of the process are as follows:
- The optimizing component of IRP (Core) is taken offline and existing improvements are purged. The Core being offline guarantees IRP will not automatically insert new improvements into its Current Improvement table and hinder the Go Intrusive process.
Listing 1.1: Stop IRP Core and purge existing improvements
root@server ~ $ systemctl stop core.service root@server ~ $ mysql irp -e ’delete from improvements;’
- Enable Intrusive Mode and adjust IRP Core and BGPd parameters as follows:
root@server ~ $ nano /etc/noction/irp.conf global.nonintrusive_bgp = 0 core.improvements.max = 100 bgpd.improvements.remove.next_hop_eq = 0 bgpd.improvements.remove.withdraw = 0
- Improvements towards test networks are introduced manually so that client’s traffic is not affected. The improvements are chosen so that they cover all client’s providers. Any public networks could be used for test purposes. Just keep in mind that preferably your network shouldn’t have traffic with chosen test network in order to do not re-route the real traffic. Use the template below in order to insert the test improvements:
Listing 1.3: Inserting test improvements
mysql> insert into improvements
(ni_bgp, prefix, peer_new, ipv6, asn)
values
(0, ’10.10.10.0/24’, 1, 0, 48232),
(0, ’10.10.11.0/24’, 2, 0, 48232),
(0, ’10.10.12.0/24’, 3, 0, 48232);
- Make sure that ’route-reflector-client’ is set for IRP BGP session.
- Make sure that ’next-hop-self’ is not configured for IRP BGP session.
- On iBGP sessions (between edge routers, route-reflectors; except session with IRP) where ’next-hop-self’ is configured, the following route-map should be applied:
Listing 1.4: Remove next-hop-self route-map (RM-NHS) example
route-map RM-NHS set ip next-hop peer-address neighbor X.X.X.X route-map out RM-NHS
- Use the commands below to restart IRP BGPd to use actual IRP configuration and establish BGP session(s) and verify if BGP updates are being announced:
Listing 1.5: Restart IRP Bgpd
root@server ~ $ systemctl restart bgpd.service root@server ~ $ tail -f /var/log/irp/bgpd.conf
Wait for the following lines for each BGP session:
NOTICE: Adding peer X NOTICE: BGP session established X INFO: N update(s) were sent to peer X
where X is the router name and N is the number of the updates sent towards the X router.
- Verify if IRP BGP announcements are properly propagated across all the network. Run the following commands on each router (the commands vary depends on the router brand):
Listing 1.6: Show BGP information for specified IP address or prefix
show ip bgp 10.10.10.1 show ip bgp 10.10.11.1 show ip bgp 10.10.12.1
Analyze the output from all the routers. If the IRP BGP announcements are properly propagated, you should see /25 (refer to bgpd.updates.split) announcements and the next-hop for each announcement should be the improved provider’s next-hop:
10.10.10.1 – provider 1 next-hop
10.10.11.1 – provider 2 next-hop
10.10.12.1 – provider 3 next-hop
(refer to peer.X.ipv4.next_hop, peer.X.ipv6.next_hop, provider.X.rule.Y.next_hop)
Run the following commands in order to check if IRP improvements are announced and applied:
Listing 1.7: Traceroute destination networks
root@server ~ $ traceroute -nn 10.10.10.1
root@server ~ $ traceroute -nn 10.10.11.1
root@server ~ $ traceroute -nn 10.10.12.1
Again, you should see corresponding providers’ next-hops in the traces.
-
If the tests are successful perform the steps below: #
(a) Delete test improvements
Listing 1.8: Delete test improvements
root@server ~ $ mysql -e "delete from improvements where prefix like ’10.10.1%’;"
(b) Configure at most 100 improvements and revert BGPd configuration
Listing 1.9: Configure the maximum improvements limit and revert Bgpd configuration
root@server ~ $ nano /etc/noction/irp.conf core.improvements.max = 100 bgpd.improvements.remove.next_hop_eq = 1 bgpd.improvements.remove.withdraw = 1
root@server ~ $ systemctl restart bgpd core
- If everything goes well, after 1-2 hours the maximum number of improvements announced is increased to 1000 and after 24 hour to 10000.
As a rollback plan we have to revert the changes and switch the system to non-intrusive mode: #
- Delete test improvements
Listing 1.11: Delete test improvements
root@server ~ $ mysql -e "delete from improvements where prefix like ’10.10.1%’;"
- Switch the system to non-intrusive mode
Listing 1.12: Switch the system to non-intrusive mode
root@server ~ $ nano /etc/noction/irp.conf
global.nonintrusive_bgp = 1
- Restart IRP Core and BGPd
Listing 1.13: Restart IRP Core and Bgpd
root@server ~ $ systemctl restart bgpd core