Cisco IOS Multicast History

10 years of Cisco IOS Multicast History

1994 Pimv1,SM/DM,IGMPv1/2,DVMRP
1995 Fast Switching,SAP/SDR,PIM,IGMP,Cisco IP Mroute,Mtrace,NBMA Mode
1996 AuroRP,CGMP,CMF
1997 MDFS,RFC 2337 ATM MPS
1998 PIMv2,BSR,MBGP,MSDP
1999 MMLS,Tunnel UDLR,Multicast NAT,Multicast Tag Switching
2000 SSM,PIM Bi-Dir,MSDP MIB,Heart Beat,IGMP Snooping,IGMP Mproxy Route
2001 Cisco Pim Traps,MSDP SA limits,
2002 MVPN/VRF Lite,
2003 IPv6 Multicast,Netflow v9 Multicast,PIM Snooping
2004 RPF Vector,Inter-As MVPN,MVPN MIBS,SSM Filtering,IPV6 Multicast New Features


regards
shivlu jain
Click Here To Read Rest Of The Post...

Trans Atlantic Gateway links are down

Given update is forwarded to us by Guru Prasad.

Kindly find the latest update from TATACOM.

Current Status:

This mail is in continuation to our earlier mails updating you on the network outage faced due to three cable systems, SMW4, SMW3 and FLAG being affected by seismic activity in the Mediterranean, 1861 KM from Alexandria Cable Station in Egypt towards the Palermo and Mazara landing stations in Italy.

Typically the restoration of traffic is done by restoring SMW3 on SMW4 and vice versa. Similarly capacity on FLAG is restored through SMW3. Considering the severity of impact we are not in a position to restore all traffic through the Cable Consortiums.

TATA is exploring all options to restore traffic through other cables between India to Singapore and India to Europe. This requires extensive coordination with various cable stations and cable administrations to create the additional routes and activate the capacity.

We have started to restore several circuits using our South East Asia to Japan systems and onward across the Pacific Ocean to the US and the UK. While our teams are working with all urgency to implement additional capacity, we do expect that these efforts will continue to take a considerable amount of time.

Complete repair and restoration of the underlying cable system faults, will take a considerable period of time.

SMW4/ SMW3

SMW4 - As per latest updates from the consortium Cable ship Raymond Croze is expected to reach on cable ground at 17:00 UTC / 29th December, 2008 to attend to the fault identified 387.487 kms from Alexandria. We expect the repairs to be completed by 4th Jan 2009 subject to weather conditions on the seabed and the cable.

SMW3 - As per updates from the consortium Cable ship Teliri will be repairing the SMW3 S8.8 FP 2 cable fault after it completed the FLAG Segment D Fault scheduled to completed by 29th Dec 08.

Flag - Cable ship Teliri has been mobilized for repairs. We expect the repairs to be completed by 29th Dec 2009 subject to weather conditions on the seabed and the cable.


Kindly find the latest update from RCOM.

FEA Subsea Cable System of Reliance Globalcom has major failure on Segment D on 19 December 2008 at about 08:06 GMT.

The cable fault appears to be approximately 1892km from Alexandria [44.260km from Repeater 4 (R4) towards Repeater 3 (R3)].

Current status:

The final splicing activity is on at this time and COTDR testing will be commenced soon. The cable system is expected to be up by on or before 18:00 GMT 29 December 2008.

We will continue to keep you updated on the progress.


regards
shivlu jain
Click Here To Read Rest Of The Post...

Assert Messages In Multicast

Assert messages are used in multicast multiaccess network to stop the duplicate streams. When the same stream is being received by two interfaces from the same source they share the assert messages and on the basics of metric value one can be forwarder and another will be pruned. But if the both links are having equal metric value then on the basics of higher loopback address election takes places and will become the forwarder and DR.


regards
shivlu jain
Click Here To Read Rest Of The Post...

Cisco Published Annual Security Report Of 2008

At the end of 2008 cisco has published the annual security on 18th december.

Key Findings from Cisco
This year's report reveals that online and data security threats continue to increase in number and sophistication. They propagate faster and are more difficult to detect.


Key report findings include:

a) Spam accounts for nearly 200 billion messages each day, which is approximately 90 percent of email sent worldwide.

b)The overall number of disclosed vulnerabilities grew by 11.5 percent over 2007

