Sunday, December 30, 2007

CCIE BGP ORF

This days I am a little slow on article writing as I am in the final lap before my lab exam (wish to pass..) ok that was on a personal note. Now on a hopefully helping note, i had a little bit difficulty understanding first the logic behind ORF but when the coin dropped then I started hearing a voice in my head saying tada... So here it how it goes, the real BGP full table is currently almost 250K path entries, now you have connection to 3 ISP's and you want for example to get from your Backbone ISP the full table and from your other ISP's only partial table, you then face with a dilemma should I develop my human bagging skills to ask nicely from each ISP's to filter on his side specifically for you and what you will probably get as answer is "NO" or if he is nice then "NO". So now you face with a problem you can get from each of the ISP's the full table and filter on your side but it will not solve the performance and resource intensive problem you wanted to avoid. or you can call the nice person in the ISP side and ask him just to put neighbor capability orf prefix-list recive and on your side: neighbor capability orf prefix-list send note: that this will reset your BGP peer relationship, after that you will create your Prefix Filter now lets say you want to only recive the 2 class B subnets all you need to do is: ip prefix-list FILTER-FULL-TABLE seq 5 permit 187.0.0.0/16 ip prefix-list FILTER-FULL-TABLE seq 10 permit 198.0.0.0/16 ip prefix-list FILTER-FULL-TABLE seq 15 deny 0.0.0.0/0 le 32 ! ! under the BGP process ! router bgp neighbor prefix-list FILTER-FULL-TABLE in ! This will result in filtering the BGP table on your ISP side so you will not even get the table to filter it, it is cool not?! as it is allowing you to create filters on the ISP side without him to do any thing. Here is a small example from my home lab: R3 is peering with R1 and R1 is advertising some prefixes now R3 want to filter them but not on his side: !R3 before ORF ! router bgp 100 no synchronization bgp log-neighbor-changes neighbor 150.1.1.1 remote-as 200 neighbor 150.1.1.1 password CISCO neighbor 150.1.1.1 update-source Loopback0 ! R3#sh ip bg BGP table version is 193, local router ID is 150.1.3.3Status 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 *> 150.1.0.0/21 150.1.1.1 0 0 200 i *> 150.1.1.0/24 150.1.1.1 0 0 200 i *> 167.13.0.0 150.1.1.1 0 0 200 i *> 167.13.135.0/24 150.1.1.1 0 0 200 i *> 205.90.31.0 150.1.1.1 0 200 254 ? *> 220.20.3.0 150.1.1.1 0 200 254 ? *> 222.22.2.0 150.1.1.1 0 200 254 ? ! Here is R1 before: R1#sh ip bg nei 150.1.3.3 ad BGP table version is 16, local router ID is 150.1.1.1Status 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 *> 150.1.0.0/21 0.0.0.0 32768 i *> 150.1.1.0/24 0.0.0.0 0 32768 i *> 167.13.0.0 0.0.0.0 32768 i *> 167.13.135.0/24 0.0.0.0 0 32768 i *> 205.90.31.0 192.10.1.254 0 0 254 ? *> 220.20.3.0 192.10.1.254 0 0 254 ? *> 222.22.2.0 192.10.1.254 0 0 254 ? ! router bgp 200 no synchronization bgp log-neighbor-changes network 150.1.1.0 mask 255.255.255.0 network 167.13.135.0 mask 255.255.255.0 aggregate-address 150.1.0.0 255.255.248.0 aggregate-address 167.13.0.0 255.255.0.0 neighbor 150.1.3.3 remote-as 100 neighbor 150.1.3.3 password CISCO neighbor 150.1.3.3 next-hop-self ! NOW: I would like to filter on R1 the following so I will not even get prefixes" 167.13.135.0/24 150.1.1.0/24 222.22.2.0/24 So I am setting on ! R1 (the ISP side for that example) router bgp 200 neighbor 150.1.3.3 capability orf prefix-list receive ! ! R3 (the client side) router bgp 100 neighbor 150.1.1.1 capability orf prefix-list send neighbor 150.1.1.1 prefix-list FILTER-DUP in ! and the following prefix list ip prefix-list FILTER-DUP seq 5 deny 167.13.135.0/24 ip prefix-list FILTER-DUP seq 10 deny 150.1.1.0/24 ip prefix-list FILTER-DUP seq 11 deny 222.22.2.0/24 ip prefix-list FILTER-DUP seq 15 permit 0.0.0.0/0 le 32 ! now be prepared for the TADA.. R3#sh ip bg BGP table version is 194, local router ID is 150.1.3.3Status 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 *> 150.1.0.0/21 150.1.1.1 0 0 200 i *> 167.13.0.0 150.1.1.1 0 0 200 i *> 205.90.31.0 150.1.1.1 0 200 254 ? *> 220.20.3.0 150.1.1.1 0 200 254 ? So Up to now it looks normal that the filter was done on our side and when applied it was filtering incoming prefixes, but no! See R1 Advertisements: R1#sh ip bg nei 150.1.3.3 ad BGP table version is 16, local router ID is 150.1.1.1Status 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 *> 150.1.0.0/21 0.0.0.0 32768 i *> 167.13.0.0 0.0.0.0 32768 i *> 205.90.31.0 192.10.1.254 0 0 254 ? *> 220.20.3.0 192.10.1.254 0 0 254 ? and no there is no prefix list on R1, belive me: R1#sh ip bg nei 150.1.3.3 ... Outbound Route Filter (ORF): received (4 entries) Sent Rcvd Prefix activity: ---- ---- Prefixes Current: 4 0 Prefixes Total: 4 0 Implicit Withdraw: 0 0 Explicit Withdraw: 0 0 Used as bestpath: n/a 0 Used as multipath: n/a 0 ... ORF prefix-list: 3 I hope that was a little eye open on this issue :-)

Wednesday, December 26, 2007

Mary Christmas and Happy New Year

