Archive

Archive for March, 2011

Integrated Routing and Bridging

March 30, 2011 7 comments

Sorry for the lack of updates lately but I spent the whole last week skiing and recharging my
batteries and now I’m back fully motivated to continue my path to the lab.

This time we will be talking about Integrated Routing and Bridging (IRB). Before studying for
the lab I had never used this feature. I’m not sure why we would use this feature in a
production network, maybe because we need to bridge two networks instead of routing
them due to some badly written application. If you have used it in real networks please post
in the comments. It is fair game for the lab so we need to know about it.

IRB is a feature used on routers that lets us bridge between a bridged domain and a
routed domain. Remember that in order for a VLAN to span a router the router must
be able to forward frames from one interface to another while maintaining the VLAN
header. If a network protocol is configured on a router interface (IP) it will terminate
the VLAN. This means that the VLAN header will not be maintained. When configuring
IRB we will be using a Bridged Virtual Interface (BVI), this can be compared to a SVI
on a switch. A BVI gives the bridged interfaces a connection to the routed world.

When IRB is configured and traffic comes in on a routed interface (IP address configured)
that is destined for a host in the bridge group the traffic will first be routed to the BVI.
The packet will then be forwarded to the bridging engine which forwards it through a
bridged interface, the forwarding is based on the destination MAC address. If a packet
comes in on a bridged interface destined for a host in a routed network the traffic will
first go to the BVI and then be sent to the routing engine before it sends it out the
routed interface. If bridging between two interfaces with no routed protocols the traffic
will not pass the BVI interface. Think of the bridge-group as an external switch and
the BVI lets us connect this external switch to the router.

The image below describes the scenario. R1 and R3 are in different VLANs but in
the same subnet, we need communication between the two routers. Between the
routers we have a couple of switches.

The configuration on R1 and R3 is straightforward. They have physical interfaces
with an IP address.

R1:

interface FastEthernet0/0
ip address 136.1.136.1 255.255.255.0

R3:

interface FastEthernet0/1
ip address 136.1.136.3 255.255.255.0

R1 is connected to SW1 and R3 to SW3. The switch configuration is just a basic access port.

SW1:

interface FastEthernet0/1
switchport access vlan 16

SW3:

interface FastEthernet0/3
switchport access vlan 36

Router R6 is connected to SW2 and it needs a trunk port.

SW2:

interface FastEthernet0/6
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 16,36
switchport mode trunk

Now we need to configure R6 to bridge between the two different VLANs. We start by activating IRB.

bridge irb

Then we need to tie the interfaces to the bridge-group.

interface FastEthernet0/0.16
bridge-group 1
!
interface FastEthernet0/0.36
bridge-group 1

Now we create a BVI interface in the subnet.

interface BVI1
ip address 136.1.136.6 255.255.255.0

Lastly we need to activate spanning-tree and activate routing for the bridged interfaces.

bridge 1 protocol ieee
bridge 1 route ip

So using IRB we can both bridge and route between interfaces on a
router, something that is not possible otherwise.

Finally, these are some useful commands to show what is going on when using IRB.

show interfaces irb
show bridge
show spanning-tree

Categories: Routing, Switching Tags: , ,

Lost in transit

March 19, 2011 Leave a comment

I have registered a domain for my blog. It is still hosted at WordPress but I wanted an easier address to remember. From now on you can also reach my blog via http://lostintransit.se or http://www.lostintransit.se

Categories: Announcement Tags:

Filtering RIP routes with an offset-list

March 18, 2011 1 comment

As you all know RIP is a distance vector routing protocol and that gives us a lot of options
when doing filtering. This time we will look at a feature that is not widely known, the
offset list. Assume that we have two routers, R1 and R2 and this is the task at hand.

  • R1 should filter all RIP routes coming from R2 with an even second octet
  • The access-list used may only contain one line
  • Do not use the distribute-list or distance command to accomplish this

