eigrp over atm

[rekdal163]

Hi,

i have what i think is an eigrp issue as the atm connecivity seems to be fine, no output from "debug atm error", or possibly ios incompatibility. anyway my troube is between a 3640 running ik9o3s-mz.123-16 ios and a 2821 on AdvEnt124-11.t1. all wan connections to the 3640 are atm subinterfaces. there are a total of 6 connections to the 3640 all of which are fine with the exception of the one to the 2821. all other devices are 2600 series routers except one pvc pointing at our core edge which is a 7206. the other difference is that the 2821 is running an atm-aim vwic-2mft-t1, where the others are on native atm controllers.

when i enable the interfaces between the 3640 and the 2821 the neighbor association comes up fine for about 1 min, and then says goodbye, it then comes back up almost immediately for about 1 min and says goodbye again. i have checked with the service provider and the the t1 and pvc are ok, we also have another pvc on this t1 that terminates at our 7206 which is not experiencing any trouble.

i have attached both router's conf's and debug/eigrp event log from 2821.

please let me know if you need further information.

any help is appreciated.

thanks,

Randy

[paolo bevilacqua]

Hi,

you should configure your traffic category (VBR, ABRU or what else) and the traffic parameters under each PVC. If these are common to more that one PVC, there is a "pvc class" tpe of configuration to simplify that.

If you don't do that, when a burst of traffic comes, like a routing update, the ATM network willdrop cells, result is disrupted communications and neighbor loss. If you do "show atm pvc" on the router, these should show as "failed reassembly" or something like that.

Also, you don't need to configure the EIGRP neighbor explicitly, these are automatically recognized, even if you use ip unnumbered.

May I ask why you are using "atm route-bridged" ?

[rekdal163]

will look into the pvc stats tomorrow. what timer in eigrp is at 1 minute intervals? also i do not see why it would exclusively effect this pvc. i do however appreciate your advice on the traffic categories as i am new to atm, i just started working with this network about a month ago and am in the process of learning its quirks. i do not know why the route-bridged statement is being used but it seems to be common across the network, can you point me to some information on its use?

Thank,

Randy

[paolo bevilacqua]

nevermind "atm route-bridged", we can look at that later. The atm service parameters are instead absolute crucial, ask your ATM provider about them. After proper configuration, everything will work nice and smooth. Leave alone EIGRP for now.

It is quite possible that you are seeing this on a PVC only because a 2821 is faster and more aggressive in sending than the other older routers.

[rekdal163]

can you help me out with the specific service paramters to request. i will be speaking with the ISP today. I have attached the sh pvc output you suggested as i do not see the stat you refrenced.

Thanks

[paolo bevilacqua]

Hi, the 2821 does not have cell loss on input (SarTimeOuts: 0). This means the 3640 is respecting the service parameters, even if not configured. Do the same command on 3640 and check how things look on its side for PVC going to 2821.

When talking to ATM provider, ask:

Do I have VBR ? (most likely)

If yes, what is my SCR and PCR ?

If not, what service category do I have ?

After this is solved you can look to switching to regular IP encapsulation over ATM that will let you save the unnecessary 14 bytes of overhead due to "atm route-bridged".

[rekdal163]

SarTimeOuts:0 from the 3640 back at the 2821.

will let ya know what i hear from the isp when they respond.

how would IMA effect this situation? we are adding an additional t1 to this location this evening, so all sub int's will be moved to the ATM/IMA Interface.

thanks again,

randy

full sh output attached

[paolo bevilacqua]

Ok, however the good ATM switches that your ATM provider may be using, implement something called "early packet drop" that prevents delivering of a frame that had missed cells. Is then possible that the traffic parameters are exceeded but you cannot not see that at receiving PVC level.

So my theory can be proven only when you learn the traffic parameter details and apply them.

Regarding the additional IMA circuit, sure go ahead, the more bandwidth the better.

[rekdal163]

isp states that we use UBR, that was all the info provided.

[paolo bevilacqua]

That is the worst answer you could get. Means, there is not guarantee whatsoever over the traffic you can send and the network will not warn you about anything. It is absolutely inadequate for business use and will prevent you from applying any QoS on the circuits.

Now this said, if you have to live with that, go ahead with the migration over IMA and if there are still issues you can go from there with some kind of workaround.

[rekdal163]

thanks for the input, not exactly what i wanted to hear but this is what we have to deal with.

in regard to a workaround, do you have any suggestions?

[paolo bevilacqua]

One would have to figure out how much the PVC is actually delivering. After the upgrade, try "ubr 500" under pvc, one side first, then the other, then both. Then you could gradually increase until the eigrp starts flapping again.

[rekdal163]

ok will play with that tomorrow after the ima is up and running.

[rekdal163]

tried the ubr setting on the pvc as low as 64 with no change in behaivor. IMA group is up and running happily. am considering an older ios, do you have anyother suggestions before going that route?

thanks

[paolo bevilacqua]

No, do not assume any bug in IOS before proven it is so.

Have you changed UBR on both sides ?

Can you enable "term mon" and "debug ip eigrp neigh" for the flapping neighbor.