[Cisco] PBR issue

[Zoetjuh]

Beste allen,

Op een cisco 2811 router probeer ik verkeer dat binnenkomt via een bepaalde interface, ook weer via die interface te laten terugbabbelen met een host om m'n netwerk. Nu is het alleen zo dat de 2811 via een andere interface terugbabbelt. Gezien mijn routing-table is dat ook wel logisch, waardoor ik via Policy Based Routing (PBR) dit wilde aanpakken.

Globaal de omgeving:

code:

LAN: 192.168.100.x (gw: 192.168.100.199)
            |
====================================
      192.168.100.199
             ISA
 192.168.200.4    192.168.101.4
====================================
           |         |
====================================
192.168.200.254  192.168.101.199
           Cisco 2811
====================================

De ISA heeft in totaal drie adapters. De 192.168.100.199 (richting LAN); de 192.168.101.4 met gw 192.168.101.199, waar het "normale" internet verkeer overheen gaat.
Als laatste heeft de ISA een adapter met IP 192.168.200.4, over welke een aantal subnets worden gerouteerd via de 192.168.200.254.

Op de Cisco is de 192.168.101.199 een routing-port en de 192.168.200.254 het IP van het VLAN waar de switchport onderdeel van is. De ISA is dus via één pootje verbonden met een switchport en via de andere met een routingport.

Op de cisco staat een static route voor 192.168.100.0 richting 192.168.101.4; dit zodat de werkplekken op het LAN ook pakketjes terugkrijgen.

Wat werkt:
- Pingen vanaf LAN naar 192.168.101.199 en hosts op internet
- Pingen vanaf LAN naar gerouteerde subnets (welke uiteindelijk via de 192.168.200.254 worden gerouteerd)
- Pingen vanaf de ISA richting 192.168.200.254

Wat werkt niet:
- Pingen vanaf LAN richting de 192.168.200.254

De reden waarom ISA zo is ingericht, is zodat we elk 'type' netwerken (private, internet en vestigingen) zo per adapter hebben gescheiden.

Gezien de Cisco een route voor 192.168.100.x -> 192.168.101.4 heeft, snap ik dat een ping richting de 192.168.200.254 niet werkt. Immers, de interface waarop de ping binnenkort (vlan2) is anders als de interface waar de reply vandaan komt (de 192.168.101.199). Ik dacht met een PBR op de VLAN2 dit issue op te kunnen lossen:

code:

interface vlan 2
 ip policy route-map Internal200to100
!
access-list 111 permit ip 192.168.200.0 0.0.0.255 192.168.100.0 0.0.0.255
!
route-map Internal200to100 permit 10
 match ip address 111
 set ip next-hop 192.168.200.4
!

Gek genoeg blijkt dit niet te werken. Ik heb ook getracht deze policy op de routinginterface (192.168.101.199) te plaatsen, maar ook zonder success..

Het nadeel van 'debug ip policy' is het feit dat hier zoveel verkeer overheen loopt, dat m'n telnet sessie er bijna direct onder bezwijkt, waardoor ik twijfel wat nu de oorzaak zou kunnen zijn.

Update
De reden waarom het niet werkt ben ik inmiddels achter: PBR werkt on INBOUND packets. Nu ping ik een interface van de cisco en gaat het om de reply welke de Cisco moet versturen. In andere woorden, het gaat om een outbound packet. Vraag is dan: hoe kan ik twee verschillende "ip route 192.168.100.0 255.255.255.0"-routes aanmaken, waarbij gekeken wordt naar de interface waarop deze is binnengekomen. Mijn gedachten zelf: VRF (ook al heb ik daar niet eerder mee gewerkt).

[ Voor 7% gewijzigd door Zoetjuh op 23-08-2010 20:53 ]

[Kabouterplop01]

waarom niet een static route? ip route 192.168.100 255.255.255.0 192.168.200.4 (ervan uitgaande dat da klasse c is)

Komt als je op je 2811 debug ip icmp aanzet je ping wel aan?

[ Voor 86% gewijzigd door Kabouterplop01 op 23-08-2010 21:29 ]

[Zoetjuh]

Kabouterplop01 schreef op maandag 23 augustus 2010 @ 21:26:
waarom niet een static route? ip route 192.168.100 255.255.255.0 192.168.200.4 (ervan uitgaande dat da klasse c is)