To all of you that study during the holidays and thinking they are the only one, well you are not alone. Our dedication to the goal is what Differentiate us, an expert is not the one that know all, it is the one that is most dedicated to find the best solution and do what ever it takes. So Mary Christmas and Happy New Year to all of you out there :-) Now let ABBA Continue from here....

Wednesday, December 05, 2007

CCIE EIGRP METRIC

One of the annoying fileds in my opinion is calculation, I hate them! in my mind it is just in the way of the cool stuff. but unfurtunetly to get to the cool stuf you need to calculate.

so I would like to start by giving you a little review and may be more indepth look over EIGRP Metric, as we all should know EIGRP is a Hybrid Routing Protocol that use a Composite Metric in his DUAL Diffusing Update Algorithm. the Composite metric is composed (good word selection :-)!?) from K Values.

K1 K2 K3 K4 K5

K1 = Bandwidth = 1 meaning it is used in the calculation by default.

K2 = load = 0 you gust it, meaning that is not participating in the calculation by default.

K3 = Delay = 1 you can take it from here

K4 = Reliability = 0

K5 = MTU = 0

the K values tells us if the value is participating in the calculation or not and what is the weight of the value, meaning that if you set K1 to 3 then it means that the weight of K1 will be 3 times more "important" or in other words it will take the BW * 3.

So now we know what are the "K" Values we need to know how to calculate:


well I will not endolge you with long version of the formula as it is hardly ever use (by hardly I mean I never seen it fully used).

Metric = [256 * (10^7/BW) + 256 * (Accumulated Delay)]

in the attached picture I draw a small network to demonstrate what I mean to get from R1 to R3 netwrok 3.3.3.0/24

you have the following options:
R1 -> R2 -> R3
The lowes bandwith in that path is 64Kbps
The Delay is 20000 for the 64Kbps link 100 for the 100 Mbps linke and another 100 for the 3.3.3.0/24 network link also 100Mbps = 20200 microseconds delay.

so now lets put all into the formula:

Metric = [256 * (10^7/BW) + 256 * (Accumulated Delay)]
Metric = [256 * (10^7/64) + 256 * (20000 + 100 + 100)]
Metric = [256 * (156250) + 256 * (20200)]
Metric = [40000000 + 5171200]
Metric = 45171200 = FD Feasable Distance (I will Talk about this in a bit)

R1 -> R4 -> R3

Metric = [256 * (10^7/BW) + 256 * (Accumulated Delay)]
Metric = [256 * (10^7/64) + 256 * (20000 + 1000 + 100)]

! note that now you have 1000 in the path as it is a regular 10 Mbps Ethernet
Metric = [256 * (156250) + 256 * (21100)]
Metric = [40000000 + 5401600]

Metric = 45401600 = FD

R1 -> R2 -> R4 -> R3
Metric = [256 * (10^7/BW) + 256 * (Accumulated Delay)]
Metric = [256 * (10^7/64) + 256 * (20000 + 20000 + 20000 + 100)]
Metric = [256 * (156250) + 256 * (60100)]
Metric = [40000000 + 15385600]

Metric = 55385600 = FD

R1 -> R4 -> R2 -> R3 I think you should do it now, you should get the point of the calculation

Now that have an idea how to calculate we need to see what route is preferd, in that senarion it is easy but in complex networks this basics can help us understand the proccess (leave the calc to the router).

FD as I was mentioning this Feasable Distance is the Metric that our router see from his outgoing interface to the point he wish to go, also caled end-to-end metric.

AD Advertised Distance that is the Distance we recive from our directly connected neighbor for the path we wish to go.

so for FD of R1 ->R2 ->R3 we get an AD of R2->R3.

FS Feasible Successor is the Router that is chosen by us to be the next hop to the Destination Prefix.

FC Feasible Condition is a rule that tells us in a very logical way to select a FS he must send to us an AD that is lower then the FD.

if we received from R4 for example a AD higher then the FD that we had already in our topology table to get to R3 then we would not consider him to be a Feasible Successor.

so final step lets take the Paths and FD and Calculate the AD and see what path sould we go as I am already exited where to go from now:

Now our AD for the Paths sent to R1:

R2 -> R3
Metric = [256 * (10^7/BW) + 256 * (Accumulated Delay)]
Metric = [256 * (10^7/100000) + 256 * (100 + 100)]
Metric = [256 * (100) + 256 * (200)]
Metric = [25600 + 51200]

Metric = 76800 = AD
Metric = 45171200 =FD


R4 -> R3
Metric = [256 * (10^7/BW) + 256 * (Accumulated Delay)]
Metric = [256 * (10^7/64) + 256 * (20000 + 100)]
Metric = [256 * (156250) + 256 * (20100)]

Metric = [40000000 + 5145600]
Metric = 45145600 = AD
Metric = 45401600 = FD


R1 -> R2 -> R4 -> R3
Metric = [256 * (10^7/BW) + 256 * (Accumulated Delay)]
Metric = [256 * (10^7/64) + 256 * (20000 + 20000 + 20000 + 100)]
Metric = [256 * (156250) + 256 * (60100)]
Metric = [40000000 + 15385600]

Metric = 55385600 Here we can clearly see that there is not way that this route can meet the FC.
So we have a winner:
Metric = 76800 = AD
Metric = 45171200 =FD

to get to R3 3.3.3.0/24 R1 will take the path R1 ->R2 -> R3.
if it will fail then the path R1 ->R4->R3 will be taken as he still qualified to meet then FC for FS

FS Feasible Successor the second path in the topology that is set only of FC are met.

I hope this was an intersting article :-)

Tuesday, November 13, 2007

IPV6 Tricks

