Since now it is assumed that SB series is one of the trusted series for service provider network. But as per my experience this is one of the series which is having only 56 number of bugs in cisco site but actually is affected with those problem which one cannot think about. I am along with my colleages working on to the same and hopefully with in a day or two come up with the new issues.
Currently it is affected with mdt bug.
Workaround:- Simply remove the mdt configuration from vrf and add it again.
How to check:- Use the command "show ip pim mdt"
regards
shivlu jain
Click Here To Read Rest Of The Post...
Wednesday, February 4, 2009
Tuesday, February 3, 2009
Problem In Route Reflector Update
Introduction & Findings
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 document 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...
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
Show ip bgp vpnv4 rd x:y neighbor
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 document 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...
Monday, February 2, 2009
Upgradation of RR to MDT SAFI
How to upgrade the core router to MDT SAFI
To upgrade the core routers to mdt safi is one of the biggest challenge in service provider. Assuming SP is having two RR and every PE is having peering with them. A test bed is created with the given scenario given which is explicitly showing with some test cases and the outputs.
Basic Scenario
PE1, PE2, RR1 & RR2 are cisco 7200 with IOS 12.4 15T1
We have created a test vrf with default mdt for group 239.1.1.1. End to end multicast tunnel established.
Figure 1
Test Bed 1
In test bed one we upgraded the ios of PE1 to cisco 12.2 (31)SB13 series which supports the mdt features. But the route reflectors are still using the non standard mdt features. But we did not faced any issue after up gradation and route reflectors are receiving the mdt values from PE1 with extended community 2:65500:1.
Test Bed 2
In the second test bed we upgraded the ios of RR1 from 12.4 15 T1 to 12.2 (31)SB 13 series. After the boot up process completed we checked the mdt bgp values but did not find anything. So under bgp address family ipv4 mdt we activated the neighbourship of PE1. After that we checked the same on RR1 but did not find anything. Corresponding on RR2 we are receiving the values with extended community 2:65500:1 from PE2 not from PE1. There after we activated the neighbourship of ipv4 mdt on PE1 towards RR1. As soon as it get activated on RR2 was able to receive mdt bgp routes with no extended community. But still on RR2 routes are coming from PE2 only not from PE1. Then we activated the neighbourship of ipv4 mdt for RR2. After that we received the updates from PE1 to RR2 with extended community 2:65500:1. But RR1 is not forwarding the mdt safi updates to PE2. PE2 is only receiving the updates with extended 2 community from RR2. For this we need to activate the mdt for PE2. As soon as it is activated, PE2 is able to receive the routes from the both RRs.
Results:- If the PE is using mdt safi and route reflectors are using mdt safi & pre mdt safi in this case on PE you need to activate the ipv4 mdt for both the route reflectors so that PE can send the updates to RR1 with mdt safi and for RR2 it sends the update with extended 2:65500:1 community. In short we can upgraded RR1 is backward compatabile to the PE with respect to the mdt. Only one thing which we need to take is that to enable mdt safi for the non mdt PE.
Test 3
In this test bed we upgraded the ios of PE2 to 12.2 (31) SB13. After the boot up process we checked the values of mdt bgp but did not find anything. Then we activated the ipv4 mdt neighbourship of RR2 which is running on 12.4. 15 T1 ios. As soon as it came up PE2 is able to receive the updates from RR2. Ther after neighbourship of RR1 was activated and PE2 is able to receive the routes from RR1 also. The routes received by PE2 are without standard extended 2 community.
Result:- 12.4 15 T1 code was providing the backward compatibility with both. But if the RR is upgraded with 12.2 (31) 13SB series then it can send and receive the updates only to mdt group members not to non mdt group members.
If we are going to upgrade the ios of one route reflector and second will be running on non mdt safi code. In this type of scenario core routers will be getting the mvpn routes only from the non mdt safi RR. You cannot provide the redundancy. So the best is that first upgrade the PE routers there after upgrade the route reflectors.
regards
shivlu jain
Click Here To Read Rest Of The Post...
To upgrade the core routers to mdt safi is one of the biggest challenge in service provider. Assuming SP is having two RR and every PE is having peering with them. A test bed is created with the given scenario given which is explicitly showing with some test cases and the outputs.
Basic Scenario
PE1, PE2, RR1 & RR2 are cisco 7200 with IOS 12.4 15T1
We have created a test vrf with default mdt for group 239.1.1.1. End to end multicast tunnel established.
Figure 1
Test Bed 1
In test bed one we upgraded the ios of PE1 to cisco 12.2 (31)SB13 series which supports the mdt features. But the route reflectors are still using the non standard mdt features. But we did not faced any issue after up gradation and route reflectors are receiving the mdt values from PE1 with extended community 2:65500:1.
Test Bed 2
In the second test bed we upgraded the ios of RR1 from 12.4 15 T1 to 12.2 (31)SB 13 series. After the boot up process completed we checked the mdt bgp values but did not find anything. So under bgp address family ipv4 mdt we activated the neighbourship of PE1. After that we checked the same on RR1 but did not find anything. Corresponding on RR2 we are receiving the values with extended community 2:65500:1 from PE2 not from PE1. There after we activated the neighbourship of ipv4 mdt on PE1 towards RR1. As soon as it get activated on RR2 was able to receive mdt bgp routes with no extended community. But still on RR2 routes are coming from PE2 only not from PE1. Then we activated the neighbourship of ipv4 mdt for RR2. After that we received the updates from PE1 to RR2 with extended community 2:65500:1. But RR1 is not forwarding the mdt safi updates to PE2. PE2 is only receiving the updates with extended 2 community from RR2. For this we need to activate the mdt for PE2. As soon as it is activated, PE2 is able to receive the routes from the both RRs.
Results:- If the PE is using mdt safi and route reflectors are using mdt safi & pre mdt safi in this case on PE you need to activate the ipv4 mdt for both the route reflectors so that PE can send the updates to RR1 with mdt safi and for RR2 it sends the update with extended 2:65500:1 community. In short we can upgraded RR1 is backward compatabile to the PE with respect to the mdt. Only one thing which we need to take is that to enable mdt safi for the non mdt PE.
Test 3
In this test bed we upgraded the ios of PE2 to 12.2 (31) SB13. After the boot up process we checked the values of mdt bgp but did not find anything. Then we activated the ipv4 mdt neighbourship of RR2 which is running on 12.4. 15 T1 ios. As soon as it came up PE2 is able to receive the updates from RR2. Ther after neighbourship of RR1 was activated and PE2 is able to receive the routes from RR1 also. The routes received by PE2 are without standard extended 2 community.
Result:- 12.4 15 T1 code was providing the backward compatibility with both. But if the RR is upgraded with 12.2 (31) 13SB series then it can send and receive the updates only to mdt group members not to non mdt group members.
If we are going to upgrade the ios of one route reflector and second will be running on non mdt safi code. In this type of scenario core routers will be getting the mvpn routes only from the non mdt safi RR. You cannot provide the redundancy. So the best is that first upgrade the PE routers there after upgrade the route reflectors.
regards
shivlu jain
Click Here To Read Rest Of The Post...
Subscribe to:
Comments (Atom)