Can someone help me understand Transit vs Peering vs Customer in port descriptions?

[galgier]

I have a Cisco switch at the edge of the network in our data center. It has two links each to two different ISPs.
If I use:
interface G1/0/1
desc Cust: Verizon (link 1)
interface G2/0/1
desc Cust: Verison (link 2)
interface G1/0/2
desc Cust: ATT (link 1)
interface G2/0/2
desc Cust: ATT (link 2)

Then when it does graphs it gives me composite graphs for each of the ISPs.

If I use “Transit” in the descriptions, it sums up all 4 interfaces.

Peering seems to work like Transit.

What should I be using? ATT & Verizon are not customers, they are ISPs. But Customers sums them the way I want. What controls whether there are subtotals or only totals?

Gary

[laf]

If they are providing you transit then I’d label them as transit.

The peering and transit pages still provide you with a graph per link and the overall consolidated graph.

[galgier]

These are links to our ISPs. Both are setup with redundancy (one has diversity). The goal is to control the view so that we see it as:

Verizon
Verizon summed traffic graph
Verizon link 1 traffic graph
Verizon link 2 traffic graph

ATT
ATT summed traffic graph
ATT link 1 traffic graph
ATT link 2 traffic graph

That is what we see when I call them customer interfaces.

If I call them peering or transit the summed graph combines ATT with Verizon. I don’t want that.

It seems that the summation mechanism choice is magic. I have no real control.

What should I call an ISP? Are they a customer (obviously no)? But if choose anything else they are summed incorrectly.

How can I control the summation mechanism?

Gary

[laf]

I’m not following you. I created two ports, both called Transit, one named Cogent, the other Level3. I can see the summary of both together and the individual ones under the ‘Transit’ link in the ports menu

[MHammett]

A full table connection would be transit.