[nsp] Routing Problem: I am not sure where to begin.
Jim Devane
jim at powerpulse.cc
Tue Dec 16 14:05:36 EST 2003
Danny,
Thank you. Very interesting comments.
The only routing protocol that is running between the GSR's and the 7206 is
the BGP. And I do not believe the 7206 can run APS reflector mode anyway.
I hear what you are saying, and in fact, it spurred a though. Sop thank you
for jolting some of the rust free!
I can set up 2 distinct BGP session ( perhaps only based on physical
interface and only one will come up at a time since the APS protected
circuit will be up/down. It is a bit of a bummer b/c it is going to have to
send an open and build a whole new table.
I will have to try that Thurs night.
Do you have any thought on why I am not able to ping the other side of the
protect link when it comes up? This would obviously be detrimental to an BGP
session coming up.
Any ideas on what could be stopping that?
Thanks,
Jim
-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Danny McPherson
Sent: Tuesday, December 16, 2003 8:54 AM
To: <cisco-nsp at puck.nether.net> <cisco-nsp at puck.nether.net>
Subject: Re: [nsp] Routing Problem: I am not sure where to begin.
Jim,
What you're asking for is stateful TCP session mirroring
between the two 12012s, which isn't going to happen (only
a few existences of TCP state mirroring within a single
platform have occurred, much less inter-device). The BGP
sessions are attached to the physical interfaces and
different devices/stacks, they're not going to fail over
between different Layer 3 elements.
An implementation could perhaps make this work IF both
working and protect circuits terminated on the same
Layer 3 element one both sides of the connection, but
this clearly scopes the redundancy that APS provides.
The common deployment scenario to accomplish what you're
looking to do requires two BGP sessions from the 7206, one
to each of the 12012s, all peering via loopback IPs that
are reachable via the OC3 and/or the inter-12012 paths
(depending on which APS tributary is active).
Because you've got an OC48 connection between the 12012s
the sessions SHOULD always remain active, regardless of
which router (working or protect) is the active tributary.
Any other configuration would trigger sessions resets
per either BGP or IGP adjacency resets/synchronization
times.
You should also be using bi-directional mode.
Another nifty thing I've done in the past was use a /29
with odd IPs for working, even for protect. It avoids
hosing things with NMS systems and provides more intuitive
operational capabilities (e.g., DNS PTR records, traceroute
and the like clearly indicate which port/router you're
passing through).
Finally, if you're running an IGP such as OSPF or IS-IS
you may want to look at APS reflector mode, which basically
toggles some K bits in order to trigger IGP adjacency resets
to speed convergence (else you have to receive a hello from
a new/unknown neighbor on a point-to-point connection and
tear down the adjacency from there -- it used to be much
worse).
Else, at least increase the frequency of hellos so that a
new IGP neighbor is detected much more quickly.
HTH,
-danny
On Dec 15, 2003, at 1:20 PM, Jim Devane wrote:
> Jack,
>
> 1st and foremost, thank you very much for taking the time to reply.
> 2nd I will try your suggestion in a Thurs. night maintenance window.
>
> I was wondering if you would indulge me a few more minutes of your
> time to
> look the scenario over as it is a little different from what you
> outlined.
>
> Actually, I have a little bit different of a setup. It is as below....(
> stealing your ASCII diag)
>
> 12012 (1.1.1.1/30) --W--- | ---W---\ (1.1.1.2/30)
> | SONET | 7206
> 12012 (1.1.1.1/30) --P-- | ---P---/ (1.1.1.2/30)
>
> This is fine since the protect is "up/down" When the protect becomes
> active
> it is using the same IP.
>
> CEF seems cool with it and the routing seems cool with it.
>
> WHY, oh why would I do this?
>
> I don't want to tie the BGP session to just one router and I don't
> want more
> than 1 BGP session.
>
> Meaning, if I run BGP to the interface IP then BGP *should* never go
> down
> when the interface changes. ( no BGP timer will go off and the new
> router
> will send a open in time ) ((at least that is what I am hoping))
>
> Ultimately, I want to be able to swap the customer between the routers
> without taking a traffic hit ( upgrades or upstream trouble on one of
> the
> GSR's I can switch over to other providers quickly )
>
> Thanks again,
>
> Jim
>
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of
> Jack.W.Parks at alltel.com
> Sent: Monday, December 15, 2003 11:51 AM
> To: cisco-nsp at puck.nether.net
> Subject: RE: [nsp] Routing Problem: I am not sure where to begin.
>
> If you are using /30 on the working and /30 on the protect then you
> have
> two IP subnets that don't match when you have a fail over, because each
> side fails independently. Trying using a /29
>
> For example:
>
> Properly functioning APS setup (W) working and (P) protect. The /30's
> match working-to-working (1.1.1.0/30) and one for protect-to-protect
> (2.2.2.0/30)
>
> /-----------\
> 12012 (1.1.1.1/30) --W--- | ---W---\ (1.1.1.2/30)
> | SONET | 7206
> 12012 (2.2.2.1/30) --P-- | ---P---/ (2.2.2.2/30)
> \-----------/
>
> In a failure, the scenario looks like:
>
> /-----------\
> 12012 (1.1.1.1/30) --W--- | ---P---\ (1.1.1.2/30)
> | SONET | 7206
> 12012 (2.2.2.1/30) --P-- | ---W---/ (2.2.2.2/30)
> \-----------/
>
> Now the 1.1.1.1/30 connects to 2.2.2.2/30. Use a /29 and the
> interfaces
> (both working and protect) will share the same subnet and your routing
> should work fine.
>
> I hope this helps...
>
> Jack
>
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Jim Devane
> Sent: Monday, December 15, 2003 12:29 PM
> To: cisco-nsp at puck.nether.net
> Subject: [nsp] Routing Problem: I am not sure where to begin.
>
>
> All,
>
>
>
> I am having a routing problem that I don't know how to attack.
>
>
>
> I have 2 12012's connect together by OC-48
>
> Each 12012 in turn in connected by OC-3 to a Lucent DMX ADM. One OC-3
> is
> "working" and one is "protect"
>
> Each of the OC-3's is connected downstream (through a SONET cloud) to a
> customer and plugs into a 7206 VXR.
>
> APS is configured on all the routers.
>
>
>
> When I shut the "working" interface on one of the 12012's. The Protect
> interface does go "up/up" and a "sh controllers" show the correct
> SONET
> info for the 7206. The 7206 does not see it's interface change and a
> "sh
> controller" shows the new 12012 as being the downstream.
>
>
>
> I believe that APS/SONET is working correctly.
>
>
>
> However, when this situation happens I am not able to pass L3 traffic.
> No pings, no BGP, NUTHIN'.
>
>
>
> I check the cef adjacency and the routes. The adj is correct and the
> routes are not learned since BGP goes down.
>
> Worse, I am not able to ping the directly connected far end interfaces.
> Meaning, I shut the working on GSR 02, APS switches over to GSR 01 and
> the protect becomes active.
>
>
>
> If I do a sh ip route for the 7206 ip ( a /30 on the GSR) it will say
> it
> is directly connected out the correct interface.
>
> If I so a sh ip route for the 7206 on the former active GSR it says to
> go to GSR 01.
>
>
>
> Everything *looks* Ok, but traffic is not being passed.
>
>
>
> Any ideas at all? I am not sure where to start?
>
>
>
> TIA,
>
> Jim
>
>
>
>
>
> _______________________________________________
> cisco-nsp mailing list cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
> _______________________________________________
> cisco-nsp mailing list cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
> _______________________________________________
> cisco-nsp mailing list cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
_______________________________________________
cisco-nsp mailing list cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
More information about the cisco-nsp
mailing list