So lets look at our tasks, how do we filter routes with an even second octet?
This might look a bit complicated but it’s easy when you’ve done it before. The routes we
are receiving from R2 are 30.0.0.0 to 30.3.0.0 and 31.0.0.0 to 31.3.0.0. Lets start
by focusing on the second octet. We will convert our even subnets to binary, we only care about the first and second octet.

30.0.0.0 – 00011110 00000000
30.2.0.0 – 00011110 00000010
31.0.0.0 – 00011111 00000000
31.2.0.0 – 00011111 00000010

See the pattern? If not look at the odd subnets below.

30.1.0.0 – 00011110 00000001
30.3.0.0 – 00011110 00000011
31.1.0.0 – 00011111 00000001
31.3.0.0 – 00011111 00000011

Do you see it now? Even subnets always end with a zero for the least significant bit.
Odd subnets always end with a one. This means that the final bit in the second octet is
interesting to us, the rest is don’t care. Now we need to convert this to a wildcard mask,
set all the bits we don’t care about to one and the one we do care about to zero.
Add them up, in binary it is 11111110 which equals to 254 in decimal.

Now we need to fill in the rest of the wildcard mask, remember that we were only allowed
to use one line in the access-list. How can we match both 30 and 31 in the first octet?
Look at the binary again, only the least significant bit in the first octet differs so we do
care about all the bits except for the least significant bit. Convert this to binary and we
have 00000001 which is 1 in decimal. So now we have the wildcard 1.254.255.255 since
we don’t care about the third and fourth octet.

As stated in the tasks we need to filter even routes, how can this be accomplished
in an access-list? Either we can deny odd routes, that would filter even routes
but since there is an implicit deny we would need a permit statement for the even
routes. That would break the one line requirement. So we need to permit the even
routes in the access-list and the implicit deny will solve the rest.

access-list 1 permit 30.0.0.0 1.254.255.255

Using a distribute-list would be the most common and easiest solution but
we are not allowed to do that. By using the distance command we could filter
routes by setting the administrative distance to something not believable like 255
but we are not allowed to do that either.

That only leaves us with the offset-list. The offset-list lets us manipulate routing
metrics, we are allowed to do this since it is distance vector and that is the reason
why distance vector is often called “routing by rumor”. In a link-state protocol we
would not be allowed to do this as we would need to send the original LSA.
So we can manipulate the metric, how can this help us? Remember that in RIP
we have the hop-count as metric and only metrics of up to 15 are valid, 16 and up
are regarded as invalid routes. So we then need to set our routes to have an offset of 16.

router rip
offset-list 1 in 16 Vlan783

So we have defined our offset-list, access-list 1 is used, the direction is
inbound, we want to filter routes we are receiving. We need to define the
offset, which is 16. We also need to define on what interface the RIP routes
are received. This is the layer three interface and may or may not be the
physical interface.

By now hopefully you have picked up a new way of filtering routes and can add it to your toolbelt.

Categories: CCIE, RIP, Routing Tags: , , , ,

Flash cards updated

March 17, 2011 3 comments

I have updated the flashcards with some questions on FHRP, Syslog, EEM, ZBF and NTP. There is over 200 questions in the bank now. As usual download the file from here.

Categories: Anki, CCIE Tags: , ,

OSPF lab notes

March 14, 2011 1 comment

This post is based on notes from my practicing OSPF vol1 labs. I want to have them saved
for later reference but I also think that this post can help others and clear some of the
confusions of OSPF.

Lets assume that we have some lab tasks that involve OSPF. The first thing we should do
is make a diagram with all the devices and the areas that the interfaces are connected
to. If this diagram is already provided for us and we find it usable, then don’t waste
time doing a new one! Otherwise if there isn’t one of if your not happy with it, make
a new one.

I like to make diagrams in Visio but when we diagram for the lab its about being
effective so don’t try to create some masterpiece. I just use circles for routers and
squares for switches and then I write the device name inside the circle or the square.
Then I write the interfaces on the devices and IP if needed and make circles for the
areas that include the interfaces.

So these are some of the things I have noted down when labbing.

  • The default mode of OSPF on frame-relay interfaces is non-broadcast

