Showing posts with label LAN. Show all posts
Showing posts with label LAN. Show all posts

Friday, August 29, 2014

Avanced Cisco Routing: Implementing OSPF in IPv6

So far, all of the labs have dealt exclusively with IPv4 -- what has traditionally just been called, "IP."  Today, let's look at configuring IPv6 on Cisco routers, since we are rapidly approaching the point where IPv4 will no longer suffice on the public Internet.

Consider the following network topology:

I am using the IPv6 address space 2001:dead:beef:0:0:0:0:0/64 (2001:dead:beef:0::/64) to create the subnets that I will use to address these routers.  I have decided that the subnet 2001:dead:beef::0/112 will be reserved for the loopback addresses on my core routers (far more than I need, but in real-life, that would provide room for expansion in the future).  The subnet 2001:dead:beef::1:0/112 will be reserved -- and subdivided -- for point-to-point networks, such as the serial links between the core routers.  Each LAN will be a /112 on 2001:dead:beef::x:0, where "x" is greater than 0 -- for example, 2001:dead:beef::1:0/112, 2001:dead:beef::2:0/112, etc.  I will use OPSFv6 to route between these various networks.

As I often do, I am using Cisco 3600-series routers for the core routers (ANCCR1, ENACR1, FAICR1 and HOMCR1) and Cisco 2600-series routers to simulate PCs attached to the routers' LANs.  Since the 2600 routers are the simplest to configure -- just a single Ethernet interface and a static route to the core routers -- that's where I started configuring this network:

faipc2(config)#int fa1/0
faipc2(config-if)#description Uplink to faicr1
faipc2(config-if)#ipv6 address 2001:dead:beef:0:0:0:3:2/112
faipc2(config-if)#ipv6 enable
faipc2(config-if)#no shut
faipc2(config-if)#exit
faipc2(config)#ipv6 route 0:0:0:0:0:0:0:0/0 2001:dead:beef:0:0:0:3:1
faipc2(config)#

That's all it takes to configure an IPv6 address on FA1/0 and to set up a static route to faicr1.  We'll repeat this set-up (with the appropriate IPv6 addresses and routes, of course) on R5-R9, but I won't duplicate the configurations here.

Once the "PC's" are configured, we'll start configuring the core routers.  Let's start with anccr1, since it's the most complex router on the network, having two Ethernet interfaces, two serial interfaces and a loopback interface:
anccr1(config)#int lo0
anccr1(config-if)#ipv6 address 2001:dead:beef::1/128
anccr1(config-if)#ipv6 enable
anccr1(config-if)#no shut
anccr1(config-if)#int fa1/0
anccr1(config-if)#desc Anchorage LAN 1
anccr1(config-if)#ipv6 address 2001:dead:beef::6:1/112
anccr1(config-if)#ipv6 enable
anccr1(config-if)#no shut
anccr1(config-if)#int fa2/0
anccr1(config-if)#desc Anchorage LAN 2
anccr1(config-if)#ipv6 address 2001:dead:beef::7:1/112
anccr1(config-if)#ipv6 enable
anccr1(config-if)#no shut
anccr1(config-if)#int s0/0
anccr1(config-if)#desc Uplink to faicr1
anccr1(config-if)#ipv6 address 2001:dead:beef::1:1/127
anccr1(config-if)#ipv6 enable
anccr1(config-if)#no shut
anccr1(config-if)#int s0/1
anccr1(config-if)#desc Uplink to enacr1
anccr1(config-if)#ipv6 address 2001:dead:beef::1:5/127
anccr1(config-if)#ipv6 enable
anccr1(config-if)#no shut

Just as in IPv4, by default, the router will know how to reach connected networks, but will not share routes with the other routers until a routing protocol (OSPF, BGP, EIGRP, etc.) is enabled.  However, at this point we should have two devices we can reach from anccr1: ancpc1 (R7 on the diagram) and ancpc2 (R8 on the diagram).  Let's try to ping them both:
anccr1#ping 2001:dead:beef::6:2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:dead:beef::6:2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/7/12 ms
anccr1#ping 2001:dead:beef::7:2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:dead:beef::7:2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/6/12 ms
anccr1#

Excellent!  We were able to ping both hosts.  Let's turn up enacr1 and see if we can ping across the serial link:
enacr1(config)#int fa1/0
enacr1(config-if)#desc Kenai LAN
enacr1(config-if)#ipv6 address 2001:dead:beef::4:1/112
enacr1(config-if)#ipv6 enable
enacr1(config-if)#no shut
enacr1(config-if)#int s0/1
enacr1(config-if)#desc Uplink to homcr1
enacr1(config-if)#ipv6 address 2001:dead:beef::1:9/127
enacr1(config-if)#ipv6 enable
enacr1(config-if)#no shut
enacr1(config-if)#int s0/0
enacr1(config-if)#desc Uplink to anccr1
enacr1(config-if)#ipv6 address 2001:dead:beef::1:6/127
enacr1(config-if)#ipv6 enable
enacr1(config-if)#no shut

