Chronicles of CCIE journey

.
.

Unicast Reverse Path Forwarding is a small security feature
When configured on an interface, the router checks the incoming packet’s source address with its routing table. If the incoming packet’s source is reachable via the same interface it was received on, the packet is allowed. URPF provides protection again spoofed packets with unverifiable source.
Though basically a single line command, URPF can be a little confusing when used with access-list feature if order of operation is not understood completely.
We’ll use this simple topology to demonstrate URFP.





R1 and R2 are connected through frame-relay and a Ethernet connection.
We test our basic connectivity.

R2#ping 150.1.12.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.12.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 44/93/192 ms

R1#ping 150.1.12.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.12.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/45/84 ms

R1#ping 150.1.21.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.21.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/54/100 ms

All right we have reachability on both Ethernet and frame relay interfaces.
In order to demonstrate URPF we use two static routes on R1 and R2.
R1 uses frame-relay to reach R2’s loop back (2.2.2.2/24) and R2 user Ethernet to reach R1’s Loopback (1.1.1.1/24)

R1(config)#ip route 2.2.2.0 255.255.255.0 150.1.12.2
R2(config)#ip route 1.1.1.0 255.255.255.0 150.1.21.1

Without URPF, we should be able to ping R2’s loopback from R1’s loopback.

R1#ping 2.2.2.2 source lo 0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/48/80 ms


Now we enable URPF on frame-relay interface on R2.
Now when the incoming packet arrives at the frame interface, R2 checks the source address (1.1.1.1/24) in its routing table.
Since the interface used to reach this address is Ethernet0/0 , URPF checks fail and ping is not successful.

!
interface S1/0
ip address 150.1.12.2 255.255.255.0
ip verify unicast reverse-path

R1#ping 2.2.2.2 source lo 0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
.....
Success rate is 0 percent (0/5)


All right!
This was the most simple part.
Now we use URPF with an access-list.

Understanding URPF Order of Operation:

Here we have to understand the order of operations.

1) When packet arrives at the interface, URPF check is done. If the check is successful, the packet is transmitted, and ACL doesn’t come into play
2) If the check is failed, ACL is consulted. Traffic is allowed or denied based on ACL entries.
3) The thing to understand here is that an ACL with deny any any will not mean that all traffic is denied. It won’t come into play unless the URPF check is failed. If URPF check is successful all traffic is allowed. If it is failed then ACL is checked an traffic is allowed or denied based on the ACL.

R2:
!
interface Serial1/0
ip address 150.1.12.2 255.255.255.
ip verify unicast reverse-path 101

access-list 101 permit tcp any any
access-list 101 deny ip any any log-input

Here we are allowing the TCP traffic and denying all other traffic in ACL.
It means that a telnet sourced from the LoopBack 0 of R1 to LoopBack 0 of R2 will be successful, but all other traffic will be denied.

From R1:
R1#telnet 2.2.2.2 /source-interface loopback 0
Trying 2.2.2.2 ... Open


Password required, but none set

[Connection to 2.2.2.2 closed by foreign host]

Success rate is 0 percent (0/5)
R1#ping 2.2.2.2 source lo 0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
.....
Success rate is 0 percent (0/5)


Below is the log generated by ACL.

*Mar 1 00:16:40.171: %SEC-6-IPACCESSLOGDP: list 101 denied icmp 1.1.1.1 (Serial1/0 ) -> 2.2.2.2 (0/0),

Now lets ping the loopback with source frame-relay interface.

R1#ping 2.2.2.2 source S1/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 150.1.12.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/48/80 ms

As you can see that though ACL is denying all ICMP traffic our ping is successful.
For the simple reason that ACL won’t be checked until URPF check is failed. And in the above case, it’s successful.


Now lets change the ACL.
Now our intention is to allow HTTP traffic between the loopbacks as well as ICMP traffic and deny all other traffic.