What does this mean? Non-broadcast means a few things. Non-broadcast means we cannot
send multicast or broadcast. Non-broadcast also means that a DR will be used.
Remember that if you see the prefix non in the OSPF type then we need to use neighbors.
If we have a hub and spoke topology we want to make sure that the hub always becomes
the DR since we won’t have l2 mappings to the other spokes in our frame-relay cloud.

How can we accomplish this? Remember that electing the DR is not preemptive, so we can
set the hub to have the highest priority and it is elected the DR and everything is fine
and dandy. When we have an outage at the hub and it comes back up but reachability is
not restored, why? While the hub was away another device could have been elected the DR
and just because the hub is back does not mean that it will assume its previous role.
So we need to make sure that the hub is elected the DR and that the other devices are
not eligible to be elected DR or BDR. The way of doing this is by entering ip ospf priority 0
under the frame-relay interface. Devices with a priority of 0 are not eligible for being
elected as DR/BDR.

  • Adjacencies and convergence can take a while in NBMA networks, dont panic!

What do I mean by this. While labbing I was noticing that forming adjacencies took quite
some time. I was typing show ip ospf nei and looking at the status and it would be EXSTART
or something else for quite some time before the adjacency was formed. So give it a few
minutes before you make the assumption that something is wrong with your config.
Remember that the timers on NBMA networks 30 seconds for hello and 120 for dead.

  • Neighbor command is only needed on DR

We won’t break anything by entering the neighbor command on the spokes but isn’t it better
to know how something works than just throw config at it? The spokes will only communicate
with the DR and the DR will be responsible for forming the adjacency. When we enter the
neighbor command under OSPF config mode on the hub it will start sending unicast packets
to the IP addresses that we have specified. Remember that multicast is the default in
most routing protocols. The hub sends unicast packets to the spokes which will notice that
unicast is being used and start replying with unicast themselves.

  • A router is not an ABR if no interfaces in area 0

This might sound a bit confusing. Lets say that we have a router with interfaces in area 1
and area 3. This must be an ABR right? Wrong! Unless it is connected to the backbone it
is not actually an ABR and it will not send type 3 summaries describing the other areas
networks. If you want some more background on this and a great article on OSPF I
recommend that you read Petr Laphukovs post at INE.

  • Using point-to-point mode

This mode is the default for interfaces that use point-to-point type of encapsulations
like HDLC or PPP. This mode can also be used to force a loopback to be advertised with its
configured mask instead of a /32 host route. This mode uses multicast and no DR is elected.
There is no need for a DR here since there can only be two devices communicating to each other.

  • Using point-to-multipoint mode

This mode is designed to work in partial mesh NBMA networks. When we use this mode
we will see that there is a /32 route for every spoke pointing to the hub. Also all routes
that are learned will have their next-hop changed to the IP of the hub. This means that
we do not need to have map statements for the other spokes. As this mode uses multicast
we need to have the keyword broadcast in our frame-relay statements.

  • Using point-to-multipoint non-broadcast

This works the same way as point-to-multipoint but the traffic is sent via unicast packets
instead of multicast. This means that we must have neighbor statements in our OSPF config.

  • Hints that we should use non-broadcast mode

If we have a broadcast segment like Ethernet and we are told that the OSPF
communication must be secured so noone can interfere with it then we should use
non-broadcast mode. Default on Ethernet segments multicast will be used but that
means that anyone can listen to the packets if they are connected to the segment.
If we enable non-broadcast the packets will be sent via unicast. Optionally we can
enable MD5 as well.

This post should give you an understanding of the different modes in OSPF,
remember that non-broacast always means neighbor statements.

Categories: CCIE, OSPF Tags: , ,

Saving time on lab tasks

March 11, 2011 1 comment

This post will show how you can save time on the lab tasks. Assume you need to complete this OSPF task.

  • Advertise the Loopback0 interfaces of R1, R2, R3 and R4 into OSPF area 0
  • Advertise the Loopback0 interface of R6 into OSPF area 1
  • Advertise the Loopback 0 interfaces of SW1 and SW3 into OSPF area 2
  • Advertise the Loopback 0 interfaces of R5, SW2 and SW4 into OSPF area 3