Have you ever faced with a situation where you where stuck out of your server due to a IP Address Change, well if you didn't you might one day, let me tell you how IPv6 Saved me. I have several Linux Servers in My Company and Due to some maintenance I needed to change the IP Address on on of them, simple task although it went bad due to a miss spelling on the ifcfg-eth0 file. and like I love to go fast with configuration I did a stupid mistake and restarted the network service well needless to say that as soon as I did that I was left outside, started yelling and spelling out some wired brrrrrrr hmmmm grrrrrrr and all sort of mad words. but then I said to my self hey i am an almost Expert I know Networking, how do I solve this, well the port is still listening on the Ethernet Network so If I had some way of login via ARP or MAC or Other Protocol then I was good to go, and then it pupped out to me IPv6 use in link local address based on MAC address and I have the MAC address of my Linux also I remembered that Linux from Kernel 2.6 is using IPv6 Nativity mean that if i will take the MAC address and convert it to IPv6 link local address FE80:: and do not forget to inverse the 7th bit of the MAC address if you have MAC 1234:5678:1111 0001 0010 now it is 0001 0000 1034:5678:1111 and you add to it FE80:: FE80::1034:5678:1111 --> TADA then I will be able to ping it and log in from one of my other servers so that is what I did and there you go a rescue backdoor to your network when your IPv4 network is down. also you could login from remote if you set on your Cisco a 6to4 tunnel, but that is for next article, leave the good stuff for later :-)

Saturday, October 13, 2007

CCIE IP Precedence Vs DSCP Values

The Table bellow Represent the TOS filed in the IP Header

IPP

IPP

IPP

DropP DropP

0

ECN

ECN

Drop P = Drop Precedence IPP = IP Precedence The Drop Precedence means the probability that the packet will be dropped, the higher the value it is more likely to be dropped. IP Precedence is the importance value of a packet, the higher the value the packet is more valuable. In IP Precedence we have 0 – 7 values and you can see that by looking into the amount of fields that we have Routing (Best Effort) - 000 Priority - 001 Immediate - 010 Flash – 011 => mainly used for Voice Signaling or for Video Flash-Override - 100 Critical – 101 => mainly used for Voice RTP Internet - 110 Network - 111 You do not need to remember the name value of each one, you can simply see it with: TermServ(config)#access-list 100 permit ip any any precedence ? (0-7) Precedence value critical Match packets with critical precedence (5) flash Match packets with flash precedence (3) flash-override Match packets with flash override precedence (4) immediate Match packets with immediate precedence (2) internet Match packets with internetwork control precedence (6) network Match packets with network control precedence (7) priority Match packets with priority precedence (1) routine Match packets with routine precedence (0) with that said now we have added 2 more bits for the or more accurate 3 bits but only 2 bits we are playing with for allowing us to determine with in the scope of class witch is more preferable and for that we divided to 6 main classes Class 0 – Called also Best Effort all bits are 0 = 000000 Now we have 4 classes that are with in them divided each to 3 separate
Class1 AF11 001010 AF12 001100 AF13 001110
Class2 AF21 010010 AF22 010100 AF23 010110
Class3 AF31 011010 AF32 011100 AF33 011110
Class4 AF41 100010 AF42 100100 AF43 100110
DropP IPP Class 5 – EF Expedited Forwarding last class used for Voice Traffic Mainly 101110, and also all the DSCP values you can see with a simple ACL, but I think it is better to understand the principle and once you understand it you will not have to remember you will simply know. As it is relatively simple but the quantity makes people confused. TermServ(config)#access-list 100 permit ip any any dscp ? (0-63) Differentiated services codepoint value af11 Match packets with AF11 dscp (001010) af12 Match packets with AF12 dscp (001100) af13 Match packets with AF13 dscp (001110) af21 Match packets with AF21 dscp (010010) af22 Match packets with AF22 dscp (010100) af23 Match packets with AF23 dscp (010110) af31 Match packets with AF31 dscp (011010) af32 Match packets with AF32 dscp (011100) af33 Match packets with AF33 dscp (011110) af41 Match packets with AF41 dscp (100010) af42 Match packets with AF42 dscp (100100) af43 Match packets with AF43 dscp (100110) cs1 Match packets with CS1(precedence 1) dscp (001000) cs2 Match packets with CS2(precedence 2) dscp (010000) cs3 Match packets with CS3(precedence 3) dscp (011000) cs4 Match packets with CS4(precedence 4) dscp (100000) cs5 Match packets with CS5(precedence 5) dscp (101000) cs6 Match packets with CS6(precedence 6) dscp (110000) cs7 Match packets with CS7(precedence 7) dscp (111000) default Match packets with default dscp (000000) ef Match packets with EF dscp (101110)

Thursday, October 11, 2007

CCIE INTERNETWROKEXPERT

I would like to express my grate appreciation to the contribution that Internetworkexpert brings to the Technical Community, although they are a commercial company they do give away free seminars and do help people that are in need to learn and do not have a lot of financial resources to do that. So Thank you InternetworkExpert Here is a recent v-sminar that was added on IPv6 http://classroom.internetworkexpert.com/p23982603/ Soon they will release a v-seminar that was transferred yesterday for free on Catalyst QoS. Also grate thanks to there top notch instructors: Brian Dennis, CCIE #2210 (R&S/ISP Dial/Security/Service Provider) Brian McGahan, CCIE #8593 (R&S/Service Provider/Security) THANK YOU!

Monday, October 08, 2007

CCIE SecureCRT Tip

As you all know the mostly used terminal in the CCIE lab exam is the old SecureCRT from http://www.vandyke.com/ without the tabs addition. but what you do have is the key mapping. you can set for example: F6 to be the CTRL SHIFT 6+x by simply setting the send sting in the key map to \036x F7 to be CTRL SHIFT 66 sequence of braking in the middle of a trace or a ping when you connected with the Access Server by mapping \0366 I my self practicing without the shortcuts but each person with its own methods and tactics. I believe the quest is like a preparation for the Olympics so practice practice practice.

Sunday, October 07, 2007

CCIE VERIFY RPF FAIL