Hmmm...something seems to be wrong.  I can ping the 2600 router ("LAN PC"), but not the Anchorage core router:
enacr1#ping 2001:dead:beef::1:5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:dead:beef::1:5, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
enacr1#ping 2001:dead:beef::4:2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:dead:beef::4:2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/6/12 ms
enacr1#

We'll troubleshoot just like we would on an IPv4 network:
enacr1#sho ipv6 int brief
Serial0/0                  [up/up]
    FE80::CE02:14FF:FEA2:10
    2001:dead:beef::1:6
Serial0/1                  [up/up]
    FE80::CE02:14FF:FEA2:10
    2001:dead:beef::1:9
Serial0/2                  [administratively down/down]
    unassigned
Serial0/3                  [administratively down/down]
    unassigned
FastEthernet1/0            [up/up]
    FE80::CE02:14FF:FEA2:10
    2001:dead:beef::4:1
enacr1#
enacr1#sho ipv6 route
IPv6 Routing Table - 8 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
       U - Per-user Static route
       I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
       O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
C   2001:dead:beef::1:6/127 [0/0]
     via ::, Serial0/0
L   2001:dead:beef::1:6/128 [0/0]
     via ::, Serial0/0
C   2001:dead:beef::1:8/127 [0/0]
     via ::, Serial0/1
L   2001:dead:beef::1:9/128 [0/0]
     via ::, Serial0/1
C   2001:dead:beef::4:0/112 [0/0]
     via ::, FastEthernet1/0
L   2001:dead:beef::4:1/128 [0/0]
     via ::, FastEthernet1/0
L   FE80::/10 [0/0]
     via ::, Null0
L   FF00::/8 [0/0]
     via ::, Null0
enacr1#

Hmmm...well, for one thing, we configured the IPv6 addresses on the serial ports as /127's on both routers rather than /126's.  In theory, this should work, but you might want to research /127's on an IPv6 network before using them.  For now, let's change the /127's to /126's, and see what happens:
anccr1#ping 2001:dead:beef::1:6

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:dead:beef::1:6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/12/16 ms
anccr1#

That's better!  I'd love to say that the incorrect subnetting was an accidental typo, but in all honesty...I fubar'd the notation -- but it made for a great teaching moment, so I didn't edit it out of the blog entry, lol.

One last thing to try...by default, a router knows all of the subnets connected to it, and the "LAN PC's" have a default route to the local core router, so in theory, a "LAN PC" should be able to ping the loopback IPv6 address of its local LAN router.  Let's try it:
ancpc1#ping 2001:dead:beef::1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:dead:beef::1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 ms
ancpc1#

Sweet!  That worked just as expected.

Now, let's try enabling routing on the IPv6 network:
homcr1(config)#ipv6 router ospf 42
% IPv6 routing not enabled
homcr1(config)#
Eh?!?!  A quick search of the magic Google ball explains why: you must enable IPv6 unicast routing before you can turn up any IPv6 routing protocols.  <shrug>  Okay, whatever.  Let's do it:
homcr1(config)#ipv6 unicast-routing
homcr1(config)#ipv6 router ospf 42
04:44:40: %OSPFv3-4-NORTRID: OSPFv3 process 42 could not pick a router-id,
please configure manually

Ummm...okay.  I was just about to do that, anyway:
homcr1(config-rtr)#router-id 2001:dead:beef::4
                             ^
% Invalid input detected at '^' marker.

And we wonder why IPv6 is taking so long to adopt, sigh.  According to the spec, the OSPF router ID is technically NOT an IP address, but is instead a 32-bit number that is used to uniquely identify the router in it's OSPF area.  Since IP (v4) addresses happen to also be 32-bit numbers, that is what is typically used, but it is not a requirement.  The fact that Cisco, by default, will select one of the IPv4 addresses configured on the router to use as the router ID if you do not manually specify one muddies the issue, but that isn't really relevant here...except that we haven't configured any IPv4 addresses on the router, so OSPF can't arbitrarily snatch one to use as the router ID.  Back on track...let's assign a random 32-bit router ID to this router:
homcr1(config-rtr)#router-id 4.4.4.4

Next, there is no "network a.b.c.d e.f.g.h area i.j.k.l" command in IPv6 OSPF like there is in IPv4 OSPF.  Instead, we set the OSPF area globally, and tell the OSPF process what we would like to distribute:
homcr1(config-rtr)#area 0.0.0.0 range 2001:dead:beef::0/64
homcr1(config-rtr)#redistribute connected

However, that isn't sufficient to start sharing routes via IPv6 OSPF:
faicr1#sho ipv6 route
IPv6 Routing Table - 9 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
       U - Per-user Static route
       I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
       O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
LC  2001:dead:beef::3/128 [0/0]
     via ::, Loopback0
C   2001:dead:beef::1:0/126 [0/0]
     via ::, Serial0/0
L   2001:dead:beef::1:2/128 [0/0]
     via ::, Serial0/0
C   2001:dead:beef::2:0/112 [0/0]
     via ::, FastEthernet1/0
L   2001:dead:beef::2:1/128 [0/0]
     via ::, FastEthernet1/0
C   2001:dead:beef::3:0/112 [0/0]
     via ::, FastEthernet2/0