Our task is to advertise the loopbacks of all routers and switches in the topology into OSPF in
different areas. The topology is the regular INE topology but it doesn’t really matter here.
The major network is 155.21.0.0/16 where R1 has the loopback 155.21.1.1, R2 has
155.21.2.2 and up to SW4 that has 155.21.10.10.

We will be using the notepad technique, this can save you a lot of time when the lab comes.
What we do is write everything into notepad instead of typing in the CLI and we try to
reuse as much config as we can and only change a few parameters and then we copy
and paste to all the devices. This will save you from typing, save time and be more
accurate than typing to the CLI.

We have two options here, either we advertise the loopbacks the regular way by
entering router ospf 1 and then using the network statement or we can use the
new method of configuring OSPF under the interface instead.

Lets look at the first approach. Every loopback is in it’s own class C subnet. Assume
that we have entered OSPF config mode and we now need to put the network
statement, what should we use? We only want to advertise the loopback and not
other interfaces. So we start typing in notepad.

end
conf t
router ospf 1
network 155.21.1.1 0.0.0.0 area 0

This is as specific as we can get, this will only advertise the loopback. Now we need to copy
this and lets look at R2. The reason why I put an end at the start is to make sure that we
will end up in config mode and not some other submode. Router ospf command should work
from most modes like interface config but its better to make sure.

end
conf t
router ospf 1
network 155.21.2.2 0.0.0.0 area 0

So we need to change two digits for every device. Can we be more effective? If we change
the network statement to 155.21.1.0 0.0.0.255 we would only need to change one digit in
notepad for every device, that is actually better!

There is an even more effective way of doing this, which will mean that we won’t have to
change a single digit for the first four devices! Every minute saved will give us more time
to troubleshoot and verify config. This is how we do it, type into notepad.

end
conf t
int lo0
ip ospf 1 area 0

This config will be exactly the same for the first four devices and for the others
we only need to change the area, that is one digit at most! So now we have done
this in the most effecient manner possible. Now we want to test the reachability
of all the loopbacks. We could ping manually from the CLI and type ping 155.21.1.1
and so on but that would take a lot of time for 9 loopbacks in every device.
We could enter all IP’s in notepad with ping statements and then paste this into all
the routers which would be way more effective but the most effective way of doing
this is by using the TCL shell in IOS. If we don’t have support for TCL (switches)
we can also use a macro. This is how we do it in TCL.

tclsh
foreach ip{
155.21.1.1
155.21.2.2
155.21.3.3
155.21.4.4
155.21.5.5
155.21.6.6
155.21.7.7
155.21.8.8
155.21.9.9
155.21.10.10
}{ping $ip re 1}

We could leave out the loopback from the device that we are currently on
but then we would have to edit more in notepad. We should get a reply from
ourselves and if not we know why the ping failed. So this code in TCL will ping
every loopback repeated only one time and show us the output. We have now
configured the loopbacks and verified reachability in a matter of minutes.
I hope this post will help you in saving time and as I progress in my studies I will
post more of these tips.

Categories: CCIE, Lab preparation Tags: , ,

CCIE command memorizer review

March 9, 2011 Leave a comment

This is a review of the CCIE command memorizer. Firstly, I did not pay anything for the product, David let me try it out so I could write a blogpost about it and he has a chance to respond to my remarks. That doesn’t mean that I am afraid of critizing issues that I find with it, this review will be as objective as possible. The CCIE command memorizer is developed by David Bombal, CCIE # 11023. He runs the website ConfigureTerminal.com and a lot of different applications are available there like the CCIE command memorizer and config generators.

When purchasing the CCIE command memorizer you will get some additional products as a bonus. Lets start by going through these.

Cool IOS Commands