One of the major issues with Multicast is finding the RPF and making sure that there is no Failure in it, as if we do have a fail we can patch it by adding ip mroute (like a static route but only to pass the RPF, not actually changing the path of the packet). So how we can find such fail we have several tools the first one is to find if we have rp mapping. R6#sh ip pim rp ma PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 150.1.5.5 (?), v2v1 Info source: 150.1.3.3 (?), elected via Auto-RP Uptime: 00:14:48, expires: 00:00:02 R6# we see here in that example that we do have RP Mapping so we defiantly passed the RPF. I have made an RPF fail and we now will try to trace it: R6#sh ip mroute count IP Multicast Statistics 3 routes using 1962 bytes of memory 3 groups, 0.00 average sources per group Forwarding Counts: Pkt Count/Pkts(neg(-) = Drops) per second/Avg Pkt Size/Kilobits per second Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc) Group: 227.0.0.1, Source count: 0, Packets forwarded: 0, Packets received: 0 Group: 224.0.1.1, Source count: 0, Packets forwarded: 0, Packets received: 0 Group: 224.0.1.40, Source count: 0, Packets forwarded: 0, Packets received: 0 we see that we are not receiving packets from our mapping agent when we listen on group 224.0.1.40 so some where along the path we have an RPF fail. R6#sh ip mrou IP Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT, M - MSDP created entry, X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement, U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel, z - MDT-data group sender, Y - Joined MDT-data group, y - Sending to MDT-data group Outgoing interface flags: H - Hardware switched, A - Assert winner Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 227.0.0.1), 00:02:19/00:02:47, RP 0.0.0.0, flags: SJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/0, Forward/Sparse, 00:02:19/00:02:47 (*, 224.0.1.1), 00:02:19/00:02:53, RP 0.0.0.0, flags: SJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/0, Forward/Sparse, 00:02:19/00:02:53 (*, 224.0.1.39), 00:01:12/stopped, RP 0.0.0.0, flags: DP Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Null (150.1.5.5, 224.0.1.39), 00:01:12/00:01:47, flags: PT Incoming interface: FastEthernet0/0, RPF nbr 166.1.12.1 Outgoing interface list: Null (*, 224.0.1.40), 00:02:20/00:02:54, RP 0.0.0.0, flags: DCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/0, Forward/Sparse, 00:02:20/00:02:54 R6# we see above that we do get see the RP and we get it from 166.1.12.1 so lets got to R1 (166.1.12.1). R1#sh ip mroute count IP Multicast Statistics 5 routes using 2946 bytes of memory 4 groups, 0.25 average sources per group Forwarding Counts: Pkt Count/Pkts(neg(-) = Drops) per second/Avg Pkt Size/Kilobits per second Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc) Group: 227.0.0.1, Source count: 0, Packets forwarded: 0, Packets received: 0 Group: 224.0.1.1, Source count: 0, Packets forwarded: 0, Packets received: 1 RP-tree: Forwarding: 0/0/0/0, Other: 1/0/1 Group: 224.0.1.39, Source count: 1, Packets forwarded: 12, Packets received: 12 Source: 150.1.5.5/32, Forwarding: 12/1/48/0, Other: 12/0/0 Group: 224.0.1.40, Source count: 0, Packets forwarded: 0, Packets received: 0 R1# we see here that we still do not recive any packet on the mapping group. R1#sh ip mrou IP Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT, M - MSDP created entry, X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement, U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel, z - MDT-data group sender, Y - Joined MDT-data group, y - Sending to MDT-data group Outgoing interface flags: H - Hardware switched, A - Assert winner Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 227.0.0.1), 00:01:24/00:02:10, RP 0.0.0.0, flags: SP Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Null (*, 224.0.1.1), 00:01:24/stopped, RP 0.0.0.0, flags: SP Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Null (166.1.12.4, 224.0.1.1), 00:00:20/00:03:09, flags: T Incoming interface: FastEthernet0/0, RPF nbr 0.0.0.0 Outgoing interface list: Serial1/0, Forward/Sparse, 00:00:20/00:03:09 (166.1.12.6, 224.0.1.1), 00:00:20/00:03:09, flags: T Incoming interface: FastEthernet0/0, RPF nbr 0.0.0.0 Outgoing interface list: Serial1/0, Forward/Sparse, 00:00:20/00:03:09 (*, 224.0.1.39), 00:01:26/stopped, RP 0.0.0.0, flags: D Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/0, Forward/Sparse, 00:01:26/00:00:00 Serial1/0, Forward/Sparse, 00:01:26/00:00:00 (150.1.5.5, 224.0.1.39), 00:01:26/00:02:56, flags: T Incoming interface: Serial1/0, RPF nbr 166.1.0.5 Outgoing interface list: FastEthernet0/0, Forward/Sparse, 00:01:26/00:00:00 (*, 224.0.1.40), 00:01:27/00:02:04, RP 0.0.0.0, flags: DCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/0, Forward/Sparse, 00:01:27/00:00:00 Serial1/0, Forward/Sparse, 00:01:27/00:00:00 R1# now lets go again one step forward to R5 to see if R5 is also not receiving packets for group of the mapping agent. R5#sh ip pim rp ma PIM Group-to-RP Mappings This system is an RP (Auto-RP) Group(s) 224.0.0.0/4 RP 150.1.5.5 (?), v2v1 Info source: 150.1.3.3 (?), elected via Auto-RP Uptime: 00:00:45, expires: 00:00:01 R5# and we can see that we do receive the mapping from 150.1.3.3 on R5 so we know that the RPF fail happen on R1 to R3 Now I will tell you that R5 R3 and R1 are connected over FR (Physical Interface only) R5 is the hub and R1 and R3 are the spokes. so first we need to make sure that we enabled R5(config-if)#ip pim nbma-mode that command will make sure that packets received on one VC of the FR can go out that same interface to another VC for Sparse Groups Only here bellow you can see the output of sparse group with the nbma-mode enable you can see it is going out of that same interface but to different IP (VC) (*, 227.0.0.1), 20:05:09/stopped, RP 150.1.5.5, flags: SJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Serial1/0, 166.1.0.3, Forward/Sparse, 00:15:40/00:01:01 Serial1/0, 166.1.0.5, Forward/Sparse, 04:28:41/00:02:42 And on that same router R5 although I have enabled nbma-mode you can see that for dense mode group it is acting different. (*, 224.0.1.40), 17:24:56/stopped, RP 0.0.0.0, flags: DCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Loopback0, Forward/Sparse, 17:24:56/00:00:00 Serial1/0, Forward/Sparse, 17:24:56/00:00:00 So now that we see that we traced where the RPF is we need to solve it, on R1 R1#sh ip route 150.1.3.3 Routing entry for 150.1.3.3/32 Known via "ospf 1", distance 110, metric 65, type intra area Redistributing via eigrp 1 Advertised by eigrp 1 metric 1536 1 255 1 1500 Last update from 166.1.0.3 on Serial1/0, 00:17:50 ago Routing Descriptor Blocks: * 166.1.0.3, from 150.1.3.3, 00:17:50 ago, via Serial1/0 Route metric is 65, traffic share count is 1 R1#sh ip route 166.1.0.3 Routing entry for 166.1.0.0/24 Known via "connected", distance 0, metric 0 (connected, via interface) Redistributing via eigrp 1 Advertised by eigrp 1 Routing Descriptor Blocks: * directly connected, via Serial1/0 Route metric is 0, traffic share count is 1 we know that 224.0.1.40 is Dense mode group and it cannot pass the RPF due to that as it will not be able to go out the same interface it came in. so what we can do is create a tunnel interface between R1 to R3. And set the RPF to check the path trough that tunnel. interface Tunnel0 ip unnumbered Loopback0 ip pim sparse-mode tunnel source Loopback0 tunnel destination 150.1.3.3 ! R1#sh run inc ip mrou ip mroute 150.1.3.3 255.255.255.255 Tunnel0 R1# ! interface Tunnel0 ip unnumbered Loopback0 ip pim sparse-mode tunnel source Loopback0 tunnel destination 150.1.1.1 end R3# we must make sure that the source and the destination match exactly on both side like showed here and both on the interface that we are sourcing and destination and the tunnel we enabling PIM. R1#sh ip pim neighbor PIM Neighbor Table Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority, S - State Refresh Capable Neighbor Interface Uptime/Expires Ver DR Address Prio/Mode 166.1.0.5 Serial1/0 20:52:24/00:01:20 v2 1 / DR S 166.1.12.4 FastEthernet0/0 17:20:06/00:01:24 v2 1 / S 166.1.12.6 FastEthernet0/0 20:51:54/00:01:21 v2 1 / DR S 150.1.3.3 Tunnel0 00:02:12/00:01:30 v2 1 / S R1# R1#sh ip pim rp ma PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 150.1.5.5 (?), v2v1 Info source: 150.1.3.3 (?), elected via Auto-RP Uptime: 00:00:10, expires: 00:00:02 R1# And now we can go back to R6 and see that we have also mapping on R6 so we solved RPF fail. R6#sh ip pim rp ma PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 150.1.5.5 (?), v2v1 Info source: 150.1.3.3 (?), elected via Auto-RP Uptime: 00:00:33, expires: 00:00:03 R6#