c) Vulnerabilities in virtualization products tripled to 103 in 2008 from 35 in 2007, as more organizations embraced virtualization technologies to increase cost-efficiency and productivity

d)Over the course of 2008, Cisco saw a 90 percent growth rate in threats originating from legitimate domains; nearly double what the company saw in 2007

Click here to get the report


regards
shivlu jain
Click Here To Read Rest Of The Post...

Hierarchical Provider Edge In Cisco

HoPE is hierarchical provider edge which is being offered by Huawei. From one of the blog I find the word and one the guy was asking whether cisco is providing the same or not. Given below is the explanation & working of HoPE. But one cannot say that cisco is not providing the HoPE that is some different concept in cisco how you can have the service.
The equipment directly connected with the user is called UPE (Underlayer PE, or User-end PE), while that connected with UPE and located in the network is SPE (Superstratum PE, or Service Provider-end PE).
The HoPE is the same as the traditional PE when viewed from the outside, so it can exist together with other PE's in the same MPLS network.
The HoPE network enables the MPLS VPN network to expand unrestrictedly via the hierarchical PE nesting and supports any levels of the MPLS VPN network. For example, the original network can be divided into two levels: the SPE and the UPE. As the services develop, it can have three levels: an SPE, an MPE (middle PE) and a UPE. PE's at all levels can connect users.
The UPE is used for user access. It only maintains the VPN Site routes directly connected instead of the need to maintain other remote Site routes. The SPE is used for VPN route maintenance and flooding. It needs to maintain all the routes of the VPN connected to its subordinate UPEs, including routes of the local and remote Sites.
The role division of SPE and UPE embodies the characteristics of PEs at different levels: The SPEs have routing tables of large capacities and powerful forwarding capabilities, but few interface resources; while the UPEs have low routing and forwarding capabilities, but their quantity is big, they have powerful access capabilities and can be connected nearby. HoPE fully utilizes the performance capability of SPE and the access capability of UPE.
Please note that UPE and SPE are two relative concepts. In the architecture of multiple PE levels, to the lower level, the upper level is SPE, while to the upper level, the lower level is UPE.
Protocols running between SPE and UPE include MP-BGP, MP-IBGP and MP-EBGP, whose application depends on whether the SPE and the UPE are in the same AS.
When they are in the same AS, the MP-IBGP protocol is adopted. The SPE serves as the route reflector for multiple UPE's but may not do so for other PE's. To reject routes that are from other PE's and do not belong to the site connected with the PE at this level, the SPE shall create a global Import route-target list based on the Import route-target lists of all VRF's of all the UPE's to filter out the routes from other PE's. The global list can be dynamically created based on the information exchanged between the SPE and UPE, or be statically configured.
When the SPE and UPE do not belong to the same AS, the MP-EBGP protocol is adopted. Similarly, the SPE needs to create a global import route-target list. Generally, the UPE shall use the private autonomous system number. When distributing routes out to other PE's, the SPE omits that number.
The VRF default route distributed by the SPE to the UPE can be dynamically generated or statically configured. The dynamic VRF default route should be generated by the VRF corresponding to all the sites connected to the HoPE and be distributed to all UPE's. When distributing the route, the ORF (Outbound Route Filter) can be used for filtering.
For the dynamic global list generation, the UPE sends an ORF message via the Route Refresh message of BGP to the SPE. The ORF message contains an extended community list, whose contents are the combination of the import route-target lists of all the VRFs on the UPE. The SPE merges all the UPE extended community lists to form a global list. The generation rule of static list is the same as that of a dynamic list.
Like in HoPE a SPE is deployed centrally and all the small or low end routers deployed at customer premises. The entire routing table corresponding to the vrfs installed in SPE. In Cisco this can be achieved by using the two interfaces looped with each other. You can deploy a 7600 or 7200 at central place and make two interfaces loop to each other. One physical interface will be part of routing domain. Now at the remote end deploy a 1800 or even any low end router. Terminate your client link on router and originate a xconnect and drop it to the one of the looped interface. Now on another loopinterface create the vrf interface. This all be done by creating the sub interfaces on loped interfaces. By doing this you can achieve the HoPE in cisco also & save your lot of cost.


regards
shivlu jain
Click Here To Read Rest Of The Post...

