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.
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
This VPN lab will test intranet and extranet MPLS VPN’s.
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 lab topology again:
- CPE1 and CPE5 belong to Customer1
- CPE2 and CPE6 belong to Customer2
- Both customers are running OSPF as their IGP’s
- The loopbacks as shown in the topology must be advertised into OSPF. Cutomer1 should be able to ping all loopbacks in their networks and Customer2 should be able to ping everything in theirs.
- Both customers are now running a project together, and need 2 of their offices connected. CPE1 from Customer1 should be able to communicate with CPE6 from Customer2 and vice-versa
- It’s essential that CPE2 and CPE5 are NOT able to get to all loopbacks. ONLY CPE1 and CPE6 should be able to communicate with each other. This new configuration should not break the previous VPN’s in place
- Do this without using any ACL’s, Prefix-lists, Route-maps or the like
Hopefully this will be my final tweak. This time I’ve added base configs to the CPE devices. It just gives them a hostname and ensures there is no timeout. This prevents you from having to keep logging back in.
Image-wise, it’s the same. Click for the larger image:
This is the .net file contents:
#MPLS 1.0 Topology created by Darren O'Connor 22/02/10 #MPLS 1.1 created 23/02/10 #MPLS 1.2 created 24/02/10 #www.mellowd.co.uk/ccie #Feel free to use and change as you see fit. However if you do use please leave my details here at the top [localhost:7200] workingdir = /data/dynamips/working [[3640]] image = /data/dynamips/IOS_Images/3640/c3640-js-mz.124-25c.UNCOMPRESSED.bin ram = 128 disk0 = 0 disk1 = 0 mmap = true ghostios = true ########################### # # # Mpls Topology 1.2 # # # ########################### [[Router CR1]] model = 3640 console = 2001 autostart = true idlepc = 0x605105b8 slot0 = NM-1FE-TX slot1 = NM-4T slot2 = NM-1FE-TX s1/0 = AR1 s1/0 s1/2 = AR3 s1/2 Fa0/0 = CR3 Fa0/0 Fa2/0 = CR2 Fa2/0 cnfg = /data/dynamips/Topology/Topology_Config/mpls/CR1.cfg [[Router CR2]] model = 3640 console = 2002 autostart = true idlepc = 0x605105b8 slot0 = NM-1FE-TX slot1 = NM-4T slot2 = NM-1FE-TX s1/0 = AR2 s1/0 s1/2 = AR1 s1/2 Fa0/0 = CR4 Fa0/0 cnfg = /data/dynamips/Topology/Topology_Config/mpls/CR2.cfg [[Router CR3]] model = 3640 console = 2003 autostart = true idlepc = 0x605105b8 slot0 = NM-1FE-TX slot1 = NM-4T slot2 = NM-1FE-TX Fa2/0 = CR4 Fa2/0 s1/0 = AR3 s1/0 s1/1 = GR1 s1/1 s1/2 = AR4 s1/2 cnfg = /data/dynamips/Topology/Topology_Config/mpls/CR3.cfg [[Router CR4]] model = 3640 console = 2004 autostart = true idlepc = 0x605105b8 slot0 = NM-1FE-TX slot1 = NM-4T slot2 = NM-1FE-TX s1/0 = AR4 s1/0 s1/2 = AR2 s1/2 cnfg = /data/dynamips/Topology/Topology_Config/mpls/CR4.cfg [[Router AR1]] model = 3640 console = 2005 autostart = true idlepc = 0x605105b8 slot0 = NM-1FE-TX slot1 = NM-4T slot2 = NM-1FE-TX Fa0/0 = CPE1 Fa0/0 Fa2/0 = CPE2 Fa0/0 cnfg = /data/dynamips/Topology/Topology_Config/mpls/AR1.cfg [[Router AR2]] model = 3640 console = 2006 autostart = true idlepc = 0x605105b8 slot0 = NM-1FE-TX slot1 = NM-4T slot2 = NM-1FE-TX Fa0/0 = CPE4 Fa0/0 Fa2/0 = CPE3 Fa0/0 cnfg = /data/dynamips/Topology/Topology_Config/mpls/AR2.cfg [[Router AR3]] model = 3640 console = 2007 autostart = true idlepc = 0x605105b8 slot0 = NM-1FE-TX slot1 = NM-4T slot2 = NM-1FE-TX Fa0/0 = CPE5 Fa0/0 Fa2/0 = CPE6 Fa0/0 cnfg = /data/dynamips/Topology/Topology_Config/mpls/AR3.cfg [[Router AR4]] model = 3640 console = 2008 autostart = true idlepc = 0x605105b8 slot0 = NM-1FE-TX slot1 = NM-4T slot2 = NM-1FE-TX Fa0/0 = CPE8 Fa0/0 Fa2/0 = CPE7 Fa0/0 cnfg = /data/dynamips/Topology/Topology_Config/mpls/AR4.cfg [[Router CPE1]] model = 3640 console = 2009 autostart = false idlepc = 0x605105b8 slot0 = NM-1FE-TX cnfg = /data/dynamips/Topology/Topology_Config/mpls/CPE1.cfg [[Router CPE2]] model = 3640 console = 2010 autostart = false idlepc = 0x605105b8 slot0 = NM-1FE-TX cnfg = /data/dynamips/Topology/Topology_Config/mpls/CPE2.cfg [[Router CPE3]] model = 3640 console = 2011 autostart = false idlepc = 0x605105b8 slot0 = NM-1FE-TX cnfg = /data/dynamips/Topology/Topology_Config/mpls/CPE3.cfg [[Router CPE4]] model = 3640 console = 2012 autostart = false idlepc = 0x605105b8 slot0 = NM-1FE-TX cnfg = /data/dynamips/Topology/Topology_Config/mpls/CPE4.cfg [[Router CPE5]] model = 3640 console = 2013 autostart = false idlepc = 0x605105b8 slot0 = NM-1FE-TX cnfg = /data/dynamips/Topology/Topology_Config/mpls/CPE5.cfg [[Router CPE6]] model = 3640 console = 2014 autostart = false idlepc = 0x605105b8 slot0 = NM-1FE-TX cnfg = /data/dynamips/Topology/Topology_Config/mpls/CPE6.cfg [[Router CPE7]] model = 3640 console = 2021 autostart = false idlepc = 0x605105b8 slot0 = NM-1FE-TX cnfg = /data/dynamips/Topology/Topology_Config/mpls/CPE7.cfg [[Router CPE8]] model = 3640 console = 2022 autostart = false idlepc = 0x605105b8 slot0 = NM-1FE-TX cnfg = /data/dynamips/Topology/Topology_Config/mpls/CPE8.cfg [[Router GR1]] model = 3640 console = 2023 autostart = true idlepc = 0x605105b8 slot0 = NM-1FE-TX slot1 = NM-4T Fa0/0 = ISP2 Fa0/0 cnfg = /data/dynamips/Topology/Topology_Config/mpls/GR1.cfg [[Router ISP2]] model = 3640 console = 2024 autostart = false idlepc = 0x605105b8 slot0 = NM-1FE-TX cnfg = /data/dynamips/Topology/Topology_Config/mpls/ISP2.cfg
And here are the updated config files: http://mellowd.co.uk/ccie/wp-content/uploads/2010/02/mpls.tar2.gz
I recently bought an Acer Revo 3600 to replace my ageing PopcornHour A100. I’ve installed a minimal version of Ubuntu Linux on it as well as xbmc. As this is in my bedroom far away from my router, I only wanted to use the wireless chip.
As I have no gui, I have to manually set this up. If you do happen to be in some sort of gui and want to get out of it quickly, just press ctrl+alt+f1 or ctrl+alt+f2 and so on. This will just open up another terminal session for you.
You’ll need to know the name of your SSID as well as your password of course. In my case here I’m using WPA2. You’ll need to have wpasupplicant installed. If you have a wired connection it’ll be easy to install. If not you’ll need to get it elsewhere and copy it on your box. I am using Ubuntu, so the same method should work with Debian. Just use your distro’s packet manager to get it installed.
sudo apt-get install wpasupplicant
If not already root, you’ll now need to log in as root
sudo su -
Now you need to type wpa_passphrase ssid password > /etc/wpa_supplicant.conf. This is my example:
wpa_passphrase Cisco Thisisyourpassk\$y > /etc/wpa_supplicant.conf
As this is Linux, you need to remember to use break characters when using special characters. My ssid is named Cisco and my password is Thisisyourpassk$y. I’ve used the break character just before the $ sign. You will see if you have this correct by opening up the /etc/wpa_supplicant.conf file like so:
vi /etc/wpa_supplicant.conf
network={
ssid="Cisco"
#psk="Thisisyourpassk$y"
psk=357b62bf79a0d096901fe32d3138b6d962b95675976f08d044d117970b04d0fa
}
You should see that the break character worked as the psk over here shows the correct password in full.
Copy the psk value as you’ll need it in the next step.
Open your interface config file (in Ubuntu/Debian it’s over here):
vi /etc/network/interfaces
Add the following to this file:
#The wireless interface auto wlan0 iface wlan0 inet dhcp wpa-ssid "Cisco" wpa-ap-scan 1 wpa-key-mgmt WPA-PSK wpa-psk "357b62bf79a0d096901fe32d3138b6d962b95675976f08d044d117970b04d0fa"
Save and exit. Now restart your network:
/etc/init.d/networking restart
You should now be connected, and can monitor it via ifconfig and iwconfig:
root@XBMCLive:~# iwconfig
wlan0 IEEE 802.11bg ESSID:"Cisco"
Mode:Managed Frequency:2.472 GHz Access Point: 00:1D:A2:E7:56:30
Bit Rate=54 Mb/s Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:7B16-2A4A-9A61-158A-9537-84FE-3F90-E275 [3]
Power Management:off
Link Quality=36/70 Signal level=-74 dBm Noise level=-94 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
root@XBMCLive:~# ifconfig
wlan0 Link encap:Ethernet HWaddr 0c:60:76:68:60:25
inet addr:10.20.31.10 Bcast:10.20.31.255 Mask:255.255.255.0
inet6 addr: fe80::e60:76ff:fe68:6025/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:649 errors:0 dropped:0 overruns:0 frame:0
TX packets:677 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:94586 (94.5 KB) TX bytes:123349 (123.3 KB)
This only works if your kernel actually has the driver of course. If not, you may need to download the windows driver and use ndiswrapper. I’ve got an exmple of doing this in my post over here: http://mellowd.co.uk/ccie/?p=114
I would also suggest deleting your /etc/wpa_supplicant.conf file to prevent anyone in future getting your password.
Topology used is over here: http://mellowd.co.uk/ccie/?p=243
BGP Lab 12:
- AS7, AS9 and AS11 are all customers of ISP1
- AS7 has it’s own address space – 77.48.16.0/24 advertised via a loopback
- ISP1 owns the address space 180.16.0.0/16
- AS9 has been assigned 180.16.9.0/24 from ISP1 – insert via loopback
- AS11 has been assigned 180.16.11.0/24 from ISP1 – insert via loopback
- Ensure that AS7′s address space is advertised to AS9 and AS11
- ISP1 needs to advertise the entire 180.16.0.0/16 range and not the more specific routes. Ensure AS7 sees only 180.16.0.0/16 HOWEVER it must still know that some routes have come from AS9 and AS11
- On AS9, configure an attribute so that ISP1 does not advertise the more specific 180.16.9.0/24 address to anyone.
- You should notice that ISP1 is now not advertising the aggregate because it has inherited the no-export community from above
- Now on ISP1, ensure that the community is changed so that the aggregate can be advertised again
Click on the thumbnail for the full size topology:
Topology used is over here: http://mellowd.co.uk/ccie/?p=243
BGP Lab 11:
- All routers are peered via BGP
- Router9 has the network 24.83.176.1/24 attached via a loopback
- Router2 has the network 24.83.177.1/24 attached via a loopback
- All networks MUST be inserted into the BGP process
- Now ensure that Router8 and Router1 see the full aggregate of 24.83.176/23 advertised. More specific routes MUST be supressed. i.e. Router1 and Router8 should have the aggregate ONLY – Do this WITHOUT removing any of the networks from the BGP process
- Now change the configuration so that Router1 and Router8 get the aggregate as well as the more specific routes, however using a community tag (on Router2), ensure that Router1 does NOT advertise the more specific routes to Router6.
- Router6 should still get the aggregate route
- Check to make sure Router1 has all the routes and Router6 ONLY has the aggregate route
Click on the thumbnail for the full topology:
Topology used is over here: http://mellowd.co.uk/ccie/?p=243
BGP Lab 10:
- CompanyA is a customer of ISP1
- CompanyA is peered with CompanyB which is NOT a customer of ISP1
- ISP1 advertises the loopbacks of both Router8 and Router9, however wants to ensure that only it’s own customers know about 8.8.8.8
- ISP1 does not care that all routers know about 9.9.9.9
- ISP1 does not trust CustomerA to put the right measure in place, so you need to do it from the ISP1 side.
- In other words, make sure that CompanyA knows about 8.8.8.8 but force it not to advertise that route any further
Click on the thumbnail for the full topology:
Topology used is over here: http://mellowd.co.uk/ccie/?p=243
BGP Lab 9:
- ISP1 is running OSPF internally so that all loopbacks are accessible
- Router1 has the network 172.20.1.0/24 attached to it (via a loopback)
- Router8 has the network 172.20.8.0/24 attached to it (via a loopback)
- Ensure both these networks are advertised by both Router1 and Router8
- ISP1 contains the entire 172.20.0.0/16 network. Ensure this aggregate is always advertised out, no matter the condition of the more granular networks
- Using MED, ensure traffic from Router10 to 172.20.1.0/24 goes via Router2 and traffic to 172.20.8.0/24 goes via Router9
- Ensure the MED comes from the OSPF metric itself
Click on the thumbnail for the full topology:
Comments