New Hire @Cisco System

Hi and halo, it is me again here :p

Well, it has been two month my employment with Cisco, and I sometime I can't believe that I am a part of the Cisco Family, Thank you good, I've really been appreciate it.

The thing that I can say working in Cisco is, a lot of works to do, really, in my current role, which is a Commercial System Engineer, I have to face different types of customer & technology, R/S is the fundamental skill set that you should have in Cisco, obviously, some of the customer are Small to Medium Service Provider, and you know what, they are not talking MPLS feature, but what I was encounter were the access Technology, things like HFC, FTTH, DWDM, Etc.....

well I can say it was initially quite frustrating , but the deeper you've studied this kind of thing the more interesting they are ;). Another great thing Working at Cisco is that when you are stuck with a specific Technology, then what you need to do is find out a person, locally or globally within your region, that mastering the technology, aka Consulting System Engineer (CSE), and asked for help. They will gladly help us out ;)

Thanks god, I like this kind of Giggy Internetworking stuff, so that I enjoyed (after understanding the technology) learning a new thing :)

Amazing 2014

Hi Everyone,

It was long time since I haven’t writing for this Blog, many things happened for me in this year, 2014. First of All I want to thanks to Allah , that I’m now a part of Cisco Systems family, I Joined Cisco as a System Engineer.

The people in Cisco are passionate, highly motivated, and all of them are diligent, I’m very-very motivated in here ;)

I’m also glad to say that I’ve passed the CCIE-SP Lab exam several days ago, in Mobile Lab. It was my second CCIE Attempt. I watched the Incredible INE Video, understanding the fundamental concept and practicing the SP Workbooks (old version and the latest version), since the old one still contain a great resources such as QoS, Security (RTBH), Internet Access, Etc. I was Practicing the Full scale Lab, where lab 1-2 was a warming-up lab, since I could get above 80 on both lab on my First Attempt ;), Lab 3 was quite great, since it was becoming more complex, and finally Lab 4 was totally complex in limited gear fashion and there were so much restriction on the task requirement, CCIE Lab style, hehe.

After finishing the INE Workbook, I used the CCIE-SP Sample Lab Exam, which was available on the Cisco Partner Education Center (PEC), the lab task seems straight forward, but the devices were bigger L.

In My opinion, strategy to tackle SP is slightly different from tackling R/S, since in the SP everthing was related, from building your IGP/BGP/MPLS Backbone Infrastructure to delivering Services to Tier-2 and Tier-3 small SPs, so what I did in the exam were:

·         The first 60 minutes I read the task requirements carefully and making the Diagrams (there were a bunch of devices involved), making correlation between IPv4 & IPv4 IGP/BGP/MPLS related Task, keep track the RD, RT, and the related Routers, and finally make the aliases for both IOS & IOS-XR. I did this because once you nail the lab task requirement, the deeper you config the more you would lose sight of what may happened in your IGP/BGP/MPLS, so that was why I preferred to look the Big Picture and predict what could happened in the first 60 Minutes of reading & Drawing Diagrams.

·         I didn’t trust the Initial config, So I configure the whole IOS/IOS-XR config in every task requirements, eventhough it only mentioning about some expected result was not there.

·         I found bug on some feature, where I did the verification, I detected somekind ‘unidirectional’ status on my routers on one side but the other-side it was Ok, I try to shut and no shut the Interface, but it was still the same. The Only option for me was to reloading the GSR Box, but with that PRP in place, it could took 50-70 Minutes to booting up, So I just leave the task at it is, and I have to sacrifice some points >.<

·         I managed to finish almost all the task and still have 1.30 hours to did the re-verification on all the tasks I finished, and counting the points I had earned.

·         I used the tclsh to verify all the prefix could be reachable, but unfortunately you couldn’t do that on XR Box, I used manual method instead >.<

I Thought the result would be fast like R/S, but I just got it next morning, Since I was very tired and oversleep right after getting home. I opened up the OLSM, and Alhamdulillah I passed the Exams.

On short I’m very grateful from what God has given me, My Family who support me in this Journey, Mr. Himawan whom gave me Insight on Cisco Systems, and all of you.

Let’s do the Best in this amazing years.

Cheers ;)

CCIE R/S Troubleshooting Section Strategy

