Monday, 14 March 2011

The power of access-lists

Today let's talk about access-lists. In many books we can easily find the statements, that prefix-lists are much convenient than access-lists. With prefix-lists, using ge and/or le gives more flexibility. For example imagine, that you have 5 networks: 10.0.0.0/24, 10.0.1.0/25, 10.0.1.128/25, 10.0.2.0/26, 10.0.2.128/25. Next, you want to permit only these networks with prefix length of 25. You can use a simple prefix-list command:

ip prefix-list FILTER permit 10.0.0.0/16 ge 25 le 25

whereas you need to use 3 (or 2) different lines with access-list:

access-list 1 permit 10.0.1.0 0.0.0.127
access-list 1 permit 10.0.1.128 0.0.0.127
access-list 1 permit 10.0.2.128 0.0.0.127

or

access-list 1 permit 10.0.1.0 0.0.0.255
access-list 1 permit 10.0.2.128 0.0.0.127


In this example the difference is small, but with more than 50 lines, using standard access-lists can be daunting. However extended access-lists are much more powerful.

For this example, I will use 2 routers directly connected with EIGRP:


R2 has 10 loopbacks with different networks which are being advertised to R1 via EIGRP:

R2#show ip interface | include 192
  Internet address is 192.168.0.1/24
  Internet address is 192.168.1.1/25
  Internet address is 192.168.1.129/25
  Internet address is 192.168.2.1/26
  Internet address is 192.168.2.65/27
  Internet address is 192.168.2.129/27
  Internet address is 192.168.3.1/28
  Internet address is 192.168.3.65/28
  Internet address is 192.168.3.129/29
  Internet address is 192.168.3.161/29


R1#show ip route eigrp
D    192.168.0.0/24 [90/2297856] via 10.0.0.1, 00:01:08, Serial0/0
     192.168.1.0/25 is subnetted, 2 subnets
D       192.168.1.0 [90/2297856] via 10.0.0.1, 00:00:48, Serial0/0
D       192.168.1.128 [90/2297856] via 10.0.0.1, 00:00:48, Serial0/0
     192.168.2.0/24 is variably subnetted, 3 subnets, 2 masks
D       192.168.2.64/27 [90/2297856] via 10.0.0.1, 00:00:48, Serial0/0
D       192.168.2.0/26 [90/2297856] via 10.0.0.1, 00:00:48, Serial0/0
D       192.168.2.128/27 [90/2297856] via 10.0.0.1, 00:00:48, Serial0/0
     192.168.3.0/24 is variably subnetted, 4 subnets, 2 masks
D       192.168.3.64/28 [90/2297856] via 10.0.0.1, 00:00:48, Serial0/0
D       192.168.3.0/28 [90/2297856] via 10.0.0.1, 00:00:48, Serial0/0
D       192.168.3.160/29 [90/2297856] via 10.0.0.1, 00:00:48, Serial0/0
D       192.168.3.128/29 [90/2297856] via 10.0.0.1, 00:00:48, Serial0/0
R1#show ip route summary | include eigrp
eigrp 1         1           9           720         1280



We see, that everything works. Now we would like to send to R1 only these prefixes with network length of 27 or more. We will do this using either the prefix-list or extended ACL, and in each case we will use one single matching-command!

First, let's do this using prefix-list:

R2#conf t
R2(config)#ip prefix-list PREF1 permit 192.168.0.0/16 ge 27
R2(config)#route-map PREFOUT1 permit 10
R2(config-route-map)#match ip address prefix-list PREF1
R2(config-route-map)#exit
R2(config)#router eigrp 1
R2(config-router)#distribute-list route-map PREFOUT1 out


And on R1 we've got:


R1#show ip route eigrp
     192.168.2.0/27 is subnetted, 2 subnets
D       192.168.2.64 [90/2297856] via 10.0.0.1, 00:04:30, Serial0/0
D       192.168.2.128 [90/2297856] via 10.0.0.1, 00:04:30, Serial0/0
     192.168.3.0/24 is variably subnetted, 4 subnets, 2 masks
D       192.168.3.64/28 [90/2297856] via 10.0.0.1, 00:04:30, Serial0/0
D       192.168.3.0/28 [90/2297856] via 10.0.0.1, 00:04:30, Serial0/0
D       192.168.3.160/29 [90/2297856] via 10.0.0.1, 00:04:30, Serial0/0
D       192.168.3.128/29 [90/2297856] via 10.0.0.1, 00:04:30, Serial0/0
R1#show ip route summary | include eigrp
eigrp 1         0           6           432         768


