I live in a country where historically only one company was allowed to provide WAN servives. This restriction has been lifted the last couple of years, but it will still be many years until a 2nd or 3rd operator will have the infrastructure to provide any services.
Since government made this announcement, this company has moved more from a 'dictator' role into a 'customer satisfaction' role.
This has lead our company to make a multi-million investment into a MPLS VPN offering by this company, which will bring significant savings.
Even though this company is more 'customer orientated', I feel that the 'dictatorship' has not left:
1) We are not allowed to see any CPE confiugrations
2) We are not allowed to see any CPE utilization statistics (SNMP)
3) We are not allowed to mark packets accoring to our own QoS needs
So I plan a big fight with them on Monday, especially on (3). My question is, is this normal policy for SPs in the rest of the world, or are we still being worked over?
the rest of the world is actually not that much different: anything CPE-related is basically off-limits for mortal customers...
Regarding the QoS: usually, you have to request this, which I think is fair enough. If they would just take over all the QoS settings of all customers, obviously each customer would set his or her traffic to the highest priority. So I would think it is OK that the provider resets the QoS, and let´s you either pay for it, or agree with you on the parameters. The latter is usually not a problem with the ISPs I have worked for and with (Worldcom, BT, KPN), after all, you are the customer...
By the way, which country are you in ? I couldn´t tell from your name, it sounds French...
Nope, French name and surname but I live in South Africa. As far as I understand they 'only' mark packets on the CPE routers. The number of classes are purchased from the SP (4 in our case). We could certainly attempt to put all traffic in the highest priority class, but will eventualy starve that class and drop packets. The rest of the line will be underutilized, so we will be the ones who suffer (?)
just a few comments about the different statements:
1) there is no need for you to see CPE configs, if it is a bundled service. Just check whether they stick to whatever SLA you negotiate. It´s the service providers business and problem to fulfil them. As one BIG customer once put it: "I don´t mind if my SP burns my data on CDs and delivers them by flying witches across the country ... as long as they hold their SLAs!"
2) You do not really need SNMP access to the CPE. It´s nice though, I agree, but the SP might f.e. just be scared by security issues. You might nevertheless get access to the usage data provided by your SP. They could setup a secure Web server with MRTG graphs as an example.
3) This is also understandable. The SP has to setup a QoS domain. This means throughout his network (CPE to CPE, but especially backbone) he has to use a consistent Marking scheme for ALL customers. (assume a customer that insists on FTP being 5 and VoIP being 0 ... or any other value).
This implies usually that either you or the SP is remarking at the CPE or the device before/after the CPE.
There are some QoS tunneling scenarios especially with MPLS (pipe mode short pipe mode), but not every SP offers them.
So monitor your SLAs (f.e. with Cisco SAA, etc), setup penalties for SLA violations, try to get usage data through other means than SNMP access to the SP owned CPE and try to find a marking and remarking scheme that fits both of you.
The SLA you are mentioning is the primary problem we have. It is for this reason we want to be able to see the configs. We have had new sites installed where after major complaints about response it is discovered that QoS markings is not enabled on the CPE at all.
The SNMP access is really read-only to see line stats, the primary concern was the point made above.
The SP only marks packets on the CPE and will then probably enforce it on the PE. The 4 classes we have are split by percentage, so even if we put all in the highest priority class, it will be detrimental to us (?).
Hi, yup that is what I want to base my argument on, 'we are the customer'. I certainly do not want to introduce security concerns, so (1) and (2) I only mentioned because of previous problems we have had and was the first attempts in sorting out the problems. I just do not want to be in a situation where (3) is denied for no good reason.
I don't see why option 1 & 2 would be a security concern for the ISP, if this is a professional company, there is no reason why they shouldn't trust you. Infact you are trusting them to deliver your data through there network, in a secure maner. So why shouldn't they trust you not to reveal any confidential configuration parameters on the CPE router.
Denying (3) just sounds like denying for the purpose of denying. I mean they must have configured QoS limitations on the PE router, to avoid you having 100% of your traffic prioritized above anyone else through there network.
Actually quite well. They gave me 3 of the 4 DSCP values (number 4 is used for voice, they will not budge on that). So now I can mark traffic on a CAT switch and a compression device (Either Peribit or Expand). So I guess I will be happy for a while again :)
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...