Hotel case study - ISP connection and NAT
Contents
ISP Connection
Explanation
Each hotel site has a local connection to their ISP. Note that this is a Serial (WAN) link not an Ethernet (LAN) connection. The link uses the layer 2 protocol PPP (Point to Point Protocol). PPP is very common with external providers as one of the features it supports is Authentication. If you examine the configuration of the ISP router, you will see it has accounts setup, with passwords', for SydCORE and PerCORE.
The case study requirements provide similar information to that an ISP would provide to a customer. It also provides the full configuration for Perth.
What you need to do?
- You can just copy and paste the provided configuration onto the PerCORE and the link should come up.
- For Sydney you will need to change the sent-username to match the ISP documentation and select the appropriate IP address.
How you will know it is configured correctly?
- Immediately after a performing a "no shutdown" the Serial interface should come up and stay up.
- If the interface goes "down" then the problem is almost certainly a problem with Authentication. Either the supplied username or password is incorrect. debug ppp authentication may give you some clues. (undebug all will stop the debug).
- If the line is up, you should be able to ping from a core router to the directly connected ISP interface. If that works your link is fine.
What questions could I see on the practical exam?
PPP isn't a learning objective for ICT291/ICT535 so you can assume that everything is working correctly there.
The password and username should be correct.
- As with any interface, you might find it is shutdown or has and incorrect IP address. show ip interface brief will reveal these issues.
NAT
Explanation
The hotel group uses Private IP address (10.0.0.0/8) and the Internet uses only global IP addresses. In order for packets to be exchanged with the Internet, the packets must appear as though they originate from a global IP address. That means we need Network Address Translation to convert our private IP addresses into global addresses as they leave our site.
NAT needs to occur on the boundary between private and global addresses. For the hotel group this is the S1/0 interface on the core routers.
Cisco routers translate addresses when two conditions occur:
- A packet travels from an "inside" interface (private) to an "outside" interface (global) and...
- The packet is "permitted" by and ACL. This gives the administrator fine control over the process.
When translating an address, the router needs a supply of global IP addresses to use. Here are the possibilities:
- Reuse the IP address on the routers global interface (S1/0 on core).
- The administrator provides a pool of addresses that they have received from their ISP for this purpose. This is the technique we will use.
From the scenario documentation you can see our ISP has provided a pool of 4 addresses to use at each site.
Perth Global address pool (NAT): 123.123.123.68 /30 Sydney Global address pool (NAT): 123.123.123.64 /30
What you need to do?
- Create an ACL that defines the traffic that needs to be translated. This is very general. Essentially any traffic from the 10.0.0.0/8 network (private) needs to be translated. We can achieve this with a standard ACL because it is source-address only and the whole IP suite.
- Define the pool of global addresses.
- Tell the router which of its interfaces are "inside" and "outside".
- "Turn on" NAT. (The main command)
- Remember to translate the examples below for use on the Sydney side.
NAT ACL
Study the following:
PerCORE(config)#ip access-list standard NAT-ACL PerCORE(config-std-nacl)#permit 10.0.0.0 0.255.255.255
NAT_ACL is a meaningful name we have given to describe this rule.
The "permit", in the context of NAT means "translate". A "deny" would mean "don't translate". permit/deny do allow or prevent packet flow. They will just control the NAT process.
The wildcard mask will match any traffic originating from the 10.0.0.0/8 network.
NAT Pool
Creating a pool of addresses can be achieved with "ip nat pool" command: An example for the Perth site would be:
PerCORE(Config)# ip nat pool PERTH-NAT-POOL 123.123.123.68 123.123.123.71 netmask 255.255.255.252
Note the IP addresses represent the range.
NAT Inside/Outside
All of the privately addressed interfaces of the Core router should be identified as "ip nat inside". The globally addressed int S1/1 interface of the Core router should be identified as "ip nat outside".
PerCORE(config)# interface s1/1 PerCORE(config-if)# ip nat outside
PerCORE(config)# interface s1/0 PerCORE(config-if)# ip nat inside
PerCORE(config)# interface e0/0 PerCORE(config-if)# ip nat inside
PerCORE(config)# interface e0/1 PerCORE(config-if)# ip nat inside
ACTIVATING NAT
PerCORE(config)# ip nat inside source list NAT-ACL pool PERTH-NAT-POOL overload
This command says: Translate the "source" address (where it appears to originate from), if it matches the ACL and take a global address from the pool named PERTH-NAT-POOL. The overload keyword indicates that NAT should use port-address-translation to allow a single global address to support many private addresses.
Default route
At this point NAT should be configured but your routers don't know where to send packets that are not on the 10.0.0.0 network. Routers make their routing decision based on their routing table and the only entries "show ip route" reveals are for the 10.0.0.0 network or the directly connected ISP link (on the core). We need to provide the core routers with a default route that points to the ISP.
An appropriate static route would be:
PerCORE(config)# ip route 0.0.0.0 0.0.0.0 Serial1/1
This can be interpreted as "send packets for which we don't have a route out of S0/1 (to ISP). As packets flow through the router (from inside to outside) they will trigger the NAT process and they will be sent to the ISP with a source address from the NAT pool.
This will provide a default on the core router but your distribution routers need to know how to get to the Internet as well. Rather than provide static routes on all routers, we can ask OSPF to path on the route for us.
On the core router add the following to the existing OSPF configuration:
PerCORE(config)# router ospf 1 PerCORE(config-router)# default-information originate
How you will know it is configured correctly?
NAT translates from inside to outside, so you may not get a reliable test if you ping from the core router itself. It *might* work in this simple network because the ISP is just a single router and all your "Internet" addresses are directly connected to it. But in real life it may not work. So it is best to check NAT behaviour from somewhere that is really "inside".
- From one of the PCs you should be able to ping the internet address at 1.2.3.4
- If you can't ping the Internet from your host, check that your core router has a default route pointing to the ISP.
PERCORE#show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override
Gateway of last resort is 0.0.0.0 to network 0.0.0.0
S* 0.0.0.0/0 is directly connected, Serial1/1
10.0.0.0/8 is variably subnetted, 14 subnets, 3 masks
C 10.0.0.0/30 is directly connected, Serial1/0
<output omitted>
- Also, confirm that your distribution layer devices are learning about the default route from the core router:
PerDL2#show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override
Gateway of last resort is 10.1.255.5 to network 0.0.0.0
O*E2 0.0.0.0/0 [110/1] via 10.1.255.5, 00:10:51, GigabitEthernet0/0
10.0.0.0/8 is variably subnetted, 15 subnets, 3 masks
O IA 10.0.0.0/30 [110/65] via 10.1.255.5, 02:11:16, GigabitEthernet0/0
<output omitted>
- Assuming your routing is functional you can check if translations are occurring on the core router.
Note: you will only see output here if translations have occurred recently.
So you must ping first then look at the output:
PERCORE#show ip nat translations Pro Inside global Inside local Outside local Outside global icmp 123.123.123.70:2563 10.1.1.10:2563 1.2.3.4:2563 1.2.3.4:2563 icmp 123.123.123.70:2819 10.1.1.10:2819 1.2.3.4:2819 1.2.3.4:2819 icmp 123.123.123.70:3075 10.1.1.10:3075 1.2.3.4:3075 1.2.3.4:3075 icmp 123.123.123.70:3331 10.1.1.10:3331 1.2.3.4:3331 1.2.3.4:3331 icmp 123.123.123.70:3587 10.1.1.10:3587 1.2.3.4:3587 1.2.3.4:3587
In my experience if NAT isn't working then you are unlikely to see translations here.
- If translations are not occurring, it could be that your ACL is not matching traffic:
PERCORE#show access-lists Standard IP access list NAT-ACL 10 permit 10.0.0.0, wildcard bits 0.255.255.255 (7 matches)
If the matches doesn't increment as you ping, it is an indication that your ACL is not working or hasn't been linked by the command that activates NAT.
What questions could I see on the practical exam?
- A default route could be missing or pointing to the incorrect interface.
- OSPF may not be configured to forward default routes.
- NAT may not be configured correctly.
