OK Im going to be connecting 2 sites and want to make sure I do it as redundant as possible with what I have for equipment and connectivity. So here is what I have for hardware and connectivity.
Site 1:
2 - Cisco 3845's
1 - DS-3 to MPLS cloud
1 - 100MG optical Ethernet
Site 2:
2 - Cisco 3845's
1 - pair of Multilink T'1's to MPLS Cloud (3MG)
1 - 100MG optical Ethernet.
So in summary the sites are connected by the 100MG optical (obviously primary choice) and thru the MPLS where the bottleneck is the multilink but its for redundancy and its all I have. The MPLS uses BGP and I'm not sure what if any is being handed to me by the metro optical company for routing protocols. Regardless the two are two WAY separate companies and there is no way I can do BGP across them.
Right now as it sits my plan is to use HSRP on the 3845's at each site on the LAN.
Site 1:
RTR1 - the 100MG optical Ethernet terminates here
RTR2 - the ds-3 to the MPLS terminates here
Site 2:
RTR1 - the 100MG optical Ethernet terminates here
RTR2 - the Multilink terminates here
I'll then track the interface on the router
So on RTR1 at each site I'll track the interface that the optical Ethernet comes into (Gi0/1 respectively). If it goes down RTR2 will become the active router for HSRP.
How does this look? Anyone see any improvements or if you have a better solution scrap and rebuild with what I have or for little more cost?
Now a secondary here: For redundancy the people that are providing the metro optical Ethernet interface say they can provide us a redundant connection at each end for little cost. So rather than them handing me 1 Ethernet cable they would hand me two which would go upstream to redundant equipment. Right now I have the two Ethernet interfaces on the 3845s. One goes to the LAN and one goes to the Metro Optical. How could I make this redundant within the router? Is there another vwic for a gig card that I can add another Gig interface and create a multilink out of them? Then I could track the multilink?
Also is there a way to better track the connection. I mean in order for the tracking to work the interface has to go down. On a serial interface on a circuit terminating to a router this would be somewhat valid BUT the chances of the switch connecting to my router being the cause of the outage are not as great as something else on the optical Ethernet (in the cloud if you will). So can I somehow track the directly connected router from the other site and if I lose connectivity to that cause the failover.
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Save solutions to your questions, answers you’ve discovered through searching plus helpful articles in your personal knowledgebase for easy future access.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.
Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
OK i guess i'm a bit confused. Why do I need the GRE tunnel? I presume in my case it would go from RTR2 to RTR2 over the MPLS. But why? Wouldn't this just put overhead on that connection and use resources? If this was the case wouldn't I also need a GRE tunnel over the Metro optical? I'm already using bgp with the given param's from the MPLS company as its required to some degree.
Yes, it will introduce some overhead but in this case you don't need to redistribute your internal routing to BGP. If you have more then two sites, just disregard it. If it's a connection between two points using MPLS as a transport then GRE will hide all the routing details and your MPLS carrier will see just a connection between your CE equipment. I run a multisite network over MPLS and had to create some complex redistribution configuration in order to avoid conflicts and routing black holes. GRE makes it a lot easyer if number of sites is less the 5.
Ahh ok so yes untimatly I'll have 5 sites on the mpls including these listed as site1 and site2 above. The two sites in question are the most important if you will and thus the redundancy but all sites will need connectivity to eachother. SO in this case? Do you think I should implement my own Routing protocol on the Metro optical ethernet and redistribute the bgp into it? Then still use the HSRP? Also what about the redundant links from the Metro optical ethernet company? Granted they are the same company BUT they are redundant as in the upstream equipment isn't the same. I mean they are not handing me to cables that come from the same switch. Its all redundant up the path. Is there a way to incorperate this into RTR1 at both sides?
I don't see any major issues, you have just great resourses for your network. HSRP will take care of maintaining a single gateway for your endusers. And routing protocol will find their way to each of the remote sites.
Let's say, typical exaple:
Your network uses OSPF for internal routing and you don't want to have anything from MPLS in your internal routers which are not conneted to it.
!this will maintaing internal routing
router ospf 1
router-id 192.168.1.1
! this will forward your OSPF routes over BGP to the other side but filter internal MPLS routes
redistribute bgp 100 route-map MapNets
network 192.168.1.0 0.0.0.255 area 0
network 192.168.2.0 0.0.0.3 area 0
default-information originate
!this for MPLS most likely details given by carrier
router bgp 100
no synchronization
bgp log-neighbor-changes
redistribute connected
redistribute static
redistribute ospf 1 match internal external 1 external 2
neighbor xx.xx.xx.xx remote-as 1000 ! AS assigned by carrier
default-information originate
auto-summary
! This filters internal MPLS network which you want to hide from the rest of your network.
ip prefix-list IntNets seq 5 permit 192.168.0.0/16
ip prefix-list IntNets seq 10 deny xx.xx.0.0/16
OK so I would want to redistribute my internal routing protocol into the BGP on the mpls but not allow the MPLS bgp to redistribute into my internal routing protocol? So if the metro optical went down how that router know about the other route via the MPLS if I dont allow the bgp to redistribute in?
And again what about the multiple network connections to the metro optical? How can i leverage that redundancy?
The trick is that border router will know about all networks, but will not tell anybody about it. If something will go down then 1. Interface will go down and this particular router will stop advertising remote networks redistributed over BGP. 2. As soon as interface will turn to down state, the router will start using existing alternative routes.
Regarding your second ethernet.
1. You can balance load and use both.
2. You can increase metric on one of them and and router will use it when primary link is not available or overloaded.
So if i have 2 routers with the HSRP facing my LAN. One of those routesrs connects to the mpls using bgp and one connectds to the metro optical using say eigrp. By default then wont the routing use bgp as its lower ad? I'm a little confused about how this will work once I get the redistribution of bgp into the eigrp.
In your BGP router config
(config-router)#redistribu
adjust it so fiber will take presedence
For pair of sites it will work this way:
eigrp-> 1-RTR1 ->BGP (carries routes redist. from eigrp ) -> 2-RTR1 -> EIGRP (filter all BGP)
| |
HSRP HSRP
| |
eigrp-> 1-RTR2 ----------------> EIGRP---------------------
The same apply for more sites
Ok last clarification so up above you have me redistributing the bgp into the ospf and ospf into bgp. I presume this is the same then if i was to use EIGRP. Have to redistribute the EIGRP into the BGP and the BGP into the eigrp and then make sure they are weighed accordingly so the right path is chose? Basically asking do i need to redistribute both protocols into eachother?
Yes.
EIGRP needs to be redistributed to BGP because MPLS network will need to know what to do with packets with source and destination addresses from YOUR network.
BGP needs to be redistributed to EIGRP because it carries information about routing from other EIGRP site redistributed to BGP. It's recommended to filter internal MPLS routing because hosts in your network don't need to know how to reach internals of MPLS network. This will allow you to avoid IP addresses conficts when you use more then one MPLS or other private IP network carrier with the same address space.
When you configure everything and get everything connected type "ip route" on RTR1 and RTR2.
Then simulate different problems and adjust metrics for redistribution.
You can even balance your network that way so it will use all the available connections. So if ethernet will become conggested for any reason the routers will start sending packets over slower links.
Business Accounts
Answer for Membership
by: tvman_odPosted on 2007-09-18 at 11:47:51ID: 19915549
Two redundant links from the same company kind of defeats the purpose. All the major issue in their network will affect both links. So your case is pretty good one. You can create a GRE tunnel with internal IPs on both ends over MPLS and use BGP with given parameters from MPLS company. Use HSRP for RTR1 and RTR2 on each site. Then use static or any other routing protocol and adjust a metric parameter. In most cases Ethernet will take presedence bu default, but it's a good idea to take some additional steps.