Weird RR Problem: What can happen if Route Reflector(RR) is not getting proper route updates?

From the last few days we were facing a problem with route reflector server which was not receiving proper routes from its clients. Think for a while if you were managing a service provider or immense enterprises network with multiple route reflectors in the domain and a day you come to know that one of your route reflector is not receiving the full route updates from its clients. What you will do that time? Might be look for an expert who is having good knowledge of route reflectors, bgp & mpls. But till the time network will be black holed. In this post I am giving the workaround for the problem which can be tried on imperative basics.
I will let you know a scenario in which you may face another type of problem. Assume you are having service provider domain with two route reflectors in the domain. Every PE is having peering with both the route reflectors. The route reflector you are using for both ipv4 as well as for vpnv4 routes. At any point of time both route reflectors will advertise the route advertisements to every PE. But PE will select the one out of them as best and another will be used if anything would go wrong with the first one.
In the figure I made a scenario which explicitly tells about the service provider network with MPLS in the core. Every PE is having a connection with both route reflectors. Client is VPN A and having three locations across the service provider cloud. On CE1VPNA location client is having internet for that it is imposing a default route towards the vrf and service provider is advertising that route in all the VPNA vrf. On PE1 if we verify the any route of remote location we will be getting two entries with next hop loopback of PE2 and both the routes will be advertised by both RRs and only one will be shown as best. In this case RR1 route is the first preferred route if RR1 goes down then RR2 route will be preferred. We assume at point of time PE2 advertises the routes to both RRs but RR2 is getting the proper updates. On RR2 only 10.1.2.0/24, 10.1.3.0/24 & 0.0.0.0/0 route is coming and it is advertising the route to all the PEs. At any point of time if RR1 goes down and the same time CE3 wants to reach CE2 lan. CE3 will forward the packet to PE1 and on PE1 the above three routes will be installed. But CE3 wants to reach 10.1.1.0/24 which actually is not available so it will go to the default route and traffic may be black holed any time.
Cisco commands which can be used for checking the vpnv4 route is cited below
Show ip bgp vpnv4 all summary
Show ip bgp vpnv4 rd x:y neighbor routes
Show ip bgp vpnv4 rd x:y neighbor advertise routes
On both RRs you can check the installed routes.

Workaround:-
This is nothing but the cisco bug. In this case you need to check IOS. A part from this you can clear the full bgp neighbourship or reload the router. After that it receives the full routes.
So if you see your traffic behaving abnormally then check your route reflectors updates first. The reason for writing this post because I faced the same problem and it is not a test lab scenario.

regards
shivlu jain
Click Here To Read Rest Of The Post...

FEC in traditional IP routing and MPLS

In my FEC post I describe the basic working of FEC. In MPLS it’s always said FEC is performed only at the ingress time but in traditional ip cloud it does at all the hops which requires more cpu processes and memory for the routes. During the reading of Jeff Doyle chapter second I saw a good explanation of FEC. Excerpt from Jeff Doyle TCP/IP Routing Vol 2 – Chapter 2
“Here is where things go wrong. Provo does a route lookup for 196.223.18.0/24 and sees that the network is reachable via Salt Lake. It then does a lookup for Salt Lake's IP address and sees that it is reachable via the next-hop router, Ogden. So the packet destined for 196.223.18.0/24 is forwarded to Ogden. But the external routes are shared between Salt Lake and Provo via IBGP; the OSPF routers have no knowledge of the external routes. Therefore, when the packet is forwarded to Ogden, that router does a route lookup and does not find an entry for 196.223.18.0/24. The router drops the packet and all subsequent packets for that address. Traffic for the network 196.223.18.0/24 is black-holed.
Of course, if the OSPF routers know about the external routes, the situation just described will not happen. Ogden will know that 196.223.18.0/24 is reachable via Salt Lake and will forward the packet correctly. Synchronization prevents packets from being black-holed within a transit AS by an IGP with insufficient information.”

The lines in bold explicitly states that on every hop IGP checks for the external routes in the routing table & forward the packets correctly, if the no routes in the IGP routing table the packets would be dropped. It means FEC is performing at each and every step in traditional ip routing but not in MPLSVPN case because here the FEC is performed only at the ingress after that only labels are swapped that’s why the core routers doesn’t require the information of external routes. If FEC were being in MPLS also then core routers couldn’t forward the traffic without the knowledge of external routes.