It's been a while since I had a long holiday :)

Well, I now entering the normal life, where 8-5 can make your dream come true, is it?!? :p

what I do now is focusing on my next project, which is Project 'S', where I have to spend my mind, strength, and time on it. yesterday I've attended the CCIE93 Dinner, with the other CCIE candidates, they are telling me that the Troubleshooting part of the R/S Lab exam is make them frustrated, not just because it was difficult, but Cisco put the two-hour troubleshooting session as an opener for the Lab Exam.

I had struggled with the TS part as well, so I try to find a way by mixing several method, and finally I have found Troubleshooting Strategy that fit for my Lab Style, I will show you guys what my TS Strategy to tackle the first 2 hour in the R/S Lab exam

First thing off is to read the guideline, this is very-very important, why? because the TS exam will have some restriction on it, make sure we can solve the trouble ticket without violate the exam rules, otherwise you will not get the score for that trouble ticket.

Prepare TS list can help you to track down your TS Progress, let say when you've read the first trouble ticket, and you think the ticket is very difficult, then you can write in the TS List, that you skipped the first ticket and you'll come back later on, in my case I used '!' mark to determine that this TS was difficult and I will come back later on. You can also write down what you've done in order to solve the ticket, so later on, when you have the time to re-verified your task, It will help you to determine that your solution was not violate the exam rules.

If you think the ticket is easy enough to be solved, and after 5 minutes you haven't solve it, I would say stop your progress, make a documentation about what you have done so far and MOVE ON to the next trouble ticket, you don't want to spend too much of your time on this ticket, otherwise you will get point for the specific ticket, but you will lose a lot of remaining time for another ticket. This is how we can managed the limited time in the R/S Lab exam.

By solving the easier ticket, it will build our confidence, if you have the confidence, your brain will work better, you may find something that previously you've stuck with the specific Ticket.

Note that this strategy is the one I used on my Lab exam, some of you may use this strategy and the other will see my strategy is not suited to their style.

In the End, you have to find your way to have the best strategy that fits you.

I hope that this have been informative and I'd like to thank you for reading ;)

Delivering Multicast Traffic on MPLS Enabled Network (MVPN)

MVPN is essentially a technique to enable the SP to send the multicast traffic data from the customer. In this example, I will use the Multicast Distribution Tree (MDT) in the MPLS core network to enable the multicast traffic pass through the MPLS Core network from the customer.

So the basic Idea of this technology is that PE will use its own multicast address to send the traffic to the other PE router. Note that this multicast address will represent one customer at the same time. This means that traffic from the customer that having source an Multicast sender and the destination of their own multicast address, let say 239.29.28.1, will then be encapsulated with an additional header, where the source of the traffic is the loopback address of the PE and the destination is the multicast address that is represent the customer, for this example, let say 239.0.0.1.

This 239.0.0.1 is only used for the MPLS Core network and it is not related to the customer, the customer may use the same multicast address J. With this approach, the SP can forward the customer multicast address inside the MPLS core network, how cool is that ;)

In general, there are 3 steps to deploy MDT, there are consist of:

1. Configuring Multicast support on the MPLS Core Devices
2. Configuring multicast support on the specific VRF
3.  Configuring BGP to use MDT

Let's take a look into the following scenario to get the better Idea of this MVPN Deployment :

• The Customer, under VRF VPN_A, want to use Multicast traffic using group 239.29.28.1, where, currently, the receiver is behind XR2.
• Using MDT, Configure the MPLS Cloud to supporting this customer requirement
• Note that XR1/XR2 using regular IOS
• The PEs (R2,R5,and XR1) are already being configured for MPLS L3 VPN to the Customer using OSPF as the IGP
• The CE’s is already being configured with basic PIM SM, where R1 is the RP using BSR, other switch, XR2 and SW1 will see the RP mapping after the configuration in the MPLS core is completed.

Note that in This Example, both XR1 and XR2 are using Regular IOS, not IOS-XR Software :p

1.  Configuring Multicast support on the MPLS Core Devices

This is straight forward, assuming that you guys are familiar with the Multicast configuration, where R4 will be act as a RP using BSR.

R2,R3,R4,R5,R6,XR1 ! Ip multicast-routing ! Interface loopback0  Ip pim sparse-mode ! Interface  Ip pim sparse-mode ! end