L   2001:dead:beef::3:1/128 [0/0]
     via ::, FastEthernet2/0
L   FE80::/10 [0/0]
     via ::, Null0
L   FF00::/8 [0/0]
     via ::, Null0
faicr1#

In IPv6 OSPF, you have to enable the OSPF process in each interface that will be participating in OSPF:
faicr1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
faicr1(config)#int s0/0
faicr1(config-if)#ipv6 ospf 42 area 0.0.0.0
faicr1(config-if)#exit
05:10:00: %OSPFv3-5-ADJCHG: Process 42, Nbr 1.1.1.1 on Serial0/0 from LOADING to FULL, Loading Done
faicr1(config)#exit
faicr1#sho ipv6 route
IPv6 Routing Table - 16 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
       U - Per-user Static route
       I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
       O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
OE2  2001:dead:beef::1/128 [110/20]
     via FE80::CE01:14FF:FEA2:10, Serial0/0
OE2  2001:dead:beef::2/128 [110/20]
     via FE80::CE01:14FF:FEA2:10, Serial0/0
LC  2001:dead:beef::3/128 [0/0]
     via ::, Loopback0
C   2001:dead:beef::1:0/126 [0/0]
     via ::, Serial0/0
L   2001:dead:beef::1:2/128 [0/0]
     via ::, Serial0/0
O   2001:dead:beef::1:4/126 [110/128]
     via FE80::CE01:14FF:FEA2:10, Serial0/0
O   2001:dead:beef::1:8/126 [110/192]
     via FE80::CE01:14FF:FEA2:10, Serial0/0
C   2001:dead:beef::2:0/112 [0/0]
     via ::, FastEthernet1/0
L   2001:dead:beef::2:1/128 [0/0]
     via ::, FastEthernet1/0
C   2001:dead:beef::3:0/112 [0/0]
     via ::, FastEthernet2/0
L   2001:dead:beef::3:1/128 [0/0]
     via ::, FastEthernet2/0
OE2  2001:dead:beef::4:0/112 [110/20]
     via FE80::CE01:14FF:FEA2:10, Serial0/0
OE2  2001:dead:beef::6:0/112 [110/20]
     via FE80::CE01:14FF:FEA2:10, Serial0/0
OE2  2001:dead:beef::7:0/112 [110/20]
     via FE80::CE01:14FF:FEA2:10, Serial0/0
L   FE80::/10 [0/0]
     via ::, Null0
L   FF00::/8 [0/0]
     via ::, Null0
faicr1#

That's much better! Now we have routes from the other routers (which previously had OSPF enabled on their serial interfaces) showing up on the Fairbanks core router. Let's make sure our "LAN PC's&qout; can ping end-to-end:
hompc1#ping 2001:dead:beef::4:2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:dead:beef::4:2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/13/20 ms
hompc1#ping 2001:dead:beef::6:2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:dead:beef::6:2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/36/64 ms
hompc1#ping 2001:dead:beef::7:2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:dead:beef::7:2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/30/56 ms
hompc1#ping 2001:dead:beef::2:2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:dead:beef::2:2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/35/56 ms
hompc1#ping 2001:dead:beef::3:2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:dead:beef::3:2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/25/57 ms
hompc1#

Monday, July 14, 2014

Advanced Cisco Routing -- Route Maps

