I am doing BGP with a customer but he claimed that he is not getting any prefixes from me even though from my end, my router is showing that I am sending him the full internet route.
There are no filters at both our end and I can see that he is not getting any routes from me as I did not see any packets coming in from them.
However, when I send him the default route, using default-originate, his prefix increase to 1 and stop there. When I remove the default-originate, it start to increase but very slowly and my output queue to him is very long, about 90+k.
However, in the event of any BGP reset, my prefixes to him would not go through again and I have to reinstate and remove the default-originate command.
I am very puzzled over this as I should not need to kickstart my advertisement to him by using default-originate.
Would appreciate very much if any one can shed light on this issue for me.
Is the BGP peer bouncing on your side--are you seeing your peering relationship with the customer bounce up and down? If not, then is this a multihop BGP session? If it is, are you certain they have a good route to the next hop (learned through something other than BGP?).
Other than this, it could be that the customer's router simply can't handle the routes you're trying to feed into it. How much memory does the customer's router have? What type of router is it? They're going to need 256MB of memory, most likely, and something with a decent processor, at least a 3600 series, to handle full routes.
If they can get away with just a default or partial routes, they'd be better off with one of those, anyway, unless they are dual homed and specifically want to optimally route to every possible destination. Partial routes with a default will give you fairly close to optimal routing without the headache of full routes.
Let me show you my BGP setting with this customer:
neighbor A.B.C.D remote-as 12345
neighbor A.B.C.D description Customer
neighbor A.B.C.D update-source Serial3/2
neighbor A.B.C.D soft-reconfiguration inbound
neighbor A.B.C.D maximum-prefix 30 80
This is the BGP summary of the connection:
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
A.B.C.D 4 12345 7185 1262310 0 0 0 1d16h 18
As you can see the BGP is rather stable. And this customer do do multihome with another upstream and over at my end, I just connect him to one of my upstream providers only. I can only believe that they have a good route to the next hop as I am not too sure about their setup.
My customer is connected to me via satellite and they are using a 7500 series router to do BGP with me. Therefore, I don't think hardware is the issue here. I am using a 7206 VXR myself. :)
My customer do require full routes as they are multihome and need to know which path is the most optimial for reaching any destionation.
What sort of information can you get off the customer's router? I don't think the problem is on your end at this point, though it's interesting that you're using an update source command. My best bet--ask the customer to open a TAC case. If not, we're going to need to start looking at their BGP information--what's their BGP configuration look like, can they give you a show ip bgp for some of the routes they should be learning from you, spaced apart so we can see if they are flapping, etc.
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 ...