This is an e-book with useful commands in the IOS. As a quite experienced engineer I know almost all of these already but they can be very useful if you haven’t seen them before. Some things you will find in this e-book.

  • How to use the do command
  • Searching for text in show run with / and + and –
  • How to write aliases
  • Setting the terminal length to zero
  • Using regular expressions
  • Ping and traceroute syntax

Overall a good product since it is included anyway but if you are well versed in IOS you will recognize most of these.

MPLS command memorizer

The MPLS command memorizer is developed for the MPLS exam included in the CCIP
certification but can also be used to prepare for the CCIE. When using the MPLS
command memorizer you will see a network diagram in Visio style and then
the tasks required to finish the section. The configuration is done in a virtual PuTTY
terminal. A task could be setting up BGP peering sessions and activating the peer
under the right address-family. If you need a hint you can enter an Y on the
righthand side and the correct command to be used will be shown. The program is
divided into different areas like “MPLS basic infrastructure”, “VPN configuration”,
“PE/CE static routing” and so on. This is good because it gives you the chance
to practice in the areas that you are weak. It is a good product and it has its
use but don’t expect it to replace Dynamips, they fill different roles.

BSCI command memorizer

This exam is now named ROUTE but most of the content is the same. I’ve been a
CCNP for a couple of years and I’m doing the CCIE now so I don’t have that much
use for this program but it works in the same way as the other two. If you are
doing the CCNP this is a good product. It will show you a network diagram and
the tasks that you need to complete. It contains labs for all the different routing
protocols.

CCIE command memorizer

This is the reason I got interested in the product since I am studying for the
CCIE. Every day I have a 40 minute commute one way to work and I spend that
time studying. I wanted a way to keep labbing fresh and running the full
CCIE topology in Dynamips on my laptop is not an option.

The program is divided into different sections. Except for the labs there is a
“CCIE quick fire” and a “DocCD shortcuts section”. The CCIE quick fire is a
question bank with short answers. A question could be what timer is used
for a routing protocol or what the AD is for a protocol and the questions are
divided into different sections. Most of the questions are good but some feel
a little overkill and out of context, like answering fibre lengths for different
standards. Could be useful for the written but even that is questionable,
still it’s not a bad thing to know “too much”.

The DocCD section shows where to find the different technologies used for
the CCIE. Some of the links seem broken but you can also see how you can
find the links by navigation to switches -> LAN Switches and so on. A very
good idea but an update of this section would be nice.

Then we have the main section that is labs. Some of the lab sections also
have questions, an example would be “Assigned Multicast addresses” for IPv6
and the answer is FF00::/8. This is a quite nice feature I think because even
though we are practicing for the lab we still need to know the theory behind.

There is a lot of labs available, probably hundreds. When you type into the
virtual PuTTY terminal there is no option to use the questionmark to find
out available commands. If this is a good thing or not is up to you, this will
force you to learn the commands which might be a good thing.

If you want to see what the program looks like and the structure of it please
check out Davids website. Overall I feel it is a useful product if you have the
right expectations for it. This does not replace Dynamips in any way, this
is the first thing you need to understand but it can be a good sidekick.
Lastly here are some pros and cons with the product.

Pros

  • Fast to setup, no need to develop topologies
  • Doesn’t require a fast computer to run
  • No need for a Internet connection
  • A LOT of labs available
  • You get extra products when you buy the CCIE command memorizer
  • Helps with retention of commands
  • Good for short sessions when just setting up Dynamips would take more time than you have

Cons

  • Not full support for abbreviated commands
  • No context sensitive help, might not be a con, depends on personal opinion
  • Commands must be entered in exact order
  • Some tasks might be a bit repititive and maybe the IP-addressing should change to not memorize addresses
  • Would be nice with messages in console when peerings come up and maybe some basic show commands
  • Product updates? How often is the product updated? Some pages have a copyright from 2008

Overall it is a useful product and the prize is 150$ and then you also get the other
3 products. If you have the right expectations before buying it I don’t think you will
be disappointed. Regarding updates I was told that the product will be updated in
a couple of months.

Categories: CCIE Tags: ,

Private VLANs updated

March 8, 2011 Leave a comment