Remember one thing when one talk about FEC, it means he is talking about the route lookups, next hop adjacency, longest prefix match in one algorithm. The algorithm is called on every hop in traditional ip routing but called once in MPLSVPN routing.


regards
shivlu jain
Click Here To Read Rest Of The Post...

How CEF understands overlapping of ip addresses ?

Yesterday I was reading Jeff Doyle TCP IP/Routing and got a overlapping problem. In that Jeff Doyl explained how BGP selects the best route in case of overlapping. The excerpt is given cite

“A BGP-speaking router can transmit overlapping routes to another BGP speaker. Overlapping routes are nonidentical routes that point to the same destination. For example, the routes 206.25.192.0/19 and 206.25.128.0/17 are overlapping. The first route is included in the second route, although the second route also points to other more-specific routes besides 206.25.192.0/19.When making a best-path decision, a router always chooses the more-specific path. When advertising routes, however, the BGP speaker has several options for dealing with overlapping routes:”

In the above excerpt jeff has explicitly cited that route always choose more-specfic path but BGP has many options for dealt. But the question comes in mind how router process the overlapping of routes because now-a-days cisco routers are using CEF, it means all the routing information stored in FIB which is forwarding information base.

Without wasting any time let’s see how the information is stored & processed by FIB in case of overlapping of ip addresses. CEF will create the table given in figure for storing the prefixes. As per the figure the first block is responsible till 191 & another block is responsible for rest of the prefixes. Only pointer will be used which will point towards the addresses.


regards
shivlu jain
Click Here To Read Rest Of The Post...

Multicast doesnot work with two loopbacks

Still I memorize the day when we were asked to give propose of multicast in service provider network for one of our esteemed client. The service provider client was using hierarchical route reflector design. A part from this one strange thing which we had seen that was two loopbacks were used. One loopback was used for BGP peering with route reflector server & another loopback was used for route-reflector client peering. Rest all the basics services were already deployed like layer 2 & layer 3 vpn etc.

Prior to this we had already designed multicast for service provider network. For multicast design we proposed BSR mode for rp advertisements. Network consists of 300+ routers and all were able to receive the rp updates properly. But as soon as the multicast stream started no router was able to receive the stream. After that we traced the rpf (reverse path forwarding) and aghast to see rpf was showing failure.
The next instant I replied this was the reason because we were using two loopbacks. But no one was satisfied with my answer. But after a day I proved myself right by showing them a document which explicitly shows that if you are using two loopbacks for multicast then you would not be able to receive the multicast stream.

What’s the reason why it happened so? Actual whenever the multicast peering is made it uses its loopback address for multicast group address update. It always replies with that loopback from which it receives the updates. But now in case of two loopbacks on single router one loopback is receiving the stream from the upstream router and for sending the stream another loopback is being used which forces rpf to fail. So the next time if you design the multicast network kindly check if service provider is using two loopbacks and both for bgp peering then you will not be able to implement multicast in that network.

Regards
shivlu jain
Click Here To Read Rest Of The Post...

OSPF Summary Issues

Few days back I was called up for a problem of area summary of particular region. Guys did the summary with the proper command on routers but they were unable to receive the summary prefix. After that I checked the routers and seem everything on right place but why the summary route was not originating towards the area 0. After that I asked them whether any other router in area 100 is having any connectivity with area 0. They replied me by saying one connectivity was there but that serial interface link was put in passive mode. It means only two direct connectivity with area 0.
The next question I asked them to show the diagram. From the diagram which is depicted as in Figure 1, I was aghast to see there were three ABRs but actually summary command was added only on PE1 & PE2. I asked a question whether the summary command was added on PE3 or not. I got no as answer which actually I was expecting from them. So the culprit was PE3 and as soon as the command was added, a summary route was received in area 0.
Then I was questioned why we need to give the summary command on PE3 also still don't have any direct connectivity with area 0? I replied, “You can do the summary only on the ABR (Area Border Routers)”. As per the figure you were having 3 ABRs so we need to do summary on all the ABRs which were coming in area 100.

Note: - Area summarization will always be done on ABRs which are present in that area whether they are having any direct or indirect connectivity with area 0. ABR is that router which is having one leg in area 0 whether that is direct or indirect leg.