R2:
access-list 101 permit tcp any any eq www
access-list 101 permit icmp any any
access-list 101 deny ip any any log-input

We’ll be able to ping or telnet at port 80 but regular telnet will fail

R1#ping 2.2.2.2 source lo 0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/57/80 ms
R1#telnet 2.2.2.2 80 /source-interface loopback 0
Trying 2.2.2.2, 80 ... Open


R1#telnet 2.2.2.2 /source-interface loopback 0
Trying 2.2.2.2 ...
% Connection timed out; remote host not responding

R2: (:Log)
*Mar 1 00:20:18.895: %SEC-6-IPACCESSLOGP: list 101 denied tcp 1.1.1.1(35617) (S
erial1/0 ) -> 2.2.2.2(23), 1 packet


Well thats about it for URPF.
In lab exam if the feature shows up, be careful, as it can break connectivity if routers have asymmetrical routing.
Asymmetrical routing is not a problem in LAB generally as long as we have connectivity, but with URPF enabled, asymmetrical routing will break connectivity.
In that case,we can either tune unicast routing table or use the access-list with URPF to allow for connectivity.

.
.
.
Bridging is an obscure topic in CCIE R&S study.
It can be divided in three types

1) IRB (Integrated Routing and Bridging)
2) CRB (Concurrent Routing and Bridging
3) Fall back bridging

IRB is discussed in Lab 3 of internetworkExpert labs.

Basically IRB and CRB are generally used on routers to bridging different VLAN domains. If IRB is used, we can route IP over these bridged interfaces. The topic that is least discussed is Fall Back Bridging that we configure on switches. It is basically for non-IP traffic, and thats why chances of it appearing on the LAB are slim.
But since nowadays obscure topics are my thing as I am pretty much done with the core, in fact back in April Narbik and all my fellow bootcampers urged me to take the lab immediately saying that I was more than ready and worried about things which I should not.
But my Lab date is September 18th and by that time, I want to be prepared in every thing. One of such things is Fall Back bridging, so that if by chance it shows up, i am ready to tackle it.
Other topics about which Iĺl try to write tutorials are in my post below this one.

I’ll be demonstrating how fall-back bridging works using this example. SW1 has VLAN 11 and VLAN 22 defined and R1 and R2 are in VLAN 11 and 22 respectively. R3 and R4 are connected to switch ports Fa0/3 and fa0/4 and I’ll be demonstrating how fall back bridging works using this example.


Topology Diagram:






SW1 is 3550.
3560 behaves identically

SW1 has VLAN 11 and VLAN 22 defined and R1 and R2 are in vlan 11 and 22 respectively.
R3 and R4 are connected to switch ports Fa0/3 and fa0/4 and VLANS are not defined.
For simplicity the mac-address are as follows.
R1 F0/0 = 0000.0000.001
R2 F0/0 = 0000.0000.002
R3 F0/0 = 0000.0000.003
R4 F0/0 = 0000.0000.004


Our goal here is to make all four router bridge the non-ip traffic between them where as R1 and R2 are in VLAN 11 and 12 respectively and R3 and R4 are not in any vlan.

The configuration of switchports connecting to R1 and R2 are as follows
!
interface FastEthernet0/1
description To R1 F0/0
switchport access vlan 11
!
interface FastEthernet0/2
description To R3 F0/0
switchport access vlan 22

To enable bridging on the physical port first we have to issue no-switchport command on physical interface.
Interface fa0/3 and fa0/4 here.
Here is the configuration of these ports.


!
interface FastEthernet0/3
description To R3 F0/0
no switchport
no ip address
!
interface FastEthernet0/4
no switchport
no ip address
end


Now we configure our fall back bridging.
For R1 and R2 the bridging will be configured under SVIs and for R3 and R4 under physical interface

SW1(config)#bridge 1 protocol vlan-bridge
SW1(config)#int vlan 11
SW1(config-if)#bridge-group 1
SW1(config-if)#int vlan 22
SW1(config-if)#bridge-group 1
SW1(config-if)#int fa0/3
SW1(config-if)#bridge-group 1
SW1(config-if)#int fa0/4
SW1(config-if)#bridge-group 1