Komt als je op je 2811 debug ip icmp aanzet je ping wel aan?

Aangezien het verkeer vanaf het 192.168.100.x (LAN) via de ISA over het 192.168.101.x-subnet richting het internet wordt gestuurd, heb ik al een "ip route 192.168.100.0 255.255.255.0 192.168.101.4".

De pings richting de 192.168.200.254 komen overigens netjes op de router aan (getest door een 'debug ip packet 111'). Enkel de replies op pings richting 192.168.200.254 krijg ik op mijn werkplek (binnen het 192.168.100.x) niet terug (althans, ping/traceroute laat een * zien). Richting de 192.168.101.199 krijg ik netjes een ping-reply.

Ik snap het ook wel, immers, de ping komt binnen op 192.168.200.254, maar de reply krijg ik - door de huidige ip route regel - van 192.168.101.199 (en niet van de verwachtte 192.168.200.254); waardoor een ping/traceroute een * zal laten zien.

[jvanhambelgium]

Als je nu de ACL zou aanpassen naar

access-list 111 permit ip 192.168.100.0 0.0.0.255 192.168.200.0 0.0.0.255


Zal dit toch wel werken ? Je doet een ping naar de interface van de Cisco zelve, zijnde 192.168.200.254 *VANAF* een station op je LAN 192.168.100.x
Dit zal een match geven met deze ACL. Vervolgens moet de reply van de Cisco terug naar je workstation op de 192.168.100.x LAN en deze zal wel via PBR verwerkt worden lijkt me zo.

Met zo'n constructies moet je ook oppassen of ISA niets gaat blokkeren omdat ie replies op andere interfaces ziet terugkomen oid.
Desnoods maak je ACL 111 fijner tot op 1 host (je testhost) en kan je veilig PBR-debugging doen zonder teveel brol te zien om te zien wat er allemaal beweegt binnen het IOS.


Met je initiele ACL had je geen match als je een ping vanaf je LAN (192.168.100.x) naar de Cisco interface doet (192.168.200.254). De *source* moest 192.168.200.x zijn met destination 192.168.100.x dus qua inbound traffiek zal dat niet veel matchen tenzij je ergens op die ISA NAT doet zodat er packets uitkomen die als source 192.168.200.4 oid gekregen hebben.

[Zoetjuh]

jvanhambelgium schreef op dinsdag 24 augustus 2010 @ 08:18:
Als je nu de ACL zou aanpassen naar

access-list 111 permit ip 192.168.100.0 0.0.0.255 192.168.200.0 0.0.0.255

Met je initiele ACL had je geen match als je een ping vanaf je LAN (192.168.100.x) naar de Cisco interface doet (192.168.200.254). De *source* moest 192.168.200.x zijn met destination 192.168.100.x dus qua inbound traffiek zal dat niet veel matchen tenzij je ergens op die ISA NAT doet zodat er packets uitkomen die als source 192.168.200.4 oid gekregen hebben.

Mee eens, die ACL zou triggeren, Alleen zou ik de "inbound ping" dan hoog uit kunnen verplaatsen naar de 192.168.101.199-interface. Immers, PBR kan ik een interface/nexthop aanpassing doen, maar niet triggeren dat de reply op de ping / de outbound packet hierdoor wordt aangepast (zover ik weet). Wazig is natuurlijk wel, dat je de 192.168.200.254 pingt, maar die dan uiteindelijk op de 192.168.101.199 wordt afgeleverd (als dit al zou werken).

[ Voor 10% gewijzigd door Zoetjuh op 24-08-2010 10:16 ]

[MrFX]

Zoetjuh schreef op maandag 23 augustus 2010 @ 14:10:
Beste allen,

Op een cisco 2811 router probeer ik verkeer dat binnenkomt via een bepaalde interface, ook weer via die interface te laten terugbabbelen met een host om m'n netwerk. Nu is het alleen zo dat de 2811 via een andere interface terugbabbelt. Gezien mijn routing-table is dat ook wel logisch, waardoor ik via Policy Based Routing (PBR) dit wilde aanpakken.

Globaal de omgeving:

code:

LAN: 192.168.100.x (gw: 192.168.100.199)
            |