So far, all of our routing examples have been pretty straight-forward: to reach network "A" you take route "A," and to reach network "B" you take route "B," etc. Suppose, however, that you need to filter routes between different WAN sites? Specifically, consider the following list of requirements:

  1. Multiple WAN sites with RFC-1918 IP space on the inside of the networks;
  2. Direct Nat'ed Internet links at each WAN site;
  3. Point-to-Point links (T1's, VPN tunnels, etc.) between WAN sites to route the internal LANs together;
  4. OSPF routing between internal LAN subnets.


In this case, you can use a route map to filter what networks OSPF is advertising. Here's how you do it:

First, here is the network topology for our example:
In this drawing, we'll use router R1 as our Anchorage router, R2 as our Fairbanks router, R4 and R5 will be random hosts on the internal LANs of R1 and R2 (respectively), and R3 will represent the Internet network between R1 and R2. Here is the basic configuration for R1 (the Anchorage router):

interface FastEthernet0/0
description LAN
ip address 192.168.1.1 255.255.255.0
ip nat inside
duplex auto
speed auto
!
interface FastEthernet1/0
description Inet
ip address 169.254.1.10 255.255.255.192
ip nat outside
duplex auto
speed auto
!
interface FastEthernet2/0
description OVPN to Fairbanks
ip address 172.16.1.1 255.255.255.252
ip nat inside
duplex auto
speed auto
!
ip nat inside source list 1 interface FastEthernet1/0 overload
no ip http server
no ip http secure-server
ip classless
ip route 0.0.0.0 0.0.0.0 169.254.1.1
!
access-list 1 permit 192.168.1.0 0.0.0.255
access-list 1 permit 172.16.1.0 0.0.0.3
!

As you can see, we have set up NAT to map addresses on the two internal interfaces to the external IP address of 169.254.1.10, and we have created a default route to the Internet router at 169.254.1.1. At this point, any hosts on the internal network should be able to reach any publicly-accessible IP address.

Similarly, here is the basic configuration for the Fairbanks router:

interface FastEthernet0/0
description LAN
ip address 192.168.3.1 255.255.255.0
ip nat inside
duplex auto
speed auto
!
interface FastEthernet1/0
description Inet
ip address 169.254.2.10 255.255.255.192
ip nat outside
duplex auto
speed auto
!
interface FastEthernet2/0
description OVPN to Anch
ip address 172.16.1.2 255.255.255.252
ip nat inside
duplex auto
speed auto
!
ip nat inside source list 1 interface FastEthernet1/0 overload
no ip http server
no ip http secure-server
ip classless
ip route 0.0.0.0 0.0.0.0 169.254.2.1
!
access-list 1 permit 192.168.3.0 0.0.0.255
access-list 1 permit 172.16.1.0 0.0.0.3
!

With this configuration, R4 should be able to ping the outside interface on R2, and R5 should be able to ping the outside interface on R1 (assuming that R3, R4 and R5 have been configured with the appropriate IP addresses on their respective interfaces, and that R4 and R5 have default routes through R1 and R2, respectively). However, if you try to ping R5 from R4 or vice versa, you will find that the pings fail, because R1 and R2 are not yet advertising routes to their internal networks. You could create static routes on these routers to solve this problem, but that's why we have dynamic routing protocols -- to reduce the network admin's workload.

However, you don't want to send routes to public IP addresses over your internal-only links, and even more importantly, you don't want to advertise your RFC-1918 IP addresses on the public Internet (your service provider should already be filtering these, but...). Therefore, we want to make sure OSPF is only advertising our private LAN addresses over the point-to-point link, so we'll create a route map on R1 and R2 to filter what routes OSPF advertises.

The first step in creating a route map is creating the access control list (ACL) to identify the traffic we want OSPF to allow. On R1...:

access-list 10 permit 192.168.3.0 0.0.0.255
access-list 10 permit 192.168.1.0 0.0.0.255
access-list 10 permit 172.16.1.0 0.0.0.3
!

...and on R2...:
access-list 10 permit 192.168.3.0 0.0.0.255
access-list 10 permit 192.168.1.0 0.0.0.255
access-list 10 permit 172.16.1.0 0.0.0.3
!

Note: If you don't fully understand the ACL's we have created here, check out CCNA Lesson 12 for a more in-depth explanation of ACL's on a Cisco router.

Next, we create the route-map to allow the networks filtered by these access lists (configuration is the same on both R1 and R2):
route-map inside-ospf permit 10
match ip address 10
!

Finally, we create our OSPF configuration, referencing the route maps. On R1:

router ospf 42
router-id 192.168.1.1
log-adjacency-changes
redistribute connected subnets route-map inside-ospf
network 172.16.1.0 0.0.0.3 area 0.0.0.0
!

...and on R2:

router ospf 42
router-id 192.168.3.1
log-adjacency-changes
redistribute connected subnets route-map inside-ospf
network 172.16.1.0 0.0.0.3 area 0.0.0.0
!


Here's what's happening in the router. We are creating the ACL to match our internal LAN traffic (192.168.1.0/24, 192.168.3.0/24, and 172.16.1.0/30). Then, we are creating a route map called "inside-ospf" to match the networks defined in ACL 10. Finally, OSPF is redistributing the networks referenced in the route-map "inside-ospf." If a network does not match the ACL, for example 169.254.1.0/26 (the network attached to fa1/0 on router R1), OSPF does not forward that route to other OSPF-enabled routers in that area. You can verify that this is working by tracing routes to various networks from R4 or R5. Here is an example of two traceroutes from R5:

Router#traceroute 192.168.1.2

Type escape sequence to abort.
Tracing the route to 192.168.1.2

1 192.168.3.1 8 msec 8 msec 8 msec
2 172.16.1.1 24 msec 8 msec 16 msec
3 192.168.1.2 28 msec 16 msec *
Router#traceroute 169.254.1.10

Type escape sequence to abort.
Tracing the route to 169.254.1.10

1 192.168.3.1 8 msec 4 msec 8 msec
2 169.254.2.1 16 msec 12 msec 8 msec
3 169.254.1.10 28 msec 25 msec *
Router#

You can see the traceroute follows the P-t-P link from R2 to R1 to reach 192.168.1.2, but follows the "Internet" link to reach the outside interface of R1, which is exactly what we wanted.

Reference:Cisco's "Route Maps for IP Routing Protocol Redistribution Configuration" web page.

Tuesday, November 12, 2013

JNCIA Lesson 7 -- DHCP

It is, perhaps, a little unfair that for many of these labs, I have been cheating slightly.

Don't get me wrong; I have configured all of the protocols and examples that we have discussed, and I have verified that the examples I have provided work as advertised. However, many of these examples have required that we connect one or more hosts to the various networks that we have built so that we can test end-to-end connectivity across the network(s). While there is certainly no reason why a network admin cannot configure such hosts by hand, I must confess that I do not like doing more work than is necessary. Again, do not be mislead; I am not claiming that I am unwilling to work when it is necessary, but rather I am saying that if there is an easy way to accomplish a task and a difficult way to accomplish a task, then, all else being equal, I will choose the easy way. To that end, when I have needed a PC connected to the Juniper switches to test connectivity, I have -- without providing you with the instructions on how to do likewise -- made use of the DHCP protocol to automatically assign IP addresses to my devices. I apologize, and in penance, I will endeavour to right that wrong in this lesson ;)

As I am sure you know -- or at least have by now guessed -- DHCP is a standard protocol for automatically assigning various network settings to computers on a LAN. Most obvious, of course, is the ability to automatically assign an IP address to a host on the network. However, DHCP can also assign a number of other settings such as the default gateway, DNS (name server) addresses, and domain name. Needless to say, the ability to automatically provision network settings to any device that connects to a LAN can be a huge time-saver for a busy network admin. Do you really want to visit the workstation of every user in your company first thing in the morning to assign an IP address for the day? Of course, not! Fortunately, this is another example of the kind of routine, mundane, repetitive task that computers perform extremely well, so let's set up our main office EX3200 to do so.

In one of the earlier lessons, we agreed that the default VLAN on our main3200 switch would use the network 192.168.1.0/24. However, we also stated that we would have a handful of network devices and servers on this network. Network devices almost always have their IP addresses assigned statically, as it becomes very difficult to configure your LAN equipment to reach a default gateway, for example, when the gateway address changes periodically. Servers, for exactly the same reason, often have statically assigned IP addresses also, and therefore, we will set aside the first 15 IP addresses -- 192.168.1.1 through 192.168.1.15 -- for servers and network equipment. Consequently, our DHCP server will assign addresses in the range 192.168.1.16 through 192.168.1.254 to client PCs. Also, our DNS servers for all three networks are located at 192.168.1.6 and 192.168.2.6; we'll assign those name server addresses to client PC's, as well. Let's get started:

root@main3200# edit system services

[edit system services]
root@main3200# set dhcp domain-name main.example.com

[edit system services]
root@main3200# set dhcp router 192.168.1.1

[edit system services]
root@main3200# set dhcp pool 192.168.1.0/24 address-range low 192.168.1.16 high 192.168.1.254

[edit system services]
root@main3200# set dhcp name-server 192.168.1.6

[edit system services]
root@main3200# set dhcp name-server 192.168.2.6

[edit system services]
root@main3200# commit
commit complete

[edit system services]
root@main3200#


That's it!

Now, hook up a PC to one of the ports in the default VLAN, and see if it obtains an address in the 192.168.1.0/24 net block:

me@myllt:~$ ip addr | egrep -A3 "eth0:"
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:24:e8:cb:f9:e9 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.16/24 brd 192.168.1.255 scope global eth0
    inet6 fd04:4879:556a:0:24:e8ff:fecb:f9e9/64 scope global
me@myllt:~$


Sweet! My laptop obtained the IP address 192.168.1.16/24 automatically from the DHCP service on the EX3200 switch!

However, we still have a problem. If you recall, we had planned not just one, but two VLANs on this physical network: the default VLAN for hosts like my laptop, but also a Voice-over-IP VLAN for our internal PBX. It's nice not to have to statically assign IP addresses to desktops and laptops, but wouldn't it be nice to also have DHCP hand off IP addresses automatically to the VoIP telephones, too?

Fortunately, that's not a problem, either. All we have to do is set up a separate DHCP pool using the same net block that we put the VoIP VLAN into:

root@main3200# set dhcp router 192.168.10.1

[edit system services]
root@main3200# set dhcp pool 192.168.10.0/24 address-range low 192.168.10.8 high 192.168.10.254

[edit system services]
root@main3200# set dhcp sip-server address 192.168.10.2

[edit system services]
root@main3200# commit
commit complete

[edit system services]
root@main3200#


Now, to test, we'll connect another laptop to one of the ports in the VoIP VLAN and see if we get a 192.168.10.xxx address:

me@myllt2:~$ ip addr | egrep -A3 "eth0:"
2: eth0: mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:15:c5:08:5d:92 brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.8/24 brd 192.168.10.255 scope global eth0
    inet6 fd04:4879:556a:0:15:c5ff:fe08:5d92/64 scope global
me@myllt2:~$


Yep, it worked! We now have both the default VLAN and the VoIP VLAN receiving IP addresses automatically.

It's outside of the scope of this lesson, but just for grins, let's see if OSPF will route across the VLANs for us:

me@myllt2:~$ ping -c1 192.168.1.16
PING 192.168.1.16 (192.168.1.16) 56(84) bytes of data.
64 bytes from 192.168.1.16: icmp_req=1 ttl=63 time=1.82 ms

--- 192.168.1.16 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.822/1.822/1.822/0.000 ms
me@myllt2:~$


There's that "routing-on-a-stick" we discussed earlier in action for ya' ;)