Now, let's do the same using ACL:


R2#conf t
R2(config)#access-list 100
permit ip 192.168.0.0 0.0.255.255 255.255.255.224 0.0.0.31
R2(config)#route-map ACLOUT1 permit 10
R2(config-route-map)#match ip address 100
R2(config-route-map)#exit
R2(config)#router eigrp 1
R2(config-router)#distribute-list route-map ACLOUT1 out


And what we get on R1? The same!

R1#show ip route eigrp
     192.168.2.0/27 is subnetted, 2 subnets
D       192.168.2.64 [90/2297856] via 10.0.0.1, 00:12:49, Serial0/0
D       192.168.2.128 [90/2297856] via 10.0.0.1, 00:12:49, Serial0/0
     192.168.3.0/24 is variably subnetted, 4 subnets, 2 masks
D       192.168.3.64/28 [90/2297856] via 10.0.0.1, 00:12:49, Serial0/0
D       192.168.3.0/28 [90/2297856] via 10.0.0.1, 00:12:49, Serial0/0
D       192.168.3.160/29 [90/2297856] via 10.0.0.1, 00:12:49, Serial0/0
D       192.168.3.128/29 [90/2297856] via 10.0.0.1, 00:12:49, Serial0/0
R1#show ip route summary | include eigrp
eigrp 1         0           6           432         768


Now let's permit only these prefixes, that have the length of 26 to 28. First we can use the prefix-list solution:

R2#configure t
R2(config)#ip prefix-list PREF2 permit 192.168.0.0/16 ge 26 le 28
R2(config)#route-map PREFOUT2 permit 10
R2(config-route-map)#match ip address prefix-list PREF2
R2(config-route-map)#exit
R2(config)#router eigrp 1
R2(config-router)#distribute-list route-map PREFOUT2 out



On R1:

R1#show ip route eigrp
     192.168.2.0/24 is variably subnetted, 3 subnets, 2 masks
D       192.168.2.64/27 [90/2297856] via 10.0.0.1, 00:17:22, Serial0/0
D       192.168.2.0/26 [90/2297856] via 10.0.0.1, 00:02:27, Serial0/0
D       192.168.2.128/27 [90/2297856] via 10.0.0.1, 00:17:22, Serial0/0
     192.168.3.0/28 is subnetted, 2 subnets
D       192.168.3.64 [90/2297856] via 10.0.0.1, 00:17:22, Serial0/0
D       192.168.3.0 [90/2297856] via 10.0.0.1, 00:17:22, Serial0/0
R1#show ip route summary | include eigrp
eigrp 1         0           5           360         640



Now we will use the ACL logic:

R2#configure t
R2(config)#access-list 101 permit ip 192.168.0.0 0.0.255.255 255.255.255.192 0.0.0.48
R2(config)#route-map ACLOUT2 permit 10
R2(config-route-map)#match ip address 101
R2(config-route-map)#exit
R2(config)#router eigrp 1
R2(config-router)#distribute-list route-map ACLOUT2 out


Let's go back to R1:

R1#show ip route eigrp
     192.168.2.0/24 is variably subnetted, 3 subnets, 2 masks
D       192.168.2.64/27 [90/2297856] via 10.0.0.1, 00:24:44, Serial0/0
D       192.168.2.0/26 [90/2297856] via 10.0.0.1, 00:09:49, Serial0/0
D       192.168.2.128/27 [90/2297856] via 10.0.0.1, 00:24:44, Serial0/0
     192.168.3.0/28 is subnetted, 2 subnets
D       192.168.3.64 [90/2297856] via 10.0.0.1, 00:24:44, Serial0/0
D       192.168.3.0 [90/2297856] via 10.0.0.1, 00:24:44, Serial0/0
R1#show ip route summary | include eigrp
eigrp 1         0           5           360         640


Again, we have done the same thing with the ACL that with the prefix-list! And we used the same number of commands!

Here, I tried to prove, that both of them are provide the similar level of flexibility. However prefix-lists have more user-friendly CLI and provide higher performance (use less CPU cycles) and that should be the main motivation to use them.

Sunday, 13 March 2011

BGP part 2

The second post today is also about BGP. I was asked why in  transit AS we have to run both IGP and iBGP. Why we cannot pick up one routing protocol? Let's find the answer!
In the following picture we can see the transit area which is connected to two others AS. Now let's focus on 3 different situation:
  • routers in the transit area are running only IGP
  • routers in the transit area are running only iBGP
  • routers in the transit area are running both IGP and iBGP