regards
shivlu jain
Click Here To Read Rest Of The Post...

What will happen if you see your PE loopback in vpnv4 table

May be the next time you will be weird to see your PE loopback address in VPNv4 routing table. The first thought which comes in mind that how my PE loopback can be part of the VPNv4 routing table because this is the table which actually contains the information of all the VRFs. Is your PE is working as VRF? No, not at all then what’s the reason behind this.

Check the given output which I captured from the RR server.
show ip bgp vpnv4 all | i 10.10.254.197 (10.10.254.197 is PE loopback address)
*>i10.169.68.0/24 10.10.254.197 0 100 0 ?
*>i10.235.10.8/30 10.10.254.197 0 100 0 ?
*>i10.16.190.8/30 10.10.254.197 0 100 0 ?
*>i10.80.85.128/25 10.10.254.197 0 100 0 ?
*>i10.80.97.0/26 10.10.254.197 0 100 0 ?
*>i10.235.24.8/30 10.10.254.197 0 100 0 ?
*>i10.235.54.8/30 10.10.254.197 0 100 0 ?
* i10.176.1.40/30 10.10.254.197 0 100 0 ?
* i10.176.2.0/30 10.10.254.197 0 100 0 ?
*>i10.179.32.0/26 10.10.254.197 0 100 0 ?
*>i10.103.66.48/28 10.10.254.197 0 100 0 ?
*>i10.10.254.197/32 10.10.254.197 0 100 0 ?

You can see all the routes are getting with next-hop as PE address. But In the last line you can check the loopback entry is coming as VPNv4 route entry. Actually it should not come. Now the next question comes in mind may be loopback is redistributed in BGP, Go and check you will find it is advertised in IGP not in BGP.
After that I logged in PE router i.e. 10.10.254.197 and ran given the command

PE-Router# show ip bgp vpnv4 all
BGP table version is 176194, local router ID is 10.10.254.197
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 6x500:100
*> 10.235.2.8/30 0.0.0.0 0 32768 ?
*>i10.235.5.0/30 124.247.255.241 0 100 0 ?
*>i10.235.5.4/30 124.247.255.241 0 100 0 ?
*> 10.235.5.8/30 0.0.0.0 0 32768 ?
Route Distinguisher: 6x000:123
*>i0.0.0.0 10.10.254.205 10 100 0 ?
*>i10.240.5.0/30 10.10.254.205 10 100 0 ?
Route Distinguisher: 6x500:24
*>i10.235.1.0/24 10.10.254.1 0 100 0 ?
*>i10.235.1.32/30 10.10.254.1 0 100 0 ?
Route Distinguisher: 6x500:640*>i0.0.0.0 10.10.254.20 0 100 0 ?
*>i17.12.13.11/32 10.10.253.1 0 100 0 ?
Route Distinguisher: 2:6x500:100
*> 10.10.254.197/32 0.0.0.0 0 ?
*>i14.47.255.241/32 14.47.255.241 0 100 0 ?

In the above output you can see the last route distinguisher which is 2:6x500:100 explicitly showing 10.10.254.197 is locally originate route and automatically it is binding new RD. This RD is something different from others because it is carrying 2 which explicitly states that it is mdt safi or used for your MVPN traffic. After that I checked RD 6x500:100 which is actually binding to a vrf which is using multicasting. Now check there is one more route which is 14.47.255.241/32. I did the telnet and checked what’s belong to this route. Then I found a weird thing that the same MVPN client was configured on the router and 14.47.255.241 was the loopback address of the router.

By doing the above exercise I came to know two important things
1) From RR we can get total number of MVPN clients running on particular PE.
2) From particular PE we can fetch the information that where that particular MVPN is actually working.

You can do one more thing on RR check the "show ip bgp vpnv4 all" output of that PE where no MVPN is configured. In the output you will not get PE loopback address.


regards
shivlu jain
Click Here To Read Rest Of The Post...

What to ask from customer if he demands OSPF as PE - CE Routing Protocol

If your customer demands OSPF as PE-CE routing protocol then you require the folloing points need to be clarified from customer.

1) Area 0
If client is using area 0 then they need to extend area 0 up to SP PE. Authentication can be used as per client requirement.

2) Backdoor Link
If client is using backdoor link in that case SP link will always work as secondary. But if customer demands then SP link can be made primary by creating sham link.