We should able to see that each one of them are adjacent with others

R4#show ip pim neighbor PIM Neighbor Table Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,       P - Proxy Capable, S - State Refresh Capable, G - GenID Capable Neighbor          Interface                Uptime/Expires    Ver   DR Address                                                            Prio/Mode 20.2.4.2          FastEthernet0/0.24       00:46:46/00:01:42 v2    1 / S P G 20.3.4.3          FastEthernet0/0.34       00:46:43/00:01:44 v2    1 / S P G 20.4.6.6          FastEthernet0/0.46       00:45:38/00:01:24 v2    1 / DR S P G 20.4.5.5          FastEthernet0/0.45       00:46:11/00:01:16 v2    1 / DR S P G

Then we will configure the R4 to be both RP-Candidate and BSR router

R4 ! ip pim bsr-candidate Loopback0 0 ip pim rp-candidate Loopback0 ! end

We can see from the MPLS router that they will know R4 as an RP

XR1#show ip pim rp mapping PIM Group-to-RP Mappings Group(s) 224.0.0.0/4   RP 4.4.4.4 (?), v2     Info source: 4.4.4.4 (?), via bootstrap, priority 0, holdtime 150          Uptime: 00:46:01, expires: 00:01:44

·    

       2. Configuring multicast support on the specific VRF

R2 ! ip multicast-routing vrf VPN_A ! interface FastEthernet0/1  vrf forwarding VPN_A  ip pim sparse-mode ! end

R5 ! ip multicast-routing vrf VPN_A ! interface FastEthernet0/1  vrf forwarding VPN_A  ip pim sparse-mode ! end

XR1 ! ip multicast-routing vrf VPN_A ! interface POS2/0  vrf forwarding VPN_A  ip pim sparse-mode ! end

Verification

R2#show ip pim vrf VPN_A neighbor PIM Neighbor Table Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,       P - Proxy Capable, S - State Refresh Capable, G - GenID Capable Neighbor          Interface                Uptime/Expires    Ver   DR Address                                                            Prio/Mode 10.1.2.1          FastEthernet0/1          00:46:44/00:01:19 v2    1 / S P G R5#show ip pim vrf VPN_A neighbor PIM Neighbor Table Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,       P - Proxy Capable, S - State Refresh Capable, G - GenID Capable Neighbor          Interface                Uptime/Expires    Ver   DR Address                                                            Prio/Mode 10.5.9.9          FastEthernet0/1          00:46:50/00:01:37 v2    1 / DR S G XR1#show ip pim vrf VPN_A neighbor PIM Neighbor Table Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,       P - Proxy Capable, S - State Refresh Capable, G - GenID Capable Neighbor          Interface                Uptime/Expires    Ver   DR Address                                                            Prio/Mode 10.19.20.20       POS2/0                   00:47:03/00:01:24 v2    1 / S P G

At this point, both XR2 and SW1 haven’t got any information about the RP

XR2#sh ip pim rp map PIM Group-to-RP Mappings SW1#sh ip pim rp map PIM Group-to-RP Mappings

 

    3.   Configuring BGP to use MDT

Now this is the brain of the MVPN feature

R2 ! vrf definition VPN_A  !  address-family ipv4  mdt default 239.0.0.1 ! router bgp 100  !  address-family ipv4 mdt   neighbor 5.5.5.5 activate   neighbor 5.5.5.5 send-community extended   neighbor 5.5.5.5 route-reflector-client   neighbor 19.19.19.19 activate   neighbor 19.19.19.19 send-community extended   neighbor 19.19.19.19 route-reflector-client  exit-address-family  ! end

R5 ! vrf definition VPN_A  address-family ipv4  mdt default 239.0.0.1 ! router bgp 100  !  address-family ipv4 mdt   neighbor 2.2.2.2 activate   neighbor 2.2.2.2 send-community extended  exit-address-family  ! end

XR1 ! vrf definition VPN_A  address-family ipv4  mdt default 239.0.0.1 ! router bgp 100  !  address-family ipv4 mdt   neighbor 2.2.2.2 activate   neighbor 2.2.2.2 send-community extended  exit-address-family  ! end

Now let see the verification from the MPLS side, from the vrf point of view, the router will have an adjacency to the CE routers and the other PE router that participate in the MDT