====================================
      192.168.100.199
             ISA
 192.168.200.4    192.168.101.4
====================================
           |         |
====================================
192.168.200.254  192.168.101.199
           Cisco 2811
====================================

De ISA heeft in totaal drie adapters. De 192.168.100.199 (richting LAN); de 192.168.101.4 met gw 192.168.101.199, waar het "normale" internet verkeer overheen gaat.
Als laatste heeft de ISA een adapter met IP 192.168.200.4, over welke een aantal subnets worden gerouteerd via de 192.168.200.254.

Op de Cisco is de 192.168.101.199 een routing-port en de 192.168.200.254 het IP van het VLAN waar de switchport onderdeel van is. De ISA is dus via één pootje verbonden met een switchport en via de andere met een routingport.

Op de cisco staat een static route voor 192.168.100.0 richting 192.168.101.4; dit zodat de werkplekken op het LAN ook pakketjes terugkrijgen.

Wat werkt:
- Pingen vanaf LAN naar 192.168.101.199 en hosts op internet
- Pingen vanaf LAN naar gerouteerde subnets (welke uiteindelijk via de 192.168.200.254 worden gerouteerd)
- Pingen vanaf de ISA richting 192.168.200.254

Wat werkt niet:
- Pingen vanaf LAN richting de 192.168.200.254

De reden waarom ISA zo is ingericht, is zodat we elk 'type' netwerken (private, internet en vestigingen) zo per adapter hebben gescheiden.

Gezien de Cisco een route voor 192.168.100.x -> 192.168.101.4 heeft, snap ik dat een ping richting de 192.168.200.254 niet werkt. Immers, de interface waarop de ping binnenkort (vlan2) is anders als de interface waar de reply vandaan komt (de 192.168.101.199). Ik dacht met een PBR op de VLAN2 dit issue op te kunnen lossen:

code:

interface vlan 2
 ip policy route-map Internal200to100
!
access-list 111 permit ip 192.168.200.0 0.0.0.255 192.168.100.0 0.0.0.255
!
route-map Internal200to100 permit 10
 match ip address 111
 set ip next-hop 192.168.200.4
!

Gek genoeg blijkt dit niet te werken. Ik heb ook getracht deze policy op de routinginterface (192.168.101.199) te plaatsen, maar ook zonder success..

Het nadeel van 'debug ip policy' is het feit dat hier zoveel verkeer overheen loopt, dat m'n telnet sessie er bijna direct onder bezwijkt, waardoor ik twijfel wat nu de oorzaak zou kunnen zijn.

Update
De reden waarom het niet werkt ben ik inmiddels achter: PBR werkt on INBOUND packets. Nu ping ik een interface van de cisco en gaat het om de reply welke de Cisco moet versturen. In andere woorden, het gaat om een outbound packet. Vraag is dan: hoe kan ik twee verschillende "ip route 192.168.100.0 255.255.255.0"-routes aanmaken, waarbij gekeken wordt naar de interface waarop deze is binnengekomen. Mijn gedachten zelf: VRF (ook al heb ik daar niet eerder mee gewerkt).

Als ik je vraag goed heb begrepen kun je het middels ip route 192.168.100.0 255.255.255.0 %interface% %distance%

[Zoetjuh]

MrFX schreef op dinsdag 24 augustus 2010 @ 10:28:
[...]

Als ik je vraag goed heb begrepen kun je het middels ip route 192.168.100.0 255.255.255.0 %interface% %distance%

Je bedoeld het volgende: ?

ip route 192.168.100.0 255.255.255.0 192.168.101.4
ip route 192.168.100.0 255.255.255.0 192.168.200.4 20

Dam zal (neem ik aan) toch altijd de laagste distance worden gepakt? Ofwel, is de ping-reply op 192.168.200.254 alsnog verstuurd vanuit 192.168.101.199 -> 192.168.101.4?

[ Voor 8% gewijzigd door Zoetjuh op 24-08-2010 10:32 ]

[jvanhambelgium]

Wat werkt:
- Pingen vanaf LAN naar 192.168.101.199 en hosts op internet

>> Aangezien de ISA NAT zal doen voor 192.168.100.x LAN IP's alvorens deze op Internet te zwieren is het inderdaad logisch dat dit werkt. De Cisco ziet enkel 192.168.101.4 waarschijnlijk als IP en dit gaat netjes op Internet buiten.