And we are done with simple fall back bridging.
For verification, we will simulate an IPX network.

SW1#sh bridge group
Bridge Group 1 is running the VLAN Bridge compatible Spanning Tree protocol
Port 25 (FastEthernet0/3) of bridge group 1 is forwarding
Port 26 (FastEthernet0/4) of bridge group 1 is forwarding
Port 22 (Vlan11) of bridge group 1 is forwarding
Port 23 (Vlan22) of bridge group 1 is forwarding


On R1:
R1(config)#ipx routing
R1(config)#int Fa0/0
R1(config-if)#ipx net
R1(config-if)#ipx netwo
R1(config-if)#ipx network ABC
R1(config-if)#ipx encapsulation sap
R1(config-if)#do sh ipx int f0/0
FastEthernet0/0 is up, line protocol is up
IPX address is ABC.0000.0000.0001, SAP




Similarly on R2, R3 and R4
Our IPX address are as follows
R1: ABC.0000.0000.0001
R2: ABC.0000.0000.0002
R3: ABC.0000.0000.0003
R4: ABC.0000.0000.0004

We will ping from R1 to all other routers and also monitor the bridge group table.


R1#ping
Protocol [ip]: ipx
Target IPX address: ABC.0000.0000.0002
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Verbose [n]:
Type escape sequence to abort.
Sending 5, 100-byte IPX Novell Echoes to ABC.0000.0000.0002, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/66/192 ms
R1#ping
Protocol [ip]: ipx
Target IPX address: ABC.0000.0000.0003
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Verbose [n]:
Type escape sequence to abort.
Sending 5, 100-byte IPX Novell Echoes to ABC.0000.0000.0003, timeout is 2 seconds:
!!!!!
R1#ping
Protocol [ip]: ipx
Target IPX address: ABC.0000.0000.0004
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Verbose [n]:
Type escape sequence to abort.
Sending 5, 100-byte IPX Novell Echoes to ABC.0000.0000.0004, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/48/72 ms
Finally the bridging table on switch


SW1#sh bridge
Total of 300 station blocks, 296 free
Codes: P - permanent, S - self

Bridge Group 1:

Address Action Interface Age RX count TX count
0000.0000.0001 forward Vlan11 0 20 15
0000.0000.0002 forward Vlan22 0 10 5
0000.0000.0003 forward FastEthernet0/3 0 6 5
0000.0000.0004 forward FastEthernet0/4 0 5 4



Now we’ll play with some features.

By default the mac-address are learned dynamically.
We can discard a mac-address, and force a router out of bridge group.
Lets discard R4’s mac address.


This will be done with the following command

SW1(config)#bridge 1 address 0000.0000.0004 discard
SW1#sh bridge
Total of 300 station blocks, 296 free
Codes: P - permanent, S - self

Bridge Group 1:
Address Action Interface Age RX count TX count
0000.0000.0001 forward Vlan11 2 20 15
0000.0000.0002 forward Vlan22 3 10 5
0000.0000.0003 forward FastEthernet0/3 3 6 5
0000.0000.0004 discard - P 5 4



Now R1 should not be able to communicate with R4 but still be communicating with R2 and R3.
Lets test this.

R1#ping
Protocol [ip]: ipx
Target IPX address: ABC.0000.0000.0004
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Verbose [n]:
Type escape sequence to abort.
Sending 5, 100-byte IPX Novell Echoes to ABC.0000.0000.0004, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R1#ping
Protocol [ip]: ipx
Target IPX address: ABC.0000.0000.0003
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Verbose [n]:
Type escape sequence to abort.
Sending 5, 100-byte IPX Novell Echoes to ABC.0000.0000.0003, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/58/168 ms