3) Default Route At CPE End
If client demands for the default route at the CPE end then need to clarify one thing whether they are giving a default route from their HO to SP. If yes then SP can forward that link to the CPE by restricting the other routes.

4) Cost in OSPF
Client can use any cost in OSPF, SP will transparently forward that.

5) Multihoming Scenario
If customer is using two service providers out of which one is SP; In this SP cannot provide the automatic failover between links.

6) Dual link with SP
If customer wants redundancy from SP and need to terminate two links from two different SP’s POP, In this case client router will install two routes for outgoing but In SP cloud only one route will be preferred because RR will forward the advertisement to another PE with one best as next-hop. It means in SP cloud no load balancing will happen for client. So if client is using voice type of traffic then there might problem can occur. The best workaround is play with OSPF cost and make single link primary and another will work as secondary.


regards
shivlu jain
Click Here To Read Rest Of The Post...

Future Of VOIP

I found a good question of VOIP on searchunified.

Q:- I know that VoIP has already changed the telecommunications market and landscape considerably, but do you think it will continue to do so in the future? Where do you see the VoIP market heading in 2009?
A:- VoIP is far from done in terms of its market impact. While it has gained substantial awareness recently, by most accounts, VoIP's market share can only be measured in single digits. However, its underlying impact on the overall landscape has been much greater, and VoIP is now recognized as the de facto standard for where telecom is going.
The vast majority of new telephony systems and network investments are VoIP-based, and over the next few years, as the installed base of legacy telephony turns over, the market share for VoIP will rapidly increase. For business users, VoIP will continue to gain ground in 2009, and you will start to see it used in new ways.

For most of us, business VoIP means IP telephony, which is easy to tell by the growing presence of IP phones popping up on desktops these days. However, in 2009, you can expect to see VoIP being used more often in other areas as well. Three examples come to mind right away. First is web-based calling, which can take many forms. Making a voice call on Skype is one, and that's a form of VoIP. Another would be click-to-call applications embedded in web sites or your Outlook directory. A second example – related to this – is the use of softphones. This is a desktop application developed specifically to make VoIP calls from your computer, and will work wherever you have a broadband connection. The third example is mobility. While the market is not quite ready for mobile VoIP, business users are increasingly discovering ways of making these calls over WiFi with their smartphones. These devices are becoming much more popular – and affordable – now, and with that, you can expect to see a lot more mobile calling over WiFi in 2009.

You can view the article
Click Here To Read Rest Of The Post...

AnyCast RP Deployment

Anycast RP is used in multicast scenarios to load balance the RP messages. With the deployment of anycast RP have to configure the same ip address on all those routers which will participate as RP. After that MSDP peering is required so that source active messages can be exchanged easily. RP announcements can be send by implementing autp-rp or static RP. If your cloud is havinf all cisco routers then auto-rp is the best else go with BSR mode.


regards
shivlu jain
Click Here To Read Rest Of The Post...

When to use SPT threshold infinity

When to use spt threshold in network. As per my prevous post in which I explained explicitly that by default cisco use spt threshold as 0. It means always a SPT path is selected and S,G entry will be created. But lets say if you are running sghort of memory or having lot of multicast customers which use multicast for share trading. In thoses we donot need to create S,G entry. Indeed we can go with one *,G entry instead of multiple S,G entries. Now the question comes in mind is it a dense mode fallback becasue S,G is never created in dense mode. No its not a dense mode, its a pure sparse mode and you can set the ip pim spt threshold infinity command. By giving the command router will always create *,G entry no S,G entry will be created. So you problem of memory now elimates. But if you are using data mdt then you mvpn will never fall back on data mdt because data mdt requires S,G entry. So while giving the command make your mind first because data mdt will not work.


regards
shivlu jain
Click Here To Read Rest Of The Post...

CSRF attacks: Home DSL routers are vulnerable

Michael Kassner has written a article on CSRF attacks on tech republic. In the article he has explicitly mentioned how CSRF can have your email access remotely by any attacker. This attack is mostly found on DSL routers.
Click here to read full article.


regards
shivlu jain
Click Here To Read Rest Of The Post...

Case Study MVPN BSR Mode

I have tested the BSR mode in Service Proider network with auro-rp deployed at customer end. Kindly download the document for the same.