Wednesday, October 23, 2013

JNCIA Lesson 1: Basic LAN Configuration

Congratulations! Because of your experience with networking in general, and Juniper equipment in particular, you have just landed a network administrator job with a new, small company. You will be responsible for building the network infrastructure for the new company. Your first decision in this role was to purchase two brand new Juniper EX3200 Layer-3 switches to use for both LAN switching and to route traffic to and from your Internet Service Provider.

First, of course, is racking the equipment and connecting the associated cables -- power, management console, etc. That is a breeze, and in less than half an hour, your new Juniper switches are happily humming away. You connect a serial cable from your laptop to the console port (NOT the "Management" port, however -- that's an Ethernet port for management access!), and are greeted by the Juniper's shell prompt:

root@:RE:0%

You type a few Unix commands:

root@:RE:0% ls
.cshrc  .history  .login  .profile
root@:RE:0% uname -a
JUNOS ex3200 11.4R7.5 JUNOS 11.4R7.5 #0: 2013-03-01 10:14:08 UTC  builder@evenath.juniper.net:/volume/build/junos/11.4/release/11.4R7.5/obj-powerpc/bsd/kernels/JUNIPER-EX/kernel powerpc
root@:RE:0%
Notice that it's running a BSD kernel (FreeBSD, to be exact). You want to begin configuring the switch, so you execute the "cli" command to access JunOS:

root@:RE:0% cli
root@ex3200>


The switch comes with a very basic configuration...:

root@ex3200> show configuration
version 11.4R7.5;
system {
    host-name ex3200;
    syslog {
        user * {
            any emergency;
        }
        file messages {
            any notice;
            authorization info;
        }
        file interactive-commands {
            interactive-commands any;
        }
    }
}
interfaces {
    ge-0/0/0 {
        unit 0 {
            family ethernet-switching;
        }
    }
    ge-0/0/1 {
        unit 0 {
            family ethernet-switching;
        }
    }
    ge-0/0/2 {
        unit 0 {
            family ethernet-switching;
        }
    }
    ge-0/0/3 {
        unit 0 {
            family ethernet-switching;
        }
    }
    ge-0/0/4 {
        unit 0 {
            family ethernet-switching;
        }
    }
    ge-0/0/5 {
        unit 0 {
            family ethernet-switching;
        }
    ge-0/0/6 {
        unit 0 {
            family ethernet-switching;
        }
    }
    ge-0/0/7 {
        unit 0 {
            family ethernet-switching;
        }
    }
    ge-0/0/8 {
        unit 0 {
            family ethernet-switching;
        }
    }
    ge-0/0/9 {
        unit 0 {
            family ethernet-switching;
        }
    }
    ge-0/0/10 {
        unit 0 {
            family ethernet-switching; 
        }
    }
    ge-0/0/11 {
        unit 0 {
            family ethernet-switching;
        }
    }
    ge-0/0/12 {
        unit 0 {
            family ethernet-switching;
        }
    }
    ge-0/0/13 {
        unit 0 {
            family ethernet-switching;
        }
    }
    ge-0/0/14 {
        unit 0 {
            family ethernet-switching;
        }
    }
    ge-0/0/15 {
        unit 0 {
            family ethernet-switching;
        }
    }
    ge-0/0/16 {
        unit 0 {
            family ethernet-switching;
        }
    }
    ge-0/0/17 {
        unit 0 {
            family ethernet-switching;
        }
    }
    ge-0/0/18 {
        unit 0 {
            family ethernet-switching;
        }
    }
    ge-0/0/19 {
        unit 0 {
            family ethernet-switching;
    }
    ge-0/0/20 {
        unit 0 {
            family ethernet-switching;
        }
    }
    ge-0/0/21 {
        unit 0 {
            family ethernet-switching;
        }
    }
    ge-0/0/22 {
        unit 0 {
            family ethernet-switching;
        }
    }
    ge-0/0/23 {
        unit 0 {
            family ethernet-switching;
        }
    }
    ge-0/1/0 {
        unit 0 {
            family ethernet-switching;
        }
    }
    xe-0/1/0 {
        unit 0 {
            family ethernet-switching;
        }
    }
    ge-0/1/1 {
        unit 0 {
            family ethernet-switching;
        }
    }
    xe-0/1/1 {
        unit 0 {
            family ethernet-switching;
        }
    }
    ge-0/1/2 {
        unit 0 {
            family ethernet-switching;
        }
    }
    xe-0/1/2 {
        unit 0 {
            family ethernet-switching;
        }
    }
    ge-0/1/3 {
        unit 0 {
            family ethernet-switching;
        }
    }
}
protocols {
    igmp-snooping {
        vlan all;
    }
    rstp;
    lldp {
        interface all;
    }
    lldp-med {
        interface all;
    }
}
ethernet-switching-options {
    storm-control {
        interface all;
}
vlans {
    default {
        l3-interface vlan.0;
    }
}
poe {
    interface all;
}

root@ex3200>


With all of the indentations, curly braces and semi-colons, the configuration greatly resembles a Unix/Linux configuration file, rather than a typical network vendor's config file, you think to yourself. At first, it makes the config look a little long-winded, but it's pretty easy to read, once you get used to it.

However, the basic, default configuration is missing some very important elements that you will need to add. First, you decide to give the switch a more meaningful name. Since this will be the switch/router for the main office campus, you decide to change the name to main3200. You enter configuration mode and start to make the necessary changes:

root@ex3200> configure
Entering configuration mode

[edit]
root@ex3200# set system host-name main3200

[edit]
root@ex3200#


Notice that that didn't seem to change anything. Juniper doesn't actually make the changes live until you commit them, using -- of all things -- the "commit" command.:

root@ex3200# commit
commit complete

[edit]
root@main3200#


JunOS also includes a nifty feature to allow you to undo a change. When committing a configuration change, JunOS copies the existing configuration to an archive before writing the new config to storage. Consequently, if you make a change that breaks something, you can always roll back to an earlier configuration:

root@main3200# set system host-name oops

[edit]
root@main3200# commit
commit complete

[edit]
root@oops# rollback 1
load complete

[edit]
root@oops# commit
commit complete

[edit]
root@main3200#


There are a number of other cool features available when committing changes: you can tentatively commit the changes...:

root@main3200# set host-name mo3200

[edit system]
root@main3200# commit confirmed
commit confirmed will be automatically rolled back in 10 minutes unless confirmed
commit complete

# commit confirmed will be rolled back in 10 minutes
[edit system]
root@mo3200#
Broadcast Message from root@main3200
(no tty) at 8:37 AKDT...

Commit was not confirmed; automatic rollback complete.


Cool...this could be handy when configuring remote systems, where a botched config could mean downtime while you drive across town [Edit: or fly across the country, which would be the case in my real day job]. Use "commit confirmed", and if the new config doesn't work, it will automatically roll back to the previous version after the time-out period, and you can try again.

To confirm the commit, just type "commit" again:

...
# commit confirmed will be rolled back in 10 minutes
[edit]
root@main3200# commit
commit complete

[edit]
root@main3200#


You can also simply view the changes to the active configuration...:

root@main3200# show | compare rollback 1
[edit system]
- host-name mo3200;
+ host-name main3200;

[edit]
root@main3200#
...or check the config changes without actually making them active...:

root@main3200# commit check
configuration check succeeds

[edit]
root@main3200#


Another point about JunOS that's worth noting: if you look at the "system" portion of the default config...:

root@ex3200> show configuration
version 11.4R7.5;
system {
    host-name ex3200;
    syslog {
        user * {
            any emergency;
        }
        file messages {
            any notice;
            authorization info;
        }
        file interactive-commands {
            interactive-commands any;
        }
    }
}


Notice the hierarchy for the host-name setting:

system | host-name

When we changed the hostname, we did so with the "set system host-name main3200" command. However, sometimes, you will be making a number of changes under a hierarchy, and it can be a bit of a chore repeating all of the hierarchy for every change you want to make. Consequently, you can tell JunOS that you want to work within a particular portion of the hierarchy, and to assume that all of the commands you are running are to be taken in the context of that hierarchy. For example, these two commands are identical to the Juniper:

root@ex3200# set system host-name main3200

[edit]
root@ex3200# commit
commit complete

[edit]
root@main3200#


...and...:

root@ex3200# edit system

[edit system]
root@ex3200# set host-name main3200

[edit system]
root@ex3200# commit
commit complete

[edit system]
root@main3200#


Think of it as being similar to the difference between...:

me@myllt:~$ cp /var/www/localhost/htdocs/gallery/images/thumbnails/some.jpg /var/www/localhost/htdocs/gallery/images/thumbnails/some-other.jpg


...and...:

me@myllt~$ cd /var/www/localhost/htdocs/gallery/images/thumbnails/
me@myllt:/var/www/localhost/htdocs/gallery/images/thumbnails$ cp some.jpg some-other.jpg


It's the exact same thing: you are setting the position within the hierarchy in which you want to work. In the trivial examples above, it might not seem like the "edit..." syntax saves much effort, but suppose you want to make a number of changes to an Ethernet port -- say, hard-code speed and duplex and set a description:

root@main3200# edit interfaces ge-0/0/4

[edit interfaces ge-0/0/4]
root@main3200# set description "Legacy Billing Server"

[edit interfaces ge-0/0/4]
root@main3200# set ether-options speed 10m

[edit interfaces ge-0/0/4]
root@main3200# set ether-options link-mode half-duplex

[edit interfaces ge-0/0/4]
root@main3200# set ether-options auto-negotiation no-flow-control

[edit interfaces ge-0/0/4]
root@main3200# commit check
configuration check succeeds

[edit interfaces ge-0/0/4]
root@main3200# commit
commit complete

[edit interfaces ge-0/0/4]
root@main3200#


If you hadn't used the "edit interface ge-0/0/4" command, you would have had to type this instead:

root@main3200# set interfaces ge-0/0/4 description "Legacy Billing Server"

[edit]
root@main3200# set interfaces ge-0/0/4 ether-options speed 10m

[edit]
root@main3200# set interfaces ge-0/0/4 ether-options link-mode half-duplex

[edit]
root@main3200# set interfaces ge-0/0/4 ether-options auto-negotiation no-flow-control

[edit]
root@main3200# commit check
configuration check succeeds

[edit]
root@main3200# commit
commit complete

[edit]
root@main3200#


Let's configure some other basic settings on the switch:

root@main3200# set system domain-name example.com

[edit]
root@main3200# set system root-authentication plain-text-password
New password:
Retype new password:

[edit]
root@main3200# set system services ssh protocol-version v2

[edit]
root@main3200#


With those commands, we have set the domain name, set a root password and enabled SSH access. However, you will probably have a hard time using SSH to connect to the switch, since the switch does not have a management IP address set. Let's address that issue now:

root@main3200# set interfaces vlan unit 0 family inet address 192.168.1.1/24

[edit]
root@main3200# commit
commit confirmed

[edit]
root@main3200#


With that, you should have a minimal working configuration on your switch. Each of the 24 Ethernet ports is enabled and will allow hosts to communicate with each other, and you can SSH to the switch for management access at 192.168.1.1.

That's a good start on a basic, real-world configuration for a LAN switch, but there are a couple of other things to do, too. First, in a one-person shop, it might be fine to simply use the root account for all configuration. However, if there are (or will be) multiple admins managing network devices, then it might be wise to configure separate logins for each user. Let's create three user accounts on the EX-3200 -- an admin account for you, an admin account for your assistant George and a read-only account for your Network Operations Center (NOC):

root@main3200# set system login class noc permissions interface

[edit]
root@main3200# set system login class noc permissions view

[edit]
root@main3200# set system login user nocuser class noc authentication plain-text-password
New password:
Retype new password:

[edit]
root@main3200# set system login user mike class super-user authentication plain-text-password
New password:
Retype new password:

[edit]
root@main3200# set system login user george class super-user authentication plain-text-password
New password:
Retype new password:

[edit]
root@main3200# commit
commit complete

[edit]
root@main3200#


You can also configure TACACS or RADIUS authentication:

root@main3200# set system authentication-order [radius password]

[edit]
root@main3200# set system radius-server 192.168.1.17 secret myradiussecretpw

[edit]
root@main3200# commit
commit confirmed

[edit]
root@main3200#


Next, you want the switch to forward logs to a syslog server, located at 192.168.1.20:

root@main3200# set system syslog host 192.168.1.20 any any

[edit]
root@main3200#


If you wanted, you could also send firewall logs to one server, or send warning (or higher) messages to a third server:

root@main3200# set system syslog host 192.168.1.21 firewall any

[edit]
root@main3200# set system syslog host 192.168.1.20 any warning


[edit]
root@main3200# commit
commit confirmed

[edit]
root@main3200#


Next, we will configure the switch to set its internal clock with a local NTP server...:

root@console9# set system ntp server 192.168.1.23

[edit]
root@main3200# commit
commit confirmed

[edit]
root@main3200#


...and we will configure SNMP on the switch:

root@main3200# set system location building "123 A Street" country-code US postal-code 12345 floor 2 rack 36

[edit]
root@main3200# set snmp community my-ro-community-string authorization read-only

[edit]
root@main3200# set snmp community my-rw-community-string authorization read-write

[edit]
root@main3200# root@console9# set snmp contact miswork@uui-alaska.com

[edit]
root@main3200# set snmp location Anchorage

[edit]
root@main3200# commit
commit complete

[edit]
root@main3200#


That leaves one last, very important step before we are done: we need to create a "rescue configuration." The rescue configuration is a "known good" configuration that provides basic connectivity to the switch, if the current configuration is deleted or lost. To be honest, I'm not sure I see the point of the rescue configuration, since JunOS keeps an archive of past configs (perhaps, just in case you have moved/re-addressed the switch?), but...we'll go ahead and create one from our current configuration. First, notice that there is no rescue configuration yet:

root@main3200> file list /config/

/config/:
.snap/
db /
juniper.conf.1.gz
juniper.conf.2.gz
juniper.conf.3.gz
juniper.conf.gz
ssh_host_dsa_key
ssh_host_dsa_key.pub
ssh_host_ecdsa_key
ssh_host_ecdsa_key.pub
ssh_host_key
ssh_host_key.pub
ssh_host_rsa_key
ssh_host_rsa_key.pub
usage.db
vchassis/

[edit]
root@main3200>


We'll save the current configuration as the rescue configuration, and show the contents of the /config directory again:

root@main3200> request system configuration rescue save

root@main3200> file list /config/

/config/:
.snap/
db /
juniper.conf.1.gz
juniper.conf.2.gz
juniper.conf.3.gz
juniper.conf.gz
rescue.conf.gz
ssh_host_dsa_key
ssh_host_dsa_key.pub
ssh_host_ecdsa_key
ssh_host_ecdsa_key.pub
ssh_host_key
ssh_host_key.pub
ssh_host_rsa_key
ssh_host_rsa_key.pub
usage.db
vchassis/

root@main3200>


Notice the new, bold-face file in the listing [edit: it's not actually bold-face on the switch; I highlighted it so it would stand out]? That's the rescue configuration. If you need to remove the rescue configuration, the "request system configuration rescue delete" command will do it. If you reboot the switch without an active configuration, the switch will boot with the rescue configuration, instead. Once the switch has booted, you can commit to write a new active configuration to the file system.