Let’s say we need to setup a quick DHCP server on IOS and JunOS.
We’ve been tasked with configuring DHCP to give out addresses in the 192.168.1.0/24 subnet, but only from 192.168.1.2 to 192.168.1.100.
We’ve also been asked to not give out 192.168.1.50 as this has been hardcoded in the local fileserver. The lease time should only be 1 hour, and the default gateway should be 192.168.1.1
This is how we do it on the IOS we know and love:
>conf t #ip dhcp pool 192.168.1.0/24 #network 192.168.1.0 255.255.255.0 #default-router 192.168.1.1 #lease 0 1 #exit #ip dhcp excluded-address 192.168.1.101 192.168.1.255 #ip dhcp excluded-address 192.168.1.1 #ip dhcp excluded-address 192.168.1.50
Now on JunOS:
> configure # edit system service dhcp # set default-lease-time 3600 # set router 192.168.1.1 # set pool 192.168.1.0/24 address-range low 192.168.1.2 high 192.168.1.100 # set pool 192.168.1.0/24 exclude-address 192.168.1.50
There are extra things you can add to both, like domain name and so on, but I wanted a quick and dirty comparison between the 2. Remember that you will need an interface in the scope on either router in order for DHCP to actually work.
Let’s now say that we do have a DHCP server. This server is on another subnet, and so DHCP requests won’t get through (as they are broadcasted). Consider the following topology:
Both IOS and JunOS allows you to configure the router as a DHCP relay agent. This is how it’s done.
On IOS it’s extremely simple. All you need to do is put the following command on the interface receiving the broadcast. In this topology it’ll be the interface connected to the switch and workstation the user is on
>conf t # int fa0 # ip helper-address 10.1.1.1
On JunOS it’s just as simple. The configuration is not put on a particular interface, rather you specify which interface will be receiving the broadcast.
> configure # set forwarding-options helpers bootp interface em1 # set forwarding-options helpers bootp server 10.1.1.1
Nice and easy :)
Let’s set up a basic OSPF adjacency between JunOS and IOS. I’ve got the following simple topology:
The good thing here is that the configs shown will show the difference between JunOS and IOS as the actual configuration goal is the same for both.
The Cisco config is as follows:
Router>conf t #int fa0 #ip address 192.168.1.2 255.255.255.0 #int lo100 #ip address 172.16.10.1 255.255.255.0 #router ospf 1 #network 192.168.1.0 0.0.0.255 area 0 #network 172.16.10.0 0.0.0.255 area 0 #exit
Now onto JunOS:
root@Olive>configure # set interfaces em1 unit 0 family inet address 192.168.1.2/24 # set interfaces lo0 unit 100 family inet address 172.16.20.1/24 # edit protocols ospf area 0 # set interface 192.168.1.1 # set interface 172.16.20.1
Let’s see what we see on the Cisco:
Router#sh ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
172.16.20.1 128 FULL/BDR 00:00:34 192.168.1.1 FastEthernet0
Router#sh ip route
172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
O 172.16.20.0/24 [110/1] via 192.168.1.1, 00:00:25, FastEthernet0
O 172.16.20.1/32 [110/1] via 192.168.1.1, 00:00:25, FastEthernet0
C 172.16.10.0/24 is directly connected, Loopback100
C 192.168.1.0/24 is directly connected, FastEthernet0
What about the Olive?
root@Olive> show ospf neighbor
Address Interface State ID Pri Dead
192.168.1.2 em1.0 FULL 172.16.10.1 1 36
root@Olive>show route
172.16.10.1/32 *[OSPF/10] 00:09:05, metric 2
> to 192.168.1.2 via em1.0
And yes, both routers can ping both loopbacks :)
Right, it’s really time I get cracking on with my JNCIA. I’m going to do the EX track first, then maybe ER as well.
I’ve set up an Olive quickly and connected it to a 1721 via dynamips. I want to start off with the basics of getting around the cli of JunOS. Yes it’s different to IOS, but it’s really not that difficult.
When the Olive first boots up, it’ll be a blank slate. If you logged in as root, you’ll need to enter cli to actually get to the cli:
root@O%cli root@O>
Right, now we are at the CLI. Let’s start configuring!
First go into configure mode:
root@O> configure Entering configuration mode [edit] root@O#
Let’s start with a few basics. These few are all intuitive:
#set system host-name Olive #set system time-zone Europe/London #set system domain-name test.com #set system name-server 4.2.2.1
Note that JunOS won’t make these changes live straight away. All changes go into a ‘candidate configuration’ – Only when you actually commit the changes will they actually happen. You can commit straight away or do a syntax check beforehand:
#commit check configuration check succeeds
This means all looks good, so let’s commit the changes!
#commit commit complete [edit] root@Olive#
There is something to note here. JunOS’s config mode is hierarchical. This means that if I was going to do a lot of commands in the same sub-section – I could go into that sub-section first.
For example, the above 4 commands were all in the system sub-section. Instead of the above, I could’ve done this:
root@O> configure Entering configuration mode [edit] root@O#edit system [edit system] root@O#set host-name Olive #set time-zone Europe/London #set domain-name test.com #set name-server 4.2.2.1
This would give me exactly the same configuration as the above. If I need to get out of a sub-section I just type ‘up’
#up [edit] root@O#
If I’m in pretty deep, you can type ‘top’ to get right to the top of the tree
Now we need to set up an IP address on an interface. To see what interfaces you have, you can type:
Olive> show interfaces terse
This command is similar to show ip int brief on a Cisco
I want to configure the em1 interface and I do so like this:
Olive# set interfaces em1 unit 0 family inet address 10.1.1.1/28
So quite a bit longer than on a Cisco, but it’s really not that difficult. There is an important note here. When you assign an IP address to a Cisco, it becomes the ‘first’ IP. You can add secondary addresses on that interface but you need to specify secondary when entering the IP address. The same thing happens on JunOS, but you HAVE to specify a logical unit at all times, even if it is only EVER going to have 1 IP. Therefore Unit 0 is the first IP, unit 1 the second, unit 2 the third and so on. If I wanted to add a second IP to this interface, I’d do it like so:
Olive# set interfaces em1 unit 1 family inet address 10.2.2.2/28
To set up a default route, we do it like so:
Olive# set routing-options static route 0.0.0.0/0 next-hop 10.1.1.2
There’ll be plenty more JunOS stuff coming very shortly!
Rule #1 – Just because Host 1 can get to Host 2, does NOT mean that Host 2 can get back to Host 1!
I can’t tell you how many times I’ve seen this out in the field. Here is a prime example.
This is quite a simply common topology. OfficeA and OfficeB have a WAN connection running between them. RouterA and RouterB are under control of the ISP and are running OSPF. RouterC is a customer-owned router, and so doesn’t run any OSPF with RouterA or RouterB.
OfficeB has an internet connection, and RouterB is injecting a default route to OfficeA via OSPF.
RouterB has a default route to RouterC. So let’s think about traffic flow now. A host connected to RouterA needs to send traffic to the internet. It will send it’s traffic to it’s default gateway, RouterA. RouterA has a default route injected into OSPF from RouterB and so sends traffic to RouterB.
RouterB has a default route and hence sends that traffic out to RouterC. Which then goes out to the internet.
Traffic then flows back from the internet to RouterC. The return address will be an IP that belongs in RouterA and RouterB’s routing table, however RouterC has no knowledge of that subnet (as it’s not participating in OSPF). RouterC will just use it’s default route and send that packet back out to the internet. Eventually the TTL will kill that packet.
This can be fixed by putting a static route on RouterC to let it know that RouterA’s ip range needs to be sent off to RouterB instead.
A similar thing will happen if we add a server to SwitchA. That server’s default gateway will most likely be RouterC. If a host in OfficeA send a PING to that server, that server will then send traffic off to RouterC. If RouterC does not have the static route added above, it’ll send it out to the internet.
I’m well aware that the design in the picture is pretty bad, but I used it to illustrate a point. That point being that just because router’s know how to get from A to B, it does NOT mean they know how to route that traffic back. Make sure you understand this!
I was tasked without setting up some IP SLA’s over our network to check performance at various points in the network. I’m not going to go hardcore into how to configure it, as Cisco has an excellent guide right here: http://www.cisco.com/en/US/docs/ios/12_4/ip_sla/configuration/guide/hsjitter.html
There is something I wanted to point out though. I installed a 3750 in the core running the actual tests. IP SLA requires another Cisco router to actually respond to those tests, basically an IP SLA Responder. It seemed to me that a lot of devices we had simply did not support IP SLA, or at least I though.
IP SLA used to be called something completely different. In IOS release 12.1 (4) they released a feature called SAA Monitor. The commands used to configure it were completely different to IP SLA. Basically instead of typing:
Cisco(config)#ip sla responder
The command was instead:
Cisco(config)#rtr responder
My last post about Traceroute over here: http://mellowd.co.uk/ccie/?p=609 – got some interesting conversation going on in the comments.
Basically there is quite a big difference in the way in which Windows and Linux handle traceroute. I tested on both Windows 7 and Ubuntu 10.04, but my guess is that all Windows follow the same format as do all *nix’s (please let me know if otherwise though!)
I would recommend reading the above post again quickly to get all the basics out the way before we delve into the differences.
Step-wise, this is what happens on Windows:
- The OS send a DNS PTR request to 1.2.2.4.in-addr.arpa to get the hostname for 4.2.2.1
- I get a DNS PTR response giving me a hostname
- The OS send an ICMP ECHO request with a TTL of 1
- I get an ICMP TTL Exceeded packet back from my local router
- 3 & 4 above happens twice more
- The OS send a DNS PTR request to my local router
- My local router responds with it’s hostname
- The cycle above (3-7) is then repeated with a TTL of 2, then 3 and so on
- We finally get to 4.2.2.1 – which sends back an ICMP ECHO reply – Once I get 3 the job is complete.
Ubuntu does this completely differently though. Step-wise this is what’s going on:
- The OS immidiately sent 3 UDP packets with a high port number straight to 4.2.2.1 with a TTL of 1
- The local router responded with 3X ICMP TTL Exceeded message
- The above (1 & 2) is then repeated until we get to 4.2.2.1
- 4.2.2.1 does not generate a ICMP ECHO reply as an ECHO request was not sent. Rather we get 3 ICMP Code 3 (Port unreachable) replies
- The OS now throws out 7 DNS PTR request specifically to each IP it determined in the path from above (Including 4.2.2.1 iself!)
- As soon as all the replies come, the job is complete.
The main differences are that Windows will send a DNS PTR request from the start, then send ICMP ECHO requests. At each hop it’ll send a DNS PTR request and then move onto the next hop.
Linux starts with sending UDP packets to a high port number straight away. When it finally gets to the last hop it’ll then send out a mass DNS PTR request to every hop in the path that it has determined.
Traceroute is a powerful tool. Extremely useful when checking the path of a packet through the network. But how does it ACTUALLY work? What is REALLY going on?
Layer3 packets all have a TTL. A Time To Live. If a router receives a packet with a TTL of 1 (and the packet is addresses to a host not directly connected to this router) it will drop the packet. It will also then create an ICMP error packet and send it back to the original source of the packet to let it know that the address was unreachable this time.
If you ping another machine, the OS will generally create a TTL of 255 for sent packets, though it doesn’t HAVE to be 255.
Traceroute will force an ICMP error message so it can get more information from each hop in the path.
As an example, let’s run a quick traceroute to 4.2.2.1 and see what it gives us:
C:\Users\Darren>tracert 4.2.2.1 Tracing route to vnsc-pri.sys.gtei.net [4.2.2.1] over a maximum of 30 hops: 1 1 ms <1 ms <1 ms DD-WRT [10.50.80.1] 2 8 ms 9 ms 8 ms 10.3.280.1 3 8 ms 9 ms 26 ms walt-cam-1a-ge96.network.virginmedia.net [80.1.170.69] 4 18 ms 7 ms 8 ms popl-core-1a-ae2-0.network.virginmedia.net [195.182.175.229] 5 8 ms 6 ms 16 ms popl-bb-1a-as2-0.network.virginmedia.net [213.105.174.234] 6 31 ms 15 ms 15 ms 195.50.91.69 7 12 ms 13 ms 31 ms ae-11-51.car1.London1.Level3.net [4.69.139.66] 8 14 ms 16 ms 22 ms vnsc-pri.sys.gtei.net [4.2.2.1] Trace complete.
I’ve loaded up Wireshark to tell me exactly what’s going on. The very first packet sent from my PC was sent with a destination IP of 4.2.2.1 – but with a TTL of only 1.
When my router (10.50.80.1) received that packet, it noticed that the TTL was 1, but also that 4.2.2.1 was not directly connected to it. It responded to my PC with an ICMP code 11 – Time-to-live exceeded. It also responded with it’s own source address.
Traceroute now knows that the very first hop to 4.2.2.1 happens to be my local router. It also knows that the routers IP is 10.50.80.1 – It send 3 ECHO reply requests with a TTL of 1. This is the reason you see the 3 values in the traceroute output
It doesn’t stop there though. As soon as traceroute knows that 10.50.80.1 is the first hop, it’ll ask 10.50.80.1 what it’s hostname is via a DNS PTR request. The router will respond to my PC with a DNS PTR response letting it know the hostname. Now traceroute knows what the IP address and hostname is for the first hop. Note that not ALL devices on the internet will respond with a PTR record and so you won’t ALWAYS get a hostname.
Traceroute will now start again and send 3 more packets with a TTL of 2. Exactly the same will happen as above, but for the second hop in the path. This will continue to happen until we eventually get to the host, or we run into the maximum hop count.
When we finally get ICMP echo replies from 4.2.2.1 – traceroute knows it’s job is complete.
btw, traceroute attempts to get PTR records from the devices in the path only when it gets a TTL time exceeded reply. The actual host you are trying to get to is different though. As soon as I ran traceroute 4.2.2.1 it immediately tried to get the PTR record of 4.2.2.1 first. Once it had that it started with all of the above.
What is ARP and how does it actually work? I’m surprised at the amount of people who don’t know exactly what it does and how important it is.
To illustrate, I’m going to use this extremely simple network:
Both of these systems are really just connected to a home router. Remember that these ports are really just switched ports. The only time they traverse a layer3 port is when they are sending traffic outside the local LAN.
ARP is the Address Resolution Protocol. Essentially all it does is resolve a logical IP address to a physical Hardware (MAC) address.
In the above diagram, if 10.20.30.108 wants to send traffic to 10.20.30.4, it will move down the IOS layers. It will eventually get down to layer2. The layer2 header needs to have both a source and a destination MAC address. 10.20.30.108 has the layer3 address already, but not layer2. This is where ARP comes into the picture.
10.20.30.108 will send a broadcast out onto the lan asking that whoever holds 10.20.30.4 respond with it’s MAC address (In that broadcast it’ll let everyone know what the MAC address of 10.20.30.108 is – so they can reply). When 10.20.30.4 get’s that broadcast, it’ll respond with it’s OWN MAC address with a unicast.
Once 10.20.30.108 has received 10.20.30.4′s MAC address, it will add that mapping to it’s own local ARP cache. As long as that value is in the cache, it’ll know exactly how and where to send traffic bound for 10.20.30.4
As an example, I’ve run the above through wireshark to see exactly what is happening (Click the image to see the full request and response):
The first ARP packet was a broadcast to the local lan asking for the owner of the 10.20.30.4 address. It also asks to respond to 10.20.30.108 (this ARP request also contains 10.20.30.108′s own MAC address) – The second packet is a simple unicast back to 10.20.30.108 letting it know that 10.20.30.4′s MAC address is 00:11:32:06:0c:8a
This can be verified as follows:
C:\Windows\system32>arp -a Interface: 10.20.30.108 --- 0xb Internet Address Physical Address Type 10.20.30.4 00-11-32-06-0c-8a dynamic
ARP is one of the fundamental parts of TCP/IP – Make sure you know it :)
Sign it here: http://etherealmind.com/petition/
DO IT!!!
We the undersigned ask you to sign our petition.
We are the people who are learning about Data networking and Cisco IOS software. As students and practitioners, we need to learn theory and knowledge and then to take that knowledge and practice on Cisco IOS software.
We want to be able to practice that knowledge, and demonstrate our competence. We know that you are considering the value. This petition is to show our need for this solution. Wendel Odom discusses the possibility Cisco Considers IOS for Certifcation Self Study and we are calling for Cisco to make an option available.
This experience and knowledge we gain gives us the capability to make the most of Cisco equipment for our employers, your customers. We help drive the best return on investment, and keep the network performing in the way that your customers expect.
We can test configurations prior to making and be better prepared. We can develop more complex configurations than would otherwise be possible, and not blame the equipment afterwards.
We resolve problems more quickly, we make better designs and we have greater confidence in our work. We raise less support cases (and reduce your costs) by being to perform our own testing and validation.
Whether we are resellers, consultants, students or just interested in learning, we all need an practical method to access IOS and practice.
Therefore, we are asking Cisco Systems to make a version of IOS available for educational and testing purposes.
Greg Ferro
STP works extremely well, but you lose operational links with it. i.e. you lose bandwidth. There are also quite a few other problems with STP (convergence speed being 1 of them)
TRILL seems to be the new technology coming in to resolve this. I’ve gone through the RFC: http://tools.ietf.org/html/rfc5556 and it looks pretty awesome stuff. I particularly like the following:
3.2. Zero Configuration and Zero Assumption
Both bridges and hubs are zero configuration devices; hubs having no
configuration at all, and bridges being automatically self-
configured. Bridges are further zero-assumption devices, unlike
hubs. Bridges can be interconnected in arbitrary topologies, without
regard for cycles or even self-attachment. Spanning tree protocols
(STPs) remove the impact of cycles automatically, and port
autolearning reduces unnecessary broadcast of unicast traffic.A TRILL solution should strive to have a similar zero-configuration,
zero-assumption operation. This includes having TRILL solution
components automatically discover other TRILL solution components and
organize themselves, as well as to configure that organization for
proper operation (plug-and-play). It also includes zero-
configuration backward compatibility with existing bridges and hubs,
which may include interacting with some of the bridge protocols, such
as spanning tree.VLANs add a caveat to zero configuration; a TRILL solution should
support automatic use of a default VLAN (like non-VLAN bridges), but
would undoubtedly require explicit configuration for VLANs where
bridges require such configuration.Autoconfiguration extends to optional services, such as multicast
support via Internet Group Management Protocol (IGMP) snooping,
broadcast support via serial copy, and support of multiple VLANs.
and
3.4. Spanning Tree Management
In order to address convergence under reconfiguration and robustness
to link interruption (Section 2.2), participation in the spanning
tree (STP) must be carefully managed. The goal is to provide the
desired stability of the TRILL solution and of the entire Ethernet
link subnet, which may include bridges using STP. This may involve a
TRILL solution participating in the STP, where the protocol used for
TRILL might dampen interactions with STP, or it may involve severing
the STP into separate STPs on ‘stub’ external Ethernet link subnet
segments.A requirement is that a TRILL solution must not require modifications
or exceptions to the existing spanning tree protocols (e.g., STP,
RSTP (Rapid Spanning Tree Protocol), MSTP (Multiple Spanning Tree
Protocol)).
Basically, even though TRILL sounds complicated, it very well could be plug and play (well about as plug and play as current STP mind you)
Comments