Friday, October 05, 2007

CCIE PIM AUTO RP

In that section I would like to talk about Auto-RP, well not until recently I have had little to say about multicasting as it was something I know but like most I didn’t really understand or have struggled to really see how it works, I only know that when you enable it, you basically save bandwidth by using one stream instead of unicasting to each and every station, and on the basic it is true but the how it works is more important for us candidates. So here I will show you how the Auto-RP works and what tools do we have to make it work. Well we should all know that we have today 3 basic operation modes of PIM Sparse Mode – or as it called source tree and it is mostly used today Multicast Networks using a Pull Technology meaning if you do not ask I will not send it Dense Mode – or as it called shared tree and this is the very basic of Multicast using Push Technology meaning I will always send and if you say you do not need it I will Prune back but after a certain time out I will again send to you just so you want miss it if you do need it in some point. Sparse-Dense Mode – well this is a hybrid of the 2 methods meaning that I will Sparse if I have an RP (Rendezvous Point) but if I don’t have one or I loose it then I will fall over to Dense Mode. When we enable PIM Sparse Mode we most have and RP the RP witch is like having a DR in the OSPF, it will be responsible on the Path for the Multicast Group. To have RP in a Sparse Group we have 3 methods: a) Static b) Auto-RP Cisco proprietary c) BSR the industry standard We will talk here about Auto RP: First Step before we start with any multicast config we need to make sure that all our unicasting routing is working so that is the initial step before we even think on Multicast. Why?! Because Multicast is relaying on our Unicast to pass the traffic as we know RPF is done based on the Unicast routing Table and the RPF is basic check of backwards Path between the Sources of the Traffic to the Destination, with that said each time a new group is announced it must go trough the RPF check. To Enable Auto RP we must specify an RP-Candidate and RP-Mapping RP-Candidate is to announce your self as an RP, you can also announce one Router to be RP for certain groups and different Router to be RP for different groups. RP-Mapping the Mapping agent can be the same Router as the Candidate but it also can be a different Router it is simply to send the router in the Multicast Domain the mapping to the RP. When you enable the RP Candidate you Join a Group 224.0.1.39 and when you enable the Mapping you Join Group 224.0.1.40 also you can see that all Routers that you set with multicast join group 224.0.1.40 if you do: R2#sh ip mrou IP Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT, M - MSDP created entry, X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement, U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel, z - MDT-data group sender, Y - Joined MDT-data group, y - Sending to MDT-data group Outgoing interface flags: H - Hardware switched, A - Assert winner Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.0.1.40), 00:00:00/00:02:59, RP 0.0.0.0, flags: DCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/0, Forward/Sparse, 00:00:00/00:02:59 On the RP I am setting the announce and the discovery and the listner The listner is actually to enable the pim to send the 224.0.1.39/40 as Dense Mode with out needing to enable sparse-dense mode or other workaround as this 2 groups must be in Dense Mode. ! ! I used a loopback as the source of the groups but you can also enable the source to come ! From a physical interface although if you loose that interface you will loose your RP. ! You must also remember that all Routers in the Multicast Domain must have Unicast ! Connectivity to the RP ! ip pim autorp listener ip pim send-rp-announce 150.1.1.1 scope 255 interval 10 ip pim send-rp-discovery Loopback0 scope 255 interval 10 ! ! Also if you use the loopback as the RP then you must enable on the loopback also PIM After you enable on all the interfaces in your path PIM you should check for neighbor relationship: R1#sh ip pim nei PIM Neighbor Table Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority, S - State Refresh Capable Neighbor Interface Uptime/Expires Ver DR Address Prio/Mode 120.1.0.3 Serial1/0 00:24:52/00:01:29 v2 1 / DR S 120.1.0.2 Serial1/0 00:26:37/00:01:38 v2 1 / S Then you should check that you have mapping to the RP: R3#sh ip pim rp ma PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 150.1.1.1 (?), v2v1 Info source: 150.1.1.1 (?), elected via Auto-RP Uptime: 00:12:15, expires: 00:00:26 If one of the steps is failing then first check for RPF fail by: R3#sh ip mroute count IP Multicast Statistics 4 routes using 1788 bytes of memory 2 groups, 1.00 average sources per group Forwarding Counts: Pkt Count/Pkts(neg(-) = Drops) per second/Avg Pkt Size/Kilobits per second Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc) Group: 224.0.1.39, Source count: 1, Packets forwarded: 0, Packets received: 11 Source: 150.1.1.1/32, Forwarding: 0/-1/0/0, Other: 11/0/11 Group: 224.0.1.40, Source count: 1, Packets forwarded: 0, Packets received: 11 Source: 150.1.1.1/32, Forwarding: 0/-1/0/0, Other: 11/0/11 If you had a fail here then the Other: 11/11/0 meaning that the failed would increase. To solve a RPF fail you need to make sure that you pass the RPF check and the RPF check is done using the Unicast routing table meaning that you need to check that the path that the packet is taking is trough the Multicast Domain and not trough a non Multicast interfaces. Also you can pass the RPF by adding a static R3(config)#ip mroute 0.0.0.0 0.0.0.0 # For the exam you must ask if it is allowed.