All right!
Now we can also change the behavior of dynamic learning by using “no bridge 1 acquire” command.
In that case, we have to manually add the mac-address we want to communicate with.
Lets do this and we’ll not manually add R2ś mac-address.

Weĺl see that R1 can ping R1 and R3 and R4 but not R2.

SW1(config)#no bridge 1 address 0000.0000.0004 discard
SW1(config)#no bridge 1 acquire
SW1(config)#do clear arp
SW1(config)#do sh bridge
Total of 300 station blocks, 300 free
Codes: P - permanent, S - self

All right all addresses have gone now.


Now we add

SW1(config)#bridge 1 address 0000.0000.0001 forward vlan 11
SW1(config)#bridge 1 address 0000.0000.0003 forward fastEthernet
SW1(config)#bridge 1 address 0000.0000.0004 forward

We can specify interface if we want, to avoid unnecessary broadcast. But this is not essential for communication.
Let’s see the bridge table now.


SW1#sh bridge
Total of 300 station blocks, 296 free
Codes: P - permanent, S - self
Bridge Group 1:
Address Action Interface Age RX count TX count
0000.0000.0001 forward Vlan11 P 0 0
0000.0000.0002 discard Vlan22 0 0 0
0000.0000.0003 forward FastEthernet1/3 P 0 0
0000.0000.0004 forward - P 0 0



As you can see that R2 mac address is being discarded.
As after no bridge 1 acquire, we need to manually add the mac-adresses.
Now we ping from R1 to R2 and R3 and R4.

R1#ping
Protocol [ip]: ipx
Target IPX address: ABC.0000.0000.0002
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Verbose [n]:
Type escape sequence to abort.
Sending 5, 100-byte IPX Novell Echoes to ABC.0000.0000.0002, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R1#ping
Protocol [ip]: ipx
Target IPX address: ABC.0000.0000.0003
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Verbose [n]:
Type escape sequence to abort.
Sending 5, 100-byte IPX Novell Echoes to ABC.0000.0000.0003, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/29/36 ms



Side Options:




Like spanning-tree we can modify forward time, hello time, and priority (for selecting root) by following commands


bridge 1 forward-time
bridge 1 hello-time
bridge 1 priority


Also under the interface we can modify cost and priority to choose the path to root-bridge


SW1(config-if)#bridge-group 1 priority
SW1(config-if)#bridge-group 1 path-cost


Also aging time in bridge group table can be modified using
SW1(config)#bridge 1 aging-time ?
<10-1000000> Seconds




That’s pretty much it for fall back bridging.
For IRB (Integrated Routing and Bridging) and CRB (Concurrent Routing and Bridging) IE LAB 3 has a good write-up, which should be enough for understanding

Note:

Any readers, this is my first attempt at writing a tutorial.
Please let me know if it was helpful.

Had been away from posting for a while.
Here is a summary of last 3 months.
Went to NArbik's bootcamp and was a great experience.
Lab scheduled at September 18th.
And pretty much done with core topics.
Now i'll be doing some side topics for a month, and posting some tutorials here...
Here are the Topics I am looking for to complete within this month

L2:
L2 tunnelling *
Bridging ( IRB, CRB, Fall back bridging)*
Cat QOS ( SRR and WRR Queuing, Aggregate Policer, 3560 Buffer allocations, Caveats)
Catalyst Flow Control *

Frame-relay DEs.

L3:
Protocol Timers.

Multicast :
Some little features

IP Services/ Security:
WCCP *
DRP Servers
URFP *
CBAC *
Reflexive ACLs *



* About these topics, I'll try to write short tutorials as well.

Here is a scenario I cooked up for redistribution. I’ve tried to make it as complex as possible but addressing is kept simple.









Hmmm similar scenario but EIGRP and OSPF here.
Unlike last time we wont have a problem unless EIGRP has an external route.
In that case, we have to filter that in OSPF so that at R7, we prefer or native routes of EIGRP.
Remember HIGHER to LOWER we need to take care, if domains have more than one meeting points.

