BGP SDN

Posted: June 12, 2017 in BGP, Routing, SDN

BGP SDN enables central control over distributed routing.
This is based on routing protocol BGP and its ability to signal third party next hop using policy based routing.

We are using standard community to set next-hop which will define path to reach destination

This approach is kind of similar to Fibbing: OSPF and SDN (Hybrid model) where we set third party next hop with help of LSA5

All devices are running EBGP with each other via directly connected interface and controller will speak IBGP with every router
Controller can be any device which is capable of speaking BGP . I am using Cisco router and local-as feature to form IBGP with all routers as controller. In below diagram R5 is contoller

BGP SDN NEW

When we try to reach IP 100.100.100.l00 from IP 40.40.40.40 we have 1 path available via path R4-R2-R1(marked with blue line)
R1 before

R2 before

R3 before

R4 before

Before Trace

Now with help of controller R5 I am sending 100.100.100.100 prefix to all routers with community set to {4:2 2:3 3:1} and local preference set to 120
we can move the traffic from IP 40.40.40.40 to IP 100.100.100.100 via path R4-R2-R3-R1(marked with red line).

These communities are user defined and locally significant to the router mapped with next hop value
e.g if you want move packet from AS4 to AS2 set community 4:2 (this community is local to R4) in controller and next hop will be set to 24.0.0.2 once R4 receives the update.
similarly to move packet frmo AS2 to AS3 set community 2:3 in controller and next hop will be set to 24.0.0.2 once R4 receives the update.

R1 after

R2 after

R3 after

R4 after

After trace

Please check below link for more information
http://blog.ipspace.net/2013/10/exception-routing-with-bgp-sdn-done.html

Advertisements

Fibbing is an architecture that enables central control over distributed routing.
http://fibbing.net/

This architecture is based on routing protocol OSPF and its ability to set third party next-hop with some tweak

Main trick is to create multiple LSA5 for same destination with Forward address set to IP addresses which will define path to reach destination

In LSA 5 forwarding address is set to 0.0.0.0
if the ASBR redistributes routes and OSPF is not enabled on the next hop interface for those routes

In LSA 5 forwarding address is set to non-zero address if
*OSPF is enabled on the ASBR’s next hop interface AND
*ASBR’s next hop interface is non-passive under OSPF AND
*ASBR’s next hop interface is not point-to-point AND
*ASBR’s next hop interface is not point-to-multipoint AND
*ASBR’s next hop interface address falls under the network range specified in the router OSPF command.

Controller speaks OSPF with rest of the OSPF enabled network and in turn push LSA 5 with third party next hop to influence routing centrally.
Controller can be simple computer which is capable of running OSPF and able to push LSA 5 as per our need.

For our demonstration I am using cisco router as controller. Below is the topology diagram in which R5 and switch is part of controller
We are using Secondary IP address which will resolve the third party next hop set by controller

Fibbing Topology

When we try to reach IP 100.100.100.l00 from IP 40.40.40.40 we have 2 path available one via path R4-R2-R1 and other one via R4-R3-R1(marked with blue line)
R4 Before

R1 Before

R4 Before traceroute

Now with help of controller R5 we can move the traffic from IP 40.40.40.40 to IP 100.100.100.100 via path R4-R3-R2-R1(marked with red line)
R1 after

R2 after

R3 after

R4 after

R4 after traceroute

R4 after database

Please check below link for more information
http://fibbing.net/
http://blog.ipspace.net/2015/11/fibbing-ospf-based-traffic-engineering.html
https://blog.ecitele.com/fibbing-and-sdn

In VRF-lite situation multiple customers are connected to the same CE (each customer belongs to different vrf)
Now in this design wan circuit is moving from old PE to new PE.

During this bulk migration we need to replace static route pointing to OLD PE and with static route pointing to new PE for every customer

This migration related Pre and Post data such as vrf,CE wan ip,customer name,PE name etc. is recorded in excel sheet

With help of library xlrd , ciscoconfparse we can automate the script generation for static route which can be used during migration

we are reading all info for each VRF such as (VRF,OLD_WAN_IP,NEW_WAN_INT) by running FOR Loop on excel and storing it in dictionary

e.g Below 2 static routes needs to be replaced with new wan interface and new wan IP

ip route vrf ABC 10.10.10.10 255.255.255.255 Serial1/0.10 192.168.1.1
ip route vrf ABC 10.10.10.20 255.255.255.255 Serial1/0.10 192.168.1.1