When using PIM Sparse in NBMA environment like Frame Relay you need to make sure you enter the ip pim nbma command to disable the split horizon rule that traffic coming into the interface is not going out that same interface. The IP pim nbma is working only for Sparse Mode Group Candidate RP need to be able to communicate only with the mapping agent and the Routers in the Domain need to be able to communicate with the Mapping agent so from that we can understand that we need to watch our Route to the Mapping Agent. Ok I think I will end it here for now, I hope this was good info.

Sunday, September 23, 2007

Web Design

Hi Guys, I know it is not related to the main subject of my blog but I would like to give here a Little credit to my brother and his partner new Web Design business. I think you should to EG STUDIO

Monday, August 27, 2007

CCIE Regular Expression in BGP

I think one of the most scary configuration is when using Regular Expression (at least for me) it took me a while and I am still straggling from time to time, although I am writing to you about this I am sorry to say there is no easy way to get it. you just need to put it in your head I believe the each explanation has its own advantage as some people understand reading manual some need a trainer to lecture them. Here I will give some of my own explanation to the common regular expression: * all char, mean when you use this it can be any char ^ start here, for example ^5 mean any thing that start with 5 so it could be 5 or 500 or 54 or 5000000 $ end here, for example 5$ mean any string that end with 5 so it could be 455 or 45 or 5 or 3005 _ (underscore) start or end or space, this is a nice one as it mean you can either start a string or end a string or simple space. example _5_ can only mean 5 but _5 can mean 5 or 500 or 54 or 5000000 and 5_ can mean 455 or 45 or 5 or 3005 [] brackets, I do not know how to define it but it mean that any thing with in the brackets you use example 5[9834] mean it can be 59 or 58 or 53 or 54 basically it is like you put comma between char but you don't. you can also specify range 5[3-6] so it mean 53 or 54 or 55 or 56 ? true or false, this is nice as it is like a game you either have it or you don't when you specify 5? it mean either 5 or nothing mean he will search both scenarios. () group, here like you do arithmetic's you have logical grouping mean you can set up something like so ^50(_[1-9]43)?$ and it mean that it will bring you path that looks like that: 50 or 50 143 50 243 .... + plus sign mean that at least one char should be present example 4+ mean it can match 4 or 44 or 444 or 44444 there are a lot of combinations to the regular expression but they all just like a formula, you need to understand exactly what you want to match to form it. another useful regexp small and simple is ^$ yes this is useful and how you ask well as a client you would like to know most of the time that you are not being used, as you are paying the Service Provider and not the other way around. when you are connected to 2 SP and you get advertisements from one provider the default behavior is to publish to the other EBGP neighbors mean the 2 SP and consider the option that some time your route will be shorter then the route of the 1 SP to the 2 SP you will become a SP to the SP (hope I didn't confuse you) but to make long story short, if you publish networks that are not yours from your network you can become and will become a transit area mean that unwanted traffic of one SP will pass trough you and utilize your bandwidth and the simple way to stop it is not advertise network that are not your own!!! and how you do it you ask?! well by matching an as-path list to ^$ to permit only routes that do not have any other AS numbers on there path to be advertised meaning your own AS. simple no?!

CCIE QinQ

I must say this is one of the technology's I love and some times also love to hate as it can make you very confused on where to start and what to do to make it work, but once you do make it work you fill like Houdini.

why like Houdini because basically the technology make your middle switch go away like it never was there and sowing to the person you wanted to show like he is directly connected to a switch when he is not.