At the end of this step, we’ll have reachability between R10->R5->R1 and vice versa.

Now we go to double point of redistribution.

At R6 and R7:

I'll be attending Narbik's bootcamp in April in Dubai.

Though I'd have much preferred to attend a bootcamp in July or August after finishing all IEWB labs and say a month before my Lab, but there is an uncertainty about later lab dates in Dubai .

My new Tentative Schedule about labbing is
Plus now my plan is to complete 12 IEWB labs before the bootcamp.
Come back spend a month (May) on Narbik's work book.
June will be for the remaining 8 IEWB labs.
July will be for repeition IEWB labs with difficulty 7 and higher.
Plus since I save the config just before redistribution, I may do other labs IGP onwards.
August will be dedciated to 2 mock labs (IEWB and CCIE accessor) and Narbik's work book revision.
I May attend Narbik's bootcamp around September again, just before going to the lab.

I am getting better at redistribution or at least thinking so.

I complete LAB 7 ( yes I am not doing labs in order) and Lab 6 uptil BGP.And though redistibution gave me a headache a i spent like 2 hours on each task, I did them right. What more, I did those in my own way, which is quite different from the Solution Guide.

After sweating a lot , I think I am slowly adopting a strategic approcah towards redistribution.

The way I see it is that we have to have a method before starting redistribution.I used to ignore suboptimal paths and try to tag everything, but now I have realized that going through a step by step process, eliminating loops and suboptimal paths at each step is the way to go.

Here is the methodology that has been working for me



1) Identify one of the routing domains as core routing domain. It doesn't matter which protocol it is. For me its the largest domain, which normally sits in the centre of topology.



2) Identify if there has to be redistrbution between non core or edge domains.If so, do that first. Again making sure that if two domains have more than one rendezvous point, they keep preferring their native routes. ( Doesn't matter if redistrbution is done on a single point or two. Avoid routes to get back in



3) Ensure connectivity on the edge domains.Also ensure that native paths are preferred.



4) Now redistribute between core and edge domains.Single point of redistribution first, and verify connectivity.Again, make sure that native routes are preferred. (AD or tagging)



5) If there are more than onr points of redistribution between core domain and edge domain, tag at one and deny the routes getting back at the other point and vice versa.



6)Make sure that before redistribution, if there was a 'redistribute connected' command used to advertise a loopback or a connected link, you modify it so that no interface that is supposed to be redistributed in left out.



For example R1 is a border router between OSPF and Eigrp. R1 runs EIGRP at serial and OSPF at ethernet. If I advertised R1's loopback in EIGRP through redistribution at an earlier stage, then during OSPF->EIGRP redistribution the ethernet interface won't be advertised, which should be as its running OSPF.

Workaround is simple, go to the route-map and make changes according.



What this approach does?

Well first of all we'll have connectivity between the edge domains.Then we'll inject routes from core into edge domains, making sure that core domain, within itself prefers its own routes and also edge domains prefer their own routes.There will be no loop (hopefully) and routing will be optimal, as each domain is preferring its native routes. Plus if we encounter any loop, it'd be easy to find out after which step the loop is occured.

It'd be easy to troubleshoot and worst case scenario, we can eliminate the step that resulted in a loop maintaining end to end reachability.



There is some problem with my Visio.I'll make a topology later and explain the process, through that. I could use an internetworkexpert topology, but I am not sure that'd be all right due to copy right issues. Though all I want to do here is borrow a diagram :S

Well
Its been three days and since BGP regex, the worst time I had in CCIE Prep.

The task is InternetworkExpert Lab2 , task 4.11 Redistribution.
I am stuck and have tried to read whatever I could find regarding this task but just cant, cant do it right.
When the backup interface is up, the solution is SG doesn't work. And ofcourse when backup link is down, full reachability isn't there.
I am going nuts.

Thinking again, maybe I am not CCIE material maybe:(