I found an error in my post about private VLANS in the picture of the traffic flow. PC’s that are located in the same community VLAN do have forwarding at layer 2 without going through a router. I have updated the picture to show the correct traffic flow. I always try to keep my posts as correct as possible but it is impossible to always be 100% correct. If you do find any errors please post a comment so that I am aware of it. If you are interested in private VLANs there is a RFC about it, RFC 5517. You can find it here.

Categories: Announcement Tags:

Private VLANs

March 7, 2011 2 comments

Private VLANs is a method to segment devices at layer 2 that are in the same IP network. Different VLANs are used but they share a common IP network.

The most common scenario for a private VLAN is a residential network where customers
connect to a switch provisioned by the ISP and the ISP wants to provision only one
subnet but the customers should not be able to reach each other at layer 2.
The reason to disallow layer two intercommunication is for security, to prevent someone
from interfearing or eavesdropping on another customers traffic. Another scenario could
be a hosting environment where servers are connected to a switch and a common VLAN
is used instead of provisioning one VLAN for every new customer.

Take a look at this picture.

PC’s in the grey VLAN can only communicate with each other and the router. The same goes for the PC’s in the green VLAN. PC’s in the blue VLAN can ONLY communicate with the router not with each other. The picture shows only one PC but if there was another PC it would not be able to communicate with the other PC in the same VLAN.

Lets look at some of the building blocks of private VLANs.

Types of VLAN:

Primary VLAN – The VLAN that is used for receiving traffic from the device connected to the promiscous port.

Community VLAN – Everybody that is located in a community VLAN may communicate with others in the same
community VLAN and with the primary VLAN but not with other VLANs.

Isolated VLAN – Can only reach the device on the promiscous port, can not reach any other devices.

Types of ports:

Promiscous port – A port that is connected to the primary VLAN where a promiscous device is connected. This device will route traffic between the different VLANs. Requires mapping between primary VLAN and all secondary VLANs.

Host port – Hosts are connected to host ports, requires a association between the secondary VLAN in use on the port and the primary VLAN.

This picture shows the traffic flow.

When communicating in the same community VLAN the traffic forwarding is direct (layer 2) but it traffic is sent between different secondary VLANs the traffic must pass through the router which allows us to do packet filtering at layer 3 and it also means that ARP can not be sent directly between hosts even though they are in the same IP subnet. The arrows from the PC in the blue VLAN to the PC in the black VLAN shows the traffic flow with numbering. First the PC in the blue VLAN sends a packet, this packet is always source with the VID from the secondary VLAN. The router receives the traffic and if no filtering is done it sends the packet out sourcing with the primary VLAN. The PC in the black VLAN receives the packet from the primary VLAN and sends it response with its secondary VLAN. Finally the router sends the packet back to the blue VLAN with the VID of the primary VLAN.

Lets have a look at what needs to be configured, lets start with the VLAN configuration. The scenario is that there are two switches connected by a trunk and routers are connected to the switchports (INE topology).

vlan 100
 name PRIMARY
  private-vlan primary
  private-vlan association 1000,2000,3000
!
vlan 1000
 name COMMUNITY_1
  private-vlan community
!
vlan 2000
 name COMMUNITY_2
  private-vlan community
!
vlan 3000
 name ISOLATED
  private-vlan isolated

We create the VLANs and configure them to be primary, community or isolated. The primary VLAN needs to know the secondary VLANs it should be be associated to. Next is the interface configuration.

interface FastEthernet0/1
 switchport private-vlan mapping 100 1000,2000,3000
 switchport mode private-vlan promiscuous
!
interface FastEthernet0/3
 switchport private-vlan host-association 100 1000
 switchport mode private-vlan host
!
interface FastEthernet0/5
 switchport private-vlan host-association 100 2000
 switchport mode private-vlan host

One port is configured as promiscous and the others as hosts. The host ports with secondary VLANs need to know what primary VLAN is used and the promiscous port needs to know what the secondary VLANs are.

Show vlan private-vlan will show what has been configured.