Logic for the python code is
1. Get the static routes from router config for each vrf (one by one) using OLD wan IP (regular expression)
2. Take one IP route at a time and create list using split method so we will get 8 elements in list from 0-7
3. Pop the elements from the list till list contains only 6 elements from 0-5 (remove old interface and old wan ip)
4. Append new wan interface and then new wan PE IP to the list
5. Prepend no to the old static route and print it
6. Using join method on the list create new static route pointing to new wan IP and interface and print it

output is

no ip route vrf ABC 10.10.10.10 255.255.255.255 Serial1/0.10 192.168.1.1
ip route vrf ABC 10.10.10.10 255.255.255.255 FastEthernet0/1.10 192.168.2.1
!

no ip route vrf ABC 10.10.10.20 255.255.255.255 Serial1/0.10 192.168.1.1
ip route vrf ABC 10.10.10.20 255.255.255.255 FastEthernet0/1.10 192.168.2.1
!

python code for static route script for bulk migration.

import xlrd
from ciscoconfparse import CiscoConfParse

# provide config file path
routerconfig = CiscoConfParse(configfilepath)
wanip = c[‘OLD_WAN_IP’].split(“.”)

# result [192,168,1,1]
wanipregex = “\.”.join(wanip)
# result 192\.168\.1\.1
a = “^ip route vrf ” + c[‘VRF’] +”(.+?)” + wanipregex
# result ^ip route vrf ABC(.+?)192\.168\.1\.1

# running for loop over list of static routes for vrf ABC 2 routes in this case
for staticroute in routerconfig.find_objects(a):
line = staticroute.text

sroute = line.split(” “)
# result [ip, route, vrf, ABC, 10.10.10.10, 255.255.255.255, Serial1/0.10, 192.168.1.1]

while len(sroute) > 6:
sroute.pop()

# result [ip, route, vrf, ABC, 10.10.10.10, 255.255.255.255]

sroute.append(c[‘NEW_WAN_INT’])
# result [ip, route, vrf, ABC, 10.10.10.10, 255.255.255.255,FastEthernet0/1.10,]
sroute.append(c[‘NEW_PE_WAN_IP’])
#result [ip, route, vrf, ABC, 10.10.10.10, 255.255.255.255, FastEthernet0/1.10, 192.168.2.1]
print “no ” + line
# result no ip route vrf ABC 10.10.10.10 255.255.255.255 Serial1/0.10 192.168.1.1
print ” “.join(sroute)
# result ip route vrf ABC 10.10.10.10 255.255.255.255 FastEthernet0/1.10 192.168.2.1
print “!”

Netmiko is Multi-vendor library to simplify Paramiko SSH connections to network devices with the help of netmiko library we can do network automation using python
https://github.com/ktbyers/netmiko

In some situations we can not directly connect to network devices like router and switches. We can only access them via jump server
If we have Linux machine from where are initiating ssh connection and jump server is also Linux

Linux(script server)—–Linux(jump server)—–Router

Then we can use Linux ProxyCommand to access devices via jump server.
Below link provides detail for Netmiko SSH Proxy Support
https://pynet.twb-tech.com/blog/automation/netmiko-proxy.html

But we can not use proxycommand if script server is windows

windows(script server)—–Linux(jump server)—–Router

Below code can be use in this situation
In this code i tried to get device up time via jump server using redispatch(Netmiko 1.3.0 Release). Need to adjust global_delay_factor by doing trail and error method

from netmiko import ConnectHandler
import time
from netmiko import redispatch

jumpserver = {‘device_type’: ‘terminal_server’,’ip’: ‘x.x.x.x’,’username’: ‘name’,’password’: ‘pass’,’global_delay_factor’:5}

net_connect = ConnectHandler(**jumpserver)
print net_connect.find_prompt()

net_connect.write_channel(‘command to access router’)
time.sleep(1)
net_connect.read_channel()

redispatch(net_connect, device_type=’cisco_ios’)
net_connect.send_command(‘show version | i uptime’)

Rules for IS-IS Adjacencies

Posted: February 20, 2016 in IS-IS

• L1 routers form L1 adjacency with L1 and L1-L2 routers in their area.(R1 only form L1 neighborship with R2 which is L1-L2 router and belongs to same area 49.0000)

• L2 routers form L2 adjacency with L2 and L1-L2 routers in their area or another area.(R4 forms L2 neighborship with R2 and R3 which is L1-L2 router but R2 belongs to area 49.0000 and R3 belongs to 49.0001)