- Pingen vanaf LAN naar gerouteerde subnets (welke uiteindelijk via de 192.168.200.254 worden gerouteerd)

>> Route op de Cisco staat goed, replies gaan netjes terug naar de ISA en zo terug naar de LAN stations.


- Pingen vanaf de ISA richting 192.168.200.254

>> Logisch, "exiting" packet op de ISA zal al source 192.168.200.4 hebben en dan is er geen issue. Voor de Cisco is dat gewoon een directly-connected en reply zal wel werken.


Wat werkt niet:
- Pingen vanaf LAN richting de 192.168.200.254

>> Is dat nu eigenlijk het probleem ? Waarom wil je in godsnaam persé kunnen pingen ? Indien je een interface voor management wil maak dan desnoods een extra Loopback aan om al deze probleme te vermijden.
Dit probleem zou je toch met PBR kunnen oplossen. Op de cisco moet dan een goede "match" gedaan worden met een correct ACL. (source = 192.168.100.x destination = 192.168.200.x) en als actie de gateway van 192.168.200.4 opgeven. Standaard wijst je static inderdaad naar 192.168.101.4

[MrFX]

Zoetjuh schreef op dinsdag 24 augustus 2010 @ 10:32:
[...]


Je bedoeld het volgende: ?

ip route 192.168.100.0 255.255.255.0 192.168.101.4
ip route 192.168.100.0 255.255.255.0 192.168.200.4 20

Dam zal (neem ik aan) toch altijd de laagste distance worden gepakt? Ofwel, is de ping-reply op 192.168.200.254 alsnog verstuurd vanuit 192.168.101.199 -> 192.168.101.4?

Zoetjuh schreef op dinsdag 24 augustus 2010 @ 10:32:
[...]


Je bedoeld het volgende: ?

ip route 192.168.100.0 255.255.255.0 192.168.101.4
ip route 192.168.100.0 255.255.255.0 192.168.200.4 20

Dam zal (neem ik aan) toch altijd de laagste distance worden gepakt? Ofwel, is de ping-reply op 192.168.200.254 alsnog verstuurd vanuit 192.168.101.199 -> 192.168.101.4?

Als ik je verhaal goed begrijp (los van de ping gezien) wil je van bepaalde subnetten het tx en rx verkeer over dezelfde interface laten verlopen. Een inbound PBR i.c.m. met de bovenstaande static routes voorzien van distance moet het mogelijk maken voor zover ik niets over het hoofd zien.

Laagste distance word gepakt idd default static route is 1 en connected interfaces hebben een distance van 0.

[Zoetjuh]

Probleem is alleen dat de 192.168.100.x niet direct connected is, waardoor toch die route met de laatste metric wordt gepakt en verkeer over richting de 192.168.101.4 gestuurd wordt. Een PBR werkt dus helaas niet omdat dit alleen inbound verkeer kan aanpassen.

Even recap; wat doe ik:

Vanaf 192.168.100.24

code:

C:\Users\Administrator>tracert -d 192.168.200.254

Traceren van de route naar 192.168.200.254 via maximaal 30 hops

  1   <1 ms   <1 ms     1 ms  192.168.100.199
  2     *        *        *     Time-out bij opdracht.
  3     *        *        *     Time-out bij opdracht.
  4  ^C

Verkeer richting de de 192.168.80.x wordt op de ISA-bak gerouteerd naar 192.168.200.254:

code:

C:\Users\Administrator>tracert -d 192.168.80.10

Traceren van de route naar 192.168.80.10 via maximaal 30 hops

  1     1 ms   <1 ms   <1 ms  192.168.100.199
  2     *        *        *     Time-out bij opdracht.
  3     2 ms     1 ms     1 ms  172.31.255.20
  4    13 ms    13 ms    13 ms  172.31.255.21
  5    28 ms    29 ms    30 ms  192.168.80.1
  6    28 ms    28 ms    28 ms  192.168.80.10

De trace is voltooid.

Vanaf de 192.168.80.10 is te zien dat de PBR het verkeer vanaf 192.168.80.x wel over de 192.168.200.4 stuurt (dit is de PBR op de dialer voor de ADSL/Glas verbinding):