SW1#show vlan private-vlan
Primary Secondary Type              Ports
——- ——— —————– ——————————————
100     1000      community         Fa0/1, Fa0/3
100     2000      community         Fa0/1, Fa0/5
100     3000      isolated          Fa0/1

We also need configuration for SW2.

vlan 100
 name PRIMARY
  private-vlan primary
  private-vlan association 1000,2000,3000
!
vlan 1000
 name COMMUNITY_1
  private-vlan community
!
vlan 2000
 name COMMUNITY_2
  private-vlan community
!
vlan 3000
 name ISOLATED
  private-vlan isolated
!
interface FastEthernet0/2
 switchport private-vlan host-association 100 1000
 switchport mode private-vlan host
!
interface FastEthernet0/4
 switchport private-vlan host-association 100 2000
 switchport mode private-vlan host
!
interface FastEthernet0/6
 switchport private-vlan host-association 100 3000
 switchport mode private-vlan host

Show interface switchport will show how the port is configured.

SW1#show interfaces f0/1 switchport
Name: Fa0/1
Switchport: Enabled
Administrative Mode: private-vlan promiscuous
Operational Mode: private-vlan promiscuous
Administrative Trunking Encapsulation: negotiate
Operational Trunking Encapsulation: native
Negotiation of Trunking: Off
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 1 (default)
Administrative Native VLAN tagging: enabled
Voice VLAN: none
Administrative private-vlan host-association: none
Administrative private-vlan mapping: 100 (PRIMARY) 1000 (COMMUNITY_1) 2000 (COMMUNITY_2) 3000 (ISOLATED)
Administrative private-vlan trunk native VLAN: none
Administrative private-vlan trunk Native VLAN tagging: enabled
Administrative private-vlan trunk encapsulation: dot1q
Administrative private-vlan trunk normal VLANs: none
Administrative private-vlan trunk associations: none
Administrative private-vlan trunk mappings: none
Operational private-vlan:
  100 (PRIMARY) 1000 (COMMUNITY_1) 2000 (COMMUNITY_2) 3000 (ISOLATED)
Trunking VLANs Enabled: ALL
Pruning VLANs Enabled: 2-1001
Capture Mode Disabled
Capture VLANs Allowed: ALL
Protected: false
Unknown unicast blocked: disabled
Unknown multicast blocked: disabled
Appliance trust: none

Lets try the configuration, we will start at R1 which is on the promiscous port and see if it can ping R2-R6.

R1#ping 255.255.255.255 re 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 255.255.255.255, timeout is 2 seconds:
Reply to request 0 from 100.0.0.5, 4 ms
Reply to request 0 from 100.0.0.2, 4 ms
Reply to request 0 from 100.0.0.3, 4 ms
Reply to request 0 from 100.0.0.4, 4 ms
Reply to request 0 from 100.0.0.6, 4 ms

As expected we can ping all the devices. R2 should only be able to ping R3 and R1.

R2#ping 255.255.255.255 re 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 255.255.255.255, timeout is 2 seconds:
Reply to request 0 from 100.0.0.3, 4 ms
Reply to request 0 from 100.0.0.1, 4 ms

 

Working as expected. R6 should only be able to ping R1 since it is in an isolated VLAN.

R6#ping 255.255.255.255 re 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 255.255.255.255, timeout is 2 seconds:
Reply to request 0 from 100.0.0.1, 4 ms

The configuration is working. What if we want to create a SVI in one of the switches? This is the configuration.

SW1(config)#int vlan 100
SW1(config-if)#ip add 100.0.0.7 255.255.255.0
SW1(config-if)#no sh

Lets try to ping.

SW1#ping 100.0.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.0.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/8 ms
SW1#ping 100.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.0.0.2, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)

Why can’t we ping R2? We have no mapping to the secondary VLAN!

