The diagram is the same as my last VPN Lab. Also it uses my MPLs topology found over here: http://mellowd.co.uk/ccie/?p=522
This is the topology for this lab (click for a bigger image):
- Customer1 and Customer 2 both have MPLS vpn’s through the ISP core.
- Customer1 is using OSPF and Customer2 is using EIGRP
- Customers should have no access to each others networks
- Customers should be able to reach all their sites from all their sites
- The ISP wants to monitor the CPE routers via their monitoring server. Create another loopback on each CPE router and give them all a /32 loopback in the 172.16.1.1/24 range – i.e. 172.16.1.1/32 for CPE1, 172.16.1.2/32 for CPE2 and so on
- Ensure the monitoring router can get to all these /32 routes (and ONLY these /32 routes) – It should not know about any customer routes – CPE routers should only see their OWN loopbacks in the routing table
- Now enable CPE3 and CPE6 to see each others subnets. All other CPE routers should see no change in their routing tables
Timed access-lists can be handy for all sorts of things. Let’s say you have a few contractor PC’s in your office that are only allowed internet access from 17:00 to 19:00 each day. The rest of the day those PC’s are allowed to speak internally in the lan only.
I’ve got a very simple diagram here. PC’s 1-3 are allowed full access all the time. PC’s 4 and 5 are our contractor PC’s. Let’s say that DHCP is being used, but we are matching IP’s to MAC addresses (We’ll go over this in a new post sometime) – This is the topology (Click for larger image):
On the router I’m going to create 2 access-lists. The first will be a timed access list that will prevent any traffic from 192.168.1.4 and .5 from leaving the Fa0/0 interface. The second access-list will only allow traffic with a source address of 192.168.1.1-5 to pass through interface Fa0/1. This will prevent the contractors changing their IP to 192.168.1.10 and so on to gain internet access. It might be better to just not give them admin rights to their PC’s, but sometimes they may be using their own computers.
First up is the time range in which I want the block to be active:
time-range CONTRACTOR_NO_INTERNET periodic daily 0:00 to 16:59 periodic daily 19:00 to 23:59
Next I have to create an access-list, and I need to ensure the access-list is only active during my time range:
ip access-list extended CONTRACTORS deny ip host 192.168.1.4 any time-range CONTRACTOR_NO_INTERNET deny ip host 192.168.1.5 any time-range CONTRACTOR_NO_INTERNET permit ip any any
Always remember that ACL’s have an implicit deny at the end, so in this case I need to ensure I have an implicit permit any at the end. Also note that although I’ve blocked those hosts to any destination, they’ll still be able to traverse the local lan as it’ll only go through the switch. If you had a SOHO router with a switch-plane built into the router, you may need to create another entry allowing all local subnet traffic at the top of this access-list.
Now we need to apply this access-list to the Fa0/0 interface:
interface FastEthernet0/0 ip address 10.1.1.1 255.255.255.0 ip access-group CONTRACTORS out duplex auto speed auto end
The last part I wanted to do was to ensure that only the IP’s in use on the network right now are allowed. This prevents the contractors from changing their IP’s to get around our access-list.
ACL:
access-list 1 permit 192.168.1.1 access-list 1 permit 192.168.1.3 access-list 1 permit 192.168.1.2 access-list 1 permit 192.168.1.5 access-list 1 permit 192.168.1.4 access-list 1 deny any
On the interface:
interface FastEthernet0/1 ip address 192.168.1.254 255.255.255.0 ip access-group 1 in duplex auto speed auto end
Very handy!
Edit: Just be sure that you’ve actually correctly set the clock on the router beforehand!
The main purpose of this post is to show how prefix lists work and how to decipher them vs regular access lists. Access-lists do a great job on Cisco devices, not just for security but all kinds of route filtering, QoS and so on.
A prefix list is a bit different form an access-list, and it’s important to know the differences and when to use either.
I’ve created the following simple topology to illustrate what I’m going to be doing. There are 2 routers, both running BGP. Router1 will have numerous loopbacks with IP addresses that will be advertised into the BGP process. On router2 I’ll use various access-lists and prefix-lists to see what kind of results I get. Remember though that prefix-lists can be used with other routing protocols and not just BGP.
This is the topology (Click for the full view):
This is the config on each:
R1#sh run | begin bgp router bgp 100 no synchronization bgp log-neighbor-changes network 1.1.1.1 mask 255.255.255.255 neighbor 10.1.1.10 remote-as 200 no auto-summary
R2#sh run | begin bgp router bgp 200 no synchronization bgp log-neighbor-changes neighbor 10.1.1.9 remote-as 100 no auto-summary
I’ll put the following subnets on R1 and advertise them in BGP:
- 192.168.1.1/24
- 192.168.2.1/24
- 192.168.3.1/25
- 192.168.3.129/25
- 192.168.4.1/25
- 192.168.4.129/26
- 192.168.4.193/26
#R1 interface Loopback0 ip address 1.1.1.1 255.255.255.255 ! interface Loopback1 ip address 192.168.1.1 255.255.255.0 ! interface Loopback2 ip address 192.168.2.1 255.255.255.0 ! interface Loopback3 ip address 192.168.3.1 255.255.255.128 ! interface Loopback4 ip address 192.168.3.129 255.255.255.128 ! interface Loopback5 ip address 192.168.4.1 255.255.255.128 ! interface Loopback7 ip address 192.168.4.129 255.255.255.192 ! interface Loopback8 ip address 192.168.4.193 255.255.255.192
This is R1′s BGP config now:
R1#sh run | begin bgp router bgp 100 no synchronization bgp log-neighbor-changes network 1.1.1.1 mask 255.255.255.255 network 192.168.1.0 network 192.168.2.0 network 192.168.3.0 mask 255.255.255.128 network 192.168.3.128 mask 255.255.255.128 network 192.168.4.0 mask 255.255.255.128 network 192.168.4.128 mask 255.255.255.192 network 192.168.4.192 mask 255.255.255.192 neighbor 10.1.1.10 remote-as 200 no auto-summary
On Router2, we can see the routes advertised:
R2#sh ip bgp
BGP table version is 10, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 10.1.1.9 0 0 100 i
*> 192.168.1.0 10.1.1.9 0 0 100 i
*> 192.168.2.0 10.1.1.9 0 0 100 i
*> 192.168.3.0/25 10.1.1.9 0 0 100 i
*> 192.168.3.128/25 10.1.1.9 0 0 100 i
*> 192.168.4.0/25 10.1.1.9 0 0 100 i
*> 192.168.4.128/26 10.1.1.9 0 0 100 i
*> 192.168.4.192/26 10.1.1.9 0 0 100 i
Let’s say I want to filter out the network 192.168.4.0/25. If I use an access-list I need to do it as follows. Create the access list:
R2#conf t R2(config)#access-list 5 deny 192.168.4.0 0.0.0.127 R2(config)#access-list 5 permit any
Add a rule to the BGP config:
R2#sh run | begin bgp router bgp 200 no synchronization bgp log-neighbor-changes neighbor 10.1.1.9 remote-as 100 neighbor 10.1.1.9 distribute-list 5 in no auto-summary
You can see that the 192.168.4.0/25 route has now been filtered out:
R2#sh ip bgp Network Next Hop Metric LocPrf Weight Path *> 1.1.1.1/32 10.1.1.9 0 0 100 i *> 192.168.1.0 10.1.1.9 0 0 100 i *> 192.168.2.0 10.1.1.9 0 0 100 i *> 192.168.3.0/25 10.1.1.9 0 0 100 i *> 192.168.3.128/25 10.1.1.9 0 0 100 i *> 192.168.4.128/26 10.1.1.9 0 0 100 i *> 192.168.4.192/26 10.1.1.9 0 0 100 i
Let’s say I wanted to filter out the 192.168.4.x/26′s as well. In order to do so I’d have to add another line for each network in my access-list. With a prefix-list it’s much easier to do this. Let’s remove the access-list and start again. NB: Prefix-lists, like access-lists, have a implicit DENY at the end. In an ACL you’ll place a permit any at the end. The prefix-list version of this is to permit 0.0.0.0/0 le 32
First I’ll create the prefix-list:
R2(config)#ip prefix-list exclude_4 seq 5 deny 192.168.4.0/24 ge 25 le 26 R2(config)#ip prefix-list exclude_4 seq 10 permit 0.0.0.0/0 le 32
Now I’ll apply it to the BGP process:
router bgp 200 no synchronization bgp log-neighbor-changes neighbor 10.1.1.9 remote-as 100 neighbor 10.1.1.9 prefix-list exclude_4 in no auto-summary
When checking the BGP table I see the following:
R2#sh ip bgp Network Next Hop Metric LocPrf Weight Path *> 1.1.1.1/32 10.1.1.9 0 0 100 i *> 192.168.1.0 10.1.1.9 0 0 100 i *> 192.168.2.0 10.1.1.9 0 0 100 i *> 192.168.3.0/25 10.1.1.9 0 0 100 i *> 192.168.3.128/25 10.1.1.9 0 0 100 i
You can see that all the 192.168.4.1/25 and /26s are gone thanks to the prefix-list.
The basics of the prefix list is as follows. If I write
ip prefix-list exclude_4 seq 5 deny 192.168.4.0/24 ge 25 le 26
The /24 tells the IOS to match only the first 24 bits. i.e. 192.168.4 – I then tell the IOS to match only those prefixes that have a subnet mask of /25 or /26. i.e. If I had another network advertised which was 192.168.4.200/27 it would NOT match as even though the 192.168.4 part matches, it has a subnet mask of /27
Let’s say I wanted to now match 192.168.x.x/25 but I wanted to leave the /26′s in place. This would be easy with a prefix list as follows:
R2(config)#ip prefix-list exclude_4 seq 5 deny 192.168.3.0/16 ge 25 le 25 R2(config)#ip prefix-list exclude_4 seq 10 permit 0.0.0.0/0 le 32
I’ve told the IOS to only match on the first 16 bits, i.e. 192.168 – I then told IOS to only match those prefixes that have a subnet mask of /25. If I apply this to my BGP process I can see that it works as expected:
R2#sh ip bgp Network Next Hop Metric LocPrf Weight Path *> 1.1.1.1/32 10.1.1.9 0 0 100 i *> 192.168.1.0 10.1.1.9 0 0 100 i *> 192.168.2.0 10.1.1.9 0 0 100 i *> 192.168.4.128/26 10.1.1.9 0 0 100 i *> 192.168.4.192/26 10.1.1.9 0 0 100 i
Only the 3 /25′s have disappeared, everything else is still there.
You can also do all of this with extended access-lists, but it’s so much more work, why make life difficult? Once you understand the context of prefix-lists it becomes very easy
Comments