code:

Z:\>tracert -d 192.168.100.24

Tracing route to 192.168.100.24 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  192.168.80.1
  2    18 ms    16 ms    16 ms  172.31.255.21
  3    28 ms    28 ms    28 ms  192.168.34.2
  4    29 ms    28 ms    28 ms  192.168.200.4
  5    29 ms    28 ms    28 ms  192.168.100.24

Trace complete.

[MrFX]

Is het ip adres 192.168.200.4 overigens wel de pingen vanaf het LAN?

[Zoetjuh]

Yep

[MrFX]

je zou PBR uit kunnen zetten om te testen of je de boel vervolgens wel kan pingen om uit te sluiten of de problemen zich in ISA server afspelen of in de PBR configuratie.

Wat zeg de output van het commando route print overigens op de ISA server

[ Voor 3% gewijzigd door MrFX op 24-08-2010 13:10 ]

[Zoetjuh]

De PBR (192.168.80.0 -> 192.168.100.0; set next-hop 192.168.200.4) zit niet tussen de werkplek en de 192.168.200.254 (helaas). Deze zit op de PPP-Dialer richting de ISP (waardoor deze alleen op packets vanaf de ISP wordt toegepast).

De andere PBR (welke dus niet wil wat ik wil) had ik intussen weggehaald, maar ook zonder success.
Overigens kan de ISA de 192.168.200.254 (logischerwijs) wel pingen, immers, deze is gewoon directly connected voor ISA.

Hierbij sowieso nog even de routing table van de ISA:

code:

IPv4 Route Table
===========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x10003 ...00 04 76 f8 9c 20 ...... 3Com 3C996B Gigabit Server NIC
0x10004 ...00 11 0a e9 06 43 ...... HP NC7760 Gigabit Server Adapter
0x10005 ...00 16 0a 1c 4d 3d ...... Realtek RTL8169 Gigabit Ethernet Adapter
===========================================================================
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0  192.168.101.199    192.168.101.4     20
        127.0.0.0        255.0.0.0        127.0.0.1        127.0.0.1      1
     192.168.80.0    255.255.255.0  192.168.200.254    192.168.200.4      1
    192.168.80.10  255.255.255.255  192.168.200.254    192.168.200.4      1
    192.168.100.0    255.255.255.0  192.168.100.199  192.168.100.199     10
  192.168.100.199  255.255.255.255        127.0.0.1        127.0.0.1     10
  192.168.100.255  255.255.255.255  192.168.100.199  192.168.100.199     10
    192.168.101.0    255.255.255.0    192.168.101.4    192.168.101.4     20
    192.168.101.4  255.255.255.255        127.0.0.1        127.0.0.1     20
  192.168.101.255  255.255.255.255    192.168.101.4    192.168.101.4     20
    192.168.200.0    255.255.255.0    192.168.200.4    192.168.200.4     10
    192.168.200.4  255.255.255.255        127.0.0.1        127.0.0.1     10
  192.168.200.255  255.255.255.255    192.168.200.4    192.168.200.4     10
        224.0.0.0        240.0.0.0  192.168.100.199  192.168.100.199     10
        224.0.0.0        240.0.0.0    192.168.101.4    192.168.101.4     20
        224.0.0.0        240.0.0.0    192.168.200.4    192.168.200.4     10
  255.255.255.255  255.255.255.255  192.168.100.199  192.168.100.199      1
  255.255.255.255  255.255.255.255    192.168.101.4    192.168.101.4      1
  255.255.255.255  255.255.255.255    192.168.200.4    192.168.200.4      1
Default Gateway:   192.168.101.199
===========================================================================
Persistent Routes:
  Network Address          Netmask  Gateway Address  Metric
     192.168.80.0    255.255.255.0  192.168.200.254       1

[ Voor 72% gewijzigd door Zoetjuh op 24-08-2010 13:43 ]

[MrFX]

Zoetjuh schreef op dinsdag 24 augustus 2010 @ 13:42:
De PBR (192.168.80.0 -> 192.168.100.0; set next-hop 192.168.200.4) zit niet tussen de werkplek en de 192.168.200.254 (helaas). Deze zit op de PPP-Dialer richting de ISP (waardoor deze alleen op packets vanaf de ISP wordt toegepast).