SW1(config)#int vlan 100
SW1(config-if)#private-vlan mapping 1000
SW1(config-if)#^Z
SW1#
*Mar  1 01:08:47.983: %PV-6-PV_MSG: Created a private vlan mapping, Primary 100, Secondary 1000
SW1#
*Mar  1 01:08:49.267: %SYS-5-CONFIG_I: Configured from console by console
SW1#ping 100.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.0.0.2, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)
SW1#sh run int vlan 100
Building configuration…
Current configuration : 88 bytes
!
interface Vlan100
 ip address 100.0.0.7 255.255.255.0
 private-vlan mapping 1000
end

Still no success, why?

SW1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
SW1(config)#ip routing
SW1(config)#^Z
SW1#
*Mar  1 01:14:26.858: %SYS-5-CONFIG_I: Configured from console by console
SW1#ping 100.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/8 ms

IP routing was needed! If you need to find documentation @ Cisco here is how you find it:

Support -> Configure -> Products -> Switches -> LAN Switches -> Access -> Cisco Catalyst 3560 Series Switches -> Configuration Guides -> Catalyst 3560 Software Configuration Guide, Release 12.2(52)SE -> Configuring Private VLANs

Categories: CCIE, Switching Tags: , ,

Filtering packets by TTL in Cisco ACL

March 3, 2011 1 comment

As I make progress through the INE workbooks I’m writing posts about features that I find interesting and that might not be that known to the general public. I wasn’t aware that you could filter packets based on TTL in IOS. I’m not sure where this would be used in the real world but one use could be to filter BGP packets coming in from external peers and checking the TTL of the packets. BGP does this by itself, but one scenario could be someone trying to flood BGP packets towards a router and then it might be better to filter them in an ACL then to let the CPU handle the packets. One important note when doing TTL filtering, look at this picture.

On ingress the ACL is checked before the TTL is decremented. On egress the ACL is checked after the TTL has been decremented.

Lets take a look at the configuration.

Rack20R4(config)#ip access-list extended TTL
Rack20R4(config-ext-nacl)#deny ip any any ttl ?
  eq     Match only packets on a given TTL number
  gt     Match only packets with a greater TTL number
  lt     Match only packets with a lower TTL number
  neq    Match only packets not on a given TTL number
  range  Match only packets in the range of TTLs

So we have a few options here, we can match on an exact TTL or a range or a TTL less than or greater than a value. We have a lot of options. In this example we will filter packets with TTL less than 3.

Rack20R4(config-ext-nacl)#deny ip any any ttl lt 3
Rack20R4(config-ext-nacl)#permit ip any any

Packets with TTL less than 3 are denied and the rest are allowed. We need to apply the ACL to an interface, we are filtering packets outbound in this example.

Rack20R4(config-if-range)#int s0/0/0
Rack20R4(config-if)#ip access-group TTL out

This is how the ACL looks so far.

Rack20R4#show access-lists TTL
Extended IP access list TTL
    10 deny ip any any ttl lt 3
    20 permit ip any any

Let’s try a traceroute. The traceroute command can set a min and max TTL. If we set it to min 4 the packet will pass and we will see hop 4 and onward in the trace. If we set it to 1 the packet will be filtered.

Rack20R6#traceroute 183.20.123.2 ttl 1 10
Type escape sequence to abort.
Tracing the route to 183.20.123.2
  1 183.20.46.4 4 msec 0 msec 0 msec
  2 183.20.46.4 !A  *  !A
Rack20R6#traceroute 183.20.123.2 ttl 4 10
Type escape sequence to abort.
Tracing the route to 183.20.123.2
  4 183.20.107.7 32 msec 40 msec 32 msec
  5 183.20.17.1 28 msec 28 msec 28 msec
  6 183.20.123.2 72 msec *  72 msec

 

This is the log output.

Mar  3 02:11:45.003: %SEC-6-IPACCESSLOGP: list TTL denied udp 183.20.46.6(0) -> 183.20.123.2(0), 1 packet

And finally, we have matches in the ACL.

Rack20R4# show access-lists TTL
Extended IP access list TTL
    10 deny ip any any ttl lt 3 log (3 matches)
    20 permit ip any any (168 matches)

So this post has showed how we can filter packets based on TTL in IOS. Post feedback in comments if you like these posts.