now that I made every one a little confused, i will start to explain, QinQ allow you to take a middle switch and turn it to transparent while connecting 2 other components and maid them fill like they are directly connected.





why do you need that, well the CCIE lab love it as it is confusing setup but there are more reason then that, with QinQ you can connect topology's while you migrating, you can also connect between clients that have there own topology that you do not want to encounter in your topology by transferring all of them with a single tag between there point of presents you do not need to create a trunk between the 2 branches and pass all the vlan id inside while limiting your self to 1 or 2 clients.

you can see a much more elaborate details in cisco site

here i will give you few steps to create QinQ simple scenario
you can see that R1 is connected to SW1 and SW1 connected to SW2, if you will do a show cdp nei on R1 you will see that you are connected on F0/0 to SW1 F0/1, I want you to make you see like you are connected to SW2 port F0/10, how to do that magic?!

Go into SW1
global config
! this is to allow another tag to pass the metro tag as it also
! called an additional of 4 byte
!
switch(config)#system mtu 1504
! i will create a vlan for access control between the ports


switch(config)#vlan 200
!
!now I will go under int F0/1 and F0/10 and type the same commands
switch(config-if)#sw mode dot1q-tunnel
switch(config-if)#sw acc vlan 200
switch(config-if)#l2protocol-tunnel cdp
switch(config-if)#no shut

now when you will go to R1 and do show cdp nei you will see like magic that you are directly connected to SW2 F0/10 instead of SW1 and I didn't switched the cable!!!

Read more on cisco site you will love it.

Tuesday, August 21, 2007

CCIE LAB with Dynamips

I am proude to present to you my first LAB design with Dynamips, it is a 5 router topology with the use of FRSW and ETHSW from Dynamips.

I am working today with IEWBv4 to get my number. during my study I have said to my self why not create also your own LAB topology with your own scenarios, and here we are.


you can download my .net and initial config


As for the Lab Scenarios rules:

1) Do NOT use Frame-Relay Inverse Arp
2) Do NOT use sub interface with int Frame-Relay
3) There should be connectivity trough out the network include routes advertised from BB1
4) Y represent the Router number

General
1) Set loopback interfaces on R1/R2/R3/R4 with 150.1.y.y

WAN

1) Set Connectivity on the Frame Relay cloud between R1 R2 and R3
2) set Connectivity on the Frame Relay cloud between R4 to BB1
3) Set Serial using ppp between R3 and R4
4) I am a little afraid from unwanted users so please make sure you add on MD5 authentication between R3 to R4 and to make it more efficient as most of my traffic is txt files please use compression.


IGP

OSPF


1) Router 1 , 2 , 3 should all be on Backbone area
2) Do not use DR/BDR
3) Set Timers as on Non-Brodcast Topology
4) Set Authentication MD5

Eigrp

1) Set Router 3 and 4 on AS 34
2) The Administrator have connectivity between R3 and 4 trogh the Serial and FastEthernet make sure that both path will be used.
3) Advertise loopback interfaces with out using the network command
4) please make R3 and R4 authenticate each other with "CCIEP3" password and make sure that on December 28 2008 12 AM (when I turn 30) the password will be changed to "CCIEP?" also i wont you to allow a R4 and R3 to be able to authenticate CCIEP3 until 3AM Dec 28 2008.

Redistribute

1) Simply redistribute between Eigrp and OSPF on R3


I will Continue this lab Scenario later, please review and advice if you have any suggestions or feedback I will be happy to get some.

Thank you

Sunday, July 29, 2007

CCIE PPP over Frame-Relay

first I would like to start by explaining why we need it and how it is going to take our simple frame-relay to another level of connection, as we all know Frame-Relay is Layer 2 Technology design to reduce wide band use by sharing connections and grunting or not grunting link speed, today as you probably know the frame-relay has become obsolete by other technology's such like ADSL, Cable, Metro Ethernet and others.

ppp (point to point protocol) another layer 2 protocol design to give a better solution to hdlc (high level data link control) used to control and transport ip traffic in a reliable and secure way.


now people taught how do we give the old frame-relay more features without developing a new frame-relay, they said why not take the good old ppp and join them in a "holy matrimony" just kidding, but really why not take them both and enjoy both benefits one with sharing bandwidth and traffic shaping options and one with link integrity and security features.


so now I come to our scenario where you can see I have setup 2 routers, one with 1 serial dividing it to 2 sub interfaces and the other one with 2 serial joining them together to one multilink interface making them load balance packets and also secure using chap authentication.
the multilink is needed here only to enable load balancing and interleaving, you can do without but it is less efficient and way less cooler :-)

This is the show run on router 2:

!

username Rack1R1 password 0 cisco

!

!

interface Multilink1

ip address 192.168.1.2 255.255.255.0

ppp multilink

ppp multilink group 1

!

interface Serial1/0

no ip address

encapsulation frame-relay

serial restart-delay 0

no frame-relay inverse-arp

!

interface Serial1/0.203 point-to-point

frame-relay interface-dlci 203 ppp Virtual-Template1

!

interface Serial1/0.213 point-to-point

frame-relay interface-dlci 213 ppp Virtual-Template1

!

!

interface Virtual-Template1
no ip address

ppp authentication chap

ppp multilink group 1

!

that is the show run on router 1:

!
username Rack1R2 password 0 cisco
!
!
interface Multilink1
ip address 192.168.1.1 255.255.255.0
ppp multilink
ppp multilink group 1
!
interface Serial1/0
no ip address
encapsulation frame-relay
serial restart-delay 0
no frame-relay inverse-arp
!
interface Serial1/0


no ip address

encapsulation frame-relay

serial restart-delay 0

frame-relay interface-dlci 302 ppp Virtual-Template1

no frame-relay inverse-arp

!

interface Serial1/1

no ip address

encapsulation frame-relay

serial restart-delay 0

frame-relay interface-dlci 312 ppp Virtual-Template1

no frame-relay inverse-arp