De andere PBR (welke dus niet wil wat ik wil) had ik intussen weggehaald, maar ook zonder success.
Overigens kan de ISA de 192.168.200.254 (logischerwijs) wel pingen, immers, deze is gewoon directly connected voor ISA.

Hierbij sowieso nog even de routing table van de ISA:

code:

IPv4 Route Table
===========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x10003 ...00 04 76 f8 9c 20 ...... 3Com 3C996B Gigabit Server NIC
0x10004 ...00 11 0a e9 06 43 ...... HP NC7760 Gigabit Server Adapter
0x10005 ...00 16 0a 1c 4d 3d ...... Realtek RTL8169 Gigabit Ethernet Adapter
===========================================================================
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0  192.168.101.199    192.168.101.4     20
        127.0.0.0        255.0.0.0        127.0.0.1        127.0.0.1      1
     192.168.80.0    255.255.255.0  192.168.200.254    192.168.200.4      1
    192.168.80.10  255.255.255.255  192.168.200.254    192.168.200.4      1
    192.168.100.0    255.255.255.0  192.168.100.199  192.168.100.199     10
  192.168.100.199  255.255.255.255        127.0.0.1        127.0.0.1     10
  192.168.100.255  255.255.255.255  192.168.100.199  192.168.100.199     10
    192.168.101.0    255.255.255.0    192.168.101.4    192.168.101.4     20
    192.168.101.4  255.255.255.255        127.0.0.1        127.0.0.1     20
  192.168.101.255  255.255.255.255    192.168.101.4    192.168.101.4     20
    192.168.200.0    255.255.255.0    192.168.200.4    192.168.200.4     10
    192.168.200.4  255.255.255.255        127.0.0.1        127.0.0.1     10
  192.168.200.255  255.255.255.255    192.168.200.4    192.168.200.4     10
        224.0.0.0        240.0.0.0  192.168.100.199  192.168.100.199     10
        224.0.0.0        240.0.0.0    192.168.101.4    192.168.101.4     20
        224.0.0.0        240.0.0.0    192.168.200.4    192.168.200.4     10
  255.255.255.255  255.255.255.255  192.168.100.199  192.168.100.199      1
  255.255.255.255  255.255.255.255    192.168.101.4    192.168.101.4      1
  255.255.255.255  255.255.255.255    192.168.200.4    192.168.200.4      1
Default Gateway:   192.168.101.199
===========================================================================
Persistent Routes:
  Network Address          Netmask  Gateway Address  Metric
     192.168.80.0    255.255.255.0  192.168.200.254       1

Zo te zien is je routing tabel in orde op je isa server. Mooi moment om me eens verder te verdiepen in ICMP.
Zou je de output van commando show ip route van de 2811 ook eens kunnen posten.

[Zoetjuh]

We gebruiken BGP om verbinding te maken met het internet, vandaar dat de def. route naar een ogenschijnlijk private IP loopt:

code:

Gateway of last resort is 172.31.255.20 to network 0.0.0.0

     172.31.0.0/32 is subnetted, 3 subnets
C       172.31.255.3 is directly connected, Dialer1
C       172.31.255.20 is directly connected, Dialer3
C       172.31.255.21 is directly connected, Dialer2
C    192.168.200.0/24 is directly connected, Vlan2
S    192.168.80.0/24 [1/0] via 172.31.255.20
     192.168.34.0/32 is subnetted, 3 subnets
C       192.168.34.2 is directly connected, Dialer2
C       192.168.34.3 is directly connected, Dialer3
C       192.168.34.1 is directly connected, Dialer1
S    192.168.100.0/24 [1/0] via 192.168.101.4
C    192.168.101.0/24 is directly connected, FastEthernet0/0
B*   0.0.0.0/0 [20/0] via 172.31.255.20, 17:05:36

De dialers richting het internet hebben de IPs 192.168.34.x (yep, drie verbindingen).
De BGP neighbours zijn de 172.31.255.x

Ik heb de volgende IP-route regels:

code:

ip route 192.168.80.0 255.255.255.0 172.31.255.20
ip route 192.168.80.0 255.255.255.0 172.31.255.21 20
ip route 192.168.100.0 255.255.255.0 192.168.101.4
ip route 192.168.100.0 255.255.255.0 192.168.200.4 20
ip route 192.168.101.0 255.255.255.0 Null0
ip route 192.168.200.0 255.255.255.0 Null0