So in the first option, routers in the transit area are running only IGP. Routers R1 and R5 have established the BGP-sessions to routers R6 and R7, respectively. And if you are running only IGP between all others router within the transit area, you have to redistribute on R1 and R5 all received BGP prefixes into the IGP. Easy? Maybe it is easy, however today BGP routing table has about 380 000 prefixes. That amount of prefixes will kill the IGP and the routers will suffer a shortage of CPU power. So this solution is impossible! You can of course establish the iBGP session between R1 and R5. Then R1 and R5 will have all BGP prefixes, even without the redistribution BGP into IGP. However when the R1 would like to send a packet to the R7 via R5, R1 will send the packet to either R2, R3 or R4. And because none of these routers have the route to the R7 (again, we don't redistribute BGP into IGP), the packet will be dropped.

In the second option we are using only iBGP. We redistribute connected into BGP, so every router can ping whatever he want. But BGP is designed to carry a huge number of prefixes. In the path selection, the BGP doesn't take into account the link speed or link delay, which is the strength of link-state IGPs. Moreover BGP has a relative long time to reach the convergence in case of any failures in the network. So this solution may work, however it is not optimal.

Finally we can use IGP and iBGP in our core network. And this solution is almost perfect! Almost, because we have to deploy BGP sessions between every single router (we can use MPLS to avoid this, however this technology is out of scope of this post). Before we saw what happens without a full-mesh BGP sessions (R2, R3 or R4 are dropping all unknown packets). In this solution R1 (or R5) is advertising all BGP prefixes that he learned from R6 to the transit network (so to the R2, R3 or R4) using BGP, so all other routers that are running BGP have the knowledge of all these prefixes, and all other routers in the transit area know exactly how to reach the exit point (R1), because of IGP. In case of any failure in the core network, each router within the transit area is able to update its routing table (and finds out the new route to the exit point) using the IGP and it is much faster that the convergence of BGP.

BGP.

With the first post today, I would like to focus on the BGP routing protocol. I know ( for instance from my personal experience! ) that when people are starting to learn about this protocol, they are a little bit confused. One of the reason is related to the thing, that they are thinking in the IGP-way. Let me show you, where is the problem.

Please take a closer view on the picture:


On the picture we see three routers. Each router is in a different AS. There are two BGP sessions: R1-R2 and R2-R3. Moreover, R1 and R3 are injected their LANs (LANs behind SW1 and SW2, respectively) into the BGP routing table. There is only the BGP, no other routing protocols are running between routers.
Now, lets investigate R1's routing table. R1 knows all routes to the LAN2. However, it cannot ping any address in this LAN. R1 can ping R2, and R2 can ping either R3 or LAN2. What is happening?
The thing is, that when a router is sending the ping generated by itself, it puts to the IP header the IP address of interface from which the router sent the packet. In our case, R1 will send the ping out of the fa0/1 and indeed, R1 will put to the IP packet header the IP address of fa1/0. Eventually the ping will reach LAN2, and R3 will receive the ping reply from LAN2. After this, R3 will drop the packet (the ping reply), because R3 doesn't have the route to R1's fa0/1 IP address. That is the reason, why the communication between R1 and LAN2 is unsuccessful.

What we can do about this? Nothing, because we don't have to! In the real network it is pointless to send pings in this way. In real world, devices in LAN1 have to establish the communication with the devices in LAN2. In this situation R3 exactly knows, where to send the reply, because R3 has in routing table route to LAN1.

However, if you are being determinated to send the ping from R1, you can redistribute connected to the BGP table or change the IOS default behavior by:
ping ip_address source [source_ip_address | interface interface mod/num]

At this point I would like to also tell you what is the difference between the network command in IGP and BGP. In the IGP, a router will find all of its interfaces that have the IP address within the network statement and will start to run the IGP process on these interfaces. Beside of this,  the router will start to advertise by IGP process the network to which is directly connected via this interface. Returning to our picture, when you start the IGP between R1 - R2 and R2 - R3, every single network between these routers will be presented in the routing tables of each router.
However, network in BGP works completely different. Whereas the network command in IGP is using to establish the neighborhood between directly connected routers, in BGP this command is only used to insert to the BGP routing table a network and start to advertise it to the other peers. The session between 2 BGP-speaking peers however is configured manually and even it can be configured between non directly connected routers.

So when you establish a BGP-session between 2 routers, the BGP will not start to advertise the network that is between these routers. Whereas when you establish the IGP neighborhood between two directly connected routers, the IGP process will start to advertise the network that is between the routers. That is the reason, why the connection between R1 and LAN2 doesn't work.