!
!interface Virtual-Template1
no ip address
ppp authentication chap
ppp multilink group 1
!

Verify:

sh ppp multilink

Multilink1, bundle name is Rack1R1
.
.
.
Member links: 2 active,....
Vi1, since 07:53:31
Vi2, since 07:53:31

and good old ping:

ping 192.168.1.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 174.1.23.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/82/128 ms



Thursday, July 05, 2007

Warrning !!!

This is not related to the context of my blog but I would like to put here a warring against this E-Bay Seller, he sold me and others a fake Nokia N95 Model and you can see in that movie what a rip off it is! here is the link of what he sold on eBay and on the movie you can see what I received: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=160123539029&sspagename=ADME:L:RTQ:US:1 So Be Ware

Monday, July 02, 2007

MPLS BENEFITS

1) faster switching then IP as IP Forwarding is based on IP routing table search each address is 4 octets length and can cause some time to calculate 2) Core free from BGP as the MPLS is based on label switching there is no need any more for core routers to participate in the BGP network and only Edge routers need to be BGP aware. this is a huge memory and utilization saving. 3) MPLS TE Traffic Engineering is one of the major benefits as it is allowing you to have better path selections and it have a very good mechanism called FRR Fast ReRouting and this is allowing to re-route traffic from and unavailable router in a really fast speed of less then 50ms, and this is allowing us to build a stable and reliable Data and VoIP Network as you know less then 50ms loss will still keep the Voice Call Up, if it is more then that the call will be dropped. so this feature allows us in a good planed network to give us near PSTN solution. 4) MPLS VPN is another major benefit as it is reducing manageability and introducing simplicity to the client. before if the client wanted to create a VPN for his offices network he needed to either create tunnels between all his offices creating a lot of configuration and complex design when there are more then 4 branches or he needed to ask the provider to create all this VPN's and relay on his network design. but with MPLS VPN he simply need to make a Connection between his Customer Edge Router and Provider Edge Router.

Thursday, June 28, 2007

CCIE Strategy

This is a super nice strategy I saw published in CCIE Group Study and I decided to publish it here as a link so the Author will get the credit for it, so real nice http://www.ksu.ru/petr/CCIE-RS-Checklist-draft-part-1-v2.txt

Wednesday, June 27, 2007

CCIE OSPF Behaviors

There are five main behaviors when working with OSPF, some people get confused between them and I my self had a painful time understanding at the beginning what the hell we need them and what difference dose it make using one or the other. Broadcast - for shared network environment like Ethernet as you can see bellow by tweaking the interface behavior you can adjust also the timers and make it send multicats instead of unicast: Router1(config-if)#ip address 1.1.1.2 255.255.255.0 Router1(config-if)#ip ospf network broadcast Router1(config-if)#end Router1# show ip ospf interface s0 Serial2 is up, line protocol is up Internet Address 1.1.1.2/24, Area 0 Process ID 1, Router ID 3.3.3.3, Network Type BROADCAST, Cost: 64 Transmit Delay is 1 sec, State DR, Priority 1 Designated Router (ID) 3.3.3.3, Interface address 1.1.1.2 Backup Designated router (ID) 2.2.2.2, Interface address 1.1.1.1 Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 Hello due in 00:00:19 Index 1/1, flood queue length 0 Next 0x0(0)/0x0(0) Last flood scan length is 2, maximum is 2 Last flood scan time is 0 msec, maximum is 0 msec Neighbor Count is 1, Adjacent neighbor count is 1 Adjacent with neighbor 2.2.2.2 (Backup Designated Router) Suppress hello for 0 neighbor(s) non-broadcast - for Frame-relay or ATM here in the bellow example you can see the default behavior or the serial interface Router1# show ip ospf interface s2 Serial2 is up, line protocol is up Internet Address 1.1.1.2/24, Area 0 Process ID 1, Router ID 3.3.3.3, Network Type NON_BROADCAST, Cost: 64 Transmit Delay is 1 sec, State DR, Priority 1 Designated Router (ID) 3.3.3.3, Interface address 1.1.1.2 Backup Designated router (ID) 2.2.2.2, Interface address 1.1.1.1 Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5 Hello due in 00:00:19 Index 1/1, flood queue length 0 Next 0x0(0)/0x0(0) Last flood scan length is 2, maximum is 2 Last flood scan time is 0 msec, maximum is 0 msec Neighbor Count is 1, Adjacent neighbor count is 1 Adjacent with neighbor 2.2.2.2 (Backup Designated Router) Suppress hello for 0 neighbor(s) point to point - for point to point interface like ppp or hdlc encap point to multipoint - special behavior that the hub interface act as point to point to every spoke in its hub and spoke topology Point-to-Multipoint Nonbroadcast Broadcast use DR / BDR elecation and use multicats 224.0.0.6 for DR / BDR and 224.0.0.5 for all spf routers non-Broadcast use DR / BDR election but it use unicast for neighbor relations this is why you need to make sure that you enable this on the hub of the topology and not on one of the spokes and also you must remember to specify each neighbor manually (only on the hub). point-to-point is the easiest as there is no DR / BDR and the relation is formed very quickly using multicast point to multipoint is also very easy and nice as it also do not use DR / BDR and is forming relation using multicats. Point-to-Multipoint Nonbroadcast like point to multipoint but with the requirement of the neighbor statement in the config now that we understand the modes, some time we are required "mainly in the lab exam" to manipulate the default interface behavior and setting a different one and this is done with the command ip ospf network like i showed in the initial sample when I used a serial interface and tweaked it to use Broadcast behavior and like so I can do the other way meaning using Ethernet and tweaking it to use non-broadcast behavior, now you probably ask your self why would you want to do that??? well the answer is simple: 1) they asked you :-) 2) the more serious answer is that you need more security as you know non-broadcast use unicast meaning that client that should be updated wont be! and you can add to this also encryption and authentication and even if your address been spoofed you will have protection against evil I hope this has been some help!