direct dan maar de show ip bgp laten zien (en ja, ik gebruik nu maar 2 neighbours):

code:

   Network          Next Hop            Metric LocPrf Weight Path
*> 0.0.0.0          172.31.255.20                      65535 28685 ?
*                   172.31.255.21                          0 28685 ?
*> 172.31.255.3/32  0.0.0.0                  0         32768 ?
*> 172.31.255.20/32 0.0.0.0                  0         32768 ?
*> 172.31.255.21/32 0.0.0.0                  0         32768 ?
*> 192.168.34.1/32  0.0.0.0                  0         32768 ?
*> 192.168.34.2/32  0.0.0.0                  0         32768 ?
*> 192.168.34.3/32  0.0.0.0                  0         32768 ?
*> 192.168.100.0    192.168.101.4            0         32768 i
*> 192.168.101.0    0.0.0.0                  0         32768 i
*> 192.168.200.0    0.0.0.0                  0         32768 i

OK This raises the question... Zou ik deze nog moeten toevoegen: "ip route 192.168.100.0 255.255.255.0 Null0"

[ Voor 26% gewijzigd door Zoetjuh op 24-08-2010 14:47 ]

[MrFX]

Dit lijkt met het probleem niet. Hangt er tusen het LAN en de 192.168.100.199 ook nog een cisco switch of iets dergelijks?

Aangezien het een productie omgeving is zou je op een rustig moment eens kunnen spelen met het commando debug ip packet detail en vervolgens een ping vanaf het lan kunnen geven en de output kunnen bestuderen. Komen de echo requests uberhaupt wel aan of .... Let op het bovenstaande commando kan een zwik aan cpu resources gebruiken.

Verder ben ik ook benieuwd hoe je de verbinding (van de 2811 naar de 192.168.200.4) aan beide kanten is geconfigureerd.

Mijn eerste vermoede is dat het ergens in de settings van de ISA server zit maar meten is weten. Overigens welke ISA versie heb je?

[ Voor 14% gewijzigd door MrFX op 24-08-2010 16:31 ]

[Zoetjuh]

Zojuist kunnen testen; toevoegen van de "ip route 192.168.100.0 255.255.255.0 Null0" werkt inderdaad niet. Verder zie ik inderdaad dat ISA de ping-reply tegenhoudt. Source IP klopt, maar aangezien deze via de 192.168.101.x-inferface binnenkomt, wordt het pakketje door ISA inderdaad gedropped.

Nu vermoedde ik dat het hier om Spoof Detection ging (immers, de 192.168.200.254 heeft in de arp-lijst van ISA een ander MAC-adres als het adres waar het packet vandaan komt (gezien deze van het MAC-adres van de 192.168.100.199 komt); dus heb ik de registeraanpassing in "http://support.microsoft.com/kb/838114/" doorgevoerd.

Het issue is hiermee in ieder geval opgelost. Gezien er routers voor de ISA zitten, heb ik er minder problemen mee dat Spoof Detection uit staat.

Dank voor het meedenken!

[MrFX]

Zoetjuh schreef op maandag 30 augustus 2010 @ 00:59:
Zojuist kunnen testen; toevoegen van de "ip route 192.168.100.0 255.255.255.0 Null0" werkt inderdaad niet. Verder zie ik inderdaad dat ISA de ping-reply tegenhoudt. Source IP klopt, maar aangezien deze via de 192.168.101.x-inferface binnenkomt, wordt het pakketje door ISA inderdaad gedropped.

Nu vermoedde ik dat het hier om Spoof Detection ging (immers, de 192.168.200.254 heeft in de arp-lijst van ISA een ander MAC-adres als het adres waar het packet vandaan komt (gezien deze van het MAC-adres van de 192.168.100.199 komt); dus heb ik de registeraanpassing in "http://support.microsoft.com/kb/838114/" doorgevoerd.

Het issue is hiermee in ieder geval opgelost. Gezien er routers voor de ISA zitten, heb ik er minder problemen mee dat Spoof Detection uit staat.

Dank voor het meedenken!

thnx voor je terugkoppeling dat word hier nog wel eens vergeten op het forum