• L1-L2 routers form L1 and L2 adjacency with each other in their area and only L2 adjacency in another area.(R2 and R3 area L1-L2 routers but belongs to different area so they just form L2 adjacency)

• An L1 router does not form an adjacency with an L2 router, regardless of area.(R1 doesn’t form neighborship with R4 even if they are from same area 49.0000)

• The system ID must be unique to each router regardless of area(System ID are different for each router it acts like router-id must be unique)

• Hello intervals and hold times do not have to match.(Hello timer is changed on R2 and R3 still neighborship is up with other routers)

• Network type should match to form neighborship.(if we configure command ‘isis network point-to-point’ on R2  all neighborships will go down)

• TO check IS-IS neighborship commands area
#sh isis nei
#sh clns nei

Below output and configuration of 4 routers connected to same L2 switch with interface Fa0/0 and IP address configured on it is 12.0.0.x/24 (where x is router number)
R1 – L1 router; R2 – L1-L2 router; R3 – L1-L2 router; R4 – L2 router
Only R3 belongs to different area 49.0001 and rest of the routers belongs to area 49.0000

R1#  sh isis nei
System Id      Type Interface   IP Address      State Holdtime Circuit Id
R2             L1   Fa0/0       12.0.0.2        UP    25       R2.01
R1#  sh run | sec is
ip router isis
router isis
net 49.0000.0000.0000.0001.00
is-type level-1
R1#

R2#  sh isis nei
System Id      Type Interface   IP Address      State Holdtime Circuit Id
R1             L1   Fa0/0       12.0.0.1        UP    28       R2.01
R3             L2   Fa0/0       12.0.0.3        UP    115      R4.01
R4             L2   Fa0/0       12.0.0.4        UP    8        R4.01
R2#  sh run | sec is
ip router isis
isis hello-multiplier 4
isis hello-interval 20
router isis
net 49.0000.0000.0000.0002.00
R2#

R3#  sh isis nei
System Id      Type Interface   IP Address      State Holdtime Circuit Id
R2             L2   Fa0/0       12.0.0.2        UP    78       R4.01
R4             L2   Fa0/0       12.0.0.4        UP    8        R4.01
R3#  sh run | sec is
ip router isis
isis hello-multiplier 4
isis hello-interval 30
router isis
net 49.0001.0000.0000.0003.00
R3#

R4#  sh isis nei
System Id      Type Interface   IP Address      State Holdtime Circuit Id
R2             L2   Fa0/0       12.0.0.2        UP    65       R4.01
R3             L2   Fa0/0       12.0.0.3        UP    119      R4.01
R4#  sh run | sec is
ip router isis
router isis
net 49.0000.0000.0000.0004.00
is-type level-2-only
R4#

Different types of tables in BGP

Posted: February 18, 2016 in BGP

There are three types of tables in BGP

Adj-RIBs-In – Unprocessed (without applying any filtering or attribute manipulation )routing information received from neighbor.
Loc-RIB – Best routes selected after applying routing policies on the routes available in Adj-RIBs-In
Adj-RIBs-Out – Routes selected from Loc-RIB after applying outbound routing policies.

Above mentioned tables can be verified using below commands
show ip bgp neighbor x.x.x.x advertise-routes – Adj-RIBs-Out
show ip bgp – Loc-RIB
show ip bgp neighbor x.x.x.x received-routes – Adj-RIBs-In

Best route selection process

Posted: February 13, 2016 in Routing

How best route is selected when there are multiple route available for same destination

1. Longest prefix match (more specific route)

e.g. destination is 10.10.10.10 and route available are
10.10.10.10/32 nexthop Se1/0
10.10.10.0/24 nexthop Se1/1
in this case route via nexthop Se1/0 will be preferred
2. Compare AD value (lower AD value is better)

3. Compare the metric (lower metric is better)

if AD is same and route is learned via same routing protocol then
selection is done by comparing metric.
4. Compare routing protocol preference

(AD value is same and but route are learned via different routing protocol)
connected > static > BGP > eigrp > ospf > isis


e.g. First condition if we have route 10.10.10.0/24 learned via ospf (110)and eigrp(90) (AD value is not modified for both protocol) route via eigrp will be selected


Second condition if we have route 10.10.10.0/24 learned via ospf (90)and eigrp(90) (AD value is modified for ospf and its equal to eigrp AD value 90) still route via eigrp will be preferred based on predefined routing protocol preference

Third condition if we have route 10.10.10.0/24 learned via ospf (89)and eigrp(90) (AD value is modified for ospf and its less than eigrp AD value) route via ospf will be selected based on lowest AD value