Archive
Generate traffic with traceroute
I found a very useful tool when practicing the INE labs. How to generate
traffic with traceroute. I’ve used telnet lots of times to generate TCP
traffic on different ports but what if we want to generate UDP traffic instead?
We can used traceroute to our advantage.
The topology is the one I’ve been using for my last posts with two routers
connected by a FastEthernet link.
First we create an access-list on R1 that will deny UDP on ports 9 and 19
but allow everything else.
We will confirm connectivity by doing a ping and then a telnet.
The traffic is passing successfully. Lets check the access-list on R1.
We have matches in the ACL, now lets generate traffic with traceroute.
We will type traceroute and then enter the options.
The important thing here is of course to change the port to something else
than the default port 33434. You can see by the !A in the answer that the
traffic was prohibited. Lets confirm this with looking at the ACL on R1.
And that is how you generate traffic with traceroute. Combined with the telnet
tool we can pretty much simulate most of TCP or UDP traffic. This gives us an
advantage in the lab so that we may test our ACLs to see that they are working
as expected.
RMON – Remote MONitoring
RMON stands for Remote Monitoring. It is an extension to SNMP
that lets us enable event notifications when certain thresholds
are met. We can monitor the performance of interfaces or the CPU
and everything that has an OID in the SNMP MIB. We might want to
check for a high CPU utilization or the number of errors on an
interface.
When we monitor different parameters we can either look for
absolute values or delta values. Absolute values could be that
when the CPU hits 80% send an alarm. A delta value is the difference
between two measurements. If the number of errors on an interface
increases with more than 10 packets send an alarm.
There is not much configuration needed to setup RMON. We need to
configure alarms and events. When we configure the alarm we
set values to look for and a number of the event that we want to
trigger when the value is reached. The event will log the alarm
to syslog or send a SNMP trap when it is triggered.
We will use a very simple topology with two routers and a
FastEthernet link connecting them.
We want to monitor the change (delta) in octets in on the
FastEthernet interface. The value that correspends to octets
in is ifInOctets. We can see all the available parameters that
we can monitor with the show snmp mib command. This list is
huge and it may freeze your session for a while when you
scroll through it.
We need to find what ID our interface has so we can monitor it.
We can find this ID with the show snmp mib ifmib ifindex command.
We can see that the FastEthernet0/0 interface has an ID of 1.
We now have everything that we need to setup RMON. We start by
configuring an alarm. If the number of octets has increased with
less than 20000 an alarm wil be sent and if increasing with more
than 40000 then an alarm will also be sent.
You can see that we received a message directly because of the falling
threshold. The number 1 in rmon alarm 1 is an ID that identifies the
alarm. The number 30 is the sample interval. We check this value every
30 seconds. The number 1 after the rising- and falling-threshold is
what event to trigger.
We can check the parameters that we have configured with show rmon alarms
and show rmon events.
Now lets see if we can trigger the rising threshold. We need to generate
some traffic. We will do this with ping and a timeout of 0.
Has the event been triggered?
Yes it has. We can see the last value reported with the show rmon
alarms command. The rising threshold was triggered and later when
we stopped sending traffic the falling threshold was also met. The
log messages are send to console. If we want to send them to NVRAM
we need to use the logging buffered command.
Now you know how to configure RMON. RMON is very flexible and can
monitor a lot of different values.
Lock and key ACL
The lock and key ACL is one of those features you’re not sure how to use in
production but it is viable for the CCIE lab. The lock and key ACL is a form of dynamic
ACL which requires a key before unlocking access. The lock and key ACL can only
have one dynamic entry per ACL.
We will be looking at a very simple topology with 3 routers. R2 will act as a
firewall for traffic coming from R1 going to R3. We will create an ACL that
denies telnet to R3′s loopback but allows everything else. We will run OSPF for
reachability but configuring it is out of scope for this post.
This is the topology.
All 3 routers have been configured with transit links and a
loopback address of 1.1.1.1, 2.2.2.2 or 3.3.3.3. All the magic
will occur on R2.
First we verify that we have reachability from R1 to R3 through
ICMP and telnet.
Reachability is good. Now we will start configuring the dynamic ACL on R2.
Lets try if we can telnet from R1.
As expected we can telnet to the Fa0/0 interface but not the loopback.
Now we need to create an user on R2 that will unlock the dynamic
ACE on R2. We also need to use the autocommand feature.
Now we have created the user and enabled the autocommand feature.
The autocommand will execute a command when the user logs in. The
enable-access feature is used to activate they dynamic ACE in the ACL.
We also need to enable local login on the VTY lines on R2.
Now we will login to R2 from R1 and see if we can telnet to R3.
After authenticating we get kicked out and the ACE has now been activated. We can now
telnet to R3′s loopback.
Lets look at the ACL on R2.
You can see that there is a dynamic entry allowing us to telnet to the loopback of R3.
So summarizing lock and key is a cool feature that is not very usable in real life but a
good tool to have on your lab exam.
You can download the configs, both initial and final and the .net file from here.
Don’t forget to set image dir and working dir.
Transport preferred none
Have you ever mistyped a command and the router thinks you want to telnet
another device? Sure you have and so have I. The most common solution is
to turn off name lookups.
no ip domain-lookup
This will tell the router to not use DNS for looking up names and will
speed up the failing of the command. However if you need to have DNS
enabled we can’t use this solution and there is a cleaner way of doing
it.
line vty 0 4
transport preferred none
By default telnet is the preferred protocol and when mistyping the router
will try to telnet the “name” you typed. If we set it to none the router
won’t try to telnet when mistyping and you can have DNS enabled which is
the best of two worlds. If you want to telnet to another device you have
to type telnet 1.1.1.1 instead of just 1.1.1.1 but that is a small price
to pay.
Filtering traffic with a route-map
This post describes how to filter packets with a route-map. I have never used
a route-map for the sole purpose of filtering packets before. I ran into this
while doing a vol2 lab and the task was to filter ICMP packets coming in
on a frame-relay interface and out on VLAN 162. The packets should only
be filtered if they were between 100 and 200 bytes long. The topology is
the same as in my previous post.
My first thought was to use MQC to accomplish this but we were not allowed
to do so. We were not allowed to use FPM either. That only leaves us with
a route-map. Often policy routing is not allowed in the CCIE lab unless
specified but in this case it is our only option.
First we create an ACL that matches all ICMP. All configuration is applied to R6.
ip access-list extended ICMP
permit icmp any any
Then we create the route-map and do some matches.
route-map DROP
match ip access-group name ICMP
match interface FastEthernet 0/0
match length 100 200
set interface Null0
int s0/0/0.1
ip policy route-map DROP
The packets have to match all three criterias. The packet must match the ACL ICMP
which means it’s an ICMP packet. The packet is between 100 and 200 bytes long. The
packet is being output on interface FastEthernet 0/0 meaning the VLAN 162 subnet.
We apply the policy to the S0/0/0.1 interface which is the frame-relay interface.
Remember that traffic destined to the router is not affected by this policy, only
transit traffic will be affected. This means that packets won’t be dropped if we
try to ping R6.
Lets confirm that the policy is working. We turn on policy debugging on R6.
Rack24R6#debug ip policy
Policy routing debugging is on
RS.22.24.BB1>ping
Protocol [ip]:
Target IP address: 192.10.24.1
Repeat count [5]:
Datagram size [100]: 50
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 50-byte ICMP Echos to 192.10.24.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/26/32 ms
RS.22.24.BB1>ping
Protocol [ip]:
Target IP address: 192.10.24.1
Repeat count [5]:
Datagram size [100]: 150
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 150-byte ICMP Echos to 192.10.24.1, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)
RS.22.24.BB1>
The testing is done from BB1. You can see that when the packets are only 50 bytes long
there is no dropping ocurring. If we use a size of 150 bytes packets are being dropped.
The policy is working, lets look at debug output on R6.
Rack24R6#
May 14 14:23:41.110: IP: s=54.24.1.254 (Serial0/0/0.1), d=192.10.24.1, len 50, FIB policy rejected(no match) – normal forwarding
May 14 14:23:41.130: IP: s=54.24.1.254 (Serial0/0/0.1), d=192.10.24.1, len 50, FIB policy rejected(no match) – normal forwarding
May 14 14:23:41.162: IP: s=54.24.1.254 (Serial0/0/0.1), d=192.10.24.1, len 50, FIB policy rejected(no match) – normal forwarding
May 14 14:23:41.202: IP: s=54.24.1.254 (Serial0/0/0.1), d=192.10.24.1, len 50, FIB policy rejected(no match) – normal forwarding
May 14 14:23:41.222: IP: s=54.24.1.254 (Serial0/0/0.1), d=192.10.24.1, len 50, FIB policy rejected(no match) – normal forwarding
Rack24R6#
May 14 14:24:02.058: IP: s=54.24.1.254 (Serial0/0/0.1), d=192.10.24.1, len 150, FIB policy match
May 14 14:24:02.058: IP: s=54.24.1.254 (Serial0/0/0.1), d=192.10.24.1, len 150, PBR Counted
May 14 14:24:02.058: IP: s=54.24.1.254 (Serial0/0/0.1), d=192.10.24.1 (Null0), len 150, FIB policy routed(drop)
Rack24R6#
May 14 14:24:04.058: IP: s=54.24.1.254 (Serial0/0/0.1), d=192.10.24.1, len 150, FIB policy match
May 14 14:24:04.058: IP: s=54.24.1.254 (Serial0/0/0.1), d=192.10.24.1, len 150, PBR Counted
May 14 14:24:04.058: IP: s=54.24.1.254 (Serial0/0/0.1), d=192.10.24.1 (Null0), len 150, FIB policy routed(drop)
Rack24R6#
May 14 14:24:06.058: IP: s=54.24.1.254 (Serial0/0/0.1), d=192.10.24.1, len 150, FIB policy match
May 14 14:24:06.058: IP: s=54.24.1.254 (Serial0/0/0.1), d=192.10.24.1, len 150, PBR Counted
May 14 14:24:06.058: IP: s=54.24.1.254 (Serial0/0/0.1), d=192.10.24.1 (Null0), len 150, FIB policy routed(drop)
Rack24R6#
May 14 14:24:08.058: IP: s=54.24.1.254 (Serial0/0/0.1), d=192.10.24.1, len 150, FIB policy match
May 14 14:24:08.058: IP: s=54.24.1.254 (Serial0/0/0.1), d=192.10.24.1, len 150, PBR Counted
May 14 14:24:08.058: IP: s=54.24.1.254 (Serial0/0/0.1), d=192.10.24.1 (Null0), len 150, FIB policy routed(drop)
Rack24R6#
May 14 14:24:10.062: IP: s=54.24.1.254 (Serial0/0/0.1), d=192.10.24.1, len 150, FIB policy match
May 14 14:24:10.062: IP: s=54.24.1.254 (Serial0/0/0.1), d=192.10.24.1, len 150, PBR Counted
May 14 14:24:10.062: IP: s=54.24.1.254 (Serial0/0/0.1), d=192.10.24.1 (Null0), len 150, FIB policy routed(drop)
The first five packets don’t match the policy so they use normal forwarding. The next five
packets are being dropped. We can also see this with show route-map.
Rack24R6#sh route-map
route-map DROP, permit, sequence 10
Match clauses:
ip address (access-lists): ICMP
interface FastEthernet0/0
length 100 200
Set clauses:
interface Null0
Policy routing matches: 15 packets, 1810 bytes
And this is how flexible route-maps are, we can use them to modify metrics, redistribute and
even filter traffic.
Filtering traffic with VLAN access maps
While doing a vol2 lab I got stumped by one of the tasks in the lab.
The task was to filter ICMP packets coming from the backbone destined
to a network on the internal routers. The topology looks like this.
We need to filter ICMP packets from BB2 but we may not apply this on
R1 and/or R6. We are of course not allowed to do any changes in the
backbone either. So what is left? We have an Ethernet segment connecting
the routers together, they are all connected to a switch. This means
that we can apply a VLAN filter. VLAN filters are good for filtering
traffic that does not leave the VLAN. For traffic crossing network
boundaries we can use regular ACL’s but they won’t work for intra VLAN
traffic.
The configuration is pretty straight forward and has a lot of resemblance
to a route-map. First we create a VLAN access-map.
Rack24SW2(config)#vlan access-map ICMP_FILTER 10
Rack24SW2(config-access-map)#action drop
Rack24SW2(config-access-map)#match ip address 100
Rack24SW2(config-access-map)#exit
Rack24SW2(config)#vlan access-map ICMP_FILTER 20
Rack24SW2(config-access-map)#action forward
Rack24SW2(config-access-map)#exit
We want to drop traffic when there is a match in access-list 100. If there is
not a match permit the traffic.
Then we create the access-list.
Rack24SW2(config)#access-list 100 permit icmp 205.90.31.0 0.0.0.255 any echo
The 205.90.31.0/24 network is one of the backbone networks but the addressing is
not what’s important here.
Then we need to apply the filter to the VLANs that should be filtered.
Rack24SW2(config)#vlan filter ICMP_FILTER vlan-list 162
We have a few show commands that will show us what filters are in use.
Rack24SW2#show vlan filter
VLAN Map ICMP_FILTER is filtering VLANs:
162
Rack24SW2#show vlan filter vlan 162
Vlan 162 has filter ICMP_FILTER.
Rack24SW2#show vlan filter access-map ICMP_FILTER
VLAN Map ICMP_FILTER is filtering VLANs:
162
In this configuration we permitted the traffic that should be dropped in an ACL. Could we
have done the reverse? An alternate solution is to make an action of forward and then
deny the ICMP traffic. Lets look at this.
Rack24SW2(config)#vlan access-map ICMP_FILTER 10
Rack24SW2(config-access-map)#action forward
Rack24SW2(config-access-map)#match ip address 100
Rack24SW2(config-access-map)#exit
Rack24SW2(config)#vlan access-map ICMP_FILTER 20
Rack24SW2(config-access-map)#action drop
Rack24SW2(config-access-map)#exit
The logic is reversed here. We forward only certain traffic and drop the rest. We also
need to modify ACL 100.
Rack24SW2(config)#access-list 100 deny icmp 205.90.31.0 0.0.0.255 any echo
Rack24SW2(config)#access-list 100 permit ip any any
ICMP from 205.90.31.0 will be denied and all IP allowed, should work like a charm right?
And it might, for a while… There’s a pitfall in this configuration, we have allowed
all IP but there is one other quite important protocol used in Ethernet segments. We
use it when we know the IP address of a host but need to find out the MAC address. Yes,
it is ARP. With this ACL all ARP will be dropped. Some traffic might go through due to
that we have entries in the cache but as soon as they time out there will be a problem.
If we need to allow ARP we can do that by creating a MAC access-list.
Rack24SW2(config)#mac access-list extended PERMIT_ARP
Rack24SW2(config-ext-macl)#permit any any 0×806 0×0
So now you know how to filter traffic within a VLAN. There is almost always more than
one solution but we need to be careful when thinking through alternate solutions.
Drastically decreasing CPU load in Dynamips
Running Dynamips takes a lot of CPU and memory and running a full CCIE topology on
a Windows machine can be tough. I do a lot of studying on my commute to my job
and I run some smaller labs but I have not been able to run a full topology on
my laptop until now.
I came across a post on IEOC (Internetwork Experts forum) on how to
dramatically decrease CPU usage. Original credit goes to Journeyofanetworkengineer.
There is a value called idlemax which is related to the famous idle-PC value.
There is not much information on what this value does. According to Greg
at Hacki forum idlemax specifies how many times the address that the idle-PC
value references is used before going to sleep. The default value is 1500.
I’m not sure about the magic behind this, maybe someone with more expertise
in Dynamips can explain this but lowering this value dramatically decreases
the CPU usage.
I was able to run the full INE topology at 20-40% CPU load on my Core2 duo
@ 2.13 GHz and 4 GB RAM. Without idlemax applied my CPU runs at close to
100% load.
This is before idlemax.
This is after idlemax.
This is what a hypervisor entry looks like in the .net file.
[localhost:7200]
udp = 10000
workingdir = C:\GNS3\Working
[[3725]]
image = C:\GNS3\IOS\c3725-adventerprisek9-mz.124-15.T10.extracted.bin
ram = 128
ghostios = True
idlepc = 0x614ac21c
idlemax = 100
We will need four entries like this with an unique port for localhost and unique port for UDP.
You can download my complete .net file here if you need it for reference.
If you use this tip please post in comments how much your CPU was decreased and if you
have any stability issues when running it at 100.
IPv6 over frame relay
This post will look at IPv6 over frame-relay and describe some of the small things
that differ compared to IPv4 and some gotchas.
We start out with the same topology as in my previous frame-relay post.
We configure routers R1, R2 and R3 to be in the subnet 2001:CC1E:1:1::/64.
Remember that the pool of global IPv6 unicast addresses comes from 2000::/3
which means that all today legit IPv6 addresses will start with a 2 or a 3.
R1
interface Serial0/0
encapsulation frame-relay
ipv6 address 2001:CC1E:1:1::1/64
frame-relay map ipv6 2001:CC1E:1:1::2 102
frame-relay map ipv6 2001:CC1E:1:1::3 103
I won’t say much about this config as this should be known to you if you read
my previous post on frame relay. We are using a physical interface so all DLCI’s
will be available to us. The first thing to notice about IPv6 over frame relay is that
there is no inverse ARP. This means that we need static mappings or the
frame-relay interface-dlci command on point-to-point interfaces.
We configure R2 and to mix things up a bit we use a point-to-point interface.
interface Serial0/0
encapsulation frame-relay
frame-relay interface-dlci 201
Since this is a point-to-point interface there is no need for static mappings.
R3 will use a multipoint interface but not the physical interface. We will use a
static mapping.
interface Serial0/0
encapsulation frame-relay
interface Serial0/0.301 multipoint
ipv6 add 2001:CC1E:1:1::3/64
frame-relay map ipv6 2001:CC1E:1:1::1 301
When we use IPv6 we always have a link-local address assigned to all IPv6 enbabled
interfaces. This can be seen with the show ipv6 interface brief command.
R1#sh ipv6 int brief
FastEthernet0/0 [administratively down/down]
Serial0/0 [up/up]
FE80::C001:8FF:FEE0:0
2001:CC1E:1:1::1
The link-local address is calculated based on the MAC address.
R1#sh int | i bia
Hardware is Gt96k FE, address is c201.08e0.0000 (bia c201.08e0.0000)
Hardware is Gt96k FE, address is c201.08e0.0001 (bia c201.08e0.0001)
Our link-local address is based on the first MAC of this output. We want to use
an easier to remember address so we set the link local address to FE80::1 and
then the same on R2 and R3 but with ::2 and ::3.
R1(config)#int s0/0
R1(config-if)#ipv6 add FE80::1 link-local
Now it is time to do some routing. We start out with BGP. Knowing BGP is of
course a must when you are studying for the CCIE and the difference between
IPv4 and IPv6 is not that great. We need networks to announce so we create
some loopbacks on the routers.
R1
R1(config-if)#int lo0
R1(config-if)#ipv6 add 2001:CC1E:10:1::1/64
R2
R1(config-if)#int lo0
R1(config-if)#ipv6 add 2001:CC1E:11:1::2/64
R3
R1(config-if)#int lo0
R1(config-if)#ipv6 add 2001:CC1E:12:1::3/64
Don’t you just love being able to have IP addresses with CCIE in them? 
Time to setup BGP. We will be using AS 100 for R1 and R2. R3 will be in AS 300.
R1
R1(config)#ipv6 unicast-routing
R1(config)#router bgp 100
R1(config-router)#nei 2001:CC1E:1:1::2 remote-as 100
R1(config-router)#address-family ipv6 unicast
R1(config-router-af)#neighbor 2001:CC1E:1:1::2 activate
R1(config-router-af)#network 2001:CC1E:10:1::/64
R1(config-router-af)#exit
R1(config-router)#bgp router-id 1.1.1.1
Notice that we need to set a router-ID because we have no IPv6 addresses
configured on the routers.
R2
R2(config)#ipv6 unicast-routing
R2(config)#router bgp 100
R2(config-router)#bgp router-id 2.2.2.2
R2(config-router)#nei 2001:CC1E:1:1::1 remote-as 100
R2(config-router)#address-family ipv6 unicast
R2(config-router-af)#nei 2001:CC1E:1:1::1 activate
R2(config-router-af)#network 2001:CC1E:11:1::/64
The session comes up and we receive one prefix.
*Mar 1 10:12:46.853: %BGP-5-ADJCHANGE: neighbor 2001:CC1E:1:1::2 Up
R1#sh bgp ipv6 uni sum
BGP router identifier 1.1.1.1, local AS number 100
BGP table version is 3, main routing table version 3
2 network entries using 304 bytes of memory
2 path entries using 152 bytes of memory
3/2 BGP path/bestpath attribute entries using 372 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
Bitfield cache entries: current 1 (at peak 1) using 32 bytes of memory
BGP using 860 total bytes of memory
BGP activity 3/1 prefixes, 3/1 paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2001:CC1E:1:1::2
4 100 8 8 3 0 0 00:04:03 1
Lets see if we have reachability.
R1#sh ipv6 route 2001:CC1E:11:1::/64
IPv6 Routing Table – 6 entries
Codes: C – Connected, L – Local, S – Static, R – RIP, B – BGP
U – Per-user Static route, M – MIPv6
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
ON1 – OSPF NSSA ext 1, ON2 – OSPF NSSA ext 2
D – EIGRP, EX – EIGRP external
B 2001:CC1E:11:1::/64 [200/0]
via 2001:CC1E:1:1::2
R1#ping 2001:CC1E:11:1::2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:CC1E:11:1::2, timeout is 2 seconds:
!!!!!
Indeed we do, now lets setup peering between R1 and R3.
R1
R1(config-router)#nei 2001:CC1E:1:1::3 remote-as 300
R1(config-router)#address-family ipv6 unicast
R1(config-router-af)#nei 2001:CC1E:1:1::3 activate
R3
R3(config-router)#nei 2001:CC1E:1:1::1 remote-as 100
R3(config-router)#address-family ipv6 unicast
R3(config-router-af)#nei 2001:CC1E:1:1::1 activate
Now lets look at the BGP table on R1.
R1#sh bgp ipv6 uni
BGP table version is 12, local router ID is 1.1.1.1
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
*> 2001:CC1E:10:1::/64
:: 0 32768 i
*>i2001:CC1E:11:1::/64
2001:CC1E:1:1::2
0 100 0 i
*> 2001:CC1E:12:1::/64
2001:CC1E:1:1::3
0 0 300 i
We can see R3′s loopback, nothing weird, yet…We have a next-hop of
2001:CC1E:1:1::3 which is expected. Now look at the show ipv6 route bgp
output.
R1#sh ipv6 route bgp
IPv6 Routing Table – 7 entries
Codes: C – Connected, L – Local, S – Static, R – RIP, B – BGP
U – Per-user Static route, M – MIPv6
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
ON1 – OSPF NSSA ext 1, ON2 – OSPF NSSA ext 2
D – EIGRP, EX – EIGRP external
B 2001:CC1E:11:1::/64 [200/0]
via 2001:CC1E:1:1::2
B 2001:CC1E:12:1::/64 [20/0]
via FE80::3, Serial0/0
The route to 2001:CC1E:12:1::/64 has been resolved to a next-hop of FE80::3.
Do we have reachability to this network?
R1#ping 2001:CC1E:12:1::3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:CC1E:12:1::3, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)
No, we don’t. We don’t have a mapping for the link-local address. Debug frame-relay
packet should confirm this.
R1#debug frame-relay packet
Frame Relay packet debugging is on
R1#ping 2001:CC1E:12:1::3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:CC1E:12:1::3, timeout is 2 seconds:
*Mar 1 00:35:52.759: Serial0/0:Encaps failed–no map entry link 79(IPV6).
*Mar 1 00:35:54.767: Serial0/0:Encaps failed–no map entry link 79(IPV6).
*Mar 1 00:35:56.767: Serial0/0:Encaps failed–no map entry link 79(IPV6).
*Mar 1 00:35:58.771: Serial0/0:Encaps failed–no map entry link 79(IPV6).
*Mar 1 00:36:00.775: Serial0/0:Encaps failed–no map entry link 79(IPV6).
Success rate is 0 percent (0/5)
Indeed, there is no mapping. Lets configure this.
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#int s0/0
R1(config-if)#frame-relay map ipv6 FE80::3 103
R1(config-if)#^Z
R1#ping 2001:CC1E:12:1::3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:CC1E:12:1::3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/37/88 ms
R1#
Success, but the question still is why do we have a link-local next-hop for
R3′s loopback interface? RFC 2545 – Use of BGP-4 Multiprotocol extensions
for IPv6 Inter-Domain Routing gives us a hint.
A BGP speaker shall advertise to its peer in the Network Address of
Next Hop field the global IPv6 address of the next hop, potentially
followed by the link-local IPv6 address of the next hop.
We must announce the global next-hop and potentially a link-local one.
The link-local address shall be included in the Next Hop field if and
only if the BGP speaker shares a common subnet with the entity
identified by the global IPv6 address carried in the Network Address
of Next Hop field and the peer the route is being advertised to.
If the BGP peers share a common subnet the link-local address shall be included.
Why doesn’t the route to R2′s loopback have a link-local next-hop?
Once again, RFC 2545 gives us the answer.
As a consequence, a BGP speaker that advertises a route to an
internal peer may modify the Network Address of Next Hop field by
removing the link-local IPv6 address of the next hop.
If announcing to an internal peer, we may modify the next-hop by removing the
link-local address. R1 and R2 are in the same AS so they are internal peers.
Now we have seen how BGP works, what about IGPs? Lets try to configure
OSPF between R1 and R2.
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#int s0/0
R1(config-if)#ipv6 ospf 1 area 0
R1(config)#ipv6 router ospf 1
R1(config-rtr)#router-id 1.1.1.1
R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#int s0/0.201
R2(config-subif)#ipv6 ospf 1 area 0
R2(config-subif)#exit
R2(config)#ipv6 router ospf 1
R2(config-rtr)#router-id 2.2.2.2
The peering won’t be successful, why? We turn off the route-cache and debug IPv6 packets.
R1(config)#int s0/0
R1(config-if)#no ip route-cache
R1(config-if)#^Z
R1#debug ipv6 packet
IPv6 unicast packet debugging is on
R1#
*Mar 1 08:59:20.181: IPV6: source FE80::2 (Serial0/0)
*Mar 1 08:59:20.185: dest FF02::5
*Mar 1 08:59:20.185: traffic class 224, flow 0×0, len 76+4, prot 89, hops 1, forward to ulp
Let’s try a ping to FF02::5 which is the destination address of IPv6 OSPF packets.
R1#ping FF02::5
Output Interface: Serial0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FF02::5, timeout is 2 seconds:
Packet sent with a source address of FE80::1
Request 0 timed out
Request 1 timed out
Request 2 timed out
Request 3 timed out
Request 4 timed out
Success rate is 0 percent (0/5)
0 multicast replies and 0 errors.
No success, we can see that the packets are source from FE80::2 which must
be mapped. Also, we must have broadcast capability on one PVC, does it matter
which one? This is output from debug frame-relay packet when doing a ping to FF02::5
R1#debug frame-relay packet
Frame Relay packet debugging is on
R1#ping FF02::5
Output Interface:
*Mar 1 09:04:41.549: Serial0/0(i): dlci 102(0×1861), pkt type 0x86DD, datagramsize 80Serial0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FF02::5, timeout is 2 seconds:
Packet sent with a source address of FE80::1
*Mar 1 09:04:45.349: Serial0/0: broadcast search
*Mar 1 09:04:45.353: Serial0/0:encaps failed on broadcast for link 79(IPV6)
Request 0 timed out
This shows us clearly that we have no broadcast capability. Lets look at what
frame-relay mappings we have, R2 is point-to-point only so no need for mappings there.
R1#sh run | i frame-relay map
frame-relay map ipv6 FE80::3 103
frame-relay map ipv6 2001:CC1E:1:1::3 103
frame-relay map ipv6 2001:CC1E:1:1::2 102
We don’t have a mapping for R2′s link-local address. We will need that and we
will also need broadcast capability for the PVC. To prove that we can add the
brodcast capability by configuring a map for the global address I will configure that.
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#int s0/0
R1(config-if)#frame-relay map ipv6 FE80::2 102
R1(config-if)#frame-relay map ipv6 2001:CC1E:1:1::2 102 broad
Can we ping FF02::5 now?
R1#ping FF02::5
Output Interface: Serial0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FF02::5, timeout is 2 seconds:
Packet sent with a source address of FE80::1
Reply to request 0 received from FE80::2, 40 ms
Reply to request 1 received from FE80::2, 52 ms
Reply to request 2 received from FE80::2, 96 ms
Reply to request 3 received from FE80::2, 40 ms
Reply to request 4 received from FE80::2, 128 ms
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/71/128 ms
5 multicast replies and 0 errors.
Looking much better now. However, there is still no OSPF peering, why?
R1#sh ipv6 ospf interface
Serial0/0 is up, line protocol is up
Link Local Address FE80::1, Interface ID 6
Area 0, Process ID 1, Instance ID 0, Router ID 1.1.1.1
Network Type NON_BROADCAST, Cost: 64
R2#sh ipv6 ospf int
Serial0/0.201 is up, line protocol is up
Link Local Address FE80::2, Interface ID 14
Area 0, Process ID 1, Instance ID 0, Router ID 2.2.2.2
Network Type POINT_TO_POINT, Cost: 64
We have a mismatch in the network types. We will set both sides to broadcast.
R1(config)#int s0/0
R1(config-if)#ipv6 ospf network broadcast
R2(config)#int s0/0.201
R2(config-subif)#ipv6 ospf network broadcast
R2(config-subif)#
And finally we have a working peering.
*Mar 1 09:16:27.185: %OSPFv3-5-ADJCHG: Process 1, Nbr 1.1.1.1 on Serial0/0.201 from LOADING to FULL, Loading Done
I hope this post has cleared some misconceptions about IPv6 over frame relay.
If you have any questions please post them in the comments section.
You can find the final configs for this lab here. You can find the topology for GNS3
in my earlier post on frame-relay.
First troubleshooting session done
I did my first troubleshooting session tonight. I was worried about only having 2 hours alotted but time was the least of my concerns. I finished at 70 minutes so almost an hour to spare. I did quite OK, 60% if I grade myself strictly, not too shabby for my first attempt. Some tickets I solved but not in the same fashion as the solution guide, sometimes you look for more complex solutions than needed. Troubleshooting is definately fun and hopefully one of the skills that will be most useful in real life after becoming a CCIE.