regards
shivlu jain
Click Here To Read Rest Of The Post...

Investing in Talent During Challenging Times

Even in an uncertain economy, it’s critical to invest in the development of employees. Organizations need to understand and plan for their changing IT needs, taking into consideration the development of personnel and their ongoing need for training. This training not only expands employee expertise and builds loyalty, but it also optimizes an organization’s competitive advantage during challenging times.

For more you can visit the link and make your self register asap.


regards
shivlu jain
Click Here To Read Rest Of The Post...

What is SPT & Shared Tree

In multicast we have shared tree and shortest path tree(SPT). Shared tree means alwasy your request will be processed by RP. It means whenever you want to reach any group you require to send your information to RP and RP will process it. In this type of scenarios *,G entry is created becasue you will not get the source address.
But in case of SPT a first *,G entry is created after that RP sends the group information to source and S,G entry is created. S,G means client knows which source is responsible for which multicast group. After that client can go to source with the help of local routing table. You can say RP is working as mediator first time and after that it comes out from the picture. But in case of shared tree it always works as mediator.
During design phase you have to decide which tree you are looking for. By default on cisco platform spt value is 0 means it will alwasy converge to SPT.


regards
shivlu jain
Click Here To Read Rest Of The Post...

Types Of BGP Tables

Till now we all believe that BGP is having only a single routing table where it used to store the routes and process for the best path calculation. But we all are mistaken here actually BGP maintains three table one for storing incoming routes from neighbours, one for sending the routes to neighbours and one for installing the routes where you actually find the routes with next-hop address. The tables are given below:-
a) Adj-RIB-in
b) Adj-RIB-out
c) Loc-RIB
Adj-RIB-in stores the unprocessed information received from its peers. Here the best path selection occurs as per BGP attributes and after conformation path is entered into the local bgp table i.e Loc-RIB. From the local RIB table it conform the next-hop address if it reachable by IGP then the route is entered into the main routing table.


regards
shivlu jain
Click Here To Read Rest Of The Post...

Magic Of TEE & Redirect Command

Today morning I received a mail from of my friend Deepak Arora who is persuing CCIE security with a very intersting command. The command name is Redirect & Tee which is being used by cisco routers to redirects or save the show config directly to any where.

e.g.

sh run | tee tftp://192.168.0.1/runconf.txt
show tech-support | tee tftp://192.168.0.1/techsupp.txt

You can also use redirect in the same way
e.g.
show tech-support | redirect tftp://192.168.0.1/techsupp.txt

regards
shivlu jain
Click Here To Read Rest Of The Post...

Implementation of Data MDT

Working of Data MDT has already been defined in recent post.
This post will actually cover the implementation of data mdt in network. Data MDT is configured under vrf. You cannot configured more than 256 addresses per vpn or vrf. One thing keep in mind during its implementation that data mdt range should be different from default mdt range while using auto-rp or bsr. If you are using the SSM then the data and default mdt can be same. This is the design problem with sparse mode.

Ip vrf Shivlu
mdt data 239.1.1.0 0.0.0.255 threshold 1

Threshold means that whenever the multicast stream will trigger more than 1 Kbps a data mdt will fire. You can say multicast tree will be constructed on demand.
Note:- Data MDT will be created only by the PE that has the source connected to it.
As i have already told we are having limited number of data mdts for particular vpn so we can re-use the addresses with the help of ref-count. Now the question comes which number will be used after 256. The data mdt addresses which are used least that number will be reused.

How to check the data mdt usage
“ Show ip pim vrf Shivlu mdt send “ command will help you to check the data mdt operation. In the output you can see the ref_count.
How to check data mdt is used for sending and receiving
Run the command “show ip mroute vrf Shivlu “ and in the output if you are getting the Y/y flag it means data mdt is working fine.


regards
shivlu jain
Click Here To Read Rest Of The Post...

How default mdt and data mdt works?

Prior reading to the this kindly have a look on Basic Of MVPN.

