I am looking for an example from a service provider point of view how multichassis operate.
Imagine two locations both served by a 5350 Access Server. Between the 5350 is a VLAN running the SGBP bidding protocol.
The service provider runs two PRIs to each location. One phonenumber is associated with the four PRIs.
How does the call setup work? If both 5350s are available, do the call setup message reach both routers? Or is there a mechanism on the CO switch that governs the call setup to one of the 5350s.
What happens when the 5350 on location A has a higher bid but the PRI interface(s) is down. Is there a mechanism in place that functions like interface tracking for HSRP/GBLP does?
Any information would be helpful. However I have studied all the documents on Cisco.com.
Many thanks in advance.
Have you read this document, including the restrictions on the use of these protocols?
My understanding is that commo to each of the access servers from the dial in client is established with a normal telco hunt group. Once you have connected to either of the systems in the stack, they will communicate with the primary system containing the dialer interface via Layer 2 Forwarding. By the way, in the xample above, are their two or four PRIs? The telco should be able to set up one hunt group that will access either two or four PRIs. Call setup will initially occur on one router. Communication is passed via L2F for subesquent calls to alert other routers in the stack who is handling the call for the user who already dialed in.
As far as how does the system know when to pull out a bad interface, my understanding is that since the interfaces that are dialed into are virtual interfaces, they will rely on the real interface status reporting on whether to bind the virtual interface to the real interface. For example, if you have twelve configured BRI lines and number 10 is shot, the status reported on that interface should be "down and down". As such, I would expect the dialer rotary group to not use that interface. OTOH, if the status is reported on 12 separate asynch lines as "up and up", but line nine has a bad external modem, I would not expect the virtual interface to know this. In that instance you will start to see problems. Ultimately, you would have to test this all in a lab first before you rolled it out into production.
Paul, first off I would like to thank you for your reply.
There are four PRIs in total. Two of them lead to location A, two to location B.
Your reply is very helpful for my understanding.
I was going to send another link from pete Welcher that seemed to expand upon the detail. It was talking to setting up a working lab to enable this feature and see exactly what the bugs were. For Pete, this link was in prep for the CMTD class (forerunner to the current BCRAN class):
I am just not sure if he ever got it up and running and what all of the issues were/are. He should still be at Chesapeake netcraftsmen, he made be able to shed more light on this. I believe the key to fully working it all out is to test the setup in a lab and gather packet captures to see the protocols at work and see/discover what issues/limitations exist with Cisco's iplementation.