R2#show ip pim vrf VPN_A neighbor PIM Neighbor Table Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,       P - Proxy Capable, S - State Refresh Capable, G - GenID Capable Neighbor          Interface                Uptime/Expires    Ver   DR Address                                                            Prio/Mode 10.1.2.1          FastEthernet0/1          00:46:44/00:01:19 v2    1 / S P G 19.19.19.19       Tunnel2                  00:40:41/00:01:22 v2    1 / DR S P G 5.5.5.5           Tunnel2                  00:41:02/00:01:23 v2    1 / S P G PIM Neighbor Table Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,       P - Proxy Capable, S - State Refresh Capable, G - GenID Capable Neighbor          Interface                Uptime/Expires    Ver   DR Address                                                            Prio/Mode 10.5.9.9          FastEthernet0/1          00:53:17/00:01:34 v2    1 / DR S G 19.19.19.19       Tunnel1                  00:47:47/00:01:37 v2    1 / DR S P G 2.2.2.2           Tunnel1                  00:48:08/00:01:40 v2    1 / S P G XR1#show ip pim vrf VPN_A neighbor PIM Neighbor Table Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,       P - Proxy Capable, S - State Refresh Capable, G - GenID Capable Neighbor          Interface                Uptime/Expires    Ver   DR Address                                                            Prio/Mode 10.19.20.20       POS2/0                   00:47:03/00:01:24 v2    1 / S P G 2.2.2.2           Tunnel1                  00:41:32/00:01:32 v2    1 / S P G 5.5.5.5           Tunnel1                  00:42:01/00:01:32 v2    1 / S P G

The three PE router should have seen the 239.0.0.1 in their mroute, which this multicast address is representing a VPN_A customer, they should seen both (*,G) and the (S,G) for the specific group and PE Routers.

XR1#show ip mroute <…SNIP…> (*, 239.0.0.1), 00:49:06/stopped, RP 4.4.4.4, flags: SJCFZ   Incoming interface: FastEthernet0/0.619, RPF nbr 20.6.19.6   Outgoing interface list:     MVRF VPN_A, Forward/Sparse, 00:49:06/00:01:52 (5.5.5.5, 239.0.0.1), 00:49:05/00:01:29, flags: JTZ   Incoming interface: FastEthernet0/0.519, RPF nbr 20.5.19.5   Outgoing interface list:     MVRF VPN_A, Forward/Sparse, 00:49:05/00:01:54 (2.2.2.2, 239.0.0.1), 00:49:06/00:01:29, flags: JTZ   Incoming interface: FastEthernet0/0.619, RPF nbr 20.6.19.6   Outgoing interface list:     MVRF VPN_A, Forward/Sparse, 00:49:06/00:01:53 (19.19.19.19, 239.0.0.1), 00:49:06/00:03:26, flags: FT   Incoming interface: Loopback0, RPF nbr 0.0.0.0   Outgoing interface list:     FastEthernet0/0.619, Forward/Sparse, 00:49:06/00:02:33     FastEthernet0/0.519, Forward/Sparse, 00:49:06/00:02:37 (*, 224.0.1.40), 01:03:53/00:02:06, RP 0.0.0.0, flags: DCL   Incoming interface: Null, RPF nbr 0.0.0.0   Outgoing interface list:     Loopback0, Forward/Sparse, 01:03:52/00:02:06 R2#show ip mroute | inc 239.0.0.1                            (*, 239.0.0.1), 00:54:10/stopped, RP 4.4.4.4, flags: SJCFZ (19.19.19.19, 239.0.0.1), 00:50:38/00:01:22, flags: JTZ (5.5.5.5, 239.0.0.1), 00:50:59/00:02:49, flags: JTZ (2.2.2.2, 239.0.0.1), 00:54:10/00:03:26, flags: FT R5#show ip mroute | inc 239.0.0.1          (*, 239.0.0.1), 00:51:39/stopped, RP 4.4.4.4, flags: SJCFZ (19.19.19.19, 239.0.0.1), 00:51:18/00:02:39, flags: JTZ (2.2.2.2, 239.0.0.1), 00:51:39/00:02:26, flags: JTZ (5.5.5.5, 239.0.0.1), 00:51:39/00:03:11, flags: FT