Default mdt is used by multicast tunnel in MVPN to carry customer multicast traffic. It is unique per vpn. By defining default mdt under every vrf a multicast tunnel interface establish with every PE. So in short we can it is a full mesh process by default. Cisco uses GRE tunnel for multicast interfaces tunnel and MTU is of 1514 bytes. You cannot edit and delete the tunnel interface until and unless delete the default mdt. Check the interface tunnel with show interface command you will be weird to see one thing the destination address will be the default mdt group address with source address loopback of the PE router. From this it is very much clear any default mdt which is being created for any vpn should be reachable in service provider with the help of loopbacks of PEs. Why loopbacks because they are used as next hop in MP-iBGP. It means default mdt will flood the multicast traffic on each and every multicast tunnel whether the multicast is required by the PE or not. So it means *,G entry is created and unnecessary flood of multicast traffic in network which can cause lot of unnecessary problems.
To overcome the problems originated by default mdt will be sorted out by using data mdt. By usinf data mdt we can set the rate limit of originating PE. If will send the message encapsulate in default mdt to every multicast tunnel by saying whether you required multicast stream or not. If PE responds with positive nature a S,G entry is created in the router. So the next time when the stream will come instead of sending the stream to each and every PE it will forward the multicast stream only to those which joins data mdt. It means it will check the S,G entry.
In short we can say default mdt always create *,G entry and data mdt always create S,G entry.


regards
shivlu jain
Click Here To Read Rest Of The Post...

Basics of MVPN

We are using ip multicast in the service provider network. But what about those service provider which are running MPLS. MVPN (Multicast VPN) is the one which is being deployed by service provider to transport customer multicast traffic over mpls backbone. Every customer is coming over ip cloud and has their unique multicast domain. For that domain customer wants to transport the multicast routing information along with rp information to another locations. Service provider MVPN network is responsible for forwarding customer multicast packets to another locations. All the multicast packets encapsulate at PE end and again de encapsulate at other PE end.

Now the hitch comes how the packet will encapsulate. For this we have concept of default mdt and data mdt. Default mdt is responsible for establishing multicast tunnel across all PE and should be unique per vpn. Data mdt is used for stopping unwanted multicast traffic across PEs. So we can say we have two multicast domain one is purely for customers and another is purely for service provider network. Remember one thing latter will be used for the reachability of default mdt. For example if we having a customer and default mdt is being defined, lets say i.e. 239.1.1.1. For the reachability of 239.1.1.1 we use the pim in service provider core. Now the next question comes in mind what should be the protocol in core because we have to forward the information of default mdt. Can we use auto-rp,bsr or ssm? Auto-rp, BSR is quite a good pim protocol but what will happen if we choose SSM? SSM requires IGMPv3 so don't implement SSM in core. Here most of time we are wrong because we are implementing SSM for default MDT group transportation not for multicast. So no need to worry you can implement SSM in the core. (SSM doesn’t require RP in the network)

So MVPN requires
PIM routing protocol in the SP core.
Default MDT and Data MDT (Default MDT is mandatory & Data MDT is not mandatory)


regards
shivlu jain
Click Here To Read Rest Of The Post...

Cisco Acheived Wimax Certification

A great news for sales & presales guys who are looking for wimax certified products. Recently cisco wimax products were added in wimax forum. The certification covered 2.5GHz spectrum, as that is the current focus of the forum so far - other spectrum such as 3.5 GHz will be included soon, with 2.3 and 3.3 GHz coming later.

Click here to check the certification status


regards
shivlu jain
Click Here To Read Rest Of The Post...

Eigrp adjacency issues with TLV

Approx 15 days back we changed the IOS of one of our PE 7200 router from 12.4(15)T to 12.4(22)T. After up gradation of IOS we faced weird problem of PE-CE eigrp. Every instant the eigrp neighbor comes up and goes to down. We collected the logs and forwarded to cisco. After few days cisco conforms that the IOS is having an eigrp bug in PE-CE. We changed the IOS & problem dissipate after up gradating to 12.4(11)T4.
Few days’ back one of my friend came up with the same problem but the ios used by them is other one. I don't know the name of the IOS. He was also facing the same PE-CE eigrp fluctuation. But as per him ios had not been changed or upgraded. He booked case in cisco and got reply from cisco.

Cisco Reply: when sending 10.x.x.x prefixes, the PE happens to combine them in such way, that resulting packet length is always under 1500;
- when 192.168.x.x are added, there appears a combination of TLVs, which results in length less than 1560, but more than 1500 thus jamming the update transmission.
Is this really true or false ? Still looking for relevant reply or solution.


regards
shivlu jain
Click Here To Read Rest Of The Post...