R2#show bgp ipv4 mdt vrf VPN_A BGP table version is 4, local router ID is 2.2.2.2 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,               r RIB-failure, S Stale, m multipath, b backup-path, x best-external Origin codes: i - IGP, e - EGP, ? - incomplete    Network          Next Hop            Metric LocPrf Weight Path Route Distinguisher: 100:1 (default for vrf VPN_A) *> 2.2.2.2/32       0.0.0.0                                0 ? *>i5.5.5.5/32       5.5.5.5                  0    100      0 ? *>i19.19.19.19/32   19.19.19.19              0    100      0 ?

R2#show ip pim mdt bgp MDT (Route Distinguisher + IPv4)               Router ID         Next Hop   MDT group 239.0.0.1    100:1:5.5.5.5                               5.5.5.5           5.5.5.5    100:1:19.19.19.19                           19.19.19.19       19.19.19.19 R5#show ip pim mdt bgp MDT (Route Distinguisher + IPv4)               Router ID         Next Hop   MDT group 239.0.0.1    100:1:2.2.2.2                               2.2.2.2           2.2.2.2    100:1:19.19.19.19                           2.2.2.2           19.19.19.19 XR1#show ip pim mdt   * implies mdt is the default MDT   MDT Group/Num   Interface   Source                   VRF * 239.0.0.1       Tunnel1     Loopback0                VPN_A XR1#show ip pim mdt bg XR1#show ip pim mdt bgp MDT (Route Distinguisher + IPv4)               Router ID         Next Hop   MDT group 239.0.0.1    100:1:2.2.2.2                               2.2.2.2           2.2.2.2    100:1:5.5.5.5                               2.2.2.2           5.5.5.5

Now we can see that all the CE will got the RP information from R1

XR2#show ip pim rp mapping PIM Group-to-RP Mappings Group(s) 224.0.0.0/4   RP 1.1.1.1 (?), v2     Info source: 1.1.1.1 (?), via bootstrap, priority 0, holdtime 150          Uptime: 00:53:12, expires: 00:01:43 SW1#show ip pim rp mapping PIM Group-to-RP Mappings Group(s) 224.0.0.0/4   RP 1.1.1.1 (?), v2     Info source: 1.1.1.1 (?), via bootstrap, priority 0, holdtime 150          Uptime: 00:53:25, expires: 00:01:28

And now, if we specified a traffic from the CE, it would succeed

XR2 ! interface FastEthernet0/0  ip igmp join-group 239.29.28.1 ! End R7#ping 239.29.28.1 rep 5 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 239.29.28.1, timeout is 2 seconds: Reply to request 0 from 10.8.20.20, 468 ms Reply to request 1 from 10.8.20.20, 316 ms Reply to request 2 from 10.8.20.20, 272 ms Reply to request 3 from 10.8.20.20, 264 ms Reply to request 4 from 10.8.20.20, 340 ms

If we verified the mroute table on the XR2 we could see that the source of the traffic is 10.1.7.7

XR2#show ip mroute 239.29.28.1 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, E - Extranet,        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,        V - RD & Vector, v - Vector Outgoing interface flags: H - Hardware switched, A - Assert winner  Timers: Uptime/Expires  Interface state: Interface, Next-Hop or VCD, State/Mode (*, 239.29.28.1), 00:52:56/stopped, RP 1.1.1.1, flags: SJCL   Incoming interface: POS2/0, RPF nbr 10.19.20.19   Outgoing interface list:     FastEthernet0/0, Forward/Sparse, 00:52:56/00:02:59 (10.1.7.7, 239.29.28.1), 00:00:49/00:02:10, flags: LJT   Incoming interface: POS2/0, RPF nbr 10.19.20.19   Outgoing interface list:     FastEthernet0/0, Forward/Sparse, 00:00:49/00:02:59

If we take a look on a packet level, we could see that the traffic from R7 to the 239.29.28.1 to the XR2 will be encapsulated in the MPLS Core

Note that using MDT, the customer multicast packet is not using Label Switching as a transport mechanism in the MPLS Core. Other option are now available, to optimize the multicast forwarding using MPLS.

It is indeed a cool stuf ;)

I hope that this writing would be informative, and I’d like to thank you for reading ;)